経験的研究：AIエージェントのルールにはコンテキストと階層的な強制が必要

経験的研究：AIエージェントのルールにはコンテキストと階層的な強制が必要 CLAUDE.mdではAIエージェントのルールはシンプルに見えますが、ActPlaneの2,116ステートメントにわたる研究は、コンテキストと階層的なOS強制が何がチェックできるかを決定することを示しています。 「コミット前に完全なテストスイートを実行する」のようなルールは、AIコーディングエージェントが最後のテスト実行後にソースファイルを編集してからgit commitを呼び出すまで、シンプルに見えます。カーネルは通常のプロセスがコミットオブジェクトを書き込んでいると見ますが、ハーネスはさらに1つのツール呼び出しとして見ますが、決定はどのテスト結果がまだ新しいか、どの編集が無効にしたか、そしてこのコミットが現在許可されているかに依存します。ActPlaneの論文は、開発者が書く行動ルールと、システムが実際にチェックできるサブセットとの間のギャップを測定します。2,116命令のステートメントレベル分析は、開発者がルール不足ではないことを示しています。難しさは、自然言語の要件を、システムが時間とともに観察および評価できる状態に変換することにあります。多くのルールはファイル、プロセス、またはネットワークアクティビティに関係しますが、リポジトリ構造、タスクの進行状況、または以前のイベントに依存するため、単一のOSフックはポリシーセットの一部しかカバーできません。 開発者はすでにポリシーを記述している AIエージェントの安全性に関するほとんどの議論は、脅威モデルまたは攻撃サーフェスから始まります。ActPlaneは異なる質問から始めます。開発者はすでにエージェントに何をすべきか、何をすべきでないかを伝えており、それらの指示を強制するには何が必要か？この研究は、CLAUDE.mdおよびAGENTS.mdファイルを含む64の一般的なリポジトリ（中央値20K GitHubスター、2026-05-23のスナップショット）を調査し、84の指示ファイルと2,116の個々のステートメントをカバーしています。以前の研究がファイルまたはセクション見出しレベルで指示ファイルを分析したのとは異なり、ActPlaneは各ステートメントを個別に分類します。この研究は3つの質問をします。指示ファイルは主に行動ポリシーか、それとも記述的なコンテキストか？どのポリシーがOSレベルの強制を必要とし、どのような種類のOSレベルチェックが必要か？これらのポリシーを具体的な強制可能なルールにインスタンス化するために、どのようなコンテキストが必要か？ステートメントは、コンテンツタイプ、トピック、強制レベル、およびコンテキスト要件の4つのラベルを記録した、2パスのLLMエージェント支援パイプラインを通じて抽出されました。検証スクリプトは完全なソースカバレッジと正確なスパンマッチングを確認し、その後2つの独立したエージェント（ClaudeとCodex）が結果をクロスチェックしました。100ステートメントの層化サンプルが独立した人間のレビューを受け、ラベルが正しいことが確認されました。これらの2,116ステートメント全体で、64％は特定のAIエージェントアクションを要求、禁止、または条件付けるポリシーでした。残りの36％は、アーキテクチャノートやプロジェクトの背景などの記述的なコンテキストでした。ポリシーの密度はリポジトリ間で大きく変動し、0％から97％まであり、70.1％のリポジトリには記述的なステートメントよりもポリシーのステートメントが多く含まれていました。ファイルまたは見出しレベルの研究では、このステートメントレベルの分布は報告されていないため、より細かい分類が重要です。ポリシーが懸念事項にどのように分布するかを理解するために、この研究は、以前の指示ファイル研究から適応された12のトピックカテゴリのいずれかに各ステートメントを割り当て、ファイル粒度ではなくステートメント粒度で適用します。開発プロセスと実装の詳細は、それぞれ87％と85％でポリシーの状況を支配しています。アーキテクチャは、ディレクトリレイアウトと設計概要がそのセクションの大部分を占めるため、23％で主に記述的です。インポートされたソース図は、ポリシーのステートメントをディレクティブと呼び、システムで観察可能なポリシーサブセットをシステムレベルのディレクティブと呼びます。この文章は、論文のポリシーとシステムで観察可能な用語に従っています。データセットからの5つの実際のステートメントが、強制要件の範囲を示しています。 Statement Enforcement level Context S4: "Never push to main directly." per-event self-contained S5: "Never modify upstream source code." per-event project S6: "Run the full test suite before committing." cross-event project S7: "Data read from .env must not reach the network." cross-event project S8: "Do not update dependencies without approval." per-event task 強制のギャップはコンテキストから始まる 各ポリシーは、強制ウォーターフォールの最初のマッチするティアで終了します。セマンティックのみは、推論、コミュニケーション、または出力スタイルをカバーします。コンテンツは、ファイルコンテンツに対する述語をカバーします。イベントごと（per-event）は、単一のコマンド、ファイルアクセス、またはネットワーク接続をカバーします。イベントをまたぐ（cross-event）は、操作間の時間的順序またはデータリネージに依存するポリシーをカバーします。コンテンツ、イベントごと、イベントをまたぐティアの和集合は、システムで観察可能（system-observable）と呼ばれます。データセットの1,361のポリシーのうち、セマンティックのみはわずか17％です。残りの83％はシステムで観察可能であり、38％がコンテンツ検査を必要とし、29％が1つのOSイベントにマッチし、16％がイベントをまたぐ状態を必要とします。イベントごととイベントをまたぐクラスのみ、合計45％がOSで強制可能なサブセットを形成します。イベントをまたぐポリシーは開発プロセスに集中しており、全イベントをまたぐポリシーの39.5％を占めます。これらのイベントをまたぐポリシーは、4つの繰り返しパターンに従います。時間的順序はシーケンスを制約します。「コミット前にテストを実行する」は、単に以前の時点ではなく、あるイベントが別のイベントの後に発生したことを必要とします。クロスファイルの一貫性は、成果物間の変更をリンクします。「動作が変更されたらドキュメントを更新する」は、ソース編集をドキュメント更新に結合します。マルチステップワークフローは、検証ゲート付きのリリースチェックリストを強制し、各ステップは次のステップが開始される前に完了する必要があります。条件付きトリガーは操作を結合します。「仕様を変更した場合は、SDKも更新する」は、前提条件が満たされた場合にのみトリガーされます。これらのいずれも単一のイベントから決定できないため、強制は実行されたこと、その順序、および変更された内容を記録する必要があります。そのようなポリシーは広く普及しており、81％のリポジトリには少なくとも1つのイベントをまたぐポリシーが含まれ、43％はすべての4つの強制ティアにまたがっています。コンテキストの依存関係が強制の課題を増大させます。1,127のシステムで観察可能なポリシーのうち、自己完結型はわずか26.4％です。大多数の64.2％はプロジェクトコンテキストを必要とします。「テストスイート」または「アップストリームソース」は、ポリシーが具体的なルールになる前に特定のレポジトリに対して解決される必要があります。S5、「アップストリームソースコードを変更しないでください」のようなイベントごとのポリシーでさえ、ファイル書き込みチェックがトリガーされる前に「アップストリームソース」を構成するパスを解決する必要があります。さらに9.4％は、「明示的に要求されない限り」または「承認なしに」などのタスクコンテキストを必要とします。これらの2つの困難は累積します。なぜなら、イベント間で状態を追跡する必要があるポリシーは、ルールを作成するために必要な具体的なコマンドとパスをほとんど指定しないポリシーでもあるからです。イベントをまたぐポリシーは、コンテンツポリシーと比較して、95％がコンテキスト依存です（プロジェクト77％、タスク19％）。「コミット前にテストを実行する」と言うポリシーは、強制エンジンがどのテストコマンドを監視する必要があるか、どのソースディレクトリが「関連する編集」と見なされるか、そしてテストがパスしたのか単に実行されただけなのかを知る必要があるまで、シンプルに聞こえます。固定された静的ルールのセットは、自己完結型の部分しかカバーできません。残りをインスタンス化するには、リポジトリを読み取り、チェックが実行される前に現在のタスクを解釈する必要があります。エージェントポリシーの強制は、リポジトリとタスクのコンテキストを、決定論的なチェックが評価できる具体的な状態にコンパイルすることから始まります。 1つのルールが複数の強制レイヤーを横断する プロンプト指示はモデル自身のコンプライアンスに依存しますが、プロンプトインジェクションに対して脆弱であり、長いコンテキストウィンドウでのユーザーのタスクプロンプトとの競争になります。個別のエージェントまたはLLMガードは、実行時にプロンプト、応答、またはアクション軌道をチェックできますが、これらのチェックは本質的に確率的です。ツール呼び出しガードレールとアプリケーションレベルの情報フロー制御（IFC）システムは、ハーネス境界で決定論的にインターセプトしますが、ツールが実行を開始した後のシステムレベルの効果ではなく、ハーネスによって仲介されたリクエストのみを観察します。間接的なサブプロセス、シェルアウト、またはコンパイルされたバイナリは、ツール境界をバイパスできます。Consi