Antigravity に修正を頼んだのにエラーが消えない — よくある5つの原因と解決策

「直しておきました」とAntigravityが返してきた。でも、エディタの赤い波線はまだそこにある——。

この状況、経験したことがある方は多いのではないでしょうか。私自身、使い始めの頃はこの現象に何度も出くわして、「Antigravityがおかしいのか、自分のやり方が間違っているのか」と混乱したものです。でも実際のところ、エラーが消えない理由はほぼ決まっています。5つのパターンを知っておくだけで、次からは焦らず対処できるようになります。

Antigravity が「修正した」と判断するしくみを理解する

まず前提として押さえておきたいのは、Antigravity がコードを修正するとき、それはファイルへの書き込み操作だということです。「この変更でエラーが本当になくなったか」を自動で検証するわけではありません（明示的にビルドやテストコマンドの実行を依頼した場合は別ですが）。

つまり「修正しました」という返答は「ファイルを編集しました」という意味であって、「コンパイルを通して確認しました」とは違います。この区別を最初に頭に入れておくことが、診断の出発点になります。

エラーが消えないとき、原因は次の5つのどれかに当てはまることがほとんどです。

キャッシュが古い状態を保持し続けているとき

TypeScript プロジェクトや Python の仮想環境では、キャッシュが古いコンパイル結果を保持し続けることがよくあります。Antigravity がファイルを正しく修正していても、エディタやビルドツールが古い状態を参照していれば、エラー表示は変わりません。

まず最初に試してほしいのが、キャッシュのクリアです。

# TypeScript プロジェクトの場合
# コマンドパレット（Cmd/Ctrl + Shift + P）から実行
# > TypeScript: Restart TS Server
 
# Next.js のビルドキャッシュをクリアして再ビルド
rm -rf .next && npm run build
 
# Python の場合（__pycache__ と .pyc ファイルを一括削除）
find . -type d -name __pycache__ -exec rm -rf {} + 2>/dev/null
find . -name "*.pyc" -delete 2>/dev/null

5秒もあれば終わる操作で、「Antigravityが修正した直後にキャッシュをクリアする」を習慣にするだけで、無駄なデバッグ時間がかなり減ります。地味に見えますが、実際にはこれだけで解決するケースが一番多いです。

修正されたファイルが意図したものと違うパターン

次によく見かけるのが、Antigravity が正しいファイルを修正していないケースです。特に、同じ関数名やファイル名が複数の場所に存在するプロジェクトで起きやすいです。

たとえば utils.ts というファイルが src/utils.ts と lib/utils.ts の2カ所にある場合、Antigravity は一方だけを修正して「直しました」と言うことがあります。エラーが残っているとしたら、もう一方のファイルが問題の本体かもしれません。

確認方法はシンプルです。git を使っているなら git diff が最速です。

# 直前のコミット以降に変更されたファイルを確認
git diff --name-only
 
# 変更の詳細を確認
git diff

もし意図したファイルが一覧に含まれていなければ、具体的なファイルパスを指定して再依頼します。

# 曖昧な依頼（意図と違うファイルを修正してしまうことがある）
「Profileコンポーネントのエラーを直して」

# 明確な依頼（ファイルパスと行番号を指定）
「src/components/Profile.tsx の24行目にある以下のエラーを修正してください:
TS2322: Type 'string | undefined' is not assignable to type 'string'.」

ファイルパスを明示するだけで、意図と違う修正が起きる頻度はかなり下がります。

型エラー・ランタイムエラー・リンターエラーを混同しているとき

エディタに表示されるエラーには、実は複数の種類が混在していることがあります。Antigravity が修正したエラーの種類と、表示され続けているエラーの種類が違う——というケースです。

TypeScript を例にすると、主に3種類があります。

型エラー: TypeScript コンパイラ（tsc）が検出するもの
ランタイムエラー: コンパイルは通るが、実行時に発生するもの
リンターエラー: ESLint や Biome が検出するコードスタイルの問題

これらは独立した問題です。「このエラーを直して」と伝えただけでは、表示されているエラーとは別の種類を修正してしまうことがあります。

依頼するときは、エラーの全文をそのままコピー&ペーストするのが確実です。

# ターミナルでエラーの全文を取得する例
npx tsc --noEmit 2>&1 | head -30
 
# ESLint の場合
npx eslint src/components/Profile.tsx

エラー全文を貼り付けることで、Antigravity が何を修正すべきかを正確に把握できます。エラーメッセージを自分なりに要約して伝えるよりも、そのまま貼った方がずっと正確です。

言語サーバーの表示が遅れているとき

修正は正しく適用されているのに、エディタがまだ古いエラーを表示し続けている——これは言語サーバーの応答遅れが原因です。特に、複数のファイルを短時間で修正したあとに起きやすい現象です。

言語サーバーはエディタのバックグラウンドで常時動作していますが、大量の変更後に古い状態を参照し続けることがあります。コマンドパレット（Cmd/Ctrl + Shift + P）から再起動するのが確実です。

# TypeScript の言語サーバーを再起動
> TypeScript: Restart TS Server

# Python (Pylance) の場合
> Python: Restart Language Server

# エディタ全体をリロード（最も確実）
> Developer: Reload Window

エディタのリロードは数秒で完了します。リロード後にエラーが消えたなら、実際には修正はすでに成功していて、表示だけが追いついていなかったということです。

コンテキストが古いファイル状態を参照しているとき

長いセッションで多くのファイルを修正した後、Antigravity が内部で保持しているファイルの状態が、実際の最新状態と乖離することがあります。この状態で修正を依頼すると、古い内容を元に変更を加えてしまい、かえって問題が複雑になるケースがあります。

この場合は、新しいチャットセッションを開始して、問題のファイルを明示的に読み込むよう指示してから再依頼するのが最も確実です。

「src/components/Profile.tsx を読んでから、以下のエラーを修正してください。

[エラー全文をここに貼り付ける]」

「読んでから修正してください」という一文を加えることで、Antigravity が最新のファイル内容を取得してから修正に取り掛かります。コンテキストが長くなったと感じたら、セッションをリセットするだけで大幅に精度が上がることがあります。

エラーが残る現象は、慣れてくると「ああ、またキャッシュか」「ファイルパスが違ったな」と見当がつくようになります。まず試してほしいのは、キャッシュクリアとエディタのリロードです。それだけで解決するケースが最も多く、調査の入り口としても一番手軽です。

この5つのパターンを頭に入れておくと、次に同じ状況に出くわしたときに、焦らず順番に確認していけるようになると思います。