Microsoft Purview DSPM for AI / DLPの2026年4月更新で押さえるべきポイントは、AI利用の「見える化」だけでは不十分になり、DLPポリシー、感度ラベル、リスク調査、修復アクションを組み合わせて実際に止める・直す・監査する運用へ進むことです。
2026年4月23日にMicrosoft Tech Communityで公開された「From Oversharing to Enforcement」は、Microsoft Purviewを使ってAIデータセキュリティを実装するための実務ガイドです。対象読者は、Microsoft 365 Copilotや外部AIサービスの利用を管理するsecurity admins、identity teams、compliance teamsです。特に、Copilot導入後に「過剰共有されたファイルがAIから参照される」「ユーザーがプロンプトに機密情報を貼り付ける」「未承認AIサービスにデータが流れる」といったリスクをどう制御するかが焦点になります。Microsoftは同記事で、DSPMがMicrosoft 365、Azure、Fabric、サードパーティSaaSにまたがるデータリスクの可視化と制御を担うと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview DSPM for AI / DLPの最新動向: Microsoft Purview guide moves AI data security from oversharing to enforcementで何が変わったか
今回の更新を一言でまとめると、Microsoft Purview DSPM for AI / DLPは、AI利用状況を眺めるためのレポート機能から、AIに触れるデータを継続的に発見し、ポリシーで制御し、違反時に修復する運用基盤へ位置づけが強まったということです。
従来のデータ漏えい対策では、メール送信、ファイル共有、デバイスへのコピーなどを中心にDLPを設計していました。しかし生成AIでは、ユーザーが何気なく入力したプロンプトや、Copilotが参照できる過剰共有ファイルがリスクになります。Microsoftの公式ガイドでも、AIはまったく新しいリスクを作るというより、既存の「過剰共有」「誤送信」「未承認ツール利用」を高速かつ大規模に増幅すると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、管理者が見るべきポイントは「Copilotを許可するか禁止するか」ではありません。次のように、AI利用を前提にした制御へ切り替える必要があります。
| 従来の考え方 | 2026年4月更新で重視される考え方 |
|---|---|
| AI利用状況をレポートで確認する | リスクを検出したらDLPや修復アクションにつなげる |
| ユーザー教育で機密情報の入力を避けてもらう | プロンプト内の機密情報をポリシーで検出・制御する |
| SharePointやOneDriveの共有設定を個別に見直す | DSPMで過剰共有を評価し、優先度付きで修復する |
| セキュリティ部門だけで管理する | セキュリティ、ID、コンプライアンス、法務、業務部門で運用する |
| まず全面ブロックする | シミュレーション、監視、段階的な強制適用で調整する |
更新ポイントは「oversharing対策」から「enforcement」への移行
記事タイトルにある「oversharing to enforcement」は、今回の内容を理解するうえで重要です。oversharingは、ファイルやサイト、メールなどが必要以上に広い範囲へ共有されている状態を指します。
たとえば、次のような状態です。
- SharePoint上の人事資料が「社内全員」に共有されている
- 退職済みプロジェクトメンバーが機密フォルダーへアクセスできる
- 「リンクを知っている全員」が閲覧できる共有リンクが残っている
- 機密ラベルが付くべきファイルが未分類のままCopilotから参照できる
生成AI導入前であれば、過剰共有ファイルは「存在しているが読まれない」こともありました。しかしMicrosoft 365 CopilotのようなAIは、ユーザーの質問に応じて関連情報を探し、要約し、提示します。つまり、人が探さなかった情報をAIが見つけてしまう可能性があります。
今回のガイドでは、こうしたリスクに対して、Microsoft Purview DSPMでデータリスクを把握し、DLPや感度ラベル、Insider Risk Management、eDiscoveryなどを組み合わせて、予防・検知・調査・修復までつなげる流れが示されています。Microsoft Learnでも、DSPMはDLP、Insider Risk Management、感度ラベルによるInformation Protection、Data Security Investigationsの情報を統合し、データリスク、ポリシー適用範囲、姿勢の傾向を一元的に確認できると説明されています。(Microsoft Learn)
Microsoft Purview DSPMで統合される主な機能
Microsoft Purview DSPMは単独のレポート画面ではなく、複数のPurview機能を束ねてデータ保護の成果につなげる役割を持ちます。2026年4月時点で特に重要なのは、次の機能群です。
| 機能 | 主な役割 | AIデータセキュリティでの使いどころ |
|---|---|---|
| DSPM / DSPM for AI | データリスクの可視化、推奨アクション、姿勢管理 | Copilot、AIアプリ、エージェント利用の全体像を把握する |
| DLP | 機密情報の検出、ブロック、通知、監査 | プロンプト内の機密情報や、AIサイトへの送信を制御する |
| 感度ラベル | ファイルやメールの分類、保護 | Copilotが処理してよいデータと処理してはいけないデータを分ける |
| Insider Risk Management | 内部リスクの検出 | 不自然なAI利用、過剰な共有、持ち出し兆候を検出する |
| Activity Explorer / Audit | 操作ログとAIアクティビティの確認 | 誰がどのAIアプリでどのようなリスク行動をしたか調査する |
| eDiscovery / Data Lifecycle Management | 証跡保全、保持、調査 | AIプロンプトや応答をコンプライアンス要件に沿って管理する |
特に注目すべきなのは、DSPMの「Data security objectives」です。これは、個別機能の設定画面を渡り歩くのではなく、「Microsoft 365 CopilotとMicrosoft Copilotのやり取りでデータ露出を防ぐ」といった目的別のワークフローから必要な設定へ進める考え方です。Microsoft Learnでは、Data security objectivesがDLP、Information Protection、Insider Risk Management、eDiscoveryなどの関連機能をまとめ、特定のデータセキュリティ成果に集中できるようにすると説明されています。(Microsoft Learn)
DLP for Microsoft 365 Copilotでできること
Microsoft Purview DLPは、Microsoft 365 CopilotとCopilot Chatのやり取りを保護するうえで中心的な機能です。Microsoft Learnでは、DLPにより、プロンプトに機密情報タイプが含まれる場合にCopilotの処理や外部Web検索への利用を制限できると説明されています。(Microsoft Learn)
実務上は、次の2つを分けて考えると設計しやすくなります。
プロンプト内の機密情報を制御する
ユーザーがCopilotに入力するプロンプトに、クレジットカード番号、パスポート番号、社会保障番号、社内で定義したカスタム機密情報タイプなどが含まれる場合、DLPポリシーで処理を制限できます。
たとえば、次のような入力が対象になり得ます。
「この顧客リストを要約して。氏名、住所、カード番号は以下です」
このようなケースでは、ユーザー本人に悪意がなくても、機密情報がAI処理に渡されるリスクがあります。DLPを使えば、プロンプト内の機密情報タイプを条件にして、Copilotが応答を返すことや、その情報を内部・外部検索で使うことを制限できます。
注意点として、Microsoft Learnでは「Block sensitive information types in prompts」はプレビュー機能として案内されており、テナントへの展開状況を確認する必要があるとされています。導入時は、いきなり全社強制ではなく、対象部門や検出対象を絞って開始するのが現実的です。(Microsoft Learn)
感度ラベル付きファイルやメールの処理を制御する
もう一つの重要な制御は、感度ラベルが付いたファイルやメールをCopilotの応答生成に使わせないことです。Microsoft Learnでは、Microsoft 365 CopilotとCopilot Chatに対するDLPポリシーで、特定の感度ラベルが付いたファイルやメールを応答要約の処理対象から除外できると説明されています。(Microsoft Learn)
たとえば、次のような設計が考えられます。
| 感度ラベル | Copilotでの扱い | 想定例 |
|---|---|---|
| Public | 処理を許可 | 公開済み資料、Web掲載済み情報 |
| General | 原則許可 | 一般的な社内文書 |
| Confidential | 条件付きで制限 | 顧客情報、契約前資料、社内戦略 |
| Highly Confidential | 処理を制限 | M&A、人事評価、未公開財務情報、法務案件 |
ここで重要なのは、DLP for Copilotを有効にする前に、感度ラベルの運用がある程度整っている必要があることです。ファイルの大半が未ラベル、またはすべて「General」扱いでは、Copilotに何を処理させないか判断できません。
2026年4月更新で管理者が注目すべき実務ポイント
今回の公式ガイドは、単に新機能を紹介しているのではなく、AIデータセキュリティをどの順序で運用へ落とし込むかを示している点が実務的です。特に、security admins、identity teams、compliance teamsは、次の観点で整理すると対応しやすくなります。
security adminsはDLPを「検知」から「強制適用」へ進める
セキュリティ管理者は、まずDLPポリシーをシミュレーションモードやテストモードで開始し、どの程度の検出が出るかを確認します。その後、誤検知や業務影響を調整し、重要度の高いシナリオから強制適用へ移行します。
最初に強制適用しやすいのは、次のようなケースです。
- 個人番号、クレジットカード番号、パスポート番号など明確な機密情報
- 「Highly Confidential」ラベルが付いたファイルのCopilot処理
- 外部AIサイトへの機密情報貼り付け
- リスクが高いユーザーによるAIアプリへのデータ送信
反対に、事業部ごとの文脈が必要な営業資料、研究開発資料、コード断片などは、最初から厳格に止めると業務影響が大きくなります。検出ログを見ながら、ラベル、例外、通知文を調整することが重要です。
identity teamsは「誰がAIとデータにアクセスできるか」を見直す
AIデータセキュリティはDLPだけでは完結しません。Copilotは、基本的にユーザーがアクセス権を持つデータをもとに動作します。そのため、IDとアクセス管理の状態が悪いと、AIが過剰共有の影響を増幅します。
identity teamsが確認すべきポイントは次のとおりです。
| 確認項目 | 見直すべき内容 |
|---|---|
| グループ権限 | 部署異動や退職後もアクセス権が残っていないか |
| SharePointサイト権限 | 「全社」「全員」「外部ユーザー」に広がりすぎていないか |
| ゲストアクセス | 不要なゲストが機密サイトに残っていないか |
| 管理者ロール | PurviewやDLP設定を変更できる権限が過剰でないか |
| AI関連ロール | AIコンテンツ閲覧やポリシー編集の権限が最小限になっているか |
特に、Microsoft PurviewのAI関連コンテンツやプロンプト・応答の閲覧には慎重な権限設計が必要です。調査に必要な人だけが見られるようにし、監査ログと職務分離を前提に設計します。
compliance teamsは「証跡」と「説明可能性」を重視する
コンプライアンス部門にとって重要なのは、AI利用を禁止することではなく、規制や社内規程に対して説明できる状態を作ることです。
たとえば、監査や内部調査で次の質問に答えられる必要があります。
- AIアプリで機密情報が使われた形跡はあるか
- DLPポリシーはいつから、どの範囲に適用されているか
- ブロックされた操作と許可された操作の違いは何か
- 違反が検出された後、誰がどのように修復したか
- AIプロンプトや応答を保持・削除するポリシーはあるか
Microsoft Purviewでは、AIアプリとのやり取りに関する監査、Activity Explorer、eDiscovery、Data Lifecycle Managementなどを組み合わせて、AI利用の証跡管理を進められます。Microsoft Learnでも、サードパーティAIアプリとのやり取りについて、監査、データ分類、DLP、Insider Risk Management、Communication Compliance、eDiscovery、Data Lifecycle Managementなどの対応が整理されています。(Microsoft Learn)
まず実施すべき3つの初期対応
Microsoft Purview DSPM for AI / DLPをすべて一度に展開しようとすると、関係者調整や例外設計で止まりやすくなります。最初は、リスク低減効果が高く、業務影響を測定しやすい対応から始めるのが現実的です。
Microsoft 365 Copilotのプロンプト保護を有効化する
最初の候補は、Microsoft 365 CopilotとCopilot Chatに対するDLPポリシーです。特に、プロンプトに機密情報タイプが含まれる場合の制御は、AI利用時の「うっかり貼り付け」を防ぐ効果があります。
導入手順の考え方は次のとおりです。
| ステップ | 実施内容 | 判断基準 |
|---|---|---|
| 対象を決める | まずは情報システム、法務、人事、営業管理など高リスク部門を選ぶ | 機密情報を扱う頻度が高いか |
| 機密情報タイプを選ぶ | Microsoft標準のSITと、自社のカスタムSITを整理する | 誤検知が少なく、検出価値が高いものから始める |
| シミュレーションで開始 | ブロックせず、検出件数と内容を確認する | 業務影響と検出精度を評価する |
| 通知文を整備 | ユーザーに何がブロックされたか、次にどうすべきかを示す | ヘルプデスク問い合わせを減らせるか |
| 強制適用へ移行 | 重大リスクからブロックを有効化する | 例外申請フローが用意されているか |
DLPのポリシー更新は、Microsoft 365 CopilotとCopilot Chatの体験に反映されるまで最大数時間かかる場合があるため、検証時は即時反映を前提にしないことも大切です。Microsoft Learnでは、DLPポリシーの更新がCopilot体験に反映されるまで最大4時間かかる可能性があると説明されています。(Microsoft Learn)
Shadow AIの利用状況を把握する
次に取り組むべきなのは、未承認AIサービス、いわゆるShadow AIの把握です。Microsoft 365 Copilotだけを制御しても、ユーザーがブラウザーから外部AIサービスへ機密情報を貼り付けていれば、リスクは残ります。
Microsoft Purviewでは、DSPM for AIのレポートやActivity Explorerを使って、AIアプリ利用や機密情報の送信状況を確認できます。Microsoft Learnでは、AIサイトの訪問検出、Microsoft Edge内のAIプロンプトに共有された機密情報の検出などが案内されています。(Microsoft Learn)
最初の調査では、次のような切り口で見ると判断しやすくなります。
- 利用されている外部AIアプリの種類
- 利用頻度が高い部門やユーザー
- 機密情報を含むプロンプトの有無
- ブラウザー、ネットワーク、デバイスのどこで検出されているか
- ブロックすべきアプリと、業務上許可すべきアプリの違い
ここで避けたい失敗は、利用実態を見ずに一律ブロックすることです。業務でAIを使う必要がある部門に安全な代替手段を示さないまま禁止すると、別の経路での利用が増える可能性があります。まず可視化し、リスクの高い用途から制御するのが現実的です。
DSPMのData security objectivesを運用の入口にする
3つ目は、DSPMのData security objectivesを運用の入口にすることです。個別にDLP、感度ラベル、Insider Risk Management、eDiscoveryを設定しようとすると、担当者が分かれ、どの設定がどのリスクを下げているのか見えにくくなります。
Data security objectivesを使うと、「CopilotやAIアプリでのデータ露出を防ぐ」という目的から、必要な推奨アクションやメトリックへ進めます。Microsoft Learnでは、DSPMのObjectivesが、リスクに対応するための修復計画、ワンクリックポリシー、推奨アクションを含むと説明されています。(Microsoft Learn)
運用に落とし込む場合は、次のようなKPIを設定すると効果が測定しやすくなります。
| KPI | 見るべき理由 |
|---|---|
| 感度ラベルが付いたファイルの割合 | ラベルベースのAI制御が機能する前提になる |
| DLPポリシーの検出件数 | どの機密情報がAI利用で問題になっているか分かる |
| ブロック件数とオーバーライド件数 | ポリシーが厳しすぎるか、妥当かを判断できる |
| 過剰共有の修復件数 | Copilot導入前後のデータ露出低減を示せる |
| Shadow AIの利用アプリ数 | 未承認AI利用が減っているか確認できる |
| 調査から修復までの時間 | インシデント対応の成熟度を測れる |
DLPポリシー設計で失敗しやすいポイント
Microsoft Purview DSPM for AI / DLPの導入でよくある失敗は、機能不足ではなく設計不足です。特に、次の点は事前に確認しておく必要があります。
感度ラベルが整っていないままCopilot制御を始める
感度ラベルを使ったCopilot制御は有効ですが、ラベル運用が未成熟だと効果が出ません。重要ファイルが未ラベルのままでは制御対象にならず、逆に一般資料に過剰なラベルが付いていると業務に支障が出ます。
最初は、すべてのラベル体系を完璧に作るより、次のように段階化するのがおすすめです。
- 最重要データだけを「Highly Confidential」として明確にする
- 人事、財務、法務、顧客情報など高リスク領域から自動ラベルを検討する
- 既存ファイルをスキャンし、未ラベルの重要ファイルを棚卸しする
- ラベル変更の申請・承認フローを決める
プロンプトだけを見て、ファイル共有を見落とす
AIデータリスクというと、ユーザーがプロンプトに何を入力するかに注目しがちです。しかし、Copilotが参照できるファイルのアクセス権も同じくらい重要です。
たとえば、ユーザーが「来期の人員計画を要約して」と聞いたとき、過剰共有された人事ファイルにアクセス権があれば、AIが意図せず情報を拾う可能性があります。プロンプト制御と同時に、SharePoint、OneDrive、Teamsの共有状態を見直す必要があります。
シミュレーションのまま放置する
DLPのシミュレーションモードは、業務影響を把握するために有効です。しかし、検出結果を見ているだけではリスクは減りません。
シミュレーション開始時に、あらかじめ次の期限を決めておきます。
| 期間 | 実施内容 |
|---|---|
| 1週目 | 対象部門と対象SITを限定して検出状況を確認 |
| 2〜3週目 | 誤検知、例外、通知文、ヘルプデスク手順を調整 |
| 4週目 | 高リスク条件から強制適用へ移行 |
| 以後毎月 | 検出傾向、例外申請、業務影響をレビュー |
「安全のためにシミュレーションする」は正しい判断ですが、「判断を先送りするためにシミュレーションを続ける」は避けるべきです。
ユーザー通知を軽視する
DLPでプロンプトやAIサイトへの送信をブロックした場合、ユーザーには「なぜ止められたのか」「どうすればよいのか」が分かる必要があります。通知文が抽象的だと、ヘルプデスクへの問い合わせが増え、現場からセキュリティ施策への反発が起きます。
通知文には、次の要素を入れると実用的です。
- 機密情報が含まれる可能性があるため処理できないこと
- 入力内容から機密情報を削除して再試行できること
- 業務上必要な場合の申請先
- 社内で利用できる承認済みAIツール
- 関連する社内ポリシーへのリンク
フェーズ別の導入ロードマップ
Microsoft Purview DSPM for AI / DLPの導入は、短期・中期・継続運用に分けると進めやすくなります。Microsoft公式ガイドでも、早期の安全策、広範な強制適用、成熟したガバナンスという段階的な考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
| フェーズ | 目的 | 主な作業 | 成功の目安 |
|---|---|---|---|
| 初期対応 | 可視化と最小限の保護 | Copilot向けDLPをシミュレーションで開始、Shadow AIを把握、過剰共有を評価 | 主要なAIリスクがレポートで見える |
| 強制適用 | 検出結果をポリシーへ反映 | 高リスクSITをブロック、感度ラベル付きデータの処理制御、外部AIアプリ送信制御 | 重大なデータ送信や処理が実際に止まる |
| 継続運用 | 改善と監査対応 | KPIレビュー、例外申請、調査手順、eDiscovery、保持ポリシーを整備 | 監査時に根拠と改善履歴を説明できる |
導入の優先順位は、組織のAI利用状況によって変わります。すでにMicrosoft 365 Copilotを全社展開している場合は、Copilot向けDLPと過剰共有対策を優先します。外部AIサービスの利用が多い場合は、Shadow AIの可視化とブラウザー／ネットワーク経由のDLPを先に整備します。
グローバル組織で考慮すべき点
今回のMicrosoft Purview guideは、グローバル読者向けにも扱いやすい内容です。ただし、多国籍企業や複数リージョンでMicrosoft 365を使う組織では、次の点を追加で考慮する必要があります。
国・地域ごとの機密情報タイプを分ける
個人情報、金融情報、医療情報、政府IDなどは国・地域ごとに形式が異なります。DLPポリシーでは、Microsoft標準の機密情報タイプに加えて、自社の業務に合わせたカスタムSITを検討します。
たとえば、グローバル企業では次のような分類が必要です。
- 日本: マイナンバー、銀行口座、健康保険関連情報
- 米国: Social Security Number、医療情報、州ごとの個人情報
- EU: GDPR対象の個人データ、顧客住所、金融識別子
- アジア各国: 国民ID、税務番号、携帯電話番号、住所情報
ただし、検出精度を高めようとして条件を増やしすぎると誤検知が増えます。最初は漏えい時の影響が大きいものから始め、ログを見ながら調整します。
部門ごとの業務例外を設計する
研究開発、法務、人事、営業、カスタマーサポートでは、AIの使い方が大きく異なります。全社一律のDLPでは、ある部門では厳しすぎ、別の部門では弱すぎることがあります。
実務では、次のように分けると調整しやすくなります。
| 部門 | 主なAI利用 | 制御方針 |
|---|---|---|
| 人事 | 評価、異動、採用関連文書の要約 | 高機密ラベルのCopilot処理を厳格に制限 |
| 法務 | 契約書レビュー、訴訟資料調査 | eDiscoveryと保持ポリシーを重視 |
| 営業 | 顧客資料、提案書、商談メモ | 顧客情報を含むプロンプトを監視・制御 |
| 開発 | コード生成、仕様書要約 | ソースコードや未公開仕様の外部AI送信を制御 |
| サポート | 問い合わせ要約、ナレッジ検索 | 個人情報の貼り付けをブロックし、匿名化を促す |
監査ログの閲覧権限を絞る
AIプロンプトや応答には、ユーザーが入力した機密情報が含まれる可能性があります。調査担当者が必要以上に内容を閲覧できる状態は、二次的な情報漏えいリスクになります。
そのため、ログやAIコンテンツを閲覧できるロールは最小限にし、閲覧目的、承認、記録を明確にします。セキュリティ部門、コンプライアンス部門、法務部門で役割を分けることが重要です。
導入前チェックリスト
Microsoft Purview DSPM for AI / DLPを本格導入する前に、次の項目を確認しておくと、設定後の手戻りを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| Copilot利用範囲 | Microsoft 365 Copilot、Copilot Chat、Officeアプリ内Copilotの利用者を把握しているか |
| 外部AI利用 | ChatGPT、Gemini、DeepSeekなどの利用実態を把握できるか |
| 感度ラベル | 重要データを分類できるラベル体系があるか |
| DLP対象 | まず制御すべきSITやラベルが決まっているか |
| 権限管理 | SharePoint、OneDrive、Teamsの過剰共有を評価できるか |
| 管理者ロール | Purview、DLP、AI関連ロールの職務分離ができているか |
| 通知・教育 | DLPでブロックされたユーザーへの説明文があるか |
| 例外申請 | 正当な業務が止まった場合のレビュー手順があるか |
| 監査・保持 | AIプロンプトや応答をどの範囲で記録・保持するか決まっているか |
| 運用KPI | 検出件数、修復件数、ラベル適用率などを定期レビューできるか |
2026年4月更新を受けて今すぐ取るべき行動
Microsoft Purview DSPM for AI / DLPの2026年4月更新ポイントは、AIデータセキュリティを「利用状況の可視化」で止めず、DLP、感度ラベル、過剰共有修復、監査、継続改善までつなげることです。
まず実施すべき行動は、次の3つです。
1つ目は、Microsoft 365 CopilotとCopilot Chatに対するDLPポリシーをシミュレーションで開始することです。プロンプト内の機密情報タイプと、感度ラベル付きファイル・メールの処理制御を分けて設計します。
2つ目は、DSPMでAIアプリとエージェントの利用状況を可視化することです。承認済みCopilotだけでなく、外部AIサービスへの機密情報送信も確認します。
3つ目は、検出結果を期限付きで強制適用へ進めることです。シミュレーション結果を見て終わりにせず、重大リスクからDLPブロック、共有リンク削除、権限見直し、感度ラベル適用へつなげます。
AIの利用を止めるだけでは、生産性向上の機会を失います。一方で、見える化だけではデータ漏えいリスクは下がりません。Microsoft Purview DSPM for AI / DLPを活用するなら、最初のゴールは「AIを安全に使える状態を、ポリシーと証跡で説明できること」です。今回の2026年4月更新は、そのための実務的な道筋を示したものと捉えると、導入計画に落とし込みやすくなります。
コメント