Purview DLP が Copilot のプロンプト自体を保護 何を止められる?適用粒度と運用の勘所

Purview DLP がいま注目される理由は、Microsoft 365 Copilot に「何を見せるか」だけでなく、「何を入力させないか」まで管理できるようになってきたからです。Copilot に入力したプロンプトに機密情報が含まれる場合、Microsoft Purview DLP は応答そのものを止めたり、社内データへのグラウンディングや Web 検索への利用を制御したりできます。2026年4月4日時点の公式情報では、プロンプト内の機密情報を検知して全面的に抑止する保護はプレビュー、外部 Web 検索だけを止める保護は3月に Public Preview として案内されており、Copilot 導入可否の判断材料としてかなり重要です。(TECHCOMMUNITY.MICROSOFT.COM)

この機能の本質は、Copilot の安全性を「出力後に確認する」発想から、「入力時点で統制する」発想へ一段引き上げることにあります。この記事では、Purview DLP が Copilot のプロンプト自体をどこまで保護できるのか、何を止められるのか、DLP の適用粒度、現場運用と両立する設計、見落としやすい制約まで、実務目線で整理します。

目次

Copilot への入力そのものを Purview が守る意味

まず前提として、Microsoft 365 Copilot はユーザーが閲覧権限を持つデータしか返さず、プロンプトや応答は Microsoft 365 のサービス境界内で扱われ、基盤 LLM の学習にも使われません。つまり「入力した内容が学習に使われるのでは」という不安と、「機密情報をプロンプトに入れてよいのか」という不安は、別の論点です。Purview DLP が今回強く効くのは後者です。(Microsoft Learn)

しかも Web 検索が有効な場合、Copilot はユーザーの元のプロンプトをそのまま Bing に送るのではなく、数語の検索クエリを生成して送ります。ユーザーの全文プロンプトや文書全文は通常送られませんが、プロンプトが極端に短い場合や、Word などで文書を開いたまま質問した場合、あるいは特定文書を明示参照した場合は、その文脈が検索クエリ生成に影響し得ます。だからこそ、「外部に全文送っていないから大丈夫」で済ませず、入力時点の DLP が必要になります。(Microsoft Learn)

何を止められるのかを3つに分けて見る

保護の種類何を見て判定するか起きる動作向いている場面
プロンプト自体のブロックプロンプト本文に含まれる Sensitive information types(SIT)Copilot が応答しない。プロンプトは内部検索にも Web 検索にも使われないクレジットカード番号、国民 ID、銀行口座番号、旅券番号などを入力させたくない
ラベル付きコンテンツの除外ファイルやメールに付いた感度ラベルその項目の内容は応答生成に使われない。ただし項目自体は引用元として見える場合がある「極秘」「個人情報」ラベルの文書を Copilot に要約・引用させたくない
Web 検索だけの抑止機密情報を含むプロンプトの外部 Web グラウンディングBing への送信は止めるが、許可された社内データによる回答は継続できる外部送信は防ぎたいが、社内データベースや SharePoint を使った回答は残したい

上の3つは同じ Purview DLP でも役割が違います。特に重要なのは、全面ブロックとWeb だけ止める制御は別物だという点です。ここを混同すると、「外部送信だけ止めたかったのに、回答まで全部止まった」という設計ミスが起きやすくなります。(Microsoft Learn)

たとえば、経理担当が「この顧客カード番号を前提に督促文を作って」と入力した場合、SIT ベースのプロンプト保護ならその場で応答自体を止められます。一方で、営業担当が社内の案件メモを踏まえて競合比較をしたい場面では、外部 Web 検索だけ止めて社内データからの回答を許可する設計も可能です。現場運用と両立しやすいのは、後者をうまく使い分けるパターンです。(Microsoft Learn)

Purview DLP の適用粒度はどこまで細かいか

入力文は Sensitive information types で判定する

Copilot のプロンプト保護は、Microsoft 365 Copilot and Copilot Chat のポリシー場所に対して、Content contains > Sensitive information types を条件に設定します。使えるのは Microsoft 提供の SIT だけでなく、独自に作成した custom SIT も含まれます。公式ドキュメントの例でも、クレジットカード番号、旅券番号、社会保障番号のような代表的な機密データが挙げられています。(Microsoft Learn)

実務で大事なのは、「全部の機密」を一気に止めようとしないことです。最初に止めるべきなのは、誤入力の被害が大きいものです。たとえば決済情報、銀行番号、国民 ID、パスポート番号のような規制色の強いものから始めると、ブロック理由がユーザーにも説明しやすく、運用が荒れにくくなります。(TECHCOMMUNITY.MICROSOFT.COM)

ラベル付きファイルやメールの制御は別ルールで考える

ファイルやメールに付いた感度ラベルで Copilot の利用を抑える場合は、Content contains > Sensitivity labels を使います。ここで注意したいのは、SIT 条件と感度ラベル条件は同じルールに同居できないことです。同一ポリシー内で別ルールに分けることはできますが、1ルールでまとめて処理しようとすると詰まります。(Microsoft Learn)

また、ラベルベースの制御は「その文書がまったく存在しない扱いになる」わけではありません。該当項目の内容は応答生成に使われませんが、引用元として表示される可能性は残ります。つまり「見えるが要約されない」という挙動があり得るため、ユーザーにはその違いを事前に説明しておく必要があります。(Microsoft Learn)

権限モデルと DLP は役割が違う

Copilot のすべてのプロンプトは、質問した本人のセキュリティ コンテキストで処理されます。つまり、共有設定や閲覧権限の整理は今まで通り最優先です。その上で Purview DLP は、「見えてよいデータ」を決める仕組みではなく、「その入力を処理させてよいか」「その文書を応答生成に使わせてよいか」を決める仕組みです。権限整理をせずに DLP だけで Copilot を安全化することはできません。(Microsoft Learn)

現場運用と両立しやすい設計パターン

運用シーンおすすめ設計理由
全社導入の初期段階決済情報・国民 ID・銀行番号などは Web 検索だけ抑止外部送信リスクを先に下げつつ、社内データを使う回答は維持しやすい
人事・経理・法務SIT ベースのプロンプト全面ブロック + 高機密ラベル文書の除外規制情報や個人情報は「入力自体を禁止」にしたほうが説明しやすい
経営企画・機密案件高機密ラベル文書の除外を優先し、必要なら custom SIT で案件固有パターンも追加社内機密は「見えていても Copilot に要約させない」設計が効く

おすすめは、全社一律で強制ブロックではなく、業務特性で二段階に分けることです。一般部門は Web グラウンディングのみ抑止、規制部門は入力自体を止める。この分け方なら、Copilot の利便性を残しつつ「うっかり入力」の事故確率を大きく下げやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)

さらに、Microsoft の Copilot セキュリティ ガイダンスでも、機微データは Purview DLP で制御しつつ、必要に応じて「Work IQ グラウンディングは許可、Web グラウンディングだけブロック」という考え方が示されています。これは、まさに「止めすぎない運用」を組むための設計思想です。(Microsoft Learn)

検証前に知っておきたい注意点

注意点現場で何が起きるか先にやるべき対策
アップロードしたファイルの中身はこの DLP では検査されないプロンプトに添付したファイル内容の機密判定はされないユーザー教育と感度ラベル運用を別で回す
ポリシー反映に最大4時間かかる「設定したのに止まらない」が起きる切り替え検証は即断せず時間差を見込む
Custom policy template でしか使えない既存の汎用 DLP ポリシーに横付けしにくいCopilot 専用ポリシーとして設計する
Copilot 用のポリシー場所を選ぶと他ロケーションは無効1つのポリシーでメールや Teams などをまとめにくいCopilot 用と他ロケーション用を分ける
Admin units 非対応組織単位での分離運用に制約が出るテナント運用設計を先に確認する
Word / Excel / PowerPoint では、プレビュー中の表示が分かりにくい場合がある利用者が「なぜ返答されないのか」を理解しにくいFAQ と問い合わせ導線を用意する

加えて、ラベルベースの除外には対応範囲があります。公式ドキュメントで明記されているのは、SharePoint Online と OneDrive for Business 上のファイル、そして 2025年1月1日以降に送信された Exchange メールです。予定表招待は対象外です。開いたファイルに対してラベル DLP が効いた場合、Word / Excel / PowerPoint のスキルが無効化される一方、ファイル内容を参照しない体験までは必ずしも止まりません。ここは検証で見落としやすいポイントです。(Microsoft Learn)

監査・運用改善まで含めて初めて機能する

Purview DLP は、作って終わりではありません。プロンプトや応答は統合監査ログに記録され、DSPM for AI の Activity Explorer で確認できます。さらに Microsoft は、Web 検索で実際に生成された検索語も監査・検索できるようにしており、Copilot が「何を外部検索に使ったか」まで追いやすくしています。事故調査やルール見直しに使えるため、導入初期こそ監査系の画面を先に整備しておくべきです。(Microsoft Learn)

法務や監査対応まで見据えるなら、eDiscovery の価値も大きいです。Copilot のプロンプトや応答はユーザーのメールボックスに保存され、Purview eDiscovery で検索・保全できます。つまり、DLP で防ぐだけでなく、万一の際に「誰が何を入力し、どんな応答が返ったか」を後から調べられる運用まで組めます。(Microsoft Learn)

権限分離も実務では重要です。Copilot 向け DLP を編集できる Data Security AI Admin は、AI 対話のプロンプトや応答そのものを読む権限を持ちません。一方、詳細な prompt / response を読むには Data Security AI Content Viewer という別ロールが用意されています。セキュリティ担当に設定権限だけを渡し、閲覧権限は監査担当だけに絞る、といった分離がしやすい設計です。(Microsoft Learn)

Copilot 導入可否の判断材料としてどう見るべきか

結論として、企業が最も不安に感じやすい「社員が Copilot のプロンプトに機密情報を貼ってしまう」問題に対して、Purview DLP はかなり具体的な答えを出せる段階に入っています。Microsoft はもともと、Copilot がユーザー権限内のデータだけを扱い、プロンプトや応答を学習に使わない設計を示していました。その上で、今回の DLP 拡張によって、入力そのものと外部 Web グラウンディングまで制御できるようになった意味は大きいです。Copilot 導入を保留していた組織でも、部門限定パイロットを前向きに検討しやすくなる更新です。(Microsoft Learn)

ただし、これを「万能の漏えい対策」と考えるのは危険です。アップロードファイルの中身はこの Copilot 向け DLP では評価されませんし、Microsoft 365 外の AI サイトへの貼り付けやファイル送信は別対策が必要です。Microsoft 自身も、第三者 AI サイトへの入力に対しては Endpoint DLP やネットワーク/ブラウザー層の保護を組み合わせる考え方を示しています。Copilot 向け DLP は、権限整理・感度ラベル・外部 AI 対策とセットで考えるべきです。(Microsoft Learn)

まずやるべきこと

  1. 最初に止める対象を絞ってください。決済情報、銀行番号、国民 ID、旅券番号のように、説明しやすく誤入力の被害が大きい SIT から始めるのが現実的です。
  2. Purview では Copilot 専用の Custom policy を作り、Sensitive information types を使うプロンプト保護ルールと、Sensitivity labels を使うコンテンツ除外ルールを分けて設計してください。(Microsoft Learn)
  3. 一般部門には Web 検索だけを止める設計、規制部門にはプロンプト全面ブロック、という二段階で試すと、止めすぎを避けやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
  4. 本番前に監査、Activity Explorer、DLP アラート、通知、シミュレーションを確認し、ポリシー反映に最大4時間かかる前提で検証計画を組んでください。Word / Excel / PowerPoint ではプレビュー中の表示が分かりにくいこともあるため、利用者向け FAQ も用意しておくと運用が安定します。(Microsoft Learn)
  5. 「この DLP は入力欄に打った文字を守る機能であり、添付ファイルの中身まで自動で検査するわけではない」と周知してください。Microsoft 365 外の AI サービス対策まで必要なら、Endpoint DLP やネットワーク/ブラウザー層の保護も併用すべきです。(Microsoft Learn)

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次