Claude Media
ClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれか

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設定の流れの中で表示されます。

3社の違い

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の設定画面に入ってからの手順にも違いがあります。接続テストの有無や、有効化の前に必要な操作が異なります。

観点OktaGoogle WorkspaceEntra ID
入口Oktaアプリの「Provisioning」タブで「Configure API Integration」Google Workspaceアプリ設定の「Autoprovisioning」で「Configure autoprovisioning」Entra IDアプリの「Provisioning → Get Started」
入れる値OktaSCIM Base URLとAPI TokenGoogle WorkspaceEndpoint URLとAccess tokenEntra 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が同期するメールが食い違うと、ログインの失敗につながります。

IdPSAML側SCIM側不一致が起きる例
OktaSAML側Attribute Statementsの email を user.email にSCIM側Attribute Mappings(To App)のemailを user.email に不一致が起きる例SAMLが user.email、SCIMが user.login
Google WorkspaceSAML側Name IDをBasic Information > Primary emailにSCIM側primaryEmail をClaudeのemailに不一致が起きる例別名(エイリアス)を持つ人で、SCIMが送る値と主メールがずれる
Entra IDSAML側emailクレームを user.mail にSCIM側Mappingsのemailを同じ項目(通常は user.mail)に不一致が起きる例クレームとマッピングが別の項目を指す

ログインできない・意図しない組織に入るといった症状が出たときの診断手順は、Claude SSO/SCIMメールアドレス不一致の直し方にあります。

SCIMを保存する前に、全員をIdPのアプリへ割り当てる

SCIMやJITを有効にして「Save changes」を押す前に、全員をIdPのClaudeアプリへ割り当てておく必要があります。割り当てが済んでいない状態で保存すると、その人たちが組織から外されます。この点は3社のどれにも当てはまります。管理画面には、同期で何が変わるか(削除される人数を含む)のプレビューが出る場合があります。

順序

SCIM有効化の順序

  1. 1

    IdPのアプリに全員を割り当てる

    Okta・Entra IDなら「Assignments」「Users and groups」で、Google Workspaceなら「User access」で、対象の人またはグループを割り当てます。

  2. 2

    Claudeの管理画面でプロビジョニング方式を選ぶ

    「User provisioning」でSCIM directory syncを選びます。この時点では保存しません。

  3. 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基盤に合わせるのが、追加コストの出ない組み合わせです。

この記事を共有:XはてブLinkedIn