Compliance APIで組織のユーザーとグループを取得する手順

Compliance APIの組織データ取得でできること

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

親組織をカバーするComplianceアクセスキーが1本あれば、配下の全連結組織のデータに届きます。組織ごとにキーを分ける必要はありません。

前提: どのキーとスコープが必要か

ディレクトリ系エンドポイントはComplianceアクセスキー(sk-ant-api01-...)専用です。Admin APIキー(sk-ant-admin01-...)はActivity Feedのみ読めるため、組織データのエンドポイントに使うと403 Forbiddenが返ります。

必要なスコープはエンドポイントによって分かれます。

ディレクトリを端から端まで歩くつもりなら、キー作成時に両方のスコープを選んでおきます(スコープ不足時に何が起きるかは後述の「つまずきやすいポイント」で扱います)。

組織一覧を取得する

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のページネーション情報です。has_moreがtrueのときはnext_pageの値をそのまま次のリクエストのpageクエリパラメータへ渡します。

各組織のuuidは、他のエンドポイントで組織を指すときの基準値です。ただしフィールド名と形式はエンドポイントによって違うため、混同しやすい点は後述の「つまずきやすいポイント」にまとめます。

組織のメンバーシップ変化を追うには、このエンドポイントを定期的に呼び直し、next_pageを最後まで辿ります。Activity Feedでもorg_deletion_requestedやorg_parent_join_proposal_createdなどのアクティビティタイプで組織の増減を検知できます。

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

このエンドポイントは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"

結果は組織への参加日昇順で並びます。返ってくるuser_...形式のIDは、Activity Feedのactor_ids[]フィルタや、チャット・セッション系エンドポイントのuser_ids[]フィルタでもそのまま使えます。

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

退職・異動でユーザーが組織から外れると、この一覧には即座に出てこなくなります。過去の活動履歴は保持期間内であればActivity Feedから同じユーザーIDで引けるので、ユーザー一覧が消えた後の追跡はActivity Feed側で行います。

ロール一覧を取得する

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_...形式)は、あるロールに付与された権限を確認する専用エンドポイントや、グループレコードのroles配列と突き合わせる基準値になります。ロールの割り当て履歴・権限変更履歴を監査したい場合は、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)かを見分ける項目です。取得したグループ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はActivity Feedやセッション一覧と共通の識別子です。フルネームまでほしい場合は、このIDを組織のユーザー一覧と突き合わせます。メンバーレコード自体にはメールアドレスは入っていても氏名は入っていないためです。

実効組織設定を取得する

実効組織設定エンドポイントは、HIPAA対応などの規制上の制約や機能可用性ルール、組織タイプの既定値を適用した後の「実際に効いている設定」を返します。管理者がConsoleで設定した値そのものではなく、それらの制約を通過した後の値である点が、監査で意味を持ちます。データ保持期間、コンテンツのredaction(機微情報の伏せ込み)、SSO強制、IP許可リスト、セッション時間制御を、管理者コンソールにアクセスせずに証跡として残せます。

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"

対象にできるのは親組織配下の連結組織だけで、親組織自体は対象にできません。404 Not Foundが複数の原因を一つにまとめている点は、後述の「つまずきやすいポイント」で扱います。

設定に出てこない行は「オフ」ではなく「その組織の管理者には変更権限がない項目」として扱います。Anthropicのポリシーで固定されている設定や、その組織で利用できない設定は、レスポンスのsettings配列に現れません。

レスポンスのapi_keys配列には、親組織に紐づく全Complianceアクセスキーの一覧(id / name / scopes / is_active / 作成者・有効期限)が入ります。どの連結組織に対して呼んでも同じ一覧が返ります。無効化済みのキーや、廃止済みスコープしか持たないキーも一覧から消えないため、鍵の棚卸しにそのまま使えます。

廃止スコープに注意する

このエンドポイントは以前read:compliance_org_settingsという専用スコープを要求していましたが、そのスコープは廃止済みで、新規キー作成時に選択できません。廃止スコープしか持たない既存キーで呼び出すと403 Forbiddenになります。すでにread:compliance_org_dataを持つキーはこの廃止の影響を受けません。エラーの詳細な原因分岐はCompliance APIのエラーハンドリング完全ガイドにまとめています。

電子情報開示(eDiscovery)のユーザーリストをどう組み立てるか

典型的な電子情報開示のフローは、組織一覧から対象組織のIDを絞り込み、その組織のユーザー一覧を取得し、自社の人事データと突き合わせる、という流れです。一致したユーザーIDは、そのままチャット・セッション系のクエリへ渡します。組織のユーザー一覧は「現在アクティブなメンバー」しか返さないため、退職者を含めた調査では、まず組織のユーザー一覧でIDを確定できる現役分を処理し、退職済みの対象者はActivity Feedのactor_ids[]フィルタで別途拾う、という二段構えが必要です。

グループ単位で調査範囲を絞る場合は、グループ一覧のroles配列とロール一覧のidを突き合わせて、「どのグループがどのロールを持つか」を先に確定してから、対象グループのメンバー一覧を取得する順番が効率的です。逆にメンバー一覧から先に全件を舐めると、無関係なグループのメンバーまで大量に取得することになります。

つまずきやすいポイント

いずれもエラーメッセージやレスポンスの見た目だけでは気づきにくく、実装時に想定と違う挙動として現れます。典型的な失敗と、原因・対処の早見表です。

3件に共通するのは、レスポンスの見た目(フィールド名・ステータスコード)だけでは原因を判別できず、どのエンドポイントの応答かという文脈を合わせて読む必要がある点です。同じorganization_idや同じ404でも、返ってきたエンドポイントによって意味が変わることを前提にコードを書きます。

ページネーションの実装で気をつけること

ディレクトリ系エンドポイントはpageという不透明トークンでページ送りします。Activity Feedのbefore_id / after_idカーソルとは形式が異なるので、同じコードで両方を扱おうとすると壊れます。pageの値は常に前回レスポンスのnext_pageをそのまま渡し、自分でIDから組み立てません。has_moreがfalseになった時点で歩き終わりです。

アクセス範囲・データ保持・ページネーションでよくある疑問はCompliance APIのFAQに、スコープ不足時の具体的なエラーメッセージはCompliance APIのエラーハンドリング完全ガイドにまとめています。ロール設計そのものを見直すならClaude Enterpriseでカスタムロールを作成する手順も参考になります。

まとめ

組織一覧・ユーザー一覧・ロール一覧・グループとメンバー・実効組織設定の5つのエンドポイントは、スコープの要求がread:compliance_org_dataとread:compliance_user_dataに分かれています。ディレクトリ配下を全件取得する用途なら、キー作成時に両方のスコープを選んでおくのが手戻りを避ける一番の近道です。read:compliance_org_settingsのような廃止済みスコープを見つけたら、既存キーを使い続けようとせず新しいキーへ切り替えます。スコープの過不足と識別子の形式違いは、実装をひととおり終えた後になって404や403という形で表面化しやすいため、キー作成の時点とコーディングの時点の両方で、一度立ち止まって確認しておくと後の手戻りを防げます。