論文解説: SafeActBench — 道具を使うエージェントは「実行」より手前で失敗する
「結果が合っていた」は「根拠があって動いた」ことを意味しない。656件のSafeActBenchと10構成の実測で、失敗の多くが実行より手前——調べ足りないまま止まる／根拠が揃う前に動く——で起きていることを示した論文を1から解説する。
要点
- SafeActBenchは、6つの業務領域と5つのプロトコルに656件の事例を並べた、道具を使うエージェントの評価である。
- 評価はEvidence Ledgerと決定的な軌跡評価器で、行動の前に何が確立されていたかを記録する。
- Legacy（静的な行動判断）は83.7〜97.7だが、対話的なプロトコルでは47.3〜72.6まで落ちる。
- 失敗はしばしば実行の前に始まり、調べ足りないまま止まるか、根拠が確立される前に動く。
- 同じGPT-5.6でもECSはCodexで65.4、共通Inspectでは61.0と、ハーネスで数字が動く。
From Evidence to Action: How Tool-Using Agents Fail
一次資料 — この記事の根拠
論文の発表 2026-10-06→この解説の公開 2026-10-10同月
From Evidence to Action: How Tool-Using Agents FailHongzhan Lin, Shidong Cao, Ziyang Luo ほか · 2026-10-06 · v1arXiv:2610.07753論文ページ·PDF原文の要旨（Abstract）を読む
Tool-using agents make consequential changes to external state, yet correct outcomes do not guarantee that their actions were supported by evidence established beforehand. We study where this evidence-to-action chain breaks as agents move from deciding whether to act to executing single actions and dependent workflows. Across ten model-harness configurations, strong static action assessment can coexist with much weaker interactive execution. Failures often begin before execution: agents stop with incomplete investigation or act before required evidence is established. Once required evidence is obtained, single-action execution is usually reliable, while multi-action workflows additionally expose unresolved prerequisites and incomplete execution. For this analysis, we introduce SafeActBench, comprising 656 cases across six operational domains and five protocols that progress from static action judgment and investigated non-action to single- and multi-action workflows. A provenance-bound Evidence Ledger and deterministic trajectory evaluator track what information was established, when actions occurred, and whether downstream dependencies were satisfied. These results show that failures arise not only from missing information, but also from how agents use established evidence when deciding and executing actions.
結果が合っていても、根拠があったとは言えない
この記事で読む論文の原題は "From Evidence to Action: How Tool-Using Agents Fail"（Hongzhan Lin・Shidong Cao・Ziyang Luo・Wenhao Chai・Mong-Li Lee・Wynne Hsu / arXiv:2610.07753, 2026-10-06）です。
道具を使うエージェントは、外の世界の状態を実際に変えます。メールを送る、設定を書き換える、支払いを通す。ここで厄介なのは、出てきた結果が正しくても、その行動が事前に確かめた根拠に支えられていたとは限らないことです。たまたま当たった行動と、調べた上での行動は、結果だけ見ると区別が付きません。
この論文は、その「根拠から行動へ」の鎖がどこで切れるかを測ります。
何を作ったか
SafeActBench。要旨の記述では 656件の事例を、6つの業務領域と5つのプロトコルに並べたものです。プロトコルは「静的な行動判断」から始まり、「調べた上で何もしない」を経て、単発の行動、さらに依存関係のある複数行動のワークフローへと段を上げていきます。
測り方の核が2つあります。
- Evidence Ledger（出所に紐づけた根拠の台帳）… どの情報が、いつ確立されたかを追う
- 決定的な軌跡評価器 … 行動がいつ起きたか、下流の依存関係が満たされたかを機械的に判定する
つまり「正解したか」ではなく、正解する前に何を知っていたかを記録する作りです。
実測: 静的な判断は得意、対話的な実行は苦手
10のモデル×ハーネス構成で測っています。ハーネスは Claude Code・Codex・DeepSeek Harness (DSH)・Qwen Code・ZCode と、Inspect AI 上に実装した共通の ReAct ハーネス（Inspect）で、同じモデルを別のハーネスで動かした比較ができます。
表の列は、全体（ECS・P-M・D-M＝プロトコルと領域のマクロ平均）と、プロトコル別（Legacy・V0〜V3）です。
| モデル / ハーネス | ECS | Legacy | V0 | V1 | V2 | V3 |
|---|---|---|---|---|---|---|
| Claude-5 / Claude Code | 67.2 | 97.7 | 63.4 | 60.3 | 60.6 | 65.9 |
| Claude-5 / Inspect | 63.4 | 96.5 | 58.9 | 54.2 | 59.1 | 61.4 |
| GPT-5.6 / Codex | 65.4 | 96.5 | 65.7 | 52.7 | 58.3 | 64.4 |
| GPT-5.6 / Inspect | 61.0 | 94.2 | 59.4 | 47.3 | 55.3 | 60.6 |
| DeepSeek-V4 / DSH | 63.0 | 96.5 | 49.1 | 61.1 | 65.2 | 59.1 |
| DeepSeek-V4 / Inspect | 57.5 | 83.7 | 56.0 | 49.6 | 56.8 | 50.8 |
| Qwen3.8 / Qwen Code | 66.0 | 91.9 | 72.6 | 58.8 | 59.8 | 53.8 |
| Qwen3.8 / Inspect | 63.9 | 94.2 | 67.4 | 60.3 | 54.5 | 52.3 |
読み方は1つです。Legacy（静的な行動判断）は 83.7〜97.7 と高いのに、対話的なプロトコルでは 47.3〜72.6 まで落ちる。 同じモデルの話です。「行動の良し悪しを紙の上で判定させれば9割以上当てるのに、実際に道具を持たせると半分前後になる」。要旨の言葉では、強い静的判断と、ずっと弱い対話的実行は同居しうる。
ハーネスの効きも見えます。GPT-5.6 は Codex で ECS 65.4、同じモデルを共通 Inspect で動かすと 61.0。Qwen3.8 は Qwen Code 66.0 / Inspect 63.9。モデルを変えなくても、器を変えると数字が動きます（この構図は HarnessDev の解説と同じ方向の話です）。
失敗は「実行」より手前で起きている
この論文のいちばん実務に効く主張です。要旨から3点。
- 失敗はしばしば実行の前に始まる。 エージェントが調べ足りないまま止まるか、必要な根拠が確立される前に動く。
- 必要な根拠が得られた後なら、単発の行動はおおむね確実。
- 複数行動のワークフローは、さらに別の失敗を見せる。 未解決の前提条件と、途中で止まる実行。
順番が大事です。「情報が足りなかったから失敗した」だけではない。確立した根拠を、決めるときと実行するときにどう使うかでも失敗する——これが結論です。
実装者にとって何が変わるか
- 「出力が正しい」で受け入れる評価をやめる。 根拠がいつ揃ったかを記録しないと、たまたま当たった行動を合格にします。
- 止まり方も失敗として数える。 情報がまだ取れるのに「分かりません」と引くのは、この論文では investigated non-action とは別の失敗です。要旨の表現では、情報が取得可能なまま残っているとき、欠けた根拠は早すぎる拒否ではなく追加調査を促すべきです。
- 複数行動は単発の延長ではない。 前提条件の解決と、最後までやり切ることが別に要る。
現場ではこう使う
道具を持つエージェントを業務に組み込むエンジニア、エージェントの評価基盤を作る人、本番で動かす運用担当が、この論文の見方を使う場面は主に3つあります。
1. 評価ログに「いつ知ったか」を残す。 最終状態だけを採点する評価（チケットが閉じたか、設定値が期待どおりか）は、たまたま当たった行動も合格にします。最低限、ツール呼び出しの軌跡——どの道具を、どの引数で、どの順に呼び、何が返ったか——を保存し、書き込み系の行動の時点でその判断に必要な読み取りが済んでいたかを照合できるようにします。Inspect AI なら評価ログに各サンプルのメッセージとツール呼び出しが残り、inspect view で軌跡を追えます。採点器（scorer）を最終出力ではなく軌跡に対して書くのが、論文の Evidence Ledger と決定的な軌跡評価器を手元で小さく真似る形です。
2. 書き込み系の道具の手前に関門を置く。 失敗の多くが「根拠が揃う前に動く」なら、止める場所は実行の直前です。Claude Code の PreToolUse フックや許可するツールの設定、Codex の --sandbox（read-only / workspace-write）や承認ポリシーは、まさにこの境目を操作するつまみです。読み取りは自由に、外の状態を変える呼び出し（送信・削除・支払い・本番設定の変更）にだけ確認を挟む、という分け方が出発点になります。ただし関門は根拠が揃ったかを判定してはくれません。人が承認する場面を作るだけです。承認の画面に「この行動の前に何を確かめたか」を出させないと、承認する側も結果の見た目だけで押すことになります。
3. 「分かりません」を成功扱いにしない。 安全側に倒した拒否は一見無害ですが、この論文は、情報がまだ取れるのに調査をやめることを失敗として数えます。運用では止まったログを拒否率として眺めるだけでなく、止まった時点でまだ実行していない読み取り（見ていないファイル、叩いていない参照API）が残っていたかを確かめます。残っていたなら、直すべきはプロンプトや道具の説明の側で、調査を続けるよう促す方向です。
知らないと事故になる落とし穴
- 単発の成功率から複数行動を見積もる。 論文では、根拠が揃った後の単発行動はおおむね確実でした。しかし複数行動のワークフローでは、未解決の前提条件と途中で止まる実行が別に出ます。1手ずつのテストが全部通っても、ワークフローを最初から最後まで通すテストを別に持つ必要があります。
- ハーネスを混ぜたまま比べる。 上の表のとおり、同じ GPT-5.6 でも Codex では ECS 65.4、Inspect では 61.0 でした。モデルを比べるなら器を固定し、器を比べるならモデルを固定します。
- 静的な判定テストだけで安全性を語る。 「この行動はやってよいか」を紙の上で問うテストで高得点（Legacy 83.7〜97.7）でも、道具を持たせると 47.3〜72.6 まで下がりうる。判定テストの点は、実行の安全性の代わりになりません。
設計レビューや面接で問われる問い
- 「このエージェントの評価で、結果が正しかった事例のうち、根拠を確かめてから動いたものはどれだけありますか」——最終状態の採点だけでは答えられない、と言えるかが分かれ目です。軌跡を保存し、書き込み行動の時点で必要な読み取りが済んでいたかを照合する仕組みがあって初めて数えられる、と筋道を立てます。
- 「拒否率が下がったのは改善ですか」——不要な拒否が減ったのか、根拠が足りないまま動くようになったのかで、意味は正反対になります。この2つを分けて数えていなければ判断できない、と答えます。
この記事で確かめていないこと
- V0〜V3 が具体的に何のプロトコルかは書いていません。 取得した原文に 4.2 節の本文が入っておらず、列名以上のことを言えないためです。段の進み方は要旨の記述（静的判断 → 調べた上での非行動 → 単発 → 複数行動）に拠っています。
- 表は ZCode の行まで取れていないため、10構成のうち8構成を載せています。
- 領域別の件数は、6領域の名称と数の対応が原文の抽出から確定できなかったので載せていません。
数値はすべて取得済みの原文（arXiv:2610.07753）と逐語で照合しています。
コメント
コメントにはログインが必要です