Antigravity で Gemini 3.8 Flash が遅いときは、何を待っているのかを先に確かめると、不要な再起動や再送を減らせます。回答開始前に止まるなら短い依頼で切り分ける、ツール実行中なら最後の処理と確認待ちを見る、同じ操作を繰り返すならいったん止める、画面の切替だけが重いならクライアントの版を確認する、という順序です。
Gemini 3.8 Flash は、複雑な作業で推論やツール呼び出しを重ねる設計です。ただし、それだけで新規チャットの短い挨拶まで遅くなる理由を説明できるわけではありません。Google のモデル発表が説明する推論時間と、サーバー容量不足、ツール待ち、アプリの操作遅延は分けて考える必要があります。
この記事は 2026年9月21日に確認した公開情報をもとにしています。以下の手順は原因を絞るための提案であり、当サイトで速度改善を測定した結果ではありません。
まず「遅い」を4つに分ける
画面が動かないように見えても、確認する場所は症状によって違います。
| 今の状態 | 最初に見るところ | 次に試すこと |
|---|---|---|
| 送信後、最初の返答がなかなか出ない | エラー表示、選択モデル、思考レベル、発生時刻 | 新規チャットで、ツール不要の短い依頼を1回だけ送る |
| 返答は始まったが、途中の処理が進まない | 最後のツール名、端末出力、許可や入力の待機 | 止まった処理だけを確認する |
| 同じコマンドや修正を繰り返す | 実行履歴と実際のファイル差分 | エージェントを停止し、重複操作の影響を確認する |
| 会話一覧や設定、タブの操作が重い | 使っている製品とバージョン | 作業を保存し、該当する更新があるか確認する |
最初の返答までの時間は TTFT とも呼ばれます。これは依頼全体が終わるまでの時間とは別です。すぐに返答が出ても、その後のビルドやブラウザー操作が長ければ、完了までには時間がかかります。反対に、ツールを使わない短い依頼で返答開始から遅い場合、リポジトリの大きさだけに原因を求めるのは早計です。
待つ時間に一律の正解はありません。今回確認した公式情報からは、全アカウントに当てはまる「何秒を超えたら異常」という基準は得られませんでした。普段の同じ作業との差と、途中経過が更新されているかを手がかりに、自分の作業を止められる時間を決めてください。
9月の遅延報告から分かること
Google AI Developers Forum の9月15日のスレッドには、新規の空のチャットで挨拶を送っても回答開始が遅いという報告があります。Gemini 3.7 に切り替えると速くなったという投稿がある一方、3.7 でも遅いという投稿もあり、切替は万能な対処ではありません。
同じスレッドでは、サポート側の返信が性能低下の調査に言及し、9月15日の後続返信では解消したと伝えています。しかし、9月16日から18日にかけての投稿には、再び遅くなった、まだ止まるといった声も続きます。
ここから言えるのは、特定の時期に遅延が報告され、解消の案内後にも一部の利用者が症状を報告した、ということまでです。過去の返信だけで「現在も全体障害が続いている」「すべて復旧している」のどちらも断定できません。自分の環境でいま起きている症状と、投稿の日付を合わせて判断しましょう。
503 と MODEL_CAPACITY_EXHAUSTED が出る場合
このスレッドには、503 UNAVAILABLE、MODEL_CAPACITY_EXHAUSTED とともに、サーバー側に利用可能な容量がない旨を示すエラーが投稿されています。この組み合わせが出ている場合は、まずサービス側の処理容量を疑う材料になります。個人の利用枠を使い切った証拠とは別です。
短時間に同じ大きな依頼を何度も送り直すより、エラーと時刻を残し、いったん間隔を空けるか、選択欄にある別モデルで小さく試す方が切り分けやすくなります。何回も再送しても、サーバー側の容量不足そのものを解消することはできません。
エラー内には gemini-3.8-flash-medium という文字列も含まれていました。これは投稿された診断ログ内の名前であり、そのまま公開 Gemini API のモデル ID として使えると確認されたものではありません。Antigravity 内の問題を調べるために、この文字列を API コードへ転記する必要はありません。
回答開始が遅いときの、負担の少ない切り分け
まず現在のファイル変更を保存し、並行して動いているエージェントや端末処理がないかを見ます。そのうえで、次のように条件を一つずつ変えると、待ち時間の原因を追いやすくなります。
- 現在の条件を控える。 使用中のクライアント、バージョン、モデル、思考レベル、時刻とタイムゾーンを残します。モデル名だけが同じでも、別のアプリや別設定との比較では判断が難しくなります。
- 新規チャットで短く試す。 たとえば「ツールを使わず、『確認できました』とだけ返答してください」と1回送ります。元の長い作業を再送する必要はありません。
- 元の会話との差を見る。 短い依頼には返るのに元の会話だけ遅いなら、会話に含まれる情報や依頼の複雑さ、使用ツールを調べる余地があります。新規チャットでも遅いなら、長い履歴だけでは説明できません。
- 利用できる別モデルと比べる。 モデル選択欄に Gemini 3.7 などがあれば、同じ短い依頼で回答開始の様子を比べます。同時に複数の試行を走らせず、アカウントや回線など他の条件はできるだけそろえます。
- 結果に合わせて作業を小さく再開する。 別モデルだけ応答するなら、まず範囲を限定した作業に切り替えます。どちらも止まる場合は、大きな依頼の連続再送を止め、エラーの保存とサポートへの報告に進みます。
これは厳密な速度測定ではありません。試す時刻が変わればサービスの混雑も変わるため、1回の比較で「モデル変更が原因で速くなった」とまでは言えません。それでも、元の作業を丸ごとやり直す前に、どこを調べるべきかの手がかりは得られます。
思考レベルを下げれば直る？
複雑な依頼の処理時間を減らす選択肢にはなります。Antigravity の公式発表では、思考レベルによって推論の深さと遅延のバランスを調整できること、計算効率を重視する用途向けに 3.7 も残すことが説明されています。
小さな修正や明確な質問なら、低い思考レベルで必要な結果が得られるか試す価値があります。ただし、設定を下げても、許可待ちの端末処理や 503 の容量不足を直接解消するわけではありません。複雑な設計判断では推論を減らすことで出力の質が変わる可能性もあるため、速さだけでなく差分やテスト結果まで確認してください。
9月18日の別の利用者報告では、思考レベルを変えても、新規チャットにしても改善しなかったと述べられています。これは一人の経験ですが、「思考レベルを下げる」「新規チャットにする」を必ず直る設定として案内できない理由になります。
ツールが止まる・同じ操作を繰り返すとき
回答開始後に止まった場合は、文章が出る速度より、最後に何を実行していたかが重要です。端末が追加入力を待っていないか、権限の確認が表示されていないか、ブラウザーや外部サービスから返答が来ていないかを確認します。確認待ちが原因なら、その処理の内容を理解してから応答します。速くするためだけに権限を一括許可する必要はありません。
同じコマンドを繰り返す、同じファイルを直して戻す、といった状態では、待ち続けるより停止して現状を確かめる方が適切です。前述の9月18日の投稿にも、基本的なコマンドの反復と利用枠消費への懸念があります。ただし、報告だけで全利用者に共通する不具合とまでは言えません。
停止後は、次の順序で再開の材料をそろえます。
- 実行履歴から、最後に成功した処理と繰り返していた処理を見分ける。
- ファイル差分や生成物を確認し、必要な変更を保存する。エージェントの「完了」という説明だけで判断しない。
- 残っている端末プロセスを確認する。停止ボタンを押した後も、別の処理が動いていないかを見る。
- 再開するなら、確認できた現在の状態と未完了の作業だけを短く伝え、一つの処理から始める。
たとえば、テストに失敗しているのにインストールを何度も繰り返しているなら、次の依頼を「この失敗したテストの出力を読み、原因候補を説明する」に絞れます。新規チャットへ元の長い指示をそのまま貼り直すより、既に行われた変更を踏まえて再開できます。これは再発を防ぐ保証ではなく、重複操作の範囲を小さくするための進め方です。
画面操作だけが重いなら、更新内容を確かめる
会話の切替やサイドバーの反応が遅い症状は、モデルの回答待ちと別に扱います。公式変更履歴の Antigravity 2.0 バージョン 2.15.0、2026年9月18日には、会話サイドバー切替の性能改善と、重複した権限項目が会話ファイルを肥大化させてアプリを遅くする問題の修正が記載されています。
該当する Antigravity 2.0 を使っているなら、バージョンを確認して更新の適用を検討する根拠があります。更新は数日かけて段階的に提供されるため、同じ日に全環境へ届くとは限りません。作業を保存し、実行中の処理を確かめてから更新・再起動してください。
この 2.15.0 の説明を、すべての IDE 拡張や CLI の共通バージョンとして扱うことはできません。また、サイドバーの修正が入ったことは、モデルのサーバー容量不足まで直った証拠にはなりません。翌日の 2.15.1 は Windows のサンドボックスに関する更新であり、番号が新しいという理由だけで遅延修正の根拠にはできません。
出所の分からないキャッシュ削除やプロジェクト設定の初期化を、最初の対処にするのは避けましょう。少なくとも今回確認した公式情報は、それらで Gemini 3.8 Flash の回答開始が一定の秒数まで短縮されるとは示していません。ローカル設定を大きく変える前に、症状に合った変更履歴があるかを確かめる方が判断しやすくなります。
利用枠が減った場合と、サポートに残す情報
サーバー容量不足と、アカウントの利用枠は分けて確認します。利用枠の画面では「使用済み」と「残り」を取り違えないことが大切です。公式変更履歴にも両者の表示を区別する説明がありますが、場所や表示名はクライアントによって異なり得ます。自分が使っている製品のモデル・利用状況の画面で確認してください。
エージェントが反復していたなら、停止前後の表示と実行履歴を残すと相談しやすくなります。一方、「失敗したから必ず利用枠は減らない」「今回の遅延で減った分は自動的に戻る」とは、確認済みの公開情報から言えません。9月18日の投稿には外部 API の料金に関する訴えも含まれますが、Antigravity の利用枠と API の課金記録を同じものとして扱うべきではありません。
報告は、次の情報がまとまっていれば状況を伝えやすくなります。
text発生日時・タイムゾーン： 製品名・バージョン・OS： 選択モデル・思考レベル： 症状：回答開始前／特定ツール／同じ操作の反復／画面操作 新規チャットの短い依頼でも起きるか： 別モデルで同じ短い依頼を試した結果： エラー全文・リクエスト ID（表示される場合）： 最後に進んだ処理・繰り返した処理： 利用枠の表示と確認時刻（関係する場合）：
公開フォーラムに載せるときは、API キー、個人情報、非公開のソースコードや業務データを除いてください。依頼を再現するために必要な情報と、秘密の内容そのものは分けられます。
いま作業を進めたいなら、まず短い依頼で回答開始を確認し、使えるモデルで小さな作業から再開します。繰り返し動作があるなら停止と差分確認を優先し、画面操作だけが重いなら該当するクライアント更新を確かめます。この区別ができれば、効果の分からない設定変更を重ねずに、次の一手を選べます。
