LLM API のレート制限・利用ティア・クォータ実践ガイド
公開日 2026-08-02 · 更新日 2026-09-27
トークン単価だけでは、実運用に必要な処理能力は判断できません。コストを見積もったうえで、ピーク時のリクエスト数やトークン数を、現在のアカウントに適用されているレート制限と照合する必要があります。このページでは、料金と処理能力を分けて確認する方法を整理します。
レート制限・適用単位・利用ティア・料金を分けて考える
API では複数の制限が同時に適用されます。代表的なものは、1 分あたりのリクエスト数（RPM）、1 分あたりのトークン数（TPM）、1 日あたりのリクエスト数（RPD）です。該当する制限のうち、どれか 1 つでも上限に達すると 429 エラーになることがあります。
- レート制限の軸：RPM、入力 TPM、出力 TPM など、何を上限として測るか。
- 制限の適用単位：組織、プロジェクト、ワークスペース、モデルグループなど、どの範囲で上限を共有するか。
- 利用ティア：利用実績や支払い状況などに応じて、利用可能な上限が変わる区分。
- 料金・処理オプション：バッチ処理や優先処理など、通常の利用ティアとは別に料金や制限が定義される仕組み。
通常の利用ティアが上がるとレート制限が緩和されることはありますが、それだけで標準のトークン単価が変わるとは限りません。料金と処理能力は別々に確認するのが安全です。
OpenAI：組織・プロジェクト単位とモデル別上限を確認する
OpenAI は RPM、RPD、TPM、TPD、画像数/分、音声系の制限など複数の軸を文書化しています。制限は組織単位・プロジェクト単位で設定され、モデルによって異なります。複数モデルが同じ制限プールを共有する場合もあります。
API の利用額が増えると利用ティアが上がり、多くのモデルでレート制限が引き上げられる仕組みです。実運用では固定表をコードに埋め込まず、アカウントの Limits 画面と API のレート制限ヘッダーで現在値を確認するのが確実です。
2026-09-27 確認： OpenAI のレート制限ドキュメント
Anthropic：RPM・入力 TPM・出力 TPM を別々に見る
Anthropic の Messages API では、1 分あたりのリクエスト数（RPM）、入力トークン数（ITPM）、出力トークン数（OTPM）が別々に管理されます。サービス側の制限は組織単位で適用され、必要に応じてワークスペースへより低い上限を設定できます。短時間の急増では、1 分平均が上限未満でも制限に達する場合があります。
多くの Claude モデルでは入力トークンの制限がキャッシュを考慮して計算されるため、キャッシュ済み入力と未キャッシュ入力の扱いが同一とは限りません。現在の設定値は Claude Console で確認でき、組織向け Admin API を利用できる場合は Rate Limits API から取得できます。変化しやすい数値を記事やアプリへ固定値として埋め込むより安全です。
2026-09-27 確認： Anthropic のレート制限 ／ Rate Limits API
Gemini API：API キーではなくプロジェクト単位で考える
Gemini API では、RPM、入力 TPM、RPD などが代表的な制限です。これらは API キーごとではなくプロジェクトごとに適用され、モデルやプロジェクトの利用ティアによって現在値が変わります。
Google は、現在のレート制限を AI Studio で確認するよう案内しており、公開されている上限値も処理能力を保証するものではないとしています。また、RPM・TPM・RPDとは別に支出ベースのレート制限もあります。Vertex AI には別のクォータ体系があるため、Gemini API の上限をそのまま Vertex AI の容量計画へ流用しないでください。
2026-09-27 確認： Gemini API のレート制限
ピーク負荷を RPM と TPM に換算する
月間平均ではなく、最も混雑する 1 分間を基準にすると、必要な処理能力を概算できます。
| 確認項目 | 計算方法 | 照合する上限 |
|---|---|---|
| ピークリクエスト数 | ピーク RPM = 最も混雑する 1 分間のリクエスト数 | 対象モデル・プロジェクトの RPM |
| 入力トークン | 概算入力 TPM = ピーク RPM × 1 リクエストあたりの平均入力トークン数 | 入力 TPM または TPM |
| 出力トークン | 概算出力 TPM = ピーク RPM × 1 リクエストあたりの平均出力トークン数 | 出力 TPM または TPM |
例えば、最も混雑する 1 分間に 120 リクエスト、1 リクエストあたり平均 2,000 入力トークン・400 出力トークンなら、約 240,000 入力トークン/分、48,000 出力トークン/分が必要です。関連する制限をすべて比較し、最初に上限へ達する軸を確認します。
この計算は一次判定用です。瞬間的なバースト、急激なトラフィック増加に対する制限、同時実行数、共有モデルプール、モダリティ固有の制限などは別に影響します。
レート制限とコスト計画を分けて確認する
- 料金を見積もる：コスト計算機で、トークン量やリクエスト構成から月額コストを概算します。
- ピーク処理能力を確認する：最も混雑する 1 分間を RPM とトークン/分へ換算し、現在のプロジェクトや組織の上限と比較します。
- ボトルネックを特定する：RPM、入力 TPM、出力 TPM などのうち、どれが最初に上限へ達するかを確認します。
API キーを増やせば容量も増える、と一般化するのは危険です。OpenAI と Gemini は個別キーより上位の単位で制限され、Anthropic も組織単位のサービス制限を適用します。対象プロバイダーが明示している方法で上限を引き上げるか、処理を分散してください。
レート制限に対処する主な方法
| 方法 | 向いている場面 | 確認点・トレードオフ |
|---|---|---|
| キュー + 指数バックオフ | アクセス集中や一時的な 429 | 遅延が増える。プロバイダーの retry 指示やヘッダーを優先する |
| トラフィックを段階的に増やす | 本番負荷を急に増やす場合 | バーストや急増時の制限を避けやすいが、流量制御が必要 |
| バッチ・非同期処理 | 即時応答が不要な処理 | 通常リクエストとは別の制限・料金体系になる場合がある |
| プロンプトキャッシュ | 長い共通プロンプトや文脈を繰り返す処理 | レート制限上のトークン計算が変わる場合があるためモデル別仕様を確認する |
| 上限引き上げを申請 | 継続的な正規トラフィックが現在上限に近い場合 | 審査、利用実績、支払い条件などが必要な場合がある |
| モデルルーティング | 品質要件を満たす別モデルに独立した容量がある場合 | 品質・料金が変わる。共有レート制限なら期待した余力は得られない |
料金データはカタログから取得しています。出典と鮮度はデータソースをご確認ください。
まずここから
コスト計算機で月間ボリュームを概算し、対象プロバイダーのレート制限ドキュメントを確認してください。制限に引っかかる場合は、バッチ処理やモデルルーティングを検討してください。