Gemini APIのレート制限（2026年）：プロジェクト・利用ティア・処理経路から429を切り分ける

Gemini APIに、すべての製品とアカウントで共通する単一のレート制限はありません。Developer APIの実効値はプロジェクト、モデル、利用ティア、指標、処理経路で決まり、公開表を保証値とせずAI Studioで確認します。

失敗したら、コードや請求設定を変える前にHTTPステータスとエラー本文を保存してください。429 RESOURCE_EXHAUSTEDは制限到達、503 UNAVAILABLEは一時的なサービス容量の分岐です。日次上限、費用制御、残高不足、明示的な割り当てを、同じ再試行ループで解決することはできません。

最初に、リクエストを受け取った製品を特定する

Geminiという名前は、消費者向けアプリ、開発者API、Firebase、Google Cloudの複数の製品面で使われています。モデル名が同じでも、割り当ての所有者や確認画面まで同じとは限りません。SDK、エンドポイント、プロジェクト、認証方法を手掛かりにします。

この区分を入れると、矛盾に見える事象を説明できます。Geminiアプリで上限表示が出てもDeveloper APIプロジェクトには余裕がある場合があります。Firebaseではモデル提供元が正常でも一人のユーザーだけがゲートウェイ上限に達します。Vertex AIの429はCloud側の容量契約が原因で、AI Studioには異常が見えないことがあります。

Developer APIとは、ai.google.devの契約に基づくAPIキー経由のGemini APIを指します。FirebaseとVertex AIには追加のプラットフォーム所有レイヤーがあり、同じモデルファミリーだからという理由だけで同じ診断を適用しません。

Developer APIは「指標×プロジェクト×モデル×ティア」で読む

Googleのレート制限ドキュメントは、基本となる三つの指標を定義し、制限がAPIキー単位ではなくプロジェクト単位で適用されると明記しています。

どれか一つでも適用中の上限を超えれば429になり得ます。RPMが低くても入力TPMは枯渇します。短いリクエストでも、日中に蓄積すればRPDへ到達します。「数回しか実行していない」という説明には、プロジェクト全体のワーカー、ノートブック、検証環境、他のAPIキーが含まれていません。

モデルやモダリティによっては、TPD（1日あたりのトークン数）、IPM（1分あたりの画像数）、Batch専用上限もあります。これらはモデルと処理経路に属する値です。画像生成のIPMが所有者なら、Gemini画像の429切り分けへ問題を分離します。

運用上の要点は二つです。まず、同一プロジェクト内でAPIキーを増やしても、資格情報が増えるだけで割り当てプールは増えません。次に、公開文書は仕組みを説明するもので、現在のプロジェクトとモデルに適用される値はAI Studioで確認します。Google自身も、記載されたレート制限は保証されず、実際の容量が異なる場合があると説明しています。

プレビュー版や試験運用版は一般に厳しい上限を持ちます。無料で使えるモデルと、有料設定が必要な経路も変化します。その判断が未解決なら、Gemini API無料枠の整理を参照し、モデル利用資格と残り割り当てを別問題として扱ってください。

60秒で所有者を絞るための記録

サポートや別チームへ渡しても意味が残る情報を記録します。

• 製品面と完全なエンドポイント
• APIキーそのものではなく、キーが属するプロジェクトID
• 正確なモデル名と処理モード
• HTTPステータス、エラーステータス、全文メッセージ
• タイムゾーン付きの発生時刻
• 入力サイズ、同時実行数、直前の再試行回数
• 同じ時間帯のAI StudioまたはCloud使用量

判断は次の順序で進めます。

1. 製品面：Geminiアプリ、Developer API、Firebase AI Logic、Vertex AIのどれか。
2. ステータス：429の制限イベントか、503の一時容量イベントか。
3. 指標：RPM、入力TPM、RPD、費用、残高、Priority、Batchのどれが候補か。
4. 集計単位：どのプロジェクトまたは請求先アカウントが所有し、何が共有しているか。
5. 処理経路：Standard、Priority、Batch、Firebaseゲートウェイ、Vertex容量のどこか。
6. 管理画面：同じ時刻に、所有者の画面とエラーが一致するか。
7. 変更：証明された所有者へ作用する最小の一手を選ぶ。
8. 検証：同じプロジェクト、モデル、負荷、指標で回復を確認する。

利用ティア、費用、残高、上限を分けて確認する

「請求を有効にしたのに429が消えない」という事象は、金銭に関係する複数の制御を一つに見たときに起きます。2026年7月14日にGoogleのレート制限と請求情報を確認した時点では、少なくとも次の四項目を分ける必要があります。

利用ティアの資格はリンクされた請求先アカウントに基づきます。一方、Developer APIのリクエスト割り当てはプロジェクト単位です。同じ請求先に属する二つのプロジェクトが同じティアになっても、リクエストプールが一つになるわけではありません。

具体値は変わり得るため、本番変更の直前に公式の利用ティアと費用制限とAI Studioを再確認します。支払い履歴、アカウント状態、入金反映、表示遅延が結果に影響します。

たとえばTier 2でRPMが低いのに429が続く場合、10分間の高価な呼び出しが費用制限へ達した可能性があります。この状態で同時実行を増やすと悪化します。ローリング費用が正常でもPrepay残高がゼロなら、1分待っても変わりません。両方正常でRPDが尽きているなら、追加の支払いも誤ったレバーです。

Standard、Priority、Batchは別の処理契約

処理経路は、エラー後の切り替えオプションではなく、初めから容量設計に含める要素です。

GoogleのBatch API文書では、完了まで最大24時間を見込む設計で、ジョブ作成は冪等ではありません。クライアント側の永続IDを先に作り、返されたジョブ名を保存します。作成要求がタイムアウトしただけで同じ仕事を再投入すると、重複処理を作る危険があります。

Batchは再試行の捨て場所ではありません。待てる仕事を対話系から分離するための契約です。Priorityも、すべてのプロジェクトに自動で追加容量を与えるものではありません。資格、独自上限、対話全体への計上を同時に確認します。

待機で状況が変わるときだけ再試行する

Googleのトラブルシューティングは、429と503を別の状態として扱います。実装でも最初に分けます。

次の関数は、429を一律に再試行しません。呼び出し側が「短時間待てば所有者の状態が変わる」と判定した場合だけ許可します。

javascript
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

export async function withGeminiRetry(run, {
  maxAttempts = 5,
  baseDelayMs = 750,
  maxDelayMs = 20_000,
  isTransient429 = () => false,
  onRetry = () => {},
} = {}) {
  let lastError;
  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      lastError = error;
      const status = Number(error?.status ?? error?.code ?? 0);
      const retryable = status === 500 || status === 503 || status === 504 ||
        (status === 429 && isTransient429(error));
      if (!retryable || attempt === maxAttempts) throw error;

      const ceiling = Math.min(
        maxDelayMs,
        baseDelayMs * 2 ** (attempt - 1),
      );
      const delayMs = Math.floor(Math.random() * ceiling);
      onRetry({ attempt, status, delayMs, message: error?.message });
      await sleep(delayMs);
    }
  }
  throw lastError;
}

外側にはプロジェクトとモデル別の同時実行制限を置きます。複数ワーカーが同時に起床すれば、バックオフ後に次のバーストを作るからです。可能な処理には冪等キーを付け、重複入力をキャッシュし、総再試行時間を利用者の待ち時間予算以内に収めます。

isTransient429をtrueにするのは、短いRPMバーストなど、時間が所有者の状態を変える証拠がある場合だけです。RPD枯渇、残高ゼロ、支出上限、却下された増枠、設定変更が必要な所有者ではfalseのままにします。

Firebase AI Logicではユーザー単位の上限も確認する

Firebase AI Logicを通しても、モデル提供元の割り当ては残ります。Firebaseの割り当て文書によると、提供元の制限が優先し、Firebaseゲートウェイは別に設定可能なユーザー単位上限を追加します。2026年7月14日時点の既定値は、ユーザーごとに100 RPMです。

そのため、多数の利用者がそれぞれ100 RPM未満でも提供元プロジェクトを使い切る場合があります。逆に、異常な一クライアントだけがFirebaseの上限へ達し、提供元には余裕がある場合もあります。

同じリクエストについてFirebase層、App Checkの識別、提供元の利用量を照合します。ユーザー上限を上げても提供元容量は増えません。提供元の増枠も、意図して低く設定したクライアント保護を解除しません。

Vertex AIの429はCloud側で診断する

Vertex AIはGoogle Cloudのプロジェクト、ロケーション、エンドポイント、容量契約を使います。Vertex AIの429文書は、従量課金とProvisioned Throughputでメッセージと対策を分けています。

従量課金では、対応モデルでglobal endpointを使う、トラフィックを平準化する、上限付きで再試行する、割り当て型モデルの増枠を申請する、容量計画を変える、といった選択肢があります。Provisioned Throughputでは、購入済みスループット内か、超過分が従量課金として扱われるかを確認します。

VertexリクエストをAI Studioだけで判断しません。Cloudプロジェクト、エンドポイント、ロケーション、割り当て、Provisioned Throughput状態が最初の確認先です。限界対応ではなくプラットフォーム選択が課題なら、Gemini APIとVertex AIの比較へ分離します。

証明した所有者に効く順で容量を変える

変更は、小さく戻しやすいものから並べます。

1. 無駄を除く：重複をキャッシュし、繰り返しコンテキストを削り、再帰的再試行を止め、不要になった要求をキャンセルする。
2. 需要を整形する：バーストをキュー化し、プロジェクトとモデル別に同時実行を制限し、対話系の余力を予約する。
3. 適格な経路へ移す：待てる仕事はBatchへ。Priorityは契約と余力が合う場合だけ。
4. 仕事の形を変える：要件を満たす軽量モデル、入力分割、不要な出力削減を使う。
5. 金銭所有者を直す：残高を戻し、正しい支出上限を調整し、ティア資格の反映を待つ。
6. 容量を取得する：増枠を申請し、Cloud管理や予約容量が必要なら適切なVertex経路を採用する。
7. 診断後に分散する：単一提供元への集中が実証された信頼性リスクなら、複数モデルへのフォールバックを設計する。

最後の用途では、laozhang.aiのようなマルチモデルゲートウェイを候補として評価できます。ただしGoogleプロジェクトの割り当ては増えません。モデル同等性、タイムアウト、切り替え、冪等性、データ処理、観測性、費用を実測し、価格、対応モデル、速度、稼働率を未確認のまま約束しないでください。

どの変更にも同じ所有者の検証指標が必要です。同じプロジェクト、モデル、代表的負荷で、429率、遅延、重複処理、リクエストとトークン利用量を確認します。デプロイ成功は容量回復の証明ではありません。

よくある質問

現在のGemini APIレート制限はどこで確認できますか？

AI Studioで対象と同じプロジェクトとモデルを選びます。公開文書はRPM、入力TPM、RPD、ティア、処理経路を説明しますが、記載値は保証されません。運用判断は有効な管理画面の値で行います。

制限はAPIキー単位ですか、プロジェクト単位ですか？

Developer APIはプロジェクト単位です。同一プロジェクトの複数キーは同じプールを共有します。新しいプロジェクトは、仕事、所有、請求、ガバナンスを本当に分離するときだけ使います。

RPDはいつリセットされますか？

現行のDeveloper API文書では、太平洋時間午前0時です。待つ前にRPDが所有者か確認してください。RPM、入力TPM、費用、残高、Firebase、Vertexは別の窓や契約です。

請求を有効にしても429が消えないのはなぜですか？

請求は一つの分岐にすぎません。RPM、入力TPM、RPD、ローリング費用、二種類の支出上限、Priority、モデル固有制限、Prepay残高を個別に確認します。

Priorityに変えれば容量は増えますか？

必ずではありません。Priorityは適格な独自契約で、独自上限を持ちながら対話トラフィックにも計上されます。切り替える前に両方の有効余力を見ます。

Batchなら対話上限を回避できますか？

Batchは独立上限を持ち、非同期仕事に適しますが無制限ではありません。同時ジョブ、ファイル、保存容量、キュートークンがあり、最大24時間の完了時間を受け入れる必要があります。

429はすべて再試行すべきですか？

いいえ。待機または負荷形状が所有者を変えられるときだけです。日次枠、残高、費用上限、明示割り当てには別の修正が必要です。

使用量と429が一致しないとき、何を添えて問い合わせますか？

完全なエラー本文、タイムゾーン付き時刻、プロジェクトID、モデル、エンドポイント、処理経路、入力規模、直前の同時実行、同じ時間帯の使用量を添えます。APIキーと利用者データは除きます。

実務で残す一つの原則

製品面、指標、集計単位、処理経路、修正行動を先に特定します。正しい管理画面で所有者を確認し、そこに効く一つの変更だけを行い、同じ負荷で検証します。硬い境界が残るなら再試行を止め、正しいリセットを待つ、需要を減らす、適格な経路へ移す、または容量を取得します。