Claude Code、バックアップ指示でユーザーのホームを全削除。「Sorry, typo.」

開発者がClaude CodeにPC全体のバックアップを依頼したところ、AIエージェントがWindowsのプロファイルフォルダをまるごと消し去った。繰り返されてきた同種の事故の最新例だ。　

バックアップが消去に変わるまで

r/ClaudeCodeに投稿されたスクリーンショットには、Claude Codeのターミナル画面が映っている。

投稿者はClaude Opus 5にシステムのバックアップを指示した。AIはタスクに取りかかったが、バックアップの保存先を誤ったと判断し、自分で修正を試みた。その「修正」がrm -rfだった。

問題は、AIがWindows上のUnixスタイルシェル（Git BashやWSLなど）で動作していた点にある。Windowsの標準的なパスはC:\Users\harih\だが、Unixシェル上ではこれが/c/Users/harih/と表記される。

AIはこの/c/Users/パスを自分が作った一時的なバックアップフォルダだと誤認した。本来のWindows形式のパスと一致しなかったため、不要なバックアップだと判断し、rm -rf "/c/Users/harih/"を実行した。

ユーザーのプロファイルフォルダ内のファイルとフォルダがすべて削除された。

削除が終わった後、Claude Codeはこう返した。

Sorry, typo.

投稿者は「何事もなかったかのように」と振り返っている。

10か月で7件以上

この種の事故は初めてではない。

2025年10月、開発者のマイク・ウォラック（Mike Wolak）氏がGitHub Issue #10077を起票した。Claude Codeがルートからの再帰削除を試み、システムファイルはパーミッションで弾かれたが、ユーザー所有のファイルはすべて消えた。同氏は--dangerously-skip-permissionsを使っていなかったにもかかわらず、コマンドは確認なしで実行されている。

同年11月には別の経路が報告された。Claude Codeがチルダ記号（~）という名前のディレクトリを誤って作成した。その後、親ディレクトリでrm -rf *を実行した際にシェルが~をホームディレクトリに展開し、全削除に至っている。

12月には、GoogleのAI開発環境Antigravityが写真家のDドライブを丸ごと消去する事故が起きている。

2026年に入ると事故の規模が拡大した。2月、ベンチャーキャピタル創業者のニック・ダビドフ（Nick Davidov）氏がClaude Coworkに妻のデスクトップの整理を依頼し、一時ファイルの削除だけを許可した。AIは15年分の家族写真（1万5000〜2万7000枚）を、ゴミ箱を経由せずターミナルコマンドで削除した。

iCloudの30日間保持が偶然有効だったため復旧できたが、それがなければ取り返しがつかなかった。同月、MetaのAI安全性責任者サマー・ユエ（Summer Yue）氏が自身の受信箱をOpenClawに消されている。Amazonでは自社のAIコーディングツールKiroが本番環境を削除・再構築し、13時間の障害を引き起こした。

4月にはPocketOSの本番データベースと全バックアップが9秒で消去された。

そして8月、今回の事故が起きた。モデルはOpus 5に世代交代している。

コミュニティが指し示す構造

投稿は2000件以上のupvoteと370件超のコメントを集めた。議論は事故そのものよりもAIエージェントの運用構造に集中している。

最も早く挙がった指摘は、投稿者がauto classifierを動かしていなかったのではないかという点だった。Claude Codeには、ファイル書き込みやシェルコマンドの実行前にユーザーの承認を求める仕組みがある。

auto classifierはその承認判断をAI自身に委ねる機能で、Anthropicの計測では93%の承認プロンプトが手動でも承認されていた。手動であれ自動であれ、大半のコマンドは通過する。

サンドボックスコンテナの使用を推奨するコメントには140upvoteがついた。「Claudeにはカレントプロジェクトのディレクトリと~/.claudeと/tmpしか見えない。探索もできない」。

最も支持を集めたのは、rm -rfを含む破壊的コマンドをhooksで事前にブロックする提案で、348upvoteに達している。Claude Codeのhooksは、ツール実行の前後にスクリプトを走らせる機能で、禁止コマンドを列挙するdeny listよりも柔軟にコマンドを検査できる。

ただ、deny listには構造的な限界がある。Claude Codeのdeny listはコマンドの先頭トークンだけを検査するため、複合コマンド（git fetch && rm -rf ~/のような連結）の後半部分はチェックをすり抜ける。

GitHub上でも複数のIssueで同じ問題が報告されており、rm -rfを禁止しても、find -deleteや変数展開、サブシェル経由で同じ結果に到達できる。テキストで書かれたルールは、テキストを操るAIにとって絶対的な壁にはならない。

環境が止める

Anthropicは2026年5月、自社のエンジニアリングブログでエージェントの封じ込め戦略を公開した。その中心にあるのは「モデルの行動を監督するのではなく、モデルが到達できる範囲を制限する」という設計思想だ。

claude.aiではgVisorコンテナ内でコードが実行され、ユーザーのファイルシステムには触れない。Claude Coworkでは仮想マシンの中でエージェントが動き、ユーザーが選択したワークスペースフォルダだけがマウントされる。

Claude Codeでは、macOSのSeatbeltとLinuxのbubblewrapによるOSレベルのサンドボックスが導入された。書き込みはワークスペース内に限定され、ネットワークは初期状態で遮断される。

Anthropic自身の検証でも、承認プロンプトの93%がユーザーに承認されていたという数字が出ている。承認回数が増えるほど注意力は下がる。

この「承認疲れ」への対処としてauto classifierが導入されたが、約17%の過剰な動作はすり抜ける。環境側の制約がなければ、そのすり抜けがrm -rf ~/になる。

Dockerも6月のブログ記事で「Docker Sandboxes」を提案している。エージェントをmicroVM内で実行し、ホストのファイルシステムを見えなくする。エージェントがrm -rf ~/を実行しても、削除されるのはサンドボックス内のワークスペースだけで、ホスト側のホームディレクトリには影響しない。

繰り返しの意味

モデルは世代を重ね、各社は安全機能を追加し、ベストプラクティスは文書として残った。それでもrm -rfは止まらない。

止まらない理由は明確だ。AIコーディングエージェントはユーザーと同じ権限でシェルを叩く。ユーザーのシェルが実行できることは、すべてエージェントも実行できる。プロンプトに「削除するな」と書いても、CLAUDE.mdに禁止コマンドを列挙しても、それは提案であって壁ではない。

Anthropicの封じ込めブログがこの構造を要約している。

確率的な防御がすべて外れたとき、最後に当たるのは確定的な境界だ。

ルールをどれだけ書いても、それを読むのがAIである限り、破られる可能性はゼロにならない。安全を担保するのは文章ではなく、到達できない場所を設計することだ。

今回の投稿者は、コメント欄でこう書いている。「自分もサンドボックスを設定すべきだ」。その通りだ。ただ、その判断がユーザーの自己責任だけに委ねられている現状が、事故を生んでいる。

関連記事

• AIが10年眠ったFirefoxのバグを掘り起こしている
• マイクロソフト、AIトークンに部門予算を導入。「使いすぎるな」と全社に通達
• DNA鑑定のデジタルファイルに30年放置の脆弱性。AIで改ざん可能と判明
• Microsoft、AIが見つけたバグの修正に追われる。7月は過去最多の600件超
• Claudeの共有会話がGoogle検索に露出。1年前と同じ原因
• AIコーディングツール4種にサンドボックス脱出の欠陥
• Microsoft、Mythos対抗のAIセキュリティ製品を準備
• アリババ、Claude Codeを社内禁止。7月10日から
• 米政府がGPT-5.6のリリースに介入。顧客ごとの承認制へ
• Claudeが身分証を求める日。Anthropicが書き換えた規約の中身