サイドバーに並んだプロジェクトが増えてきた朝、使わなくなったものを片づけようとして、削除の操作の前で手が止まりました。押したあとにフォルダの中身がどうなるのか、自分の言葉で言えなかったからです。
同じところで迷っている方は少なくないようで、Zenn には「プロジェクトを削除するとファイルは消えるのか」を整理した Antigravity 2.0 のプロジェクトとフォルダの関係を扱った投稿 がありました。結論は「消えない」という内容です。ただ、書き手ご自身が、キャッシュの削除などは未確認だと明記しておられます。
最初にお伝えしておきますと、この記事でも、実際に削除ボタンを押して中身を比べる検証まではしておりません。代わりに、押す前に何も壊さずに確かめられることを、個人開発のリポジトリで使える形にしました。
「消えない」の中身を、二つの保存場所に分けて読む
その投稿の説明を私なりに整理すると、プロジェクトは「作業フォルダへの参照」で、データは二か所に分かれて置かれる、という話でした。
| 場所 | 入っているもの | 削除ボタンの影響 |
|---|---|---|
| 手元の作業フォルダ | ソースコード、.git、.agents/ や GEMINI.md などの指示ファイル | 消えない、と説明されている |
| Antigravity の内部領域（~/.gemini/antigravity/） | 会話履歴、思考ログ、生成物、プロジェクトごとの権限設定 | サイドバーの登録と紐づけが外れる、と説明されている |
ここで私が線を引いておきたいのは、「消えないと書かれている」ことと「消えないと確かめた」ことは別だという点です。投稿の例は Windows のパスで書かれており、macOS では ~/.gemini/antigravity に当たるはずですが、これもご自身の環境で ls して確かめるのが確実です。
押す前に言えるようにしておきたい「残るもの」は、私の場合は次の三つになりました。
- 作業フォルダの中の、コミット済みのソースコード
- まだコミットしていない変更と、Git に載せていないファイル
- エージェントへの指示ファイル（.agents/、GEMINI.md、AGENTS.md）
この三つのうち、二番目が盲点です。.env のように Git が無視しているファイルは、リポジトリから復元できません。削除の影響が及ばない設計だとしても、別の事故で失えば戻らないものですから、押す前に一度だけ存在を確認しておきたいのです。
何も消さずに、残るものを数えるスクリプト
次のスクリプトは読み取りしかしません。削除や移動は一行も入れておりません。
#!/usr/bin/env bash
# 削除前の点検（読み取り専用）。使い方: ./preflight.sh /path/to/project
set -u
proj="${1:?プロジェクトのフォルダを指定してください}"
echo "== 1. 未コミットの変更と未追跡ファイル（先頭 20 行）"
git -C "$proj" status --short | head -n 20
echo "== 2. Git が無視しているファイル（.env などは復元できません）"
git -C "$proj" status --short --ignored | grep '^!!' | head -n 20
echo "== 3. まだ push していないコミット"
git -C "$proj" log --oneline '@{u}..HEAD' 2>/dev/null | head -n 10
echo "== 4. エージェント向けの指示ファイル"
ls -d "$proj"/.agents "$proj"/GEMINI.md "$proj"/AGENTS.md 2>/dev/null
echo "== 5. 内部領域の容量（大きい順に上位 8 件）"
du -sh "$HOME"/.gemini/antigravity/* 2>/dev/null | sort -h | tail -n 8なぜこう書いたのかを、番号ごとにお伝えします。
1 番と 3 番は、「ソースコードは消えない」を信じたとしても、まだ手元にしかない変更が見えるようにするためです。2 番は、Git の外にあるものを拾うためで、ここに .env や鍵が出てきたら、別の場所に控えがあるかを先に見ます。4 番は、エージェントとの約束事を書いたファイルが作業フォルダ側にあることを、目で確認するためです。5 番だけは削除とは無関係で、あとで容量を空けたくなったときの地図になります。
小さなテスト用リポジトリで動かし、未追跡のファイルと、Git が無視している .env が、それぞれ出力に拾えることは確認しました。実際のプロジェクトでは、出力の量がもう少し多くなるはずです。
フォルダ名を OS 側で変えるときは、紐づけが切れる前提で
同じ投稿には、アプリ側での名前の変更は表示名が変わるだけで、Finder やエクスプローラーでフォルダ名を変えると紐づけが切れる、とありました。切れた場合は、新しい場所を開き直し、入力欄で @ を打って過去の会話を呼び出せば文脈を引き継げる、という手順です。
私自身はこの手順を、まだ本番のリポジトリで試しておりません。名前を変える前に会話の置き場所を確かめたいなら、プロジェクトの粒度や会話の命名をあらかじめ整えておくのが近道で、プロジェクトが十数個になった Antigravity で、目的の会話を探し回らないための整理手順 に、私が見直した順番を書き残しております。
容量を空けたいときは、エージェントに頼む前に
内部領域の容量が増えるのは、ブラウザ操作の録画や会話ごとの生成物が積み上がるためで、先ほどの投稿は数 GB から数十 GB に達することもあると書いています。空けたくなる気持ちはよく分かります。
ただ、「キャッシュを掃除して」とエージェントに頼む前に、一つだけ立ち止まっていただきたいのです。パスの解釈を誤って、思わぬ範囲を消してしまったという報告が出ています。この件は キャッシュを消すだけのはずが、ドライブごと消えた報告を読んで。削除だけは関所を通すことにしました に、削除の届く範囲を機械で狭める方法をまとめました。
順番としては、アプリの会話履歴から不要な会話を削除する、それで足りなければ容量の大きい場所を du で確かめる、手で消すのは最後、と考えています。また、会話データの置き場が SQLite の場合、消しただけではファイルが縮まないことがあり、その見分け方は Antigravity CLI の会話データベースは、重複を消しても 1 バイトも縮みません に書きました。
押す前の一文
残るものを三つ言えるようになってから、削除を押します。 私が決めた線引きは、これだけです。
まずは、いちばん使っていないプロジェクトのフォルダに、上のスクリプトを一度だけ流してみていただければと思います。出力に見覚えのないファイルがなければ、そのときは安心して片づけられます。