Microsoft Entra SCIM 2.0 APIの重要点は、Microsoft Entra IDを「SCIMの送信側」だけでなく「SCIMの受け皿」として扱えるようになったことです。つまり、HRシステム、IDガバナンス基盤、SaaS、独自の自動化ツールから、標準のSCIM 2.0プロトコルでMicrosoft Entra内のユーザーとグループを作成・更新・削除しやすくなります。
2026年4月16日時点で押さえるべき更新は、Microsoft EntraのSCIM 2.0 APIsがProvisioning / Identity Lifecycle Management向けの一般提供機能として整理された点です。MicrosoftのMarch 2026 roundupでも、Microsoft Entra ID Governanceの新リリースとして「SCIM 2.0 APIs for Microsoft Entra ID」が掲載されています。(Microsoft Learn)
IAMエンジニアにとっては、入社・異動・退職に伴うIDライフサイクル管理をSCIM中心で標準化しやすくなります。連携開発者にとっては、Microsoft Graph専用の実装に寄せすぎず、既存のSCIMクライアントやプロビジョニングフレームワークをMicrosoft Entra連携にも再利用しやすくなるのが大きな価値です。
Microsoft Entra ID Governance / SCIMの最新動向：SCIM 2.0 APIsがIDライフサイクル運用で重要な理由
Microsoft Entraは以前から、SaaSアプリに対してユーザーやグループをプロビジョニングするSCIMクライアントとして使われてきました。今回のSCIM 2.0 APIsで重要なのは、Microsoft Entra IDがSCIMサービスプロバイダー、つまりSCIMサーバーとしても機能し、外部システムからMicrosoft Entraへユーザーとグループを直接プロビジョニングできる選択肢が明確になった点です。(Microsoft Learn)
Microsoft公式ブログでは、外部のSCIM互換IDソースがMicrosoft Entraに対してユーザーとグループを直接プロビジョニングできるようになり、オーケストレーションツールやカスタム自動化フレームワークから標準SCIM操作を使えると説明されています。Microsoft Entra public cloudでは一般提供となり、Microsoft Entra ID for US Governmentでは2026年6月末までに利用可能になる予定です。(TECHCOMMUNITY.MICROSOFT.COM)
この変化は、単なるAPI追加ではありません。ID管理の設計上、「Microsoft Entraだけ特別扱いする」実装から、「SCIMという共通モデルで複数のID基盤やSaaSを扱う」実装へ寄せやすくなるためです。
まず理解すべき全体像：EntraはSCIMクライアントにもSCIMサーバーにもなる
Microsoft Entra IDのSCIM対応は、方向によって意味が変わります。ここを混同すると、導入判断を誤ります。
| シナリオ | Microsoft Entraの役割 | 主な用途 | 向いている読者 |
|---|---|---|---|
| Microsoft EntraからSaaSへプロビジョニング | SCIMクライアント | ServiceNow、Zoom、Dropboxなどのアプリにユーザーやグループを作成・更新・プロビジョニング解除する | IAM管理者、SaaS管理者 |
| 外部システムからMicrosoft Entraへプロビジョニング | SCIMサービスプロバイダー | HRシステム、IDプラットフォーム、パートナー基盤、独自パイプラインからEntraへユーザーやグループを同期する | IAMエンジニア、統合開発者、IGA担当者 |
| Microsoft固有機能まで深く操作 | Microsoft Graph APIの利用先 | ユーザー・グループ以外のMicrosoft 365、セキュリティ、詳細なディレクトリ操作を扱う | アプリ開発者、プラットフォームエンジニア |
Microsoftのドキュメントでも、SCIMはユーザーとグループのライフサイクル管理を標準化したい場合、Microsoft Graphはより広範なMicrosoft固有機能を扱いたい場合に適すると整理されています。両者は排他ではなく、SCIMをライフサイクル同期に使い、GraphをMicrosoft固有の拡張処理に使う設計が現実的です。(Microsoft Learn)
何ができるようになるのか
Microsoft Entra SCIM 2.0 APIsでは、外部のSCIMクライアントからMicrosoft Entra内のユーザーとグループを管理できます。MicrosoftのAPIリファレンスでは、SCIM APIのベースURLはhttps://graph.microsoft.com/rp/scimで、/usersと/groupsはGET、POST、PATCH、DELETEをサポートするとされています。/serviceproviderconfig、/resourcetypes、/schemasも用意されており、対応する機能やスキーマを標準的なSCIMの形で確認できます。 (Microsoft Learn)
代表的な操作は次のとおりです。
| 操作 | できること | 実務での使いどころ |
|---|---|---|
| ユーザー作成 | 外部HRやID基盤の情報をもとにEntraユーザーを作成 | 入社予定者の事前登録、パートナー企業ユーザーの作成 |
| ユーザー更新 | 氏名、部署、ライフサイクル属性、カスタムセキュリティ属性などを更新 | 異動、組織変更、ロール変更 |
| ユーザー無効化・削除 | active属性や削除操作を使ってアカウント状態を制御 | 退職、契約終了、アクセス停止 |
| グループ作成 | セキュリティグループやMicrosoft 365グループを作成 | 部門・職種・プロジェクト単位のアクセス制御 |
| グループメンバー管理 | ユーザーの所属や権限の土台になるグループメンバーシップを更新 | ロールベースアクセス、アプリ割り当て、ライセンス連動 |
| スキーマ・機能検出 | 対応属性、リソースタイプ、サービスプロバイダー構成を確認 | コネクタ開発、互換性チェック、テナント差分確認 |
特に重要なのは、/schemasや/serviceproviderconfigを使って、クライアント側が対応機能を事前に確認できることです。固定の前提で実装するより、サービス側の対応状況を検出して処理を分岐できるため、複数テナント・複数顧客向けの連携では保守性が上がります。
IAMエンジニアにとっての価値：Joiner、Mover、Leaverを標準化しやすい
IDプロビジョニングで最も失敗しやすいのは、入社時の作成処理ではなく、異動・休職・退職・再雇用のような状態変化です。SCIM 2.0 APIsは、このライフサイクルイベントをMicrosoft Entraへ届ける標準的な入口として使えます。
たとえば、次のような流れを設計できます。
| ライフサイクルイベント | 外部システム側の変化 | SCIMでEntraへ反映する内容 | 注意点 |
|---|---|---|---|
| 入社 | HRシステムに新しい従業員が登録される | ユーザー作成、初期属性設定、基本グループ追加 | userName、氏名、displayName、mailNicknameなど必須属性を事前に用意する |
| 異動 | 部署、上長、職務コードが変わる | 属性更新、グループ追加・削除 | グループ更新はまとめ方に制約があるため、差分計算が重要 |
| 休職 | 就業ステータスが一時停止になる | アカウント無効化、特定グループから削除 | 無効化と削除を混同しない |
| 退職 | 雇用終了日が到来する | active更新、アクセスグループ削除、必要に応じて削除 | 監査・保持・再雇用ポリシーと合わせて設計する |
| 再雇用 | 過去ユーザーが再び有効になる | 既存IDの確認、属性更新、再有効化 | 新規作成と復帰処理を分ける |
Microsoftのリファレンスでは、ユーザー作成にuserName、password、name.familyName、name.givenName、active、displayName、Microsoft Entra拡張のmailNicknameが必要とされています。また、グループ作成ではdisplayNameが必須です。実装前に「ソースシステム側で必須属性を必ず持てるか」を確認しないと、作成処理が途中で失敗します。(Microsoft Learn)
連携開発者にとっての価値：Microsoft Graph専用実装を減らせる
連携開発者にとってのメリットは、Microsoft EntraだけのためにすべてをMicrosoft Graph前提で作り込まなくてもよい点です。SCIM 2.0に対応済みのIDガバナンス製品、ミドルウェア、社内プロビジョニング基盤がある場合、既存のSCIMクライアントをMicrosoft Entra連携にも使える可能性があります。
これは、特に次のようなケースで効きます。
| ケース | SCIM 2.0 APIsが向く理由 |
|---|---|
| 複数のSaaSとMicrosoft Entraを同じIDライフサイクル基盤で管理したい | SCIMベースの共通パターンを使い回せる |
| パートナーが顧客テナントへIDをプロビジョニングしたい | Microsoft EntraをSCIMサービスプロバイダーとして扱える |
| 既存のIGA製品や自動化基盤がSCIMクライアントを持っている | コネクタ開発の差分を小さくできる |
| Microsoft固有機能までは不要で、ユーザー・グループ管理が中心 | Graphより目的が絞られた標準プロトコルで実装できる |
| グローバル展開でテナントや地域が増える | スキーマ検出と標準操作により、実装のばらつきを抑えやすい |
ただし、SCIMはMicrosoft Graphの完全な代替ではありません。認証方法、条件付きアクセス、Microsoft 365の詳細リソース、TeamsやSharePointなどの深い操作まで扱うならGraphが必要です。SCIMは「IDライフサイクルの標準入口」として位置付けるのが現実的です。
導入前に確認すべき前提条件
SCIM Provisioning APIは、単にエンドポイントへHTTPリクエストを送れば使える機能ではありません。Microsoft Learnでは、Entra ID P1またはそれを含むライセンス、課金用にリンクするAzureサブスクリプション、必要なアプリ登録を作成する管理者ロール、課金を有効化するBilling Administratorロールが前提条件として示されています。(Microsoft Learn)
導入前に、最低限次の確認をしておきましょう。
| 確認項目 | 見るべきポイント | 見落とすと起きること |
|---|---|---|
| ライセンス | Entra ID P1相当以上を満たすか | 機能を有効化できない、または本番展開でライセンス確認が止まる |
| 課金 | Azureサブスクリプションとリソースグループをリンクできるか | API呼び出し料金の管理先が決まらない |
| 管理者ロール | アプリ登録、API権限、課金設定を行える担当者がいるか | 技術検証は進んでも有効化で止まる |
| 認証方式 | クライアントシークレット、証明書、フェデレーション資格情報、マネージドIDのどれを使うか | 秘密情報の管理が属人化する |
| ソースオブトゥルース | HR、既存IdP、IGA、社内DBのどれが正とするか | Entra Connectや他の同期処理と競合する |
| コスト監視 | Azure Cost Managementで月次の使用量を見られるか | 検証用ジョブの暴走や再試行で予期しない課金が発生する |
Microsoft Learnでは、SCIM APIはアプリケーションコンテキスト、つまりアプリ専用トークンでのみ動作し、委任されたユーザー代理シナリオはサポートしないとされています。運用環境では、クライアントシークレットよりもクライアント証明書やマネージドIDの利用を優先して検討すべきです。(Microsoft Learn)
実装の基本手順
SCIM 2.0 APIsをいきなり本番の入退社処理に接続するのは危険です。まずは検証テナントまたは限定スコープで、次の順序で進めるのが安全です。
ユースケースを1つに絞る
最初の対象は「入社者のユーザー作成」または「特定グループへのメンバー追加」など、失敗時の影響が限定しやすいものにします。いきなり退職処理や全社グループ同期を始めると、誤った属性マッピングや差分計算のミスが大きな障害になります。
SCIM Provisioning APIを有効化する
Microsoft Entra管理センターでID GovernanceのダッシュボードからSCIM Provisioning APIタイルを選び、Azureサブスクリプションとリソースグループをリンクして有効化します。Microsoft Learnでは、すべてのSCIM Provisioning API呼び出しが課金対象になると説明されています。(Microsoft Learn)
アプリ登録またはマネージドIDを用意する
SCIMクライアントが使う認証情報を用意します。アプリ登録を使う場合は、Microsoft Graphのアプリケーション権限を付与し、管理者の同意を行います。ユーザー読み取り、ユーザー書き込み、グループ読み取り、グループ書き込み、カスタムセキュリティ属性、ライフサイクル属性など、用途に応じて権限を選びます。(Microsoft Learn)
ここで重要なのは、最初から広すぎる権限を付けないことです。たとえば、アカウントの有効・無効だけを扱う処理なら、いきなり全ユーザーのフル書き込み権限を与えるのではなく、必要な最小権限で実現できるかを検討します。
まずは検出系APIを呼ぶ
最初に呼ぶべきは、作成や更新ではありません。/serviceproviderconfig、/schemas、/resourcetypesで、利用可能な機能、スキーマ、リソースタイプを確認します。
GET https://graph.microsoft.com/rp/scim/serviceproviderconfig
Authorization: Bearer <access_token>
Accept: application/jsonMicrosoft Learnの例では、serviceproviderconfigの応答にページネーション、PATCHサポート、フィルター対応、Bulk非対応などが含まれます。Bulkがサポートされない前提で、クライアント側はバッチ処理、再試行、差分処理を自前で丁寧に設計する必要があります。(Microsoft Learn)
属性マッピングを決める
SCIMの属性とMicrosoft Entra側の属性は、1対1で機械的に決まるとは限りません。たとえば、userNameをメールアドレスにするのか、従業員番号ベースにするのか、externalIdをどのシステムのIDにするのかで、後の照合・再実行・再雇用処理の難易度が変わります。
実務では、次の3つを必ず決めておきます。
| 決めること | 推奨される考え方 |
|---|---|
| 一意キー | HRやIGA側で変わりにくいIDをexternalIdに置く。メールアドレス変更に耐えられる設計にする |
| 表示名・氏名 | 監査ログ、人事表記、グローバル表記のどれに合わせるかを決める |
| グループ付与条件 | 部署コード、職務コード、勤務地、雇用形態など、条件の優先順位を明文化する |
小さな更新から本番に近づける
最初の本番相当テストでは、読み取り、ユーザー1件作成、属性1件更新、グループ1件追加、無効化の順に試します。成功したら、再実行時に同じ結果になるか、重複作成されないか、失敗時にどこから再開できるかを確認します。
実装時にハマりやすい制約
SCIM 2.0という標準に沿っていても、Microsoft Entra側の実装には制約があります。リファレンスに書かれている制約を先に実装へ反映しておくと、運用開始後のトラブルを大きく減らせます。
フィルター条件を過信しない
ユーザー一覧やグループ一覧ではフィルターを使えますが、利用できる論理演算子や対象属性には制約があります。Microsoft Entra ID SCIM APIリファレンスでは、ユーザーフィルターの論理演算子はandのみで、eqやewに使える属性も限定されています。また、クエリ文字列内の=周辺に不要な空白があるとBadRequestになると説明されています。(Microsoft Learn)
検索条件を柔軟に組み立てる汎用SCIMクライアントをそのまま接続すると、想定外のフィルターを発行してエラーになる可能性があります。Microsoft Entra向けには、対応済みフィルターだけを生成するアダプター層を用意したほうが安全です。
ページングはcursor前提で実装する
複数ページの結果はcursor-based paginationで取得します。ページ番号やオフセットで巡回する前提にすると、データ量が増えたときに取りこぼしや重複取得が起きやすくなります。nextCursorが返る場合は、次のリクエストでcursorとして渡す実装にします。(Microsoft Learn)
グループメンバー更新はまとめ方に注意する
グループ更新では、メンバー追加・削除のまとめ方に制約があります。Microsoftのリファレンスでは、複数メンバーの追加は1リクエストで最大20人、削除はPATCH呼び出しごとに1人、追加と削除や他の属性変更を同じPATCHに混在させないことなどが示されています。(Microsoft Learn)
つまり、数千人規模のグループ同期を単純な「全差し替え」で実装すると、API呼び出し数、課金、スロットリング、失敗時の復旧が問題になります。差分を計算し、追加と削除を分け、失敗した単位を再実行できるようにしておくべきです。
401、403、400、404を切り分けられるログを残す
SCIM APIのエラーは、原因によって対処が変わります。Microsoft Learnのトラブルシューティングでは、401は認証トークン、403はAPI権限や管理者同意、404は存在しないユーザーまたはグループID、400はペイロードやクエリパラメーターの制約違反が主な原因として整理されています。(Microsoft Learn)
運用ログには、少なくとも次の情報を残します。
| ログ項目 | 目的 |
|---|---|
| 相関IDまたはジョブID | どのライフサイクルイベントから発生した処理か追跡する |
| SCIM操作種別 | GET、POST、PATCH、DELETEのどれで失敗したか分かるようにする |
| 対象ID | externalId、Entra object ID、グループIDを切り分ける |
| HTTPステータス | 認証・権限・スキーマ・存在確認のどれかを初期判断する |
| リクエストの要約 | 個人情報や秘密情報を除いた属性名・操作内容を残す |
| 再試行結果 | 一時的な失敗か恒久的なデータ不備か判断する |
課金とコスト設計：API呼び出し数を設計に入れる
SCIM Provisioning APIは有料アドオンで、Azureサブスクリプションを通じて月次課金されます。Azureの価格ページでは、Microsoft Entra SCIM APIsは利用量ベースの価格モデルで、APIリクエスト数に基づいて課金されると説明されています。また、2xx応答または404応答になったSCIM APIリクエストが課金対象トランザクションとされ、PATCHは複数操作を含んでいても1リクエストとして課金されます。(マイクロソフトAzure)
コストを抑えるには、次の設計が重要です。
| コストに効く設計 | 理由 |
|---|---|
| 差分同期にする | 毎回全ユーザー・全グループを更新すると呼び出し数が増える |
| 事前バリデーションを行う | 必須属性不足のままAPIを呼ばない |
| グループ更新を計画的に分割する | 制約違反による再実行を減らす |
| 無駄なポーリングを避ける | イベント駆動または変更検知で呼び出しを減らす |
| 検証環境のジョブを停止管理する | テスト用バッチの放置による課金を防ぐ |
| Cost Managementで監視する | 月中の累積コストと予測を確認できる |
特に連携開発者は、リトライ処理の設計に注意が必要です。429や一時的な失敗に対して再試行するのは必要ですが、権限不足や必須属性不足のような恒久エラーまで無限に再試行すると、ログもコストも膨らみます。
SCIM、API-driven provisioning、Microsoft Graphの使い分け
Microsoft Learnでは、SCIM Provisioning APIはSCIM APIへの直接プログラムアクセスを目的とする機能であり、Entra IDの組み込みアプリプロビジョニング、HR-driven provisioning、API-driven provisioningを使う場合は有効化不要と説明されています。(Microsoft Learn)
迷った場合は、次のように判断すると分かりやすいです。
| やりたいこと | 選ぶべき候補 | 判断基準 |
|---|---|---|
| EntraからSaaSアプリへユーザーを同期したい | 組み込みのアプリプロビジョニング | 既存ギャラリーアプリやSaaS向けの標準連携が目的 |
| HRデータをEntraへ取り込みたいが、Microsoftの既存機能で足りる | HR-driven provisioningまたはAPI-driven provisioning | 直接SCIMサーバーとしてEntraを公開する必要がない |
| 外部SCIMクライアントからEntraを操作したい | SCIM Provisioning API | 既存のSCIMクライアント、IGA、ミドルウェアを再利用したい |
| Microsoft 365やEntraの広い機能まで制御したい | Microsoft Graph API | ユーザー・グループのライフサイクル管理を超える操作が必要 |
| 複数方式を組み合わせたい | SCIM＋Graph | SCIMで標準同期、GraphでMicrosoft固有の後処理を行う |
独自性のある設計観点としては、「どのAPIが高機能か」ではなく「どの境界を標準化したいか」で選ぶことが重要です。Microsoft Entraを含めたIDライフサイクルの入口をSCIMにそろえるならSCIM 2.0 APIs、Microsoft特有の管理面を深く自動化するならGraph、管理画面ベースで十分なら組み込みプロビジョニングを選びます。
グローバル展開で注意したいポイント
グローバル企業や多国籍SaaSベンダーでは、SCIM 2.0 APIsの価値がさらに大きくなります。理由は、国・地域・事業部ごとに異なるIDソースを持っていても、Microsoft Entraへのプロビジョニング境界をSCIMに寄せられるためです。
ただし、グローバル展開では次の点を早めに決めてください。
| 論点 | 実務上の判断基準 |
|---|---|
| ユーザー名の形式 | メールアドレス変更に耐えるか、国別ドメインをどう扱うか |
| 氏名表記 | 姓名順、ミドルネーム、ローカル文字、英字表記をどう格納するか |
| 雇用形態 | 正社員、契約社員、派遣、外部パートナーを属性で区別できるか |
| グループ設計 | 部門グループ、アプリ権限グループ、ライセンスグループを混在させない |
| 監査 | どのシステムが、いつ、どの属性を変更したか追えるか |
| データ削除 | 退職時に削除するのか、無効化して保持するのか、地域ごとの規程に合うか |
| フェイルセーフ | ソースシステム障害時に大量無効化を防ぐ仕組みがあるか |
特に危険なのは、HR側の一時的なデータ欠損を「退職」と誤判定して、ユーザー無効化やグループ削除を大量実行してしまうことです。退職処理や大規模なグループ削除には、しきい値チェック、承認、ドライラン、ロールバック手順を必ず用意しましょう。
導入判断のチェックリスト
SCIM 2.0 APIsを使うべきか迷う場合は、次の質問に答えてください。
| 質問 | Yesなら |
|---|---|
| 既存のSCIMクライアントやIGA基盤を持っているか | SCIM Provisioning APIを検証する価値が高い |
| Microsoft Entraへ外部システムから直接ユーザー・グループを作りたいか | SCIMサービスプロバイダーとしての利用が合う |
| ユーザー・グループのライフサイクル管理が主目的か | SCIM向き |
| Microsoft 365全体の細かい操作まで必要か | Graph併用を前提にする |
| API呼び出し数を見積もれるか | 課金設計に進める |
| 属性のソースオブトゥルースが明確か | 本番化に進みやすい |
| 失敗時の再実行・ロールバックを設計できるか | 自動化の信頼性を高められる |
反対に、SaaSアプリへの一般的なユーザープロビジョニングだけが目的なら、まずMicrosoft Entraの組み込みアプリプロビジョニングを確認するほうが近道です。SCIM 2.0 APIsは、外部のSCIM互換システムからMicrosoft Entraを管理したい場合に真価を発揮します。
まず取るべき次のアクション
Microsoft Entra SCIM 2.0 APIは、IDプロビジョニング自動化と相互運用性を高める実用的な選択肢です。ただし、導入の成否はAPIそのものではなく、属性設計、権限設計、差分同期、課金監視、エラー処理で決まります。
最初にやるべきことは、次の3つです。
- 既存のIDライフサイクル処理を棚卸しし、Entraへ入れるべきユーザー・グループ変更を洗い出す
- SCIMで標準化する範囲と、Microsoft Graphで補完する範囲を分ける
- 検証テナントで
/serviceproviderconfig、ユーザー1件作成、属性更新、グループメンバー更新、無効化までを小さく試す
SCIM 2.0 APIsを「新しいAPI」として見るだけでは、効果は限定的です。HR、IGA、SaaS、社内自動化基盤をつなぐIDライフサイクルの共通インターフェースとして設計すると、Microsoft Entraを中心にしたプロビジョニング運用をより安全に、再利用しやすくできます。
コメント