Antigravity IDE で言語サーバー（LSP）が応答しない・補完が効かない時の診断フロー

昨日まで普通に効いていた補完が、ある朝 Antigravity を立ち上げたら何も出てこありません。型情報にカーソルを合わせてもツールチップが空で、「Go to Definition」もクリック音だけ返ってくる。こういう時、私はいつも「どこから手をつけるか」で 10 分くらい固まってしまうことがあります。

この記事は、Antigravity IDE で言語サーバー（LSP）が応答しなくなった時に、どの順番で何を確認すれば最短で復旧できるかをまとめたものです。TypeScript Server、Python の Pylance / Pyright、Go の gopls、Rust の rust-analyzer のそれぞれについて、実際に詰まる箇所を中心に書きました。

LSP は「静かに死ぬ」ことを前提に診断する

言語サーバーの厄介なところは、エラーダイアログを出さずに停止することがある点です。画面上は何も起きていないのに、内部ではプロセスがクラッシュしていたり、無限ループに入って返事が返せなくなっていたりします。

ですから診断の最初のステップは「LSP プロセスが生きているかを確認する」ことから始めます。推測ではなく事実を見に行くのが、回り道に見えて一番早い方法です。

Antigravity のコマンドパレット（Cmd+Shift+P / Ctrl+Shift+P）から Developer: Show Running Extensions を開くと、現在起動中の拡張機能とそれぞれが抱えている子プロセスの状態が一覧できます。ここで TypeScript Server や Pylance が「Activated」ではなく「Stopped」や「Failed」になっていたら、そこが出発点です。

最初に試すべき 3 つの復旧アクション

どの言語の LSP であっても、次の 3 つは真っ先に試す価値があります。体感ですが、これで直るケースが半分以上あります。

1. 言語サーバーを明示的に再起動する

コマンドパレットから言語ごとの再起動コマンドを実行します。

TypeScript: TypeScript: Restart TS Server
Python: Python: Restart Language Server
Go: Go: Restart Language Server
Rust: rust-analyzer: Restart server

再起動だけで直る場合は、大抵は一時的なメモリ逼迫や、編集中のファイルが LSP を混乱させた何らかの中間状態が原因です。

2. Antigravity ウィンドウをリロードする

Developer: Reload Window でウィンドウを再読み込みします。これは拡張機能のホストプロセスごと再起動するので、LSP 単体の再起動で直らないケースに効きます。未保存の変更は残りますが、念のため保存してから実行するのが安全です。

3. キャッシュと一時ファイルを削除する

それでも直らない場合、LSP が参照しているキャッシュが壊れている可能性があります。言語ごとのキャッシュ場所を以下にまとめました。

TypeScript: プロジェクトルートの .tsbuildinfo と、node_modules/.cache/ を削除
Python (Pylance): ホームディレクトリの .cache/pylance/ を削除
Go (gopls): go clean -cache でビルドキャッシュをクリア
Rust (rust-analyzer): プロジェクトルートの target/ を削除（ビルドは走り直しますが LSP のインデックスが再構築されます）

削除してから LSP を再起動すると、インデックスを作り直すので最初の数十秒は補完が遅くなります。そこで止まってしまったように見えても、少し待ってあげると戻ってくることが多いです。

TypeScript Server が応答しない典型パターン

TypeScript を書いていて LSP が止まる場面で、私がよく遭遇するのは次の 3 パターンです。

パターン 1: モノレポで型解決に失敗している

pnpm workspace や Turborepo を使っていると、パッケージ間の型参照が Project references の設定ミスで解決できなくなることがあります。tsconfig.json の references フィールドと、実際に存在するパッケージのパスが一致しているかを確認します。

// tsconfig.json — モノレポのルート
{
  "references": [
    { "path": "./packages/ui" },
    { "path": "./packages/core" }
  ]
}

packages/ui/tsconfig.json が存在しなかったり、composite: true が設定されていなかったりすると、TypeScript Server は黙って落ちます。エラーログは Developer: Open Logs Folder から exthost.log を開くと見られます。

パターン 2: 巨大な型定義で CPU が張り付く

Zod や Prisma の生成型など、深く入れ子になった型を多用していると、TypeScript Server が 100% CPU を掴んだまま応答を返さなくなることがあります。

対処としては、tsconfig.json に skipLibCheck: true を設定し、node_modules 内の型チェックをスキップするのが効きます。また、Antigravity の設定で typescript.tsserver.maxTsServerMemory を 8192 などに上げておくと、大規模プロジェクトで応答性が改善します。

// .vscode/settings.json または Antigravity の settings.json
{
  "typescript.tsserver.maxTsServerMemory": 8192,
  "typescript.tsserver.experimental.enableProjectDiagnostics": false
}

enableProjectDiagnostics は非同期にプロジェクト全体をチェックする機能で便利なのですが、規模によっては LSP を圧迫します。止まりがちな環境では切っておくのが現実的です。

パターン 3: 開いているファイル数が上限に達している

Antigravity は多くのファイルをバックグラウンドで開いたまま保持しています。VCS からチェックアウトした直後などに 100 ファイル以上が開いたままになっていると、TypeScript Server のファイルウォッチャーが限界に達してハングします。

Window: Close Other Editors で現在のエディタ以外を閉じるだけで直ることが意外と多いです。LSP の再起動と組み合わせて試してみてください。

Python の Pylance / Pyright が silent failure する時

Python の言語サーバーで特に多いのは、仮想環境の選択ミスによる無反応です。Pylance は選択されたインタプリタのサイトパッケージを見に行くので、.venv を作ったのに Antigravity が古い Python を指したままだと、外部ライブラリの型が一切解決できなくなります。

コマンドパレットで Python: Select Interpreter を実行し、.venv/bin/python や .venv/Scripts/python.exe を明示的に選び直します。設定ファイルに固定したい場合は以下の通りです。

{
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
  "python.analysis.extraPaths": ["./src"],
  "python.analysis.typeCheckingMode": "basic"
}

typeCheckingMode を strict にしていると、大量のエラーで Pylance がキューを処理しきれずに応答が遅くなることがあります。初期は basic から始めて、プロジェクトが安定してから strict に上げるのが私の好みです。

もう一つよくあるのは、pyproject.toml にある [tool.pyright] セクションと、Antigravity の設定が矛盾しているケースです。両方で venvPath や extraPaths を指定していると、Pylance はどちらを優先するかで混乱します。pyproject.toml 側に寄せて、エディタ設定はシンプルに保つのをおすすめします。

gopls と rust-analyzer で起きやすい問題

Go の gopls が応答しない時、最も疑うべきは GOPATH と GOMODCACHE の環境変数がエディタから見えているかどうかです。ターミナルでは正しく設定されていても、Antigravity の GUI 起動プロセスには反映されていないことがあります。

macOS や Linux で GUI からアプリを起動した場合、~/.zshrc や ~/.bashrc で設定した環境変数は読み込まれません。launchctl setenv GOPATH /Users/you/go（macOS）や、systemd の user service 経由で環境変数を渡す必要があります。一番シンプルなのは、ターミナルから antigravity . で起動することです。

rust-analyzer で多いのは、target/ ディレクトリのインデックスが壊れて LSP が起動しなくなる症状です。一度 cargo clean でクリーンにして、プロジェクトを開き直すと直ります。加えて、rust-analyzer は巨大プロジェクトだと初回インデックスに数分かかるので、ステータスバーの進捗表示を確認して待ってあげてください。

# rust-toolchain.toml
[toolchain]
channel = "stable"
components = ["rust-analyzer", "rust-src"]

rust-toolchain.toml で rust-src コンポーネントを明示しておくと、標準ライブラリの型情報も引けるようになり、補完の体験が大きく改善します。

拡張機能の競合を切り分ける方法

LSP の応答性が落ちた時、原因が Antigravity 本体ではなく、最近インストールした拡張機能であるケースも少なくありません。競合を切り分けるには「拡張機能をすべて無効化した状態」から出発するのが確実です。

コマンドパレットから Developer: Reload With Extensions Disabled を実行すると、拡張機能を全て切った状態で再起動できます。この状態で LSP が正常に動くなら、原因は拡張機能のどこかです。半分ずつ有効化して絞り込む、いわゆる二分探索が有効です。

私の経験では、以下の組み合わせで問題が起きやすい印象があります。

フォーマッタ系拡張（Prettier、Black 等）を複数入れている
古い ESLint 拡張と新しい TypeScript ESLint が同居している
AI 補完系の拡張が複数入っていて、補完候補の取り合いになっている

拡張機能は便利さと引き換えに不安定さを持ち込みます。「使っていないのに有効化したまま」になっているものがないか、定期的に棚卸しするのがおすすめです。

それでも直らない時の最終手段

すべて試してまだ直らない場合、設定ファイルの破損を疑います。Antigravity の設定は以下の場所にあります。

macOS: ~/Library/Application Support/Antigravity/User/
Linux: ~/.config/Antigravity/User/
Windows: %APPDATA%\Antigravity\User\

ここの settings.json を一度別名にリネームし、デフォルト設定で起動してみます。直った場合は、リネームしたファイルから設定を少しずつ戻して、どの設定が原因かを特定できます。

また、.antigravity/ フォルダがプロジェクトルートにある場合、そこにも設定やワークスペース固有の状態が保存されています。このフォルダ全体を一時的に退避させて起動し直すと、ワークスペース固有の問題を切り分けられます。

全体を振り返って

LSP のトラブルは「何が起きているか見えない」のが一番つらい部分です。次に同じ状況になった時は、まず Developer: Show Running Extensions でプロセスの生死を確認してから、再起動 → キャッシュクリア → 拡張機能無効化、の順で絞り込んでみてください。

関連する記事もあわせて役立つかもしれません。Antigravity IDE でよく出るエディタのエラーと対処法ではこの記事で扱わなかった汎用的なエラー、Antigravity のタブ補完が効かない時の原因と解決策ではタブ補完に特化した症状、Antigravity の動作が重い時のトラブルシューティングでは全体的なパフォーマンス問題を扱っています。

AI 時代のエディタ活用法をさらに体系的に