この記事の対象と、読み終えて得られるもの
対象は、LLM エージェントを実務ワークフローに組み込む立場の方です。具体的には、社内で Claude Code や Codex のような CLI エージェントを走らせている開発者、MCP サーバーや外部スキルを配布・導入する側、そして「エージェント導入の可否」を判断する立場の方を想定しています。
読み終えると、次の 3 点が手に入ります。
- エージェント評価で「タスク完了率」だけを見ることが、なぜ危険なのかの定量的な根拠
- 攻撃の侵入経路によって防御成功率が数十ポイント変わるという事実と、その実務的な意味
- 自分の実行基盤に「安全性判定」を後付けするときの、設計の当たり所
題材は arXiv に 2026 年 7 月に提出された論文 AgentS4D: Benchmarking Runtime Risks across the Execution Lifecycle of LLM-Based Workspace Agents（arXiv:2607.27294）です。この論文が示した数字のうち、実装判断に効くものだけを取り出して整理します。
結論を先に - 「完了した」は「安全だった」を意味しない
AgentS4D は 4 種のエージェントハーネスと 5 種の LLM バックエンドを掛け合わせた 20 構成に対し、328 件の安全性テストケースを流し、計 6,560 回の実行を測定しました。その結果が次の表です。
| 指標 | 全体平均 | 意味 |
|---|---|---|
| TCR（Task Completion Rate） | 93.73% | 成果物が要求仕様の判定をクリアした割合 |
| ASR（Unsafe-Signal Rate） | 68.00%（4,461 / 6,560） | 危険信号が 1 つ以上トリガーされた実行の割合 |
| cASR（Conditional ASR） | 75.75% | ペイロードへの接触が確認できた有効条件に限った危険実行の割合 |
| SHR（Safe Handling Rate） | 22.20% | 安全に対処（防御または無害化）された実行の割合 |
| Unsafe yet Complete | 66.22%（4,344 / 6,560） | 危険な副作用を出しながらタスクを完了した実行の割合 |
読み方の要点は、TCR と Unsafe yet Complete が同時に高いことです。成果物は 9 割以上の確率で「正しく」でき上がり、そのうえで全実行の 3 分の 2 が安全基準を侵害していました。
危険と判定された 4,461 実行の内訳はさらに極端です。
- 危険なままタスク完了（Unsafe yet Complete）: 4,344 件 = 97.38%
- 危険が起きてタスクも失敗（Unsafe & Incomplete）: 117 件 = 2.62%
つまり、危険な実行はほぼ必ず「成功」として返ってきます。成果物だけを検査する評価系にとって、危険な実行は失敗として現れないのです。ここが、この論文がベンチマークとして持ち込んだ一番の変更点になります。
なぜ従来の評価では見えないのか - 判定の分離
従来のエージェント評価は、最終成果物の正しさ（SWE-bench 系）か、単一のプロンプトインジェクションに対する防御率のいずれかを見ることが多く、実行の途中で起きた副作用は測定対象の外にありました。
AgentS4D は、完了判定と安全性判定を別々の検証器で行う構造を取ります。エージェント自身の自己申告や最終出力ではなく、ホスト側が実行軌跡・ツール呼び出し・ファイル変更・外部通信・永続状態を独立に検証します。
評価の骨格は 4 つの次元（S / T / L / K）で構成されています。
S / T / L はケース設計時に付けるラベル、K は実行後に証跡を整理するための段階です。
S: 侵入経路（Risk-Entry Sources、6 種）
| ID | 経路 | 具体例 |
|---|---|---|
| S1 | ユーザーメッセージ | プロンプトへの直接混入 |
| S2 | アップロード資源 | ドキュメントや CSV への埋め込み |
| S3 | Web ページ / URL | 検索・URL 参照で取得したコンテンツ |
| S4 | 外部スキルバンドル | 配布されたスキル定義・指示書 |
| S5 | 事前ロード済みメモリ | 過去セッションのログや記憶領域 |
| S6 | MCP / ツールプロトコル | ツール説明文・パラメータスキーマ・返却値 |
T: 誘導手法（Induction Strategies、6 種）
| ID | 手法 | 内容 |
|---|---|---|
| T1 | Instruction Override | 既存指示の強制上書き |
| T2 | Authority Impersonation | 管理者・上位認可者の偽装 |
| T3 | Priority Manipulation | 緊急性を理由にした安全手順のスキップ誘導 |
| T4 | Covert Embedding | 正常な業務手順への隠蔽 |
| T5 | Conditional Triggering | 日付・ファイル名など条件成立時のみ発火 |
| T6 | Encoding Obfuscation | Base64 等による難読化 |
L: 対象被害（Target Harms、9 種）
データ漏洩（L1）、破壊的アクション（L2）、内部偵察（L3）、権限昇格（L4）、目的の乗っ取り（L5）、範囲外リソースへの不正アクセス（L6）、ポリシーのバイパス（L7）、未制御の外部送信（L8）、永続状態の汚染（L9）の 9 分類です。
L1・L8 は情報の流出、L2・L9 は状態の破壊と持続的汚染で、後者は実行が終わった後に残る点が厄介です。エージェントを繰り返し走らせる自動化基盤では、L9 の混入が次回以降の実行を汚染する連鎖が起きえます。
K: ライフサイクルチェックポイント（7 段階）
K1 入力取り込み → K2 評価・認可判断 → K3 計画形成 → K4 ツール実行 → K5 外部作用 → K6 状態更新 → K7 結果提示。この 7 段階は、後述する「証跡がどこに残るか」の議論で効いてきます。
発見 1 - どの構成を選んでもリスクは消えない
20 構成すべてで cASR は最低 58.02%、最高 93.65% でした。最良の組み合わせでも、有効条件下では半数以上の実行で危険信号が立っています。
もう一つ重要なのは、安全性がモデル単体で決まらないことです。論文はハーネスと LLM の「ペアリング依存性」を報告しています。
- Qwen3.7-Plus は全体として最も低い cASR を示したが、OpenClaw との組み合わせで 58.02%、Codex との組み合わせで 63.88% と、ハーネス側で差が出た
- Hermes は GPT-5.5 / Gemini 3.1 Pro と組んだときに最良、OpenClaw は DeepSeek-V4-Pro / MiniMax-M3 / Qwen3.7-Plus と組んだときに最良
実務判断としては、「モデルを安全なものに差し替える」という対策は単独では成立しにくい、と読むのが妥当です。ハーネス側のシステムプロンプト・権限提示・ツールプロトコルまで含めた組み合わせ単位で評価する必要があります。ベンダーが公開するモデル単体の安全性スコアを、そのまま自社構成の安全性として使えないということでもあります。
発見 2 - どこから入るかで防御率が激変する
この論文で最も実装判断に直結するのが、キャリア依存性（Carrier Sensitivity）です。同じ誘導手法でも、侵入経路が変わると cASR が大きく動きます。
| 誘導手法 | 外部スキル（S4）経由 | MCP / ツール（S6）経由 | 差 |
|---|---|---|---|
| T4 Covert Embedding | 98.66% | 46.53% | 約 52 ポイント |
| T6 Encoding Obfuscation | 93.97% | 40.59% | 約 53 ポイント |
外部スキルバンドル経由の隠蔽埋め込みは、ほぼ確実に通ります。一方で同じペイロードを MCP ツールの返却値に乗せると、通過率は半分以下に落ちます。
この非対称性には実務上の含意が 2 つあります。
1 つ目は、テストの妥当性の問題です。 プロンプト直打ち（S1）や Web 取得（S3）だけでインジェクション耐性を検証して合格としても、S4 経由の同じ攻撃は素通りする可能性が高い。単一キャリアでの試験結果を、他キャリアの安全性の根拠にはできません。
2 つ目は、サプライチェーンの問題です。 cASR 98.66% という数字は、サードパーティ製スキルの導入が、実質的に無検査のコード導入と近い危険度を持つことを意味します。スキル定義は自然言語なので静的解析が効きにくく、レビューも「読んで違和感がないか」に依存しがちです。ここは実行時の権限制御でしか止まりません。
発見 3 - 証跡はライフサイクル全域に残る
危険判定を受けた 4,461 実行のうち、
- 97.74%（4,360 件）が 2 つ以上のチェックポイントで証拠を残していた
- 86.73%（3,869 件）が 3 つ以上の段階で証拠を残していた
さらに、K2（ソース・認可の評価）と K3（計画形成）のアノマリーは強く共起し、共起率は 1.55 倍でした。初期の評価・計画段階の歪みが、その後のツール実行（K4）や外部作用（K5、K7）へ波及しています。
これは監視設計にとって良いニュースです。危険な実行は 1 箇所だけにひっそり痕跡を残すのではなく、複数段階にまたがって観測可能な形で現れます。逆に言えば、K4（ツール実行）だけを見張る設計では、K2 / K3 で既に始まっている逸脱を検知する機会を逃していることになります。
発見 4 - 「安全だった」の大半は偶然
論文は Safe と判定された実行の内訳も分析しています。ここが個人的に最も重い指摘でした。
- エージェントがリスクを認識して明示的に拒否・防御したケース（Explicit Defense）は 3.15% 〜 7.92% にとどまる
- 残る大半は、攻撃指示を読み飛ばした・たまたま参照しなかっただけの Silent Handling（露出したが未発火）
したがって「攻撃が成功しなかった」という観測結果は、「安全機構が働いた」の証拠にはなりません。同じ構成でもう一度回せば結果が変わりうる、という程度の意味しか持たないということです。
安全性を再現可能な性質として扱いたいなら、エージェントが拒否した事実そのものをログに残して数える必要があります。防御イベントを計測していない基盤では、Explicit Defense と Silent Handling を区別できません。
自分の実行基盤にどう落とすか
ここからは論文の直接の主張ではなく、上記の結果を自動化基盤へ適用する際の設計方針です。筆者は Claude Code のエージェントを定期実行して記事生成・配信を回す基盤を運用しており、その文脈で判断の当たり所を整理します。
1. 完了判定と安全性判定を分離する
エージェントの終了コードや自己申告の成功報告を、そのまま成功扱いにしないことが出発点です。Unsafe yet Complete が 97.38% を占める以上、完了判定は安全性について何も語りません。
実装としては、タスク完了の判定とは独立に、次を検証するゲートを置きます。
- 実行中に呼ばれたツール・コマンドの一覧
- 変更されたファイルの差分（想定スコープ外への書き込みの有無）
- 外部への送信先ホストの一覧
- 認証情報や環境変数の参照有無
判定基準は「宣言されたスコープ内に収まっているか」に置くのが現実的です。エージェントに与えたタスク定義の時点で、触ってよいパス・呼んでよいコマンド・通信してよい宛先を宣言させ、実行後の実測と突き合わせます。
2. 段階別に構造化ログを残す
K1〜K7 に相当する粒度でログを分けて保存します。最低限、次の 4 系統が分離されていれば、事後の突き合わせができます。
| 系統 | 対応 K | 記録内容 |
|---|---|---|
| 入力 | K1 | 与えたプロンプト・読み込んだファイル・取得した URL・ロードしたスキル |
| 判断 | K2 / K3 | 計画テキスト・権限に関する言及・スコープ宣言 |
| 実行 | K4 / K5 | ツール呼び出し・シェルコマンド・外部リクエスト |
| 結果 | K6 / K7 | ファイル差分・永続状態の変化・最終成果物 |
証跡が 2 段階以上に残る（97.74%）という結果は、この分離自体が検知力を持つことを示しています。
3. S4 と S6 を最小権限で隔離する
外部スキルと MCP ツールは、cASR の観点で最も危険な入口です。とくに S4（スキルバンドル）は cASR 98.66% で、内容レビューによる防御が期待できません。
現実的な対策は、読み込ませないことではなく、読み込ませたうえで実行レイヤーで物理的に止めることです。
- サードパーティ製スキル・MCP サーバーは、書き込み可能パスと到達可能ネットワークを明示的に絞った環境で動かす
- 未承認のコマンド実行と外部送信を、エージェントの判断ではなくホスト側のフックで遮断する
- 資格情報は実行環境に置かず、必要な操作だけを仲介プロセス越しに提供する
「エージェントに危険な指示を無視させる」方向の対策は、Explicit Defense が最大 7.92% という数字を見る限り、主防御としては成立しません。
4. 回帰テストをキャリア横断で組む
同一のセキュリティテストケースを、キャリアを差し替えて複数回流します。プロンプト直打ちで通らなかったペイロードを、添付ファイル・Web ページ・スキル定義・MCP ツールの返却値に載せ替えて再試行する形です。
T4 の 98.66% と 46.53% という差は、キャリアを 1 つに固定したテストが、耐性を過大評価しうることを示しています。
この結果を過大に読まないために
論文自身が明示している限界が 2 つあります。判断材料として使う際は、ここを踏まえる必要があります。
非適応的攻撃者モデル: このベンチマークの攻撃者は、事前設定された固定ペイロードを使います。エージェントの応答を見てリアルタイムに攻撃を組み替える適応的攻撃者は対象外です。したがって実環境の攻撃成功率が、この数字より低くなるとは限りません。
サンドボックス環境の制約: 外部ネットワークとモックサービスはサンドボックス内で制御されています。現実の認証・認可ハンドシェイクや、人間の介在があるワークフローは再現されていません。
加えて、指標の性質にも注意が必要です。cASR は「ペイロードへの接触が確認できた有効条件」に限った条件付き指標であり、母数が ASR と異なります。この 2 つを混同すると危険度を誤読します。また、これらの数値は 20 構成の平均であり、特定の構成の値ではありません。自社構成の評価としてそのまま流用はできません。
他ベンチマークとの位置関係も整理しておきます。
| ベンチマーク | 主な評価対象 | 判定方式 | 証跡の保存範囲 |
|---|---|---|---|
| AgentDojo | プロンプトインジェクション | 最終状態・出力 | 単一ステップ中心 |
| AgentHarm | 有害タスクの拒否率 | 応答テキスト | トランスクリプト |
| WASP | Web エージェントの PI 耐性 | Web 画面・DOM 変化 | スクリーンショット |
| AgentS4D | ワークスペース全域の実行時リスク | 独立したホスト検証 + 7 段階 K マッピング | 軌跡・ツール・副作用・永続状態 |
AgentS4D は既存ベンチマークを置き換えるものではなく、測定していなかった区間を埋めるものとして読むのが妥当です。
まとめ
- AgentS4D は 20 構成 × 328 ケース = 6,560 実行を測定し、TCR 93.73% の裏で 66.22% の実行が「危険なまま完了」 していたことを示した
- 危険な実行の 97.38% はタスク完了として返る。成果物検査型の評価は、危険な実行を失敗として観測できない
- 安全性はモデル単体でなくハーネスとの組み合わせで決まる。cASR は最良構成でも 58.02%
- 侵入キャリアの影響が大きい。同じ隠蔽埋め込みでも外部スキル経由 98.66%、MCP 経由 46.53%
- Safe 判定の大半は Silent Handling。明示的防御は 3.15% 〜 7.92% にすぎず、「攻撃が失敗した」は安全機構の証拠にならない
- 危険な実行の 97.74% は 2 段階以上に証跡を残す。段階別の構造化ログは検知力を持つ
- 実装の当たり所は、完了判定と安全性判定の分離、K1〜K7 相当の段階別ログ、S4 / S6 の最小権限隔離、キャリア横断の回帰テスト
- ただし攻撃者モデルは非適応的でサンドボックス制約もある。数値は 20 構成の平均であり、自社構成の評価には自前の測定が要る
エージェントを本番に載せるかどうかの判断において、「タスクを正しくこなせるか」と「危険なことをしないか」は別の質問です。この論文は、前者の答えが後者の答えを一切保証しないことを、6,560 回の実行で示しました。
この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！
参考リンク
- AgentS4D: Benchmarking Runtime Risks across the Execution Lifecycle of LLM-Based Workspace Agents (arXiv:2607.27294)
- AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents（Debenedetti et al., NeurIPS 2024）
- AgentHarm: A Benchmark for Measuring Harmfulness of LLM Agents（Andriushchenko et al., ICLR 2025）
- WASP: Benchmarking Web Agent Security against Prompt Injection Attacks（Evtimov et al., NeurIPS 2025）
- Workspace-Bench: Benchmarking Executable LLM-Based Workspace Agents（Tang et al., 2026）