Microsoft(マイクロソフト)は、Microsoft 365 CopilotとCopilot Chatが機微情報を含むプロンプトを受け取った際に、Web検索によるグラウンディングだけを自動的に止める新しいMicrosoft Purview DLP(データ損失防止)制御を発表した。Microsoft 365ロードマップにID 565870として2026年6月26日に追加され、一般提供(GA)は2026年7月を予定している。クレジットカード番号や社会保障番号、医療情報などがプロンプトに含まれると判定された場合、Bingへの外部検索リクエストだけを遮断し、SharePointやExchange、Teamsといった社内データを使った回答生成はそのまま継続できる点が特徴だ。
仕組みと従来制御との違い
Purview DLPのエンジンは、Copilotがプロンプトを処理する前にテキストを検査する。300種類以上ある標準の機密情報タイプ(クレジットカード番号、社会保障番号、健康状態など)に加え、Exact Data Match(EDM)を使えば企業独自の機密文字列パターンも検出対象にできる。ポリシーに抵触すると、その1回のやり取りに限ってWebグラウンディングだけが無効化される。社内データで回答できる場合はそのまま回答が生成され、社内データもない場合はポリシー制限によりリクエストを完了できない旨の通知が表示される。
これは既存のPurview DLP制御とは仕組みが異なる。従来のDLPポリシーは、機微情報を含むプロンプトそのものをCopilotに渡す前の入り口で丸ごとブロックする「上流」型の制御だった。今回の新制御は、社内データでの評価は許可しつつ外部接続だけを切る「下流」型で、管理者はリスク許容度に応じてどちらの制御を使うか、あるいは併用するかを選べる。
実務への影響
日本のCopilot導入企業、特に金融・医療・製造業のようにデータ越境に敏感な業種では、今回の制御は「Copilotを使わせるかどうか」の二択から「どこまで使わせるか」を細かく設計できる話に変わる意味を持つ。IT管理者は7月のGAを待たずに、既存のPurview DLPポリシーとセンシティブ情報タイプの定義を棚卸しし、部署ごとに「プロンプト全体をブロック」と「Web検索だけをブロック」のどちらが適切かを見極めておきたい。特に自社固有の機密情報(契約書番号や製品コードなど)はEDMで定義しないと検出されないため、GA前に監査モードでポリシーをテストし、Purviewのアクティビティエクスプローラーでログを確認しておく価値がある。
筆者の見解
今回の制御は、私が普段から言っている「禁止ではなく、安全に使える仕組みを作る」という考え方にちょうど当てはまる機能だと感じる。プロンプトを問答無用で全部ブロックしてしまうと、ユーザーは「Copilotは使えない」と諦めて、結局管理外のAIツールにこっそりコピペする、いわゆるシャドーAIに流れてしまう。Web検索の経路だけを切って社内データでの回答は続けさせる今回の設計は、ユーザー体験を大きく損なわずにリスクを抑える、実務的によくできた落としどころだと思う。
ただ正直に言うと、「ここまで来るのに時間がかかったな」という気持ちもある。CopilotがWeb検索でグラウンディングする以上、データ越境のリスクは展開当初からわかりきっていたはずで、本来はもっと早い段階でこの粒度の制御が用意されていてもよかった。正面から勝負できる技術力があるのだから、企業導入の現場で後から噴出する懸念を後追いで塞ぐのではなく、最初から一歩先回りしたガバナンス設計をしてほしいというのが、応援する立場からの率直な注文だ。
もう一つ付け加えると、機能があることと、正しく設定・運用されていることはまったく別の話だ。DLPポリシーもセンシティブ情報タイプの定義も、放置されていれば今回の新制御は絵に描いた餅になる。Copilot導入を進める企業ほど、このタイミングをPurview DLPの設定を棚卸しする良い機会にしてほしい。
出典: この記事は Microsoft Purview DLP to Halt Copilot Web Searches for Sensitive Prompts in July 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。