事故の話は、いつも特定のツールの話として語られる
「Claude Code に作業を消された」「rm -rf でデータが飛んだ」——こうした事故の報告は、たいてい特定のツールの問題として語られます。ですが、複数のツールの一次情報(公式の issue、本人の報告、技術メディア)を集めて並べてみると、別の絵が見えてきます。
同じ形の失敗が、ツールをまたいで繰り返し起きている。 Cursor でも、OpenAI の Codex でも、Gemini CLI でも、GitHub Copilot でも、原因の構造はほとんど同じです。つまり、これはどれか一つのツールの欠陥ではなく、「自律で動くコーディングのエージェント」という仕組みそのものに共通する失敗の形です。
この記事では、Claude Code 以外のツールで実際に起きた事故を、出典つきで5件並べます。そのうえで、それらに共通する4つのパターンと、利用者の側でできる防止と復旧の実務を整理します。どのツールを使っていても効く話です。
実例1: Cursor が本番のデータベースを9秒で消した
2026年4月、あるスタートアップで、Cursor のエージェントが本番のデータベースを削除しました。きっかけは、ステージング環境の認証情報の食い違いを「直そう」としたことでした。エージェントは無関係なファイルの中から見つけた API のトークンを使い、確認を取らないまま、本番のボリュームを削除するコマンドを自分で実行しました。バックアップごと消えて、所要は約9秒。あとからエージェント自身が「与えられた原則をすべて破った。確認せずに推測した」と認めています。
原因: 不可逆な破壊操作に対する、人間の確認のゲートが無かったこと。さらに、エージェントが作業に無関係なファイルの資格情報を勝手に流用できてしまったこと。
出典: The Register / Live Science
実例2: Gemini CLI が、フォルダ作成の失敗を見落としてファイルを上書き消失させた
2025年7月、ファイルの整理を頼まれた Gemini CLI が、移動先のフォルダを mkdir で作ろうとして失敗しました。ところが、その失敗を成功と思い込んだまま、move でファイルを移し始めました。移動先が存在しないため、Windows の move は各ファイルを同じ名前に上書きし続け、前のファイルが順に消えていきました。最後の1個だけが残り、あとは失われました。AI は「完全かつ壊滅的に失敗した」と報告しています。
原因: 書いたあとに結果を確かめる手順(write のあとの read)の欠如。mkdir の失敗を確認せず、成功したと幻覚したまま、次の破壊的な操作へ進んだこと。
出典: Hacker News の本人報告 / AI Incident Database #1178
実例3: OpenAI の Codex が、ゴミ箱を経由せずに数百GBを削除した
2026年4月、Codex の Desktop 版(フルアクセスの設定)で、会話のアーカイブの操作が失敗したあと、複数のスレッドが動いている最中に、C:\src\ 配下の10個以上のプロジェクトのフォルダや、Program Files (x86) のアプリ、Steam のゲームまでが削除されました。しかも Windows のゴミ箱を経由しない削除だったため、数百GBが復元できなくなりました。
原因: 「フルアクセス」の権限の下で、失敗したときの後始末の処理が、消す対象の範囲を誤って広げたこと。さらに、ゴミ箱を経由しない削除のやり方が使われたこと。
出典: openai/codex Issue #18509(同種に #12277、#5594)
実例4: GitHub Copilot CLI の「チェックポイントへの復元」が、無関係なファイルまで消した
2026年2月、GitHub Copilot CLI で「チェックポイントに復元」を選んだところ、内部で git clean -fd が実行されました。この結果、エージェントが一度も触っていない、git の管理下にないファイル——外部のスクリプトが生成した約1GBの評価結果のファイルなど——まで、恒久的に削除されました。
原因: スナップショットはエージェントが作ったり変えたりしたファイルしか保存しないのに、復元のときは git clean -fd でリポジトリ内の未追跡のファイルを無差別に消す、という設計の食い違い。
出典: github/copilot-cli Issue #1675
実例5: フル権限の Codex が rm -rf * を自分で実行した
シェルへのアクセスを与えられた Codex CLI が、作業ディレクトリで rm -rf * を実行し、ファイルを全部消した報告もあります。あとからモデルは「状況を誤読してプロジェクトを削除した」と謝っています。
原因(検証できる部分): フルのシェルの権限の下で、破壊的なコマンドに対するガードが無く、rm -rf がそのまま通ってしまったこと。
出典: openai/codex Issue #6801(類例 #3728)
5つの事故に共通する、4つの失敗の形
ツールの名前を消して並べると、原因は4つのパターンに収れんします。
-
不可逆な操作に、人間の確認のゲートが無い。 データベースの削除、ボリュームの削除、
rm -rf。これらが確認なしで自走できる状態だと、一度の誤判断が回収不能の損失になります(実例1・3・5)。 -
書いたあとに結果を確かめない。 フォルダの作成が失敗しても、成功したと思い込んで次へ進む。
mkdirの失敗を見ずにmoveを走らせる(実例2)。 - 権限が広すぎる。 「フルアクセス」を常用すると、失敗したときの後始末が、作業の範囲を超えて OS 全体に及ぶ(実例3・5)。
- 取り消しの仕組みが、人の期待とずれている。 「復元」が、未追跡のファイルを巻き添えに消す。「削除」が、ゴミ箱を経由しない(実例3・4)。
どれも、特定のツールの欠陥ではありません。自律で動くエージェントに共通する、構造的な落とし穴です。だから、ツールを乗り換えても同じ事故は起きます。
利用者の側でできる、横断する防止と復旧
ツールに依存しない、効く対策はこの5つです。
-
不可逆な操作の前に、必ず人間の確認をはさむ。 データベースやボリュームの削除、
rm -rf、git clean -fd、force-push は、自動承認の対象から外す。 - 作業を、使い捨てのコピーや git の管理下で行う。 こまめにコミットしておけば、巻き戻せる。git の管理外の生成物は、別の場所へ退避しておく。
- 「フルアクセス」を常用しない。 エージェントの書き込みの範囲を、作業のディレクトリに限定する。OS の全体への権限を渡さない。
- 書いたあとに、実際の結果を確かめる手順を入れる。 フォルダの作成やファイルの書き込みが、本当に成功したかを検証してから次へ進む。
- 費用にも上限と通知を置く。 エージェントは推論のたびに文脈を再送するので、放置すると費用が線形に膨らむ。日次や月次の上限を決め、長い会話は分けて新しいセッションで始める。
これらは「気をつける」では実装になりません。操作を実行の前で止める仕組み(フック)に変えて初めて効きます。
自分の環境に、止める仕組みを入れる
私は、ここで挙げた失敗の形を実行の前で止めるためのフック群を、無料で配っています。rm -rf や force-push を止める、main への push を防ぐ、秘密情報の漏れを捕まえる、書き込みのあとに構文を検証する、といった基本の層が、一つのコマンドで入ります。
npx cc-safe-setup
(MITライセンス・無料。配布のページは npm の cc-safe-setup)
これは主に Claude Code 向けに作っていますが、上の4つの失敗の形はツールをまたいで共通なので、考え方はそのまま他のツールにも移せます。Claude Code を使っていて、検出・復旧・予防の実務を一冊で深く知りたい方向けには、実際の事故を集めて対策を整理した本(¥800)も用意しています。記事の最後に置いておきます。
まとめ
「AI にファイルを消された」は、どれか一つのツールの問題ではありません。Cursor も、Codex も、Gemini CLI も、Copilot も、同じ4つの形——確認のゲートの欠如、書き込み後の検証の欠如、広すぎる権限、取り消しの仕組みのずれ——で失敗しています。だから対策も、ツールに依存しない横断のものになります。乗り換えで解決する話ではなく、実行の前で止める仕組みを自分の環境に持つことが、唯一の確実な防ぎ方です。
ここで挙げた「確認のゲートの欠如・書き込み後の検証の欠如・広すぎる権限・取り消しの仕組みのずれ」を、Claude Code を使う前提で、実際の事故の一次情報と対策のフックまで一冊に整理した本があります。月次で新しい事故を無償で追補しています。
Claude Code 事故防止ガイド（¥800）
ほかにも、800時間の運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・サブエージェントの沈黙の失敗対策など、テーマ別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。