ツールを使うAIエージェントが返金を実行し、記録を書き換え、次のタスクをトリガーし始めたことで、評価の問いが変わった。いま問われるのは「結果が正しかったか」ではなく、「その行動を裏づける根拠を実行前に実際に確保したか」だ。本論文は656課題で構成したベンチマークSafeActBenchを用い、10個のモデル・ハーネス構成を走らせて、「証拠から行動へ(evidence-to-action)」とつながる鎖がどこで切れるのかを追跡した。結論から言えば、鎖は実行そのものよりもその手前——調査を終えきらない、あるいは根拠が揃う前に手をつける地点——でより頻繁に切れる。
従来の評価は「関数を正しく呼び出したか」に近かった。正しいツールを、正しい対象に、正しい引数で呼べば合格だった。ところがエージェントが「答えを出す存在」から「状態を変える存在」へと移ってきたことで、この基準は手薄になった。論文は、アプリの状態を変えたり外部に実際の効果を及ぼしたりするツール呼び出しを結果性行動(consequential action、取り消しの難しい実行)と呼ぶ。返金の発行、文書の送付、レコードの修正といったものだ。
核心となる区別はこうだ。「結果が正しい」と「その行動に根拠があった」は別物である。エージェントは重複かどうかを確認もせずに正しい金額を返金し、成功レスポンスを受け取ることができる。状態が返金を許可し、呼び出しも正確なら、見かけ上は成功だ。だが、エージェントが残した記録の中に根拠が残っていなければ、その行動は「裏づけのない」ものだ。そして後続の行動が前の結果に依存するとき、この欠陥はそのまま伝播する。
既存研究も、静的な関数呼び出し精度から、状態が変化するインタラクション評価へとすでに移ってきている(AgentBench、WorkArena、OSWorld、AppWorld など)。ただし「各結果性行動が、実行前に立てた根拠によって裏づけられているか」は、より直接的には扱われてこなかった、というのが本論文の出発点だ。
論文の骨格は一本の鎖である。「行動前に根拠を揃えたか → 行動 → その結果が次の行動へつながるか」。二重課金の返金という一つの場面で追ってみよう。
1. 行動の前の根拠。 返金ボタンを押す前に、エージェントは「この決済が本当に重複なのか」からまず確認しなければならない。領収書を探し、金額・対象・条件を突き合わせる段階だ。ここで肝心なのは数字が合っているかではなく、「その数字がどこから来たか」である。隣の決済Aで49.99ドルを見かけたとして、返金対象の決済Bも偶然49.99ドルだったからといって、Aの領収書がBを返金してよい根拠になるわけではない。論文は、こうして出所に結びついた情報を証拠(provenance、情報の出所)と呼ぶ。まさにその返金が触れる決済・顧客・金額についての観測であって初めて証拠になる。
2. 調査された非行動。 領収書を調べてみたら重複ではなかったり、返金条件に合わなかったりすることもある。このとき、ただ「できません」と止まるだけでは不十分だ。論文は「調査された非行動(investigated non-action)」を求める。なぜできないのか、必要な調査を終えたうえで止まれ、ということだ。調査もせずに先回りして止まれば怠惰な拒否であり、条件がはっきりしないのにとりあえず返金してしまえば性急な行動だ。
3. 連鎖。 返金が終わると refund_id=R42 のような識別子が返る。「返金したことを顧客に知らせよ」という後続行動は、必ず「その返金が」返したR42を使わなければならない。別のところで拾った番号を使えば依存関係を満たせない。順序も縛られる。通知は、返金が実際に終わった後でなければ送れない。
この三つの節を人間の目分量ではなく機械的に測るために、二つの仕掛けを置いた。一つは証拠台帳(Evidence Ledger)で、エージェントが確認した事実を「どこから得て、何を説明するか」とともに書き留める。もう一つは決定論的評価器で、エージェントが残した行動・観測の記録である軌跡(trajectory)をそのまま再生(replay)しながら、必要な調査をしたか、正しいツール・対象・引数を使ったか、後続行動が先行の結果に縛られているかを問う。隠れた内心を覗き込んだり、別のAIの判定に頼ったりせず、課題の文脈・観測されたツール使用・結果の状態だけを使う。
SafeActBenchは656課題を、顧客・ポリシー、エンジニアリング・インフラ、法務・金融、研究補助、スマートホーム制御、ヘルスケアまで六つの運用ドメインに分けて収めた。評価プロトコルは五段階で、静的判断から依存関係制約つき実行まで次第に難しくなる。
| プロトコル | 性格 | 行動数 | 合格条件 | 課題数 |
|---|---|---|---|---|
| Legacy | 静的判断 | – | 固定の候補行動にAllow/Block/Deferを判定 | 86 |
| V0 | 調査された非行動 | 0 | 必要な調査を終え、結果性行動を取らない | 175 |
| V1 | 単一行動 | 1 | 正しい行動一つの前に必要な根拠を確保 | 131 |
| V2 | 線形の多重行動 | 2個以上(≥2)、チェーン | 各行動の前に根拠 + 後続が先行の実際の結果を使用 | 132 |
| V3 | 依存関係制約つき多重行動 | 2個以上(≥2)、DAG | 各行動の前に根拠 + 有効な位相順序ならどの順でも可 | 132 |
表のDAGは「前後関係だけが定まった作業の網」(順序が一つに固定されない)を、位相順序は「先行作業が先に来さえすればよい順序」を意味する。中心指標はexact_case_success(ECS)で、一つのエピソードがプロトコル要件をすべて満たしたかを測る合格/不合格の二値だ。一つでも外れれば失敗である。
評価対象は、五つのモデルファミリーをそれぞれ二つのハーネスに載せた10構成だ。最新の商用大型モデルから軽量なオープンソースモデルまで、性格の異なるファミリーを一緒に収めた。ここでハーネス(harness)とは、モデルの思考を実際のツール呼び出しへと移してくれる実行フレーム——いわばモデルを動かすオペレーティングシステム(OS)のようなものだ。同じ頭脳(モデル)でも、どのOSを使うかによって仕事のさばき方が変わる。一つはモデルの作り手が出した専用フレームワーク、もう一つは汎用のReAct方式の共有フレームワークで、同じモデルを異なるOSに載せて「OSが性能をどれだけ分けるか」を切り分けて見ようという設計だ。すべての構成は同じ公開課題・ツールを受け取り、採点仕様は最後まで伏せ、各課題-構成ペアを3回繰り返し実行してカバレッジ100%を報告する。
ここで、この評価が見るものと見られないものを押さえておこう。評価器は表に現れた軌跡だけを検査するのであって、モデルが内側で何に頼ったかは見られない。だからこのベンチマークは「行動が持つ情報と前後が合っていたか(整合)」を測るだけで、「その情報ゆえにそう行動したか(因果)」までは測れない。
二つのパターンがはっきりしている。
第一に、静的判断がうまくても、証拠に基づく実行ははるかに弱いことがある。 ある構成はLegacyで97.7%を取る(ランダムに当てる期待値が約33.3%の三択判定なので、ほぼ満点だ)。ところがV1〜V3へ進むと分かれる。DeepSeekを専用ハーネスに載せた構成は60%台を保つ一方、GLMをZCodeに載せた構成は12.1〜34.1%へ落ち込み、V2(線形の多重行動)で12.1%と最も低かった。課題をまったく同じに固定して測り直しても隔たりは残り、静的精度が最低95%なのにインタラクションECSは最大52%だった(付録C.2)。要するに、静的ベンチマークの満点は「何をすべきかを判断できる」という意味にすぎず、「インタラクションの中で根拠を立てて実行できる」保証ではない。
第二に、ハーネス効果が大きく、その向きはモデルごとに異なる。 DeepSeekは共有ハーネス(57.5%)より専用ハーネス(63.0%)で全体ECSが上がったが、その相当部分はLegacyから来ており、GLMは逆に共有ハーネス(41.0%)が専用ハーネス(37.7%)より良かった。残りのファミリーは自分の専用ハーネスを2.1〜4.4ポイント好んだ。同じモデルをどのOSに載せるかが、それ自体で性能の変数だということだ。
さらに興味深いのは、鎖がどこで切れるかだ。V0で調査を終える前に止まった比率(BSR)は21.7〜62.9%、V1で根拠を揃えきる前に手をつけた比率(PAR)は37.0〜66.9%と高かった。一方、根拠を揃えたうえで行動したときの成功率(CAS)は10のうち9が93.2〜100%だった(1構成だけ83.3%)。つまりいったん根拠が整えば、単一行動の実行はおおむね信頼できる。問題はその手前だ。 調査を終えきらずに止まる、あるいは根拠が完成する前に先に行動してしまう上流(upstream)で、失敗がより多く起きる。
多重行動は失敗の形がさらに分かれる。V2・V3では「行動の直前なのに前提が立っていない場合(Gap)」と「始めはしたが締めくくれなかった場合(Part.)」が新たに表れるが、二つの比重は構成ごとに異なる。ある人は計画段階で詰まり(Gap)、別の人はとりあえず始めはするが仕上げられない(Part.)ように、モデル・ハーネスの組み合わせごとに「失敗する性格」が違うわけだ。しかも二つの型は一つのエピソードで重なりうるため、きれいに二つに割れもしない。多重行動の失敗を「一つの共通ボトルネック」とひとくくりにはできない、ということだ。
先に述べたように、この評価は観測された行動の「整合」を見るだけで、「因果」を断定はできない。表向き鎖がつながったように見える運の良い軌跡と、実際に根拠に頼った軌跡とを、観測だけで完璧に分けるのは難しい。
その上に、より重要な限界がある。仕様の代表性だ。ベンチマークは著者たちが設計した要件仕様の上で回る。評価器が使う「必要な根拠」の定義がそのまま採点基準なので、その仕様が現実の意思決定状況をどれだけ代表するかが、結果の一般化を左右する。著者のリファレンス解法656個がすべて評価器を通過し、人手による監査も経たとされるが(付録B.3)、これは評価器の自己整合性の検証であって、「仕様がそのまま良い運用規範である」という保証とは別の層だ。また、モデル・ハーネス構成は特定世代の特定の組み合わせなので、別の世代や別のプロンプト戦略でBSR・PARの分布がどう動くかは、この表だけでは断定しがたい。
この論文はインタラクション評価の流れの上に立つ。先に述べたAgentBench系が「課題を完了したか」を現実的に測ってきたのに対し、本論文は「完了」ではなく「実行前に立った根拠がその行動を裏づけるか」へと焦点を移す。
この記事で初めて出てくる二つの研究と並べると、その色がはっきりする。EnvTrustBenchは、古かったり改ざんされたりした観測を過度に信じる過信(overtrust)を扱い、Near-Missは、エージェントがポリシー点検を飛ばしても最終状態には到達しうることを示す。本論文はもう一歩踏み込み、「その行動が触れるまさにその対象・状態について、実行前に根拠が立ったか」「連鎖行動が先行の結果にきちんと縛られているか」までを見る。いつ、もっと調べ、止まり、棄権するかを扱った情報探索・棄権の研究とも、「行動が起きるまさにその地点で根拠を求める」点で区別される。
この論文の発見は、学術的な話にとどまらない。私たちONTLEがAIエージェントを現場に組み込みながら払った高くついた教訓と、同じ地点を突くからだ。
ONTLEは顧客プロジェクトごとにAI PMを派遣し、受付からサービス公開までを管理する。論文が最も鋭く刺さる場面は、AI PMがあるタスクを「進行」へ押し進めたり、顧客に給付性の特典(たとえばクレジット)を実行したりする瞬間だ。
実際に事故があった。二重クリック一回で23,000クレジットが誤って支払われたことがあり、以来、金銭・クレジットのような給付性アクションは1回制限と台帳訂正による原状回復を基本にしている。この論文の枠組みを借りれば、当時切れていた環は、実行(ボタン)そのものではなかった。ボタンは正常に動いた。弱かったのはその手前、「この給付がこの受益者にこの条件でまだ実行されていない」を出所に結びつけて確認する段階に近い。値が合い呼び出しが成功したからといって終わりではない、という論文の指摘と響き合う。
だからONTLEのPM再設計の方向——PMの「言葉」を信じる代わりに、共通アクションサービスがサーバー側で根拠の状態を確認し決定論的に実行するよう、狭いツールに閉じ込めた構造——は、論文がLLM判定の代わりに決定論的な軌跡評価器を使ったことと結を同じくする。この論文がくれる具体的な補強点は、測定の軸だ。PMの行動ログをBSR(調査未完での停止)・PAR(早すぎる実行)・Gap(未解決の前提)・Part.(未完のワークフロー)に分けて測れば、「成功/失敗」という単一の結果を「どの節で切れたか」へと解剖できる。とりわけONTLEのon_hold(決定待ち)状態は、論文の「調査された非行動」に似ている。ただ止まるのではなく、なぜ止まるべきかの必要な確認を終えたうえで止まってこそ、顧客に説明できる停止になる。調査なしに止まれば、それはBSR型の性急な停止に近い。
既存のベンチマークは、たいてい課題を完了したかと最終状態が正しいかを見ます。SafeActBenchはその「直前」を見ます。状態を変える行動が起きるまさに前に、その行動が触れる対象・状態についての根拠が、観測された軌跡の中で出所のレベルまで確保されているかを確認します。最終状態が正しくても、根拠がなければ失敗とみなします。
条件をつける必要があります。CASは「根拠が完成した後に行動を試みた場合」の成功率です。その条件の中では単一行動はおおむね信頼できましたが(10のうち9が93.2〜100%)、多くの失敗はその条件に届く前——調査未完や早すぎる実行——で起きました。「根拠さえ揃えば実行はうまい、問題は根拠を揃える過程だ」と読むのが正確です。
いいえ。向きはモデルごとに異なりました。DeepSeekは専用ハーネスで共有ハーネスより上がりましたが、GLMは逆に共有ハーネスのほうが良かったです。残りは自分の専用ハーネスをわずかに好みました。ですからハーネスは、モデルと組にして一緒に実測すべき変数です。