レート制限

制限には2種類あります。

1. 支出制限は、組織がAPI使用に対して発生させることができる月間最大コストを設定します。
2. レート制限は、組織が一定期間内に実行できるAPIリクエストの最大数を設定します。

APIは組織レベルでサービス設定の制限を適用しますが、組織のワークスペースに対してユーザー設定可能な制限を設定することもできます。

これらの制限は、Standard TierとPriority Tierの両方の使用に適用されます。コミットされた支出と引き換えに強化されたサービスレベルを提供するPriority Tierの詳細については、サービスティアを参照してください。

レート制限について

• 制限は、一般的な顧客の使用パターンへの影響を最小限に抑えながら、APIの不正使用を防ぐように設計されています。
• 制限は使用ティアによって定義され、各ティアは異なる支出制限とレート制限のセットに関連付けられています。
• APIの使用中に特定のしきい値に達すると、組織は自動的にティアが上がります。 制限は組織レベルで設定されます。組織の制限は、Claude ConsoleのLimitsページで確認できます。
• より短い時間間隔でレート制限に達する場合があります。たとえば、1分あたり60リクエスト（RPM）のレートは、1秒あたり1リクエストとして適用される場合があります。短時間のリクエストバーストは制限を超え、レート制限エラーを引き起こす可能性があります。
• 以下に示す制限は標準ティアの制限です。より高いカスタム制限や、強化されたサービスレベルのためのPriority Tierをお求めの場合は、Limitsページから営業担当にお問い合わせください。
• APIはトークンバケットアルゴリズムを使用してレート制限を行います。これは、固定間隔でリセットされるのではなく、キャパシティが最大制限まで継続的に補充されることを意味します。
• ここで説明するすべての制限は、保証された最小値ではなく、許可される最大使用量を表しています。これらの制限は、意図しない過剰支出を減らし、ユーザー間でリソースを公平に分配することを目的としています。

支出制限

各使用ティアには、暦月ごとにAPIに支出できる金額の制限があります。ティアの支出制限に達すると、次のティアの資格を得るまで、翌月までAPIを再度使用できるようになるのを待つ必要があります。

次のティアの資格を得るには、デポジット要件を満たす必要があります。アカウントへの過剰入金のリスクを最小限に抑えるため、月間支出制限を超える金額をデポジットすることはできません。

ティア昇格の要件

支出制限の引き上げ

組織には2種類の支出制限があります。直接管理できる顧客設定の制限と、使用ティアによって設定されるティア適用の上限です。それぞれ引き上げのプロセスが異なります。

顧客設定の支出制限

コストを管理するために、ティアの上限よりも低い支出制限を設定できます。調整するには：

ティア適用の支出制限

ティアの上限（Tier 4の上限は月額$200,000）よりも高い制限が必要な場合は、LimitsページでContact Salesをクリックします。これにより、新しいタブでお問い合わせフォームが開き、組織がアップグレードされると営業チームのメンバーがメールでフォローアップします。

月次請求では月間支出上限が完全に撤廃され、デフォルトでNet-30の支払い条件が使用されます。

レート制限

Messages APIのレート制限は、各モデルクラスごとに「requests per minute」（1分あたりのリクエスト数）、すなわちRPM、「input tokens per minute」（1分あたりの入力トークン数）、すなわちITPM、および「output tokens per minute」（1分あたりの出力トークン数）、すなわちOTPMで測定されます。 いずれかのレート制限を超えると、どのレート制限を超えたかを説明する429エラーが、待機時間を示すretry-afterヘッダーとともに返されます。

キャッシュ対応ITPM

多くのAPIプロバイダーは、キャッシュされたトークンとキャッシュされていないトークン、入力と出力のすべてのトークンを含む可能性のある、統合された「tokens per minute」（1分あたりのトークン数）、すなわちTPM制限を使用しています。ほとんどのClaudeモデルでは、キャッシュされていない入力トークンのみがITPMレート制限にカウントされます。 これは、レート制限が最初に見えるよりも実質的に高くなる重要な利点です。

ITPMレート制限は各リクエストの開始時に推定され、その推定値はリクエスト中に実際に使用された入力トークン数を反映するように調整されます。

ITPMにカウントされるものは以下のとおりです。

• 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

例：2,000,000 ITPMの制限と80%のキャッシュヒット率がある場合、キャッシュされたトークンはレート制限にカウントされないため、実質的に1分あたり合計10,000,000の入力トークン（キャッシュされていない2M + キャッシュされた8M）を処理できます。

OTPMレート制限は、出力トークンが生成されるにつれてリアルタイムで評価され、実際に生成されたトークンのみがカウントされます。max_tokensパラメータはOTPMレート制限の計算に影響しないため、より高いmax_tokens値を設定してもレート制限上のデメリットはありません。

レート制限はモデルごとに個別に適用されるため、異なるモデルをそれぞれの制限まで同時に使用できます。 現在のレート制限と動作はClaude Consoleで確認できます。また、Rate Limits APIを使用して設定された制限をプログラムで読み取ることもできます。

^{* - Opusのレート制限は、Claude Opus 4.8、Opus 4.7、Opus 4.6、Opus 4.5、Opus 4.1（非推奨）、およびOpus 4（非推奨）の合計トラフィックに適用される合計制限です。}

^{** - Sonnet 4.xのレート制限は、Sonnet 4.6、Sonnet 4.5、およびSonnet 4（非推奨）の合計トラフィックに適用される合計制限です。}

^{† - この制限はcache_read_input_tokensをITPM使用量にカウントします。}

Message Batches API

Message Batches APIには、すべてのモデルで共有される独自のレート制限セットがあります。これには、すべてのAPIエンドポイントに対する1分あたりのリクエスト数（RPM）制限と、同時に処理キューに入れることができるバッチリクエスト数の制限が含まれます。ここでの「バッチリクエスト」とは、Message Batchの一部を指します。数千のバッチリクエストを含むMessage Batchを作成でき、それぞれがこの制限にカウントされます。バッチリクエストは、モデルによってまだ正常に処理されていない場合、処理キューの一部と見なされます。

マネージドエージェント

Claude Managed Agentsのエンドポイントは、組織ごとにレート制限されます。これらの制限は、上記のMessages APIのレート制限とは別です。

高速モードのレート制限

Claude Opus 4.8、Opus 4.7、またはOpus 4.6でspeed: "fast"を指定して高速モード（リサーチプレビュー）を使用する場合、標準のOpusレート制限とは別の専用レート制限が適用されます。高速モードのレート制限を超えると、APIはretry-afterヘッダーとともに429エラーを返します。

レスポンスには、高速モードのレート制限ステータスを示すanthropic-fast-*ヘッダーが含まれます。これらのヘッダーの詳細については、高速モードを参照してください。

Consoleでのレート制限の監視

Claude ConsoleのUsageページでレート制限の使用状況を監視できます。

トークンとリクエストのチャートに加えて、Usageページには2つの個別のレート制限チャートが用意されています。これらのチャートを使用して、成長の余地、ピーク使用に達している可能性のあるタイミング、リクエストすべきレート制限、またはキャッシング率を改善する方法をより深く理解できます。チャートは、特定のレート制限（たとえば、モデルごと）に対する多数のメトリクスを視覚化します。

• Rate Limit - Input Tokensチャートには以下が含まれます。
  • 1時間ごとの1分あたりの最大キャッシュされていない入力トークン数
  • 現在の1分あたりの入力トークン数のレート制限
  • 入力トークンのキャッシュ率（つまり、キャッシュから読み取られた入力トークンの割合）
• Rate Limit - Output Tokensチャートには以下が含まれます。
  • 1時間ごとの1分あたりの最大出力トークン数
  • 現在の1分あたりの出力トークン数のレート制限

ワークスペースに対するより低い制限の設定

ワークスペースの詳細については、ワークスペースを参照してください。

組織内のワークスペースを潜在的な過剰使用から保護するために、ワークスペースごとにカスタムの支出制限とレート制限を設定できます。

例：組織の制限が1分あたり40,000入力トークンと1分あたり8,000出力トークンの場合、1つのワークスペースを1分あたり30,000入力トークンに制限できます。これにより、他のワークスペースを潜在的な過剰使用から保護し、組織全体でリソースをより公平に分配できます。残りの未使用の1分あたりのトークン（またはそのワークスペースが制限を使用しない場合はそれ以上）は、他のワークスペースで使用できます。

注意：

• デフォルトのワークスペースには制限を設定できません。
• 設定されていない場合、ワークスペースの制限は組織の制限と一致します。
• ワークスペースの制限は、リミッタータイプごと（1分あたりのリクエスト数、1分あたりの入力トークン数、1分あたりの出力トークン数など）に設定されます。
• ワークスペースの制限の合計がそれを超える場合でも、組織全体の制限は常に適用されます。

現在の組織およびワークスペースのレート制限をプログラムで読み取るには、Rate Limits APIを使用してください。

レスポンスヘッダー

APIレスポンスには、適用されたレート制限、現在の使用状況、および制限がリセットされるタイミングを示すヘッダーが含まれます。

以下のヘッダーが返されます。

anthropic-ratelimit-tokens-*ヘッダーは、現在有効な最も制限の厳しい制限の値を表示します。たとえば、ワークスペースの1分あたりのトークン制限を超えた場合、ヘッダーにはワークスペースの1分あたりのトークンレート制限値が含まれます。ワークスペースの制限が適用されない場合、ヘッダーは残りの合計トークン数を返します。ここで合計とは入力トークンと出力トークンの合計です。このアプローチにより、現在のAPI使用に対する最も関連性の高い制約を把握できます。