Claude の rate limits は「429 が出た」だけでは原因を誤診する

要点

要点まとめ

この docs の価値は、API 停止を一つの「速度超過」にまとめず、月間 spend cap、組織の spend limit、RPM、ITPM、OTPM、acceleration limit に分けて読むべきだと明示している点にある。
つまり 429 が出ても、すぐ retry や backoff の話に飛ぶのは雑で、予算上限なのか、急激なトラフィック増加なのか、入力 token の窓口なのかを切り分ける必要がある。
Anthropic は rate limit を token bucket で運用し、短い burst でも超過しうると書いている。分単位の表だけ見て「余裕があるはず」と判断すると誤る。
prompt caching は単なるコスト小技ではなく、ほとんどの model で cached input が ITPM に数えられないため、実効 throughput を変える運用要素になっている。
読後にやるべきことは、429 を一括処理するのではなく、failure mode ごとに監視項目と切り分け手順を分けることだ。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む まず知りたい

新しい言葉や発表の意味を、短時間でつかみたい人向け。

同じテーマで読む LLM API

Responses API、Gemini API、モデル更新、構造化出力、SDK。

次の記事 Claude API の rate limit 統合は「安い model は細い」を前提にした運用表を壊す

Anthropic は 2026-06-26 の release note で、Claude Sonnet と Claude Haiku の rate limit を Claude Opus と同水準にそろえ、usage tier を `Start / Build / Scale` の 3 段階へ統合した。

読解

何が変わったのか

Anthropic のこの docs は、limit を二層に分けています。まず spend limit は月間の費用上限で、tier cap に達すると月末まで usage が止まります。次に rate limit は requests per minute、input tokens per minute、output tokens per minute に分かれ、429 には `retry-after` が付くと説明しています。さらに重要なのは、急激な利用増加による acceleration limit を別物として書いている点です。steady-state の表に収まっていても、急に流量を立ち上げれば止まりうる。また prompt caching を使うと、多くの model では cache read 分が ITPM に数えられず、見かけの token 量と rate-limit 消費量が一致しません。つまり運用者は『何 token 送ったか』だけでなく、『どの token が uncached として数えられたか』を見る必要があります。

日本の文脈

なぜ重要か

日本のチームでは API 障害を全部『429 だから backoff 不足』と片づけやすいですが、それでは spend cap 超過や traffic ramp-up 失敗を見逃します。とくに小規模チームでは、経理上限、組織設定、batch job、chat UI を同じ鍵と組織で混ぜたまま走らせがちで、止まった理由が混ざります。この docs は、モデル選定より手前の運用責任をはっきりさせます。request budget と token budget を分ける、cached input を別に観測する、burst と steady-state を分ける、予算停止を技術障害と混同しない。地味ですが、本番の継続利用にはこちらのほうが効きます。

技術ポイント

技術的ポイント

`spend cap` は月間の費用上限です。Start、Build、Scale tier に月上限があり、到達すると次の月まで usage が止まります。retry では直りません。
`rate limits` は RPM、ITPM、OTPM の別窓口です。429 が返るときは、どの窓口を超えたかと `retry-after` を見て切り分ける必要があります。
`acceleration limit` は急な利用増加に対する制限です。平均負荷が低くても、急に traffic を立ち上げると当たります。これは steady-state throughput の問題とは別です。
`prompt caching` は、多くの model で `cache_read_input_tokens` が ITPM に数えられません。つまり cached prefix を増やせば、単純な request 最適化以上に実効 throughput が変わります。
docs は limits が organization level と明記しており、workspace 側の自前設定も別に持てます。障害解析では application 単位だけでなく、組織全体の混雑や予算設定も見る必要があります。

用語

英日キーワード

英語	日本語	補足
spend cap	月間利用上限	provider が tier ごとに決める月単位の最大支出。到達すると usage が止まる。
spend limit	任意の支出制限	組織が自分で設定できる予算上限。tier の cap より低く切って使う。
RPM	1分あたりリクエスト数	request 件数で測る rate limit の窓口。短い burst でも当たりうる。
ITPM	1分あたり入力トークン数	入力側で消費する token 量の上限。cached input が数えられない場合もある。
OTPM	1分あたり出力トークン数	生成された output token 量の上限。長い応答で先に詰まることがある。
acceleration limit	急増抑制上限	急なトラフィック増加時に別系統でかかる制限。通常 retry だけでは解きにくい。
token bucket	トークンバケット方式	時間とともに余力が補充される制限方式。毎分きっかりで窓が切り替わる前提ではない。

試す

試すなら

429 を受けたときの runbook を作り、spend cap、spend limit、RPM、ITPM、OTPM、acceleration limit を別分岐にする。
batch job と interactive UI を同じ組織枠で動かしているなら、どちらが token と request を食っているか分けて観測する。
prompt caching を使っている場合は、総 input token ではなく `input_tokens`、`cache_creation_input_tokens`、`cache_read_input_tokens` を分けて見る。
新機能の rollout では、一気に 10 倍流さず、traffic ramp を段階的に上げて acceleration limit を避ける。

注意

注意点

docs 上で標準 tier の例は示されていますが、実際の上限は組織 tier と account 状況で変わります。表をそのまま他社比較に使うのは危険です。
Claude Platform on AWS では spend limit の扱いなどが異なります。この docs でも AWS 向けの差分が明示されています。
prompt caching が効く前提で throughput 設計をすると、prefix 崩壊時に急に ITPM 消費が増える可能性があります。cache hit 率の観測なしで設計しないほうがよいです.

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。