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

OktaをIDプロバイダー(IdP)にしてClaudeのSSOを設定するには、Okta管理コンソールでアプリケーションを作成します。作成したアプリに、ClaudeのWorkOSセットアップ画面が発行する値を相互に登録します。対象はTeamプラン・Enterpriseプラン・親組織を持つConsole組織です。SAMLによるSSO自体はどのプランでも設定できますが、SCIM自動プロビジョニングはEnterpriseプランと対象のConsole組織に限られます。

前提条件

• Claude側でOwnerまたはPrimary Owner権限(Team・Enterprise)、またはAdmin権限(Console)
• Okta管理者権限
• 自社ドメインがClaudeの管理設定でドメイン検証済みであること
• Console組織の場合、親組織が存在すること(単独のConsole組織は営業チームへ親組織作成を依頼します)

設定値を確認する画面

ACS URL・Entity ID・SCIMの認証情報は、いずれもClaude側の管理画面が発行する値です。

• TeamプランとEnterpriseプランは claude.ai/admin-settings/identity を開きます
• Console組織は platform.claude.com/settings/identity を開きます

この画面でSSOセットアップフローを開始し、Okta管理コンソールと並行して開いたまま以下の手順を進めます。

ステップ1 — Oktaでアプリケーションを作成する

• Okta管理コンソールで「Applications」→「Applications」→「Create App Integration」に進みます
• SSO方式は「SAML 2.0」(推奨)または「OIDC」を選びます
• アプリ名を「Claude」にして「Next」をクリックします

ステップ2 — SAMLを設定する

• 「Configure SAML」タブで、Claude側のセットアップフローに表示されるSingle sign-on URL(ACS URL)とAudience URI(Entity ID)を入力します
• Name ID formatを「EmailAddress」、Application usernameを「Email」に設定します
• 「Attribute Statements」で、名前を email、値を user.email とする属性を追加します
• Identity Provider metadata XMLをダウンロードし、Claude側のセットアップフローにアップロードします

ステップ3 — SCIMプロビジョニングを有効にする

SCIMによる自動プロビジョニングはEnterpriseプランと対象のConsole組織のみが利用できます。Teamプランの場合はこのステップをスキップし、JIT(Just-in-Time)プロビジョニングを使います。

• アプリの「Provisioning」タブで「Configure API Integration」をクリックします
• 「Enable API integration」にチェックを入れ、Claude側のセットアップフローに表示されるSCIM Base URLとAPI Tokenを入力します
• 「Test API credentials」で疎通を確認し、保存します
• 「To App」で、Create Users・Update User Attributes・Deactivate Usersを有効にします
• 「Attribute Mappings」→「To App」で、email 属性が user.email にマッピングされているか(SAMLアサーションと同じフィールドか)確認します

ステップ4 — 対象の利用者・グループを割り当てる

• 「Assignments」タブで、Claudeへのアクセスを許可する利用者またはOktaグループを割り当てます
• SCIMを有効にしている場合、割り当てられた利用者はOktaが自動でプロビジョニングします。JITを使っている場合は、初回のSSOログイン時にプロビジョニングされます

ステップ5 — 動作確認する

• SCIMを有効にした場合、プロビジョニングログで利用者がClaude側に正しく作成されたか確認します
• テスト用のアカウントでSSOログインを完了し、正しく組織のワークスペースに入れるか確認します

Oktaダッシュボードからアプリを直接起動する場合の注意

同じ親組織にTeam・EnterpriseプランのClaude組織とConsole組織の両方が連携している場合、Console組織向けのIdP起動ログインには制約があります。Oktaのダッシュボードでアプリタイルを直接クリックして始める方式には対応しておらず、クリックすると利用者は常に claude.ai 側にリダイレクトされます。

Console組織へ直接ログインさせたい場合は、Okta側で platform.claude.com/login?sso=true にリンクするブックマークアプリを別途作成します。これをConsole用の入口として案内する回避策があります。通常のSP起動ログイン(Claude側のログイン画面から「Continue with SSO」を選ぶ方式)であれば、この制限は影響しません。

プロビジョニング方式ごとの挙動早見表

Oktaでの運用は、割り当て解除時の挙動がプロビジョニング方式によって変わる点が実務上の分かれ目になります。

「Oktaでアクセスを外したのに、Claude側にまだユーザーが残っている」という状態は、JIT運用でよく起こります。SCIMに切り替えるか、定期的な手動棚卸しのどちらかで対応します。

よくあるつまずき

Oktaでの失敗は、SCIMとSAMLがそれぞれ違うフィールドを見ていることに起因するものが大半です。

SCIMが user.login、SAMLが user.email を参照していて不一致になる。Oktaのユーザープロファイルには類似したフィールドが2つあります。user.login(既定のSCIM userName マッピングで、testuser1 のような形式のこともある)と、user.email(SAML/OIDCのメールクレームとして推奨される形式)です。SCIMのプロビジョニング設定(Provisioning → To App)とSAMLの属性設定(Sign On)はOktaの別タブにあり、片方だけ確認して見落とすのが典型的な失敗です。両方を user.email に揃え、変更後は「Force Sync」で全利用者の再同期を実行します。属性を直しただけでは既存の登録済みレコードは更新されません。

組織作成の制限をかけずにメール不一致のまま運用してしまう。SSOログインが失敗した利用者が組織作成を制限されていない場合、意図せず個人の無料アカウントを作成してしまうことがあります。後から属性マッピングを直しても、誤って作成された個人アカウントと、誤ったメールで登録されたアカウントの両方が残るため、サポートへの問い合わせでの削除が必要になります。ドメイン検証後に「組織作成を制限」を有効にしておくと予防できます。

TeamプランのままProvisioningタブで「Configure API Integration」を探して詰まる。TeamプランはSCIMを利用できないため、この設定項目自体が意味を持ちません。JITプロビジョニングで運用するか、統制機能が必要ならEnterpriseへの移行を検討します。

まとめ

OktaでのClaude SSO設定は、アプリケーションの作成からグループの割り当て・動作確認まで5ステップです。つまずきの中心は、SCIMとSAMLが異なるOktaフィールド(user.login と user.email)からメールを参照してしまうことに集約されます。

TeamプランとEnterpriseプランのどちらでSCIMまでの統制が必要かはClaude Teamプランガイドで比較できます。詳しい統制機能はClaude Enterpriseプランガイドにまとまっています。IdPがGoogle Workspaceの組織はGoogle Workspace SSO設定を参照してください。Microsoft Entra IDの組織はMicrosoft Entra ID SSO設定が手順を扱います。

よくある質問

OktaのSAML 2.0とOIDC、どちらが向いていますか

公式手順ではSAML 2.0を推奨方式としています。OIDCでも接続自体は可能ですが、属性・クレームの確認箇所が変わるため、迷う場合はSAML 2.0を選ぶのが無難です。

Oktaのグループを複数のClaude・Console組織に振り分けて割り当てられますか

できます。同じ親組織に複数のClaudeまたはConsole組織が連携している場合、グループマッピングを使うことでOktaのグループごとに異なる組織へ振り分けられます。

SSO必須化(Require SSO)を有効にすると、既存のOktaに未割り当てのユーザーはどうなりますか

「Require SSO」を有効にした時点で、Oktaのアプリに割り当てられていない利用者はメールログインでのアクセスができなくなります。アカウント自体は削除されないため、後からOktaに割り当て直せば再びアクセスできます。

SSOの必須化を解除して、Okta連携自体も切り離すとどうなりますか

「Require SSO」のトグルを切るだけならSSOが任意に戻り、利用者はメールログインも選べます。Okta連携自体を切り離すには管理設定で「Manage SSO」から「Reset connection」を実行します。これを行うと全利用者のセッションが終了し、次回はメールのログインリンクからのサインインが必要になります。