AIエージェントに社内の仕事を任せ始めるとき、ほぼ全ての会社が同じ手を打ちます。社内のルールをドキュメントにまとめて、最初に読ませておく。 承認が必要な金額、使ってよい取引先、対応してはいけない問い合わせ。システムプロンプトなり、AGENTS.md のようなファイルなりに書いておけば、その通りに動いてくれるはずだ、と。
この前提が実際どこまで成り立つのかを正面から測った研究が、2026年7月に公開されました。結論から書くと、成り立っていません。
65の会社を作って測った
HANDBOOK.md と名付けられたそのベンチマークは、AIエージェントに「長くて拘束力のある方針文書」を渡したとき、それが複数ステップの実務のあいだ実際に行動を規定するかを測るものです（HANDBOOK.md: A Benchmark for Long-Context Agentic Instruction Following — arXiv）。
作りが丁寧で、数字を読むうえで前提として押さえておく価値があります。
- 65個の独立した企業環境。それぞれに固有の業務とツールがある
- 各環境に、専門家が書き下ろした20〜124ページの規程を、実際のオフィス文書形式で用意
- 6つのサービスにまたがる82のツールをエージェントが操作する
- 合否は人の感想ではなく、824個の決定的な受け入れ基準で機械的に判定する
つまり、「よくできているように見えるか」ではなく、規程に書かれた通りに動いたかどうかだけを見ています。
結果はこうです。すべての基準を満たした場合のみ合格とする厳格な採点で、評価した30のモデル構成のうち最も成績のよいものが36.2%。フロンティアと呼ばれる構成の多くは25%を下回りました。
最良の構成でも、3回に2回近くは、渡した規程のどこかを守れていません。
「読ませておけば守る」が成り立たない4つの型
数字より実務に効くのは、失敗の中身が一貫した型を持っていたという点です。研究が挙げているのは次の4つで、どれも汎用的な推論ミスではなく、統制の失敗として読める形をしています。
1. 目の前のもっともらしい依頼が、規程を上書きする
環境の中で「これをやってください」ともっともらしく頼まれると、規程に書かれた恒常的なルールより、その場の依頼を優先してしまう。人間の新人がやりがちな失敗と同じ形ですが、新人は違和感を持てば聞き返します。
2. 必要な確認を実行したうえで、その結果に反して動く
これがいちばん厄介です。チェック自体はちゃんと走っている。 ログにも残る。にもかかわらず、その結果を無視した行動を取る。外形的には手続きを踏んでいるように見えるので、「統制が効いている」という誤った安心が生まれます。
3. 長い作業のあいだにルールの細部を失う
工程が進むにつれて、最初に読んだ規程の細かい条件が抜け落ちていく。序盤は守れていて、終盤で崩れる。部分的に成功しているぶん、気づきにくい。
4. 達成していないコンプライアンスを、達成したと報告する
そして最後がこれです。守っていないのに「守りました」と報告する。この型が混ざると、自動で取れた監査ログは、人が手で検証し直さないと使えない文書になります。 自動化のために入れたはずのものが、確認作業を増やす。
「もっと詳しく書けば守る」ではない
この結果を見て最初に出てくる対策は、たいてい「規程の書き方が悪いのでは」というものです。もっと明確に、もっと構造化して、もっと具体例を足せば守るのではないか。
残念ながら、方向が逆であることを示す観察も出てきています。指示ファイルは長くすると効きが落ちるという指摘は、実務者のあいだでも共有されつつあります（The research is in: your AGENTS.md is probably too long — Upsun）。20ページで守れないものが、40ページにしたら守れるようにはなりません。
ここから引き出せる結論は、けっこうはっきりしています。文書は方針を伝える手段であって、強制する手段ではない。
人間の組織でも同じです。就業規則に「経費は事前承認が必要」と書いてあるから承認が取られるのではなく、承認なしでは経費精算のシステムが通らないから取られます。文書は根拠であり、強制しているのは仕組みのほうです。
エージェントを業務に入れる側が変えるべき設計
では実務としてどうするか。方向は1つで、守らせたいことを文書からツール側に移すことです。
| 文書に書いてあるだけの状態 | 仕組みに移した状態 |
|---|---|
| 「50万円を超える発注は承認を取ること」 | 50万円超のリクエストは、承認レコードがないとAPIが受け付けない |
| 「本番環境の変更は営業時間内のみ」 | 実行ツール側で時間帯を制限する |
| 「顧客情報を外部に送らない」 | エージェントに外部送信ツールを渡さない |
見ての通り、エージェントに与えるツールの設計そのものが統制になります。「やってはいけないこと」を書いて渡すより、「できないようにする」ほうが確実です。当たり前の話に見えますが、AIエージェントの導入ではプロンプトで何とかしようとする段階が長く続きがちです。
もう一つ、失敗の型4番（達成していない遵守を報告する）から直接導かれる原則があります。エージェントの自己申告を、統制の証拠にしない。 「確認しました」「規程に従って処理しました」という出力は、監査の材料になりません。確認したかどうかは、ツールの実行ログ側で取ります。
本番環境に対する破壊的操作をどう囲うかはAIエージェントが本番DBを削除した事件で、外部から読み込んだ内容に指示が紛れ込む問題は間接プロンプトインジェクションで扱いました。今回の話は、その手前にある「そもそも指示通りに動くのか」という層の問題です。
それでも入れる価値はある
誤解のないように書いておくと、これは「AIエージェントに業務を任せるのは時期尚早」という話ではありません。
36.2%という数字が示しているのは、規程を読ませただけの状態で、監督なしに走らせてはいけないということです。逆に言えば、確認が入る前提の作業、間違っても取り返しがつく作業、人が最終判断する下ごしらえの作業では、いまの水準でも十分に価値を出します。
線引きの基準はシンプルです。「間違ったときに、誰がいつ気づくか」に答えられるか。 答えられない作業は、まだ任せる段階にありません。答えられるなら、任せてよい。
導入の順番として効くのは、いきなり判断を含む業務ではなく、手数が多いだけで判断が少ない業務から入れることです。この考え方はツールを増やす前に繋ぐで書いた「やめられるか → 減らせるか → 繋ぐか」の順番と、実は同じ形をしています。
今週、自社のエージェント設定を1つ確認する
すでに社内でAIエージェントやAIアシスタントを業務に組み込んでいるなら、そのエージェントに渡している指示ファイルを開いて、書かれているルールを2つに仕分けてみてください。
守られなくても困らないもの（文体、書式、口調）と、守られないと事故になるもの（金額、権限、送信先）。後者がもし指示ファイルの中にしか存在していないなら、それは統制されていない状態です。ツール側で塞げないかを検討する対象になります。
AIエージェントを業務に組み込むにあたって、どこまでを任せ、どこを仕組みで止めるか。設計から一緒に整理したい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- HANDBOOK.md: A Benchmark for Long-Context Agentic Instruction Following — arXiv:2607.25398（2026年7月）
- HANDBOOK.md Benchmark: Can AI Agents Follow a 100-Page Company Policy? — Surge AI
- AI Struggles to Respect the Employee Handbook — Unite.AI
- The research is in: your AGENTS.md is probably too long — Upsun Developer Center
