Microsoft PurviewのAdministrative unitsは、Microsoft Entra IDの管理単位を使って、Purviewの管理権限や一部ポリシーの対象範囲を「部門」「地域」「拠点」「事業会社」単位に絞り込むための仕組みです。結論から言うと、全社管理者を増やさずに、DLP、秘密度ラベル、ライフサイクル管理、内部リスク管理などの運用を委任したい組織は、早めに設計を見直すべき機能です。
2026年6月上旬に更新された公式情報で特に重要なのは、Administrative units in Microsoft Purviewにおいて、SharePointサイトをAdministrative unitsに関連付けるサポートが明記されている点です。これにより、ユーザーやグループだけでなく、SharePointサイトを含むポリシー運用でも、管理範囲の分離をより実務に近い形で設計しやすくなります。Microsoft Learn上の該当ページは「Last updated on 2026-06-04」と表示されていますが、本記事では2026年6月5日時点で確認すべき公式情報として整理します。(Microsoft Learn)
Microsoft PurviewのAdministrative unitsとは
Administrative unitsは、Microsoft Entra ID上で組織を小さな単位に分割し、その単位ごとに管理権限を制限する機能です。Microsoft Purviewでは、このAdministrative unitsとロールグループを組み合わせることで、特定の管理者に「自分が担当する部門や地域だけを管理させる」構成を取れます。(Microsoft Learn)
たとえば、次のようなケースで効果があります。
| 利用シーン | Administrative unitsで実現できること |
|---|---|
| 日本法人、米国法人、欧州法人で管理を分けたい | 各地域の管理者が自地域のユーザーやポリシーだけを扱える |
| 人事部、法務部、研究開発部でDLPやラベル運用を分けたい | 部門ごとのポリシー作成・確認・調査権限を委任できる |
| 子会社ごとにコンプライアンス担当を置きたい | 全社管理者権限を付与せず、対象子会社の範囲に限定できる |
| SharePointサイト単位でDLPや自動ラベル付けを管理したい | 対象サイトをAdministrative unitsに関連付け、ポリシー範囲を絞れる |
ポイントは、Administrative unitsが単なる「表示フィルター」ではないことです。対応しているMicrosoft Purview機能では、管理者が見えるポリシー、作成・編集できる対象、確認できるアラートやアクティビティの範囲に影響します。
2026年6月更新で確認すべき主な変更点
今回の公式情報で管理者が最も注目すべき点は、Microsoft PurviewがSharePointサイトをAdministrative unitsに追加するサポートを示していることです。このサポートは、Microsoft Information Protectionの自動ラベル付けポリシーと、SharePointサイトに適用できるMicrosoft Purview DLPポリシーで利用できるとされています。(Microsoft Learn)
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| SharePointサイトのAdministrative units対応 | SharePointサイトをAdministrative unitsに関連付けられる | 部門サイト、プロジェクトサイト、地域別サイトの管理委任がしやすくなる |
| 対象ポリシー | DLPポリシー、Information Protectionの自動ラベル付けポリシーが中心 | すべてのPurview機能で同じように使えるわけではない |
| 反映時間 | SharePointサイトクエリの反映には最大5日かかる場合がある | ポリシー適用直前に設定すると、期待どおりの範囲にならない可能性がある |
| 個別サイトの追加・除外 | Administrative unitsを選んだ場合、個別SharePointサイトのinclude/excludeはできない | クエリ設計の精度が重要になる |
| 権限要件 | SharePointサイト関連付けにはadmin unit extension managerロールが必要 | 既存のPurview管理者だけでは作業できない可能性がある |
特に注意したいのは、「SharePointサイトをAdministrative unitsに関連付けたあと、さらに個別サイトを選んで微調整する」という運用ができない点です。公式情報では、Administrative unitsを選択した管理者は個別SharePointサイトを含めたり除外したりできず、そのAdministrative unitsに関連付けられたすべてのサイトに適用されると説明されています。(Microsoft Learn)
Administrative unitsが対応するMicrosoft Purview機能
Administrative unitsはMicrosoft Purview全体のすべての機能に一律で効くわけではありません。公式情報でサポート対象として整理されている主なソリューションは次のとおりです。(Microsoft Learn)
| Microsoft Purviewソリューション | Administrative unitsで制御できる主な範囲 |
|---|---|
| Data lifecycle management | ロールグループ、保持ポリシー、保持ラベルポリシー |
| Data Loss Prevention（DLP） | ロールグループ、DLPポリシー |
| Communication Compliance | ロールグループ、ポリシー |
| Insider Risk Management | ロールグループ、ポリシー |
| Records management | ロールグループ、保持ポリシー、保持ラベルポリシー、Adaptive scopes |
| Sensitivity labeling | ロールグループ、秘密度ラベルポリシー、自動ラベル付けポリシー |
DLPでは、ポリシーのスコープが2段階で考えられます。まずAdministrative unitsなどで組織内の大きな対象範囲を絞り、その後、DLPが対応する場所や対象に応じて詳細なスコープを設定します。SharePointに対してAdministrative unitsを使った場合、そのAdministrative unitsに含まれるサイトすべてが対象になり、さらに個別サイトを含める・除外する操作はできないとされています。(Microsoft Learn)
また、DLPの対象場所によってAdministrative units対応状況は異なります。Exchange Online、SharePoint、OneDrive、Teamsチャットとチャネルメッセージ、デバイスなどはAdministrative units対応として整理されていますが、クラウドアプリインスタンス、オンプレミスリポジトリ、FabricとPower BIワークスペースなどは同じ表で非対応として示されています。DLPを展開する場合は、「DLP全体で使える」ではなく、「どの場所に対して使えるか」を確認する必要があります。(Microsoft Learn)
restricted administratorとunrestricted administratorの違い
Administrative unitsを理解するうえで重要なのが、restricted administratorとunrestricted administratorの違いです。
| 管理者の種類 | できること | 注意点 |
|---|---|---|
| unrestricted administrator | ディレクトリ全体を対象にポリシーを作成・編集できる | 権限が広いため、最小権限の原則に反しやすい |
| restricted administrator | 割り当てられたAdministrative unitsの範囲でポリシーを作成・編集できる | 既存ポリシーや過去データが見えなくなる場合がある |
Microsoft Purviewでは、ロールグループメンバーをAdministrative unitsに割り当てると、その管理者はrestricted administratorとして扱われます。restricted administratorは、自分に割り当てられたAdministrative unitsを使ってポリシーの初期スコープを定義できます。一方、Administrative unitsが割り当てられていないunrestricted administratorは、ディレクトリ全体を対象にした設定が可能です。(Microsoft Learn)
移行時に特に注意すべきなのは、Administrative unitsをロールグループメンバーに割り当てた後、restricted administratorは既存ポリシーを表示・編集できなくなる点です。ただし、既存ポリシーの動作自体が止まるわけではなく、unrestricted administratorからは引き続き表示・編集できます。(Microsoft Learn)
過去データの見え方にも影響があります。Activity explorerやアラートなどAdministrative units対応機能では、restricted administratorは過去データを見られず、以後は割り当てられたAdministrative unitsに関連するデータだけを確認できるとされています。運用チームを分割する場合は、「過去の調査履歴を誰が参照できるか」まで含めて権限設計を行う必要があります。(Microsoft Learn)
まず確認すべきライセンスと権限
Administrative units in Microsoft Purviewを使う前に、ライセンスと権限の確認が必要です。公式情報では、Microsoft Entra ID P1またはP2のライセンスに加え、Microsoft Purview側の対象サブスクリプションが前提として挙げられています。具体的には、Microsoft 365 E5/A5/G5、各種E5/A5/G5/F5 Compliance、Information Protection & Governance、Insider Risk Management系のライセンスが例示されています。(Microsoft Learn)
権限面では、ロールグループメンバーをAdministrative unitsに割り当てるにはRole managementロールが必要です。Microsoft PurviewポータルのRoles and scopesでロールグループを表示・作成・変更する場合も、グローバル管理者、またはOrganization Managementロールグループに含まれるRole Managementロールが必要とされています。(Microsoft Learn)
ここで見落としやすいのが、Microsoft Entraロールとの優先関係です。Microsoft Purviewのスコープ付きロールグループ割り当てとMicrosoft Entraロールの両方を同じユーザーやグループに付与した場合、重複する機能ではEntraロールが優先され、Administrative unitsによるスコープ制限が効かない可能性があります。(Microsoft Learn)
つまり、「Purview側ではAdministrative unitsで絞ったから安全」とは限りません。対象ユーザーがCompliance Administrator、Global Reader、Security AdministratorなどのEntraロールを持っていないかを必ず確認してください。最小権限の設計では、Purviewロールグループだけでなく、Entra ID側の管理ロール棚卸しが必須です。
設定手順の全体像
Administrative unitsをMicrosoft Purviewで使う流れは、Entra IDで管理単位を作り、メンバーを追加し、Purview側のロールグループやポリシーに反映させる形です。公式手順では、Administrative unitsの作成、ユーザーや配布グループの追加、必要に応じた動的メンバーシップルールの設定、Purviewの対応ロールグループへの割り当てが示されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Entra IDでAdministrative unitsを作成 | 地域、部門、子会社、業務領域など、運用責任の単位に合わせる |
| 2 | ユーザーや配布グループをAdministrative unitsに追加 | Dynamic Distribution Groupsのメンバーは自動的にAdministrative unitsのメンバーにならない |
| 3 | 必要に応じて動的メンバーシップルールを設定 | 動的メンバーシップルールを使うAdministrative unitsにはグループを追加できない |
| 4 | Microsoft Purviewのロールグループに管理者を追加 | 対象ロールグループがAdministrative units対応か確認する |
| 5 | ロールグループメンバーにAdministrative unitsを割り当て | restricted administratorとして期待どおりに制限されるか検証する |
| 6 | 対応ポリシーでAdministrative unitsを選択 | restricted administratorは1つ以上のAdministrative unitsを選ぶ必要がある |
| 7 | アラート、Activity explorer、ポリシー表示をテスト | 管理者ごとに見える範囲が想定どおりか確認する |
動的メンバーシップルールを使う場合は、部門名や国・地域などの属性値が正確に管理されていることが前提です。たとえば「Department = Sales」で営業部を対象にする設計にしても、ユーザー属性が「Sales」「Sales Dept」「営業部」のように揺れていると、対象漏れや意図しない除外が起きます。導入前にEntra IDのユーザー属性を標準化しておくことが重要です。
SharePointサイトをAdministrative unitsに関連付けるときの注意点
SharePointサイトをAdministrative unitsに関連付ける場合は、Microsoft PurviewポータルのSettingsからRoles and scopes、Administrative unitsへ進み、既存のAdministrative unitsを選択して編集します。そのうえで、SharePointサイトを関連付けるクエリを作成します。この作業にはadmin unit extension managerロールが必要です。(Microsoft Learn)
SharePointサイトの関連付けクエリでは、Site URL、サイト名、RefinableString00からRefinableString99までのプロパティがサポートされています。これらのクエリはSharePointサイトとOneDriveアカウントに適用されますが、共有チャネルのSharePointサイトは例外として扱われます。(Microsoft Learn)
実務では、いきなり本番ポリシーへ関連付けるのではなく、SharePoint検索でクエリを検証します。SharePoint管理者ロールを持つアカウントでhttps://<your_tenant>.sharepoint.com/searchにアクセスし、Administrative unitsで使うクエリと同じ条件を検索して、期待するサイトURLだけが返るか確認します。(Microsoft Learn)
失敗しやすいのは、サイト名に部門名が含まれるという理由だけでクエリを作るケースです。たとえば「HR」を含むサイトを人事部のAdministrative unitsに含める設計にすると、「Shared-HR-Archive」「Project-HR-System」「Old-HR-Test」など、運用対象外のサイトまで拾う可能性があります。重要なポリシーに使う場合は、サイト命名規則だけでなく、管理対象を識別するカスタムプロパティを整備し、RefinableStringにマッピングする設計を検討すべきです。
既存環境への影響と移行時の進め方
既存のMicrosoft Purview環境にAdministrative unitsを導入する場合、最初にやるべきことは「管理者」と「ポリシー」と「対象範囲」の棚卸しです。特に既存ポリシーは、restricted administratorから見えなくなる場合があるため、いきなり本番ロールにAdministrative unitsを割り当てるのは危険です。
移行は次の順序で進めると失敗を減らせます。
| フェーズ | 作業 | 目的 |
|---|---|---|
| 棚卸し | Purviewロールグループ、Entraロール、既存ポリシー、アラート運用を一覧化 | スコープ外アクセスや重複権限を見つける |
| 設計 | 部門・地域・サイト単位でAdministrative unitsを設計 | 実際の責任分界と一致させる |
| 検証 | テスト用管理者にAdministrative unitsを割り当てる | 表示範囲、作成範囲、アラート確認範囲を確認する |
| 段階展開 | 低リスクなポリシーからAdministrative unitsを適用 | 全社影響を避けながら運用手順を固める |
| 本番移行 | DLP、自動ラベル付け、保持系ポリシーなどに展開 | 最小権限と運用委任を両立する |
| 監査 | 定期的にEntraロール、Purviewロール、Administrative unitsメンバーを確認 | 権限の肥大化や退職者・異動者の残存を防ぐ |
既存ポリシーの移行では、「ポリシーをそのまま残すのか」「Administrative unitsに合わせて分割するのか」を決める必要があります。全社ポリシーを1つだけ運用していた場合、部門ごとの管理者に委任するには、ポリシーを分割したほうが管理しやすいことがあります。一方、全社で同じルールを強制したいDLPや保持ポリシーは、unrestricted administratorが管理し続けたほうが一貫性を保てます。
管理者・開発者が確認すべきチェックリスト
Administrative units in Microsoft Purviewを展開する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| Entra IDライセンス | Microsoft Entra ID P1またはP2の前提を満たしているか |
| Purviewライセンス | 対象機能に必要なMicrosoft Purviewライセンスがあるか |
| Entraロールの重複 | スコープ制限したいユーザーに広いEntraロールが付与されていないか |
| Purviewロールグループ | 対象ロールグループがAdministrative units対応か |
| 既存ポリシー | restricted administratorにした後、誰が既存ポリシーを管理するか |
| 過去データ | Activity explorerやアラートの過去データ参照が必要な担当者は誰か |
| SharePointクエリ | 期待するサイトだけをAdministrative unitsに関連付けられるか |
| 反映時間 | SharePointサイトクエリやメンバー詳細の反映に最大5日かかる前提で計画しているか |
| 動的メンバーシップ | ユーザー属性の表記揺れ、グループ追加不可の制約を考慮しているか |
| 削除時の運用 | SharePointサイトを外す場合、クエリ結果が空になるよう編集する手順を把握しているか |
開発者や自動化担当者は、権限やスコープの反映が即時ではない点を前提に運用設計をしてください。たとえば、サイト作成ワークフローとDLPポリシー適用を自動化する場合、SharePointサイトクエリの反映を待たずにポリシーを有効化すると、対象サイトが一時的にポリシー範囲外になる可能性があります。承認、検証、反映確認、ポリシー有効化の順にステップを分ける設計が安全です。
よくある誤解と失敗しやすいポイント
Administrative unitsを設定すれば、すべてのPurview権限が制限されるわけではない
Administrative unitsは対応ソリューションで効果を発揮しますが、Microsoft Purviewの全機能、全API、全データ表示に一律で適用されるものではありません。さらに、Microsoft Entraロールが付与されている場合は、Purview側のスコープ付き割り当てよりEntraロールが優先される可能性があります。(Microsoft Learn)
SharePointサイトを個別に微調整できると思い込む
Administrative unitsにSharePointサイトを関連付けた場合、ポリシー側で個別サイトをさらにinclude/excludeする運用はできません。サイト単位の精密な制御が必要なら、最初のクエリ設計で対象サイトを正確に絞り込む必要があります。(Microsoft Learn)
反映を待たずに本番ポリシーを適用する
SharePointサイトクエリの完全反映には最大5日かかる場合があり、変更は即時ではありません。メンバー詳細リストの更新にも最大5日かかる可能性があります。急ぎのDLP展開や自動ラベル付け展開では、この遅延をスケジュールに組み込む必要があります。(Microsoft Learn)
既存ポリシーの管理者を失う
restricted administratorは、Administrative units割り当て後に既存ポリシーを見られなくなる可能性があります。既存ポリシーを誰が維持するのか、必要ならunrestricted administratorを残すのか、ポリシーを分割して移行するのかを事前に決めておきましょう。(Microsoft Learn)
どのような組織が優先して対応すべきか
Administrative units in Microsoft Purviewの見直しを優先すべきなのは、次のような組織です。
| 組織の状態 | 優先度 | 理由 |
|---|---|---|
| 複数地域・複数法人でMicrosoft Purviewを運用している | 高 | 地域ごとの管理委任と最小権限を両立しやすい |
| DLPや秘密度ラベルを部門ごとに運用している | 高 | 部門管理者の権限を対象範囲に限定できる |
| SharePointサイト単位のDLPや自動ラベル付けを強化したい | 高 | 2026年6月更新で確認すべき影響が大きい |
| 全社管理者アカウントが多い | 高 | EntraロールとPurviewロールの棚卸しが必要 |
| 小規模で管理者が1〜2名のみ | 中 | すぐに導入するより、将来の権限分離に備えた設計確認が有効 |
| Purviewをまだ一部機能でしか使っていない | 中 | ライセンスと対象機能を確認しながら段階導入するとよい |
特に、DLP、秘密度ラベル、自動ラベル付け、保持ポリシーをすでに本番運用している組織では、Administrative unitsを単なる新機能としてではなく、権限設計・監査設計・ポリシー設計の見直しポイントとして扱うべきです。
まず取るべき対応
最初に行うべきことは、Microsoft PurviewのロールグループとMicrosoft Entraロールの棚卸しです。Administrative unitsでスコープ制限したつもりでも、Entraロールによって広い権限が残っていると、最小権限の設計になりません。
次に、DLPや自動ラベル付けでSharePointサイトを対象にしている場合は、サイト一覧、サイト命名規則、SharePoint管理プロパティ、RefinableStringの利用状況を確認してください。Administrative unitsに関連付けるクエリは、運用部門名ではなく、管理対象を安定して識別できる属性で作るのが安全です。
最後に、いきなり全社展開せず、1部門または1地域でパイロットを行います。テスト用のrestricted administratorを用意し、ポリシー作成、既存ポリシー表示、アラート確認、Activity explorerの見え方、SharePointサイトメンバーの反映を確認してから本番ロールへ展開しましょう。
Administrative units in Microsoft Purviewは、全社管理者を減らしながら、現場に近い単位でコンプライアンス運用を委任できる重要な機能です。2026年6月の更新内容を踏まえると、特にSharePointサイトを含むDLPや自動ラベル付けを運用している組織は、権限・ポリシー・反映時間の3点を優先して確認することが、トラブルを避ける近道です。
コメント