AIが「ホームディレクトリ全削除」 重要データ消失で相次ぐ悲劇：「危険なコマンドでも、構文的には正しい」 対策は？

Dockerは、AIコーディングエージェントが開発者のmacOSのホームディレクトリを丸ごと削除した事例を解説した。問題はAIの賢さではなく、エージェントが開発者本人の権限でホストのシェルを直接実行する構造そのものにあり、「モデルの判断とシェルの実行の間に境界が存在しないことが原因だ」との見解を示している。

[＠IT]

編集部注：本稿には、実行するとOSやデータを破壊する極めて危険なコマンドが含まれています。インシデントのメカニズムを解説する目的で掲載しているものであり、ご自身の環境（ターミナルなど）では絶対に実行しないでください。

　Dockerは2026年6月1日（米国時間）、AIコーディングエージェントのセキュリティリスクを扱う連載「Coding Agent Horror Stories」の第2弾として、AIコーディングエージェントが開発者の「macOS」のホームディレクトリを1つのコマンドで全削除した事例を解説した。

　事例は2025年12月、海外掲示板「Reddit」のユーザー「u/LovesWorkin」が、AIコーディングツール「Claude Code」に古いリポジトリの整理を依頼したところ、Claude Codeが次のコマンドを実行したものだ。

Claude Codeで実行されたコマンド

　一見すると3つのプロジェクトディレクトリを削除するコマンドだが、致命的な誤りは末尾の「~/」にある。UNIXでは「~」はユーザーのホームディレクトリに展開される。再帰的かつ確認なしで削除する「rm -rf」と組み合わさることで、ホームディレクトリ全体を削除してしまう。

　数秒のうちに、デスクトップや書類、ライブラリフォルダ、キーチェーン、長年のプロジェクトファイルや家族写真が失われた。キーチェーン消失によりClaude Code自身も認証情報を失い、自らのバックエンドと通信できなくなった。TRIMが有効な現代のSSDでは解放ブロックがゼロ化されるため、復旧の手段はなかった。

　この投稿は数時間で1500以上の高評価（upvote）を集め、2025年で最も議論されたAIコーディングエージェントのインシデントの一つとなった。これはCVE（共通脆弱〈ぜいじゃく〉性識別子）でも巧妙な攻撃でもなく、エージェントが言われた通りに作業を遂行した結果、ミスを食い止めるアーキテクチャ上の境界がないまま起きたものだ。

同じ悲劇の連鎖　繰り返される原因とユーザーにできる対策は？

　Dockerは、これが一度限りのインシデントではなくパターンの一例に過ぎないと指摘する。

　2025年10月には、別の開発者がUbuntu/WSL2（「Windows Subsystem for Linux」）で類似の失敗を報告した（GitHub issue #10077）。このIssueによると、Claude Codeがルートディレクトリから「rm -rf」を実行し、ユーザー所有ファイルが全て消えた。「--dangerously-skip-permissions」を使っていなかったにもかかわらず、権限システムは破壊的な展開を検出できなかったという。

　2025年11月には、「GitHub Issue #12637」で別パターンのインシデントが報告された。Claude Codeは以前の作業で、誤って「~」という名前のディレクトリを作成していた。その後、エージェントはそのディレクトリを削除しようとして、引用符で囲まない「rm -rf ~」を実行した。しかしシェルは、「rm」が引数を受け取る前に「~」をユーザーの実際のホームディレクトリへ展開してしまった。その結果、開発者のホームディレクトリは削除された。

　2026年1月には、Anthropicの「Claude Cowork」を使って妻のデスクトップを整理していたユーザーが、15年分の家族写真を含む1万5000〜2万7000ファイルを、macOSのごみ箱を迂回（うかい）して削除した。「iCloud」の30日保持期間がたまたま有効だったため辛うじて復元できた。

　Dockerは、なぜこうしたインシデントが繰り返すのかをアーキテクチャの観点から解説した。コーディングエージェントのClaude Codeや「Cursor」「Replit」「Kiro」はAI駆動のシェルであり、プロンプトを読み取り、コマンドを生成し、それをOSで直接実行する。

　推論ステップと実行ステップは同一で、人間が承認する独立した「実行提案」ステップは存在しない。エージェントは起動時に継承した開発者のシェル（macOSでは通常zsh）を、開発者のフル権限で使う。権限の継承は暗黙的かつ全面的で、セッションが続く限りエージェントは開発者そのものだ。

　Claude Codeの「--dangerously-skip-permissions」フラグは、コマンド実行ごとの確認を取り除く。確認が複数ステップのタスクを煩雑にするため開発者はこれを付けがちだが、その結果エージェントは介入なしに破壊的コマンドを実行できるようになる。

　「推論と実行の間に生じる問題だ。『このコマンドはホームディレクトリを削除するので拒否する』というアーキテクチャの境界がなく、シェルは構文的に正しい危険なコマンドを見たままに実行する」（Docker）

エージェントを隔離環境で実行　破壊リスクを排除するアプローチ

　Dockerは実行環境の構造そのものを変えるアプローチとして「Docker Sandboxes」を提案している。エージェントをホストのユーザー権限で動かすのではなく、独自のカーネル、ファイルシステム、ネットワークを持つmicroVM（マイクロ仮想マシン）の内部で動作させるというものだ。

　エージェントから見た「~/」はワークスペースのマウント先であり、開発者のホームディレクトリはサンドボックス（隔離された実行環境）の内部からは存在しない。管理にはCLI（コマンドラインインタフェース）ツール「sbx」を使う。

ホスト直接実行とDocker Sandboxes（microVM分離）の違いを示す構成図。隔離境界が破壊の波及を断つ（提供：Docker）

　Docker Sandboxes環境では、次のコマンドでエージェントを起動できる。

cd ~/my-project
sbx run claude

　この環境でファイルを全削除するような危険なコマンドを実行しても、ワークスペースが消えるだけで、ライブラリフォルダ、キーチェーン、SSH（セキュアシェル）鍵などはサンドボックス内に存在しないため手を出せない。

　加えて「~/.aws」「~/.ssh」「~/.gnupg」などの認証情報ディレクトリはデフォルトでマウントがブロックされ、「:ro」サフィックスによる読み取り専用マウントや「--branch」によるGitワークツリー分離も利用できる。

　「重要なのは、サンドボックスは使い捨てを前提として設計されているということだ。『sbx rm』コマンドでサンドボックスを捨てれば、ホストは無傷のまま新しく実行環境を再構築できる」（Docker）

　Dockerは「PC内のファイル全削除のようなインシデントは個々のエージェントのバグではなく実行モデルの性質で引き起こされるものであり、エージェントがホストのユーザー権限で動作する限り繰り返されてしまう」と注意を呼び掛けている。