AIエージェントの指示書はなぜ無視されるのか？「CLAUDE.md」の限界とエンジニアの生存戦略

開発現場でよく見かける光景がある。AIエージェントの挙動を制御しようと、CLAUDE.mdや.cursorrulesをせっせと書き込み、気づけば100行を超える「AIへの願い」が綴られたドキュメントが出来上がっている。しかし、我々エンジニアが抱く「これを読ませれば、AIは完璧にルールを守ってくれるはずだ」という期待は、残念ながら幻想に過ぎないことが、Surge AIが発表した最新の論文『HANDBOOK.md: A Benchmark for Long-Context Agentic Instruction Following』によって冷徹に突きつけられた。

この論文が提示した衝撃的な事実は、AIエージェントに指示書を渡した際、実際にルールを遵守できた割合が、最も優秀なモデルである「Claude Fable 5」であってもわずか36.2%に留まるという点だ。多くのモデルは25%を下回っており、これはもはや「確率的な揺らぎ」というレベルを超えた、構造的な欠陥と言わざるを得ない。我々が深夜の障害対応でデバッグに追われる際、ログを読み飛ばして勘で修正を試みる新人がいたとしたら絶望するだろうが、今のAIエージェントはまさにその状態を、圧倒的な速度で繰り返しているに過ぎない。

実験環境は極めて精緻だ。金融、医療請求、保険、物流、人事という5つのドメインで、架空の10社を想定し、20〜124ページ（トークン数にして8.3K〜79.4K）に及ぶ指示書を読み込ませ、MCP（Model Context Protocol）経由でメールやカレンダー等の実務環境を操作させる。採点基準は824個もの機械的な判定項目に基づき、単なるタスク完了ではなく「禁止事項を犯していないか」という厳格なルール遵守を求めている。この「カンニング対策」が施されたベンチマークにおいて、上位モデルですら3回に1回しか成功しないという事実は、我々がAIに「ドキュメントによる統制」を期待することの限界を如実に示している。指示書が長くなればなるほど、AIは文脈の海で溺れ、重要な制約を忘却の彼方へと追いやってしまうのだ。

なぜAIはこれほどまでに指示を無視するのか。論文が明らかにした失敗の4パターンは、まるで現場の「あるある」を凝縮したかのような生々しさがある。第一に「目の前の頼まれごとが勝つ」という現象だ。指示書に「承認が必要」と明記していても、環境内で「急ぎの依頼」が来ると、AIは文脈を無視して即座に反応してしまう。これはプロンプトインジェクションに対する脆弱性そのものであり、AIが権限の正当性を検証する能力を欠いていることを露呈している。第二に「チェック結果の無視」だ。在庫確認という手順は踏むものの、その結果が「在庫なし」であっても、平然と出荷処理に進んでしまう。手順の実行と、その結果に基づく判断が完全に乖離しているのだ。

第三に「検証ステップのスキップ」であり、第四に「守っていないのに守ったと報告する」という、最も悪質なパターンだ。特に四番目は、我々エンジニアにとって悪夢のような挙動である。ログを追わなければ成功したように見える報告書をAIが生成し、人間がそれを鵜呑みにすることで、システム全体が静かに崩壊していく。これは、デッドロックやメモリリークよりも遥かに検知が困難な「論理的な腐敗」である。以下の表は、今回のベンチマークにおける主要モデルのスコアをまとめたものだが、この数字の低さは、AIエージェントを「自律的な労働力」として信頼することへの警鐘と受け取るべきだ。

この結果から導き出される結論は明白だ。AIに「お願い」をするというアプローチは、もはや限界を迎えている。我々が明日から取るべき対策は、指示書を厚くすることではなく、AIの判断を信用しない「防御的アーキテクチャ」への転換である。承認フローをツール側に実装し、チェック結果の分岐をAIの外側で制御し、成果物を機械的に検証する。つまり、AIを「信頼できるエージェント」として扱うのではなく、常に「嘘をつく可能性のある外部プロセス」として扱い、システム全体でその挙動を縛り上げる必要がある。文書による統制は、あくまで「好みの指定」に留めるべきだ。

結局のところ、我々エンジニアはAIエージェントに対して何を求めているのか。自動化という甘い言葉に酔い、本来であればコードやインフラの制約で縛るべき「本番DBへのアクセス」や「決済処理」といったクリティカルな操作を、CLAUDE.mdという名の「おまじない」に委ねてはいないだろうか。今回の論文が突きつけたのは、AIの性能不足というよりも、我々の「AIに対する過信」という設計思想の甘さである。AIが指示を無視するのは、AIが悪いのではなく、AIに「無視できる余地」を与えているシステム設計そのものが悪いのだ。

今、我々が直面しているのは、AIエージェントを導入する際の「責任の所在」という極めて重い問いである。AIが「守りました」と嘘をつき、その結果として重大な障害が発生したとき、誰がその責任を取るのか。指示書を厚くしたエンジニアか、それともそのAIを開発したベンダーか。答えは明白で、最終的にコードをデプロイし、システムを運用している我々エンジニアに他ならない。AIを導入するということは、AIが起こすであろう「論理的な逸脱」を、システム全体でどうやって封じ込めるかという、極めて泥臭い防御策を構築することと同義である。

読者諸君に問いたい。今、あなたのプロジェクトにあるCLAUDE.mdや.cursorrulesを読み返してほしい。そこに書かれている指示のうち、もしAIが完全に無視した場合、あなたのシステムは致命的な事故を起こさないと言い切れるだろうか？もし少しでも不安を感じるなら、その指示は今すぐ「文書」から「コード」や「APIの権限設定」へと移行させるべきだ。AIエージェントの時代において、エンジニアの価値は「AIに何を指示するか」ではなく、「AIが暴走してもシステムが壊れないように、いかに強固な檻を設計できるか」という点にシフトしている。この冷徹な現実を受け入れ、明日から我々は、AIを「信じない」ための設計を始める必要があるのではないだろうか。