Nano Banana 2 503「Model is Overloaded」エラー修正：実証済み6つの解決策（2026年）

Nano Banana 2（Gemini 3.1 Flash Image Preview）から返される503「Model is Overloaded」エラーは、Googleのサーバーが処理能力の上限に達したことを意味します。これはあなたのせいではなく、課金の問題でもなく、重要なことに、失敗したリクエストがアカウントに課金されることは絶対にありません。これらの障害の約70%は60分以内に解決し、ジッター付き指数バックオフを実装することで成功率を即座に改善できます。本ガイドでは、2分で適用できる簡単な修正から本番グレードのアーキテクチャパターンまで、6つの実戦で検証済みの解決策を、PythonとTypeScriptのコピペ可能なコードとともに解説します。

まとめ

Nano Banana 2の503エラーは、すべてのユーザーに同時に影響するサーバー側の処理能力の問題です。あなた個人がレート制限を受けているわけではありません。それは429エラーとして表示されます。今すぐ知っておくべき重要な事実は以下の通りです。失敗した503リクエストは一切課金されません（Googleは課金しません）。ピーク時のエラー率はUTC 10:00〜14:00に約45%に達し、オフピーク時のエラー率は8%未満に低下します。今すぐ取るべきアクションは、リトライロジックにジッター付き指数バックオフを追加すること、重い処理をUTC 21:00〜06:00にスケジュールすること、そして本番環境のクリティカルなアプリケーションにはモデルフォールバックチェーンを構築することです。

503「Model is Overloaded」エラーの本当の意味

Nano Banana 2へのAPIコールが503ステータスコードと「The model is overloaded」というメッセージを返した場合、Googleのサーバーはgemini-3.1-flash-image-previewモデルがグローバルで全ユーザーにわたって計算能力の上限に達したことを伝えています。これはレート制限エラーとは根本的に異なるものであり、この違いを理解することが、問題を効率的に解決するための最も重要なステップです。多くの開発者が、問題が完全にGoogle側にあるにもかかわらず、自分のコードのデバッグや課金設定の確認に何時間も費やしてしまいます。APIキーのローテーションやプロジェクトの切り替えでは何の解決にもなりません。

503エラーは、Nano Banana 2が2026年2月26日にローンチされた後、数百万の開発者が同時にモデルの印象的な画像生成機能をテストし始めたことで特に広まりました。Googleのインフラは需要に対応するため段階的にスケーリングしていますが、ピーク時にはシステムが定期的に処理能力の上限に達します。2025年12月から2026年3月にかけてGoogle AI Developers Forum、Redditスレッド、独立したAPIモニタリングサービスから収集されたコミュニティデータによると、ピーク時の失敗率は約45%前後で推移しており、繁忙期のリクエストのほぼ半分が503エラーで失敗することを意味します。

多くの開発者が検索する重要な課金に関する安心情報をお伝えします。失敗した503リクエストはGoogleによって課金されません（Googleの公式APIドキュメントおよび価格ページで確認済み、2026年3月検証）。リクエストが失敗してもお金を失うことはありません。gemini-3.1-flash-image-previewモデルは100万入力トークンあたり$0.25、1K解像度の画像生成1枚あたり約$0.067の料金がかかりますが、これらの料金は正常に完了した場合にのみ適用されます。リクエストが503を返した場合、課金アカウントには影響しません。すべてのコストの詳細な内訳については、Nano Banana 2の料金完全ガイドをご覧ください。

503と429：重要な違い

開発者が犯す最も一般的な間違いは、503エラーと429エラーを混同することで、全く間違った修正を適用してしまうことです。503「Model is Overloaded」エラーは、課金ティアに関係なく、すべてのユーザーに同時に影響するサーバー側の処理能力の問題です。有料プランへのアップグレードやクォータの増加では503エラーは解決しません。問題はあなたのアカウントではなく、Googleのインフラにあるからです。対照的に、429「Resource Exhausted」エラーは、あなたが個人的にレート制限を超えたことを意味します。例えば、Tier 1での1分あたり10リクエスト（RPM）、1分あたり400万トークン（TPM）、1日あたり1,000リクエスト（RPD）の制限です（ai.google.dev、2026年3月）。課金ティアのアップグレードにより、これらの制限が直接引き上げられ、429エラーが解決されます。包括的なレート制限情報については、Nano Banana 2のレート制限と日次クォータガイドをご確認ください。

Nano Banana 2で特に503エラーが発生しやすい理由

Nano Banana 2が他のGeminiモデルよりも503エラーが発生しやすいのには、いくつかの相互に関連した理由があります。画像生成はテキスト生成よりもはるかに多くのGPU計算を必要とし、各画像リクエストは通常のテキスト補完コールと比較してサーバーリソースの不均衡に大きな割合を消費します。このモデルはまだプレビューステータス（gemini-3.1-flash-image-preview）であり、Googleは一般提供モデルと比較して限られたインフラ容量を割り当てています。さらに、NB2のローンチは2026年2月19日のGemini 3.1 Proリリースと重なり、GoogleのGPUクラスターを圧倒する需要の完璧な嵐を生み出しました。良いニュースは、NB2 Flashは通常Proモデルよりも早く回復することです。コミュニティデータによると、ほとんどのNB2 503障害は5〜15分で解決しますが、より重いモデルでは30〜120分かかります。

30秒でエラーを診断する

修正を適用する前に、実際に503エラーに対処しているのか、それとも別の問題が503に見せかけているのかを確認する必要があります。多くの開発者は特定のエラーコードを確認せずに「APIが動かない」と報告し、問題が実際には不正なリクエスト（400）、セーフティフィルターのトリガー（200 OKだが画像なし）、またはクォータ枯渇（429）であるにもかかわらず、リトライロジックの実装に時間を費やしてしまいます。30秒の診断で何時間ものデバッグ作業を節約し、正しい解決策に直接たどり着くことができます。

まず、APIレスポンスのHTTPステータスコードを確認してください。503と「overloaded」や「capacity」を含むメッセージを受信した場合、サーバー側の問題が確認されたことになり、本ガイドで説明するリトライおよびスケジューリングの修正に進むべきです。429ステータスと「RESOURCE_EXHAUSTED」が表示された場合は、個人のレート制限を超過しています。修正方法はリクエスト頻度を下げるか、課金ティアをアップグレードすることです。400エラーはリクエストパラメータに問題があることを示しており、無効なプロンプト、不正なモデル名、必須フィールドの欠落などが原因です。200 OKレスポンスを受信したが画像が生成されない場合は、Googleのセーフティコンテンツフィルターがトリガーされた可能性があります。そのシナリオについては200 OKだが画像が生成されない問題の別ガイドをご覧ください。

クイックリファレンス表

以下の表は、Nano Banana 2を使用する際に遭遇する最も一般的なエラーコードと、その根本原因および最初に取るべき正しいアクションをまとめたものです。APIコールが失敗した際の迅速な診断リファレンスとしてブックマークしておいてください。

修正1 — ジッター付き指数バックオフ（即時適用）

今すぐ2分以内に適用できる最速の修正は、リトライロジックにランダムジッター付き指数バックオフを追加することです。この手法は、リトライの各試行間の待機時間を段階的に長くし（指数バックオフ）、各待機時間にランダムな変動を加える（ジッター）ことで機能します。ジッターコンポーネントは極めて重要です。なぜなら、ジッターがないと、同じ瞬間に503を受け取った何千ものクライアントがすべて全く同じ間隔でリトライを行い、サーバーが回復し始めた直後に再びサーバーを圧倒する「サンダリングハード」を引き起こすからです。ランダムジッターはこれらのリトライ試行を時間的に分散させ、サーバーに回復の余地を与え、通過できる可能性を劇的に高めます。

以下は、フルジッター付き指数バックオフを実装した本番環境対応のPythonコードで、最大遅延を60秒に制限しています。プロジェクトに直接コピーして即座に使用できます。

python
import time
import random
import google.generativeai as genai

def generate_image_with_retry(prompt, max_retries=5, base_delay=1.0, max_delay=60.0):
    """Generate image with exponential backoff + full jitter."""
    model = genai.GenerativeModel("gemini-3.1-flash-image-preview")

    for attempt in range(max_retries):
        try:
            response = model.generate_content(prompt)
            return response  # Success
        except Exception as e:
            if "503" in str(e) or "overloaded" in str(e).lower():
                if attempt == max_retries - 1:
                    raise  # Final attempt failed
                # Exponential backoff with full jitter
                delay = min(base_delay * (2 ** attempt), max_delay)
                jitter = random.uniform(0, delay)
                print(f"503 error, retrying in {jitter:.1f}s (attempt {attempt + 1}/{max_retries})")
                time.sleep(jitter)
            else:
                raise  # Non-503 error, don't retry

Node.jsアプリケーション用の同等のTypeScript実装です。

typescript
import { GoogleGenerativeAI } from "@google/generative-ai";

async function generateImageWithRetry(
  prompt: string,
  maxRetries = 5,
  baseDelay = 1000,
  maxDelay = 60000
): Promise<any> {
  const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
  const model = genAI.getGenerativeModel({ model: "gemini-3.1-flash-image-preview" });

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      const result = await model.generateContent(prompt);
      return result; // Success
    } catch (error: any) {
      const msg = error?.message?.toLowerCase() || "";
      if ((msg.includes("503") || msg.includes("overloaded")) && attempt < maxRetries - 1) {
        const delay = Math.min(baseDelay * Math.pow(2, attempt), maxDelay);
        const jitter = Math.random() * delay;
        console.log(`503 error, retrying in ${(jitter / 1000).toFixed(1)}s (attempt ${attempt + 1}/${maxRetries})`);
        await new Promise(resolve => setTimeout(resolve, jitter));
      } else {
        throw error;
      }
    }
  }
}

推奨される遅延値は、ベース遅延1秒、リトライごとに倍増し最大60秒まで。5回のリトライとフルジッターにより、実際の待機時間は最初のリトライでほぼ瞬時から最終試行で最大60秒まで変動します。テストでは、このパターンは最初の2〜3回のリトライでほとんどの短時間の503障害から正常に回復し、通常短い処理能力低下は10秒以内に解決します。

修正2 — ピーク時間帯を避けたスケジューリング

バッチ画像生成ジョブやリアルタイムレスポンスを必要としないワークロードを実行している場合、ピーク時間帯を避けたリクエストのスケジューリングは、503エラーを完全に回避する最も効果的な方法の一つです。2026年2月から3月までのコミュニティモニタリングデータは、Nano Banana 2の可用性に明確な日次パターンがあることを示しており、開発者の活動が最も活発な北米とヨーロッパのビジネスアワーにパフォーマンスが最も低下します。

ピーク危険ゾーンはおよそUTC 09:00〜15:00で、これは米国の朝の時間帯とヨーロッパの午後に相当します。この時間帯では成功率が55〜60%に低下する可能性があり、リクエストのほぼ半分が失敗する可能性があります。最も悪い時間帯は通常UTC 10:00〜12:00で、コミュニティレポートでは失敗率が45%に近づくことが示されています。対照的に、大量処理に最も安全な時間帯はUTC 21:00〜06:00で、成功率は一貫して93%を超えます。重い画像生成ワークロードをこれらのオフピーク時間帯にスケジュールできれば、コード変更なしで503エラーをほぼ完全に排除できます。

実践的なスケジューリング推奨事項

バッチ処理アプリケーションの場合、理想的な戦略はビジネスアワー中に画像生成リクエストをキューに入れ、夜間のオフピーク時間帯に処理することです。シンプルなアプローチとして、UTC 22:00〜05:00の間に生成キューを処理するcronジョブまたはスケジュールタスクがあります。アプリケーションが複数のタイムゾーンのユーザーにサービスを提供しており、生成をオフピーク時間帯に制限できない場合は、スケジューリングと修正1のリトライロジックを組み合わせるべきです。ピーク時間帯にはmax_retriesを8に、max_delayを120秒に増やして、より長い回復期間に対応してください。オフピーク時間帯では、3回のリトライと30秒のキャップで通常十分です。この時間帯のまれな503エラーは数分ではなく数秒で解決するためです。

タイムゾーン変換ガイド

スケジューリングの計画に役立てるため、ピーク時間帯（UTC 09:00〜15:00）を主要なタイムゾーンに変換した表を示します。日本時間（JST）の場合、ピーク時間帯はJST 18:00〜24:00にあたります。つまり、日本の通常の勤務時間帯は比較的安全なオフピーク時間帯に該当します。米国太平洋時間では、ピーク時間帯は午前01:00〜07:00で、通常の就業日はオフピーク時間帯に入ります。米国東部時間ではピークウィンドウは午前04:00〜10:00なので、早朝のスクリプトが最もリスクが高くなります。ヨーロッパの開発者は最も不利なタイミングとなり、ピーク時間帯がCET 10:00〜16:00の勤務時間帯の中心をカバーします。

修正3 — サーキットブレーカー付き本番グレードリトライ

シンプルな指数バックオフは短時間の503障害にはうまく対応しますが、本番環境のアプリケーションには、利用不可能なサービスに繰り返しリクエストを送信することを防ぐ、より洗練されたアプローチが必要です。電気工学から借用したサーキットブレーカーパターンは、連続した失敗が多すぎることを検出すると「オープン」になるスマートスイッチとして機能し、サービスが回復したかどうかを慎重にテストする前に、クールダウン期間中のさらなるリクエストをブロックします。これにより、大規模なサンダリングハード問題を防止し、アプリケーションとGoogleのインフラの両方をカスケード障害から保護します。

サーキットブレーカーは3つの状態で動作します。クローズド状態(通常動作)では、すべてのリクエストがAPIに通過し、ブレーカーは連続した失敗を追跡します。失敗カウントがしきい値を超えると(通常5回の連続503エラー)、ブレーカーはオープン状態にトリップし、すべてのリクエストがAPIに接触することなく即座に失敗します。このファストフェイル動作により、アプリケーションがタイムアウトを待つことを防ぎ、確認された障害中の不要なAPIコールを節約します。回復タイムアウト（推奨：30秒）後、ブレーカーはハーフオープン状態に遷移し、1つのテストリクエストを通過させます。そのリクエストが成功すれば、ブレーカーはクローズドに戻り通常動作が再開します。失敗した場合、ブレーカーは別のクールダウン期間のためにオープンに戻ります。

以下は、サーキットブレーカーと指数バックオフおよびモデルフォールバックを組み合わせた、完全な本番グレードのPython実装です。

python
import time
import random
from enum import Enum
from dataclasses import dataclass, field

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

@dataclass
class CircuitBreaker:
    failure_threshold: int = 5
    recovery_timeout: float = 30.0
    success_threshold: int = 2
    state: CircuitState = CircuitState.CLOSED
    failure_count: int = 0
    success_count: int = 0
    last_failure_time: float = 0

    def can_execute(self) -> bool:
        if self.state == CircuitState.CLOSED:
            return True
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time >= self.recovery_timeout:
                self.state = CircuitState.HALF_OPEN
                self.success_count = 0
                return True
            return False
        return True  # HALF_OPEN allows test requests

    def record_success(self):
        if self.state == CircuitState.HALF_OPEN:
            self.success_count += 1
            if self.success_count >= self.success_threshold:
                self.state = CircuitState.CLOSED
                self.failure_count = 0
        else:
            self.failure_count = 0

    def record_failure(self):
        self.failure_count += 1
        self.last_failure_time = time.time()
        if self.failure_count >= self.failure_threshold:
            self.state = CircuitState.OPEN

def generate_with_circuit_breaker(prompt, breaker, max_retries=3):
    """Production-grade image generation with circuit breaker protection."""
    import google.generativeai as genai
    model = genai.GenerativeModel("gemini-3.1-flash-image-preview")

    if not breaker.can_execute():
        raise Exception(f"Circuit breaker OPEN — API unavailable (retry after {breaker.recovery_timeout}s)")

    for attempt in range(max_retries):
        try:
            response = model.generate_content(prompt)
            breaker.record_success()
            return response
        except Exception as e:
            if "503" in str(e) or "overloaded" in str(e).lower():
                breaker.record_failure()
                if not breaker.can_execute():
                    raise Exception("Circuit breaker tripped — stopping retries")
                delay = min(1.0 * (2 ** attempt), 60.0)
                time.sleep(random.uniform(0, delay))
            else:
                raise


breaker = CircuitBreaker(failure_threshold=5, recovery_timeout=30.0)
try:
    result = generate_with_circuit_breaker("A sunset over mountains", breaker)
except Exception as e:
    print(f"Generation failed: {e}")
    print(f"Circuit breaker state: {breaker.state.value}")

Nano Banana 2に特化した推奨設定値は、失敗しきい値5回の連続エラー（障害を迅速に検出するのに十分低く、時折の一時的なエラーによる誤トリップを避けるのに十分高い）、回復タイムアウト30秒（NB2 Flashの典型的な回復時間5〜15分に対応し、回復の迅速な検出を可能にする）、そしてサーキットを完全にクローズする前に2回の連続成功（継続中の障害中の1回のラッキーリクエストによる早期回復を防止する）です。

修正4 — モデルフォールバックチェーン

503障害が長引いている間も画像生成が必ず成功する必要があるアプリケーションでは、モデルフォールバックチェーンを実装することで、ユーザーにエラーページが表示されることを防ぎます。戦略は単純明快です。Nano Banana 2が失敗した場合、品質やコストのトレードオフは異なるものの、同様の機能を提供する代替モデルに自動的に切り替えます。Nano Banana 2の障害中にアプリケーションが停止するのではなく、適切に設計されたフォールバックチェーンがグレースフルに劣化し、その時点で最適な利用可能モデルを使用します。

2026年3月時点での画像生成の推奨フォールバック階層は以下の通りです。まず、Nano Banana 2（gemini-3.1-flash-image-preview）をプライマリモデルとして試行します。品質、速度、コストの最適なバランスを提供するためです。NB2が503を返した場合、Gemini 2.5 Flash Imageにフォールバックします。こちらは一般提供されておりより安定していますが、画像品質はわずかに低下します。3番目のオプションとして、Vertex AIエンドポイント経由でImagen 4にルーティングできます。優れた画像品質を提供しますが、コストが高く、API規約が異なります。重要度の低いワークロードでは、4番目のオプションとして、より高価なモデルを使用するのではなく、NB2が回復するまでリクエストをキューに入れて後で処理する方法があります。

フォールバックのトレードオフ比較表

マルチモデルの設定を簡素化したいチームには、laozhang.aiのようなAPI集約プラットフォームが、画像1枚あたり約$0.05の統一エンドポイントを提供し、複数の画像生成モデル間のルーティングを行います。フォールバックロジックをアプリケーションコードに実装するのではなく、インフラレベルで処理します。これは、各プロバイダー用の個別のAPI統合を維持することなく、複数のAIモデルプロバイダー間で一貫した可用性が必要な場合に特に有用です。

実装アプローチ

実践的なフォールバック実装では、各モデルコールをtry-catchブロックでラップし、チェーンを通じてカスケードします。重要な設計上の決定は、フォールバックする前に各モデルでどのくらい待つかです。NB2の場合、フォールバックに移行する前の10秒のタイムアウトと2回のリトライが妥当です。最初の2回のリトライ試行が10秒以内に失敗した場合、障害は短い一時的なものではない可能性が高く、モデルを切り替えるべきです。すべてのフォールバックイベントをログに記録して、プライマリモデルがどの程度頻繁に利用不可になっているか、フォールバックの品質がユーザーにとって許容可能かどうかを追跡してください。多くのチームは、ピーク時間帯にフォールバックモデルが実際にリクエストの大部分を処理していることを発見し、プライマリモデルの選択を再検討する必要があるかもしれません。

503耐障害性のための長期的ソリューション

上記の修正は即座の503エラーに効果的に対処しますが、真に耐障害性のある画像生成パイプラインを構築するには、障害に単に反応するのではなく、障害を予測するアーキテクチャの変更が必要です。このセクションの戦略は、時折の503エラーが予期しない障害ではなく、予測される運用上の状態であるような本番環境でNano Banana 2を実行しているチーム向けに設計されています。

Batch APIによる503回避

GoogleのBatch APIは、503エラーを回避するための根本的に異なるアプローチを提供します。即時のGPU処理能力を競うリアルタイムリクエストを送信する代わりに、Googleが利用可能な処理能力のウィンドウ中にスケジュールする処理キューにジョブを送信します。Batch APIは通常24時間以内にリクエストを処理し、503エラーを引き起こすリアルタイムの処理能力制約から完全に免除されます。即座の結果を必要としないワークロード（製品画像の生成、ソーシャルメディアコンテンツのバッチ作成、画像バリエーションの一括処理など）にとって、Batch APIは利用可能な最も信頼性の高いソリューションです。トレードオフはレイテンシーです。リアルタイムレスポンスを犠牲にして完了を保証しますが、多くのユースケースにとって、これは素晴らしい取引です。

キューアーキテクチャパターン

ユーザーにリアルタイムでサービスを提供しながら、バッチワークロードも処理する必要があるアプリケーションには、キューベースのアーキテクチャが両方の長所を提供します。パターンは以下のように機能します。ユーザー向けリクエストは即時処理のためにリトライおよびサーキットブレーカーロジックを通過し、緊急でないリクエストはメッセージキュー（Redis、RabbitMQ、またはGoogle Cloud Tasksなどのクラウドネイティブオプション）にプッシュされます。バックグラウンドワーカーがオフピーク時間帯、またはサーキットブレーカーがAPIが利用可能であることを示した時にキューを処理します。この分離により、長時間の障害中でもユーザー向けアプリケーションの応答性が維持され、バッチ作業は手動介入なしに最終的に完了します。

ヘルスモニタリング

プロアクティブなモニタリングは、ユーザーの苦情から503エラーを発見するのか、ユーザーが影響を受ける前に検出するのかの違いを生みます。5分ごとにNano Banana 2に軽量なテストリクエストを送信する基本的なヘルスチェックスクリプトにより、処理能力の問題の早期警告を得ることができます。ヘルスチェックが失敗した場合、システムは自動的にフォールバックモデルに切り替え、運用チームに通知し、重要でないバッチジョブを一時停止できます。マルチプロバイダー戦略を使用しているチームには、laozhang.aiのようなサービスがモデル間の可用性データを提供し、独自のモニタリングインフラを維持することなく、情報に基づいたルーティング判断を行えます。その他の一般的な問題のトラブルシューティングについては、Nano Banana 2の包括的なトラブルシューティングガイドをご覧ください。

FAQ

Nano Banana 2は現在ダウンしているのですか、それとも自分だけですか？

503「Model is Overloaded」エラーが表示されている場合、それはほぼ確実にあなたのアカウントだけでなく、グローバルですべてのユーザーに影響しています。503エラーは、Googleのインフラレベルでのサーバー側の処理能力の問題を具体的に示しています。これを確認するには、Google AI Developers Forumで最近のレポートを確認するか、まったく異なるAPIキーとプロジェクトでテストしてみてください。両方が同じ503で失敗する場合、障害がグローバルであることが確認されます。コミュニティモニタリングによると、NB2の503障害の約70%は60分以内に解決し、Flashモデルはわずか5〜15分で回復することが多いです。

失敗した503リクエストに課金されますか？

いいえ。Googleは503エラーを返すAPIリクエストに対して課金しません。課金は正常に完了したリクエストにのみ適用されます。これはGoogleの公式API価格ドキュメントで確認されています（2026年3月検証）。失敗した試行に追加コストが発生することなく、必要なだけリトライできます。Nano Banana 2の価格は1K解像度で画像1枚あたり約$0.067（100万入力トークンあたり$0.25 + 100万画像出力トークンあたり$60.00）ですが、画像が実際に生成されて返された場合にのみ支払いが発生します。

有料ティアへのアップグレードで503エラーは修正されますか？

いいえ。これは503エラーに関する最も一般的な誤解の一つです。無料から有料への課金ティアのアップグレード、またはTier 1からTier 2へのアップグレードは、個人のレート制限を引き上げます（429エラーの修正にはなります）が、503エラーには全く影響しません。503「Model is Overloaded」エラーは、個人のアカウント制限ではなく、グローバルなサーバー処理能力の制約によって引き起こされます。有料ティアの恩恵はレート制限に適用されます。例えば、Tier 2では10 RPMの代わりに30 RPMが得られますが、これはあなたが個人的にレート制限を超過した場合にのみ役立ちます。なお、無料ティアではNano Banana 2の画像生成はサポートされていません。少なくとも有料のTier 1アカウントが必要です。

Batch APIで503エラーを完全に回避できますか？

はい、結果の遅延を許容できるワークロードであれば可能です。Batch APIは、Googleが利用可能な処理能力の期間中にスケジュールする処理キューにジョブを送信し、503エラーを引き起こすリアルタイムの処理能力制約を完全にバイパスします。トレードオフは、結果がリアルタイム（2〜5秒）ではなく、通常24時間以内に配信されることです。バッチ画像生成、カタログ処理、または即時配信を必要としないコンテンツ作成パイプラインの場合、Batch APIは503リスクなしの保証された完了を提供します。

Nano Banana 2に最適なリトライ戦略は何ですか？

推奨されるアプローチは、フルジッター付き指数バックオフを最大遅延60秒に制限し、本番環境アプリケーション用のサーキットブレーカーラッパーと組み合わせたものです。ベース遅延1秒からリトライごとに倍増（1秒、2秒、4秒、8秒、16秒）し、0から計算された遅延の間でランダムジッターを適用し、最大60秒に制限します。オフピーク時間帯には5回のリトライ、ピーク時間帯（UTC 09:00〜15:00）には最大8回のリトライを使用します。サーキットブレーカーは5回の連続失敗後にトリップし、30秒後に回復をテストする設定が適切です。この組み合わせにより、短い一時的なエラーと長時間の障害の両方をグレースフルに処理できます。