Azure DatabricksでMicrosoft Entra IDのユーザー、グループ、サービスプリンシパルをどう同期すべきか迷っているなら、2026年4月更新で押さえるべき結論は明確です。IDフェデレーション済みワークスペースでは、自動ID管理（Automatic Identity Management）を中心に設計し、SCIMとの併用・移行・監査ログ・トークン失効を運用ルールに組み込むことが重要です。
Microsoft Learn日本語版の「Microsoft Entra ID からユーザーとグループを自動的に同期する」は2026年4月22日に更新され、Azure DatabricksがMicrosoft Entra IDをIDの信頼元として扱う考え方、SCIMプロビジョニングとの違い、ネストグループ、サービスプリンシパル、監査ログ、既知の制限が整理されています。セキュリティ管理者、ID管理チーム、コンプライアンス担当者は、単に「同期できるようになった」と見るのではなく、アクセス権の継承、削除済みユーザーの扱い、PATの残存、SCIMからの移行影響まで確認する必要があります。(Microsoft Learn)
2026年4月更新でまず押さえるべきポイント
今回のMicrosoft Learn更新で実務上重要なのは、Azure Databricksの自動ID管理が「Microsoft Entra IDのユーザーとグループを楽に追加する機能」ではなく、ID同期と権限管理の設計方針そのものに関わる機能として整理されている点です。
自動ID管理を有効にすると、Microsoft Entra IDで個別のエンタープライズアプリケーションを構成しなくても、Microsoft Entra IDのユーザー、サービスプリンシパル、グループをAzure Databricks側で検索し、IDフェデレーション済みワークスペースへ追加できます。DatabricksはMicrosoft Entra IDをレコードのソースとして扱い、グループメンバーシップの変更もAzure Databricksに反映します。(Microsoft Learn)
| 確認ポイント | 実務上の意味 | 管理者が見るべき箇所 |
|---|---|---|
| 自動ID管理が中心になる | SCIMアプリを前提にした従来運用を見直す必要がある | User provisioning、SCIM設定、既存グループ |
| JITプロビジョニングが常時有効 | 初回ログイン時にユーザーが自動作成される | 初回アクセス時の監査ログ、不要ユーザーの扱い |
| ネストグループを考慮する | 親グループへの権限付与が子グループのメンバーにも及ぶ | Entra IDのグループ階層、Workspace assignment |
| サービスプリンシパルも対象 | CI/CDやジョブ実行用IDの管理方針に影響する | ジョブ、トークン認証、API実行 |
| SCIMとの混在に注意 | 重複IDや権限競合の原因になる | externalId、ObjectId、SCIM同期履歴 |
| 監査ログで追跡できる | 自動同期による作成・変更を証跡化できる | system.access.audit |
この更新を読んだ後に最初に行うべきことは、Azure Databricksの各ワークスペースがIDフェデレーションに対応しているか、既存のSCIMプロビジョニングと自動ID管理が競合していないか、削除済みユーザーの個人用アクセストークンが残っていないかを確認することです。
自動ID管理とは何か
Azure Databricksの自動ID管理は、Microsoft Entra IDのID情報をAzure Databricksへ自動的に取り込む仕組みです。対象には、ユーザー、サービスプリンシパル、グループが含まれます。
従来のSCIMプロビジョニングでは、Microsoft Entra ID側にエンタープライズアプリケーションを作成し、SCIMコネクター、シークレットトークン、同期対象の割り当てなどを構成する必要がありました。自動ID管理では、この構成作業を大きく減らせます。
ただし、重要なのは「手順が少ない」ことだけではありません。自動ID管理は、Microsoft Entra IDを信頼できるIDのソースとして扱い、Azure Databricks側のユーザー・グループ管理をEntra ID中心に寄せる設計です。ID管理チームにとっては、Azure Databricksだけを個別に管理するのではなく、Entra IDのライフサイクル管理と連動させやすくなります。
JITプロビジョニングはオフにできない
自動ID管理を有効にすると、Just-In-Time（JIT）プロビジョニングは常に有効になります。Microsoft Entra IDの新規ユーザーは、初回ログイン時にAzure Databricksへ自動的にプロビジョニングされます。Microsoft Learnでは、このJITプロビジョニングは自動ID管理が有効な場合に常時有効で、オフにできないと説明されています。(Microsoft Learn)
これは便利な一方で、セキュリティ管理者にとっては注意点でもあります。
たとえば、組織内の広いグループにAzure Databricksの利用可能性を持たせている場合、実際にログインしたユーザーだけがAzure Databricks側に作成されます。そのため、ユーザー棚卸しでは「Entra ID上の対象者」と「Azure Databricksに実体として現れたユーザー」を分けて考える必要があります。
自動ID管理とSCIMプロビジョニングの違い
2026年4月更新で特に重要なのが、自動ID管理とSCIMプロビジョニングの役割分担です。Microsoft Learnでは、自動ID管理を有効にすると、ユーザー、グループ、グループメンバーシップがMicrosoft Entra IDからAzure Databricksへ同期されるため、SCIMプロビジョニングは不要と説明されています。(Microsoft Learn)
ただし、既存環境でSCIMを使っている企業は少なくありません。いきなりSCIMを停止するのではなく、現在の同期対象、グループ構造、権限付与、監査要件を確認してから移行する必要があります。
| 比較項目 | 自動ID管理 | SCIMプロビジョニング |
|---|---|---|
| Microsoft Entra IDアプリの構成 | 原則不要 | 必要 |
| ユーザー同期 | 対応 | 対応 |
| グループ同期 | 対応 | 対応 |
| ネストグループ | 対応 | 直接メンバー中心で制約あり |
| サービスプリンシパル同期 | 対応 | SCIMコネクターでは非対応 |
| Microsoft Entra ID管理者ロール | 不要な構成で利用可能 | Cloud Application Administratorなどが必要 |
| 既存運用との相性 | 新規・統合運用向き | 既存SCIM運用の継続に向く場合あり |
Microsoft LearnのSCIM構成ページでも、自動ID管理はMicrosoft Entra IDアプリケーションの構成を必要とせず、SCIMでは対応しないサービスプリンシパルやネストグループの同期をサポートすると説明されています。SCIMプロビジョニングにはAzure Databricks Premium plan、Azure Databricks account admin、Microsoft Entra ID側のCloud Application Administratorロールなどの要件もあります。(Microsoft Learn)
既存SCIM環境で失敗しやすいポイント
既存のSCIM運用から自動ID管理へ移る際に起きやすい失敗は、次の3つです。
| 失敗しやすいケース | 何が起きるか | 対策 |
|---|---|---|
| SCIMと自動ID管理を無計画に併用する | 同じIDが重複し、権限競合が発生する可能性がある | 自動ID管理を信頼元にするか、SCIM継続範囲を明確にする |
| SCIM同期済みメンバーシップが残る | 古いグループメンバーシップが意図せず残る | SCIM APIで不要なメンバーシップを手動整理する |
| externalIdに依存した自動化を組んでいる | externalId更新によりワークフローが不安定になる | Entra IDのObjectIdを基準に設計を見直す |
Azure Databricksは、Microsoft Entra IDのObjectIdをIDとグループメンバーシップ同期の権威あるリンクとして使用し、externalIdフィールドをObjectIdに合わせて更新します。そのため、externalIdに依存する独自ワークフローは避けるべきです。(Microsoft Learn)
ユーザーとグループのステータスをどう読むか
自動ID管理が有効になると、Microsoft Entra IDのユーザー、サービスプリンシパル、グループはAzure Databricksのアカウントコンソールやワークスペース管理者設定ページに表示されます。ステータスは、Entra IDとAzure Databricks間の状態を理解するための重要な手がかりです。(Microsoft Learn)
| ステータス | 意味 | 実務での対応 |
|---|---|---|
| 非アクティブ: 使用なし | ユーザーやサービスプリンシパルは未ログイン、グループはワークスペース未追加 | 初回利用前の状態として扱う |
| アクティブ | Azure Databricksで有効なID | 通常利用中として監査対象にする |
| アクティブ: Entra IDから削除済み | Entra IDから削除済みで、次回同期時に非アクティブ化される | 早急にトークンと権限を確認する |
| 非アクティブ | Entra IDまたはDatabricks側で非アクティブ化済み | ログイン・API認証不可。残存権限とトークンを点検する |
特に重要なのは、Microsoft Entra IDからユーザーを削除しても、Azure Databricksが個人用アクセストークンを自動的には取り消さない点です。Microsoft Learnでは、非アクティブ化されたユーザーや「Active: Removed From EntraID」のユーザーについて、個人用アクセストークンを取り消すことがセキュリティ上のベストプラクティスとして推奨されています。(Microsoft Learn)
セキュリティ管理者向けの確認リスト
ユーザー削除や異動が多い組織では、次のチェックを定期運用に入れるとよいでしょう。
| チェック項目 | 理由 | 推奨頻度 |
|---|---|---|
| 削除済みEntra IDユーザーのDatabricksステータス | 退職者・異動者の残存アクセスを防ぐ | 日次または週次 |
| 個人用アクセストークンの残存 | ユーザー無効化だけではトークンが失効しないため | 日次またはインシデント時 |
| グループメンバーシップ変更の反映 | 権限付与・剥奪の遅延を把握するため | 重要変更後 |
| SCIM由来メンバーシップ | 自動ID管理で削除されない可能性があるため | 移行時・棚卸し時 |
| 監査ログのAIMイベント | 自動作成・自動更新の証跡確認 | 継続監視 |
グループメンバーシップ同期のタイミング
自動ID管理では、グループメンバーシップが常にリアルタイムで完全同期されるわけではありません。Azure Databricksは、ブラウザーログイン、トークン認証、ジョブ実行など、認証や認可チェックを伴う活動の中でMicrosoft Entra IDからグループメンバーシップを更新します。(Microsoft Learn)
| アクティビティ | 同期の目安 |
|---|---|
| ブラウザーログイン | 前回同期から5分超の場合に同期 |
| トークン認証、ジョブ実行など | 前回同期から40分超の場合に同期 |
この仕様は、権限変更直後の確認で特に重要です。
たとえば、Microsoft Entra IDでユーザーを機密データアクセス用グループから削除した直後に、Azure Databricks上のアクセス確認を行う場合、同期タイミングを考慮しないと「まだアクセスできる」「まだ反映されない」と誤解する可能性があります。緊急の権限剥奪では、グループ変更だけでなく、セッション、トークン、ジョブ実行ID、ワークスペース割り当ての確認もあわせて行うべきです。
ネストグループ対応で権限設計はどう変わるか
自動ID管理では、Microsoft Entra IDの推移的な、つまりネストされたグループメンバーシップを取得します。ユーザーがGroup Aに所属し、Group AがGroup Bに所属している場合、Azure Databricksはそのユーザーを両方のグループのメンバーとして認識します。(Microsoft Learn)
これは大規模組織にとって便利です。地域別、部門別、職務別のグループを親グループにまとめ、親グループへAzure Databricksのアクセス権を与えることで、権限設計を簡素化できます。
一方で、コンプライアンス観点では「どの子グループ経由でアクセスできているのか」を把握しにくくなる場合があります。特にUnity Catalogの権限、ワークスペース割り当て、AI/BIダッシュボード共有では、親グループに付与した権限が想定以上の範囲へ広がらないように注意が必要です。
ネストグループ利用時の判断基準
| 利用シーン | ネストグループを使うべきか | 判断理由 |
|---|---|---|
| 全社共通の閲覧権限 | 使いやすい | 親グループで管理しやすい |
| 部門別ワークスペースアクセス | 条件付きで有効 | 子グループ構造が明確なら運用しやすい |
| 機密データへの書き込み権限 | 慎重に使う | 間接所属による過剰権限に注意 |
| 本番ジョブ実行権限 | 原則として限定グループ推奨 | サービスプリンシパルやCI/CD権限の影響が大きい |
| 監査証跡が厳しい環境 | グループ階層の文書化が必須 | 監査時に権限継承経路を説明する必要がある |
Azure Databricksは、Azure Databricksに追加されたグループのメンバーシップを取得しますが、Microsoft Entra IDの完全な親グループ階層を同期・再構築するわけではありません。この点を誤解すると、Entra ID側で見えている階層とDatabricks側で管理できる対象に差が出ます。(Microsoft Learn)
アカウントレベル資産とワークスペースレベル資産で挙動が違う
Microsoft Entra IDグループを使った権限付与は、対象資産がアカウントレベルかワークスペースレベルかで挙動が異なります。
Microsoft Learnでは、Databricks Apps、Unity Catalogオブジェクト、AI/BIダッシュボード、Genie Spaces、ワークスペース割り当てなどのアカウントレベル資産ではグループを共有や権限割り当てに利用できる一方、ノートブック、ジョブ、SQLウェアハウス、アラート、ファイルなどのワークスペースレベル資産をグループと共有するには、ワークスペース管理者が先にグループをワークスペースへ直接追加する必要があると説明されています。(Microsoft Learn)
| 資産の種類 | 例 | グループ利用時の注意点 |
|---|---|---|
| アカウントレベル資産 | Unity Catalog、AI/BIダッシュボード、Genie Spaces、Databricks Apps | Microsoft Entra IDグループを権限付与に使いやすい |
| ワークスペースレベル資産 | ノートブック、ジョブ、SQLウェアハウス、アラート、ファイル | 先にグループをワークスペースへ追加する必要がある |
| ダッシュボード共有 | AI/BIダッシュボードなど | 共有先ユーザーはログイン時にアカウントへ追加されるが、必ずしもワークスペースメンバーになるわけではない |
実務では、データガバナンスチームとワークスペース管理者の役割分担を明確にしておく必要があります。Unity Catalogの権限は中央管理できていても、ワークスペース内のジョブやノートブック共有はワークスペース追加の有無に左右されるためです。
有効化の手順と事前確認
自動ID管理は、2025年8月1日以降に作成されたAzure Databricksアカウントでは既定で有効です。既存アカウントでは、アカウント管理者がアカウントコンソールから有効化できます。変更が反映されるまでには5〜10分かかると説明されています。(Microsoft Learn)
| 手順 | 操作 |
|---|---|
| 1 | Azure Databricksのアカウント管理者としてアカウントコンソールへログイン |
| 2 | サイドバーで「Security」を開く |
| 3 | 「User provisioning」タブを開く |
| 4 | 「Automatic identity management」をEnabledに切り替える |
| 5 | 反映後、ユーザー、サービスプリンシパル、グループの追加・削除手順を確認する |
有効化前に確認すべきこと
自動ID管理の有効化は簡単ですが、運用影響は大きくなります。特に既存環境では、次の項目を事前に確認してください。
| 確認項目 | 確認理由 |
|---|---|
| ワークスペースがIDフェデレーション済みか | 非IDフェデレーションワークスペースでは自動ID管理がサポートされない |
| 既存SCIMコネクターの有無 | 同期方法の混在による重複や競合を避ける |
| Entra IDグループ階層 | ネストグループにより権限範囲が広がる可能性がある |
| サービスプリンシパルの利用状況 | ジョブ実行、CI/CD、API認証に影響する |
| PATとトークン管理 | ユーザー削除後もトークンが残るリスクがある |
| 監査ログの保存・閲覧体制 | 自動作成や同期イベントの説明責任に関わる |
無効化すると何が起きるか
自動ID管理は、有効化だけでなく無効化時の影響も重要です。無効化すると、ユーザーとサービスプリンシパルは残り、アクセス権も保持されますが、Microsoft Entra IDとは同期されなくなります。一方、グループはAzure Databricks内に残るものの、すべてのグループメンバーが削除されます。さらに、Entra ID側のユーザー削除やグループ更新はAzure Databricksに反映されなくなります。(Microsoft Learn)
| 無効化後の対象 | 挙動 | 注意点 |
|---|---|---|
| ユーザー | 残る | アクセス権が残るため手動削除・非アクティブ化が必要 |
| サービスプリンシパル | 残る | ジョブやAPI実行が継続する可能性がある |
| グループ | グループ自体は残るがメンバーシップは削除 | グループベース権限が崩れる可能性がある |
| Entra ID変更 | 反映されない | 退職者・異動者対応がDatabricks側で必要になる |
| ネストグループ権限 | 継承されない | 親グループベースの設計に影響する |
無効化を検討する場合は、事前にSCIMプロビジョニングをフォールバックとして設定することが推奨されています。特に本番環境でグループベースの権限設計をしている場合、無効化は単なる設定変更ではなく、アクセス制御モデルの変更として扱うべきです。(Microsoft Learn)
監査ログで確認すべきAIMイベント
自動ID管理が有効な場合、AIMプロセスによるID操作は監査ログで追跡できます。Microsoft Learnでは、既存の監査ログイベントにタグを追加することで、自動ID管理による操作を識別できると説明されています。(Microsoft Learn)
主に見るべきタグは次の2つです。
| タグ | 意味 |
|---|---|
endpoint: "autoUserCreation" | AIMプロセスから生成されたユーザー、グループ、グループメンバーシップ操作 |
groupMembershipType: "IdentityProvider" | Microsoft Entra IDから同期されたグループメンバーシップ操作 |
AIMで作成されたユーザーを確認するSQL例
SELECT
request_params.targetUserName,
event_time
FROM
system.access.audit
WHERE
action_name = "add"
AND request_params.endpoint = "autoUserCreation"Entra IDから同期されたグループメンバーシップを確認するSQL例
SELECT
request_params.targetGroupName,
request_params.targetUserName,
event_time
FROM
system.access.audit
WHERE
action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
AND request_params.groupMembershipType = "IdentityProvider"コンプライアンス担当者は、これらのクエリを単発で実行するだけでなく、定期レポート化することを検討すべきです。たとえば、次のような観点でダッシュボード化すると、監査対応が楽になります。
| 監査観点 | 見るべき内容 |
|---|---|
| 新規ユーザー作成 | AIMにより作成されたユーザーと時刻 |
| グループ追加・削除 | どのユーザーがどのグループに追加・削除されたか |
| 削除済みユーザー | Entra IDから削除された後のDatabricksステータス |
| 異常な初回ログイン | 想定外の部署・地域からの初回利用 |
| サービスプリンシパル利用 | ジョブ実行やトークン認証による初回プロビジョニング |
既知の動作と制限事項
2026年4月更新で実務上見逃せないのが、既知の動作と制限事項です。特に、グループ作成、ワークスペース割り当て、サービスプリンシパルの初回使用、グループ名同期、クロステナント対応は、設計時に必ず確認する必要があります。(Microsoft Learn)
| 項目 | 仕様・制限 | 実務上の注意点 |
|---|---|---|
| グループ作成 | Entra IDから同期されたグループはアカウントレベルで自動作成される | ワークスペースアクセスは別途割り当てが必要 |
| ワークスペース割り当て | 自動ID管理はグループメンバーシップを制御し、管理者がワークスペースアクセスを制御する | 「同期された＝ワークスペースに入れる」ではない |
| サービスプリンシパル | グループに含まれていても、初回使用までプロビジョニングされない | ジョブ実行やトークン認証まで表示されない可能性がある |
| グループ名変更 | Entra IDでの名前変更は即時反映されない | アカウント管理者が詳細ページを開いた時に同期される |
| SCIM同期済みメンバーシップ | 自動ID管理では削除されない | SCIM APIで手動クリーンアップが必要 |
| クロステナントEntra ID | 自動ID管理では非対応 | Microsoft Entra B2BとSCIMプロビジョニングを検討 |
| API・Terraform | 直接プロビジョニングされていないネストグループやサービスプリンシパルは取得・管理できない | プログラム管理が必要なら明示的にアカウントへプロビジョニング |
| SCIMからの移行 | グループは同じ内部Databricksオブジェクトとして残る | Unity Catalog権限やワークスペース割り当ては引き継がれる |
「同期されたグループ」と「ワークスペースに入れるグループ」は別
よくある誤解は、Microsoft Entra IDからグループが同期されたら、そのメンバーがすぐにワークスペースへアクセスできるというものです。
実際には、自動ID管理でアカウントレベルにグループが作成されても、ワークスペースへの割り当ては別の手順です。同期はIDとメンバーシップの管理、ワークスペース割り当てはアクセス制御の管理と考えると整理しやすくなります。
セキュリティ管理者・ID管理チーム・コンプライアンス担当者の対応方針
今回の更新を踏まえると、Azure DatabricksのID管理は「Databricks管理者だけの作業」ではなく、Entra ID管理、データガバナンス、監査対応をまたぐ共同運用に変わります。
セキュリティ管理者が行うべきこと
セキュリティ管理者は、削除済みユーザー、PAT、サービスプリンシパル、ネストグループによる過剰権限を重点的に確認します。
| 優先度 | 対応 |
|---|---|
| 高 | 削除済みEntra IDユーザーのPATを失効する運用を作る |
| 高 | 機密データにアクセスできるグループのネスト構造を棚卸しする |
| 高 | SCIMと自動ID管理の併用状態を確認する |
| 中 | サービスプリンシパルの初回使用とジョブ実行を監査する |
| 中 | グループ名変更時の反映タイミングを運用手順に入れる |
ID管理チームが行うべきこと
ID管理チームは、Microsoft Entra IDを信頼元として、グループ設計をAzure Databricksの権限設計と整合させる必要があります。
たとえば、Entra ID側では便利な「部門全体グループ」でも、Azure Databricksでは本番データや機密ダッシュボードに広すぎる権限を与えてしまうことがあります。親グループへ権限を付与する場合は、子グループのメンバー変更がDatabricks権限に直結することを明文化しておきましょう。
コンプライアンス担当者が行うべきこと
コンプライアンス担当者は、監査ログの保存と説明可能性を重視します。AIMによる自動操作は便利ですが、監査時には「誰が、いつ、どのグループ経由で、どの権限を得たか」を説明できる必要があります。
system.access.auditのAIMイベントを定期的に抽出し、Entra ID側の変更ログ、Databricksのワークスペース割り当て、Unity Catalog権限と突き合わせる運用が理想です。
SCIMから自動ID管理へ移行する場合の進め方
既存のSCIM運用がある場合は、次の順序で移行を検討すると安全です。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | SCIMアプリ、同期対象、グループ、サービスプリンシパルを洗い出す | ID同期台帳 |
| 影響分析 | ネストグループ、Unity Catalog権限、ワークスペース割り当てを確認 | 影響範囲一覧 |
| 重複確認 | ObjectId、externalId、既存Databricks IDの対応を確認 | 重複IDリスト |
| テスト | 検証用グループで自動ID管理の挙動を確認 | テスト結果 |
| 移行 | 自動ID管理を有効化し、SCIMの役割を整理 | 移行手順書 |
| クリーンアップ | 不要なSCIM同期メンバーシップを削除 | クリーンアップ記録 |
| 監査定着 | AIMイベントを定期監視する | 監査レポート |
SCIMから自動ID管理へ移行する場合、Microsoft Learnでは、グループは同じ内部Azure Databricksオブジェクトとして残り、Unity Catalog権限やワークスペース割り当てなどは自動的に引き継がれ、移行中に権限は失われないと説明されています。(Microsoft Learn)
ただし、これは「何も確認しなくてよい」という意味ではありません。SCIM由来の古いメンバーシップ、自動ID管理による新しいメンバーシップ、ネストグループによる間接権限が混在すると、棚卸しが難しくなります。移行前後で、同じユーザーがどの経路で権限を得ているかを確認してください。
実務で使える運用チェックリスト
最後に、2026年4月更新を踏まえて、Azure Databricks管理者がすぐに使えるチェックリストをまとめます。
| チェック | 完了条件 |
|---|---|
| IDフェデレーションの有効状態を確認した | 対象ワークスペースが自動ID管理に対応している |
| 自動ID管理の有効状態を確認した | User provisioningで設定状態を把握している |
| SCIMコネクターを棚卸しした | 併用範囲、停止予定、移行計画が明確になっている |
| Entra IDグループ階層を確認した | 親子グループによる過剰権限がない |
| サービスプリンシパルを確認した | ジョブ、API、CI/CDの実行IDが明確になっている |
| 削除済みユーザーのPAT失効手順を作った | Entra ID削除後の残存トークン対策がある |
| AIM監査ログを確認した | autoUserCreationとIdentityProviderを追跡できる |
| グループ名変更時の運用を決めた | 表示名の不一致で混乱しない |
| クロステナント要件を確認した | 必要に応じてSCIMとMicrosoft Entra B2Bを検討している |
| API・Terraform管理対象を確認した | ネストグループやサービスプリンシパルの明示プロビジョニング要否を判断した |
Azure Databricksの自動ID管理は、Microsoft Entra IDを中心にIDライフサイクルを統一できる強力な仕組みです。一方で、SCIMとの混在、削除済みユーザーのトークン、ネストグループによる権限継承、ワークスペース割り当ての手動管理など、運用で見落としやすい点もあります。
まずは、現在のAzure Databricksアカウントで自動ID管理が有効か、SCIMプロビジョニングが残っているか、Entra IDグループ階層がDatabricksの権限設計と一致しているかを確認してください。そのうえで、監査ログによるAIMイベントの可視化と、削除済みユーザーのPAT失効ルールを整備することが、2026年4月更新を実務に反映する最初の一歩です。
コメント