Claude Enterpriseの組織UUIDを取得する手順 — Compliance APIでユーザー・グループも

親組織のキー1本で、配下の組織・ユーザー・グループまで読める

Claude Enterpriseの連結組織のUUIDは、Compliance APIの組織一覧(GET /v1/compliance/organizations)が返すuuidで取れます。呼び出しにはCompliance Access Keyが要り、以降のエンドポイントでもこのuuidを使います。親組織のプライマリーオーナーが作ったキーなら配下の全連結組織が返り、Admin APIキーでは403になります。

Compliance APIのディレクトリ系エンドポイントは、Claude Enterpriseの親組織にひもづく連結組織・ユーザー・ロール・グループを読み取ります。eDiscoveryのユーザーリスト作成、レポーティングダッシュボード、外部の台帳とのグループメンバーシップ照合が主な用途です。

どのキーで何が読めるかは、キーの種類と作成者で決まります。

親組織はClaude Consoleに現れません。キーはclaude.aiのOrganization settings > APIで作ります。

スコープはエンドポイントごとに2種類に分かれる

必要なスコープは次のとおりです。

読み取りエンドポイントには、これらのほかにread:org_auditも通ります。Admin APIのユーザー管理の読み取りと、Compliance APIの全読み取りエンドポイントを1つのスコープで賄う、セキュリティ監査向けの読み取り専用スコープです。

スコープは作成後に変更できません。足りなければ新しいキーを作り、古いキーを削除します。

ディレクトリを端から端まで歩くなら、キー作成時にread:compliance_org_dataとread:compliance_user_dataの両方を選びます。後者は、親組織のすべての連結組織のチャット・ファイル・プロジェクト・セッションの中身まで読めるスコープでもあります。シークレットマネージャーに置き、ソース管理やSIEM転送の設定ファイルには書きません。

不足したときの403は、次の形でキーが持つスコープと必要なスコープを両方返します。

Missing required scopes. Got: ['read:compliance_user_data'] Needed one of: ['read:compliance_org_data', 'read:org_audit']

Needed one of:は「どれか1つあればよい」の意味です。Needed:と書かれるのは削除エンドポイントだけです。

ユーザー一覧に出る人と、出ない人

ユーザー一覧に載るのは、いま組織に在籍しているメンバーだけです。退職・異動で外れたユーザーは即座に一覧から消えます。

電子情報開示のユーザーリストを作る流れ

典型的な流れは4段階です。

組織一覧を取得する

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01"

レスポンスはcreated_at昇順のdata配列と、has_more / next_pageです。各組織はuuid・name・created_atを持ちます。

組織の増減を追うなら、このエンドポイントを定期的に呼び直し、毎回next_pageを最後まで辿ります。Activity Feedのorg_deletion_requested、org_deleted_via_bulk、org_parent_join_proposal_created、org_join_proposal_decidedでも変化を検知できます。

組織UUIDだけを取り出す

後続のパスに渡すuuidと組織名だけが欲しいときは、jqで絞ると扱いやすくなります。

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01" \
  | jq -r '.data[] | [.uuid, .name] | @tsv'

出力はタブ区切りのuuidとnameです。has_moreがtrueならnext_pageを渡して続きを取ります。

組織のユーザー一覧を取得する

read:compliance_user_dataが必要です。read:compliance_org_dataだけのキーでは403 Forbiddenになります。

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"
 
curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/organizations/$org_uuid/users" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01" \
  --data-urlencode "limit=500"

結果は組織への参加日昇順です。各レコードはid・full_name・email・organization_role・created_atを持ちます。

organization_roleはadmin / billing / claude_code_user / developer / managed / membership_admin / owner / primary_owner / userのいずれかで、組織への標準的な所属レベルです。ロール一覧が返すカスタムRBACロールの割り当てとは独立した軸です。両方を突き合わせて初めて、「組織メンバーとして何ができるか」と「カスタムロールで何を割り当てられているか」が分かります。

ロール一覧を取得する

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"
 
curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations/${org_uuid}/roles" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01"

ロール一覧・詳細はどちらもread:compliance_org_dataで足ります。レコードはid(rbac_role_...)・name・description・created_at・updated_atを持ちます。

ロールに付与された権限は、別のロール権限一覧エンドポイントで引きます。割り当て履歴と権限変更履歴は、Activity Feedのrbac_role_assignedやrbac_role_permission_addedで絞ります。

グループとメンバーを取得する

グループ一覧・詳細はread:compliance_org_data、メンバー一覧はread:compliance_user_dataが必要です。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/groups" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01"

グループレコードのsource_typeは、グループの作成元を見分ける項目です。claude.aiで手動作成したグループはdirect、外部IDプロバイダーからSCIM(クロスドメインでID情報を同期する仕組み)で同期したグループはscimです。roles配列には、そのグループに割り当てたロールのIDが入ります。グループごとにメンバーを引きます。

group_id="rbac_group_01P9qRsTuVwXyZa2BcDeFgHjK"
 
curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/groups/$group_id/members" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01"

メンバーレコードはuser_id・email・created_at・updated_atで、氏名は入っていません。フルネームが要るときは、user_idを組織のユーザー一覧と突き合わせます。このuser_idはActivity Feedやセッション一覧と共通で、ローカルセッションのuser.idとも一致します。エージェントが所有するリモートセッションでは、人間のIDがstarted_by_user.idに入ります。

実効組織設定を取得する

実効組織設定は、規制上の制約(HIPAAなど)、機能の提供可否のルール、組織タイプの既定値、機能同士の依存を適用した後の「実際に効いている設定」を返します。管理者が設定した値と違うことがあるので、監査の証跡として意味を持ちます。保持期間、コンテンツのリダクション設定、SSO強制、IP許可リスト、セッション時間制御が基線どおりかを、管理者のConsoleに入らずに示せます。

org_uuid="91012d09-e48b-438e-a489-1bebfd8fa6f9"
 
curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/organizations/$org_uuid/settings" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2023-06-01"

レスポンスのsettingsは、name・type・valueを持つ行の配列です。typeはboolean / integer / string_list / provisioning_mode / data_retentionのいずれかで、valueの形を決めます。

行が現れない設定は「オフ」ではなく、Anthropicのポリシーで固定されている、またはその組織で使えないために、管理者が変更できない項目です。

値は有効になっている状態を映します。たとえばsso_provisioning_modeは、ディレクトリ同期が有効なときだけSCIMモードを報告します。ip_allowlist_enabledは、許可リストが有効で、有効な範囲が1つ以上あるときだけtrueです。code_execution_network_egress_enabledは、コード実行がオフなら常にfalseです。

読んだ時点の状態であり、スナップショットは取られません。多くの設定は変更がActivity Feedのイベントとして残るので、誰がいつ変えたかはそちらで追います。

レスポンスのapi_keys配列には、親組織に紐づく全Complianceアクセスキーが入ります。各行はid / name / scopes / is_active / created_at / expires_at / created_by_idで、どの連結組織に対して呼んでも同じ一覧です。無効化済みのキーや、廃止されたスコープしか持たないキーも残るため、鍵の棚卸しにそのまま使えます。

廃止されたスコープ

このエンドポイントは以前read:compliance_org_settingsという専用スコープを要求していましたが、2026年6月30日に廃止され、新規キーでは選べません。そのスコープしか持たないキーは403 Forbiddenになります。read:compliance_org_dataを持つキーは影響を受けません。エラーの原因分岐はCompliance APIのエラーハンドリング完全ガイドにあります。

プラグインの一覧も同じキーで読める

read:compliance_org_dataのキーは、Admin APIのPlugins APIの読み取りエンドポイントも呼べます。プラグインの一覧と詳細、バージョンの一覧と取得とファイルのダウンロード、インストール設定と共有の一覧、マーケットプレイスの一覧と取得が対象です。

すべてのリクエストにanthropic-beta: ce-plugins-2026-09-01ヘッダーが要ります。付けないと404 Not Foundです。1回の呼び出しは1組織を読み、親組織のキーは、自分が作られた連結組織を読みます。別の組織はorganization_idクエリパラメータで指定します。呼び出しはCompliance APIではなくAdmin APIのレート制限に数えられます。

この一覧はメンバーを特定できる情報を含みます。プラグインを所有・作成したメンバーのユーザーIDと、個別に共有された相手のID、作成者のメールアドレス(nullのこともあります)です。作成や変更は、write:pluginsを持つAdmin APIキーの領分です。読み取りでActivity Feedにイベントが残るのは、メンバーの個人マーケットプレイスにあるプラグインのファイルをダウンロードしたときだけです。種別はclaude_plugin_archive_accessedです。イベントにはキー、プラグイン、バージョン、所有メンバーのIDが入り、組織所有のプラグインのダウンロードは記録されません。

識別子の形式が場所ごとに違う

組織の識別子は、同じ組織を指していても場所によって形が違います。

ローカルセッション一覧には組織フィルタがありません。

404が続くときの切り分け

実効組織設定のエンドポイントは、次の4つのケースを同じ本文の404で返します。存在しない組織、UUIDとして不正な値、親組織のツリー外の組織、親組織に対してこのエンドポイントが有効化されていない場合です。組織が存在するかどうかを応答から推し量れないようにする設計なので、既知の組織IDで404が続いても、組織が存在しないと決めつけられません。連結組織のUUIDを使っているか、組織一覧の結果と照らして確かめます。

親組織自体も対象にできません。この設定エンドポイントは、ほかのディレクトリ系とは別に親組織ごとに有効化されます。全リクエストが404なら、Anthropicの担当者への連絡が必要です。

ロールとグループのエンドポイントの404は、メッセージがRole not found.とGroup not found.で固定です。パスのIDが存在しないか、呼んだキーが読めるツリーに属さなくなったときに返ります。組織のエンドポイントだけは、メッセージにorg_uuidが入ります。

Plugins APIでは、anthropic-betaヘッダーを付け忘れた場合も404です。

ページネーションはpageトークンで進める

ディレクトリ系はpageという不透明なトークンで進みます。Activity Feedのbefore_id / after_idカーソルとは形式が違い、同じコードで両方を扱うと壊れます。pageには前回レスポンスのnext_pageをそのまま渡し、IDから組み立てません。has_moreがfalseになれば終わりです。

アクセス範囲・データ保持・ページネーションの疑問はCompliance APIのFAQに、キーの作成手順はCompliance APIアクセスキーの作り方にあります。ロール設計を見直すならClaude Enterpriseでカスタムロールを作成する手順も参考になります。

まとめ

用途ごとにキーを分けるなら、read:compliance_user_dataを持つキーは、チャットやセッションの中身まで読めるキーとして管理者を絞って扱います。組織の増減や設定の確認だけなら、read:compliance_org_dataだけのキーで足ります。