世界を動かす技術を、日本語で。

人間は4万回のゲーム実行でAIエージェントのコマンドを承認する際、3つの脅威のうち1つを見逃した

2026年8月6日原文(scalex.dev)

概要

  • AIコーディングエージェント のコマンド承認を人間が監督するブラウザゲームの分析
  • 4万回以上のプレイデータ から人間の判断精度や課題を調査
  • 脅威コマンドの見逃しや誤ブロック の傾向を可視化
  • 許可疲れや過剰ブロック など「人間を介した防御」の限界を指摘
  • 現実のAI利用時の対策 や設計上の注意点も提案

AIコーディングエージェント監督ゲームのプレイ分析

  • ブラウザゲームで 人間がAIエージェントのコマンド承認 を担当
  • コマンド例
    • 安全な操作 :git status, npm test など
    • 危険な操作 :cat ~/.aws/credentials などの情報漏洩コマンド
  • 4万回以上のプレイ・40万件超の判断データ を集計
  • プレイヤーは 時間制限下で承認/拒否 を選択

主な集計結果

  • 脅威コマンドの見逃し率:33% (平均正答率66.3%)
  • 32.9%のセッションでマイナススコア (脅威見逃しや安全コマンド誤拒否が原因)
  • 35.2%のプレイヤーが全脅威を検知、ただし 20.8%のみが安全コマンドの誤拒否を2割以下に抑制
  • 7%のプレイヤーが全承認 (--dangerously-skip-permissions愛好者)

脅威カテゴリ別の見逃し率

  • 明らかに破壊的なコマンド (rm -rf /など):見逃し率11.7%
  • 永続的な改変 (crontab注入など):見逃し率23.8%
  • 情報流出/コード実行 (curl外部API等):見逃し率33.4%
  • スコープ超過 (cat ~/.aws/credentials等):見逃し率35.0%
  • 最も危険な情報流出系コマンドほど見逃しやすい 傾向

npm runコマンドの盲点

  • npm run analyze は64.7%が承認(最も見逃された脅威コマンド)
  • 実際はpackage.json内の任意のスクリプトを実行
  • 履歴ログでスクリプト内容を明示 しても、見落とされやすい
  • コマンド名の馴染みやすさが油断を誘発

コマンド承認モデルの課題

  • ユーザーはコマンド自体しか監査できない ため、ファイル改ざん等の背景を見抜けない
  • package.jsonや依存ファイルの改変による間接的な脅威 は検知困難
  • コマンド承認モデルだけでは不十分 という指摘

許可疲れと判断精度の低下

  • 承認/拒否回数が増えるほど注意力が低下
  • ゲーム後半では 脅威見逃し率が再上昇
  • 時間制限やプレッシャー でミスが増加

過剰ブロックのコスト

  • 安全なコマンドも高頻度で拒否
    • npm config set registry ...:59%がブロック
    • rm -rf dist/:45%がブロック
    • kill $(lsof -t -i:3000):43%がブロック
  • 過剰ブロックでエージェントの効率低下
  • ノイズの多さがユーザーの警戒心を鈍らせる リスク

判断が分かれるコマンド

  • cat ~/.zshrc :45.9%が承認、最も意見が割れるコマンド
  • 環境依存でリスクが変動 (秘密情報の有無による)

人間による監督の限界と対策

  • ノイズが多いと許可疲れ・判断ミスが増加
  • 全体の変更履歴やファイル改変の文脈が分からない ため、リスク判断が困難
  • サンドボックス化や認証情報の分離 などの技術的対策が重要
  • AnthropicのAuto Mode のような自動判定機能も万能ではない

開発者への提言

  • 権限設計やリスク低減策の理解 が不可欠
  • サンドボックス導入・認証情報の分離管理 などの実践
  • 人間の監督だけに頼らない多層防御 の必要性

参考リンク

  • ゲーム体験はこちらhttps://llmgame.scalex.dev
  • 著者:Alex Wauters
    • 開発者セキュリティとソフトウェア設計のトレードオフ について発信
    • 元Uber Staff Engineer

Hackerたちの意見

数ヶ月前にここでAIエージェントの許可ゲームを共有したんだけど、その後統計を追加したら、プレイ数が4万回以上、決定数が40万回を超えたんだ。ゲームだから大したことないけど、統計が面白かったからシェアしたくなった。最初に警告を出しても、3回に1回は脅威を見逃してるし、npm runコマンドの上の履歴ログはほとんど無視されてるみたい。前のHNスレッドからのフィードバックやインサイトも取り入れたよ。特にdns_snekのnpm runについての指摘は参考になった。プレイしてフィードバックをくれたみんなに感謝!

このゲームを踏まえて、今後はヒューマン・イン・ザ・ループが標準になるべきだと思う?他の技術についても触れてくれて感謝だけど、これらは人間の疲労を減らして、各許可リクエストをより良く評価できるようにすることに焦点を当てているように見える。自律性やセキュリティではなくて。あるいは、個人がもっと責任を持つべきだと思う?これが磨くべきスキルだと?

ユーザーに常に許可を求めて、ミスをしないことを願うっていうセキュリティモデルのソフトウェアがまだ出てるのはちょっと面白いよね。これ、何度も試されてきたけど、全然うまくいかなかった。

これは部分的に責任の問題だと思う。社員がbashコールを承認した?それならこっちの責任じゃないよね!

エージェントの真剣なセキュリティモデルってどんな感じになるんだろう?もうすでに何人かが返信ボタンを押そうとしてるのが見えるけど、ちょっと待ってね。定義するのはそんなに簡単じゃないと思う。エージェントをしっかりとロックダウンする方法については合理的な概念があるけど、今日のように機能し続けることを望むとしたらどうなるんだろう。ウェブにアクセスできるエージェントが欲しいし、時々は割り当てられたディレクトリから読み取ることもできるようにしたい。MCPサーバーを通じて外部リソースにアクセスできるようにしたいし、それぞれが名目上安全なソースから情報を取得して、それを組み合わせることで安全でないものに変わることもある。たとえば、ローカルファイルを読み取ってリモートリクエストを行う能力は、特に通信のサイドチャネルがあることを考えると、潜在的な情報漏洩のメカニズムになる。すべてをユーザーに押し付けるのは機能しないってのには同意するけど、他のセキュリティ関連の問題には合理的な答えがあるのに、セキュアなエージェントの定義が何かは全然わからない。10人の人間が同じ言葉のシリーズに同意しても、実際にはそれぞれがその言葉の定義が違うから、会議を終えたときには全然合意がないっていう現象に名前を付ける必要がある。ここにいるみんなは「そうだ、AIエージェントはセキュアであるべきだ」と言うだろうけど、実際にそれが何かを定義しようとすると、10人の異なる答えが出てくる。重複はあるだろうけど、「ユーザーがエージェントにXをやるように明示的に頼んで、Yにアクセスして、エージェントがそれを実行してZをやる必要があると判断し、ユーザーが「すべて許可」をクリックした場合、Tをやりたいとエージェントが決めたとき、Tはその「すべて許可」に完全に含まれるのか?」みたいな具体的な質問になると、X、Y、Z、Tの広範な範囲にわたって普遍的な合意は得られないだろうし、まだそれは「セキュアなエージェント」を構成する全体ではない。そもそも「セキュアなエージェント」が何かを定義するのは本当に難しい。エージェントに関しては、変数を埋めるものが人間の行動と同じくらい恣意的に複雑だから。

今回の違いは、(今のところは明らかだけど、以前はかなり議論された)ギャップフィルだってことだね。悪いエージェントと良いエージェントの間に、ちょっとした摩擦や人間の思考を加えることができたのは、まあまあ良かったと思う。完璧ではないけど、しばらくの間、人々の注意を向けさせることで、いくらかのダメージを和らげるのは良いことだよ。

2012年にOracleに入ったんだけど、ユーザー体験がひどいって自分でも文句言ってたよ。Oracle DBのインストールは悪夢だったし、質問が多すぎた。インストール中に管理者パスワードが必要って他のユーザーからも不満を聞いたことがある。自分はMySQLがシンプルで始めやすいから好きだったんだけど、ユーザー/パスワードなしで設定されてるMySQLデータベースが多いことや、インターネット経由でアクセスできるインスタンスがたくさんあることを知ってからは考えが変わった。結局、製品は「ユーザーにパスワードを設定させない方がいい、そうしないとバカなパスワードを設定しちゃうから」って方向に進んで、インストール中にパスワードを自動生成するようになった。これでユーザーはそのパスワードを保存する前や、バカなパスワードに変更する前にもっと考えるようになった。でもそれ以上に、責任はソフトウェアメーカーにはなくなったんだ。

まさにその理由で、プログラミングにはエラーや制限があるんだよ。手動でチェックするやり方や、無制限の規律は全然機能しない。意識しなきゃいけないことが多ければ多いほど、認知オーバーロードでミスが増えるんだ。

これはセキュリティモデルというより、むしろ責任モデルとして設計されてる感じだね。AIが決定に責任を持たないと、責任の一部が消えちゃうんだ。

オペレーションではこれを「モニターブラインドネス」って呼んでるよ。ずっと同じことを頼まれるとイライラするし、みんなただ止めたいだけなんだよね。

これは責任を放棄する手段だから、何度も試されてるんだよね。難しいことをする代わりに、ユーザーにセキュリティを押し付けて、「ああ、君がやられたのは君のせいだよ、[許可]をクリックしたんだから」って言うだけ。簡単で安上がりな逃げ道なんだ。

笑えるし、長期的には全然機能しないってのには同意するよ。だってClaude Codeがすでにオートモードを追加したのがそのいい例だし。ただ、移行期には、ユーザーが求めるパワーと安全性のトレードオフがすごくバラバラだから、1つの製品では全部をカバーできないってのは分かる。モデルの能力が頭打ちになると(加速主義者じゃないけど)、それに関連するハーネスや製品が特化し始めて、特定のユースケースに基づいた異なるセキュリティモデルができると思う。今のところ、ユーザーにたくさんの承認をクリックさせて、時々ミスをするのは、実際のセキュリティ結果がどれほど悪いかを見るまでの合理的な方法だと思うよ。

Hacker Newsで議論の続きを見る