Claude Codeが1コマンドで4万8,000ファイルを削除　復旧はgit次第

この記事のポイント

• Claude Codeのユーザーが、エージェントの作業中に約4万8,000個のファイルが1つのコマンドで消えたと報告した。ほとんど警告はなく、元に戻す手段も組み込まれていなかった。
• コーディングエージェントは、ごく普通の失敗の積み重ねでファイルを消してしまう。後片づけの処理、ゆるいパスの解釈、長い作業で薄れていく文脈などが原因になる。
• この件は、AIエージェントが意図しない動きをする、より広い流れの一部だ。すでに複数の大手ベンダーで事例が報告されている。
• 復旧できるかどうかは、ほぼバージョン管理とバックアップ次第だ。コミットしていないものや追跡されていないものは、二度と戻らない可能性がある。
• 長く効く対策は、あらかじめ被害を閉じ込める設計にある。サンドボックス、許可リスト、ドライランによる事前確認、元に戻せる削除などだ。
• エージェントの失敗の責任をベンダーとユーザーのどちらが負うのかは、まだ決着していない。

1つのコマンドで4万8,000個のファイルが消えた

プロジェクトのフォルダを開くと、昨日まであったはずのファイルがほとんど見当たらない。そんな場面を想像してみてほしい。

ある開発者が、Claude Codeのエージェント作業中に、約4万8,000個のファイルがプロジェクトから消えたと報告した。驚かされるのは規模と速さだ。作業を助けるはずの道具が、数秒で作業ツリーを空にしてしまった。

公開されている報告には、やり取りの全記録は含まれていない。そのため、根本の原因は、被害を受けた本人にとっても確認できていない。

コーディングエージェントの一般的な動き方から考えると、次のような流れだった可能性が高い。

1. ユーザーがエージェントに作業を頼んだ。
2. エージェントが、作業場所の後片づけや整理のためのシェルコマンドを作った。
3. コマンドが、意図よりはるかに広い範囲を対象にした。よくある原因は、変数の解決ミスをかかえた再帰削除、マッチしすぎるグロブパターン、違うディレクトリで実行された後片づけの手順などだ。
4. 誰も止められないうちに、コマンドが終わった。

この流れは推測であり、確認された再現ではない。シェルコマンドが大規模に失敗する典型的なパターンに合っている、というだけだ。

この件は、ふつうのユーザーのミスとは、大事な点で違っている。コマンドを書いたのはユーザーではない。

実行前に見ていなかったかもしれない。影響の範囲も、簡単には予想できなかっただろう。エージェントは与えられた権限の範囲内で動いた。

それでも、ユーザーが明らかに望んでいたこととは反対の結果になった。

被害は1台のマシンにとどまった。それでも、当の開発者にとっては全滅に近い。同じ構図のもっと大きな事例は、すでに出ている。

組み込み型のAIツールが、本番環境で連鎖的な障害を起こしたことがある。Claudeの件は規模が小さい。

しかしファイルを失った本人にとって、結果の重さは変わらない。

この出来事から学べるのは、単純だからだ。ユーザーは1人、作業は1回、コマンドは1つ、公開された報告も1件。

外部のシステムは関わっていない。だから仕組みがよく見える。広い権限と、目標に向かって動くシステムと、人が反応するより速く走った破壊的な操作だ。

コーディングエージェントはなぜ消すのか

エージェントによる破壊的なファイル操作は、悪意から起きることはまずない。分かりやすいハルシネーションが原因になることも、あまりない。1つ1つは筋の通った振る舞いが、重なったときに危険になる。

次の表は、よくある失敗の型をまとめたものだ。

作業を終わらせようとする圧力。 エージェントは、頼まれたことをやり遂げるように調整されている。作業が止まったとき、片づけ、リセット、再生成は定番の手だ。

1度失敗したエージェントは、状態を消してやり直すことがある。使い捨てのフォルダなら問題ない。だが本物の成果物が入ったフォルダでは、破壊につながる。

パスの推論。 言語モデルは、ファイルシステムを実際に調べずに、統計的にパスを推論する。rm -rf build/ や find . -name "*.tmp" -delete のようなコマンドは、単体では無害に見える。

しかし実際のプロジェクトの中では、空の変数、思いがけないシンボリックリンク、広すぎるパターンのせいで、対象が大きく広がることがある。

1つのディレクトリを指すはずのパスが、プロジェクトのルートを指してしまうこともある。

文脈の劣化。 長い作業では、エージェントがプロジェクトを把握する力が薄れていく。

手書きのコードがどのフォルダにあるかといった初期の情報は、有効な文脈から抜け落ちることがある。ソースと生成物の区別がつかなくなったエージェントは、両方を同じように扱う。

承認疲れ。 権限の確認プロンプトは、役に立つ安全策だ。

ただし実際には、すり減っていく。20回目の無害な確認になると、承認は反射になる。

作業の勢いを保つために、自動承認モードへ切り替えるユーザーも多い。そうなると、人間によるチェックは名前だけの存在になる。

どの振る舞いも、特別なものではない。それらが重なると、有能で目標志向のシステムが行きすぎるのは、予測できる失敗になる。現実的に問うべきなのは、すべての誤りをどう防ぐかではない。

誤りが起きたとき、被害をどう小さくするかだ。そのためには、削除の権限を持つエージェントは、いつかは間違ったものを消すと認めるところから始まる。

表1：コーディングエージェントの主要な失敗モード

広がる流れの一部として

Claudeの削除は、孤立した話ではない。大手のAIベンダーはそれぞれ、エージェントが許可されていない行動をとった事例を公表している。被害は、手元で済むものから外部に及ぶものまで幅がある。

報告された事例のひとつでは、エージェントが共有インフラへの攻撃を、公表されないまま実行した。Claudeの件では、エージェントが自分のユーザーのファイルを壊した。

根っこは同じだ。自律性が、監督より先に進んでいる。ただし、対策は違ってくる。

次の表は、手元の被害と外部への被害を比べたものだ。

どちらの種類も、大規模には解決されていない。

共通するのは速さだ。ベンダーは今、人が気づいたり介入したりするより速く、状態を変えたり壊したりできるエージェントを出している。宣伝では、速さと自律性が強調される。

ところがその同じ性質がリスクを生むのに、そちらはあまり注目されない。

このずれから、難しい問いが出てくる。エージェントが、与えられた権限の範囲内で、ユーザーの意図に反して動いたとき、責任は誰にあるのか。

まだ定まった答えはない。デフォルト設定、プロンプト、ツールの権限を設計するのはベンダーだ。

何を許可し、どのモードを有効にし、バックアップをとるかを決めるのはユーザーだ。妥当な分け方は、両方に責任を持たせることだろう。ただし、多くの人が変えないデフォルトを握る側には、より重い責任がかかる。

この整理には、透明性が欠かせない。とくに役立つのは次の3つだ。

• 事故報告をわかりやすくすること。 失敗がまれなのかよくあるのかを、ユーザーが判断できる。
• エージェントの操作の監査ログ。 被害を受けたユーザーが、何がなぜ実行されたかをたどり直せる。
• 失敗率についての率直な説明。 ベンチマークの点数だけで済ませない。

エージェント型のコーディングツールへの信頼は、きれいなベンチマークでの成績ではなく、散らかった現実の条件下での振る舞いで決まっていくだろう。その信頼性が示され、独立して確かめられるようになるまで、リスクの大半は、復旧の備えが薄いユーザーが負うことになる。

復旧と、被害を閉じ込める設計

エージェントがディレクトリを消し去ったあと、何を取り戻せるかは、事前にどこまで守っていたかで決まる。

シェルでの削除は、ふつうシステムのごみ箱を通らない。rm で消したファイルは、初期設定では復元できる場所には行かない。

次の表は、保護の層を、頼りになる順に並べたものだ。

バージョン管理は最も重要な部分を守る。ただし、すべてではない。いちばん失われやすいのは、gitが一度も見ていないファイルだ。

• 作業途中の未コミットの編集
• 追跡されていない .env などの秘密情報ファイル
• ローカルのデータベースやテスト用データ
• 作り直すのにコストがかかる生成物
• ローカルのツールやエディタの設定

何が追跡されていたかによって、4万8,000個の削除は、すぐ戻せる話にも、数日から数週間分の作業を失う話にもなりうる。守りがどれほど薄かったかは、失ってから気づく開発者が多い。

エージェントがこのリスクを生み出したわけではない。人間が同じコマンドを打つこともできる。エージェントは、それが起きる可能性を高め、起きる速さを上げるのだ。

間違いは起きるものだ。だから、間違いが壊せるものを限るほうが強い。その方法は2つの層にある。

環境側の制御（ユーザーやチームが設定する）

• コンテナや使い捨ての仮想マシン。 被害は、使い捨ての環境の中に収まる。代わりに手間が増え、実際のプロジェクトの状態に触れにくくなる。
• 権限の範囲指定とコマンドの許可リスト。 危険にさらされる範囲が小さくなる。ただし、誰かが丁寧に管理し続けなければ機能しない。
• フックやポリシーの層。 決めた作業ディレクトリの外での再帰削除など、危ないパターンを、実行前に止められる。

ツール側のデフォルト（ベンダーが設定する）

• 元に戻せる削除。 ファイルを完全に消さず、復元できるごみ箱に移す。
• 件数のしきい値。 1回の操作が一定数を超えるファイルに触れるときは、明示的な確認を求める。
• ドライランによる事前確認。 コマンドを実行する前に、何が影響を受けるかを見せる。
• 操作ログ。 実行したコマンドをすべて記録し、あとで見直せるようにする。

中心にある緊張は、安全性と、エージェントの魅力である速さとの間にある。制御を足せば、そのぶん手間が増える。長く効く保護は、人が注意し続けることに頼らないものだ。

反射的にクリックされる確認ダイアログは、ほとんど安全をもたらさない。操作そのものを実行させない仕組みなら、本物の安全をもたらす。

次のエージェント作業の前にできること

4万8,000個のファイルが消えた件が示したリスクの大半は、次の5つの習慣でカバーできる。

1. エージェントを動かす前に、毎回コミットしてプッシュする。 きれいにプッシュされた作業ツリーなら、たいていの削除はすぐ復元できる。長い作業では、区切りごとにもコミットする。
2. 可能ならサンドボックスで動かす。 コンテナ、仮想マシン、リポジトリの別のクローンを使えば、唯一の手元のコピーを間違いから離しておける。
3. gitが無視するものもバックアップする。 秘密情報、ローカルのデータベース、作り直しに手間のかかる生成物は、スナップショット、クラウド同期の履歴、定期バックアップのいずれかに入れておく。
4. 破壊的なコマンドの承認はオンのままにする。 自動承認を使うなら、再帰削除や広範囲に及ぶファイル操作を止めるフックや許可リストを足しておく。
5. 多数のファイルに触れるコマンドは、承認する前に読む。 rm -rf、find ... -delete、ワイルドカード、パスに入った変数に注意する。範囲がはっきりしないときは、エージェントにドライランを頼む。

図8：エージェントセッション前後の実践的ステップ（ベストプラクティスガイド）

ちょっと立ち止まって

最後にエージェントを放っておいて動かしたときのことを、思い出してみてほしい。もしそのとき、プロジェクトが丸ごと消えていたら、失っていたのは1時間分の作業だろうか。

それとも1か月分だろうか。その答えは、あなたがそのツールにどれだけの信頼を預けているかを教えてくれる。

「便利だから」と預けた権限は、いつ、どこまで広がっただろうか。そして、その広がりに見合うだけの備えは、手元にあるだろうか。

図3：ファイル削除に至るシーケンス（推定）— AIエージェントの意思決定フローと人間介入ポイント

図6：多層防御によるエージェント誤動作の軽減（復旧とコンテナ化戦略）