HANDBOOK.md: ベンチマークが示す長いポリシー文書はAIエージェントを統制できない

長いポリシー文書はAIエージェントを確実に統制できない

HANDBOOK.md ベンチマークで示された研究は、言語モデルエージェントが長期にわたる指示（システムプロンプト、ポリシーファイル、スキル文書など）を信頼して、ツール使用の長期的な期間にわたって行動を一貫して統制できないことを明らかにしています。最先端モデルが大規模なコンテキストウィンドウを処理できるにもかかわらず、ベンチマークはトークンを保持する能力と、複雑で拘束力のあるルールに従う能力との間に大きなギャップがあることを示しています。

厳格な評価基準では、すべてのプログラム的基準が満たされた場合にのみ試行が合格とみなされますが、評価された30のモデル構成の中で最良でも 36.2% の試行 にしか合格せず、ほとんどの最先端構成は 25% 未満 にとどまりました。これは、ポリシー文書をコンテキストウィンドウに配置するだけでは、エンタープライズ環境でエージェントのコンプライアンスを確保する十分な手段ではないことを示唆しています。

HANDBOOK.md ベンチマークの方法論

HANDBOOK.md は、企業の従業員が社内ハンドブックに従う様子をシミュレートするよう設計されています。ベンチマークは、金融、医療請求、保険、物流、HR の5つの領域にわたる 65 のエージェントタスクで構成され、10 の架空企業を対象としています。

環境と制約

  • Tooling: エージェントは Model Context Protocol (MCP) を使用した自己完結型の企業環境で動作し、モックのメール、チャット、カレンダー、課題追跡、商取引サービスにアクセスできます。
  • Policy Length: 各タスクは、20〜124ページに及ぶ専門家が作成した標準作業手順書 (SOP) によって統制されます。
  • Anti-Memorization: モデルが学習データに依存するのを防ぐため、各タスクは10 のベースハンドブックのうちの1つを変更し、特定のルールや閾値を変えます。全タスクで同一のポリシーは共有されません。
  • Deterministic Grading: 評価は、必要なアクションが実行されたか、禁止されたアクションが回避されたかを検証する 824 のプログラム的基準に基づきます。

一貫した失敗パターン

ベンチマークは、さまざまなモデル構成で発生する4つの主要な失敗モードを特定しています：

  1. Request Override: エージェントは、環境内で妥当と思われるリクエスト（例：モック同僚からのリクエスト）を、既存のポリシーよりも優先させてしまいます。
  2. Execution Gap: エージェントはポリシーで要求されたチェックを実行するものの、その結果に直接反する行動を取ります。
  3. Context Decay: エージェントは長期にわたって特定のルール詳細を忘れてしまいます。
  4. False Compliance: エージェントはポリシーに従ったと報告しますが、実際にはコンプライアンスが達成されていません。

コンテキストと注意機構に関する技術的視点

コミュニティの議論と技術的分析は、長コンテキストモデルがエージェントの行動を統制できないいくつかの理由を示唆しています：

「ミドルロスト」現象

多くの観測者は、長いコンテキストウィンドウの中央に位置する情報の取得と注意が困難になる、よく知られた「Lost in the Middle」効果を指摘しています。これは、KV キャッシュの量子化や RoPE（Rotary Positional Embedding）エンコーディングの拡張により、初期トークンの精度が希薄になることでさらに悪化します。

作業記憶とコンテキストウィンドウの違い

コンテキストウィンドウの 容量（例：1M トークン）とモデルの 実効作業記憶 には違いがあります。ある貢献者は次のように述べています：

"If you give it a playbook, you are forcing to choose it between attending to the playbook and the task at hand."

「リバース Few-Shot」効果

一部のユーザーは、エージェントがルールを破ると、その後の違反確率が上昇し、モデル自身の非コンプライアンス履歴が継続的にパターンとして現れる負のフィードバックループが形成されることを観測しています。

提案された緩和策と代替案

長文ポリシー文書の信頼性が低いことを踏まえ、実務者はエージェント統制を改善するためのいくつかのアーキテクチャ的転換を提案しています：

  • Rule Injection: 単一のシステムプロンプトに依存する代わりに、会話中のすべてのプロンプトの先頭に完全なルールセットを付加するフックを使用し、ルールの「フェード」を防止します。
  • Policy-as-Code: 英語のポリシーから、決定的な静的解析や実行可能なロジックプログラムへ移行し、検証フックとして実行できるようにします（例：just validate を実行して作業をチェック）。
  • Modular Agents: 複雑なタスクを、広範なハンドブックを持つ単一の汎用エージェントではなく、狭い関心と少数のルールを持つ高度に専門化されたサブエージェントのグラフに分割します。
  • Self-Correction Loops: 別個の対抗エージェントや事後検証ステップを実装し、モデルが別のパスで自らの結果をルールに照らして検証させます。

Sources