Antigravity の Workspace Indexing が止まる・完了しない時の診断と修復手順

Antigravity を起動してプロジェクトを開いた直後、左下のステータスバーに「Indexing... 12%」と表示されたまま、何時間経っても進まありません。あるいは「Indexing complete」と出たはずなのに、エージェントに src/ 配下のクラス名を尋ねても「ファイルが見つかりません」と返ってくる。私自身、新しいモノレポを開いた時に何度かこの症状に遭遇し、その度に作業が止まってしまった経験があります。

Workspace Indexing は地味な仕組みですが、Antigravity の AI 体験を裏側から支えている柱の一つです。ここが詰まると、Tab 補完の精度低下、シンボル検索の不発、エージェントが「プロジェクトの構造を理解していない」回答を返すといった、ぱっと見では原因が分かりにくい症状が連鎖します。ここでは私が実際に試して効果のあった切り分け手順を、軽い対処から順にまとめました。

まず症状を「3 つのパターン」に分類する

闇雲にキャッシュを消す前に、自分の症状がどのタイプかを把握すると修復が早くなります。

パターン A — Indexing がそもそも始まらない／0% で止まっている

ステータスバーに「Indexing 0%」と出たまま、CPU もディスク I/O もほとんど動いていない状態です。プロセスが起動できていない、あるいは .antigravity/index/ ディレクトリの権限が壊れている可能性が高いです。

パターン B — 進捗は進むが完了しない／途中で止まる

20%、40% あたりまでは進むのに、ある時点から動かなくなります。大きなバイナリファイルや node_modules を巻き込んでしまっている、あるいは特定のファイルでパースエラーが起きてループしているケースが多いです。

パターン C — 完了表示が出るのにエージェントが認識しない

「Indexing complete」と表示されるのに、AI に対して getUserById のような既存関数の場所を尋ねると「見つかりません」と返ってきます。インデックスは構築されているがメモリ上のキャッシュに反映されていない、あるいは別ワークスペースの古いインデックスを参照している可能性があります。

パターン A の対処 — Indexing が起動しない場合

最初に確認したいのは、Antigravity がインデックス用の作業ディレクトリに書き込めているかどうかです。~/.antigravity/index/{workspace-id}/ 配下の権限を見ます。

# macOS / Linux の場合 — ディレクトリの権限と所有者を確認
ls -la ~/.antigravity/index/
 
# 該当ワークスペースのディレクトリだけ調べる
WORKSPACE_ID=$(cat ~/.antigravity/state/active-workspace.json | grep -o '"id":"[^"]*"' | head -1 | cut -d'"' -f4)
ls -la ~/.antigravity/index/${WORKSPACE_ID}/
# 期待出力例: drwxr-xr-x  10 yourname  staff   320  Apr 25 18:00 .

期待する出力は所有者が現在のユーザーになっていて、書き込み可能（u+w）であることです。root 所有や読み取り専用になっていたら、それが原因です。私の環境では一度 sudo で起動した経歴がある時にこの状態になり、以下のコマンドで復旧しました。

# 自分のユーザーに権限を戻す（macOS の場合は staff グループ）
sudo chown -R $(whoami):staff ~/.antigravity/index/
 
# 念のため書き込み権限も付与
chmod -R u+w ~/.antigravity/index/

権限を直しても起動しない場合、Antigravity を完全終了してから ~/.antigravity/state/indexer.lock を削除してみてください。プロセスが異常終了した時に lock ファイルが残り、次回起動時に「すでに動いている」と誤判定する症状を何度か見ました。lock ファイルを削除する際は、必ず Antigravity が完全終了している（ps aux | grep antigravity で残存プロセスがない）ことを確認してから行います。

パターン B の対処 — 進捗が途中で止まる場合

私の経験では、このパターンの 8 割は「インデックス対象に巨大ファイルが混じっている」ことが原因です。Antigravity の標準設定では node_modules、.git、dist/ などは除外対象ですが、ビルド成果物や生成されたコード、画像アセットなどがプロジェクト直下に置かれているとインデックス対象になってしまいます。

まずは .antigravityignore で明示的に除外します。

# .antigravityignore — プロジェクトルートに配置
# ビルド成果物
build/
out/
*.bundle.js
*.min.js
 
# 大きな生成ファイル
**/*.generated.ts
**/openapi-types.ts
 
# 画像・動画・データ
*.png
*.jpg
*.mp4
*.csv
*.parquet
 
# ベンダードコード
vendor/
third_party/

このファイルを置いてから Antigravity 側で「Workspace: Rebuild Index」コマンド（コマンドパレット Cmd + Shift + P から実行）を打つと、対象ファイルが一気に減って完了するケースがほとんどです。

それでも止まる場合、特定ファイルがパーサで詰まっている可能性があります。インデクサのログを ~/.antigravity/logs/indexer.log で確認すると、最後に処理していたファイルが分かります。

# 最後の 30 行で詰まり位置を特定
tail -30 ~/.antigravity/logs/indexer.log
 
# 「Parsing file: ...」で長時間止まっていれば、そのファイルが原因候補
# 期待出力例: Parsing file: src/generated/schema.graphql.ts (8.2MB)

私の場合は 8MB の自動生成された GraphQL スキーマファイルでパーサがメモリを使い果たして詰まっており、.antigravityignore で除外することで解決しました。生成ファイルは AI が読む価値がほぼない一方でインデックスのコストは高いので、最初から除外しておくのが得策です。

パターン C の対処 — 完了したのに認識されない場合

このパターンは、インデックスは構築されているのに「現在のセッション」が古いインデックスを参照しているケースが大半です。最初に試すのは Antigravity 自体の再起動ではなく、コマンドパレットからの「Workspace: Reload Index Cache」です。これでメモリ上のインデックスキャッシュだけがリフレッシュされます。

それでも改善しない場合、ワークスペース ID の重複が起きていないか確認します。同じフォルダ名で別の場所のプロジェクトを開いた時、内部 ID が衝突して古いインデックスを引き続けてしまう症状があります。

# ワークスペース一覧を確認
ls ~/.antigravity/workspaces/
 
# 同名ワークスペースの重複候補を抽出
ls ~/.antigravity/workspaces/ | sort | awk -F'-' '{print $1}' | sort | uniq -c | sort -rn | head
# 例: 「  3 my-app」のように 2 以上ある場合は重複あり

同じ名前のワークスペースが複数ある場合、現在使っていない側を削除するか、別名でリネームします。インデックスの整合性については AI 提案の品質低下を診断する手順でも触れていますが、ワークスペース ID の競合は特に気づきにくい原因なので、症状が長引いている時は最初に疑う価値があります。

大規模リポジトリで再発を防ぐ設定

繰り返し Indexing で困るプロジェクトには、最初から戦略的な設定を入れておくと安定します。

~/.antigravity/settings.json で以下のキーを調整できます。

"indexing.maxFileSize": 1 ファイルあたりの最大サイズ（バイト）。デフォルト 5MB を、生成コードが多いプロジェクトでは 1MB 程度に下げると安定します
"indexing.parallelism": 並列度。デフォルト 4 ですが、CPU が貧弱なマシンでは 2 にする方が体感は速いです
"indexing.includeSymbolsOnly": シンボル情報のみインデックスする省エネモード。本格的な検索が不要な閲覧用ワークスペースで便利です

例えば、私の手元で 30 万ファイルあるモノレポでは以下の組み合わせが安定して動きます。

{
  "indexing": {
    "maxFileSize": 1048576,
    "parallelism": 6,
    "includeSymbolsOnly": false,
    "excludeBinaries": true
  }
}

大規模リポジトリでのインデックス戦略全体は大規模コードベースのコンテキスト管理でも掘り下げているので、本記事の対処を済ませた後に読んでもらえると、症状の予防につながると思います。

インデックスやシンボル解析の仕組みを理解する上で、コードベースを「分割して見る」感覚の解像度が上がる一冊です。

全体を振り返って — まず試すべき一手

ここまで色々書きましたが、症状の見立てが付かない時にまず試して欲しいのは「コマンドパレットから Workspace: Rebuild Index を実行する」ことだけです。9 割の症状はこれだけで直り、残り 1 割が今回の各セクションで扱った深い原因です。

Workspace Indexing は普段意識しない仕組みですが、止まると AI 体験全体の信頼が一気に揺らぎます。今日の作業中に AI が急に的外れになったと感じたら、まずステータスバーで Indexing の状態を確認するところから始めてみてください。それだけで原因の切り分けが何段階か進みます。