Claude APIのITPM制限にキャッシュ読み込みがカウントされない仕組み

Claude APIのITPM制限はキャッシュ読み込み分を数えない

Claude APIのレート制限は、リクエスト数(RPM)・入力トークン数(ITPM)・出力トークン数(OTPM)の3種類をモデルクラスごとに管理します。多くのAPIプロバイダーは「トークン/分」の上限にキャッシュ済みトークンも含めますが、Claude APIのほとんどのモデルは違います。キャッシュから読んだ入力トークン(cache_read_input_tokens)はITPM制限にカウントされません。この設計により、実効スループットは表示された上限より大きく引き上がります。

対象はMessages APIのレート制限です。Message Batches APIやFiles API、Managed Agentsのレート制限には別枠の制限があり、本記事の計算式は対象外です。

3つのトークン種別とITPMへの算入ルール

Claude APIのレスポンスには入力トークンを表す3つのフィールドがあります。

• input_tokens — 直前のキャッシュブレークポイントより後のトークン(ITPMに算入)
• cache_creation_input_tokens — キャッシュへの書き込みが発生したトークン(ITPMに算入)
• cache_read_input_tokens — キャッシュから読み出したトークン(ほとんどのモデルでITPMに算入されない)

合計の入力トークン数は次の式で求まります。

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

ここで注意が必要なのは、input_tokens フィールドが「リクエスト全体の入力トークン数」ではなく「直前のキャッシュブレークポイントより後ろの部分だけ」を表す点です。20万トークンのドキュメントをキャッシュして50トークンの質問だけを追加した場合、レスポンスの input_tokens は50になります。合計入力は20万50トークンですが、ITPM制限に効くのはinput_tokensとcache_creation_input_tokensの合計だけです。ITPM制限はリクエスト開始時に見積もられ、実際に消費したトークン数に応じて途中で調整されます。

OTPM(出力トークン/分)側はこれとは別の評価方式です。実際に生成された出力トークン数だけをリアルタイムに数え、max_tokens パラメータの値そのものはOTPM計算に影響しません。max_tokensを大きく設定してもレート制限上の不利益はありません。

ITPMはトークンバケット方式で連続的に補充される

ITPM(に限らず全てのレート制限)は固定の時間枠でリセットされる方式ではなく、トークンバケットアルゴリズムで上限まで連続的に補充されます。1分あたりの上限が決まっていても、実際には秒単位でならされた形で消費が判定されるため、短時間にリクエストが集中するとバーストとして制限に触れることがあります。たとえば60RPMの上限は、実質的に1秒あたり1リクエストとして扱われる場合があり、短い間隔でまとめて送ると上限内でも429が返ることがあります。キャッシュの非算入効果を最大化する設計をしていても、リクエストの送信間隔が偏っていると、ITPMではなくRPM側で先に制限に当たることがある点は覚えておく必要があります。さらに、組織全体の利用量が急激に増えると、通常のITPM/RPM/OTPM上限とは別の「acceleration limits(急増抑制の制限)」に触れて429が返ることもあります。トラフィックを一気に増やすのではなく、段階的にランプアップして一定のパターンを保つことが、この種の429を避ける公式の推奨です。

キャッシュヒット率80%で実効ITPMが5倍になる計算

公式ドキュメントが挙げる例はこうです。ITPM上限が200万トークン/分でキャッシュヒット率が80%のとき、実効的には1分あたり1,000万トークン(非キャッシュ200万+キャッシュ済み800万)を処理できます。キャッシュヒット率をhとすると、実効容量は次の式で近似できます。

実効ITPM ≈ ITPM上限 ÷ (1 - キャッシュヒット率)

Build tier(Claude Opus 5・Sonnet 5などで500万ITPM)を例に、ヒット率ごとの実効容量を並べると効き方の差が分かります。

キャッシュヒット率が95%を超える帯域では、ITPM上限そのものを引き上げるより、キャッシュ設計を見直すほうがレバレッジが大きくなります。システムプロンプト・ツール定義・長文コンテキストなど繰り返し送る内容をキャッシュ対象にすることが、レート制限緩和の実質的な手段になります。

ティアごとのITPM上限とキャッシュの掛かり方

ITPM上限はティア(Start / Build / Scale)とモデルの組み合わせごとに決まります。代表的なモデルのITPM上限は次の通りです(RPM・OTPMは割愛)。

上限はFable / Opus 4.x / Sonnet 4.xでそれぞれ合算バケットが分かれます(Fable 5.1とFable 5は合算、Opus 4.8/4.7/4.6/4.5は合算、Sonnet 4.6/4.5は合算。Opus 5・Sonnet 5は単独バケット)。同じ組織でも複数モデルを並行利用すれば、モデルごとの上限を別々に消費できます。キャッシュの非算入効果はHaiku 3.5を除く全モデルに等しく掛かるため、Scale tierでヒット率80%ならOpus 5・Sonnet 5などの実効ITPMは1モデルあたり5,000万トークン/分相当まで伸びます。

レスポンスのusageフィールドでキャッシュ挙動を確認する

キャッシュがITPMにどう効いているかは、実装側でも検証できます。Messages APIのレスポンスにある usage オブジェクトを見れば、リクエストごとに input_tokens / cache_creation_input_tokens / cache_read_input_tokens の内訳が分かります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":100,"messages":[...]}' \
  | jq .usage

cache_creation_input_tokens と cache_read_input_tokens が両方0なら、そのリクエストはキャッシュされていません(最小トークン数の条件を満たしていない可能性があります)。継続的に呼ぶワークロードでは、この内訳をログに残しておくと、ITPM上限に当たり始めたときに「キャッシュが効いていないだけ」なのか「本当にトラフィックが増えた」のかを、レスポンスヘッダーを見るより先に切り分けられます。

Haiku 3.5だけがcache_read_input_tokensをITPM消費に含める

この「キャッシュはITPMを消費しない」というルールには唯一の例外があります。Claude Haiku 3.5(Bedrock・Google Cloud以外では提供終了済み)は、cache_read_input_tokensもITPM制限にそのまま算入します。他の全モデル(Opus 5・Sonnet 5・Sonnet 4.x・Opus 4.x・Haiku 4.5・Fable 5.x)はキャッシュ読み込み分を除外する新方式です。

Haiku 3.5のITPM上限自体もStart tierで10万トークン/分と、他モデルの2,000,000トークン/分に比べて一桁以上小さく設定されています。旧世代モデルのレート制限インフラがキャッシュ非算入方式に移行していないことが、上限値の低さと合わせて表れている形です。Haiku 3.5からHaiku 4.5への移行は、料金だけでなくレート制限の実効容量という観点でも効果があります。移行後に429エラーの出方が変わった場合は、Claude rate limitエラーの対処で切り分け手順を確認できます。

プロンプトキャッシュ自体の仕組みと課金・サブスク上限への効き方はClaudeのプロンプトキャッシュの仕組みで扱っています。本記事はそのうちレート制限(ITPM)への効き方だけを掘り下げています。

この設計はAnthropicの何を狙っているか

TPM(トークン/分)を全トークン合算で管理する方式は運用側の実装が単純ですが、ユーザーには「キャッシュを使っても上限は変わらない」という体験になります。Claude APIがキャッシュ読み込みを除外する設計を採ったのは、プロンプトキャッシュの利用を積極的に後押しする狙いがあります。キャッシュ読み込みは課金上も基準価格の10%(Claude Fable 5.1・Mythos 5.1は2.5%)に割り引かれており、コスト面とレート制限面の両方でキャッシュ活用にインセンティブを与える一貫した設計です。

ITPM上限の引き上げ申請(Request rate limit increase)を出す前に、まずキャッシュヒット率を確認する価値があります。Usageページの「Rate Limit - Input Tokens」チャートは、時間あたりの非キャッシュ入力トークン最大値・現在のITPM上限・入力トークンのキャッシュ率を並べて表示するため、上限を上げるべきかキャッシュ設計を見直すべきかの判断材料になります。

まとめ — キャッシュ戦略はITPM回避策として機能する

Claude APIのITPM制限は、input_tokensとcache_creation_input_tokensの合計だけを見て、cache_read_input_tokensを除外します(Haiku 3.5を除く)。キャッシュヒット率80%で実効ITPMは5倍、95%で20倍に達します。システムプロンプトやツール定義、長大なコンテキストドキュメントを繰り返し送信するワークロードでは、レート制限に頻繁に当たる前にプロンプトキャッシュの設計を見直すのが先決です。Haiku 3.5からの移行を予定しているなら、この非算入ルールの恩恵も移行メリットに数えられます。ITPM上限の引き上げを申請する前に、まず自分のワークロードのキャッシュヒット率を確認することが最初のステップです。