Microsoft Purview DSPM for AI の更新ポイントで最初に押さえるべきことは、対象ドキュメントが Data Security Posture Management for AI の「classic」版に関する導入時の考慮事項として位置づけられている点です。現在の Microsoft Purview では、AI アプリやエージェントまで対象を広げた新しい Data Security Posture Management が案内されており、classic 版には今後の改善が追加されない前提で確認する必要があります。(Microsoft Learn)
そのため、管理者が取るべき行動は「急いで全設定を変更する」ことではありません。まずは、監査ログ、DLP、端末オンボーディング、Edge 構成、ブラウザー拡張、従量課金、既存ポリシーのスコープを棚卸しし、classic 版で使っている設定を新しい DSPM へどう引き継ぐかを整理することが重要です。移行期限が公式ドキュメント内で明示されていない場合でも、新規導入や設計変更は新しい DSPM を前提に進めるのが安全です。
Microsoft Purview DSPM for AI とは何か
Microsoft Purview DSPM for AI は、生成 AI の利用に伴うデータリスクを可視化し、機密情報の持ち出しや過剰共有、危険な AI 利用を検出・制御するための機能群です。
対象は Microsoft 365 Copilot だけではありません。Microsoft Copilot experiences、Fabric、Security Copilot、Edge 上の AI アプリ、サードパーティの生成 AI サイト、Entra 登録済み AI アプリなど、組織内で使われる複数の AI 利用経路が関係します。公式ドキュメントでは、Microsoft 365 Copilot やエージェントの監視には Purview 監査の有効化、Copilot ライセンス、Fabric や Security Copilot の場合は追加の前提条件が必要であることが示されています。(Microsoft Learn)
従来の DLP は「メールやファイル転送で機密情報が出ていないか」を見るイメージが強いですが、DSPM for AI では プロンプト、応答、AI サイト訪問、DLP ルール一致、機密情報タイプの検出など、AI 利用に特化したイベントを Activity explorer で確認できます。(Microsoft Learn)
今回の更新で確認すべき最大のポイント
今回の公式情報で特に重要なのは、DSPM for AI の考慮事項ページが classic 版として整理されている点です。
Microsoft Learn では、classic 版は新しい Data Security Posture Management に置き換えられており、新機能や拡張は新しいバージョンに追加される流れで案内されています。新しい DSPM は、従来のデータと AI アプリ・エージェントの両方を対象に、Microsoft 365、Azure、Fabric、統合されたサードパーティ SaaS などを横断してリスクを発見・保護・調査する位置づけです。(Microsoft Learn)
管理者にとっての実務上の意味は、次の通りです。
| 確認項目 | 実務上の意味 |
|---|---|
| classic 版の扱い | 既存機能は参照できるが、新規設計の中心にしない |
| 新しい DSPM | 今後の拡張、AI observability、データセキュリティ目標の中心になる |
| 既存ポリシー | すぐ削除せず、作成元・対象ユーザー・モードを確認する |
| 移行期限 | 公式ページで明示されていない場合は、社内計画として段階移行を設計する |
| 管理者対応 | 監査、DLP、端末、Edge、課金、権限を先に確認する |
特に注意したいのは、「classic と表示されたから不要」と判断して設定を止めてしまうことです。既存の DLP ポリシー、Insider Risk Management ポリシー、Communication Compliance、Collection policy は、AI 利用の監視や証跡管理に関係している可能性があります。削除や変更の前に、どの推奨事項から作成されたポリシーなのかを確認してください。
影響範囲：どの AI 利用が対象になるのか
Microsoft Purview DSPM for AI の影響範囲は、AI アプリを「Microsoft 製かどうか」だけで切り分けると見落としが発生します。実務では、AI がどこで使われ、どのデータに触れ、どの経路で送信されるかで整理する必要があります。
| 対象領域 | 主な確認ポイント | 管理者が見るべき設定 |
|---|---|---|
| Microsoft 365 Copilot とエージェント | 監査ログと Copilot ライセンスが前提 | Purview Audit、対象ユーザーのライセンス |
| Copilot in Fabric / Security Copilot | 必要な API と collection policy が関係 | Purview data governance、collection policy |
| Edge 上の AI アプリ | Edge 構成ポリシーが必要 | Edge for Business、DLP ポリシー |
| サードパーティ生成 AI サイト | 端末オンボーディングとブラウザー拡張が重要 | Endpoint DLP、Purview browser extension |
| Chrome 利用者 | Windows で Endpoint DLP を使う場合、拡張機能が必要になるケースがある | Chrome 拡張、デバイス管理 |
| Entra 登録済み AI アプリ | Purview SDK との統合が前提 | Entra app、Purview SDK |
| Microsoft 365 Copilot 以外の AI アプリ | 従量課金が必要になる場合がある | Azure サブスクリプション、PAYG 設定 |
公式ドキュメントでは、Microsoft 365 Copilot と Microsoft Facilitator 以外の AI アプリについて、構成によっては pay-as-you-go billing の設定が必要になることが示されています。従量課金は「ライセンスだけで完結する」と思い込むと、検証段階でデータが出ない、または本番展開後に想定外の請求が発生する原因になります。(Microsoft Learn)
管理者が最初に確認すべき前提条件
DSPM for AI を導入または見直すときは、いきなりポリシーを作るのではなく、前提条件を順番に確認するのが近道です。
権限を確認する
DSPM for AI を管理するには、Microsoft Entra Compliance Administrator、Microsoft Entra Global Administrator、Microsoft Purview Compliance Administrator role group などの権限が関係します。一方で、Microsoft は Global Administrator の利用を最小限にすることを推奨しており、閲覧だけでよい担当者には Security Reader や Data Security AI Viewer などの権限を検討するのが現実的です。(Microsoft Learn)
実務では、次のように分けると運用しやすくなります。
| 役割 | 推奨される担当 |
|---|---|
| 初期構成・ポリシー作成 | セキュリティ管理者、コンプライアンス管理者 |
| AI 利用状況の確認 | セキュリティ運用、SOC、リスク管理部門 |
| 監査・証跡確認 | 法務、監査、コンプライアンス部門 |
| DLP 例外判断 | 情報システム、データオーナー、業務部門責任者 |
Global Administrator で日常運用するのは避け、必要な作業ごとに最小権限を割り当てることが重要です。
監査ログを確認する
Microsoft 365 Copilot や Copilot Chat の操作を追跡するには、Microsoft Purview Audit が有効であることが前提になります。監査は既定で有効になっていることが多いものの、過去に無効化されていたり、対象ユーザーのライセンスや保持期間が期待と異なったりすることがあります。
確認すべき項目は次の通りです。
| 確認項目 | 見落とした場合の問題 |
|---|---|
| Purview Audit が有効か | Copilot 連携イベントが見えない |
| 対象ユーザーに必要なライセンスがあるか | 一部ユーザーだけイベントが欠落する |
| 監査ログ保持期間 | 調査時に必要な証跡が残らない |
| Activity explorer の表示権限 | 担当者がイベントを確認できない |
「DSPM に画面があるのにデータが出ない」という相談では、機能そのものではなく監査・権限・ライセンスの前提不足が原因になりがちです。
Edge、Chrome、端末オンボーディングを確認する
サードパーティの生成 AI サイトを監視・制御する場合、Microsoft 365 Copilot だけを見ている構成とは前提が変わります。公式ドキュメントでは、第三者の生成 AI サイトに共有された機密情報を可視化したり、Endpoint DLP で警告・ブロックしたりするには、デバイスの Purview へのオンボーディングが必要とされています。また、Windows ユーザーで AI サイト訪問を検出する場合や Chrome で Endpoint DLP を使う場合、Microsoft Purview browser extension が関係します。(Microsoft Learn)
実務では、ブラウザー別に次のように確認してください。
| 利用ブラウザー | 確認すべきこと |
|---|---|
| Microsoft Edge | Edge 構成ポリシー、DLP ポリシー、Edge for Business の管理状態 |
| Google Chrome | Purview browser extension の展開、端末オンボーディング |
| Firefox | 対応範囲と DLP 動作の確認 |
| 未管理ブラウザー | ブロック対象や例外ルールの整理 |
特に、BYOD や海外拠点では端末管理の前提が本社と異なることがあります。全社展開前に、対象国・対象デバイス・対象ブラウザーを棚卸ししてください。
設定変更で確認すべきポリシー
DSPM for AI では、推奨事項から作成できる one-click policy や、既定ポリシーが複数あります。これらは「全部オンにすれば安全」というものではありません。対象ユーザー、対象ブラウザー、監査モード、テストモード、ブロック動作を確認してから展開する必要があります。
データ発見・監査系のポリシー
データ発見系のポリシーは、AI 利用状況の把握に役立ちます。たとえば、AI サイトに貼り付け・アップロードされた機密情報を検出する DLP ポリシー、AI サイト訪問を検出する Insider Risk Management ポリシー、AI アプリでの危険なやり取りを検出するポリシーなどがあります。
公式ドキュメントでは、AI サイトに追加された機密情報を検出する DLP ポリシーが audit mode のみで組織全体を対象にすること、Edge 上の AI プロンプト内の機密情報検出ではコンテンツをキャプチャしない構成があることも示されています。(Microsoft Learn)
管理者は次の観点で確認してください。
| 確認項目 | 判断基準 |
|---|---|
| audit mode か test mode か | まず監査で影響を把握し、その後ブロックを検討する |
| 対象ユーザーが全社か | 検証段階では特定部門・特定グループに絞る |
| 機密情報タイプ | 日本の個人番号、クレジットカード、顧客番号など業務に合わせる |
| アラートの運用担当 | SOC、情シス、法務のどこが一次確認するか決める |
ブロック・警告系の DLP ポリシー
AI サイトへの機密情報送信を防ぐには、DLP ポリシーが中心になります。DSPM for AI の既定ポリシーには、AI サイトへの機密情報送信をブロックするもの、リスクが高いユーザーによる AI アプリへの入力を Edge でブロックするもの、Microsoft 365 Copilot とエージェントによる特定ラベル付きアイテムの処理をブロックするものがあります。(Microsoft Learn)
ここで重要なのは、最初から本番ブロックにしないことです。AI 利用を急に止めると、業務部門が未承認ツールや個人アカウントに流れるリスクがあります。
おすすめの進め方は次の通りです。
| 段階 | 実施内容 |
|---|---|
| 検出 | audit mode で AI 利用と機密情報送信の傾向を見る |
| 警告 | test mode または警告表示でユーザー反応を確認する |
| 例外設計 | 正当な業務利用、承認済み AI、特定部門を整理する |
| 制御 | 高リスクユーザー、重要情報、未承認 AI から優先してブロックする |
| 改善 | 誤検知、業務影響、回避行動を定期的に見直す |
AI ガバナンスでは、強すぎるブロックよりも「どの情報を、どの AI に、どの条件で渡してよいか」を明確にすることが大切です。
Collection policy とコンテンツキャプチャ
Collection policy は、AI のプロンプトや応答を Purview の各ソリューションで扱えるようにする重要な設定です。たとえば、Copilot in Fabric や Security Copilot のプロンプト・応答を収集し、eDiscovery や Data Lifecycle Management などで管理する用途があります。
ただし、注意点があります。公式ドキュメントでは、collection policy でコンテンツキャプチャのオプションが選択されていない場合、プロンプトや応答が表示されないことがあると説明されています。また、ネットワーク経由で AI アプリに共有された機密情報を検出するポリシーでは、SASE または SSE 連携を手動で追加する必要があり、検出はネットワークパートナーの実装に依存します。(Microsoft Learn)
「イベントは出ているのに、プロンプト本文が見えない」という場合は、まず次を確認してください。
| 症状 | 確認ポイント |
|---|---|
| AI interaction は見えるが本文がない | collection policy で content capture が有効か |
| ネットワーク経由の検出が出ない | SASE/SSE 連携が構成済みか |
| Copilot では見えるが外部 AI では見えない | 対象 AI アプリがサポート範囲内か |
| Chrome で検出できない | Purview browser extension と端末オンボーディング |
| 一部ユーザーだけ出ない | ライセンス、管理単位、ポリシースコープ |
Fabric データリスク評価の確認ポイント
Fabric ワークスペースのデータリスク評価を使う場合は、通常の Microsoft 365 管理とは別に、Entra アプリ登録、サービスプリンシパル認証、Fabric 管理者権限、Fabric admin portal の Tenant settings が関係します。
公式ドキュメントでは、Fabric データリスク評価の前提として、Cloud Application Administrator、Application Administrator、Privileged Role Administrator などの Entra ロールや、Fabric administrator が必要になることが示されています。また、認証方式として Federated Credentials が推奨され、Client Secret を使う場合は値が一度しか表示されないため安全に保存する必要があります。(Microsoft Learn)
実務で失敗しやすいのは、Purview 側だけ設定して Fabric 側の Admin API 設定を忘れるケースです。次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 |
|---|---|
| Entra アプリ登録 | Application client ID を控える |
| 認証方式 | 可能なら Federated Credentials を検討する |
| セキュリティグループ | 登録アプリをグループに追加する |
| Fabric Tenant settings | サービスプリンシパルの Admin API アクセスを有効化する |
| Purview 側設定 | DSPM for AI でデータリスク評価を構成する |
Client Secret を使う場合は、個人のメモやチャットに貼り付けず、組織のシークレット管理ルールに従って保存してください。
Microsoft 365 の item-level scanning で必要な確認
Microsoft 365 の item-level scanning を使うカスタムデータリスク評価では、Entra アプリに Microsoft Graph のアプリケーション権限を付与する必要があります。公式ドキュメントでは、Application.Read.All、Directory.Read.All、Files.ReadWrite.All、SensitivityLabels.Read.All、Sites.ReadWrite.All、User.Read.All などの権限が例示されています。(Microsoft Learn)
ここでの注意点は、権限が強いことです。Files.ReadWrite.All や Sites.ReadWrite.All は影響範囲が広いため、次の運用を必ず組み合わせてください。
| 対策 | 理由 |
|---|---|
| 管理者同意の記録を残す | 監査時に説明できるようにする |
| アプリ所有者を明確にする | 退職・異動時の放置を防ぐ |
| シークレット有効期限を管理する | 期限切れによる評価停止を防ぐ |
| 定期的に利用状況を確認する | 不要な高権限アプリを残さない |
| 変更管理に載せる | セキュリティ部門と業務部門の認識を合わせる |
AI セキュリティのための設定であっても、過剰なアプリ権限を放置すると別のリスクになります。DSPM for AI の導入は、Entra アプリの権限レビューとセットで進めるべきです。
移行期限はどう考えるべきか
対象の Microsoft Learn ページでは、classic 版が新しい Data Security Posture Management に置き換えられたことは明記されています。一方で、classic 版の利用終了日や強制移行期限が常に明示されているとは限りません。確認時点で期限が明確でない場合、管理者は「期限が出てから対応」ではなく「新規設計は新 DSPM、既存運用は棚卸し」の方針にしておくのが現実的です。
移行方針は次のように整理できます。
| 状況 | 推奨対応 |
|---|---|
| これから初めて導入する | 新しい DSPM を前提に設計する |
| classic 版で既にポリシー運用中 | 既存ポリシーを棚卸しし、影響を確認してから移行する |
| AI 利用の可視化だけ始めたい | audit mode から開始し、Activity explorer で傾向を見る |
| すでに DLP がある | 既存 DLP と DSPM for AI の既定ポリシーが重複しないか確認する |
| グローバル拠点がある | 国・地域ごとの法務、労務、ログ保持要件を確認する |
特にグローバル企業では、AI プロンプトや応答を収集する設定が、国や地域のプライバシー・労務規制に影響する可能性があります。技術的に収集できることと、社内規程として収集してよいことは別です。法務、セキュリティ、労務、人事、データ保護責任者を含めて判断してください。
Activity explorer で見るべきイベント
DSPM for AI の運用では、Activity explorer に表示されるイベントを理解しておく必要があります。公式ドキュメントでは、AI interaction、AI website visit、DLP rule match、Sensitive info types などのイベントが説明されています。(Microsoft Learn)
| イベント | 見るべきポイント |
|---|---|
| AI interaction | 誰が、どの AI とやり取りしたか |
| AI website visit | 未承認 AI サイトへのアクセスが増えていないか |
| DLP rule match | 機密情報送信時に DLP が反応しているか |
| Sensitive info types | どの種類の機密情報が AI 利用で検出されているか |
ただし、すべてのイベントでプロンプトと応答が完全に表示されるわけではありません。メールボックスが Exchange Online にないユーザー、Microsoft Facilitator の AI 生成ノート、collection policy の content capture 未選択などでは、プロンプトや応答が表示されない場合があります。表示されないことを「ログが壊れている」と決めつけず、前提条件を確認してください。
サポート対象 AI サイトの確認も欠かせない
サードパーティ AI サイトへの対応では、組織で利用されている AI サービスが Microsoft Purview のサポート対象に含まれるかを確認する必要があります。公式のサポート対象 AI サイト一覧には、ChatGPT、Claude、Copilot、DeepSeek などを含む多数の生成 AI 関連ドメインが掲載されており、今後増える可能性があると案内されています。(Microsoft Learn)
ただし、サポート対象一覧にあることと、組織で安全に使えることは同じではありません。次の観点で社内ルールを作ると運用しやすくなります。
| 分類 | 例 |
|---|---|
| 承認済み AI | 会社契約済み、ログ取得可能、データ利用条件を確認済み |
| 条件付き許可 | 機密情報入力禁止、個人情報入力禁止、部門限定 |
| 監視対象 | 利用実態を把握中、DLP で警告 |
| 禁止 | 規約不明、データ保持不明、業務利用不可 |
AI サイトは増減が早いため、年 1 回の棚卸しでは追いつかないことがあります。月次または四半期ごとに、Activity explorer とブラウザー利用ログを見ながら見直す運用が現実的です。
よくある失敗と回避策
Microsoft Purview DSPM for AI の導入で失敗しやすいポイントは、機能不足よりも「前提条件の思い込み」です。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Copilot のイベントが出ない | Audit、ライセンス、権限不足 | 監査と対象ユーザーを先に確認 |
| Chrome で AI サイト検出が弱い | 拡張機能や端末オンボーディング不足 | Purview browser extension を展開 |
| プロンプト本文が見えない | content capture 未設定 | collection policy を確認 |
| いきなり業務が止まる | DLP を本番ブロックで全社展開 | audit mode から段階展開 |
| 料金が想定外になる | PAYG 対象を把握していない | Azure サブスクリプションと課金単位を確認 |
| 管理者が設定できない | 管理単位や権限が制限されている | unrestricted administrator が必要な操作を確認 |
| 既存ポリシーと重複する | 既存 DLP と one-click policy の整理不足 | ポリシー一覧を棚卸しする |
特に、Administrative Units を使っている環境では、制限付き管理者が全ユーザー対象の one-click policy を作成できないことがあります。グローバル展開では、地域管理者に任せる作業と、中央管理者が行う作業を分けてください。(Microsoft Learn)
グローバル展開時の実務チェックリスト
グローバル企業や複数拠点を持つ組織では、Microsoft Purview DSPM for AI を一括展開する前に、次のチェックリストを使って準備すると安全です。
| フェーズ | チェック項目 |
|---|---|
| 事前調査 | 承認済み AI、未承認 AI、Copilot 利用部門を棚卸しする |
| 権限設計 | Compliance Administrator、閲覧者、調査担当者を分ける |
| 監査設定 | Purview Audit、保持期間、Activity explorer 権限を確認する |
| 端末管理 | Windows、macOS、Edge、Chrome、Firefox の対象を整理する |
| DLP 設計 | audit、warning、block の段階展開を決める |
| データ分類 | sensitivity labels と機密情報タイプを業務に合わせる |
| 課金確認 | pay-as-you-go 対象と Azure サブスクリプションを確認する |
| 法務確認 | プロンプト・応答の収集、従業員監視、ログ保持を確認する |
| 教育 | ユーザーに「入力してよい情報」と「禁止情報」を伝える |
| 運用改善 | 月次で検出件数、誤検知、例外申請を見直す |
AI セキュリティは、ポリシーを作って終わりではありません。実際の利用状況を見ながら、業務部門と一緒にルールを調整することが重要です。
管理者が次に取るべき行動
Microsoft Purview DSPM for AI の今回の更新ポイントは、classic 版の導入考慮事項を確認しつつ、新しい DSPM への移行を見据えることにあります。
まず行うべきことは、次の 5 つです。
| 優先度 | 作業 |
|---|---|
| 高 | 既存の DSPM for AI ポリシー、DLP、collection policy を棚卸しする |
| 高 | Purview Audit、ライセンス、Activity explorer 権限を確認する |
| 高 | Edge、Chrome、端末オンボーディング、ブラウザー拡張の状態を確認する |
| 中 | pay-as-you-go が必要な AI アプリや機能を洗い出す |
| 中 | 新しい DSPM で同等の運用ができるか検証する |
新規導入では、新しい Microsoft Purview Data Security Posture Management を前提に設計し、classic 版の情報は既存機能や one-click policy の理解に使うのがよい進め方です。既存環境では、急な削除や一括移行を避け、監査モードで実態を把握してから、DLP、ラベル、collection policy、AI サイト制御を段階的に強化してください。
Microsoft Purview DSPM for AI は、AI 利用を止めるための機能ではなく、機密データを守りながら AI を業務利用するための管理基盤です。最初の一歩は、画面上の推奨事項を有効化することではなく、自社の AI 利用経路、対象データ、管理責任、ログ取得方針を明確にすることです。
コメント