Gemini API 429 RESOURCE_EXHAUSTED：正しい制限面を読んで直す

Gemini API 429 RESOURCE_EXHAUSTED は、request がどこかの制限境界を越えたという意味です。最初から retry を強めるのではなく、AI Studio の live limit、project quota pool、billing/prepay state、burst pattern、または Vertex AI の capacity contract のどれが owner かを切り分けます。

Google の troubleshooting 表では HTTP 429 は RESOURCE_EXHAUSTED に対応し、rate limit を超えた状態を示します。rate-limits ページはさらに、制限が RPM、input TPM、RPD などで測られ、per project, not per API key で適用され、specified limits は保証値ではないため active limits は AI Studio で確認する、と説明しています。

鮮度: Gemini API rate limits、troubleshooting、billing、pricing、Vertex AI 429 は 2026年5月3日に再確認しました。

429 を汎用障害ではなく limit branch として読む

body が RESOURCE_EXHAUSTED なら、limit branch に残ります。503 UNAVAILABLE は temporary capacity、400 FAILED_PRECONDITION は region と billing の可能性があります。429 は request format は通ったが、現在の capacity boundary が拒否した状態です。

よくある誤りは、429 をすべて code bug とみなすことです。Backoff は burst traffic には効きますが、daily quota を増やしたり、prepay balance を戻したり、paid-only route を free route に変えたりはできません。

エラー本文は必ずログに残します。JavaScript SDK @google/genai の API error では name、message、status を読めるため、retry classification と same-path escalation の証拠に使えます。

quota 表より先に AI Studio を見る

Google は rate limits が RPM、input TPM、RPD で測られ、per project, not per API key で適用され、active limits は AI Studio で見ると説明しています。公開表は tier ladder の説明であり、live dashboard の代わりではありません。

確認する質問は三つです。どの metric が limit に達したか。どの model、route、project がエラーを出したか。dashboard とエラーが一致しているか。一致して飽和しているなら capacity または traffic shaping に進みます。一致しないなら、新しい API keys を作る前に request time、model、project、response body、usage view を集めます。

project quota、billing、route eligibility を分ける

Project quota は pool です。production、staging、local script、batch worker が同じ Google Cloud project の key を使えば競合します。Billing は account state であり、prepay credits が $0 なら関連 project の keys は止まり得ます。Route eligibility は model contract で、paid-only route は free-tier tuning では安定しません。

この分離により、billing 問題を retry 問題として扱う誤りと、route eligibility 問題を free-tier tuning として扱う誤りを避けられます。先に owner を確定し、その後で fix を選びます。

owner が分かってから retry する

Retry は bounded にします。exponential backoff with jitter、queue、concurrency cap、idempotency が必要です。worker が同時 retry すれば retry layer が spike になります。Batch jobs には checkpoint、interactive apps には wait state と prompt caching が必要です。

javascript
const retryable = new Set([429, 500, 503, 504]);

async function callWithBackoff(run, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      const status = Number(error?.status || error?.code || 0);
      if (!retryable.has(status) || attempt === maxRetries) throw error;
      const delayMs = Math.min(1000 * 2 ** attempt + Math.random() * 500, 30000);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }
}

Developer API と Vertex AI は 429 contract が違う

Gemini Developer API は AI Studio から始めます。API key、project、usage tier、active limits、billing plan、prepay credits が対象です。Vertex AI は Google Cloud project、endpoint、region/global endpoint、quota framework、Provisioned Throughput を見ます。pay-as-you-go は global endpoint、truncated exponential backoff、QIR、traffic smoothing、reserved throughput が選択肢です。

同じ HTTP code でも同じ system とは限りません。Developer API の第一証拠は通常 AI Studio にあり、Vertex AI の第一証拠は Google Cloud project、endpoint、quota framework、provisioning contract にあります。

capacity を増やすべきタイミング

route、project、billing、traffic shape が証明済みなら capacity 判断に移ります。軽い model、Batch API、quota increase、Vertex AI、Provisioned Throughput、multi-provider gateway を選びます。provider-level risk になった時だけ laozhang.ai のような unified routing/fallback layer が意味を持ちます。

よくある質問

Gemini API key ごとに独立した 429 limit はありますか？

いいえ。Gemini API limits は per project, not per API key です。同じ project の複数 key は quota pool を共有します。

billing を有効にすれば RESOURCE_EXHAUSTED は必ず直りますか？

常にではありません。Billing は tier と eligibility を変えますが、shared project、depleted prepay balance、daily exhaustion、burst pattern は別問題です。

429 は常に retry すべきですか？

いいえ。Retry は temporary pressure と bursts 向けです。daily quota、billing state、paid-only route は retry で直りません。

現在の Gemini API limit はどこで見ますか？

同じ project と model の active rate-limit view を AI Studio で確認します。公開文書は仕組みと tier ladder を説明しますが、specified limits を guaranteed serving capacity として扱ってはいけません。

実用ルール

same error body、same project、same model、same endpoint、same time window をそろえます。その後、billing action、project isolation、traffic smoothing、model change、quota increase、Vertex capacity、gateway fallback から最小の fix を選びます。