Claude Workspacesのロール継承とAPIキーのスコープ

Claude Workspacesは何のための仕組みか

組織のAPI利用が増えると、開発・ステージング・本番のトラフィックが1本の請求と1組のレート制限に混ざり込み、どのプロジェクトがいくら使っているか分からなくなります。Workspacesは、組織内のAPIキー・メンバー・リソース上限をプロジェクトや環境単位で分離しつつ、請求と管理は組織レベルに一本化する仕組みです。

すべての組織には「Default Workspace」が1つ必ず存在し、これはリネームもアーカイブも削除もできません。追加のワークスペースを作ると、そこにメンバー・サービスアカウント・APIキー・リソース上限を個別に割り当てられます。ワークスペースIDはwrkspc_接頭辞を持ち、1組織あたり既定で最大100個まで作成できます(アーカイブ済みは数に含まれません)。Default Workspaceもwrkspc_形式のIDを持ちますが、List Workspacesの一覧には現れず、APIキーや利用状況・コストレポートではworkspace_idがnullとして表示されるという扱いの違いがあります。

組織のメンバーが初めてClaude Codeにサインインすると、AnthropicはClaude Codeワークスペースを自動で作成し、そのメンバーを追加します。以降にサインインするメンバーも同じ扱いです。このワークスペースには他にはない特徴が4つあります。

• サインイン時にワークスペース内でユーザーごとのAPIキーが自動発行されます(Console画面から手動でキーを作ることはできません)
• キー所有者がワークスペースまたは組織から外れると、通常のワークスペースキーと違いそのキーは即座に使えなくなります
• Claude Codeの利用は組織の他のAPIトラフィックとは別枠でレート制限され、管理者はその上限比率をSettings > Workspacesで調整できます
• per-user月次支出上限に対応する唯一のワークスペースです

ワークスペースロールと権限の一覧

ワークスペース内の権限は5段階です。

Workspace Billingロールだけは手動で割り当てられません。組織の請求ロールを持つメンバーに自動で付与される専用の継承ロールです。

ロール継承の実装イメージ

ワークスペースの権限は、すべてが個別に手動設定されるわけではなく、組織ロールから自動継承される部分とワークスペースごとに手動で割り当てる部分に分かれます。

• 組織管理者は、すべてのワークスペースに自動でWorkspace Admin権限を持ちます
• 組織の請求メンバーは、すべてのワークスペースに自動でWorkspace Billing権限を持ちます
• 組織のユーザー・開発者は、ワークスペースごとに明示的な追加が必要です
• サービスアカウントは、Settings → Service accountsのサービスアカウント自身のページか、ワークスペースの「Service accounts」タブから追加します

ワークスペースロールは、組織ロール(User・Admin・Owner・Primary Owner)とは別の階層です。組織ロールが組織全体の権限を決めるのに対し、ワークスペースロールは各ワークスペース内でのみ効きます。組織ロールが変わると、継承されたワークスペース権限も連動して変わります。管理者や請求メンバーが降格されてユーザー・開発者になると、個別に権限を割り当てられていたワークスペース以外の全アクセスを失います。逆に昇格すると、全ワークスペースへの自動アクセスを獲得します。組織管理者と請求メンバーは、その組織ロールを保持している間はワークスペースロールの変更も除外もできません。例外は1つだけで、請求メンバーはWorkspace Adminへ昇格させることができます。それ以外のケースで権限を変えたいなら、先に組織ロール側を変更する必要があります。

ワークスペースを作成できるのは組織管理者だけです。組織のユーザー・開発者をワークスペースに参加させるのも管理者の作業で、セルフサービスでは入れません。

APIキーのスコープとリソースの分離

すべてのAPIリクエストは、必ずどこか1つのワークスペースの中で実行され、そのワークスペース内のリソースにしかアクセスできません。どのワークスペースになるかはキーの種類で決まります。ワークスペースキー(所有者を持たないレガシーキー)は作成されたワークスペースに固定されます。個人キーやサービスアカウントキーはそのユーザーやサービスアカウントとして動作し、単一ワークスペース用のキーなら作成時に選んだワークスペースに固定、複数ワークスペース対応のキーなら各リクエストのanthropic-workspace-idヘッダーで指定したワークスペースで動きます。

ワークスペース単位で分離されるリソースは、Files APIで作成したファイル、Batch APIのメッセージバッチ、Skills APIのスキルの3種類です。一方でMCPトンネルは少し違う扱いで、Workload Identity Federation経由のworkspace:manage_tunnelsスコープ付きOAuthトークンで管理し、アクティブ数10本という上限は組織全体で共有されます。ワークスペースそのものと組織メンバーの管理は、組織レベルの操作としてAdmin APIキー・org:adminスコープのOAuthトークン・ワークスペースに紐づかない個人/サービスアカウントキーのいずれかで行います。プロンプトキャッシュもClaude API・Claude Platform on AWS・Microsoft Foundryではワークスペース単位で分離されますが、Amazon BedrockとGoogle Cloudでは組織単位の分離になる点は環境差として押さえておく必要があります。

APIレスポンスにはanthropic-workspace-idヘッダーが付き、そのリクエストがどのワークスペースで解決されたかを示します。認証が完了する前に失敗したリクエスト(401など)や、ワークスペースに解決されない資格情報(Admin APIリクエストなど)ではこのヘッダーは付きません。

curl -sS -D - -o /dev/null https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }' | grep -i '^anthropic-workspace-id'

このヘッダーの値を使えば、利用状況・コストレポートのworkspace_idと突き合わせてどのワークスペースが対象か確認できるほか、Admin API資格情報でGet Workspaceに渡してDefault Workspaceかどうかを判定できます(Default Workspaceは"name": "Default"で返りますが、List Workspacesの一覧には出てきません)。

ワークスペース単位の上限とコスト集計

各ワークスペースには組織の上限以下でしか上限を設定できません(組織の上限を超える値は設定できません)。設定できるのは支出上限(月次の支出上限とアラートのしきい値)とレート制限(モデルティアごとの毎分リクエスト数・入力/出力トークン数)の2種類で、Default Workspaceには設定できません。ワークスペース側で上限を設定しなければ組織の上限がそのまま適用され、ワークスペース側の上限を合算した値が組織の上限を上回っていても、組織全体の上限が優先されます。

curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2026-01-01T00:00:00Z&\
ending_at=2026-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"

Usage and Cost APIでワークスペースごとの利用量・コストを集計する際も、Default Workspace分はworkspace_idがnullとして現れます。ワークスペース単位のコストだけを見たい場合は、null行を「Default Workspace」として別枠で扱う実装にしておくと集計ミスを避けられます。

メンバーがワークスペースを離れるとAPIキーはどうなるか

離職やチーム異動でメンバーをワークスペースから外すとき、APIキーの挙動はキーの種類で分かれます。個人キーやサービスアカウントキーは、所有者がワークスペースから外れるとほどなく使えなくなります。ただしサービスアカウントキーは、作成者本人が外れても動き続けます。ワークスペースキーはメンバーの在籍状況に関わらず動作し続けます。Claude Codeワークスペースだけは例外で、各キーは発行したメンバー個人に紐づき、そのメンバーが外れた時点で使えなくなります。メンバーが組織そのものから外れると個人キーはアーカイブされ、再招待されても過去のキーは復元されず新規発行が必要です。

ワークスペース分割の典型パターン

実務でのワークスペース分割は、大きく3つのパターンに収れんします。1つ目は開発・ステージング・本番の環境分離で、開発は低めのレート制限、ステージングは本番に近い制限、本番は制限を絞らず監視を厚くする構成です。2つ目はチーム・部門単位の分離で、エンジニアリングチームには開発者権限、データサイエンスチームには専用のAPIキー、サポートチームには限定的なアクセスというようにロールごと分けます。3つ目はプロジェクト単位の分離で、個別のプロダクトやプロジェクトごとにワークスペースを立て、利用量とコストを独立して追跡します。どのパターンでも、ワークスペースを作る前に命名規則(「Production - 顧客チャットボット」のように用途が一目で分かる名前)と上限方針を決めておくと、後から棚卸しをする負担が減ります。

まとめ

Claude Workspacesは、プロジェクト・環境・チームでAPIキーとリソースを分離しながら、請求と組織管理は一本化する仕組みです。ロールの実務で押さえるべき要点は、組織管理者・請求メンバーへの自動継承と、それ以外のメンバーへの手動追加という二重構造にあります。APIキーのスコープはリクエストごとに1つのワークスペースへ解決され、ファイル・バッチ・スキルはそのワークスペース内に閉じます。支出やコストを部門・プロジェクト単位で追いたい場合は、Spend Limits APIと組み合わせて、ワークスペース単位の可視化まで含めて設計しておくと運用が崩れにくくなります。