Claude APIでWorkspace単位のレート制限を設定する手順
Claude ConsoleでWorkspaceごとにAPIレート制限を組織全体の上限より低く絞る設定手順と、Default Workspaceが対象外になる等の制約を解説します。
Claude APIのレート制限は組織(Organization)単位で決まりますが、Workspaceごとに組織の上限より低い独自の値を設定できます。複数のチームやプロジェクトが同じ組織を共有しているとき、1つのWorkspaceがトークンを使い切って他のWorkspaceのリクエストが詰まる事態を防げます。
Workspaceのレート制限は、ConsoleのRate limitsページでWorkspaceを選んで設定します。この記事では、設定の前に決めておくこと、Consoleでの手順、反映の確かめ方、上限に当たったときのエラーの見分け方を扱います。ロールの継承やAPIキーのスコープはClaude Workspacesのロール継承とAPIキーのスコープにあります。ワークスペースの作成からメンバー追加、支出上限までを通しで進める手順はClaude Consoleでワークスペースを作成する手順にまとめています。
設定する前に決めておくこと
Workspaceのレート制限には、先に押さえておくと迷いにくい前提が4つあります。
- 誰が設定できるか: Workspaceを作れるのは組織のadminだけです。組織のadminは全WorkspaceでWorkspace Adminを自動で持ち、Workspace AdminはWorkspaceの設定とメンバーを完全に管理できます。
- 対象にならないもの: Default Workspaceには上限を設定できません。Claude Platform on AWSでは、Workspaceごとのレート制限設定そのものが使えません。
- 値の向き: Workspaceの上限は組織の上限より低くはできても、高くはできません。未設定なら組織の上限と同じ値になります。
- 制限の粒度: リクエスト数/分(RPM)、入力トークン/分(ITPM)、出力トークン/分(OTPM)は、制限の種類ごとに別々に設定します。
Consoleで上限を設定する
Workspaceのレート制限を設定する流れ
- 1
Rate limitsページでWorkspaceを選ぶ
Claude Consoleにサインインし、Rate limitsページを開きます。Workspaceのドロップダウンから対象を選びます。まだ無ければSettings > WorkspacesのCreate workspaceで作ります。
- 2
モデルの横のEditを押す
絞りたいモデルの横にあるEditを押すと、リクエスト数、入力トークン、出力トークンの上限を入れられます。
- 3
絞りたい制限の種類だけ値を入れる
値を入れた種類だけがWorkspace側の上書きになります。
Claude Codeを組織で使っていると、メンバーが初めてConsoleアカウントでサインインした時点で、Anthropicが「Claude Code」Workspaceを自動で作ります。Claude Codeのトラフィックは他のAPI利用と分離され、レート制限も別枠で扱われます。管理者はRate limitsページで、このWorkspaceが組織の上限のどれだけを使えるかを絞れます。Claude Code自体の使い方はClaude Code完全ガイドにあります。
上限値の決め方と、効き方の癖
公式の例では、組織の上限が入力40,000トークン/分・出力8,000トークン/分のとき、1つのWorkspaceを入力30,000トークン/分に絞ります。この絞りで他のWorkspaceを保護できます。Workspaceが上限を使い切らなければ、余った分は他のWorkspaceが使えます。
上限の効き方には、設定前に知っておきたい癖が3つあります。
上限の効き方の癖
組織の上限が常に優先される
複数のWorkspaceの設定値の合計が組織の上限を超えていても、組織全体の上限は常に適用されます。画面上のWorkspaceの数値を足して「合計でこれだけ使える」とは読めません。
モデルのグループ単位で効く
レート制限はモデルごとに別枠で、複数のモデルバージョンが1つのグループで枠を共有することがあります。Opus 4.8・4.7・4.6・4.5は1つの合算枠で、Opus 5.5とOpus 5はそれぞれ別枠です。Sonnet 4.6と4.5も合算ですが、Sonnet 5.5とSonnet 5は別枠です。Fable 5.1とFable 5は合算の1枠で、Mythos 5.1とMythos 5も別の合算枠を共有します。
ITPMはキャッシュ読み取りを数えない
多くのモデルでは、キャッシュから読んだ入力トークンはITPMに入りません。数えるのは
input_tokensとcache_creation_input_tokensです。Haiku 3.5だけは読み取りも数えます。OTPMは実際に生成したトークンだけを数え、max_tokensは計算に入らないので、max_tokensを大きく設定してもレート制限上の不利はありません。ITPMの絞り方はキャッシュ率で効き目が変わるので、Cache-aware ITPMの解説も参照してください。
数値の例として、組織がScale tierのとき、Claude Opus 5.5の上限は10,000 RPM・10,000,000 ITPM・2,000,000 OTPMです。Start tierなら同じモデルで1,000 RPM・2,000,000 ITPM・400,000 OTPMになります。組織の上限はtierで変わるので、ConsoleのRate limitsページで組織側の値を見てから、Workspaceの値を決めます。
反映を確かめる
設定を保存したら、そのWorkspaceのAPIキーで1回リクエストを送り、レスポンスヘッダーを見ます。
curl -sD - https://api.anthropic.com/v1/messages \
-H "x-api-key: $WORKSPACE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":100,"messages":[{"role":"user","content":"hi"}]}' \
-o /dev/null | grep -i "anthropic-ratelimit\|anthropic-workspace-id"見る場所は2つです。anthropic-workspace-idは、キーが実際に解決されたWorkspaceのIDです。複数Workspaceにまたがるキーで「想定と違うWorkspaceの制限が効いている」ときの手がかりになります。認証が通る前に失敗したリクエスト(401など)と、Admin APIへのリクエストでは、このヘッダーは返りません。
anthropic-ratelimit-tokens-*は、その時点で最も厳しい上限の値を示します。Workspaceの制限が効いていない場合は、入力と出力を合算した値です。入力だけ、出力だけの上限を確かめるときはanthropic-ratelimit-input-tokens-limitとanthropic-ratelimit-output-tokens-limitを見ます。
設定値そのものを読むなら、Rate Limits APIを使います。
curl "https://api.anthropic.com/v1/organizations/workspaces/$WORKSPACE_ID/rate_limits?include_inherited=true" \
-H "x-api-key: $ADMIN_API_KEY" \
-H "anthropic-version: 2023-06-01"レスポンスの扱い方には読み違えやすい点があります。include_inheritedを付けないと、返るのはWorkspaceの上書きだけです。返ってこないグループや制限の種類は「無制限」ではなく、組織の値を継承しています。各値に付くorg_limitは、同じ制限の組織側の値です。Default Workspaceは上書きを持てないので、このエンドポイントには出てきません。組織側の値は/v1/organizations/rate_limitsで読みます。
Rate Limits APIは設定値を読み出すためのAPIで、Workspaceのレート制限はConsoleのRate limitsページで設定します。呼び出せるのはAdmin APIキー、org:adminスコープのOAuthトークン、Workspaceに固定されていない個人キーまたはサービスアカウントキーで、Workspace固定のキーは通りません。WorkspaceそのものをAPIで作る方法はClaude Admin APIでワークスペース管理を実装するにあります。レート制限APIの全体像はRate Limits APIの解説にまとめています。
上限に当たったとき、どのエラーで見分けるか
Workspaceまわりでは、よく似た3種類の失敗が出ます。再試行して直るかどうかが違うので、最初に見分けます。
| 状況 | ステータスとエラー種別 | 再試行で直るか |
|---|---|---|
| RPM・ITPM・OTPMの上限を超えた | ステータスとエラー種別429 rate_limit_error。超えた上限を示し、retry-afterヘッダーが付く | 再試行で直るかretry-afterの秒数を待てば通る |
| Workspaceに設定した支出上限(Settings > WorkspacesのSpend limits)に達した | ステータスとエラー種別400 invalid_request_error。メッセージはYou have reached your specified workspace API usage limitsで始まり、再開時期が書かれる | 再試行で直るか通らない。上限を上げるか外す |
| 組織のtierの月間支出キャップに達した | ステータスとエラー種別429 rate_limit_error。retry-afterは付かず、Messages APIではerror.details.error_codeがenforced_spend_limit_reached | 再試行で直るか翌月初め(00:00 UTC)まで通らない。SDKの自動リトライでも直らない |
例外が1つあります。Claude Code Workspaceの上限は別に判定され、超えたリクエストが400ではなくretry-after付きの429を受け取ることがあります。Claude Code Workspaceは、ユーザーごとの月間支出上限を設定できる唯一のWorkspaceです。
上限の枠はinference_geoの値で分かれません。inference_geo: "us"と"global"のリクエストは同じレート制限の枠から引かれます。Opus 5.5・Opus 5・Opus 4.8のfast mode(speed: "fast")には、標準のOpusと別の専用レート制限が適用されます。超えるとretry-after付きの429が返ります。
fast modeを使う前提にも注意点があります。claude-opus-4-6にspeed: "fast"を付けてもエラーにならず、標準速度・標準料金で動きます。レスポンスのusage.speedもstandardになります。claude-opus-4-7に付けるとエラーが返ります。また、fast modeとWorkspaceごとのレート制限設定は、どちらもClaude Platform on AWSでは使えません。
分割パターンと絞り方
Workspaceは用途を問わず作れますが、レート制限を絞る価値が大きいのは次の分割です。公式は、Developmentは低めの上限、Stagingは本番相当、Productionは上限いっぱいで監視を厚く、という構成を例に挙げています。
| 分割パターン | Workspace例 | 絞り方 |
|---|---|---|
| 環境分離 | Workspace例Development / Staging / Production | 絞り方Developmentは低めのRPM・ITPMにして、実験的なコードが本番の枠を食わないようにする。Productionは上限のまま、Usageページで監視する |
| チーム・部門分離 | Workspace例Engineering / Data Science / Support | 絞り方部門ごとにコスト按分とアクセス制御を分けたうえで、サポート向けのツールなど限定用途には低めのITPM/OTPMを入れる |
| プロジェクト単位 | Workspace例製品・案件ごとのWorkspace | 絞り方利用量とコストを個別に追いたいときに分け、想定トラフィックに合わせて上限を設定する |
Workspace名は「Production - Customer Chatbot」のように用途が分かる形にしておくと、あとで上限を見直すときに迷いません。Workspace単位の消費量はUsage and Cost APIで追え、上限に頻繁に当たるWorkspaceが分かれば、引き上げとキャッシュ活用のどちらで対処するかの判断材料になります。
自動生成されるClaude Code Workspaceも見直しの対象です。メンバーが増えるほど実利用量も増えるため、他のプロジェクト用Workspaceを圧迫していないかを確かめます。
まとめ
Workspaceの上限は、他のWorkspaceの取り分を守る仕切りであって、組織全体の枠を増やす手段ではありません。枠そのものが足りないなら、絞り方より先に、tierの引き上げやキャッシュ率の改善で対処するかを考えます。