ClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれか
OktaとGoogle WorkspaceとEntra IDは、ClaudeのSAML設定自体は同条件です。差が出るのはSCIMの追加コストと設定の手間で、Entra IDだけがP1/P2ライセンスを要求します。
Okta・Google Workspace・Entra IDのどれをIdP(IDプロバイダー)に選んでも、ClaudeのSAMLによるSSO自体は同じ条件で動きます。差が出るのはSCIMによる自動プロビジョニングの側です。Entra IDだけがSCIM利用にP1またはP2ライセンスを要求し、Google WorkspaceはカスタムSAMLアプリの手動作成から始まります。IdPを選ぶときに見る点はここです。
SAMLは3社とも同条件、差が出るのはSCIMだけ
3社のセットアップガイドを突き合わせると、前提条件のうちClaude側のものは共通です。Team・Enterprise・親組織を持つConsole組織のどれでもSAMLでSSOを設定できます。Claude側で必要なのは、TeamとEnterpriseならOwnerまたはPrimary Owner、ConsoleならAdminのロールです。
プランで差が出るのはSCIM(自動プロビジョニング)のほうです。SCIMはEnterpriseと、独自の親組織を持つ(またはEnterpriseの親組織に属する)Console組織に限られます。Teamプランと、Teamの親組織に属するConsole組織では使えず、代わりにJITプロビジョニング(初回ログイン時の自動作成)を使います。JITとSCIMの役割分担そのものはClaudeのSSO・JIT・SCIMの違いと選び方で扱っています。
SAMLだけで足りるTeamプランなら、IdPの選択はコストにほぼ影響しません。追加ライセンスが効いてくるのは、EnterpriseかConsole組織でSCIMを使う場合です。
Console組織には、もう1つ共通の前提があります。3社のガイドはいずれも、前提条件に「親組織を持つConsole組織」を挙げています。Consoleで使う場合は、IdPを選ぶ前に組織の構成を確かめておくと手戻りが出ません。
3社で違うのは前提の権限とアプリの作り方
3社とも、IdP側の管理者権限とClaude側で検証済みのドメインが前提です。管理者権限の名前は次のとおり違い、アプリを用意する入口も違います。Claude側のEntity IDやACS URL、SCIMの認証情報は、どのIdPでもClaudeの管理画面(Identity and access)から始まるSSO設定の流れの中で表示されます。
IdPごとの前提権限とアプリの作り方
Okta
前提は「Okta administrator access」です。Admin consoleの「Applications → Applications → Create App Integration」で新規作成します。SSO方式は「SAML 2.0」(推奨)か「OIDC」から選びます。アプリ名は「Claude」にします。
Google Workspace
前提は「Super Admin」です。「Apps → Web and mobile apps → Add app → Add custom SAML app」でカスタムSAMLアプリを作ります。手順はここから始まり、ギャラリーの検索は出てきません。
Entra ID
前提は「Global AdministratorまたはApplication Administrator」とP1/P2ライセンスです。「Enterprise applications → New application」でギャラリーを「Claude」で検索します。見つかれば選択し、無ければ「Create your own application」で作ります。
3社のうちギャラリー検索から始まる手順を書いているのはEntra IDのガイドだけです。Okta・Google Workspaceのガイドは新規作成から始まります。Entra IDではギャラリーに「Claude」が出ない場合の分岐も、同じガイドの中に書かれています。自組織のテナントでどちらになるかは、作業の前に一度検索すると分かります。
EntraだけがSCIMに追加ライセンスを要求する
前提条件の書き方に、3社で明確な非対称があります。OktaとGoogle Workspaceの前提はIdP側の管理者権限だけです。Entra IDの前提には、それに加えて「Microsoft Entra ID P1またはP2ライセンス(SCIMプロビジョニングに必須)」の一文があります。
つまりSCIMを使うつもりでEntra IDを選ぶ組織は、Claudeの契約とは別に、Microsoft側のライセンスの有無を先に確かめる必要があります。P1/P2を持っていない場合の選択肢は2つです。ライセンスを追加するか、SCIMを使わずSAMLとJITで運用します。SAMLによるSSOログイン自体は、P1/P2を前提条件に挙げていません。
OktaとGoogle Workspaceのセットアップガイドには、この種のライセンスの前提が書かれていません。ガイドが挙げる前提は、IdP側の管理者権限などです。
SCIMの接続手順も3社で違う
SCIMの設定画面に入ってからの手順にも違いがあります。接続テストの有無や、有効化の前に必要な操作が異なります。
| 観点 | Okta | Google Workspace | Entra ID |
|---|---|---|---|
| 入口 | Oktaアプリの「Provisioning」タブで「Configure API Integration」 | Google Workspaceアプリ設定の「Autoprovisioning」で「Configure autoprovisioning」 | Entra IDアプリの「Provisioning → Get Started」 |
| 入れる値 | OktaSCIM Base URLとAPI Token | Google WorkspaceEndpoint URLとAccess token | Entra IDTenant URLとSecret Token |
| 接続テスト | Okta「Test API credentials」 | Google Workspace手順に接続テストの項目なし | Entra ID「Test Connection」 |
| 有効化の前に | Okta「To App」でCreate Users・Update User Attributes・Deactivate Usersを有効にする | Google Workspace管理設定で機能を有効にする必要がある場合がある | Entra IDProvisioning Modeを「Automatic」にする |
Entra IDにはもう1つ、運用に関わる違いがあります。ClaudeのJIT・SCIMガイドは、Entraが送るSCIMの変更は40分ごとなので、反映に遅れが出ると書いています。グループやロールを変えた直後にClaude側が変わらなくても、すぐに異常とは限りません。Claude側の「Manage SCIM」でDirectoryを見ると、IdPから同期されているユーザーを確かめられます。
3社共通の落とし穴はメール属性の不一致
3社のガイドが共通して「Critical」「Important」と強調しているのが、SAMLとSCIMで異なるメール属性を使ってしまう不一致です。SSOでのログインに使うメールと、SCIMが同期するメールが食い違うと、ログインの失敗につながります。
| IdP | SAML側 | SCIM側 | 不一致が起きる例 |
|---|---|---|---|
| Okta | SAML側Attribute Statementsの email を user.email に | SCIM側Attribute Mappings(To App)のemailを user.email に | 不一致が起きる例SAMLが user.email、SCIMが user.login |
| Google Workspace | SAML側Name IDをBasic Information > Primary emailに | SCIM側primaryEmail をClaudeのemailに | 不一致が起きる例別名(エイリアス)を持つ人で、SCIMが送る値と主メールがずれる |
| Entra ID | SAML側emailクレームを user.mail に | SCIM側Mappingsのemailを同じ項目(通常は user.mail)に | 不一致が起きる例クレームとマッピングが別の項目を指す |
ログインできない・意図しない組織に入るといった症状が出たときの診断手順は、Claude SSO/SCIMメールアドレス不一致の直し方にあります。
SCIMを保存する前に、全員をIdPのアプリへ割り当てる
SCIMやJITを有効にして「Save changes」を押す前に、全員をIdPのClaudeアプリへ割り当てておく必要があります。割り当てが済んでいない状態で保存すると、その人たちが組織から外されます。この点は3社のどれにも当てはまります。管理画面には、同期で何が変わるか(削除される人数を含む)のプレビューが出る場合があります。
SCIM有効化の順序
- 1
IdPのアプリに全員を割り当てる
Okta・Entra IDなら「Assignments」「Users and groups」で、Google Workspaceなら「User access」で、対象の人またはグループを割り当てます。
- 2
Claudeの管理画面でプロビジョニング方式を選ぶ
「User provisioning」でSCIM directory syncを選びます。この時点では保存しません。
- 3
割り当て済みであることを確かめてから保存する
「Save changes」で初回の同期が走ります。グループマッピングを使う場合は、ここでEnable group mappingsに進みます。
プロビジョニング方式によって、IdPから人を外したときの動きも違います。JITはメンバーを自動では削除しません。IdPのアプリから外された人はログインできなくなりますが、Claude側のメンバー一覧には残り、席も保持したままです。完全に外すには、Claudeで削除してIdPでも割り当てを外します。Claudeだけで削除すると、次のSSOログインで再び追加されます。SCIMなら、IdPのアプリから外した人は自動で削除されます。
グループマッピングで起きる事故
ロールや席の種類をIdPのグループで決めるグループマッピングには、IdPを問わない落とし穴があります。設定を保存した人自身が、AdminまたはOwnerにマップされたグループに入っていないと、その人の権限がUserに下がります。OwnerとAdminはSCIMの突き合わせの対象外ではないので、マップされたグループに入っていなければ外されます。Primary Ownerだけは突き合わせの対象から外れ、グループマッピングでは割り当てられません。
Oktaにはさらに固有の手順があります。グループマッピングを使うなら、SAMLのAttribute StatementsにGroup Attribute Statement(名前は groups)を追加します。フィルターには、ClaudeのロールまたはSeat typeにマップするOktaグループをすべて含めます。追加しないと、サインインにグループ情報が載りません。JITとグループマッピングの組み合わせでは、マップ対象のグループに属さないサインインのユーザーが、次のログインで組織から削除されます。
JITでCustomロールにグループをマップする場合も注意が要ります。JITはグループの所属をIdPから同期しないので、Claudeの管理画面の「Groups」で手動でユーザーを入れないと、権限が空のままログインします。この場合はSCIMに切り替える選択肢もあります。
グループマッピングを使うときは、全員をいずれかのロール用グループに入れておく必要もあります。どのグループにも入っていない人は、アカウントがプロビジョニングされません。席の種類のマッピングは、席種のグループに入っていない既存ユーザーなら今の席種を保ち、新規ユーザーなら空席のある最上位の席種になります。
同期されたのにメンバーに入らないとき
IdPの設定に誤りがなくても、SCIMのDirectoryには出ているのにClaudeのメンバーになっていない状態が起こります。ClaudeのJIT・SCIMガイドが挙げる原因は、購入済みの席が足りないことです。Organization and accessで空席数を確かめ、席を足してから「Directory sync (SCIM)」の横の「Sync now」を押すと、未追加の人のアカウントが作られます。
SCIMを有効にすると、新しく追加されたメンバーにはClaudeからウェルカムメールが届きます。止めたいときは、OwnerまたはPrimary Ownerが「User provisioning」の「Send a welcome email to new members」をオフにします。CMEK・HIPAA・FERPAのような追加の要件を持つ組織にはこのメール自体が送られず、設定も表示されません。
情シスはどう選べばよいか
| 状況 | 選び方 | 理由 |
|---|---|---|
| Google Workspaceで社内認証を統一している | 選び方Google Workspaceをそのまま使う | 理由ガイドに追加ライセンスの前提がない。カスタムSAMLアプリの作成から始める |
| P1またはP2を含むライセンスを既に契約している | 選び方Entra IDをそのまま使う | 理由SCIMの前提条件を満たしている。ギャラリー検索から始められる |
| P1/P2を含まないライセンスで運用している | 選び方SCIMを使わずJITで運用するか、ライセンス追加のコストを先に試算する | 理由P1/P2はClaudeの契約とは別にMicrosoft側で必要になる |
| すでにOktaを統合認証基盤として使っている | 選び方Oktaをそのまま使う | 理由ガイドに追加ライセンスの前提がない |
| Teamプランで当面SCIMを使わない | 選び方どのIdPでも実質差はない | 理由SAMLの条件が同一で、JITもIdPを問わず使える |
すでにSSOを設定済みの組織が別のIdPへ移行するときは、専用の手順があります。Claude IdP切り替え、SSOリセットの7手順にまとめています。設定作業に進む場合は、Claude Okta SSO設定・Claude Google Workspace SSO設定・Claude Entra ID SSO設定がIdP別の手順です。組織構成の事前確認はClaude SSO・SCIM導入前に確認する3点にあります。
まとめ
SAMLの条件は3社で横並びなので、IdP選びはSCIMを使うかどうかで決まります。使うならEntra IDのP1/P2ライセンス、使わないなら既存のID基盤に合わせるのが、追加コストの出ない組み合わせです。