Claude Media
Claude Entra ID SSO設定 — SAMLとSCIM自動プロビジョニングの手順
Claudeチュートリアル

Claude Entra ID SSO設定 — SAMLとSCIM自動プロビジョニングの手順

Microsoft Entra ID(旧Azure AD)をIdPにしたClaudeのSSO設定を、エンタープライズアプリケーションの追加からSCIM連携まで手順で解説します。

読了目安 約11分

Microsoft Entra ID(旧Azure Active Directory)をIDプロバイダー(IdP)にして、ClaudeのSSOを設定します。Entra管理センターでエンタープライズアプリケーションを作り、ClaudeのWorkOSセットアップ画面が出す値を相互に登録する流れです。対象はTeamプラン・Enterpriseプランと、親組織を持つConsole組織です。

SAMLによるSSOは対象のどの組織でも設定できます。SCIM自動プロビジョニングはEnterpriseプランと一部のConsole組織に限られます。細かい条件は、後述の提供方式の表にまとめています。

ヘルプセンターの別ページには、SCIMを有効にできるのはEnterpriseプランの組織だけとする脚注もあります。Console組織でSCIMを使う場合は、表の条件を満たしているか、自組織の管理画面で確かめてください。

前提条件

  • Claude側でOwnerまたはPrimary Owner権限(Team・Enterprise)、またはAdmin権限(Console)
  • Entra側でGlobal AdministratorまたはApplication Administratorロール
  • SCIMを使う場合、Microsoft Entra ID P1またはP2ライセンス
  • 自社ドメインがClaudeの管理設定でドメイン検証済みであること
  • Console組織の場合、親組織が存在すること。単独のConsole組織は、営業チームに親組織の作成を依頼します

Entity ID・Reply URL(ACS URL)・SCIMの認証情報は、Claude側の管理画面が発行します。サポートに問い合わせて入手する情報ではありません。TeamプランとEnterpriseプランは管理設定の claude.ai/admin-settings/identity を開きます。ヘルプセンターの別ページは同じ設定を claude.ai/admin-settings/organization と案内しているので、開けたほうで構いません。Console組織は platform.claude.com/settings/identity です。SSOセットアップフローを始めた状態で、Entra管理センターと並べて作業します。

Entraでの設定は5ステップ

手順

Entraでの設定の流れ

  1. 1

    エンタープライズアプリケーションとして追加する

    Entra管理センターの「エンタープライズアプリケーション」→「新しいアプリケーション」に進みます。ギャラリーで「Claude」を検索し、無ければ「独自のアプリケーションを作成する」を選んでアプリ名を「Claude」にします。「ギャラリーに見つからない他のアプリケーションを統合する」を選び、「作成」を押します。

  2. 2

    SAML SSOを設定する

    「シングルサインオン」→「SAML」を開きます。「基本的なSAML構成」にIdentifier(Entity ID)とReply URL(ACS URL)を入力し、サインオンURLは https://claude.ai/login にします。「属性とクレーム」ではメールクレームが user.mail(またはSCIMで使うのと同じ属性)になっているかを見ます。フェデレーションメタデータXMLをダウンロードし、Claude側のセットアップフローにアップロードします。

  3. 3

    SCIMプロビジョニングを設定する(SCIMを使う場合)

    「プロビジョニング」→「開始する」でモードを「自動」にし、テナントURLとシークレットトークンを入力して「テスト接続」を押します。「マッピング」でメール属性がSSOのメールクレームと同じフィールド(通常は user.mail)を指しているかを確認し、ステータスを「オン」にして保存します。Teamプランはこのステップを飛ばし、JIT(Just-in-Time)プロビジョニングを使います。

  4. 4

    利用者・グループを割り当てる

    「ユーザーとグループ」で、Claudeを使わせる人またはグループを割り当てます。割り当てた人とグループだけがプロビジョニングされ、SSOでログインできます。

  5. 5

    動作を確認する

    SCIMを有効にしたなら、プロビジョニングサイクルを実行して、Claudeの管理設定に利用者が現れるかを見ます。テスト用アカウントでSSOログインを通し、組織のワークスペースに入れるかも確認します。

Claude側で保存を押す前に、割り当てを済ませておく

手順の順序で見落としやすいのは、Claude側の「User provisioning」で「Save changes」を押すタイミングです。JITまたはSCIMを選んだら、保存する前に、Entraのアプリに全員を割り当て終えてください。Claudeのヘルプセンターは、割り当て前に保存すると、その人たちが組織からプロビジョニング解除されると説明しています。管理画面には、同期で何が変わるかのプレビューが出る場合があります。削除される人数が想定より多いときは、確定せずにキャンセルします。

グループマッピングを併用するなら、全員をロール用のグループに入れておく必要があります。シートの種類を決めるグループへの所属は任意です。

ログインできないときは、メール属性のずれを疑う

ログイン失敗の最も多い原因は、SCIMが送るメールとSSOが送るメールの不一致です。Claudeはメールアドレスの完全一致で、SSOログインとプロビジョニング済みのシートを結び付けます。1文字違っても通りません。

公式ガイドの手順はSAMLを前提に書かれています。管理画面を取り違えて探し回るIT管理者の例が、ヘルプセンターにも挙がっています。メールを送る経路が2つあり、設定画面も別々です。

くらべる

メールを送る経路は2つあり、設定画面も別

エンタープライズアプリケーション → プロビジョニング

SCIM側

SCIMの userName マッピングは、既定では userPrincipalName が参照元です。emails[type eq "work"].value の参照元も、ここの「属性マッピング」で変えます。プロビジョニングログの「Modified attributes」で、実際に送られた値を見られます。

シングルサインオン → 属性とクレーム

SSO側

SAMLのメールクレームは、user.mail を送る構成が一般的です。OIDCで構成した場合だけ、トークン設定が「アプリの登録」→「Token configuration」という別の管理画面になります。

Entraのユーザーには、メールに見える属性が複数あります。参照元がずれる余地は、次の4つの間にあります。

属性

メールに見えるEntraの属性

  • userPrincipalName

    SCIMの userName の既定マッピング。従業員ID形式で、実際のメールアドレスと違うことがあります。

  • mail

    OIDC・SAMLのメールクレームでよく使われる、標準的なメールアドレスです。

  • proxyAddresses

    SMTP: で始まる値で、ExchangeやM365の主アドレスとして使われます。

  • otherMails

    別名や副アドレスを持つことがある属性です。

症状と、それが指すもの

ヘルプセンターに挙がっている症状は4種類です。原因は同じでも、見え方は組織の設定で変わります。

  • 「Account creation is blocked」: SSOの認証は通るが、一致するプロビジョニング済みアカウントが無い。組織作成が制限されていれば、その人は完全に入れません
  • 個人の無料アカウントに着地する: 組織作成が制限されていないと、組織を素通りして無料アカウントを作ります
  • 「Please confirm your email」で、入力したメールとSSOコールバックのメールが違う
  • Claude CodeのCLI認証でメール不一致エラーが出る

Claude Codeの認証フローでは、ヘルプセンターは再認証に claude auth login --enterprise を案内しています。v2.1.285で claude auth login --help を見ると、オプションは次のとおりで、--enterprise は載っていません。

claude auth login --help
Options:
  --claudeai       Use Claude subscription (default)
  --console        Use Anthropic Console (API usage billing) instead of Claude
                   subscription
  --email <email>  Pre-populate email address on the login page
  -h, --help       Display help for command
  --sso            Force SSO login flow

SSO経由でログインし直すなら、v2.1.285では --sso と、メールを事前入力する --email が実在する選択肢です。ヘルプセンターの案内と手元のヘルプが食い違うときは、手元のヘルプに出るオプションを使います。

直し方と、直したあとの後始末

直すのはSCIM側です。「エンタープライズアプリケーション」で、Claudeの「プロビジョニング」があるアプリを開きます。「プロビジョニングの編集」→「属性マッピング」で emails[type eq "work"].value の行を開き、ソース属性をSSOが送る側(多くは mail)に揃えます。userName のマッピングも確認します。

反映の方法は、Claudeのヘルプセンターと、Microsoft Learnの記述が食い違います。ヘルプセンターは、属性マッピングを変えても増分同期ではメールが更新されないので、概要ページの「Restart provisioning」で全体を再実行するよう求めています。Learnには、属性マッピングやスコープの変更が新しい初回サイクルを起こすとあります。公式同士で記述が揃っていないため、変更後にプロビジョニングログで送られたメールが更新されたかを見て、更新されていなければ再実行する流れが確実です。増分サイクルの間隔は、Learnによると約40分です。

修正のあとに残る問題もあります。

  • 組織作成を制限していなかった間に、個人の無料アカウントを作った人がいる。削除にはサポート依頼が要ります
  • 誤ったメールで作られたゴースト席が残り、契約席数を使い続ける。すべての席が埋まると、マッピング修正後も「席が足りない」エラーでログインできません
  • ゴースト席の削除は、管理者の操作ではなくサポートへの依頼になります。削除後に、正しいメールで招待し直すか、再プロビジョニングが必要になることがあります

再発防止には、ドメイン検証のあとに管理設定で「Restrict organization creation」を有効にします。検証は、プロビジョニングログの値がSSOのメール形式と一致するかを、数人分で見ます。該当者にはブラウザーのclaude.aiのCookieを消してからSSOでログインしてもらいます。

My Appsポータルから直接起動する場合の制約

同じ親組織にTeam・EnterpriseのClaude組織とConsole組織の両方が連携しているとき、Console組織にはIdP起動ログインの制約があります。My Appsポータルのアプリタイルから始めると、利用者は常に claude.ai にリダイレクトされます。Console組織へ直接入れたいときは、Entra側で platform.claude.com/login?sso=true へのブックマークアプリケーションを別に作り、Console用の入口にします。

提供方式の違い

項目TeamEnterpriseConsole
SAML SSOTeam○Enterprise○Console○(親組織が必要)
JITプロビジョニングTeam○Enterprise○Console○
SCIMプロビジョニングTeam×Enterprise○(Entra ID P1/P2が必要)Console自前の親組織かEnterpriseの親組織なら○、Teamの親組織に合流していれば×
グループマッピングTeamJIT + マッピングEnterpriseJITまたはSCIM + マッピングConsoleJITまたはSCIM + マッピング

JIT + グループマッピングでは、初回ログイン時にグループ所属のうち最も権限の高いロールが付きます。ロールとシートの種類は、次のログインで所属に合わせて更新されます。SCIM + グループマッピングでは、グループ所属の変更がロールとシートに自動で伝わります。ロール変更の反映をログインまで待てるかどうかが、選ぶ基準です。

JITには、メンバーを自動では削除しない性質もあります。IdPのアプリの割り当てを外した人はログインできなくなりますが、メンバー一覧とシートは、管理者が消すまで残ります。Claude側だけで削除しても、次のSSOログインで再登録されます。恒久的に外すには、両方で操作します。

グループマッピングを併用している場合は例外があります。マッピング済みのグループをすべて外れた人は、アプリに割り当てたままでも、次のログインで組織から外れます。

証明書の期限切れで、全員が入れなくなる場合

EntraのSAML署名証明書(X.509)を更新したときは、Claude側でも書き換えが必要です。「Manage SSO」→「Metadata configuration」の「Edit」で証明書情報を更新して保存し、同じ画面の「Test sign-in」で確かめます。

「Require SSO」がオンのまま証明書が期限切れになると、すべてのサインイン経路がSSOを通るため、誰も更新作業に入れません。この場合はOwnerまたはPrimary Ownerのメールアドレスからサポートに連絡し、所有権を確認してもらう必要があります。Entra側で証明書の有効期限を控え、期限前に差し替えておくことが、この状況を避ける手段です。

まとめ

「Require SSO」をオンにする前に、SCIMとSSOが同じメール属性を送っていることと、証明書の期限を控えたことを確かめておくと、サポート頼みの復旧を避けられます。

TeamとEnterpriseのどちらでSCIMまで統制するかはClaude法人プランの契約ガイドが判断材料になります。制度の詳細はClaude Enterpriseプランガイドにまとまっています。IdPがGoogle Workspaceの組織はGoogle Workspace SSO設定を参照してください。Oktaの組織はOkta SSO設定が手順を扱います。

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

関連する記事

Claude をもっと見る →