GEMINI LABEN
NANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定ですNANOLITE — Nano Banana 2 Liteが登場しました。Googleで最も速く、最もコスト効率の高いGemini Imageモデルで、軽量な画像生成を安く回したい用途に向いていますOMNIFLASH — Gemini Omni Flashがpublic previewになりました。ネイティブにマルチモーダルなモデルで、企業や開発者が独自の動的な動画ワークフローを構築できますAGENTS — Managed Agentsが拡張されました。background: trueでサーバー側の非同期実行とポーリング、リモートMCPサーバー連携、対話をまたぐ認証情報のリフレッシュに対応しますMEMORY — Memory BankのIngestEvents APIが一般提供になりました。イベントの取り込みとメモリ生成を分離し、コンテンツを継続的にストリームできますTHROUGHPUT — Provisioned Throughputで、同一モデル・同一リージョンに対して最大7件の保留オーダーを提出できるようになりましたDEPRECATE — 画像生成モデルは8月17日に、Gemini Enterprise Agent PlatformのGrok 4.1系は8月20日に停止される予定です
記事一覧/開発ツール
開発ツール/2026-03-29上級

Gemini API 本番運用ノート — 429・500・503 に静かに耐えるエラーハンドリングとレート制限の設計

Gemini API を本番で動かして気づいた、エラーハンドリングとレート制限の運用パターンの記録です。指数バックオフ・ジッター・サーキットブレーカー・トークンバケット・モデルカスケードを、個人開発アプリで踏んだ落とし穴と実測メトリクス付きで整理しました。

gemini-api279error-handling8rate-limiting4production105circuit-breaker2retry-pattern

プレミアム記事

取り組みの背景 — なぜ本番AIアプリは「静かに壊れる」のか

Gemini API を使ったプロトタイプは驚くほど簡単に動きます。しかし、本番環境にデプロイした途端、予期しないエラーでサービスが停止したり、レート制限に引っかかってユーザーが離脱したりする問題に直面する開発者は少なくありません。

AIアプリケーション特有の難しさは、障害が「静かに」起きることです。HTTPステータス200で返ってきても中身が空だったり、ストリーミング途中で接続が切れたり、安全フィルターで応答がブロックされたりと、従来のWeb APIとは異なるエラーパターンが存在します。

ここではGemini API を本番環境で安定運用するために必要なエラーハンドリングとレート制限対策を体系的に解説します。対象読者は、すでに Gemini API の基本を理解しており、プロダクションレベルの堅牢性を実現したい中級〜上級の開発者です。

Gemini API エラーコード全体像とリトライ判定マトリクス

Gemini API が返すHTTPエラーは大きく「リトライ可能」と「リトライ不可」の2種類に分かれます。この判定を間違えると、修正すべきバグに対して無意味なリトライを繰り返したり、逆に一時的な障害でサービスを停止させたりしてしまいます。

リトライ可能なエラー(Transient Errors)

  • 429 Too Many Requests — レート制限超過。最も頻繁に発生するエラーで、RPM(リクエスト/分)、TPM(トークン/分)、RPD(リクエスト/日)、IPM(画像/分)のいずれかの上限に到達した場合に返されます
  • 500 Internal Server Error — Google側の一時的な障害。モデル推論のタイムアウトやインフラの問題で発生します
  • 503 Service Unavailable — サービスの一時停止。メンテナンスや過負荷時に返されます
  • 504 Gateway Timeout — リクエストの処理時間が上限を超過した場合に発生します

リトライ不可のエラー(Permanent Errors)

  • 400 Bad Request — リクエスト形式の不備(不正なJSON、サポートされていないパラメータ等)
  • 401 Unauthorized — APIキーが無効または期限切れ
  • 403 Forbidden — APIキーに対象モデルのアクセス権がない、または地域制限
  • 404 Not Found — 指定したモデル名が存在しない

判定ロジックの実装

# Python: リトライ判定ヘルパー
RETRYABLE_STATUS_CODES = {429, 500, 503, 504}
 
def is_retryable(status_code: int) -> bool:
    """リトライ可能なエラーかどうかを判定する"""
    return status_code in RETRYABLE_STATUS_CODES
 
def classify_error(status_code: int, error_message: str) -> dict:
    """エラーを分類し、推奨アクションを返す"""
    if status_code == 429:
        return {
            "type": "rate_limit",
            "retryable": True,
            "action": "exponential_backoff",
            "message": "レート制限に到達。バックオフ後にリトライ"
        }
    elif status_code in (500, 503, 504):
        return {
            "type": "server_error",
            "retryable": True,
            "action": "exponential_backoff",
            "message": "サーバー側の一時的なエラー。自動リトライ"
        }
    elif status_code == 400:
        return {
            "type": "client_error",
            "retryable": False,
            "action": "fix_request",
            "message": f"リクエスト形式エラー: {error_message}"
        }
    else:
        return {
            "type": "fatal_error",
            "retryable": False,
            "action": "alert_developer",
            "message": f"即時対応が必要: {status_code} {error_message}"
        }

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
429/500/503 の発生頻度と、リトライ可否を最短で見極めるための判定マトリクス
指数バックオフ+ジッター・サーキットブレーカー・トークンバケットを Python と TypeScript の動くコードで実装
Pro→Flash→Flash-Lite のカスケード設計と、個人開発アプリで踏んだ落とし穴・実測リトライ成功率
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

開発ツール2026-06-17
Gemini API のチャット履歴を Redis で運用する — 本番で会話状態を失わない実装メモ
Gemini のチャット履歴をプロセスメモリに置いたまま本番に出すと、再デプロイやスケールのたびに会話が消えます。Redis を受け皿にしつつ、トークン予算・同時送信・SDK 依存・障害時の縮退まで、実運用で踏んだ箇所を実装とともにまとめました。
開発ツール2026-06-15
Firestore × Gemini Embeddings の RAG が静かに劣化する — 埋め込み世代交代に耐える再埋め込み設計
Firestore のネイティブベクトル検索と Gemini Embeddings で組んだ RAG は、埋め込みモデルの世代交代でベクトル空間がずれ、検索品質が静かに落ちます。ドリフトの検知、無停止の再埋め込み移行、取得コストの抑え方を実装で詰めます。
開発ツール2026-04-17
Google Cloud Workflows × Gemini API 本番オーケストレーション:タイムアウト・リトライ・コスト制御まで
Google Cloud WorkflowsでGemini APIを長時間・多段階処理するための本番設計を徹底解説。YAML定義・タイムアウト設定・自動リトライ・コスト予算管理まで、動作確認済みコード付きで解説します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →