Microsoft PurviewでSharePoint向けDLPポリシーを運用している管理者にとって、「Microsoft Purview: Data Loss Prevention- Adaptive Scopes for DLP for SharePoint」は、サイト指定の運用を大きく楽にする更新です。結論から言うと、これまで手作業でSharePointサイトをDLPポリシーに追加・削除していた運用を、サイトURL、サイト名、カスタムサイトメタデータなどの条件に基づいて自動化できるようになります。Microsoft 365 Roadmap ID 549288では、静的なサイト指定ではなく、条件に合うサイトを継続的に評価してDLP対象へ自動的に含める、または除外する機能として説明されています。(Microsoft)
ただし、これは「既存ポリシーが自動で安全に最適化される」更新ではありません。管理者がAdaptive Scopeの条件を設計し、既存のDLPポリシーへ適用し、シミュレーションや段階展開で影響を確認する必要があります。特に、SharePointサイトが多い企業、プロジェクトサイトが頻繁に作られる組織、Microsoft 365 Copilot利用に向けてSharePoint上の機密情報管理を強化したい組織では、早めに設計を見直す価値があります。
Microsoft Purviewのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
2026年5月27日更新相当のMicrosoft 365 Roadmap情報では、この機能はMicrosoft PurviewのDLP向け更新として扱われています。ロードマップ上の対象はWorldwideの標準マルチテナント環境、プラットフォームはWeb、ステータスはIn development、プレビューは2026年2月、一般提供は2026年8月予定です。ロードマップ情報は予定であり、Microsoft自身も公開情報は変更される可能性があると明記しています。(Microsoft)
| 確認項目 | 内容 |
|---|---|
| Roadmap ID | 549288 |
| 対象サービス | Microsoft Purview Data Loss Prevention |
| 対象ワークロード | SharePoint向けDLPポリシー |
| 主な変更 | SharePointサイトのDLP適用範囲を動的条件で指定できる |
| 対象条件の例 | サイトURL、サイト名、カスタムサイトメタデータ |
| プレビュー | 2026年2月予定 |
| 一般提供 | 2026年8月予定 |
| 展開対象 | Worldwide、Web、Microsoft Purview |
今回のポイントは、DLPルールそのものの検出条件やアクションが変わることではなく、どのSharePointサイトにDLPポリシーを適用するかを柔軟に管理できるようになる点です。
Adaptive Scopes for DLP for SharePointとは
Adaptive Scopes for DLP for SharePointは、SharePointサイトを1つずつDLPポリシーに登録するのではなく、条件に合致するサイトを自動的にDLPポリシーの対象にする仕組みです。
たとえば、次のような考え方でDLP対象を決められます。
| シナリオ | Adaptive Scopeでの考え方 |
|---|---|
| 機密プロジェクトサイトをすべて保護したい | サイトURLやサイト名の命名規則で対象化する |
| 特定部門のSharePointサイトだけDLPを強化したい | サイト名やカスタムサイトプロパティで部門を判定する |
| 外部共有リスクの高いサイトを継続的に監視したい | 「社外共有用途」「顧客共有」などのメタデータを条件にする |
| 新規作成サイトのDLP漏れを防ぎたい | サイト作成時に命名規則やメタデータを付与し、自動的に対象化する |
従来の静的スコープでは、対象サイトを手動でリスト管理する必要がありました。Microsoft LearnのDLPポリシーリファレンスでは、SharePointロケーションのスコープ指定は特定サイトおよびAdaptive Scopeに限定でき、静的なSharePointサイト指定では最大100サイトまでと説明されています。(Microsoft Learn)
今回のRoadmap項目では、Adaptive Scopeによってこの100サイトの静的指定上限を回避し、よりスケーラブルで自動化されたポリシー展開が可能になるとされています。(Microsoft)
静的スコープとAdaptive Scopeの違い
SharePoint DLPを小規模に運用している場合、静的スコープでも十分なケースはあります。しかし、サイト数が増えるほど、手動管理は抜け漏れや棚卸し負荷の原因になります。
| 比較項目 | 静的スコープ | Adaptive Scope |
|---|---|---|
| 対象指定 | サイトを手動で指定 | 条件に合うサイトを動的に指定 |
| 新規サイト対応 | 管理者が追加する必要がある | 条件に合えば自動的に対象化 |
| サイト数が多い場合 | 管理負荷が増える | 大規模環境に向く |
| 設計の難しさ | 初期設定は分かりやすい | 命名規則・メタデータ設計が重要 |
| 失敗しやすい点 | 追加漏れ、削除漏れ | 条件設計ミス、メタデータ未整備 |
| 向いている環境 | 対象サイトが少なく固定的 | サイトが頻繁に増減する組織 |
特に注意したいのは、Adaptive Scopeは「便利な自動化」ですが、条件が曖昧だと誤って対象外にしてしまうリスクもあることです。たとえば、サイト名に「confidential」が含まれることを条件にした場合、命名規則を守らず作成された機密サイトはDLP対象から外れる可能性があります。
影響を受ける管理者・開発者
この更新で直接対応が必要になるのは、主にMicrosoft Purview、SharePoint、Microsoft 365の管理者です。エンドユーザーのSharePoint画面が大きく変わる更新ではありませんが、DLPポリシーの適用範囲が変われば、共有ブロック、ポリシーヒント、管理者アラートなどの発生範囲は変わります。
管理者が影響を受ける範囲
Microsoft PurviewのDLP管理者は、既存のDLPポリシーでどのSharePointサイトを対象にしているかを確認する必要があります。これまで手作業でサイトURLを追加していたポリシーは、Adaptive Scopeへ置き換える候補になります。
SharePoint管理者は、サイトの命名規則、テンプレート、カスタムサイトプロパティ、検索インデックスの状態を確認する必要があります。Adaptive Scopeで使えるSharePointサイトのプロパティには、Site URL、Site name、SharePoint向けカスタムプロパティであるRefinableString00〜RefinableString99が含まれます。(Microsoft Learn)
セキュリティ・コンプライアンス担当者は、どの種類のサイトを保護対象にすべきかを業務リスクから定義する必要があります。「すべてのサイトを強く制限する」だけでは、共同作業の妨げになる場合があります。機密度、外部共有の有無、部門、データ種別ごとに、DLPの強度を分ける設計が現実的です。
開発者・自動化担当者が確認すべき範囲
SharePointサイトをPower Automate、PnP PowerShell、Microsoft Graph、社内ポータルなどで自動作成している場合は、サイト作成プロセスに注意が必要です。Adaptive Scopeはサイトの属性を見て対象判定するため、作成時点で命名規則やメタデータが正しく付与されないと、DLP対象に入らない可能性があります。
開発者や自動化担当者は、サイト作成フローに次の観点を組み込むべきです。
- サイトURLやサイト名に一貫したプレフィックスを付ける
- 機密度、部門、用途などのサイトメタデータを必須化する
- テンプレートごとにDLP対象となる条件を整理する
- サイト作成後にメタデータ付与が遅れる設計を避ける
- DLP対象外サイトを例外として記録できる運用にする
Adaptive Scopeの効果は、Purview側の設定だけでなく、SharePointサイトの作られ方に大きく左右されます。
設定前に確認すべきチェックポイント
Adaptive Scopeを作る前に、いきなり条件を設定するのは避けるべきです。まずは既存のDLPポリシーとSharePointサイトの実態を棚卸しします。
| 確認項目 | 確認する理由 |
|---|---|
| 既存DLPポリシーの対象サイト | どの静的スコープをAdaptive Scope化できるか判断するため |
| サイトURLの命名規則 | URL条件で安定して対象化できるか確認するため |
| サイト名の運用実態 | サイト名変更でスコープから外れるリスクを確認するため |
| カスタムサイトプロパティ | メタデータベースの対象化が可能か確認するため |
| SharePoint検索のインデックス | KeyQLや管理プロパティを使う場合の前提になるため |
| Purviewの権限 | Adaptive Scope作成やDLPポリシー編集ができるか確認するため |
| ライセンス | テナントで対象機能を利用できるか確認するため |
| 既存アラート運用 | 対象拡大でアラート量が増えても対応できるか確認するため |
Adaptive Scopeを作成するには、Scope Managerロールを含むロールグループが必要です。Microsoft Learnでは、Compliance Administrator、Compliance Data Administrator、Organization ManagementなどがScope Managerロールを含む組み込みロールグループとして示されています。(Microsoft Learn)
DLPポリシーの作成・展開に使うアカウントについても、Compliance administrator、Compliance data administrator、Information Protection、Security administratorなどのロールグループが必要です。(Microsoft Learn)
Adaptive Scopeの設定手順
実際の設定は、Microsoft Purviewポータルから行います。Microsoft Learnでは、Microsoft Purview portalのSettings > Roles and scopes > Adaptive scopesから作成する手順が案内されています。(Microsoft Learn)
| 手順 | 作業内容 | 実務上のポイント |
|---|---|---|
| 1 | 対象にしたいSharePointサイトの条件を決める | URL、サイト名、カスタムプロパティのどれを主条件にするか決める |
| 2 | Microsoft Purviewポータルを開く | Settings > Roles and scopes > Adaptive scopesへ進む |
| 3 | + Create scopeを選ぶ | 名前は後から見ても用途が分かるものにする |
| 4 | スコープタイプを選ぶ | SharePoint sitesを選択する |
| 5 | 条件を設定する | シンプルクエリまたはAdvanced query builderを使う |
| 6 | メンバーシップを確認する | Scope detailsで含まれるサイトを確認する |
| 7 | DLPポリシーに割り当てる | 既存ポリシーをすぐ置き換えず、検証用から始める |
| 8 | シミュレーションで確認する | 誤検知、対象漏れ、アラート量を確認してから本番適用する |
高度なクエリを使う場合、SharePointサイトスコープではKeyword Query Language、つまりKeyQLを使用します。Microsoft Learnでは、モダンコミュニケーションサイトのみを含める例として次のクエリが示されています。(Microsoft Learn)
SiteTemplate=SITEPAGEPUBLISHING同じ説明では、SharePointサイトスコープにはMicrosoft 365グループ接続サイト、Teamsプライベートチャネルサイト、クラシックチームサイト、OneDriveサイトなど複数のサイトタイプが含まれるため、SiteTemplateで含める・除外する設計が有効とされています。(Microsoft Learn)
失敗しやすいポイント
Adaptive Scopeは自動化の仕組みですが、設定した瞬間に期待どおりの対象がすぐ反映されるわけではありません。Microsoft Learnでは、クエリは即時実行されず、入力値の正しさもその場で検証されないと説明されています。また、クエリが完全に反映されるまで最大5日かかる場合があるため、新しく作成したスコープをすぐ本番ポリシーに追加しないよう注意が必要です。(Microsoft Learn)
URLやサイト名だけに依存する
URLやサイト名は分かりやすい条件ですが、長期運用では変更される可能性があります。たとえば、部署名変更、プロジェクト名変更、サイト統合があると、条件に合わなくなる場合があります。
安定運用を目指すなら、URLやサイト名だけでなく、機密度や用途を表すカスタムサイトプロパティを併用する設計が向いています。
カスタムメタデータが整備されていない
Roadmapではカスタムサイトメタデータが対象条件の例に挙げられていますが、実務では「どのサイトにも同じ項目が正しく入っている」状態を作る必要があります。サイト作成者が任意で入力する運用では、値の揺れが起きます。
たとえば、同じ意味でも「Confidential」「confidential」「機密」「社外秘」が混在すると、意図したスコープになりません。選択式の項目、サイトテンプレート、作成ワークフローで値を統一することが重要です。
Administrative Unitsと混同する
Microsoft Learnでは、Adaptive Scope作成時にAdministrative Unitを選択すると、SharePoint sitesのAdaptive Scopeを作成できないと説明されています。(Microsoft Learn)
一方で、DLPポリシーリファレンスでは、SharePointサイトをAdministrative Unitに追加し、SharePointロケーションのDLPポリシーをAdministrative Unitに割り当てる機能も説明されています。(Microsoft Learn)
つまり、Administrative Unitによる管理境界と、Adaptive Scopeによる動的なサイト選定は、似て見えても同じものではありません。権限委任のためにAdministrative Unitを使いたいのか、DLP対象サイトを動的に選びたいのかを分けて設計してください。
既存ポリシーをいきなり置き換える
既存の静的スコープをすぐ削除してAdaptive Scopeへ切り替えると、条件ミスによって一部サイトがDLP対象外になる可能性があります。まずは検証用ポリシーまたはシミュレーションで、静的スコープの対象サイトとAdaptive Scopeのメンバーが一致するか確認します。
DLPのシミュレーションモードでは、実際のブロックなどのアクションを適用せずにポリシーの影響を確認できます。Microsoft Learnでは、シミュレーションモードをポリシー作成・展開プロセスに組み込み、誤検知を減らしながら本番適用前に検証することが推奨されています。(Microsoft Learn)
移行・展開のおすすめ手順
既存のSharePoint DLPポリシーをAdaptive Scopeへ移行する場合は、段階的に進めるのが安全です。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 棚卸し | 既存DLPポリシーと対象サイトを一覧化 | どのポリシーが静的指定に依存しているか分かる |
| 設計 | URL、サイト名、メタデータの条件を決める | 人が見ても条件の意味を説明できる |
| 試作 | Adaptive Scopeを作成 | 想定サイトが含まれ、対象外サイトが混入していない |
| 検証 | Scope detailsやSharePoint検索で確認 | メンバーシップが業務部門の想定と一致する |
| シミュレーション | DLPポリシーをシミュレーションで実行 | アラート量、誤検知、業務影響が許容範囲 |
| 段階展開 | 低リスク部門や限定サイトから適用 | 問い合わせ・例外申請が運用可能 |
| 本番化 | 静的スコープを廃止または縮小 | 監査ログ、DLPアラート、利用者影響を継続確認 |
Microsoft Learnでは、DLPポリシーの展開はスコープ、状態、アクションの3軸で段階的に管理し、最も影響の少ないシミュレーションモードから始めてフル適用へ進む考え方が示されています。(Microsoft Learn)
実務で使いやすい設計例
Adaptive Scopeを活かすには、「条件をどう書くか」より先に、「どの業務リスクを守りたいか」を決めることが大切です。
例：顧客共有サイトを自動的にDLP対象にする
顧客とファイルを共有するサイトは、社外共有による情報漏えいリスクが高くなります。この場合は、サイト作成時に「ExternalCollaboration」や「CustomerProject」のような用途情報を付け、該当するサイトをDLP対象にする設計が考えられます。
この設計では、URLやサイト名が多少変わっても、用途メタデータが維持されていればDLP対象から外れにくくなります。
例：機密プロジェクトだけDLPを強化する
すべてのSharePointサイトに強いDLP制御をかけると、通常業務の共有まで止まる可能性があります。そこで、機密度が高いプロジェクトサイトだけを対象に、外部共有ブロック、通知、管理者アラートを強める設計が有効です。
この場合は、機密度を表すサイトプロパティを設け、プロジェクト開始時点で必ず分類する運用にします。
例：コミュニケーションサイトだけを対象にする
社内ポータルや全社公開情報を扱うモダンコミュニケーションサイトだけを対象にしたい場合は、SiteTemplateのようなサイト種別を使った設計が候補になります。Microsoft Learnでは、SharePointサイトスコープの高度なクエリでSiteTemplateを利用する例が示されています。(Microsoft Learn)
管理者が今すぐ確認すべきこと
この更新は、一般提供を待ってから考えるより、既存DLPとSharePointサイト管理の棚卸しを先に進める方が効果的です。
まず確認すべきことは次の5つです。
- SharePoint向けDLPポリシーで、静的に指定しているサイト数を確認する
- サイト追加・削除を誰が、どの頻度で行っているか確認する
- サイト命名規則と実際のサイト名が一致しているか確認する
- 機密度や用途を表すサイトメタデータがあるか確認する
- DLPポリシーを変更できる管理者権限と承認フローを確認する
特に、SharePointサイトが100件に近い、または100件を超える単位で管理されている場合は、Adaptive Scopeの導入効果が大きくなります。逆に、対象サイトが数件でほとんど変わらない場合は、静的スコープのままでも運用上の問題が少ないかもしれません。
まとめ：Adaptive ScopeはDLP運用を「手作業」から「条件設計」へ変える
Microsoft PurviewのAdaptive Scopes for DLP for SharePointは、SharePoint向けDLPポリシーの適用対象を、静的なサイト一覧管理から動的な条件管理へ移行するための重要な更新です。サイトURL、サイト名、カスタムサイトメタデータを使って対象サイトを自動判定できるため、サイト数が多い組織や、新規サイトが頻繁に作成される環境では大きな運用改善が期待できます。
一方で、効果を出すには、SharePointサイトの命名規則、メタデータ設計、作成フロー、DLPポリシーのシミュレーションが欠かせません。まずは既存のSharePoint DLPポリシーを棚卸しし、静的スコープに依存しているポリシーを洗い出してください。そのうえで、低リスクな範囲からAdaptive Scopeを試作し、メンバーシップとDLPシミュレーション結果を確認してから本番展開するのが安全です。
コメント