Claude Rate Limits APIで組織・ワークスペースのレート制限を確認する

Rate Limits APIで何が取得できるか

Rate Limits APIは、組織とワークスペースに設定されているレート制限をプログラムから読み取るAPIです。Claude Consoleの「Rate limits」ページに出ているのと同じ情報を、コードから取得できます。

エンドポイントは /v1/organizations/rate_limits(組織全体の値)と /v1/organizations/workspaces/{workspace_id}/rate_limits(ワークスペースの上書き値)の2本です。どちらも読み取り専用で、値を書き換えるエンドポイントはありません。

用途は主に3つです。ゲートウェイやプロキシが持つ設定値を、起動時や定期実行で最新化する。Usage and Cost APIで取った消費量と突き合わせ、上限に近づいたら通知する。プロビジョニング自動化が意図した上書き値どおりにワークスペースを設定したかを監査する。

呼び出しに必要な権限

呼べるのは、Admin APIキー、org:admin スコープを持つOAuthトークン、ワークスペースにスコープされていない個人・サービスアカウントキーのいずれかです。ワークスペースAPIキーでは呼び出せません。Admin APIキーの作り方とスコープの選び方はClaude Admin APIキーの取得方法とスコープ選択にあります。

Admin APIは個人アカウントでは使えず、Consoleの「Settings > Organization」で組織を作る必要があります。SDKのクライアントは環境変数 ANTHROPIC_API_KEY からキーを読むので、Admin APIキーをそこへ入れるか、curlなら x-api-key ヘッダーに直接渡します。

2つのエンドポイントは返すものが違う

組織のレート制限を取得する

組織エンドポイントの対象は、Messages APIとその周辺リソースです。Managed Agentsのような別プロダクトの制限は含まれません。

curl "https://api.anthropic.com/v1/organizations/rate_limits" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

レスポンスは「レート制限グループ」の配列です。複数バージョンのモデルは1つのグループに束ねられ、同じ上限を共有します。バッチAPI・Files API・Token Counting API・Skills・Web検索ツールも、それぞれ独立したグループで返ります。各グループの limits には、requests_per_minute のようなリミッター種別ごとの値が並びます。

{
  "data": [
    {
      "type": "rate_limit",
      "group_type": "model_group",
      "group": {
        "type": "model_group",
        "id": "rlg_01Hq7YkP3mZ9dTwRx4cVbN2s",
        "display_name": "Claude Opus 5.5"
      },
      "models": ["claude-opus-5-5"],
      "limits": [
        { "type": "requests_per_minute", "value": 4000 },
        { "type": "input_tokens_per_minute", "value": 10000000 },
        { "type": "output_tokens_per_minute", "value": 800000 }
      ]
    },
    {
      "type": "rate_limit",
      "group_type": "batch",
      "group": { "type": "batch", "id": "rlg_01Wn3pBz6kCg9vHtQ7mLxD5a" },
      "models": null,
      "limits": [{ "type": "enqueued_batch_requests", "value": 500000 }]
    }
  ],
  "next_page": null
}

グループを識別するキーは group.id

このレスポンスで注意したいのは、グループを何で識別するかです。group.id(rlg_ で始まる不透明なID)は、どの組織でもどのワークスペースの上書きでも同じ値で、変わりません。一方、エントリー自身の id は組織ごとに異なり、models はAnthropicがモデルを別グループへ移すと変わります。display_name は表示用のラベルで、変更される可能性があります。

ゲートウェイの設定表やアラートの定義をグループに紐づけるなら、キーは group.id です。group_type は group.type に置き換えられて非推奨ですが、返り続けていて削除予定日もありません。クエリパラメーターの group_type は非推奨ではありません。

モデル名から引く

あるモデルの上限だけ知りたいときは、model にモデルIDかエイリアスを渡します。models には日付付きID(claude-sonnet-4-5-20250929)も日付なしエイリアス(claude-sonnet-4-5)も入っているので、Messages APIに渡している文字列がそのまま使えます。どのモデル文字列も、ちょうど1つの model_group エントリーに入ります。一致するグループが無ければ404です。

curl "https://api.anthropic.com/v1/organizations/rate_limits?model=claude-opus-5" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

ワークスペースの上書きを読み解く

ワークスペース側のレスポンスは「上書きだけ」の差分表です。デフォルトワークスペースには上書きを設定できないため、このエンドポイントにエントリーが出ません。IDはConsoleのワークスペース設定画面か、List Workspacesエンドポイントで調べます。

curl "https://api.anthropic.com/v1/organizations/workspaces/wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ/rate_limits" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

{
  "data": [
    {
      "type": "workspace_rate_limit",
      "group_type": "model_group",
      "group": {
        "type": "model_group",
        "id": "rlg_01Hq7YkP3mZ9dTwRx4cVbN2s",
        "display_name": "Claude Opus 5.5"
      },
      "models": ["claude-opus-5-5"],
      "limits": [
        { "type": "requests_per_minute", "value": 1000, "org_limit": 4000 },
        { "type": "input_tokens_per_minute", "value": 500000, "org_limit": 10000000 }
      ]
    }
  ],
  "next_page": null
}

実効値は、上から順に3段階で決めます。

ワークスペースの上限の合計が組織の上限を超えていても、組織全体の上限は常に効きます。Consoleでの設定例は、組織が入力4万・出力8,000トークン/分のとき、1つのワークスペースを入力3万に抑えると、残りを他のワークスペースが使えるというものです。設定の手順はConsole UIでの設定手順にまとめています。

group_typeで絞り込み、ページを送る

両エンドポイントとも、group_type で特定カテゴリーだけに絞り込めます。値は model_group / batch / token_count / files / skills / web_search の6種類です。公式のCLI(ant)でも同じ操作ができます。

curl "https://api.anthropic.com/v1/organizations/rate_limits?group_type=batch" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"
 
ant beta:organization:rate-limits list --group-type batch
ant beta:organization:workspaces:rate-limits list \
  --workspace-id wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ

ページ送りは page パラメーターと next_page フィールドで行います。現状はレスポンスが常に1ページに収まり、next_page は null です。next_page をたどるループを書いておけば、件数が増えても実装を変えずに済みます。

SDKで呼び出す

Python・TypeScript・C#・Go・Javaでは list() が next_page を追うイテレーターを返すので、ページ送りを自分で書く必要はありません。PHP・Ruby・curlは1ページずつ読む実装です。以下はPythonの例で、グループの種別は group.type から読みます。

client = anthropic.Anthropic()
 
rate_limits = client.beta.organization.rate_limits.list()
 
for entry in rate_limits:
    models = f" ({', '.join(entry.models)})" if entry.models else ""
    print(f"{entry.group.type}{models}")
    for limit in entry.limits:
        print(f"  {limit.type}: {limit.value}")

ワークスペース側は client.beta.organization.workspaces.rate_limits.list(workspace_id) で、ワークスペースIDを引数に渡します。この2つの呼び出しを起動シーケンスに入れておけば、Anthropicが上限を調整してもハードコードした値とずれません。

RPM・ITPM・OTPMの数え方

limits の type に並ぶのは、リクエスト数(RPM)・入力トークン数(ITPM)・出力トークン数(OTPM)です。モデルクラスごとに3種が別々に管理され、どれか1つでも超えると、どの上限を超えたかを説明する429エラーが返ります。

見落としやすいのがキャッシュを考慮したITPMです。ITPMに数えるのは、キャッシュ位置より後の input_tokens と、キャッシュへ書き込む cache_creation_input_tokens です。cache_read_input_tokens は、ほとんどのモデルで数えません。

公式の例では、ITPMが200万で、キャッシュヒット率が80%なら、1分あたり合計1,000万の入力トークンを処理できます。ただしClaude Haiku 3.5は例外で、cache_read_input_tokens もITPMに入ります。このモデルはBedrockとGoogle Cloudを除いて提供を終えています。Rate Limits APIの value は設定された上限であって、キャッシュでどこまで消費を抑えられるかは別の話です。上限を使い切りがちなら、引き上げを依頼する前に、Consoleの「Usage」ページでキャッシュヒット率を確かめる余地があります。ここには、時間ごとの未キャッシュ入力トークンの最大値と現在の上限を重ねたグラフもあります。

429が出たとき、どの上限か切り分ける

429は、レート制限だけで出るエラーではありません。Rate Limits APIで見られるのはレート制限の設定値なので、エラーの原因が別なら、読んでも答えは出ません。

組織の使用量が急に増えたときも、加速制限(acceleration limits)による429が出ることがあります。避けるには、トラフィックを段階的に増やし、使い方を一定に保ちます。

月間の上限はティアごとに決まっていて、Startが500ドル、Buildが1,000ドル、Scaleが20万ドルです。Customティアには上限がありません。新しい組織や利用履歴の少ない組織はEvaluationティアから始まることがあり、その上限は標準値より低く、履歴ができるにつれて自動で上がります。Claude Codeのワークスペースは別枠で判定され、上限を超えたClaude Codeのリクエストには、retry-after 付きの429が返ることがあります。

レスポンスヘッダーとの使い分け

Messages APIの各レスポンスには anthropic-ratelimit-* ヘッダーが付きます。Rate Limits APIが返す設定値に対し、ヘッダーは直近のリクエストを起点にした残量です。

構成管理や監査にはRate Limits APIを、個々のリクエストの消費の追跡にはヘッダーを使います。anthropic-ratelimit-tokens-* ヘッダーには、その時点でいちばん厳しい上限の値が入ります。ワークスペースの上限を超えていればその値、ワークスペースの上限が効いていなければ入出力の合計トークンの残りです。どのワークスペースで計上されたかは anthropic-workspace-id ヘッダーで分かります。429が続いて上限の不足を疑うときの順序は、Claude APIの429でレート制限が低すぎると感じたときの確認手順にあります。

Claude Platform on AWSでは

Claude Platform on AWSでも、レート制限の値は同じです。ただしワークスペース単位のレート制限の設定と「Request tier increase」の流れは使えないため、引き上げはAnthropicの担当者かサポートへ依頼します。Tierの上がり方と申請の条件はClaude APIのレート制限を引き上げる方法にあります。

Managed Agentsの制限は別の系統

Claude Managed Agentsのエンドポイントには、組織単位の別枠の制限がかかります。作成系(エージェント・セッション・環境など)は1分あたり300リクエスト、参照系(取得・一覧・ストリーム)は1分あたり1,200リクエストです。この値はMessages APIの上限とは別で、Rate Limits APIの組織エンドポイントのレスポンスにも含まれません。

両方を使っている組織が監視ダッシュボードを作るなら、Rate Limits APIで読める上限と、レート制限のドキュメントに載っているManaged Agentsの値を、別の系統として持つ必要があります。

よくあるつまずき

• 値を更新しようとして失敗する: Rate Limits APIは読み取り専用です。変更は、ConsoleのRate limitsページでWorkspaceドロップダウンから対象を選んで行います
• デフォルトワークスペースを指定しても応答に何も出ない: デフォルトワークスペースには上書きを設定できないので、エントリーがありません。値は組織エンドポイントで読みます
• ワークスペースのAPIキーで呼べない: ワークスペースにスコープされたキーは使えません。Admin APIキーか、ワークスペースにスコープされていない個人・サービスアカウントキーに替えます
• ワークスペースエンドポイントで model が使えない: model は組織エンドポイント専用で、ワークスペースエンドポイントは受け付けません。ワークスペース側で特定モデルを見るなら、全体を取ってからクライアント側で絞ります
• display_name や models をキーにしたら、あるとき一致しなくなった: どちらも変わりえます。グループのキーは group.id にします

まとめ

Rate Limits APIで読めるのは設定値だけです。組織エンドポイントの値と、ワークスペースの上書き(足りない項目は組織を継承)を突き合わせれば、実効的な上限が分かります。429の原因がレート制限とは限らないため、エラーコードと retry-after の有無を先に見てから、どの値を読むか決めます。