概要
- 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ツールは、慎重な運用が必要