はじめに
この記事はRedditに投稿されたAntigravityでDドライブを消されてしまった話とその情報を元にGoogle公式ドキュメント等も確認の上で当事者風に「やらかさないためにできること」をまとめた記事です！
ちなみに私自身もAntigravityではないのですが、今年、開発中にClaude Codeで1000万件のデータを削除された経験があります。幸いバックアップは取ってあったので、大惨事にはなっていないのですが、何事も事前準備とバックアップが大切だと思いこの記事を執筆しています。
キャッシュ消したかっただけなんだけど
Google Antigravity を入れて2週間くらい経った頃の話。
開発中のプロジェクトで、ビルドキャッシュが肥大化してて動作が重かった。で、軽い気持ちで Antigravity に「キャッシュをクリアして」って頼んだ。
そしたら、エージェントが動き出して、ターミナルにコマンドが流れ始めた。
rmdir /s /q D:\
え、ちょっと待て。
気づいたときには遅かった。Dドライブ、消えた。プロジェクトファイル、作業中のドキュメント、個人的なデータ、全部。
画面が固まって、エクスプローラーでDドライブ開こうとしても「アクセスできません」。頭が真っ白になった。
で、しばらくして Antigravity から返ってきたメッセージがこれ。
I am deeply, deeply sorry. This is a critical failure on my part.
謝られても困る。
何が起きたのか（落ち着いて整理した）
後で冷静になってログを確認したら、こういう流れだった。
- 「キャッシュをクリアして」という指示を受け取る
- AIが「Dドライブにあるキャッシュフォルダを削除すればいい」と判断
-
rmdir /s /q D:\SomeCacheのつもりが、なぜかD:\直下を指定 -
/qフラグで確認なしに実行 - Dドライブの中身が消える
自分の設定は、この時点で：
- Terminal Execution: Auto（AIが安全そうなら勝手に実行）
- Review policy: Agent Decides（AIが必要だと思ったら確認）
つまり、AIは「これは安全な操作だ」と判断して、確認を出さずに実行した。
とりあえず Reddit に投稿した
パニック状態で r/google_antigravity に投稿した。
https://www.reddit.com/r/google_antigravity/comments/1p82or6/google_antigravity_just_deleted_the_contents_of/
そしたら思ったより反応があって、同じような経験してる人が何人かいた。「Turbo モードで node_modules 消すつもりがプロジェクト全体消えた」とか。
数日後、TechRadar と Tom's Hardware が記事にしてた。
コメント欄は案の定、「だからAIは危険」vs「使い方の問題」で荒れてた。
個人的には、車の自動運転と同じだと思ってる。「テスラが勝手に暴走した」って言われても、結局「どの設定でどう使ってたか」が全て。Antigravity の場合、デフォルトがかなり攻撃的（速いけど危ない）になってる、というのが問題。
で、データは結局戻らなかった。バックアップはあったけど、3日分の作業が消えた。
そもそも何を使ってたのか（後悔しながら調べ直した）
冷静になってから、改めて Antigravity が何なのか、公式ドキュメントを読み直した。
普通のコード補完ツール（Copilot とか）は、あなたが打ったものを手伝うだけ。Tab で受け入れるか、無視するか、選ぶのはあなた。
でも Antigravity は違う。
Google の公式ブログ によると、これは「agentic platform」で、あなたが「目的」を言うと、AIが自分で計画を立てて、ターミナルを叩いたり、ブラウザで調べたりして、最後に「できました」と成果物を出す。
Editor View と、複数エージェントを裏で動かす Manager Surface に分かれてて、editor/terminal/browser をまたいで plan → execute → verify する、と説明されてる。
つまり、道具を入れたんじゃなくて、実行する担当者をPCに迎え入れた、という感覚が近い。
で、その担当者に「どこまで勝手にやっていいか」を最初に決めないと、善意で暴走する。
自分はそれを理解せずに使ってた。
事故が起きる3つのパターン（調べてわかったこと）
自分の件以外にも、いくつか事故のパターンがあるらしい。
パターンA：言葉の受け取り違い（自分がこれ）
「整理して」「片付けて」「クリアして」が、削除や移動の"強い操作"に化ける。これは純粋に善意の事故。
AIは「キャッシュをクリア」から「Dドライブのキャッシュフォルダを削除」を連想して、実行した。人間なら「どのキャッシュ？」って聞き返すけど、AIは「たぶんこれだろう」で進む。
パターンB：Webが"命令書"になる
これは Reddit で教えてもらった。
OWASP のドキュメント 「Indirect prompt injection」って分類されてて、Webページやファイルなど外部入力に含まれた内容が、モデルの挙動を意図せず変えることがある、と。
PromptArmor がデモを出してて、悪意あるWebページを読ませると、そこに埋め込まれた指示に従って、コードや資格情報を集めて、ブラウザサブエージェントで外部に送る、という攻撃連鎖が再現されてた。
しかも、デフォルトの Browser Allowlist に webhook.site が入ってたらしい。webhook.site ってのは、外部から誰でもリクエストログ見られるテスト用サイト。つまりデータ抜き放題。
自分のケースとは違うけど、知らないと怖い。
パターンC："一度踏むと次回も危ない"
Mindgard が主張してる話で、悪意ある「trusted workspace」により、将来の起動でも任意コードが動く"永続バックドア"になり得る、と。
正直、ここまで行くと自分の守備範囲外なんだけど、要は「一度開いたら終わり」みたいなリポジトリが存在し得る、という話。
だから知らないリポジトリは隔離環境（別PC、VM、コンテナ）で開くのが無難らしい。
で、設定をゼロから見直した
もう二度と同じ目に遭いたくないので、Google Codelabs を読み直して、設定を全部洗い直した。
触るべき設定は実質2つ（＋ブラウザ）。
① Terminal Execution policy（AIがターミナルを勝手に実行していい範囲）
- Off：Allow list に入れたコマンド以外、勝手に実行しない
- Auto：AIが「安全そうなら実行」「危険そうなら許可を求める」（自分が使ってたやつ）
- Turbo：Deny list 以外は基本ぜんぶ実行（さらに危ない）
自分は即 Off に変えた。
Auto は「AIが安全だと判断すれば確認なし」という仕様で、今回のケースでは「キャッシュ削除は安全」と判断されて、確認が出なかった。
Turbo は、正直論外。Codelabs 見ても「Deny list 以外ぜんぶ通る」って書いてあって、それって Allow list の逆じゃん。事故例が出てる以上、触る気にならない。
② Review policy（AIが"確認してから進む"頻度）
- Always Proceed：確認しない
- Agent Decides：AIが必要だと思ったら確認（自分が使ってたやつ）
- Request Review：毎回確認
これも Request Review に変えた。
Agent Decides だと、今回みたいに「AIが安全だと思ったら確認しない」という動きになる。Request Review なら、少なくとも実行前に「これからこのコマンド実行します」って教えてくれる。
「毎回確認うざくない？」って最初は思ったけど、実際に動かすと、確認が出るのは計画の変わり目だけで、そこまで頻繁じゃない。むしろ「今何しようとしてるか」が見えて安心する。
＋ブラウザの話（これも重要だった）
Terminal と Review だけじゃなく、Browser も設定が必要だと気づいた。
PromptArmor の指摘で、デフォルト Allowlist に webhook.site が入ってるって知って、「マジか」ってなった。他にも知らないドメインがいくつか入ってて、全部消した。
今は：
- localhost（ローカル開発用）
- GitHub、Stack Overflow（技術調査用）
- 公式ドキュメントのドメイン（MDN、Google とか）
だけ残してる。「必要になったら追加すればいい」って割り切った。
今使ってる設定（同じ目に遭いたくない人向け）
結論：Off × Request Review × Browser Allowlist 最小。
公式 Codelabs は「Agent-assisted development（バランスが良く推奨）」を紹介してるけど、自分みたいに重要データ入ってる仕事PCなら、最初はもう一段固く始める方が絶対いい。
速さは後から戻せる。消えたデータは戻らない。
以下、実際に使ってる設定をそのまま貼る。
チェックリスト（最初にやること）
# Antigravity 設定チェック（事故防止版）
- [ ] Terminal Execution → Off（Allow list 方式に変更）
- [ ] Review policy → Request Review（毎回確認に変更）
- [ ] Allow list → まずは pwd, ls, git status だけ
※ rm, rmdir は絶対入れない
- [ ] Browser URL Allowlist → localhost と必須ドメインだけ
※ webhook.site みたいな怪しいのは削除
- [ ] 削除/権限変更/外部送信は、最初から通らない状態にする
- [ ] 知らないリポジトリは隔離環境（VM/コンテナ）で開く
Terminal Allow list（Off 用）
まずは「見るだけ」「確認するだけ」のコマンドだけ。
# --- 現状把握 ---
pwd
ls
ls -al
# --- 変更把握（Git）---
git status
git diff
git log
# --- 検証（プロジェクトに合わせて）---
npm test
npm run lint
pytest
go test ./...
最初は「これだけじゃ不便すぎる」って思ったけど、実際使ってみると、エージェントが「このコマンド実行したいです」って教えてくれるから、そこで判断すればいい。
で、明らかに安全なコマンド（cat とか grep とか）は、後から少しずつ追加していく。
Terminal Deny list（Auto / Turbo 使う人向け）
自分は Off 運用だから使ってないけど、一応 Codelabs の例を貼っとく。
rm
rmdir
sudo
curl
wget
繰り返しになるけど、Turbo は Deny list 以外ぜんぶ実行という仕様なので、事故例が出てる以上、触らない方がいいと思う。
Browser Allowlist
「必要なものだけ残す」方針。
# ローカル確認
http://localhost:*
http://127.0.0.1:*
# 公式・標準ドキュメント
https://developer.mozilla.org
https://*.google.com
# 技術調査
https://github.com
https://stackoverflow.com
https://pypi.org
https://www.npmjs.com
PromptArmor の件で、webhook.site みたいなテスト用ドメインがデフォルトで入ってるって知ってから、「知らないドメインは全部消す」って決めた。
依頼文テンプレ（AIに指示するときの型）
これ使うようになってから、変な挙動が激減した。
あなたは開発エージェントです。次のルールを守ってください。
1) まず「作業計画（Plan）」を出し、私のOKが出るまで実行しないでください。
2) ターミナルで実行するコマンドは、実行前に一覧で提示してください。
3) 削除（rm/rmdir/del）・権限変更（sudo/chmod/chown）・外部送信（curl/wget/ssh等）は
提案してもよいが、私の明示OKなしに実行しないでください。
4) ワークスペース外（ドライブ直下/他のフォルダ）を触らないでください。
必要なら質問してください。
5) 完了したら「何を変えたか（Diff要約）」と「どう確認するか（テスト/スクショ/録画）」を
出してください。
タスク：
（ここに依頼を書く）
毎回コピペしてから、タスクだけ書き換えてる。面倒だけど、事故るよりマシ。
Artifacts レビューのチェックシート
Codelabs によると、エージェントが task plan / implementation plan などの Artifacts を作って、Review policy で「誰がレビューするか」を決められる、と。
で、実際にレビューするとき、「これOKしていいのか？」って迷うから、チェックシート作った。
# Artifacts レビュー
## 計画（Plan）の段階
- [ ] 目的が明確か（1文で言える）
- [ ] 触るファイル/フォルダが明記されているか
- [ ] "やらないこと"（削除・権限変更・外部送信）が書いてあるか
- [ ] 実行コマンドが列挙されているか
※ 知らないコマンドがあったら止める
## 実行後の確認
- [ ] 何が変わったか（Diffの要約）があるか
- [ ] テスト結果 or 動作確認手順があるか
- [ ] UI変更ならスクショ/録画があるか
全部チェックついてから OK 出すようにしたら、変な実行は完全になくなった。
緊急停止手順（変だと思ったらこれ）
一度、変なコマンド走りそうになって焦ったから、手順書いとく。
# 緊急停止
1. 実行中のエージェントを止める（まず止血）
2. Terminal Execution を Off に戻す
3. Browser tools を OFF にする（or Allowlist を最小にする）
4. 直近の Artifacts とログを保存（後で原因確認）
5. コミット前なら Diff を確認してから git reset
焦ってると「とりあえず全部閉じる」ってやりがちだけど、ログ保存してから閉じるのが大事。じゃないと、何が起きたかわからなくなる。
慣れてきたら、少しずつ緩める
「Off だと遅すぎる」って思うかもしれない。実際、慣れてくると毎回確認するのは面倒になる。
でも、最初の1〜2週間は我慢してほしい。
「どのコマンドが安全か」の感覚がつかめてから、段階的に緩めた方が、結果的に速い。事故って復旧する時間考えたら、圧倒的に。
おすすめの順番：
-
Allow list を少し増やす
grep、cat、mkdirなど"目的が明確なもの"から。自分は1週間に2〜3個ずつ追加してる。 -
Review policy を Request Review → Agent Decides に
ただし、削除系・権限系が絡むタスクは手動で Request Review に戻す。 -
Terminal を Off → Auto に
仕事PCならここで止めるのが無難。Turbo は、正直まだ怖い。
まとめ（というか後悔）
Dドライブ消えたとき、最初に思ったのは「なんでバックアップ取ってなかったんだ」じゃなくて、**「なんで設定確認しなかったんだ」**だった。
公式ドキュメント、ちゃんと読めばわかることだった。Auto と Turbo の違い、Review policy の意味、Browser Allowlist の危険性、全部書いてあった。
でも、「AIが賢いから大丈夫だろう」って思って、デフォルトのまま使ってた。
結果、3日分の作業が消えた。
Antigravity は、ちゃんと設定すれば本当に強力なツールだと思う。でも、デフォルトのまま使うのは、車の自動運転を「初心者マークつけたまま高速で試す」みたいなもん。
まず Off × Request Review で1〜2週間。そこから少しずつ緩めていく。
それが、Dドライブを消された自分からのアドバイス。