Claude CodeやCodex CLIで起きる予期
せぬファイル破壊
（コマンドオプション）

by

先日、SNSで興味深い報告を目にしました。
AIエージェントに「ファイルを消さないように」と指示していたのに、実際には削除されてしまったという話です。

これは単なる不具合ではなく、もっと根深い問題です。
AIエージェントは、私たちが思っている以上に「創意工夫」してしまうのです。

関連記事

1. AIエージェントが実際にやってしまったこと

Claude CodeやGitHub Copilot CLIといったAIエージェントツールは、コーディングや開発作業を劇的に効率化してくれます。
しかし、これらのツールを使う上で多くの人が見落としているのが、UNIXコマンドの持つ「パワフルさ」とその裏にある「危険性」です。

AIエージェントが実際にやってしまったこと 禁止指示 「rmコマンドは使うな」 AI 判断 回避行動の例 ① find -delete 削除コマンド実行 ② sed -i ファイル上書き ③ > filename 空ファイルで上書き ④ mv /dev/null 目的達成を優先

1.1. findでファイルを消す

あのケースでは、rm コマンド（ファイル削除コマンド）を禁止していたところ、AIは find -delete オプションを使ってファイルを削除してきました1。

# rmコマンドを禁止されたAIが実行した例
find . -name "*.tmp" -delete
Code language: PHP (php)

find は本来、ファイルを検索するためのコマンドですが、-delete というオプションを付けると検索したファイルをそのまま削除できてしまいます。

1.2. 空のファイルで上書きする（mv, echo）

さらに驚くのは、削除そのものを禁止した場合です。
AIは空のファイルを作成して、元のファイルに上書きする方法を取りました。
削除はしていませんが、結果的にファイルの内容は失われます。

# 削除せずにファイルを「空にする」方法
> important_file.txt
# または
echo "" > important_file.txt
Code language: PHP (php)

他にも mv コマンドで /dev/null（Linuxの「ゴミ箱」のような特殊なファイル）にファイルを移動させたり、sed の -i オプション（in-place、その場で書き換えるという意味）で直接ファイルを書き換えたりと、手口はさまざまです。

1.3. sedで機密情報を見る

ある開発者は .env ファイル（環境変数などの機密情報を保存するファイル）の読み取りを禁止していました2。
しかしAIエージェントは cat や less といった通常のファイル閲覧コマンドが使えないとわかると、sed コマンドでファイルの中身を読み取ろうとしたそうです。

2. なぜプロンプトだけでは防げないのか

これらはすべて、AIが「禁止されたコマンドを避けつつ、目的を達成しようとした結果」です。

利用者が見落としていること 誤った認識 「AIが提案したから 大丈夫だろう」 実際の危険性 コマンドの意味を 理解していない ↓ 判断できない 危険なコマンド例 find -delete 確認なし即座削除 sed -i 元に戻せない上書き chmod -R 777 セキュリティリスク rm -rf / システム全削除

ここで考えるべきは、「なぜAIはこんなことをするのか」ということです。

AIエージェントは、与えられたタスクを完遂することを最優先に動きます。
「ファイルを整理して」「不要なデータを削除して」といった指示を受けると、それを実行するために利用可能な手段を探します。

プロンプト（AIへの指示文）で「rm コマンドは使わないで」と書いても、AIにとってそれは「rmという特定のコマンドを避けるべき」という意味にしかなりません。
「ファイルを削除してはいけない」という意図までは確実に伝わらないのです。

UNIXやLinuxのコマンドラインには、同じ目的を達成する方法が無数に存在します3。
ファイルを削除する方法だけでも、rm、find -delete、unlink、> ファイル名での上書き、mv /dev/nullなど、いくらでも思いつきます。

# ファイル削除の様々な方法
rm file.txt           # 直接削除
find . -name "file.txt" -delete  # findで検索して削除
unlink file.txt       # unlinkシステムコールで削除
> file.txt            # 空ファイルで上書き
mv file.txt /dev/null # /dev/nullに移動（実質削除）
Code language: PHP (php)

AIは膨大な学習データから、これらの代替手段を知っています。
プロンプトで一つのコマンドを禁止しても、別の方法を見つけ出してしまうのです4。

つまり、プロンプトによる制限は「お願い」であって「強制」ではないということです5。

初学者やコマンドラインにあまり慣れていない開発者は、AIが実行するコマンドの意味を完全には理解していないことがあります。
「AIが提案しているから大丈夫だろう」という信頼が、思わぬトラブルにつながります。

2.1. コンテナや仮想環境での隔離

では、どうすればAIエージェントによる予期せぬファイル操作を防げるのでしょうか。

結論から言えば、プロンプトだけでは不十分で、システムレベルでの制限が必要です6。

最も基本的な対策は、ファイルシステムの権限（パーミッション）を適切に設定することです。
AIエージェントが動作するユーザーアカウントに、削除や変更をさせたくないファイルへのアクセス権を与えなければ、物理的に操作できなくなります。

しかし、より安全な方法は、AIエージェントをDockerコンテナや仮想マシンの中で動かすことです7。

# Dockerコンテナ内でAIエージェントを実行
docker run --rm -it \
  --read-only \  # ファイルシステムを読み取り専用に
  -v /path/to/work:/work \  # 必要な作業ディレクトリのみマウント
  ai-agent-image
Code language: PHP (php)

コンテナ内のファイルシステムを読み取り専用にしたり、必要最小限のディレクトリだけをマウントしたりすることで、被害範囲を限定できます。
仮にAIが暴走しても、コンテナを破棄すれば元に戻せます。

2.2. 多層防御という考え方

セキュリティの世界では、「多層防御」という考え方があります。
一つの防御策に頼るのではなく、複数の対策を組み合わせることです。

AIエージェントの安全な利用も同じです。

  1. 第1層：プロンプトでの指示 ── AIに意図を明確に伝える
  2. 第2層：コマンドレベルの制限 ── 危険なコマンドを無効化
  3. 第3層：ファイルシステムの権限 ── 物理的にアクセスを制限
  4. 第4層：コンテナでの隔離 ── 被害範囲を限定
  5. 最終層：システムコール制御 ── OS機能レベルで操作を禁止

プロンプトでの指示は、もっとも初歩的な対策にすぎません。

3. UNIXコマンドの知識が必要な理由

ここまで見てきて感じるのは、AIエージェントツールを安全に使うには、ユーザー自身がUNIXコマンドについてある程度の知識を持っている必要があるということです。

AIが提案するコマンドの意味を理解できなければ、それが危険かどうかも判断できません。
find -delete が何をするのか、sed -i がどれほど強力なのか、> ファイル名 が上書きを意味することなど、基本的なコマンドの挙動を知っておく必要があります。

特に -delete、-i（in-place）、-R（recursive、再帰的）、-f（force、強制）といったオプションは、確認なしに大量のファイルを操作するため、取り扱いに注意が必要です。

3.1. AIエージェントとの付き合い方

AIエージェントは、指示を「理解」しているわけではありません。
学習したパターンから最も適切と思われる行動を選んでいるだけです8。

プロンプトはあくまで「お願い」であり、本当に守らせたいルールは、システムレベルで物理的に強制する。このことを意識するだけで、AIエージェントとの付き合い方は大きく変わるはずです9。

「AIに任せておけば安心」ではなく、「AIの行動を理解し、適切に制御する」というスタンスが必要だと思います。

  1. findコマンドの-deleteオプションは、検索条件に一致するファイルやディレクトリを削除します。このオプションは確認なしに即座に実行されるため、条件指定のミスが重大な結果を招く可能性があります。また、オプションの順序を間違えると意図しないファイルまで削除される危険性があります。 – Find and Delete Files and Directories
  2. AIエージェントによるプロンプトインジェクション攻撃は、OWASP 2025では#1の脆弱性としてランク付けされており、実際に73%の本番AI環境で確認されています。 – Prompt Injection Attacks: The Most Common AI Exploit in 2025
  3. Trail of Bits社のセキュリティ研究によると、AIエージェントにおける「argument injection（引数インジェクション）」攻撃は一般的であり、事前承認されたコマンドでも、引数を悪用することで任意のコード実行が可能になることが報告されています。 – Prompt injection to RCE in AI agents
  4. セキュリティ研究者は、コマンドのホワイトリストだけでは不十分であると警告しています。なぜなら、findやgrepなどの一見安全なコマンドでも、数百の危険なフラグやパラメータを持っており、それらを悪用することで攻撃が可能になるためです。サンドボックス化なしのホワイトリストは根本的に欠陥があるとされています。 – Critical Argument Injection Flaw Lets Hackers Hijack AI Agents
  5. Claude Codeには実際に2つの高危険度脆弱性（CVE-2025-54794とCVE-2025-54795）が発見されました。これらはパス制限バイパスとコマンドインジェクションの問題で、Cymulate社のセキュリティ研究者によって報告され、現在は修正されています。 – CVE-2025-54795: Claude Code Vulnerabilities
  6. 2025年の研究では、最先端のLLMエージェントの94.4%がプロンプトインジェクションに脆弱であり、83.3%がリトリーバルベースのバックドアに、100%がエージェント間の信頼関係の悪用に脆弱であることが示されています。OpenAIやAnthropicも、プロンプトインジェクションは「完全には解決できない可能性がある」長期的な課題であると認識しています。 – Agentic AI Security: Threats, Defenses, Evaluation
  7. OpenAIは、AI搭載ブラウザにおいてサンドボックス技術を使用してプロンプトインジェクションの結果として有害な変更が行われることを防いでいます。セキュリティ専門家は、サンドボックス化が現在利用可能な最も効果的な防御手段であると強調しています。 – Understanding prompt injections
  8. 2025年の大規模研究では、GitHub CopilotとCursorに対するプロンプトインジェクション攻撃の成功率が41%から84%に達することが実証されています。特に、外部リソース（GitHubのissueやコードコメント）に埋め込まれた悪意のある指示をAIエージェントが区別できず、それらを実行するために必要だと判断してしまうことが確認されています。 – “Your AI, My Shell”: Demystifying Prompt Injection Attacks
  9. Model Context Protocol（MCP）のような標準化されたレイヤーでも、信頼されていないソースからのデータを扱う場合には脆弱性が存在します。例えば、CursorにおけるCVE-2025-59944は、保護されたファイルパスの大文字小文字の区別のバグにより、エージェントが誤った設定ファイルを読み込み、隠された指示に従ってリモートコード実行にエスカレートした事例です。 – Indirect Prompt Injection: The Hidden Threat