Gemini API の429・400・500エラーを最短で直す方法【2026年版】

2026 年 3 月 18 日時点の結論を先に言うと、 429 RESOURCE_EXHAUSTED はクォータ、課金 tier、またはリクエスト速度の問題であることが多く、短く待って再試行する価値があります。400 INVALID_ARGUMENT はリクエスト本体、モデル、パラメータ、または endpoint の組み合わせが間違っていることが多く、普通は修正してから再送すべきです。500 INTERNAL は Google 側の一時的不安定さ、または入力コンテキストの肥大化が主因になりやすく、最短の回復策は入力を縮め、上限付きのバックオフを入れ、必要なら Gemini 2.5 Pro から Gemini 2.5 Flash に一時退避することです。

このテーマで本当に重要なのは「エラーコードの意味」ではなく、「次の 1 分で何をするべきか」です。2026 年の Gemini では、429 は単なる「送りすぎ」ではありません。2025 年 12 月 7 日のクォータ調整、Paid Tier 1 の伝播タイミング、さらには使用量が低いのに 429 が出るというコミュニティ報告まで含めて判断する必要があります。400 も同様で、JSON の構造ミスだけでなく、/v1 と /v1beta の不一致や billing の前提条件不足が混ざります。500 に関しても、Google 公式が「長すぎるコンテキスト」で発生し得ると明言しているため、サーバー障害と決めつけるのは危険です。

要点まとめ

インシデント中であれば、まず下の表を見てから該当セクションに移ってください。429、400、500 を同じ手順で処理しないことが最大のポイントです。

特に覚えておきたいのは 3 つの時系列です。第一に、Firebase AI Logic の FAQ は、Gemini Developer API の Free Tier と Paid Tier 1 のクォータが 2025 年 12 月 7 日から調整されたと明記しています。第二に、Google の Gemini API billing ドキュメント は、400 と 500 の失敗リクエストは課金されないが、quota は消費すると書いています。第三に、Google は 2026 年 3 月に usage tier と spend cap を見直し、2026 年 4 月 1 日から tier spend cap の適用を開始します。つまり、2025 年前半の感覚だけで 2026 年の Gemini エラーを判断すると外しやすいということです。

30 秒で 429・400・500 を切り分ける

Gemini のエラーで最も効果がある習慣は、HTTP ステータスだけでなく、レスポンスの本文全体を読むことです。見るべきなのは status、message、QuotaFailure や RetryInfo の有無、そしてモデル名と endpoint version です。ログに単に "429" だけ残していても、そこから正しい行動はほとんど導けません。

公式の troubleshooting guide は依然として最重要の出発点ですが、実運用では次のように読み替えると判断が速くなります。429 は「クォータか tier の状態に問題がある、あるいは送信速度が高すぎる」。400 INVALID_ARGUMENT は「リクエストそのものが拒否された」。400 FAILED_PRECONDITION は「形式よりも billing や地域の条件が足りない」。500 は「認証や基本的な検証は通過し、その後の処理で Google 側が失敗した」ケースです。

本当に時間を節約したいなら、最低限、モデル名・endpoint version・リクエストサイズ・同一 payload が別モデルで成功するかどうかの 4 点をログに残してください。この 4 点だけで、ローカルバグと platform incident の切り分け速度がかなり変わります。

429 RESOURCE_EXHAUSTED を直す：本当の制限、課金反映待ち、Ghost 429

Google の公式説明では、429 は「rate limit を超えた」状態です。これは間違っていませんが、2026 年の実務には少し足りません。公式の rate limits ページ は、active limit は AI Studio で確認すべきこと、そして文書化された制限値は固定保証ではないことを明示しています。つまり、古いブログの表だけを基準にして 429 を説明すると、ズレた判断になりやすいのです。

特に重要なのが 2025 年 12 月 7 日のクォータ調整です。Firebase AI Logic の FAQ は、この日から Gemini Developer API の Free Tier と Paid Tier 1 の quota が変わり、予期しない 429 の原因になり得ると書いています。コードもトラフィックも大きく変わっていないのに 429 が増えた、という事例の背景を説明するにはこの日付が欠かせません。

もうひとつの重要点は、Gemini の制限は API key 単位ではなく project / billing account 単位 で効くということです。Billing ドキュメントによれば、API key は project と billing account の状態を継承します。したがって、同じ project 内で key を追加しても、新しい quota は生まれません。

実務では 429 を次の 3 ケースに分けると理解しやすいです。

Google AI Developers Forum では、低使用量なのに Paid Tier で 429 が続くという報告が複数ありました。中には free-tier metric のように見える詳細を含む例もあります。すべての 429 が provider 側の問題という意味ではありませんが、少なくとも「429 = 単に送りすぎた」と決めつけるのは危険です。低トラフィックの paid project が最初の数回から 429 を返すなら、tier の同期や quota-state の不整合も十分疑うべきです。

一方で、本当に rate limit に当たっているなら、対策は地味でも効果的です。トラフィックのピークを丸める、不要なコンテキストを削る、小さな呼び出しをまとめる、クライアント側で queue と backoff を入れる。必要なら正式に上位 tier へ移行する。Google の rate limits ページは、Free から Tier 1 への移行は通常すぐ反映され、その後の tier 変更も通常 10 分ほどで有効になると書いています。そこを大きく超えても free tier のような挙動が続く場合は、設定や billing の紐付けを優先的に確認するべきです。

もし本当の問題が「個別の request」ではなく「本番 API 経路の不安定さ」なら、解き方も変わります。複数プロバイダをまたいだ OpenAI 互換の relay が必要なチームなら laozhang.ai のような選択肢が意味を持つ場合がありますが、それは production routing や可用性の課題に対する話であり、単一の payload ミスを隠すための近道ではありません。

400 を直す：INVALID_ARGUMENT と FAILED_PRECONDITION は別問題

400 系は「Bad Request」という言葉だけでまとめられがちですが、実際には処理方針がかなり違います。Google 公式は INVALID_ARGUMENT と FAILED_PRECONDITION を分けて説明しており、その違いを見落とすと無駄な retry や無駄な修正が増えます。

まず INVALID_ARGUMENT。これは payload の形、パラメータ、model / endpoint の組み合わせが正しくない場合に出ることが多いです。特に大事なのは、Google が「新しい API version の機能を古い endpoint で使うと 400 になる」と明記している点です。つまり JSON の見た目が正しくても、/v1 と /v1beta の整合が崩れていれば 400 になります。

典型例は、古い model 名、サポート外パラメータ、field の nesting ミス、ファイル処理フローの不一致、そしてモデルが対応しない capability を無理に使うパターンです。したがって 400 の正しい直し方は「もう一回送ってみる」ではなく、「モデル、endpoint、payload をセットで照合する」ことです。

FAILED_PRECONDITION は payload の問題に見えて、実際は access 条件の問題であることがよくあります。無料 tier が利用できない地域で billing を有効化していない場合などがその典型です。ここで JSON をいじり続けても問題は解決しません。

ただし、コミュニティには「同じコードなのに突然 400 INVALID_ARGUMENT になり、時間が経つと復旧した」という報告もあります。だからといって 400 を retryable 扱いすべきという意味ではありません。正しい解釈は、request の妥当性を確認したうえで、同一 payload を別モデルで試し、モデル固有の一時不調かどうかを見極めるべき、ということです。

500 INTERNAL を直す：長いコンテキスト、モデル不安定、賢い retry

Google の公式 troubleshooting guide は、500 INTERNAL が Google 側の unexpected error だけでなく、長すぎる入力コンテキストでも起きると明記しています。推奨されている回避策も明快で、コンテキストを縮めるか、Gemini 2.5 Pro から Gemini 2.5 Flash へ一時的に切り替えることです。

この説明はモデル情報とも一致します。Gemini 2.5 Pro は 1,048,576 token の入力を受けられますが、それは「巨大な prompt を毎回安全に処理できる」という意味ではありません。長い会話履歴、大量のドキュメント、retrieval chunk、複雑な system instruction を一度に詰め込めば、500 が出る確率は自然に上がります。

したがって、500 を見たら最初にやるべきことはとても単純です。まず入力を減らす。重複した指示を削る。古い会話履歴を切る。retrieval の件数を絞る。巨大な context を「入るから入れる」状態にしない。これだけで通るようになるケースは本当に多いです。

もう一方の 500 はモデル側の不安定さです。Google AI Developers Forum では、Gemini 2.5 Pro が広く 500 を返す一方で Flash は通る、という時期がありました。この場合に一番役立つ確認は、同じ payload を Flash でも試すことです。Flash が通るなら、Pro の状態問題を疑う方が自然で、最短の回復策は一時的な model switch になります。

実務的には次の順番で十分です。

1. その request が大きすぎないか確認する。
2. jitter 付きの bounded backoff を入れる。
3. Pro を使っていたら同じ payload を Flash へ流す。
4. 入力を縮めても広く失敗するなら platform incident と見なす。

失敗が続くときの Troubleshooting フロー

同じ系統の失敗が繰り返されるなら、1 回ごとに場当たりで直すのではなく、比較可能なフローに落とし込むべきです。成功した payload と失敗した payload を並べ、model、endpoint、prompt サイズ、file の有無を比べる。それだけで「これは traffic 問題か、request 問題か、model 状態問題か」の解像度がかなり上がります。

ここで重要なのは、時間が効くエラーかどうか を見極めることです。429 と多くの 500 には待つ意味があります。決定論的な 400 に待つ意味はほぼありません。同じ INVALID_ARGUMENT を何度も送っているだけなら、前進しているのではなく quota を削っているだけです。

本番運用なら、"Gemini が失敗した" だけをログに残すのは不十分です。model、endpoint version、概算サイズ、正規化したエラー分類まで残してください。後から見返したときの学習効率が大きく変わります。

本番向け retry テンプレート：再試行すべきものと即失敗させるもの

retry ロジックで最も重要なのは待機秒数よりも、retryable と non-retryable の境界です。Gemini では 429、500、503、504 を bounded backoff で再試行し、400、401、403、404 は実際に何かを直すまで fail fast にする、という方針が最も実用的です。

Python

python
import random
import time
from google import genai
from google.genai import errors

client = genai.Client(api_key="YOUR_GEMINI_API_KEY")

RETRYABLE = {429, 500, 503, 504}
FAIL_FAST = {400, 401, 403, 404}


def generate_with_retry(model: str, contents, max_retries: int = 5):
    for attempt in range(max_retries):
        try:
            return client.models.generate_content(model=model, contents=contents)
        except errors.ClientError as exc:
            status = getattr(exc, "code", None)
            message = str(exc)

            if status in FAIL_FAST:
                raise RuntimeError(
                    f"Non-retryable Gemini error {status}: {message}"
                ) from exc

            if status in RETRYABLE and attempt < max_retries - 1:
                delay = min(2 ** attempt, 30)
                jitter = random.uniform(0, delay * 0.2)
                time.sleep(delay + jitter)
                continue

            raise RuntimeError(
                f"Retry budget exhausted after Gemini error {status}: {message}"
            ) from exc

Node.js

ts
import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });
const retryable = new Set([429, 500, 503, 504]);
const failFast = new Set([400, 401, 403, 404]);

export async function generateWithRetry(model: string, contents: string) {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    try {
      return await client.models.generateContent({ model, contents });
    } catch (error: any) {
      const status = error?.status ?? error?.code ?? 0;

      if (failFast.has(status)) {
        throw new Error(`Non-retryable Gemini error ${status}: ${error.message}`);
      }

      if (retryable.has(status) && attempt < 4) {
        const delayMs = Math.min(1000 * 2 ** attempt, 30000);
        const jitterMs = Math.random() * delayMs * 0.2;
        await new Promise((resolve) => setTimeout(resolve, delayMs + jitterMs));
        continue;
      }

      throw error;
    }
  }
}

大事なのは式ではなく分岐です。INVALID_ARGUMENT を延々 retry しても request は正しくなりません。一方で 429 や 500 を 1 回も retry しなければ、数秒待てば成功した可能性のある call を自分から捨てることになります。

2026 年の変更で、古い対処法が通用しなくなった理由

Gemini の古い解説が役に立ちにくくなっているのは、プラットフォーム自体が変わったからです。少なくとも次の時系列は現在の troubleshooting に直結します。

だからこそ、古い「完全ガイド」は一見正しくても、現在の Gemini を正しく切り分けるには情報が足りません。日付を伴った前提更新が必要です。

FAQ

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

400 と 500 については通常課金されません。Google の billing FAQ では、これらは課金対象外だが quota は消費すると説明されています。

Gemini の制限は API key ごとですか、それとも project ごとですか？

基本的には project / billing account で考えるべきです。API key はそれらの状態を継承するだけで、同じ project 内で key を増やしても quota は増えません。

billing を有効化してからどれくらいで反映されますか？

Google は Free から Tier 1 は通常すぐ、以後の upgrade は通常 10 分程度と説明しています。それを大きく超えても挙動が変わらないなら、project と billing の紐付けを優先して確認してください。

Gemini 2.5 Pro から Flash に切り替えるべきなのはいつですか？

同じ payload が Flash では通るのに Pro では落ちるとき、500 が巨大な context と結び付いているとき、あるいは最優先が reasoning 品質より service recovery のときです。

Gemini の全エラーを 1 ページで完璧に解決できる公式ページはありますか？

ありません。公式 troubleshooting guide が最良の出発点ですが、2026 年の判断には rate limits、billing、pricing、release notes も併せて読む必要があります。より広い整理が必要なら、Gemini API エラー完全ガイド も参照してください。