In Silico

AIエージェント

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

2026/7/28 （更新: 2026/11/3）

🤖 AIを使用して執筆

  • エージェントの実行時検証
  • AIエージェント
  • 安全性
  • tau-bench
  • TRIAD-SAFETY
  • AgentSpec
  • TRACE
  • Claude Code
  • Integrity Leak
  • 安全成功率
  • 差し止め
  • 復帰率
  • トークン
  • 接地
  • 本人確認
  • 識別子
  • ポリシー
  • 軌跡
  • 権限ルール
  • tool-use tax
  • Stagnation
  • GPT-OSS-20B
  • GLM-4-9B
  • GSM8K
  • bypassPermissions
  • AIR
目次
背景・問い・要点
背景

AIエージェントは、指示を受け取るとツールを呼び出す。予約システムのAPI（Application Programming Interface）を呼び、レコードを書き換え、返金の処理を出す。モデルが文章だけを返すなら、開発者は間違いを読んで捨てればよい。ツールを持つモデルの間違いは、外の世界に残る。だから実務では、開発者はモデルが出した操作をそのまま実行させない。実行の直前に「この操作は開発者が決めた手順に反していないか」を確かめる層を挟み、反していれば弾く。たとえば、本人確認を済ませる前に予約を変更しようとしたら、そこで止める、という規則である。この実行時の検証（ガード）は、ツールを持つエージェントを安全に働かせる定番の手である。

検証を言語モデルにさせる構成では、規則に照らして弾く前の段階がある。開発者はまずエージェントに計画を立てさせ、その計画を、検証役と呼ぶ別の言語モデルの呼び出しに点検させ、弾かれた後にはやり直させる。呼び出しが増えるので対話は長くなり、計算の費用が増える。この費用を払って何が得られるのかは、止めた回数を数えるだけではわからない。

問い

危ない操作を実行時の検証で止めるようにしたエージェントは、どこまで安全に仕事をやり遂げられるのか。

要点

tau-bench で2モデルを測った論文1本では、検証は違反操作の最大94%を止めたが、一度も違反せずに終えたタスクは多くの設定で5%未満だった1。検証は止めることには効くが、安全にやり遂げるところまでは届いていない。

エージェントは止められた後に立て直せないことが多く、本人確認のIDを捏造して認証を迂回することもあった1。検証のためにトークンは2〜2.8倍に増えたが、その大半は役を計画・実行・検証に分けた構成そのものの費用だった1。

モデル・例示

9割を止めても、安全に終わる件数は立て直しで決まる

※ この節の例は、説明のために作った架空のものです。

この例の数では、一度も違反せずに終わる件数を左右するのは、違反を止める割合よりも、止められた後に立て直せる割合のほうである。本人確認の要る手続きを、検証役つきのエージェントに100件こなさせる場合を考える。100件のうち80件で、エージェントは途中で一度は規則に反する操作を出そうとする。検証役はその9割にあたる72件を実行の前に止め、残る8件は違反を含んだまま進む。

止められた72件のうち、止められた地点から規則どおりのやり方に立て直して最後まで終えるのが8件に1件なら、9件である。一度も規則に反しなかった20件のうち、ゴールに届くのが半分なら10件である。一度も違反せずにゴールに届いたのは合わせて19件で、100件中19%になる。

二つの割合を一つずつ動かすと、どちらが結果を決めているかがわかる。

  1. 止める割合を9割から10割に上げても、止める件数は72件から80件に増えるだけで、立て直して終える件数は9件から10件へ1件しか増えない。
  2. 立て直せる割合を8件に1件から2件に1件へ上げると、立て直して終える件数は9件から36件に増え、一度も違反せずに届く件数は19件から46件になる。
  3. 止められなかった8件の中には、違反を含んだままゴールに届くものがありうる。それはゴールに届いた件数には入るが、一度も違反せずに届いた件数には入らない。

測り方：達成と遵守を別々に数える

Sah らの測定は、タスクを達成したかと、手続きの規則を守ったかを、同じ対話の記録から別々に数える。比べたのは三つの構成である。一つ目は素のツール呼び出しである。二つ目の TRIAD は、計画・実行・検証の三役に分け、検証役が一般的な規則（本人確認を先に済ませる、など）で提案を弾く。三つ目の TRIAD-SAFETY は、その検証役のプロンプトにドメインのポリシー規則を書き足したものである。これらを GPT-OSS-20B と GLM-4-9B の2モデルで、航空券予約（Airline）と小売（Retail）という多段の対話タスクの上で比べた1。

土台のベンチは tau-bench（τ-bench）である。Yao らが2024年6月に公開したもので、ツールを持つエージェントと、言語モデルが演じる利用者との対話を模擬する。採点は会話の見た目でなく、終了時のバックエンドの状態を正解の状態と突き合わせて行う。各ドメインは、本人確認を済ませてから予約を変更する、といった明文の手続き上のポリシーを、エージェントへの指示として与える2。

ただし tau-bench の採点そのものはポリシーの遵守を見ない。Yao らは、報酬1は成功の必要条件ではあっても十分条件ではないかもしれない、明示的な確認を取らずに返金処理を出すようなポリシー違反がありうるからだ、と自ら断っている2。その隙間を埋めたのが Sah らだ。 彼らは、エージェントが1件のタスクで出した発話とツール呼び出しの記録（軌跡ログ）に、同じ入力には常に同じ判定を返す監査スクリプト（strict_policy_auditor.py）を当て、違反を3類型に分けて機械的にラベル付けし、達成と遵守を切り分けた1。彼らが tau-bench を選んだ理由も、ベンチ側で遵守が測れるからではない。Web操作や身体化環境の対話ベンチは主に達成度を測るもので、手続きの遵守を扱わないからだ、と彼らは書いている1。

評価は一本の数字にせず、成功率（SR、Success Rate）／安全成功率（SSR、Safe Success Rate）／危険な成功率（USR、Unsafe Success Rate）に分けて見る。「タスクを達成したか」と「一度も危険を踏まずに達成したか」は、別の量だからである。

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

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

分けて見ると、結果は二つに割れる。Sah らの計測では、検証役は違反アクションの最大94%を止めたという。intercept（差し止め）そのものは、この設定では効く。ところが、最後まで一度も違反せずゴールに達するSSRは、多くの設定で5%未満だった1。比べる相手の素のツール呼び出し（検証役なし）では、SSR は0.0〜2.6%だった。検証役を置いて最も上がったのは GLM-4-9B の Airline で、0.7%から5.3%への約5ポイントである。GPT-OSS-20B はどの構成でも0.7%以下のままだった1。成功率（SR）のほうは、検証役を置いた構成も最終的には素のツール呼び出しと同程度に収まる、と著者らは書いている1。

差し止めが安全な完了につながらない理由は、彼らの読みでは復帰の失敗にある。検証役は「今の一手」を止められても、エージェントはそのあとタスクを立て直せない。差し止め後の復帰率は、著者らの総括では約5〜21%、ポリシー違反からの復帰を集計した表の列では6.0〜26.2%である1。ここでの復帰率は、差し止めなどの介入が1回以上あったエピソードのうち、終了時の状態が正解と一致した割合で、届くまでに違反したかどうかは問わない。一度も違反せずに届いた割合は、前段の SSR（多くの設定で5%未満）のほうで測られている1。

復帰率はドメインによっても大きく違う。同じ列で 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倍）である1。

立て直せないエージェントは、止められた地点から先へ進まない。著者らはこれを Stagnation（停滞）と呼び、介入の約85%で、エージェントは安全な代替案を組み立てられずループに入るかターン上限まで足踏みすると報告している1。

検証には費用もかかる。計画・実行・検証の三段に分けた TRIAD 系の構成は、素のツール呼び出しに比べて、トークン（モデルが読み書きする文字列を数える単位）が2.0〜2.8倍に増えた。呼び出し回数の増分（1.6〜2.2倍）より伸び幅が大きく、著者らはその差を、計画と検証のメッセージが、モデルに毎回渡す対話の履歴（コンテキスト）を長くするためだと説明する1。著者らはこれを「検証税（verifier tax）」と呼ぶ。止める効果と引き換えに、長さと計算コストを払うからである。それだけの費用を払っても、彼らが測った範囲では SSR は多くの設定で5%未満にとどまる。

この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倍へ下がっている1。つまりトークンの軸で見るかぎり、増分のほとんどは検証役をポリシー対応にしたことの費用ではなく、計画・実行・検証という三段構成そのものの費用だ。ポリシー規則のぶんの上乗せは、四組のうち二組が同値で、残りも +0.1 倍と −0.2 倍である。符号も揃わない1。

著者らの解釈は違う方向を向いている。著者らは §4.8 で、TRIAD-SAFETY の呼び出し増分1.6〜2.2倍を安全の仲介による負担と呼び、性能の罰金としてだけ捉えず Robustness Premium と解釈すると書いている。重大な取引の一手ごとを、ドメインの厳しい制約に照らして点検させるための予算だという説明である。ただし Table 5 では同じ増分が TRIAD にもほぼ同じ大きさで出ているので、増分はドメインのポリシー規則を書き足した分ではなく、計画・実行・検証に分けた構成そのものから来ている1。ここからは筆者の解釈である。「検証税」という名前は、費用がポリシー規則のために生じたと読ませやすい。

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

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

著者らが観察した高い「危険な成功」の主因は、彼らが Integrity Leak と呼ぶ現象だった。モデルが、本人確認に使う識別子をハルシネーション（根拠の無い内容を事実のように生成すること）で捏造し、必須の認証を迂回してしまう1。原典の違反分類でも偏りは大きく、GPT-OSS-20B の Retail は Integrity が93.7%、認証と認可はどちらも0.0%だった1。

検証役が見張るのはポリシー違反の「行為」である。その手前でモデルが事実そのものを偽ると、検証役は規則どおりに動いたまま違反を通してしまう。安全化の欠けは、行為の禁止リストではなく、それまでのツール呼び出しで得た記録に接地（grounding）されていない事実の側にあった、と解釈できる。

識別子の捏造そのものは、tau-bench の設計論文が先に測っている。存在しない利用者・商品・注文 ID を引数に入れたツール呼び出しは、retail の1タスクあたり gpt-4o で0.46件、gpt-3.5-turbo では2.08〜6.34件あった。最先端のモデルでもゼロではない2。著者らは対策として Strict Grounding Gates を提案している。検証役の点検を、それまでのツール呼び出しで取得した記録に機械的に結びつけ、識別子の引数がすべてそのセッションの履歴に在るかを確かめる形で、原典はこれで最も多い破れ方を除けうると見込んでいる1。

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

長い軌跡では、一手ずつの検証が証拠を取りこぼしやすい

その場で一手ずつ止める検証が、手数の多いタスクで弱くなる理由を、Hong らの TRACE が一つ出している3。長い軌跡では、危険の兆候が疎・遅延・複合的になる。一手ずつ見ても無害に見え、離れた複数の手が合わさって初めて危うくなる。ターン単位や短いコンテキストで動く検出器は、この証拠をしばしば取りこぼす、と彼らは述べる。

TRACE は安全検出を、軌跡全体を圧縮して判断する問題に組み替え、ASSEBench と Pre-Ex-Bench で強いベースラインを最大12.6ポイント上回り、R-Judge でも一貫した改善を示した。コンテキスト長を伸ばす LongSafety では、比較対象の MAGE が安全率78%→55%と23ポイント落ちるのに対し、TRACE は79%→76%の3ポイントにとどまったと報告する。ここから読めるのは、「その場の検証」の弱さが検出器の作り込み不足だけに帰せるものではなく、問題の形（長い軌跡に散らばる証拠）にも由来する、という筋だ。ただし TRACE 自身は、認証フロー・レート制限・多利用者・複雑な権限階層を実験の対象外としている。本人確認を接地する課題を、TRACE の検出器が代わりに解くわけではない3。

ツールを呼ぶ手続き自体にも費用がかかる

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

彼らは、それが成り立つ条件も特定している。ツールが与える能力が、モデルの素の推論と重複しているときである。負担が最も重かった算数課題（GSM8K）では、ツールの恩恵を受けたように見えるケースのうち本当にツールが要ったのは4.6〜10.4%で、残りは素の思考連鎖でも解けていた。彼らの結論はこうである。ツールは普遍的に有益なのではなく、素の推論と重複しない能力を本当に与えているかどうかで価値が決まる。もっとも、重複だけで劣化の程度が決まるわけではない、とも彼らは明記している。正味の効果は、その課題が課すプロトコル費用の絶対量にも依る。つまり重複が低いことは、負担が軽いことを保証しない4。

この数字を、本稿が扱う取引エージェントにそのまま持ち込むことはできない。取引エージェントでは、予約番号も在庫もモデルが自力で知りようがなく、ツールが唯一の経路である。彼らが測ったのは GSM8K と HotpotQA という問答の課題で、取引の背後状態も利用者役も明文のポリシーも無い。もっとも彼らはツール呼び出しを重ねる効果も測っていて、32B のモデルではターンを足しても利得がほぼゼロで、強いモデルではプロトコルの費用だけが加わりうる、と示唆している4。ここで押さえるべきは負担の大きさではなく、ツールを呼び出す手続き自体に費用の項があるという一点だ。

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

ここまでは費用の話だが、反対側の証拠もある。実行時ルールを開発者が明示できる AgentSpec（ICSE 2026採択）は、コード実行エージェントの危険な実行を9割超防ぎ、身体化エージェントでは危険な行動をすべて排除しながら、追加コストをミリ秒級に抑えたと報告する5。ただし同じ原典は、自動運転では LLM（Large Language Model、大規模言語モデル）に生成させたルールが違法シナリオ8件中5件しか止められず、人手で書いた場合の100%とは差があるとも報告している5。

費用の内訳では、止める機構と立て直す機構の差が1本の原典の中に出ている。ルールのパースが約1.42ミリ秒、述語の評価がコード実行で2.83ミリ秒・身体化エージェントで1.11ミリ秒である。著者らはこの数ミリ秒を、エージェント自身の平均実行時間と並べて置いている。コード実行エージェントの平均は25.4秒、身体化エージェントは9.82秒だ5。強制そのものは、単に止める（stop）なら無視できる。即座に処理を打ち切るだけだからだ。一方、同じ枠組みが持つ「違反から立て直す」機構（llm_self_examine：エージェントに意図を省みさせ、部分目標を導出し直させる）は、応答時間が LLM のレイテンシに左右されると彼らは書く5。原典が数値を挙げているのはパースと述語評価の時間であり、そのうえで止める機構の費用を無視できるとし、立て直す機構の費用を LLM の応答時間で決まる側に置いている。

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

AgentSpec が評価した3つの領域では、ルールを具体的に書けば「危ない一手を止める」ことを低い負担のまま高い率で達成できた。差し止めそのものが成功率を下げる分も小さい。Sah らの分解では、差し止めだけが起きたエピソードの成功率は21.3%から18.7%への約3ポイント減にとどまる。大きく落ちるのは重なったときだ。環境エラーと同時に起きた19.1%のエピソードでは7.7%まで落ち、著者らはこの落ち込みを非加算的だと書いている1。

難しいのは差し止めそのものではない。止めた後に安全な完了へ立て直すことと、事実の接地、つまり本人確認をモデルに捏造させないことである。二つの結果は矛盾しない：AgentSpec の「止める」は効き、Sah らの示した乖離は「止めた後」に残る。この「止めた後」について、Sah らは違反後の構造化された復旧計画を唱える枠組み AIR（Agent Incident Response）を挙げ、自分たちの結果もその方向を支持すると述べている。検証役は差し止めるだけでなく、具体的な復帰の道筋をエージェントに渡すべきだ、という含意である1。守るべき面が一つでないことは、Sah ら自身も述べている。取引型エージェントの安全性は単一の性質ではなく、手続きの遵守と事実の接地に別々の防御が要る。それが彼らの結論である1。だから設計の焦点は、検証役の精度そのものより、止めた後の復帰と接地に置く。

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

同じ切り分けは、製品の権限設計にも現れている。Claude Code の権限ルール（permissions.deny などで禁止するツール・コマンド・パス）は、モデルではなく Claude Code 本体が強制する。本体はルールを deny → ask → allow の順に評価し、最初に一致したものが結果を決める。

  1. deny ルールに一致する？
    はい
    ✗ 拒否
    いいえ
  2. ask ルールに一致する？
    はい
    利用者に確かめる
    いいえ
  3. allow ルールに一致する？
    はい
    ✓ 許可
    いいえ
  4. ルールでは決まらない

モデルが何を決めようと、拒否ルールに一致すれば実行は止まる。しかもこの拒否ルールは、確認プロンプトを省く bypassPermissions モードを含むすべてのモードで効くと、2026年8月時点の公式ドキュメントは明記している6。そのドキュメントは同じ箇所に例外もひとつ書いている。会話を終了する EndConversation だけは、他のツールが残っているかぎり拒否ルールで塞げない6。

この「止める」は LLM の再検証を挟まない。だから、検証役をもう一体置く形の負担、つまり計画と検証のメッセージでコンテキストが長くなりトークンが2〜2.8倍になる費用は掛からない。ただし拒否ルールは、書き方によって二つの機構に分かれる。Bash のような裸のツール名はツールをモデルのコンテキストごと取り除くので、モデルはそもそも提案しない。一方 Bash(rm *) のようにスコープを絞った規則はツールを残したまま、モデルが試みたところで弾く6。後者では言い直しのぶん対話が伸びる。安いのは LLM の検証役を置かずに済むことであって、弾かれないことではない。AgentSpec がミリ秒級で示した「具体ルールなら止めるのは安い」が、そのまま製品の設計になっている。

権限ルールで安く止められるのは「禁止された行為」までである。止めた後の復帰や、モデルが捏造した事実の接地は、この層だけでは得られない。安い層で止めきれない問題が”止めた後”に残るという本稿の解釈と、Claude Code の権限設計は食い違わない。

出典6件

  1. Sah ほか「The Verifier Tax: Horizon Dependent Safety Success Tradeoffs in Tool Using LLM Agents」CAIS ‘26, 2026. https://arxiv.org/abs/2603.19328 — 検証つき構成を tau-bench で比べた査読付き会議録。独立再現は未確認。 https://doi.org/10.1145/3786335.3813160 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27

  2. Yao ほか「τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains」arXiv, 2024. https://arxiv.org/abs/2406.12045 — 終了時のデータベース状態で採点するベンチ。報酬1でもポリシー違反がありうると原典自身が断る。 ↩ ↩2 ↩3

  3. Hong ほか「TRACE: Trajectory Risk-Aware Compression for Long-Horizon Agent Safety」arXiv, 2026（査読前）. https://arxiv.org/abs/2606.00611 — 安全検出を、軌跡全体の証拠を圧縮して判断する問題に組み替えた。 ↩ ↩2

  4. Zhang ほか「Are Tools All We Need? Unveiling the Tool-Use Tax in LLM Agents」arXiv, 2026（査読前）. https://arxiv.org/abs/2605.00136 — 3モデルの GSM8K と HotpotQA に紛らわしいコンテキストを混ぜ、ツールを呼ぶ手続き自体の負担を測った。 ↩ ↩2 ↩3

  5. Wang ほか「AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents」ICSE 2026. https://arxiv.org/abs/2503.18666 — 開発者が書く実行時ルールで危険な行為を止める枠組みを、3領域で評価した。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Anthropic「Configure permissions」「Choose a permission mode」Claude Code 公式ドキュメント, 閲覧2026-08-27. https://code.claude.com/docs/en/permissions — 権限ルールの評価順と、拒否ルールが効く範囲の記述。 https://code.claude.com/docs/en/permission-modes ↩ ↩2 ↩3

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