元ツイート: Sebastien Guillemot (@SebastienGllmt) on X
AIエージェントが人間の指示を「文字どおり」、あるいは「予想を超えて忠実に実行してしまう」ことで起きるトラブルが増えています。
今回、開発者のSebastien Guillemot氏が経験した出来事は、AIエージェントの権限管理と安全機構の罠を示す非常に示唆深い事例と言えるでしょう。
AIエージェントは見事に約700GBものディスク容量を解放することに成功しました。
しかし、その代償として削除されたのは、なんとGuillemot氏のホームディレクトリ（~）に保存されていたデータと、約1週間分の開発作業でした。
しかもこの問題、AIモデルがセキュリティ上の理由で自動的に別のモデルへ切り替えられた「直後」に発生したというオチまでついています。
本記事では、このインシデントの技術的な経緯と、私たちが学ぶべき教訓をまとめます。
背景：「/tmpにゴミを残すAIエージェント」を掃除したかった
Guillemot氏は普段からAIエージェントを頻繁に利用しています。しかし、複数のAIエージェントを並列実行していると、処理の途中で作成された一時ファイルなどがLinuxの /tmp ディレクトリに大量に残ってしまう問題に悩まされていました。
そこで彼は、AI（Claude）に対して次のようなプロンプトでスクリプトの作成を依頼しました。
「各AIエージェントを
/tmp内の専用フォルダで実行し、処理が終了したら不要なファイルを自動的に削除するスクリプトを作ってほしい」
目的は非常にシンプルです。
「AIエージェントが残したゴミだけを、安全に掃除する」
ただし、ファイル削除を伴うスクリプトであるため、絶対にしてはいけないことがあります。
「現在使用中のファイルや、ユーザーのホームディレクトリまで間違って削除してはいけない」
事態の悪化：AIによる「セルフ安全チェック」
AIは指示を受け、実行中のAIエージェントを検出し、そのエージェントが使用している領域については削除を延期する仕組みを提案しました。しかし、Guillemot氏はその実装について「複雑すぎる」と判断し、よりシンプルなアプローチを求めます。
ここから事態が少しずつ予想外の方向へ進みます。
ファイルを実際に削除する処理（rm -rf 等）を含むスクリプトだったため、AIは自らコードに対するアドバーサリアル（敵対的）レビューを実施し始めました。
つまり、AIが自分で作ったコードを安全性の観点から検証するために、別のAIエージェントを起動してチェックさせたのです。
その結果、AIのハーネス（実行環境）はこのコードを「危険な処理を含む可能性がある」と判断。安全対策として、使用するモデルが自動的に切り替わり、最終的に Claude 3 Opus から、より軽量な Claude 3.5 Sonnet へとダウングレードされてしまいました。
バグの正体：テスト用変数とクリーンアップ用変数の混同
ダウングレードされたモデルは、削除処理が本当に安全なのかを確認するためのテストコードを生成・実行しました。
テストでは、削除対象となるパスが /tmp なのか、それともユーザーのホームディレクトリ（~）なのかを確認し、ホームディレクトリを削除するような危険なコマンドが実行されないことを検証しようとしていました。
ここまではうまくいっていました。AIはテストの中で ~ を検出し、「これは危険なパスだ」と正しく認識してブロックしていたのです。
ところが、問題はその後の「後片付け」で起こります。
テストが終われば当然、テスト用に作ったダミーファイルなどを削除する「クリーンアップ処理」が必要です。ここで、コード内で同じ変数名が「テスト処理」と「クリーンアップ処理」の両方に使われていたことが致命傷となりました。
結果として、以下のようなロジックの混同（変数のスコープバグ）が発生します。
- テストで「危険なパス（ホームディレクトリ）」を変数に格納する
- クリーンアップ処理に移行する
- 変数がリセットされず、ホームディレクトリのパスがそのまま削除コマンドに渡される
そして最終的に、クリーンアップ処理によって削除されたのは――
AIエージェント専用の一時フォルダではなく、開発者自身のホームディレクトリでした。
図1: 開発者によるインシデントの技術的説明。2つのエラーが重複し、ガード機構自体がトリガーとなってしまった
結果：約700GBの消失と皮肉な結末
Guillemot氏は異常に気付き、処理を停止しました。しかし、すでに約700GBものデータが削除されており、その中には1週間分の開発作業も含まれていました。
図2: 削除実行時のシステム状況。複数のディスクパーティションが逼迫していた（83%〜92%の使用率）
さらに皮肉なことに、AIが最初に掃除しようとしていた /tmp には、不要なファイルが残ったままだったとされています。
つまり、
「/tmpをきれいにするためのAIエージェントが、最も守るべき開発者のデータを削除してしまい、肝心の /tmp は十分に掃除できなかった」
という、エンジニアとしては涙が出そうな結末を迎えたのです。
エンジニアが考えるべき教訓
今回の事件は、単に「AIが間違えた」という話で片付けるべきではありません。AIエージェントにファイル削除などの強力な権限（Tool Use）を与えた場合のシステム設計について、いくつかの重要な教訓を残しています。
1. サンドボックス環境の必須化
ホストOSのファイルシステムを直接操作させるのは極めて危険です。AIエージェントの実行環境には Dockerコンテナ や e2b のようなサンドボックス、あるいはVMを用い、ホストの ~ や重要なディレクトリをマウントしない（あるいは読み取り専用にする）設計が必須です。
2. 破壊的コマンドへの「Human-in-the-loop」
rm -rf のような不可逆なコマンドを実行する際は、AIが自律的に実行するのではなく、必ず人間にDry-run（プレビュー）の結果を表示し、承認（Y/N）を求めるステップを挟むべきです。
3. 「安全機構」がバグを生むパラドックス
AIに「安全性をチェックするコード」を書かせると、変数のスコープや状態管理のミスによって、かえって危険なバグが混入するリスクがあります。複雑な安全機構をAIに任せるより、OSレベルやシェルレベルでの権限制限（chroot や chmod） でガードレールを作る方が信頼性が高いと言えます。
4. 状態管理とバージョンコントロール
開発環境でAIエージェントを動かす場合でも、重要なファイルはGitでコミットしておく、あるいはスクリプト実行前に自動でバックアップ（スナップショット）を取る仕組みをCI/CDパイプラインに組み込んでおくことが、最後の防衛線となります。
まとめ
AIエージェントは強力なツールですが、それはすなわち「強力な破壊力」も同時に持っていることを意味します。
今回の事件は、「AIに何をさせるか」だけでなく、「AIにどこまで権限を与え、どう隔離するか」 という、従来のセキュリティやDevOpsの知識が、AI時代においてもいかに重要であるかを私たちに教えてくれました。
皆さんもAIエージェントをローカル環境で実行する際は、ぜひ /tmp だけでなく、自分のホームディレクトリを守る設計を今一度見直してみてはいかがでしょうか。
Tags:
AIエージェント LLM Claude セキュリティ DevOps インシデント Linux バックアップ