Power Platform 管理センターのデータ ポリシー（DLP）｜社員のフローが社外へつなぐのを止める設定

たとえば、社員が Power Automate で「SharePoint のリストに入った問い合わせを、自分の Gmail に送る」フローを作ったとします。管理者が Power Platform 管理センターで何も設定していなければ、このフローは作れて、そのまま動きます。社外へつなぐフローを、管理者が知らないうちに作れる状態です。

こうしたフローは、データ ポリシーで止められます。どのコネクタをどのグループに置けばよいか、データ ポリシーでは止まらない使い方を何で止めるかが分かれば、管理者が最初に決めることはそろいます。当社は Microsoft 365 の導入を支援している会社で、ライセンスの販売はしていません。

データ ポリシーは、DLP（データ損失防止）ポリシーとも呼ばれます。名前が似ていますが、メールやファイルの中身を見て送信や共有を止める Microsoft Purview のデータ損失防止は別の仕組みです。こちらはPurview の DLP でマイナンバー・カード番号の送信を止める記事に書いています。

何も設定していなければ、データ ポリシーは1本も無い

Power Platform（Power Automate・Power Apps・Copilot Studio）のフローやアプリは、「コネクタ」という部品で SharePoint・Outlook・Gmail などのサービスにつなぎます。データ ポリシーは、どのコネクタを使えるか、どのコネクタを一緒に使えるかを、管理者が決める仕組みです。

このデータ ポリシーは、最初は1本もありません。Microsoft Learn「データ ポリシー戦略を実装する」は「既定では、データ ポリシーはテナントに実装されません。」と書いています。どの組織にも「既定の環境」が1つ自動で作られ、組織の全員で共有されます。ライセンスを持つ社員は、ここでフローを作り始められます。

当社の検証用の環境でも、2026年11月に［データ ポリシー］の一覧を開くと「ポリシーを作成していません」と表示されました。

既定の環境の性質や、環境を作れる人の絞り方は、Power Platform を Microsoft 365 の範囲で使う記事に書いています。この記事は、ポリシーの中身に絞ります。

データ ポリシーは、Power Platform 管理センターの［セキュリティ］>［データとプライバシー］>［データ ポリシー］にあります。ポリシーは、テナント全体（特定の環境を含める・除く）か、1つの環境に当てます。人ごとには当てられません。テナント全体のポリシーを作るには、Power Platform 管理者のロールが要ります。環境管理者が作れるのは1つの環境に当てるポリシーだけで、テナント管理者が作ったポリシーは編集できません（Microsoft Learn「データ ポリシーを管理する」）。

この記事に関連するサービス

基幹システムの刷新・移行長く使ってきた基幹システムを、止めずに移行する。詳しく見る →システム保守の引継ぎ作った人がいない業務の仕組みを、中身を書き出してから引き継ぎます。詳しく見る →受発注・在庫管理システムの開発FAX・電話・Excelで受けている注文を、取引先がWebで入れる形に。詳しく見る →kintone 導入支援業務に合うアプリ設計から内製化まで伴走します。詳しく見る →データ分析・データ基盤支援データ基盤とBIを、設計から運用まで詳しく見る →

分けると組み合わせが止まり、ブロックすると使うこと自体が止まる

データ ポリシーでは、コネクタを「ビジネス」「非ビジネス」「ブロック」の3つのグループのどれかに置きます。1つのコネクタが入れるのは1つのグループだけです。作成画面のタブの表示は「業務」「非ビジネス」「ブロック済み」です。この記事では、Microsoft Learn の言い方に合わせて「ビジネス」「非ビジネス」「ブロック」と書きます。

• ビジネスと非ビジネス：同じグループのコネクタどうしは、1つのフローで一緒に使えます。違うグループのコネクタは、一緒に使えません。
• ブロック：そのコネクタは、ポリシーを当てた環境では使えません。

冒頭の例で考えます。SharePoint をビジネスに、Gmail を非ビジネスに置くと、SharePoint と Gmail を両方使うフローは作れなくなります。Microsoft Learn「コネクタ分類」も、この組み合わせを例に挙げています。ただし、Gmail だけを使うフローは、非ビジネスのグループの中で完結するので作れます。Gmail を使うこと自体を止めたいなら、Gmail をブロックに置きます。

Microsoft Learn は「「ビジネス」 と 「非ビジネス」 は単なるラベルであり、特に意味はありません。」としています。ビジネスに置いたから安全、という意味はありません。決まるのは、どのコネクタどうしを一緒に使えるかだけです。新しくポリシーを作ると、すべてのコネクタは最初は非ビジネスに入っています。ポリシーを作っただけでは、何も止まりません。

ブロックできるコネクタと、ブロックできないコネクタ

Microsoft 365 の主なコネクタは、ブロックに置けません。SharePoint、OneDrive for Business、Microsoft Teams、Excel Online (Business)、Office 365 Outlook（Learn の一覧では Microsoft 365 Outlook）、Planner などです。Power Platform の土台になる承認・通知のコネクタと、Dataverse（Power Platform のデータベース）のコネクタも、ブロックできません。これらはビジネスか非ビジネスのどちらかにしか置けません。それ以外のコネクタは、ブロックできます。Gmail・Dropbox のような社外のサービスのコネクタ、Dataverse を除く Microsoft のプレミアム コネクタ、ブロックできないコネクタの一覧に無い Microsoft の標準コネクタです。この記事では、これらを「ブロックできるコネクタ」と呼びます。

どのコネクタがブロックできるかは、作成画面の［ブロック可能］の列で分かります。当社の検証用の環境で2026年11月に作成画面を開くと、SharePoint と OneDrive for Business は「いいえ」、Salesforce・OneDrive・SQL Server は「はい」でした。検索して確かめると、Office 365 Outlook は「いいえ」、Gmail と Microsoft Forms は「はい」でした。Microsoft Forms は Microsoft 365 のサービスですが、ブロックできるコネクタです。

ここから、置き方が決まります。会社のデータを SharePoint・OneDrive・Outlook に置いているなら、それらのコネクタはブロックできません。そこで、ブロックできないコネクタはまとめてビジネスに置き、ブロックできるコネクタはブロックに置きます。こうすると、会社のデータを社外のサービスへ渡す組み合わせも、社外のサービスだけを使うフローも作れなくなります。既定の環境についての Microsoft の推奨も、この形です（Microsoft Learn「既定の環境のセキュリティ保護」）。

既定の環境を含む全環境に当てる1本を、作成画面の順に決める

［セキュリティ］>［データとプライバシー］>［データ ポリシー］で［新しいポリシー］を選ぶと、画面の左に［ポリシー名］［事前構築済みコネクタ］［カスタム コネクタ］［スコープ］［レビュー］の手順が並びます。この順に進みます。［スコープ］で［特定の環境を除外する］を選ぶと、除外する環境を選ぶ画面が続きます（Microsoft Learn「データ ポリシーを管理する」）。当社が開いたのは［すべての環境を追加する］のままの画面だけです。ここでは、既定の環境を含むすべての環境に当てる1本を作るとして、画面ごとに選ぶものを書きます。

事前構築済みコネクタ：ブロックできないものをビジネスへ、ブロックできるものをブロックへ

コネクタの一覧には、［名前］［ブロック可能］［エンドポイント構成可能］［クラス］［公開元］［詳細］の列が並びます。［クラス］は、標準かプレミアムかの区別です。ブロックできないコネクタを選んでも、［ブロック］の操作は使えず、警告が出ます（Microsoft Learn「データ ポリシーを管理する」）。

全社員に、会社のデータと一緒に使わせてよい社外のサービスがあれば、それだけをブロックからビジネスに移します。Microsoft Forms のように、ブロックできる Microsoft 365 のコネクタを社内で使っているなら、それもビジネスに移します。一部の部署だけが使うサービスは、このポリシーでは動かさず、後の節の「例外の環境」で許します。全環境に当てる1本で移すと、既定の環境の全員が使えるようになるためです。

ブロックできるコネクタは、アクションごとに許可・ブロックも決められます。この機能を「コネクタ アクション コントロール」と呼びます。たとえば、あるコネクタで読み取りのアクションは許し、書き込みのアクションは止める、といった使い方です。ブロックできないコネクタとカスタム コネクタでは使えません（Microsoft Learn「コネクタ アクション コントロール」）。

既定のグループ：新しいコネクタをどこに入れるか

コネクタは、ポリシーを作ったあとも Microsoft が足していきます。新しいコネクタがどのグループに入るかは、［既定グループの設定］で決まり、最初は非ビジネスです。Microsoft Learn の2つのページで、勧め方が違います。データ ポリシーの作り方のページは、一般には既定を非ビジネスのままにし、コネクタを確かめてから移すことを勧めています（Microsoft Learn「データ ポリシーを管理する」）。既定の環境に当てるポリシーについては、管理者が確かめるまで新しいコネクタを使えないよう、既定をブロックにすることを勧めています（Microsoft Learn「既定の環境のセキュリティ保護」）。全員が使う既定の環境を含む1本なら、当社は既定の環境向けの勧めに合わせ、ブロックにすることをお勧めします。

既定のグループをブロックにしても、ブロックできない新しいコネクタは、ブロックではなく非ビジネスに入ります。［既定グループの設定］のパネルにも、「ブロックできないコネクタは既定で非ビジネスになります。」と書かれています。非ビジネスに入ったコネクタは、ビジネスに置いた SharePoint などと一緒には使えません。必要なら、管理者がビジネスに移します。

HTTP のコネクタ

HTTP のコネクタ（HTTP、HTTP Webhook、HTTP 要求を受信したとき）は、任意の URL にデータを送れます。社外へつなぐ使い方の代表なので、既定の環境ではブロックに置くことをお勧めします。ただし、子フロー（フローから呼び出す別のフロー）は HTTP のコネクタと内部でつながっています。HTTP をどのグループに置くかが、子フローを動かせるかに影響することがあります（Microsoft Learn「コネクタ分類」）。子フローを使う部署には、後の節の「例外の環境」を用意します。

HTTP や SQL Server など一部のコネクタには、つなぐ先の URL やサーバーを許可・拒否のリストで絞る「コネクタ エンドポイント フィルター処理」もあります。ただし、この機能はプレビューです。環境変数・カスタム入力・実行時に作る宛先には効かず、作成時に決まった宛先だけが評価されます。SQL Server と Azure Blob Storage は、Microsoft Entra ID で認証した接続には効きません（Microsoft Learn「コネクタ エンドポイント フィルター処理 (プレビュー)」）。そのため、宛先の絞り込みに頼らず、HTTP のコネクタそのものをブロックに置くことをお勧めします。

カスタム コネクタ

カスタム コネクタは、作り手が自分でつなぎ方を定義して作るコネクタです。自社や社外のシステムが外部から呼び出せるように用意している窓口（API）につなぎます。全環境に当てるポリシーでは、［カスタム コネクタ］の画面で、つなぐ先の URL のパターンごとにグループを決めます。一覧の最後の行は、すべてのカスタム コネクタに当たる「*」の行で、新しいポリシーでは「無視」になっています。「無視」のままで、ほかに当てはまるルールが無ければ、カスタム コネクタはビジネスと非ビジネスのどちらのコネクタとも一緒に使えます（Microsoft Learn「コネクタ分類」）。つまり、カスタム コネクタで SharePoint のデータを社外の API へ送るフローも作れます。

Microsoft は、既定の環境では、すべての URL パターンをブロックするルールを作ることを勧めています。「*」の行をブロックにすれば、この形になります。社内の API を使わせるなら、その URL のパターンを「*」より上の行に足します。

スコープ：すべての環境に当てる

スコープは、［すべての環境を追加する］［複数の環境を追加する］［特定の環境を除外する］の3つから選びます。最初は［すべての環境を追加する］が選ばれています。Microsoft のデータ ポリシー戦略の例では、選んだ環境を除くすべての環境に当てるポリシーを作り、このポリシーは「作成されるすべての新しい環境にも適用されます」としています（Microsoft Learn「データ ポリシー戦略を実装する」）。逆に、環境を1つずつ足す形にすると、あとから作った環境は自分で足すまで対象に入りません。基本の1本は、［すべての環境を追加する］か、例外の環境だけを［特定の環境を除外する］で除く形にすることをお勧めします。

データ ポリシーを作っても止まらない3つの使い方

前の節のポリシーで、ブロックできるコネクタを使うフローは作れなくなります。それでも、社外へデータを送る使い方が3つ残ります。どれも、ブロックできないコネクタか、接続先に関わるものです。データ ポリシーでは止められないので、別の設定で止めます。

1. Office 365 Outlook で社外へメールを送る

Office 365 Outlook はブロックできないコネクタで、ビジネスに置けば SharePoint のデータと一緒に使えます。SharePoint のリストの中身を本文に入れて、社外のアドレスへメールで送るフローは、データ ポリシーでは止まりません。Microsoft Learn は、このコネクタのリスクはメールを送る機能だとし、Exchange の管理者がルールでアプリからのメール送信を止める方法を示しています（Microsoft Learn「既定の環境のセキュリティ保護」）。

Power Automate が Office 365 Outlook で送るメールには、「x-ms-mail-application: Microsoft Power Automate」で始まるヘッダーが付きます。Exchange Online のメール フロー ルールで、このヘッダーがあり、宛先が社外のメールを止めます。こうすると、フローからの外部送信だけを止められます。Learn は、外部の受信者への送信をすべて止めるルールと、許可リストのメールボックス以外からの外部への転送を止めるルールを例に挙げています。メール フロー ルールの作り方とテストの進め方は、Exchange Online のメール運用の決めごとの記事に書いています。

2. ほかの組織のテナントにつなぐ

SharePoint や Office 365 Outlook のコネクタは、接続を作るときにサインインしたアカウントのテナントにつながります。テナントの分離がオフの初期の状態では、ほかのテナントの正しいアカウントでサインインすれば、テナントをまたぐ接続をそのまま作れます（Microsoft Learn「テナント間のインバウンドとアウトバウンドを制限する」）。そのため、社員が取引先など別の組織のアカウントでサインインすれば、会社の SharePoint のデータを別の組織の SharePoint に書き込むフローも作れます。

これを止めるのは、Power Platform 管理センターの［セキュリティ］>［ID およびアクセス管理］>［テナント分離］です。オンにすると、ほかのテナントへの接続（アウトバウンド）とほかのテナントからの接続（インバウンド）が止まり、例外に足したテナントだけを許せます。効くのは、Office 365 Outlook や SharePoint のように Microsoft Entra ID でサインインするコネクタだけです。例外のルールは500件までです。Azure DevOps のコネクタには、既知の問題でテナントの分離が効きません。Learn は、社内からの持ち出しが心配なら、このコネクタはデータ ポリシーで制限することを勧めています。テナントの分離の設定には、Power Platform の管理者の権限が要ります。同じページは、オンにする前に、テナント間の分離のレポート（プレビュー）で例外に足すテナントを確かめる流れを示しています。

画面では、［テナント分離］を選ぶと右にパネルが開き、［テナント間接続を制限する］の切り替えと［例外の追加］が並びます。Learn は既定の構成をオフとしています（Microsoft Learn「テナント間のインバウンドとアウトバウンドを制限する」）。当社の検証用のテナントでは、2026年11月に開いたときオンになっていました。オンかオフかは、このパネルで確かめてください。

3. ブロックできないコネクタそのものを使わせたくない

データ ポリシーとは別に、Microsoft は「高度なコネクタ ポリシー」を用意しています。明示的に許可したコネクタ以外をすべてブロックする仕組みで、［データとプライバシー］の同じ画面から開けます。ただし、ブロックできないコネクタまで止められるのはマネージド環境だけです。それ以外の環境では、ブロックできないコネクタはブロックできないままです。カスタム コネクタと HTTP のコネクタには、まだ使えません（Microsoft Learn「高度なコネクタ ポリシー」）。マネージド環境は、環境に共有の制限などの管理の機能を足す設定です。マネージド環境にすると、その環境を使う人全員にライセンスが要ります。その費用の考え方はPower Platform を Microsoft 365 の範囲で使う記事に書いています。

保存する前に、動いているフローが何を使っているかを確かめる

データ ポリシーは、これから作るフローだけでなく、すでに動いているフローにも当たります。保存すると、ポリシーが環境ごとに当てられます。違反するフローは中断（一時停止）されます。ブロックしたコネクタの接続は、無効になります。反映までは多くの場合1時間以内、最も長いと24時間です（Microsoft Learn「データ ポリシー」）。

違反しなくなれば、過去7日以内に一時停止されたアクティブなクラウド フロー（クラウドで動くフロー）は、自動で再開されます（Microsoft Learn「データ損失防止 (DLP) ポリシーの作成」）。それでも、業務で使っているフローが止まれば、その間の処理は行われません。保存する前に、次の2つを確かめることをお勧めします。

• ブロックに置くコネクタを、業務のフローで使っている部署があるか。あるなら、そのフローを例外の環境に移してから保存する。
• HTTP のコネクタや子フローを使っているフローがあるか。HTTP のコネクタを使うフローは、HTTP をブロックに置くと止まる。子フローも影響を受けることがある。

どのフローがどのコネクタを使っているかを全環境で一覧にするには、仕組みが要ります。Microsoft Learn は、CoE スターター キットを例に挙げています。Microsoft が公開している、Power Platform の利用状況を集めて管理するための道具一式です（Microsoft Learn「既定の Power Platform 環境の管理とガバナンス」）。

保存したら、どのコネクタがどのグループにあるかを社内に知らせます。Microsoft Learn は、データ ポリシーの一覧を組織と共有し、作り手がアプリを作る前にポリシーを知れるようにすることを勧めています。ポリシーに違反したときに作り手に出るメッセージは、PowerShell の Set-PowerAppDlpErrorSettings で変えられます。社内の問い合わせ先を入れておくと、止まったフローの作り手が次に何をすればよいか分かります。

例外は、使う人を限った別の環境とポリシーで許す

一部の部署が業務で社外のサービスや HTTP を使うなら、基本のポリシーを緩めず、別の環境を用意します。Microsoft のデータ ポリシー戦略でも、部署やプロジェクトの環境は共有の環境のポリシーから除外し、その環境だけに当てるポリシーで、使うコネクタを部署と決める形を示しています。

例外の環境を作るときに気をつけたいのは、ポリシーの重なりです。1つの環境に複数のポリシーが当たると、すべてが一緒に評価されます。どれか1本でブロックなら、そのコネクタは使えません。ビジネスと非ビジネスの分け方も、ポリシーを重ねるほど細かく割れます。作り手には、何が止まっているのかが分かりにくくなります。Microsoft は、1つの環境に当てるポリシーをできるだけ少なくするよう強く勧めています（Microsoft Learn「複数のデータ ポリシーの組み合わせ効果」）。そのため、例外の環境は基本のポリシーのスコープから除外し、その環境用のポリシーを1本だけ当てます。環境ごとのポリシーでは、テナント全体のポリシーを上書きできない点にも気をつけてください。

例外の環境は、基本のポリシーの外にある場所です。その環境でフローを作れる人は、管理者が決めて絞ります。社員が自分で作る環境は、基本のポリシーのスコープが［すべての環境を追加する］か［特定の環境を除外する］なら、自動でその対象に入ります。環境を作れる人を絞る［テナント設定］の環境の割り当ては、Power Platform を Microsoft 365 の範囲で使う記事に書いています。

次にすること

まず Power Platform 管理センターの［セキュリティ］>［データとプライバシー］>［データ ポリシー］を開き、ポリシーがあるか、あればどのコネクタがどのグループにあるかを確かめてください。1本も無ければ、社員が今どんなフローを作っているかを聞き、社外のサービスを使っている業務を書き出します。その一覧が、全環境に当てる1本でビジネスに移すコネクタと、例外の環境に移す業務を決める材料になります。

プレミアム コネクタを業務で使うときのライセンスはPower Automate のライセンスの記事、フローの作り方は最初のフローを作る記事にあります。どのコネクタをどのグループに置くかの棚卸しから一緒に進めたい場合は、Microsoft 365 の導入支援でお受けしています。

この記事の確かめ方

データ ポリシーの仕組み・手順・推奨は、2026年11月6日に Microsoft Learn の各ページで確かめました。見たのは、データ ポリシー、データ ポリシーを管理する、コネクタ分類、コネクタ アクション コントロール、コネクタ エンドポイント フィルター処理、複数のデータ ポリシーの組み合わせ効果、高度なコネクタ ポリシー、テナント間のインバウンドとアウトバウンドを制限する、データ ポリシー戦略を実装する、既定の環境のセキュリティ保護、既定の Power Platform 環境の管理とガバナンス、環境の概要、Power Automate のデータ損失防止 (DLP) ポリシーの作成です。

写真と画面の表記は、当社の検証用の環境の Power Platform 管理センターで2026年11月6日に見たものです。作成画面は［スコープ］の手順まで開いてキャンセルし、ポリシーは作成・保存していません。テナント分離の切り替えも変えていません。保存したあとにフローが中断される様子は確かめていません。組織名・環境名・名前・メールアドレス・テナント ID は、写真から切り落としています。