Claude SSO/SCIMメールアドレス不一致の直し方 — プロバイダー別診断

Claude SSO/SCIMメールアドレス不一致とは

Claudeはメールアドレスを一意の識別子として使い、SSOでログインした人とSCIMでプロビジョニングされた座席を突き合わせます。SCIM側とSSO側が異なるメールアドレスを送ってくると、この突き合わせが失敗してログインがブロックされます。Claudeは完全一致でしか照合しません。1文字でも違えば同一人物と認識されません。

対象はSCIMプロビジョニングを使うEnterpriseプランとConsoleの組織です。TeamプランにはそもそもSCIMプロビジョニングがないため、この不一致は起こりません。Team・Enterpriseの管理機能の違いはClaude Enterpriseとはで整理しています。

SCIMと混同されやすい仕組みにJIT(Just-in-Time)プロビジョニングがあります。JITはSSOログインの瞬間にアカウントを作る方式で、事前の一括同期を必要としません。一方SCIMはIDプロバイダー側の変更を継続的に押し込む常時同期の仕組みで、退職者の自動無効化のような運用まで担います。ここで扱う不一致はSCIMの属性マッピングに起因するもので、JITのみを使っている組織では発生しません。

症状は主に4パターンです。

• 組織作成がブロックされる — SSO認証は通るが、プロビジョニング済みの座席が見つからない
• 個人の無料アカウントに着地する — 組織作成の制限をかけていない場合、本来の組織を素通りして無料アカウントが作られる
• 「メールアドレスを確認してください」という不一致警告が出る
• Claude Code CLIの認証が失敗する — 認証フローの途中でメールアドレスの不一致エラーが出る

メールアドレス不一致が起こる仕組み

どのIDプロバイダーでも構造は同じです。SCIMプロビジョニングとSSO認証は管理コンソールの別々の画面で設定され、それぞれ別のユーザー属性を参照できてしまいます。片方がエイリアスや従業員IDのような値を送り、もう片方が正規のメールアドレスを送っていると、文字列としては一致しません。

厄介なのは、管理者が片方の設定だけ更新して終わったつもりになるケースです。SCIM側とSSO側は同じアプリの中でもタブが分かれているため、片方を直しても、もう片方が古い属性を参照したままということが頻繁に起こります。

プロバイダー別に見る典型的な不一致パターン

5つの主要IDプロバイダーで、SCIMとSSOがそれぞれどの属性を参照しやすいかをまとめました。

Google WorkspaceとMicrosoft Entra IDは、SCIMプロビジョニングとSSO/SAML設定が管理コンソールの別タブに分かれている点が共通の落とし穴です。Entra IDはさらに、SCIMアプリが「Enterprise applications」、OIDCアプリが「App registrations」という別々の管理画面にあり、IT管理者が誤った画面を編集してしまう例が典型的です。

不一致を確認する3ステップ

原因の切り分けは、どのプロバイダーでも同じ3ステップで進められます。

1. SCIM側の送信属性を確認する — 管理コンソールのプロビジョニング設定(Google Workspaceなら「Auto-provisioning」、Oktaなら「Provisioning → To App」)で、メールフィールドにマッピングされている属性を見ます
2. SSO側の送信属性を確認する — SAML属性ステートメントやOIDCのクレーム設定を開き、emailにマッピングされている属性を見ます。SAMLではName ID(Entra IDやGoogle Workspaceで別途チェックが必要)も確認します
3. 影響範囲を切り分ける — 対象者のほとんどで同じズレが起きているなら属性マッピングそのものの問題、1〜2人だけなら個別アカウントの属性値の問題です

2つの属性が異なるフィールドを参照していれば、不一致は確定です。個別ユーザーのプロファイル画面でメールアドレスとエイリアス(またはユーザー名)を見比べると、ズレが視覚的に分かります。

修正手順 — 属性マッピングをそろえて完全再同期する

修正の原則はどのプロバイダーでも共通です。SCIMとSSOの両方を、同じ「正規のメールアドレス」を返す属性に統一します。Google Workspaceならprimary email、Entra IDならmail、Oktaならuser.email、OneLoginならEmailフィールド、Ping IdentityならPingOneのEmail Address属性(PingFederateはLDAPのmail属性)が該当します。

再同期後は、プロビジョニングログで実際に更新後の値が反映されているかを確認してから、対象者にログインを再試行してもらいます。

修正後に必ず行うクリーンアップ

属性マッピングを直して再同期しただけでは終わりません。修正前に発生した副作用が残っているためです。

• 野良の無料アカウント — 組織作成の制限をかけていなかった期間に、対象者が意図せず個人の無料アカウントを作ってしまっているケース。サポートチームへの削除依頼が必要です
• 幽霊アカウント — 誤ったメールアドレスでプロビジョニングされた旧アカウントが、座席を占有したまま組織に残っているケース。これもサポートチームでのデプロビジョニングが必要です
• 座席不足エラー — 幽霊アカウントが契約座席をすべて占有していると、マッピングを直した後も新規ログインが座席不足エラーで失敗します。幽霊アカウントの解消が先です

再発を防ぐには、組織の「Identity and access settings」で組織作成の制限を有効にしておきます。これを有効にしておけば、未プロビジョニングの人が誤って個人アカウントを作ることを防げます。

プロバイダーごとのよくあるつまずき

診断の途中で見落としやすいポイントは、プロバイダーによって癖が違います。

• Google Workspace: SCIMの自動プロビジョニング設定とSAMLの属性マッピングは同じアプリ内の別タブにあります。片方だけ更新して満足してしまう管理者が多く、両方を必ず確認します
• Microsoft Entra ID: SCIM設定は「Enterprise applications」、OIDCアプリの設定は「App registrations」という別々の管理画面にあります。IT管理者が慣れているのはどちらか一方だけということも珍しくありません
• Okta: user.loginとuser.emailという似た名前の2つの属性があり、SCIMのuserNameマッピングにuser.loginが既定で使われがちです。両方をuser.emailにそろえるのが安全です
• OneLogin: UsernameフィールドとEmailフィールドが独立しており、Usernameが従業員IDのような形式になっている組織では、SCIM側のマッピングを見直す必要があります
• Ping Identity: PingFederateは属性がLDAP→IdPアダプタ→アダプタ契約→SPコネクタ→アサーションという多層構造を通るため、途中のどの層でズレているかをトレースする作業が他のプロバイダーより手間がかかります

Claude Code CLIの認証でこのエラーに遭遇した場合は、ブラウザのCookieを削除してからSSOで再ログインし、claude auth login --enterprise を再実行して、プロビジョニングされたメールアドレスと一致しているかを確認します。Claude Code Desktopのシングルサインオン設定全般はClaude Code Desktop SSOとデバイス管理ポリシーの設定にまとめています。

サポートへ連絡するタイミング

属性マッピングをそろえても解消しない場合は、次の情報を添えてサポートチームに連絡します。

• 組織のドメイン
• 影響を受けている人のメールアドレス
• SCIM・SSOそれぞれの属性マッピングのスクリーンショット

SCIMとSSOの属性が一致して見えるのにログインできない、特定ユーザーのプロビジョニング済みメールアドレスの確認が必要、野良アカウント・幽霊アカウントの削除が必要、契約座席が余っているのに座席不足エラーが出る、といったケースはサポート対応が前提です。

まとめ

Claude SSO/SCIMのメールアドレス不一致は、突き詰めればSCIMとSSOが別々の管理画面から別々の属性を参照していることに尽きます。Google Workspace・Entra ID・Okta・OneLogin・Ping Identityのどれを使っていても、直し方の骨格は「両方を同じ正規メール属性にそろえる」「完全再同期を必ずトリガーする」「野良アカウントと幽霊アカウントを片付ける」の3点です。組織の管理者・IT部門がSSOログイン障害の一次切り分けを行うときの、最初のチェックリストとして使えます。Team・Enterpriseどちらの契約から始めるかを検討している段階なら、Claude TeamプランとはでSCIMを含む管理機能の違いを比較できます。