Nano Banana Proの503エラー対処：Deadline expired・504の見分け方

Nano Banana Proの画像生成で503 UNAVAILABLEが返ったら、応答元とエラーコードを確認し、再送を許容できるジョブだけ、少し待って同じ条件で再試行します。 The model is overloadedという文言でも、Deadline expired before operation could complete.という文言でも、HTTP 503を受け取っているなら、文言だけで504と判断しないでください。

今止まっている処理には、次の順番で対処します。

1. 送信先、HTTPステータス、APIのエラーコードを残し、本当に503か確かめます。
2. 同じAPI・モデル・入力・出力設定を保ち、待ち時間を挟んで再送します。Retry-Afterがあれば、その指定を尊重します。
3. 決めた回数か処理時間の上限に達したら、画面上の再試行を止めます。あとで処理できる仕事は待ち行列へ、急ぐ仕事は要求を変えてよいかの判断へ進めます。
4. 再送後はコードを読み直し、成功応答なら画像の取得・保存まで確認します。429、504、認証エラーに変わったら、その原因を調べます。

一時的なエラーに待ち時間とランダムなずれを入れ、再試行回数を制限する方針は、Googleのトラブルシューティング ガイドに沿っています。ただし画像生成のPOSTは、再送しても必ず一度だけ実行される仕組みではありません。応答が届かず結果が分からない場合は、下の「応答なし」の手順を先に使います。

503なのにDeadline expiredと出る理由は？

Deadline expiredは、処理が期限内に終わらなかったことを伝える文言です。しかし、それだけでは応答を返したサービスのエラー分類は決まりません。次の組み合わせは、2025年12月から2026年1月のGoogle開発者フォーラムの報告にあります。

{
  "error": {
    "code": 503,
    "message": "Deadline expired before operation could complete.",
    "status": "UNAVAILABLE"
  }
}

これは旧プレビュー版での過去の事例です。現在の障害発生や、特定の修正で必ず復旧することを示す報告ではありません。一方、Deadlineという単語と503が同時に出ることはあるので、文字列の検索だけで504へ振り分ける実装は避けられます。

HTTP、APIの形式、応答元を合わせて確認する

Googleの既存のgenerateContent、Interactions API、SDKの例外は、同じ名前のフィールドでも型や意味が異なります。Interactionsのエラー一覧を、別のAPIのJSON形式へそのまま当てはめないでください。

Google Python SDKのAPIErrorでは数値のcodeを確認できます。str(e)の中に「503」が含まれるかを探すより、例外の属性で判定します。公開ソースの例外定義については2026年10月6日の保存内容を基準としており、手元の導入バージョンの動作は別途確認が必要です。

送信先がgenerativelanguage.googleapis.comなのか、Vertex AIなのか、仲介APIなのかも残します。アプリ側のタイムアウトを独自に503へ変換している場合、その503からGoogleの混雑を推定することはできません。HTTPと本文のコードが食い違う場合も、再送より先に応答元と変換処理を確認します。

HTTPの仕様が定義する503には、過負荷や保守など、一時的に処理できない状態が含まれます。503だけでGPU不足の仕組みや、Google全体の障害、復旧時刻まで分かるわけではありません。

なお、2026年10月7日時点の公式ProのモデルIDはgemini-3-pro-imageです。旧gemini-3-pro-image-previewは提供終了の一覧に2026年6月25日終了と記載されています。古いIDで404が出ているなら、待つよりモデル名の確認が先です。仲介APIが古い名前を受け付ける場合も、Google公式で同じIDが現役とは限りません。

同じ条件で再試行し、回数か時間で止める

503に対する最初の確認では、送信先URL、モデル、認証に使うプロジェクト、入力、画像サイズや比率をそろえます。API、モデル、画像サイズを一度に変えて成功しても、元の画像生成が回復したかは判断できないためです。

同時に送り続けている処理をいったん絞り、ひとつのジョブで再試行を確認すると、大量の再送を避けながら経過を追えます。並列数を下げるのはアプリ側の送信を整えるための判断であり、Googleの内部処理を変更する対策ではありません。

Retry-Afterがあるときは、指定より早く送らない

Retry-Afterは、待つ秒数またはHTTPの日付形式で返ることがあります。受け取った日付は待ち時間へ換算し、指定がない場合は徐々に待ち時間を長くしながら、ランダムなずれを加えます。ヘッダーの定義が根拠です。

たとえば残りの処理時間が30秒なのに、Retry-After: 120が返った場合は、その場の再試行を止めて後回しにします。待ち時間を30秒へ切り詰めて再送しても、サーバーの指定を守ったことにはなりません。

回数・待機・通信時間をひとつの予算に入れる

次は、最初の送信を含めて最大3回、最初の送信開始から180秒、各通信の上限60秒としたアプリ側の設計例です。Google推奨の固定値でも、180秒で復旧するという約束でもありません。必要な画像の処理時間と、利用者が待てる時間に合わせて値を決めます。

この関数はAPIを呼びません。503を正しく識別し、再送による重複生成・追加費用を許容できると判断したあとに、次の送信時刻と残りの通信時間を決める部品です。retry_after_sには、ヘッダーを秒数へ変換した値を渡します。

from math import isfinite

MAX_CALLS = 3            # 最初の送信を含む
JOB_BUDGET_S = 180.0     # 待機と通信を含む
CALL_TIMEOUT_S = 60.0


def plan_503(calls, elapsed_s, retry_after_s=None, jitter=0.5):
    """戻り値: (判断, 待機秒数, 次の通信の上限秒数)。通信はしない。"""
    if type(calls) is not int or calls < 1:
        raise ValueError("callsは実際に送信した回数")
    if not isfinite(elapsed_s) or elapsed_s < 0:
        raise ValueError("elapsed_sは単調増加時計で測った経過秒数")
    if not isfinite(jitter) or not 0 <= jitter <= 1:
        raise ValueError("jitterは0から1の値")
    if retry_after_s is not None:
        if not isfinite(retry_after_s) or retry_after_s < 0:
            raise ValueError("Retry-Afterを非負の秒数へ変換する")
    if calls >= MAX_CALLS:
        return ("stop", 0.0, 0.0)
    wait_s = min(8.0, 2.0 ** calls) * jitter
    if retry_after_s is not None:
        wait_s = max(wait_s, retry_after_s)
    remaining_s = JOB_BUDGET_S - elapsed_s - wait_s
    if remaining_s <= 0:
        return ("defer", 0.0, 0.0)
    return ("retry", wait_s, min(CALL_TIMEOUT_S, remaining_s))


print(plan_503(1, 20.0, jitter=0.5))       # ('retry', 1.0, 60.0)
print(plan_503(2, 170.0, 20.0))           # ('defer', 0.0, 0.0)
print(plan_503(3, 50.0))                 # ('stop', 0.0, 0.0)

実際の呼び出し側では、再試行のたびに新しい乱数を使い、待機が終わった時点で残り時間を測り直します。次の通信の期限は、その残り時間と通信上限の小さいほうに合わせます。SDKごとにタイムアウトの単位が違うこともあるため、この秒数をそのまま任意の設定項目へ渡さないでください。

この例の構文と判定は合成データでオフライン確認しています。SDKの実行、実APIの再送、画像品質、実際の待ち時間や請求額は検証していません。

SDK・アプリ・仲介APIで再試行を重ねない

再試行を管理する場所は、ひとつに決めます。アプリが3回、SDKが各回5回送る構成なら、実送信は最大15回になり得ます。これは回数が重なった場合の計算例で、特定バージョンの既定値を示すものではありません。

GoogleのガイドにはPython SDKの自動再試行に関する説明がありますが、導入済みバージョン、利用するAPI、明示した設定で挙動を確認してください。SDKに任せるならアプリで外側の再試行を増やさず、アプリが管理するならSDKや仲介APIの再送を含めて実送信回数と経過時間を数えます。

503が続いて上限に達したら、未完了としていったん止めます。後で再開する待ち行列には、ジョブID、試行回数、期限、次に処理できる時刻を引き継ぎます。取り出すたびに回数をゼロへ戻すと、無限再送になってしまいます。失敗が広がっている間は新しい送信を一時停止し、少数の確認から再開する運用も選べます。

504と「応答なし」は、別の手順で調べる

HTTP 504を受け取った場合

HTTP 504の定義は、ゲートウェイやプロキシが上流から時間内に応答を得られなかった状態です。Googleのエラー本文があるなら、そのAPIのDEADLINE_EXCEEDEDやdeadline_exceededも合わせて読みます。

最初に、アプリ、SDK、プロキシ、上流APIのどこで期限に達したか、開始時刻と経過時間を照合します。自分が管理する待機時間が短すぎていると分かった場合は、その設定を見直せます。しかし、すでに上流が504を返した処理は、クライアントの待機時間を延ばしても成功へ変わりません。

同じ入力で期限内に完了しない場合は、入力を軽くする、出力サイズを下げる、処理を後回しにする、といった選択が必要です。ひとつずつ変えて結果を比べ、4Kが必要な仕事で2Kが返った場合は、元の要件を満たしたかを別に確認します。Proはモデル仕様でThinkingを無効にできないため、一般的な「Thinkingを切る」という助言をProへそのまま適用しないでください。

HTTP応答を受け取れなかった場合

タイムアウト例外や通信の切断だけでは、サーバーが生成していないと断定できません。生成が終わったのに応答だけ失われた可能性もあるため、まず自動再送を止めます。

1. すでに保存された画像や、利用中のサービスにあるジョブ結果を確認します。
2. プロバイダーの正式な結果取得機能があり、既存のIDを持っている場合は、その結果を照合します。
3. 結果を確認できなければ「成否不明」として残し、重複生成と追加費用を許容するか決めてから再送します。

アプリで作るジョブIDは、二重クリックや二重登録の防止に使えます。ただし同じIDやプロンプトを送るだけで、Google側が重複実行を防ぐとは限りません。画像生成POSTの再送条件は、HTTPの冪等性に関する規定も踏まえて判断します。

HTTP 200で終わらず、必要な画像が保存できたか確認する

復旧を確認するのは、元のAPI・モデル・入力・出力設定で、必要な画像を受け取れたときです。HTTP 200、テキストだけの返答、キューへの登録完了は、それぞれ画像生成の完了とは分けて扱います。

APIごとの形式は画像生成ガイドで確認できます。新規実装に推奨されるInteractionsへ移ることと、既存のgenerateContentの503が復旧したことは別です。既存APIも引き続きサポートされています。

取り出したデータはBase64をデコードし、空でないことと返却MIMEを確認して保存します。そのファイルが画像として開けること、必要な枚数、サイズ・比率、内容が仕事の要件を満たすことまで確認してください。途中まで得られた有効な画像は残し、不足分をどう扱うか決めます。保存処理を含む実装は、Nano Banana Pro APIのJSON設定と画像保存の手順で扱っています。

200なのに画像がない場合は、本文のエラー、ブロック理由、画像取得処理を確認します。Interactionsのno_imageや画像の安全性に関するエラーは、503の混雑とは別の問題です。画像がないという理由だけで何度も生成し直したり、安全性の設定を弱めたりしないでください。

4Kを下げる・別APIへ移るのは、暫定対応として選ぶ

4Kが必須なら、同じ4K条件での成功を確認するまでは、元の処理は未完了です。締め切りが優先で2Kでも使える仕事なら、解像度を下げる暫定対応を選べます。その場合は、2Kで納品してよいかを確認し、元の4Kジョブと結果を分けて残します。

2026年4月3日のnoteの報告では、ひとりの利用者が4Kで503となる一方、1K・2Kや手動の生成では利用できたと記しています。APIの割り当てや上位プランに関する説明は同記事の仮説で、現在のProの4K制限やプラン変更の効果を証明するものではありません。アップスケールも、元のAPIから4K画像を受け取った結果とは区別します。

別モデル・別プロバイダーへ切り替える場合も、必要な画像サイズ、比率、参照画像、料金、入力データの扱いを先に確かめます。送信先だけでなく、認証、リクエスト、画像の取得形式が変わることもあります。切り替え先で成功したら「代替手段で完成」と記録し、Googleの元の503が解消した証拠にはしません。

別のエラーに変わったら、503の再試行を終了する

毎回の応答でエラーを読み直し、次の状態になったら処理を切り替えます。Googleのエラー一覧はInteractionsの文字列コードを説明しているため、他のAPIではその提供元の定義も照合してください。

429に変わった場合は、Gemini画像生成の毎分・日次・支出上限の見分け方で、エラー本文の上限名を照合します。枠はプロジェクト単位なので、キーを作り直すことから始めません。

503が続く場合に問い合わせへ残す情報は、発生時刻、送信先、モデルID、HTTPコード、APIのエラーコード、試行回数、経過時間、取得済みのリクエストIDです。キー、非公開のプロンプト、入力画像などは共有ログへ載せないようにします。

よくある質問

Deadline expiredが出たら、すぐタイムアウトを延ばせばよいですか？

503を受け取っているなら、まず上限付きの再試行です。HTTP 504なら期限を返した場所を確認し、HTTP応答自体が届いていないなら結果確認を先にします。文言だけでこの3つをまとめないでください。

有料のTier 1でも503は出ますか？

出ることはあります。2025年12月の公式フォーラムの利用者報告には、課金済みTier 1での503があり、後に利用できたと記されています。有料化やティア変更が503を確実に直すとはいえません。429で利用枠に達した場合の対処とは分けます。

503なら料金はかからず、何度再送してもよいですか？

その前提では再送しません。503の状態コードだけでは請求や返金は判断できず、成否不明の通信を再送すれば重複する可能性もあります。公式Proの料金表に無料API枠は表示されていないため、再試行も利用予算の中で管理してください。仲介APIを使う場合は、その提供元の課金条件を確認します。

いつまで待てば復旧しますか？

503には一律の復旧時間がありません。Retry-Afterがあれば待機の目安として守り、なければ回数と総時間を決めて再試行します。上限に達したら後回しにするか停止し、ずっと画面を待たせないようにします。再開しても画像の保存まで確認することが、完了の判断です。