レート制限

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

1. 使用量上限（Spend limits） は、組織がAPI使用に対して負担できる月間の最大コストを設定します。
2. レート制限（Rate limits） は、組織が定められた期間内に行えるAPIリクエストの最大数を設定します。

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

レート制限について

• 制限は、一般的なお客様の使用パターンへの影響を最小限に抑えつつ、APIの悪用を防ぐように設計されています。
• 制限は使用量ティア（usage tier）によって定義されます。組織は使用履歴とアカウントの状態に基づいて自動的にティアに配置され、APIを使用するにつれて時間とともにより高いティアに移行できます。
• 新しい組織や使用履歴が限られている組織は、アカウント履歴が確立されるまでの間、このページに示されている標準の制限よりも低い制限が適用されるEvaluationティアから開始する場合があります。これらの初期制限は、Anthropicが不正行為や悪用を防止する仕組みの一部であり、組織が使用履歴を積み重ねるにつれて自動的に引き上げられます。
• 制限は組織レベルで設定されます。組織のティアと現在の制限は、Claude ConsoleのRate limitsページで確認できます。
• より短い時間間隔でレート制限に達する場合があります。たとえば、1分あたり60リクエスト（RPM）のレートは、1秒あたり1リクエストとして適用される場合があります。短時間に集中したリクエストは制限を超え、レート制限エラーを引き起こす可能性があります。
• 以下の制限は各ティアの標準の制限です。より高い制限が必要な場合は、より高い制限のリクエストを参照してください。
• APIはレート制限にトークンバケットアルゴリズムを使用しています。これは、キャパシティが固定間隔でリセットされるのではなく、最大制限まで継続的に補充されることを意味します。
• ここで説明するすべての制限は、保証された最小値ではなく、許可される最大使用量を表します。これらの制限は、意図しない過剰な支出を減らし、ユーザー間でリソースを公平に分配することを目的としています。

使用量上限

Start、Build、Scaleの各ティアには月間使用量上限があり、これは組織が各暦月にAPIに対して支出できる最大額です。組織の月間使用量上限の確認と独自の上限の設定は、Billingページで行えます。

Customティアの組織には月間使用量上限はありません。制限はアカウントチームとの取り決めによって設定されます。

使用量上限に達した場合

ティアの使用量上限に達すると、より早く高い制限をリクエストしない限り、API使用は翌月1日の00:00 UTCまで一時停止されます。使用が一時停止されている間、APIリクエストはHTTP 429を返します。

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "You have reached your API usage limits: your organization has crossed its monthly API usage threshold, set based on your organization's API tier. You will regain access on 2026-09-01 at 00:00 UTC.",
    "details": { "error_code": "enforced_spend_limit_reached" }
  },
  "request_id": "req_018EeWyXxfu5pfWkrYcMdjWG"
}

• エラータイプはレート制限の場合と同じrate_limit_errorですが、レスポンスにはretry-afterヘッダーがありません。再試行（SDKの自動再試行を含む）は、アクセスが再開されるまで失敗します。
• Messages APIでは、error.details.error_codeはenforced_spend_limit_reachedになります。これを使用して、このレスポンスをレート制限と区別してください。
• 上位のティアに移行するとアクセスが回復します。より高い制限のリクエストを参照してください。

独自の使用量上限の設定

コストを管理するために、ティアの上限よりも低い独自の使用量上限を設定することもできます。

1. 1

   Billingページに移動する

   Claude ConsoleでSettings > Billingに移動します。

2. 2

   使用量上限エディターを開く

   Spend limitsセクションで、Adjust limit（現在上限が設定されていない場合はSet limit）をクリックします。

3. 3

   使用量上限を調整する

   新しい値を入力します。使用量上限は現在のティアの上限を超えることはできません。

使用量が設定した使用量上限に達すると、リクエストはエラータイプinvalid_request_errorのHTTP 400を返します。メッセージはYou have reached your specified API usage limits、またはワークスペースの上限の場合はYou have reached your specified workspace API usage limitsで始まり、アクセスがいつ再開されるかが記載されます。より早くアクセスを回復するには、上限を引き上げるか削除してください。

Claude Codeワークスペースの上限は別途チェックされます。そのワークスペースの上限を超えたClaude Codeリクエストは、代わりにretry-afterヘッダーを含む429を受け取る場合があります。

レート制限

Messages APIのレート制限は、各モデルクラスについて、1分あたりのリクエスト数（RPM）、1分あたりの入力トークン数（ITPM）、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にカウントされない

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

レート制限を最大限に活用するには、システム指示やプロンプト、大きなコンテキストドキュメント、ツール定義、会話履歴などの繰り返しコンテンツをキャッシュしてください。ガイダンスについてはプロンプトキャッシングを参照してください。効果的なキャッシングにより、レート制限を引き上げることなく実際のスループットを大幅に向上させることができます。キャッシング戦略を調整するには、Usageページでキャッシュヒット率を監視してください。

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

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

^{1 Fableのレート制限は、Claude Fable 5.1とClaude Fable 5の合計トラフィックに適用される合計制限です。Claude Mythos 5.1とClaude Mythos 5は、同じ条件で別の合計制限を共有します。}

^{2 Opusのレート制限は、Claude Opus 4.8、Opus 4.7、Opus 4.6、Opus 4.5の合計トラフィックに適用される合計制限です。Claude Opus 5.5とClaude Opus 5はそれぞれ個別のレート制限を持ち、この合計バケットには含まれません。}

^{3 Sonnet 4.xのレート制限は、Sonnet 4.6とSonnet 4.5（非推奨）の合計トラフィックに適用される合計制限です。Claude Sonnet 5.5とClaude Sonnet 5はそれぞれ個別のレート制限を持ち、この合計バケットには含まれません。}

^{4 この制限ではcache_read_input_tokensがITPM使用量にカウントされます。}

Message Batches API

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

Managed Agents

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

Files API

Files APIのリクエストには組織ごとの独自の制限があり、アップロード、一覧、取得、ダウンロード、削除の各操作で共有され、このページで前述したMessages APIの制限とは別のものです。現在の値については、Files APIのレート制限を参照してください。

Fast modeのレート制限

fast mode（リサーチプレビュー）をspeed: "fast"でClaude Opus 5.5、Claude Opus 5、またはOpus 4.8に対して使用する場合、標準のOpusレート制限とは別の専用レート制限が適用されます。fast modeのレート制限を超えると、APIはretry-afterヘッダー付きの429エラーを返します。fast modeはClaude Opus 4.7（リクエストはエラーを返します）およびClaude Opus 4.6（speed: "fast"を指定したclaude-opus-4-6へのリクエストは標準速度で実行されます）では利用できません。Fast modeを参照してください。

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

Consoleでのレート制限の監視

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

Usageページでは、トークンとリクエストのチャートに加えて、2つの独立したレート制限チャートが提供されます。これらのチャートを使用して、成長の余地がどれだけあるかを確認し、ピーク使用に達している可能性のある時期を特定し、どのレート制限をリクエストすべきかを理解し、キャッシュ率を改善する方法を把握できます。チャートは、特定のレート制限（たとえばモデルごと）に関する複数のメトリクスを可視化します。

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

より高い制限のリクエスト

より高いレート制限またはより高い月間使用量上限をリクエストするには、Rate limitsページのRequest rate limit increaseを使用してください。Anthropicサポートも制限を引き上げることができます。緊急の場合は、Anthropicサポートにお問い合わせください。

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

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

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

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

注意：

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

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

レスポンスヘッダー

APIレスポンスには、適用されているレート制限、現在の使用量、および制限がリセットされる時刻を示すヘッダーが含まれます。

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

anthropic-ratelimit-tokens-*ヘッダーは、現在有効な最も厳しい制限の値を表示します。たとえば、ワークスペースの1分あたりのトークン制限を超えた場合、ヘッダーにはワークスペースの1分あたりのトークンレート制限の値が含まれます。ワークスペースの制限が適用されない場合、ヘッダーは残りの合計トークン数を返します。ここでの合計とは、入力トークンと出力トークンの合計です。このアプローチにより、現在のAPI使用に対する最も関連性の高い制約を把握できます。リクエストがどのワークスペースに対してカウントされたかを確認するには、anthropic-workspace-idレスポンスヘッダーを読み取ってください。このヘッダーには、APIキーまたはアクセストークンが解決されたワークスペースのIDが含まれます。