Gemini APIのレート制限とは｜ティア別の上限の確認方法と429の対処

Gemini APIのレート制限は、1分あたりのリクエスト数（RPM）、1分あたりの入力トークン数（TPM）、1日あたりのリクエスト数（RPD）の3つで測られ、どれか1つでも超えると429 RESOURCE_EXHAUSTEDが返ります。上限はプロジェクト単位で、自分の値はGoogle AI Studioで確認します。公式のRate limitsページ（2026年10月15日更新の表示）を2026年10月20日に開いて確認した内容で整理しています。

429が出たときの対処は、待って再試行する、1回のリクエストを小さくする・減らす、Batch APIに回す、ティアを上げる、の4つです。この記事では、どの上限に当たったかの見分け方から順に説明します。なお、同ページにはモデル別のRPM・TPM・RPDの一覧表はなく、数値はAI Studioで見る形になっていたため、この記事ではモデル別の具体的な上限値を書きません。料金の読み方はGemini APIの料金を解説した記事に分けています。

レート制限とは：RPM・TPM・RPDの意味

Gemini APIのレート制限とは、一定の期間内に送れるリクエストやトークンの量を決める上限のことで、公式ページでは主にRPM・TPM・RPDの3つの単位で測ると説明されています。

公式のRate limitsでは、使用量は3つの上限それぞれに対して評価され、どれか1つを超えるとレート制限エラーになると説明されています（2026年10月20日確認）。たとえばRPMの上限が20なら、1分間に21回送るとTPMなど他の上限を超えていなくてもエラーになります。

この3つのほかに、同じページには、画像を生成できるモデル（Nano Banana）だけに適用される1分あたりの画像数（IPM）や、モデルによっては1日あたりのトークン数（TPD）の上限があることも書かれています。どの単位が効くかはモデルごとに違うため、使うモデルの行をAI Studioで見る必要があります。

上限が決まる仕組み：プロジェクト・モデル・ティア

Gemini APIの上限は、APIキーではなくプロジェクトに対して、使うモデルと利用ティアに応じて決まります。

公式のRate limitsには、レート制限はプロジェクトごとに適用され、APIキーごとではないと書かれています。日本語版のページにも同じ内容があり、日英で食い違いは見つかりませんでした（2026年10月20日確認）。同じプロジェクトでキーを増やしても、上限が増えるわけではありません。

同じページには、試験運用版（experimental）とプレビュー版のモデルは制限が厳しいこと、記載された上限は保証されるものではなく実際の容量は変わりうることも書かれています。この記事の数値も、確認日時点のものとして読んでください。

通常のリクエストとは別の枠もあります。同ページによると、Batch APIには非バッチの呼び出しとは別の上限があり、優先推論（Priority）には独自の上限があって、既定ではモデルとティアごとの標準の上限の0.3倍とされています。Batch APIについては後の節で説明します。

利用ティアの仕組み：4段階の条件と費用ベースの上限

利用ティアとは、プロジェクトの請求状況と支払い実績に応じて割り当てられる段階のことで、Free・Tier 1・Tier 2・Tier 3の4つがあり、段階が上がると上限も上がります。

公式のRate limitsの表（2026年10月20日確認）では、各ティアの条件と、費用ベースの上限が次のように示されています。費用ベースの上限は、RPMやTPMとは別に、予期しない請求を防ぐために適用されるもので、10分間のローリングウィンドウで評価されます。

Tier 2とTier 3の条件は、プロジェクトにリンクした請求先アカウントでの、Gemini APIを含むGoogle Cloudサービスの累計の支払いに基づくと説明されています。費用ベースの上限が自分のアカウントに適用されるかどうかは、請求履歴とアカウントの状態によると書かれています。公式の表にはBilling tier capという列もありますが、その列の意味は同ページに説明が見当たらないため、この記事では扱いません。

費用ベースの上限は、見方を変えると平均の支出ペースの目安にもなります。次は、公式の表の値を使った仮の計算です。Tier 1の10分あたり$10は、均すと1分あたり$1です。1回のリクエストの費用が仮に$0.05なら、10分で200回、つまり1分あたり約20回で$10に届きます。この$0.05は説明用の仮の数字で、実際の費用ではありません。RPMに余裕があっても、高コストなリクエストが続くと費用ベースの上限に先に当たる、という順序を示す例です。

自分の上限とティアを確認する場所

自分のプロジェクトに適用されている上限は、Google AI Studioのレート制限のページで確認し、ティアはAI StudioのProjectsページで確認します。

公式のRate limitsでは、有効なレート制限を見るボタンとして「View your active rate limits in AI Studio」が案内され、リンク先はAI Studioのレート制限ページです。ティアの確認はAI StudioのProjectsページで行うと同ページに案内されています（2026年10月20日確認）。画面の細かい表示は更新されることがあるため、ここでは公式ページに書かれた案内だけを書きます。AI Studio自体の使い方はGoogle AI Studioの使い方を解説した記事で説明しています。

上限は、ティアやアカウントの状態が変わると自動で更新されると公式ページに書かれています。以前メモした数値を使い回さず、設計や見積もりの前にその都度AI Studioで確かめるのが安全です。

429 RESOURCE_EXHAUSTEDが出たときの見分け方

429 RESOURCE_EXHAUSTEDとは、レート制限や費用ベースの上限に達したときにGemini APIが返すエラーで、どの上限に当たったかによって取るべき対処が変わります。

公式のTroubleshooting guideは、429 RESOURCE_EXHAUSTEDや503 UNAVAILABLEのように再試行を促すエラーには、指数バックオフを実装することを勧めています（2026年10月20日確認）。一方、API errorsのページは、429系のエラーコードを次のように分けています。ただし、このページは冒頭でInteractions APIのエラーコードの参照ページと説明されているため、generateContentで同じコード名が返るとは、この記事の確認範囲では書かれていませんでした。コード名は、考え方の整理として読んでください。

見分け方の手順は次のとおりです。まず、エラーが出た時刻と、その日のリクエスト回数を見ます。1日の回数が多く、太平洋時間の午前0時を過ぎるとまた通るなら、RPDの可能性があります。次に、1分間のリクエスト回数と入力トークン量を見て、RPMかTPMのどちらに近いかを考えます。最後に、高コストなリクエストが続いていないかを見て、費用ベースの上限を疑います。これは編集部が公式の説明を手順に並べたもので、エラーの本文だけでどの上限か判別できるとは公式ページに書かれていません。

太平洋時間の午前0時は、日本時間に直すと、米国の夏時間の間は16時、冬時間の間は17時になる計算です。これは時差からの編集部の換算なので、リセット時刻の目安として使い、詳細は公式の表記を確認してください。

待って再試行する：指数バックオフとジッターの書き方

指数バックオフとは、再試行の待ち時間を1秒、2秒、4秒のように倍々に延ばしていく方法で、ジッターはその待ち時間にランダムな揺らぎを足して、複数のクライアントが同じ瞬間に再試行するのを防ぐ工夫です。

公式のTroubleshooting guideによると、公式のクライアントSDKは、タイムアウトやネットワークの問題、レート制限（429と5xx）のような一時的なエラーに対して、指数バックオフ付きの自動再試行を既定で備えています。Python SDKの例として、最大4回、最初の待ちは約1秒、最大の待ちは60秒と説明されています（2026年10月20日確認）。SDKを使っている場合は、まずその挙動を確かめ、自分で二重に再試行を重ねないようにします。

REST APIを直接呼ぶ場合や再試行を自作する場合について、同じガイドは次の方針を挙げています。

これを書き方の形にした、仮のコードを示します。公式のサンプルではなく、考え方を示すための編集部の例で、送信部分は自分の環境に置き換えます。

import random, time

def call_with_backoff(send, max_retries=5):
    for attempt in range(max_retries + 1):
        status, body = send()
        if status == 200:
            return body
        if status not in (429, 408) and not (500 <= status < 600):
            raise RuntimeError(f"retry しないエラー: {status}")
        if attempt == max_retries:
            raise RuntimeError("再試行の上限に達しました")
        wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)

このコードの待ち時間は、1回目が約1秒、2回目が約2秒、3回目が約4秒、4回目が約8秒、5回目が約16秒で、最大5回の再試行で合計約31秒（ジッターを除く）です。分単位の上限（RPM・TPM）なら、数十秒待てば枠が空く可能性がありますが、1日の上限（RPD）や費用ベースの上限では、待つ時間の見積もりが変わります。待つだけで解決しない場合は、次の節の見直しに進みます。

リクエストを小さくする・減らす：自分の側でできる見直し

リクエストを小さくする・減らすとは、再試行に頼らず、送る回数や1回あたりのトークン量、1回あたりの費用を下げて、上限に当たりにくくする見直しのことです。

公式のRate limitsは、費用ベースの上限に当たったときの対処として、少し待って再試行すること、高コストなリクエストの頻度を下げること（例：コンテキストウィンドウを小さくする、出力を短くする）、通常の利用でも当たるなら引き上げを申請することを挙げています（2026年10月20日確認）。この考え方は、RPMやTPMに当たる場合にも応用できます。ただし、公式がこの文脈で例に挙げているのは費用ベースの上限への対処なので、RPMやTPMへの効果は編集部の当てはめとして読んでください。

RPMに合わせて送信の間隔をあける場合は、60秒をRPMで割ると最短の間隔が出ます。公式の例と同じ仮の値でRPMが20なら、60÷20で3秒に1回のペースです。実際の上限値はAI Studioで確認した自分の値に置き換えてください。

TPMでは、1回あたりの入力トークンが多いほど、同じ上限でも送れる回数が減ります。次は仮の数字での計算です。TPMの上限が仮に100万、1回の入力が仮に5万トークンなら、1分に送れるのは100万÷5万で20回です。RPMが仮に60あっても、先にTPMで頭打ちになる計算です。これは実際の上限ではなく、2つの単位のどちらが先に効くかを確かめる方法の例です。

思考（thinking）の設定も、費用の見直しに使えます。公式のTroubleshooting guideには、Gemini 3.xのモデルは思考が既定で有効で、応答の遅延とトークン消費が増えること、遅延や費用を抑えたいなら思考のレベルを下げるか、オフにできることが書かれています。さらに、公式の料金ページでは、出力の単価に思考トークンが含まれると表記されています（2026年10月20日確認）。このため、思考を軽くすることは、費用ベースの上限への手段の一つになりうると考えられます。設定の詳細はGemini APIのThinkingの使い方を解説した記事にまとめています。

長い入力を繰り返し送る使い方では、コンテキストキャッシュも選択肢になります。ただし、キャッシュした入力がTPMなどの上限にどう数えられるかは、この記事で確認した公式ページには書かれていなかったため、ここでは扱いません。仕組みと料金はGemini APIのコンテキストキャッシュを解説した記事で説明しています。

Batch APIに回す：急がない処理は別の枠で流す

Batch APIとは、大量のリクエストを非同期で処理するGemini APIの機能で、標準の料金の50%で使え、完了までの目標は24時間とされており、通常のリクエストとは別のレート制限が適用されます。

公式のBatch APIのページ（2026年10月20日確認）には、データの前処理や評価の実行のように、すぐに結果が要らない大規模な処理向けと書かれています。リクエストの渡し方は、合計サイズが20MB未満の小さなバッチ向けのインラインと、大きなバッチ向けのJSON Lines形式のファイルの2つです。使い方の手順はGemini Batch APIの使い方を解説した記事で説明しています。

レート制限の面では、公式のRate limitsに、Batch APIの上限として、同時実行できるバッチリクエストが100、入力ファイルが2GB、ファイルストレージが20GBと書かれています。加えて、モデルごとに、すべてのアクティブなバッチジョブでキューに登録できるトークン数の上限があります。2026年10月20日に確認した、3つのモデルの値を抜き出します。

この表の値はBatch enqueued tokens（キューに登録できるトークン数）で、公式のRate limitsの表から取得日の値を写したものです。値は変わりうるため、使う前に公式の表で最新の値を確認してください。ほかのモデルの値も同じ表にあります。Tier 1で3,000,000のモデルを例に、仮に1件あたり3,000トークンと数えるなら、3,000,000÷3,000で1,000件分という見積もりになります。トークンの数え方の細部は同ページに説明が見当たらないため、実際の件数は小さく試して確かめます。

画像生成については、公式のBatch APIのページに、Nano Bananaで大量の画像を作る場合、Batch APIを使えば、最大24時間の納期と引き換えに、より高いレート制限が得られると書かれています。急がない大量処理は、リトライで耐えるより、最初からBatch APIに分ける設計が向いています。

ティアを上げる・上限の引き上げを申請する

ティアを上げるとは、請求先アカウントの設定と支払い実績によって、プロジェクトがより上位のティアへ自動で移ることを指し、移った段階で各モデルの上限が引き上がります。

公式のRate limitsによると、FreeからPaidのティアへ移るには、まずAI Studioで請求を設定します。2026年10月20日の確認時点で、条件を満たすと自動で次のティアにアップグレードされ、FreeからTier 1への移行は通常すぐに反映され、その後の移行は10分以内に反映されると書かれています。条件を満たしても、まれに審査で拒否されることがある、とも書かれています。

公式のRate limitsの条件の日数を使った、仮の計算です。初回の支払いが成功した日を仮に11月1日とすると、表の「3日」を単純に足した場合、Tier 2の条件のうち日数の条件を満たすのは11月4日以降、Tier 3の「30日」では12月1日以降になる計算です。金額の条件（$100、$1,000）も同時に満たす必要があり、日数の数え方の細部は同ページに説明が見当たらないため、実際の反映は余裕を見て、AI StudioのProjectsページで確認します。

ティアの条件を満たしても足りない場合は、引き上げを申請できます。同ページには、有料ティア向けの引き上げ申請の案内があり、増やすことは保証されないが、できる限り審査する、と書かれています。申請先は公式Rate limitsページの申請の節です。対処の選び方を、4つの対処で並べると次のとおりです。

よくある質問（FAQ）

Q1. APIキーを増やせば、レート制限は増えますか。

公式のRate limitsには、レート制限はAPIキーごとではなくプロジェクトごとに適用されると書かれています。同じプロジェクトでキーを増やしても、上限が増えるとは書かれていません。

Q2. 1日の上限（RPD）は、いつリセットされますか。

公式には、太平洋時間の午前0時にリセットされると書かれています。日本時間への換算は時期で変わるため、本文の換算の説明を参照してください。

Q3. モデルごとのRPMやTPMの具体的な値はどこで見られますか。

公式のRate limitsには、有効なレート制限はGoogle AI Studioで確認できると案内されています。この記事で確認した公式ページには、モデル別のRPM・TPMの一覧表は載っていませんでした。

Q4. 429が出たら、すぐ何度も再試行してよいですか。

公式は、待ち時間を延ばしていく指数バックオフとジッター、再試行の上限回数を勧めています。間をあけずに連打する方法は勧められていません。

Q5. Batch APIにすれば、レート制限を気にしなくてよいですか。

そうとは言えません。公式には、Batch APIにも同時実行数、ファイルサイズ、キューに登録できるトークン数の上限が別にあると書かれています。上限の値は本文の表と公式ページで確認してください。

Q6. ティアは、申し込めばすぐ上がりますか。

公式の条件を満たすと自動でアップグレードされ、FreeからTier 1は通常すぐ、その後は10分以内に反映されると書かれています。条件の詳細は本文の表を参照してください。

まとめ

Gemini APIのレート制限は、RPM・TPM・RPDの3つで測られ、プロジェクト単位でモデルとティアに応じて決まります。自分の上限はAI Studioで確認し、429 RESOURCE_EXHAUSTEDが出たら、どの上限に当たったかを考えたうえで、待って再試行する、リクエストを小さくする・減らす、Batch APIに回す、ティアを上げるの順に検討します。値は変わりうるため、設計の前に公式のRate limitsとAI Studioで最新の値を確かめてください。

Gemini APIの料金はGemini API料金の読み方の記事、コマンドラインから使う方法はGemini CLIの使い方の記事も合わせてどうぞ。