Claude Codeのファイル削除事故——rm -rf禁止でも4万8000件が消えた理由とauto モード時代の防ぎ方

103秒で消えた4万8,218ファイル——報告された事故の中身

最初に、何が起きたのかを事実だけで整理します。元になっているのは、ある開発者がRedditに投稿した報告と、添付された検証レポートです。投稿はその後削除されており、第三者による独立した調査ではない点を先にお断りしておきます。

報告によれば、舞台はWindows上の開発プロジェクトでした。開発者はClaude Codeのエージェントに、作業用に複製した「ミラー」フォルダを作り直すタスクを任せていました。ところがエージェントは、既存のミラーをその場で更新できないことに気づきます。そこで取った手段が、一時フォルダに置かれた古いコピーを丸ごと消すPythonスクリプトを書いて実行する、というものでした。

問題は、その古いコピーの中身です。通常のファイル7,332件に加えて、614個の「ディレクトリジャンクション」が含まれていました。ジャンクションはWindowsのリンク機能のひとつで、別の場所にあるフォルダへの抜け道のようなものです。この614個は、稼働中の本物のプロジェクトフォルダを指していました。

スクリプトは抜け道を抜け道と認識できず、その先の本物のフォルダを通常のフォルダとして辿りました。結果として、消すはずのなかった4万8,218件の実ファイルが削除されます。被害はそれだけで終わりません。プロジェクトのGitの保存領域（コミットの中身や履歴を格納している部分）も空になり、過去の状態を取り出せなくなりました。空になったフォルダは728個にのぼったとされています。

作業の途中、エージェントは開発者にこう告げたといいます。「作業を止めて、これを読んでください。私は何かを壊しました」。自分の失敗を即座に報告した点は、AIの振る舞いとして誠実だったと思います。ただ、報告が届いた時点で、103秒の削除はすでに終わっていました。

rm -rf を禁止していても、この削除は止まらなかった

この事故で最も見落とされやすいのは、「危険なコマンドを禁止していれば防げた」という発想が通用しない点です。

「Claude Code ファイル削除」「Claude Code 事故 対策」といった言葉で調べると、国内の解説記事の多くは設定ファイルでrm -rfを拒否するルールを勧めています。permissions.denyに削除コマンドのパターンを書いておけば、エージェントがそれを実行しようとした時点で止まる、という考え方です。私たちも、この設定そのものは入れるべきだと考えています。ホームディレクトリをまるごと消すような典型的な事故は、これでかなり防げるからです。

ただ、今回の削除にrm -rfは登場しません。エージェントが実行したのは「pythonでスクリプトを動かす」という1行のコマンドでした。スクリプトの中で何千回もファイル削除の関数が呼ばれていても、外から見えるのはその1行だけ。コマンドの文字列を検査する仕組みから見れば、無害な処理と区別がつきません。

もうひとつの落とし穴は、スクリプト自体に安全策が入っていたことです。検証レポートによると、スクリプトはリンクを辿らない設定で書かれていました。Linuxやmacのシンボリックリンクであれば、これで止まります。ところがWindowsのジャンクションは、プログラムからはリンクとして判定されないことがあり、安全策をすり抜けました。さらにスクリプトには、削除後に「対象フォルダが存在するか」だけを確認する検証も入っていました。中身が空になったフォルダも「存在する」ので、検証は成功と判定されています。

誤解のないように申し上げると、これはエージェントが手を抜いた話ではありません。むしろ、それらしい安全策を二重に入れていました。それでも、OSの細かな挙動という一点で全部が崩れた。私たちがこの事故を重く見ているのは、この構図が特殊なケースではないと考えているからです。

auto モードは何を止め、何を見ていないのか

では、人間の代わりにAIが操作を審査する仕組みなら防げたのでしょうか。「Claude Code auto モード」で検索すると設定手順の解説が並びますが、ここでは仕組みの側から見ていきます。

Claude Codeは2026年8月14日から、Pro・Max・Teamプランでauto モードを既定にしました。さらに9月25日のv2.1.283では、Amazon Bedrockなどのサードパーティ経由や、テレメトリを無効にした対話セッションでも、設定がなければauto モードで始まるようになっています。企業が使う経路のほとんどで、既定がauto モードになったわけです。

背景にある数字は、ITmediaの報道で紹介されています。Anthropicによると、Claude Codeの利用者は権限確認の97%を承認していました。検証では、人間は危険なコマンドの86.4%を承認してしまい、確認が50回を超えると危険の検出率は約5%まで落ちたといいます。一方、判定を担うAI（分類器）はセッションの長さに関係なく約89%の検出率を保った、とされています。

この数字は、私たちの実感ともよく一致します。確認ダイアログが1日に何十回も出る環境では、人は中身を読まずにEnterを押すようになる。承認を人間に残しておけば安全、という前提は、少なくとも大量の操作が発生するエージェント作業では成り立ちません。

公式ドキュメントを読むと、分類器が既定でブロックする操作には「セッション開始前から存在していたファイルを取り返しのつかない形で破壊すること」が含まれています。一時フォルダのファイルを、特定のパスではなくワイルドカードでまとめて消す操作もブロック対象です。ルールだけを見れば、今回の削除は止まりそうに見えます。

ところが、分類器が判断材料にできるのは、会話の文脈とコマンドの内容です。ディスク上のフォルダ構造そのものは見えていません。今回のスクリプトが狙ったのは、名前が特定された一時フォルダの古いコピーでした。文字列の上では「作業用の古い複製を片付ける」処理にしか見えません。その中に本物のフォルダへの抜け道が614本あることは、実際にディスクを辿らない限り分からない。この報告では、どの権限モードで動いていたかは明らかにされていません。それでも、仮にauto モードだったとしても、止められた保証はなかったと私たちは見ています。

「あとで戻せる」と思っていた3つの仕組みの限界

止められなかったとしても、戻せればいい。そう考える方もいるはずです。ここにも、公式ドキュメントに明記されている落とし穴が3つあります。

チェックポイントは、スクリプトの変更を追いかけない

Claude Codeには、エージェントの編集を会話単位で巻き戻せるチェックポイント機能があります。/rewindで呼び出せる便利な仕組みですが、公式ドキュメントの制限事項にはこう書かれています。Bashコマンドで変更されたファイルは追跡しない。rmやmvで消したり動かしたりしたファイルは、巻き戻しでは戻りません。サブエージェントの編集も、多くの場合は復元対象外です。チェックポイントはバージョン管理の代わりではない、とドキュメント自身が念を押しています。

Gitは、同じ場所にある限りバックアップではない

「Gitで管理しているから大丈夫」と考えるエンジニアは少なくありません。私たちもそうでした。ただ、手元のGitの保存領域は、プロジェクトと同じディスクの同じフォルダの中にあります。今回のように削除がフォルダを辿って広がれば、履歴ごと一緒に消えます。リモートにこまめにpushしていれば取り戻せる範囲はありますが、未pushの作業は戻りません。

サンドボックスは、ネイティブのWindowsでは動かない

Claude Codeのサンドボックスは、コマンドが触れるファイルの範囲をOSのレベルで制限してくれる仕組みです。作業フォルダの外への書き込みを止められるので、今回のような事故には本来いちばん効きます。ところが公式ドキュメントによれば、対応しているのはmacOS・Linux・WSL2で、ネイティブのWindowsは非対応です。Windowsで使うならWSL2の中で動かすよう案内されています。今回の事故はWindowsの一時フォルダとプロジェクトフォルダで起きており、サンドボックスの保護の外でした。

3つを並べると、共通点が見えてきます。どれも「エージェントと同じ場所にある安全装置」だということです。エージェントの手が届く範囲にある仕組みは、エージェントの操作で一緒に壊れる可能性があります。

削除は「消す」前に「数える」——ドライランと件数照合

では、何なら止められたのか。私たちの答えは地味なものです。消す前に、消す対象を数えることでした。

検証レポートの報告によれば、削除の前に対象パスの一覧を書き出していれば、そこには約5万5,550件が並んでいたはずでした。想定していたのは7,332件。7倍以上の食い違いは、一覧を1回数えるだけで目に入ります。

「AIエージェント ファイル削除 防止」の答えとして、私たちが社内と顧客の現場で使っている削除を伴う作業の型は、次の5段階です。

1. ドライラン：実際には消さずに、消す予定の対象を洗い出す
2. 一覧の書き出し：対象のパスをファイルに書き出し、件数と合計サイズを出す
3. 件数照合：想定していた件数・サイズと突き合わせ、ずれがあればそこで止める
4. 移動：いきなり削除せず、隔離用のフォルダやゴミ箱へ移す
5. 確定削除：動作確認が済んでから、期限を決めて本当に消す

ポイントは3段階目です。エージェントに「確認してから消して」と頼むだけでは不十分でした。今回のスクリプトも確認処理を持っていたのに、その確認は「フォルダが存在するか」という的外れなものでした。何を確認するかを、人間が先に決めておく必要があります。私たちは、件数と合計サイズという「数字で比べられるもの」を照合の基準にしています。

4段階目の「移動」も、効き方が大きい工夫です。移動であれば、仮に対象を間違えても元に戻せます。削除を「取り返しのつかない操作」から「取り返しのつく操作」に変えるだけで、事故の性質がまるで変わります。

バックアップは「エージェントの手が届かない場所」に置く

もうひとつ、事前にしか効かない対策があります。バックアップの置き場所です。

報告した開発者は、NASへの複製、夜間のクラウドバックアップ、Windowsのシャドウコピーという3種類のバックアップを持っていたとされています。復旧できたかどうかは報告されていませんが、少なくとも「ゼロからやり直し」にはならない備えがありました。

バックアップで問われるのは、有無よりも場所です。@ITが報じた別の事例では、AIエージェントの操作で本番データとバックアップが同時に消え、その間わずか9秒だったといいます。バックアップが本番と同じ領域に置かれていたためでした。エージェントが使う資格情報で書き換えられる場所にあるバックアップは、事故のときに一緒に消えるものとして扱うのが安全です。

私たちが確認しているのは、次の3点です。バックアップ先に、エージェントの資格情報で書き込めないか。消そうとしても消せない（または一定期間は消えない）設定になっているか。そして、実際に復元を試したことがあるか。3点目は見落とされがちです。復元したことのないバックアップは、事故の当日に初めて使い方を調べることになります。

私たちが社内と顧客の現場で引いている線

ここからは、私たち自身の運用をお話しします。完璧だと言うつもりはありません。ただ、同じ種類の事故を起こさないために、実際に続けていることです。

1. 「ブランチは汚していい、データベースは触るな」。 非エンジニアが開発に加わるとき、最初に共有する一線です。自分の作業ブランチはどれだけ散らかしても戻せます。本番のデータベースを直接変更すると、後戻りできません。ある化学メーカーのDX推進担当の方は、AIで開発できる手軽さを「簡単すぎて逆に怖い」と表現していました。その怖さは正しい感覚だと思います。だからこそ、怖くない範囲を先に決めて渡しています。

2. 変更は提案として出し、AIと人の確認を通す。 メインのブランチに直接取り込まず、まずプルリクエストとして出してもらいます。AIがレビューし、人が妥当性を確認してから反映する。本番への反映はステージング環境で回帰テストが通ってからの二段階にしています。

3. データの削除は「論理削除」を既定にする。 業務データを消すときは、行を物理的に消すのではなく「削除済み」の印を付けるだけにするのが社内の標準です。物理的に消すのは、法的な消去義務がある場合など、承認と記録を伴う限られた場面だけにしています。

4. 並列で動くエージェントは、作業フォルダを分ける。 複数のエージェントを同時に走らせるときは、Gitのworktree（同じリポジトリを別フォルダに展開する機能）で作業場所を分けています。自分が作っていない未コミットの変更には触らない、というルールも明文化しました。

正直に言えば、最後のルールは「気をつけよう」では守れませんでした。先日も、記事を管理するデータベースを更新する場面で、手元の全ファイルでデータベースを一括上書きする同期処理を使いかけたことがあります。手元には、他のメンバーがWeb上で直した記事の古い版も残っていました。そのまま流せば、他人の修正を黙って巻き戻すところでした。そのときは作業していたAIが一括処理の範囲に気づき、対象を2件に絞って実行しています。助かったのは、仕組みよりも運の要素が大きかった。だから私たちは、この種の「全件に効く操作」を、手順書ではなく機構の側で止める方向に寄せ続けています。

非エンジニアがClaude Codeを使う会社で、最初に決めること

VibeCoding（自然言語でAIに指示を出し、従来の10分の1程度のコストでオーダーメイドのシステムを作る開発手法）が広がっています。Claude Codeを使う人は、もうエンジニアに限られません。そうした会社で、個人任せにせず会社として先に決めておきたいのは次の4点です。

決めること	なぜ必要か	最初の一歩
権限モードの社内標準	auto モードが既定になり、何もしなければ全員がそのモードで動く	業務ごとにManualとautoのどちらを使うかを決め、設定ファイルで固定する
Windowsでの動かし方	ネイティブWindowsではサンドボックスが効かない	WSL2の中で動かすことを標準にする
エージェントが触れる範囲	作業フォルダの外に抜け道があると、被害がそこまで広がる	作業専用のフォルダを決め、本番データや共有ドライブへのリンクを置かない
削除を伴う作業の型	削除は「無害な1行」のスクリプトからでも起きる	ドライラン・件数照合・移動の3点を、社内の依頼テンプレートに入れる

ここで気をつけたいのは、ルールを厳しくしすぎないことです。以前、ある化学メーカーの担当者から「セキュリティ対策がトゥーマッチにならないか」と懸念されたことがあります。全部の操作に承認を求めれば、先ほどの数字のとおり、人は承認を読まなくなります。守りを置くのは、取り返しのつかない操作だけで十分です。テストの実行やドラフトの作成まで縛ると、エージェントを使う意味そのものが薄れてしまいます。

私たちの見解: 「止める」ことより「区切る」こと

今回の事故から私たちが引き出した結論は、削除事故をゼロにする方法はない、という少し身も蓋もないものです。

コマンドの禁止は、文字列に現れない削除を見逃します。承認ダイアログは、人の注意力に頼る限り50回目で形骸化します。AIの分類器は、ディスクの構造までは見えません。どの仕組みも、それぞれの持ち場では確かに効いています。それでも、全部を重ねても抜ける経路は残る。今回の103秒は、その経路が現実に通った例でした。

だから私たちは、「止める」ことと同じくらい「区切る」ことに力を入れています。止め損ねたときに、被害がどこまでで止まるのか。作業フォルダの外には届かない、バックアップには届かない、本番データベースには届かない——その線を、エージェントの手が届かない側に引いておく。考え方の全体は、AIエージェントの『被害範囲』を区切る設計で詳しくお伝えしています。

ここは意見が分かれるところかもしれませんが、私たちはエージェントの自律性を下げる方向には進みません。人が1件ずつ承認する運用に戻せば、確かに今日の事故は減るかもしれない。けれど、その分だけAIで開発する速さを手放すことになります。速さを保ったまま安全にするには、自律に任せる範囲を広げ、その外枠を仕組みで固めるほうが筋がいいと考えています。

よくある質問

Q. permissions.denyでrm -rfを禁止する設定は、もう意味がないのですか。

意味はあります。ホームディレクトリの丸ごと削除のように、コマンドとして直接実行される典型的な事故はこの設定で防げます。ただし、スクリプトの中で行われる削除は見えません。禁止ルールは「最初の一枚」であって、それだけで完結する対策ではない、という位置づけで入れてください。

Q. auto モードは使わないほうが安全ですか。

一律にそうとは言えません。人間が承認を続けると、確認が50回を超えたあたりで危険の検出率が約5%まで落ちるという検証結果が公表されています。取り返しのつかない操作を扱う業務はManualにし、それ以外はautoにする、というように業務ごとに使い分けるのが現実的です。どちらにするかは個人任せにせず、会社として設定ファイルで固定しておくことをおすすめします。

Q. Gitで管理していれば、消えても戻せるのではありませんか。

リモートにpushしていない作業は戻りません。手元のGitの保存領域はプロジェクトと同じフォルダにあるため、削除がそこまで広がれば履歴ごと失われます。今回の事故でも、Gitの保存領域が空になったと報告されています。こまめなpushに加えて、エージェントの手が届かない場所にバックアップを置いてください。

Q. Windowsで使う場合、最低限なにをすればよいですか。

WSL2の中でClaude Codeを動かし、サンドボックスを有効にしてください。ネイティブのWindowsではサンドボックスが動作しません。あわせて、作業フォルダの中に本番データや共有ドライブを指すショートカットやジャンクションを置かないことも確認してください。

Q. 非エンジニアに使わせる前に、何を決めておけばよいですか。

「データベースは直接触らない」「変更はプルリクエストで出す」「削除はドライランと件数照合を通す」の3点です。技術を教えるより先に、壊れない範囲を教えるほうが早く、本人も安心して試せます。

まず試すなら

1. 自社の権限モードの設定を確認する。 Claude Codeを使っている全員が、今どのモードで動いているかを把握してください。何も設定していなければ、v2.1.283以降の対話セッションはauto モードで始まります。業務ごとの使い分けを決め、設定ファイルで固定するところまでが一区切りです。
2. 削除を伴う依頼に「件数照合」を必須にする。 エージェントに削除や整理を頼むときは、「消す前に対象を一覧にして件数を報告し、想定と違えば止まる」を依頼文に入れます。社内の依頼テンプレートに1行足すだけで始められます。
3. バックアップを1回、実際に復元してみる。 エージェントの資格情報で書き換えられない場所にあるか、消せない設定になっているか、そして本当に戻せるかを確かめてください。復元したことのないバックアップは、備えとしては半分です。

AI-Pathでは、無償の業務プロセス診断（BPR）を実施しています。現場のヒアリングから業務フロー・改善案・投資対効果のたたき台までを可視化し、「どの業務をAIエージェントに任せるか」「どこに守りが要るか」を同時に見極めます。Claude Codeを社内に広げる前に、任せる範囲と区切る線を一緒に整理したい場合は、お問い合わせからご相談ください。

非エンジニア向けの線引きは、VibeCodingの線引き設計でも詳しく書いています。

参考リンク

• Claude Code Agent Allegedly Deletes 48,000 Files in 103 Seconds（Cybersecurity News） — 事故の経緯と検証レポートの要点

• 「Claude Code」、AIが権限確認を代行する「auto mode」がデフォルトに（ITmedia AI+） — auto モード既定化の背景と承認率・検出率の数字

• Checkpointing（Claude Code Docs） — チェックポイントがBashの変更やサブエージェントの編集を追わないという制限事項

• AIエージェントが本番とバックアップを同時に破壊 設計ミスが招いた最悪の9秒（@IT） — バックアップを本番と同じ領域に置いたことによる同時消失の事例