Gemini APIで429が返っても、最初に「何分待つか」を決めないでください。先に確認するのは、どのサービスから、どのプロジェクトで、どの正確なモデルを使い、どの指標または処理レーンに達し、いつ更新される制限なのかという5点です。ここが不明なままでは、待機、課金、モデル変更、キー変更のどれが妥当か判断できません。
Gemini Developer APIの実際の値は、Google AI Studioのレート制限画面で対象のGoogle Cloudプロジェクトとモデル行を確認します。Geminiアプリ、Firebase AI Logic、Vertex AIは別の単位で数えるため、ひとつの「Geminiの回数制限」にはまとめられません。
| 実際に使っている経路 | 現在値を確認する場所 | 最初の対応 |
|---|---|---|
| Gemini Developer API | AI Studioの対象プロジェクト・モデル行 | RPM、入力TPM、RPD、IPM、TPD、支出、Priority、Batchのうち先に達したものを特定する |
| Geminiアプリ | 設定 → 使用量の上限 | 機能別の残量と表示された回復時刻を確認する |
| Firebase AI Logic | Firebaseのユーザー単位設定と上流プロバイダーのクォータ | 両方を確認し、低い側を実効上限として扱う |
| Vertex AI | Google CloudのDynamic Shared QuotaまたはProvisioned Throughput | 共有容量の競合と購入済み処理量を分けて調べる |
停止条件：APIキーを次々に替えたり、無制限に再試行したりしないでください。429 RESOURCE_EXHAUSTEDならクォータ、頻度、日次、支出などの受付条件を調べます。503 UNAVAILABLEなら一時的な過負荷やサービス容量を調べます。どちらも一時的に回復する可能性はありますが、根本対応は異なります。
固定の一覧表より、対象プロジェクトの現在値を確認する
Gemini APIの公式レート制限ドキュメントは仕組みを説明し、ログイン済みのAI Studioは対象プロジェクトに適用される値を示します。公開されているモデル別一覧は用語の理解には役立ちますが、現在のusage tier、billing accountの状態、preview modelの扱い、アカウント状態、利用可能な容量までは反映できません。
Developer APIでは、主に次の指標が独立して計数されます。
- RPM（1分あたりのリクエスト数）：短いリクエストを大量に送ると、tokenに余裕があっても先に到達します。
- 入力TPM（1分あたりの入力token数）：長いpromptやcontextが多いと、リクエスト数が少なくても先に到達します。
- RPD（1日あたりのリクエスト数）：対象の行に表示される場合だけ適用されます。現在の公式ルールでは太平洋時間の午前0時にリセットされます。
- モデルや機能によっては、画像用のIPMや1日単位のTPDも表示されます。
適用される指標のどれかひとつでも上限に達すれば、リクエストは拒否される可能性があります。previewやexperimentalのモデルは上限が厳しい場合があります。障害記録には「Pro」「Flash」だけでなく、リクエストに指定した完全なmodel IDを残してください。
APIキーを増やしても同一プロジェクトの枠は増えない
Developer APIのレート制限はAPIキー単位ではなくGoogle Cloudプロジェクト単位です。同じプロジェクトに複数のキーを作っても、RPM、TPM、RPDは共通の枠から消費されます。
追加キーは、credential rotation、サービス分離、権限管理には有効です。しかし容量増加の手段ではありません。クォータ回避のためだけに複数プロジェクトへ分散するのも適切ではありません。環境、請求、セキュリティ、組織上の境界が実在するときに限り、routing、費用、data policy、障害分離を設計したうえで分けます。
コードの応答ではなくAI Studioのチャット画面に具体的な制限メッセージが出た場合は、Google AI Studioのレート制限から復旧する手順を使ってください。画面側のcooldownとDeveloper APIのproject quotaは同じ問題ではありません。
利用階層と支出条件は更新される
2026年7月15日時点で、Googleの公開ドキュメントは次の条件を示しています。将来も同じとは限らないため、負荷試験の直前に再確認してください。
| 階層 | その日時点の公開条件 | アカウント側で確認する内容 |
|---|---|---|
| Free | 有効なプロジェクトまたはfree trialの状態 | 対象プロジェクトで利用できるモデルと実際の行の値 |
| Tier 1 | 有効なbilling accountをリンク | 課金有効化後に表示された階層とモデル行 |
| Tier 2 | 100米ドル以上の支払い、かつ最初の成功支払いから3日以上 | account standingとGoogleが表示する階層 |
| Tier 3 | 1,000米ドル以上の支払い、かつ最初の成功支払いから30日以上 | account standingとGoogleが表示する階層 |
同じ公開ドキュメントは、ローリング10分で評価する支出ベースの受付上限も記載しています。2026年7月15日時点ではTier 1が10米ドル、Tier 2とTier 3が200米ドルです。金額、適用範囲、資格条件は変わり得るため、運用手順に固定する前に公式情報と対象プロジェクトを照合します。
billing accountを設定すると階層の資格は変わりますが、すべての制限が消えるわけではありません。有料プロジェクトでもRPM、入力TPM、RPD、支出枠、Batchなどに達します。無料で使えるモデルの範囲を確認したい場合は、Gemini API無料枠ガイドで別に判断してください。
分・日・支出・処理レーンを分ける
1分の指標に余裕があっても、日次または支出の条件で拒否されることがあります。また、Standard、Priority、Batchは同じ枠の呼び名ではなく、別々に観測すべき処理経路です。
| 指標または経路 | 制御するもの | 保存すべき証拠 | よくある誤り |
|---|---|---|---|
| RPM | 1分あたりのオンライン呼び出し数 | request timestampの分布と現在のRPM行 | 平均RPSだけを見てburstを無視する |
| 入力TPM | 1分あたりのprompt・context token | 入力サイズの分布 | 全リクエストが同じ大きさだと仮定する |
| RPD | 有効な場合の1日あたりリクエスト数 | 現在のRPD行と太平洋時間のリセット | 数秒のbackoffで日次上限が戻ると思う |
| 支出枠 | 対象ローリング期間の支出受付 | billing tierと現在の公式条件 | 月間予算と混同する |
| Priority | 優先処理用の別上限 | 指定したservice tierとx-gemini-service-tier | 無制限の追加容量だと考える |
| Batch | 非同期処理用の別クォータ | 同時job、file size、enqueued tokens | 緊急の対話処理をBatchへ移す |
Priority inferenceのドキュメントでは、現在の既定Priority上限を対応するStandardのモデル・階層上限の0.3倍としています。Priority容量に達すると、単純に失敗するのではなくStandardとして処理される場合があります。latencyやcostが処理レーンに依存する場合は、返されたx-gemini-service-tierを記録します。
Batchは対話リクエストと別の枠を使うため、急がない処理に向いています。2026年7月15日時点のBatch APIドキュメントでは、同時batch request 100件、入力ファイル1件あたり2 GB、file storage合計20 GB、モデル・階層別のenqueued token上限が示されています。これらも確認日付きの条件です。
負荷試験の記録には、target RPSだけでなく、正確なモデルとプロジェクト、入力tokenのp50/p95、burst係数、requested serving tier、p95 latency、1日量、支出リスク、retry比率、同期処理が必須かどうかを含めます。
実測値から安全な処理量を計算する
対象プロジェクトの行を確認したら、まず1分単位でどちらが先に制限になるか計算します。
リクエスト上限 = min（現在のRPM、現在の入力TPM ÷ 1リクエストあたりの平均入力token）
ここで得た数値は計算上の出発点であり、本番の目標値ではありません。入力サイズのばらつき、burst、retryによる増幅、表示値より低い実容量を考慮し、実測と業務リスクに応じてheadroomを決めます。Googleが全システム共通の余裕率を指定しているわけではありません。
前提を明示した計算例
現在の行が60 RPM、120,000入力TPMで、観測した平均入力が4,000 tokenだとします。
- RPMから見た上限は60 request/minです。
- 入力TPMから見た上限は120,000 ÷ 4,000 = 30 request/minです。
- 小さい側が先に制限になるため、headroomを入れる前の上限は30 request/minです。
- この例でチームが20%のheadroomを採用するなら、初期運用目標は24 request/min、つまり0.4 RPSです。
- 実測p95 latencyが2秒なら、定常時の同時実行数は0.4 × 2 = 0.8と見積もれます。まずconcurrency 1から始め、queue、burst、retryの挙動を測定します。
20%は説明用の工学的仮定であり、Googleの推奨値ではありません。変動の大きい一般向けサービスではさらに余裕が必要な場合があり、入力を厳密に制御できるoffline queueでは別の値が妥当です。
分単位の計算だけでは不十分です。24 request/minを24時間継続すると、理論上は1日34,560件を試行します。対象のRPDと比較し、支出枠も別に確認してください。10分間の試験が成功しても、1日中動かせるとは限りません。
入力サイズが一定でない場合は、平均だけでなく分位点を使います。
| 観測値 | 分かること |
|---|---|
| 平均入力token | 定常処理量の初期値 |
| p95入力token | 通常のピークでTPMに達するか |
| 許容する最大入力 | 1種類の長文処理が1分枠を占有しないか |
| p95 latency | 安全なRPSを初期concurrency capへ変換 |
| Retry rate | 部分障害時の増幅量 |
| Cache hit rate | 繰り返しcontextをhot pathから外せるか |
モデル、prompt template、context長、tool use、traffic mix、階層、処理レーンが変わったら再計算します。容量設計は一度だけの割り算ではなく、継続的な測定です。
429と503を別の障害として切り分ける
公式トラブルシューティングは、429 RESOURCE_EXHAUSTEDと503 UNAVAILABLEを別の意味として扱います。どちらにも上限付きのexponential backoffとjitterが役立つ場合はありますが、先に根拠と再実行の安全性を確認します。
| 応答 | 最初の見立て | 確認する証拠 | 有効な対応 | 中止する条件 |
|---|---|---|---|---|
429 RESOURCE_EXHAUSTED | クォータ、頻度、RPD、支出、その他の受付上限 | 完全なerror body、headers、Retry-After、プロジェクト・モデル行、直近のusage | queue、rate低下、入力削減、正しいwindowの待機、公式quota path | 到達した指標とリセットが不明なままの再試行を中止 |
503 UNAVAILABLE | 一時過負荷、容量、サービス停止 | request ID、時刻とtimezone、endpoint/region、model、service status | 上限付きbackoff、traffic smoothing、適切なglobal endpoint、証拠付きescalation | retry budget超過または影響が継続した時点 |
1分のburstによる429は、windowが進めば回復することがあります。RPDに達した429は数秒ごとの再試行では戻りません。支出枠なら対象のrolling windowまたはbilling対応が必要です。503が継続する場合は、project quotaに余裕があってもservice statusやcapacity pathを確認します。
再試行には回数と時間の上限を設ける
本番のretry policyでは、少なくとも次を決めます。
- retry可能なstatus codeと即時中止するstatus code
- 同じ操作を繰り返しても二重処理にならないか
- 最大試行回数と合計経過時間
- randomized jitterを含むexponential backoff
Retry-Afterがある場合の扱い- 同期的なretry stormを防ぐqueueまたはcircuit breaker
- 元の呼び出しとretry trafficを分けたmetrics
- request ID、model ID、endpoint、timezone付き時刻、応答詳細、影響を含むescalation情報
APIキーは含めず、安全に共有できる情報だけを残します。キー変更はクォータを増やさないうえ、どのcredentialとserviceが失敗したかを追いにくくします。クォータ回避のためのプロジェクト分散も行いません。
症状ではなく、先に達した制限を直す
最小の安全な対応は、実際に先に達した指標で決まります。
| 先に達した制限 | 短期対応 | 継続的な設計 | 避ける対応 |
|---|---|---|---|
| RPM | burstを平滑化し、concurrencyを制限し、queueへ入れる | workload別のadmission controlとbudget | 同一projectでキーを増やす |
| 入力TPM | contextを短くし、重複指示を除き、batch sizeを下げる | 安定prefixをcacheし、大きいjobを分離 | tokenを測らずrequestだけ数える |
| RPD | 不要な呼び出しを止め、該当時はPacific resetを待つ | 日次量を予測し、適切なtierを検討 | 短い間隔で繰り返す |
| 支出枠 | 受付量を下げ、対象rolling windowを待つ | cost alertとcost-aware admission | billingが全制限を消すと考える |
| Priority | 実際に返ったtierを確認し、Standard fallbackを許容するか決める | latency-sensitiveな処理だけに使い個別監視 | 一般的な余裕枠として扱う |
| Batchのtokenまたはjob | 提出時刻を分散し、jobを小さくする | 現在のBatch条件に沿った非同期scheduler | 即時回答が必要な処理を移す |
| 503の容量 | 上限付きbackoffとtraffic smoothing | global routing、capacity planning、必要時Provisioned Throughput | 容量の証拠なしにproject quotaだけ追う |
cacheは大きな安定prefixが繰り返されるときに有効です。queueは待てる需要に、Batchは対話性が不要な処理に有効です。モデル変更は、候補モデルが現在利用可能で、品質要件を満たし、そのモデル行が実際の制限を改善するときだけ意味があります。古い一覧にあるmodel nameはfallbackになりません。
上限引き上げを依頼するなら、project、model、traffic distribution、先に達した指標、成長予測、実施済み対策、business impactを添えます。「RPMを増やしてほしい」だけより判断材料が増えます。
Geminiアプリ、Firebase、Vertexを混同しない
Geminiという名称は複数の製品で使われますが、制限を数える単位は共通ではありません。
Geminiアプリは消費者アカウントの使用量を数える
Geminiアプリの上限は、選択モデルや機能、promptの複雑さ、file、会話の長さなどで変わります。2026年7月15日時点のGeminiアプリヘルプでは、週間上限に達するまでは5時間ごとに利用可能量が更新され、具体的な回復時刻は設定 → 使用量の上限に表示されると説明しています。値はcapacityによって変わる場合があります。
アプリのsubscriptionは、Developer APIプロジェクトのRPM、TPM、RPDを自動的に増やしません。消費者向けsubscriptionと課金済みAPI projectは別の利用経路です。
Firebase AI Logicでは2段階を確認する
Firebase AI Logicは、上流のmodel provider quotaに加えてper-user gateway limitを設定できます。2026年7月15日時点でFirebaseは既定値をユーザーあたり100 RPMとしています。上流のGemini project/model quotaも引き続き適用されます。
実効上限は、該当する低い側です。ひとりのユーザーだけが制限され、project usageに余裕があるならFirebase gatewayを確認します。多数のユーザーが同時に失敗し、Geminiのプロジェクト行が上限なら、gatewayだけを変更しても解決しません。
Vertex AIは独自の容量方式を使う
Vertex AI PayGoの新しいGeminiモデルについて、Google Cloudは固定の一律project quotaではなくDynamic Shared Quotaを説明しています。Vertexの429はshared poolの競合を示す場合があり、traffic smoothing、適切なglobal endpoint、上限付きretry、Provisioned Throughputがこの経路の選択肢です。
Developer APIのRPM/RPDをVertexの計画へ転記しないでください。予測可能なenterprise throughputが必要なら、観測したPayGoの挙動とProvisioned Throughputを比較します。
画像生成ではIPM、アプリの画像回数、Vertex image capacityなども関係します。対象が画像ならGemini画像生成のレート制限ガイドへ分け、一般的なDeveloper APIの説明だけで判断しないでください。
本番投入前に制限条件を記録する
リリース前の記録で、次の項目を回答できるようにします。
- 経路：Developer API、Geminiアプリ、Firebase、Vertexのどれか
- 帰属：どのproject、billing account、consumer account、Firebase projectか
- モデル：完全なmodel IDと現在のstatus
- 指標：RPM、入力TPM、RPD、IPM、TPD、支出、Batch、Priorityのどれが適用されるか
- window：いつリセットまたは移動し、どこで再確認するか
- traffic形状：p50/p95入力token、p95 latency、burst係数、日次量、retry rate
- 受付制御：queue、concurrency cap、token budget、shed rule
- エラー分岐：429と503を別々に記録し、それぞれにretry上限と停止条件があるか
- 処理レーン：Standard、Priority、Batchを別々に観測しているか
- 共有可能な証拠：request ID、時刻、model、project、response、impactをcredentialなしで保存できるか
負荷試験にはhelloではなく、本番に近い入力サイズを使います。短いburstと継続時間の両方を測り、retryが追加負荷として見えることを確認します。alertは公開上限そのものではなく、チームが決めた運用目標より手前に設定します。
有用なdashboardはモデル別の数字を並べるだけではありません。障害時に、どの経路で、どの指標が先に達し、何が変わり、どの対応なら安全かを短時間で答えられる必要があります。
よくある質問
Gemini APIのレート制限はAPIキー単位ですか？
いいえ。Developer APIはGoogle Cloudプロジェクト単位です。同一プロジェクトの複数キーは同じクォータを共有します。
Gemini APIに1日あたりの上限はありますか？
一部のプロジェクト・モデル行にはRPDまたはTPDがありますが、全モデル共通の数字はありません。RPDが適用される場合、現在は太平洋時間の午前0時にリセットされます。
課金済みなのに429になるのはなぜですか？
課金はtier資格を変えますが、RPM、入力TPM、RPD、支出枠、Batchなどは残ります。429はbilling failureの証明ではなく、到達した指標を探す手掛かりです。
429のあと何分待てばよいですか？
到達したwindowによります。Retry-Afterがあれば従い、error bodyと現在の行を照合します。分単位の圧力に有効な短い待機でも、RPDはリセットされません。
Batch APIのクォータは別ですか？
はい。Batchには独立したpoolがあり、同時job、入力file、storage、enqueued tokenの制限があります。本番投入前に最新条件を確認してください。
Geminiアプリの有料プランでAPI上限も増えますか？
そうとは限りません。アプリの上限はconsumer accountと機能に、Developer APIの上限はCloud project、model、tier、AI Studioの現在行に属します。
Vertex AIのGemini上限はDeveloper APIと同じですか？
いいえ。新しいVertex AI PayGoはDynamic Shared Quotaを使い、Provisioned Throughputは購入済み容量です。Google Cloud側の証拠で切り分けます。
複数のGoogle Cloudプロジェクトで容量を増やせますか？
実在する環境、請求、セキュリティ、組織の境界なら別々の制限を持てますが、クォータ回避を目的に作成・切り替えしてはいけません。
サポートには何を送ればよいですか？
製品経路、安全に共有できるproject ID、完全なmodel、endpointまたはregion、timezone付きtimestamp、request ID、完全なerror codeとdetails、現在の制限行、直近trafficとtoken分布、retry挙動、影響を送ります。APIキーは絶対に含めません。
