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

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

ClaudeでSSOやSCIMを有効化する前に確認することは3つあります。親組織(parent organization)の有無と紐付け方、契約プランで使えるプロビジョニング方式、そしてSSO強制がすでにアカウントを持つ社員に与える影響です。

飛ばして進めると、想定外のユーザーがログインできなくなったり、退職者の席が残り続けたりします。画面操作の手順はClaudeのSSO設定手順にあります。本記事は、着手前に自分の状況を判定する材料と、設定後に詰まりやすい箇所を扱います。

親組織(parent organization)とは何か

親組織は、複数のClaude組織やConsole組織でSSO設定を共有するための入れ物です。ドメイン検証・IDプロバイダー(IdP)の接続・ユーザーのプロビジョニングが親組織に保存され、紐づく各組織はそれを参照します。

親組織が最初からあるかどうかは、プランで決まります。

制約は3つあります。ドメイン検証は親組織単位で行われ、検証済みのドメインは別の親組織から取れません。接続できるIdPは1親組織につき1つなので、同じ親組織に紐づく組織はすべて同じIdPで管理することになります。IdPを使い分けたいなら親組織自体を分けます。

請求・インボイス・利用量の集計は組織ごとに処理され、親組織の紐付けでは変わりません。親組織が持つのは、ドメイン検証・SSO設定・ユーザーのプロビジョニングです。

自分の組織はどこから始めるか

次の3つのうち、当てはまるものを選んでください。

判定

契約の組み合わせ別の出発点

• TeamまたはEnterpriseだけ

  親組織はすでにあるか、SSOの有効化時に作られます。そのままSSO設定手順に進めます。

• Console + TeamまたはEnterprise

  Console組織がすでに親組織へ紐づいている可能性があります。platform.claude.com/settings/identity を開けるなら、紐付けもSSO設定も済んでいます。開けなければ、Team・Enterprise側のOwnerが組織統合を開始します。

• Consoleだけ

  親組織は自動では作られません。営業チームに連絡して作成を依頼します。作られるとConsoleにIdentity settingsページが現れ、SSOの設定に進めます。

2つ目のカードで/settings/identityを開けない場合は、後述の組織統合が必要です。

ドメイン検証で詰まりやすい点

SSOを設定する前に、ドメインの検証が要ります。操作できる役割は、TeamとEnterpriseならOwnerまたはPrimary Owner、ConsoleならAdminです。会社ドメインのDNSを触れる人とIdPを管理できる人も、先に押さえておきます。検証とSSOの設定にはWorkOSの画面が挟まります。

検証だけでは既存ユーザーのアクセスは変わりません。影響が出るのは、SSOを設定して明示的に強制してからです。そのため、検証は強制より前に済ませておけます。

つまずきやすいのは、TXTレコードの扱いです。

• 設定画面に出る値は、anthropic-domain-verification- で始まる長い文字列です。画面上では途中までしか見えないので、コピーボタンで全体を取ります
• ステータスがPendingになると、管理画面は値を再表示しません。控えずに画面を離れると、ドメインを削除して入れ直すことになり、値も新しくなります
• 入れ直した後に古い値のままDNSへ登録していた場合は、一致せずPendingが続きます
• レコードは yourdomain.com のルートに置きます。www.yourdomain.com のようなサブドメインでは検証されません
• 値は大文字・小文字を区別します。1文字違うだけでPendingのままです。既存のTXTレコードは置き換えず、並べて追加します

反映には10分ほどかかり、DNSによっては24〜48時間かかることがあります。「Refresh」を押しても、公開されたTXTが期待値と完全に一致するまでVerifiedにはなりません。レコードが正しく反映済みでもPendingのままなら、サポートへの連絡が案内されています。

複数のドメインを1つの組織で検証することはできます。ただしすべて同じIdPで管理する必要があります。別のIdPのドメインを同じ組織に混ぜることはできません。

プロビジョニング方式をプランで選ぶ

SSOを設定したあとに、ユーザーをどう組織へ入れるかを選びます。方式は3つで、使える範囲はプランで違います。

SCIMだけはTeamプランで使えません。注記には、Console組織がTeamプランの親組織に統合されている場合も、そのConsole組織はSCIMを使えないとあります。SCIMが必須なら、Enterpriseへの変更か、自前の親組織を持つConsole組織が候補です。プランごとの料金や統制機能はClaude Enterpriseの法人プランガイドとClaude Teamプランガイドにあります。

退職者の扱いは、方式で大きく変わります。JITはメンバーを自動では削除しません。IdPのアプリから外すとログインできなくなりますが、メンバー一覧には残り、席も埋まったままです。管理者が削除するまで続きます。

JITの利用者を完全に外すには、Claude側で削除し、IdP側でも割り当てを外します。Claude側だけで削除した人は、次にSSOでログインしたときに再び追加されます。

グループマッピングを併用すると、いくらか自動になります。マッピングされたグループのすべてから外れた人は、アプリに割り当てが残っていても、次のログイン時に組織から外されます。それでも、アプリから完全に外した人の席は手作業で解放します。SCIMなら、IdPのアプリから外した人が自動で削除されます。Teamプランで入退社を回す運用では、この差を見込んでおく必要があります。

JITでグループマッピングを使うときは、もう1点あります。マッピングが決めるのは、ロールと席の種類だけです。Customロールの権限は、Claude側のグループから得ます。そのグループがIdPから同期されるのはSCIMのときだけで、JITでは自分で作って人を入れます。IdPのグループをCustomロールに対応づけたままにすると、その人たちはログインできても権限がありません。

SSOを強制すると既存ユーザーはどうなるか

社内で個人のFree・Pro・Team・Maxアカウントを使っている社員がいる場合、結果は2通りに分かれます。分かれ目は、その社員がIdP上のClaudeアプリに割り当てられているかどうかです。

くらべる

IdPのアプリへの割り当てで変わる結果

アクセス維持

割り当てあり

既存の個人アカウントにも入れます。画面左下のイニシャルのプロフィールアイコンから、組織のアカウントと元のアカウントを切り替えられます。

強制の有無で分岐

割り当てなし

「Require SSO for Claude」がオフなら、「Continue with email」で既存アカウントに入れます。オンにすると入れなくなります。アカウントは削除されませんが、IdPのアプリに割り当てがないためSSOでもログインできず、入れない状態が続きます。

強制を切れば、メールでのログインが選べる状態に戻ります。公式の説明では、SSOが必須でないときは「Continue with SSO」と「Continue with email」のどちらかを選べるとされているためです。

探す手がかりは「Domain memberships」です。claude.aiなら「Organization and access」、Consoleなら「Identity and access」の「Domains」セクションにあります。検証済みドメインに紐づく既存アカウントの情報を、CSVまたはJSONでダウンロードできます。この一覧とIdPの割り当てを突き合わせれば、漏れた人が見つかります。

ドメイン検証が済むと、Ownerには「Restrict organization creation」というトグルが、Security欄に表示されます。オンにすると、検証済みドメインで新しいClaudeやConsoleの組織を作れなくなります。個人アカウントも対象です。強制と同時にオンにしておけば、社員が未管理の個人組織を新しく作る抜け道を残さずに済みます。

実施する時間帯は、利用の少ないときに寄せます。IT部門の問い合わせ窓口を用意し、アクセスを付与する手順も決めておきます。可能なら、SSOとプロビジョニングを同時に導入してください。段階を分けると、SSOだけ先に強制してプロビジョニングが未設定のまま、既存ユーザーが取り残されやすくなります。

組織を統合する(Merge Organizations)

Team・Enterprise組織とConsole組織を別々に運用していて、SSO設定を共有したいときに使います。開始できるのはclaude.ai側のTeam・Enterprise組織だけです。Console組織は招待される側になります。

統合の条件は4つあります。

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

招待したい組織が一覧に出ないなら、その組織が独自の親組織を持っている可能性があります。サポートに連絡して切り離し(デタッチ)を頼む必要があります。デタッチすると、その組織のドメイン検証とSSO・SCIMの設定は消えます。実行前に、その組織の管理者の了承を取ってください。

承認は片側で終わりません。両側の操作がそろって初めて統合が完了します。

手順

統合の流れ

1. 1

   招待を送る

   Team・Enterprise側で「Organization settings > Organization and access」を開きます。Merge Organizationsの「Invite」から招待する組織を選び、メンバー数を確認して送ります。

2. 2

   招待された組織が受け入れる

   受け入れ手順には、招待された組織のOwnerまたはPrimary Ownerが claude.ai/settings/join-proposal で行うと書かれています。通知メールの件名は「Parent Organization Update: New Member Organization Proposed」で、期限は14日です。

   承認の条件(前節)にはAdmin(Console)またはOwner(Claude)とあり、手順側の役割とは表記が揃っていません。Console組織が招待される場合に誰が操作するかは、原文の中でも食い違っています。

3. 3

   親組織の側が承認する

   親組織に属する組織のOwnerまたはAdminが、「Organization and access > Pending Organizations」か、同じメールのリンクから承認します。

招待を送った人が、招待された組織のAdminまたはOwnerも兼ねているなら、承認は1回で足ります。完了すると、Console組織の設定に「Identity and access」ページが現れ、SSOとプロビジョニングを設定できるようになります。

設定後に起きやすいロックアウト

強制をオンにしたあとに起きる詰まりは、前もって知っておけば避けられます。

最も深刻なのは、証明書の失効です。IdPのX.509署名証明書が失効または更新されたら、ClaudeかConsoleでも更新が要ります。Require SSOがオンのまま証明書が失効済みだと、すべてのログイン経路がSSOを通るため、更新のためにログインできる人がいなくなります。この場合は、OwnerまたはPrimary Ownerのメールアドレスからサポートに連絡します。失効日をIdP側に控え、前もって更新するのが避け方です。

同じ連絡先は、IdPの変更やグループマッピングの誤りで管理者全員が入れなくなったときにも使います。サポートが組織の所有を確認したうえで、再びアクセスできるようにするとされています。

Console組織がTeam・Enterprise組織とSSO設定を共有している場合は、IdP起点のログインに制限があります。現状は未対応で、IdPからはclaude.aiに遷移します。対処として、IdPにブックマークを作り、platform.claude.com/login?sso=true へ向ければ、Consoleでのサービスプロバイダー起点のログインに誘導できます。IdPがブックマークの作成に対応している場合に限られます。

SSOを止める操作は2段階です。強制のトグルをオフにすれば、SSOは任意になります。接続そのものを外すには「Manage SSO」から「Reset connection」を選びます。全ユーザーのセッションが終了し、メールのログインリンクで入り直すことになります。

次にやること

論点を確認できたら、ClaudeのSSO設定手順でドメイン検証からIdP接続まで進みます。方式の選定とグループマッピングはJIT/SCIMプロビジョニングの設定手順に詳しく、契約プランで迷っているならClaude法人プランの契約ガイドが入口です。