SaaSのSSO/SCIM対応チェックリストとは、SaaSを契約する前に「IdP（Entra ID、Google Workspace、Oktaなど）からのシングルサインオンと、SCIMによるアカウントの自動作成・無効化に対応しているか」を、プロトコル・プラン・属性・監査ログの観点で確認する項目の一覧です。契約後に「SSOは上位プランだけ」「SCIMは非対応」と分かると、退職者のアカウントを手作業で消す運用が何年も続きます。
SSOとSCIMがそれぞれ何を解決するのか、なぜセキュリティ上はSCIMのほうが効くのかから始めて、導入前に営業担当に投げる質問リスト、IdP側とSaaS側の設定の流れ、パイロットでのテスト項目、運用に入ってからの属性マッピングとライセンス自動割り当ての順に進めます。
この記事でわかること
- SSO（認証の委任）とSCIM（アカウントのライフサイクル同期）の役割の違い
- 退職者処理においてSSOだけでは不十分で、SCIMの無効化が必要な理由
- 導入前チェックリスト：SAML/OIDC、SSO専用プラン、SCIMの属性とグループ、監査ログ、緊急ログイン
- Entra ID / Google Workspace / OktaでのIdP側設定と、SaaS側設定の流れ
- パイロットグループでのテスト項目と、AADSTSエラーやSCIMの検疫状態への対処
SSO/SCIMを導入するメリット：退職者処理と監査
SSOは「認証をIdPに委ねる」仕組みです。SaaSはパスワードを持たず、ユーザーがアクセスするとIdPにリダイレクトし、IdPが発行した署名付きの証明（SAMLアサーションまたはOIDCのIDトークン）を受け取ってログインさせます。MFAや条件付きアクセスはIdP側で一度設定すれば、SSO対応のSaaSすべてに効きます。プロトコルの詳細はSSO・SAML・OIDCの違いの解説を参照してください。
SCIM（System for Cross-domain Identity Management）は、IdPがSaaSのREST API（/Users、/Groups）を呼んで、アカウントの作成・属性更新・無効化を自動で行う仕様です。IdPでユーザーを無効化すると、SCIMがactive: falseをSaaSに送り、SaaS側のアカウントが無効化されます。
退職者処理の観点では、SSOよりSCIMのほうが効きます。SSOで止められるのは「新しいログイン」だけで、退職前にログインしたままのブラウザーセッション、スマホアプリの長期トークン、ユーザーが発行したAPIキーやパーソナルアクセストークンは、SaaS側で有効期限が来るまで生き続けます。SCIMでアカウント自体を無効化すると、ほとんどのSaaSは既存セッションとトークンを失効させ、ライセンスも解放します。SCIMがないSaaSは、退職日に管理者が手で無効化するしかなく、その作業が抜けたアカウントが「退職者のアカウントで取引先データが持ち出された」という事故の典型的な経路です。
監査の面でも、ログインの成否・IPアドレス・MFAの有無がすべてIdPのサインインログに集約され、「誰がいつどのSaaSに入ったか」を1か所で答えられるようになります。
導入前チェックリスト
SaaSの営業担当やヘルプページに確認する項目です。「SSO対応」と一言で書かれていても、中身は製品ごとに大きく違います。
| 項目 | 確認する内容 | 判断基準 |
|---|---|---|
| プロトコル | SAML 2.0とOIDCのどちら（または両方）か。SP-Initiated（SaaSのURLから始める）とIdP-Initiated（IdPのポータルから始める）の両方に対応するか | 自社IdPが対応していればどちらでも可。SP-Initiatedがないとブックマークからのアクセスで困る |
| プラン | SSOがどのプランから使えるか。SCIMはさらに上のプランか | SSOのために全員分のプランを上げると総額が倍近くになる製品もある。見積もり段階で必ず織り込む |
| SSOの強制 | パスワードログインを無効化して「SSOのみ」にできるか。管理者用のバイパスURLはあるか | 強制できないと、SSOを迂回してパスワードでログインされ、IdP側のMFAが無意味になる |
| JITプロビジョニング | 初回SSOログイン時にアカウントを自動作成するか | SCIMがない場合の次善策。ただし無効化はできない |
| SCIM | SCIM 2.0対応か。ユーザーの作成・更新・無効化と、グループの同期（Group Push）に対応するか。無効化は「停止」か「削除」か | 「削除」しかない製品はデータが消えるため、退職時の引き継ぎ手順が別途必要 |
| 属性 | userName、email、displayName、部署、役職、managerなど、どの属性を受け取れるか。カスタム属性は可能か | グループやロールを部署属性で自動化したいなら必須 |
| ロールとライセンス | IdPのグループをSaaS側のロールやライセンス種別に対応付けられるか | できないと「アカウントは作られるが権限は手動」になる |
| 監査ログ | ログイン・権限変更・データエクスポートのログが取れるか。CSV出力やAPI、SIEM連携は可能か | ISMSや内部監査の要求水準で判断 |
| セッション制御 | セッションの最大時間、管理者による強制ログアウト、無効化時のトークン失効の挙動 | SCIM無効化で既存セッションが切れない製品は、退職手順に「強制ログアウト」を足す |
| 緊急ログイン | IdP障害時に管理者がパスワードで入れる「ブレークグラス」の口があるか | ないと、IdP障害中はSaaSの設定変更もできない |
| 複数ドメイン・複数IdP | グループ会社など複数ドメインや複数IdPからのSSOに対応するか | M&Aや分社の予定がある会社は必須 |
| IdPのカタログ掲載 | Entraのギャラリー、GoogleのSAMLアプリカタログ、Okta Integration Networkに掲載されているか | 掲載済みならURLや属性が事前設定され、設定時間が数時間から数十分に縮む |
この中で契約前に必ず確定させるべきは「プラン」「SSOの強制」「SCIMの無効化の挙動」の3つです。他は導入後にも調整できますが、この3つは契約とデータの扱いに直結します。
設定の流れ（IdP側・SaaS側）
SSOの設定は、IdPとSaaSの間で「互いのURLと署名証明書を交換する」作業です。SaaS側の管理画面にある「SSO設定」ページに、IdPが発行するメタデータ（エンティティID、SSO URL、署名証明書）を貼り、IdP側にはSaaSのエンティティIDとACS URL（アサーションの送り先）を登録します。
| IdP | SSOの設定場所（執筆時点） | SCIMの設定場所 |
|---|---|---|
| Microsoft Entra ID | Entra管理センター → エンタープライズアプリケーション → 新しいアプリケーション → ギャラリーから検索（なければ「独自のアプリケーションの作成」）→ シングルサインオン → SAML → 基本的なSAML構成に識別子（エンティティID）と応答URL（ACS URL）を入力 → 属性とクレームでNameIDを決定 → フェデレーションメタデータXMLをダウンロード → ユーザーとグループで割り当て | 同じアプリの「プロビジョニング」→ モード「自動」→ SaaSから取得したテナントURLとシークレットトークンを入力 → 接続テスト → マッピング確認 → 設定で「割り当て済みのユーザーとグループのみを同期」→ 開始 |
| Google Workspace | 管理コンソール → アプリ → ウェブアプリとモバイルアプリ → アプリを追加 → カタログから検索（なければ「カスタムSAMLアプリの追加」）→ IdPのメタデータをダウンロード → ACS URLとエンティティIDを入力 → 属性マッピング → ユーザーアクセスをOUまたはグループでオン | 同じアプリの「自動プロビジョニング」→ 承認 → 属性マッピング → プロビジョニングの範囲（グループ）→ 無効化時のアクション（一時停止／削除）→ オン。エディションによって設定できるアプリ数に上限があるため、公式ヘルプで確認 |
| Okta | Admin Console → Applications → Browse App Catalog → 対象を追加 → Sign Onタブの設定手順に従ってSaaS側へ値を入力 → Assignmentsでグループ割り当て | 同じアプリのProvisioningタブ → Configure API Integration → トークン入力 → To AppでCreate / Update / Deactivateを有効化 |
NameID（SaaSがユーザーを識別するキー）にどの属性を使うかは、最初に決めて以後変えないでください。Entra IDでは既定がuser.userprincipalnameですが、UPNとメールアドレスが違う会社（UPNが[email protected]から同期されている等）ではSaaS側のメールアドレスと一致せず、既存アカウントと紐づかないか、重複アカウントが作られます。UPNとメールが同じ会社はUPN、違う会社はuser.mailを使い、SCIM側のuserNameマッピングも同じ属性に揃えます。
運用開始後にこの属性を変えると、SaaS側は全ユーザーを別人と判定して新しいアカウントを一斉に作ります。UPNの形式変更（ドメイン統合や表記ルールの変更）を予定している会社は、SSO導入前に済ませるか、SCIMのexternalIdにobjectIdのような不変のIDをマッピングしておいてください。
SCIMの通信は、IdPがSaaSのエンドポイントにBearerトークン付きでリクエストを送る形です。IdPが実際に送っている内容は次のようなもので、トラブル時にSaaS側のログと突き合わせる際の目安になります。
# ユーザーが存在するかの確認（IdPは同期前にこの検索を行う）
curl -s -H "Authorization: Bearer $SCIM_TOKEN" \
"https://scim.example-saas.com/scim/v2/Users?filter=userName%20eq%20%22taro.yamada%40example.com%22"
# 無効化のリクエスト本文（PATCH /Users/{id}）
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{ "op": "replace", "path": "active", "value": false }
]
}Entra IDのプロビジョニングは約40分間隔の増分サイクルで動きます。ユーザーを無効化してからSaaS側に反映されるまで最大40分程度かかるため、即時に止めたい退職処理では、IdPでの無効化に加えて「プロビジョニング → オンデマンドでプロビジョニング」で対象ユーザーを個別に同期します。
テスト手順（パイロットグループ）
SaaS側のSSOは、最初は「任意（パスワードログインも可）」の状態で有効化し、次の項目をパイロットグループ（情シス2〜3名＋利用部署の1〜2名）で確認してから「SSO必須」に切り替えます。
- SP-Initiated：SaaSのログインURLからIdPにリダイレクトされ、IdP側のMFAを経てログインできる
- IdP-Initiated：EntraのMyAppsポータルやGoogleのアプリランチャーからログインできる
- 既存ユーザーの紐づけ：SSO前から存在するアカウントに正しく紐づき、重複アカウントが作られない（大文字小文字やエイリアスの違いに注意）
- SCIM作成：IdPのグループにテストユーザーを追加すると、次のサイクルでSaaS側にアカウントができ、部署などの属性が入っている
- SCIM更新：IdPで表示名を変えると、SaaS側に反映される
- SCIM無効化：グループから外すとSaaS側で無効化され、ログイン中のセッションが切れ、ライセンスが解放される。再追加で同じアカウントが復活する
- SaaS側のMFAが二重に要求されないこと（IdPでMFA済みならSaaS側のMFAはオフにする）
- モバイルアプリとデスクトップアプリからもSSOでログインできる
- 管理者用のバイパスURLで、シークレットウィンドウからパスワードでログインできる
- IdPのサインインログとSaaSの監査ログに、同じログインが記録されている
「SSO必須」に切り替える前に、SaaS側の管理者アカウントを1つ、SSO対象外のブレークグラスとして残してください。SAML証明書の期限切れやIdP障害のとき、この口がないとSSO設定の修正自体ができなくなります。このアカウントはSaaS側でMFAを有効にし、パスワードは緊急用として金庫やパスワードマネージャーの管理者専用領域に保管します。
運用：属性マッピングとライセンス自動割り当て
運用に入ってからの手間を決めるのはグループ設計です。SaaSごとにSaaS-製品名-UsersとSaaS-製品名-AdminsのようなグループをIdPに作り、SSOの割り当てとSCIMの同期範囲を両方このグループに向けます。SaaS側で「グループ→ロール」「グループ→ライセンス種別」の対応付けができる製品なら、Admins グループに入れるだけで管理者権限が付き、Usersから外せばライセンスが戻ります。Entra IDの動的グループ（部署属性が「営業」なら自動で所属など）と組み合わせると、人事マスタの部署変更だけでSaaSのアクセス権が追随します。
期限管理が必要なものが2つあります。SAML署名証明書（Entra IDの既定は3年）と、SCIMのBearerトークン（SaaSによっては1年で失効）です。どちらも切れた瞬間に全員がログインできなくなるか、同期が止まります。SaaS台帳に期限を記録し、期限の1か月前にカレンダー通知を出す運用にしておきます。SaaSの棚卸しと台帳の項目はSaaS管理の始め方でまとめています。
名前変更（結婚など）でメールアドレスが変わる会社では、SaaS側がユーザーをuserNameで照合していると、変更後に別人として新規作成されることがあります。SCIMのexternalIdにEntraのobjectIdのような不変のIDをマッピングしておくと、この問題を避けられます。対応しているかどうかも、チェックリストの「属性」の項目で聞いておくべき点です。
確認方法
SSOのログインは、Entra IDなら「ID → 監視と正常性 → サインインログ」でアプリケーション名でフィルタし、認証要件（MFAの有無）と条件付きアクセスの結果を確認します。Google Workspaceは「レポート → 監査と調査 → SAMLログイベント」に成否とエラー理由が記録されます。SCIMの動作は、Entra IDなら「ID → 監視と正常性 → プロビジョニングログ」でユーザーごとにCreate / Update / Disableのアクションと結果が見られ、Googleは対象アプリの「自動プロビジョニング」画面のログで確認します。
SAMLアサーションの中身（NameIDの値や属性）を見たいときは、ブラウザー拡張のSAMLトレーサーを入れてログインの通信を記録すると、IdPが実際に送った値が確認できます。「NameIDに何が入っているか」が分かるだけで、紐づけ失敗の原因の大半が特定できます。
つまずきポイント
AADSTS50105: The signed in user is not assigned to a role for the application
Entra IDのエンタープライズアプリで「ユーザーの割り当てが必要」が「はい」のとき、割り当てられていないユーザーがアクセスするとこのエラーになります。対象グループにユーザーを追加するか、割り当てが不要なアプリなら設定を「いいえ」にします。グループの追加後、反映まで数分かかることがあります。
AADSTS50011: The reply URL specified in the request does not match
SaaSが送ってきたACS URLと、Entra側の「応答URL」が一致していないエラーです。SaaSの管理画面に表示されているACS URLを、末尾のスラッシュやhttp/httpsの違いまで含めて正確に貼り直します。SaaSがテナント固有のURL（https://example-corp.saas.com/saml/acs）を使う場合は、汎用のURLでは通りません。
Googleで「app_not_configured_for_user」と表示される
ユーザーが所属するOUまたはグループでアプリの「ユーザーアクセス」がオンになっていないか、ACS URLとエンティティIDの設定が誤っているときのGoogle側のエラーです。まずアプリのユーザーアクセスが該当OUで「オン」かを確認し、次にSaaS側の値と突き合わせます。
Entraのプロビジョニングが「検疫（Quarantine）」状態になり同期が止まる
SCIMエンドポイントが認証エラーや5xxを返し続けると、Entra IDはそのアプリのプロビジョニングを検疫状態にして再試行間隔を伸ばします。原因の大半はBearerトークンの失効か、SaaS側でSCIM機能がオフになったことです。SaaS側でトークンを再発行してEntraに登録し、接続テストが通れば「プロビジョニングの再開」で復旧します。検疫中はユーザーの無効化も届かないので、プロビジョニングログの通知メールは必ず情シスのグループアドレスで受け取ってください。
よくある質問
SSOとSCIMの違いは？
SSOは「ログインのとき」に働く仕組みで、認証をIdPに委ね、SaaSにパスワードを持たせません。SCIMは「ログインしていないとき」に働く仕組みで、IdPの変更（入社・異動・退職）をSaaSのアカウントに自動で反映します。SSOだけだと退職者のアカウントはSaaS側に残り、既存セッションやAPIトークンも生き続けるため、両方揃って初めてアカウントのライフサイクルを閉じられます。
SSO対応が上位プラン限定なのはなぜ？
SaaSベンダーが「SSOを必要とするのは統制の効いた企業」とみなし、企業向けプランとの差別化要素にしているためです。技術的なコストの差ではなく価格戦略なので、交渉で「SSOだけ追加オプションで」と持ちかける余地はあります。見積もり段階で必ずSSO/SCIM込みの価格を出させ、全員分のプランを上げる総額で比較してください。
SCIMがない場合の代替は？
JITプロビジョニングで作成を自動化し、SSOを必須にしてIdP側の無効化で新規ログインを止め、退職手順書に「SaaS側で手動無効化」を明記して二人で確認します。SaaSがユーザー管理APIを公開していれば、退職イベントを起点に無効化するスクリプトも組めます。いずれも抜けが起きるので、四半期ごとにSaaS側のユーザー一覧と在籍者リストを突き合わせてください。
まとめ
契約前に確定させる3点は、SSO/SCIMが使えるプランと総額、パスワードログインを無効化できるか、SCIMの無効化が「停止」か「削除」かです。設定作業そのものはカタログ掲載のSaaSなら1時間程度で終わりますが、NameIDに使う属性とグループ設計を最初に決めておかないと、重複アカウントと手動運用が後に残ります。SSO必須に切り替える前のブレークグラスアカウント、SAML証明書とSCIMトークンの期限管理、四半期の突き合わせ棚卸しの3つを運用に組み込んでください。
次に読む
- SSO・SAML・OIDCの違いをやさしく解説：チェックリストのプロトコル項目を理解するための基礎
- Entra IDの条件付きアクセス入門：SSOで集約した認証にMFAと端末条件を掛ける
- 企業向けパスワードマネージャーの選び方：SSOに対応しないSaaSの認証情報を管理する