Azure DatabricksでMicrosoft Entra ID（旧Azure Active Directory）からユーザーやグループを同期する場合、2026年4月22日に更新された公式ドキュメントでまず確認すべき結論は、SCIM provisioningを設定する前に、Automatic identity managementを使うべきか判断することです。SCIMは現在も有効な選択肢ですが、ネストされたグループやサービスプリンシパルの同期には対応していません。新規構築や大規模な権限管理では、従来どおりSCIMを設定するだけでなく、ID管理方式そのものを見直す必要があります。(Microsoft Learn)
この記事では、Azure Databricksの「Configure SCIM provisioning using Microsoft Entra ID (Azure Active Directory)」の2026年4月更新ポイントを、security admins、identity teams、compliance teams向けに整理します。設定手順だけでなく、採用判断、移行時の注意点、よくある失敗、監査で確認すべき観点まで実務目線で解説します。
Azure Databricksの2026年4月更新ポイントで重要なこと
2026年4月22日更新のMicrosoft Learnでは、Azure Databricksアカウントに対してMicrosoft Entra IDからSCIM provisioningを設定する手順が説明されています。あわせて、Automatic identity managementという別方式が明確に案内されており、これはMicrosoft Entra ID側で専用アプリケーションを構成せずに、ユーザー、グループ、サービスプリンシパルをAzure Databricksへ同期できる仕組みです。(Microsoft Learn)
実務上の読みどころは、次の5点です。
| 更新ポイント | 実務での意味 | 取るべき対応 |
|---|---|---|
| Automatic identity managementが重要な選択肢になっている | SCIMだけを前提に設計すると、ネストグループやサービスプリンシパル管理で制約が出る | 新規構築ではSCIMとAutomatic identity managementを比較してから方式を決める |
| 2025年8月1日より後に作成されたアカウントではAutomatic identity managementが既定で有効 | 新しいDatabricks環境では、SCIMアプリを作る前に既定状態を確認する必要がある | Account consoleのUser provisioning設定を確認する |
| アカウントレベルSCIMが推奨される | ワークスペースごとのSCIMはレガシー寄りの設計になりやすい | 既存のworkspace-level SCIM connectorがある場合は移行計画を作る |
| SCIMではネストグループとサービスプリンシパルの自動同期に非対応 | グループ階層が複雑な企業やM2M認証が多い環境では運用負荷が増える | 親子グループ構造、SP利用状況、Terraform/API利用を事前に棚卸しする |
| Microsoft Entra ID SCIM provisioning connectorはAzure Chinaリージョンで利用不可 | グローバル展開では地域差を前提に設計する必要がある | 中国リージョン利用時は公式制約を確認し、代替運用を検討する |
ここで重要なのは、「SCIMの設定方法を知る」だけでは不十分という点です。Azure Databricksを全社利用する場合、ID同期方式はセキュリティ、退職者対応、監査証跡、データアクセス権限に直結します。特にUnity Catalog、ワークスペース割り当て、ジョブ実行用サービスプリンシパルを使う組織では、ID管理方式の選定ミスが後から大きな移行コストになります。
SCIM provisioningは何をする仕組みか
SCIM provisioningは、Microsoft Entra IDなどのIdPを起点に、Azure Databricks上のユーザーやグループを作成、更新、無効化するための仕組みです。認証そのものを行う機能ではなく、IDのライフサイクル管理を自動化するための機能です。Azure Databricksの認証はMicrosoft Entra IDによるOpenID Connectのフローで処理され、SCIM provisioningとは別の領域として扱われます。(Microsoft Learn)
たとえば、社員が入社したらMicrosoft Entra IDのグループに追加され、Azure Databricksアカウントにもユーザーが作成されます。異動によりグループが変われば、Databricks側のアクセス範囲もグループ設計に応じて変わります。退職や契約終了で対象から外れれば、Databricks側のアクセスも無効化できます。
ただし、SCIMを「ログイン許可の設定」とだけ捉えると設計を誤ります。実際には、次のような運用全体に影響します。
- どのユーザーをDatabricksアカウントに同期するか
- どのグループをワークスペースやUnity Catalog権限に使うか
- 退職者・異動者の無効化をどこで起点管理するか
- 手動で追加したユーザーや権限をどう扱うか
- 既存のworkspace-level SCIM connectorを残すか廃止するか
特に大規模環境では、「誰がDatabricksに存在するか」よりも「誰がどの権限を、どの根拠で持っているか」を説明できる設計が重要です。
SCIMとAutomatic identity managementの違い
2026年4月時点で、Azure DatabricksのID同期は大きく分けてSCIM provisioningとAutomatic identity managementの2つを比較して考える必要があります。Microsoft Learnでは、Automatic identity managementはMicrosoft Entra IDアプリケーションを構成せずにユーザー、サービスプリンシパル、グループをAzure Databricksへ同期でき、SCIMでは非対応のネストグループやサービスプリンシパル同期にも対応すると説明されています。(Microsoft Learn)
| 判断軸 | SCIM provisioning | Automatic identity management |
|---|---|---|
| Microsoft Entra ID側の専用アプリ | 必要 | 不要 |
| ユーザー同期 | 対応 | 対応 |
| グループ同期 | 対応。ただし直接メンバー中心 | 対応 |
| ネストグループ | 非対応 | 対応 |
| サービスプリンシパル | 非対応 | 対応 |
| Microsoft Entra ID管理者ロール | Cloud Application Administratorが必要 | 専用のEntraアプリ構成は不要 |
| 新規アカウントでの扱い | 手動構成が必要 | 2025年8月1日より後に作成されたアカウントでは既定で有効 |
| 向いているケース | 既存のSCIM運用、明示的なアプリ割り当て、クロステナント要件 | 新規構築、ネストグループ活用、サービスプリンシパル管理、運用簡素化 |
DatabricksはAutomatic identity managementの利用を推奨しています。ただし、すべての環境で無条件にAutomatic identity managementを選べばよいわけではありません。Automatic identity managementはidentity federationが有効なワークスペースで使う前提があり、クロステナントのMicrosoft Entra IDディレクトリには対応しません。クロステナントのID管理が必要な場合は、Microsoft Entra B2B collaborationを組み合わせたSCIM provisioningが選択肢になります。(Microsoft Learn)
SCIMを選ぶべきケース
SCIM provisioningは、次のような環境では引き続き有力です。
| ケース | 理由 |
|---|---|
| 既存のMicrosoft Entra ID provisioning運用に統合したい | エンタープライズアプリケーション単位で割り当て、ログ、承認フローを管理しやすい |
| クロステナントのID管理が必要 | Automatic identity managementではクロステナントEntra IDディレクトリがサポートされない |
| 同期対象を明示的に絞りたい | SCIMアプリに割り当てたユーザー・グループを中心にスコープ管理しやすい |
| 既存の監査手順がSCIMアプリ前提で整備されている | 変更管理や証跡レビューを維持しやすい |
Automatic identity managementを優先すべきケース
一方で、次のような環境ではAutomatic identity managementを優先して検討する価値があります。
| ケース | 理由 |
|---|---|
| 新規にAzure Databricksを展開する | 専用SCIMアプリを作らずにID同期を開始できる |
| ネストされたグループを権限設計に使っている | SCIMではネストグループの自動同期に対応しない |
| サービスプリンシパルをジョブやAPI実行で使う | SCIM connectorではサービスプリンシパルの同期に対応しない |
| ID運用をMicrosoft Entra ID中心に単純化したい | Azure Databricks側でEntra IDをsource of recordとして扱いやすい |
注意したいのは、SCIMとAutomatic identity managementを安易に混在させることです。Microsoft Learnでは、同じIDをAutomatic identity managementとSCIM provisioningの両方で追加すると、重複エントリや権限競合が発生する可能性があると説明されています。既存SCIM環境から移行する場合は、どちらを正とするかを決め、段階的に整理する必要があります。(Microsoft Learn)
SCIM provisioning設定前に確認すべき前提条件
Azure DatabricksでSCIM provisioningを設定する前に、管理者権限とライセンス条件を確認します。公式ドキュメントでは、Azure Databricks Premium plan、Azure Databricks account admin、Microsoft Entra IDのCloud Application Administratorロールが必要です。また、グループをプロビジョニングするにはMicrosoft Entra ID Premium editionが必要で、ユーザーのプロビジョニングはMicrosoft Entra IDの任意のエディションで利用できます。(Microsoft Learn)
| 確認項目 | 必要な内容 | 見落とすと起きる問題 |
|---|---|---|
| Azure Databricksプラン | Premium plan | SCIM設定に進めない |
| Databricks管理者権限 | Account admin | Account consoleでUser provisioningを設定できない |
| Microsoft Entra ID権限 | Cloud Application Administrator | Enterprise applicationの作成・構成ができない |
| Microsoft Entra ID edition | グループ同期にはPremium editionが必要 | ユーザーは同期できてもグループ同期で詰まる |
| 既存SCIM connector | workspace-level connectorの有無を確認 | account-level SCIMと二重管理になる |
| identity federation | ワークスペース割り当てを一元管理する場合に重要 | アカウントレベルのID管理とワークスペース権限設計が分断される |
特に確認すべきなのは、既存のworkspace-level SCIM connectorです。公式ドキュメントでは、account-level SCIM connectorを有効にする場合、ワークスペースへ直接IDを同期している既存SCIM connectorは無効化する必要があると説明されています。残したまま移行すると、同じユーザーやグループが複数経路で管理され、権限レビューが難しくなります。(Microsoft Learn)
Microsoft Entra IDでAzure Databricks SCIM provisioningを設定する手順
SCIM provisioningの設定は、大きく分けてAzure Databricks側でSCIM URLとトークンを取得し、Microsoft Entra ID側のEnterprise applicationに登録する流れです。公式手順では、Azure Databricks account consoleのSecurityからUser provisioningを開き、Set up user provisioningでSCIM tokenとAccount SCIM URLを取得します。このSCIM tokenはAccount SCIM API専用で、他のDatabricks REST APIの認証には使えません。(Microsoft Learn)
| 手順 | 作業場所 | 実施内容 | 確認ポイント |
|---|---|---|---|
| 1 | Azure Databricks account console | Security → User provisioning → Set up user provisioningを開く | Account SCIM URLとSCIM tokenを安全に控える |
| 2 | Azure portal | Microsoft Entra ID → Enterprise Applicationsで新規アプリを追加 | GalleryからAzure Databricks SCIM Provisioning Connectorを選ぶ |
| 3 | Enterprise application | Provisioning ModeをAutomaticに設定 | SCIM API endpoint URLにAccount SCIM URLを入力 |
| 4 | Enterprise application | Secret TokenにDatabricksのSCIM tokenを入力 | Test Connectionで認証確認を行う |
| 5 | Enterprise application | Saveして設定を保存 | エラーが出た場合はURL、token、管理者権限を確認 |
| 6 | Properties | Assignment requiredをNoに設定 | Databricksはこの設定を推奨しているが、社内ポリシーと照合する |
| 7 | Provisioning | Provisioning StatusをOnにする | 初回同期が開始される |
| 8 | Users and groups | 同期対象のユーザー・グループを割り当てる | 数分後にDatabricks account側で存在確認する |
Assignment requiredをNoにする点は、セキュリティ担当者が迷いやすいポイントです。公式ドキュメントでは、すべてのユーザーがAzure Databricksアカウントにサインインできるようにするため、この設定が推奨されています。ただし、実際のデータアクセスはワークスペース割り当て、グループ権限、Unity Catalog権限で制御されるため、単に「Noだから危険」と判断するのではなく、Databricks側の権限設計とセットでレビューする必要があります。(Microsoft Learn)
セキュリティ管理者が押さえるべき設計ポイント
SCIM provisioningは設定作業よりも、運用設計のほうが重要です。特にsecurity adminsやidentity teamsは、次の観点を事前に決めておくと、後からの手戻りを減らせます。
グループは「組織図」ではなく「権限単位」で設計する
Microsoft Entra IDのグループをそのままDatabricksに同期すると、組織変更のたびに権限が揺れやすくなります。たとえば「営業部」「データ分析部」といった組織グループを直接Unity Catalog権限に使うと、異動や兼務のたびに意図しないアクセスが発生する可能性があります。
実務では、次のような権限単位のグループを作るほうが管理しやすくなります。
| グループ例 | 用途 |
|---|---|
| adb-ws-finance-analyst | 財務分析用ワークスペースへのアクセス |
| adb-uc-sales-read | salesカタログへの読み取り権限 |
| adb-job-operators | ジョブ実行・監視担当者 |
| adb-admin-breakglass | 緊急時管理者用。通常運用では最小人数に制限 |
グループ名には、サービス名、対象範囲、権限レベルを含めると、監査時に説明しやすくなります。反対に「Databricks Users」のような広すぎるグループを複数用途で使い回すと、後から誰が何のためにアクセスしているのか分かりにくくなります。
ネストグループを使っている場合はSCIMだけで設計しない
Microsoft Entra IDのSCIM provisioningでは、Azure Databricksへのネストグループの自動プロビジョニングに対応していません。Microsoft Entra IDは、明示的に割り当てられたグループの直接メンバーのみを読み取ってプロビジョニングします。ネストグループを利用する場合は、必要なユーザーを含むグループを明示的に割り当てる、またはAutomatic identity managementの利用を検討する必要があります。(Microsoft Learn)
よくある失敗は、親グループだけをSCIMアプリに割り当てて「子グループのメンバーも同期されるはず」と考えることです。この場合、期待したユーザーがDatabricksに作成されず、ログインできない、権限が付かない、監査対象に出てこないといった問題が起きます。
サービスプリンシパルは別管理を前提にする
Azure DatabricksのSCIM Provisioning Connector applicationは、Microsoft Entra IDサービスプリンシパルの自動プロビジョニングに対応していません。ジョブ、CI/CD、API連携、MLOpsパイプラインでサービスプリンシパルを使う場合は、Automatic identity management、Databricks Terraform provider、Databricks SCIM API、または手動追加のいずれかを設計に含める必要があります。(Microsoft Learn)
特に本番ジョブの所有者を個人ユーザーにしている環境では、退職や異動でジョブ運用が止まるリスクがあります。サービスプリンシパルを使う場合でも、SCIMで自動的に同期されると思い込まず、作成、権限付与、ローテーション、削除の責任分界を決めておくことが重要です。
コンプライアンス担当者が確認すべき監査ポイント
compliance teamsにとって重要なのは、「誰がアクセスできるか」だけでなく、「なぜアクセスできるか」「いつ変更されたか」「削除時に何が起きるか」を説明できることです。
SCIM provisioningを利用する場合、次の証跡を残しておくと監査対応がしやすくなります。
| 監査項目 | 残すべき証跡 | 理由 |
|---|---|---|
| SCIMアプリ設定 | Enterprise applicationの設定内容、プロビジョニング状態 | どの仕組みで同期しているか説明するため |
| 同期対象 | 割り当て済みユーザー・グループ一覧 | Databricksに入る対象の根拠を示すため |
| 権限設計 | グループとワークスペース・Unity Catalog権限の対応表 | データアクセス権限を説明するため |
| 例外管理 | 手動追加ユーザー、break-glass管理者、外部ユーザー | 自動同期外のアクセスを把握するため |
| 退職者対応 | Entra ID側の無効化、グループ削除、Databricks側の状態 | アクセス剥奪が完了したことを示すため |
| 変更履歴 | グループメンバー変更、マッピング変更、SCIM token更新 | 権限変更の追跡に使うため |
SCIMアプリからユーザーを削除すると、そのユーザーはAzure Databricksアカウントとワークスペースからdeactivateされます。一方、Azure Databricks account consoleでユーザーを直接削除すると、そのユーザーはMicrosoft Entra ID provisioningで再同期されない挙動が説明されています。退職者対応やアクセス剥奪は、原則としてMicrosoft Entra ID側を起点に設計するのが安全です。(Microsoft Learn)
よくある失敗と対策
Azure DatabricksのSCIM provisioningでは、設定自体は難しくなくても、運用でつまずくケースが多くあります。代表的な失敗と対策を整理します。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| workspace-level SCIM connectorを残したままaccount-level SCIMを有効化する | IDが複数経路で管理され、権限レビューが複雑になる | account-levelへ移行する前に既存connectorを棚卸しし、無効化計画を作る |
| ネストグループをSCIMで同期しようとする | 子グループのメンバーがDatabricksに作成されない | 直接メンバーのグループを割り当てるか、Automatic identity managementを検討する |
| サービスプリンシパルもSCIMで同期されると思い込む | ジョブやAPI実行用IDがDatabricksに存在しない | SPは別方式でプロビジョニングする |
| userNameとemails.valueが一致していない | ユーザー作成リクエストがAzure Databricksに拒否される可能性がある | 外部ユーザーやメールエイリアス利用時はSCIM mappingを確認する |
| グループ名変更がDatabricksに反映されると期待する | Entra ID側とDatabricks側でグループ名がずれる | グループ名変更の運用ルールを決め、必要に応じて再作成や整理を行う |
| 同期が即時反映されると思い込む | 変更後すぐにログイン・権限確認して誤判定する | 初回同期と定期同期のタイミングを考慮して確認する |
| Databricks側でユーザーを直接削除する | Entra ID provisioningで再同期されない | 削除・無効化はEntra ID側を起点にする |
公式ドキュメントでは、初回のMicrosoft Entra ID同期はプロビジョニング有効化後すぐにトリガーされ、その後の同期はアプリ内のユーザーやグループ数に応じて20〜40分ごとにトリガーされると説明されています。また、userNameとemails.valueは一致している必要があり、外部ユーザーやメールエイリアスのケースでは、既定のSCIM mappingをmailではなくuserPrincipalNameに変更する必要がある場合があります。(Microsoft Learn)
トラブルシューティングの実務チェックリスト
ユーザーやグループが同期されない場合は、闇雲に再設定するのではなく、原因を切り分けます。まず見るべき場所は、Microsoft Entra IDのEnterprise application側のProvisioningログ、Azure Databricks account consoleのUser provisioning設定、同期対象の割り当て状態です。
| 症状 | 確認すること | 対応 |
|---|---|---|
| ユーザーがDatabricksに作成されない | SCIM tokenが有効か、対象ユーザーがアプリに割り当てられているか | Test ConnectionとProvisioningログを確認する |
| グループが同期されない | Microsoft Entra ID Premium editionか、直接割り当てられたグループか | ネストグループではなく直接メンバー構成を確認する |
| サービスプリンシパルが同期されない | SCIM connectorで同期しようとしていないか | Automatic identity management、Terraform、API、手動追加を検討する |
| 初回同期後に更新が反映されない | 同期遅延か、プロビジョニング状態の問題か | 必要に応じてClear current state and restart synchronizationを使う |
| IP制限で接続できない | Microsoft Entra ID provisioning serviceの通信が許可されているか | AzureActiveDirectoryのservice tagに該当するIP範囲を許可する |
ネットワーク制限をかけている環境では、Microsoft Entra ID provisioning serviceのIP範囲が到達可能かも確認が必要です。公式ドキュメントでは、制限がある場合にAzure IP Ranges and Service Tags – Public Cloudファイル内のAzureActiveDirectoryに該当するIPアドレスからの通信を許可する必要があると説明されています。(Microsoft Learn)
Microsoft Graphによる自動化はいつ使うべきか
公式ドキュメントでは、Azure portalで個別にSCIM provisioning connector applicationを作成するだけでなく、Microsoft Graphを使ってユーザーやグループのプロビジョニングを自動化する方法にも触れています。Microsoft Graphを使う場合は、アプリケーション登録、Application IDとTenant IDの取得、client secretの構成、Application.ReadWrite.AllやApplication.ReadWrite.OwnedByなどの権限付与が必要です。(Microsoft Learn)
Microsoft Graphによる自動化は、次のような組織で検討すると効果があります。
| 向いている環境 | 理由 |
|---|---|
| 複数のDatabricksアカウントを管理している | 手作業のEnterprise application設定を減らせる |
| 環境構築をIaCやCI/CDに寄せている | ID同期設定も変更管理の対象にしやすい |
| グローバル拠点で同じ統制を展開したい | 手順差や設定漏れを減らせる |
| 監査のために設定変更をコード化したい | 誰がいつ何を変更したか追いやすい |
ただし、Microsoft Graphを使うと、アプリ権限やsecret管理の責任が増えます。小規模環境であればAzure portalからの手動設定で十分な場合もあります。自動化は「設定作業を減らすため」だけでなく、「変更管理と再現性を高めるため」に導入するのが現実的です。
グローバル運用で注意すべきポイント
Azure Databricksを複数リージョンや複数国で使う場合、SCIM provisioningの設計はさらに慎重に行う必要があります。特に注意すべきなのは、Azure ChinaリージョンではMicrosoft Entra ID SCIM provisioning connectorが利用できない点です。グローバル共通の手順書を作る場合でも、中国リージョンを含む環境では例外運用を明記する必要があります。(Microsoft Learn)
また、外部ユーザーやメールエイリアスを使う企業では、mail、userPrincipalName、emails.valueの扱いを事前に確認してください。グローバル企業では、買収企業、委託先、B2Bゲスト、地域別ドメインが混在しやすく、メール属性の不一致がSCIMエラーの原因になります。
クロステナントのID管理が必要な場合も注意が必要です。Automatic identity managementはクロステナントMicrosoft Entra IDディレクトリをサポートしないため、Microsoft Entra B2B collaborationとSCIM provisioningを組み合わせる設計が候補になります。(Microsoft Learn)
移行時は「IDの重複」と「権限の残り方」を確認する
既存のworkspace-level SCIM provisioningからaccount-level SCIM、またはSCIMからAutomatic identity managementへ移行する場合、もっとも避けたいのはIDの重複と権限の不整合です。
移行前に、少なくとも次の棚卸しを行います。
| 棚卸し対象 | 確認内容 |
|---|---|
| 既存ユーザー | Databricks上のユーザーがEntra IDに存在するか |
| 既存グループ | グループ名、用途、メンバー、権限付与先 |
| SCIM connector | workspace-levelとaccount-levelのどちらが使われているか |
| 手動追加ID | 自動同期外のユーザー、外部ユーザー、管理者 |
| サービスプリンシパル | ジョブ、API、CI/CDで利用されているID |
| 権限 | ワークスペース、Unity Catalog、SQL warehouse、ジョブ、クラスターポリシー |
| 監査ログ | 変更履歴をどこで追跡しているか |
Microsoft Learnでは、Automatic identity managementとSCIM provisioningを混在させると重複エントリや権限競合が起こる可能性があるため、Automatic identity managementをsingle source of truthとして使うことが推奨されています。一方、SCIMからAutomatic identity managementへ移行する場合、グループは同じAzure Databricks内部オブジェクトとして残り、Unity Catalog権限やワークスペース割り当てなどは引き継がれると説明されています。(Microsoft Learn)
この点は移行計画で重要です。権限が引き継がれることはメリットですが、不要な権限や古いSCIM同期由来のメンバーシップまで残る可能性があります。移行は「切り替え作業」ではなく、「不要権限を整理する機会」として扱うべきです。
実務で使える導入チェックリスト
Azure DatabricksのSCIM provisioningを設定する前に、次のチェックリストを使って準備状況を確認してください。
| チェック項目 | 完了条件 |
|---|---|
| ID同期方式を決めた | SCIM、Automatic identity management、併用期間の扱いが決まっている |
| 既存connectorを棚卸しした | workspace-level SCIM connectorの有無と停止計画が明確 |
| 権限グループを設計した | 組織グループではなく権限単位のグループが定義されている |
| ネストグループを確認した | SCIMで同期できない構造を把握している |
| サービスプリンシパル管理を決めた | SCIM以外の登録・削除・権限付与方法が決まっている |
| メール属性を確認した | userName、emails.value、userPrincipalNameの対応が確認済み |
| 退職者対応を設計した | Entra ID側を起点に無効化する手順がある |
| 監査証跡を決めた | provisioningログ、グループ変更履歴、例外ID一覧を保存できる |
| 同期遅延を説明できる | 20〜40分程度の同期間隔を運用担当者が理解している |
| グローバル制約を確認した | Azure China、クロステナント、B2B利用の有無を確認済み |
このチェックリストを満たしてから設定に入ると、導入後の「同期されない」「権限が残る」「監査で説明できない」といった問題を減らせます。
まとめ：SCIM設定の前にID管理方式を決める
Azure Databricksの2026年4月更新ポイントは、SCIM provisioningの手順そのものよりも、Microsoft Entra IDとのID管理方式をどう選ぶかにあります。SCIMはユーザーとグループの同期に使える実績ある方法ですが、ネストグループやサービスプリンシパルには対応しません。新規構築ではAutomatic identity managementを優先して検討し、既存環境ではaccount-level SCIMへの整理や移行計画を立てることが重要です。
次に取るべき行動は明確です。まずAzure Databricks account consoleで現在のUser provisioning設定を確認し、workspace-level SCIM connectorの有無、Microsoft Entra IDのグループ構造、サービスプリンシパル利用状況を棚卸ししてください。そのうえで、SCIMを継続するのか、Automatic identity managementへ移行するのかを決め、退職者対応と監査証跡まで含めた運用手順に落とし込みましょう。
コメント