Gemini APIのFree、Tier 1、Tier 2、Tier 3は、すべてのモデルに共通する固定RPMを表すものではありません。モデル、プロジェクト、請求先アカウント、通常・Priority・Batchという実行方法によって適用される制限が変わり、現在の有効な値はGoogle AI Studioで確認します。
429 RESOURCE_EXHAUSTEDが返ったときは、古い「Freeは15 RPM」という表ではなく、失敗したリクエストと同じプロジェクト、モデル、利用ティア、時間帯を比較する必要があります。429はRPMだけでなく、入力TPM、RPD、モデル固有の制限、10分間の支出上限でも発生します。
ティアと有効な上限は別に確認する
Googleのレート制限ページは、利用ティアなど複数の要因で上限が決まると説明し、有効なレート制限をAI Studioで確認するよう案内しています。公開された上限値は保証ではなく、実際の容量は変動するとも明記されています。
確認先を混ぜないことが重要です。
- ProjectsまたはAPI keysで、キーが属するプロジェクト、請求先アカウント、現在の利用ティアを確認する。
- DashboardのRate Limitで、実際に呼び出したモデルの有効なRPM、入力TPM、RPDなどを確認する。
- Usageで、同じプロジェクトと時間帯の消費量を確認する。
- リクエストが通常、Priority inference、Batch APIのどれか確認する。
APIキーごとに独立した容量が与えられるわけではありません。同じプロジェクトのキーはプロジェクトの制限を共有します。プロジェクトは、紐付いた請求先アカウントの利用ティアとアカウント上限を引き継ぎます。
2026年9月時点の利用ティア条件
2026年9月12日に確認したGemini API請求ガイドでは、次の条件が示されています。ここにある月額上限と10分間の支出上限は、特定モデルのRPMではありません。
| 利用ティア | 現在の条件 | 請求先アカウントの月額上限 | 直近10分間の支出上限 |
|---|---|---|---|
| Free | 有効なプロジェクトまたは無料トライアル | 該当なし | 該当なし |
| Tier 1 | 有効な請求先アカウントを設定してリンク | $250 | $10 |
| Tier 2 | $100を支払い、最初の成功した支払いから3日経過 | $2,000 | $50 |
| Tier 3 | $1,000を支払い、最初の成功した支払いから30日経過 | $20,000〜$100,000+ | $200 |
Tier 2とTier 3の判定では、リンクされた請求先アカウント配下のプロジェクトで発生したGoogle Cloudサービスについて累計で支払い済みの金額が数えられます。1本のGemini APIキーの利用額だけでも、未払いの請求額でもありません。
条件を満たすと原則として自動昇格します。FreeからTier 1は通常すぐに反映され、その後の昇格は通常10分以内ですが、処理や審査の影響を受けることがあります。支払い完了画面だけで判断せず、AI StudioのProjectsで反映後の利用ティアを確認します。
直近10分間の支出上限は、請求履歴とアカウント状態によって適用されるため、全アカウントに同じ条件で適用されるとは限りません。支出レート制限の公式説明リクエスト数と入力トークンが有効な上限内でも、高コストの呼び出しが短時間に集中すると429になる可能性があります。
RPM以外に確認する制限
Googleが一般的な指標として挙げているのは次の三つです。
- RPM：1分あたりのリクエスト数。短いバーストや同時実行で到達しやすい。
- 入力TPM：1分あたりの入力トークン数。長いコンテキストを並列送信すると、少ないリクエストでも到達する。
- RPD：1日あたりのリクエスト数。太平洋時間の午前0時にリセットされる。
画像生成モデルではIPM、別のモデルではTPDが設定される場合があります。適用される各指標は独立して評価されるため、RPMに余裕があっても入力TPM、RPD、IPM、TPD、支出上限のどれかで拒否されます。
現在のRPMと入力TPMが分かる場合、目安となる処理量は次の式で求められます。
1分あたりのリクエスト数 ≈ min(有効RPM, floor(有効入力TPM / 1リクエストの平均入力トークン))
これは新しい割り当てではなく、容量計画の目安です。入力が短文から長文書へ変われば、利用ティアとRPMが同じでも入力TPMが先にボトルネックになります。公開値を100%継続利用できる前提にせず、変動分の余裕を持たせます。
PriorityとBatchは通常リクエストと分ける
Priority inferenceには独自の制限があります。Googleは、同一モデル・利用ティアの標準レート制限の0.3倍をデフォルト値として示しています。Priorityの消費は全体のインタラクティブトラフィックにも数えられるため、標準リクエストの値をそのまま適用できません。
Batch APIは非Batchリクエストとは別の制限です。現在は、同時実行のBatchジョブ100件、入力ファイル2 GB、ファイル保存20 GB、モデル・利用ティア別のキュー投入トークン数が公開されています。モデル表は変わるため、Batch APIの最新上限を直接確認します。
429の出方から次の操作を選ぶ
| 状況 | 確認する制限 | 対応 |
|---|---|---|
| 同時実行を増やした直後に429 | RPM | プロジェクト共通キューで平準化し、同時数を抑え、上限回数付きで再試行 |
| 呼び出し回数は少ないが入力が大きい | 入力TPM | 重複コンテキストを除き、大きな並列入力を減らし、必要な情報だけ取得 |
| 1日の継続利用後に止まる | RPDまたはTPD | エラーで指標を特定する。RPDは太平洋時間0時、TPDはその指標の案内を確認して待つ |
| 高コスト要求が10分以内に集中 | 支出上限 | 過去の消費が直近10分間の集計対象から外れるのを待ち、入力・出力の費用を抑える |
| Priorityだけ失敗 | Priorityの上限 | 専用値を確認し、遅延要件が合う場合だけ標準リクエストへ変更 |
| Batchジョブを投入できない | 同時ジョブまたはキュー投入トークン | 既存ジョブの完了を待ち、バッチを小さくするかモデル表を確認 |
| Usageが低いのに429 | プロジェクト/モデル違い、利用ティア反映待ち、容量変動 | キーとプロジェクト、モデルID、利用ティア、請求状態を照合し、解消しなければ記録を添えて問い合わせる |
利用ティアを上げても、別プロジェクトの画面を見ている、プレビュー版モデルの上限が厳しい、全プロセスが同時再試行する、といった問題は解決しません。
再試行は一時的な失敗だけに使う
Googleのトラブルシューティングガイドは、429や503などの一時的エラーに指数バックオフ、ランダムなジッター、最大試行回数を使うよう推奨しています。公式SDKが自動再試行する場合もあるため、独自実装を重ねる前に確認します。
バックオフは再試行の間隔を延ばす方法です。割り当てられたRPM、TPM、RPDや支出上限を増やすものではなく、日次枠や請求の問題を数秒の待機で解決できるとは限りません。キー別ではなくプロジェクト単位の共通キューやレートリミッターを使うと、同時再試行の波を抑えられます。
400や403は、パラメータ、モデル/API版、認証、権限などの問題であることが多く、429と同じ再試行をしてはいけません。Gemini APIエラーガイドで分けて確認できます。
現在値を記録して次回も比較できるようにする
容量判断には、日付、請求先アカウント、プロジェクト、利用ティア、省略しないモデルID、実行方法、有効なRPM/TPM/RPDや固有制限、平均入力、同時数、10分のピーク支出を残します。モデルや条件が変わっても再計算できます。
無料枠だけを評価する場合はGemini API無料枠ガイドを使います。このページは、すべての利用ティアで有効な容量と429の原因を判断するためのものです。
利用ティアだけから処理可能量を決めず、AI Studioに表示される現在の上限と、失敗したリクエストのエラーを照合してください。上限値が変わっても、同じ手順で原因を絞り込めます。
