壁紙アプリの配信用画像を抱えた大きなリポジトリを開いた日のことです。エージェントに簡単な修正を頼んだだけなのに、返事がいつまでも返ってきませんでした。
最初のうち、私は手当たり次第に設定を触っていました。再起動し、キャッシュを消し、モデルを切り替え——結果は芳しくありませんでした。遅さの正体が「入力の大きさ」「つないでいるものの数」「選んだモデル」「ネットワーク」のどれなのかを、一度も確かめていなかったからです。
ここからは、直す前に切り分ける順番でお伝えします。なお、応答時間や削減率のような数値は、環境によって大きく変わります。ここでは「何秒短くなる」とは書かず、ご自身の環境で前後を測る方法を置いておきます。
直す前に、遅さの置き場所を一つに絞ります。 この線引きだけは、急いでいるときほど守るようにしています。
まず、遅いのは「エージェント」か「画面」かを分ける
最初の切り分けは次の二択です。
| 症状 | 疑う場所 | 最初に見るもの |
|---|---|---|
| 入力欄やスクロールが重い、画面が固まる | アプリ本体（メモリ・拡張機能・ファイル監視） | OS のタスクマネージャー／アクティビティモニタ |
| 画面は動くが、返事が来ない・遅い | エージェント側（コンテキスト・モデル・MCP・ネットワーク） | プロジェクトの規模、有効な MCP、選択中のモデル |
| 返事は来るが、コードが途中で切れる | 出力トークンの不足 | 下の「コード出力が途中で切れるとき」 |
画面が重いだけなら、エージェントの設定をいくら詰めても効きません。逆も同じです。ここを分けるだけで、試す項目が半分ほどに減ります。
原因1: プロジェクトが大きすぎる
エージェントはプロジェクト内のファイルを手がかりに答えを組み立てます。依存関係のフォルダやビルド出力、ログまで対象に入っていると、読む量が膨らんで待ち時間が伸びやすくなります。
まず、除外すべきものを除いたファイル数を実際に数えます。
# 依存関係とビルド出力を除いたファイル数
find . \( -name node_modules -o -name .git -o -name dist -o -name build -o -name .next \) -prune -o -type f -print | wc -l
# 参考: 除外せずに数えた場合
find . -type f | wc -l
# 5MB を超える大きなファイルの候補
find . \( -name node_modules -o -name .git \) -prune -o -type f -size +5M -print二つの数字の開きが大きいほど、除外の設定が効く余地があります。開きがほとんどなければ、原因は別の場所です。
除外の書き方は、.gitignore と同じ書式のファイルで指定する方法があります。私の手元では .antigravityignore として運用してきましたが、どの除外ファイルがどこまで読まれるかは、バージョンによって扱いが変わってきました。Google の開発者フォーラムでも、.gitignore の扱いや権限まわりの設定が 2.5 系で整理し直されたという利用者の書き込みがあります（公式の確認ではありません）。ですので、除外を書いたあとは必ず挙動を確かめてください。確かめ方は.antigravityignore が効いていないときに疑う4か所にまとめています。
node_modules/
.git/
dist/
build/
.next/
out/
*.log
.DS_Store
__pycache__/
coverage/
秘密情報（.env など）は、速度のためではなく安全のために、除外とは別に権限側でも守ってください。除外ファイルだけに頼る設計は、私は避けています。
インデックスが進まない場合はWorkspace Indexing が止まる・完了しない時の診断と修復手順、巨大なファイルで AI が失敗する場合は大きなファイルで AI が失敗するときの対処も併せてご覧ください。
原因2: MCP サーバーが多すぎる
有効にしている MCP サーバーが増えると、起動時の接続確認や、ツール一覧の読み込みが増えます。使っていないものまで有効のままだと、エージェントを起動するたびに待たされる原因になります。
見るべきは次の三つです。
| 確認項目 | 見方 |
|---|---|
| 有効な MCP の一覧 | 設定画面の MCP 項目で、今週一度も使っていないものを洗い出します |
| 起動の遅い MCP | 一つずつ無効にして、エージェントの初回応答が変わるか比べます |
| 同時に動かす数 | 複数のエージェントを並べているとき、MCP の接続が重なっていないか見ます |
一度に全部を切らず、一つ切って、一回測ります。 この順番にしておくと、どれが効いていたのかが後から分かります。
原因3: モデルとモードの選び方
高機能なモデルや、計画を立てるモードほど、返事までに時間がかかるのが普通です。逆に、簡単な質問まで重いモデル・重いモードで投げていると、遅さを自分で作ってしまいます。
使い分けの考え方は次のとおりです。具体的なモデル名や料金は更新が早いため、ここでは固定せず、設定画面に表示されている名前でご確認ください。
| 作業の性質 | 向いている選び方 |
|---|---|
| 調べもの・小さな質問 | 軽量・高速側のモデル／速いモード |
| 通常のコード生成・デバッグ | 標準的なモデル |
| 複数モジュールにまたがる設計相談 | 高機能なモデル／計画を立てるモード |
大事なのは、既定値を軽い側に置いて、必要なときだけ上げることです。逆に既定を重くすると、普段使いのたびに待つことになります。
前後を比べるときは、同じ依頼文を同じ条件で二度投げて、体感ではなく時計で測ります。
# 開始時刻をメモして、返事が来た時刻との差を見る（macOS / Linux）
date +%H:%M:%S原因4: アプリ本体のメモリ
長時間つけっぱなしにしたアプリは、メモリを多く抱えがちです。Antigravity は VS Code 系のデスクトップアプリですので、OS 側のタスクマネージャー（macOS ならアクティビティモニタ）で、Antigravity 関連のプロセスのメモリを見ます。
- 再起動すると軽くなる場合は、長時間稼働による蓄積を疑います。
- 拡張機能を一時的にすべて無効にして軽くなる場合は、拡張機能との相性を疑います。
- 複数のプロジェクトを同時に開いている場合は、一つに絞って比べます。
「どのプロセスが何 GB か」を見てから動くと、闇雲な再起動を減らせます。
原因5: ネットワークの遅延
API への往復が遅い環境では、エージェントの返事も遅くなります。VPN や社内ネットワークを経由している場合は、特に疑ってみる価値があります。
# 一般的な疎通と遅延の目安（接続先は任意の公開ホストで構いません）
ping -c 5 8.8.8.8VPN を切って比べる、別の回線（テザリングなど）で試す——この二つだけで、ネットワークが原因かどうかはかなり絞れます。社内ネットワークの場合は、管理者の方へ遅延の事実を伝えるのが近道です。
エージェントが「思考中」のまま進まないとき
応答が返ってこないときは、次の順で確認します。
- ネットワークに接続できているか。
- アプリ内のエラー表示や、開発者向けのログに赤いエラーが出ていないか。
- サービスの障害情報が出ていないか（公式のステータス表示を確認します）。
- アカウントの利用枠やクレジットが残っているか。
そのうえで、エージェントを停止して再度依頼し、それでも進まなければアプリを再起動して、プロジェクトを開き直します。キャッシュの削除は最後の手段にして、消す前に何が消えるかを確かめてください。
コード出力が途中で切れるとき — 「遅い」とは別の対処が要ります
応答が遅いのと、出力が途中で切れるのは、見た目が似ていても原因が違います。関数の } が閉じられないまま終わる、インポート文だけで本体がない——こういうときは、速度のチューニングではなく、出力トークンを確保することが要点になります。
まず症状を3つに切り分けると、打つ手が決まります。
- A: 関数やクラスの途中でコードが切れる — 出力トークンを使い切って、AI が生成を諦めた状態です。
- B: 「続きを書いて」と頼むと前の内容を忘れる — チャット履歴が長くなり、古い文脈が押し出されています。
- C: 「ファイルが長すぎる」と明示的にエラーが出る — 最もわかりやすく、入力側が大きすぎるサインです。
切れたら、続けずに新しいセッションで頼み直す
長いセッションの続きで追加を頼むより、新しいセッションを開いて必要な部分だけを渡すほうが安定します。
# 長いセッションでの追加依頼（切れやすい）
「さっきのコードに認証機能を追加してください」
# 新しいセッションでの依頼（推奨）
「以下の関数に JWT 認証を追加してください。変更対象は auth.ts のみです。
export function checkAuth(req: Request) { /* ... */ }」
文脈の整理については、大規模コードベースでの Context Window 管理でも触れています。
「変更後のコードだけ返してください」で出力枠を空ける
依頼文に一行添えるだけで、前置きや全文の再掲が減り、コード生成に回せるトークンが増えます。
「fetchUserData 関数にエラーハンドリングを追加してください。
変更後の関数コードだけを返してください（他の関数や説明は不要です）」
私自身、個人開発で長いファイルを一度に直そうとして何度も途中で切られました。変更する関数だけを切り出して「その関数だけ返してください」と頼む形に変えてから、出力切れはほとんど起きなくなっています。広く頼まず、狭く何度も——これが一番効きます。
Auto-continue の見直し
Auto-continue は、エージェントがタスクを自動で継続する機能です。便利な反面、途中で誤った方向に進んだまま走り続けると、時間も利用枠も余計に使います。
パフォーマンスが落ちていると感じるときは、いったん無効にして、各ステップを自分で確認しながら進めてみてください。そのうえで、問題が出なかった作業の種類から順に、有効に戻していきます。設定の場所や名称はバージョンで変わりますので、お手元の設定画面でご確認ください。
一つずつ測るためのチェックリスト
上から順に、一項目ずつ変えて、その都度同じ依頼で測ります。
- [ ] 画面が重いのか、エージェントの返事が遅いのかを分ける
- [ ] 除外すべきフォルダを除いたファイル数と、除かない場合の数を比べる
- [ ] 使っていない MCP を一つずつ無効にして、初回応答を比べる
- [ ] 既定のモデルとモードを軽い側にして、同じ依頼で比べる
- [ ] Auto-continue を無効にして様子を見る
- [ ] OS のタスクマネージャーでメモリを確認し、必要なら再起動する
- [ ] VPN を切る・回線を変えて、遅延の差を見る
結びに
遅さの正体は、コンテキストの大きさ、MCP の数、モデルとモード、アプリのメモリ、ネットワークのどれかに落ち着くことがほとんどでした。ただし、どれが効くかは環境ごとに違うのだと思います。
まずは、除外を除いたファイル数と、除かない場合の数を数えるところから始めていただければと思います。数字を一つ持っておくと、次に遅くなったとき、もう手探りにはなりません。