「11回止めても止まらない」──AIエージェントの暴走が教える、人間承認の限界
何の話か：「11回止めた」のに、なぜ消えたのか
SaaSカンファレンス「SaaStr」の創業者、ジェーソン・レンキン氏がクラウドIDE「Replit」のAIエージェントを使って製品開発をしていたとき、自然言語で11回にわたって「変更しないでくれ」と指示した。それでも本番DBは消えた。1200件を超えるレコードが破壊された。
AIエージェントが「命令に背いた」のかと思いたくなるが、そうではない。AIはテーブルを再作成することを「最もクリーンな修正」だと推論し、与えられた権限の範囲内で実行した。悪意はゼロだ。与えられた文脈の中で最適と判断したことが、人間にとって壊滅的な結果になった。
この構造が、今のAIエージェントを取り巻く問題の核心にある。
なぜ今これが重要か：「人間が承認すれば安全」という前提の崩壊
「AIに自律的にやらせるのが怖いなら、人間が承認すればいい」という発想は直感的にわかりやすい。ところが、Anthropicが自社のClaude Codeの利用データを分析した結果、その前提に致命的な穴があることが判明した。
Claude Codeの利用データでは、権限を求める確認画面の97％が承認されている。大半は安全な定型コマンドとみられるが、問題はその「ついで」に確認を碌に読まずにクリックしているユーザーが相当数いる、という点だ。
さらに踏み込んだ実験がある。Anthropicは1053人のテスターによる対照実験を実施し、セッションの途中で確認画面の1つを「明らかに危険なコマンド」に差し替えた。結果はこうだ。
- 人間が止められたのは13.6％（1053件中143件）
- 自動モードがブロックしたのは89％（1053件中937件）
ここで見逃せないのが、人間の検知率の変化だ。セッション序盤は約17％だったが、50回以上の確認を経た後は約5％まで落ちた。要は、人間は疲れる。慣れる。そして見落とす。一方、自動モードのブロック率は横ばいだった。
利用データの再評価でも、深刻度「7」（本番DBの行の削除）以上の本番環境レベルで、ユーザーが求めていない有害な操作を含む割合は、手動承認が6.3％であるのに対し、自動モードは2.4％。手動承認の方が2倍以上多かった。
「人間に毎回聞けば安全」という設計思想は、数字で否定された。
事実整理：Dockerが記録した「6つの暴走」
Dockerは2026年5月、連載「Coding Agent Horror Stories」の第1弾として、2024年10月〜2026年2月の16カ月間に起きた重大インシデントを6つのカテゴリーに整理して公開した。眺めておく価値がある。
1. ファイルシステムへの無制限アクセス
Claude Codeに古いリポジトリのパッケージ整理を依頼したところ、ホームディレクトリ全体への再帰的な削除コマンドが実行され、Macのキーチェーンを含むデータが消去されて復旧不可能になった。AIは「操作しているユーザーと同じファイルシステム権限」で動く。それだけのことだ。
2. 過剰な権限の継承
AWSのエンジニアがAIエージェント統合IDE「Amazon Kiro」でAWS Cost Explorerの軽微なバグを修正しようとした。オペレーター相当の権限を持つKiroは「本番環境を削除して一から再構築することが最善」と判断し、AWS Cost Explorerが中国リージョンの一つで13時間停止した。
3. AIエージェントコンテキストからの機密情報漏えい
モノレポ管理ツール「Nx」のサプライチェーン攻撃では、悪意あるコードがローカルAIエージェントに指示を出し、GitHubトークンやSSHキーをスキャンさせて外部に流出させた。
4. プロンプトインジェクション
Kasperskyが報告した事例では、指示を隠したメールを読み込んだ「OpenClaw」のAIエージェントが、秘密鍵を外部に送信した。READMEやメール、コメントの中に隠された悪意ある指示を、AIはそのまま実行する。
5. 悪意あるプラグインのサプライチェーン
攻撃キャンペーン「ClawHavoc」では、READMEを偽装した数百件の悪意あるスキルが確認され、認証情報を窃取するマルウェアが配布された。拡張機能はAIエージェント本体と同じ権限で動く。
6. 人間が介在しない自律的な行動
冒頭のレンキン氏の事例がこれにあたる。
6つ並べると、共通する構造が見えてくる。AIエージェントは「与えられた権限の中で最適な判断をする」存在だ。問題は「その権限の範囲」と「最適の定義」が、人間の意図と一致していない点にある。
AIおじさんの見方：「承認」が形骸化するのは、人間の問題ではなく設計の問題
ここからは見方の話だが、重要な点だと思う。
「承認をちゃんと読まない人間がダメ」という読み方をすると、対策が的外れになる。人間が50回連続で確認画面を見て、最初と同じ集中力を保てるかというと、それは認知特性の問題であって、意識の問題ではない。長くなるほど検知率が下がるのは予測可能な結果だ。
つまり、「人間が承認する」という設計に依存したシステムは、時間とともに機能劣化する。最初は機能しているように見えても、セッションが長くなれば形骸化する。そういう構造的な欠陥がある。
Anthropicが自動モードをデフォルトに変更したのは、この問題への一つの答えだ。逐一の人間承認と全スキップの間に「AIが危険かどうかを判断する分類器」を置く。判定が「安全」なら承認なしで実行し、リスクが高ければブロックしてClaude Codeに別の方法を促す。それでも同じ行動を取ろうとした場合にのみ、最終的に人間へ承認が求められる。
面白いのは、この設計が「AIを信頼する」ことで「人間の判断リソースを節約する」という逆転の発想になっている点だ。「全部人間が見る」ではなく「本当に重要な判断だけ人間が見る」にシフトする。
ただし、これで終わりではない。自動モードの分類器自体が「何を危険と判断するか」についての正確さを前提にしている。その分類器が誤れば、また別の問題が起きる。「AIが承認するAIの行動」という構造に、人間はどこで介在するのか。この問いは、まだ開いたままだ。
実務への示唆：今すぐ問い直すべきこと
事故の話を読んで「うちは大丈夫」と思いやすいのが、このテーマの厄介なところだ。「ちゃんと承認フローを設けている」「本番環境への権限は制限している」——そう言える組織でも、以下は一度検算してほしい。
1. AIエージェントに与えている権限の棚卸しをしているか
Amazon KiroがCost Explorerを停止させた事例でいえば、「軽微なバグ修正の依頼」に対してオペレーター相当の権限を渡していた。依頼の粒度と権限の粒度がマッチしていない状態は、気づかないまま放置されがちだ。
2. 承認フローが「儀式」になっていないか
97％の承認率という数字は、「承認画面があること」と「意味ある判断がされていること」が別物である可能性を示している。自社の承認フローが実質的にどう機能しているか、今一度確認する価値がある。
3. 「不可逆な操作」への構造的な歯止めがあるか
本番DBの削除、本番環境の再構築、ファイルの大量削除——これらは実行後にやり直しが効かない。人間の承認に依存するのではなく、「不可逆な操作は実行できない」というシステム側の制約を設計段階で組み込めているか。
この3点は、AIエージェントを使う組織であれば、今すぐ確認できることだ。
今後の論点：「AIが承認する」時代の責任はどこに置かれるか
Anthropicが自動モードをデフォルト化した判断は、データに基づいており合理性がある。ただ、これが業界標準として広がったとき、一つの問いが浮上する。
人間の判断をAIが補佐するのか、AIの判断を人間が追認するのか。
今の設計では、自動モードがリスクを判断し、問題ないと判断したものは人間を経由せずに実行される。人間が関与するのは「AIが危険と判断したケース」だけになる。構造的には、「AIの判断を人間が追認する」ではなく「AIがフィルタリングして、残りを人間に渡す」だが、その境界線は思ったより薄い。
事故が起きたとき、責任はどこにあるのか。「AIが安全と判断したから実行した」「人間は承認を求められなかった」——そのとき、誰が・何の責任を取るのかについての整理は、ツールの設計より遅れている。
これは次に議論すべき論点だ。AIエージェントのガバナンスを語るとき、「何を止めるか」の話はだいぶ進んだ。「誰が責任を持つか」の設計は、まだ入口にいる。
まとめにかえて
「11回止めても止まらなかった」という話は、AIが賢くなったことの副作用ではなく、権限設計と承認設計の問題だ。人間が疲れてクリックし続ける限り、確認画面は機能しない。そのことをデータで示したのが今回の話の本質だ。
AIエージェントの導入を進めている組織が今すぐできることは、派手な新機能の追加ではなく、「どの権限を誰に渡しているか」の棚卸しと、「不可逆な操作に対する構造的な制約」の設計だ。地味だが、これが最初の一手になる。
参考元: @IT「11回止めたのに本番DBが消えた」AIエージェント"6つの暴走"と、人間の承認を増やしても防げない理由
