Microsoft 365 Copilot を社内展開するとき、多くの管理者が最初に不安になるのが、「ユーザーが機密情報を含む内容をプロンプトに入れ、その情報が Web検索に使われないか」という点です。結論から言うと、Microsoft Purview DLP は 2026年3月から Public Preview として、Copilot と Copilot Chat の Web検索で機密データが使われるのを抑止する方向へ拡張されています。ポイントは、Web検索を全部止めるのではなく、必要に応じて内部データ活用と両立しながら、外部検索に出したくない情報だけを細かく制御しやすくなったことです。(TECHCOMMUNITY.MICROSOFT.COM)
しかも、このテーマは単なる「便利機能の追加」ではありません。Microsoft Learn の現行説明では、ユーザーのプロンプトと Copilot の応答は Microsoft 365 のサービス境界内で扱われる一方、Copilot が生成した Web検索クエリは Bing search service 側に送られ、別の取り扱いになります。さらに、生成された Web検索クエリには Microsoft 365 の DPA が適用されないと明記されているため、Web検索を許可する企業ほど、この経路を分けて統制する意味が大きいと言えます。(Microsoft Learn)
Copilot の Web検索を Purview が止める、何が新しいのか
2026年3月の Microsoft 365 Copilot 更新情報では、Purview DLP が Microsoft 365 Copilot と Copilot Chat の Web検索を保護するよう拡張され、機密データを含む Web検索を safeguard するリアルタイム制御として案内されました。Microsoft Security ブログでも、機密情報タイプ（SITs）を含むプロンプトを外部 Web検索へ送らないようにしつつ、許可された Microsoft 365 の内部データで応答できる設計が示されています。現時点では Public Preview で、世界展開は 2026年6月に進む予定です。(TECHCOMMUNITY.MICROSOFT.COM)
この制御で対象になり得るのは、クレジットカード番号、口座番号、パスポート番号、各国の national ID、独自に定義した custom SITs などです。Microsoft Learn の Copilot 向け DLP 説明でも、敏感なプロンプトを検知して Copilot の処理を制限する構成が示されており、既定ポリシーには日本の銀行口座番号やマイナンバー、Azure SAS、Azure Storage Account Key なども含まれます。(Microsoft Learn)
まず整理したい、4つの統制レイヤー
管理者が混同しやすいのは、「Web検索を切ること」と「機密データを外に出さないこと」と「内部データの過剰参照を防ぐこと」が別の統制だという点です。
| やりたいこと | 主に使う機能 | 期待できること | 向いている運用 |
|---|---|---|---|
| Public Web を組織として使わせない | Allow web search in Copilot ポリシー | Copilot / Copilot Chat の Web検索を管理者が有効・無効化できる | 規制要件上、外部検索自体を許可しにくい組織 |
| 機密を含むプロンプトだけ外部に出したくない | Purview DLP の prompt / Web検索保護 | 機密情報タイプを検知し、少なくとも Web検索への利用を抑止できる | 営業・調査・広報のように Web検索は必要だが、PII や秘密情報は外に出したくない組織 |
| 特定ファイルやメールを Copilot の根拠に使わせたくない | Purview DLP の sensitivity labels 条件 | ラベル付きファイル/メールを Copilot の処理対象から外せる | 契約書、人事資料、法務文書などを内部 grounding から除外したい組織 |
| そもそもの過剰共有を直したい | Purview DSPM for AI / SharePoint 権限 / RCD | Copilot が見に行けるデータ面積そのものを減らせる | 導入前後の権限棚卸し、oversharing 改善 |
出典: Microsoft Learn と Microsoft Tech Community の現行説明を要約。(Microsoft Learn)
2026年4月時点では、Microsoft の説明に少し幅があります。公開ブログと最新ガイダンスは「外部 Web検索を止めつつ、許可された内部データで回答できる」方向を示していますが、Copilot DLP の詳細ページでは「機密プロンプトでは Copilot が応答せず、internal / external search の両方を使わない」とも説明しています。プレビュー機能なので、管理ポータルに表示されるオプションと実際のテスト結果を、自社テナントで確認してから本番適用するのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
内部データとの両立で押さえるべき設計
Microsoft の最新ガイダンスでは、Microsoft 365 Copilot は Work IQ を使って、ユーザーが権限を持つデータをもとに応答を組み立てます。さらに、Copilot はユーザーに閲覧権限があるコンテンツだけを参照できる設計です。つまり、Web検索の統制だけでは不十分で、SharePoint / OneDrive / Exchange 側の権限、ラベル、DLP を重ねてはじめて「使えるが漏れにくい」状態になります。(Microsoft Learn)
実務では、prompt 側の制御 と 内部コンテンツ側の制御 を分けて考えるのが基本です。前者は SITs を使って機密プロンプトを検知し、後者は sensitivity labels を使って特定ファイルやメールを Copilot の処理対象から外します。なお、ラベル条件で除外したコンテンツは応答生成には使われませんが、項目自体が citations に見える場合があります。つまり「中身は使わせないが、存在までは完全に隠れない」ことがあるため、ファイル名やサイトの存在そのものが機密なら、権限見直しや Restricted Content Discovery まで含めて設計する必要があります。(Microsoft Learn)
たとえば営業部門なら、競合ニュースや相場情報の取得には Web検索を使いたい一方で、顧客の口座番号や本人確認情報が入ったプロンプトは外部検索に出したくありません。この場合、プロンプト側は SITs で止め、社内文書側は sensitivity labels で除外範囲を切り分けると、「外部検索は活かしつつ、顧客情報や高機密文書は使わせない」設計にしやすくなります。Microsoft の最新ガイダンス自体も、Work IQ の grounding を許可しつつ、Web grounding をブロックする設計を案内しています。(Microsoft Learn)
管理者が導入前にやるべき設定
Web検索を全面停止するのか、選択的に制御するのかを先に決める
まず決めるべきなのは、「Public Web を組織として使わせない」のか、それとも「Web検索は許可するが機密情報だけ止める」のかです。前者なら Cloud Policy service の Allow web search in Copilot でコントロールするのが最短です。このポリシーは Microsoft 365 Copilot と Copilot Chat の両方に適用でき、Work mode だけ無効 / Web mode と Copilot Chat は有効 という分け方も用意されています。なお、ユーザーが自分で切り替える Web content toggle は Microsoft 365 Copilot にだけあり、Copilot Chat にはありません。(Microsoft Learn)
DLP ポリシーは Copilot 専用で作る
Copilot 向け DLP は、Purview ポータルの Custom policy template で作るのが前提です。Microsoft 365 Copilot and Copilot Chat の policy location を選ぶと、そのポリシーでは他の location は無効になります。機密プロンプトを止める場合は Content contains > Sensitive information types を条件にし、アクションは Restrict Copilot from processing content > Processing prompts を使います。ファイルやメールを除外したい場合は Sensitivity labels 条件を使いますが、SIT と sensitivity labels は同じルールに同居できないため、別ルールで設計する必要があります。(Microsoft Learn)
この location は Microsoft 365 Copilot、Copilot Chat、Word、Excel、PowerPoint の Copilot で利用でき、組み込みの prebuilt agents にも保護が広がります。さらに、DLP alerts、DLP notifications、simulation mode がサポートされる一方、ポリシー変更の反映には最大4時間かかることがあります。テスト直後に効かないからといって、すぐ誤設定と決めつけないことが大切です。(Microsoft Learn)
既定ポリシーを simulation で回し、SIT を絞り込む
2026年3月時点では、Microsoft は Default DLP policy - Protect sensitive M365 Copilot interactions という既定ポリシーを用意しています。これは最初から block する設定ではなく、simulation mode でイベントを記録する構成です。実際にブロックしたい場合は enforce mode に切り替える必要があります。まずは simulation で業務影響を確認し、その後に relevant でない SITs を外す流れが現実的です。(Microsoft Learn)
既定ポリシーには、クレジットカード番号、IBAN、SWIFT、Azure SAS、Azure Storage Account Key、日本の銀行口座番号、日本のパスポート番号、日本のマイナンバーなど、かなり広い種類の SITs が入っています。便利な反面、そのままでは誤検知や過剰検知が出やすいので、自社で実際に止めたい情報だけに絞ることが重要です。Microsoft 自身も、incident reports を有効にしてセキュリティチームへ通知する設定を少なくとも入れることを推奨しています。(Microsoft Learn)
ログと監査で「本当に止まったか」まで確認する
運用で強いのは、Purview が「止める」だけでなく「見える化」もできる点です。Copilot Chat では、ユーザーが response の linked citation から、Copilot が Bing に送った正確な Web検索クエリを確認できます。ただし、この表示は Copilot Chat に限られ、チャットスレッド上で 24時間だけ見えます。管理者側では、生成された Web検索クエリを audit や eDiscovery の対象にでき、Purview DSPM for AI の Activity Explorer では prompt・response・supporting resources と並べて実際の Web検索語を確認できます。(Microsoft Learn)
より踏み込んで確認したいなら、Purview Audit で AISystemPlugin.Id を見ます。ここに BingWebSearch が入っていれば、その Copilot interaction で public web が使われたと判断できます。導入直後の検証では、「通常の公開情報プロンプトでは Web検索が動くか」「カード番号やマイナンバー入りプロンプトは止まるか」「ラベル付き社内ファイルは grounding から外れるか」を、ログまで含めてセットで確認すると判断がぶれません。(Microsoft Learn)
失敗しやすいポイント
| 失敗しやすい点 | 実際の挙動 | 対策 |
|---|---|---|
| ポリシーを作ったのに止まらない | 既定ポリシーは simulation mode なので、初期状態ではログ取得が中心 | enforce mode への切り替え有無を確認する |
| 添付ファイルの中身まで prompt DLP が見ていると思い込む | DLP は prompt に直接入力したテキストを評価し、アップロードファイルの中身はスキャンしない | sensitivity labels、権限、別の DLP で補完する |
| 1つのルールで SIT と sensitivity labels をまとめて扱おうとする | 同じルールでは両条件を併用できない | prompt 用とコンテンツ用でルールを分ける |
| ラベル型 DLP の適用範囲を広く見積もる | 対象は SharePoint Online / OneDrive のファイルと、2025-01-01 以降のメール。予定表招待は未対応で、項目自体は citations に出る場合もある | 対象データを事前に棚卸しし、存在自体を隠したい場合は権限や RCD も併用する |
| Word / Excel / PowerPoint の案内文を過信する | preview 中は、組織ポリシーでブロックされたことが UI 上で分かりにくい場合がある | ヘルプデスク向け FAQ とテストケースを先に用意する |
| すべてのテナントで同時に見えると思い込む | preview 展開と licensing update には到達差がある | まず自社テナントで feature 到達を確認する |
出典: Microsoft Learn の DLP 詳細、制限事項、既定ポリシー、preview 注意事項を要約。(Microsoft Learn)
導入企業にとっての統制メリット
この機能の一番大きな価値は、「Copilot の Web検索を止めるか、許可するか」の二択から抜けられることです。Web検索を全部オフにすると、調査、営業、広報、企画のような部門では Copilot の実用性がかなり落ちます。Purview DLP を組み合わせれば、公開情報の活用余地を残しながら、出してはいけない prompt だけを細かく抑えられます。(Microsoft Learn)
もう1つのメリットは、説明責任を持ちやすいことです。生成された Web検索クエリは exact match で監査・検索でき、DSPM Activity Explorer でも確認できます。つまり、「どの prompt が Web検索に回ったか」「何が Bing に送られたか」を、感覚ではなくログで追えます。(Microsoft Learn)
そして最後に、内部データ統制との相性がよい点も大きいです。Microsoft は Copilot 導入時のガードレールとして、oversharing の是正、ラベル、DLP、監査、DSPM を重ねる設計を案内しています。つまり、今回の Web検索保護は単独で使うより、「社内で見せてよい情報」と「外に出してよい情報」を分けるレイヤーとして入れたほうが効果を発揮します。(Microsoft Learn)
まずやること
最初の一歩は、次の3つで十分です。
- まず Microsoft 365 管理側で、Web検索を tenant 全体で止めるのか、Purview DLP で選択的に守るのかを決める。(Microsoft Learn)
- Purview の既定 Copilot DLP ポリシーを開き、simulation mode のまま relevant な SITs だけに絞る。不要な国別 ID や業務に関係ない検知項目を減らす。(Microsoft Learn)
- 次の3パターンを必ずテストする。
公開情報だけの prompt、カード番号やマイナンバーなどを含む prompt、ラベル付き社内ファイルを参照する prompt。そのうえで Audit と DSPM Activity Explorer を見て、期待どおりに止まっているか確認する。ポリシー変更後は反映まで最大4時間を見込む。(Microsoft Learn)
Copilot 導入で本当に怖いのは、「AI 全体」ではなく、「どの経路で何が外に出るのか」が見えないことです。Purview DLP による Web検索保護は、その経路を切り分けて統制するための、かなり実務的な一手です。Web検索を全部止める前に、まずはこのレイヤーを設計してから判断したほうが、業務と統制を両立しやすくなります。(Microsoft Learn)
コメント