Gemini APIのレート制限を利用ティア別に確認する：429の原因と現在値

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月2日時点のGemini API請求ガイドでは、次の条件が示されています。ここにある月額上限と10分間の支出上限は、特定モデルのRPMではありません。

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の出方から次の操作を選ぶ

利用ティアを上げても、別プロジェクトの画面を見ている、プレビュー版モデルの上限が厳しい、全プロセスが同時再試行する、といった問題は解決しません。

再試行は一時的な失敗だけに使う

Googleのトラブルシューティングガイドは、429や503などの一時的エラーに指数バックオフ、ランダムなジッター、最大試行回数を使うよう推奨しています。公式SDKが自動再試行する場合もあるため、独自実装を重ねる前に確認します。

バックオフはウィンドウが解消するまで待つ仕組みで、RPM、TPM、RPD、支出容量を増やしません。キー別ではなくプロジェクト単位の共通キューやレートリミッターを使うと、同時再試行の波を抑えられます。

400や403は、パラメータ、モデル/API版、認証、権限などの問題であることが多く、429と同じ再試行をしてはいけません。Gemini APIエラーガイドで分けて確認できます。

現在値を記録して次回も比較できるようにする

容量判断には、日付、請求先アカウント、プロジェクト、利用ティア、完全なmodel ID、実行方法、有効なRPM/TPM/RPDや固有制限、平均入力、同時数、10分のピーク支出を残します。モデルや条件が変わっても再計算できます。

無料枠だけを評価する場合はGemini API無料枠ガイドを使います。このページは、すべての利用ティアで有効な容量と429の原因を判断するためのものです。

利用ティアは資格、AI Studioは現在のプロジェクト情報、失敗したリクエストは診断対象です。この三つを分けると、上限値が更新されても判断方法は変わりません。