Claude Code の Rate Limit Reached：429 の原因と 6 つの対処法（2026）

Claude Code が「Rate limit reached」と言ったら、それは API が「あなたが毎分のトークンまたはリクエストの予算を使い切った」と伝えているのであって、Anthropic がダウンしているわけではありません。対処は、ヘッダーを 1 つ読み、正しい次元で速度を落とすことです。

並列サブエージェントを少し走らせた、あるいは長いエージェントループを回した。そして Claude Code が rate limit や「Request rejected (429)」の赤い行で止まった。壊れてはいません。あなたはアカウントのティアが定める毎分の上限に当たり、API は再試行する前に具体的な秒数だけ待つよう求めています。

本記事は、トークン単位で課金される Console / API キーのユーザーが受け取る API 側の 429 についてです。Pro や Max のサブスクリプションを使っていて、429 ではなく週次やセッションの上限に当たったなら、それは別の仕組みで別の対処になります。Claude Code の使用上限に早く達しすぎる で扱っています。

30 秒の診断

まず片づけるべきこと：あなたが実際に見ているのはどのエラーか。対処が大きく分かれるからです。

このチェックリストを順番に回してください。

1. 429 であって 529 でないことを確認する。 Claude Code はそれぞれ異なる文言を使います。「Request rejected (429)」や「Rate limited」はあなたのアカウント。「529 Overloaded」はサーバー。扱いを分けてください。
2. アクティブな認証情報を確認する。 /status を実行します。シェルに紛れ込んだ ANTHROPIC_API_KEY が、あなたの思っているアカウントではなく低ティアのキー経由でルーティングしているかもしれません。
3. ティアを見る。 Console の Limits ページ を開きます。Tier 1 はきつく、Sonnet 4.x で 50 RPM、30,000 ITPM です。大きなコンテキストの 1 ターンにサブエージェントが 1 つ加わるだけで超えてしまいます。

429 を直すとき（と、ただ待つとき）

リファクタリングを始める前に判断してください。429 には自然に解消するものと、本当の変更が要るものがあります。

ただリトライして待つとき。 バースト中にたまに 429 が出て、retry-after が小さい（数秒）なら、構造的な手は不要です。Claude Code はすでに、一時的な 429 と 529 の容量エラーをエラーとして表面化させる前に指数バックオフで最大 10 回リトライし、Retrying in Ns · attempt x/y のカウントダウンを表示します。エラー率がリクエストのおおよそ 5% 未満なら、リトライがそのまま対処のすべてです。

実際に何かを変えるとき。 429 が常時出る、タスクの途中でサブエージェントを殺す、retry-after が伸び続ける。これらはティアの毎分予算を構造的に超えています。並列度を下げる、キャッシュを足す、またはティアを上げてください。飽和した制限にリトライを積み増しても、失敗を増やしてキューに並べるだけです。

中止ルール。 Tier 1 で大きなリポジトリに対して並列サブエージェントを走らせているなら、どれだけバックオフしても持ちません。上位ティアに移るか、ゲートウェイ越しに容量をプールするかです。バックオフはスパイクをならすだけで、天井は上げません。

「Rate Limit Reached」と HTTP 429 が実際に意味すること

429 は、あなたの組織が毎分の rate limit のいずれかを超えたときに Claude API が返す HTTP ステータスです。組織にスコープされたアカウントレベルのシグナルで、モデルごとに別々に適用されます。エラーボディは rate_limit_error で、メッセージがどの制限に当たったかを示します。たとえば「This request would exceed your organization’s rate limit of x0,000 input tokens per minute.」。API は retry-after ヘッダーも付けます。

Messages API が適用する毎分の次元は 3 つあります（Anthropic の rate-limits ドキュメント より）。

• RPM（毎分リクエスト数）：何回 API を呼べるか。
• ITPM（毎分入力トークン数）：何トークンを送れるか。エージェントのワークロードに効くのはこれです。各ターンが会話コンテキスト全体を入力として運ぶからです。
• OTPM（毎分出力トークン数）：モデルが毎分あなたに生成できるトークン数。注意：max_tokens は OTPM に算入されません。実際に生成されたトークンだけが数えられるので、max_tokens を高く設定しても rate limit 上のデメリットはありません。

3 つのいずれか 1 つでも越えた瞬間に 429 になります。制限はトークンバケットアルゴリズムを使うので、容量は毎分の頭でリセットされるのではなく連続的に補充されます。これはつまり、毎分平均の利用量が問題なく見えても短いバーストで制限に触れうるということです。60 RPM は 60 リクエストを一斉に撃つのではなく、1 秒 1 リクエストに近い形で適用されます。

あらゆる 429 を支配するのは 3 つの数字：毎分のリクエスト、入力トークン、出力トークン。どれを吹き飛ばしているかを見つければ、対処は自ずと決まります。

429 レスポンスと、すべてを教えてくれるヘッダー

制限に当たると、レスポンスには制限値・残り予算・補充タイミングを伝えるヘッダーが付きます。自作のエージェントループでは表に出す価値があります。

HTTP/1.1 429 Too Many Requests
retry-after: 12
anthropic-ratelimit-input-tokens-limit: 30000
anthropic-ratelimit-input-tokens-remaining: 0
anthropic-ratelimit-input-tokens-reset: 2026-06-24T18:42:30Z

retry-after はリトライ前に待つ秒数です。それより早いリトライは失敗します。anthropic-ratelimit-*-limit、-remaining、-reset の各ヘッダーは、リクエスト・入力トークン・出力トークンそれぞれに存在するので、各次元の余裕を監視し、制限に触れる前に（後ではなく）バックオフできます。

現場が痛い思いをして学んだ注意点が 1 つ：retry-after はサーバーのヒントであり、ローリングウィンドウの境界ではやや短めに出ることがあります。これを下限として尊重し、その上にプラスのジッターを乗せてください。そうすれば多数のワーカーが同じミリ秒で目覚めて一斉にリトライすることがなくなります。

エラー・症状 → 原因 → 対処

なぜ触れるのか：並列度、トークンのバースト、バックオフなし

ほぼすべての Claude Code の 429 は、3 つのパターンが原因です。

並列サブエージェントと並列セッション。 これが最大の要因です。Claude Code が Task ツールを通じてサブエージェントをファンアウトすると、各サブエージェントは別々のリクエストストリームになり、それぞれが自身のコンテキストのコピーを入力トークンとして運びます。大きなリポジトリに対して 6 つのサブエージェントを走らせれば、ITPM と RPM が同時に跳ね上がります。既知の Claude Code issue では、5-10 の並列セッションがサブエージェントのファンアウトを起動し、容量エラーでハードに失敗する事例が記録されています。ファンアウトを減らせば 429 は止まります。

きついティアでのコンテキストのバースト。 Tier 1 では Sonnet 4.x が 30,000 ITPM です。会話コンテキストが 25,000 トークンまで育っていると、新しいメッセージ 1 つが毎分の入力予算の大半を消費し、同じ分内の 2 つ目のメッセージで 429 に触れます。これが「プロンプトの肥大化」です。セッションがタスクの必要以上に大きくなっています。/context を実行してウィンドウを埋めているものを確認し、/compact か /clear してください。

自前スクリプトにバックオフがない。 Claude Code 自体は指数バックオフでリトライします。しかし Claude Code の周りで API を直接叩いていて（CI ラッパー、自作エージェントループ）、ジッターなしの固定間隔でリトライしていると、全ワーカーが同期してリトライし、まとめて制限に再び触れます。同期リトライは、短いスロットルを持続的な障害に変えます。

対処法：あらゆるティア向けの解決策

Free / Tier 1 の対処：ヘッダーを読み、バーストを削る

最下位ティアにいるなら余裕が最も少ないので、それに合わせて振る舞ってください。

• retry-after を尊重する。 ヘッダーの示す秒数だけ待ち、ジッターを足す。早めにリトライしない。
• コンテキストを縮める。 自然な区切りで /compact を実行するか、/clear で仕切り直す。ターンあたりのコンテキストが減れば、リクエストあたりの ITPM も減ります。
• 並列度をほぼ直列まで下げる。 並列度の上限を低くして、賄えないリクエストをファンアウトしないようにします。

# 重いセッションの前にツール使用の並列度を下げる
export CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=2
# スクリプトでは 10 回リトライせず、失敗を早く表面化させる
export CLAUDE_CODE_MAX_RETRIES=3
claude

Paid / Tier 2-3 の対処：キャッシュと指数バックオフ

ある程度の余裕ができたら、効くのはキャッシュと規律あるリトライです。

prompt caching はコストだけでなく ITPM も削る。 現行のほとんどの Claude モデルでは、cache_read_input_tokens は ITPM 制限にカウントされません。Anthropic 自身の例：2,000,000 ITPM の制限とキャッシュヒット率 80% なら、キャッシュされた 8M が rate limit に対して無料になるため、実質毎分およそ 10,000,000 の入力トークンを処理できます。システムプロンプト、ツール定義、大きなコンテキスト文書をキャッシュしてください。トークン使用量を端から端まで削るメカニクスは Claude Code のトークン最適化 を参照。

ジッター付き指数バックオフ は、ループを自分で制御しているときの正しいリトライの形です。

import random, time

def backoff_sleep(attempt, retry_after=None):
    if retry_after is not None:        # honor the server hint as a floor
        base = float(retry_after)
    else:
        base = min(2 ** attempt, 60)   # 1, 2, 4, 8 ... capped at 60s
    time.sleep(base + random.uniform(0, base * 0.25))  # add jitter

CI のような無人実行では、CLAUDE_CODE_RETRY_WATCHDOG=1 を設定して、CLAUDE_CODE_MAX_RETRIES 回で諦める代わりに、Claude Code が 429 と 529 の容量エラーを無期限にリトライするようにもできます。

Enterprise / Tier 4 の対処：天井を上げるか、プールする

バックオフとキャッシュでは足りないときは、もっと制限が必要です。

• ティアを上げる。 累積クレジット購入が各しきい値に達するとティアは自動的に上がります。Tier 4 では Sonnet 4.x が 4,000 RPM、2,000,000 ITPM になり、Tier 1 の 50 RPM / 30,000 ITPM を大きく上回ります。Tier 4 を超える制限は、Anthropic の営業に連絡してカスタムまたは Priority Tier の制限を相談してください。
• ワークスペースごとの上限を設定する ことで、1 つのプロジェクトが組織の残りを飢えさせないようにします。ワークスペースの制限は、組織の毎分予算をリミッター種別ごとに分割します。
• プロバイダー間で負荷を分散するか容量をプールする。 ワークロードがバースト的で、単一組織の毎分上限がボトルネックなら、複数プロバイダーの前段にルーティング層を置くと実効的な天井が広がります。パターンの詳細は Claude Code のハイブリッドルーティングガイド を参照。

ティア別の Anthropic rate limit（Sonnet 4.x と Opus 4.x）

429 に触れる速さを決める毎分の上限（公式の rate-limits ドキュメント より）：

Opus 4.x の制限は、Opus 4.8、4.7、4.6、4.5、4.1 で共有される単一の合計です。Sonnet 4.x の制限は Sonnet 4.6 と 4.5 で共有されます。同じファミリー内でバージョンを切り替えても、新しいバケットはもらえません。役立つ詳細が 1 つ：制限はモデルごとに別々に適用されるので、Opus のジョブと Sonnet のジョブはそれぞれ自分のプールから引き、同時に各自の上限まで走れます。安価で大量の作業を Haiku 4.5 にルーティングすれば、それを Opus と Sonnet のバケットから完全に外せます。

acceleration limit：あなたのティアとは無関係な 429

知っておく価値のある 2 つ目の 429 があります。ティアの天井に全然近づいていない人を驚かせるからです。組織の利用量が急に跳ね上がると、API は acceleration limit を適用し、毎分の上限に余裕があっても 429 を返すことがあります。狙いは暴走するスパイクを止めることであって、安定した利用を罰することではありません。対処は「ティアを上げる」ではなく「徐々に立ち上げる」です。新しいワークロードはコールドスタートからピークトラフィックを撃つのではなく、1-2 分かけて温め、リクエストレートをおおむね一定に保ってください。Claude Code ではこれが Server is temporarily limiting requests (not your usage limit) メッセージの背後にあるスロットルで、CLI が表面化する前にすでにリトライしてくれます。

積み上げる代わりに負荷を分散する

エージェントの 429 の多くは、すべてを 1 つの狭い時間枠でやることから来ます。安価なスケジューリングの習慣をいくつか身につけると、同じ総量の作業が同じ上限の下に収まります。

• 高コストなターンを直列化する。 大きなコンテキストの 1 ターンは、Tier 1 では毎分の ITPM の大半になりえます。サブエージェントに並列で撃たせるのではなく、1 つずつ走らせてください。
• 緊急でない作業をバッチにする。 生の即答が要らないジョブなら、Message Batches API には独自の別の制限があるので、一括作業をそちらに移せばインタラクティブな RPM とトークン予算が解放されます。
• CI ジョブをずらす。 10 のパイプラインを同じ cron の分に開始させないでください。開始時刻をオフセットして、最初のバーストが同じバケットで衝突しないようにします。

2026 年に観測したよくある失敗パターン

Claude Code の issue トラッカーとサポートスレッドから、現場が繰り返し報告している形：

これらは公開されたインシデントログではなく、メカニズムのパターンです。一貫する筋は同じ：飽和させている次元を見つけ、それを遅くするか広げるかです。

もっと余裕が必要なとき：いま機能する最良の代替

ボトルネックが単一組織の毎分上限なら、現実的な選択肢はこちら（ofox から）。

ofox のプール容量（1 つのキー、従量課金）。 ofox は https://api.ofox.ai/v1 に OpenAI 互換の endpoint を公開し、プールされた従量課金の容量上で 1 つの API キーを多数のモデルにルーティングします。リクエストが単一の低ティア組織バケットではなく共有容量から引くため、バースト的なエージェントのワークロードが 1 つのプロバイダーの毎分天井を飽和させにくくなります。同じ OpenAI SDK の形を保ち、model 文字列を差し替えるだけでモデルを変えられます。毎分トークンの物理法則を撤廃するわけではありませんが、バースト的なワークロードが制限に触れるまでの余地が広がります。

from openai import OpenAI
client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")
resp = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",
    messages=[{"role": "user", "content": "Refactor this function for clarity."}],
)

Anthropic のティアを上げる。 単一プロバイダーで通したいなら最もすっきりした対処です。次のティアまで入金すれば、RPM/ITPM/OTPM がすぐに跳ね上がります。トラフィックが予測可能で支出をコミットできるときに最適。

自分側でのマルチプロバイダールーティング。 プロバイダー間でリクエストを分散し、各自の retry-after を尊重する自前のルーターを動かします。最も制御が利き、保守するコードも最も多い。設計は ハイブリッドルーティングパターン で扱っています。

rate limit を監視して 429 の先回りをする方法

429 は着地する前に見えます。見るべき場所は 3 つ。

• Console の Usage ページ には rate-limit チャートが 2 つあります：現在の ITPM 上限に対する毎分のキャッシュ未適用入力トークンの時間最大値と、出力トークンについての同じもの。キャッシュヒット率も表示され、キャッシュがどれだけ ITPM の余裕を買っているかが分かります。
• レスポンスヘッダー（anthropic-ratelimit-*-remaining と -reset）を使えば、自前のコードが先回りしてスロットルできます。残りの入力トークンがゼロに近づいたら、バケットが空になる前に速度を落とします。
• Anthropic のステータス（status.claude.com）は、「rate limited」メッセージの波が実は全員に影響する 529 容量イベントなのかを教えてくれます。その場合の対処は設定ではなく忍耐です。

FAQ

Claude Code の API Error: Rate Limit Reached とは何ですか？ Claude API が HTTP 429 を返したという意味です。あなたの組織が、利用ティアの許す以上の毎分リクエスト数またはトークン数を送ったことを示します。サーバー障害ではなく、RPM・ITPM・OTPM に対するアカウント側のスロットルです。レスポンスには何秒待てばよいかを示す retry-after ヘッダーが付きます。

Claude Code の 429 と 529 は同じものですか？ いいえ。429（rate_limit_error）はあなたのアカウントが自身の毎分制限を超えたという意味です。529（overloaded_error）は Anthropic のサーバーが全ユーザー向けに一時的に満杯で、あなたの利用量とは無関係です。Claude Code は別々のメッセージで表示します：「Request rejected (429)」に対して「Repeated 529 Overloaded errors」。

429 rate limit エラーの後はどれくらい待つべきですか？ retry-after ヘッダーを読んでください。リトライ可能になるまでの正確な秒数を示します。早くリトライすると再び失敗します。ヘッダーがない場合は、1-2 秒程度から始めて倍々にしていく指数バックオフに、並列ワーカーが同時にリトライしないようランダムなジッターを加えてください。

なぜ Claude Code はサブエージェントを使うとこんなに早く rate limit に達するのですか？ 並列サブエージェントは多数の同時リクエストにファンアウトし、それぞれが会話コンテキスト全体を入力トークンとして運びます。大きなコンテキストで少数のサブエージェントを動かすだけで、数秒で ITPM の上限を突き抜けます。CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY を下げるか、一度に生成するサブエージェントの数を減らしてください。

Anthropic の rate limit における RPM・ITPM・OTPM とは何ですか？ RPM は毎分リクエスト数、ITPM は毎分入力トークン数、OTPM は毎分出力トークン数です。Messages API はモデルクラスごとに 3 つすべてを適用します。いずれか 1 つを超えた瞬間に 429 になり、エラーがどの制限に当たったかを示します。

Claude API の rate limit を引き上げるにはどうすればいいですか？ 利用ティアは累積クレジット購入額が各しきい値に達すると自動的に上がります（Tier 1 は $5、Tier 2 は $40、Tier 3 は $200、Tier 4 は $400）。上位ティアは RPM・ITPM・OTPM を引き上げます。Tier 4 を超える制限が必要なら、Anthropic の営業に連絡してカスタムまたは Priority Tier の制限を相談してください。

prompt caching は 429 rate limit エラーに効きますか？ はい。現行のほとんどの Claude モデルでは、cache_read_input_tokens は ITPM 制限にカウントされません。2,000,000 ITPM の上限に対してキャッシュヒット率 80% なら、キャッシュ部分が rate limit に対して無料になるため、実質的に毎分およそ 10,000,000 の入力トークンを処理できます。

プロバイダーを切り替えれば Claude Code の rate limit を回避できますか？ プロバイダー間で負荷を分散したり、プールされたゲートウェイを使ったりできます。https://api.ofox.ai/v1 の ofox のような OpenAI 互換ゲートウェイは、従量課金のプール容量上で 1 つのキーを多数のモデルにルーティングするので、単一プロジェクトが 1 つの組織の毎分上限を飽和させにくくなります。物理法則を消すわけではありませんが、余裕は広がります。

429 は API がペースを設定しているのであって、ドアを叩きつけて閉めているわけではありません。retry-after を読み、飽和させている次元を遅くすれば、作業は動き続けます。

今回の更新で確認したソース

• Anthropic API Rate Limits リファレンス：ティア表、RPM/ITPM/OTPM、retry-after と anthropic-ratelimit-* ヘッダー、キャッシュ対応 ITPM（2026-06-24 確認）
• Claude Code Error リファレンス：正確な「Request rejected (429)」と「Server is temporarily limiting requests」の文字列、および CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY、CLAUDE_CODE_MAX_RETRIES、CLAUDE_CODE_RETRY_WATCHDOG、自動リトライの挙動（2026-06-24 確認）
• Claude Code issue #68502：並列サブエージェント、429 と 529 の誤ラベル、バックオフなしのハード失敗について（2026-06-24 確認）
• ofox models ページ：現行の Claude フラッグシップ（Opus 4.8）と OpenAI 互換 endpoint（2026-06-24 確認）