Claude IdP切り替え、SSOリセットの7手順

Claude組織のIDプロバイダー(IdP)を別のものへ乗り換えるときは、旧IdPの接続を切ってから新IdPを設定する順序を守る必要があります。この手順はすでにSSOが設定済みの組織が別のIdPへ移行するとき専用で、初めてSSOを設定する場合は対象外です。

切り替える前に済ませておくこと

必要な権限は、TeamまたはEnterpriseプランならOwnerかPrimary Owner、Claude ConsoleならAdminロールです。移行の途中で全ユーザーがサインアウトされるので、利用者への事前告知と、業務影響の小さい時間帯の選定も済ませておきます。

最大の落とし穴はメールアドレス属性の不一致です。新しいIdPに登録するSSOとSCIMのメール属性は、旧IdPで使っていたものと完全に一致させます。一致しないと、ユーザーは重複アカウントとしてプロビジョニングされます。

もう1つ、構造上の前提があります。親組織が紐づけられるIdPは1つだけです。同じ親組織にぶら下がるClaude組織とConsole組織は、すべて同じIdPで管理されます。したがってSSOのリセットと新IdPの設定は親組織単位で1回です。組織ごとに行うのは、各組織の「Identity and access」ページでのプロビジョニングモードの切り替えです。

7ステップの流れ

次の7ステップのうち、ステップ1〜3とステップ7は、該当する組織だけが行います。1時間の待機とSCIMディレクトリの削除は、SCIMを使っている組織の話です。

手順

IdP切り替えの7ステップ

1. 1

   現在のIdPからのSCIMプッシュを無効化する

   該当する場合、現在のIdP側でCreate/Updateイベントの送信を止めます。

2. 2

   プロビジョニングモードを「Invite only」にする

   該当する場合、ステップ1から約1時間待ちます。その後、接続しているすべてのClaude組織とConsole組織で「Identity and access」ページを開きます。Claude組織はclaude.ai/admin-settings/organization、Console組織はplatform.claude.com/settings/identityです。「Global SSO Configuration」でプロビジョニングモードを「Invite only」にします。

3. 3

   SCIMディレクトリを削除する

   該当する場合、「Manage SCIM」から「Delete Directory」をクリックします。Invite onlyモードのときは、ディレクトリを削除してもデプロビジョニングを含む同期イベントは発生しません。

4. 4

   SSO接続をリセットする

   「Manage SSO」から「Reset Connection」をクリックします。全ユーザーがサインアウトされ、新しいIdPでSSOが設定されるまではメールリンクでサインインします。

5. 5

   リセットを確認する

   「Identity and access」ページを更新し、ボタンが「Manage SSO」から「Setup SSO」に変わっていることを見ます。

6. 6

   新しいIdPをSSOとプロビジョニング用に設定する

   SSOのセットアップ手順に従い、必要ならグループマッピングを有効にしたJITまたはSCIMを設定します。接続しているすべてのClaude組織とConsole組織で、新しいIdP上の正しいグループにユーザーが割り当てられているか確かめます。「Manage SCIM」を開けば、どのユーザーがディレクトリに同期されグループに紐づいているかを確認できます。

7. 7

   プロビジョニングを再度有効化する

   該当する場合、「Approve automatically (JIT)」か「Sync with SCIM」を選び、「Save Changes」で適用します。

SCIM同期はWorkOSに届いた更新イベントを1分おきに取り込み、通常は数分で終わります。システムが混み合う時間帯には、数時間かかることもあります。同期の仕組みはClaude SCIM同期の仕組みで扱っています。

SCIMを使えない組織の流れはどうなるか

Teamプランの組織ではSCIMを使えません。Teamプランの親組織に合流したConsole組織でも同様です。この場合は最初からJITか招待制の側の流れになり、ステップ1・3(SCIMの停止とディレクトリ削除)は不要です。ステップ7では「Approve automatically (JIT)」を選びます。

JITはメンバーを自動で削除しません。Claude側だけでユーザーを削除しても、そのユーザーは次のSSOログインで再追加されます。完全に外すには、Claudeで削除したうえでIdP側の割り当ても外します。JITでカスタムロールにマップするときは、組織設定のGroupsでグループを作って手作業で割り当てます。割り当てがないと、そのユーザーはログインしても権限がありません。

新IdPでメールが一致しないとどうなるか

メールが一致しない原因は、IdPごとに決まった形があります。

IdP別

IdPごとのメール属性の食い違い

• Okta

  SCIMはuser.loginを使い、SAMLはuser.emailを送ります。この2つが異なる値だと不一致になります。

• Microsoft Entra ID

  SCIMのuserNameの既定マッピングはuserPrincipalNameで、OIDC・SAMLのメールクレームはmailです。両者が違えば食い違います。

• Google Workspace

  SCIMがエイリアスのアドレスを送り、SAMLがプライマリのメールを送る構成だと食い違います。

不一致が起きたときの症状は4種類あります。

• アカウントの作成がブロックされる
• 無料の個人アカウントに着地する(組織作成を制限していない場合のみ)
• 「Please confirm your email」の不一致画面が出る
• Claude Codeの認証が失敗する

SSOとSCIMが別の属性からメールを取るため、画面の症状だけでは原因が分かりにくい点が厄介です。まずSSOとSCIMが送っている属性の組を、上のカードに沿ってIdP側で確認します。

見えにくい被害もあります。誤ったメールで作られた「ghost accounts」は、誰も使えない席を占有します。席が埋まると、新規ログインは席不足のエラーで失敗します。

メール属性を直して全同期を終えたあとにも後始末があります。ghost accountsと、不一致の間に作られた無料の個人アカウントは、サポートに削除を依頼します。ghost accountsの削除後は、正しいメールの人を再招待するか再プロビジョニングする必要が出ることがあります。再発は、Identity and accessの「Restrict organization creation」を有効にして防ぎます。

ステップ7で「Sync with SCIM」を選ぶ前に知っておくこと

「Sync with SCIM」を選んで再同期が走ると、メンバーの追加と削除が起きます。契機は次の4つです。

SCIMの再同期には、実行前の確認の仕組みがあります。同期によってメンバーの異常に大きな割合が削除される場合、プレビューに警告が表示されます。削除数が実際の退職者より大幅に多いなど想定と違えば、同期を取り消して、IdPのディレクトリとグループマッピングを見直します。

Primary OwnerはSCIMの照合の対象外です。IdPのディレクトリにいなくても、ロールにマップされたグループに入っていなくても、同期ではスキップされ、所属とロールは保たれます。この例外は唯一のPrimary Ownerにだけ適用され、OwnerとAdminはディレクトリとグループに含まれている必要があります。Primary OwnerはSCIMのグループマッピングでは割り当てられず、組織設定のMembersから手動で移すだけです。SCIMを有効にする前に、誰をPrimary Ownerにするかを決めておきます。

SCIMでプロビジョニングされた新メンバーには、歓迎メールが送られます。止めるのは、OwnerかPrimary Ownerの操作です。組織設定のUser provisioningでSCIM directory syncを開き、「Send a welcome email to new members」をオフにします。変更は保存後にプロビジョニングされたメンバーから適用され、送信済みのメールは取り消せません。CMEK、HIPAA、FERPAなどの要件がある組織にはこのメールが送られず、設定も表示されません。

手動での同期は、100人あたり約1分が目安です。Microsoft Entraは、SCIMの変更を40分おきにしかプッシュしません。

モードをSCIMに切り替えたら、初回の再同期が終わるのを待ってからグループマッピングを設定します。グループマッピングを有効にすると、メンバーのロールと席種はマッピングで決まり、手動では上書きできません。マッピングを保存したあとは「Sync」を押して、既存メンバーのロールと席種を再計算します。

手動同期は、2か所から起動します。GroupsページのSCIM syncにある「Check for updates」と、Organization and accessのUser provisioningにある「Sync」です。対象は、メンバー・グループ・両方から選びます。反映済みかどうかは、Membersの「Export CSV」か「Manage SCIM」で確かめます。バックグラウンドで変更の処理中に手動同期を走らせると、メンバーやグループごとに最新の変更だけが取られます。同じ対象に複数の変更が溜まっていたときは、もう一度再同期が要ることがあります。

席種のマッピングはロールと挙動が違います。席種のグループに入っていないメンバーは削除されず、既存メンバーは今の席種のまま残ります。新規メンバーは、未割り当ての購入済み席が残っている席種のうち最上位で追加され、空きがなければ席なしで追加されます。グループマッピングを無効にすると、ロールと席種を手動で割り当て直せます。既存メンバーのロールは変わらず、新規メンバーはUserロールになるので、カスタムロールの権限を使うなら「Custom」に変更します。

切り替え後に確認する項目

SCIMを使う構成へ戻す場合は、モードを変える前に、既存メンバー全員が新IdPのディレクトリにいるかを確かめます。旧IdPで使っていたグループ構成が新IdPでも再現できているかは、グループ単位で照らします。支出上限やカスタムロールの割り当てがグループ経由なら、ここがずれると権限が変わります。

新IdPの全同期をやり直すには

メール属性を直したあとなど、全同期が必要になる場面があります。その操作はIdPによって異なります。

まとめ

実務で差が出るのは、メール属性の一致と、SCIMへ戻すときの再同期のプレビュー確認です。前者はずれると重複アカウントと席の占有に、後者は想定外のメンバー削除につながります。

切り替え後のロール・グループ設計はClaude Enterpriseでカスタムロールを作成する手順、組織の変更履歴を後から追いたい場合はClaude監査ログの見方にまとめています。Enterpriseプラン自体の権限体系はClaude Enterpriseとはを参照してください。