複雑なコードのレビューを Gemini 2.5 Pro に頼んだ瞬間、画面に「このモデルは現在過負荷です。しばらくしてからもう一度試してください」と表示された経験はないでしょうか。長文を貼り付けてじっくり分析してもらおうと思ったタイミングに限って出てくる、ちょっと困るエラーです。
このエラーは何が起きているのか、そしてどうすれば早く解消できるのか — 実際にいくつかのパターンで試した経験をもとに整理してみます。
「過負荷」とはどういう状態か
まず、このメッセージが意味することを整理しましょう。「モデルが過負荷」というのは、そのモデルを実行するサーバーが現時点で処理できる上限に達しているという状態です。つまり Google 側の問題であり、あなたのリクエスト内容・アカウント設定・インターネット環境とは無関係です。
Gemini 2.5 Pro のような高性能モデルは、Flash 系モデルと比べてリソース消費が大きいため、同時リクエスト数の上限が低めに設定されています。特に以下のタイミングで起きやすいです。
- JST の午前9〜12時、夜20〜24時 — 日本や米国東部の業務時間帯と重なるピーク時
- Google I/O 前後や大型モデルのリリース直後 — アクセスが急増する時期
- 非常に長いプロンプト・大きなファイルを添付したとき — 処理負荷が高いリクエストが多く届いている状態
覚えておいてほしいのは、このエラーは一時的なものだということです。数分から数十分後に同じリクエストが通ることがほとんどです。
まず試してほしい3つの対処
1. 少し待ってからリトライする
最もシンプルで効果的な対処法です。ブラウザを閉じずに1〜3分待ってから「再生成」ボタンを押すか、同じメッセージを送り直してみてください。多くの場合これだけで解消します。
即座にリトライを繰り返すのは逆効果になることがあります。すでに混雑しているサーバーに同じリクエストを連打しても、キューが詰まるだけです。少し間を置く方が通りやすくなります。
2. Gemini 2.5 Flash に切り替えてみる
Gemini の画面右上(またはチャット欄左下)のモデル選択から Gemini 2.5 Flash に変えてみてください。Flash は Pro よりもサーバーリソースの占有が少なく、同じ処理量でも過負荷になりにくい設計です。
「Pro でないと品質が下がるのでは」と思われるかもしれませんが、日常的な文章要約・コード補完・翻訳・アイデア出しのような用途では Flash でも十分な品質が出ます。過負荷エラーを避けながら作業を続けるには、用途に応じてモデルを使い分けるのが現実的な対応策です。
3. タスクを分割してプロンプトを短くする
過負荷は「今の瞬間にどれだけの処理が集中しているか」で決まります。3,000 トークンを超えるような長い入力を1回で渡すより、500〜1,000 トークン程度に分割して数回に分けて送る方がサーバーへの負荷を分散できます。
たとえば長いコードベースのレビューなら、ファイル単位・機能単位で分割して送る、という具合です。結果的に精度が上がることもありますし、過負荷エラーを踏みにくくなるメリットもあります。
API 経由で使っている場合のエラー処理
Gemini API を組み込んだアプリケーションで「モデルが過負荷」状態のリクエストが来た場合、503 UNAVAILABLE または 429 RESOURCE_EXHAUSTED のステータスコードでエラーが返ってきます。
以下は Python で指数バックオフ(Exponential Backoff)を実装した基本的な例です。
import google.generativeai as genai
import time
import random
def generate_with_retry(model, prompt, max_retries=5):
"""
過負荷・レート制限エラー時に指数バックオフでリトライするラッパー関数。
503 (UNAVAILABLE) と 429 (RESOURCE_EXHAUSTED) の両方に対応。
"""
for attempt in range(max_retries):
try:
response = model.generate_content(prompt)
return response # 成功したらそのまま返す
except Exception as e:
error_str = str(e).lower()
# 過負荷または レート制限エラーか判定
is_retryable = (
"503" in error_str or
"unavailable" in error_str or
"overloaded" in error_str or
"429" in error_str or
"resource_exhausted" in error_str or
"quota" in error_str
)
if not is_retryable:
# リトライ対象外のエラー(400 Invalid argument 等)はそのまま raise
raise
if attempt == max_retries - 1:
# 最大リトライ回数に達したら諦めて raise
print(f"最大リトライ回数 ({max_retries}回) に達しました。")
raise
# 指数バックオフ: 2^attempt 秒 + ランダムジッター(最大60秒)
wait_seconds = min(60, (2 ** attempt) + random.uniform(0, 1))
print(f"Attempt {attempt + 1}: {e}")
print(f" → {wait_seconds:.1f}秒後にリトライします...")
time.sleep(wait_seconds)
# 使い方
genai.configure(api_key="YOUR_GEMINI_API_KEY")
model = genai.GenerativeModel("gemini-2.5-flash")
response = generate_with_retry(
model,
"Pythonで二分探索を実装してください。コメント付きで。"
)
print(response.text)
# 期待される動作:
# - 正常時: 即座にレスポンスが返る
# - 過負荷時: Attempt 1 → 待機1秒 → Attempt 2 → 待機2秒 → ... と徐々に間隔を広げてリトライこのコードのポイントはランダムジッターを加えていることです。複数のインスタンスが同時に動いているとき、全員が同じタイミングでリトライすると再び過負荷を引き起こします。少しランダム性を加えることでリクエストが分散します。
JavaScript(Node.js)での実装例
import { GoogleGenerativeAI } from "@google/generative-ai";
const genai = new GoogleGenerativeAI("YOUR_GEMINI_API_KEY");
async function generateWithRetry(prompt, maxRetries = 5) {
const model = genai.getGenerativeModel({ model: "gemini-2.5-flash" });
for (let attempt = 0; attempt < maxRetries; attempt++) {
try {
const result = await model.generateContent(prompt);
return result.response.text();
} catch (error) {
const message = error.message?.toLowerCase() ?? "";
const isRetryable =
message.includes("503") ||
message.includes("unavailable") ||
message.includes("overloaded") ||
message.includes("429") ||
message.includes("resource_exhausted");
if (!isRetryable || attempt === maxRetries - 1) {
throw error;
}
// 指数バックオフ + ジッター
const waitMs = Math.min(60000, Math.pow(2, attempt) * 1000 + Math.random() * 1000);
console.log(`Attempt ${attempt + 1} failed. Retrying in ${(waitMs / 1000).toFixed(1)}s...`);
await new Promise((resolve) => setTimeout(resolve, waitMs));
}
}
}
// 使い方
generateWithRetry("JavaScriptで非同期処理を10行で説明してください")
.then(console.log)
.catch(console.error);本番環境では max_retries を 3〜5 程度に設定し、Gemini 2.5 Pro がエラーになった場合に Gemini 2.5 Flash にフォールバックする設計にすると、ユーザーへの影響を最小限に抑えられます。
過負荷エラーが頻繁に出る場合は
一日に何度もこのエラーに遭遇するようであれば、以下を確認してみてください。
プランの確認: 無料プランの場合、Gemini 2.5 Pro の利用枠はかなり制限されています。Google AI Pro(月額 ¥2,900 程度)または Ultra にアップグレードすると、より多くのリクエストを処理できるようになります。Gemini のプラン選択ガイド も参考にしてみてください。
API 利用者の場合: 無料枠(Google AI Studio の Free Tier)では RPM(1分あたりのリクエスト数)制限が厳しく設定されています。本番利用には API の料金体系とフリー枠戦略 を確認の上、有料プランへの移行を検討してみてください。
ステータスページの確認: Google Workspace Status Dashboard(www.google.com Gemini のサービス状況を確認できます。Google 全体で障害が発生している場合は、少し時間をおくしかありません。
503 エラーとの関係について
Gemini API を利用している場合、「モデルが過負荷」のエラーは技術的には 503 UNAVAILABLE として返ってきます。チャット UI に表示される「このモデルは現在過負荷です」というメッセージは、この 503 エラーをわかりやすい言葉に変換したものです。
API 側の詳しい実装(リトライ実装・バックオフ設計・サーキットブレーカーパターン)については、Gemini API 503 エラーの対処と実践的なリトライ実装 に詳しくまとめてあります。
全体を振り返って
「このモデルは現在過負荷です」エラーは、Google 側のサーバー負荷が原因です。あなたのアカウントやプロンプトには問題ありません。
すぐ試してほしい対処の優先順位は:
- 1〜3分待ってリトライ — ほとんどはこれで解消する
- Gemini 2.5 Flash に切り替え — Pro でなくても多くのタスクは対応できる
- プロンプトを分割して送る — 長文入力は負荷が高い
API 利用者であれば、今回紹介した指数バックオフの実装を入れておくだけで、過負荷エラーをユーザーが体験することはほぼなくなります。ぜひ組み込んでみてください。