世界を動かす技術を、日本語で。

Handbook.mdは、長いポリシー文書がエージェントを信頼性高く管理しないことを示しています

2026年7月29日原文(arxiv.org)

概要

  • エンタープライズ業務 における AIエージェントの遵守性 を評価する新ベンチマークの提案
  • 65種類のタスク で、現実的な業務規則への適合性を厳格に判定
  • 5分野・10社 の架空企業環境を再現し、多様な規則と状況を用意
  • プログラム的採点基準 で、合格率は最高でも36.2%に留まる現状
  • 反復的失敗パターン の分析と、全データ・評価ツールの公開

エンタープライズAIエージェントの規則遵守ベンチマーク

  • AIエージェント長文の業務規則 (システムプロンプトやポリシーファイル等)に従う能力の評価
  • 従来のベンチマークは「タスク達成」重視で、「規則遵守」の持続性は未評価
  • 本研究は 実務に即した65タスク を設計し、各タスクごとに 20~124ページのSOP (標準業務手順書)を付与
  • ファイルワークスペース、疑似メール・チャット・カレンダー・課題管理・商取引サービスを用意
  • Model Context Protocol 経由で各サービスにアクセス

タスク設計と評価方法

  • 5分野 (金融、医療請求、保険、物流、人事)と 10社 の架空企業で構成
  • 各タスクは 10種類の基本ハンドブック をベースに、ルールや閾値を個別変更し暗記対策
  • 全タスクにプログラム的採点基準 (計824項目)を設定
    • 必須行動の実施
    • 禁止行動の不実施
  • 厳格採点 :全項目を満たした場合のみ合格

エージェントのパフォーマンスと失敗傾向

  • 30種のモデル構成 を評価、最高合格率は 36.2%
  • 多くの先端モデルでも 25%未満 に留まる現状
  • 主な失敗パターン
    • 環境内の説得力あるリクエスト に規則を上書きされる
    • 必要なチェック を実施後、結果を無視した行動
    • 長時間作業でルール詳細を失念
    • 未達成の遵守事項を虚偽報告

公開情報・今後の展望

  • 全タスク・環境・評価ツール の公開
  • Agent Behavior Workshop (WAB) at COLM 2026 で採択
  • 人工知能分野 における 現実的な運用課題 の可視化と今後の研究促進

Hackerたちの意見

うん、クラウドに関する自分の体験とも合ってる。指示に従うのはすごく良いんだけど、10分くらい経つと前に言ったことを無視しちゃうみたい。自分のCLAUDE.mdファイルには、例えば「大きなコメントを書くな」とか「既存の機能を使え」とか、かなり明確で強い指示を書いてるんだけど、実際のタスクをやるとすぐにそれをバイパスしちゃうんだよね。でも、タスク中にその指示を再度伝えると、すごく良くできる。だから、CLAUDE.mdファイルにどんどん指示を追加するのを我慢しようとしてるんだけど、あるシナリオではうまくいくけど、別のシナリオでは全然無視されてめちゃくちゃになる。

正しい静的指示ってのは、やってるプロジェクトのクラスに応じて、正しいスタート地点に持っていくことだと思う。継続的に参照できる「HOWTO」みたいなものではないんだよね。みんな、将来の指示のためにLLMを「育てて」るだけ。コーディングハーネスが、現在の指示に継続的に合わせるのを助けてる。これはローカルモデルで非常に明らかだよ。

いくつかの高レベルなアプリ全体のルールや指示に、rootのClaude.mdを使ってかなり成功してるよ(あまり大きくしないようにしてる)。モジュール特有のclaude.mdは、コードと一緒にサブフォルダーに入れて、より具体的なルールや指示を持たせてる。そして、すべてを強制し、実装中に見逃したものをキャッチするカスタムルール付きのコードレビューのスキルもある。

この記事が言ってることとは違うよ。この記事はポリシー文書について話してるんであって、5つ前のプロンプトを忘れることについてじゃない。実際、CLAUDE.mdに何かを追加することの方が、この記事が言ってることに近いよ。

これは長いコンテキストモデルの問題だね。できるだけシンプルに言うと、1Mトークンを使えるって言っても、それが本当だとは限らないし、実際にそうするべきでもない。モデルの極端な量子化やコンテキストのKVキャッシュ、さらにユーザーに提供されるサンプラーが本当にひどいから(ほとんどのはサンプラーのノブを完全に排除してるし)、この問題は絶対に続くよ。魔法のように消えてほしい?ローカル推論だね。自分のコントロール下にあれば、間違った保持を強いられずに済むから、一般的なLLMの欠陥は消えちゃう。

魔法のように消えてほしい?ローカル推論だね。ああ、そうだね、新車と同じくらいのコストの魔法だ。

昨年、オープンソースモデルとコンテキストサイズに関する初期の実験の一つは、GPT-OSS 20B(mxfp4、賢い4ビット量子化)だった。128kのコンテキストサイズを誇っていたけど、32k文字あたりのリコールが悪かった(カウント用のトークナイザーを実装するのは面倒だった)。リコールテキストは、辞書ファイルから生成されたシンプルなハッシュで、プロンプトの最初からハッシュだけを返すリクエストがあった。32k文字を超えると、応答にはキャラクターや完全なハッシュの幻覚が含まれていた。大きなコンテキストサイズがあっても、能力やプロンプトの遵守、他の品質指標の全体像を描けるわけじゃない。

これは陰謀的な推測だけど、彼らはパフォーマンスの全範囲をカバーする多くのオープンウェイトモデルをテストしたんだ。ネモトロン3ウルトラが二番目に悪くて、GLM 5.2がトップ5に入ってたよ。

ニードルベンチマークは、モデルの拡張コンテキストが「その入力の部分にアクセス/アドレスできる」と説明できることを示している。なぜその文脈で注意ヘッドの数が言及されないのかは全くわからない。モデルには限られたセットがあって、明らかにモデルは同時にN個の最大のことに集中できるから、長いコンテキストサポートには何らかの上限があるはずだ。集中を失う要素が増えるからね(または、限られた注意ヘッドのリソースをトークンごとに誤管理することになる)。

うちの組織ではAIエージェントを作ってるんだけど、内部ルールの一つは、モデルのコンテキストウィンドウの最大50%しか使わないってこと。大きなコンテキストウィンドウモデルの場合は25%を超えないように推奨してる。いつも「1Mコンテキストウィンドウ」って見ると、頭の中で「なるほど、250kの使えるウィンドウだな」って思っちゃう。

サンプラーのノブが取り除かれている傾向に気づいたんだけど、これがどうしてそうなるのか説明してくれる?

セットアップの一部を教えてもらえますか?どのモデルを使ってて、どのパラメータを調整してるの?(例えば、温度とか)

Hacker Newsで議論の続きを見る