>
>
公開日
SCIMプロビジョニングは、IdPとSaaSをつないで有効にすれば終わる設定ではありません。どの属性で既存アカウントと突き合わせるか、誰を同期の対象にするか、退職時に無効化と削除のどちらにするか。これらを決めないまま有効にすると、重複アカウントや「止めたはずなのに残っているアカウント」が生まれます。
本記事は、SCIMプロビジョニングを実際に設定する情シス担当者に向けて、設定前に決めること、IdPに共通する設定の流れ、Microsoft Entra ID・Okta・Google Workspace・HENNGE Oneそれぞれの手順と注意点をまとめたものです。設定後に起きやすい失敗パターンと、監査に備えた確認・記録の方法もあわせて解説します。
本記事のポイント
画面名・メニュー名は、2026年10月23日時点の各IdPの公式ドキュメントに基づいています
設定のトラブルは、IdPの画面操作よりも「正本・マッチング属性・同期の対象範囲・退職時の処理」を決めずに有効にしたことから起きがちです
IdPからの退職処理は「無効化」が基本で、アカウントの削除やライセンスの解放までは行われないことがあります
Google WorkspaceとHENNGE Oneは、自動プロビジョニングできる連携先が限られます
SCIMの仕組みやSAMLとの違いはSCIMとは？自動プロビジョニングの仕組みとSAMLとの違いで、SaaSごとの対応状況とプラン条件はSCIM対応SaaS一覧で解説しています。
SCIMプロビジョニングを設定する前に決める4つのこと
設定画面を開く前に、ユーザー情報の正本、既存アカウントとのマッチング属性、同期の対象範囲、退職時の処理の4つを決めておきます。ここが曖昧なまま有効にすると、IdPの設定だけでは直せない不整合がSaaS側に残ります。
決めること | 決める内容 | 決めずに進めると起きること |
|---|---|---|
ユーザー情報の正本 | 人事システム・IdP・SaaSのどこを正しい値とするか。SaaS側で直接編集してよい項目はあるか | SaaS側で直した値がIdPの値で上書きされる。IdPとSaaSで部署や氏名が食い違う |
マッチング属性 | 既存のSaaSアカウントとIdPのユーザーを、どの属性（メールアドレス、ユーザー名など）で突き合わせるか | 同じ人のアカウントが二重に作られる。作成に失敗し続ける |
同期の対象範囲（スコープ） | 全ユーザーを対象にするか、割り当てたユーザー・グループだけにするか | 対象外のはずの人までアカウントが作られる。必要な人に作られない |
退職時の処理 | 無効化で止めるか、削除まで行うか。削除までの猶予をどうするか | ライセンスが解放されないまま残る。データを引き継ぐ前にアカウントが消える |
ユーザー情報の正本
SCIMでは、IdPの値がSaaSへ一方向に送られるのが基本です。たとえばOktaで属性の更新を有効にすると、SaaS側で編集したプロフィールはOktaの値で上書きされます。人事システムを起点にIdPを更新し、SaaSはIdPから受け取るだけ、という流れを決めておくと、どこを直せばよいかで迷わなくなります。入社から退職までの社内手続きと合わせて整理する場合は、入退社フローのテンプレートも参考にしてください。
マッチング属性
SaaSにすでにアカウントがある状態でSCIMを有効にすると、IdPはマッチング属性を使って既存アカウントを探し、見つかればそのアカウントと結びつけます。見つからなければ新しく作成するため、メールアドレスの表記揺れや旧ドメインのままのアカウントがあると、同じ人のアカウントが二重にできます。有効にする前に、SaaSのユーザー一覧を出力し、IdPのメールアドレスやユーザー名と一致しているかを確かめておくのが確実です。
同期の対象範囲
最初から全ユーザーを対象にせず、テスト用のユーザーやグループだけを割り当てて動きを確かめ、問題がなければ対象を広げる進め方が安全です。どのIdPでも、割り当てたユーザー・グループに絞って同期する設定ができます。
退職時の処理
IdPでユーザーを止めたとき、SaaS側では「無効化（ログインできない状態）」になるのが一般的です。アカウントを削除するとデータも消えるSaaSが多いため、引き継ぎや証拠保全の期間を考えて、無効化から削除までの猶予を決めておきます。
なお、SCIMより先にSAMLによるSSOの設定を求めるSaaS・IdPが多くあります。SSOでの属性のずれも同期の失敗につながるため、SAMLとOAuthの違いで触れている属性マッピングの注意点もあわせて確認しておくと安心です。
どのIdPでも共通する設定の流れ：5ステップ
IdPが違っても、設定は「SaaS側で接続情報を発行する」「IdPにアプリを登録して接続する」「属性をマッピングする」「同期の対象範囲を決める」「テストユーザーで確かめてから有効にする」の5ステップで進みます。画面の名前は違っても、各IdPで同じ役割の設定があります。
ステップ | やること | 注意点 |
|---|---|---|
1. SaaS側で接続情報を発行する | SaaSの管理画面でSCIMを有効にし、エンドポイントURLとトークンを発行する | 発行時にしか表示されないトークンもある。有効期限があれば記録しておく |
2. IdPにアプリを登録して接続する | IdPのアプリ一覧から対象のSaaSを追加し、接続情報を入力して接続テストをする | 一覧にないSaaSは、カスタムのSCIMアプリとして登録できるIdPもある |
3. 属性をマッピングする | IdPのどの属性をSaaSのどの属性に送るかを確認・調整する | マッチング属性と、SaaS側の必須属性を必ず確認する |
4. 同期の対象範囲を決める | 同期するユーザー・グループを割り当てる | 最初はテスト用のユーザー・グループに絞る |
5. テストして有効にする | テストユーザーで作成・更新・無効化を確かめ、問題なければ本番の対象を割り当てる | エラー通知の送り先も設定しておく |
IdPごとの設定場所と、同期のタイミングは次のとおりです。
項目 | Microsoft Entra ID | Okta | Google Workspace | HENNGE One |
|---|---|---|---|---|
設定する場所 | エンタープライズ アプリケーションの［プロビジョニング］ | アプリの［Provisioning］タブ | ［ウェブアプリとモバイルアプリ］のアプリの［自動プロビジョニング］ | Access Control管理画面の［システム］→［プロビジョニング設定］ |
主な接続情報 | テナントのURLとシークレット トークン | APIトークンなど（カスタムアプリはSCIM connector base URLと認証方式） | ［承認］からSaaSの管理者でログインして連携（アプリによりトークンを入力） | 連携先サービスの認証情報 |
同期の対象 | 割り当てたユーザー・グループ（または全ユーザー） | ［Assignments］で割り当てたユーザー・グループ | 範囲に指定したグループ（指定しなければ全ユーザー） | 接続サービスへのアクセス権を持つユーザー |
同期のタイミング | 初回のあと約40分ごと | 割り当てや属性の変更をきっかけに処理 | 数時間おき | 管理画面から同期を実行 |
テストの方法 | 特定ユーザーをすぐ同期する「オンデマンド」 | テストユーザーを割り当てる | テスト用グループを範囲に指定する | 同期プレビューで変更内容を事前に確認 |
ステップ1でSaaS側に発行する値や、SCIMを使える契約プランはSaaSごとに異なります。対象のSaaSがどのIdPに対応しているかは、SCIM対応SaaS一覧で確認してから設定に入ると手戻りが減ります。
Microsoft Entra IDでの設定手順と注意点
Entra IDは、アプリギャラリーにないSaaSでも、SCIM 2.0に対応していれば接続できます。同期は約40分ごとで、グループで割り当てるにはMicrosoft Entra ID P1以上のライセンスが必要です。入れ子になったグループのメンバーは同期されない点にも注意します。
設定手順
Microsoft Entra 管理センターにアプリケーション管理者以上の権限でサインインし、［Entra ID］→［エンタープライズ アプリケーション］で対象のアプリを開きます。ギャラリーにないアプリは、独自のアプリケーションとして追加してから設定します
［プロビジョニング］を開き、プロビジョニング モードを［自動］にします
［管理者資格情報］に、SaaS側で発行したテナントのURLとシークレット トークンを入力し、［テスト接続］で接続できることを確かめます
［マッピング］で、ユーザー（SaaSが対応していればグループも）の属性マッピングを確認します。既存アカウントとの突き合わせに使うマッチング属性と、SaaS側の必須属性に値が入るかを見ておきます
［設定］で、エラー通知の送り先メールアドレスと、同期の範囲（割り当てたユーザーとグループだけにするか、全員にするか）を指定します
［ユーザーとグループ］でテストユーザーを割り当て、オンデマンドのプロビジョニングで、そのユーザーだけをすぐに同期して結果を確かめます
問題がなければ、プロビジョニングの状態を［オン］にして保存します
押さえたい注意点
最初に有効にしたときは、対象の全ユーザーを処理する初回サイクルが走るため、時間がかかります。そのあとは約40分ごとの差分の同期です。属性マッピングや範囲の条件を変更すると初回サイクルからやり直しになるため、対象人数が多い環境では、変更する時間帯を選んだほうが安全です。
グループで割り当てる場合、グループ内の直接のメンバーだけが同期され、入れ子になった子グループのメンバーは対象になりません。部署グループの中に課のグループを入れている構成では、必要なグループを直接割り当てるか、範囲の条件で対象に含めます。グループ自体（グループ名とメンバー構成）がSaaSに作られるのは、SaaSがグループの同期に対応している場合だけです。
退職時の動きは、IdPでの状態によって変わります。アプリの割り当てを外したとき、またはユーザーを無効化・論理削除したときは、SaaS側のアカウントは無効化されます（SCIMではactiveをfalseにする更新）。SaaS側で削除まで行われるのは、ユーザーが完全に削除されたときで、Entra IDでは論理削除から30日後に完全削除になります。
接続情報が無効になるなどで処理の失敗が続くと、アプリは「検疫」の状態になり、同期の頻度は最終的に1日1回まで下がります。検疫が4週間を超えると、プロビジョニング自体が停止します。トークンの有効期限切れで気づかないうちに止まっていた、という事態を防ぐため、エラー通知の送り先は担当者個人ではなくチームのアドレスにしておくと確実です。
ライセンスごとに使える機能の違いは、Entra IDの基本機能とライセンスで整理しています。
Oktaでの設定手順と注意点
Oktaでは、OIN（Okta Integration Network）に登録されたアプリなら、［Provisioning］タブから数ステップで接続できます。OINにないアプリも、SAMLなどで作ったカスタムアプリにSCIMを追加できます。割り当て用のグループとGroup Push用のグループを分けること、そしてLifecycle Managementの契約がないと［Provisioning］タブ自体が表示されないことに注意します。
設定手順（OINのアプリの場合）
管理コンソールの［Applications］→［Applications］で対象のアプリを開き、［Provisioning］タブを選びます。タブ内のConfiguration Guideに、そのアプリ固有の設定値が書かれています
［Configure API Integration］をクリックし、［Enable API integration］を選んで、SaaS側で発行したAPIトークンなどを入力します。［Test API Credentials］で接続を確かめ、保存します
［To App］で、［Create Users］［Update User Attributes］［Deactivate Users］のうち使う操作を有効にします
［Mappings］で、Oktaのユーザー属性からアプリへのマッピングを確認・編集し、保存します
［Assignments］タブでテストユーザーを割り当て、SaaSにアカウントが作られることを確かめます
Oktaのグループを、そのままSaaS側のグループとして作りたい場合は、［Push Groups］タブで設定します
OINにないアプリは、SAMLなどでSSO用のカスタムアプリを作成したうえで、［General］タブの［App Settings］でProvisioningに［SCIM］を選びます。［Provisioning］タブに、SaaS側のSCIM connector base URL、ユーザーを一意に識別する項目名（多くはuserName）、SaaSが対応している操作、認証方式（HTTPヘッダーのトークンなど）を入力します。
押さえたい注意点
［Create Users］では、SaaS側に同じユーザー名のアカウントがすでにあると、Oktaは新しく作成しません。Oktaのユーザー名とSaaS側のユーザー名の形式が揃っているかを、有効にする前に確認しておきます。
［Update User Attributes］を有効にすると、SaaS側で編集したプロフィールはOktaの値で上書きされます。SaaS側で部署名などを手で直す運用が残っていると、同期のたびに元に戻るため、正本をOktaに寄せるか、その属性をマッピングから外します。
［Deactivate Users］を有効にすると、アプリの割り当てを外したとき、またはOktaでユーザーを無効化したときに、SaaS側のアカウントも無効化されます。同じユーザーに再び割り当てると、SaaS側のアカウントも再び有効になります。
Group Pushでは、アプリの割り当てに使っているグループと同じグループをPushすることはサポートされていません。同じグループを使うと、休職などでユーザーを無効化したあとも、SaaS側のグループにメンバーとして残るといった不整合が起きます。割り当て用とPush用でグループを分け、PushしたグループはSaaS側で直接編集しないようにします。
［Provisioning］タブが表示されない場合、Okta組織にLifecycle Managementの権利がないか、アプリ自体がプロビジョニングに対応していないことが考えられます。カスタムアプリでは、作成方法によってSCIMを追加できないこともあるため、Oktaの案内に沿って作り方を確認してください。
Google Workspaceでの設定手順と注意点
Google WorkspaceをIdPにする場合、自動プロビジョニングできるのはGoogleが事前に連携したアプリだけで、同期は数時間おきです。対象のアプリで、先にGoogleをIdPとするSSOを設定してから、管理コンソールで自動プロビジョニングを設定します。
対象になるアプリは、Googleの管理者ヘルプにある自動プロビジョニングのガイド一覧で確認できます。2026年10月時点では、Slack、Box、Dropbox Business、Notion、Atlassian Cloud、Asana、Miro、Figma、Canva、HubSpot、Zendesk、Salesforce、Adobe、Docusignなどが掲載されています。構成できるアプリ数にも上限があり、Business Starter・Frontline Starterは最大3つ、Business Standard以上のエディションは最大100です。
設定手順
特権管理者として管理コンソールにログインし、［アプリ］→［ウェブアプリとモバイルアプリ］で対象のアプリを開きます
［自動プロビジョニング］で［自動プロビジョニングを設定］をクリックします
［承認］をクリックし、SaaSの管理者アカウントでログインして連携を許可します。アプリによっては、SaaS側で取得したアクセストークンなどを入力します
属性のマッピングで、SaaS側の必須属性（＊印の付いたもの）がすべてGoogleのディレクトリの属性に対応づいているかを確認します
必要に応じて、プロビジョニングの範囲を特定のグループに限定します。グループにセカンダリ ドメインのユーザーや組織外のユーザーが含まれていても、それらのユーザーは同期されません
プロビジョニング解除の条件を設定します。アプリがオフになったとき、Googleでユーザーが停止されたとき、削除されたときのそれぞれについて、何日後にSaaS側のアカウントを停止（アプリによっては削除）するかを選びます。選べる期間はアプリによって異なります
設定を完了し、自動プロビジョニングを有効にします
押さえたい注意点
同期は数時間おきに行われるため、入社日の朝に作成したユーザーが、始業時点ではまだSaaSに作られていないことがあります。入社前日までにGoogle側でユーザーを作成しておく運用にすると、初日のトラブルを避けられます。
自動プロビジョニングの対象は、有効なユーザー、停止中のユーザー、削除されたユーザーで、アーカイブされたユーザーは含まれません。退職者をアーカイブ ユーザーとして残す運用をしている場合は、SaaS側のアカウントがどう扱われるかを、テストユーザーで事前に確かめておきます。
うまく同期されないときは、アプリの自動プロビジョニングの画面で失敗の件数を確認し、失敗したユーザーの一覧をダウンロードすると、エラーコードと理由を確認できます。主なエラーは、後半の失敗パターンの章で解説します。
反対に、Microsoft Entra IDやOktaを主なIdPにしていて、Google Workspace側でユーザーを受け取りたい場合は、Google Workspaceのインバウンド SCIMを使います。仕組みと注意点はGoogle Workspaceのインバウンド SCIMで解説しています。
HENNGE Oneでできる範囲と設定の流れ
HENNGE OneのAccess Controlでは、HENNGE One ProまたはHENNGE One IdP Proプランで、Cybozu（cybozu.com）とSalesforceへのユーザープロビジョニングを使えます。Microsoft 365やGoogle Workspaceへのユーザー同期も別途用意されていますが、それ以外のSaaSのアカウント作成・削除は、HENNGE Oneの外側で補う前提で設計します。
連携先 | 前提 | 押さえたい仕様 |
|---|---|---|
Cybozu | Pro／IdP Proプラン。SSOの連携は必須ではないが、未設定の場合は作成したユーザーのパスワードをCybozu側で別途設定する | 一部の属性はマッピングを変更できない。cybozu.com側のプロビジョニングの制限事項もあわせて確認する |
Salesforce | Pro／IdP Proプラン。SalesforceのWebサービスAPIを使えるエディション（Enterpriseなど）が必要。SSO連携を推奨 | Access Controlでユーザーを削除しても、Salesforceでは無効化になり削除はされない。Salesforceのユーザー名を変えて同期すると新しいユーザーが作られ、元のユーザーは無効化される。ライセンス数を超えた分は無効なユーザーとして作られる |
Google Workspace | Access ControlからGoogle Workspaceへのユーザープロビジョニングを有効にする | 有効にしたあとは、ユーザーの作成・変更・削除をAccess Controlで行う。Google Workspace側での変更はAccess Controlに反映されない。Googleグループへの追加はGoogle Workspace側で別途行う |
設定の流れ（Cybozu・Salesforceの場合）
Access Controlの［接続サービス］で、連携先サービスのSSOを設定しておきます。その接続サービスへのアクセスを許可されたユーザーが、プロビジョニングの対象になります
管理画面の［システム］→［プロビジョニング設定］で、Access Controlからの同期の設定を追加し、連携先のサービスを選んで認証と属性のマッピングを設定します
対象サービスの同期の画面から、まず同期プレビューを実行し、どのユーザーが作成・更新されるかを確認します。同期による変更は元に戻せないため、プレビューで確かめてから同期を実行します
同期のあとは、実行履歴のログで結果を確認します
人事システムの入退社情報をAccess Controlに自動で反映したい場合は、HENNGE Access Control APIを使う方法があります。ただし、このAPIは通常の製品サポートの対象外とされているため、社内で開発・保守できる体制が前提になります。
HENNGE Oneを使っている企業では、SSOでログインはまとめられても、アカウントの作成・削除はCybozuとSalesforce以外のSaaSで手作業のまま、という状態になりやすくなります。マネーフォワード AdminaはHENNGE Oneとも連携できるため、HENNGE Oneの外側に残るSaaSアカウントの管理を補えます。詳しくはHENNGE Oneとの連携をご覧ください。
設定後に起きやすい失敗パターンと対処
SCIMプロビジョニングのトラブルは、「同期されない」「重複して作られる」「グループが合わない」「認証エラーで止まる」「退職者のアカウントが残る」の5つにほぼ分けられます。症状から原因の見当をつけ、IdPのログでエラーの中身を確かめてから直すのが近道です。
症状 | よくある原因 | 確認する場所 |
|---|---|---|
ユーザーが同期されない | 割り当て・範囲の対象外、必須属性が空、同期のタイミング待ち、SaaS側のライセンス不足 | IdPの割り当て設定と範囲、プロビジョニングのログ |
重複して作られる・作成に失敗する | マッチング属性の不一致、ユーザー名の重複、ユーザー名の変更 | 既存アカウントの一覧とIdPの属性値 |
グループが反映されない・残る | 入れ子グループ、割り当てとPushで同じグループを使用、SaaS側での直接編集 | グループの構成とPushの設定 |
同期が止まる | トークンの期限切れ・失効、連携を許可した管理者アカウントの変更 | 接続情報、エラー通知、IdPの状態表示 |
退職者のアカウントが残る | IdPの退職処理が無効化止まり、削除までの猶予期間、SCIM対象外のSaaS | 退職時の処理設定とSaaS側のアカウント一覧 |
1. ユーザーが同期されない
まず、そのユーザーが同期の対象に入っているかを確認します。Entra IDの入れ子グループのメンバー、Google Workspaceでセカンダリ ドメインや組織外のユーザー、アーカイブされたユーザーは、グループに入っていても対象になりません。
対象に入っているのに作られない場合は、SaaS側で必須の属性が空になっていないかを確認します。Entra IDでは、SaaS側で必須の属性がIdPで空になっていることが、よくある失敗の原因として挙げられています。Google Workspaceでは、必須項目が未入力の場合にエラーコード45016が記録されます。
単に同期のタイミングを待っているだけのこともあります。Entra IDは約40分ごと、Google Workspaceは数時間おきなので、すぐ確かめたいときはEntra IDのオンデマンドのプロビジョニングを使います。SaaS側のライセンスが足りない場合も作成に失敗し、Google Workspaceではエラーコード45003の理由として、ライセンス数の上限超過が挙げられています。
2. 重複して作られる・作成に失敗する
既存アカウントがあるのに新しく作られる場合は、マッチング属性の値がずれています。結婚で姓が変わった人のメールアドレス、会社統合前の旧ドメインのアドレスなどが典型です。反対に、SaaS側で一意であるべき値（ユーザー名やメールアドレス）が他のアカウントと重なっていると、作成そのものが失敗します。Google Workspaceのエラーコード45003の理由にも、ユーザー名がすでに存在するケースが含まれています。
ユーザー名の変更にも注意が必要です。HENNGE OneからSalesforceへの同期では、Salesforceのユーザー名を変えると新しいユーザーが作られ、元のユーザーは無効化されます。氏名変更などでユーザー名やメールアドレスを変えるときは、同期の前にSaaS側の扱いを確認します。
予防策は、有効にする前に既存アカウントの一覧とIdPの属性値を突き合わせておくことです。Entra IDには、既存アカウントを有効化前に洗い出して分類する機能があり、マッチング属性の設定を確かめるのに使えます。
3. グループが反映されない・メンバーが残る
OktaでGroup Pushを使っている場合は、割り当てに使っているグループと同じグループをPushしていないかを確認します。Oktaはこの使い方をサポートしておらず、ユーザーを無効化したあともSaaS側のグループにメンバーが残る原因になります。PushしたグループをSaaS側で直接編集した場合も、Oktaとの間で不整合が起きます。
Google Workspaceでは、範囲に指定していたグループを削除すると、エラーコード50005が記録されます。範囲の設定から削除済みのグループを外してください。HENNGE OneからGoogle Workspaceへの同期では、Googleグループへの追加は同期の対象外なので、Google Workspace側で別途行います。
4. 認証エラーで同期が止まる
SaaS側で発行したトークンの期限切れや失効は、気づかないうちに同期を止めます。Entra IDでは、管理者資格情報が無効な状態が続くと検疫に入り、4週間を超えるとプロビジョニングが停止します。Google Workspaceでは、トークンが失効した場合にエラーコード17010などが記録され、自動プロビジョニングの設定画面から再承認して復旧します。
トークンの発行日と有効期限は、どのSaaSのものかとあわせて台帳で管理しておくと、期限前に更新できます。連携を許可した管理者アカウントを削除したり権限を変えたりするときも、同期に影響しないかを事前に確認しておきます。
5. 退職者のアカウントが消えない
IdPで退職処理をしても、SaaS側では無効化にとどまるのが一般的です。Entra IDでは完全削除のときに初めて削除の要求が送られ、HENNGE OneからSalesforceへの同期では削除しても無効化になります。無効化されたアカウントがライセンスを使い続けるSaaSもあるため、削除までの流れを決めておく必要があります。
そもそもSCIMの対象になっていないSaaSや、SSOを通さずに作られたアカウントは、IdPの処理では止まりません。IdPを止めたあとに各SaaSで確認する手順は、退職者のアカウント削除｜IdP停止後のSaaS確認手順で詳しく解説しています。
設定完了の確認項目と証跡の残し方
本番の対象を割り当てる前に、テストユーザーで「作成・更新・グループ・無効化・削除」の一連の動きを確かめ、その結果と設定内容を記録しておきます。監査で入退社時の権限の処理を問われたとき、この記録がそのまま説明の材料になります。
確認項目 | 確認する方法 |
|---|---|
作成 | テストユーザーを割り当て、SaaSにアカウントが作られ、氏名・メールアドレス・部署などの属性が正しいかを見る |
更新 | IdPで部署や氏名を変え、SaaS側に反映されるかを見る |
グループ | テストユーザーをグループに追加・削除し、SaaS側のグループや権限に反映されるかを見る |
無効化 | 割り当てを外す、またはIdPで無効化し、SaaSにログインできなくなるか、ライセンスがどう扱われるかを見る |
削除 | 決めた方針どおり、削除まで行われるか（または無効化のまま残るか）を見る |
エラー通知 | 通知の送り先が設定され、担当チームに届くかを見る |
結果の記録には、各IdPのログを使います。Entra IDはプロビジョニングのログ、OktaはSystem Log、Google Workspaceは自動プロビジョニングの画面と管理コンソールの監査ログ、HENNGE Oneはプロビジョニング設定の実行履歴で確認できます。ログの保存期間はIdPや契約によって異なるため、監査で使う期間分は定期的に出力して保管します。
あわせて、設定日・設定者・接続先・属性マッピング・同期の範囲・退職時の処理・トークンの有効期限・テスト結果を、SaaSごとに1枚の記録にまとめておくと、担当者が替わっても設定の意図を引き継げます。監査で求められやすい証跡の考え方は、IT監査への対応と証跡の準備も参考にしてください。
SCIMで入退社を自動化しても、異動で増えた権限が残っていないか、使われていない権限がないかは、定期的に見直す必要があります。全ユーザー・全SaaSを対象にした見直しの進め方は、アクセス権限の棚卸しの進め方で解説しています。
IdPのログだけではわからないこと
IdPのログからわかるのは、IdPがSaaSへ送った処理の結果です。SCIMの対象外のSaaSや、SaaS側で直接作られたアカウントは、IdPのログには現れません。
マネーフォワード Adminaは、人事システムやGoogle Workspace・Microsoft Entra ID・Oktaを従業員マスターとして連携し、各SaaSのアカウントと突き合わせます。退職済みの人のアカウントが残っていればアラートで知らせ、従業員マスターにないIDも「未登録ID」として検知できます。アカウントの作成・削除に対応するSaaSも多く、連携できるSaaSの数は国内トップクラスです。APIのないSaaSも、Googleスプレッドシート連携でアカウント一覧を取り込めば、同じように確認の対象にできます。機能の詳細は従業員IDライフサイクルマネジメントとAdmina Directoryのページで紹介しています。
よくある質問（FAQ）
Q. SCIMプロビジョニングとJITプロビジョニングは何が違いますか？
A. JITプロビジョニングは、ユーザーがSSOで初めてログインしたときにアカウントを作る方式です。作成はできても、IdPでユーザーを止めたときにSaaS側のアカウントを無効化する仕組みは含まれないのが一般的です。SCIMプロビジョニングは、作成・更新・無効化をIdPからSaaSへ送るため、退職時の処理まで自動化できます。プロビジョニングという言葉の意味や種類から整理したい場合は、プロビジョニングとはをご覧ください。
Q. SCIMを設定する前に、SSOの設定は必要ですか？
A. 多くの場合は必要です。Google Workspaceの自動プロビジョニングは、対象のアプリでGoogleをIdPとするSSOを設定してから行います。HENNGE OneからSalesforce・Cybozuへのプロビジョニングは、SSOがなくても使えますが、作成したユーザーのパスワードを別途設定する必要があります。SaaSごとの条件は、SaaS側の管理者ヘルプで確認してください。
Q. 同期はどのくらいの頻度で行われますか？
A. Entra IDは初回のあと約40分ごと、Google Workspaceは数時間おきです。HENNGE Oneは管理画面から同期を実行します。Entra IDでは、オンデマンドのプロビジョニングを使うと、特定のユーザーを通常30秒以内に同期できます。
Q. Entra IDでグループ単位に割り当てるには、どのライセンスが必要ですか？
A. Microsoft Entra ID P1またはP2が必要です。グループで割り当てる場合、セキュリティが有効なグループを使い、入れ子になったグループのメンバーは同期されない点にも注意してください。
Q. SaaSにすでにアカウントがある状態で、SCIMを有効にしても大丈夫ですか？
A. 有効にできますが、事前の確認が欠かせません。IdPはマッチング属性で既存アカウントを探し、見つかれば結びつけ、見つからなければ新しく作ります。メールアドレスやユーザー名がIdPとずれていると重複アカウントができるため、有効にする前にSaaSのユーザー一覧とIdPの値を突き合わせてください。
Q. SCIMに対応していないSaaSは、どう管理すればよいですか？
A. SaaS独自のAPI、CSVの一括操作、SaaS管理ツールのいずれかで補います。方法ごとの向き不向きはSCIM対応SaaS一覧の後半で整理しています。対象のSaaSが多い場合は、入社日・退職日をきっかけにアカウントを発行・削除できるSaaS管理ツールを使うと、IdPに載らないSaaSも一か所で管理できます。
まとめ
SCIMプロビジョニングの設定は、IdPの画面操作そのものより、正本・マッチング属性・同期の対象範囲・退職時の処理を先に決めておくことが成否を分けます。IdPごとの違いは、同期のタイミング、グループの扱い、自動プロビジョニングできる連携先の範囲に出ます。設定後は、テストユーザーで一連の動きを確かめて記録し、IdPのログに現れないアカウントまで含めて定期的に確認する運用につなげてください。
設定を進めるときは、次の項目を確認してください。
ユーザー情報の正本を決め、SaaS側で直接編集してよい項目を整理した
既存アカウントの一覧とIdPのメールアドレス・ユーザー名を突き合わせた
同期の対象を、まずテスト用のユーザー・グループに絞った
退職時に無効化で止めるか削除まで行うか、削除までの猶予を決めた
SaaS側の必須属性に、IdPの値がすべて対応づいていることを確認した
Entra IDでは入れ子グループ、OktaではGroup Pushのグループを分けることを確認した
テストユーザーで作成・更新・グループ・無効化・削除の動きを確かめた
エラー通知の送り先をチームのアドレスにし、トークンの有効期限を記録した
設定内容とテスト結果、ログの出力先をSaaSごとに記録した
参考にした公式ドキュメント
Microsoft Learn「Configure an app for automatic user provisioning」「How Application Provisioning works in Microsoft Entra ID」「Application provisioning in quarantine status」「Provision a user or group on demand」「Customizing user provisioning attribute-mappings」
Okta Help Center「Configure provisioning for an app integration」「Add SCIM provisioning to app integrations」「Group Push」「Troubleshooting Group Push」、Okta Support「The Provisioning Tab Does Not Appear In the App Integration」
Google Workspace 管理者ヘルプ「ユーザーの自動プロビジョニングについて」「View auto-provisioning errors」および各アプリのプロビジョニング設定ガイド
HENNGE One サポートサイト「Access Control ユーザープロビジョニング機能概要」、SalesforceとCybozuのユーザープロビジョニング設定、ユーザー同期の実行手順、Google Workspaceへのユーザープロビジョニングの有効化手順、HENNGE Access Control API
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
