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

Claude組織のIDプロバイダー(IdP)を別のものへ乗り換えるときは、ユーザーのアクセスを保ったまま、旧IdPの接続を切り新IdPへ切り替える手順を順番通りに踏む必要があります。この手順はすでにSSOが設定済みの組織が別のIdPへ移行するとき専用で、初めてSSOを設定する場合は対象外です。

始める前に確認すること

必要な権限を持っているか確認します。ClaudeのTeam・EnterpriseプランではOwnerまたはPrimary Owner、Claude ConsoleではAdminロールが必要です。

利用者への事前告知も欠かせません。移行の途中で全ユーザーが一時的にサインアウトされるため、あらかじめ通知し、業務影響の小さい時間帯を選んで実施します。

もっとも見落としやすいのがメールアドレス属性の一致確認です。新しいIdPに登録するSSOおよびSCIMのメール属性は、旧IdPで使っていたものと完全に一致させる必要があります。1文字でも違えば、同じ人物として認識されません。結果は重複アカウントの作成です。

接続している組織をすべて洗い出すことも事前準備の一つです。同じIdPに複数のClaude組織やConsole組織がぶら下がっている場合、手順の各ステップは組織ごとに個別へ適用します。着手前に対象組織の一覧を作っておくと、後半のステップで一部の組織を切り替え忘れる事態を防げます。

切り替えの手順

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

該当する場合、現在のIdP側でCreate/Updateイベントの送信を止めます。移行作業中に同期シグナルが飛んでくるのを防ぐためです。

ステップ2: プロビジョニングモードを「Invite only」に切り替える

該当する場合、SCIMプッシュを無効化してから約1時間の待機を挟みます。接続しているすべてのClaude組織(claude.ai/admin-settings/organization)またはConsole組織(platform.claude.com/settings/identity)の「Identity and access」ページを開き、「Global SSO Configuration」でプロビジョニングモードを「Invite only」に設定します。これにより、SCIMによる自動的なユーザー管理が止まります。既存メンバーは組織に残ったまま、SCIMイベントの対象外になります。

1時間という待機時間は、SCIM同期が結果整合性(eventually consistent)のポーリング方式で動いていることと関係していそうです。自動同期は通常1分おきに動きますが、混雑時には反映まで数時間かかることがあるため、この待機はキューに残った同期シグナルを先に消化させるための安全マージンと考えられます。同期そのものの仕組みはClaude SCIM同期の仕組みで扱っています。

ステップ3: SCIMディレクトリを削除する

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

ステップ4: SSO接続をリセットする

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

ステップ5: リセットを確認する

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

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

SSOのセットアップ手順に従い、必要であればグループマッピングを有効にしたJITまたはSCIMのプロビジョニングを設定します。接続しているすべてのClaudeおよびConsole組織で、新しいIdP上の正しいグループにユーザーが割り当てられていることを確認します。設定後は「Manage SCIM」を開き、どのユーザーがディレクトリに同期され、正しいグループに紐づいているかを確認できます。旧IdPで使っていたグループ構成をそのまま新IdP側で再現できていないと、切り替え後にカスタムロールや支出上限の割り当てが変わってしまうため、グループマッピングは旧環境の設定を見ながら1つずつ照合するのが安全です。

ステップ7: プロビジョニングを再度有効化する

該当する場合、「Approve automatically (JIT)」または「Sync with SCIM」を選んでプロビジョニングモードを切り替え、「Save Changes」をクリックして適用します。「Sync with SCIM」を選んだ直後は、新しいIdPディレクトリを基準にした初回の再同期が走ります。反映されたメンバー数がIdP側の人数と一致するかは、この時点で一度確認しておくと安心です。

SCIMを使っていない組織は手順がどう変わるか

ステップ1・ステップ3、そしてステップ7の「Sync with SCIM」選択は、いずれもSCIMプロビジョニングを使っている組織限定です。SSOだけを使い、ユーザー管理はJIT(初回ログイン時の自動作成)または招待制で行っている組織であれば、これらは飛ばして構いません。

その場合の流れは短くなります。ステップ2でプロビジョニングモードの確認だけ済ませ、ステップ4のSSO接続リセットから始めます。ステップ5で確認、ステップ6で新しいIdPをSSO用に設定し、必要ならステップ7で「Approve automatically (JIT)」を選び直します。SCIM関連の手順を無理に実行する必要はありません。

なぜSSO接続を先にリセットする必要があるのか

接続が有効な間はボタンが「Manage SSO」のままで、リセットして初めて「Setup SSO」に変わります。つまり新IdPの設定は、旧IdPとの接続を切った後にしか始められません。この順序が手順として固定されているのはこのためです。ステップ1〜3でSCIM側の後始末を先に終わらせるのも同じ考え方で、旧接続が残ったまま次のIdPを触り始めると、どちらの設定変更が反映されたのか切り分けにくくなります。手順を7つに分けているのは作業を細分化するためではなく、この依存関係を守るためです。

よくあるつまずき

メール属性のわずかな表記違いに気づかない: 大文字小文字の違いやドメインのサブアドレス表記など、目視では気づきにくい差異が重複アカウントの原因になります。切り替え前に新旧IdPのユーザー一覧をエクスポートし、機械的に突き合わせる方が確実です。

SCIMプッシュを無効化した直後にプロビジョニングモードを切り替えてしまうケースもよくあります。キューに残っていた同期シグナルが後から適用され、意図しないメンバー変更が起きる余地があるためです。約1時間の待機はここで効いてきます。

同じIdPに複数のClaude・Console組織がぶら下がっている場合、手順は組織ごとに個別に実施する必要があります。1つの組織だけ新IdPに切り替え、他の組織が旧IdPのままだと、ユーザーごとに使える組織がばらつく状態になります。

リセット直後は全ユーザーがサインアウトされ、メールリンクでのサインインに切り替わります。新しいIdPの設定が終わるまでの期間、ユーザーからの問い合わせが増えることを見込んで告知しておくと混乱を避けられます。

よくある質問

切り替え中、既存のプロジェクトやチャット履歴は失われますか

手順自体はユーザーのメンバーシップとSSO接続の付け替えが目的で、プロジェクトやチャットのデータには触れません。ただし、新旧のメールアドレス属性が一致しない場合は別のメンバーレコードとして作成され、過去のデータには紐づかなくなる点が実質的なリスクです。

初めてSSOを設定する場合もこの手順ですか

いいえ。この手順はすでにSSOが設定済みの組織が別のIdPへ移行する場合専用です。初めてSSOを設定する組織は、通常のSSOセットアップ手順に従います。

移行作業は業務時間中でも問題ありませんか

手順の途中(ステップ4)で全ユーザーが強制的にサインアウトされ、新IdPの設定が終わるまではメールリンク経由のサインインになります。業務への影響を考えると、利用が少ない時間帯を選んで実施するのが安全です。

まとめ

Claude組織のIdP切り替えは、SCIMプッシュの停止 → Invite only化 → SCIMディレクトリ削除 → SSOリセット → 確認 → 新IdP設定 → プロビジョニング再有効化、という7ステップで進みます。手順そのものより、メールアドレス属性の完全一致と、複数組織がある場合の対応漏れが実務上のつまずきどころです。切り替え後のロール・グループ設計はClaude Enterpriseでカスタムロールを作成する手順、組織の変更履歴を後から追いたい場合はClaude監査ログの見方にまとめています。Enterpriseプラン自体の権限体系はClaude Enterpriseとはを参照してください。