Claude SSO・SCIM導入前に確認する3点

SSO・SCIM導入前に確認すべき3点

ClaudeでSSOやSCIMを有効化する前に確認すべきことは3つです。親組織(parent organization)の有無とその紐付け方、契約プランで使えるプロビジョニング方式の違い、そしてSSO強制がすでにアカウントを持つ社員に与える影響です。この3つを飛ばして設定を進めると、想定外のユーザーがログインできなくなったり、ドメインの再検証が必要になったりします。手順そのものはClaudeのSSO設定手順にまとめてあるので、本記事では設定に着手する前に潰しておくべき論点だけを扱います。

親組織(parent organization)とは何か

親組織とは、複数のClaude組織やConsole組織にまたがってSSO設定を共有するための入れ物です。ドメイン検証・IDプロバイダー(IdP)の接続・グループマッピングといったID関連の設定はすべて親組織側に保存され、紐づく各組織はそれを参照する形になります。

自分の組織に親組織があるかどうかは、契約プランで変わります。

親組織にまつわる制約はいくつかあります。ドメイン検証は親組織単位で行われ、一度検証済みになったドメインは別の親組織から横取りできません。複数の組織を同じ親組織に紐づけると、ドメイン検証とSSO設定を使い回せます。ClaudeのTeam・Enterprise組織とConsole組織の両方を運用している会社にとっては便利な仕組みです。

ただし1つの親組織が接続できるIDプロバイダーは1つだけという制約があるため、同じ親組織に紐づく組織はすべて同一のIdPで管理する前提になります。異なるIdPを使い分けたい場合は、親組織自体を分ける必要があります。

もう一点、親組織が管理するのはID・アクセスの範囲だけだという点も押さえておく必要があります。請求・インボイス・利用量トラッキングは各組織単位で個別に処理され、親組織の紐付けによる影響を受けません。

プランによってスタート地点が違う

自組織がどのプランかで、次にやることが変わります。

TeamプランまたはEnterpriseプランを契約している場合は、親組織がすでに存在するか、SSO有効化のタイミングで自動作成されるため、そのままSSO設定手順に進んで問題ありません。

Consoleを契約していて、かつ既存のTeam・Enterpriseプランもある場合は、すでに親組織へ紐づいている可能性があります。platform.claude.com/settings/identity にアクセスできるか確認してください。アクセスできればすでに親組織と連携済みでSSOも設定済みという意味です。アクセスできない場合は、Team・Enterprise側のOwnerが組織統合(後述のMerge Organizations)を開始する必要があります。

Consoleのみを契約していてTeam・Enterpriseプランがない場合は、親組織が自動的には作られません。Anthropicの営業チームに連絡し、Console用の親組織作成を依頼してください。作成されると、Console上にIdentity settingsページが現れ、SSO設定に進めるようになります。

プロビジョニング方式をプランで比較する

SSOを設定したあと、ユーザーをどう組織に追加するかを選ぶことになります。方式は3つあり、契約プランによって使える範囲が変わります。

SCIMだけはTeamプランで使えません。公式サポート記事には注記があり、Console組織がTeamプランの親組織に統合されている場合は、そのConsole組織もSCIMを使えないとされています。中小規模のチームがTeamプランのままSCIMによる入退社の自動同期を実現する方法は、現状用意されていません。SCIMが必須要件なら、Enterpriseへの契約変更か、独立した親組織を持つConsole組織を別途用意する以外の選択肢がないという点は、契約前に把握しておく価値があります。プランごとの料金・統制機能の全体像はClaude Enterpriseの法人プランガイド、Teamとの比較はClaude Teamプランガイドで確認できます。

SSOを有効化すると既存ユーザーはどうなるか

社内で個人のFree・Pro・Team・Maxアカウントをすでに使っている社員がいる場合、SSO有効化の影響は2パターンに分かれます。

SSOアプリケーション(IdP側のClaudeアプリ)にその社員が割り当てられている場合、既存アカウントへのアクセスは維持されます。画面左下のプロフィールアイコンから、Team・Enterprise組織のアカウントと元の個人アカウントを切り替えて使えます。

割り当てられていない場合は、「Require SSO for Claude」の設定次第で結果が変わります。この設定が無効なら、社員は引き続き「Continue with email」から既存アカウントへログインできます。有効(SSO強制)にすると、その社員は既存のFree・Pro・Team・Maxアカウントへログインできなくなります。アカウント自体は削除されませんが、SSO経由でしかログインできない状態になるため、事実上アクセス不能になります。

ドメイン検証が完了すると、Ownerには「Organization and access」ページのSecurity欄に「Restrict organization creation」というトグルも表示されるようになります。これをオンにすると、検証済みドメインを使って新しくClaudeやConsoleの組織(個人アカウントを含む)を作成することを止められます。SSO強制と合わせて有効化しておくと、既存ユーザーの移行と同時に、社員が検証済みドメインで未管理の個人組織を作ってしまう抜け道もふさげます。

組織を統合する(Merge Organizations)が必要なケース

Team・Enterprise組織とConsole組織を別々に運用していて、SSO設定を共有したい場合はMerge Organizationsを使います。この操作を開始できるのはTeam・Enterprise組織(claude.ai)側だけで、Console組織から統合を持ちかけることはできません。招待される側になります。

統合には次の条件が必要です。

• 招待する側(Team・Enterprise)の親組織で、ドメイン検証が完了していること
• 招待されるConsole組織のメンバー全員のメールアドレスが、その検証済みドメインと一致すること
• 招待されるConsole組織のAdmin(Console)またはOwner(Claude)が統合を承認すること
• 招待されるConsole組織が、他の親組織にすでに所属していないこと

統合の申請は「Organization settings > Organization and access」から送信し、招待された側のAdmin・Ownerに承認を求めるメールが届きます。承認期限は14日間です。招待したいConsole組織が招待リストに出てこない場合、その組織がすでに別の親組織(独自のドメイン検証・SSO設定を持つ)に属している可能性があります。この場合はサポートに連絡してデタッチ(切り離し)を依頼する必要がありますが、デタッチするとその組織の既存のドメイン検証・SSO/SCIM設定は消去される点に注意してください。実行前に、その組織の管理者に必ず了承を取ってください。

統合が完了すると、Console組織は「Identity and access」ページにアクセスできるようになり、SSO・プロビジョニング設定を親組織側で一元管理できます。

導入前にやっておくべき実務チェックリスト

設定作業そのものに入る前に、次の項目を済ませておくと移行がスムーズになります。

• 既存アカウントの棚卸し: 「Organization and access」(claude.aiの場合)または「Identity and access」(Consoleの場合)の「Domains」セクションから「Domain memberships」を開くと、自社の検証済みドメインに紐づく既存アカウントの一覧をCSVまたはJSON形式でダウンロードできます。強制前にこれで対象社員を洗い出しておきます
• 全社員への周知: SSOへの移行タイミングを明確なスケジュールで伝える
• 会話履歴のエクスポート案内: SSOアプリに割り当てられない予定の社員には、強制前に会話履歴を保存・エクスポートするよう案内する
• 業務影響の少ない時間帯を選ぶ: 実施タイミングは利用の少ない時間帯にずらす
• IT部門の受け入れ体制: 移行中の問い合わせに即応できる体制を組んでおく
• アクセス権付与プロセスの明確化: 認可されたユーザーへのアクセス付与フローを事前に決めておく
• SSOとプロビジョニングを同時に導入する: 可能なら、SSO設定とJIT・SCIMのプロビジョニング設定を同じタイミングで実施する。段階的に導入すると、SSOだけ先に強制してプロビジョニング未設定のまま既存ユーザーが宙に浮く状態が生まれやすい

次にやること

ここまでの論点を潰せたら、ClaudeのSSO設定手順でドメイン検証からIdP接続までの実際の操作に進んでください。プロビジョニング方式の選定やグループマッピングの詳細はJIT/SCIMプロビジョニングの設定手順、契約プラン自体で迷っている場合はClaude法人プランの契約ガイドを参照してください。

よくある質問

SSO強制後に既存アカウントへログインできなくなった社員は復旧できますか

アカウント自体は削除されていないため、IdP側のSSOアプリにその社員を割り当て直せば、SSO経由で元のアカウントへ再びアクセスできるようになります。データが消えるわけではなく、ログイン経路が塞がれているだけです。

検証済みドメインで社員が勝手に新しい組織を作るのを防げますか

防げます。ドメイン検証が完了すると、Ownerの画面に「Restrict organization creation」というトグルが現れ、オンにすると検証済みドメインを使った新規組織(個人アカウント含む)の作成を止められます。SSO強制と合わせて有効化しておくのが安全です。

同じドメインを複数の親組織で検証できますか

できません。一度あるドメインが1つの親組織で検証されると、他の親組織はそのドメインを取得できなくなります。同じドメインを使う組織を後から追加したい場合は、Merge Organizationsで既存の親組織に統合する形になります。

強制前に対象社員の一覧をまとめて確認する方法はありますか

あります。「Organization and access」または「Identity and access」の「Domains」セクションから「Domain memberships」を開くと、検証済みドメインに紐づく既存アカウントの一覧をCSVまたはJSON形式でダウンロードできます。強制前の棚卸しに使えます。