Gemini が high demand、高需要、モデルが混雑している、または 503 と表示したとき、最初にやるべきことはプロンプト変更やプラン変更ではありません。まず、どの入口で起きたのかを分けます。Gemini App、Gemini CLI、Gemini API、画像プレビュー系のどれかで、必要な証拠も復旧手順も変わります。
次に状態コードを見ます。503 は一時的な容量不足やモデル過負荷に近く、429 はレート制限やクォータ、504 はタイムアウト予算に近い問題です。これらをまとめて「Gemini が落ちた」と扱うと、最初の数分で誤診します。
2026 年 4 月 24 日に Gemini API の公式トラブルシューティング、英語と日本語の可視結果、CLI/API 利用者の公開報告を確認したうえで、実務的な順番は明確です。入口を確認し、状態コードを分け、同じ経路で一度だけ制限付きで再試行し、その後に待機、キュー、許容できる代替経路、またはサポート用の証拠整理へ進みます。
まず判断ボードで誤診を防ぐ
メッセージは警告として扱い、診断そのものにしないでください。
| 入口 | よくある意味 | 最初の動き | 止める基準 |
|---|---|---|---|
| Gemini App / Advanced | モデル経路の混雑、画面側の問題、プラン認識のずれ。 | 選択モデル、表示プラン、公式ステータスを確認。 | 1 回の混雑表示だけで再購入しない。 |
| Gemini CLI | 既定モデル、Code Assist 経路、または上流応答の短縮表示。 | 同じコマンドを 1 回再試行し、モデル、認証、CLI 版を記録。 | 所有者が分かるまでプロジェクトコードを変えない。 |
| Gemini API | 表示文より HTTP クラスが重要。 | 503、429、504 を先に分離。 | 429 または 504 に変わったら別分岐へ移る。 |
| 画像プレビュー系 | 画像モデルだけが混雑することがある。 | 経路を保って制限付き再試行。 | 画像 503 と確認してから専用分岐へ進む。 |
この分け方により、サービス容量の問題をローカル設定の問題として扱うミスを避けられます。モデル経路が混雑しているとき、キャッシュ削除やプロンプト変更は原因の理解にはなりません。逆に 429 なら、単に待つだけでは制限問題を解けません。
API では Google の Gemini API troubleshooting guide をログと一緒に見ます。画像生成の 503 と確認できた場合は、Gemini image 503 overloaded guide が近い分岐です。
再試行の前に入口を確定する
Gemini high demand エラーは 1 つの契約ではありません。App、CLI、API、画像経路では見るべき証拠が違います。
Gemini App では、表示モデル、プラン、ログインアカウント、Web またはモバイルの状態を見ます。Pro が混雑して高速モデルへ回る場合、それは developer API の 503 とは別の問題です。
Gemini CLI では、コマンド、CLI バージョン、認証方式、既定モデル、エラーが tool call の前か後かを記録します。モデル応答が始まる前に止まるなら、リポジトリのコードよりモデル経路やアカウント側を疑います。
Gemini API ではログが最も強い証拠です。HTTP code、status、model id、timestamp、request id、リージョンまたはプロバイダ経路、同じ経路での再試行結果を残します。モデル、SDK、timeout、payload を同時に変えると、成功しても理由が分からなくなります。
画像生成は分けて扱います。テキスト応答が成功しても画像プレビューが正常とは限りません。画像要求だけが失敗しているなら、画像経路の容量として切り分けます。
API 分岐：503、429、504 は別物
API では、先に状態を読みます。
| クラス | 実務上の意味 | 最初の対応 |
|---|---|---|
| 503 UNAVAILABLE / overloaded | 一時的な容量不足、モデル過負荷、backend unavailable。 | 同じ経路で上限付き backoff。 |
| 429 RESOURCE_EXHAUSTED | クォータ、rate limit、billing tier。 | 速度を下げ、制限分岐へ移る。 |
| 504 DEADLINE_EXCEEDED | timeout、重い payload、時間窓不足。 | timeout と負荷を見直して再検証。 |
最初の再試行は同じ経路にします。model id、endpoint、auth owner、主要 payload を保つことで、結果が解釈できます。成功すれば一時的な容量不足があり得ます。503 のままなら待機、キュー、計画済み fallback。429 や 504 に変われば、別問題です。
よくある失敗は、high demand を見てモデル、SDK、timeout、プロンプトを同時に変えることです。一度成功しても、何が効いたのか分かりません。運用では小さな検証が必要です。
制限系は Gemini API rate limits guide、広い API 障害は Gemini API error troubleshooting を使います。
CLI 分岐：一度だけ再試行し、品質低下を判断する
Gemini CLI はローカル環境、認証、モデル、API 経路を 1 つの画面にまとめます。そのため、短い high demand 表示だけでローカルコードを疑わないでください。
同じコマンドを 1 回再試行します。時刻、コマンド、表示モデル、認証方式、tool call が始まっていたかを記録します。有効なモデル応答の前で止まるなら、まずモデル経路またはアカウント容量の問題です。
その後、低負荷モデルへ切り替えてよいかを判断します。軽い説明なら許容できる場合があります。コード生成やリファクタリングでは、品質低下によるレビュー負担のほうが待機より高くなることがあります。
CLI の導入や認証が怪しい場合は、Gemini CLI install guide で分けて確認します。インストール問題とライブ容量問題を混ぜないことが重要です。
App と有料ユーザーの分岐
有料プランは優先度を上げる可能性がありますが、混雑時の完全な回避保証ではありません。有料ユーザーは、まず正しいアカウントとプランが認識されているかを確認します。
表示プラン、ログインアカウント、選択モデル、Web/mobile の表面、公式ステータスを見ます。Pro が混雑し、Fast が動くならモデル経路の容量問題です。プラン自体が見えないなら、アカウントまたは entitlement の問題です。
問い合わせ前の証拠は小さくまとめます。
- high demand 表示のスクリーンショット；
- timestamp と timezone；
- App、Web、mobile、CLI、API、画像経路のどれか；
- 選択モデルと表示プラン；
- その時点の公式ステータス；
- 同じ経路での再試行結果；
- 可能なら別の公式表面での結果。
この形なら、サービス状態、経路容量、プラン認識、リクエスト形状を分けて説明できます。
画像プレビューと Nano Banana 系の失敗
画像生成は計算負荷が高く、テキストとは別に混雑します。テキスト Gemini が動いていても、image preview が 503 になることはあります。
画像経路で overloaded や high demand が出たら、最初の再試行は同じ経路を保ちます。prompt、aspect ratio、SDK、model、batch を同時に変えないでください。まず同じ核心リクエストで確認し、その後 backoff します。画像分岐のままなら batch を下げるかキューへ回します。
確認済みの image 503 には Fix Gemini 3 Pro Image 503 Errors を使います。そこでは code/status が中心で、App のバナーとは分けて考えます。
待つ、切り替える、問い合わせる基準
| 状況 | 次の動き | 理由 |
|---|---|---|
| 同じ経路の再試行が成功 | 継続して監視。 | 一時的な容量不足の可能性。 |
| 同じ経路で 503 のまま | 待機、キュー、計画済み fallback。 | 短い時間では回復していない。 |
| 429 に変わる | quota / rate limit 分岐へ移る。 | 別の問題に変わった。 |
| 504 または client timeout | timeout 予算を調整。 | 再試行だけでは直らない。 |
| 有料ユーザーに upgrade 表示 | アカウントとプラン認識を確認。 | entitlement の問題かもしれない。 |
問い合わせは、経路を説明できる状態になってから行います。モデル、入口、状態、時刻、アカウント、再試行結果があれば、対応が具体的になります。
よくある質問
Gemini high demand とは何ですか？
その時点の Gemini 経路がリクエストを処理できなかったという意味です。アカウント、プロンプト、ブラウザ、コードが壊れている証拠ではありません。
503 high demand は rate limit と同じですか？
違います。503 は一時的な容量や backend unavailable に近く、429 が制限やクォータです。
表示されたらプランを上げるべきですか？
最初の対応ではありません。まずステータス、モデル、表示プラン、同じ経路での再試行を確認します。
Gemini CLI が何度も high demand と言うのはなぜですか？
既定モデルが混雑しているか、上流応答が短い表示に変換されている可能性があります。コマンド、CLI 版、認証、モデル、時刻、再試行結果を残してください。
モデルを変えれば直りますか？
タスクが品質差を許容できるなら一時 fallback になります。診断の第一歩として使うべきではありません。
最後に
Gemini high demand エラーは、先にルーティングする問題です。入口を決め、状態コードを読み、同じ経路で一度だけ再試行し、その後に待機、キュー、fallback、証拠付き問い合わせへ進みます。