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 段階へ統合した。
- 重要なのは数字そのものより、「軽い model は capacity も低いはず」という古い前提で組んだ queue 制御、fallback、burst 見積もりが静かに古くなる点だ。
- 公式の rate limits ページでは、429 は単純な毎分上限だけでなく短時間 burst や acceleration limit でも起こりうると説明している。
- prompt caching により、多くの model では cached input token が ITPM に数えられず、実効 throughput の見積もり方も単純な TPM 発想とはずれる。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この更新は、limit 表の数字だけを上げた話ではありません。release notes は 2026-06-26 付で Sonnet と Haiku の rate limit が Opus と同水準になり、usage tier も `Start / Build / Scale` の 3 段階へ整理されたと案内しています。つまり、古い model-class 前提で切った queue や retry 方針を再点検しないと、過剰制限にも過剰楽観にも振れます。 さらに rate limits docs は、organization 単位の上限、token bucket 方式、短時間 burst でも起こる 429、急増時の acceleration limit、cached input token が多くの model で ITPM に算入されない点まで明示しています。実務上の変化は provider の数字ではなく、capacity planning の前提が変わることです。
なぜ重要か
日本の現場では rate limit を『困ったら上げてもらう数字』として扱い、実装側では昔の上限値を env や runbook に固定しがちです。しかし本当に問題になるのは、どの workspace でどの queue を共有し、429 をどう分類し、prompt caching を throughput 設計へ組み込むかです。 少人数チームほど trial、CI、production を同じ key と queue で回しやすく、provider 側の tier 変更が静かに本番設計を腐らせます。この note は、その古い運用表をそのまま信じるなという停止線になります。
技術的ポイント
- rate limit は RPM だけでなく ITPM と OTPM でも測られる。429 はどの limiter に当たったかで対処が変わる。
- docs は token bucket 方式を明示しており、毎分ぴったりで窓が切り替わる前提ではない。短時間 burst でも上限超過は起こる。
- acceleration limit は急な利用増で起きる別系統の抑制であり、通常 retry だけでなく段階的 ramp-up が必要になる。
- 多くの Claude model では cached input token が ITPM に算入されない。prompt caching はコスト削減だけでなく実効 throughput を上げる手段でもある。
- 上限は organization 単位で効く一方、workspace ごとの user-configurable limits も持てる。bot、CI、手動利用を同じ余力プールで食わせない設計が必要だ。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| rate limits | 利用上限 / レート制限 | 一定時間内に使える request 数や token 数の上限。429 の原因切り分けはこの内訳から始まる。 |
| usage tier | 利用ティア | 組織ごとに割り当てられる上限制御の段階。provider 変更で運用表が古くなりやすい。 |
| token bucket | トークンバケット方式 | 時間とともに余力が補充される制限方式。毎分きっかりで窓が切り替わる前提ではない。 |
| acceleration limit | 急増抑制上限 | 急なトラフィック増加時に別系統でかかる制限。通常 retry だけでは解きにくい。 |
| prompt caching | プロンプトキャッシュ | 同一 prefix の再利用で効率を上げる仕組み。静的 instructions を先に置く設計が効きやすい。 |
| 429 error | 429 エラー | 利用上限超過時に返る HTTP エラー。どの limiter に当たったか見ないと対処を誤る。 |
試すなら
- 運用表や retry 設定に「Sonnet は低め」「Haiku は別枠」などの古い前提が残っていないか確認する。
- 429 ログを model 名ではなく、RPM、ITPM、OTPM、acceleration のどれに当たったかで分類する。
- 繰り返し使う system prompt、tool 定義、長文文脈があるなら prompt caching を入れ、実効 throughput の差を測る。
- trial、CI、production を同じ組織余力で食わせているなら、workspace limit や queue 分離を見直す。
注意点
- release note の `no action required` は Anthropic Console 上の設定を指すのであって、コード内の古い上限制御や runbook までは直してくれない。
- rate limit 表は今後も変わり得る。この note は 2026-07-09 時点で確認した docs を前提にしている。
- Claude Sonnet 5 は Sonnet 4.x の combined bucket と別扱いだと docs にあるため、『Sonnet は全部同じ』とまとめると誤る。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。