Microsoft が 2026年4月7日に案内した Copilot の最新セキュリティ強化と、Microsoft Learn の Purview DLP ガイダンスを合わせて読むと、今回の本質は明確です。Microsoft Purview データ損失防止（DLP）で、Microsoft 365 Copilot と Copilot Chat を「使わせるか・止めるか」で一括管理する時代から、「どのプロンプトを止めるか」「どのファイルやメールを要約に使わせないか」「Web検索に何を渡さないか」を分けて管理する段階に入った、ということです。特に管理者は、既定ポリシーが初期状態ではシミュレーションである点と、機密情報の種類（SIT）条件と秘密度ラベル条件を同じルールに混在できない点を先に押さえる必要があります。 (TECHCOMMUNITY.MICROSOFT.COM)
一方で、資料の粒度には少し差があります。4月7日の Microsoft 365 Copilot Blog では、プロンプト保護を「Generally available」と案内している一方、詳細な Learn 記事は 2026年2月19日時点で、SIT によるプロンプト制御を「preview」と記載し、「自テナントでロールアウト状況を確認してほしい」としています。実務では、この差を“資料の食い違い”と見るより、テナント側で機能の見え方を必ず確認するのが安全です。 (TECHCOMMUNITY.MICROSOFT.COM)
この記事では、今回の Purview DLP ガイダンス更新が Microsoft 365 Copilot と Copilot Chat の管理に何を意味するのかを、設定の判断基準、見落としやすい制約、今すぐやるべき見直し手順まで含めて整理します。
今回の更新をどう理解すべきか
実務で整理しやすい見方は、Purview DLP を次の3層で考えることです。4月7日の最新案内と詳細ガイダンスをつなぐと、Copilot 管理はかなり細かく設計できるようになっています。 (TECHCOMMUNITY.MICROSOFT.COM)
| 制御レイヤー | 何を制御するか | 実際に起きること | 向いている場面 | 根拠 |
|---|---|---|---|---|
| プロンプト保護 | ユーザーが入力するテキスト内の SIT | Copilot が応答せず、機密データを内部・外部の検索にも使わない | 個人番号、口座番号、クレジットカード番号、API キー、機密プロジェクト名などを入力させたくないとき | (Microsoft Learn) |
| 参照データ保護 | 秘密度ラベル付きファイル・メール | 応答の要約には使わない。ただし項目自体は引用に出ることがある | 「極秘」「個人情報」ラベルの文書を Copilot の要約材料から外したいとき | (Microsoft Learn) |
| Web検索保護 | Web検索に渡すクエリ | 機密情報を Web 検索に使わせず、内部データ中心の回答を許可できる粒度が追加 | 外部 Web への検索語送信は抑えつつ、社内データでの回答は続けたいとき | (TECHCOMMUNITY.MICROSOFT.COM) |
ここで重要なのは、「Copilot 全面禁止」しか選べないわけではないことです。入力そのものを止める、参照データだけ外す、Web検索だけ絞る、という形で guardrail を分けられるため、業務を止めすぎずにリスクを下げやすくなりました。特に Microsoft 365 Copilot を本格展開している組織では、この粒度の差が運用しやすさに直結します。 (TECHCOMMUNITY.MICROSOFT.COM)
Purview DLP の中核は「プロンプト保護」と「参照データ保護」
プロンプト内の機密情報をブロックする
詳細ガイダンスでは、Microsoft 365 Copilot と Copilot Chat 向けの DLP で、Content contains > Sensitive information types を使うと、プロンプト本文に含まれる機密情報の種類を検出し、Copilot の応答自体を止められます。この制御は Microsoft 365 Copilot、Copilot Chat、Word・Excel・PowerPoint 内の Copilot に加え、事前構築済みエージェントにも広がります。Microsoft 提供の SIT だけでなく、組織独自のカスタム SIT も使えます。 (Microsoft Learn)
管理者目線で特に実用的なのは、「何を機密とみなすか」を細かく決められることです。たとえば人事部門なら個人番号や口座番号、開発部門なら Azure の秘密情報や特定のプロジェクトコード、営業部門なら顧客識別子など、部門ごとに“入力させたくない情報”を SIT で具体化する設計ができます。これは、単に Copilot の利用可否を切るより現実的です。 (Microsoft Learn)
さらに見逃せないのが、Microsoft が用意した既定 DLP ポリシーです。この既定ポリシーはユーザープロンプト内の SIT を検出する目的で用意されており、初期状態ではシミュレーションモードです。つまり、最初からブロックしてくれるわけではなく、イベント記録が中心です。実際に止めたいなら、ポリシー状態を強制モードに切り替える必要があります。 (Microsoft Learn)
しかも、既定ポリシーは最初から全テナントのユーザーとグループを対象にし、かなり広い SIT セットを持っています。日本語圏で関係が深い Japan Bank Account Number、Japan Passport Number、Japanese My Number Personal が含まれるだけでなく、Azure SAS や Azure Storage Account Key も初期対象です。つまり、個人情報対策だけでなく、クラウド秘密情報対策としても効く反面、業種や部署によっては誤検知や不要検知の原因になり得ます。不要な SIT を外して精度と運用負荷を調整する視点が必要です。 (Microsoft Learn)
秘密度ラベル付きファイル・メールを要約に使わせない
もう1つの中核が、Content contains > Sensitivity labels を使う秘密度ラベルベースの制御です。これは一般提供済みで、秘密度ラベルが付いたファイルやメールを Copilot の応答要約に使わせないための機能です。ここで大事なのは、項目そのものが完全に見えなくなるわけではない点です。文書やメールは引用欄に現れることがありますが、その内容自体は応答生成に使われません。 (Microsoft Learn)
この違いは運用上とても重要です。たとえば「取締役会資料」「M&A関連」「個人情報」などを Highly Confidential や Personal の秘密度ラベルで管理しているなら、Copilot 利用は認めつつ、そうした文書だけ要約対象から除外できます。逆に、「引用にファイル名すら出したくない」という要件があるなら、DLP だけでなく権限設計や保管場所の見直しも必要です。 (Microsoft Learn)
対応範囲にも制約があります。秘密度ラベルベースの制御で対象になるのは、SharePoint Online と OneDrive for Business に保存されたファイル、そして 2025年1月1日以降に送信されたメールです。予定表の招待は未対応です。また、秘密度ラベル付きで処理禁止にしたファイルを Word、Excel、PowerPoint で開いている場合、対象アプリ内の Copilot スキルは無効化されます。 (Microsoft Learn)
管理者が誤解しやすいポイント
- SIT 条件と秘密度ラベル条件は、同じルールには入れられません。 同じポリシー内に別ルールとして置くことはできますが、1ルールにまとめる設計はできません。Copilot 向け DLP を1本の“大きなルール”で済ませようとすると、ここで詰まりやすいです。 (Microsoft Learn)
- プロンプトにアップロードしたファイルの中身は、Copilot 向け DLP では検査されません。 検査対象は、あくまでユーザーが入力したテキストです。ファイル添付まで見てくれると思い込むと、盲点になります。 (Microsoft Learn)
- Copilot 向けポリシーの場所は Custom policy template でしか使えません。 さらに、その場所を選ぶと同一ポリシー内の他の場所は無効になります。Exchange や Teams や Endpoint と1つのポリシーにまとめる設計はできません。 (Microsoft Learn)
- 反映は即時ではありません。 Microsoft は、DLP ポリシー更新が Microsoft 365 Copilot と Copilot Chat の体験に反映されるまで最大4時間かかると案内しています。テスト直後に結果が出なくても、設定ミスと決めつけないほうが安全です。 (Microsoft Learn)
- 管理の委任はできても、Admin units には未対応です。 すでに管理単位ベースで運用している組織は、この場所だけ別運用になる前提で考えたほうがよいです。 (Microsoft Learn)
- アプリ側の表示が親切とは限りません。 Learn 記事では、Word・Excel・PowerPoint ではプレビュー中、ポリシーでブロックされたことがユーザーに分かりにくい場合があるとしています。問い合わせ削減のためには、事前の社内周知が有効です。 (Microsoft Learn)
DLP だけでは Copilot の過剰共有は止め切れない
Copilot は、ユーザーが閲覧権限を持つデータだけを表示する設計です。裏を返すと、アクセス権が広すぎる状態そのものは DLP では直りません。権限が広すぎれば、Copilot はその広すぎる範囲から答えを作れてしまいます。Microsoft も、過剰共有は Copilot 特有の問題ではなく、共有範囲が広すぎることや保護が持続しないことに起因すると説明しています。 (Microsoft Learn)
4月7日の Microsoft の案内でも、Secure and Govern Microsoft 365 Copilot の更新ポイントとして、Remediate oversharing、Implement reliable guardrails、Meet AI-related regulatory obligations の3本柱が示されました。つまり、今回の Purview DLP ガイダンス更新は「Copilot への入力制御が増えた」という話だけではなく、過剰共有の是正とセットで運用するべきというメッセージでもあります。 (TECHCOMMUNITY.MICROSOFT.COM)
実務では、Purview ポータルの Microsoft 365 Copilot ビューや DSPM for AI を使って、過剰共有リスクの把握、データ保護、アクティビティ確認を継続するのが現実的です。Learn の推奨でも、Microsoft 365 Copilot に切り替えたビューから、機密データの過剰共有評価、データ保護、アクティビティ検出を進める流れが示されています。 (Microsoft Learn)
Microsoft 365 Copilot 向け DLP とエンドポイント DLP は別物
ここも混同しやすいポイントです。Microsoft 365 Copilot と Copilot Chat の対話制御には、専用の「Microsoft 365 Copilot and Copilot Chat」ポリシー場所を使います。一方で、ブラウザー経由で ChatGPT などのサードパーティ生成 AI に機密情報を貼り付けさせない制御は、Windows デバイスを Purview にオンボードしたうえでの Endpoint DLP が中心です。 (Microsoft Learn)
さらに、Microsoft 365 Copilot Chat が Endpoint DLP 側でサポートするのは、機密コンテンツの貼り付けブロックと、指定した秘密度ラベルに基づくファイルブロックの2つに限られます。つまり、「Copilot のプロンプト制御」と「ブラウザー上の AI サイトへの持ち出し制御」は、同じ DLP でも役割が違います。ここを混ぜると、設計も説明も分かりにくくなります。 (Microsoft Learn)
今すぐやるべき見直し手順
権限を Global Admin 前提にしない
Copilot 向け DLP の作成・編集には、Entra AI Admin、Purview Data Security AI Admin、Purview Compliance Administrator など複数のロールが使えます。Microsoft も最小権限を推奨しており、Global Admin の人数は最小化すべきだと案内しています。しかも Purview Data Security AI Admin は、Copilot 向け DLP 編集や DSPM for AI の閲覧はできても、AI 対話のプロンプトと応答本文の閲覧権限は持ちません。ポリシー管理担当と会話内容の閲覧権限を分けたい組織では、まずここから設計すると運用しやすくなります。 (Microsoft Learn)
既定ポリシーの状態と対象範囲を確認する
Purview の Data loss prevention > Policies で、既定 DLP ポリシーの状態を確認してください。初期状態はシミュレーションなので、作っただけでブロックが有効になっているとは限りません。また、初期スコープは全テナント対象になりやすいため、いきなり全社適用せず、まずは部門やグループで絞ってテストするほうが失敗しにくいです。Microsoft も、不要な SIT を外して誤検知やパフォーマンス影響を減らすことを勧めています。 (Microsoft Learn)
「入力を止めるルール」と「参照を外すルール」を分ける
Copilot 向け DLP では、SIT 条件と秘密度ラベル条件を同じルールに入れられません。したがって、設計上は少なくとも次の2本に分けるのが基本です。
1つ目は、My Number、口座番号、Azure キーなどを入力させないルール。
2つ目は、Highly Confidential や Personal などを要約材料に使わせないルールです。
この分け方にしておくと、誤検知調整や例外設定、通知先の切り分けがやりやすくなります。 (Microsoft Learn)
秘密度ラベルと保管場所の前提を整える
秘密度ラベルベースの保護を効かせたいなら、先にラベル運用が整っていなければ意味がありません。対象文書が SharePoint Online や OneDrive for Business にあり、適切な秘密度ラベルが付いていて、対象メールが対応期間に入っていることが前提です。逆に、ファイルが別保管先にある、予定表招待が中心、古いメールも含めて守りたい、といったケースでは、Copilot 向け DLP だけで要件を満たせない可能性があります。 (Microsoft Learn)
添付ファイルの盲点をユーザーに周知する
プロンプトに直接アップロードしたファイルの中身は、Copilot 向け DLP では評価されません。ここは管理者だけ知っていても不十分で、利用者へのガイドにも落とし込むべきです。たとえば「機密ファイルを添付して分析させる前提で安心しない」「本当に保護したい文書は秘密度ラベルと権限で守る」「外部 AI サイト対策は Endpoint DLP で別に考える」といった説明が有効です。 (Microsoft Learn)
監視はレポートとアクティビティで回す
Purview では Microsoft 365 Copilot ビュー、レポート、アクティビティ エクスプローラーで継続監視できます。Microsoft は、Microsoft 365 Copilot ビューのレポート表示には少なくとも1日待つよう案内しており、ポリシー変更の反映には最大4時間かかるとしています。つまり、「設定変更 → 数分で断定」ではなく、少し時間を置いて検証する運用が必要です。 (Microsoft Learn)
まとめ
今回の Microsoft Purview DLP ガイダンス更新が意味するのは、Microsoft 365 Copilot と Copilot Chat を、プロンプト入力・参照データ・Web検索の単位で分けて守る運用へ進め、しかもその運用を過剰共有対策とセットで考えるべき、ということです。SIT によるプロンプト制御、秘密度ラベルによる要約除外、既定ポリシーのシミュレーション状態、アップロードファイルの非検査、SharePoint / OneDrive 前提といった細かい条件を理解して初めて、Purview DLP は実用レベルになります。 (TECHCOMMUNITY.MICROSOFT.COM)
最初の一歩としては、Purview ポータルで既定ポリシーを開き、ポリシーモード、対象ユーザー、含まれる SIT、通知先、そして秘密度ラベル運用の前提を確認するのが最短です。そこまで確認できれば、今回の更新を「ニュース」で終わらせず、実際の Copilot ガバナンス改善につなげられます。 (Microsoft Learn)
コメント