fast modeのレート制限は標準のOpusと別枠になる仕組み

fast modeのレート制限は標準Opusと分かれている

Claude APIのfast modeには専用のレート制限があり、標準のOpusレート制限とは別枠で管理されています。標準リクエストをどれだけ送っていても、fast modeの枠は独立して消費されます。逆に、fast modeの枠を使い切っても、標準速度でのリクエストは別枠のまま影響を受けません。Claude Code上での/fastコマンドやキーバインド、サブスク枠との関係はClaude Codeのfast modeで扱っており、ここではClaude APIを直接叩く場合のレート制限と課金の別枠構造を見ます。

fast modeのレート制限を超えると、APIは 429 エラーを、retry-after ヘッダー付きで返します。このヘッダーには、次にリクエストが通る見込みの待機時間が示されます。

fast modeは継続的なトークン補充(continuous token replenishment)という方式でレート制限を管理しているため、retry-after の待機時間は一般に短く済みます。Anthropicの各SDKは、この429エラーに対してデフォルトで最大2回まで自動リトライを行い(max_retriesで変更可能)、サーバーが指定した遅延を待ってから再送します。

fast modeはresearch preview段階の機能で、利用にはアカウントマネージャーへの申請が必要です。アカウントマネージャーが付いていない組織はウェイトリストに登録して利用開始を待つ形になります。レート制限の設計を検討する前に、そもそも自組織がfast modeへのアクセスを持っているかを、まず確認します。

専用レスポンスヘッダー6種で残量を追跡する

fast modeのレスポンスには、レート制限の残量を示す専用ヘッダーが6種類含まれます。標準Opusのレート制限ヘッダーとは別物なので、監視システムを組むときは取り違えやすく、プレフィックスで見分けます。

ティアごとの具体的な数値は、公式のRate limitsページで確認します。fast modeを本番運用に組み込むなら、-remaining の値をログに残しておくと、429が実際に発生する前に枠の逼迫を検知できます。

Opus 4.6でfast modeを要求するとエラーにならず黙って標準に切り替わる

fast modeの対応モデルはClaude Opus 5とClaude Opus 4.8の2つだけです。この2モデル以外に speed: "fast" を指定したときの挙動が、モデルによって大きく異なります。

Claude Opus 4.7に対して speed: "fast" を指定すると、エラーが返ります。標準速度へのフォールバックは起きません。モデル自体は標準速度でなら引き続き利用できますが、fast modeを使い続けたい場合はClaude Opus 5かClaude Opus 4.8への移行が必要です。

Claude Opus 4.6に対して speed: "fast" を指定した場合の挙動は特殊です。エラーは返らず、リクエストは黙って標準速度で実行されます。課金もfast modeのpremium単価ではなく標準単価で行われ、レスポンスの usage.speed フィールドには正確に "standard" と記録されます。つまり、リクエスト自体は失敗せず正常応答が返ってくるため、speed フィールドを確認しない実装では、fast modeが効いていないことに気づかないまま運用してしまう危険があります。

speedフィールドで実際の速度を確認する

レスポンスの usage オブジェクトには speed フィールドが含まれ、"fast" か "standard" のどちらでリクエストが処理されたかを示します。speed: "fast" を要求して成功した場合は "fast" が返り、fast modeに未対応のモデルへ speed: "fast" を指定した場合はエラーになります(Opus 4.6を除く)。fast modeのレート制限や容量を超えた場合(429 または 529)も同様にエラーになります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: fast-mode-2026-02-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "speed": "fast",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

組織全体でのfast mode利用状況とコストを追跡するには、Usage and Cost APIを使います。

レート制限超過時にフォールバックする実装パターン

fast modeのレート制限や容量超過を待たずに、標準速度へその場でフォールバックしたい場合は、レート制限エラーをアプリケーション側で捕捉し、speed: "fast" を外して再送します。この用途では、初回のfast modeリクエストで max_retries を 0 に設定し、SDKの自動リトライを止めて、レート制限エラーを即座に受け取れるようにしておきます。

このオプトインのクライアント側フォールバックは、Claude Opus 4.6で発生する自動フォールバック(fast mode自体が使えないため標準速度で自動実行される挙動)とは別物です。Opus 4.6のケースはモデルがfast modeに対応していないことによる恒常的な挙動であるのに対し、ここで扱うフォールバックはOpus 5・Opus 4.8がレート制限や容量の制約で一時的にfast modeを提供できないときの、開発者が明示的に選ぶ再試行戦略です。

fastから標準速度へフォールバックすると、プロンプトキャッシュがミスします。速度が異なるリクエストはキャッシュされたプレフィックスを共有しないためです。フォールバック処理を設計するときは、この点も踏まえてキャッシュ課金への影響を見込んでおきます。

課金への影響 — 別レート制限と別単価の二重構造

fast modeはレート制限だけでなく、単価も標準速度とは別枠です。Claude Opus 5・Claude Opus 4.8のfast mode単価は入力$10/MTok・出力$50/MTokで、標準単価(入力$5/MTok・出力$25/MTok)のちょうど2倍にあたります。このpremium単価は、200kトークンを超える入力を含む全コンテキスト幅に対して適用されます。

fast modeの単価は他の課金修飾子とも重なります。プロンプトキャッシュの倍率(cache write / cache read)はfast mode単価の上にさらに乗り、データレジデンシーの倍率も同様にfast mode単価の上に乗ります。したがって、fast mode + 1時間キャッシュ書き込み + 米国限定インフェレンスを組み合わせると、複数の倍率が積み重なった単価になる点に注意が必要です。

レート制限枠と単価が別枠であることは、コスト管理の観点でも意味を持ちます。標準速度のリクエストがレート制限に達していない状況でも、fast modeだけ先に枠を使い切ることがあり得ますし、逆にfast modeの単価がpremiumだからといって標準速度のレート制限に余裕が生まれるわけでもありません。

fast modeが使えない・向かない組み合わせ

レート制限や課金の設計を組む前に、fast modeそのものが使えない構成を把握しておくと手戻りを減らせます。

• Batch API: fast modeはBatch APIでは利用できません
• Priority Tier: Priority Tierのコミットメントとfast modeは併用できません
• Claude Platform on AWS: fast modeは提供されていません。Amazon Bedrock・Google Cloud・Microsoft Foundryといったパートナー運用クラウド全般でも同様に利用できず、Claude API(第一者)とClaude Managed Agentsに限られます
• TTFTの短縮は狙えない: fast modeの効果はOTPS(output tokens per second)に集中しており、time-to-first-tokenの短縮は狙えません。TTFTを縮めたい場合は事前ウォームアップのような別の手段を検討します

まとめ

fast modeのレート制限は、標準Opusのレート制限と完全に独立した専用枠です。専用の6種ヘッダーで残量を追跡でき、超過時は429とretry-afterが返り、継続的なトークン補充のおかげで待機時間は短く済む設計になっています。もっとも注意すべきはOpus 4.6の挙動です。他の非対応モデルと違ってエラーにならず、黙って標準速度・標準課金に切り替わるため、usage.speedを確認しない実装ではfast modeが効いていないことに長期間気づけません。fast modeを本番導入する際は、専用ヘッダーでの残量監視とusage.speedの確認を、最初から運用フローに組み込んでおくと安全です。レート制限・単価・対応モデルの3つが標準速度と別枠になっている前提を押さえておけば、429の切り分けも課金の説明も迷わずに済みます。

fast modeの基本的な仕組みと料金はClaude Opus 5の使い方と仕様、レート制限エラー全般の対処はClaude rate limit(レート制限)エラーの対処、プロンプトキャッシュとの相互作用はプロンプトキャッシュの事前ウォームアップをmax_tokens=0で行う、Claude Code上での操作はClaude Codeのfast modeで扱っています。