3行でいうと
- 上限は「回数」と「トークン量」など複数の物差しで測られ、どれか1つでも超えると429エラーになります。
- 再試行は、Retry-Afterを最小の待ち時間として守り、ランダムな揺らぎを足して、回数と合計時間に上限を付けます。
- 429でも、月の支出上限に達した場合は、待っても通りません。再試行してはいけないエラーを見分ける必要があります。
この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。数字は2026年10月22日に確認しました。上限は変わることがあります。
先に結論
- 429は「リクエストが多すぎる」という意味のHTTPエラー番号です。多くは一時的で、待って再試行すれば通ります。ただし、例外があります。月の支出上限に達した429は、翌月まで待っても同じです（Anthropicの文書）。
- 再試行は、闇雲に繰り返すと逆効果です。失敗したリクエストも1分あたりの上限に数えられる、とOpenAIの文書が明記しています。
- 設計では、上限そのものより「急に増やさない」ことが大事だと文書が書いています。OpenAIは、1分あたり100万入力トークンに達してからは、15分で50%以内の増加に抑えるよう目安を示しています。Anthropicも、急な増加は上限以下でも429になりうると書いています。
前提：何の話か
APIは、アプリの中からAIを呼び出す開発者向けの窓口です。トークンは、AIが読み書きする文字の量を数える単位です。レート制限は、短い時間にどれだけ使えるかの上限です。会社が全体の負荷を保ち、利用者が公平に使えるようにするためのものです。
測る物差しは、主に次のものです。
- RPM：1分あたりのリクエスト数。
- TPM：1分あたりのトークン数。AnthropicではITPM（入力）とOTPM（出力）に分かれます。
- RPD：1日あたりのリクエスト数（Googleで言及）。
どれか1つでも超えると、制限にかかります。OpenAIは「最初に達したものが効く」と書いています。
429エラーは、HTTPの「Too Many Requests」です。指数バックオフは、再試行の待ち時間を、1秒、2秒、4秒のように倍々に伸ばしていく方式です。ジッターは、その待ち時間にランダムな揺らぎを足すことで、多数のクライアントが同時に再試行して再び詰まるのを避ける工夫です。
3社の上限の考え方
| OpenAI | Anthropic（Claude） | Google（Gemini） | |
|---|---|---|---|
| 測る物差し | RPM、RPD、TPM、TPD、IPM（画像）など | RPM、ITPM、OTPM | RPM、入力TPM、RPD。一部にIPM、TPD |
| 適用の単位 | 組織とプロジェクト | 組織。ワークスペースごとにより低い上限を設定できる | プロジェクト（APIキー単位ではない） |
| 区分の名前 | Free、Build、Launch、Grow | Start、Build、Scale、Custom | Free、Tier 1、Tier 2、Tier 3 |
| 区分の上がり方 | クレジット購入の累計が基準を超えると自動 | 利用実績とアカウントの状態に基づき自動 | 累計の支払額と日数に基づき自動（審査で拒否されることもある） |
| 月の上限 | Free 100ドル、Build 500ドル、Launch 5,000ドル、Grow 20万ドル | Start 500ドル、Build 1,000ドル、Scale 20万ドル | 請求の上限（billing cap）が区分ごと。直近10分間の支出上限もある |
| 日次のリセット | 記載を読んでいません | 記載を読んでいません | RPDは太平洋時間の午前0時にリセット |
OpenAI
公式のレート制限の文書によると、次の通りです。
- 区分（ティア）：Freeは対象地域の利用者で月100ドル。Buildはクレジット購入の累計5ドルで月500ドル。Launchは累計100ドルで月5,000ドル。Growは累計500ドルで月20万ドル。購入額が基準に達すると自動で上がります。
- 標準の上限（RPM／TPM）：次のとおりです。
| 区分 | モデル | RPM | TPM |
|---|---|---|---|
| Build | Astra、Sol、Terra | 5,000 | 100万 |
| Build | Luna | 5,000 | 200万 |
| Launch | Astra、Sol、Terra | 10,000 | 400万 |
| Launch | Luna | 10,000 | 1,000万 |
| Grow | Astra、Sol、Terra | 15,000 | 4,000万 |
| Grow | Luna | 30,000 | 1億8,000万 |
- 上限は組織とプロジェクトの単位で、モデルごとに違います。モデルによっては上限を共有します。Free区分のRPM／TPMは、読んだ文書に書かれていませんでした。
max_tokensの影響：上限の計算には、max_tokensと、リクエストの長さに基づく見積もりの大きいほうが使われる、とあります。期待する出力の大きさに近い値にmax_tokensを設定するように、と書かれています。- バッチ：すぐに答えが要らない処理には、Batch APIを使うと、同期のリクエストの上限を使わない、と書かれています。
- ヘッダー（応答に付く情報）：
x-ratelimit-limit-requests、-remaining-requests、-reset-requests、トークンについても同じ3種、Retry-After。プロジェクト単位のトークン上限があるときは、専用のヘッダーも付きます。
Anthropic
公式のレート制限の文書によると、次の通りです。
- 区分：Start、Build、Scale、Customの4つ。評価用の区分から始まる新規の組織もあります。Customは数字が公開されず、アカウント担当と取り決めます。月の支出上限は、Startが500ドル、Buildが1,000ドル、Scaleが20万ドルです。
- 標準の上限：モデルごとに別枠です。
| 区分 | モデル | RPM | ITPM | OTPM |
|---|---|---|---|---|
| Build | Sonnet 5.5、Opus 5.5、Haiku 5.5 | 5,000 | 500万 | 100万 |
| Scale | Sonnet 5.5、Opus 5.5、Haiku 5.5 | 10,000 | 1,000万 | 200万 |
| Build | Fable 5.x | 2,000 | 150万 | 30万 |
| Scale | Fable 5.x | 4,000 | 400万 | 80万 |
Start区分の数字は、この記事では扱いません。Fable 5.xの上限は、Fable 5.1とFable 5を合算し、Mythos 5.1と5は別の合算枠、と脚注にあります。
- 単位：上限は組織の単位で、ワークスペース（組織内の区切り）ごとに、より低い上限を設定できます。未設定なら組織の上限と同じです。デフォルトのワークスペースには支出上限を設定できない、と書かれています。デフォルトのワークスペースにRPMなどの上限を設定できるかは、読んだ範囲では見つかりませんでした。組織全体の上限は、ワークスペースの合計が超えていても、常に効きます。
- 測り方：「トークンバケット」方式です。上限は、固定の時刻にリセットされるのではなく、連続的に回復します。60 RPMの上限は、1秒に1回として実施されることもあり、短い時間の集中でも上限に当たりえます。
- キャッシュと入力：ITPMに数えられるのは
input_tokensとcache_creation_input_tokensで、ほとんどのモデルでcache_read_input_tokensは数えられません（Haiku 3.5は例外）。文書の例では、ITPM上限が200万で、キャッシュのヒット率が80%なら、1分あたり約1,000万の入力トークンを処理できます。 - OTPM：実際に生成された出力トークンで、リアルタイムに数えます。
max_tokensは影響しません（OpenAIと違います）。 - バッチ：Message Batches APIには、別に上限があります（Startは処理待ち20万件、Buildは30万件、Scaleは50万件、1バッチ10万件）。
Google（Gemini）
公式のレート制限の文書によると、次の通りです。
- 測り方：RPM、入力TPM、RPDが基本。1つでも超えるとエラー。上限はプロジェクト単位で、APIキー単位ではありません。RPDは太平洋時間の午前0時にリセットされます。モデルによっては、IPM（画像）やTPD（1日あたりのトークン）も使われます。
- ティア：Freeは有効なプロジェクトか無料トライアル。Tier 1は請求アカウントの設定と連携で、請求の上限が250ドル。Tier 2は100ドルの支払いと最初の支払いから3日で、2,000ドル。Tier 3は1,000ドルの支払いと30日で、2万ドル〜10万ドル超。
- 直近10分間の支出上限：Tier 1は10ドル、Tier 2は50ドル、Tier 3は200ドル。超えると
429 RESOURCE_EXHAUSTEDになります。 - 自分の上限の見方：Google AI Studioのレート制限のページで確認する、と書かれています。この文書自体には、Gemini 3.8 Flashなどの具体的なRPM／TPM／RPDの数字は載っていません。載っているのはバッチ用の待ち行列のトークン数の上限だけでした。
- 429の対処：少し待って再試行、コンテキストを小さく、出力を短くして重いリクエストを減らす、通常の使用で上限に当たるなら引き上げを申請する（保証はない）、とあります。
再試行の作法
3社の文書を合わせると、次の考え方になります。
- Retry-Afterを守る：このヘッダー（秒数）があれば、それは最小の待ち時間です（OpenAI、Anthropic）。そのうえで、少しランダムな遅れを足す、とOpenAIは書いています。
- ヘッダーがなければ、指数バックオフ＋ジッター：OpenAIの文書の勧めです。待ち時間を倍々にし、揺らぎを足します。
- 回数と合計時間に上限を付ける：OpenAIの文書が、両方に上限を付けるよう書いています。
- 再試行してはいけないエラーを見分ける：クォータ、請求、その他、人の対応が要るエラーは再試行しません（OpenAI）。Anthropicの月間支出上限の429（
enforced_spend_limit_reached）は、retry-afterが付かず、翌月の1日の午前0時（UTC）まで、またはティアが上がるまで、再試行は失敗し続けます。SDKの自動再試行も同じです。 - 失敗した試行も数えられる：OpenAIの文書は、失敗したリクエストも1分あたりの上限に入るので、すぐに連続して再送しても役に立たない、と書いています。
- SDKの自動再試行と二重にしない：OpenAIの文書は、自前で再試行するなら、SDKの再試行を切るか、数に入れるように、と書いています。公式SDKは429と503を自動で再試行します。AnthropicのSDKは、既定で2回再試行し、
retry-afterを尊重し、max_retriesで設定または無効化できる、と書かれています。
429以外のエラー
- OpenAIの503（
server_is_overloaded）：モデルが一時的に過負荷。Retry-Afterがあればそれに従い、続くなら間隔をあける。 - Anthropicの529（
overloaded_error）：全利用者のトラフィックが多く、一時的に過負荷。500（api_error）は、指数バックオフで再試行し、続くならリクエストIDを添えて問い合わせる。504（timeout_error）はタイムアウト。 - Anthropicの400：組織やワークスペースで自分が設定した支出上限に達したときも、400（
invalid_request_error）で返ります（Claude Codeのワークスペースだけ429）。 - 長い処理：10分を超えるような長いリクエストには、ストリーミング（少しずつ返す方式）かバッチを使うよう勧められています（Anthropic）。
待ち時間の例と、同時実行の上限の見積もり（僕らの計算です）
僕らの計算です。公式の数字ではなく、考え方の例です。
待ち時間の例：最初の待ちを1秒、倍率を2、上限を5回とした指数バックオフは、待ち時間が1秒、2秒、4秒、8秒、16秒となり、合計は最大31秒です。ここにジッターを足します。Retry-Afterが20秒と返ったなら、その回は20秒以上待ちます。回数と合計時間の上限は、利用者の待てる時間（チャットなら数十秒、夜間処理ならもっと長い）で決めます。
同時実行の見積もり：1リクエストあたりの入力が4,000トークン、出力が500トークン、1リクエストの処理時間が20秒とします。Anthropic Buildの Sonnet 5.5（RPM 5,000、ITPM 500万、OTPM 100万）の場合、1分あたりに送れる件数は、RPMでは5,000件、ITPMでは500万÷4,000＝1,250件、OTPMでは100万÷500＝2,000件です。いちばん小さいITPMの1,250件が実質の上限になります。1リクエストが20秒かかるなら、同時に動かす本数は、1,250件×（20秒÷60秒）＝約417本が上の目安です。ただし、実際の入力トークンは、キャッシュのヒットで大きく変わります。Anthropicの文書では、キャッシュの読み取りはITPMに数えられないモデルが多いので、同じ前置きをキャッシュしているなら、上限はもっと余裕が出ます。
この見積もりは、トークンバケットの性質（短時間の集中でも当たる）を考えると、そのまま使い切る設計は危険です。余裕を持たせて、上限の7〜8割を目安にする、といった運用が無難だと思います（見立てです）。
選び方・判断の基準
見立てです。設計するときの順番は、次のようなものだと思います。
- まず自分の区分の上限を確かめる：OpenAIはプラットフォームの設定画面、AnthropicはClaude Consoleのレート制限のページ、GoogleはAI Studioで確認します。この記事の表は、文書に載っていた数字です。
- 急に増やさない：負荷試験や、大量処理の開始は、少しずつ増やす。OpenAIは100万入力TPMを超えたら15分で50%以内、と目安を書いています。
- 処理をキューにためて、一定の速さで流す：トークンバケットで測られるため、短時間の集中を避ける設計に向きます。
- 待てる処理はバッチへ：同期の上限を使わず、半額です（別記事「バッチAPI」を参照）。
- キャッシュで入力を減らす：Anthropicでは、キャッシュの読み取りが上限に数えられないモデルが多いです。
max_tokensを適切に：OpenAIでは上限の見積もりに効きます。
よくある失敗・つまずき
- 429を全部「待てば通る」と思って、無限に再試行する。回数と時間に上限を付けます。
- 支出上限の429を再試行し続ける（Anthropic）。
retry-afterが付かないのが目印です。 - 自前の再試行とSDKの再試行を重ねて、リクエストを何倍にもしてしまう。
- 一斉に起動して一斉に失敗し、全員が同じ秒数後に再試行する。ジッターを入れます。
- 負荷を急に上げる。上限以下でも、
slow_down（OpenAI）や加速制限（Anthropic）で429になります。 - ストリームの途中のエラーを、普通の再試行に任せる。Anthropicの文書は、200の応答のあとでストリームの途中に起きたエラーは、標準の仕組みに従わない、と書いています。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。数字と挙動は公式文書の記載です。
- 上限の数字は、区分、モデル、組織の状態で変わります。この記事の表は、文書に載っていたものの一部です。自分のアカウントの実際の上限は、各社の管理画面で確認してください。
- GoogleのGeminiのRPM／TPM／RPDの具体的な数字は、読んだ文書には載っておらず、確認できていません。
- OpenAIのFree区分のRPM／TPM、バッチの待ち行列の具体的な数字は、確認できていません（設定画面で見る、と書かれています）。
- OpenAIの文書では、モデルによって上限を共有することがあります。表のモデルは、読んだ表に出ていた名前のとおりです。
- Anthropicの上限は、モデルごとに別枠のものと、合算のものがあります（Fable 5.xなど）。脚注を確認してください。
- 429以外のエラーの扱いは、各社の文書のうち、読んだ範囲のものだけを書きました。Googleの429以外のエラーは扱っていません。
- 上限、区分の条件、エラーの種類は、変わることがあります。
出典
- Rate limits（OpenAI API、OpenAI、2026年10月22日確認）
- Rate limits（Claude Platform Docs、Anthropic、2026年10月22日確認）
- Errors（Claude Platform Docs、Anthropic、2026年10月22日確認）
- Rate limits（Gemini API、Google AI for Developers、Google、2026年10月22日確認）
更新履歴
-
2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
-
2026年10月22日 公式の資料を読み直して、次の点を直しました。
- 前：デフォルトのワークスペースには（上限を）設定できない → いま：設定できないのは支出上限。RPMなどの上限は、読んだ範囲では見つかっていない
- 前：ワークスペースの上限の初期値は書いていなかった → いま：未設定なら組織の上限と同じ