Antigravity の CPU・メモリ使用率が高すぎるときの原因と対処

Antigravity で Next.js プロジェクトを 1 時間ほど触ったあと、MacBook のファンが「ゴォォォ」と回り続け、バッテリー残量が一気に 40% を切ったことがあります。Activity Monitor を開くと Antigravity Helper (Renderer) と Antigravity Helper (Plugin) の 2 プロセスがそれぞれ 120% 以上 CPU を使い、常駐メモリは合計 4.8GB。プロジェクト自体はそんなに大きくないはずなのに、なぜこんなに重くなるのか。

結論を先に言うと、Antigravity が重くなる原因のほとんどは「どのサブプロセスが暴走しているか」を特定すれば絞り込めます。ここでは症状ごとに原因プロセスを見分ける方法と、それぞれに効く具体的な設定変更をまとめます。

まず「どのプロセス」が重いのかを特定する

Antigravity は Electron 系の構造を取っており、実行中は複数のプロセスが同時に走っています。トップレベルで CPU を食っているプロセス名を見れば、原因領域はほぼ特定できます。

macOS と Linux では、次のコマンドが最も速く当たりを付けられます。

# CPU 使用率の高い順に Antigravity 関連プロセスだけ抽出
ps -eo pid,pcpu,pmem,comm | grep -i antigravity | sort -k2 -rn | head

出力例と、そこから読み取れる意味は次のとおりです。

Antigravity Helper (Renderer) が暴走: UI レイヤー（エディタ描画・大量のタブ・シンタックスハイライト）が重い
Antigravity Helper (Plugin) が暴走: 言語サーバー（TS Server, Pylance, rust-analyzer 等）が再解析を繰り返している
Antigravity Agent / agent-runtime が暴走: エージェントが無限ループ、または長いコンテキストを毎ターン送信している
node 子プロセスが大量発生: MCP サーバーが数十個同時起動している、もしくは終了に失敗して残っている

Windows の場合は、タスクマネージャーの「詳細」タブで Antigravity.exe を右クリックし「プロセスツリーを展開」すると、同じ分類が見えます。

どのプロセスが主犯かを決めずに「設定を片っ端から変える」と、原因と違う領域をいじって時間を溶かすことが多いです。最初の 30 秒はプロセス名を確定することに使うのが、結局いちばん早い近道です。

UI（Renderer）が重いとき — ファイルタブと拡張機能を削る

Renderer プロセスが常時 80% を超えている場合、最初に疑うのは「開きっぱなしのタブ」と「Web ビュー系拡張機能」です。

開いているタブを 1 桁台に抑える

Antigravity のタブは軽量に見えて、シンタックスハイライト・Minimap・Git Lens 表示・リアルタイムリンティングがそれぞれバックグラウンドで走り続けます。20 ファイルを開いた状態と 5 ファイルに絞った状態では、アイドル時の Renderer CPU が 3 倍以上違うことも珍しくありません。

Cmd/Ctrl + Shift + P から View: Close Other Editors を実行するだけで、すぐに効果が見えます。日常的にタブを閉じる運用にするなら、設定ファイル (settings.json) に次を追加すると自動で古いタブを閉じてくれます。

{
  "workbench.editor.limit.enabled": true,
  "workbench.editor.limit.value": 8,
  "workbench.editor.limit.perEditorGroup": true
}

この設定で同時に開けるタブは 8 件までになります。実装作業中に集中を乱されにくい値を選ぶのが大事で、私自身は 8 〜 12 の間で運用しています。

重い拡張機能を 1 つずつ止めて犯人を特定する

Renderer は拡張機能の Web ビューもホストしています。特に Markdown プレビュー、Live Preview、Thunder Client、Live Share は描画コストが高く、バックグラウンドでも CPU を食い続けることがあります。

Cmd/Ctrl + Shift + P から Developer: Show Running Extensions を開くと、CPU 時間・起動時間・現在の状態が一覧で確認できます。Activation Time が 1000ms を超えているもの、CPU Profile が赤で表示されているものから順に、Disable (Workspace) で無効化して挙動を見ていくのが最短ルートです。

全体を無効化したいなら「拡張機能をすべて無効化して再起動」に相当する次のコマンドが便利です。

# macOS の例。--disable-extensions で一時的にすべて無効化して起動
/Applications/Antigravity.app/Contents/MacOS/Antigravity --disable-extensions

これで CPU 使用率が通常に戻るなら、犯人は拡張機能のいずれかです。一つずつ戻して試すのが確実です。

言語サーバー（Plugin）が暴走するとき

TypeScript / Pylance / Gopls といった言語サーバーは、プロジェクトサイズとファイル変更頻度に応じて再解析を繰り返します。大規模な monorepo や、node_modules 内のシンボルを全文検索するような拡張機能が入っていると、Antigravity Helper (Plugin) が慢性的に 100% 超になります。

TypeScript プロジェクトなら、まず tsconfig.json のスコープを疑ってください。ルートに tsconfig.json を 1 つ置いて全ファイルを対象にすると、パッケージが増えるほど解析コストが爆発します。

{
  "compilerOptions": {
    "skipLibCheck": true,
    "incremental": true,
    "tsBuildInfoFile": "./.tsbuildinfo"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", ".next", "coverage"]
}

skipLibCheck: true と incremental: true は、大きめのプロジェクトなら体感で解析時間が半減します。include を狭める効果も大きく、たとえば **/* を src/**/* に絞るだけで、言語サーバーのメモリが 1GB 程度減ることもあります。

Pylance を使っている場合は、"python.analysis.indexing": false と "python.analysis.userFileIndexingLimit": 2000 を settings.json に追加すると、初期インデックスの時間とメモリ常駐量が明確に減ります。これは公式ドキュメントには書かれていないトレードオフですが、コード補完の精度とメモリ使用量を天秤にかけたとき、個人開発のスピード感では後者を取る価値があると感じています。

より踏み込んだコンテキスト最適化や MCP 設定の見直しについては、Antigravity の動作が遅い・フリーズする時の完全対処法も合わせて参照してください。

エージェントが走り続けているとき

Activity Monitor で Antigravity Agent や agent-runtime と表示されるプロセスが 2 分以上 CPU を食い続けている場合、エージェントが内部的にループしている可能性が高いです。症状としては UI が応答を返しているのに、バックグラウンドでモデル呼び出しと編集試行を繰り返しており、気づかないうちに API クレジットが減っていることもあります。

まずは現在走っているエージェントタスクを停止します。

# Command Palette から
# > Antigravity: Cancel All Agent Tasks

停止しても CPU が下がらないなら、プロセスツリーの中に古い子プロセスが残っているサインです。

# 残留している node プロセス（MCP/agent 系）を確認
ps -eo pid,ppid,comm,args | grep -iE 'antigravity|mcp|agent' | grep -v grep

ここで、親プロセス (PPID) が 1 になっている node プロセスが見つかったら、それは孤児化したサブプロセスです。kill で片付けて構いません。

ループの再発を防ぐには、長時間タスクに明示的な終了条件を書き添えるのが効きます。「3 回試してもビルドが通らなければ停止して理由を報告して」のような指示を最初のプロンプトに入れておくだけで、無限ループで CPU を食い続ける事故はかなり減ります。MCP サーバー側で詰まっているケースは、Antigravity の MCP 接続トラブル完全解決ガイドの手順で切り分けられます。

メモリが数 GB 単位で膨らんだまま戻らないとき

Antigravity を長時間使うと、常駐メモリが 8GB を超えて減らなくなることがあります。Electron 系のエディタでは、開いたファイルの AST や編集履歴がプロセスに蓄積されていくため、ある程度は構造的に避けられません。ただし、以下のどれかに当てはまるなら、設定やワークフローで抑え込めます。

1 日を通してウィンドウを開きっぱなしにしている（閉じる機会を作る）
タブが常時 15 以上開いている（前述のタブ上限設定を導入する）
ウォッチ対象のファイルが大量にある（files.watcherExclude を広める）

files.watcherExclude は、ネイティブのファイル監視に乗せないパスを指定する設定です。デフォルトだと node_modules の奥深くまで監視され続けるため、大規模プロジェクトでは大きなメモリ要因になります。

{
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/**": true,
    "**/.next/**": true,
    "**/dist/**": true,
    "**/.turbo/**": true,
    "**/.cache/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/.next": true,
    "**/dist": true
  }
}

ここまでやってもメモリが戻らないなら、一度ウィンドウを閉じて再度開くのが最終手段です。完全終了すれば常駐メモリはリセットされるため、「昼休みに一度閉じる」程度の運用でも、午後のパフォーマンスが体感でまったく違います。

次の一歩

今日の運用で一つだけ変えるとすれば、まず files.watcherExclude に node_modules と .next（あるいは使っているビルド出力）を追加してみてください。この 1 行で、メモリ常駐量の右肩上がりがかなりゆるやかになります。そのうえで、重さを感じた瞬間に Developer: Show Running Extensions を開く癖を付けておくと、次からは 30 秒で原因プロセスにたどり着けるようになります。