Geminiで503「The model is overloaded」が出る原因と対処

Gemini APIで突然「The model is overloaded」が返り、処理が止まって困っていませんか。このエラーの意味と、実装すべきリトライの形を解説します。

「The model is overloaded」の意味

日本語訳と意味

まずはメッセージが何を言っているかを押さえます。

• 直訳すると「モデルが過負荷状態です。後で再試行してください」という意味になります。
• 後半の「Please try again later」は、ユーザー側に過失がないため時間を置いてから再度試すよう促す指示です。

つまり、このエラーはユーザー側の設定ミスではなく、Geminiのインフラ側で一時的にリソースが不足していることが直接的な原因であることを伝えています。

公式の定義

Googleの公式トラブルシューティングガイドでは、この503エラーの状態をより具体的に定義しています。

• サービスが一時的に過負荷状態にあるか、あるいは何らかの理由でダウンしている際に発生します。
• 公式ドキュメントが推奨しているのは、指数バックオフを用いた待機と再試行です。

発生環境

• REST APIを直接HTTPSリクエストで叩いている環境では、JSON形式のレスポンスの一部として返却されます。
• PythonやNode.jsなどの公式SDKを使用している場合、ServerErrorという例外クラスとして検知されます。
• Google AI Studioの画面上でも、同じ趣旨のメッセージが表示されることがあります。

関連記事：Geminiで「リクエストが集中しています」と出る原因と対処法

503と429は原因が逆

エラーコードの判別

エラーの種類によって対処は変わります。公式の一覧で違いを確認してください。

表①：Gemini API 公式エラーコード表

エラー名	ステータスコード	Description（公式原文）	Recommended action（公式原文）
service_unavailable	503 Service Unavailable	The service is temporarily overloaded or down.	Wait and retry with exponential backoff.
rate_limit_exceeded	429 Too Many Requests	You have exceeded the per-minute or per-second request or token limit.	Wait and retry with exponential backoff.
quota_exceeded	429 Too Many Requests	You have exceeded your daily quota.	Wait until the quota resets or request a quota increase.
api_error	500 Internal Server Error	An unexpected error occurred on the server.	Retry the request. If it persists, contact support.

出典：Gemini API 公式ドキュメント「API errors」（2026年8月29日確認）

• 503はサーバー側の問題であるため、基本的にはユーザー側は「待ってから再試行する」しかありません。
• 429はユーザー側のリクエスト送信頻度が高すぎることが原因であるため、送信ペースを落とす工夫が必要です。
• クォータ（割当）超過の場合は、プランのアップグレードや上限緩和申請を検討する必要があります。

どちらのエラーかによって、次にやることが逆になります。

status判定

google.genai.errors.ServerError: 503 UNAVAILABLE. {'error': {'code': 503, 'message': 'The model is overloaded. Please try again later.', 'status': 'UNAVAILABLE'}}

• statusフィールドが「UNAVAILABLE」となっていれば、それは明確に503エラーを指しています。
• 一方で「RESOURCE_EXHAUSTED」と表示されている場合は、503ではなく429エラーとして処理すべきです。
• エラーコードの数値（503や429）を直接見るよりも、このステータス文字列を確認する方が、より確実な判定に繋がります。

表②：503と429の見分け方

項目	503（Service Unavailable）	429（Too Many Requests）
主な原因	Google側のサーバー混雑・障害	こちら側のリクエスト過多・割当超過
レスポンスstatus	UNAVAILABLE	RESOURCE_EXHAUSTED
正しい対処	指数バックオフによる自動リトライ	送信頻度の抑制・上限緩和申請

関連記事：Geminiのエラー429対処法｜原因特定と安定運用の設定変更

対処の手順

SDKのリトライ活用

公式SDKには、一時的なエラーを自動で再試行する仕組みが既定で入っています。

• 公式SDKはタイムアウトやネットワークエラー、さらに5xx系のサーバーエラーを自動で処理します。
• Python SDKの場合、初期遅延1秒から最大60秒の間で、指数バックオフによる待機時間が自動計算されます。
• デフォルト設定では最大4回までのリトライが自動的に行われ、多くの場合はこれでエラーが解消します。

自前で書く前に、SDKの標準機能が効いているかをログで確かめてください。

The official client SDKs for the Gemini API, such as the Python SDK, include automatic retry logic with exponential backoff by default for handling transient errors like timeouts, network issues, and rate limits (429 and 5xx status codes). For example, the Python SDK automatically retries transient errors up to four times with an initial delay of approximately 1 second and a maximum delay of 60 seconds.
（公式SDKは、タイムアウトやネットワーク問題、レート制限などの一時的なエラーに対し、デフォルトで指数バックオフを用いた自動リトライ機能を備えています。例えば、Python SDKは最大4回まで、初回は約1秒、最大60秒の遅延を設定して自動的に再試行します。）

指数バックオフの実装

自前でリトライを書くときは、全員が同時に再試行してサーバーを押し戻さない工夫が要ります。

• 指数バックオフを採用し、リトライの間隔を2秒、4秒、8秒と段階的に広げるように設計してください。
• 待機時間に「ジッター」と呼ばれるランダムな数値を加え、複数のリクエストが衝突するのを防ぎます。
• ジッターがないと、全クライアントが全く同じタイミングでリトライしてサーバーを再度ダウンさせかねません。

リトライ回数の制限

無限ループを防ぐため、リトライ回数の上限は必ず決めます。

• 最大リトライ回数をあらかじめコード内で定義し、それを超えたらエラーとして処理を終了させます。
• 公式ドキュメントでも、無限ループ防止のために上限設定を行うことの重要性が明記されています。
• 上限まで再試行しても解消しない場合は、サーバー側の障害を疑って切り分けに移ります。

実行数と出力の見直し

リトライでも解消しないときは、1回のリクエストが重すぎないかを見直します。

• 一度に送信するプロンプトのトークン量を減らすことで、サーバー側のメモリ負荷を下げることができます。
• システム全体で同時並列に実行しているリクエスト数を抑え、サーバーの処理待ちキューに空きを作ります。
• API設定のmax_output_tokensの値を小さくし、レスポンスの生成にかかる計算時間を短縮させます。

知っておきたい落とし穴

クォータ消費の注意点

Google AI開発者フォーラムでは、503エラーへの対応において注意すべき挙動が報告されています。

• 503エラーが発生した際のリクエストも、内部的に利用回数としてカウントされている可能性があります。
• 503に対して執拗にリトライを繰り返すと、最終的に429エラー（RESOURCE_EXHAUSTED）へ移行した事例があります。
• 失敗したリクエストがAPIの上限枠を消費する場合があるため、リトライ間隔は十分に空けるべきです。

エラーだからといって無制限に叩き続けると、意図せぬクォータ制限に陥り、長時間APIが使えなくなるリスクがあることを覚えておきましょう。

有料プランでの発生

有料プランを契約していても、503エラーは避けられません。同フォーラムには、有料のGemini 2.5 Proで1週間に10回以上発生したという報告もあります。

• 無料枠のユーザーだけでなく、課金設定を完了しているビジネス環境でも503エラーは等しく発生します。
• 課金は「クォータ（上限）」を増やしますが、サーバーの瞬間的なパンクを保証するものではありません。
• 特定のリージョンや最新モデルにアクセスが集中すると、プランに関係なく一時的に処理が制限されます。

直らないときの確認先

Googleの障害確認

リトライを入れてもエラーが消えないときは、Google側で障害が起きている可能性があります。

• Googleが公開しているステータス確認ページで、異常が出ていないかを確認します。
• 障害が発生している場合は、公式からの復旧アナウンスがあるまで、コードを修正せずに待機するのが賢明です。

他ユーザーの状況確認

公式のステータスが更新される前でも、SNSやフォーラムで状況をつかめることがあります。

• X（旧Twitter）や開発者フォーラムでエラーメッセージを検索し、同時多発的な報告がないか探します。

サポートへの報告情報

サポートへ問い合わせるときは、調査が早く進むよう次の情報を添えます。

• 発生したエラーメッセージの全文と、ミリ秒単位まで含めた正確なタイムスタンプを提示します。
• 使用しているモデルの正確な名称と、リクエストを送信したリージョン情報を記載してください。
• リクエストの平均的な頻度や並列実行数など、再現環境の具体的な情報を整理して伝えると、問題の切り分けがスムーズになります。

まとめ

• 503エラーはサーバー側が一時的に混雑している合図であり、基本的には「待ち」で解決すべき事象です。
• 公式SDKは最大4回のリトライを、初回1秒・最大60秒の遅延で自動実行する機能を備えています。
• 自分でリトライを実装する場合は、ジッター（ランダムな遅延）を加え、試行回数の上限を必ず設定してください。
• 503を過剰にリトライし続けると、内部的にクォータを消費し、429エラーを誘発する恐れがあります。
• まずは公式のステータスボードやSNSで障害情報を確認し、広範囲の問題でないかを調査してから実装を見直してください。

次に503が出たら、まずログでリトライ回数の上限に達していないかを確認してください。