開発用と本番用で API キーを分けたい。チームごとに費用を出したい。特定の用途だけ支出に上限をかけたい。こうした「組織のなかで API 利用を仕切る」要求に応えるのが ワークスペース(Workspaces) です。この記事では公式ドキュメントの内容を日本語で整理します。
概要
ワークスペースは、組織のなかで API の利用を分けるためのしくみです。請求と管理は組織にまとめたまま、プロジェクト・環境・チームごとに区切ることができます。
どの組織にも Default Workspace(既定のワークスペース) が1つあり、これは名前の変更・アーカイブ・削除ができません。追加のワークスペースを作ると、そこにメンバー・サービスアカウント・API キー・上限を割り当てられます。
- ワークスペースの ID は
wrkspc_で始まります(例:wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ) - 1組織あたり既定で 最大100ワークスペース。アーカイブ済みは数に入りません。増やしたい場合はアカウントチームへ問い合わせます
- API キーは1つのワークスペースに紐づけられます。複数ワークスペースにまたがる権限を持てるキーもあり、その場合はリクエストごとにヘッダでワークスペースを指定します
Default Workspace の扱いが少し特殊です
Default Workspace にも他と同じ wrkspc_ 形式の ID があり、レスポンスヘッダにも返りますし、Get Workspace でも引けます。ただし List Workspaces の結果には現れません。 さらに、API キー・利用量レポート・費用レポートでは workspace_id が null になります。
ここが紛らわしいのは、全ワークスペース対象のキーも同じく null になる点です。両者を見分けるには API キーの scope フィールドを見ます。Default Workspace に紐づいたキーであれば、scope のほうには実際の ID が入っています。
Claude Code 専用のワークスペース
組織のメンバーが Claude Console アカウントで初めて Claude Code にサインインすると、Claude Code ワークスペースが自動で作られ、そのメンバーが追加されます。以降にサインインしたメンバーも同じように追加されます。
- サインイン時に、そのワークスペース内でユーザーごとの API キーが発行されます。Console から手で作ることはできません
- Claude Code のキーは、持ち主がワークスペースや組織から外れると使えなくなります(通常のワークスペースキーとは挙動が違います)
- Claude Code の利用は別枠でレート制限され、組織全体の上限のうち何割まで使えるかを管理者が設定できます
- ユーザーごとの月間支出上限を設定できる唯一のワークスペースです
注意点として、Claude Code ワークスペースをアーカイブすると、組織全体で Console 課金経由の Claude Code サインインができなくなります。
基本概念
ワークスペースの役割(ロール)
メンバーはワークスペースごとに別の役割を持てます。これによって細かいアクセス制御ができます。
| 役割 | できること |
|---|---|
| Workspace User | playground の利用のみ |
| Workspace Limited Developer | API キーの作成・管理、API の利用。セッションのトレース画面の閲覧とファイルのダウンロードは不可 |
| Workspace Developer | API キーの作成・管理、API の利用 |
| Workspace Admin | ワークスペースの設定とメンバーの完全な管理 |
| Workspace Billing | ワークスペースの請求情報の閲覧(組織の billing ロールから継承) |
組織のロールからの継承
- 組織の管理者(admin)は、すべてのワークスペースで自動的に Workspace Admin になります
- 組織の billing メンバーは、すべてのワークスペースで自動的に Workspace Billing になります
- 組織の user / developer は、ワークスペースごとに明示的に追加する必要があります
Workspace Billing の役割は手で割り当てられません。 組織の billing ロールを持っていることから継承されるだけです。同じ理由で、組織の管理者と billing メンバーは、その組織ロールを持っているあいだワークスペースから外せません(billing メンバーを Workspace Admin に引き上げるのは例外的に可能です)。外したい場合は先に組織ロールのほうを変えます。
逆方向も押さえておきます。組織の管理者や billing メンバーが user / developer に降格されると、手動で役割を割り当てられたワークスペース以外はすべてアクセスを失います。
どのワークスペースで動くかはキーの種類で決まる
すべてのリクエストはちょうど1つのワークスペースの中で動き、そのワークスペース内のリソースにしかアクセスできません。どこで動くかはキーの種類で決まります。
- ワークスペースキー(所有者のいないレガシーなキー)… 作られたワークスペースに属し、常にそこで動きます
- 個人キー / サービスアカウントキー … そのユーザーまたはサービスアカウントとして動きます。単一ワークスペースのキーは作成時に選んだワークスペースで動き、複数ワークスペース対応のキーはリクエストごとの
anthropic-workspace-idヘッダで指定されたワークスペースで動きます
ワークスペース単位で区切られるリソースは次のとおりです。
- Files API で作ったファイル
- Batch API で作った Message Batches
- Skills API で作ったスキル
さらに、プロンプトキャッシュもワークスペースごとに分離されます(Claude API / Claude Platform on AWS / Microsoft Foundry の場合)。Amazon Bedrock と Google Cloud では組織単位の分離になります。開発用と本番用を分けるとキャッシュも共有されない、という点はコストの見積もりに効いてきます。
ワークスペースそのものは組織レベルで管理する
ワークスペースの作成・削除や組織メンバーの管理は、ワークスペースキーではできません。Admin API キー、org:admin の OAuth トークン、または特定のワークスペースに紐づいていない個人キー/サービスアカウントキーのいずれかが要ります。認証方法の詳細は Admin API の公式ドキュメントにあります。
使い方
Console で作る
作成できるのは組織の管理者だけです。
- Claude Console で Settings > Workspaces を開く
- Create workspace を押す
- 名前と、見分けるための色を選ぶ
- Create で確定する
Console 上でワークスペースを切り替えるには、左上の Workspaces セレクタを使います。名前や色を後から変えるには、一覧でワークスペースを選び、... メニューから Edit details を開きます。
メンバーを追加する
- ワークスペースの Members タブを開く
- Add to Workspace を押す
- 組織のメンバーを選び、ワークスペースの役割を割り当てる
- 確定する
上限を設定する
設定は2つのタブに分かれています。
- Rate limits タブ … モデルのティアごとに、毎分のリクエスト数・入力トークン・出力トークンの上限を設定します
- Spend limits タブ … 月間の支出に上限をかけ、一定額に達したときのアラートを設定します
設定時に効いてくる制約が3つあります。Default Workspace には上限を設定できません。 設定しなければ組織の上限がそのまま適用されます。 そして組織全体の上限は常に効きます。各ワークスペースの上限を足した値が組織の上限を超えていても、実際には組織の上限で頭打ちになります。
Admin API で作る
curl -X POST "https://api.anthropic.com/v1/organizations/workspaces" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"name": "Production"}'
Python の SDK では client.beta.organization.workspaces の下にまとまっています。
client = anthropic.Anthropic()
workspace = client.beta.organization.workspaces.create(name="Production")
print(f"id: {workspace.id}")
print(f"name: {workspace.name}")
一覧を取るときは include_archived でアーカイブ済みを含めるかを指定します。
curl "https://api.anthropic.com/v1/organizations/workspaces?limit=10&include_archived=false" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01"
メンバーの追加は、ユーザー ID と役割を渡します。
curl -X POST "https://api.anthropic.com/v1/organizations/workspaces/wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ/members" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"user_id": "user_01XyDMpzjS89pFZXqSFUBDr6",
"workspace_role": "workspace_developer"
}'
アーカイブは取り消せません
アーカイブすると、レポート用の履歴データは残りますが、そのワークスペースで作られた API キーが数秒のうちにすべてアーカイブされます(Admin API 上ではアーカイブ済みとして一覧に残ります)。複数ワークスペース対応のキーも、そのワークスペースでは動かなくなります。この操作は取り消せません。
curl -X POST "https://api.anthropic.com/v1/organizations/workspaces/wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ/archive" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01"
レスポンスからワークスペースを特定する
Claude API のレスポンスには request-id や anthropic-organization-id と並んで anthropic-workspace-id ヘッダが入ります。値は、そのリクエストのキーやトークンが解決したワークスペースの ID で、Default Workspace のときもその ID が入ります。
HTTP/1.1 200 OK
request-id: req_018EeWyXxfu5pfWkrYcMdjWG
anthropic-organization-id: 0d0e7a3b-52f1-4c7e-9a51-3f6f2f7c1b9e
anthropic-workspace-id: wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ
ヘッダが付かない場合もあります。Admin API のリクエストのようにワークスペースが決まらないときと、401 のように認証が終わる前に失敗したときです。
Python なら with_raw_response でヘッダを読めます。
client = anthropic.Anthropic()
response = client.messages.with_raw_response.create(
model="claude-opus-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
)
workspace_id = response.headers.get("anthropic-workspace-id")
print(f"Workspace ID: {workspace_id}")
取得した ID があれば、そのリクエストがどのワークスペースの利用量・費用・レート制限に計上されたかを確認でき、Usage and Cost API のレポートや Admin API 上のオブジェクトの workspace_id と突き合わせられます。
ワークスペース別に費用を取る
curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2025-01-01T00:00:00Z&\
ending_at=2025-01-08T00:00:00Z&\
workspace_ids[]=wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ&\
group_by[]=workspace_id&\
bucket_width=1d" \
-H "anthropic-version: 2023-06-01" \
-H "x-api-key: $ANTHROPIC_ADMIN_KEY"
繰り返しになりますが、Default Workspace に計上された利用量と費用は workspace_id が null で返ります。
よくある分け方
公式ドキュメントが挙げている代表的な使い分けは3つです。
| ワークスペース | 用途 |
|---|---|
| Development | 低めのレート制限で、検証と実験を行う |
| Staging | 本番に近い上限で、リリース前の検証を行う |
| Production | 本番トラフィック。上限は最大、監視つき |
このほか、チーム・部署ごとに分けて費用配賦とアクセス制御を行う分け方と、プロダクトや案件ごとに分けて利用量と費用を別々に追う分け方があります。
まとめ
ワークスペースは「請求と管理は1つにまとめたまま、利用だけを仕切る」ための道具です。実際に運用するうえで効いてくるのは次の点です。
- 作れるのは組織の管理者だけ。組織の user / developer はワークスペースごとに追加してもらう必要がある
- Default Workspace は例外だらけ。List Workspaces に出ず、レポートでは
workspace_idがnull、上限も設定できない nullのworkspace_idは Default Workspace と全ワークスペース対象キーの両方でありうる。見分けるのはscopeフィールド- アーカイブは取り消せず、そのワークスペースのキーを巻き込む。Claude Code ワークスペースをアーカイブすると組織全体のサインインが止まる
- ワークスペース単位で分かれるのは、ファイル・バッチ・スキル、そしてプロンプトキャッシュ
- ワークスペースの上限を足し合わせても組織全体の上限は超えられない
最初に構成を決めてから作ること、名前で用途が分かるようにすること(「Production - Customer Chatbot」など)、上限を設定しておくこと、メンバーを定期的に棚卸しすること、Usage and Cost API で消費を追うこと。公式ドキュメントが挙げている推奨はこの5つです。
本記事は 公式ドキュメントの Workspaces(2026-09-23 確認)に基づく非公式の日本語解説です。最新の仕様は公式ドキュメントを確認してください。