Microsoft PurviewのEndpoint Data Loss Prevention – Device Health Reporting Dashboardは、Endpoint DLP対象デバイスの健全性とポリシー更新の受信準備状況を、管理者が横断的に確認するための新しいダッシュボードです。結論から言うと、既存のDLPポリシーをすぐ作り替える更新ではなく、管理者が「ポリシーを正しく配布できない端末」を早く見つけるための運用改善と捉えるのが適切です。
特に確認すべきなのは、オンボード済みデバイスの構成状態、ポリシー同期状態、最終接続時刻、Defender関連バージョン、DLPポリシーのユーザー・デバイススコープです。Microsoft 365ロードマップ上では、Roadmap ID 559267として、Worldwide標準テナント向けにPreviewが2026年4月、GAが2026年5月、ステータスはRolling outとして掲載されています。公式API上の更新時刻は2026-05-20 23:15 UTCで、日本時間では2026年5月21日に相当します。(Microsoft)
Microsoft Purviewのセキュリティ更新で何が変わるのか
今回の更新は、Microsoft PurviewのEndpoint DLPにおいて、管理者がデバイス全体の状態を把握しやすくするためのダッシュボード追加です。公式ロードマップでは、このダッシュボードにより、管理者が全デバイスのデバイスヘルスを確認し、システムが正常でポリシー更新を受け取れる状態かどうかを判断し、準備ができていないデバイスを素早く特定できると説明されています。(Microsoft)
| 項目 | 内容 |
|---|---|
| 機能名 | Microsoft Purview: Endpoint Data Loss Prevention – Device Health Reporting Dashboard |
| Roadmap ID | 559267 |
| 対象サービス | Microsoft Purview |
| 対象プラットフォーム | Web |
| 対象クラウド | Worldwide (Standard Multi-Tenant) |
| リリース段階 | Preview / General Availability |
| Preview予定 | 2026年4月 |
| GA予定 | 2026年5月 |
| ステータス | Rolling out |
重要なのは、この更新が「DLPの検出条件を増やす」「ブロック動作を変更する」「エンドユーザーの画面に新しい警告を出す」といったポリシー動作そのものの変更として案内されているわけではない点です。少なくともロードマップ上の説明から読み取れる主目的は、Endpoint DLPの運用監視を強化し、ポリシーが届かない端末を見つけやすくすることです。
ただし、Microsoft 365ロードマップの情報は予定であり、日付や内容は変更される可能性があります。実際の展開状況は、テナントのMicrosoft 365管理センターのメッセージセンター、Microsoft Purviewポータル、該当機能の表示有無で確認するのが確実です。(Microsoft)
これまでのEndpoint DLP運用で起きやすかった課題
Endpoint DLPは、デバイスにDLPポリシーが正しく届いて初めて意味を持ちます。ポリシーを設計しても、対象デバイスがオフライン、構成不備、Defender関連コンポーネントの問題、スコープの不一致などで更新を受け取れていない場合、管理者が期待した制御は働きません。
Microsoft Purview DLPのOverviewページでは、ポリシー同期状態、デバイス状態、検出された上位アクティビティ、デバイス全体の健全性などを確認できます。今回のDevice Health Reporting Dashboardは、この「デバイスがDLPを適用できる状態か」をより運用しやすく見るための専用・強化された表示と考えると理解しやすいでしょう。(Microsoft Learn)
| これまで起きやすかった課題 | ダッシュボードで期待できる改善 |
|---|---|
| ポリシーを更新したのに、一部端末だけ反映されない | ポリシー更新を受け取れていない端末を見つけやすくなる |
| デバイス一覧を個別に確認する必要がある | 全体傾向から問題端末へ絞り込みやすくなる |
| Defenderや構成状態の問題に気づくのが遅れる | 健全性の異常を運用監視に組み込みやすくなる |
| 「DLPが効いていない原因」がポリシーか端末か切り分けにくい | デバイス側の準備状況を先に確認できる |
現場では、DLPポリシーの設計ミスよりも、「端末がそもそも最新ポリシーを受け取れていない」「対象ユーザーと対象デバイスのスコープが噛み合っていない」ことが原因になるケースがあります。今回の更新は、その切り分けを早めるために有効です。
影響範囲：対象になる組織と管理者
この更新の主な対象は、Microsoft PurviewでEndpoint DLPを利用している組織です。特に、Windows 10/11、macOS、Windows Serverの一部をEndpoint DLPで監視・制御している管理者に影響があります。Endpoint DLPは、Microsoft Purview DLPの監視・保護機能をWindows 10/11、直近3つのメジャーバージョンのmacOS、特定のWindows Serverに拡張する機能です。オンボード後は、機密アイテムに対するユーザー操作をActivity explorerで確認し、DLPポリシーによる保護アクションを適用できます。(Microsoft Learn)
対象になりやすい担当者
| 担当者 | 確認すべきこと |
|---|---|
| Microsoft 365管理者 | Purviewポータルへのアクセス権、対象テナントでの展開状況 |
| セキュリティ管理者 | Endpoint DLP対象端末の健全性、Defender関連状態、未同期端末 |
| コンプライアンス管理者 | DLPポリシーが意図したユーザー・デバイスに適用されているか |
| 情報システム部門 | Intune、MDE、macOS MDM、端末更新の運用手順 |
| SOC / SIEM担当 | Advanced Huntingや外部ダッシュボードとの連携方針 |
| 開発者・自動化担当 | UIの目視に頼らず、KQLやAPI連携で端末状態を取得する設計 |
なお、Roadmap ID 559267はWorldwide標準テナント向けの項目です。公式API上では、GCC、GCC High、DoD向けに近い内容の別項目としてRoadmap ID 561033も確認できます。政府機関向けクラウドを利用している場合は、559267だけで判断せず、自テナントのメッセージセンターと該当クラウド向けロードマップを確認してください。(Microsoft)
管理者が最初に確認すべき設定
Device Health Reporting Dashboardが表示されたら、最初に見るべきなのは「赤い箇所」ではなく、DLPの適用前提が成立しているかです。DLPはポリシー設定だけで完結せず、デバイスのオンボード、Microsoft Defender関連の状態、Entra IDユーザーとの対応、ポリシースコープが揃って初めて機能します。
| 確認項目 | 見るべきポイント | 判断基準 |
|---|---|---|
| Purviewポータルの権限 | 管理者がダッシュボードやDLP設定を確認できるか | 必要なロールだけを付与し、Global Administrator常用を避ける |
| Device onboarding | Endpoint DLP対象端末がオンボード済みか | 未オンボード端末はDLP制御の前提から外れる |
| Configuration status | 端末構成がDLPに適した状態か | Updated以外は端末側の構成確認を優先 |
| Policy sync status | 最新DLPポリシーを受信できているか | Not updated / Not availableを調査対象にする |
| Last seen | 端末が最近オンラインだったか | 長期間未接続ならポリシー未反映の原因になりやすい |
| Defender version | Defender engine / clientの状態 | 古い端末群が偏っていないか確認 |
| Valid user | ログオンユーザーがEntra IDと対応し、DLP対象か | 共有端末・キオスク端末で特に注意 |
| DLP policy scope | ユーザーとデバイスの両方が対象か | 片方だけ対象ではエンドポイントに適用されない |
Microsoft Purviewポータルでは、ロールとスコープを使って権限を管理できます。Microsoftは最小権限の原則を推奨しており、Global Administratorの人数を最小化することがセキュリティ向上につながると説明しています。運用担当者に広すぎる権限を与えるのではなく、DLP確認・調査・設定変更の担当範囲に応じて権限を分けることが重要です。(Microsoft Learn)
DLPポリシーを作成・展開するアカウントには、Compliance administrator、Compliance data administrator、Information Protection、Information Protection Admin、Security administratorなどのロールグループが必要です。閲覧だけの担当者と、ポリシー変更まで行う担当者を分けておくと、監査時にも説明しやすくなります。(Microsoft Learn)
Device healthの状態はどう読むべきか
Endpoint DLPのトラブルシューティングでは、Configuration statusとPolicy sync statusが重要です。Microsoft Learnでは、オンボード済みデバイスの構成状態とポリシー同期状態には、Updated、Not updated、Not availableの3種類があると説明されています。Configuration statusはデバイスが正しく構成され、Purviewへハートビートを送信しているかを示し、Policy sync statusは最新ポリシーを受け取ったかを示します。(Microsoft Learn)
| 状態 | 意味 | 管理者の初動 |
|---|---|---|
| Updated | デバイス構成やポリシー同期が最新状態 | 追加対応は不要。新しいDLPポリシー展開後の基準値として記録する |
| Not updated | 一部設定やポリシー同期に注意が必要 | 端末のオンライン状態、Defender設定、ポリシー更新タイミングを確認する |
| Not available | デバイス属性を取得できない状態 | OS要件、オンボード直後かどうか、Endpoint DLPポリシーの有無を確認する |
特に見落としやすいのが、端末がオンラインでなければポリシー更新が行われない点です。ステータスが更新されない場合は、まずLast seenを確認し、端末が最近オンラインだったかを見ます。(Microsoft Learn)
「Not updated」を見つけたときの調査順
Not updatedを見つけたら、いきなりDLPルールを書き換えるのは避けてください。原因が端末側にある場合、ポリシーを変更しても改善しません。次の順で確認すると切り分けが速くなります。
| 順番 | 確認内容 | 具体的な見方 |
|---|---|---|
| 1 | 端末が最近オンラインか | Last seenが古くないか確認 |
| 2 | 端末構成が正常か | Configuration statusがUpdatedか確認 |
| 3 | Defender関連状態 | Defender engine version、Defender client versionを確認 |
| 4 | ログオンユーザー | Valid userが想定通りか確認 |
| 5 | DLPポリシースコープ | ユーザーとデバイスの両方が対象か確認 |
| 6 | ポリシー更新の反映待ち | 直近変更直後なら一定時間を置いて再確認 |
| 7 | 自己解決不可の場合 | OS、Defender version、MDATP device ID、Valid userを記録してサポート調査へ |
Microsoft Learnでも、自己修復できない場合は、Device detailsからOS、Defender engine version、Defender client version、MDATP device ID、Valid userなどを記録してサポートチケット用の証跡にする流れが示されています。(Microsoft Learn)
DLPポリシーのスコープ確認で失敗しやすいポイント
Endpoint DLPで特に注意したいのは、DLPポリシーのDevicesロケーションを使う場合、ユーザーとデバイスの両方がスコープに含まれていなければエンドポイントにポリシーが適用されないことです。ユーザーだけ対象、またはデバイスだけ対象では、期待した制御が働かない場合があります。(Microsoft Learn)
たとえば、経理部門の端末でUSBコピーを制御したい場合、経理ユーザーを対象にするだけでは不十分です。対象デバイスがDLPポリシーのデバイススコープにも含まれているかを確認する必要があります。
| よくある設定ミス | 起きる問題 | 対応 |
|---|---|---|
| 対象ユーザーだけを指定している | 特定端末でDLPが効かない | Devicesスコープも確認する |
| 端末グループだけを指定している | 対象ユーザーが範囲外で適用されない | ユーザースコープも確認する |
| 共有端末の利用者を想定していない | ログオンユーザーにより適用結果が変わる | Valid userと利用シナリオを確認する |
| パイロット端末を除外したまま本番展開 | 本番確認で一部端末が未適用になる | 除外リストを棚卸しする |
| macOS端末の要件を見落とす | Windowsでは効くがMacで効かない | macOS側の対応バージョンと管理状態を確認する |
Device Health Reporting Dashboardは、こうしたスコープ不一致の「結果」を見つける助けになります。ただし、ダッシュボードが原因をすべて自動で直してくれるわけではありません。DLPポリシー、デバイスグループ、ユーザーグループ、オンボード状態を突き合わせて確認する運用が必要です。
展開・移行で注意すべきこと
今回の更新について、公式ロードマップ上ではポリシー移行やエージェント再インストールが必要な変更としては説明されていません。とはいえ、運用現場では「新しいダッシュボードが出たら終わり」ではなく、既存のDLP運用にどう組み込むかが重要です。
展開時にやるべきこと
| タイミング | 作業 | 目的 |
|---|---|---|
| 表示前 | 現在のEndpoint DLP対象端末数を把握 | ダッシュボード表示後の差分確認に使う |
| 表示直後 | Updated / Not updated / Not availableの割合を記録 | 初期状態のベースラインを作る |
| 1週間以内 | 問題端末の上位パターンを分類 | OS、部署、端末種別、Defenderバージョンの偏りを見る |
| 2〜4週間以内 | 運用手順書に追加 | DLP変更時の確認手順に組み込む |
| 定常運用 | 月次または週次で確認 | ポリシー未反映端末を放置しない |
DLPポリシー変更と同時に進める場合の注意
ダッシュボード公開に合わせてDLPポリシーも強化する場合は、いきなり本番ブロックを有効にするのは避けた方が安全です。Microsoft Learnでは、DLPポリシー展開はスコープ、状態、アクションの3軸で管理し、影響の小さいシミュレーションモードから段階的に始めることが推奨されています。(Microsoft Learn)
実務では、次の順番が現実的です。
| フェーズ | 設定例 | 確認すること |
|---|---|---|
| 事前確認 | 既存ポリシーは変更しない | ダッシュボード上で端末健全性を確認 |
| パイロット | 対象ユーザー・端末を限定 | Not updated端末がないか確認 |
| シミュレーション | 監査のみ、またはポリシーチップ表示 | 業務影響と誤検知を確認 |
| 段階的強化 | Block with overrideなどを一部適用 | 問い合わせ件数と例外申請を確認 |
| 本番展開 | 対象範囲を拡大 | 端末健全性とアラート傾向を継続監視 |
Device Health Reporting Dashboardは、ポリシー展開の前後比較に使うと効果的です。たとえば、ブロックポリシーを有効化する前にNot updated端末を減らしておけば、「一部端末だけ制御が効かない」という展開後のトラブルを減らせます。
開発者・SOC担当者はAdvanced Huntingも確認する
ダッシュボードは管理者が状況を見るには便利ですが、大規模環境ではUIの目視だけでは限界があります。Microsoft Learnでは、Microsoft DefenderポータルのAdvanced Huntingを使い、DeviceInfoテーブルのDlpInfo列からEndpoint DLPデバイス詳細を確認できると説明されています。これにより、手動エクスポートに頼らず、KQLでデバイス状態を分析し、カスタムダッシュボードや外部レポート基盤へ統合できます。(Microsoft Learn)
まずは、次の最小クエリでDlpInfoが取得できるか確認します。
DeviceInfo
| where DlpInfo != ""
| project DlpInfo運用に組み込む場合は、次のような使い方が考えられます。
| 活用シーン | 例 |
|---|---|
| SOC監視 | Not updated端末が一定数を超えたら調査対象にする |
| 月次レポート | Endpoint DLP有効端末数、未同期端末数、OS別傾向を集計 |
| IT資産管理 | 古いDefenderバージョンの端末群を抽出 |
| 監査対応 | DLPポリシー適用準備が整っている端末割合を証跡化 |
| 自動チケット作成 | 長期間Not availableの端末をITSMへ連携 |
ダッシュボードを直接スクレイピングするような実装は避け、Microsoftが案内しているAdvanced Huntingなど、運用に適したデータ取得経路を使う方が保守しやすくなります。
運用で見落としやすい注意点
ダッシュボードが正常でもDLPリスクがゼロとは限らない
Device Health Reporting Dashboardは、Endpoint DLPのデバイス状態やポリシー同期の準備状況を見るためのものです。機密情報の分類設計、DLPルールの妥当性、例外設定の過剰付与、ユーザーの業務回避行動まで自動で保証するものではありません。
たとえば、全端末がUpdatedでも、DLPポリシーが対象外のファイル種別を見落としていれば、データ漏えいリスクは残ります。ダッシュボードは「ポリシーを届ける土台の健全性」を見るものとして扱いましょう。
Not availableをすぐ障害と決めつけない
Not availableは、端末が最小OS要件を満たしていない場合、オンボード直後の場合、Endpoint DLPポリシーが存在しない場合などにも表示され得ます。Microsoft Learnでも、Not availableはデバイス属性が取得できない状態であり、条件によって発生すると説明されています。(Microsoft Learn)
新規オンボード直後の端末をすぐ障害扱いすると、不要な調査が増えます。まずは、オンボード日時、Last seen、OS、対象ポリシーの有無を確認してください。
部署別・端末種別で偏りを見る
全体のUpdated率だけを見ると、問題を見逃します。たとえば全社で95%が正常でも、研究部門のmacOS端末だけNot updatedが多い場合、情報漏えいリスクの高い部署に問題が集中している可能性があります。
確認するときは、次の切り口で分けると原因を見つけやすくなります。
| 切り口 | 見つけやすい問題 |
|---|---|
| OS別 | macOSだけ未同期、Windows Serverだけ未対応 |
| 部署別 | 特定部門の端末更新遅れ |
| ネットワーク別 | VPN外の端末がポリシー未受信 |
| 端末管理方式別 | Intune管理端末とJamf管理端末の差 |
| Defenderバージョン別 | 古いクライアントに問題が集中 |
ランブックに「DLP変更後の確認」を入れる
DLPポリシーを変更した後は、ルールの保存完了だけで終わらせず、Device Health Reporting Dashboardまたは既存のポリシー同期確認で、対象端末が更新を受け取ったかを確認する手順を入れましょう。
おすすめの運用ルールは次の通りです。
| 場面 | 確認ルール |
|---|---|
| 新しいDLPポリシーを作成した | パイロット端末でPolicy sync statusを確認 |
| ブロック設定を有効化した | Not updated端末が残っていないか確認 |
| 監査でDLP適用状況を聞かれた | ダッシュボードとAdvanced Huntingの結果を証跡化 |
| 新入社員・端末入替が多い時期 | 新規オンボード端末のNot availableを重点確認 |
| DefenderやMDM設定を変更した | Configuration statusの悪化がないか確認 |
管理者が次に取るべき行動
今回のMicrosoft Purview Endpoint DLP Device Health Reporting Dashboardは、DLPポリシーの設計そのものよりも、ポリシーが確実に端末へ届く状態を維持するための更新です。管理者がまず行うべきことは、機能の表示有無を確認し、対象端末の健全性を棚卸しし、Not updatedやNot availableの端末を放置しない運用に変えることです。
まずは次の3つを実施してください。
| 優先度 | 実施内容 |
|---|---|
| 高 | Microsoft PurviewポータルでEndpoint DLP対象端末のConfiguration statusとPolicy sync statusを確認する |
| 高 | DLPポリシーのDevicesスコープで、ユーザーとデバイスの両方が対象になっているか確認する |
| 中 | Advanced HuntingのDlpInfo取得を試し、定常レポートやSOC監視に組み込む |
Device Health Reporting Dashboardを単なる新画面として扱うのではなく、「DLPが効くはずなのに効いていない端末」を見つける運用ポイントとして組み込むことで、Microsoft Purview Endpoint DLPの実効性を高められます。
コメント