Claude Google Workspace SSO設定 — SAMLとSCIM自動プロビジョニングの手順
Google WorkspaceをIdPにしたClaudeのSSO設定を、カスタムSAMLアプリの作成からSCIM自動プロビジョニングまで手順で解説します。
Google WorkspaceをIDプロバイダー(IdP)にしてClaudeのSSOを設定するには、Google管理コンソールでカスタムSAMLアプリを作成します。作成したアプリに、ClaudeのWorkOSセットアップ画面が発行する値を相互に登録します。対象はTeamプラン・Enterpriseプラン・親組織を持つConsole組織です。SAML自体はこの3つのプランすべてで設定できますが、SCIMによる自動プロビジョニングはEnterpriseプランと対象のConsole組織に限られます。
前提条件
作業を始める前に、次がそろっているか確認します。
- Claude側でOwnerまたはPrimary Owner権限(Team・Enterprise)、またはAdmin権限(Console)
- Google Workspace Super Admin権限
- 自社ドメインがClaudeの管理設定でドメイン検証済みであること(手順は後述の「ドメイン検証がPendingのまま進まないとき」)
- Console組織の場合、親組織が存在すること
親組織はドメイン検証とIdP接続を一元管理する単位です。Teamプランでは、SSOを有効にするときに親組織が作られます。Team・Enterpriseプランと連携していない単独のConsole組織は、営業チームに親組織の作成を依頼します。すでにTeam・Enterpriseの親組織があるなら、そちらのOwnerがConsole組織を統合(merge)する方法もあります。
1つの組織で検証する複数のドメインは、すべて単一のIdPで管理する必要があります。別々のIdPで管理しているドメインを同じ組織に混在させることはできません。1つの親組織に接続できるIdPも1つだけです。
Google側の設定を6ステップで進める
ACS URL・Entity ID・SCIMのエンドポイントURLとアクセストークンは、Claude側の管理画面が発行する値です。サポートに問い合わせて入手する情報ではありません。TeamとEnterpriseは claude.ai/admin-settings/identity、Consoleは platform.claude.com/settings/identity でSSOセットアップフローを開始し、Google管理コンソールと並行して開いたまま進めます。
Google管理コンソールでの設定の流れ
- 1
カスタムSAMLアプリを追加する
「アプリ」→「ウェブアプリとモバイルアプリ」→「アプリを追加」→「カスタムSAMLアプリを追加」に進み、アプリ名を「Claude」にします。IdPメタデータXMLをダウンロードし、Claude側のセットアップフローで求められたときにアップロードします。
- 2
サービスプロバイダーの詳細を入力する
Claude側に表示されるACS URLとEntity IDをGoogle側の該当欄に貼ります。Name ID形式は「EMAIL」、Name IDは「基本情報 > 主要メールアドレス」にします。
- 3
属性マッピングを設定する
Googleディレクトリ属性の「主要メールアドレス」をアプリ属性の
emailに対応させて「完了」をクリックします。Name IDとこの属性マッピングは別々の設定で、どちらもメールアドレスの送り先に関わります。 - 4
SCIM自動プロビジョニングを有効にする(Enterprise・対象のConsole組織のみ)
アプリ設定の「自動プロビジョニング」で「自動プロビジョニングを設定」をクリックします(Google Workspace管理者設定で有効化が必要な場合があります)。Claude側のエンドポイントURLとアクセストークンを入力し、
primaryEmailをClaude側のメールフィールドにマッピングして、プロビジョニングを有効にして保存します。Teamプランはこのステップを飛ばし、JITプロビジョニングを使います。 - 5
対象の組織部門・グループにアプリを割り当てる
アプリ設定の「ユーザーアクセス」で、対象の組織部門(OU)またはグループのサービスをオンにして「保存」します。Googleの画面では、全ユーザーのオン・オフ切り替えと、組織部門ごとの個別設定が選べます。
- 6
動作確認する
SCIMを有効にした場合は、メンバー一覧に対象者が追加されているかを見ます。あわせてテスト用アカウントでSSOログインし、組織のワークスペースに入れるかを確認します。Google側にも「SAMLログインをテスト」ボタンがあり、IdP起点のSSOを試せます。
Googleの管理コンソールでは、設定変更が反映されるまでに最長で24時間ほどかかることがあります(通常はそれより短い時間です)。割り当てた直後にログインできなくても、設定ミスとは限りません。Claude側のセットアップフローの最後にもSSOのテストを求める画面があるので、そこで通ることを確かめてから次に進みます。
割り当てていない利用者はSSOでログインできません。「設定は済んだのに誰も入れない」ときは、ステップ5の割り当てから疑います。
SSOを必須にする前に、既存アカウントの扱いを決める
Claude側には「Require SSO for Claude」と「Require SSO for Console」のトグルがあります。オンにする前に確認したいのは、自社ドメインのメールで作られた個人のFree・Pro・Team・Maxアカウントの扱いです。ドメイン検証だけでは、既存ユーザーのアクセスは変わりません。影響が出るのは、SSOを設定して必須にしたときです。
Require SSOのオン・オフで、既存アカウントはどうなるか
オフのまま
SSOアプリに割り当てた人は、既存のFree・Pro・Team・Maxアカウントを引き続き使えます。Team・Enterpriseのアカウントと個人アカウントは、画面左下のプロフィールアイコンから切り替えられます。割り当てていない人も「Continue with email」から既存アカウントに入れます。
オンにする
SSOアプリに割り当てていない人は、既存の個人アカウントに入れなくなります。アカウントが削除されるわけではなく、SSOで通れないためアクセスできない状態です。割り当て漏れがあると、その人の業務が止まります。
親組織に複数のClaude・Console組織をぶら下げている場合は、組織ごとに別のIdPグループを作る運用が公式に案内されています。SSOを必須にしたあと、IdP側の割り当てミスで管理者自身が入れなくなる事態にも備えて、Owner・Adminの割り当てを最初に確認します。
Team・Enterprise・Consoleでプロビジョニング方式はどう変わるか
SAMLによるSSOログインは3つのプランすべてで使えますが、自動プロビジョニングの選択肢はプランで変わります。
| プロビジョニング方式 | Team | Enterprise | Console(親組織あり) |
|---|---|---|---|
| Invite only(手動追加) | Team○ | Enterprise○ | Console(親組織あり)○ |
| JIT(初回ログイン時に自動作成) | Team○ | Enterprise○ | Console(親組織あり)○ |
| SCIM(IdP側の割り当てと自動同期) | Team× | Enterprise○ | Console(親組織あり)○(Team親組織と連携時は×) |
JITは初回ログイン時にUserロールで自動作成される方式です。落とし穴は削除の扱いで、JITはメンバーを自動では削除しません。Google側で割り当てを解除した人はログインできなくなりますが、メンバー一覧に残り、席も占有したままです。管理者がClaude側で削除するまで、その席は空きません。
JITで完全に外すには、Claudeで削除したうえでIdP側の割り当ても解除します。Claude側だけで削除すると、次のSSOログイン時に再び追加されます。SCIMなら、IdPのアプリから外した人は自動で削除されます。
ロールや席の種類をIdPのグループで決める「グループマッピング」は、JITでもSCIMでも組み合わせられます。JITでも、マッピング済みのすべてのグループから外れた人(アプリの割り当ては残っている人)は、次回ログイン時に組織から削除されます。「JITは自動削除しない」には、この例外があります。
Customロールにも注意が要ります。CustomロールはEnterpriseプランだけの機能で、TeamのロールはOwner・Admin・Userです。Customロールの権限はClaude側のグループから得る仕組みで、そのグループがIdPから同期されるのはSCIMのときだけです。JITでは「組織設定 > Groups」でグループを作ってユーザーを入れないと、Customロールにマッピングした人は権限のない状態でログインします。
SCIMを有効にすると、新しくプロビジョニングされたメンバーへ歓迎メールが送られます。止めたいときは、OwnerかPrimary Ownerが「User provisioning」の「SCIM directory sync」で送信設定をオフにします。CMEK・HIPAA・FERPAなど追加の要件を持つ組織にはメール自体が送られず、設定も表示されません。
TeamでJITに留めるか、SCIMまで使えるEnterpriseに進むかは、Claude TeamプランガイドとClaude Enterpriseプランガイドで機能差を比べられます。
ログインできないときは症状から原因をたどる
SCIMを使う組織で起きやすいのが、SAMLとSCIMが別々のメールアドレスをClaudeに送る不一致です。TeamのJITでは、この不一致は起きません。Google Workspaceのアカウントは主要メールアドレスのほかに複数のエイリアスを持てます。Claudeは両者を文字列の完全一致で照合するので、片方がエイリアスだとアカウントが結びつきません。SCIM設定とSAMLの属性マッピングはGoogle管理コンソールの別々のタブにあり、片方だけ直して満足するミスが典型です。
| 画面に出る症状 | 起きていること |
|---|---|
| 「Account creation is blocked」 | 起きていることSSO認証は通ったが、対応するプロビジョニング済みアカウントが見つからない(組織作成を制限している場合) |
| 個人の無料アカウントに入ってしまう | 起きていること組織作成を制限しておらず、プロビジョニングされた席を素通りして個人アカウントが作られた |
| 「Please confirm your email」で別のメールが出る | 起きていることSSOのコールバックが、入力したものと違うメールを返している |
| Claude Codeの認証でメール不一致エラー | 起きていることCLIの認証フローで同じ不一致が起きている |
どこを見て切り分けるか
確認する場所は3つです。1つ目はSCIMの属性で、「アプリ」→「ウェブアプリとモバイルアプリ」→ Claudeアプリ →「自動プロビジョニング」で、メールフィールドに何が対応しているかを見ます。2つ目はSAML属性マッピングのメール項目の元属性。3つ目は「ディレクトリ」→「ユーザー」で、該当者の主要メールとエイリアスを見比べる作業です。
ほとんど全員が同じ形でずれているなら属性マッピングの問題で、直す場所はSCIM側のマッピングです。1〜2人だけなら、そのアカウントのプロフィールに原因がある見込みです。SAMLの「サービスプロバイダーの詳細」でName IDがカスタムスキーマ項目やエイリアスになっていないかも確かめます。
直したあとに必要な全同期
primaryEmail にそろえて保存しても、増分同期では既存のレコードは更新されません。自動プロビジョニングをいったん停止して再度有効にし、全員分の同期を走らせます。個別に直すなら、該当者をアプリの割り当てから外して入れ直す方法もあります。
プロビジョニングログでメールが更新されたことを確かめてから、本人にログインし直してもらいます。この段階でclaude.aiのブラウザーCookieを消してもらうと、古いセッションの影響を避けられます。
すでに作られてしまったアカウントの後始末
不一致の間に個人の無料アカウントが作られていたり、誤ったメールで登録された席(ゴーストアカウント)が残っていたりする場合は、サポートに削除を依頼します。ゴーストが契約席をすべて埋めていると、新しいログインは席不足のエラーで失敗します。ゴーストはサポートによる削除で席が空きます。「Restrict organization creation」はゴースト対策ではありません。ドメイン検証のあとに使え、検証済みドメインでの新しいClaude・Console組織(個人アカウントを含む)の作成を止めます。
Claude Codeでの再認証
Claude Codeが影響を受けた人は、再ログインして席のメールと一致するか確認します。公式のトラブルシューティング記事は claude auth login --enterprise と案内しています。ただしv2.1.285の claude auth login --help には --enterprise がなく、SSOを強制するオプションは --sso です。実機で確認した出力は次のとおりです。
$ claude --version
2.1.285 (Claude Code)
$ claude auth login --help
Usage: claude auth login [options]
Sign in to your Anthropic account
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--email でメールを事前入力できるため、席のメールと一致しているかを確かめる用途に使えます。案内と手元のヘルプが食い違うときは、claude auth login --help の表示に従います。
ドメイン検証がPendingのまま進まないとき
ドメイン検証は、Claudeの組織設定でドメインを追加し、表示されるTXTレコードをDNSに登録して行います。TXTの値は anthropic-domain-verification- で始まり、入力欄に見えている部分より長い文字列です。コピーボタンで全体を取ります。既存のTXTレコードは置き換えず、並べて追加します。
Pendingになった後は、画面が値を再表示しません。値を失くしたときはドメインを削除して追加し直すことになり、新しい値が発行されます。DNSの反映は通常10分ほど待ちますが、世界中に伝播するには24〜48時間かかることがあります。「Refresh」で再チェックしても変わらないときは、次の3点を見ます。
- TXTレコードがドメインのルート(
yourdomain.com)にあること。wwwなどのサブドメインでは照合されません - 値が大文字小文字を含めて完全に一致していること
- 公開後にドメインを削除・再追加していないこと。再追加のたびに新しい値が発行され、公開済みの値は無効になります
SSOを必須にしたまま証明書が切れると管理者も入れない
IdPの署名証明書(X.509)が期限切れになる、またはローテーションされると、Claude側の更新が必要です。「Authentication」の「Manage SSO」から「Metadata configuration」の「Edit」で証明書を更新し、同じページの「Test sign-in」で確認します。
見落としやすいのは、「Require SSO」がオンのまま期限が切れたケースです。すべてのログイン手段がSSOを経由するため、証明書を更新するための管理者もログインできません。この場合はOwnerかPrimary Ownerのメールアドレスからサポートに連絡し、所有確認のうえでアクセスを回復してもらいます。IdP側で証明書の期限日を控え、期限前に更新するのが避ける手段です。
証明書更新の手間やDesktopアプリ側の統制まで含めて運用を組み立てるなら、Claude Code Desktop SSOとデバイス管理が続きの資料になります。IdPがMicrosoft Entra IDの組織はMicrosoft Entra ID SSO設定、Oktaの組織はOkta SSO設定が手順を扱います。
Googleのアプリ一覧から直接起動できない場合
同じ親組織にTeam・EnterpriseプランのClaude組織とConsole組織の両方が連携している場合、Console組織向けのIdP起点ログインには制約があります。GoogleのアプリランチャーからClaudeアイコンをクリックして始める方式には対応しておらず、開くと利用者は常に claude.ai 側にリダイレクトされます。
Console組織へ入れたいときは、IdP側で「Claude Console」というブックマークを作り、platform.claude.com/login?sso=true に向けます。SP起点のログインでConsoleに入る回避策です。IdP側でブックマークを作れる場合の手段です。
まとめ
Google側の作業は6ステップで済みますが、詰まる場所はその後に集中します。SCIMまで使うかは、退職者の席を自動で空けたいかで決まります。SSOを必須にするのは、Owner・Adminの割り当てと証明書の期限を確かめてからにします。