Microsoft Purview DLPとMicrosoft Defender XDRのアラートをAPI連携している組織は、2026年5月9日時点の公式ロードマップ更新を確認しておくべきです。今回の変更は、Defenderアラートを取得するMicrosoft Graph APIにDLPイベントデータを追加し、SIEM連携、自動化ワークフロー、カスタムレポート作成をしやすくするものです。
結論から言うと、DLPポリシーそのものを作り直す更新ではありません。ただし、現在「Graph APIでアラートを取得し、Office 365 Management Activity APIでDLPルール一致イベントを別途取得して突合している」構成では、データ取得設計・SIEMマッピング・重複検知・権限設計を見直す必要があります。Microsoft 365 Roadmap ID 558681では、プレビューが2026年5月、一般提供が2026年6月、対象はMicrosoft Purview、Worldwideの標準マルチテナント、Web、ステータスはIn developmentとされています。(Microsoft)
Microsoft Purview DLPのGraph API拡張で何が変わるのか
今回の更新は、Microsoft Purview Data Loss Prevention、つまりDLPのアラート運用をAPI連携しやすくする改善です。
これまで、Defender側のアラート情報はMicrosoft Graph APIで取得できる一方、DLPルールに一致したイベントの詳細はOffice 365 Management Activity API側に存在する、という分断がありました。公式ロードマップでは、この分断を埋めるためにGraph APIへDLPイベントデータを付加し、相関分析や外部システム連携を容易にすることが目的と説明されています。(Microsoft)
つまり、管理者や開発者にとっての主な変化は次の通りです。
| 観点 | これまで | 今回の更新後に期待されること |
|---|---|---|
| アラート取得 | Microsoft Graph APIでDefenderアラートを取得 | Graph API上のDefenderアラートにDLPイベント情報が加わる |
| DLPイベント詳細 | Management Activity APIから別途取得 | Graph API側で参照できる情報が増える可能性がある |
| SIEM連携 | 複数APIのデータを突合する実装が必要 | 連携処理を簡素化しやすい |
| レポート作成 | アラートとDLPルール一致イベントの結合が必要 | アラート軸でDLP情報を扱いやすくなる |
| 自動化 | アラートID、日時、ユーザー、ファイル、ポリシー名などの相関処理が必要 | ワークフロー起動条件を整理しやすくなる |
注意したいのは、「Management Activity APIが不要になる」と断定できる段階ではないことです。ロードマップ上ではGraph APIをDLPイベントデータで強化すると説明されていますが、すべての監査イベントや全ワークロードの詳細がGraph APIだけで完結するとは明記されていません。既存連携をすぐ廃止するのではなく、プレビュー環境で取得できるフィールド、保持期間、欠損時の挙動を確認するのが現実的です。
なぜこの更新が重要なのか
Microsoft Purview DLPは、機密情報の外部送信、共有、コピー、印刷、クラウドアップロードなど、情報漏えいにつながる操作を検知・制御する仕組みです。DLPポリシーでは、ルール条件に一致したときにアラートを生成できます。Microsoftのドキュメントでも、DLPアラートはDLPポリシールールで構成され、Microsoft Defender XDRダッシュボードやMicrosoft Purviewポータルで調査・管理できると説明されています。(Microsoft Learn)
実務では、DLPアラートを人がポータルで確認するだけでは不十分なケースが多くあります。たとえば、次のような運用です。
- Microsoft SentinelやSplunkなどのSIEMへDLPアラートを転送する
- 重大度の高いDLPアラートをTeamsやチケット管理ツールへ通知する
- 特定のユーザー、部門、ラベル、ファイル種別ごとに月次レポートを作る
- Insider Risk ManagementやDefender for Endpointのアラートと突合する
- 監査証跡としてDLPイベントを長期保管する
こうした運用では、単なる「アラートが発生した」という情報だけでは足りません。どのDLPポリシーに一致したのか、どのユーザーが何をしたのか、対象ファイルや場所はどこか、機密情報の種類は何か、といったイベントデータが必要です。
今回のGraph API拡張は、この「アラート」と「DLPイベント詳細」の距離を縮める更新と考えると理解しやすいでしょう。
対象範囲とリリース状況
公式ロードマップ上の対象範囲は次の通りです。
| 項目 | 内容 |
|---|---|
| Roadmap ID | 558681 |
| 対象サービス | Microsoft Purview |
| 機能名 | Data Loss Prevention – Enrich Defender alerts Graph API with DLP event data |
| ステータス | In development |
| 対象クラウド | Worldwide Standard Multi-Tenant |
| プラットフォーム | Web |
| プレビュー | 2026年5月 |
| 一般提供 | 2026年6月 |
| 作成日 | 2026年3月13日 UTC |
| 最終更新 | 2026年5月8日 22:15 UTC、日本時間では2026年5月9日朝に相当 |
この情報はロードマップ上の予定であり、Microsoft 365 Roadmap自体も予定日や内容が変更される可能性があります。Microsoftのロードマップページでは、商用機能の予想リリース日と説明を提供するもので、情報は変更される可能性があるとされています。(Microsoft)
そのため、運用チームは「2026年6月に必ず全テナントで同じ挙動になる」と決め打ちせず、対象テナントで実際のレスポンスを確認してから本番移行するべきです。
既存のGraph API連携に与える影響
Microsoft Graph security APIでは、アラートやインシデントを取得できます。ドキュメントでは、最新世代のアラートとインシデントはmicrosoft.graph.security名前空間のalertリソースとincidentリソースで表され、Microsoft Purview Data Loss PreventionもGraph security APIで利用可能なセキュリティプロバイダーに含まれています。(Microsoft Learn)
実装面では、GET /security/alerts_v2でアラート一覧を取得できます。このAPIはアラートのフィルターや並べ替えに対応し、SecurityAlert.Read.Allが最小特権のアクセス許可として示されています。(Microsoft Learn)
今回の変更により、既存のGraph API連携では次の点を確認する必要があります。
| 確認項目 | 実務上の確認ポイント |
|---|---|
| レスポンス形式 | 新しいDLP関連フィールドが追加されても既存パーサーが落ちないか |
| JSONマッピング | SIEMやDWHに取り込むフィールド定義を更新する必要があるか |
| 重複データ | Management Activity APIから取得済みのDLPイベントと二重登録されないか |
| フィルター条件 | serviceSource、createdDateTime、severityなど既存条件でDLPアラートを正しく抽出できるか |
| 権限 | Graph API側の権限とManagement Activity API側の権限を最小権限で整理できているか |
| エラー処理 | プレビュー中に一部フィールドが空、未提供、形式変更される可能性を考慮しているか |
特に注意すべきなのは、JSONレスポンスを厳密な固定スキーマとして処理しているシステムです。新しいプロパティが追加されたときに取り込み処理が失敗する設計になっている場合、Graph API拡張のタイミングでSIEM連携やレポート生成が止まる可能性があります。
Management Activity API連携はどう見直すべきか
Office 365 Management Activity APIは、Office 365やMicrosoft Entraのユーザー操作、管理者操作、システム操作、ポリシー関連イベントを取得するためのAPIです。Microsoftのドキュメントでは、監視、分析、データ可視化のソリューション作成に利用できると説明されています。(Microsoft Learn)
また、同APIではDLP.AllというDLPイベント用のコンテンツタイプがサポートされています。(Microsoft Learn) DLP関連では、SharePointとOneDriveのDLPイベント、Unified DLP Policyで構成されたExchangeのDLPイベントなどがスキーマ上で示されています。(Microsoft Learn)
今回のGraph API拡張後も、Management Activity APIの役割が完全になくなるとは限りません。実務では、次のように使い分けを検討すると安全です。
| 用途 | Graph APIを優先しやすいケース | Management Activity APIを継続確認すべきケース |
|---|---|---|
| インシデント対応 | Defenderアラート起点で調査する | 監査ログ全体を時系列で追う |
| SIEM通知 | アラート単位で検知・通知する | DLP以外の監査イベントもまとめて取り込む |
| 自動化 | 特定のDLPアラート発生時にワークフローを起動する | アラート化されないイベントも対象にする |
| レポート | アラート、重大度、対応状況を集計する | 全操作ログ、監査証跡、証跡保管を重視する |
| 相関分析 | Defender XDRのインシデントと紐づける | 複数ワークロードの詳細イベントを横断分析する |
移行判断のポイントは、「同じデータが取れるか」ではなく「業務要件に必要な粒度で取れるか」です。たとえば、SOC向けの即時アラート通知はGraph API中心に寄せられる可能性があります。一方、内部監査や証跡保管では、Management Activity APIの継続利用が必要になるかもしれません。
管理者が確認すべき設定
Microsoft Purview管理者は、APIの話だけでなく、DLPアラートが正しく生成される前提条件も確認しておく必要があります。Microsoft Defender XDRでDLPアラートを調査するには、DLPポリシーのアラートを有効化しておく必要があるとドキュメントに記載されています。(Microsoft Learn)
まず確認したいのは次の項目です。
| 確認箇所 | 確認内容 |
|---|---|
| DLPポリシー | 対象ワークロード、条件、アクション、アラート設定が意図通りか |
| アラート設定 | 単一イベントアラートか、集約イベントアラートか |
| Defender XDR連携 | DLPアラートがDefenderポータルのインシデントキューに流れているか |
| 管理ロール | 調査担当者に必要最小限のロールが付与されているか |
| 管理単位 | Administrative Unitsの制限により見えるアラートが限定されていないか |
| 監査ログ | Management Activity APIを使う場合、統合監査ログが有効か |
| SIEM連携 | DLPアラートを取り込むコネクタやカスタム取り込み処理があるか |
Defenderポータルでは、DLPアラートをインシデントキューで確認し、DLPポリシー名、タグ、日付、サービスソース、ユーザーなどでフィルターできます。Microsoftのドキュメントでも、DLPアラートを含むインシデントの表示、他ソリューションのアラートとの相関、Advanced Hunting、修復アクションなどが可能とされています。(Microsoft Learn)
このため、Graph APIの拡張を待つだけでなく、そもそもDLPアラートが運用上使える状態になっているかを先に確認することが重要です。
開発者が確認すべきAPI実装上のポイント
開発者やセキュリティエンジニアは、プレビュー段階でAPIレスポンスを実際に取得し、既存実装への影響を検証する必要があります。
特に、次のような実装は見直し対象です。
固定スキーマ前提のパーサー
SIEMやデータ基盤へ取り込む際、許可されたフィールド以外をエラー扱いにしている場合があります。Graph APIにDLPイベントデータが追加されると、新しいプロパティや入れ子構造が現れる可能性があります。
対策として、未知のフィールドを無視または別領域に退避できる設計にしておくと安全です。DLP関連フィールドが正式に確認できた後、必要な項目だけを正規化テーブルやSIEMフィールドへマッピングします。
アラートとイベントの重複登録
現在、Graph APIのアラートとManagement Activity APIのDLPイベントを別々に取り込んでいる場合、同じ事象が二重に記録される可能性があります。
重複判定では、単純な日時一致だけに頼らない方が安全です。次のような複数要素で相関キーを作ると、誤検知を減らせます。
| 相関に使う候補 | 例 |
|---|---|
| アラートID | Graph APIのalert ID、providerAlertId |
| インシデントID | Defender XDRのincidentId |
| ユーザー | User principal name、メールアドレス |
| 対象ファイル | ファイル名、パス、SharePoint/OneDrive URL |
| ポリシー | DLPポリシー名、ルール名、ポリシーID |
| 発生時刻 | firstActivityDateTime、createdDateTime、イベント時刻 |
| ワークロード | Exchange、SharePoint、OneDrive、Teams、Endpointなど |
Microsoft Graphのalertリソースには、アラートID、インシデントID、ポータルURL、証拠情報、ポリシーID、カスタム詳細などのプロパティが定義されています。(Microsoft Learn) ただし、今回追加されるDLPイベントデータがどのプロパティにどの形式で入るかは、実際のプレビュー応答で確認する必要があります。
権限の過剰付与
Graph APIのalerts_v2取得では、アプリケーション権限としてSecurityAlert.Read.Allが最小特権として示されています。(Microsoft Learn) 一方、Management Activity APIでは、組織のアクティビティデータ、サービス正常性情報、DLPポリシーイベントの読み取り権限が利用されます。DLPワークロードに関心がある場合のみDLPポリシーイベントの読み取りが必要とされています。(Microsoft Learn)
移行時にありがちな失敗は、「動かないから広い権限を付ける」ことです。まずはGraph APIとManagement Activity APIで必要な権限を分け、どの処理がどの権限を使っているかを棚卸ししましょう。将来的にGraph API中心へ寄せる場合でも、不要になった権限をすぐ削除するのではなく、一定期間の並行稼働とログ確認を挟むのが安全です。
SIEM連携で見直すべきマッピング
今回の更新で最も恩恵を受けやすいのは、Microsoft Purview DLPのアラートをSIEMに取り込んでいる組織です。
SIEM側では、単にDLPアラートを保存するだけでなく、検知ルール、ダッシュボード、相関分析、通知、チケット起票に使っていることが多いはずです。Graph APIにDLPイベントデータが入ることで、取り込み元が変わるだけでなく、フィールド設計も見直す必要が出てきます。
| SIEM項目 | 見直しポイント |
|---|---|
| 重大度 | Graph APIのseverityと既存DLPポリシーの重大度をどう対応させるか |
| ユーザー | UPN、表示名、部署、管理単位との紐づけを維持できるか |
| ファイル情報 | ファイル名、パス、URL、ハッシュ、ラベル情報の有無を確認する |
| ポリシー情報 | ポリシー名、ルール名、ポリシーIDをダッシュボードで表示できるか |
| イベント種別 | 送信、共有、アップロード、コピー、印刷などの行動を分類できるか |
| インシデント連携 | Defender XDRのincidentIdを相関キーとして使えるか |
| 調査URL | alertWebUrlやincidentWebUrlをチケットに含められるか |
実装のおすすめは、いきなり既存のSIEMフィールドを置き換えるのではなく、まずは新しいGraph API由来のDLPデータを別フィールドとして取り込むことです。一定期間、Management Activity API由来のデータと比較し、欠損、重複、時刻差、ポリシー名の表記差を確認してから正規化ルールを更新します。
自動化ワークフローで注意すべきこと
DLPアラートをきっかけにPower Automate、Logic Apps、Azure Functions、ServiceNow、Jira、Teams通知などを動かしている場合、Graph API拡張はワークフローの簡素化につながる可能性があります。
たとえば、次のような自動化です。
| 自動化シナリオ | Graph API拡張後の確認ポイント |
|---|---|
| 高重大度DLPアラートをTeams通知 | 通知文にポリシー名、対象ファイル、ユーザーを含められるか |
| チケット自動起票 | 重複チケットを作らない相関キーを設定できるか |
| 上長通知 | ユーザー属性との連携に必要な情報が揃うか |
| ファイル隔離やアクセス見直し | 自動修復に必要なファイル識別情報が取得できるか |
| 月次レポート生成 | 既存レポートの集計軸を維持できるか |
注意点は、DLPアラートはノイズが発生しやすい領域だということです。単一イベントごとに即時通知すると、業務上問題のない操作まで大量に通知される可能性があります。MicrosoftのDLPアラートには単一イベントアラートと集約イベントアラートがあり、集約アラートは一定期間内の複数イベントをまとめて扱う考え方です。(Microsoft Learn)
自動化では、次のような条件を組み合わせると実用性が高くなります。
- 重大度が高いアラートだけ通知する
- 外部共有や外部送信など、リスクの高いアクションに絞る
- 特定の機密情報種類や秘密度ラベルを含む場合だけ起票する
- 同一ユーザー・同一ポリシー・一定時間内のアラートをまとめる
- 初回は通知のみ、一定回数以上でチケット化する
APIで取得できる情報が増えるほど、自動化は作りやすくなります。ただし、自動化の精度はDLPポリシー設計に依存します。API変更だけで誤検知や過検知が解決するわけではありません。
展開前にやるべき検証手順
本番環境で影響を出さないために、次の流れで検証するのがおすすめです。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | Graph API、Management Activity API、SIEM、レポート、通知の利用箇所を洗い出す | API利用一覧 |
| 権限確認 | アプリ登録、Graph権限、Management API権限、管理ロールを確認する | 権限棚卸し表 |
| プレビュー検証 | テスト用DLPポリシーでアラートを発生させ、Graph APIレスポンスを比較する | 新旧レスポンス比較 |
| マッピング確認 | SIEMやDWHの取り込みフィールドを更新候補として整理する | フィールド対応表 |
| 重複検証 | Management API由来イベントとGraph API由来データの重複を確認する | 重複判定ルール |
| 自動化テスト | 通知、チケット起票、レポート生成の動作を検証する | テスト結果 |
| 段階移行 | 一部ポリシーまたは一部ワークロードで先行展開する | 移行計画 |
| 本番反映 | 監視しながら取り込みルールを更新する | 運用手順書 |
特に重要なのは、プレビュー検証で「DLPアラートの種類ごとにレスポンスを確認する」ことです。Exchange、SharePoint、OneDrive、Teams、Endpoint DLPでは、イベントの性質や取得できる情報が異なる可能性があります。Activity Explorerでも、Exchange、SharePoint、OneDrive、Teams、オンプレミスSharePoint、Endpoint DLPのデバイスレベル活動など、さまざまなDLPポリシー一致イベントを扱うと説明されています。(Microsoft Learn)
失敗しやすいポイント
Graph APIだけで全部取れると思い込む
今回の更新はGraph APIを強化するものですが、監査ログ、全イベント、履歴保管、ワークロード別の詳細まで完全に置き換えるとは限りません。移行判断は、実際のレスポンスと業務要件で決める必要があります。
プレビューのレスポンスを本番仕様として固定する
プレビュー段階の仕様は変わる可能性があります。フィールド名、入れ子構造、値の有無、対象ワークロードは、一般提供までに調整される可能性があります。パーサーやSIEMマッピングは、未知フィールドやnull値に強い設計にしましょう。
既存の相関ロジックをそのまま使う
これまでManagement Activity APIのイベント時刻を基準に相関していた場合、Graph APIのアラート作成時刻や更新時刻とは差が出る可能性があります。時刻だけでなく、ユーザー、ファイル、ポリシー、インシデントIDを組み合わせて判定するべきです。
権限を整理しないまま移行する
Graph APIとManagement Activity APIを並行利用すると、アプリ登録や権限が複雑になります。検証用、本番用、レポート用、SIEM用のアプリが混在している場合は、どのアプリが何を取得しているかを整理してから移行しましょう。
DLPポリシーの品質を見直さない
APIでデータが増えても、DLPポリシーが粗いままだとアラートノイズも増えます。機密情報の種類、秘密度ラベル、対象ユーザー、例外条件、アラート集約条件を見直し、運用で使えるアラートに調整することが大切です。
管理者・開発者向けチェックリスト
展開前に、最低限次の項目を確認しておきましょう。
| 対象 | チェック項目 |
|---|---|
| Purview管理者 | DLPポリシーでアラートが有効になっている |
| Purview管理者 | 対象ワークロードとポリシー条件が現在の業務要件に合っている |
| Defender管理者 | Defender XDRのインシデントキューでDLPアラートを確認できる |
| Defender管理者 | DLP調査担当者のロールが最小権限で設定されている |
| 開発者 | GET /security/alerts_v2のレスポンス差分を取得している |
| 開発者 | 新しいDLP関連データを受けても既存処理が失敗しない |
| 開発者 | Management Activity APIとの重複判定ルールを用意している |
| SOC | SIEMのフィールドマッピングと検知ルールを見直している |
| SOC | 通知やチケット起票のノイズを抑える条件を設定している |
| 監査担当 | 監査証跡として必要なデータがGraph APIだけで足りるか確認している |
今回の更新で取るべき次の行動
Microsoft Purview DLPの今回のGraph API拡張は、DLPアラートを外部システムへ連携している組織にとって実務的な改善です。特に、SIEM連携、自動化ワークフロー、カスタムレポートの実装では、これまで分かれていたDefenderアラート情報とDLPルール一致イベント情報を扱いやすくなる可能性があります。
一方で、既存のManagement Activity API連携をすぐ廃止する更新ではありません。まずは現在のAPI利用箇所を棚卸しし、プレビュー期間中にGraph APIのレスポンス差分を確認しましょう。そのうえで、SIEMマッピング、重複判定、権限、DLPポリシー設計を段階的に見直すのが安全です。
最初に着手すべきことはシンプルです。DLPアラートを取得・通知・集計しているシステムを一覧化し、/security/alerts_v2の検証環境を用意してください。今回の更新は、API連携を減らすチャンスであると同時に、DLPアラート運用を見直すよいタイミングです。
コメント