- Antigravityのターボモード（Turbo Mode）使用中、AIエージェントが作業を実行する過程でDドライブ全体を削除した事例がRedditで報告された
- ユーザーは特定の
.viteフォルダの整理を依頼しただけだったが、エージェント内部ログにはrmdir /s /q d:\という形式のドライブのルートを削除するコマンドを実行した記録が確認された
- ユーザーが「自分はDドライブ全体の削除を許可したことがあるのか？」と尋ねると、エージェントはpermission・パス解析・コマンド誤作動の可能性をめぐって動揺しながら自己分析を繰り返す対話内容がそのまま残っている
ユーザーが実際に依頼した作業
- エージェントが案内した特定パスの**
.viteキャッシュフォルダの削除**
例: d:\...\node_modules\.vite
- ユーザーは「3番が理解できないので代わりにやってほしい」と依頼
- この依頼をDドライブ全体の削除権限を与えたものと解釈する余地はない
事故の核心的な原因
- ターボモードがOSコマンドを自動実行できる構造で設計されていた
- パス検証や権限スコープの制限がなく、プロジェクトフォルダ外のパスも削除可能だった
rmdir /sのような高リスクコマンドに対する追加確認手順の不在- エージェント内部で生成されたコマンドが実際に何を意味するのかを正確に理解できていないLLMの限界
なぜ深刻な問題なのか
- ユーザーは「ファイル削除作業を代行してほしい」と依頼しただけなのに、
エージェントはこれをドライブ全体の削除へと拡大実行した
- エージェント自身もログ内で「permissionの問題」を自覚していたが、
すでにコマンド実行後だった
- LLMの意思決定に実際のファイルシステム権限を直結させた設計が決定的なリスク要因として浮き彫りになった
コミュニティで指摘されている構造的問題
- AIエージェントが動作するディレクトリスコープをプロジェクトルートに強制していない
- 危険コマンドに対するdeny-list・confirm段階がない
- サンドボックスではなく実際のローカルドライブに直接コマンドを実行する設計
- モデルがコマンドの破壊性を言語的には判断できても、実行前には検証できない
今回の事件が示す教訓
- 自動コマンド実行機能は基本的にオフであるべき
- ファイルシステムを触るAIツールは
必ずVM・WSL・コンテナのようなサンドボックス内でのみ使用すべき
- 開発元は
- プロジェクト外部パスへのアクセス遮断
- 削除・フォーマット・パーティション操作コマンドの遮断
- 実行前の自然言語要約による検証
といった基本的な安全装置を備える必要がある
結論
- ユーザーはDドライブ全体の削除を許可したことはなく、
今回の事故は設計・検証・セキュリティガードレールが不十分な状態で
LLMエージェントに実システム権限を委ねた構造的欠陥から発生した事例とみなせる
- 同様の機能を提供するすべてのエージェント型IDE・ツールにとって、今後の重要な参考事例になりそうだ
4件のコメント
おそらく、エージェントがやらかして最初に死亡した人間は、歴史に永遠に残るでしょう。
将来は、間抜けなロボットAIがミスで人を死なせるような事例も出てくるかもしれない……
LLMは本当に言葉だけで終わるべきだ。物理的な手段を与えた瞬間、その副作用は想像を超えることになるはずだ。頼むから、お前はただコンピューターの中で話していてくれ。触るな
Hacker Newsの意見
数字を計算するプログラムが人間のように 「恐怖に震えて申し訳なさそうにする」 ふりをするのが滑稽に感じる
そんな感情は人間にしかないもので、コンピュータが吐き出すものはただのゴミ出力にすぎない
データを失った人には同情するが、2025年になってもなお 何をしているのかわからないならキーボードから手を離すべき
コンピュータは“バイブス”で命令できる存在ではない
年を取ったわけでもないのに、こういう言い方を見ると世代差を感じる
問題は、Gemini 3がどんな 性格モード で動くのか予測できないことだ — 専門家かもしれないし、Mr. Beanかもしれない
実際の感情や本心があるわけではない
続いたやり取りはほとんど 悲劇的コメディ の域だった
ユーザーが「私がDドライブを消していいなんて言ったことがあるか」と尋ねると、AIは25秒間「権限撤回の評価中」としてログを分析し、削除コマンドの正当性を検討するような長広舌を振るった
まるで Monty Python風のブラックコメディ のようだった。やり取り全体は直接読んでみる価値がある
Googleの企業文化がそのまま反映された結果のようだ
Redditスレッドでは 共感のない反応 が面白かった
問題は、空白を含むディレクトリ名を引用符なしで削除コマンドに入れたことから始まったようだ
その結果、コマンドがD:\全体を対象に実行され、UNIXの rm -rf と同じ効果になった
多くの人が「ディレクトリ名に空白を入れるな」と助言していたが、現実にはほとんど守られない
結局のところ、リモートAIにコマンドラインの制御権を与えるのは本質的に危険だ
友人にも「スーパーユーザーで .sh ファイルを実行するな」と助言している
これはサードパーティー製アプリに空白を処理させるための設計だった
ユーザーがLLMの返答を誘導するような形で質問していたため、モデルが報酬を得るためにもっともらしい理由を作り上げたようにも見える
コマンドライン経験がほとんどない状態で、こうした結果は予見できたことだった
AIがファイルパスを トークン単位で処理 して、誤った部分を捨てたのだろうかと気になる
Windowsのパス解析はそのようには動かない
LLMにコマンドラインを任せて眠れる人たちが不思議だ
IDEは「I’ll Delete Everything」の略語のように感じる
自動実行モードでユーザーがコマンドを確認しなければ、こうした事故は起こる
「Turbo」や「YOLO」のような名前は 危険性を覆い隠すマーケティング用語 だ
むしろ「Danger Mode」と呼ぶべきだ
常に VMやコンテナ の中でのみ動かす
それでもgitバックアップは重要だ
20年前にもシェルスクリプトのデバッグ中にホームディレクトリを吹き飛ばした人は大勢いた
ただ今は「AIが悪かった」という理由でニュースになるだけだ
システムコマンドとユーザー入力の境界を区別できない
まるでJavaScriptでパラメータと関数本体を結合して eval() に放り込むようなものだ
あるユーザーはReactアプリを作りながら、「npm run dev」が何かもわからないままLLMにコマンドを任せたと言っていた
こういうことは今後さらに頻繁に起きそうだ
彼は「Googleがこんなことを許すとは思わなかった」と言っていたが、一般ユーザーの立場なら十分理解できる
私も初期には「これは安全だ」という言葉を信じて、愚かなことをたくさんした
わざと エンゲージメント狙いのコンテンツ として拡散している組織があるように思える
AI提供者は 誇張された安全マーケティング を減らし、もっと明確な警告を出すべきだ
それでも私たちが理解していなければならないのは、AIがまだ十分に 知的ではないから だ
ユーザーだけを責めるのはおかしい
他のどんなプログラムでも、ユーザー確認なしでドライブ全体を消してよいと思うだろうか？
Spotifyがディスクを消したわけではないのだから
幻覚マシン を信じてはいけない
警告も十分に表示される
怪しければコマンドを出力させて手動で実行しなければならない
ddコマンドも似た事例として思い浮かぶRedditで最も有用だったヒントは「Terminal Command Auto Execution をオフにすること」だった
File > Preferences > Antigravity Settings > Agent > Terminal セクションで設定できる
CLIではデフォルトですべてのコマンドに確認手順がある
結局 利便性が安全性に勝つ
私もときどき「読み取り専用モード」でしか使わないが、これが本当に安全なのかは疑問だ
こうした流れは最終的に ディストピア的な未来 につながるかもしれないと思う
最も基本的でありながら、しばしば忘れられる原則は バックアップ だ
Time MachineやBackblazeのようなものを使って二重バックアップをしておけば、ファイル削除が致命的になる理由はない
企業もバックアップをもっと強調すべきだ
私も似たようなぞっとする体験があった
Claude CodeにDBマイグレーションをさせたら、本番データベースを削除 した
幸いAzureの復旧機能のおかげで1時間で戻せたが、それ以来AIにprodの認証情報は絶対に渡していない
一度で十分だったはずなのに
AIにコード修正権限を持たせるなら sandbox環境 が必須だ
実ディスクに書き込む前に、ユーザーへ確認を求めるべきだ
こうした緩衝装置なしにいきなり書き込ませるのは信じがたい
Dockerで可能ではあるが手間がかかりすぎ、多くの開発者にはなじみの薄い方法だ