Microsoft Purview の運用が成熟してくると、多くの大企業で同じ課題が出てきます。DLP ポリシー、アラート、調査、例外対応をすべて中央チームだけで抱えると遅くなり、かといって地域・事業部ごとに自由に運用させるとガバナンスが分断されます。
この課題に対する現実的な答えが、Microsoft Purview で Administrative Units（管理単位、以下 AU）を使って運用範囲を分離する設計です。AU を使うと、地域、事業部、規制対象部門などに合わせて Purview の管理・可視性・ポリシー運用を「囲い込む」ことができます。一方で、分類、ベースラインポリシー、全体監視といった中央ガバナンスは維持できます。
2026年4月18日時点の最新動向として、Microsoft は Purview の成熟した運用モデルにおいて、AU を使った ring-fenced operations、つまり明確な境界を持つ分散運用を重要なアーキテクチャとして示しています。特に Microsoft Purview Data Loss Prevention（DLP）を大規模展開する組織では、複数テナントや部門別 DLP 製品に分ける前に、AU による分散統制を検討する価値があります。Microsoft の公開情報でも、AU は管理者の権限と可視性を特定の単位に制限しつつ、グローバルな監視や共通サービスを維持する方法として説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview の Administrative Units とは
Microsoft Purview における Administrative Units は、Microsoft Entra ID の管理単位を Purview の権限管理やポリシー運用に活用する仕組みです。簡単に言えば、組織全体を「日本法人」「欧州地域」「金融事業部」「役員グループ」などの論理的な単位に分け、それぞれの担当者に、その範囲だけを管理・閲覧させるための設計です。
Microsoft Learn では、Entra ID の AU によって組織を小さな単位に分割し、管理権限を Microsoft Entra 組織内の特定部分に制限できると説明されています。Purview はこの仕組みと連携し、AU がサポートされる Purview ソリューションで、割り当てられた単位内に可視性と管理権限を制限します。(Microsoft Learn)
たとえば、次のような運用が可能になります。
| 目的 | AU を使わない場合の課題 | AU を使った場合の設計 |
|---|---|---|
| 地域別 DLP 運用 | 本社チームが全地域のアラートを処理し、現地事情を反映しにくい | APAC、EMEA、Americas などの AU に分け、地域担当者が自分の範囲だけを管理 |
| 事業部別の機密情報保護 | 事業部ごとの規制や業務リスクを中央チームが細かく把握しにくい | 金融、医療、研究開発などの AU に分け、ローカルポリシーを調整 |
| 役員・法務・人事など高感度ユーザーの監視 | 一般の DLP アナリストに見せるべきでないアクティビティまで見える | 専用 AU を作り、限られたアナリストだけが確認 |
| グローバル統制 | 部門別に製品やテナントを分けると全体監視が難しい | 中央チームは全体ポリシー、分類、レポートを維持 |
重要なのは、AU は単なる「ユーザーの整理用フォルダー」ではないという点です。Purview では、誰がどのユーザー、アラート、アクティビティ、ポリシーを見られるかに影響します。そのため、DLP やコンプライアンス運用の権限設計そのものとして扱う必要があります。
なぜ大規模組織で AU による分散運用が必要になるのか
Purview の導入初期は、中央の情報システム部門やコンプライアンスチームが少数のグローバルポリシーを管理する形でも運用できます。しかし、対象部門、対象地域、保護対象データ、DLP アラートが増えると、中央集権型の運用には限界が出てきます。
よくある失敗は次の2つです。
1つ目は、部門や地域ごとに別々の DLP ツールやテナントを使い始めることです。短期的には現場が動きやすくなりますが、ポリシーの重複、検出ルールのばらつき、監査レポートの分断、ライセンスや運用コストの増加につながります。
2つ目は、すべてを中央チームが抱え続けることです。中央チームは全体統制には強い一方で、地域ごとの法規制、部門固有の業務フロー、現場の例外判断まで即座に処理するのは困難です。結果として、アラート対応が遅れたり、現場が DLP を「業務を止める仕組み」と感じたりします。
Microsoft の Tech Community でも、大規模な Purview 展開が成熟すると、分散運用しながらガバナンスや可視性を失わない方法が課題になると説明されています。AU は、複数テナントや別々の DLP プラットフォームを作らずに、明確な境界を持つ運用モデルを実現する方法として位置づけられています。(TECHCOMMUNITY.MICROSOFT.COM)
AU で分散してよい領域、中央に残すべき領域
AU 設計で最も重要なのは、「何を分散し、何を中央に残すか」を最初に決めることです。すべてを現場に渡すとガバナンスが崩れます。逆に、すべてを中央に残すと AU を使う意味が薄れます。
中央チームに残すべき機能
中央チームは、組織全体で一貫性が必要な領域を持つべきです。
| 中央に残す領域 | 理由 |
|---|---|
| グローバルなベースラインポリシー | 最低限の情報保護レベルを全社でそろえるため |
| 機密情報の分類、SIT、分類器、再利用可能なコンポーネント | 部門ごとに検出条件が分裂すると、同じ情報が別々に扱われるため |
| 全社監視、レポート、監査対応 | 分散運用しても経営・監査・セキュリティ統括は全体像を見る必要があるため |
| Purview のロール設計と AU 命名規則 | 権限の乱立を防ぎ、棚卸ししやすくするため |
| テナント全体の制限やプラットフォーム設計 | AU はテナント全体のサービス制限を変えるものではないため |
Microsoft の公開情報でも、分類器や再利用可能なコンポーネントなどの共有サービスは中央に残し、AU ごとの運用は RBAC とデータ可視性境界で制御するモデルが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
AU 側に委任しやすい機能
一方で、現場の文脈が重要な作業は AU 側に委任しやすい領域です。
| AU 側に委任する領域 | 具体例 |
|---|---|
| AU スコープの DLP ポリシー作成・調整 | 日本法人向けにマイナンバーや取引先情報の検出を厳しめにする |
| ローカルアラートの一次対応 | 地域担当の DLP アナリストが自分の AU 内のアラートを調査する |
| 業務部門固有の例外判断 | 研究開発部門の外部共有ルールを、中央基準の範囲内で調整する |
| インシデント初動 | 現場の上長や法務担当と連携して、誤検知・真陽性を切り分ける |
| 規制・業務要件に応じた運用チューニング | EU、米国、日本など地域ごとの運用要件を反映する |
この分担により、中央は「ルールの一貫性」と「全体監視」を担い、AU 側は「現場に近い運用」と「早い判断」を担う形になります。
Purview DLP で AU を使うと何が変わるのか
Microsoft Purview DLP では、AU を使うことで、ポリシーの適用範囲や管理者の可視性を制御できます。Microsoft Learn では、DLP ポリシーのスコープはまず組織全体または AU のようなサブグループで定義され、そのうえで DLP がサポートする場所単位のスコープが適用されると説明されています。AU 制限付き管理者は、自分に割り当てられた AU だけを選択できます。(Microsoft Learn)
特に重要なのは、ポリシーの適用範囲と管理者の可視範囲の両方に影響する点です。
無制限管理者と AU 制限付き管理者の違い
| 管理者の種類 | できること | 注意点 |
|---|---|---|
| 無制限管理者 | 組織全体の DLP ポリシーを作成・編集し、すべてのアラートやイベントを確認できる | 強い権限を持つため、人数を絞り、監査対象にする |
| AU 制限付き管理者 | 割り当てられた AU にスコープされた DLP ポリシーを作成・編集し、その範囲のアラートやイベントを確認できる | 全社ポリシーや他 AU のアラートは見えない前提で運用設計する |
Microsoft Learn では、AU 制限付き管理者は、割り当てられた AU に対してのみ DLP ポリシーを作成・スコープ設定でき、該当する DLP ポリシーのアラートやイベントだけを表示できるとされています。(Microsoft Learn)
代表的な AU アーキテクチャ
AU の設計は、組織構造をそのまま写すだけでは不十分です。誰が何を管理し、どのアラートを見て、どのポリシーを変更できるべきかを基準に設計します。
地域・事業部ごとのリングフェンス運用
最も基本的なモデルは、地域や事業部ごとに AU を作る形です。
例として、グローバル企業が次のように分けるケースがあります。
| AU | 主な対象 | 担当チーム |
|---|---|---|
| AU-Japan | 日本法人のユーザー、必要に応じて関連 SharePoint サイト | 日本の DLP 管理者・アナリスト |
| AU-EMEA | 欧州・中東・アフリカ地域のユーザー | EMEA コンプライアンスチーム |
| AU-Americas | 米州地域のユーザー | Americas セキュリティチーム |
| AU-RD | 研究開発部門のユーザー | R&D セキュリティ担当 |
このモデルでは、中央チームが全社共通の DLP ベースラインを作り、各 AU の担当チームが地域・部門固有のポリシーやアラート対応を担当します。Microsoft の参照アーキテクチャでも、中央ガバナンス、AU、事業部レベルの運用という3層に分けるモデルが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上は、最初から全社に広げるより、1つの地域または1つの事業部でパイロットを行うのが安全です。既存の DLP ポリシー、誤検知、アラート量、担当者の判断基準を確認してから横展開すると、権限設計の手戻りを減らせます。
役員・人事・法務など高感度ユーザーの分離
AU は、単純な地域分けだけでなく、高感度ユーザーの可視性を制限する用途にも向いています。
たとえば、役員や人事部門の DLP アラートは、一般の地域アナリストには見せず、専任の少人数チームだけが確認する設計が考えられます。Microsoft の参照アーキテクチャでも、役員、HR、Legal、高感度なユーザー集団に対して、専用 AU により可視性を分離するパターンが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、この設計ではユーザーの AU 所属を慎重に扱う必要があります。誰がどの AU に属しているかによって、アラートやアクティビティの見え方が変わるためです。役員を地域 AU と役員 AU の両方に入れるのか、専用 AU に寄せるのかは、調査権限と業務責任の観点で決めます。
複数 AU にまたがるユーザーの扱い
現実の組織では、ユーザーが1つの所属だけに収まらないことがあります。たとえば、グローバル役員、共有サービス部門のリーダー、地域と事業部の両方を担当する管理職などです。
Microsoft の説明では、ユーザーアクティビティは、そのアクティビティ発生時点でユーザーが属していた AU の合計で扱われるとされています。また、AU に割り当てられた DLP アナリストは、自分の AU 内のユーザーについて、別 AU にスコープされたポリシーによって生成されたアクティビティであっても確認できる場合があります。これは、調査コンテキストを失わないための重要な挙動です。(TECHCOMMUNITY.MICROSOFT.COM)
設計上のポイントは、複数 AU 所属を例外扱いにしないことです。役員、兼務者、共有サービス部門など、複数 AU にまたがりやすいユーザー群を事前に洗い出し、「誰が見えるべきか」「誰が見えてはいけないか」を明文化しておく必要があります。
AU を導入すべきケース、導入しないほうがよいケース
AU は強力ですが、すべての Purview 環境に必要なわけではありません。導入判断を誤ると、かえって運用が複雑になります。
AU を導入すべきケース
次の条件に当てはまる場合は、AU の導入価値が高いです。
| 判断基準 | 具体例 |
|---|---|
| 地域・事業部ごとに DLP 運用チームがある | APAC、EMEA、Americas で担当者が分かれている |
| 管理者やアナリストの可視範囲を制限したい | 日本法人のアラートを他地域の担当者に見せたくない |
| 高感度ユーザーのアクティビティを限定公開したい | 役員、人事、法務、M&A 関連チーム |
| 複数の DLP 製品やテナントを統合したい | 旧システムを廃止し、Purview に集約する |
| 中央統制と現場裁量を両立したい | 全社共通の分類・監査は中央、例外対応は現場 |
特に、「どのユーザーを保護するか」だけでなく、「誰がそのユーザーのアラートやアクティビティを見てよいか」が問題になる場合、AU は有力な選択肢です。
AU を導入しないほうがよいケース
一方で、次のような環境では AU を急いで導入しないほうがよい場合があります。
| 状況 | 理由 |
|---|---|
| コンプライアンスチームが1つだけで、全員が全体を見てよい | 可視性を分ける要件がないため、複雑さだけが増える |
| Purview 導入初期で、グローバルポリシーが少ない | まずは中央運用で検出精度や運用フローを固めたほうがよい |
| 単にポリシーの対象者を動的に絞りたいだけ | Adaptive scopes など別の仕組みで足りる可能性がある |
| 組織構造や責任分界が頻繁に変わる | AU メンバーシップと権限のメンテナンス負荷が高くなる |
| 管理者の棚卸しプロセスがない | 権限委任後に過剰権限を見逃しやすい |
Microsoft の Tech Community でも、単一の中央チームで全体を管理している場合や、可視性・管理分離の要件がない場合、初期または小規模な Purview 展開では AU の価値が限定的になると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
AU 導入の実務手順
AU の導入は、単に Entra ID で管理単位を作る作業ではありません。Purview のロール、DLP ポリシー、アラート対応、監査、例外運用を含めた変更として進めるべきです。
まず運用責任をマッピングする
最初にやるべきことは、組織図ではなく「運用責任」の整理です。組織図どおりに AU を作ると、不要に細かくなりがちです。
以下の観点で整理します。
| 確認項目 | 判断例 |
|---|---|
| 誰が DLP ポリシーを作るのか | 中央のみ、地域別、事業部別 |
| 誰がアラートを一次確認するのか | SOC、地域チーム、部門セキュリティ担当 |
| 誰が例外を承認するのか | 中央コンプライアンス、現地法務、事業部責任者 |
| 誰に見せてはいけないアクティビティがあるか | 役員、人事、法務、研究開発 |
| 全社で統一すべきルールは何か | 個人情報、財務情報、認証情報、ソースコードなど |
この時点で、AU の単位を「地域」「事業部」「高感度ユーザー群」「規制対象部門」のどれに寄せるかを決めます。
AU の命名規則を決める
AU は後から増えるため、命名規則を決めておくことが重要です。
例：
| 用途 | 命名例 |
|---|---|
| 地域 | AU-Region-Japan、AU-Region-EMEA |
| 事業部 | AU-BU-Finance、AU-BU-RD |
| 高感度ユーザー | AU-Sensitive-Executives、AU-Sensitive-HR |
| テスト | AU-Test-DLP-Japan |
命名規則には、地域名、事業部名、用途、環境区分を含めると棚卸ししやすくなります。逆に、「AU1」「DLP-Team-A」のような名前は、半年後に意図が分からなくなります。
Entra ID で AU とメンバーシップを設計する
AU の作成、削除、ユーザーやグループのメンバー管理は Microsoft Entra ID 側で行います。Purview はその AU を参照し、ロールグループやポリシーのスコープに利用します。Microsoft Learn でも、AU の作成やメンバー管理は Entra ID で行い、Purview の対応ソリューションで role group のメンバーを特定の AU に割り当てる流れが示されています。(Microsoft Learn)
実務では、次の点を確認します。
| 項目 | 注意点 |
|---|---|
| 動的メンバーシップ | 部署、国、属性を使う場合は、人事データや Entra ID 属性の品質が重要 |
| 手動メンバーシップ | 少人数の高感度ユーザーには有効だが、棚卸しが必須 |
| 兼務者 | 複数 AU 所属時の可視性を事前にテストする |
| 退職・異動 | AU から外れないと、想定外の可視性やポリシー対象が残る可能性がある |
Purview のロールグループに AU を割り当てる
Purview 側では、対応するロールグループのメンバーに AU を割り当てます。Microsoft Learn では、AU をロールグループメンバーに割り当てるには Role management ロールが必要で、対応する組み込みロールグループやカスタムロールグループで AU の割り当てが可能とされています。(Microsoft Learn)
設計の基本は、以下の3層です。
| 層 | 役割 | 権限設計 |
|---|---|---|
| 中央管理者 | 全体設計、ベースライン、監査、例外ルール | 無制限管理者を少人数に限定 |
| AU 管理者 | 自 AU の DLP ポリシー作成・調整 | 対象 AU のみに制限 |
| AU アナリスト | 自 AU のアラート調査・一次対応 | 調査に必要な最小権限に限定 |
カスタムロールグループを使う場合は、既定ロールをコピーして安易に強い権限を付けるのではなく、「ポリシー編集が必要か」「アラート閲覧だけでよいか」「監査ログ検索が必要か」を分けて設計します。
既存ポリシーへの影響を確認する
AU を割り当てたあと、制限付き管理者が既存ポリシーや過去データをどう見えるかは重要な確認ポイントです。Microsoft Learn では、ロールグループメンバーに AU を割り当てると、制限付き管理者は既存ポリシーを表示・編集できず、既存ポリシー自体の動作は変わらず、無制限管理者からは引き続き表示・編集できると説明されています。また、Activity explorer や alerts など AU 対応機能の履歴データについても、制限付き管理者には過去データが見えず、以後は割り当て AU の関連データのみ見えるとされています。(Microsoft Learn)
導入時には、次の確認を必ず行いましょう。
| 確認項目 | 見るべきポイント |
|---|---|
| 既存 DLP ポリシー | 誰が編集できるか、AU 管理者から見えるか |
| アラート履歴 | 制限付き管理者の画面で過去データがどう見えるか |
| Activity explorer | AU 内ユーザーのアクティビティだけが見えるか |
| レポート | 中央チームの全体レポートが維持されるか |
| 例外処理 | AU 管理者が必要な操作を実行できるか |
本番適用前に、テスト AU とテストユーザーを用意し、管理者別に画面を確認することをおすすめします。
SharePoint サイトを AU に含める場合の注意点
Purview では、ユーザーだけでなく SharePoint サイトを AU に関連付けるサポートもあります。Microsoft Learn では、Microsoft Purview が SharePoint サイトを AU に追加する機能をサポートし、Microsoft Information Protection の自動ラベル付けポリシーと、SharePoint サイトに適用される DLP ポリシーで利用できると説明されています。(Microsoft Learn)
DLP の観点では、SharePoint の場所に対して AU にスコープしたポリシーを割り当てると、その AU に含まれるサイトにのみポリシーが適用されます。ただし、AU に含まれる SharePoint サイトの一部だけをさらに個別に含める、または除外するような細かいスコープ編集はできないとされています。(Microsoft Learn)
実務上の注意点は次のとおりです。
| 注意点 | 対策 |
|---|---|
| サイトの所属反映に時間がかかる場合がある | ポリシー適用直前ではなく、事前に AU への関連付けを完了する |
| サイト単位で細かく除外できない | AU のサイトクエリ設計を慎重に行う |
| サイト URL や管理プロパティの品質に依存する | SharePoint 管理者と連携し、検索結果を事前検証する |
| OneDrive や SharePoint の境界が複雑になる | ユーザー AU とサイト AU の目的を分けて文書化する |
Microsoft Learn では、SharePoint サイトを AU に関連付けるクエリが完全に反映されるまで最大5日かかる可能性があるとも説明されています。大規模環境では、変更当日に DLP ポリシーを本番投入するのではなく、反映確認の期間をスケジュールに入れておきましょう。(Microsoft Learn)
AU と Adaptive scopes の使い分け
Purview のスコープ設計では、AU と Adaptive scopes を混同しがちです。どちらも対象を絞るために使えますが、目的が違います。
| 観点 | Administrative Units | Adaptive scopes |
|---|---|---|
| 主な目的 | 管理者の権限、可視性、運用責任を分ける | ポリシー対象を属性条件などで動的に絞る |
| 典型例 | 日本チームは日本 AU のアラートだけ見る | 部署属性が Finance のユーザーに保持ポリシーを適用 |
| 権限分離 | 強い | 主目的ではない |
| 向いている課題 | 誰が見て、誰が管理するか | どのユーザーや場所に適用するか |
| 設計単位 | 運用組織、地域、部門、高感度ユーザー群 | ユーザー属性、グループ、条件 |
検索意図として「DLP の対象を自動で変えたい」だけであれば、AU ではなく Adaptive scopes のほうが自然な場合があります。逆に、「地域担当者に他地域のアラートを見せたくない」「人事関連のアクティビティを専任チームだけに見せたい」という要件があるなら、AU を検討すべきです。
Microsoft の Tech Community でも、要件が純粋にポリシー対象の動的ターゲティングであり、管理者アクセスや可視性の制限が主目的でない場合は、Adaptive scopes だけで足りる可能性があると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
失敗しやすい設計パターン
AU は便利ですが、設計を誤ると運用負荷が増えます。特に大規模組織では、次の失敗に注意が必要です。
組織図どおりに細かく作りすぎる
部門、課、チーム単位で AU を作ると、権限管理が煩雑になります。AU は「運用責任の境界」で作るべきであり、「人事上の所属」をそのまま反映するものではありません。
目安として、次の条件を満たす単位だけ AU 化するとよいでしょう。
- 独自の DLP ポリシー調整が必要
- 専任または準専任の管理者・アナリストがいる
- 他部門に見せたくないアラートやアクティビティがある
- 定期的に権限棚卸しできる
これらを満たさない小さな部門は、グループや Adaptive scopes で対象を絞るほうが運用しやすい場合があります。
中央ポリシーと AU ポリシーの優先関係を決めていない
AU ごとに自由にポリシーを作れるようにすると、同じ種類の機密情報に複数ポリシーが重なり、ユーザー体験やアラート処理が混乱します。
たとえば、中央ポリシーがクレジットカード番号の外部送信をブロックし、地域 AU のポリシーも同じ条件で警告を出すと、アラートの重複や調査責任の曖昧化が起きます。
対策として、次のように役割を分けます。
| ポリシー種別 | 担当 | 内容 |
|---|---|---|
| 全社ベースライン | 中央チーム | 認証情報、個人情報、財務情報など最低限の保護 |
| 地域・部門固有 | AU チーム | ローカル規制、業務プロセス、例外ルール |
| 高感度ユーザー向け | 専任チーム | 役員、人事、法務、M&A など |
| テスト・チューニング | 中央または AU | シミュレーション、誤検知調整 |
AU 管理者に強すぎる権限を与える
AU を設定しても、強いグローバルロールを与えてしまうと、分離の意味が薄れます。特に、無制限管理者、全体閲覧可能なロール、広範な監査ログ検索権限は慎重に扱うべきです。
AU 管理者には、必要最小限の Purview ロールを割り当て、定期的に棚卸しします。退職・異動・兼務解除のタイミングで AU 権限が残ると、想定外の可視性につながります。
過去データの見え方をテストしていない
AU を割り当てると、制限付き管理者から見える既存ポリシーや履歴データの範囲が変わります。導入後に「これまで見えていたアラートが見えない」「既存ポリシーを編集できない」と現場から問い合わせが来ることがあります。
本番前に、次のアカウントで確認しましょう。
| テストアカウント | 確認内容 |
|---|---|
| 中央管理者 | 全社ポリシー、全体アラート、全体レポートが見えるか |
| AU 管理者 | 自 AU のポリシーだけ作成・編集できるか |
| AU アナリスト | 自 AU のアラート、Activity explorer のみ見えるか |
| 他 AU の担当者 | 別 AU のユーザーやアラートが見えないか |
グローバル組織向けの実装モデル
グローバル企業で AU を導入する場合、最初から全世界を完璧に設計しようとすると時間がかかります。現実的には、以下の順序で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状整理 | 既存 DLP ポリシー、アラート量、運用担当、規制要件を棚卸し | ポリシー一覧、アラート分類、責任分界表 |
| パイロット | 1地域または1事業部で AU を作成し、DLP 運用を検証 | AU 設計書、ロール設計、テスト結果 |
| 中央基準の整備 | 全社ベースライン、命名規則、例外承認フローを定義 | グローバル DLP 標準 |
| 段階展開 | 地域・事業部ごとに AU を拡張 | 移行計画、教育資料 |
| 継続改善 | 誤検知、アラート処理時間、権限棚卸しを定期レビュー | 改善バックログ、監査証跡 |
特に重要なのは、AU 導入を「権限設定プロジェクト」ではなく「Purview 運用モデルの再設計」として扱うことです。DLP 管理者、SOC、法務、プライバシー担当、IT 管理者、事業部責任者が同じ前提を共有しないと、権限は分かれても運用が回りません。
AU 導入前のチェックリスト
最後に、Purview admins や compliance architects が導入前に確認すべき項目を整理します。
| チェック項目 | 確認内容 |
|---|---|
| 導入目的 | 可視性分離、管理委任、地域別運用など、AU を使う理由が明確か |
| AU 単位 | 組織図ではなく、運用責任の境界で設計しているか |
| 中央と分散の分担 | ベースライン、分類、監査、ローカル対応の責任者が決まっているか |
| ロール設計 | 無制限管理者と AU 制限付き管理者を分けているか |
| 既存ポリシー影響 | AU 割り当て後の見え方、編集権限、履歴データを確認したか |
| SharePoint 対応 | サイトを AU に含める場合、反映時間やクエリ条件を考慮しているか |
| 複数 AU ユーザー | 役員、兼務者、共有サービス部門の可視性を設計したか |
| 運用手順 | アラート対応、例外承認、エスカレーション、棚卸しが文書化されているか |
| 教育 | AU 管理者とアナリストに、見える範囲と見えない範囲を説明したか |
| 監査 | 誰がどの AU に割り当てられているかを定期確認できるか |
まとめ：AU は Purview を大規模運用するための権限設計である
Microsoft Purview の Administrative Units は、単なる管理対象の分類ではありません。大規模な Purview 運用で、中央ガバナンスを維持しながら、地域・事業部・高感度ユーザー単位に運用を分散するための設計要素です。
導入のポイントは明確です。
中央チームは、全社ベースライン、分類、再利用可能なコンポーネント、監査、全体監視を維持します。AU 側のチームは、自分の範囲の DLP ポリシー、アラート、調査、ローカル調整を担当します。これにより、ガバナンスを壊さずに現場のスピードを上げられます。
ただし、AU は万能ではありません。小規模環境や単一チーム運用では、導入により複雑さが増えるだけの可能性もあります。まずは「誰に何を見せるべきか」「誰がどのポリシーを管理すべきか」を整理し、1つの地域または事業部でパイロットするのが現実的です。
次に取るべき行動は、既存の Purview DLP 運用を棚卸しし、中央に残す機能と AU に委任する機能を分けることです。そのうえで、テスト AU、テストユーザー、制限付き管理者アカウントを使い、ポリシー作成、アラート表示、Activity explorer、既存ポリシーの見え方を検証しましょう。ここまで確認できれば、AU は Purview をグローバル規模で運用するための強力な土台になります。
コメント