Antigravity の Workspace Indexing が大規模リポジトリで完了しないときの原因と対処

個人開発で 2014年から積み上げてきた iOS / Android のアプリ事業は累計5,000万ダウンロードに達しましたが、そのぶんリポジトリも年々重くなりました。コードと素材を合わせると 12 GB を超え、node_modules を抜いても 380 万ファイル弱あります。このモノレポを Antigravity で開いた瞬間に、画面右下の Indexing のスピナーが 40 分回り続けたまま終わらず、エージェントに ./apps/wallpapers/src/store/category.ts を読ませようとしても「still indexing workspace」としか返ってこない、という状況に何度かぶつかりました。

廣川という同じ立場の個人開発者として、Antigravity の Workspace Indexing が大規模リポジトリで詰まる理由と、私自身が実務で落ち着いて使えるまでに辿り着いた対処の手順をまとめます。手元の環境は執筆時点で macOS 15.4 / Antigravity v0.34 / M2 Pro 32GB です。

症状の見分け方

Indexing が「重い」のか「壊れている」のかを切り分けることが最初のポイントです。次の三つはまったく違う問題なので、対処も別になります。

第一に、Indexing は走っているが時間がかかっているだけの状態。CPU の利用率が継続的に 200〜400% 程度、メモリは右肩上がりではなく一定、ディスク IO はずっと走っている、という挙動です。これは待てば終わります。

第二に、Indexing が CPU を食わずに止まっている状態。Activity Monitor で antigravity-helper (Renderer) のスレッドが Idle/Wait、Console.app に EAGAIN や EMFILE が並んでいるなら、これは外部要因で詰まっています。

第三に、Indexing が無限ループしている状態。CPU は高い、しかしファイル数がいつまで経っても進まありません。出力ログに同じパスが何度も書き出されている場合は、シンボリックリンクの循環や、書き込みファイルウォッチャと再インデックスが噛み合っていない可能性が高いです。

サイドバーのスピナーだけを見て判断するのは難しいので、Antigravity → View → Output → Antigravity Indexer を開き、最後の数十行が何を語っているかを必ず確認します。

原因 1: 自動除外の対象に入っていないキャッシュ群

Antigravity は .antigravityignore と .gitignore を参照しますが、リポジトリ直下に置かれていない場合は反映されません。私のモノレポでは Xcode の DerivedData を ~/Library/Developer/Xcode/DerivedData から ./build/DerivedData にシンボリックリンクしており、ここに 4.2 GB / 90 万ファイルが積み上がっていました。これが除外対象に入っておらず、Indexer がそれを 1 ファイルずつ読み込もうとしていたため詰まっていたわけです。

対処は単純で、ワークスペース直下に .antigravityignore を一つ置き、よくある重い対象を一気に外します。

cat << 'IGNORE' > .antigravityignore
# Build artifacts
build/
dist/
out/
.next/
.turbo/
.cache/
 
# Native build outputs
DerivedData/
.gradle/
.cxx/
Pods/
android/.cxx/
android/app/build/
ios/build/
ios/Pods/
 
# Dependency caches
node_modules/
.pnpm-store/
.yarn/cache/
.yarn/install-state.gz
vendor/
.bundle/
 
# Media that won't help the agent
assets/raw/
assets/originals/
*.psd
*.sketch
*.fig
*.mp4
*.mov
 
# Database & coverage
*.sqlite
*.duckdb
coverage/
playwright-report/
test-results/
IGNORE

書き換えた後は Antigravity を再起動するか、コマンドパレット (⌘⇧P) から Antigravity: Reindex Workspace を実行します。再起動を挟まないと、古いインデックスがメモリに残ったまま走り続けて改善が見えないことがあります。

原因 2: シンボリックリンクの循環

node_modules をプロジェクト間で共有するために手動でシンボリックリンクを張っていたり、pnpm の workspace 設定が想定外のパスを指していたりすると、Indexer が同じディレクトリを延々と辿り直す状態になります。

確認は、ワークスペースのルートで find を打つのが速いです。

# Symlinkを全列挙
find . -type l -not -path "./node_modules/*" -not -path "./.git/*" \
  -exec ls -la {} \; 2>/dev/null
 
# 循環していそうなものだけ
find . -type l -not -path "./node_modules/*" \
  -exec sh -c 'realpath "$1" 2>/dev/null | head -c 200; echo " <- $1"' _ {} \;

不要なシンボリックリンクは削除するか、.antigravityignore で明示的に弾きます。私の場合は ./shared -> ../shared-lib の構造を pnpm の workspaceRoot に変更し、シンボリックリンクは置かない構成に直しました。Indexer の進行が安定しただけでなく、エージェントが import 文を読むときの推論精度も上がりました。

原因 3: ファイルディスクリプタ上限

macOS の EMFILE: too many open files は、Antigravity の Indexer ではかなりよく出るエラーです。デフォルトの ulimit -n は 256 で、これはモノレポに対しては足りません。

ulimit -n
# → 256 が返ってきたら確実に足りない

恒久的に上げるには ~/Library/LaunchAgents/limit.maxfiles.plist を作成して再起動するのが王道ですが、まず動かして検証したい場面が多いので、Antigravity を起動するシェルで都度設定する方法から試します。

# 一時的に引き上げ
ulimit -n 65536
 
# このシェルから Antigravity を起動
open -a "Antigravity" .

私の環境ではこれだけで Indexer が 24 分から 3 分に短縮されました。EMFILE を出さなくなったので、副次的にエージェントの read_file ツールがハングする現象も同時に消えました。

原因 4: アンチウイルス・バックアップソフトとの競合

Time Machine、Backblaze、企業配布の EDR が同じディレクトリを舐めていると、Indexer が読み込んだ直後にファイルロックを取られて読み込み直しが発生し、結果として CPU だけが食われて進まないことがあります。

対処はシンプルで、Antigravity が開いているリポジトリのルートを、これらのソフトウェアの除外対象に入れます。Time Machine の場合は System Settings → General → Time Machine → Options → Exclude these locations から追加できます。プロジェクトルート全体を除外して問題がないかは事業ポリシーによりますが、開発中に頻繁に書き換わる場所はバックアップ対象から外しても痛みは少ないことが多いです。

原因 5: GPU エンベディングの初期化に失敗している

Antigravity v0.32 以降はワークスペース全体の意味検索のためにローカルでエンベディングを生成しますが、Metal の初期化に失敗すると CPU フォールバックが走り、これが恐ろしく遅くなります。Output → Antigravity Indexer に Failed to acquire Metal device, falling back to CPU のような行が出ていたら、これに該当します。

回避策は Settings → Antigravity → Indexer: Embedding Provider を Local (Metal) から Remote (Google) に切り替えるか、もしくは検索を諦めて Disabled にする方法です。私はノマド作業中の通信品質を考えて Remote ではなく Disabled で運用しており、その場合はエージェントに対して read this file: <path> のように明示的にパス指定するスタイルになりました。検索精度は落ちますが、待ち時間が読めるので結果として作業時間は短くなりました。

段階的な復旧手順

ここまでの原因切り分けをチェックリストにすると、私はおおむね以下の順で消化しています。

Antigravity: Reindex Workspace を一度実行する（一過性の不整合ならこれで解消する）
Output → Antigravity Indexer を開き、最後の 50 行を読む
.antigravityignore がリポジトリ直下にあるか確認し、ない場合は上の雛形を置く
シンボリックリンクを find -type l で列挙し、循環していそうなものを除外する
ulimit -n を確認し、256 のままなら 65536 まで引き上げて Antigravity を再起動する
Time Machine / バックアップソフトの除外設定にリポジトリを追加する
Embedding Provider を Remote か Disabled に切り替える
それでも改善しなければ ~/Library/Application Support/Antigravity/Indexes/<workspace-hash> を削除して、まっさらな状態から作り直す

最後のインデックスキャッシュ削除は、上から順に試して最後の手段として使います。削除した後は数十分の再構築時間がかかるので、寝る前か離席前のタイミングを選ぶのが現実的でした。

予防策

私が普段気をつけているのは、新しいプロジェクトを Antigravity で開く前に .antigravityignore の雛形を必ず置く、という一点に尽きます。ビルド成果物は人間の目で見ないので、Indexer に読み込ませる意味はほぼありません。これだけで Indexing にかかる時間が一桁短くなる場合もあります。

もう一つは、エンタープライズ向けに配布された EDR が動いている会社の Mac で作業するときは、最初から Embedding Provider を Remote に倒しておくことです。Metal アクセスが許可されていない端末で延々と CPU フォールバックを引いて時間を溶かす、というのは何度かやってしまいました。

参考リンク

Antigravity 公式: Indexing performance tips
Apple Developer: limit.maxfiles.plist for macOS
関連: Rork で大規模モノレポのパフォーマンスを確保する

似た構造の問題に出くわすたびに、私自身もこの手順に立ち戻って一つずつ潰しています。同じ症状で困っている方の手間が、ほんの少しでも減りましたら幸いです。