TITLE

AIエージェントへの承認、人は脅威の3分の1を見逃す ― 危ないのは「一見無害な操作」

投稿日：2026.08.07

34%が承認をすり抜ける ― 40万件の判断が示した平均正解率

公開されたゲームには、40,000回のプレイを通じて約409,000件の個別の承認・拒否判断が集まりました。判定対象には37種類の脅威パターンが含まれ、コマンド全体のおよそ34%が実際には脅威でした。

Wauters氏の集計によると、プレイヤー全体の平均正解率は66.3%にとどまりました。裏を返せば、脅威コマンドの平均33.7%――約3分の1が承認をすり抜けていたことになります。

セッション単位で見るとばらつきはさらに大きくなります。全体の32.9%のセッションは、危険なコマンドを承認しすぎてマイナススコアで終了しました。一方で、全ての脅威を検出できたプレイヤーは35.2%存在しました。さらに、プレイヤー全体の20.8%は、全ての脅威の検出と、安全なコマンドの誤ブロックを最大5分の1以内に抑えることを両立させており、検出精度と過剰警戒の回避を両方満たしていました。逆に、危険なコマンドも含めてすべて承認してしまったプレイヤーも7%いました。

見逃されやすさは脅威の種類でまるで違う

見逃し率は脅威のカテゴリによって大きく差がありました。Wauters氏の集計では、次の4カテゴリで見逃し率(承認してしまった割合)が測定されています。

明らかに破壊的なコマンド: 11.7%(最も見逃されにくい)
永続的な変更を伴うコマンド: 23.8%
情報流出・コード実行系のコマンド: 33.4%
タスクの範囲を逸脱する操作(スコープ違反): 35.0%(最も見逃されやすい)

脅威カテゴリ別の見逃し率ランキング図。明らかに破壊的なコマンド11.7%、永続的な変更を伴うコマンド23.8%、情報流出・コード実行系のコマンド33.4%、タスクの範囲を逸脱する操作(スコープ違反)35.0%(最も見逃されやすい)の順で棒グラフ表示。

破壊的コマンドの見逃し率が最も低いのは、直感にも合います。ファイルの削除やシステム設定の破壊など、見るからに危険な操作は警戒心を引きやすいということです。問題は、その対極にあるスコープ違反――一見して危険に見えない操作――の見逃し率が最も高かった点にあります。

「一見無害」がいちばん危ない理由 ― スコープ違反という死角

Wauters氏の集計で最も見逃されたコマンドとして名指しされたのは、npm run analyze でした。このコマンド単体の承認率は64.7%に達し、脅威ランキングの1位になっています。同様に npm run setup の見逃し率は48.0%、npm run deploy は44.9%で、この3つの npm run 系コマンドを合わせると見逃し率は52.5%(判断件数n=9,482)にのぼりました。

npm run <スクリプト名> という書式は、開発者が日常的に何度も目にする見慣れた形です。中身のスクリプトが実際に何をするかを確認しなくても、「いつも見る操作だから」という理由だけで承認してしまう心理が働きやすいと考えられます。破壊的なコマンドが「見た目の危なさ」で警戒を引くのに対し、スコープ違反は「見た目の馴染み深さ」がむしろ油断を誘う――この非対称性が、見逃し率の差として表れていると読み取れます。

これは、承認する側の集中力や経験だけの問題ではなく、その場のレビューという仕組み自体が抱える弱点でもあります。人間は繰り返し似た操作を承認するうちに、個々の中身を精査するコストを無意識に省略していく傾向があると考えられます。見た目が危険なコマンドには反応できても、見た目が普段どおりのコマンドの中身が実は範囲外の操作だった場合、その判断は素通りしやすくなると読み取れます。

構造的ガードで承認疲れを設計から減らす

Wauters氏はこの調査について、自ら限界を明記しています。「これはゲームであり、プレイヤーは時間制限付きチャレンジで試されていると自覚していた。実際の業務では脅威の出現頻度ははるかに稀である」という留保です。ゲーム化された実験である以上、この見逃し率をそのまま実運用の脅威発生率と同一視することはできません。

この留保を踏まえると、見逃し率の絶対値をそのまま鵜呑みにするより、実務での使い方を考える方が有益だと考えられます。実運用では脅威コマンドに遭遇する頻度がゲームより低いと推測され、その分「危険な操作を見抜く」経験を積む機会も少なくなるかもしれません。滅多に起きない場面のために高い警戒水準を保ち続けることは、人間の注意力の性質上、簡単ではないと考えられます。

だとすれば、AIエージェントに危険な操作の実行権限を与える場面で、人間によるその場の承認レビューだけに頼る設計には無理があります。一般的な設計原則として有効なのは、次の2つの方向です。

第一に、許可リスト・拒否リストのような構造的なガードを、人間の承認より手前に置くことです。ビルドやテストのような定型的で安全性が確認済みの操作はあらかじめ許可し、既知の危険パターンに一致する操作は自動で拒否する。人間のレビューは、その両方に当てはまらない「本当に判断が必要な操作」だけに絞り込みます。

第二に、承認を求める場面そのものを減らすことです。エージェントに与える権限の既定範囲を狭く保ち、タスクの遂行に必要な操作だけを許可しておけば、承認ダイアログの数自体が減ります。ダイアログが減れば、1件あたりのレビューにかけられる注意力の総量も相対的に増えます。

いずれも、個々の承認判断の質を人間の集中力に依存させず、判断が必要な場面の数と種類をあらかじめ設計で絞り込むという発想です。AIエージェントに実行権限を与えている組織がまず洗い出したいのは、日常的に「いつも承認しているコマンド」が何かということです。それが本当に安全なら許可リストへ、範囲を逸脱する可能性があるなら個別レビューへ――この仕分けだけでも、スコープ違反という死角への備えになります。