429 Too Many Requests: 意味と再試行のタイミング (2026)

TL;DR

Status code:       HTTP 429 (Too Many Requests)
Anthropic:         error.type = rate_limit_error, plus a retry-after header
OpenAI:            rate-limit 429 and spend/credit 429 share the code; read error.code
Google Gemini:     429 RESOURCE_EXHAUSTED, no retry hint documented
OpenRouter:        429 raised by OpenRouter, or relayed from the upstream provider
First thing to do: read retry-after, wait that long, retry once
No header:         back off 1s, 2s, 4s with jitter, cap at 5 attempts
Never retry:       credit/spend-cap 429s, they do not clear on their own

ステータスコード単体では、ほとんど何もわかりません。エラーボディとレスポンスヘッダーが、あなたが5種類のどの問題に直面しているのかを教えてくれます。そして5つのうち2つは、待っても解決しません。

「429 Too Many Requests」とは何を意味するのか?

認証情報は受理されたのにリクエストが拒否された、という意味です。現時点で許可されている量を超えてアカウントが要求したためです。 文言はベンダーによって異なります(「Rate limit reached for requests」「rate limit exceeded」「RESOURCE_EXHAUSTED」)が、ステータスコードは変わりません。

429ではない3つのもの:

• 認証失敗。不正または失効したキーは401、リソースへのアクセス権のないキーは403です。
• 障害。Anthropicは全ユーザーに影響する「the API is temporarily overloaded」(APIが一時的に過負荷)には529 overloaded_error を使い、あなた自身の制限とは別扱いにしています。
• 必ずしもあなたのトラフィックの話とは限らない。ルーター経由では、429が上流プロバイダー側のものであなたに中継されている場合があります。

ウィンドウは通常1分ですが、時計上の1分ではありません。Anthropicは自社のリミッターをトークンバケットとして文書化しています。「your capacity is continuously replenished up to your maximum limit, rather than being reset at fixed intervals.」(容量は固定間隔でリセットされるのではなく、上限まで連続的に補充される)。

レート制限超過エラーは自分のせい? それともプロバイダーのせい?

多くの場合、どちらでもありません。これはあなたのアカウントに関するポリシー判断であり、同じステータスコードを生む明確に異なる5つのポリシーが存在します。

OpenAIはこの区別を明言しています。Retry-After は「does not mean that quota, billing, or other errors that require user action can be resolved by retrying.」(クォータ、課金、その他ユーザーの対応が必要なエラーが再試行で解決できるという意味ではない)。すべての429を同じように扱う再試行ループは、アラートが気づくまで枯渇したクレジット残高を延々と叩き続けることになります。

最後の行が、最も頻繁に誤診されるものです。ローンチで制約されたモデルは、あなたのティアに関係なく429を返すため、そのルートでいくらバックオフしても効果はありません。これはまさにOpenRouter Kimi K3 429問題の形そのものです。

どのヘッダーで再試行のタイミングがわかるのか?

retry-after を読んでください。これはサーバーが直接あなたに伝えている唯一の値であり、他のヘッダーはすべて文脈情報です。 残りのヘッダーセットはベンダーによって異なり、リセット値の形式も違います。

この表には2つの罠があります。

• リセット値の型はベンダー間で同じではありません。 Anthropicは時計と比較するタイムスタンプを返します。OpenAIは間隔としてパースするGo形式の継続時間を返します。一方の形を前提としたコードは、もう一方に対して静かにゴミを生成します。
• Anthropicは残りトークン数を最も近い1000単位に丸めます。 そのため anthropic-ratelimit-input-tokens-remaining を正確な値として扱うと、小さなリクエストでは過大評価します。

ヘッダーの存在も保証されていません。これはゲートウェイで特に重要です。2026-08-10に1つのOpenAI互換エンドポイント経由でfour models(4つのモデル)をテストしたところ、two routes(2つのルート)は完全な x-ratelimit-limit-requests / -limit-tokens / -remaining-* / -reset-* のセット(加えて非標準の x-ratelimit-renewalperiod-requests: 60)を返し、two routes(2つのルート)はレート制限ヘッダーを一切返しませんでした。ヘッダーセットは、あなたが呼び出したエンドポイントではなく、そのモデルを提供する側に属します。ヘッダーが欠けていたら例外を投げるのではなくバックオフに切り替えるよう、パーサーを書いてください。

429の後、どれだけ待つべきか?

retry-after が言う時間だけ待ちます。ヘッダーがなければ、ジッター付きで1s、2s、4s、上限は五(five)回まで。 固定スリープは誤った答えです。並列で動くすべてのワーカーが同じ瞬間に目を覚まし、同じ制限を再び踏むからです。

ジッターは人々が省きがちな部分ですが、20 workers(20のワーカー)が同時に壁に当たったときに効いてくるのはまさにこの部分です。

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.ofox.ai/v1")

def call_with_backoff(**kwargs):
    for attempt in range(5):
        try:
            return client.chat.completions.create(**kwargs)
        except RateLimitError as e:
            # the SDK unwraps the envelope, so e.body is the inner "error" object
            code = e.body.get("code") if isinstance(e.body, dict) else None
            if code in {"credit_balance_exhausted", "organization_spend_limit_exceeded"}:
                raise  # a spend cap does not clear by waiting
            retry_after = e.response.headers.get("retry-after")
            delay = float(retry_after) if retry_after else random.uniform(0, 2 ** attempt)
            time.sleep(delay)
    raise RuntimeError("still rate limited after 5 attempts")

そのループを書く前に、SDKがすでにやってくれていないか確認してください。インストール済みの openai 2.53.0 クライアントを読むと、DEFAULT_MAX_RETRIES is 2 で、再試行パスはまず retry-after-ms を、次に retry-after(秒、またはHTTP日付)をパースし、サーバー指定の遅延を120 secondsまで尊重し、それより長い指定の場合は一切再試行を拒否します。ヘッダーがない場合は 0.5 * 2^n でバックオフし、8 secondsを上限とし、0.75 から 1.0 の間のジッター係数を掛けます。AnthropicのSDKもデフォルトで一時的な失敗を2回再試行し、retry-after を尊重します。つまりデフォルト設定では、あなたのコードに現れる429はすでにthree times(3回)失敗しており、試行の間隔はhalf a second(約半秒)とone second(1秒)しかなく、1分間のウィンドウには程遠いのです。max_retries を上げるか、ループを自分で管理してください。既存の再試行層の上に2つ目の再試行層を重ねてはいけません。

RPM、TPM、ITPM、OTPMは実際に何を数えているのか?

ベンダーごとに計測するものが異なり、その単位によってどのつまみが効くかが決まります。

• RPM は呼び出し回数を数え、サイズは数えません。これを繰り返し踏むなら、1回の呼び出しにもっと多くの処理を詰め込みましょう。
• TPM は入力と出力を合わせた1つの予算です。OpenAIは一部のモデルで、その上に RPD、TPD、IPM(毎分あたりの画像数)を重ねています。
• ITPM と OTPM は、Anthropicがその予算を分割したもので、モデルクラスごとに強制されます。そのため、ロングコンテキストのワークロードとロングアウトプットのワークロードは、別々の壁に当たります。
• キャッシュ読み取りは興味深い例外です。ほとんどのClaudeモデルでは cache_read_input_tokens は ITPM にカウントされず、cache_creation_input_tokens はカウントされます。Anthropic自身の例: 2,000,000 ITPM の制限で 80% のキャッシュヒット率なら、毎分約 10,000,000 の合計入力トークンを処理できます。
• max_tokens は OTPM に影響しません。OTPMは実際に生成されたトークンで評価されるからです。上限を大きく設定してもレート制限の面では何のコストもかかりません。
• 同時実行数の制限はまた別物です。一部のプロバイダーは毎分あたりのレートではなく処理中のリクエスト数に上限を設けており、5ベンダーのレート制限比較にティアごとの数値があります。

トラフィックをほとんど送っていないのに429が出るのはなぜ?

毎分あたりの制限が毎分単位で強制されることはめったになく、バケットがあなただけのものであることもめったにないからです。 よくある容疑者:

• 分未満での強制。Anthropicのドキュメントは明言しています。「a rate of 60 requests per minute (RPM) might be enforced as 1 request per second. Short bursts of requests can exceed the limit and trigger rate limit errors.」(60 requests per minute (RPM)のレートは 1 request per second として強制されることがある。短いバーストが制限を超えてレート制限エラーを引き起こす)。
• 組織全体で1つのバケット。制限はキーごとではなく組織レベルにあります。そのため、per-workspace(ワークスペースごと)の制限を設定しない限り、すべてのサービス、ノートブック、CIジョブが同じプールから引き出します。
• ファンアウト。並列エージェントは同時リクエストを倍増させ、それぞれがフルコンテキストを持ち運ぶため、ITPMが先に尽きます。
• 加速制限。使用量の急増は、明示された制限内であっても429を引き起こすことがあります。
• 無料枠の1日上限。1日50リクエストの枠は、午後のデバッグ1回で消え去ります。
• 実は課金系の429。トラフィックがゼロなのに429が出る場合、通常はスループットではなく支出上限や残高枯渇を意味します。

自分のコードではなくコーディングエージェント内でこれが起きている場合、仕組みは同じですがつまみが異なります。Claude Codeレート制限の解説で同時実行の設定を扱っています。

429は529やRESOURCE_EXHAUSTEDと同じか?

いいえ。429はあなたのアカウントの話、529と503はプロバイダーの話、RESOURCE_EXHAUSTED はGoogleにおける429の呼び名です。

この区別はログに組み込む価値があります。「429 + 529」を1つの数値として数えるダッシュボードでは、上位ティアを買うべきかフォールバックルートを追加すべきかを判断できません。容量の話をより深く知りたい場合は、Claude API 529 過負荷ガイドを参照してください。

429をもらわないようにするには?

軽減効果あたりの労力が少ない順に、おおまかに並べると:

• retry-after を尊重し、ない場合はジッターを加える。無料で、自業自得の部分を直せます。
• クライアント側の同時実行数を制限する。ワーカープールを囲むセマフォは、どんな再試行ポリシーよりも信頼できるリミッターです。反応するのではなくバーストを未然に防ぐからです。
• プレフィックスをキャッシュする。Claudeモデルではこれが実際のITPMの余裕を買います(請求額が安くなるだけではありません)。プロンプトキャッシュのコスト計算で損益分岐点がどこにあるかを示しています。
• 急がない処理はバッチエンドポイントへ移す。バッチAPIは別枠の制限を持ち、通常は半額です(usually half price)。
• より強く再試行するのではなくフェイルオーバーする。429が上流の容量によるものなら、同じリクエスト形式に対する2つ目のモデルが1ホップで呼び出しを回復させます。これが、1つのエンドポイントの背後に複数のモデルを置くことの実践的な論拠です。ofoxはOpenAI互換なので、フォールバックは2つ目の統合ではなくモデル文字列の変更で済みます。
• 上限引き上げを申請する。AnthropicはConsoleに「Request rate limit increase」のフローを持ち、OpenAIは累積支出額に応じてアカウントのティアを上げます。どちらも即時ではないので、これは今日の午後ではなく来月の計画です。

やってはいけないことが2つあります。1つは、同一組織内の複数のAPIキーに1つのワークロードを分散させないこと(制限は組織レベルなので何も変わりません)。もう1つは、実際にそれだけのトークンを生成しているのでない限り、出力制限を緩和しようとして max_tokens を下げないことです。

この更新のために確認したソース

• https://platform.claude.com/docs/en/api/rate-limits
• https://platform.claude.com/docs/en/api/errors
• https://developers.openai.com/api/docs/guides/rate-limits
• https://developers.openai.com/api/docs/guides/error-codes
• https://ai.google.dev/gemini-api/docs/rate-limits
• https://ai.google.dev/gemini-api/docs/troubleshooting
• https://openrouter.ai/docs/api-reference/limits