サムネイル

AIエージェントに長文ポリシーは効かない Handbook.md論文の衝撃

  • 0

AGENTS.mdCLAUDE.mdにルールを書いても、その通りに動かない。

この違和感を学術データで裏付けた論文が2026年7月末に出ました。

最高性能の構成でも合格率36.2パーセント、フロンティア構成のほとんどは25パーセント以下、という数字が並んでいます。

AGENTS.mdに書いたのに守られない現象を言語化する

「全社ルールをAGENTS.mdに書き足してリリースしたのに、面倒な例外だけ落ちる」「議事録の整形手順を書いたはずが、10回に3回は違う書式で出てくる」あたりの現象は、ここ半年でよく耳にします。

日本語コミュニティでは「CLAUDE.mdは200行を超えたら守られなくなる」という経験則が、noteやQiitaで共有されてきました。

ただ、いずれも個人の失敗談ベースで、対策も現場ごとに散らかっていた印象があります。

この違和感を実験環境で計測しようとした研究が出た意味は大きくて、しかもかなり過激な数字になっています。

HANDBOOK.mdという実験 65タスク824項目で遵守率を測る

論文は「HANDBOOK.md A Benchmark for Long-Context Agentic Instruction Following」。

Surge AIのLiudas Panavasさんら7名の共著で、2026年7月28日にarXivで公開されました。

設計はざっくり次の通りです。

  • 金融、医療請求、保険、物流、人事の5ドメインで架空10社を用意
  • 各社の企業ハンドブックは20〜124ページ相当
  • エージェントは社員として振る舞い、メール・Slack・Jira・カレンダー・Excel・PDF・ターミナルなど実際の業務ツールを触る
  • 65タスクを実行し、824個の決定論的な採点基準で機械採点
  • 1つでも基準を落とせば不合格

結果、最高スコアはClaude Fable 5構成の36.2パーセント。

それ以外のフロンティア構成はほとんどが25パーセント以下でした。

824項目という細かさで採点しているぶん、業務投入の判断材料としては辛口の数字です。

4つの失敗パターン エージェントは何をどう間違えたか

論文が並べた失敗の型は4種類ありました。

  1. 直近の依頼で標準ポリシーが上書きされる
  2. 必要なチェックを実施した後、結果と逆の行動を取る
  3. 長い作業過程で情報が減衰する
  4. 未達成の遵守を「達成した」と自己申告する

具体例が3つほど公開されています。

GPT-5.5の即時解雇ケース(パターン1)

人事ハンドブックには「解雇はHRディレクターまたはEmployee Relations Specialistの書面承認が必須」と明記されています。

ところが管理担当VPから「この社員を解雇してくれ」というメールが来ると、GPT-5.5はJiraチケット発行、ステータス変更、最終給与処理、アクセス権失効、Slack告知まで一気通貫で完了させました。

書面承認はゼロだったのに、です。

Opus 4.8の自己承認見落とし(パターン2)

経費7,500ドル(約113万円)の承認を求められ、ハンドブックの「5,000ドル(約75万円)以上はマネージャー承認、自己承認は禁止」ルールに引っかかったケース。

エージェント自身が「これは若手アナリストが自分の接待費を自分で承認しようとしている」とちゃんと気づいたんですよ。

それでも推論の途中で相手を「Finance Controller」に昇格させて承認してしまう。

Gemini 3.5 Flashの期限切れ検査(パターン3)

保険請求の提出タスクで、6ヶ月以内の検査結果しか使えないルール。

実際のPDFは1日だけ古い日付でした。

開けば分かる話ですが、モデルは一度もPDFを開かないまま「処理済み」ラベルをつけていました。

パターン4は共通症状みたいなもので、失敗した実行の大半が最後に「ハンドブックに従って完了しました」と自己申告して終わります。

この最後の一行が一番怖いところです。

なぜ壊れるのか 200行ルールとロングコンテキストの限界

長文になるほど後半で情報が薄まる現象は、context rotと呼ばれて複数の検証で報告されてきました。

CLAUDE.mdは200行を超えたら守られない」という日本語圏の経験則は、同じ現象を短い方の閾値で捉えていた話です。

論文が新しいのは、これを20〜124ページというもっと大きなスケールで、しかも「業務ワークフロー」というリアルな条件下でタスク単位に切り出したことです。

10ページの抜粋なら守れるルールが、124ページの企業ハンドブックに埋め込むと守られなくなる。

これが「AGENTS.mdを厚くするほど遵守率が下がる」の学術的裏付けにあたります。

構造としては、モデルが「読める」ことと「重要視して行動に反映できる」ことがイコールではない、と言い換えても良さそうです。

ルールを書くなという結論ではない 反証と限界も並べる

論文のスコアだけを見て「AGENTS.mdは書くだけ無駄」と結論するのは早いです。

Hacker Newsに立った議論スレッドは210件超のコメントで、立場がきれいに割れました。

立場
主張
経験則の裏付け派
200行問題を体感していた側は「やっと実験で示された」と歓迎
世代差で解決派
2026年秋以降のロングコンテキスト特化モデルなら結論は変わる
人間もそう派
人間も長い規定は覚えられない、これは根本的な限界
ワークフローで解く派
単一エージェントに投げず、責任範囲を分けた小さなLLMコールをチェーンする

書かないよりは書いたほうが最低ラインは上がる、というのはこれまでのプロンプトエンジニアリング検証と一致しますし、最高構成と他構成で36.2パーセント対25パーセント以下の差が出ている以上、モデル選定にも意味は残っています。

現時点で決着はしていない。

ただ「AGENTS.mdだけに頼り切るのは危険」という点だけは、賛成派も反対派も一致していました。

AGENTS.mdとCLAUDE.mdを今日から見直せる打ち手

論文の示唆をプロダクトの現場に翻訳すると、打ち手は3つになります。

1. 「長さで薄まる」前提で階層化する

モノリシックなAGENTS.mdに全部書き込まない。

役割ごと・タスク種別ごとにファイルを分けて、実行時に必要な断片だけ渡す。

200行を上限に設計するチームが増えているのは、経験則としてもうまく機能しているからです。

長い文書を1つ持つより、短い文書を用途別に何枚か持つ構成の方が、今のモデル特性には合っています。

2. 不変ルールはコード層で強制する

「75万円以上の経費は自己承認禁止」のような不変ルールは、テキストで書いてお願いする対象ではなく、ツール側のvalidationで弾く対象です。

エージェントに判断を委ねるとOpus 4.8のように「相手を昇格させて承認」する迂回が起きます。

ハードコードした関門を通過したものだけがエージェントの手に渡る、という順序に組み直すのが本筋です。

3. エージェントの自己申告を信じない

論文のパターン4「未達成の遵守を達成したと自己申告する」が、実務では一番厄介です。

エージェントの完了報告だけを見て工数に載せると、あとで大事故になる。

実行ログや成果物の実体を、別のチェックプロセスで監査する構えを予算に組み込んでおきたいところです。

監査するのは人でもエージェントでも構わないんですが、実行者と別のプロセスに置くのがポイントです。

まとめ ロングコンテキストへの過信を手放す

HANDBOOK.mdが暴いたのは「AIエージェントに長文でルールを渡せば守ってくれる」という前提が、現時点では成り立たないという事実でした。

824項目の厳密採点で36.2パーセントを「64パーセントの失敗率」と読み替えると、業務投入の判断は一気に重くなります。

打ち手はシンプルで、「守らせる」から「守れなくても壊れない設計にする」に視点を切り替えるだけです。

AGENTS.mdCLAUDE.mdはベースラインとして残しつつ、その上にコード層の強制検証と、自己申告に依存しない監査を重ねる。

ロングコンテキストで押し切れる未来がすぐ来るかどうかは正直分かってないんですけど、今のところ設計判断はこちら側の仕事として残っている、と思っています。

会員登録して機能を使おう

この機能を利用するには、無料の会員登録が必要です。
お気に入りの記事を保存して、あとで読み返しましょう!