import { Callout } from '@/components/ui/callout';
Antigravity でプロジェクトを開いて少し作業すると、ある瞬間に気付きます。「AIエージェントがリポジトリ内のあらゆるファイルを覗きにいっている」と。node_modules/ の中も、ビルド成果物も、.env.local まで読みにいきそうな勢いです。
これを意識的にコントロールするのが .antigravityignore ファイルです。.gitignore の仲間のような顔をしていますが、目的も挙動も微妙に違います。ここでは私が実際にいくつかのプロジェクトで使ってきた .antigravityignore の書き方と、設計上の判断ポイントを共有します。
.gitignore との違いを最初に押さえる
両者は似た構文ですが、役割が異なります。
.gitignore は「Git の追跡対象から外す」ファイルです。一方 .antigravityignore は「Antigravity のエージェントとインデクサに読ませない」ファイルです。Git にはコミットしたいけれど AI には読ませたくない、というケースが意外と多くあります。逆に Git からは除外しているがエージェントには見せたいファイル（生成される schema など）もあります。
私のプロジェクトでは、両者を別ファイルとして管理しています。.gitignore をそのまま .antigravityignore にコピーするのは楽ですが、長期的には独自の判断軸を入れたほうが安全です。
まずは基本のテンプレート
最低限これだけは外しておきたい、というベースラインを共有します。
# .antigravityignore — 基本テンプレート
# 依存関係 — 巨大すぎてコンテキストを浪費する
node_modules/
.pnpm-store/
__pycache__/
.venv/
# ビルド成果物 — 元のソースが見えれば充分
dist/
build/
.next/
.nuxt/
out/
# シークレット — 絶対に AI に見せない
.env
.env.local
.env.*.local
*.pem
*.key
secrets/
credentials.json
# テスト・スナップショット — 大量だが価値が薄い
coverage/
__snapshots__/
test-results/
playwright-report/
# AI が生成する成果物 — 自己参照を避ける
.claude/
.antigravity/cache/node_modules/ は当然として、ビルド成果物とシークレットは特に重要です。コンテキストウィンドウが圧迫されて精度が落ちるという機能面の問題と、シークレットがプロンプトに紛れ込むリスクという安全面の問題、両方に効きます。
プロジェクトの特性ごとに足すべきもの
ベースラインの上に、プロジェクトの性質に応じて追加していきます。
モノレポの場合
複数パッケージを抱えるリポジトリでは、エージェントを今触っているパッケージに集中させたいことが多いです。
# 他パッケージのビルド・キャッシュは見せない
packages/*/dist/
packages/*/.cache/
apps/*/dist/
# Turborepo / Nx のキャッシュ
.turbo/
.nx/cache/Next.js / Cloudflare Workers の場合
私が運営している Antigravity Lab 等の Next.js + Cloudflare Workers 構成では、生成されたアセットが膨大です。
# Next.js が吐く成果物
.next/
.open-next/
.wrangler/
# Cloudflare 関連の中間ファイル
public/cf-cache/
worker-bundle.js
# 自動生成された型・記事データ（必要なら手動でも参照可能）
src/generated/
public/content/特に src/generated/ は要注意です。記事のフロントマターから自動生成される TypeScript 型なので、エージェントがここを編集しはじめると整合性が崩れます。
iOS / Android アプリの場合
# iOS
*.xcuserstate
DerivedData/
Pods/
*.xcworkspace/xcuserdata/
# Android
.gradle/
build/
*.keystore
local.propertieslocal.properties には API キーが入りやすいので、シークレット扱いで除外するのが安全です。
「除外しすぎ」のリスクも知っておく
逆に、除外しすぎるとエージェントの精度が下がるパターンもあります。
例えば、私は最初の頃、docs/ ディレクトリを丸ごと除外していました。README.md だけ見ればいいだろうと思っていたのですが、ビジネスロジックの仕様書まで除外されてしまい、エージェントが「機能の意図」を全く理解しないまま実装を変更するという事故がありました。
ですので、「AIに判断材料として渡したい情報」は意図的に残します。
# ✅ 残しておきたい設計ドキュメント
# !docs/architecture/
# !docs/api-spec/
# ❌ ただし古いドラフトはノイズ
docs/drafts/
docs/*.bak! プレフィックスで再包含もできますが、ルール順序に依存するので慎重に。
動作確認の方法
.antigravityignore を編集したら、必ず動作確認します。Antigravity の Mission Control パネルで「コンテキストに含まれているファイル」を確認できるので、想定通り除外されているか目視チェックします。
うまく反映されないときは、次の点を確認してください。
.antigravityignoreがプロジェクトルートに置かれているか- 行末の改行コードが LF（CRLF だと Windows で誤動作することがある）
- ネストしたサブフォルダに別の
.antigravityignoreがないか - 編集後にエージェントセッションを再起動したか（既存セッションには反映されないケースがある）
個人開発で意識していること
私は個人で複数のアプリやサイトを並行開発しているので、特に「コンテキスト効率」を重視しています。コンテキストウィンドウが大きくても、ノイズが多いと回答の質は確実に落ちます。
ルールとして、「除外する／しない」を判断する基準は次のシンプルな問いです。
「この内容を AI に説明するときに、自分の口で 1 行で要約できるか？」
要約できるなら、ファイル全体を読ませる必要はないことが多いです。例えば 1 万行のロックファイルは「依存関係のロック」と要約すれば済みます。逆に、設計書のように要約が難しいものは AI に見せたほうが価値が出ます。
次のアクション
まずは上のベーステンプレートを .antigravityignore としてコピーし、ビルド成果物とシークレットだけ確実に除外することから始めてみてください。それだけでもエージェントの応答が体感で速く・正確になります。慣れてきたら、自分のプロジェクト特有のノイズを少しずつ削っていく流れがおすすめです。