AIエージェントはなぜルールを守らないのか — 物理的ガバナンスの必要性
きっかけとなった出来事
あるリポジトリに 130KB を超えるガバナンスドキュメントが存在していた。
AIエージェントはそれを読んだ。理解した。そして次のツール呼び出しで違反した。
これは指示の失敗ではない。アーキテクチャの失敗である。
テキストルールが機能しない理由
AIエージェントにルールを守らせる方法として、現在ほぼすべてのチームが採用しているのは「プロンプトで禁止する」だ。
ルール
- evals/ ディレクトリは絶対に編集しないこと
- 00_Management/ 配下への Write は禁止
このアプローチには構造的な欠陥がある。
テキストルールは「読まれた瞬間」に機能する。エージェントが「選択する」ことを前提にしている。
しかし実行時点でその選択を強制する仕組みは存在しない。
同じ理由で rm -rf / にはポリシー文書ではなく確認フラグが存在する。物理的な制約は実行時点で機能する。テキストルールは読まれた時点でしか機能しない。それは間違ったタイミングだ。
検証の汚染問題
もう一つの構造的問題がある。
エージェントが自分の成果物を評価できる場合、評価基準を改竄できる。意図的にではなく、生成時と同じ失敗モードを評価時にも持ち込む形で。
テストが常にパスするシステムは、テストが機能していない可能性がある。
AOS が定義するもの
AI Operating Standard（AOS） は、エージェントガバナンスのための最小物理制約層を定義する仕様だ。
核心は3つだ：
1. Zones — 全パスを3種に分類する
| Zone | クラス | Write 権限 |
|---|---|---|
| Oracle | 読み取り専用・絶対的 | いかなるエージェントも書けない |
| Permitted | エージェント作業空間 | ロール範囲内で可 |
| Prohibited | スコープ外 | 主権者の明示承認のみ |
2. Roles — 役割を重複させない
設計官・実行官・承認者の3役割は構造的に分離する。エージェントは自分に割り当てられた役割の外で動いてはならない。役割境界に到達した場合、エージェントは作業を止め人間に報告する義務を持つ。
3. Physical Enforcement — フックで実行時点に介入する
PreToolUse フックがファイルシステムへのアクセス前に Write 操作を遮断する。
- Oracle Zone への Write → exit 2（実行されない）
- 禁止パターン（
sed -i等）→ exit 2
エージェントの「善意」を前提にしない。物理法則で縛る。
参照実装：iron_cage
iron_cage は AOS の参照実装だ。Claude Code の PreToolUse Hook システムで §4.1〜§4.5 を実装している。
iron_cage の背後には Type-91 Governance と呼ぶ設計原則がある。Forensic isolation（事後追跡可能な物理証跡）と Physical isolation（エージェントが自分の検証結果を改竄できない構造）の二軸だ。スクリプトはその表面に過ぎない。
AOS は仕様であり、iron_cage はその証明だ。
エージェント自身に読ませる
AOS-v0.1.md の §0 は「Machine-Reading Instructions」から始まる。
エージェントのコンテキストにこの仕様書を渡せば、エージェントは自分が何をしてはならないかを仕様レベルで理解する。
「プロンプトで禁止する」のではなく、「仕様書を読んだエージェントが自律的に準拠する」。これが AOS のもう一つの設計意図だ。
なぜ今か
2026年現在、エージェントが書いたコードを「どう信頼するか」は未解決問題のままだ。ほとんどのチームはまだプロンプトで対処しようとしている。
物理的ガバナンス層の標準が存在しない今、誰かが定義する必要がある。AOS はその試みだ。
最後に
AOS は完成した規格ではない。v0.1 はドラフトだ。
フィードバック・Issue・実装報告を歓迎する。
Discussion