Claude API のワークスペースで環境・チーム・費用を分ける

Claude API 管理 7分で読めます

開発用と本番用で API キーを分けたい。チームごとに費用を出したい。特定の用途だけ支出に上限をかけたい。こうした「組織のなかで API 利用を仕切る」要求に応えるのが ワークスペース(Workspaces) です。この記事では公式ドキュメントの内容を日本語で整理します。

概要

ワークスペースは、組織のなかで API の利用を分けるためのしくみです。請求と管理は組織にまとめたまま、プロジェクト・環境・チームごとに区切ることができます。

どの組織にも Default Workspace(既定のワークスペース) が1つあり、これは名前の変更・アーカイブ・削除ができません。追加のワークスペースを作ると、そこにメンバー・サービスアカウント・API キー・上限を割り当てられます。

Default Workspace の扱いが少し特殊です

Default Workspace にも他と同じ wrkspc_ 形式の ID があり、レスポンスヘッダにも返りますし、Get Workspace でも引けます。ただし List Workspaces の結果には現れません。 さらに、API キー・利用量レポート・費用レポートでは workspace_idnull になります。

ここが紛らわしいのは、全ワークスペース対象のキーも同じく null になる点です。両者を見分けるには API キーの scope フィールドを見ます。Default Workspace に紐づいたキーであれば、scope のほうには実際の ID が入っています。

Claude Code 専用のワークスペース

組織のメンバーが Claude Console アカウントで初めて Claude Code にサインインすると、Claude Code ワークスペースが自動で作られ、そのメンバーが追加されます。以降にサインインしたメンバーも同じように追加されます。

注意点として、Claude Code ワークスペースをアーカイブすると、組織全体で Console 課金経由の Claude Code サインインができなくなります。

基本概念

ワークスペースの役割(ロール)

メンバーはワークスペースごとに別の役割を持てます。これによって細かいアクセス制御ができます。

役割できること
Workspace Userplayground の利用のみ
Workspace Limited DeveloperAPI キーの作成・管理、API の利用。セッションのトレース画面の閲覧とファイルのダウンロードは不可
Workspace DeveloperAPI キーの作成・管理、API の利用
Workspace Adminワークスペースの設定とメンバーの完全な管理
Workspace Billingワークスペースの請求情報の閲覧(組織の billing ロールから継承)

組織のロールからの継承

Workspace Billing の役割は手で割り当てられません。 組織の billing ロールを持っていることから継承されるだけです。同じ理由で、組織の管理者と billing メンバーは、その組織ロールを持っているあいだワークスペースから外せません(billing メンバーを Workspace Admin に引き上げるのは例外的に可能です)。外したい場合は先に組織ロールのほうを変えます。

逆方向も押さえておきます。組織の管理者や billing メンバーが user / developer に降格されると、手動で役割を割り当てられたワークスペース以外はすべてアクセスを失います。

どのワークスペースで動くかはキーの種類で決まる

すべてのリクエストはちょうど1つのワークスペースの中で動き、そのワークスペース内のリソースにしかアクセスできません。どこで動くかはキーの種類で決まります。

ワークスペース単位で区切られるリソースは次のとおりです。

さらに、プロンプトキャッシュもワークスペースごとに分離されます(Claude API / Claude Platform on AWS / Microsoft Foundry の場合)。Amazon Bedrock と Google Cloud では組織単位の分離になります。開発用と本番用を分けるとキャッシュも共有されない、という点はコストの見積もりに効いてきます。

ワークスペースそのものは組織レベルで管理する

ワークスペースの作成・削除や組織メンバーの管理は、ワークスペースキーではできません。Admin API キー、org:admin の OAuth トークン、または特定のワークスペースに紐づいていない個人キー/サービスアカウントキーのいずれかが要ります。認証方法の詳細は Admin API の公式ドキュメントにあります。

使い方

Console で作る

作成できるのは組織の管理者だけです。

  1. Claude Console で Settings > Workspaces を開く
  2. Create workspace を押す
  3. 名前と、見分けるための色を選ぶ
  4. Create で確定する

Console 上でワークスペースを切り替えるには、左上の Workspaces セレクタを使います。名前や色を後から変えるには、一覧でワークスペースを選び、... メニューから Edit details を開きます。

メンバーを追加する

  1. ワークスペースの Members タブを開く
  2. Add to Workspace を押す
  3. 組織のメンバーを選び、ワークスペースの役割を割り当てる
  4. 確定する

上限を設定する

設定は2つのタブに分かれています。

設定時に効いてくる制約が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-idanthropic-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_idnull で返ります。

よくある分け方

公式ドキュメントが挙げている代表的な使い分けは3つです。

ワークスペース用途
Development低めのレート制限で、検証と実験を行う
Staging本番に近い上限で、リリース前の検証を行う
Production本番トラフィック。上限は最大、監視つき

このほか、チーム・部署ごとに分けて費用配賦とアクセス制御を行う分け方と、プロダクトや案件ごとに分けて利用量と費用を別々に追う分け方があります。

まとめ

ワークスペースは「請求と管理は1つにまとめたまま、利用だけを仕切る」ための道具です。実際に運用するうえで効いてくるのは次の点です。

最初に構成を決めてから作ること、名前で用途が分かるようにすること(「Production - Customer Chatbot」など)、上限を設定しておくこと、メンバーを定期的に棚卸しすること、Usage and Cost API で消費を追うこと。公式ドキュメントが挙げている推奨はこの5つです。

本記事は 公式ドキュメントの Workspaces(2026-09-23 確認)に基づく非公式の日本語解説です。最新の仕様は公式ドキュメントを確認してください。