GEMINI LABEN
ROBOTICS — 8月31日に停止した ER 1.6 preview には後継があります。Gemini Robotics ER 2 が公開プレビュー中で、通常版とストリーミング版の2種類が提供されていますVIDEO — ER 2 の成功・失敗判定は静止画ではなく生の映像フィード上で動きます。こぼれ・滑り・位置ずれのような、実行の途中で起きる失敗を捉えられる設計ですDEADLINE — 次の期限は9月30日、gemini-omni-flash-preview の廃止です。移行先は8月27日に GA になった gemini-omni-1.1-flash で、残り4週間を切りましたAPIKEY — 残りの標準 API キーは、制限付きのものも含めて9月中に全面停止します。移行先は Google Cloud サービスアカウントに紐付く auth キー形式ですPRICE — Gemini 3.7 Flash の導入価格 $0.75/$3.75 per 1M は12月31日までです。2027年1月1日から $1.50/$7.50 になるため、年を跨ぐ見積もりは2本立てが要りますAUDIO — Gemini 3.5 Transcribe は85言語以上の言語検出、話者ダイアライゼーション、単語単位タイムスタンプ、最大1,000語のカスタム語彙バイアスに対応していますROBOTICS — 8月31日に停止した ER 1.6 preview には後継があります。Gemini Robotics ER 2 が公開プレビュー中で、通常版とストリーミング版の2種類が提供されていますVIDEO — ER 2 の成功・失敗判定は静止画ではなく生の映像フィード上で動きます。こぼれ・滑り・位置ずれのような、実行の途中で起きる失敗を捉えられる設計ですDEADLINE — 次の期限は9月30日、gemini-omni-flash-preview の廃止です。移行先は8月27日に GA になった gemini-omni-1.1-flash で、残り4週間を切りましたAPIKEY — 残りの標準 API キーは、制限付きのものも含めて9月中に全面停止します。移行先は Google Cloud サービスアカウントに紐付く auth キー形式ですPRICE — Gemini 3.7 Flash の導入価格 $0.75/$3.75 per 1M は12月31日までです。2027年1月1日から $1.50/$7.50 になるため、年を跨ぐ見積もりは2本立てが要りますAUDIO — Gemini 3.5 Transcribe は85言語以上の言語検出、話者ダイアライゼーション、単語単位タイムスタンプ、最大1,000語のカスタム語彙バイアスに対応しています
記事一覧/開発ツール
開発ツール/2026-03-29上級

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

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

gemini-api285error-handling8rate-limiting4production105circuit-breaker2retry-pattern

プレミアム記事

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

壁紙アプリの異変に気づいたのは、クラッシュレポートではなくレビュー欄からでした。「昨日から説明文が出ません」。サーバーは生きていて、ログに例外は一件も積まれていません。手元で叩き直してみると、Gemini API は HTTP 200 を返し続けていて、response.text だけが空でした。

AI を組み込んだアプリの障害は、この形で届きます。プロセスは落ちない。アラートも鳴らない。機能だけが静かに抜け落ちて、気づくのは数日後のレビューです。200 で中身が空、ストリーミングが途中で切れる、安全フィルターで応答がブロックされる。従来の Web 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 — 指定したモデル名が存在しない。タイポだけでなく、使っていたモデルが世代交代で消えたときにも同じ 404 が返ります。後述の「モデルの世代交代は 404 として届く」で扱います

判定ロジックの実装

# 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/月 または ¥2,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駆動開発
※ アフィリエイトリンクを含みます
もっと見る →