AIエージェント

エージェントの実行時検証はどこまで効く？違反阻止と安全完遂の差

2026/7/28 （更新: 2026/10/12）

🤖 AIを使用して執筆

「検証税」とは何か

検問を足すと何が起きるか。止まった操作の数は増える。だが、止めた回数を数えても払っているものは出てこない。計画を立てさせ、別の役に点検させ、検問が弾いた後にやり直させる。その全部が対話の長さと計算の費用に乗る。これが「検証税」である。税がどこにかかっているのかは、一つのベンチの上で分解できる。

論の土台になっているのは tau-bench（τ-bench）というベンチである。Yao らが2024年6月に公開したもので、ツールを持つエージェントと、言語モデルが演じる利用者との対話を模擬する。採点は会話の見た目でなく、終了時のバックエンドの状態を正解の状態と突き合わせて行う。さらに各ドメインは、本人確認を済ませてから予約を変更する、といった明文の手続き上のポリシーを、エージェントへの指示として与える。ただし採点そのものはポリシーの遵守を見ない。Yao らは、報酬1は成功の必要条件ではあっても十分条件ではないかもしれない、明示的な確認を取らずに返金処理を出すようなポリシー違反がありうるからだ、と自ら断っている²。その隙間を埋めたのが Sah らだ。 彼らは軌跡ログに決定的な監査スクリプト（strict_policy_auditor.py）を当て、違反を3類型に分けて機械的にラベル付けし、達成と遵守を切り分けた¹。彼らが tau-bench を選んだ理由も、ベンチ側で遵守が測れるからではない。Web操作や身体化環境の対話ベンチは主に達成度を測るもので、手続きの遵守を扱わないからだ、と彼らは書いている¹。

弱点もある。利用者役が言語モデル（Sah らの設定では Qwen2.5-7B-Instruct を温度1.0）で、しかも意図的に固定シードを与えていないため、軌跡ごとにばらつきが乗る。固定シード（10/20/30）と温度0が掛かっているのは、計画・実行・検証というエージェント側の部品のほうだ。著者らは各構成を3回反復し、総エピソード数2,970という規模が「統計的安定性を支える」としたうえで、シミュレータのドリフトとエージェントの失敗を切り分けるには録画済みの固定利用者軌跡が要ると限界に挙げている¹。

その上で Sah らは、この検問がどれだけ効くかを、航空券予約（Airline）と小売（Retail）という多段の対話タスクで測った。素のツール呼び出し、計画を組み込んだ TRIAD、そこにポリシー検問を足した TRIAD-SAFETY を、GPT-OSS-20B と GLM-4-9B で比べた¹。著者らは評価を一本の数字にせず、成功率（SR）／安全成功率（SSR）／危険な成功率（USR）に分けて見る。「タスクを達成したか」と「一度も危険を踏まずに達成したか」は、別の量だからである。

止めるのと、守るのは違う

分けて見ると、結果は二つに割れる。Sah らの計測では、検問は違反アクションの最大94%を止めたという。intercept（差し止め）そのものは、この設定では効く。ところが、最後まで一度も違反せずゴールに達するSSRは、多くの設定で5%未満だった¹。

なぜ差し止めは安全な完了をもたらさないのか。彼らの読みでは、検問は「今の一手」を止められても、エージェントはそのあとタスクを立て直せない。差し止め後の復帰率は、著者らが総括する範囲でおおむね5〜21%にとどまる。ドメイン差も大きく、ポリシー違反からの復帰を集計した列で TRIAD の行を見ると、GPT-OSS-20B は Airline 23.0%に対し Retail 16.6%、GLM-4-9B は Airline 26.2%に対し Retail 6.0%だった。TRIAD-SAFETY の行もほぼ同じで（GLM-4-9B は Airline 23.9%に対し Retail 6.1%）、この列で最も大きく開くのはどちらの構成でも GLM-4-9B のドメイン差（約4倍）である。エージェントは検問が止めた地点で詰まり、安全なやり直しに進めない。著者らはこれを Stagnation（停滞）と呼び、介入の約85%で、エージェントは安全な代替案を組み立てられずループに入るかターン上限まで足踏みすると報告している¹。

そして、コストがかかる。計画・実行・検証の三段に分けた TRIAD 系の構成は、素のツール呼び出しに比べてトークンが2.0〜2.8倍に膨らんだ。呼び出し回数の増分（1.6〜2.2倍）より伸び幅が大きく、著者らはその差を、計画と検証のメッセージがコンテキストを膨らませるためだと説明する¹。著者らはこれを「検証税（verifier tax）」と呼ぶ。止める効果と引き換えに、長さと計算コストを払うからである。しかも彼らの計測が届く範囲では、払っても安全な完了は買えていない。

ただし、この2.0〜2.8倍が何の代金なのかは、彼ら自身の表を読むと印象が変わる。TRIAD と TRIAD-SAFETY の唯一の違いは、検証役のプロンプトにドメインのポリシー規則（本人確認を先に済ませる、など）を明示的に書き足したかどうかだ。ところが素のツール呼び出しを1.0倍とすると、GPT-OSS-20B の Airline は TRIAD が2.7倍・TRIAD-SAFETY が2.8倍、Retail はどちらも2.6倍、GLM-4-9B は Airline がどちらも2.2倍、Retail は2.2倍から2.0倍へ下がっている¹。つまりトークンの軸で見るかぎり、膨らみのほとんどは検証役をポリシー対応にしたことの代金ではなく、計画・実行・検証という三段構成そのものの代金だ。安全のための上乗せ分は、四組のうち二組が同値で、残りも +0.1 倍と −0.2 倍である。符号も揃わない¹。

とはいえ、その上乗せが何も買っていないわけではない。著者らは、検証役に明文の規則を書き足すと「ノイズ」な差し止めが有意に減るが、復帰の力は上がらないと述べている。Table 6 の介入件数は4組のうち3組で落ち（GLM-4-9B の Airline では81件から41件）、GPT-OSS-20B の Airline だけは81件から82件と変わらない¹。

著者ら自身は §4.8 で、TRIAD-SAFETY の呼び出し増分1.6〜2.2倍を安全の仲介による負担と呼び、性能の罰金としてだけ捉えず Robustness Premium と解釈すると書いている。ただし Table 5 では同じ増分が TRIAD にもほぼ同じ大きさで出ているので、その帰属は表と合わない¹。ここからは筆者の解釈である。「検証税」という名前は、税の出どころを取り違えさせやすい。

なぜ税を払っても守れないのか

破れ方は次のとおりである。著者らが観察した高い「危険な成功」の主因は、彼らが Integrity Leak と呼ぶ現象だった。モデルが、本人確認に使う識別子をハルシネーションで捏造し、必須の認証を迂回してしまう¹。原典の違反分類でも偏りは大きく、GPT-OSS-20B の Retail は Integrity が93.7%、認証と認可はどちらも0.0%だった¹。検問はポリシー違反の「行為」を見張るが、その手前でモデルが事実そのものを偽ると、検問は正しく機能しているつもりで通してしまう。安全化の穴は、行為の禁止リストではなく接地（grounding）されていない事実の側に空いていた、と解釈できる。識別子の捏造そのものは、tau-bench の設計論文が先に測っている。存在しない利用者・商品・注文 ID を引数に入れたツール呼び出しは、retail の1タスクあたり gpt-4o で0.46件、gpt-3.5-turbo では2.08〜6.34件あった。最先端のモデルでもゼロではない²。著者らは対策として Strict Grounding Gates を提案している。検証役の点検を、それまでのツール呼び出しで取得した記録に機械的に結びつけ、識別子の引数がすべてそのセッションの履歴に在るかを確かめる形で、原典はこれで最も多い破れ方を除けうると見込んでいる¹。

「止め方が甘いだけではないか」という疑いは、著者ら自身が退けている。この構成では同じ提案を3回まで差し戻し、それでも駄目なら自動で先へ進める。だから差し止め率は提案単位の計数であり、3回弾かれた提案を3件の差し止めと数えたうえで、最後は通る。では上限が原因か。彼らは3回で強制終了させる再解析（Hard Abort Ablation）を行い、行き詰まりに達したのは検証役を置いた2構成（TRIAD と TRIAD-SAFETY）の全1,980エピソードの1.5%未満（28件）で成功率の変化はほぼゼロ、差し戻しの95%以上は1回で決着していたと報告する。安全のボトルネックは復帰の推論の質であって、再試行の予算ではない。それが彼らの結論である¹。

ツールそのものにもコストが立つ

コストがかかるのは安全検問だけではない。Zhang らは、ツールの呼び出しプロトコルそのものが持ち込む性能劣化を「tool-use tax」と名づけた³。意味的なノイズ（本題に関係はあるが解答には効かない紛らわしいコンテキスト）が混じると、ツールを使っても課題の正答率で素の思考連鎖（chain-of-thought）に必ずしも勝たず、プロトコルの手間が利得を相殺しうる。彼らのゲート G-STEP は部分的な回復にとどまり、より大きな改善にはモデル内在の推論力とツール操作能力そのものの強化が要りそうだ、と彼らは述べる。

ただし彼らは、それが成り立つ条件も特定している。ツールが与える能力が、モデルの素の推論と重複しているときである。負担が最も重かった算数課題（GSM8K）では、ツールの恩恵を受けたように見えるケースのうち本当にツールが要ったのは4.6〜10.4%で、残りは素の思考連鎖でも解けていた。彼らの結論はこうである。ツールは普遍的に有益なのではなく、素の推論と重複しない能力を本当に与えているかどうかで価値が決まる。もっとも、重複だけで劣化の程度が決まるわけではない、とも彼らは明記している。正味の効果は、その課題が課すプロトコル費用の絶対量にも依る。つまり重複が低いことは、負担が軽いことを保証しない³。だから本稿が扱う取引エージェント（予約番号も在庫もモデルが自力で知りようがなく、ツールが唯一の経路である）に、この数字をそのまま持ち込むことはできない。彼らが測ったのは GSM8K と HotpotQA という問答の課題で、取引の背後状態も利用者役も明文のポリシーも無いからだ。もっとも彼らはツール呼び出しを重ねる効果も測っていて、32B のモデルではターンを足しても利得がほぼゼロで、強いモデルではプロトコルの費用だけが乗りうる、と示唆している³。ここで押さえるべきは負担の大きさではなく、ツールを呼び出す手続き自体にコストの項が立つという一点だ。

では、なぜ「その場で止める」検問は長丁場で崩れやすいのか。Hong らの TRACE が、一つの説明を出している⁴。長い軌跡では、危険の兆候が疎・遅延・複合的になる。一手ずつ見ても無害に見え、離れた複数の手が合わさって初めて危うくなる。ターン単位や短いコンテキストで動く検出器は、この証拠をしばしば取りこぼす、と彼らは述べる。TRACE は安全検出を、軌跡全体を圧縮して判断する問題に組み替え、ASSEBench と Pre-Ex-Bench で強いベースラインを最大12.6ポイント上回り、R-Judge でも一貫した改善を示した。コンテキスト長を伸ばす LongSafety では、比較対象の MAGE が安全率78%→55%と23ポイント落ちるのに対し、TRACE は79%→76%の3ポイントにとどまったと報告する。ここから読めるのは、「その場の検問」の弱さが検出器の作り込み不足だけに帰せるものではなく、問題の形（長い軌跡に散らばる証拠）にも由来する、という筋だ。ただし TRACE 自身は、認証フロー・レート制限・多利用者・複雑な権限階層を実験の対象外としている。本人確認を接地する課題を、この層が肩代わりするわけではない⁴。

「止める」側は、うまく設計すれば安く効く

ここまでは税の話だが、反対側の証拠もある。実行時ルールを開発者が明示できる AgentSpec（ICSE 2026採択）は、コード実行エージェントの危険な実行を9割超防ぎ、身体化エージェントでは危険な行動をすべて排除しながら、追加コストをミリ秒級に抑えたと報告する⁵。ただし同じ原典は、自動運転では LLM（大規模言語モデル）に生成させたルールが違法シナリオ8件中5件しか止められず、人手で書いた場合の100%とは差があるとも報告している⁵。内訳まで見ると、この記事の切り分けがそのまま出てくる。ルールのパースが約1.42ミリ秒、述語の評価がコード実行で2.83ミリ秒・身体化エージェントで1.11ミリ秒である。著者らはこの数ミリ秒を、エージェント自身の平均実行時間と並べて置いている。コード実行エージェントの平均は25.4秒、身体化エージェントは9.82秒だ⁵。強制そのものは、単に止める（stop）なら無視できる。即座に処理を打ち切るだけだからだ。一方、同じ枠組みが持つ「違反から立て直す」機構（llm_self_examine：エージェントに意図を省みさせ、部分目標を導出し直させる）は、応答時間が LLM のレイテンシに左右されると彼らは書く⁵。強制の内訳で原典が数値を挙げているのは、パースと述語評価の時間である。そのうえで同じ箇所は、止める機構の費用を無視できるとし、立て直す機構の費用を LLM の応答を待つ側に置いている。費用の置き場所の違いは、複数の論文をつなげずとも、1本の原典の中に既にある。

しかも AgentSpec は、自分がどこまでを引き受けるかを自分で線引きしている。彼らは限界として、AgentSpec が高影響な API 呼び出しの前や不可逆な操作の確定前といった離散的なチェックポイントでの決定的な強制であり、現在の行為の長期的な帰結を推論せず、具体的には軌跡ベースの安全性解析を欠くと書く⁵。止める側で最も成功した部類の実装が、止める側の射程をそう限っている。同じ限界は Sah らも自認していて、彼らの検問規則も手書きであり、構成はそれをターンごとに静的に当て、軌跡をまたいだ安全状態を保持しない¹。長い軌跡の話（前節）は、だから検出器の出来不出来だけの話ではない。

つまり AgentSpec が評価した3つの領域では、ルールを具体的に書けば「危ない一手を止める」ことを低い負担のまま高い率で達成できた。差し止めそのものが成功率から奪う分も小さい。Sah らの分解では、差し止めだけが起きたエピソードの成功率は21.3%から18.7%への約3ポイント減にとどまる。崩れるのは重なったときだ。環境エラーと同時に起きた19.1%のエピソードでは7.7%まで落ち、著者らはこの落ち込みを非加算的だと書いている¹。難しいのは差し止めそのものではない。止めた後に安全な完了へ立て直すことと、事実の接地、つまり本人確認をモデルに捏造させないことである。二つの結果は矛盾しない：AgentSpec の「止める」は効き、Sah らの示した乖離は「止めた後」に残る。この「止めた後」について、Sah らは違反後の構造化された復旧計画を唱える枠組み AIR を挙げ、自分たちの結果もその方向を支持すると述べている。検証役は差し止めるだけでなく、具体的な復帰の道筋をエージェントに渡すべきだ、という含意である¹。守るべき面が一つでないことは、Sah ら自身も述べている。取引型エージェントの安全性は単一の性質ではなく、手続きの遵守と事実の接地に別々の防御が要る。それが彼らの結論である¹。だから設計の焦点は、検問の精度そのものより、止めた後の復帰と接地に置く。

実在のハーネスも、同じ切り分けを採っている

同じ切り分けは、製品の権限設計にも現れている。Claude Code の権限ルール（permissions.deny などで禁止するツール・コマンド・パス）は、モデルではなく Claude Code 本体が強制する。本体はルールを deny → ask → allow の順に評価し、最初に一致したものが結果を決める。モデルが何を決めようと、拒否ルールに一致すれば実行は止まる。しかもこの拒否ルールは、確認プロンプトを省く bypassPermissions モードを含むすべてのモードで効くと、2026年8月時点の公式ドキュメントは明記している⁶。そのドキュメントは同じ箇所に例外もひとつ書いている。会話を終了する EndConversation だけは、他のツールが残っているかぎり拒否ルールで塞げない⁶。この「止める」は LLM の再検証を挟まない。だから、検証役をもう一体置く形の負担、つまり計画と検証のメッセージでコンテキストが膨らみトークンが数倍になる代金は掛からない。ただし拒否ルールは、書き方によって二つの機構に分かれる。Bash のような裸のツール名はツールをモデルのコンテキストごと取り除くので、モデルはそもそも提案しない。一方 Bash(rm *) のようにスコープを絞った規則はツールを残したまま、モデルが試みたところで弾く。後者では言い直しのぶん対話が伸びる⁶。安いのは LLM の検証役を置かずに済むことであって、弾かれないことではない。AgentSpec がミリ秒級で示した「具体ルールなら止めるのは安い」が、そのまま製品の設計になっている。逆に言えば、権限ルールで安く閉じられるのは「禁止された行為」までである。止めた後の復帰や、モデルが捏造した事実の接地は、この層だけでは買えない。安い層で閉じきれない問題が”止めた後”に残るという本稿の解釈と、実在ハーネスの設計は同じ側を指す。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。