ClaudeのSSO・JIT・SCIMの違いと選び方
SSOは認証、JIT・SCIMはアカウント管理の話で、混同すると設定を誤ります。SCIMはEnterpriseと一部のConsole組織限定でTeamでは使えません。プラン別の選び方の基準をまとめます。
SSOとJIT・SCIMは何が違うのか
SSO(シングルサインオン)は「誰がログインできるか」を決める認証の仕組みです。JIT(Just-in-Time)とSCIM(System for Cross-domain Identity Management)は、ログインしてきた人にどうアカウントを割り当てるかというアカウント管理(プロビジョニング)の方式です。3つは対立する選択肢ではありません。SSOを土台にして、JITかSCIMかを選ぶという積み上げの関係にあります。
混同しやすいのはここです。「SSOかSCIMか」という二択は存在しません。SSOを設定して初めて、プロビジョニング方式を選べるようになります。招待制のまま個別に手動追加を続ける運用も、SSO設定後に選べる選択肢の1つです。
導入の流れ — ドメイン検証からプロビジョニング選択まで
SSOの設定は5ステップで進みます。対象はTeam・Enterpriseプラン、およびClaude Console組織です。
- 前提条件の確認 — Team・Enterpriseプランは組織のOwnerまたはPrimary Owner権限、Claude ConsoleはAdmin権限が要ります。会社のDNS設定とIdP(Okta、Google Workspace等)へのアクセスも必要です
- ドメイン検証 — 組織設定にドメインを追加し、DNSにTXTレコードを追加して所有権を証明します。DNSの反映まで10分ほど待ちます(レジストラの設定によってはさらにかかります)
- IdPとの接続 — 組織設定の「Setup SSO」からIdP別のセットアップガイドに沿って接続し、テストログインで動作を確認します
- SSOの必須化を選ぶ — Claude・Console単位で「Require SSO」を切り替えます。必須にすると全員が「Continue with SSO」経由でのログインになります
- プロビジョニング方式を選ぶ — 招待制・JIT・SCIMのいずれかを決めます。プロビジョニング方式の違いは次の節で比較します
SSOを完全に無効化したい場合は「Manage SSO」から「Reset connection」を選びます。全ユーザーのセッションが終了し、メールログインでの再認証が必要になります。
SSOを設定した後も、放置していい設定ではありません。IdPのX.509署名証明書は期限が切れたりローテーションされたりします。証明書が切れると、更新するまで組織全員がログインできなくなります。更新は「Manage SSO」の「Metadata configuration」から証明書情報を差し替え、「Test sign-in」で動作確認するだけで済みます。IdP側で証明書の更新スケジュールを事前に確認しておくと、期限切れによる全社ログイン不能を避けられます。
プロビジョニングモード5パターンを比較する
プロビジョニング方式は招待制・JIT・SCIMの3つに見えますが、グループマッピングを組み合わせるかどうかで実質5パターンに分かれます。挙動の違いは「追加」「役割・シート変更」「削除」の3点に表れます。
| モード | アカウント追加 | 役割・シート変更 | 削除 |
|---|---|---|---|
| 招待制(既定) | アカウント追加管理者が手動で追加 | 役割・シート変更管理者が手動で変更 | 削除管理者が手動で削除 |
| JIT | アカウント追加IdPアプリ割り当て済みのユーザーが初回ログイン時に自動追加(役割はUser固定) | 役割・シート変更手動変更のみ | 削除自動削除なし。IdP側の割り当てを外してもログイン不可になるだけで、メンバー一覧とシートは残る |
| JIT+グループマッピング | アカウント追加マッピング済みグループに所属するユーザーが初回ログイン時に、最も権限の高い役割で自動追加 | 役割・シート変更次回ログイン時にグループ所属に応じて自動更新 | 削除ほぼ手動。マッピング済みグループから全て外れた場合のみ自動削除 |
| SCIM | アカウント追加IdPアプリ割り当て済みのユーザーを自動でプロビジョニング(親組織配下の全組織に展開) | 役割・シート変更手動変更のみ | 削除IdPアプリから外れると自動削除 |
| SCIM+グループマッピング | アカウント追加マッピング済みグループのユーザーを、該当グループが紐づく組織へ自動プロビジョニング | 役割・シート変更グループ所属の変更が役割・シートに自動反映 | 削除グループアクセスを外すと自動削除 |
削除の自動化だけが欲しいならSCIM、権限の自動割り当てだけが欲しいならグループマッピング付きJITでも足ります。退職者のアカウントを放置したくない組織にとって、この「削除」列の違いが選定の決め手になります。なおJIT+グループマッピングの「ほぼ手動」は、IdPアプリの割り当てだけを外した場合を指します。この場合はログイン不可になるだけでメンバー一覧とシートは残るため、完全に削除するにはマッピング済みグループからも外す必要があります。
プランで使える範囲が変わる
JITは全プランで使えます。一方でSCIMはTeamプランでは使えません。SCIMディレクトリ同期が使えるのは、Enterpriseプラン、または自身の親組織を持つ・Enterpriseの親組織に参加しているClaude Console組織に限られます。
| プラン・組織 | SSO | JIT | SCIM |
|---|---|---|---|
| Team | SSO○ | JIT○ | SCIM× |
| Enterprise | SSO○ | JIT○ | SCIM○ |
| Console(単独の親組織) | SSO○ | JIT○ | SCIM○ |
| Console(Teamの親組織に参加) | SSO○ | JIT○ | SCIM× |
役割とシート種別もプランで変わります。Team・Enterpriseは「Owner・Admin・User」が基本形で、EnterpriseはさらにCustom役割を追加できます。Claude Console組織は役割の体系そのものが異なり、「Admin・Developer・Limited Developer・Billing・Claude Code User・User」の6種類です。シート種別はTeam・EnterpriseともにPremiumとStandardの2種類があります。JIT・SCIM・グループマッピングのいずれも、自動で割り当てるのは役割までです。シート種別(Premium/Standard)が自動で変わるかどうかは、公式ヘルプに記載がありません。組織構成が複雑なら、Claude EnterpriseとはとClaude Teamプランとはで料金と機能の全体像を先に押さえておくと、プロビジョニング方式の選定がぶれません。
組織の状況別に見る使い分け早見表
| 組織の状態 | おすすめ | 理由 |
|---|---|---|
| 10人未満、入退社が少ない | おすすめ招待制のまま | 理由手動運用のコストが低く、自動化の恩恵が小さい |
| Teamプランで、社員がIdPアプリに割り当て済み | おすすめJIT(グループマッピングなし) | 理由SCIMが使えないプランでも、初回ログインの手間だけは自動化できる |
| 役割・シート種別をIdPの部署やグループで管理したい | おすすめJIT+グループマッピング | 理由Enterpriseへの移行前でも、権限の自動割り当てだけは先に導入できる |
| 退職者のアカウントを即座に無効化したい規制業種 | おすすめSCIM | 理由IdPアプリから外すだけでClaude側も自動的にアクセスを失う |
| 複数の子組織にまたがってユーザーを一括管理したい | おすすめSCIM+グループマッピング | 理由親組織配下の複数組織への自動配布まで含めて自動化できる |
自動化の度合いを上げるほど、事前のグループ設計を丁寧に済ませておく必要があります。IdP側で役割ごとにグループを作り、最低1人をAdmin・Owner相当のグループに入れておくのが前提です。設計を飛ばしてグループマッピングを有効化すると、次の落とし穴にそのまま当てはまります。
Primary Ownerだけは特別に扱われる
SCIMのグループマッピングを有効にすると、マッピング済みグループに属さないOwner・Admin権限のユーザーは次回同期で除外されます。ただし組織のPrimary Ownerだけは例外です。
- IdPディレクトリに存在しない、またはどの役割マッピング済みグループにも属していなくても、SCIM同期の対象から外れ、既存の役割とメンバーシップがそのまま保持される
- この例外はPrimary Owner 1人にしか適用されない。Owner・Admin役割は例外の対象外で、役割マッピング済みグループに入っていないとSCIM有効化時に除外される
- Primary Owner役割自体はSCIMのグループマッピングでは割り当てられない。移譲は「Organization settings > Members」からの手動操作のみで、SCIM有効化前に済ませておく
- Primary OwnerもSSOのログイン強制(ドメイン単位)の対象からは除外されない。メールドメインが必須化対象なら、Primary OwnerもSSO経由でのログインが必要になる
よくあるつまずき
IdPで正しく割り当てているのに、メンバー一覧に追加されない
多くはシート不足が原因です。組織設定の空きシート数を確認し、不足していれば追加購入したうえで「Sync now」を実行すると、未追加のユーザーがまとめてプロビジョニングされます。
役割が意図した通りに割り当てられない
まずIdP側でユーザーが正しいグループに入っているか、そのグループが正しい役割にマッピングされているかを確認します。JITの場合はグループ所属の変更が次回ログイン時にしか反映されないため、対象者に一度ログアウト・再ログインしてもらう必要があります。SCIMの場合は「Sync」を手動実行するか、自動同期のサイクルを待ちます。
Custom役割にマッピングしたユーザーが、ログイン後に何もできない
プロビジョニング方式がJITで、IdPグループをCustom役割にマッピングしている場合に起きます。JITは役割の種類だけを割り当て、IdP側のグループ所属そのものは同期しません。そのためCustom役割に紐づく権限を持つグループの実体が存在せず、権限ゼロの状態になります。修正は、対象ユーザーを組織設定のグループへ手動で追加するか、グループ同期まで行うSCIMへ切り替えるかのどちらかです。
グループマッピングを有効にした途端、自分がAdmin・Owner権限を失った
設定した本人がAdmin・Ownerにマッピングされたグループに所属していないと起きます。別の管理者に「Organization settings > Members」から役割を戻してもらうか、IdP側で正しいグループに自分を追加してから再ログイン(JIT)・同期実行(SCIM)します。
SSOでログインできるのに、SCIMで作られたはずのアカウントに繋がらない
SAMLとSCIMが別々の属性からメールアドレスを送っている、というメールアドレスの不一致が典型的な原因です。IdP製品によってはSCIMのプロビジョニング設定とSAMLの属性マッピングが別タブに分かれており、片方だけ更新して見落とすことがあります。両方が同じメールアドレス、できれば主要メールアドレスを参照しているか確認してください。
まとめ — 迷ったら削除の自動化で決める
SSOは認証、JIT・SCIMはアカウント管理という役割の違いをまず切り分けます。プランで迷うなら、SCIMが使えるのはEnterpriseプランと一部のConsole組織に限られる点が最初の分岐です。Teamプランで自動化したいならJIT、退職者アカウントの自動削除まで求めるならSCIMという基準で選べば、大きく外しません。グループマッピングを組み合わせるなら、有効化前にPrimary Ownerと自分自身の役割マッピングを確認しておくと、アクセス喪失の事故を避けられます。役割設計そのものを詰めるならClaude CoworkのRBAC運用がグループ設計の実装例を扱っています。Desktopアプリ固有の統制設定はClaude Code Desktop SSOとデバイス管理ポリシーの設定が別にまとめています。