Microsoft Purview の「Get started with Power Automate integration」は、DLPルールに一致したイベントをきっかけに、Power Automate のワークフローを起動できるようにする連携機能です。結論から言うと、既存の DLP ポリシーが自動的に変更される更新ではありません。管理者が確認すべきポイントは、対象となる場所、Power Automate 側のライセンスとコネクタ制御、フロー所有者、SharePoint / OneDrive の既存ファイルに関する制限です。2026年6月26日更新の公式情報では、強制移行や明確な移行期限は示されていないため、「すぐ置き換える」よりも「どの DLP 違反を業務フローにつなぐべきか」を整理することが重要です。(Microsoft Learn)
Microsoft Purview DLP と Power Automate integration の要点
Microsoft Purview DLP は、機密情報を含むメール、ファイル、デバイス上の操作などを検出し、警告、ブロック、監査、アラートなどの保護アクションを実行する仕組みです。今回の「Power Automate integration」は、この DLP ルールのアクションとして、カスタム Power Automate ワークフローを起動できる点が特徴です。(Microsoft Learn)
従来の DLP 運用では、違反検知後に管理者がアラートを確認し、関係者へ連絡し、チケットを作成し、上長へ共有するといった作業が発生しがちでした。Power Automate 連携を使うと、これらの後続処理を DLP ルールに組み込めます。
| 確認項目 | 更新ポイント | 管理者が取るべき行動 |
|---|---|---|
| 機能の位置付け | DLP ルールのアクションとして Power Automate ワークフローを起動できる | 既存ルールに追加すべき業務フローを洗い出す |
| 対象場所 | Exchange メール、SharePoint Online / OneDrive のファイル、Windows デバイス 24H2 以上が対象 | 自社の重要 DLP シナリオが対象場所に含まれるか確認する |
| ライセンス | 既存 DLP 顧客は追加の Purview ライセンス要件なし。ただし、カスタムフローでプレミアムコネクタを使う場合は Power Automate プランが必要 | フローで使うコネクタのライセンスを事前確認する |
| 権限 | DLP ポリシー作成に必要な Purview 側ロールは基本的に従来通り | Purview 管理者と Power Automate 管理者の責任分界を決める |
| 制限 | SharePoint / OneDrive では、新規または変更されたコンテンツのみワークフロー実行対象 | 既存ファイルの棚卸しや再スキャン目的に使わない |
| 移行期限 | 公式情報上、強制移行や廃止期限は明記されていない | 期限対応ではなく、段階導入として計画する |
何ができるようになるのか
Power Automate integration の価値は、DLP 違反を「検知して終わり」にせず、実際の対応プロセスにつなげられる点にあります。Microsoft の公式ドキュメントでは、DLP ポリシー違反時に上長へ通知するテンプレートが例示されています。このテンプレートでは、違反ユーザー名とポリシー名を含むメールを上長に送信でき、送信者や追加情報は Power Automate 側でカスタマイズできます。(Microsoft Learn)
実務では、次のような使い方が考えられます。
外部送信メールの DLP 違反を上長へ通知する
たとえば、個人情報や財務情報を含むメールが社外宛てに送信されようとした場合、DLP で検知し、Power Automate から上長やセキュリティ担当者へ通知します。
単にアラートを出すだけでは、管理者が気付くまでに時間が空くことがあります。上長通知を組み合わせることで、現場側での確認や再教育を早められます。
SharePoint / OneDrive の共有リスクを対応フローへつなげる
機密ラベル付きファイルや個人情報を含むファイルが SharePoint または OneDrive で共有された場合に、関係者へ確認依頼を送る、担当部署へレビューを依頼する、といった処理が可能です。
ただし、SharePoint / OneDrive では既存ファイルが DLP 条件に一致していても、それだけでは Power Automate ワークフローは実行されません。公式情報では、新規または変更されたコンテンツのみが対象とされています。既存ファイル全体の洗い出しには、DLP アラート、Activity explorer、監査ログなど別の確認手段を組み合わせる必要があります。(Microsoft Learn)
Windows デバイスの操作をインシデント対応へつなげる
Windows デバイス 24H2 以上も対象場所に含まれています。たとえば、機密情報を含むファイルに対するリスクの高い操作を DLP で検知し、セキュリティチームの確認フローへ連携する設計が考えられます。(Microsoft Learn)
ここで大切なのは、すべての DLP 検知を自動化しないことです。軽微なイベントまで通知やチケット化すると、関係者が通知に慣れてしまい、本当に重要なアラートへの反応が遅れます。最初は「情報漏えいにつながる可能性が高い」「人の判断が必要」「対応手順が定型化できる」イベントに絞るのが現実的です。
影響範囲：既存環境で変わること、変わらないこと
今回の更新で重要なのは、Power Automate が DLP ルールの新しい実行先になる点です。一方で、既存の DLP ポリシーが自動的に Power Automate を呼び出すわけではありません。
| 領域 | 影響 | 注意点 |
|---|---|---|
| 既存 DLP ポリシー | 自動変更は想定しにくい | 管理者がルールアクションとして追加しない限り、フローは起動しない |
| Exchange | メール関連の DLP ルールで活用可能 | 誤通知を避けるため、外部送信、特定機密情報、重大度などで条件を絞る |
| SharePoint / OneDrive | ファイル関連イベントに活用可能 | 既存ファイルは、変更されない限りワークフロー起動対象にならない |
| Windows デバイス | 24H2 以上のデバイスが対象 | 対象 OS、デバイス管理、Endpoint DLP の前提を確認する |
| Power Automate | フロー、コネクタ、環境、所有者管理が影響 | Power Platform 側のデータポリシーやコネクタ分類と衝突しないか確認する |
| 運用チーム | DLP 管理者だけでなく、Power Platform 管理者、セキュリティ運用担当が関係 | フロー停止時の責任者を事前に決める |
Microsoft Purview DLP 自体は、Exchange、SharePoint、OneDrive、Teams、デバイス、オンプレミスリポジトリ、Power BI など幅広い場所を対象にできます。ただし、Power Automate integration の対象場所は公式情報上、Exchange メール、SharePoint Online / OneDrive のファイル、Windows デバイス 24H2 以上に限定されています。DLP 全体の対応範囲と、Power Automate 連携の対応範囲を混同しないことが重要です。(Microsoft Learn)
設定変更の基本：DLP ルールに「ワークフロー起動」を追加する
Power Automate integration は、DLP ルールのアクションとして設定します。公式情報では、Power Automate ポータルから作成する方法と、DLP ルール作成画面で「Start a Power Automate workflow」をアクションとして追加し、テンプレートまたはカスタムワークフローを作成する方法が示されています。(Microsoft Learn)
実務では、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 自動化したい DLP イベントを選ぶ | 人手対応が多い、重大度が高い、対応手順が決まっているものを優先 |
| 2 | 対象場所を確認する | Exchange、SharePoint / OneDrive、Windows デバイス 24H2 以上に該当するか |
| 3 | テンプレートかカスタムフローかを選ぶ | 上長通知だけならテンプレート、承認・チケット化・複数部門連携ならカスタム |
| 4 | Power Automate でフローを作成する | Microsoft Purview コネクタの DLP トリガーを使う |
| 5 | DLP ルールにフロー起動アクションを追加する | 既存ルールへ追加するか、新規ルールとして分離するかを決める |
| 6 | 小さな範囲で検証する | パイロットユーザー、特定サイト、特定ポリシーから始める |
| 7 | 所有者・接続・監視方法を文書化する | 作成者退職や接続切れで止まらないようにする |
シミュレーションと本番検証は分けて考える
DLP ポリシーは、いきなり広範囲へ適用せず、段階的に展開するのが基本です。Microsoft は、DLP ポリシーの展開ではスコープ、状態、アクションを調整しながら、影響の小さい状態から始めることを推奨しています。また、シミュレーションモードでは構成済みアクションは適用されないため、Power Automate の実行確認まで含める場合は、対象範囲を絞ったパイロット運用で検証する必要があります。(Microsoft Learn)
おすすめは、まずシミュレーションで「どの程度イベントが発生するか」を確認し、その後、少人数または限定サイトで実際のフロー起動を検証する進め方です。
ライセンスと権限で確認すべきポイント
Power Automate integration は、Purview DLP 側だけで完結する機能ではありません。DLP ルールは Microsoft Purview 側で管理しますが、実際に動く処理は Power Automate のフローです。そのため、ライセンス、権限、コネクタ制御をセットで確認する必要があります。
Purview 側のライセンス
公式情報では、Microsoft Purview DLP の既存顧客は、Power Automate integration を使うために追加の Purview ライセンス要件はないとされています。(Microsoft Learn)
ただし、これは「Power Automate 側のすべての機能が追加費用なしで使える」という意味ではありません。フローで使うコネクタや機能によっては、Power Automate 側のライセンス確認が必要です。
Power Automate 側のライセンス
カスタムフローでプレミアムコネクタを使う場合は、Power Automate プランが必要です。一方、テンプレートへアクセスするだけであれば Power Automate ライセンスは不要と説明されています。(Microsoft Learn)
Power Automate のライセンスは、ユーザー単位のライセンスと、フローなどの自動化単位に割り当てる容量ライセンスがあります。プレミアムコネクタ、デスクトップ自動化、AI Builder などを使う場合は、どのライセンスでカバーするかを事前に確認してください。(Microsoft Learn)
Purview 側の権限
DLP ポリシーの作成・展開には、Compliance administrator、Compliance data administrator、Information Protection、Information Protection Admin、Security administrator などのロールグループが関係します。Power Automate integration を DLP ルールアクションとして使うこと自体で、DLP ポリシー作成に必要なロールが変わるわけではありません。(Microsoft Learn)
Power Automate 側の所有者管理
Power Automate のフローは、既定では作成者だけが利用・管理できる状態です。他の管理者がアクセスして利用するには、フロー作成者による共有が必要です。共同所有者を追加すると、実行履歴の確認、フローの編集、接続情報の更新、所有者追加などが可能になります。(Microsoft Learn)
ここは運用上の落とし穴です。個人アカウントで作ったフローを DLP ルールに紐づけると、作成者の異動、退職、接続資格情報の期限切れによって、重要な通知や対応フローが止まる可能性があります。少なくとも本番用フローには、複数の共同所有者、管理用グループ、接続情報の更新手順を用意しておきましょう。
Power Platform のデータポリシーとの違いに注意する
ここで混同しやすいのが、Microsoft Purview DLP と Power Platform のデータポリシーです。
Microsoft Purview DLP は、Microsoft 365 やデバイス上の機密情報を検出し、保護アクションを実行する仕組みです。一方、Power Platform のデータポリシーは、Power Apps や Power Automate のコネクタ利用を制御する仕組みです。Power Platform では、コネクタを Business、Non-Business、Blocked のデータグループに分類し、異なるグループ間でのデータ共有を制限できます。(Microsoft Learn)
Power Automate integration を使う場合、この2つが同時に関係します。
たとえば、DLP 違反を検知して Power Automate フローを起動し、そのフローが SharePoint と外部サービスのコネクタを組み合わせて使う設計だったとします。Power Platform 側のデータポリシーで、それらのコネクタが別グループに分類されていると、フロー作成や実行が制限される可能性があります。
そのため、管理者は次の3点を確認してください。
- フローで使うコネクタが、Power Platform のデータポリシーで許可されているか
- 本番環境、検証環境、既定環境でデータポリシーが違わないか
- HTTP、カスタムコネクタ、外部 SaaS 連携を使う場合、セキュリティ部門の承認を得ているか
DLP 違反をきっかけに自動化する機能で、別の経路から情報を外部へ送ってしまっては本末転倒です。Power Automate integration は便利ですが、連携先コネクタのガバナンスまで含めて設計する必要があります。
移行期限はあるのか
2026年6月26日更新の公式情報を確認する限り、「既存機能の廃止」「旧方式からの強制移行」「いつまでに設定変更が必要」といった移行期限は示されていません。したがって、この更新は期限対応ではなく、DLP 違反後の対応を自動化するための新しい選択肢として捉えるのが適切です。(Microsoft Learn)
ただし、移行期限がないからといって放置してよいわけではありません。特にグローバル企業では、リージョンや拠点ごとに DLP 違反後の対応速度がばらつきやすく、時差によって初動が遅れることがあります。Power Automate で通知、承認、エスカレーションを標準化できれば、DLP 運用の属人化を減らせます。
優先度は、次の基準で決めるとよいでしょう。
| 優先度 | 対象シナリオ | 理由 |
|---|---|---|
| 高 | 個人情報、認証情報、財務情報など重大情報の外部共有 | 初動遅れのリスクが高い |
| 高 | 違反後に必ず上長確認やセキュリティ確認が必要な業務 | 定型処理として自動化しやすい |
| 中 | アラート件数が多く、管理者の手作業が重いルール | 通知条件を絞れば効果が出やすい |
| 中 | 海外拠点や複数部門にまたがる確認プロセス | 標準化の効果が大きい |
| 低 | 参考レベルの軽微な検知 | 通知疲れを起こしやすい |
失敗しやすいポイント
すべての DLP イベントを通知してしまう
最も多い失敗は、DLP ルールに一致したイベントを何でも通知対象にすることです。これを行うと、上長やセキュリティ担当者に大量の通知が届き、重要な通知が埋もれます。
最初は、重大度の高いルール、外部共有、特定の機密情報タイプ、特定部門などに絞りましょう。フロー側でも条件分岐を設け、低リスクイベントは記録だけ、高リスクイベントは通知と承認を行う、といった設計が有効です。
フローの所有者が1人だけになっている
Power Automate のフローは、作成者に依存しやすい運用になりがちです。作成者が退職したり、接続情報が失効したりすると、DLP 違反時の自動対応が止まる可能性があります。
本番運用では、個人に依存しない所有者設計が必要です。共同所有者を追加し、接続情報の更新手順を残し、フローの実行履歴を誰が確認するかを決めておきましょう。
SharePoint / OneDrive の既存ファイルにも自動実行されると誤解する
公式情報では、SharePoint / OneDrive の Power Automate ワークフローは新規または変更されたコンテンツに対して実行され、既存ファイルがルールに一致しているだけではフローは起動しません。既存ファイルのリスクを洗い出したい場合は、DLP のレポート、Activity explorer、監査ログなどの確認と組み合わせてください。(Microsoft Learn)
Power Platform のデータポリシーを確認していない
Power Automate 側のコネクタ制御を確認しないままフローを作ると、検証環境では動いたのに本番環境で動かない、特定のコネクタだけ使えない、といった問題が起きます。
Power Platform のデータポリシーでは、コネクタが Business、Non-Business、Blocked に分類され、異なるグループ間のデータ共有が制限されます。セキュリティ対応フローほど、接続先が適切かを厳しく確認してください。(Microsoft Learn)
管理者向けチェックリスト
Power Automate integration を導入する前に、少なくとも次の項目を確認しておくと安全です。
| チェック項目 | 確認内容 |
|---|---|
| 対象 DLP ルール | どのルールでワークフローを起動するか |
| 対象場所 | Exchange、SharePoint / OneDrive、Windows デバイス 24H2 以上のどれか |
| 通知先 | 上長、セキュリティ担当、データ所有者、ヘルプデスクなど |
| フロー種別 | テンプレート利用か、カスタムフローか |
| コネクタ | 標準コネクタか、プレミアムコネクタか |
| ライセンス | Power Automate プランが必要か |
| Power Platform データポリシー | 使用コネクタが許可されているか |
| 所有者 | 複数の共同所有者または管理グループを設定しているか |
| 接続情報 | 個人依存の接続になっていないか |
| 検証方法 | シミュレーション、パイロット、本番展開の順序を決めているか |
| 監視 | フロー失敗、DLP アラート、Activity explorer を誰が見るか |
| ドキュメント | 変更理由、対象ルール、通知文面、復旧手順を記録しているか |
実務でのおすすめ導入パターン
最初から大規模に導入するよりも、1つの高リスクシナリオに絞って始めるのが現実的です。
おすすめは、次のような流れです。
まず、外部送信メールや外部共有ファイルなど、情報漏えいリスクが明確な DLP ルールを1つ選びます。次に、Power Automate のテンプレートまたは簡単なカスタムフローで、上長またはセキュリティ担当者への通知を実装します。最初の段階では、複雑な承認プロセスや外部システム連携を入れすぎない方が安定します。
その後、通知件数、誤検知、対応時間、フロー失敗率を確認します。通知が多すぎる場合は条件を絞り、対応が遅い場合は通知先やエスカレーション条件を見直します。安定したら、チケット化、承認、記録保存、複数部門への通知などへ広げるとよいでしょう。
Microsoft Purview の Power Automate integration は、DLP を「検知中心の運用」から「対応まで含めた運用」へ進めるための機能です。移行期限に追われる更新ではありませんが、重要な DLP 違反に対する初動を速くし、対応手順を標準化する効果があります。管理者は、対象場所、ライセンス、権限、フロー所有者、Power Platform のコネクタ制御を確認したうえで、小さな範囲から段階的に導入するのが安全です。
コメント