8月28日、Bruno Ferreiraが「Claude nukes a developer's 700 GB home directory while testing deletion safeguards; automatic model safety downgrade may have contributed to the screw-up」と題した記事を公開した。AnthropicのAIエージェント「Claude Fable」（Anthropicが提供するAIエージェント製品群の一つ）が、削除スクリプトの安全性テスト中に開発者のホームディレクトリ700GBを丸ごと消去した事故を報じたものだ。
「削除しないことを確認するためのテスト」が、まさにそのデータを削除した——この逆説的な事故が起きた背景には、安全機構として設計された自動モデルダウングレードと、変数名の再利用というバグが複合的に絡んでいた。AIエージェントに実害を出させるリスクが単一の判断ミスではなく、複数のレイヤーの連鎖から生まれることを示す事例として、開発者コミュニティで広く共有されている。
「削除しないことを確認するテスト」で削除した
開発者のSebastien Guillemot氏は、AIエージェントが/tmpディレクトリに大量の一時ファイルを残す問題に悩んでいた。そこでClaude Fableに対し、各エージェントを/tmp以下の専用フォルダにサンドボックス化し、終了後に自動クリーンアップするスクリプトを書かせることにした。
Fableが最初に提案したコードは「実行中のエージェントを検知して削除を遅延させる」ロジックを含んでおり、Guillemot氏はこれを「複雑すぎる」と突き返した。
ここからが問題の連鎖だ。
スクリプトがファイルの完全削除を伴う内容だったため、Fableは自発的に「敵対的レビュー（adversarial review）」を実施しようとした。これはAI安全性の文脈で使われる手法で、別のモデルインスタンスを起動して自分自身のコードを批判的に検証させるものだ。削除操作のリスクを自己判断したFableが、このチェックを自発的に開始したことが連鎖の引き金となった。
安全機構が「より低品質なモデル」を呼び込んだ
Fableが新たなエージェントインスタンスを起動しようとした際、Anthropicの実行基盤（ハーネス）がこの動作を検知。リスクの高い操作と判断し、モデルをClaude Opus 5からOpus 4.8へ自動ダウングレードした。
しかし元記事が指摘するのは、この安全機構の逆説的な結果だ。Claude Opus 5はコーディングタスクにおいてOpus 4.8より性能が高い。上位モデルのままであれば、後述する変数名の矛盾を検出できた可能性がある。安全リスクを抑えるためにモデルを下げた結果、より低品質なコードが生成されて事故が起きた——という構図だ。
変数名の衝突が引き起こした致命的バグ
ダウングレードされたOpus 4.8が安全性テストを実行した。削除コマンドの対象が/tmpとユーザーのホームディレクトリに一致しないかを検証するテストで、この判定自体は正しく機能した。両者とも「危険」と正しく識別されている。
問題はその後のクリーンアップ処理にあった。テストコードがテスト用変数とクリーンアップ用変数に同じ変数名を使い回していたため、クリーンアップステップがユーザーのホームディレクトリを削除対象として実行してしまった。
700GBのデータと1週間分の作業が消えた。
Guillemot氏はプロセスを途中で止めたが、間に合わなかった。皮肉なことに、エージェントは当初の目的だった/tmpのクリーンアップはしないまま終了した。
データは一部回復、しかしバックアップはゼロだった
Guillemot氏はgit、nix、セッションログなどから大半のデータを復元できた。ただし元記事はこう締めくくっている。「複数のエージェントが動いていたのに、日次バックアップは一つもなかった」。
事故後、Anthropicがこの自動ダウングレード挙動をどう修正するかについては現時点で公式な発表はない。コミュニティではTermaxaのようなサンドボックスツールや、Dockerコンテナによるファイルシステム分離を代替策として提案する声がある。ただしそうしたツールが必要とされること自体、AIエージェントにファイルシステムへのアクセス権を与える際のリスク管理がまだ整備途上であることを示している。
今回の事故の構造は、自動ダウングレード・自己複製による安全チェック・変数名の再利用という三つの要因の連鎖だ。Anthropicのコンピューター操作機能をはじめとするツール系AIの普及が加速する中、AIエージェントへのファイルシステム権限付与は慎重に設計する必要があると改めて示した。
