Microsoft Purview Information Protectionでは、秘密度ラベルの発行ポリシーに、動的セキュリティ グループとメール非対応セキュリティ グループを包含する機能、およびMicrosoft 365 グループを除外する機能が追加されました。Microsoft 365 Roadmap ID 558685は、2026年7月7日23時1分（UTC）、日本時間では2026年7月8日8時1分ごろに更新され、ステータスは「Launched」とされています。これは、ラベルの暗号化方式や検出機能を変える更新ではなく、誰にラベルとポリシー設定を配布するかを柔軟にする変更です。(Microsoft)
結論として、全ユーザー向けの単一ポリシーで問題なく運用できている組織に、緊急の設定変更は必要ありません。一方、個人ユーザーを手作業で割り当てている組織、部門や雇用区分に応じて対象を自動更新したい組織、特定のMicrosoft 365グループだけを例外にしたい組織では、優先的に活用を検討する価値があります。
最初に行うべきことは、現在の発行ポリシーをエクスポートし、「どのユーザーやグループに、どのラベルと設定を配布しているか」を一覧化することです。そのうえで、動的セキュリティ グループを使った小規模なパイロットを実施します。
Microsoft Purview sensitivity-label policies gain dynamic security group inclusion and modern group exclusionとは
今回の更新は、Microsoft Purview Information Protectionの秘密度ラベル発行ポリシーにおける、対象ユーザーの指定方法を拡張するものです。
ロードマップ上の「modern groups」はMicrosoft 365グループを指します。管理者は、次のような対象指定を行えるようになります。
- 動的セキュリティ グループを発行対象に含める
- メール非対応セキュリティ グループを発行対象に含める
- Microsoft 365グループを発行対象から除外する
公式ロードマップで確認できる情報は次のとおりです。
| 項目 | 内容 |
|---|---|
| Roadmap ID | 558685 |
| 対象サービス | Microsoft Purview Information Protection |
| 主な変更 | 動的およびメール非対応セキュリティ グループの包含、Microsoft 365グループの除外 |
| ステータス | Launched |
| プレビュー予定 | 2026年4月 |
| 一般提供予定 | 2026年5月 |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| プラットフォーム | Web |
| 実質更新日 | 2026年7月8日（日本時間） |
「Launched」は、ロードマップ上では対象顧客への一般提供が完了した状態を示します。ただし、Microsoft 365 Roadmapの公開日や説明は変更される可能性があるため、実際に利用できるかどうかは自社テナントのMicrosoft Purviewポータルでも確認してください。(Microsoft)
従来の対象指定との違い
従来のMicrosoft Learnでは、秘密度ラベルの発行先として、特定ユーザー、メール対応セキュリティ グループ、配布グループ、Microsoft 365グループが案内されていました。Microsoft 365グループについては、動的メンバーシップを持つグループも対象に含まれていました。
今回の変更で重要なのは、従来から利用できた「動的メンバーシップのMicrosoft 365グループ」ではなく、動的セキュリティ グループを包含できるようになったことです。
| 項目 | 従来の主な対象 | 今回追加された選択肢 |
|---|---|---|
| ポリシーへの包含 | 特定ユーザー、メール対応セキュリティ グループ、配布グループ、Microsoft 365グループ | 動的セキュリティ グループ、メール非対応セキュリティ グループ |
| ポリシーからの除外 | 個別の例外指定を中心に設計 | Microsoft 365グループを除外対象として利用 |
| 対象者の更新 | 個人指定では手動メンテナンスが必要 | 動的グループの属性ルールにより自動更新が可能 |
| ラベルの保護設定 | 暗号化、コンテンツ マーキング、既定ラベルなど | 変更なし |
2026年7月時点では、一般的な発行手順を説明するMicrosoft Learnに従来のグループ種別が残っている場合があります。新しい対象指定を利用するときは、ロードマップだけでなく、自社テナントのポリシー編集画面に該当する選択肢が表示されるか確認するのが安全です。(Microsoft)
発行対象のグループと、ラベルを付けるグループは別物
今回の変更は、動的セキュリティ グループのメンバーに秘密度ラベル ポリシーを配布する機能です。動的セキュリティ グループ自体に秘密度ラベルを適用する機能ではありません。
例えば、次のような運用が可能になります。
- 動的セキュリティ グループ：
SG-DYN-Finance-Users - メンバー条件：財務部門に所属し、アカウントが有効なユーザー
- 発行するラベル：
社外秘 - 財務 - 発行ポリシー：
Finance-Restricted-Labels
この場合、グループの条件に一致したユーザーが「社外秘 – 財務」ラベルを利用できるようになります。しかし、SG-DYN-Finance-Usersというセキュリティ グループ自体が、暗号化やゲスト制限の対象になるわけではありません。
Microsoft Entraのクラウド セキュリティ グループ自体へ秘密度ラベルを付ける機能は、別のプレビュー機能です。そちらは2026年5月28日時点の公式情報では、動的メンバーシップのセキュリティ グループをサポートしていません。両機能を混同しないことが重要です。(Microsoft Learn)
今回の変更で何が保護対象になるのか
今回の更新で変わるのは、秘密度ラベルを利用できるユーザーの範囲です。ラベルが保護できるデータや、適用できる制御そのものが追加されるわけではありません。
秘密度ラベルの主なスコープと保護内容は次のとおりです。
| ラベルのスコープ | 主な対象 | 設定できる主な保護 |
|---|---|---|
| Files & other data assets | Officeファイル、Loop、Power BI、Microsoft Fabric、Purview Data Mapの対応データ | 暗号化、ヘッダー、フッター、透かし、自動ラベル付け |
| Emails | メール、対応する添付ファイルやメール操作 | 暗号化、コンテンツ マーキング、既定ラベル、ラベル必須化 |
| Meetings | 会議出席依頼、Teams会議オプション、関連チャット | 会議へのアクセス制御、記録やチャットに関する保護 |
| Groups & sites | Microsoft 365グループ、Teams、SharePointサイト、Loopワークスペースなど | プライバシー、ゲストアクセス、外部共有、非管理デバイスからのアクセス制御 |
Groups & sitesスコープの秘密度ラベルは、TeamsやSharePointなどのコンテナーを保護します。ただし、コンテナー内に保存された個々のファイルへ、同じ秘密度ラベルが自動適用されるわけではありません。(Microsoft Learn)
発行ポリシーでは、ラベルを表示するだけでなく、既定ラベル、ラベル付けの必須化、下位ラベルへの変更理由の入力、社内ヘルプへのリンクなども設定できます。そのため、発行対象となるユーザーが変わると、OfficeやOutlookで表示されるラベルだけでなく、保存・送信時の操作にも影響する可能性があります。(Microsoft Learn)
影響範囲と対応要否を判断する基準
今回の更新は、セキュリティ修正プログラムのように一律の緊急対応を求めるものではありません。現在のポリシー運用に、対象管理の負荷や例外処理の課題があるかどうかで対応を判断します。
| 現在の運用状況 | 対応優先度 | 判断理由 |
|---|---|---|
| 全ユーザー向けの単一ポリシーで問題がない | 低 | 新しい包含・除外機能を使う必要がない |
| ポリシーへ個人ユーザーを多数登録している | 高 | 入社、異動、退職のたびに手動更新が必要になる |
| 部門、地域、雇用区分などで対象を自動更新したい | 高 | 動的セキュリティ グループによる自動化が有効 |
| 特定のプロジェクトや外部共同作業グループを除外したい | 高 | Microsoft 365グループ単位の除外を活用できる |
| 複数ポリシーが重複し、既定ラベルや必須設定が異なる | 高 | 対象拡張によりポリシー競合が起きやすい |
| 秘密度ラベルをまだ導入していない | 低 | まずラベル体系と保護要件の設計が必要 |
| GCCなど標準マルチテナント以外のクラウドを利用している | 要確認 | Roadmap ID 558685ではWorldwide Standard Multi-Tenantのみ確認できる |
特に優先度が高いのは、機密性の高いラベルを個人単位で割り当てている組織です。個人指定は短期的には分かりやすいものの、異動や退職時の削除漏れが発生しやすくなります。
一方、動的グループを使えば安全になるとは限りません。動的メンバーシップは、ユーザー属性が条件に一致すると自動的に追加され、一致しなくなると自動的に削除されます。そのため、ポリシーの対象範囲は、departmentや雇用区分などの属性データの品質に直接依存します。Microsoftも、動的グループの安全性は、ルールで利用する属性を誰が変更できるかに左右されるため、属性の書き込み権限を監査するよう案内しています。(Microsoft Learn)
動的メンバーシップを新たに利用する場合は、ライセンスも確認してください。Microsoft Entraの動的グループには、対象となる一意のユーザー数に応じたMicrosoft Entra ID P1などのライセンス要件があります。今回のPurview機能だけでなく、動的グループ自体の利用条件を満たす必要があります。(Microsoft Learn)
管理者が行う設定と検証の進め方
現在の発行ポリシーをエクスポートする
Microsoft Purviewポータルで、次の順に開きます。
ソリューション → Information Protection → Publishing policies
設定を変更する前に、Label policiesページのエクスポート機能を使い、現在の状態をCSVまたはZIPで保存します。ZIPエクスポートでは、秘密度ラベルと発行ポリシーの設定をポイントインタイムのスナップショットとして保持できます。(Microsoft Learn)
最低限、次の項目を記録してください。
- ポリシー名
- ポリシーの優先順位
- 発行しているラベル
- 包含しているユーザーとグループ
- 除外しているユーザーとグループ
- 既定ラベル
- ラベル付けの必須設定
- 下位ラベルへ変更するときの理由入力設定
- 各グループのオブジェクトIDと所有者
作業者には、Information Protection AdminsやSensitivity Label Administratorなど、必要最小限の権限を付与します。日常的な変更のためにグローバル管理者を使用する運用は避けるべきです。(Microsoft Learn)
対象ルールを業務上の文章で定義する
最初からグループ名や動的ルールを考えるのではなく、誰に何を配布するのかを文章で定義します。
例えば、次のように整理します。
有効な財務部門の従業員には「社外秘 – 財務」を発行する。ただし、外部企業と共同作業する特定のMicrosoft 365グループのメンバーには、この財務部門向けポリシーを適用しない。
設定例は次のとおりです。
| ポリシー | 包含対象 | 除外対象 | 発行ラベル | 優先順位 |
|---|---|---|---|---|
| Org-Baseline | 全ユーザー | なし | 公開、一般、社外秘 | 低 |
| Finance-Restricted | SG-DYN-Finance-Users | M365-Finance-External-Project | 社外秘 – 財務 | 高 |
この構成では、除外されたプロジェクト メンバーも、全ユーザー向けのOrg-Baselineから配布されるラベルは利用できます。Microsoft 365グループを一つのポリシーから除外しても、別のポリシーによる割り当てまで無効になるわけではありません。
動的セキュリティ グループのルールを検証する
秘密度ラベル発行ポリシーはユーザーへ適用するため、基本的にはユーザーベースの動的セキュリティ グループを使用します。Microsoft Entraのセキュリティ グループは、ユーザーまたはデバイスのどちらかをメンバーにできますが、両方を同じ動的ルールに含めることはできません。デバイスベースのグループを誤って選ばないようにしてください。(Microsoft Learn)
例えば、次のようなルールが考えられます。
(user.department -eq "Finance") -and (user.accountEnabled -eq true)本番利用前には、少なくとも次のケースを確認します。
- 対象部門の正社員が含まれる
- 退職済み、無効化済みのアカウントが含まれない
- 同じ部門名が設定されたゲストや委託先アカウントが意図せず含まれない
- 部門異動後に、旧ポリシーの対象から外れる
- 属性の更新元と更新責任者が明確になっている
- ルールに使う属性を一般ユーザーが自己変更できない
動的グループはメンバーを手動で追加・削除できません。例外を手作業で処理する前提の運用には向かないため、必要な例外はルール条件またはポリシーの除外設定として設計します。(Microsoft Learn)
小規模なパイロットポリシーで確認する
既存の全社ポリシーを直接編集するのではなく、まず少人数のパイロット用ポリシーを作成します。
検証対象には、次の4パターンを含めると問題を見つけやすくなります。
- 動的セキュリティ グループにだけ含まれるユーザー
- 除外するMicrosoft 365グループにだけ含まれるユーザー
- 包含グループと除外グループの両方に関係するユーザー
- 既存の別ポリシーにも割り当てられているユーザー
確認するのは、ラベルが表示されるかどうかだけではありません。既定ラベル、ラベル付け必須、下位ラベルへの変更理由、グループやサイト作成時の挙動も確認してください。
ポリシーの優先順位と重複を確認する
ユーザーは複数の秘密度ラベル ポリシーに所属できます。その場合、各ポリシーから発行されたラベルはまとめて利用できます。一方、既定ラベルやラベル付け必須などの設定が競合した場合は、順序番号が大きい、つまり優先順位が高いポリシーの設定が適用されます。(Microsoft Learn)
そのため、Microsoft 365グループをポリシーから除外しても、別のポリシーから同じラベルが発行されていれば、ユーザーには引き続き表示される可能性があります。
期待どおりの結果にならないときは、次の順に確認します。
- ユーザーが実際にどのグループへ所属しているか
- どの発行ポリシーがユーザーへ割り当てられているか
- 同じラベルが別ポリシーから発行されていないか
- 競合するポリシー設定の優先順位
- グループの表示名ではなく、正しいオブジェクトIDを選択しているか
反映時間を考慮してテストする
秘密度ラベルと発行ポリシーの変更は、Microsoft 365全体へ反映されるまで最大24時間程度かかることがあります。新しいグループのメンバー展開やグループ メンバーシップの変更が関係する場合は、24～48時間かかる可能性があります。(Microsoft Learn)
設定直後にラベルが表示されないからといって、すぐに設定を何度も変更しないでください。変更を重ねると、どの設定が有効になったのか分からなくなります。
テナントで利用できる場合は、Label policiesページに表示される発行ポリシーの同期状態も確認します。この同期状態表示は、2026年5月時点ではプレビューとして案内されています。(Microsoft Learn)
なお、ユーザーを発行対象から外しても、すでにファイル、メール、Teams、SharePointサイトなどへ適用済みの秘密度ラベルが一括解除されるわけではありません。Microsoftは、ラベルを発行ポリシーから外した場合でも、適用済みのコンテンツやコンテナーにはラベルが残ると説明しています。(Microsoft Learn)
監査・検知への影響
今回の変更は、検出エンジンや自動ラベル付けルールを追加する機能ではありません。発行ポリシーの対象者を変える機能です。
ただし、対象者が増減することで、秘密度ラベルの利用状況や、秘密度ラベルを条件にしているDLPポリシーの検知結果には、間接的な変化が生じる可能性があります。
監査は3つの層に分けて考える
| 監査対象 | 主に確認する内容 | 異常の例 |
|---|---|---|
| ポリシー構成 | 発行ラベル、包含・除外グループ、優先順位 | 意図しないグループが追加された |
| Microsoft Entraグループ | 動的ルール、グループ更新、メンバーの追加・削除 | 属性変更により対象者が急増した |
| ラベル利用状況 | ラベルの適用、変更、削除、失敗 | 適用失敗や下位ラベルへの変更が増えた |
Microsoft 365監査ログには、秘密度ラベルの適用、変更、削除、適用失敗などが記録されます。代表的な操作名には、SensitivityLabelApplied、SensitivityLabelUpdated、SensitivityLabelRemoved、FileSensitivityLabelAppliedFailedなどがあります。(Microsoft Learn)
Microsoft Entraのグループ管理では、AddGroup、UpdateGroup、AddMemberToGroup、RemoveMemberFromGroupなどの操作を確認できます。動的グループでは、メンバーの増減だけでなく、動的メンバーシップ ルールや参照属性を変更した管理操作にも注意が必要です。(Microsoft Learn)
Activity Explorerで見るべき項目
Activity Explorerでは、秘密度ラベルが適用されたコンテンツに対して、どのような操作が行われたかを確認できます。
今回の変更後は、次の項目を重点的に監視します。
- 新しく対象にしたユーザーによるラベル適用件数
- ラベル適用、変更、削除の失敗件数
- 高い秘密度から低い秘密度への変更件数
- ラベル削除件数
- 除外対象ユーザーによる想定外のラベル利用
- 部門別、ユーザー別の利用件数の偏り
Microsoftは、Activity Explorerで「Highly ConfidentialからGeneralへの変更が大量に発生している」といった想定外の動きを確認し、DLPなどの制御が有効に機能しているか判断できると説明しています。(Microsoft Learn)
DLPのアラート件数だけで成否を判断しない
秘密度ラベルは、Microsoft Purview DLPポリシーの条件として利用できます。動的セキュリティ グループによってラベルの利用者が増えると、ラベル付きコンテンツも増え、DLPのポリシー一致件数が変化する可能性があります。(Microsoft Learn)
ただし、アラート件数が増えたからといって、設定ミスとは限りません。対象ユーザーが増えた結果、これまでラベル付けされていなかった機密データが正しく検知されるようになった可能性もあります。
実務では、本番変更前の7日間と、変更後の7～14日間を比較します。次の指標をセットで確認してください。
- 対象ユーザー数
- ユーザー1人当たりのラベル適用件数
- ラベル適用の失敗率
- 下位ラベルへの変更率
- DLPポリシーの一致件数
- DLPのブロック、警告、上書き件数
- 動的グループのメンバー増減数
件数だけでなく、対象ユーザー数を分母にした比率で比較することが重要です。
設定時に失敗しやすいポイント
| 失敗しやすい点 | 起こる問題 | 防止策 |
|---|---|---|
| 動的Microsoft 365グループと動的セキュリティ グループを混同する | 想定していたグループ種別を選べない | グループの種類、メール対応、メンバーシップ種別を確認する |
| 発行対象指定とグループ自体へのラベル付けを混同する | 期待したアクセス制御が実施されない | 「ユーザーへのラベル配布」と「グループ オブジェクトの保護」を分けて設計する |
| 動的グループの属性を無条件に信頼する | ゲスト、委託先、異動済みユーザーが含まれる | 属性の更新元、書き込み権限、データ品質を監査する |
| グループの表示名だけで管理する | 同名グループを誤って指定する | オブジェクトID、所有者、用途を変更記録に残す |
| 除外すれば全ポリシーが無効になると考える | 別ポリシーからラベルが引き続き表示される | ユーザーに割り当てられる全ポリシーを確認する |
| ポリシー優先順位を確認しない | 既定ラベルや必須設定が想定と異なる | 優先順位が最も高いポリシーの設定を確認する |
| 設定直後に失敗と判断する | 不要な再設定で原因を追えなくなる | グループ関連では24～48時間を見込む |
| 除外によって既存コンテンツのラベルも消えると考える | 適用済みラベルや暗号化が残り、運用判断を誤る | 発行対象と既存コンテンツの状態を分けて確認する |
| すべてのクラウドで利用できると判断する | 対象テナントに機能が表示されない | 自社クラウドとテナントUIで提供状況を確認する |
優先して実施すべき対応
対応の優先順位は次のように整理できます。
| 優先度 | 実施内容 | 完了の判断基準 |
|---|---|---|
| 最優先 | 現在の発行ポリシーをCSVまたはZIPでエクスポートする | 変更前の構成を復元・比較できる |
| 最優先 | 個人ユーザーを直接指定しているポリシーを洗い出す | 手動管理の対象人数と更新頻度が分かる |
| 高 | 包含・除外するグループと業務要件を一覧化する | 誰に何を配布するか文章で説明できる |
| 高 | 動的グループのルールと属性権限を監査する | 意図しないユーザーが含まれない |
| 高 | 少人数のパイロットで優先順位と重複を検証する | 4パターン以上のテストユーザーで期待結果を確認できる |
| 中 | 反映後のActivity Explorer、監査ログ、DLPを比較する | 適用失敗や想定外のラベル変更が増えていない |
| 中 | 不要になった個人割り当てを整理する | グループベースの運用へ移行できている |
| 低 | 全社一律ポリシーのみの組織は提供状況だけ確認する | 「現時点では変更不要」と判断記録を残せる |
今回の更新は、秘密度ラベルの保護機能そのものを強化するのではなく、ポリシーの対象管理をより正確かつ自動化しやすくするものです。
特に、個人ユーザーの手動指定を続けている組織では、動的セキュリティ グループへの移行により、異動や退職時の更新漏れを減らせます。一方で、動的ルールに使う属性が不正確であれば、誤ったユーザーへ機密性の高いラベルを発行する危険があります。
まず、現在の発行ポリシーをエクスポートし、包含・除外・優先順位を1枚の表にまとめてください。そのうえで、1つの動的セキュリティ グループと1つのMicrosoft 365グループ除外を使ったパイロットを実施し、24～48時間後の適用結果と監査ログを確認するのが現実的な進め方です。
コメント