メインコンテンツにスキップ

SSO/SCIM メール不一致 — Google Workspace

概要: Claudeはメールアドレスをプライマリ識別子として使用し、SSO ログインをプロビジョニング済みシートにマッチングします。Google Workspaceでは、SCIM自動プロビジョニングとSAML SSOが異なるメール値を送信する可能性があります。特にユーザーがメールエイリアスを持っている場合、このミスマッチがアクセスをブロックします。

症状

ユーザーがSSO経由でClaude for Enterpriseにアクセスしようとする際に、以下の1つ以上の症状が発生する可能性があります:

  • 「アカウント作成がブロックされています」 — ユーザーはSSO経由で認証されますが、Claudeはマッチングするプロビジョニング済みアカウントを見つけることができません。組織がOrganization作成を制限している場合(推奨)、ユーザーは完全にブロックされ、先に進むことができません。

  • 無料の個人アカウントにランディング — Organization作成が制限されていない場合、ユーザーはエンタープライズOrganizationをバイパスし、エンタープライズシートの代わりに無料の個人アカウントを作成するか、そこにランディングします。

  • 「メールアドレスを確認してください」ミスマッチ — SSO コールバックがログイン時にユーザーが入力したメールアドレスと異なるメールアドレスを表示します。

  • Claude Code認証失敗 — Claude Code CLIは認証フロー中にメールアドレスのミスマッチエラーを表示し、ユーザーがエンタープライズOrganizationに接続できません。

これが発生する仕組み

Google Workspaceのユーザーアカウントにはプライマリメールアドレスがあり、複数のエイリアスを持つ可能性があります。SCIM プロビジョニングとSAML SSOはGoogle Admin コンソールで個別に設定され、異なるアドレスフィールドから取得できます:

Google属性

典型的な値

一般的に使用される場所

primaryEmail

SCIMとSAMLの両方に推奨

メールエイリアス

SCIMで誤ってマッピングされることがあります

カスタムスキーマフィールド

組織ごとに定義されたカスタム属性

高度な属性マッピング

Organization Unit メール

OU派生アドレスバリアント

複雑な組織構造では稀に使用

最も一般的なミスマッチ:SCIMはエイリアスアドレスを送信するように設定されているのに対し、SAMLはプライマリメール(またはその逆)を送信します。エイリアスとプライマリメールは異なる文字列であるため、Claudeはそれらをマッチングできません。Claudeは完全な文字列マッチを必要とします。

一般的な混乱: Google Adminでは、SCIM自動プロビジョニング設定とSAML属性マッピングは同じアプリ内の別々のタブにあります。管理者が一方を更新してもう一方を見落とすことがあります。両方の場所を確認してください。

診断手順

ステップ1 — ミスマッチを確認する

  1. SCIMメールを確認: Google Admin コンソールで、アプリ → ウェブアプリとモバイルアプリ → [Claude App] → 自動プロビジョニングに移動します。Claudeに送信されるメールフィールドにマッピングされている属性を確認します。

  2. SAMLメールを確認: 同じアプリで、SAML属性マッピングセクションに移動します。emailにマッピングされている属性を見つけ、そのソースをメモします。

  3. 特定のユーザーを確認: ディレクトリ → ユーザー → [ユーザー]で、ユーザーのプライマリメールと記載されているエイリアスメールを比較します。

ステップ2 — 問題の範囲を特定する

これが1人の影響を受けたユーザーか、システム全体の問題かを判断します:

  • ほとんどまたはすべてのプロビジョニング済みユーザーが同じメール形式のミスマッチを共有している場合、これはシステム的な属性マッピング問題です。修正はIdPのSCIM属性マッピングにあります。

  • 1~2人のユーザーのみが影響を受けている場合、問題はそれらのユーザーアカウントに固有の可能性があります。ユーザープロフィールを直接確認してください。

ステップ3 — SAML設定でName IDを確認する

  1. アプリ設定で、SAML → サービスプロバイダーの詳細に移動します。

  2. Name ID基本情報 → プライマリメールに設定されていることを確認します。

  3. Name IDがカスタムスキーマフィールドまたはエイリアスに設定されている場合、SCIMとは異なる値を送信する可能性があります。

解決方法

両方のマッピングをprimaryEmailに合わせる

Google WorkspaceのprimaryEmailは、SCIMとSAMLの両方に最も信頼できるソースです。

  1. SCIMプロビジョニングを更新: アプリ → ウェブアプリとモバイルアプリ → [Claude App] → 自動プロビジョニング → 属性マッピングで、メール属性がprimaryEmailにマッピングされていることを確認します。

  2. SAML Name IDを更新: SAML → サービスプロバイダーの詳細で、Name ID基本情報 → プライマリメールに設定します。

  3. SAML属性マッピングを更新: 属性マッピングステップで、email属性が基本情報 → プライマリメールにマッピングされていることを確認します。

  4. すべての変更を保存します。

完全な再同期をトリガーする

重要 — 完全な同期が必要: 属性マッピングを変更した後、増分同期は既存ユーザーを更新しません。プロビジョニングサイクルの完全な再開始をトリガーする必要があります。

  1. Google Admin コンソールで、アプリの自動プロビジョニング設定に移動します。

  2. プロビジョニングを一時的に中断してから、再度有効にします。これにより、割り当てられたすべてのユーザーの完全な同期がトリガーされます。

  3. または、影響を受けたユーザーをアプリ割り当てから削除して再度追加し、個々のレコードを強制的に再プロビジョニングします。

  4. プロビジョニングログでエラーを監視し、ユーザーに再試行を依頼する前に、ユーザーメールがSAML形式に更新されたことを確認します。

修正後のクリーンアップ

属性マッピングを修正して完全な同期を完了した後、追加のクリーンアップが必要な場合があります:

  • 不正な無料アカウント: 修正前にOrganization作成が制限されていなかった場合、一部のユーザーが誤って無料の個人Claudeアカウントを作成している可能性があります。Anthropic Supportに連絡して、これらを削除してもらいます。

  • ゴーストアカウント(間違ったメールシート): 元々プロビジョニングされたアカウント(間違ったメール付き)がエンタープライズOrganizationに存在し、シートを占有している可能性があります。Anthropic Supportに連絡して、これらのゴーストアカウントをデプロビジョニングしてもらいます。

  • シート可用性: ゴーストアカウントがすべての契約済みシートを占有している場合、新しいログインはシート不足エラーで失敗します。ゴーストアカウントをデプロビジョニングすると、それらのシートが解放されます。

  • 影響を受けたユーザーの再追加: ゴーストアカウントが削除された後、修正されたメールを持つユーザーは再度招待またはプロビジョニングが必要な場合があります。

将来の発生を防ぐ: エンタープライズ設定で「Organization作成を制限」を有効にします。これにより、まだプロビジョニングされていないユーザーが誤って無料の個人アカウントを作成するのを防ぎます。

検証

  1. プロビジョニング済みユーザーのサンプルを確認します。IdPのプロビジョニングログ内のメールアドレスがSSO送信するメール形式と一致することを確認します。

  2. 影響を受けたユーザーにclaude.aiのブラウザクッキーをクリアしてからSSO経由でログインするよう依頼します。エラーなしでエンタープライズワークスペースに直接ランディングするはずです。

  3. ユーザーが誤って無料アカウントを作成していないことを確認します。Organization作成が制限されている場合、ブロックされたユーザーは個人アカウントにランディングするのではなく、明確なエラーが表示されます。

  4. Claude Codeが影響を受けた場合、ユーザーにclaude auth login --enterpriseを再実行させ、メールアドレスがエンタープライズシートと一致することを確認します。

一般的な落とし穴

落とし穴

解決方法

SCIMはエイリアスを送信し、SAMLはプライマリメールを送信

常に両方にprimaryEmailを使用します。

SAML設定のName IDが確認されていない

Name IDフィールドはログイン時に送信されるメールアドレスを決定します。これは属性マッピングセクションとは別です。両方を確認してください。

カスタムスキーマフィールドが一部のユーザーで空白

primaryEmailなどの標準Google属性に固執します。

マッピング変更後、再プロビジョニングが自動的にトリガーされない

完全な同期を強制するために、プロビジョニングを手動で中断して再度有効にする必要がある場合があります。

ユーザーのプライマリメールが変更されたが、古いメールがClaudeに表示されたままである

プライマリメール変更後、完全な再同期が必要です。

SCIMでメールが更新されたがユーザーがログインできない

不正な無料Organizationまたはゴーストアカウントを確認します。ブラウザクッキーをクリアして再試行してください。

Anthropic Supportに連絡する場合

  • SCIM属性とSSO属性が同じに見えるが、ユーザーがシートにアクセスできない。

  • 特定のユーザーについて、Claudeが SCIM プロビジョニング中に記録したメールアドレスを確認する必要がある。

  • ゴーストアカウントまたは不正な無料Organizationのクリーンアップを支援してもらう必要がある。

  • ユーザーが契約に利用可能なシートがあるにもかかわらず、シート不足エラーが発生している。

[email protected]に、組織のドメイン、影響を受けたユーザーのメールアドレス、属性マッピングのスクリーンショットを添えて連絡してください。

こちらの回答で解決しましたか?