ClaudeをSailPoint連携でアクセスレビューに載せる手順 — ユーザー・グループ・ロールの棚卸し
SailPointのClaude Enterpriseコネクタで組織のユーザー・グループ・ロールを取り込み、ソースオーナー向けの認定キャンペーンで棚卸しする手順と、取り消しが自動で届かない点まで示します。
SailPointのClaude Enterpriseコネクタは、Claude Enterpriseの組織ユーザーをアカウントとして、ロールとグループを権限(エンタイトルメント)として取り込みます。取り込んだ後は、SailPointの認定キャンペーンで「誰がどのロール・グループを持っているか」をレビューにかけられます。
接続の土台になるのは、AnthropicのCompliance APIです。コネクタは読み取り専用で動き、レビューで「取り消し」と決めた結果をClaude側へ自動で反映する機能は、対応機能の一覧に載っていません。この記事は、接続から最初のキャンペーン開始までの流れと、その線引きをまとめます。
SailPointに取り込まれるのは、ユーザー・ロール・グループ
コネクタが対象にするのは、次の対応づけです。
| Claude Enterprise側 | SailPoint側の扱い | 識別子の形 |
|---|---|---|
| 組織のユーザー | SailPoint側の扱いアカウント | 識別子の形id |
組織ロール(organizationRole) | SailPoint側の扱いエンタイトルメント | 識別子の形組織UUID:ロール名 |
コンプライアンスロール(complianceRole) | SailPoint側の扱いエンタイトルメント | 識別子の形組織UUIDとロールIDを:でつないだ値 |
| コンプライアンスグループ | SailPoint側の扱いエンタイトルメント | 識別子の形グループID(rbac_group_*の形) |
Claude Managed Agentsも取り込み対象ですが、これはSailPoint Agentic Fabricを契約している組織の機能です。人のアクセスレビューとは別の流れなので、この記事では扱いません。エージェントの集約はベータ版のAPIを使うため、将来変わる可能性があると注記されています。
グループとロールのつながりは、グループ側のroles属性と、ユーザー側のgroups属性で追えます。ユーザーからグループ、グループからロールへ、2段で権限が決まる構造です。
連携の前に揃える条件
Claude側とSailPoint側で、先に用意するものがあります。
- Claude EnterpriseプランのPrimary Ownerであること
- Compliance APIを有効にして、コンプライアンスAPIキーを作成すること
- キーのスコープに
read:compliance_org_data、read:compliance_user_data、read:compliance_activitiesを付けること - SailPointでソースを作成できる管理権限があること
Claude Enterpriseプランには、一般にCompliance APIが含まれます。ただしPublic Sector(公共部門)の組織は例外です。この条件に当たる場合は、そもそもキーを作れません。
3つのスコープの違いは、Compliance APIで組織のユーザーとグループを取得する手順に整理しています。read:compliance_user_dataは、会話やファイルの中身まで読めるスコープでもあります。レビュー専用のキーとして発行するなら、保管場所と閲覧できる管理者を絞っておきます。
手順: キーの作成からテスト接続まで
接続から最初の集約までの流れ
- 1
Claude側でCompliance APIを有効にする
組織設定の「Data and privacy」を開き、Compliance APIの欄で有効化します。続けて「+ Create key」でキーを作り、先の3スコープを選びます。
- 2
SailPointでソースを作る
管理画面の接続一覧(Admin > Connections > Sources)から新規作成し、コネクタ名で「Claude Enterprise」を検索して構成します。ソース名・ソースオーナー・説明を入れます。
- 3
接続設定を入れる
API Base URLは
https://api.anthropic.comのまま変えません。Compliance API Keyの欄に、作成したキーを貼ります。 - 4
集約の設定を決める
Organizationsで対象の組織を選びます。1つも選ばなければ、すべての組織が対象です。組織一覧はキーを保存してから、接続テストか更新で読み込まれます。
- 5
確認してテストする
「Review and Test」の要約を読み、問題がなければ「Test Connection」を押します。成功したら、アカウントとエンタイトルメントの集約を実行します。
設定値は、控えとして次の形で残しておくと、後から差分を追いやすくなります。
ソース名 : Claude Enterprise(本番)
API Base URL : https://api.anthropic.com
Compliance APIキー : (シークレット管理側に保管。ここには書かない)
Organizations : 対象の組織を選択(未選択なら全組織)
Connection Timeout : 1分(既定値)
Page Size : 100(既定値。1〜1,000)
キーのスコープ : read:compliance_org_data
read:compliance_user_data
read:compliance_activitiesソースの作成時、プロビジョニング(SailPointからの変更書き込み)は既定で無効です。コネクタは読み取りだけを行います。一度有効にすると無効に戻せないという注意もあるため、Claudeのように対応機能の一覧に変更系がないソースでは、触らないのが無難です。
取り込んだ属性を、レビューでどう読むか
アカウントには、email、full_name、created_at(組織に加わった日時)、organization_names、organization_roles、groupsなどが入ります。organization_rolesは組織UUID:ロールの形で、ロールのエンタイトルメントと同じ値です。
最終ログインを見たいときは
last_loginとlast_login_methodは、既定では取り込まれません。read:compliance_activitiesスコープをキーに付けたときだけ読めます。処理が重く、集約の時間が延びるため、必要になってから追加する扱いです。
休眠ユーザーの洗い出しや、退職者の残存確認に最終ログインを使いたいなら、このスコープを最初から付けておきます。ADの休眠アカウントを見る流れはActive Directory休眠アカウントの棚卸しにあります。
権限の重さは、推奨レベルで並べる
SailPointの権限分類(Privilege Classification)は、組織ロールの値ごとに推奨レベルを付けます。
| 推奨レベル | 組織ロールの値 |
|---|---|
| High | 組織ロールの値admin、billing、membership_admin、primary_owner、owner |
| Medium | 組織ロールの値developer、managed |
| Low | 組織ロールの値claude_code_user、user |
レビューの優先順位は、このレベルで決められます。Highの付いたロールを持つ人から先に確認すると、数が多い組織でも要所を外しません。
照合のキーはメールアドレス
SailPointがClaudeのアカウントを社内のIDに結びつける既定の条件は、ID側のWork Emailとアカウント側のemailの一致です。比較の演算は「Equals」で固定され、変更できません。
条件の追加や変更は、アカウント管理の「Account Correlation」から行います。IdP側のメールアドレスと、Claudeに登録されているメールアドレスの表記が違うと、照合が取れないアカウントが残ります。原因の切り分けはSSO・SCIM設定でメールアドレスが一致しないときの対処が参考になります。
アクセスレビューを組む
取り込みが済んだら、ソースオーナー向けの認定キャンペーンを作ります。ソースオーナーは自分が所有するソースのIDだけをレビューします。
ソースオーナーキャンペーンの作り方
- 1
ソースオーナーを確認する
キャンペーンは、ソースオーナーが割り当てられているソースにしか生成されません。Claudeのソースの設定で、レビューを担当する人が入っているかを先に見ます。
- 2
キャンペーンを新規作成する
Admin > Certifications > Campaignsから「Create New」を選び、種類で「Source Owner Campaign」を選びます。名前と説明を入れ、期限を決めます。既定の期限は作成から2週間後です。
- 3
対象のソースを選ぶ
ソースの選択欄で、Claude Enterpriseのソースにチェックを入れます。全ソースを一括で対象にする選択肢もあります。
- 4
未決定の項目の扱いを決める
期限までに判断されなかった項目は、既定ではアクセス維持として承認されます。完了時に管理者が「全て承認」か「全て取り消し」を選べる設定もあります。SailPointは、取り消し後の復旧が難しいため、既定の維持を推奨しています。
- 5
プレビューを確認して開始する
「Preview Campaign」でレビュー担当者ごとの対象人数を確かめ、「Start Campaign」で開始します。プレビューを作ってから1日以内に開始する決まりです。過ぎたら削除して作り直します。
レビューで見る観点は、取り込んだ属性から作れます。
organization_rolesにHighのロールが付いている人は、業務上の理由があるかgroupsに、異動前の部署のグループが残っていないか- 組織ロールとグループ経由のロールが、重複して付いていないか
created_atが古いのに、last_loginが空か古い人はいないか(スコープを付けた場合)
退職者の残存確認は、SailPoint側のID(人事連携で退職が反映されたID)と、Claudeのアカウントの突合で行います。Claudeのコネクタ自体は人事情報を持たないため、照合の元になるのは前節のメールアドレスです。SSO/SCIMでアカウントが自動で消える構成かどうかは、ClaudeのSCIM同期の仕組みで確かめられます。
取り消しの結果は、Claude側で人が反映する
認定キャンペーンで「取り消し」を選ぶと、SailPointは接続先のソースから権限を外そうとします。SailPointが接続先に直接書き込めない場合は、ソースオーナー宛てに「ソース側で変更してください」というタスクを作ります。管理者は、このマニュアル対応の進み具合を確認できます。
Claudeのソースは、対応機能が「アカウントの集約」「エンタイトルメントの集約」「権限分類」「マシンID(エージェント)の集約」で、書き込み系が載っていません。レビューで外すと決めたロールやグループは、Claudeの管理画面かSCIM側で、人が実際に外す運用になります。
組織ごとに独自のロールを持たせている場合は、割り当ての考え方をClaude Enterpriseのカスタムロールでプログラムを割り当てる手順で確かめておくと、レビュー時にロール名の意味を迷いません。
また、署名(認定の完了)を押さなかった取り消しは適用されません。期限切れの扱いは、キャンペーン作成時の設定で決まります。
つまずきやすい点
落とし穴
組織を選べない、または0件になる
組織の選択肢は、有効なCompliance APIキーを保存してから読み込まれます。キーを入れる前に集約設定を開くと、一覧が空になります。接続設定を保存して、テストか更新をやり直します。
落とし穴
最終ログインの列が空のまま
last_login系は、read:compliance_activitiesが付いたキーでしか取れません。キーのスコープに含まれているかを、Claude側のキー一覧で確かめます。
落とし穴
アカウントIDを変えて、集約が壊れる
ユーザーのid、グループのidなど、アカウントIDの属性は既定のまま使う決まりです。変えると、コネクタが失敗することがあります。直すときは既定値に戻します。
大規模な組織で集約が遅いときは、ページサイズ(1〜1,000件、既定は100件)と接続タイムアウトを調整できます。エージェント側では、シングルワークスペースからマルチワークスペースに切り替えると、以前のワークスペースキーは自動では引き継がれません。Multi-Workspaceの表に、必要なキーを入れ直します。
まとめ
Claude Enterpriseのアクセスレビューは、Compliance APIのキー、SailPointのソース、ソースオーナー向けキャンペーンの3点がそろえば回せます。判断の材料は、組織ロールの推奨レベルと、グループ・ロールのつながりです。
一方で、取り消しはClaude側に自動では届きません。レビューの結果を管理画面かSCIMで反映する担当者を、キャンペーンを始める前に決めておくのが現実的な準備です。請求やSSOログと突き合わせる別の棚卸しは、SaaSの棚卸しをClaudeで進める手順で扱っています。