これまでコスト・モデル戦略シリーズでは**「1 トークンいくらか」を扱ってきましたが、実運用ではもう一つの制約——「1 分に何トークン流せるか」= レート制限(スループット)が効いてきます。直近、Claude API の使用ティアが Start / Build / Scale の3つに整理され、Sonnet 5・Sonnet 4.x・Haiku 4.5 のレート制限が各ティアで Opus と同水準に引き上げられました。本記事は、このスループットの軸**を モデル選択チートシート に足す「スループット編」です。
到達点
- 3ティア(Start / Build / Scale) の上限と月額スペンドキャップを把握する
- レート制限の 3軸(RPM / ITPM / OTPM) を理解する
- 安いモデルが Opus と同一枠になった意味
- キャッシュ読取が ITPM に数えられない=実効スループットが上がる仕組み
- OTPM と max_tokens の関係、モデルごとの別枠
3ティア:Start / Build / Scale
使用ティアは組織単位で自動的に割り当てられ、使うほど上位に上がります。月額スペンドキャップは:
| ティア | 月額スペンドキャップ |
|---|---|
| Start | $500 |
| Build | $1,000 |
| Scale | $200,000 |
| Custom | 上限なし(要相談) |
キャップに達するとその月は API 利用が止まります(上限引き上げ申請は可能)。ティア内で自前のスペンド上限を下げて設定することもできます。
レート制限の3軸
Messages API のレート制限は、モデルクラスごとに次の3つで測られます。
- RPM:1 分あたりのリクエスト数
- ITPM:1 分あたりの入力トークン数
- OTPM:1 分あたりの出力トークン数
いずれかを超えると 429 エラーと retry-after ヘッダが返ります。モデルごとに別枠なので、複数モデルをそれぞれの上限まで同時に使えます。
安いモデルが Opus と同一枠に
今回の目玉です。標準モデル(Opus 4.x / Sonnet 5 / Sonnet 4.x / Haiku 4.5)は、各ティアで同じ RPM / ITPM / OTPM になりました。
| ティア | RPM | ITPM | OTPM |
|---|---|---|---|
| Start | 1,000 | 2,000,000 | 400,000 |
| Build | 5,000 | 5,000,000 | 1,000,000 |
| Scale | 10,000 | 10,000,000 | 2,000,000 |
つまり Haiku 4.5 や Sonnet 5 でも Opus と同じ高スループットで回せる。安いモデルで大量処理する構成(分類・抽出・エージェントの実行役)に、価格だけでなくスループットの後押しが付いたことになります。
例外:Fable 5 は低め
フロンティア最上位の Fable 5 だけは別で、上限が低いです。
| ティア | RPM | ITPM | OTPM |
|---|---|---|---|
| Start | 1,000 | 500,000 | 100,000 |
| Build | 2,000 | 1,500,000 | 300,000 |
| Scale | 4,000 | 4,000,000 | 800,000 |
Fable 5 は高価なだけでなくスループットも絞られている——要所の一撃に向くという結論が、レート制限の面からも裏づけられます。
バケットの注意
- Opus の枠は Opus 4.8 / 4.7 / 4.6 / 4.5 の合算
- Sonnet 4.x は 4.6 / 4.5 の合算だが、Sonnet 5 は別枠(合算に含まれない)
核心:キャッシュ読取は ITPM に数えない
ここが実効スループットを大きく変えます。多くのモデルで、ITPM にカウントされるのは「キャッシュされていない入力トークン」だけです。
| トークン種別 | ITPM に数えるか |
|---|---|
input_tokens(最後のキャッシュ境界より後) | ✓ 数える |
cache_creation_input_tokens(キャッシュ書き込み) | ✓ 数える |
cache_read_input_tokens(キャッシュ読み取り) | ✗ 数えない |
つまりキャッシュヒットした入力は、レート制限を消費しません。公式の例では——2,000,000 ITPM の枠 + キャッシュヒット率 80% なら、実質 10,000,000 トークン/分(2M 非キャッシュ + 8M キャッシュ)を処理できる。
プロンプトキャッシュは「コストを 1/10 にする」だけでなく、レート制限を実質的に何倍にも広げる。大きな固定コンテキスト(システムプロンプト・ツール定義・長い文書・会話履歴)を持つワークロードほど、キャッシュがスループットの主戦略になります。
(注:旧 Haiku 3.5 だけは cache_read_input_tokens も ITPM に数えるため、この恩恵は受けません。)
OTPM と max_tokens は無関係
もう一つ実務で効く点。OTPM は実際に生成された出力トークンだけをリアルタイムに数えます。max_tokens の値は OTPM 計算に入りません。だから「余裕を持って max_tokens を大きめに」しても、レート制限上のペナルティはゼロ。安心して上限を広く取れます。
実務への落とし込み
- 安いモデルの高スループットを活かす:Haiku / Sonnet 5 が Opus と同一枠になったので、大量処理は迷わず安いモデルへ。価格もスループットも有利
- キャッシュでスループットを稼ぐ:固定コンテキストは必ずキャッシュ。ITPM を消費せず、実効スループットが跳ね上がる。Console の Usage でキャッシュ率を監視
- 複数モデルを並行:モデルごとに別枠なので、実行役(Sonnet 5)と助言役(Opus)を同時に上限まで回せる
- Fable 5 はスループットも希少資源:枠が低いので、大量・並行には使わない
- 429 は段階的に:急な usage 増は acceleration limit にも当たる。トラフィックは徐々に立ち上げる
- ヘッダで残量を見る:
anthropic-ratelimit-*ヘッダで残 RPM/トークンと回復時刻が取れる。バックプレッシャ制御に使う
まとめ
Claude API のレート制限は Start / Build / Scale の3ティアに整理され、Sonnet 5・Haiku 4.5 が Opus と同一枠に引き上げられました。上限は RPM / ITPM / OTPM の3軸・モデル別枠。そして最大の実務ポイントは——キャッシュ読取は ITPM に数えないため、プロンプトキャッシュがコストと同時にスループットも押し上げること。
勘所は 3 つ — 安いモデルは価格もスループットも Opus 並みなので大量処理に使う、固定コンテキストはキャッシュして ITPM を節約する、Fable 5 はスループットも希少なので要所に絞る。「1 トークンいくら」だけでなく「1 分に何トークン流せるか」まで設計に入れると、モデル選択の解像度が一段上がります。