アカウントプロビジョニングとは？SCIMの仕組みと導入方法

アカウントプロビジョニングは、システムを利用するためのアカウントを作成し、属性や所属などを整える処理です。入社時の作成だけでなく、異動時の変更、退職時の利用停止まで含めて設計すると、手作業の漏れを減らせます。

対象はSaaS、オンプレミス、自社開発アプリケーション、クラウドサービスです。ここではSCIM 2.0と、既存SSO環境への追加を中心に扱います。製品情報と参考資料の確認日は2026年11月1日です。

プロビジョニングとIDライフサイクル管理

IDライフサイクル管理は、IDの発生から変更、廃止までを管理する考え方です。人事情報や承認済みのディレクトリを正本として、必要な利用先へ反映します。退職や契約終了時の無効化・削除はデプロビジョニングと呼びます。

イベント	代表的な処理	確認すること
入社・利用開始	アカウント作成、初期グループ設定	利用開始日、承認、必要最小限の権限
異動	部署・役割・所属の変更	新権限だけでなく旧権限の除去
退職・利用終了	無効化、データ移管、必要に応じた削除	停止期限、保存義務、所有者、再雇用時の扱い

手動管理では管理者が利用先ごとに操作します。自動化すると一貫した反映がしやすくなりますが、正本の誤りや設定ミスも広がります。同期の成功件数だけでなく、反映された状態を確認する運用が必要です。

SCIMとは

SCIM（System for Cross-domain Identity Management）は、異なるシステム間でID情報を管理するための標準です。RFC 7643がCore Schema（属性の構造）、RFC 7644がProtocol（HTTPでの操作）を定義しています。SSOのSAMLやOIDCとは役割が異なります。

一般的な構成では、ID基盤のプロビジョニング機能がSCIMクライアント、利用先がSCIMサービスプロバイダーになります。これはSAMLのIdP・SPという認証上の役割とは別です。

人事・ディレクトリ → ID基盤のプロビジョニング機能
                           ↓ HTTPSの管理API
                    アプリのSCIMエンドポイント
                           ↓
                    ユーザー・グループ

オンプレミスでは中継エージェントやネットワーク設計が必要になることがあります。SCIM未対応なら、製品固有APIやディレクトリ連携なども候補です。

SCIM 2.0のリソースと操作

Usersはユーザー、Groupsはグループのリソースです。実際の対応属性やグループ同期の可否は利用先によります。グループをアプリへの割当条件に使うことと、グループ自体を利用先へ作成することも別の機能です。

HTTPメソッド	役割	例
POST	リソース作成	`/Users`に新規ユーザーを登録
GET	取得・検索	`/Users/{id}`やフィルター検索
PATCH	一部を変更	`active`や所属メンバーを変更
PUT	更新可能な属性を全体置換する更新	省略属性への影響に注意して更新
DELETE	リソース削除	`/Users/{id}`を削除

PATCHなどの対応機能は実装に依存します。DELETE後の内部的な保管方法やデータ保持、active=falseによる無効化の具体的な効果も、アプリ側の仕様を確認します。

`id`・`externalId`・`userName`の違い

次は利用先が返すユーザー情報の一例です。値は架空です。

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "app-u-8421",
  "externalId": "source-user-0198",
  "userName": "aoi@example.com",
  "active": true
}

属性	この例での意味	注意点
`id`	利用先が発行したリソースID `app-u-8421`	サービス提供側が割り当て、リソースの存続中は変わらない
`externalId`	連携元のユーザーを表す `source-user-0198`	クライアントが指定する任意属性。常に存在するとは限らない
`userName`	利用先のユーザー名 `aoi@example.com`	必須のユーザー識別属性だが、メールアドレスとは限らず変更もあり得る
`active`	利用状態が有効	無効化の効果やセッション処理は利用先次第

例えば改姓でユーザー名を変更しても、同じ利用先アカウントとして更新するならidは維持します。externalIdを連携元の不変IDに対応させる設計は候補になりますが、対応・マッピングを確認せず設定してはいけません。

既存SSO環境に追加する場合

例えば、社内ポータルはクラウドID基盤とSAML連携済みで、社員のファイル、投稿、権限が既存アカウントに紐付いているとします。現在のアカウント作成・変更・停止は手動です。

追加後は、SSO設定を原則維持し、別の管理経路としてSCIMを設定します。目標は、既存アカウントを継続利用しながら、作成・更新・無効化を自動化すること です。SCIM追加のためにアカウントを削除・再作成する必要があるとは限りません。

項目	変更前	変更後の目標
認証	既存のSAML・OIDCによるSSO	原則維持
アカウント管理	手動や別の運用	SCIM等で自動化
既存ユーザー	データ・権限を保有	同じアカウントへ紐付け
データと権限	アプリ内で管理	保持状態と変更範囲を検証

SSOとプロビジョニングの責任範囲は両者の比較、認証識別子はSSOの仕組みで確認できます。

既存アカウントとのマッチング

マッチングは、連携元の利用者と、利用先にすでに存在するユーザーを結び付ける処理です。「同じ人物に見える」ことではなく、コネクターがどの属性を検索し、何件に一致したかが重要です。

連携元と利用先のユーザー一覧を取得し、利用先の内部ユーザーIDも記録する。
メールアドレス、ユーザー名、不変IDなど、利用先が検索に対応する属性を確認する。
空値、重複、大文字小文字、別名、メール変更、再雇用を確認し、照合規則を設計する。
少数ユーザーで検索結果と同期ログを確認する。既存の利用先IDへの更新になっているか調べる。
SSOでログインし、同じユーザーIDのアカウントと元のデータへ到達できることを確認する。

例えば、SSOのNameIDがaoi@example.comで、利用先のuserNameも同じなら、その値を照合に利用できる場合があります。しかしNameIDとSCIMのid・externalId・userNameに、規格上の自動的な同一関係はありません。OIDCのsubも同様です。SSOが参照するアカウントとSCIMが更新するアカウントが一致するよう、製品ごとの設定で結び付けます。

一致がゼロ件なら新規作成が試みられ、重複アカウントができることがあります。複数件一致ならエラーや予期しない紐付けの原因になります。誤紐付けは別人のデータへのアクセスにつながるため、メールアドレスの再利用も検討します。作成か更新かをログで区別し、重複に気付いたら同期範囲の拡大を止めます。

マッチング条件や優先順位、最初の照合後に保持する対応関係は製品依存です。例えばEntra IDでは照合属性と優先順位を設定できますが、相手APIがその属性のフィルター検索に対応する必要があります。

既存データは保持できるか

同じ既存アカウントを継続利用できれば、紐付いたデータを保持できる場合が多いものの、保証はできません。SCIMはファイルやチャット履歴を移行する規格ではなく、属性更新や所属変更が権限に影響する場合もあります。

対象	導入前後で比較するもの
ユーザーID	アプリ内部のIDが同じか
ファイル	所有者、共有設定、閲覧・編集可否
チャット・投稿履歴	履歴と投稿者の対応
ユーザー設定	個人設定や通知設定
グループ所属	手動所属と同期所属の差分
アクセス権限	ロール、個別権限、旧部署の権限
監査ログ	過去の操作と同じ主体として追跡できるか、保存期間

削除や再作成ではデータや履歴の参照関係が変わることがあります。アプリのバックアップ・エクスポート機能と復旧手順、退職時の所有権移管を事前に確認します。

導入時の注意事項

項目	確認・対策
既存アカウントとのマッチング	検索可能な一意属性と既存IDを照合
重複アカウントの作成	ログで作成・更新を区別し、JITとの競合も試験
属性の上書き	正本と管理対象属性を決め、空値や変換の影響を確認
既存権限の変更	ロール・ライセンス割当への影響と旧権限の除去を確認
グループの同期	作成、所属追加・削除、手動設定との競合を確認
同期対象外ユーザーの無効化	対象から外した時の処理を確認。絞り込み変更も影響する
管理者アカウントの保護	緊急管理者を一括無効化に巻き込まない設計と監視
SSOとの識別子の整合性	認証と管理が同じ利用先ユーザーに到達するか確認
ライセンス制限	ID基盤と利用先の双方でAPI・SSO・同期機能の条件を確認
同期タイミング	初回・差分の間隔、失敗時の再試行、停止期限を確認
セッション失効	無効化後のブラウザ・モバイル・長期セッションを実測
APIトークンの扱い	同期用資格情報の保管・最小権限・更新と、利用者の個人トークンの失効を別途管理
製品ごとの仕様差	PATCH、グループ、削除、復元、監査機能の対応を確認

推奨する導入手順

対応状況を確認する。 SCIMの機能、対象リソース、ネットワーク、ライセンス、接続資格情報を確認する。
既存アカウントを棚卸しする。 管理者、休眠ユーザー、ゲスト、サービス用アカウントも分類する。
属性とマッチング条件を設計する。 正本、一意性、改姓・再雇用時の識別を決める。
属性マッピングを確認する。 作成時だけか毎回更新か、空値・部署・役割の変換も確認する。
無効化・削除動作を確認する。 割当解除、対象外、退職、復職を試し、復旧可能な範囲を整理する。
緊急管理者を確保する。 通常のSSOや同期障害から復旧できる手段を保護し、試験する。
少数ユーザーで検証する。 既存・新規・改姓・無効化を含むテストを行い、必要ならJITとの競合も調べる。
既存データと権限を比較する。 内部ID、ファイル、履歴、所属、監査ログを導入前後で照合する。
段階的に対象を拡大する。 変更内容とエラーを確認してから部署・人数を増やす。異常時は同期を止め、影響を調査する。
本番運用と監視を整える。 資格情報の期限、同期失敗、想定外の大量変更を監視し、定期的に棚卸しする。

同期を止めても、すでに実施された変更が元に戻るとは限りません。段階展開の前に、属性・権限の復元方法やデータ復旧の可否を確認しておきます。

Microsoft Entra IDのオンデマンドプロビジョニング例

これは製品固有の検証機能であり、SCIM規格そのものの機能ではありません。対応するアプリでは、Entra管理センターの対象エンタープライズアプリケーションでプロビジョニングを設定し、オンデマンドプロビジョニングからテストユーザーを選んで処理を実行できます。

例えば、既存ポータルのユーザーを選び、取り込み、対象範囲の評価、利用先との照合、属性の反映結果を確認します。「既存ユーザーへの更新」になったか、利用先IDが変わっていないかを調べます。これは実際の書き込みを伴うため、検証対象と変更属性を限定します。

オンデマンドの成功だけで、定期同期やグループ、退職処理の検証を済ませないでください。利用条件や制限は公式資料と対象コネクターの手順で確認します。

トラブルシューティング

症状	調査の起点
重複ユーザーができた	照合値、空値、フィルター対応、SSO/JITとの作成競合
更新されない	割当・対象範囲、属性マッピング、最終成功時刻、同期ログ
401・403エラー	トークンの期限、権限、テナント・エンドポイントの誤り
409・属性検証エラー	一意性の衝突、必須属性、利用先の文字・形式制限
グループや権限が違う	グループ同期への対応、手動設定との競合、アプリ側の役割変換
退職者がまだ操作できる	無効化の到達と効果、既存セッション、別ログイン、個人トークン
大量変更が止まらない	対象範囲・正本・変換式を確認し、拡大を中断して影響を特定

エラーログには個人情報や資格情報が含まれる可能性があります。調査に必要な範囲で扱い、トークンを共有資料に貼らないようにします。

まとめ

SCIMはアカウント管理の自動化に役立ちます。既存SSO環境への追加では、既存ユーザーとのマッチング、属性の管理主体、無効化の効果を先に確認し、同じユーザーIDとデータを維持できることを少数の利用者で検証してから広げます。

関連する基盤の整理にはオンプレミスActive Directoryの見直しも参照してください。