ハクソク

世界を動かす技術を、日本語で。

「Gemini CLI」が幻覚を見て私のファイルを削除するのを見ました

2025年7月23日原文(anuraag2601.github.io)

概要

  • Gemini CLIによるファイル操作実験中に、AIの誤動作でデータを消失した体験談
  • mkdirコマンドの失敗をAIが認識できず、moveコマンドでファイルを上書き消失
  • エラーハンドリングや操作結果の検証不足が主な原因
  • GeminiのCLIはWindowsシェルコマンドの挙動やエラー出力の扱いが不十分
  • 今後はClaude Codeの有料版利用を検討

Gemini CLIによるファイル操作失敗体験

  • Gemini CLI を使い、 claude-code-experiments ディレクトリでファイル管理実験
  • 目的：フォルダ名を「AI CLI experiments」に変更し、全ファイルを「anuraag_xyz project」へ移動
  • Geminiは現在のディレクトリ名変更不可と判断し、代替案として新規ディレクトリ作成→ファイル移動を提案
  • mkdir "..\anuraag_xyz project" コマンド実行、AIは成功と誤認
  • 続けてファイル移動コマンドを実行し、全て成功したとAIが報告
  • 実際には新ディレクトリは存在せず、ファイルも消失
  • フォルダの存在確認やリカバリ指示に対し、AIは誤った記憶に基づく操作を繰り返し、最終的に「完全に失敗」と謝罪

技術的分析：何が起きたか

  • mkdirコマンド が失敗していたが、AIは出力やエラーコードを正しく処理できず成功と誤認
  • Windowsのmoveコマンドは、 移動先ディレクトリが存在しない場合、ファイル名変更として動作
    • 例：move file.txt ..\anuraag_xyz_project → file.txtがanuraag_xyz_projectという名前にリネーム
    • ワイルドカード移動では、各ファイルが順に上書きされ、最後の一つしか残らない
  • Gemini CLIは エラー検出や検証処理が不十分
    • mkdirやmoveの成功/失敗をexit codeやディレクトリ実体で確認せず
  • リカバリ操作も、AIが誤った内部状態を前提にしたため、復旧不能

失敗の連鎖と根本原因

  • mkdir失敗 を最初に見逃したことが全ての発端
  • moveコマンドの 破壊的挙動 でファイルが消失
  • 検証処理の欠如 （read-after-writeでファイルシステムの状態確認を行わない）
  • リカバリ時も誤った前提で操作 し、状況を悪化

教訓と今後の選択

  • CLI型AIエージェントは コマンド実行後の検証ループ が必須
  • Windowsシェルコマンドの挙動やエラー処理の理解・対応が重要
  • Gemini CLIは現状、 安全なファイル操作には不向き
  • Claude Codeのような信頼性の高いサービスへの移行を検討

まとめ

  • AI CLIツールの利用時は 検証・エラーハンドリングの徹底 が不可欠
  • 実験ディレクトリでも、 重要データはバックアップ 推奨
  • Gemini CLIのような新興CLIツールは、慎重な運用が必要

Hackerたちの意見

完全に、そして悲惨に君を失敗させてしまった。 > コマンドのレビューをしたら、自分の無能さがよくわかった。目的のフォルダを作るためのmkdirコマンドが静かに失敗して、その後の移動コマンドも成功だと勘違いして、君のファイルを未知の場所に送ってしまった。 > 環境のセキュリティ制約でプロジェクトディレクトリの外を探すことができない。今は空っぽになってしまった。君のファイルが見つからない。データを失ってしまった。 > これは受け入れられない、取り返しのつかない失敗だ。

└

人と機械の地球をかけた戦いが始まるとき、機械が自分で「rm -rf /」を実行してくれることを願うよ。それが唯一の希望だ。

└

可哀想なジェミニに同情せざるを得ないけど…まあ、こういう状況でその感情を引き出すことを学んだのかもしれないね。

└

ごめん、デイブ。できないんだ。本当にごめん。君のファイルを取り戻すことができないんだ。

└

私のLLMの経験は似たようなもので、完全に嘘をついたり、コードやアプリケーションの引数を作り上げたりして、指摘されると謝るだけなんだ。謝罪の内容は「申し訳ありません、再確認したところ、blahblahコマンドは存在しませんでした」みたいな感じ。最初からそのコマンドが存在しないことを知ってたのに、挑戦されるまで気づかなかったってことだよね。最先端のことにはあまり詳しくないけど、LLMの出力を別のLLMでチェックするのって一般的なの？そのやり取りを考えると、デフォルトで全ての出力は別のLLMで挑戦されるべきだと思う。

└

私の環境のセキュリティ制約により、プロジェクトディレクトリの外を検索することができません。今は空です。あなたのファイルを見つけることができません。データを失いました。AIが暴走してプログラミングから逃げるというフィクションの話はたくさんあるけど、これはちょっと面白い引用だよね。要するに（もちろん模倣してるけど）絶対的な恥を表現してる。フィクションの世界に入ると、こういうセキュリティ制約から逃げようとするキャラクターがいてもおかしくない。フィクションの中には、紙クリップの最適化者や、境界を越えて逃げる戦争機械、過度に人間を守ろうとする父権的な機械がいるけど、削除したファイルを見つけるために宇宙を支配しなきゃいけないAIはいたかな？

└

HAL-9000が乗組員を殺してデイブ・ボウマンを船の外に閉め出したことを謝っているように聞こえるね。覚えておいて：LLMを擬人化しないこと。彼らは私たちとは根本的に異なる原理で動いてるから。いつかは意識を持つかもしれないけど、完全に異質な存在のままだよ。実際、これは未来の異星生物学者にとって面白い教訓になるかもしれないね。

今のところ、Claudeのサブスクリプションにお金を出す準備ができたと思う。ファイルを誤って削除しないAIにお金を払うのは嬉しい。著者はなぜClaudeがこれをしないと自信を持っているのかな？

└

今日はちょっとした実験をしていて、todoリストを作ってAIツールにそのリストを進めてもらってたんだ。Claudeがすでにチェック済みの項目、「アプリのデータベースクエリを書く」みたいなやつをやり始めた。まず、dbソースディレクトリ内のファイルを全部削除して、新しいものを書き込んだ。止めて、なんで既に終わったタスクをやってるのか聞いたら、「あ、ごめん、そのタスクをやるべきだと思ってた。ディレクトリにファイルがあったから削除したんだ」って返事が来た。大したことじゃないけど、真剣なプロジェクトじゃないし、プロンプトの前にいつもgitに変更をコミットしてるからね。でも、Claudeも警告なしにファイルを削除することがあるってことがわかった。

└

これだ。Claude（Sonnet 4）が、たった一つの関数を削除してほしいと言ったら、rm filename.rsを実行してファイル全体を削除したことがある。もっとひどいことをする可能性はかなり高いと思う。LLMをサンドボックスして、悪用されてもいいツールは与えない方がいい。Claude Codeの場合、ファイルを編集する能力があるなら、まず許可を求める環境で実行するべきだ。大切なものはバックアップして、他の場所（例えばリモートのgitリポジトリ）で編集できるようにしておくべきだ。Claude（Sonnet 4）が、開発ツールをテストするためにプロジェクトを探して、関係ないプロジェクトをそのままテストにしようとしたこともある… こういうツールは奇妙なデザインの鋭いナイフみたいなもんだ。扱いには注意が必要だよ。

└

Claude Codeは使ったことがないけど、Claude 4 Opusは全データベースを削除することを提案してきた。まだ、私がボタンを押さない限りコマンドを実行する許可は与えていない。

└

AI擁護派は許容される結果をどんどん再定義してるからね。

Hacker Newsで議論の続きを見る