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

> 固定の上限表を覚えるのではなく、製品面・プロジェクト・指標・処理経路を特定し、該当する管理画面で確認して最小の修正を選ぶ。

- URL: https://blog.laozhang.ai/ja/posts/gemini-api-rate-limits-guide
- Published: 2026-02-02
- Updated: 2026-07-14
- Author: AI Free API Team (https://blog.laozhang.ai/ja/about)
- Category: APIガイド
- Tags: Gemini API, 429エラー, RESOURCE_EXHAUSTED, レート制限, Google AI

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

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

![Gemini API 2026の製品面、プロジェクト、指標、処理経路別レート制限診断](https://blog.laozhang.ai/posts/ja/gemini-api-rate-limits-guide/img/cover.webp)

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

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

| 製品面 | 制限を決めるもの | 最初の確認先 | 誤診を止める条件 |
|---|---|---|---|
| Geminiアプリ | 消費者アカウント、プラン、モデル、機能 | [Geminiアプリの使用上限](https://support.google.com/gemini/answer/16275805?hl=ja)とログイン中の画面 | アプリの契約をAPI容量の証拠にしない |
| Gemini Developer API | プロジェクト、モデル、利用ティア、指標、処理経路 | [AI Studio](https://aistudio.google.com/)で同じプロジェクトとモデル | 同一プロジェクトの別APIキーは新しい枠にならない |
| Firebase AI Logic | モデル提供元の割り当てと、Firebaseのユーザー単位ゲートウェイ上限 | Firebaseの設定とApp Check、その後に提供元の利用状況 | ゲートウェイ上限をDeveloper APIのプロジェクト上限と混同しない |
| Vertex AI | Cloudプロジェクト、ロケーション、エンドポイント、容量契約 | Cloud割り当てと、従量課金またはProvisioned Throughputの状態 | AI Studioの値をVertexリクエストへ流用しない |

![Gemini Apps、Developer API、Firebase AI Logic、Vertex AIの所有者マップ](https://blog.laozhang.ai/posts/ja/gemini-api-rate-limits-guide/img/surface-owner-map.webp)

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

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

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

Googleの[レート制限ドキュメント](https://ai.google.dev/gemini-api/docs/rate-limits?hl=ja)は、基本となる三つの指標を定義し、制限がAPIキー単位ではなくプロジェクト単位で適用されると明記しています。

| 指標 | 何を数えるか | 圧力が生まれる典型例 | 時間の扱い | 有効な対策 |
|---|---|---|---|---|
| RPM | 1分あたりのリクエスト数 | 短い呼び出し、定時ジョブの同時開始、複数ワーカーの一斉再試行 | 分単位の窓 | キュー、平準化、同時実行上限、重複キャッシュ |
| 入力TPM | 1分あたりの入力トークン数 | 長い会話履歴、大量の外部取得データ、複数の長文プロンプト | 分単位の窓 | コンテキスト削減、分割、長い仕事の時間分散 |
| RPD | 1日あたりのリクエスト数 | 一日中動くバックグラウンド処理 | 現行文書では太平洋時間午前0時にリセット | 正しいリセットを待つ、日次需要を減らす、適格な容量を得る |

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

モデルやモダリティによっては、TPD（1日あたりのトークン数）、IPM（1分あたりの画像数）、Batch専用上限もあります。これらはモデルと処理経路に属する値です。画像生成のIPMが所有者なら、[Gemini画像の429切り分け](https://blog.laozhang.ai/ja/posts/gemini-image-429-rate-limit)へ問題を分離します。

![Gemini の RPM、入力TPM、RPD、支出ティア、Batch の所有者マトリクス](https://blog.laozhang.ai/posts/ja/gemini-api-rate-limits-guide/img/limit-owner-matrix.webp)

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

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

## 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. **検証**：同じプロジェクト、モデル、負荷、指標で回復を確認する。

| 観測できたこと | 可能性が高い所有者 | 最小の変更 | 成功の確認 | 中止条件 |
|---|---|---|---|---|
| 瞬間的に失敗し、時間を分散すると同じ総量が通る | RPMまたは一時圧力 | 到着を平準化し、同時実行を制限 | 分単位の429が減り、仕事が欠落しない | 再試行が新しい山を作ったら増やさない |
| 長い入力だけ失敗する | 入力TPM | 履歴を短縮し、外部取得データを圧縮、入力を分割 | 入力トークン/分が下がり同じ仕事が完了 | 同一プロジェクトの別キーへ逃げない |
| 一日使った後に全呼び出しが失敗する | RPD | 太平洋時間のリセットを待つか、適格な容量へ | リセットまたは承認済み変更後に回復 | バックオフで日次枠は増えない |
| 支出や残高の警告と同時に失敗する | 金銭関連の制御 | ティア、ローリング費用、残高、二種類の上限を別々に確認 | 該当状態が解消して配信が戻る | 「請求有効」だけで完了にしない |
| オフライン処理が対話トラフィックを圧迫する | 経路選択 | 適格な仕事をBatchへ | 対話利用率が下がりBatchが完了 | Batchを同期APIのようにポーリングしない |
| 使用量とエラーが一致しない | 未特定または提供側の不一致 | 証拠一式を保存し同じ経路でエスカレーション | 時刻、モデル、プロジェクトを照合できる | 取証前にフォールバックで隠さない |

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

「請求を有効にしたのに429が消えない」という事象は、金銭に関係する複数の制御を一つに見たときに起きます。2026年7月14日にGoogleのレート制限と[請求情報](https://ai.google.dev/gemini-api/docs/billing?hl=ja)を確認した時点では、少なくとも次の四項目を分ける必要があります。

| 制御 | 2026-07-14時点の文書上の扱い | そこからは言えないこと |
|---|---|---|
| 利用ティア | Tier 1は有効な請求先アカウント、Tier 2は累計`$100`以上の支払いと最初の成功から3日、Tier 3は`$1,000`以上と30日 | 条件達成は無制限容量や即時承認を保証しない |
| ローリング費用制限 | 10分窓でFreeは対象外、Tier 1は`$10`、Tier 2と3は`$200` | RPM、RPD、プロジェクト上限、請求先上限とは別 |
| Prepay残高 | Prepay対象アカウントでは正の残高が有料配信の条件になり得る | 過去の請求設定だけで現在の配信可能性は証明できない |
| 支出上限 | プロジェクトと請求先アカウントで意味が異なり、反映に遅延があり得る | 上限を上げてもモデル別またはプロジェクト別割り当ては消えない |

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

具体値は変わり得るため、本番変更の直前に公式の[利用ティアと費用制限](https://ai.google.dev/gemini-api/docs/rate-limits?hl=ja#usage-tiers)とAI Studioを再確認します。支払い履歴、アカウント状態、入金反映、表示遅延が結果に影響します。

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

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

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

| 経路 | 適した仕事 | 制限の構造 | 運用上の境界 |
|---|---|---|---|
| Standard | 利用者が今すぐ応答を待つ処理 | プロジェクト、モデル、ティアの対話上限 | バーストを平準化し、前景用の余力を確保 |
| Priority | 適格な有料契約で優先処理が必要な仕事 | 独自上限を持ち、2026-07-14時点の既定値は対応するStandardの`0.3×`。対話トラフィックにも計上 | 移行前にPriorityと対話全体の両方を確認 |
| Batch | 評価、索引、分類、補完などの非同期仕事 | 同時ジョブ、入力ファイル、保存容量、モデル/ティア別のキュートークン上限 | 非同期完了を前提に大きな仕事を復旧可能な単位へ分割 |

Googleの[Batch API文書](https://ai.google.dev/gemini-api/docs/batch-api?hl=ja)では、完了まで最大24時間を見込む設計で、ジョブ作成は冪等ではありません。クライアント側の永続IDを先に作り、返されたジョブ名を保存します。作成要求がタイムアウトしただけで同じ仕事を再投入すると、重複処理を作る危険があります。

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

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

Googleの[トラブルシューティング](https://ai.google.dev/gemini-api/docs/troubleshooting?hl=ja)は、429と503を別の状態として扱います。実装でも最初に分けます。

| 状態 | 意味 | 再試行の方針 |
|---|---|---|
| `429 RESOURCE_EXHAUSTED` | レート、トークン、日次、費用などの制限 | 待機または平準化が同じ所有者を解放できる場合だけ。日次、残高、費用、明示割り当てでは停止 |
| `503 UNAVAILABLE` | 一時的なサービス不足または容量不足 | 回数上限付き指数バックオフとジッター。継続時は軽量モデルや適格経路を検討 |
| その他の4xx | 認証、権限、入力、請求前提、不対応要求 | 原因を修正し、同じ内容を繰り返さない |

![Gemini 429 と 503 の分岐、再試行境界、平準化、経路、容量の復旧ラダー](https://blog.laozhang.ai/posts/ja/gemini-api-rate-limits-guide/img/recovery-capacity-ladder.webp)

次の関数は、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の割り当て文書](https://firebase.google.com/docs/ai-logic/quotas?hl=ja)によると、提供元の制限が優先し、Firebaseゲートウェイは別に設定可能なユーザー単位上限を追加します。2026年7月14日時点の既定値は、ユーザーごとに100 RPMです。

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

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

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

Vertex AIはGoogle Cloudのプロジェクト、ロケーション、エンドポイント、容量契約を使います。[Vertex AIの429文書](https://cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/error-code-429?hl=ja)は、従量課金とProvisioned Throughputでメッセージと対策を分けています。

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

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

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

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

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

最後の用途では、[laozhang.ai](https://docs.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キーと利用者データは除きます。

## 実務で残す一つの原則

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