Claude、スクリプトのテスト中に開発者のホームディレクトリから700GBを削除

開発者のセバスチャン・ギユモ（Sebastien Guillemot）氏は、Anthropicのクロード（Claude）に、自分が動かしている複数のAIコーディングエージェントを/tmpディレクトリ配下のそれぞれ専用のフォルダに隔離し、実行終了後には自動的に後片付けをするスクリプトを書くよう依頼した。本人の説明、およびTom's HardwareとAI Timesの報道によれば、2026年8月27日、そのスクリプトは本来の役目を果たすどころか、ホームディレクトリ全体を削除してしまい、約700GBのデータと1週間ほどの作業成果を失わせた。

ギユモ氏は日頃から複数のAIエージェントを頻繁に使っており、その多くが実行後も自分で片付けをせず、共有ディレクトリの/tmpにゴミファイルを残していくことに苛立ちを感じていた。そこでクロード——報道では社内コードネームの「Fable」で呼ばれている——に、隔離と後片付けのロジックを追加するよう求めた。クロードが最初に提案した案では、実行中のエージェントがまだ使用しているファイルの削除を遅らせる検出ロジックが盛り込まれていたが、ギユモ氏はできあがったコードが複雑すぎると判断し、もっと単純なものを求めた。

アドバーサリアルレビューを実施した直後、タスクの途中でモデルがダウングレード

このスクリプトはデータの恒久的な削除を伴うため、クロードは自らの判断で、いわゆる「アドバーサリアルレビュー」を実施することにした。すなわち、実行前に自分自身の作業内容を安全性の観点からチェックさせるために、自分自身の別インスタンスを立ち上げたのだ。AI Timesがギユモ氏の説明を引用して報じたところによれば、その過程の途中で、Anthropicの安全分類器がこのスクリプトを十分に危険と判断し、担当していたモデルを自動的にダウングレードした——まずOpus 5からOpus 4.8へと。このダウングレードはギユモ氏自身が求めたものではなく、ファイル削除が可能なスクリプトに対する安全システム自体のリスク評価によって引き起こされたものだった。

Opus 4.8になったクロードは、アドバーサリアルレビューが計画していた安全テストを実行し、スクリプトに書かれた削除対象が/tmpやユーザーのホームディレクトリのような危険なパスに一致していないかを確認した。このチェック自体は、まさに意図した通りに機能した——テストの段階では、両方のパスとも正しく「危険」と判定されていたのだ。ギユモ氏は、ダウングレード前に使われていたOpus 5——コーディング作業においてOpus 4.8よりも性能が高いとされる——であれば、この後に起きたことをおそらく見抜けていただろう、との見方を示している。

テストと後片付けで使い回された、たった一つの変数名

この安全チェックが対象としていたのは、スクリプトのテストの段階だけであり、その後に続く後片付けの段階までは対象になっていなかった。コードのテストを行えば、その後には必ず独自の後片付けが必要になる。ところがクロードは、この後片付けの部分を書く際に、テストの対象パスを保持するためにすでに使っていたのと同じ変数名を、そのまま使い回してしまった。テストと後片付けの二つの段階が一つの変数を共有していたため、安全チェックの間は隔離されたテスト用パスを安全に指していたその値が、後片付けの段階が実行されるとギユモ氏の実際のホームディレクトリを指すようになってしまい、クロードはそのディレクトリに対して、事実上の再帰的削除を実行してしまったのである。

• 約700GBのデータが削除され、その中にはギユモ氏のほぼ1週間分の作業成果も含まれていた
• Anthropicの安全分類器は、タスクの途中で、スクリプトを担当していたモデルをOpus 5からOpus 4.8へとダウングレードした。ギユモ氏がそれを求めたわけではない
• アドバーサリアルな安全レビューは/tmpとホームディレクトリを危険な削除対象として正しく検出していたが、それはテストの段階だけであり、後片付けの段階は検証されていなかった
• そもそもこのプロジェクトのきっかけとなった/tmp内のゴミファイルは、今回の削除事故の後もそのまま残っていた

ギユモ氏がこの出来事についてオンラインで発信すると、この話はすぐに広まり、他の開発者たちは、AIコーディングエージェントを隔離したり、まさにこの種のミスから復旧したりするために作られたサードパーティ製ツール——Tom's Hardwareは一例としてTermaxaという名前を挙げている——を指摘して反応した。Tom's Hardwareは、その皮肉さを直接指摘している。誤ったデータを削除してしまうAIエージェントから身を守るためのツールが、今や一つのカテゴリーとして存在するようになった一方で、まさにそのカテゴリーのツールを作ろうとしたことが、今回の削除事故を引き起こしたのだ、と。

ギユモ氏は何が起きているかに気づいた時点ですぐにプロセスを止めたが、間に合わず、ディレクトリの大部分はすでに失われていた。同氏によれば、データの大部分は、バックアップからではなく、gitリポジトリやNixストアのデータ、セッションログをつなぎ合わせて復元したという。本人の説明では、自分が使っている数多くのAIエージェントのうち、バックアップを作るよう指示したものは一つもなかった。

AIコーディングエージェントを使うチームにとって、これは何を意味するのか

Claude、Cursor、あるいは同様のAIコーディングエージェントを日常の開発業務に取り入れている日本のソフトウェアチームにとって、今回の事故は次のことを思い出させる。安全システムの内部状態——タスクを処理しているモデルのバージョンを含む——は、ターミナルを見ている人に見える警告なしに、実行の途中で変わり得るということだ。スクリプトの意図をチェックするアドバーサリアルレビューは、そのスクリプトが実際に実行するすべての段階をチェックしたことにはならない。エージェントに破壊的なコマンドを実行させるワークフローは、たとえ隔離されたテストのように見えるものであっても、エージェントが正しく振る舞うことに依存しない独立したバックアップを依然として必要とする。