【Power Automate】管理センターのDLPでつまずく時の入力値と条件分岐の直し方

Power Automateの管理センターでデータ損失防止(DLP)ポリシーを設定すると、想定外のタイミングでフローがブロックされることがあります。特に、コネクタの入力値に機密情報が含まれる場合や、条件分岐のロジックがポリシーに抵触するケースでつまずきがちです。この記事では、DLPポリシーによるブロックの原因を入力値と条件分岐の観点から切り分け、具体的な修正方法を解説します。会社のポリシーを守りながらフローを正常に動作させるための実践的な手順を確認してください。

DLPポリシーによるフローブロックの原因を理解する

Power AutomateのDLPポリシーは、組織外へのデータ送信や機密情報の流出を防ぐために、特定のコネクタやアクションを制限します。フローがブロックされる原因は大きく分けて二つあります。一つは、使用しているコネクタがDLPポリシーで禁止されている区分(非ビジネスやカスタムコネクタ)に分類されているケース、もう一つは、アクションの入力値にクレジットカード番号や個人情報など、ポリシーで定義された機密情報パターンが含まれているケースです。後者は特に気づきにくく、フローが不定期にエラーになる原因となります。

例えば、SharePointのリストから取得したデータをメールで送信するフローで、リスト内に顧客の電話番号が含まれている場合、DLPポリシーが「電話番号の送信」を禁止していれば、そのメール送信アクションがブロックされます。エラーは「AccessDenied」や「DataLossPreventionViolation」といったメッセージで報告されます。

ブロックされたフローのエラーメッセージの確認方法

まずは、フローがどの時点でブロックされたかを確認する必要があります。Power Automate ポータルにサインインし、該当フローの「実行履歴」を開いてください。失敗した実行を選択すると、各アクションのステータスが表示されます。赤いアイコンが付いたアクションをクリックし、詳細なエラーメッセージを確認します。メッセージに「DataLossPreventionViolation」とあれば、DLPポリシーによるブロックが原因です。

入力値が原因でブロックされる典型的なパターン

DLPポリシーを設定する際、管理者は「機密情報の種類」としてクレジットカード番号、社会保障番号、銀行口座番号などを指定できます。これらのパターンに一致する文字列が入力値に含まれていると、そのアクションは実行されません。典型的なパターンを以下の表にまとめました。

機密情報の種類	一致する値の例	影響を受けるアクション
クレジットカード番号	4111-1111-1111-1111	メール送信、HTTPリクエスト、ファイル書き込み
社会保障番号(米国)	123-45-6789	コネクタを介した外部出力全般
パスポート番号	AB1234567	SharePointリストへの書き込み、Dataverse操作

これらの値がフロー内で動的に生成される場合、静的なテキストでなくてもDLPが検出します。例えば、Excelの行から読み取った値や、フォームの回答をそのままメール本文に埋め込むと引っかかります。

失敗パターン:入力値をマスクせずに転送する

よくある失敗は、ユーザーが機密情報を含む可能性のある入力をそのまま別のコネクタに渡してしまうことです。特に「データ操作」アクションで結合した文字列や、JSONのプロパティ値を直接送信すると、DLPに抵触します。この場合、フロー自体は設計上正しくても、ランタイムでブロックされるため原因特定に時間がかかります。

条件分岐を用いた回避策の実装手順

DLPポリシーを変更せずにフローを動作させるには、条件分岐で機密情報を含まない場合のみアクションを実行する方法が有効です。以下の手順で実装します。

1. Power Automateポータルで該当フローを開き、編集画面にします。
2. ブロックされているアクションの前に「条件」アクションを追加します。トリガーの直後でも構いません。
3. 条件の左辺に、機密情報が含まれているかチェックしたい項目(動的コンテンツ)を指定します。例えば、メール本文となる変数やSharePointリストの列値です。
4. 条件の右辺には、機密情報のパターンを正規表現または特定の文字列で指定します。Power Automateの「条件」アクションでは正規表現が使えないため、代わりに「コントロール」の「Apply to each」内で「含む」演算子を使うか、Azure Functionsや「変数の設定」と組み合わせて判定します。
5. 機密情報が含まれない場合(偽の分岐)にのみ、元のアクション(例:メール送信)を実行します。含まれる場合(真の分岐)は、代替アクション(例:管理者への通知やログ出力)を行います。
6. フローを保存し、テスト実行でブロックされないことを確認します。

注意点として、条件分岐で機密情報を完全に除去するのではなく、送信そのものを停止する設計にしてください。機密情報をマスクする処理(例:「123-45-6789」を「***-**-****」に変換)を追加することも可能ですが、マスク後も元の値が別のアクションで使われるとリスクが残ります。

比較表:DLPポリシーの影響範囲と対応方法

DLPポリシーによる制限は、コネクタの区分とアクションの種類によって異なります。以下の表で主なケースを比較します。

状況	ブロックされる対象	推奨対応方法
ビジネスコネクタ(例:SharePoint, Outlook)で機密データを含む出力	特定のアクション(メール送信、ファイル作成など)	条件分岐で機密データを除外、または管理者にポリシーの例外を申請
非ビジネスコネクタ(例:Twitter, Gmail)の使用	コネクタ全体がブロック	ビジネスコネクタへの切り替え、または管理者によるポリシー緩和
カスタムコネクタの利用	カスタムコネクタのアクション全般	ポリシーでカスタムコネクタをビジネス区分に変更してもらう

このように、入力値の問題とコネクタ区分の問題では対応が異なります。まずはどちらの原因かを切り分けてください。

管理者に確認すべきポイントと注意点

DLPポリシーそのものを変更する場合は、必ずPower Platform管理者に相談してください。自分で変更できる環境は限られており、誤った設定で組織全体のフローが停止するリスクがあります。管理者に依頼する際は、以下の情報を整理して伝えるとスムーズです。

• 影響を受けているフローの正確な名前とID(URLから取得可能)
• ブロックされているアクションとエラーメッセージのスクリーンショット
• そのアクションで使用しているコネクタの一覧と、入力値に含まれる可能性のあるデータの種類
• 条件分岐などの回避策を試した結果(成功・失敗の別)

管理者はこれらの情報をもとに、ポリシーの対象範囲を調整するか、特定のコネクタをビジネス区分に変更するなどの対応を行います。ただし、ポリシーを緩和する際は、セキュリティポリシーとの整合性を確認する必要があるため、時間がかかる場合があります。

失敗パターン:管理者に相談せずにポリシーを変更しようとする

一般のユーザーがPower Platform管理センターにアクセスしようとしても、権限がないためエラーになります。また、SharePoint管理者やTeams管理者でもPower AutomateのDLPポリシーを編集できるとは限りません。必ず「Power Platform管理者」または「Dynamics 365管理者」のロールを持つ人に依頼してください。

よくある質問(FAQ)

Q: DLPポリシーのエラーが出たが、入力値に機密情報は含まれていないはずです。
A: 想定外のパターンが一致している可能性があります。例えば、連続した数字の羅列がクレジットカード番号と誤判定されることがあります。Power Automateの「機械情報の種類」定義を管理者に確認し、テストデータで検証してみてください。

Q: 条件分岐を使って回避したが、それでもブロックされる。
A: 条件分岐で機密情報を含む場合のアクションにもDLPが適用されるからです。真の分岐で何も実行しない、または安全なアクション(例:内部ログへの書き込みのみ)に限定する必要があります。また、条件式自体が常に真になっていないか、デバッグログで確認してください。

Q: ポリシーを一時的に無効にしてもらえますか?
A: 可能ですが、推奨しません。DLPポリシーは組織のセキュリティ基準に基づいて設定されています。一時的な無効化は監査上問題となるため、恒久的な対応としてフロー側の修正またはポリシーの適切な調整を依頼してください。

まとめ

Power Automate管理センターのDLPポリシーでつまずいた時は、まずエラーメッセージを確認し、ブロックの原因が入力値の機密情報パターンなのか、コネクタ区分の問題なのかを切り分けてください。入力値が原因の場合は、条件分岐を用いて機密情報を含む場合のアクションをスキップすることで回避可能です。コネクタ区分が原因の場合は、管理者にポリシーの調整を依頼する必要があります。いずれにしても、勝手なポリシー変更はせず、適切な手順で対応することが重要です。フローを安定稼働させるためにも、DLPポリシーの仕組みを理解し、セキュリティと利便性のバランスを取ってください。