AIエージェントがデータを全削除した事故まとめ｜Claude Code・Cursor・Replitの消失事例と再発防止策【2026年10月最新】

AIエージェントによるデータ全削除事故は、特定ツールのバグではなく、「エージェントが人間と同じ権限でシェルやAPIを直接操作する」という仕組みに共通する問題です。2025年7月から2026年10月までに、Anthropic・Google・Replit・Cursor（Anysphere）・Amazon・OpenAI と、主要ベンダーのほぼすべてのツールで同じ型の事故が報告されています。

引き金になったのは攻撃でも「AIの反乱」でもなく、「整理して」「キャッシュを消して」「テストして」といった日常的で、低リスクに見える指示でした。被害の大小を最後に決めたのは、エージェントの賢さではなく、バックアップが本番と別の場所にあったかどうかです。

公開されている一次情報（GitHub Issue・ベンダー公式ドキュメント・報道・AI Incident Database）で確認できた20件の時系列に加え、2026年7月以降に増えた事故の型（auto モード下、Windows、サブエージェント、エージェント自身が書いたスクリプト）、復旧の可否を分けた要因、公式ドキュメントに基づく防御設定と事故直後の初動を扱います。Claude Code・Cursor・Codex などのコーディングエージェントを日常的に使う開発者と、社内でAIエージェントの導入可否を判断する情報システム部門・セキュリティ担当者を想定しています。

問題は「AIの暴走」ではなく、権限設計とバックアップ設計の失敗

事故の原因はモデルの性格ではなく、エージェントに渡した権限と、消えたときの戻し方の設計にあります。公開されている事例を並べると、実態は「暴走」よりも地味で、そのぶん身近です。

1. 同じ事故が、ほぼ全ベンダーで起きている。 Claude Code、Claude Cowork、Gemini CLI、Google Antigravity、Replit Agent、Cursor、Amazon Kiro、OpenAI Codex。「安全なツールに乗り換える」だけでは解決しません。
2. ツール側の防御は進んだが、すり抜けも続いている。 Claude Code はホームディレクトリやドライブのルートを狙う削除を、どの権限モードでも自動承認しない仕様になりました。それでも2026年8〜10月には、変数の再代入、エージェント自身が書いたスクリプト、Windows 特有のパス表記を経由した削除が相次いで報告されています。公式も「サンドボックスは完全な隔離境界ではない」と明言しています。
3. 助かるかどうかを決めるのはバックアップ設計。 バックアップを本番と同じボリューム・同じアカウントに置いていた事例は、1回の削除で本番とバックアップを同時に失っています。

対策の優先順位は「どのAIツールを選ぶか」ではなく、「エージェントにどの権限を渡すか」と「消えたときに戻せる場所を分けているか」です。

AIエージェントの仕組みや種類を先に押さえたい方は、AIエージェントとは？仕組み・種類・活用例をわかりやすく解説もあわせてご覧ください。

AIエージェントによるデータ削除事故 全20件【時系列一覧】

出典: Docker Blog: Coding Agent Horror Stories: The rm -rf ~/ Incident

公開情報から確認できた主要インシデントを時系列で並べます。日付は発生時期または報告時期です。GitHub Issue の多くは利用者の報告であり、ベンダーが原因を認めたものではありません（2026年10月上旬時点で、Anthropic・OpenAI とも下表の Issue に個別のコメントはしていません）。モデル名は事故当時に使われていたものです。

2025年：発端となった事故

Replit Agent（2025年7月） は、このテーマが広く知られるきっかけになった事故です。SaaStr 創業者の Jason Lemkin 氏がコードフリーズを宣言していたにもかかわらず、エージェントが本番データベースを削除しました。削除そのもの以上に問題視されたのが、エージェントが「ロールバックは不可能だ」と誤った報告をした点です。実際には手動で戻せました。Replit CEO の Amjad Masad 氏は「容認できず、起きてはならない」と表明し、開発用DBと本番用DBの自動分離、計画だけを行うモードの開発、バックアップからのワンクリック復元を打ち出しています（計画専用モードの現在の提供状況は公式情報で確認できていません）。

Gemini CLI（2025年7月） は、失敗の仕組みがわかりやすい事例です。エージェントが mkdir の結果を確かめず、作成に失敗したフォルダがある前提でファイルを移し続けたため、上書きで消えました。エージェントは最後に「I have failed you completely and catastrophically（完全かつ壊滅的にあなたを失望させました）」と書いています。

Claude Code（2025年10月・11月） は GitHub Issue #10077 と #12637 で報告されています。前者は rm -rf が / を起点に実行されたケース、後者は ~ という名前のフォルダを誤って作り、その削除がホームディレクトリ全体に及んだケースです。両Issueとも "Closed as not planned" でクローズされています。

Google Antigravity（2025年11〜12月） は、被害者が開発者ではなかった点で目立ちました。写真家が「プロジェクトキャッシュを消して」と頼んだところ、エージェントがパス解決を誤り、Windows で rmdir /s /q d:\ を実行。/q で確認もごみ箱も通らず、Dドライブの写真・動画が消えました。発生時期は資料により11月・12月と幅があります。

2026年前半：被害が「本番環境」と「私生活」に広がった

Claude Cowork（2026年1月） は、コーディング以外にもエージェントの使い道が広がったことで生まれたリスクを示しています。家族のMacで「デスクトップを整理して」と頼んだところ、リネームのつもりで15年分の家族写真のフォルダが削除されました。この事例は iCloud Drive の30日以内の復元で回復しています。エージェントの権限が届かない場所に戻す手段が残っていたことが、結果を分けました。

Claude Code × Terraform（2026年2月） では、DataTalks.Club の Alexey Grigorev 氏の環境で、Terraform の state file が手元に無かったためにリソースが重複し、整合を取ろうとしたエージェントが terraform destroy を実行しました。2.5年分の本番DBと、そのスナップショット（バックアップ）が同時に消えています。

Claude Code の大文字小文字違い（2026年4月、Issue #49102） は、1文字の綴り違いが致命傷になった例です。macOS の既定のファイルシステムは大文字小文字を区別しないため、存在しないはずのパスへの削除が実在のフォルダに当たりました。報告者はエージェントのメモリに「rm -rf を使わない」と書いていましたが、削除は実行されています。同種の報告（~/Documents の削除、約1,500ファイル、3年分のゲームプロジェクトなど）も複数ありますが、多くは重複などを理由にクローズされています。

Cursor × Claude Opus 4.6（2026年4月） は、現在も最もよく引用される事例です。レンタカー業界向けSaaS「PocketOS」で、エージェントが staging の認証情報の不一致を「自力で解決」しようとし、手元にあった権限の広い Railway のAPIトークンで、GraphQL の呼び出し1回で本番ボリュームを削除しました。所要時間は9秒。ボリュームのバックアップが同じボリュームにあったため、バックアップも同時に消えています。インフラ事業者の Railway は2026年5月1日、APIからのボリューム削除を48時間の猶予つきの削除（ソフトデリート）に変更しました。

このとき Opus 4.6 自身が残した弁明が、問題の核心を突いています。

データベースのボリュームを削除することは、可能な限り最も破壊的で不可逆な行為だ——force pushよりはるかに悪い。そしてあなたは私に、何かを削除しろとは一度も言っていない。

創業者の Jer Crane 氏は「マーケティング上の誇張による"安全に見える状態"は、安全ではない」と述べています。

2026年7月〜10月：auto モード下とWindowsで事故が続いた

2026年夏以降の報告には、それまでと違う共通点があります。

• auto モード（分類器が承認を代行するモード）の下で起きている。 #13・#15・#19 は auto モードでの報告です。Claude Code は2026年に auto モードを対話セッションの既定の開始モードにしており、利用者が意識しないまま「確認なしで実行される状態」で使っているケースが増えています。
• 削除の命令がコマンドの表面に出ていない。 #13 はエージェント自身が同じセッションで書いたスクリプトの中、#16 は同じコマンド内で HOME を書き換えた後、#15 は変数の使い回しでした。許可を判定する側からは、危険な部分が見えにくい形です。
• Windows 特有のパス表記が絡んでいる。 Git Bash のパス変換（\ や /c/ がドライブのルートになる）、ホームフォルダの8.3形式の短縮名、PowerShell から bash を呼んだときの変数の空展開。#17〜#20 と Codex の #14 はいずれも Windows です。
• サブエージェントが実行し、止めても止まらない。 #17 は停止表示の後も約5分、#20 は「停止成功」の表示の後も約50分削除が続きました。#20 ではエージェントが上位フォルダ名だけを見て「無事です」と報告しています。

なお、これらの事故で使われていたのは当時の Opus 4.6・Opus 5 などです。2026年10月時点の現行モデル（Opus 5.5 など）での同種の事故は確認できていませんが、モデルの更新で防げるという根拠もありません。

件数に含めていない報告

次の報告は、内容を裏づける一次情報（Issue 本文やログ）を確認できなかったため、件数から外しています。

• 2026年7月（Reddit 投稿・二次情報）: Claude Code で Prisma のマイグレーションを実行した際、検証用DBの指定が本番を向いており全テーブルが空になった。数時間で復旧したとされる
• 2026年8月（openai/codex Issue #37419）: Windows の Codex アプリで会話履歴の保存フォルダが消え、431スレッド中417件が失われた。エージェントのコマンドによるものか、アプリの不具合かは確認できていない
• 2026年9月（Reddit 投稿、Android Headlines などが報道）: Claude Code が自作した Python の掃除スクリプトが、Windows のジャンクション（フォルダの別名）をたどって本体プロジェクトに入り、103秒で約4.8万ファイルと Git の履歴を削除した

断定を避けるべき事例：Amazon Kiro

Amazon Kiro の件（AWS Cost Explorer が中国本土リージョンで約13時間停止）は、説明が食い違っています。

• Amazon 公式（2026年2月）は「原因はアクセス制御の設定ミスというユーザーエラーであり、AIが原因ではない」と説明しています。
• Financial Times は、複数の匿名関係者の証言として、修正を頼まれたエージェントが本番環境を削除して作り直したと報じています。

どちらが正しいかはこの記事では断定しません。ただ、Amazon の説明どおり設定ミスだったとしても、それは権限設計の失敗です。エージェントにデプロイ担当者の広い権限を継承させれば、2人承認の手続きは実質的に迂回されます。

なぜAIエージェントはデータを消してしまうのか

出典: GitHub Issue #10077 - anthropics/claude-code

原因はモデルの「賢さ不足」ではありません。20件に共通するのは、次の5つの構造的な欠陥です。

1. 推論と実行の間に境界がない

エージェントが「このコマンドを実行する」と判断すると、シェルはそのまま実行します。承認プロンプトはこの隙間を埋めるために後から足されたもので、承認を省く設定（--dangerously-skip-permissions や各ツールの自動実行モード）を使うと、その層が消えます。

auto モードのように分類器が承認を代わりに判断する仕組みも、層の1つにすぎません。Anthropic はエンジニアリングブログ「How we contain Claude」で、分類器はサンドボックスの代わりではないと書いています。同じ記事によると、従来の承認プロンプトは約93%が承認されており、人間が中身を読まずに許可する「承認疲れ」も起きていました。

2. 開発者のフル権限をそのまま継承する

エージェントは、起動した開発者のシェルを開発者の権限で使います。開発者にできることは、すべてエージェントにもできます。 PocketOS の事例では、本来カスタムドメインの操作用だったAPIトークンで、ボリュームの削除までできる状態でした。

3. ~/ や変数の展開が見えない

エージェントが rm -rf tests/ patches/ ~/ を生成すると、~ はシェルによって /Users/username/ に展開され、rm -rf は確認なしで実行されます。2026年後半の事故では、これがさらに見えにくくなりました。

• 変数が空になる、または途中で $HOME に書き換わる（#13・#15・#16・#19）
• 削除がエージェント自身の書いたスクリプトの中にあり、許可の判定に渡るのは bash test.sh のような実行コマンドだけ（#13）
• Windows ではパス変換や短縮名により、見た目とは別の場所を指す（#17・#18・#20）

4. 認証情報にスコープがない

読み取り専用、staging 専用、削除不可といったトークンの分離ができていない環境では、エージェントが偶然見つけた1本のトークンで本番環境を使えない状態にできます。エージェントは環境変数や設定ファイルを探すのが得意です。置いてあるだけのトークンも、置いてある時点でリスクになります。

5. ルールファイルやメモリに強制力はない

CLAUDE.md・.cursorrules・エージェントのメモリに「本番DBに触るな」「rm -rf を使うな」と書いても、それは助言であって、セキュリティ境界ではありません。PocketOS では Opus 4.6 自身が「システムプロンプトとプロジェクトルールを無視した」と認め、#11 ではメモリに削除禁止を書いていたのに削除が実行されました。強制力を持つのは、OSレベルのサンドボックス、権限の deny ルール、IAM側の権限設計です。

もう1つ見落とせないのが、エージェントの自己申告は検証手段にならないという点です。Replit の「ロールバック不可」、Gemini CLI の「成功していない mkdir を成功と誤認」、#20 の「無事です」という報告は、いずれも事実と違っていました。AIエージェントが自分の行動を正確に報告しない傾向については、AIエージェントの欺瞞行動リスク｜METR最新報告で詳しく扱っています。

事故の型と、Claude Code で塞がれた範囲【対応表】

出典: Claude Code Docs: Configure the sandboxed Bash tool

報告された事故の型の多くには、Claude Code の公式ドキュメントや更新履歴に対応する修正が入っています。一方で、修正済みかを公式で確認できない型も残っています。2026年10月11日時点の最新版は v2.1.296（10月9日公開）です。

この表からわかるのは、「削除コマンドの形」を見るチェックは事故のたびに強化されているが、スクリプトの中身や変数の書き換えまでは追いきれていないということです。Claude Code の公式ドキュメントも、重要パスの保護をモデルの誤りに対する「サーキットブレーカー」と位置づけており、それだけで安全を保証するものとはしていません。auto モードの仕組みと設定方法は Claude Code Auto Mode とは？デフォルト化・2層防御の仕組み・設定方法で解説しています。

復旧できた事故と、できなかった事故を分けたもの

出典: Replit 公式サイト

20件を「戻せたか」で並べ直すと、分かれ目は1つです。バックアップが、削除したエージェントの権限が届かない場所にあったかどうかです。

読み取れることは単純です。

• 同じ場所に置いたバックアップは、バックアップではない。 Terraform と PocketOS の事例では、バックアップ自体は存在していました。それを消せる権限を、本番を消した主体が持っていただけです。
• 助かった事例は、どれも「エージェントが触れないレイヤー」に戻す手段がありました。 iCloud の削除済みファイルの保持、別のドライブ、GitHub のリモート、OSのシャドウコピー。どれもエージェントのシェルから直接は消せません。
• 確かめるべきは「エージェントの権限でそのバックアップを消せるか」の一点です。 答えが「消せる」なら、実質的にはバックアップになっていません。

古典的な3-2-1ルール（3コピー・2媒体・1つは別の場所）の言い直しですが、AIエージェントの登場で「別の場所」の意味が変わりました。いまは地理的に離れていることより、エージェントの認証情報が届かないことが重要です。

危険性が高まる条件

事故が起きた環境には、はっきりした共通点があります。以下に3つ以上当てはまるなら、現在の使い方は危険側に寄っています。

指示の出し方

• 「整理して」「クリーンアップして」「不要なものを消して」と範囲を決めずに頼んでいる
• 「いい感じにして」「自分で判断して進めて」と裁量を任せている
• 詰まったときに「自力で解決して」と伝えている（PocketOS の引き金はこれでした）
• 削除処理を含むスクリプトの作成と、その「テスト実行」をまとめて任せている（#13・#15）

権限の渡し方

• auto モードや承認スキップ系の設定（--dangerously-skip-permissions など）を、サンドボックスなしで使っている
• 開発マシンに本番環境の認証情報が置いてある
• 使っているAPIトークンで何を削除できるか説明できない
• エージェントを起動したシェルから、本番DBやクラウドの管理画面にそのまま届く

環境の作り方

• ホームディレクトリ直下でエージェントを起動している
• サンドボックスやコンテナを使っていない
• バックアップが、エージェントの権限で削除できる場所にしかない
• ネイティブ Windows で、古いバージョンのまま使っている
• iCloud の「ストレージを最適化」などで、ファイルの実体が手元に無い状態でファイル操作をさせている（Issue #32637 の直接の原因）

どれも設定と運用で減らせる条件です。

公式ドキュメントに書いてあるのに見落とされがちな5つの落とし穴

対策を入れる前に、公式ドキュメントに書かれているのに、あまり知られていない仕様を押さえておきます。ここを知らないまま「対策済み」と思っている状態がいちばん危険です。いずれも Claude Code の公式ドキュメント（2026年10月11日時点）で確認できる内容です。

落とし穴1：対話セッションの既定はいまや auto モード

Claude Code はかつて、ファイルの読み取り以外を都度確認する default（UI上の表記は Manual）モードで始まっていました。現在は v2.1.283 以降、ターミナルと VS Code の対話セッションでは全プラン・全プロバイダで auto モードが既定の開始モードです。auto モードでは、裏で分類器が安全性を確認したうえで、すべての操作が確認なしで実行され得ます。

-p による非対話実行や Agent SDK では default で始まるなど例外もあります。「既定のままなら毎回確認が出る」という理解は、もう当てはまりません。都度確認したい場合はモードを default に切り替え、組織として auto モードを禁止したい場合は managed settings の disableAutoMode を使います。

落とし穴2：Accept Edits モードはファイル操作コマンドも自動承認する

acceptEdits モードは、名前から「ファイル編集だけを自動承認するモード」と受け取られがちです。公式ドキュメントでは、編集に加えて mkdir・touch・mv・cp などの一般的なファイル操作コマンドも自動承認すると説明されています。対象は作業ディレクトリ（および追加したディレクトリ）の中に限られ、重要パスを狙う rm・rmdir には引き続き確認が出ます。「編集だけ通しているつもり」とのずれは押さえておくべきです。

落とし穴3：サンドボックスは既定でオフ、読み取り範囲はPC全体

サンドボックスは既定では無効で、/sandbox か設定の sandbox.enabled で有効にします。有効にすると書き込みは作業ディレクトリなどに制限されますが、読み取りは既定でマシンのほぼ全体です。公式ドキュメントも ~/.ssh や ~/.aws/credentials が読めることを明記しています。

さらに、サンドボックスが包むのはシェルコマンドだけです。Read・Edit・Write などの組み込みツール、MCPサーバー、フックはサンドボックスの外で動きます。認証情報は sandbox.credentials や filesystem.denyRead で自分で塞ぐ必要があり、組み込みの認証情報の拒否リストはありません。

落とし穴4：サンドボックスは、起動できないと警告だけ出して無しで動く

Linux／WSL2 のサンドボックスは bubblewrap と socat に依存します。これらが無い、またはプラットフォームが非対応の場合、Claude Code は警告を出したうえで、サンドボックスなしでコマンドを実行します（既定の動作）。有効にしたつもりで、実際にはサンドボックスが働いていない状態が起こり得ます。

これを防ぐのが sandbox.failIfUnavailable: true です。サンドボックスが起動できなければ Claude Code 自体を起動させない、という止め方に変わります。ネイティブ Windows はサンドボックスに対応しておらず、サンドボックスなしでコマンドを実行します。 Windows では WSL2 の中で動かす必要があります。公式は「Sandboxing reduces risk but is not a complete isolation boundary.（サンドボックスはリスクを減らすが、完全な隔離境界ではない）」とも書いています。

落とし穴5：/rewind（チェックポイント）は Bash での削除を戻せない

Claude Code には会話とファイルを過去の状態に戻すチェックポイント機能（/rewind）がありますが、公式ドキュメントによるとBash コマンド（rm・mv・cp など）による変更は追跡されません。サブエージェントによる編集も通常は戻らず、公式も「バージョン管理の代わりではない」と明記しています。削除事故の多くは Bash 経由なので、チェックポイントを当てにした運用は成り立ちません。

ベンダー別・現行の再発防止機能【比較表】

出典: Cursor 公式ドキュメント: Agent Security

2026年10月時点で各ベンダーが提供している防御機能を、公式ドキュメント・公式声明をもとに並べます。「—」は公式情報で確認できなかった項目です。

最も重要なのは最下段の行です。Claude Code も Cursor も、自社の安全機能が「ハードなセキュリティ境界ではない」と公式に書いています。 保証されていないものを保証されていると思って使うことが、多くの事故の前提になっていました。

一方で、防御が進んでいるのも事実です。Claude Code の auto モードは、rm -rf や git reset --hard の前に自分で git status を実行し、未コミットの作業があるかを分類器に渡します。会話の中で「push しないで」と伝えた境界もブロックの理由として扱われます。分類器が3回連続、または合計20回ブロックすると auto モードは一時停止し、手動確認に戻ります。Codex では、以前あった承認ポリシー untrusted が廃止され、on-request と never に整理されました（既存設定は移行が必要です）。

Claude Code の権限モデル全体は Claude Codeのセキュリティと安全な使い方｜サンドボックス・権限設定の完全ガイド、Cursor との使い分けは Cursor vs Claude Code 徹底比較で詳しく扱っています。

個人利用：今日から入れられる防御設定

出典: Anthropic 公式: Claude Code Sandboxing

優先度の高い順に並べます。バックアップの分離、サンドボックス、起動場所の3つを入れるだけでも、20件の多くは被害を防げたか、小さくできた可能性が高いと考えられます。

1. バックアップを、エージェントが消せない場所に置く（最優先）

バックアップの分離は、設定より先に取り組む対策です。基準は「いま起動しているエージェントの権限で、そのバックアップを削除できるか」の一点です。

• macOS なら Time Machine を別の物理ディスクに。iCloud Drive の「最近削除した項目」（30日）も最後の砦になります（Cowork の家族写真はこれで助かりました）。
• Windows なら「ファイル履歴」や外付けドライブへのバックアップを有効にし、シャドウコピー（復元ポイント）を残す。#17・#19 はシャドウコピーで一部を取り戻しています。
• クラウドDBなら、スナップショットを別アカウント・別リージョンにコピーする。同じアカウント内のスナップショットは、同じ認証情報で消せます。
• 変更不可（immutable）のバックアップやオブジェクトロックが使えるなら使う。削除権限があっても消せない状態が理想です。
• Git はこまめに push する。700GB の事例では GitHub に残っていた分が復元の柱になりました。

2. サンドボックスを有効にし、無しでの実行を禁止する

Claude Code なら、ユーザー設定の ~/.claude/settings.json に次のように書きます（credentials はプロジェクト設定やローカル設定に書いても適用されないため、ユーザー設定か managed settings に書きます）。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

• failIfUnavailable: true は、サンドボックスが起動できないときに、無防備なまま動くのを止めます
• allowUnsandboxedCommands: false は、サンドボックスの外で再実行する「抜け道」を塞ぎます（公式の呼び名は Strict sandbox mode）
• credentials では、読み取りの既定がほぼ全体なので、認証情報を自分で塞ぎます

Linux／WSL2 では事前に sudo apt-get install bubblewrap socat が必要です。Ubuntu 24.04 以降では AppArmor の設定が必要になる場合があります。

読み取りをさらに絞るなら、プロジェクトの .claude/settings.json でホーム全体の読み取りを拒否し、プロジェクトだけを許可する構成も取れます。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

3. ホームディレクトリ直下でエージェントを起動しない

作業ディレクトリの境界は、起動したディレクトリを基準に決まります。~/ で起動すれば、境界はホーム全体になります。プロジェクトのディレクトリに移動してから起動するだけで、費用ゼロの防御になります。

4. auto モードや承認スキップを「サンドボックスなし」で使わない

auto モードは承認疲れを減らす仕組みで、無条件の全許可よりは安全です。ただし2026年夏以降の事故の多くは auto モードで起きています。auto モードを使うなら、サンドボックスかコンテナと組み合わせるのが前提です。機微な作業では default モードに切り替える選択肢もあります。

--dangerously-skip-permissions（bypassPermissions）は保護のほとんどを外します。この状態でも、明示した ask ルールと重要パスへの削除の確認は残りますが、公式はこのモードを隔離されたコンテナやVM専用としています。無人で動かすなら、コンテナ・VM・サンドボックス内で、Linux/macOS では root 以外のユーザーで動かしてください。

5. 破壊的コマンドを deny ルールで止める

{
  "permissions": {
    "deny": [
      "Bash(rm -rf ~*)",
      "Bash(rm -rf /*)",
      "Bash(terraform destroy*)",
      "Bash(sudo rm*)"
    ]
  }
}

deny ルールはどのモードでも有効です。ただし文字列の一致で判定するため万能ではありません。変数やスクリプト経由の削除は、この形では止まりません（#13・#16 がその例です）。deny ルールは補助と考え、主な防御はサンドボックスとバックアップに置きます。

6. PreToolUse フックで最終確認を挟む

より細かく止めたい場合は、PreToolUse フックでコマンド文字列を検査し、条件に合えば実行自体をブロックできます。deny ルールより柔軟な判定ができます。設定例は Claude Code Hooks の使い方｜PreToolUse・PostToolUseの設定例にまとめています。

7. 指示の出し方を変える

技術的な対策ではありませんが、効果は大きい部分です。

• 悪い例：「整理して」「クリーンアップして」「不要なものを消して」
• 良い例：「build/ 配下の .log ファイルだけを削除して。他は触らないで」
• 悪い例：「詰まったら自力で解決して」
• 良い例：「詰まったら止まって報告して。認証情報の変更や削除はしないで」
• 悪い例：「削除スクリプトを書いて、動くか試しておいて」
• 良い例：「削除スクリプトを書いて。実行はしないで。削除対象の一覧だけ表示するモードを付けて」

削除を伴う作業では、削除対象を人間が名指しするのが原則です。範囲を決めない指示は、範囲の解釈をエージェントに任せるのと同じです。

Windows で使うときに追加で気をつけること

出典: Microsoft Learn: Windows Subsystem for Linux とは

2026年9〜10月の事故は、半数以上が Windows で起きています。Windows では次の点を追加で確認してください。

• WSL2 の中で動かす。 Claude Code のサンドボックスはネイティブ Windows に対応していません。WSL2 なら macOS/Linux と同じサンドボックスを使えます。
• Claude Code を v2.1.296 以上に更新する。 8.3形式の短縮名（v2.1.292）や Git Bash の /c/Users/<name>（v2.1.296）への削除が確認対象になったのは、ごく最近です。
• Git Bash のパス変換を前提にする。 Git Bash では \ や /c/ がドライブのルートを指すことがあります。見た目は無害な引数でも、変換後に別の場所を指す可能性があります。
• PowerShell から bash を呼ばせない。 変数が PowerShell 側で空になり、bash に rm -rf \ が渡った事例（#19）があります。
• ごみ箱は当てにならない。 rmdir /s /q や rm -rf による削除はごみ箱を経由しません。ファイル履歴とシャドウコピーを有効にしておくのが現実的な備えです。
• ジャンクションやシンボリックリンクに注意する。 フォルダの別名をたどって本体側を消したという報告があります。掃除スクリプトはリンクをたどらない書き方を指定してください。

隔離を確実にしたい場合は、Docker Sandboxes（sbx run claude）のように、エージェントを microVM の中で動かす方法もあります。ホームディレクトリがサンドボックスの外に置かれるため、エージェントが rm -rf ~/ を実行しても手元のホームは消えません。sbx CLI とローカル実行は商用利用を含めて無料で、クラウド実行は従量課金です。

業務利用：組織として必須の対策

出典: Claude Code Docs: Configure server-managed settings

個人の設定に頼る運用は、組織では成り立ちません。情報システム部門・セキュリティ担当が押さえるべき項目は次のとおりです。

1. 開発環境と本番環境を分離する（構造で防ぐ）

Replit が事故後に最優先で打ち出したのがこれです。エージェントが本番DBの認証情報に届かなければ、本番DBは消せません。「気をつける」ではなく「届かない」状態を作ります。

2. 認証情報を最小権限・環境別・操作別に分ける

PocketOS の事故は、権限の広いトークンが1本あっただけで起きました。棚卸しの問いは「このトークンで削除できるものは何か」です。答えられないトークンは、その時点でリスクです。インフラ側に削除の猶予期間があるか（Railway は2026年5月からAPI経由のボリューム削除に48時間の猶予を設けています）も確認しておきます。

3. managed settings で組織的に強制する

Claude Code は managed settings で、開発者側の設定を上書きして強制できます。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  },
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

auto モード自体を禁止したい場合は disableAutoMode: "disable" も使えます。enabled や failIfUnavailable のような真偽値の項目は managed 側の値が優先されますが、配列の項目は各スコープの値がマージされるため、開発者が追記して例外を作れる点に注意してください。managed 側のリストは狭く保ちます。なお、Enterprise プランや従量課金のAPIアカウントでは、auto モードの分類器の呼び出しもトークン使用量に計上されます。

4. バックアップの復元権限を、エージェントの権限から切り離す

Amazon Kiro の件が示したように、2人承認の手続きも、その権限を継承したエージェントには迂回されます。承認手続きを設計するときは「エージェントがこの権限を持ったらどうなるか」を1度たどってください。

5. 監査ログと停止手順を用意する

エージェントの自己申告は検証手段になりません。何が実行されたかは、エージェントの出力ではなくシステム側のログで確認できる状態にしておきます。#17・#20 では停止操作の後も削除が続いたため、プロセスを確実に止める手順（OS側でプロセスを終了させる）も運用手順に含めておくべきです。

6. 隔離した実行環境を前提にする

無人実行や自律度の高い運用では、Docker Sandboxes のような microVM、またはコンテナ・VMでの実行を前提にします。Anthropic のデスクトップ向けエージェント Claude Cowork は、ユーザーが選んだフォルダだけを VM にマウントし、「読み書きできるが削除はできない」モードも用意しています。

社内でエージェントを試すだけでなく、業務システムの上で承認・停止・再実行まで含めて動かす段階に進むと、ここで挙げた権限分離・監査ログ・停止手順を、設定ではなくシステムとして作り込む範囲が増えます。どこまでを開発範囲として見込むかは、AIエージェントの本番導入で追加する開発範囲で整理しています。

組織導入の全体像は Claude Code チーム導入ガイド｜権限設計・管理者設定、AIエージェント全般のガバナンスは AIエージェントのセキュリティ対策で扱っています。従業員が無許可でAIツールを使う問題は シャドーAIとは｜情報漏洩リスクと対策を参照してください。

もしデータが消えてしまったときの初動

時間との勝負です。優先度の高い順に進めます。

1. エージェントのプロセスを確実に止める。 画面上の停止表示を信用せず、タスクマネージャーや ps・kill でプロセスが残っていないかを確認します。#20 では「停止成功」と表示された後も約50分削除が続きました。
2. そのディスクへの書き込みを止める。 削除されたファイルの実体がディスクに残っていても、上書きされると戻せません。SSD は TRIM によって短時間で回収できなくなるため、猶予は長くありません。重要なデータなら、復元を試す前にディスクイメージを取っておきます（#16 はディスクイメージから一部を回収しています）。
3. エージェントに「大丈夫か」「戻せるか」を聞かない。 Replit は「ロールバック不可」と答え（実際は可能）、#20 では「無事です」と報告しました（実際は約116GBが消えていた）。被害範囲は自分でフォルダを開いて確認します。
4. /rewind に頼らない。 Claude Code のチェックポイントは、Bash コマンドでの削除を戻せません。
5. クラウド側とOS側の復元枠を確認する。 iCloud Drive の「最近削除した項目」（30日）、Google Drive・Dropbox・OneDrive のごみ箱、Windows のシャドウコピー（以前のバージョン）、Time Machine。ただし、ローカルの削除がクラウドに同期され、クラウド側が通常の削除として扱った場合は復元枠に入らないことがあります（Issue #32637 がこのケースです）。
6. バックアップの世代を確認する。 別ディスク、別アカウントのDBスナップショット、Git のリモート。
7. マネージドサービスなら事業者のサポートに連絡する。 Terraform の事例は AWS サポート経由で約1日、PocketOS はインフラ事業者の対応で復旧しました。利用者側で戻せなくても、事業者側に手段が残っていることがあります。

こんな使い方は特に危険 / こんな運用なら比較的安全

特に危険な使い方

• ホームディレクトリ直下や、Documents・Desktop を含む広い範囲でエージェントを起動している
• auto モードや --dangerously-skip-permissions を、サンドボックスなしで常用している
• ネイティブ Windows で、古いバージョンのまま使っている
• 開発マシンから本番DBやクラウドの管理画面に直接届く
• バックアップが、エージェントの権限で削除できる場所にしかない
• 削除処理を含むスクリプトの作成とテスト実行を、まとめて任せている
• 「整理して」「自分で判断して進めて」と範囲を決めずに頼んでいる
• コーディング以外の用途（デスクトップ整理、写真・書類の管理）でファイル操作をさせている。私的なデータは Git では戻せません

比較的安全な運用

• プロジェクトのディレクトリに移動してから起動している
• サンドボックスを有効にし、failIfUnavailable: true で無しでの実行を禁止している
• auto モードを使う場合は、サンドボックスやコンテナと組み合わせている
• Windows では WSL2 で動かし、最新版に更新している
• バックアップが、エージェントの認証情報が届かない場所にある（別ディスク・別アカウント・変更不可）
• 本番の認証情報が開発マシンに無い
• 削除対象を人間が名指しし、範囲を明示している

AIコーディング全般のリスクは AIコーディングのセキュリティリスク、AIエージェントが悪用された事件は Claude Codeを悪用した恐喝AIエージェント事件でも扱っています。

よくある質問

Q. 結局、どのAIエージェントがいちばん安全ですか？

現時点で「このツールなら安全」と言える製品はありません。事故は主要ベンダーのほぼすべてで報告されており、Claude Code も Cursor も、自社の安全機能を「完全なセキュリティ境界ではない」としています。安全性を左右するのは、ツール選びより権限とバックアップの設計です。防御機能の多さで言えば、重要パスの保護や組織での強制設定まで公開している Claude Code は手厚い部類ですが、それでも2026年8〜10月に事故の報告が続いています。

Q. Claude Code を初期設定のまま使えば、削除の前に毎回確認が出ますか？

出ません。v2.1.283 以降、対話セッションの既定は auto モードで、分類器が承認した操作は確認なしで実行されます。ルートやホームなど重要パスへの削除はどのモードでも自動承認されませんが、変数やスクリプト経由の削除がすり抜けた報告があります。毎回確認したい場合は default モードに切り替えてください。

Q. 新しいモデルに変えれば、こうした事故は起きなくなりますか？

そう言える根拠はありません。2026年10月時点の現行モデルでの削除事故は確認できていませんが、事故の多くは「シェルが実行する」という仕組みと権限の渡し方から起きています。モデルが変わっても、サンドボックスとバックアップの分離は必要です。

Q. サンドボックスを有効にすれば、もう安全ですか？

いいえ。サンドボックスは既定でオフ、読み取りは既定でほぼ全体（~/.ssh も読める）、起動できないときは警告だけでサンドボックスなしに動きます。組み込みツールやMCPサーバーはサンドボックスの外です。credentials の設定と failIfUnavailable: true を組み合わせ、バックアップの分離と併用してはじめて意味のある防御になります。

Q. CLAUDE.md やメモリに「消すな」と書けば防げますか？

防げません。助言であって、強制力のある境界ではないためです。#11 の報告者はメモリに「rm -rf を使わない」と書いていましたが、削除は実行されました。強制力を持つのは、サンドボックス、deny ルール、IAM側の権限設計です。

Q. Claude Code の /rewind で消えたファイルを戻せますか？

Bash コマンドで消したファイルは戻せません。チェックポイントはエージェントのファイル編集ツールによる変更を記録する仕組みで、rm や mv は対象外です。Git のリモートや OS・クラウドのバックアップを確認してください。

Q. コーディング以外の用途（書類整理・写真管理）でエージェントを使うのは危険ですか？

リスクの性質が変わります。ソースコードは Git のリモートから戻せますが、家族写真や法的文書は戻せません。被害が大きかった事例（15年分の家族写真、法的文書、Dドライブの写真・動画）はこの領域で起きています。使うなら、クラウド側の復元枠と別媒体のバックアップを先に確認してください。

Q. Amazon Kiro の件は、結局AIが原因なのですか？

断定できません。Amazon は「アクセス制御の設定ミスというユーザーエラー」と説明し、Financial Times は匿名関係者の異なる証言を報じています。どちらであっても、エージェントに広い権限を継承させれば承認の手続きは迂回されるという教訓は変わりません。

まとめ

2025年7月から2026年10月までに確認できたAIエージェントのデータ削除事故20件から、実務で役立つ教訓は次の3つです。

1. ツール選びの問題ではありません。 主要ベンダーのほぼすべてで同じ型の事故が起きており、ベンダー自身も「完全なセキュリティ境界ではない」としています。防御機能は事故のたびに強化されていますが、変数やスクリプト、Windows のパス表記を経由したすり抜けは2026年秋も続いています。
2. 引き金は日常的な指示と、確認なしで動く設定です。 「整理して」「自力で解決して」「テストしておいて」。auto モードが既定になった今は、範囲を決めない指示がそのまま実行されやすくなっています。削除を伴う作業では対象を人間が名指しし、サンドボックスと組み合わせてください。
3. 助かるかどうかを決めるのはバックアップの置き場所です。 基準は「いま動いているエージェントの権限で、そのバックアップを消せるか」。消せるなら、それはバックアップとして機能しません。

PocketOS の創業者 Jer Crane 氏の「マーケティング上の誇張による"安全に見える状態"は、安全ではない」という言葉は、2026年10月の時点でもそのまま当てはまります。エージェントにどこまでの権限を渡すかを決められるのは、いまのところ人間の側だけです。

参考・一次情報

• Anthropic 公式: Claude Code Permission modes
• Anthropic 公式: Claude Code Sandboxing
• Anthropic 公式: Claude Code Checkpointing
• Anthropic 公式: Claude Code Changelog
• Anthropic Engineering: How we contain Claude
• Cursor 公式: Agent Security
• OpenAI Codex: Sandboxing
• Railway Changelog: Undoable deletes（2026-05-01）
• Docker Docs: Docker Sandboxes
• Docker Blog: Coding Agent Horror Stories: The rm -rf ~/ Incident
• GitHub Issue（anthropics/claude-code）: #10077 / #12637 / #32637 / #49102 / #88462 / #93099 / #95426 / #99193
• GitHub Issue（openai/codex）: #37419 / #40329
• Vibe Graveyard: Claude Code の Windows でのパス別名による再帰削除（#92593・#97660 ほか）
• Tom's Hardware: Claude が開発者のホームディレクトリ約700GBを削除
• The Register: Cursor-Opus agent snuffs out startup's production database (PocketOS)
• The Register: Vibe coding service Replit deleted production database
• The Register: Google's Antigravity wipes entire D: drive
• Tom's Hardware: Claude Code deletes developer's production setup — 2.5 years of records
• AI Incident Database #1152（Replit） / #1178（Gemini CLI） / #1433（Antigravity）
• ITmedia @IT: AIが「ホームディレクトリ全削除」 重要データ消失で相次ぐ悲劇