LLM API レート制限を5社比較（2026）：5社5様のルールブック

要約。 LLM API のレート制限に順位を付けられる表は存在しません。最大手5社が測っているものが同じではないからです。Anthropic は毎分のリクエスト数・入力トークン数・出力トークン数を同時に制限し、キャッシュ読み取りは計上しません。Moonshot と OpenAI は支払額に応じて天井を上げます。DeepSeek は毎分の速度を完全に無視し、同時に実行できるリクエスト数だけを制限します。Google と OpenAI はモデル別の数値を公開ドキュメントから外してダッシュボードに移しました。有用な問いは「誰の RPM が一番高いか」ではなく、どの制限設計が自分のアプリの実際の呼び出し方と噛み合うか、そして最初に当たるものをどう迂回するかです。

レート制限は順位付けできる単一の数値ではない。Anthropic は毎分のトークンを数え、DeepSeek は実行中のリクエストを数え、OpenAI はあなたがいくら払ったかを数える。それらを一列に並べるのはカテゴリの誤りだ。

まずどの制限がどの種類の負荷に先に当たるかを示します。自分に当てはまる節へ飛んでください。

誰もが欲しがるあの表（と、それが揃わない理由）

「レート制限比較」の記事はどれも、一列を見渡して勝者を選べるグリッドを約束します。そのグリッドは触れた瞬間に崩れます。制限とは何かという点で5社の見解が一致していないからです。以下が正直な版です。同じ5列に「列が噛み合わない」という事実を詰めたものです。

どの行を横に読んでも形が変わります。3社はモデル別の正確な数値を示し、2社は示しません。2社はトークンで制限し、1社は実行中リクエストで制限し、2社は主にアカウントに動かした金額で制限します。この噛み合わなさこそが本当の発見であり、以下は自分が 429 を食らう側になったとき各セルが何を意味するかの解説です。

以下の数値はすべて 2026-07-22 に各社の公式レート制限ドキュメントから取得したものです。モデル別数値の公表をやめたベンダーについては、推測せずそう明記します。

Anthropic：3つの軸、そしてキャッシュ読み取りは無料

Anthropic は5社で最も透明で、最も多次元です。すべてのモデル区分が同時に3つの軸で制限されます。毎分リクエスト数（RPM）、毎分入力トークン数（ITPM）、毎分出力トークン数（OTPM）。どれか1つでも超えると 429 が返り、retry-after ヘッダが待つべき秒数を正確に伝えます。バケットは連続的に補充される（トークンバケット）ので、固定のリセット時刻を待つわけではありません。

階層は Start、Build、Scale、Custom。階層を直接購入することはできず、利用履歴とアカウントの状態に基づいて自動的に上がります。各階層に月間支出上限が付きます。

Anthropic が実際に詳細を公開しているのはモデル別の数値です。Claude Opus 4.x は 4.8、4.7、4.6、4.5 が1つのバケットを共有します。

最も特筆すべき点、そして Anthropic の天井が見た目より高い理由が、キャッシュを考慮した ITPM の規則です。多くの Claude モデルで cache_read_input_tokens は ITPM に計上されません。キャッシュへの書き込みと通常の入力トークンは計上されますが、キャッシュから読み戻したトークンはレート制限の対象外です。Anthropic 自身の計算例では、200 万 ITPM の制限でキャッシュヒット率 80% なら、毎分およそ 1000 万の入力トークンを流せます。800 万のキャッシュ済みトークンが制限に登録されないからです。Claude Haiku 3.5 だけが例外で、キャッシュ読み取りも計上されます。

入力の大きな部分が安定した system prompt や毎回送る長文書であるなら、この規則は階層を1つ上げるより実効スループットへの影響が大きくなります。金額側は DeepSeek のプロンプトキャッシュ設定 で計算しました。レート制限側は同じレバーを請求額ではなくスループットに向けたものです。

チームが不意を突かれやすい脚注が2つ。Message Batches API には独自の制限があり、Managed Agents にもあります（create 系エンドポイント 300 RPM、read 系 1,200 RPM）。バッチのトラフィックで壁に当たっても、Messages API の枠を使い切ったことにはなりません。

Moonshot / Kimi：支払って登る、4次元同時に

Moonshot はこの中で最も明快な「支払って階層を上げる」方式です。階層は累計チャージ額だけで決まり、$1 から $3,000 まで、各階層が4つのつまみ（同時実行数、RPM、TPM、日次トークン数 TPD）を同時に動かします。

国際版プラットフォーム（platform.kimi.ai）の階層、ドル建て：

これらの数値を他所と突き合わせる前に知っておくべき罠があります。Moonshot は2つの独立したプラットフォームで2つの独立した階層を運用しています。 国際版（platform.kimi.ai、platform.moonshot.ai からも到達）はドルで計量し、呼び出し開始前に $1 のチャージを要求します。中国本土版（platform.moonshot.cn）は独自の人民元階層を持ち、¥0 から始まって ¥50 / ¥100 / ¥500 / ¥5,000 / ¥20,000 と進みます。両者は互いの為替換算ではなく、参入条件も異なります。片方は最初の支払いを課し、もう片方は課しません。階層を前提にする前に、自分の key がどちらのものか確認してください。

Tier 0 から Tier 1 への跳躍が注目に値します。追加 $9 で、3 RPM・同時実行1本から 200 RPM・同時実行 50 本になり、日次トークン上限も丸ごと消えます。Tier 0 は実質「本物であることを証明する」ための床であって、何かを構築する場所ではありません。

階層表に書かれていないことがひとつ。個々のモデルは階層とは別に容量の制約を受けることがあります。Kimi K3 のような公開直後のモデルは、階層の制限に遠く及ばない状態でも上流の容量から 429 を返すことがあります。制約はあなたのアカウントの速度ではなく、そのモデルに対するプロバイダ全体の余力だからです。この場合は上位階層を買っても解決せず、対処は別モデルへのフォールバック、つまり後述のルーティングパターンです。

DeepSeek：RPM は一切なし、同時実行のみ

DeepSeek はすべての比較グリッドを壊す例外です。RPM も TPM も公表せず、アカウント単位で同時実行数、つまり同時に実行できるリクエスト数を制限します。

上限を超えない限り、モデルが返す速さでリクエストを投げられます。超えると 429。毎分の予算に合わせてペース配分する必要がなく、並列負荷にとっては明確に推論しやすい設計です。ワーカープールを同時実行上限に合わせて決めれば、毎分トークンを気にしなくてよくなります。

DeepSeek は過負荷の扱いも異なります。サーバーが混んでいるときリクエストを拒否せず接続を保ち、非ストリーミングでは空行を、ストリーミングでは SSE の : keep-alive コメントを送り、10 分経っても推論が始まらない場合にのみ接続を閉じます。枠を拡張したアカウントは user_id パラメータでエンドユーザーごとに同時実行を分離できます。1つの key で多数の顧客を多重化しているなら重要です。エージェントループでの費用面は DeepSeek V4 Flash のゼロコスト経路 で扱っています。

OpenAI：支出で階層、数値はガラスの向こう

OpenAI は依然として累計支払額で階層を分け、6段階あります。

次元は広く、RPM、RPD、TPM、TPD、毎分画像数、一部のストリーミングモデルでは毎分音声分数まであります。制限内にいるときはレスポンスに x-ratelimit-limit-requests、x-ratelimit-remaining-requests とトークン版が付き、余力をリアルタイムで見られます。

そしてグリッドを壊す点がこれです。OpenAI のレート制限ドキュメントは、もはやモデルごとの具体的な RPM や TPM を載せていません。実際の数値はモデルページかアカウントのダッシュボードを見よ、と案内されます。これは文句を言うべき見落としではなく、それ自体がデータ点です。OpenAI はモデル別のレート制限が十分頻繁に変わるため静的な表が誤解を招くと判断し、数値をアカウントと階層に紐づいたダッシュボードに置いたのです。OpenAI のモデル別 RPM を固定値のように印刷している記事は、すでに古いかもしれないスナップショットを引用しています。

Google Gemini：階層、時間ゲート、10 分の支出ウィンドウ

Gemini の階層は課金状態・支出額・経過時間を組み合わせます。

3日・30日という要件は珍しく、金額を払っても待機期間を飛ばして Tier 2 や Tier 3 に到達することはできません。Gemini はさらに通常の RPM / TPM / RPD の上に支出ベースの制御を重ね、ローリング 10 分ウィンドウごとに適用します（Tier 1 は $10、Tier 2 と 3 は $200）。毎分のトークン速度に問題がなくても、支出の急増だけで絞られ得ます。超過すると 429 RESOURCE_EXHAUSTED が返ります。

OpenAI と同様、Gemini もモデル別の RPM / TPM / RPD を静的ドキュメントから外し、AI Studio 内で現在有効な制限を見る形にしています。またこのページは Gemini Developer API のみが対象で、Vertex AI は別のクォータ体系で動いています。

単位が揃わない理由（誰も表にしない部分）

一歩下がると、この非互換性そのものが本題だと分かります。以下は各社で余力1単位が実際に何を買うか、そしてその単位がどこで詰まるかです。

小さな分類呼び出しを数千回送るチームは最初に RPM に当たり、ITPM などまったく気にしません。20 万トークンの文書を毎リクエストに貼り付けるチームは、RPM がほぼゼロのまま毎分トークンの壁に当たります。50 本の並列エージェントを走らせるチームは同時実行に当たります。この3チームは同じ「レート制限が最良」という推奨を共有できません。3つの異なる単位に制約されていて、単一のランキングが3者すべてに役立つことはあり得ないからです。

具体例で罠をはっきりさせます。50 のワーカーがそれぞれ 3 万トークンの RAG リクエストを送るとします。DeepSeek の deepseek-v4-pro では 500 の同時実行上限に対して 50 本なので、余力は10倍あり 429 は見ません。まったく同じ負荷を毎分 200 万入力トークン制限のベンダーに移すと、その 50 本が同じ1分に着地した場合、1回のバーストで 150 万入力トークン、さらに他のトラフィックが乗ります。DeepSeek では追跡すらしていなかった制限の 75% に突然到達し、少しトラフィックが増えれば越えます。同じ同時実行数、同じリクエストサイズ、まったく違う壁です。

これがベンダー移行で人が驚く理由です。見ていなかった制限が噛みつく制限になり、何か月も問題なく動いていたコードパスが、プロバイダを切り替えた日に 429 を投げ始めます。

どの制限が最初に噛みつくか（判断フレーム）

階層を上げたり何かを再設計したりする前に、実際に当たっている壁がどれかを突き止めてください。

• 単に階層を上げてよいとき。 429 が単一の軸（たとえば RPM）に集中していて、低い階層にいて、次の階層の天井がピークを余裕をもって上回る。支払うのが最も安い解決です。階層が支出のつまみである Moonshot と OpenAI ではこれが一般的なケースです。
• 階層を上げずキャッシュすべきとき。 Anthropic で ITPM に当たっていて、入力の大きな部分が呼び出し間で繰り返される。プロンプトキャッシュを有効にすると階層を変えずに実効スループットが上がります。キャッシュ読み取りは ITPM に計上されないからです。上限緩和を申請する前にこちらを試してください。
• 迂回すべきとき。 その制限がその負荷にとって構造的である場合（飽和させ続けている同時実行上限、あるいはどの階層でも直らない上流容量由来の 429）。対処は別プロバイダの同等モデルへのフェイルオーバーで、絞りがエラーではなく1ホップに縮退します。Claude Code のレート制限エラー対処 や 日本企業向け AI ゲートウェイ が役に立つのはここです。
• やめてよい条件。 429 の比率が約 1% 未満で、1回のリトライで解消するなら、レート制限の問題ではなく通常のバーストノイズです。ジッタ付きバックオフを入れて先へ進んでください。ほとんど触れていない壁のために再設計しないこと。

429 の読み方（どの壁に当たったか）

429 は自明ではなく、どの壁に当たったかを各社は違うやり方で伝えます。リトライの前にレスポンスを読めば、実際には破っていない制限を待ち続けずに済みます。

実務上の分かれ目は「待つ」制限と「減速する」制限の間にあります。Anthropic、OpenAI、Google は毎分の予算を与えるので、retry-after や残量ヘッダがゼロ近辺なら数秒バックオフすればバケットが補充されます。DeepSeek の同時実行上限は「減速する」制限です。同じ本数を実行中に保ったまま待っても何も起きません。壁は時間ではなく並列度だからです。ワーカープールを縮めずに同時実行の 429 をリトライしても、同じ壁に再度当たるだけです。この区別を誤ると、バックオフ処理は負荷を落とすべきときに眠るか、1秒待てば済むときに負荷を落とします。

ひとつのエンドポイント、5つのルールブック

Anthropic の ITPM や DeepSeek の同時実行上限を消すことはできません。できるのは、どれか1社の制限を単一障害点にしないことです。5社がそれぞれ違う規則を強制するなら、実務的な防御は全部をひとつのエンドポイントの後ろに置き、絞られたリクエストを自動で別ベンダーへ回すことです。ofox のようなゲートウェイはそれらを1つの OpenAI 互換 API と1つの key で公開するので、「A 社の制限に当たった」が失敗ではなく「B 社が答えた」になります。

パターンは短い「リトライしてから跳ぶ」ループです。どのベンダーからの 429 でもジッタ付きリトライを数回行い、その後クロスベンダーのチェーンの次のモデルへ切り替えます。

import time, random, openai

CHAIN = [
    "anthropic/claude-opus-4.8",
    "deepseek/deepseek-v4-pro",
    "moonshotai/kimi-k3",
]

def ask(prompt, retries=2):
    for model in CHAIN:
        for attempt in range(retries):
            try:
                r = client.chat.completions.create(
                    model=model,
                    messages=[{"role": "user", "content": prompt}])
                return model, r.choices[0].message.content
            except openai.RateLimitError:
                time.sleep((2 ** attempt) + random.random())
        # このベンダーで絞られ続けるなら次へ
    raise RuntimeError("チェーン上のすべてのプロバイダが絞られている")

どのモデルが答えたかを結果と一緒に返してください。後であるバッチだけ傾向が違う理由を調べるとき、各応答の出所が分かっていると時間を大きく節約できます。

境界を明確にしておくと、ゲートウェイはどの社の天井も上げません。変えるのは壁に当たった後に何が起きるかです。トラフィックのすべてを1社に寄せていて、その軸を継続的に飽和させているなら、必要なのは上位階層かトラフィック削減であって、ゲートウェイではありません。

本記事で確認した出典

• Anthropic API レート制限（2026-07-22 確認）
• OpenAI レート制限ガイド（2026-07-22 確認）
• DeepSeek レート制限（2026-07-22 確認）
• Google Gemini API レート制限（2026-07-22 確認）
• Moonshot / Kimi レート制限、国際版（2026-07-22 確認）
• Moonshot / Kimi レート制限のアーカイブ版
• Moonshot 中国本土版レート制限、人民元階層（2026-07-23 確認）