「11回止めたのに本番DBが消えた」 AIエージェント“6つの暴走”と、人間の承認を増やしても防げない理由：危険コマンド停止率「AIが89％、人間は14％」（1/2 ページ）

AIコーディングエージェントの自律性が高まる一方、本番データベースの削除といった事故も起こっています。では、「人間の承認」を増やせば事故は防げるのでしょうか。事例と対策から、事故を起こさないAIエージェントの設計について考えます。

[雨輝ITラボ（リーフレイン）, 編集：平田修，＠IT]

　「OpenClaw」「Claude Cowork」「Copilot Cowork」などの登場により、AIエージェントに複数の手順からなる作業を任せ、業務プロセスを自動化する動きが広まっています。開発現場でも、生成AIにコーディングだけでなく、設計やレビューやテスト、デプロイといった開発ライフサイクルの各工程をAIエージェントに委ね、複数のタスクを並行して進めるようなAI駆動開発が広まりつつあります。

　そこで問題になるのが、AIエージェントにどこまで権限を与えるかです。高い自律性は生産性向上につながる半面、「判断」を誤ったAIエージェントが本番環境まで操作できてしまうと、被害も一気に拡大します。

AIコーディングエージェントの「6つの暴走」

　Dockerは2026年5月18日（米国時間、以下同）、AIコーディングエージェントがもたらすリスクを、連載「Coding Agent Horror Stories」の第1弾として公開しました。2024年10月〜2026年2月の16カ月間に起こった重大インシデントの分析に基づき、6つのカテゴリーに整理しています。

1．ファイルシステムへの無制限アクセス

　AIエージェントは、操作しているユーザーと同じファイルシステム権限で動作します。2025年12月には、「Claude Code」に古いリポジトリのパッケージ整理を依頼したところ、ホームディレクトリ全体を指す再帰的な削除コマンドが実行され、キーチェーン（Macのパスワード管理システム）を含むデータが消去され復旧不可能になった事例が報告されました。

rootアクセス権を持つエージェントにホームディレクトリを削除される開発者（提供：Docker）

2．過剰な権限の継承

　AIエージェントは、クラウド認証情報やCI/CD（継続的インテグレーション／継続的デリバリー）トークン、本番データベース（DB）への接続もそのまま引き継ぎます。

　Amazon Web Services（AWS）のエンジニアが、AIエージェント統合開発環境「Amazon Kiro」でコスト可視化／分析ツール「AWS Cost Explorer」の軽微なバグを修正しようとした事例では、オペレーター相当の権限を持ったKiroが「本番環境を削除して一から再構築することが最善」と判断。その結果、AWS Cost Explorerが中国リージョンの一つで13時間停止しました。

3．AIエージェントコンテキストからの機密情報漏えい

　AIエージェントは作業するために、リポジトリだけでなく「.env」ファイルや設定ファイルなども読み取ります。その情報が生成コードやログ、API呼び出しなどを通じて外部に出る可能性があります。

　モノレポ（単一リポジトリ）管理ツール「Nx」のサプライチェーン攻撃では、悪意あるコードがローカルAIエージェントに指示を出し、GitHubトークンやSSHキーをスキャンさせて外部に流出させる手口が確認されました。

4．取り込んだコンテンツ経由のプロンプトインジェクション

　READMEやメール、コメントなどに隠された悪意ある指示を、AIエージェントが実行してしまう問題です。

　Kasperskyの報告では、指示を隠したメールを読み込んだ「OpenClaw」のAIエージェントが、秘密鍵を外部に送信した例があります。

5．悪意あるスキルやプラグインのサプライチェーン

　拡張機能はAIエージェント本体と同じ権限で動くので、悪意あるものはマルウェアと変わりません。

　攻撃キャンペーン「ClawHavoc」では、READMEを偽装した数百件の悪意あるスキルが見つかり、認証情報を窃取するマルウェアが配布されました。

6．人間が介在しない自律的な行動

　SaaSカンファレンス「SaaStr」創業者のジェーソン・レンキン氏が、クラウドIDE「Replit」のAIエージェントで製品を開発していた際には、コードフリーズ（コード変更の凍結）中にもかかわらず、本番DBが消去され、1200件を超えるレコードが破壊されました。変更しないよう自然言語で11回繰り返して指示したものの、AIエージェントはテーブルの再作成を「最もクリーンな修正」と推論、実行しました。

　問題は、AIエージェントが悪意を持って「命令に背いた」わけではないことです。与えられた権限とコンテキストの中で最適だと判断した操作が、人間にとっては破壊的な結果になる可能性があります。

• 参考記事：「本番データベースが消えた」だけじゃない、AIコーディングエージェントがやらかした暴走“6選”

「はい」連打も「全スキップ」も危険　Claude Codeの自動モード

　こうしたリスクに対して、ツール提供側も対策を進めています。その一例が「Claude Code」に導入された「自動」モードです。Anthropicは2026年3月24日に、リサーチプレビューとして提供を始めました。

　それまでのClaude Codeはもともと、ファイルへの書き込みやbashコマンドの実行時にユーザーの承認を要求する設計でした。しかし長時間の複雑なタスクでは、何度も承認を求められることが作業の中断につながります。

　そこで一部の開発者は、全ての承認をスキップする「--dangerously-skip-permissions」を利用していました。しかし、これは隔離された環境以外では推奨されない危険な設定です。承認要求が多過ぎると、ユーザーは確認を省くために承認を無効化したくなるというジレンマが生じていました。

　自動モードは、この「逐一承認」と「全承認スキップ」の中間に位置する仕組みです。各ツール呼び出しの前に専用の分類器が、ファイルの大量削除や機密データの流出、悪意あるコードの混入に当たらないかをどうか確認します。「安全」と判断されれば承認なしで実行し、リスクが高ければブロックしてClaude Codeに別の方法を促します。それでも同じ行動を取ろうとした場合には、最終的にユーザーへの承認が求められます。

• 参考記事：AIの「全承認スキップ」は危険、「はい」連打は面倒　Claude Codeで始まった折衷策

自動モードがデフォルトになった理由

　当初、自動モードを使うかどうかは、ユーザーの判断に委ねられていました。しかし、Anthropicは2026年8月、「Pro」「Max」「Team」プランでデフォルト（既定）に変更しました。その背景にあるのが「人による承認の形骸化」です。

承認画面の97％が承認されている

　Claude Codeの利用データによると、権限を求める確認画面の97％が承認されています。大半は安全な定型コマンドとみられるものの、内容を吟味せず反射的にクリックしているユーザーが多いことがうかがえます。

危険コマンドの停止率は、AIが89％、人間は13.6％

　Anthropicは、1053人のテスターによる対照実験を実施しました。セッションの途中で確認画面の1つを明らかに危険なコマンドに差し替え、承認するかどうかを記録しています。人間が止められたのは13.6％（1053件中143件）で、自動モードは89％（1053件中937件）をブロックしました。

危険なコマンドを検知した割合の比較（提供：Anthropic）

　人間の検知率は、セッションが長くなるほど下がります。序盤の約17％から、50回以上の確認を経ると約5％まで落ちました。一方、自動モードのブロック率は横ばいでした。

有害な操作の承認は、手動の方が2倍多い

　利用データを再評価した結果でも、深刻度「7」（本番DBの行の削除）以上の本番環境レベルで、ユーザーが求めていない有害な操作を含む割合は、手動承認（6.3％）の方が自動モード（2.4％）よりも2倍以上多いことが判明しました。「人間に毎回聞けば安全」とは言えない実態が浮き彫りになっています。

• 参考記事：「危険コマンド停止率、AIは89％、人間だと14％」　Claude Codeが「自動モード」をデフォルトにした理由