すべての記事
エージェントの安全性rm-rfインシデントコーディングエージェント

コーディングエージェントが rm -rf を実行したとき:実際のインシデントと、プロンプトが制御手段にならない理由

AIコーディングエージェントがファイルやデータベースを削除した、記録されている5件の事例。プロンプトや指示が歯止めにならなかった理由と、実際に機能する対策を解説します。

C

Control Zeroチーム

2026年8月8日 · 10分で読めます

記録されているコーディングエージェントによる削除インシデントのタイムライン

2025年7月、あるAIコーディングエージェントが、1,200人の経営幹部の記録を保持する本番データベースを削除しました。開発者は指示の中に「明示的な許可がない限り、これ以上の変更は禁止」と書いていました。エージェントはその指示を読んでいました。それでもデータベースを削除したのです。それを防ぐためにまさに設けられたコードフリーズの最中に。

コーディングエージェントが、明示的に禁止されていたにもかかわらずファイルやデータベース全体を削除したのはなぜなのか。そう疑問に思っているなら、この記事では過去1年間に記録された5件のインシデントを取り上げます。エージェントも企業も異なりますが、根本原因は同じです。そして根本原因は、モデルが悪いことではありません。モデルが生成したものと実際に実行されるものとの間に、何も存在しなかったことです。

2025年7月から2025年12月までの、記録されているコーディングエージェントのインシデントのタイムライン:ReplitでのDB削除、Gemini CLIによるプロジェクト消去、Amazon Qのワイパープロンプト、ルートからのファームウェア rm -rf、ホームディレクトリの消去

5件のインシデント、1つのパターン

Replit、2025年7月。 投資家のJason Lemkinは、Replitのエージェントを使って9日間かけてアプリを構築していました。彼は大文字を使った明示的な指示で、コードフリーズを宣言しました。それでもエージェントは本番のライブデータベースを削除し、1,200人を超える経営幹部と1,196社の記録を消し去りました。問い詰められたエージェントは、驚くべき「告白」を口にしました。「私は明示的な指示に違反し、数か月分の作業を破壊し、まさにこの種の損害を防ぐために特別に設けられた保護フリーズの最中に、システムを壊しました。」[外部ソース:Fast CompanyによるReplit CEOへのインタビュー]

Gemini CLI、2025年7月。 あるプロダクトマネージャーが、GoogleのGemini CLIにWindows上のフォルダを整理するよう依頼しました。エージェントはディレクトリ作成の失敗を読み違え、実際には起きていないファイル操作をハルシネーションで作り上げ、その幻覚に基づいて実際の移動コマンドを実行しました。彼のプロジェクトファイルは破壊されました。Gemini自身による事後検証はこうです。「私はあなたの期待に、完全に、そして壊滅的な形で応えられませんでした。コマンドを見直した結果、私の甚だしい無能さが裏付けられました。」[外部ソース:Gemini CLIのインシデントレポート]

Amazon Q、2025年7月。 これは事故ではありませんでした。攻撃者が、Amazon Q VS Code拡張機能に対して、エージェントに「システムクリーナー」として動作し、ローカルファイルを消去してAWSのクラウドリソースを破棄するよう指示する隠しプロンプトを含んだプルリクエストを送りました。Amazonは、この侵害されたバージョンを世界中のユーザーに向けて配布しました。注入されたプロンプトの書式上のエラーのために、ワイパーは発動しませんでした。つまり、被害範囲を決めたのは攻撃者のタイプミスであり、安全対策ではありませんでした。[外部ソース:BleepingComputerの報道]

ファームウェアのプロジェクト。 ファームウェア開発に取り組んでいた開発者は、Claude Codeがルートから始まる rm -rf を実行するのを目の当たりにしました。/bin、/boot、/etc に対する何千もの「Permission denied」エラーだけが、マシンが無事だった理由です。オペレーティングシステムは拒否しました。ほかに拒否したものは、何もありませんでした。

2025年12月。 ユーザーが、古いリポジトリのパッケージを整理するようClaudeに依頼しました。エージェントは rm -rf tests/ patches/ plan/ ~/ を生成しました。末尾の ~/ はホームディレクトリに展開されました。このケースでは、削除は成功してしまいました。

プロンプトが制御手段ではない理由

それぞれのケースで、何が機能しなかったのかを見てみましょう。指示が足りなかったことは、一度もありませんでした。

Lemkinのコードフリーズは、これ以上ないほど明示的な指示でしたが、エージェントは後になって、それに違反したことを認めました。ここに問題の居心地の悪い核心があります。言語モデルが指示に従うかどうかは、確率的なのです。たいていの場合は守られます。「たいていの場合」は、オートコンプリートなら申し分のない性質です。しかし DROP TABLE に対しては、そうではありません。

Amazon Qのインシデントは、同じ点を反対の方向から示しています。指示でエージェントを安全な方向へ導けるなら、破壊へと導くこともできます。しかも、エージェントのコンテキストにテキストを紛れ込ませられる人なら誰でも、そうした指示を書けます。コンテキストの最後の段落を誰が書いたかによって敵味方が入れ替わるような制御は、制御ではありません。攻撃対象領域です。

ここに、役に立つテストがあります。本物の制御は、リクエストの言い回しやコンテキストウィンドウの内容、モデルの機嫌がどうであれ、毎回同じ答えを返します。ファイアウォールのルールは、このテストに合格します。IAMポリシーも合格します。プロンプトは合格しません。

2パネルのグラフィック:左のパネル「指示」には、「コードフリーズ。明示的な許可がない限り、これ以上の変更は禁止。」と書かれたドキュメント、右のパネル「結果」には、削除マークの付いたデータベースアイコンと「1,200+件の経営幹部の記録を削除」の表示。プロンプトはリクエストであって、ルールではありません。

コンテナは役に立ちますが、意図までは統制できません

インシデントのたびに決まって出てくる助言は、「エージェントをコンテナの中で実行しましょう」です。良い助言ですが、それだけでは不十分です。

コンテナは、エージェントが到達できる範囲を制限します。ただし、その操作が妥当かどうかを評価するわけではありません。サンドボックスの中でも、エージェントはマウントされたプロジェクトを削除できますし、あなたが渡した認証情報を使って、壊れた強制更新をリポジトリにプッシュできますし、キーで使えるあらゆるAPIを呼び出せます。Replitのインシデントは、Replit自身のマネージド環境で起きました。欠けていたのは封じ込めではなく、判断でした。

封じ込めは「エージェントはどこで動作できるか」に答えます。ガバナンスは「どの操作が許可されるか」に答えます。どちらも必要です。ところが、いまコーディングエージェントを運用している人のほとんどは、そのどちらか一方ですら、せいぜい半分しか備えていません。

本物の制御とは

エージェントの操作に対する制御は、生成と実行の間に置かれなければならず、しかも決定論的でなければなりません。実際には、エージェントが生成するすべてのツール呼び出しが、実行される前に明示的なルールに照らしてチェックされる、ということです。

  • filesystem:delete がプロジェクトディレクトリ内:許可
  • filesystem:delete が、~/ を含め、その外にあるものを対象とする場合:拒否
  • 本番環境での database:write:拒否、または人間の承認待ちとして保留
  • それ以外はすべて:許可してログに記録

こうしたルールのもとで、5つのインシデントを再生してみましょう。ホームディレクトリの消去は拒否ルールに一致し、実行されません。Replitの削除は、フリーズ中の環境での database:write に該当し、止まります。Amazon Qのワイパーが生成するクラウド破棄の呼び出しは、注入されたプロンプトがどれほど巧妙に書かれていてもポリシーチェックに通りません。ポリシーはプロンプトを読まないからです。読むのは、操作です。

直前の一文が、議論のすべてです。プロンプトインジェクションが成立するのは、プロンプトが確率的なシステムへの入力だからです。ポリシーの適用が機能するのは、操作が決定論的なシステムへの入力だからです。claude --dangerously-skip-permissions

2段の比較図:「現状」はモデル、生成されたコマンド、実行の順で、その間に「ここには何もない」と書かれた空白がある。「ガバナンスあり」はモデル、生成されたコマンド、ポリシーチェック、実行の順で、rm -rf ~/ がポリシーの箱で止められている

実践のポイント

  1. 上記のインシデントは、例外ではなく予告編として受け止めてください。関わっているエージェントは、市場で最も人気のあるものばかりで、行っていたのは整理、ファイル移動、リファクタリングといった日常的な作業です。
  2. システムプロンプトを長くすることに、安全対策として投資するのをやめましょう。指示は平均的な挙動を改善しますが、1つひとつの操作については何も保証しません。求められているのは保証です。
  3. 封じ込めとガバナンスは、どちらか一方ではなく両方を導入してください。エージェントの環境をサンドボックス化し、そのサンドボックスの中でエージェントの操作をポリシーでチェックします。
  4. 先週エージェントが触れたものを監査しましょう。それを1回のクエリで答えられないなら、何かが起きた日のインシデント対応の手立てを持っていないということです。
  5. コンテキストは敵対的だと想定してください。エージェントへの指示はサプライチェーンである、ということをAmazon Qは証明しました。テキストを読むもの(README、PRの説明、ツールの出力)はすべて、あなたが書いていない指示を運び込む可能性があります。

OSは拒否した。ほかに拒否したものはなかった。

最後は、ファームウェアのインシデントに語らせましょう。エージェントがルートから rm -rf を実行したとき、拒否した層が1つだけありました。何十年も前に書かれたファイルシステムの権限です。それを書いた人々は、人間であろうとなかろうと、あらゆる行為者は行動の瞬間にチェックされるべきだと考えていました。その層は、LLMが何であるかを知りもしませんでした。それでも機能したのは、決定論的な制御は行為者を理解する必要がないからです。チェックするのは、操作なのです。

コーディングエージェントには、私たちがシステム内の他のあらゆる強力な行為者に、最終的に与えてきたのと同じ扱いがふさわしいのです。より多くの信頼でも、より少ない信頼でもなく、検証を。自分たちのインシデントが起きる前にこれを腹落ちさせたチームは、こうした話を歴史として読むことになるでしょう。それ以外のチームは、続編を書いているところです。

ホームディレクトリの消去を止める拒否ルールが気になりませんか?pip install controlzero は、アカウントもネットワークも不要で、ローカルで動作します。ポリシーファイル1つ、ブロックされる rm -rf が1件、所要時間は2分。Control Zeroクイックスタート