Claude Codeの料金プラン別の制限構造とレート制限の基礎を解説

Claude Codeには、APIのレート制限（RPM／ITPM／OTPM）と、製品側のセッション上限（約5時間ごとにリセット）、および週次の利用枠が存在します。上限に達するとHTTP 429（Too Many Requests）が返り、レスポンスヘッダーにはretry-afterやanthropic-ratelimit-*が含まれます。 またPro／Maxでは、モデル別の想定利用時間や、上限到達後に継続できるExtra usage（従量課金）も提供されています。

本記事では、制限の体系、プランごとの違い、429エラーの判定と対処、リトライ設計、上限超過後の継続運用、ログの見方までを整理します。

目次

• 制限の全体構造を整理する（APIレートと製品上限）
• プラン別の上限と利用イメージを押さえる（Pro／Max）
• CLIとWebで共通する利用枠を理解する
• 429エラーの判定とヘッダー情報の読み方
• 上限到達後も停止させない運用設計（Extra usageの活用）
• リトライ設計と待機・平滑化・冪等性の考え方
• バッチ運用による非リアルタイム処理のオフロード
• ログと可視化における着眼点
• まとめ

制限の全体構造を整理する（APIレートと製品上限）

まずは、Claude Codeで遭遇し得る制限を、適用対象と症状、確認ポイントの観点で整理します。

この区分を把握しておくと、429が API側の瞬間的なレート超過 なのか、 製品側のセッションや週次枠の到達 なのかを切り分けやすくなります。

代表的なエラーコードの違いは次の通りです。

• 429 は利用側の上限到達（RPM／ITPM／OTPM）を意味します。

• 529 はサービス側の混雑を表し、時間をおいて再試行すると解消する場合が多くあります。

プラン別の上限と利用イメージを押さえる（Pro／Max）

同じClaude Codeでも、プランによって到達しやすい上限や利用できる時間の目安が変わります。代表的な違いを整理します。

表の数値やリセット仕様は 公式 ヘルプ の記載に基づ く目安であり、コードベース規模や自動承認設定、並列度で実効は変動します。週次枠（想定時間）はモデル別に差がある点にも注意してください。

CLIとWebで共通する利用枠を理解する

Claude CodeのCLIとWeb版（ClaudeおよびClaude Code on the web）は、実行面に違いはあるものの、 同じプランの利用枠を共有 します。

• Web版とCLIは共通の契約枠を消費し、どちらの利用も合算でカウントされます。

• 並行実行が増えるほど、5時間ごとのセッション枠や週次の利用枠に早く到達します。

• 上限に達した場合、設定に応じてExtra usageへの切り替え確認が表示されます。

• 即時応答が求められる処理はWeb／APIで実行し、大量処理や非リアルタイム処理はBatches APIに切り離すと、枠を圧迫しにくくなります。

この前提を押さえたうえで設計すると、「どこで実行しても同じ枠が減っていく」という前提を前提条件として組み込めるため、運用中の想定外の詰まりを減らせます。

429エラーの判定とヘッダー情報の読み方

429は「レート・トークンいずれかの上限到達」を示し、レスポンスヘッダーに復帰の目安が含まれます。

HTTP 429の応答例（抜粋）

HTTP/1.1 429 Too Many Requests
retry-after: 17
anthropic-ratelimit-requests-limit: 50
anthropic-ratelimit-requests-remaining: 0
anthropic-ratelimit-input-tokens-remaining: 0
anthropic-ratelimit-output-tokens-remaining: 7600
content-type: application/json

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "Requests per minute limit exceeded for model."
  }
}

この応答から、次の点を確認できます。

• retry-after は再試行までの待機秒数であり、この値より早く再送すると失敗が続きやすくなります。

• anthropic-ratelimit-* は上限値、残量、復元タイミングなどを表し、どの指標が先に枯渇したか（RPMかITPM／OTPMか）を判断する材料になります。

• 近い性質のエラーとして、サービス過負荷を示す529 overloaded_error や、リクエストサイズ超過を示す413 request_too_large も存在します。

実務では、これらのヘッダー情報を必ずログに出力し、 どの閾値に当たっているのか を即時に判定できる状態にしておくと、原因特定と復旧が早くなります。

上限到達後も停止させない運用設計（Extra usageの活用）

上限到達後も業務を継続する必要がある場合には、 Extra usage を有効にすることで従量課金に切り替え、そのまま利用を継続できます。

Extra usageの設定は、Claudeの設定画面の「設定 > 使用量」から行い、月ごとの上限額や自動チャージの有無などを制御できます。従量制に移行したくない場合は、提示される確認画面で従量利用を拒否し、セッションのリセットや週次枠の復帰を待機する運用も選択できます。

画面上では、従量利用の状況や料金が確認でき、月内の利用見通しも把握しやすくなっています。

Extra usageはClaudeの通常の会話とClaude Codeの操作の両方に適用され、 両方のUIでの利用が合算 される点に注意が必要です。

追加使用量はClaudeの会話とClaude Codeの両方に適用され、 両UIの合算 でカウントされます。

リトライ設計と待機・平滑化・冪等性の考え方

再試行の設計では、「どのように待つか」と「同じ処理を繰り返しても安全か」の二点が重要になります。

• retry-afterの値を最優先で尊重し、その上で指数バックオフとジッタを組み合わせて再送間隔を調整します。

• モデルや用途ごとにキューを分け、送信を平滑化することで、短時間の急増による加速度制限を避けます。

• max_tokensや入力長を見直し、ITPM／OTPMの見積もりが過大にならないようにします。長文はプロンプトキャッシュの活用も検討します。

• 同一処理を再実行したときに副作用が発生しないよう、リクエストIDや状態管理を設計し、冪等性を確保します。

ヘッダー仕様とレート制限の考え方を理解したうえでこれらを実装すると、429が発生した際にも、業務全体の遅延を最小限に抑えながら復帰できます。

バッチ運用による非リアルタイム処理のオフロード

即時性が求められない処理は、Message Batches APIに切り離すことで、安定性とコストの双方を改善できます。

大量処理は、オンライン向けとバッチ向けを明確に分けることで、ピーク時間帯の衝突を避けやすくなります。

ログと可視化における着眼点

ボトルネックの特定は、 レスポンスヘッダー と 設定やUsage画面 の両方を活用して行います。

• アプリケーション側では、anthropic-ratelimit-*とretry-afterを必ずログに保存し、ダッシュボードなどで可視化します。

• 設定や使用量の画面では、現在の消費状況やExtra usageの費用、週次枠の消費状況を確認します。

• モデル別・時間帯別にどこで詰まりが発生しているかを把握し、送信計画（平準化、モデル切り替え、max_tokensの見直し）に反映します。

この運用を継続することで、「どの上限に」「どの時間帯に」「どのモデルで」詰まりが生じているかを定量的に把握でき、費用と性能のバランスをとりやすくなります。

まとめ

Claude Codeの制限は、 APIの瞬間的レート（RPM／ITPM／OTPM）と製品側のセッション上限（5時間リセット）＋週次枠 で成り立ちます。まずは429エラー発生時にレスポンスヘッダーを確認し、どの閾値に達したのかを判断することが重要です。 設計面ではretry-after準拠のバックオフと送信平滑化、max_tokensや入力長の見直し、モデル選択の最適化を前提にし、即時性の要らない処理はMessage Batches APIへ切り離すのが安全です。 上限到達後も停止させない運用が必要なら、Extra usage（従量制）を適切に用いて継続し、費用コントロールを並走させてください。プラン別の想定時間や切替仕様は更新され得るため、公式ヘルプの最新情報に合わせて運用ポリシーを定期的に更新することを推奨します。