Microsoft Purview の「Network Data Security」は、生成AIや未承認クラウドアプリへ送信されるテキスト、ファイル、添付資料などをネットワーク層で検出・分類・保護するための機能です。2026年7月1日に更新された公式情報では、Microsoft Purview の既存の分類器や DLP ポリシーを、ブラウザー、アプリ、API、アドイン経由の通信に拡張できる点が重要です。(Microsoft Learn)
特に確認すべきなのは、「既存の Purview DLP をそのまま使えば自動的に全ネットワーク通信が保護される」という話ではない点です。Entra Global Secure Access、SASE、セキュアブラウザーとの統合、pay-as-you-go の有効化、collection policy または DLP policy の作成、対象アプリや対象ユーザーのスコープ設計が必要です。移行期限や廃止期限は公式ページ上では示されていないため、現時点では“強制移行”ではなく、シャドーAIや未管理クラウドアプリ対策として計画的に導入を検討する更新と捉えるのが現実的です。(Microsoft Learn)
Microsoft Purview Network Data Securityとは
Microsoft Purview Network Data Security は、Microsoft Purview の分類・検出・DLP 制御をネットワークトラフィックに拡張する仕組みです。従来の DLP は Exchange、SharePoint、OneDrive、Teams、Endpoint などの管理対象ワークロードや端末操作を中心に考えることが多いですが、Network Data Security では、未管理または信頼されていないクラウドアプリへの通信も監視・分類・ブロックの対象にできます。(Microsoft Learn)
対象になり得る代表例は、ChatGPT、Gemini、Claude などの生成AIアプリへの入力、Dropbox、Box、Google Drive などの未承認クラウドストレージへのアップロード、Gmail などのクラウドメールへの本文や添付ファイル送信、Google Forms へのフォーム入力、Facebook や X などへの投稿です。(Microsoft Learn)
この更新の本質は、Microsoft Purview の分類機能を「ファイルやメールの中」だけでなく、「ユーザーが外部サービスへ送ろうとしている通信」に近い場所まで広げることにあります。社内では Copilot や Microsoft 365 を管理できていても、個人利用の生成AI、外部SaaS、クラウドメール、ブラウザー経由のアップロードまでは見えにくい、という課題への対策になります。
2026年7月1日更新で押さえるべきポイント
今回の公式情報で管理者が最初に確認すべきポイントは、次の4つです。
| 確認項目 | 要点 | 管理者が取るべき対応 |
|---|---|---|
| 影響範囲 | 未管理クラウドアプリ、生成AI、クラウドメール、フォーム、SNS などへの通信を対象にできる | 自社で利用・黙認・禁止している外部サービスを棚卸しする |
| 設定変更 | Purview 側の collection policy または DLP policy に加え、GSA/SASE/セキュアブラウザー連携が必要 | 既存 DLP ポリシーとは別に、ネットワーク層向けの設計を行う |
| ライセンス・課金 | 構成に応じて Purview E5 相当、Entra Internet Access 相当、pay-as-you-go 設定が関係する | 本番展開前にライセンスと Azure 課金連携を確認する |
| 移行期限 | 公式ページ上で移行期限や廃止期限は示されていない | 強制対応ではなく、AI・SaaS 利用リスクに応じて段階導入する |
Microsoft の「What’s new」では、2026年7月の Data Loss Prevention 更新として、Microsoft Entra Global Secure Access との統合により、テキストやプロンプトをネットワーク層で検査し、DLP ポリシーに基づいて制限アクションを適用できるプレビュー機能として説明されています。(Microsoft Learn)
影響範囲：生成AIだけでなく未管理クラウドアプリ全体が対象
Network Data Security という名前から「ネットワーク機器のセキュリティ機能」と誤解しやすいですが、主眼はデータ保護です。ユーザーがどのアプリに、どの種類の情報を、どの経路で送ろうとしているかを Microsoft Purview の分類器で評価し、検出、監査、ブロック、アラートに活用します。
主な対象シナリオ
| シナリオ | 例 | 想定されるリスク |
|---|---|---|
| 生成AIへの入力 | ChatGPT、Gemini、Claude へのプロンプト送信 | 顧客情報、契約情報、ソースコード、社内資料の貼り付け |
| 未承認ストレージへのアップロード | Dropbox、Box、Google Drive | 社外共有、退職前持ち出し、管理外バックアップ |
| クラウドメール利用 | Gmail への本文・添付ファイル送信 | 個人メールへの機密情報転送 |
| オンラインフォーム | Google Forms など | 個人情報や業務データの外部送信 |
| SNS・投稿サービス | Facebook、X など | 未公開情報や顧客情報の投稿 |
実務上の優先度が高いのは、生成AIへのプロンプト入力とファイルアップロードです。たとえば、営業担当者が顧客リストを生成AIに貼り付けて分析させる、開発者が未公開ソースコードを外部AIに送る、経理部門が請求書PDFを個人のクラウドストレージにアップロードするといった行為は、従来のメールDLPだけでは捕捉しにくいことがあります。
Network Data Security は、こうした「管理対象アプリの外側」に出ていく通信を可視化・制御するための選択肢です。
仕組み：SASEやセキュアブラウザーとPurviewを連携する
Network Data Security は、Microsoft Purview 単体でネットワークを監視する機能ではありません。Microsoft Entra Global Secure Access、または Microsoft 以外の SASE/セキュアブラウザーソリューションと連携し、それらのネットワークセキュリティ基盤が通信を取り込み、Microsoft Purview に分類・ポリシー評価を渡す構成です。(Microsoft Learn)
公式情報では、DLP ポリシーによる保護を適用する場合、統合ソリューションと Microsoft Purview の通信はリアルタイムに行われます。一方、collection policy による監視のみの場合は非同期で処理されます。(Microsoft Learn)
構成イメージ
| 構成要素 | 役割 |
|---|---|
| Microsoft Purview | 分類器、collection policy、DLP policy、Activity explorer、DLP alerts を管理 |
| Entra Global Secure Access | Microsoft 側のネットワークアクセス基盤として通信を中継・制御 |
| SASE/セキュアブラウザー | Microsoft 以外の統合ソリューションとしてネットワーク通信を Purview に連携 |
| Security Store | Purview と外部ソリューションの統合を設定する場所 |
| Activity explorer / DSPM for AI | 検出イベントやAI利用状況を確認する分析画面 |
注意したいのは、Microsoft 以外のパートナーソリューションと統合する場合、ユーザー識別子を含む一部のポリシー構成情報にパートナーがアクセスまたは保存する可能性がある点です。利用条件やプライバシーポリシーはパートナー側の条件に従うため、グローバル企業ではデータ所在、越境移転、委託先管理、監査対応も事前に確認する必要があります。(Microsoft Learn)
設定変更：collection policyとDLP policyを使い分ける
Network Data Security の設定では、大きく分けて collection policy と DLP policy を使います。両者は似ていますが、目的が異なります。
| 種類 | 主な目的 | 向いている使い方 |
|---|---|---|
| collection policy | 検出・可視化 | まず実態を把握したい、AI利用状況を見たい、誤検知を確認したい |
| DLP policy | 保護・制御 | 機密情報の送信を監査またはブロックしたい、アラートを出したい |
collection policy では、他の Purview ポリシーと同じ条件を利用できます。たとえば「Content contains > Sensitive information types」を使い、生成AIや未管理クラウドアプリに共有される機密情報を分類できます。対応するアクティビティには、テキスト送信、ファイルアップロード、テキスト受信、ファイルダウンロードが含まれます。(Microsoft Learn)
DLP policy では、同じくデータソースや条件を定義したうえで、Audit only または Block をアクションとして設定できます。対象アクティビティは、テキスト送信、ファイルアップロード、テキスト受信、ファイルダウンロードです。ただし、利用できるアクティビティやアクションは統合する SASE やセキュアブラウザーによって異なる場合があります。(Microsoft Learn)
Entra Global Secure Accessを使う場合の注意点
Microsoft Entra Global Secure Access を利用する場合は、Purview 側の DLP ポリシーだけでなく、Global Secure Access 側の content policy も関係します。公式情報では、Global Secure Access の network content filtering は、生成AIアプリやインターネット宛先への意図しないデータ露出を防ぐため、Microsoft Purview の分類サービスと ID 中心のネットワークセキュリティポリシーを組み合わせる構成として説明されています。(Microsoft Learn)
特に重要なのは、Global Secure Access の content policy で「Scan with Purview」を選ぶ場合、対応する Microsoft Purview DLP policy も必要になる点です。対応する DLP policy がなければ、選択したファイルやテキストコンテンツを検査したり、監査・ブロックの判断を適用したりできません。(Microsoft Learn)
GSA利用時に確認する設定
| 設定箇所 | 確認内容 |
|---|---|
| Entra 管理センター | Global Secure Access の content policy を作成しているか |
| content policy のアクション | Purview 連携が必要な場合に Scan with Purview を選んでいるか |
| Purview ポータル | Inline web traffic を対象にした DLP policy を作成しているか |
| 条件付きアクセス | Global Secure Access Security Profile を適用しているか |
| クライアント | Global Secure Access client が正しく通信を転送しているか |
Global Secure Access の公式情報では、クライアント端末が Microsoft Entra ID joined または Microsoft Entra ID Hybrid joined であること、Internet Access traffic forwarding profile、TLS inspection、Global Secure Access client の構成確認なども前提として示されています。(Microsoft Learn)
ライセンスと課金：pay-as-you-goを先に確認する
Network Data Security を試す前に、ライセンスと課金の確認は必須です。公式情報では、Entra Global Secure Access と組み合わせる場合、Microsoft 365 E7 のユーザー単位ライセンス、または Purview E5 相当と Entra Internet Access 相当のライセンス組み合わせが必要とされています。Microsoft 以外の SASE やセキュアブラウザーと組み合わせる場合は、Purview E5 相当と Microsoft Purview pay-as-you-go billing model が必要です。(Microsoft Learn)
また、ネットワークデータセキュリティポリシーを作成する前に、Microsoft 365 テナントで pay-as-you-go を構成する必要があります。ただし、Entra Global Secure Access 経由で適用されるポリシーについては、パブリックプレビュー期間中は追加料金が発生しないと説明されています。(Microsoft Learn)
課金単位は「request」です。ここでいう request は、デバイスまたはブラウザーから Web サイトや API へ送られる各ネットワーク呼び出しで、レスポンスは含まれません。Microsoft Purview の課金モデル情報でも、Network Data Security はエンドポイントデバイスから Web サイト、クラウドアプリ、生成AIアプリへ送られるアウトバウンド request 数を単位として扱うと説明されています。(Microsoft Learn)
実務では、「ユーザーが1回送信した」単位と「課金上の request 数」は一致しない可能性があります。Webアプリや生成AIアプリは、画面表示、API呼び出し、ファイル送信、補助的な通信を複数回行うことがあるためです。最初から全社全アプリに広げるのではなく、対象部門、対象アプリ、対象アクティビティを絞って使用量を観察するのが安全です。
管理者が確認すべき設定手順
本番環境でいきなりブロックを有効にすると、業務影響が大きくなる可能性があります。まずは検出から始め、誤検知や対象アプリの漏れを確認したうえで段階的にブロックへ進むのが現実的です。
| フェーズ | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 事前調査 | 生成AI、クラウドストレージ、個人メール、フォーム、SNS の利用実態を確認 | 禁止アプリだけを見て、実際に使われている代替サービスを見落とす |
| ライセンス確認 | Purview E5 相当、Entra Internet Access 相当、pay-as-you-go を確認 | ポリシー作成時に network 関連の選択肢が使えない |
| 統合設定 | GSA、SASE、セキュアブラウザーを Purview と連携 | 通信が転送されておらず、検出イベントが出ない |
| collection policy | まず監視目的でテキスト送信・ファイルアップロードを検出 | 条件が広すぎてノイズが増える |
| DLP policy | 高リスク部門・高リスク情報から Audit only または Block を適用 | 最初から全社ブロックし、業務停止や問い合わせが増える |
| 監視・改善 | Activity explorer、DSPM for AI、DLP alerts を確認 | アラートを作っても運用担当や対応手順が決まっていない |
公式情報では、統合後にポリシーがネットワークセキュリティソリューションへ配布され、最初のデータが表示されるまで最大24時間かかる場合があります。さらに、両サービスの通信が確立した後も、クライアントから Web サイトやクラウドアプリへの request に関するデータが監査ログや Activity explorer に表示されるまで最大30分かかる場合があります。(Microsoft Learn)
「設定したのにすぐ検出されない」と判断してポリシーを何度も変更すると、原因の切り分けが難しくなります。初回展開時は、テストユーザー、テストアプリ、テストデータを決め、24時間程度の反映時間も考慮して検証するのがよいでしょう。
ポリシー設計の具体例：生成AIへの機密情報送信を防ぐ
たとえば、経理部門や営業部門が生成AIを活用している企業では、次のようなポリシー設計が考えられます。
| 設計項目 | 例 |
|---|---|
| 対象ユーザー | 経理部門、営業部門、役員秘書、開発部門など |
| 対象アプリ | すべての未管理AIアプリ、または ChatGPT など特定アプリ |
| 条件 | クレジットカード番号、銀行口座番号、個人識別情報、機密ラベル付きファイル |
| 対象アクティビティ | テキスト送信、ファイルアップロード |
| アクション | 最初は Audit only、確認後に Block |
| アラート | 重大度 High、セキュリティ運用チームへ通知 |
Microsoft のシナリオ例でも、Finance 部門が未承認の生成AIアプリへ財務情報、個人情報、機密文書を送信しないように、Adaptive app scopes で All unmanaged AI apps を選び、Network and non-Microsoft secure browsers を有効化し、該当アクティビティを Block に設定する流れが示されています。(Microsoft Learn)
ただし、実務では最初から Block にするよりも、次の順番で進める方が安全です。
| ステップ | 推奨アクション |
|---|---|
| 検出開始 | collection policy で対象ユーザーと対象アプリの利用状況を確認 |
| 条件調整 | 誤検知しやすい分類器、不要なアプリ、低リスク通信を除外 |
| 監査運用 | DLP policy を Audit only で動かし、アラート量を確認 |
| 部分ブロック | 高リスク部門、高リスク分類、ファイルアップロードから Block |
| 全体展開 | 問い合わせ対応、例外申請、教育コンテンツを整備して拡大 |
この段階設計により、セキュリティ強化と業務継続のバランスを取りやすくなります。
対応プロトコルと対象外ユーザーにも注意
Network Data Security は万能なネットワークDLPではありません。公式情報では、プレビュー段階で HTTP および HTTPS プロトコルを通じて、エンドポイントデバイスから Web サイト、クラウドアプリ、生成AIサービスへ送信されるトラフィックの分類をサポートするとされています。(Microsoft Learn)
また、Purview network data security policies は B2B ゲストユーザーには適用されません。外部協力会社やゲストアカウントが多い環境では、「ゲスト経由の持ち出し」まで同じポリシーでカバーできると誤解しないようにする必要があります。(Microsoft Learn)
Global Secure Access の network content filtering では、HTTP/1.1 のシナリオや UDP/QUIC の非対応にも触れられています。QUIC を利用する通信では期待通りに検査できない可能性があるため、GSA で展開する場合はクライアント設定やネットワーク要件も合わせて確認してください。(Microsoft Learn)
Activity explorerとDSPM for AIで見るべき項目
検出されたデータは、Activity explorer、DSPM for AI の activity explorer events、DLP alerts などで確認できます。Activity explorer では enforcement plane を network に設定してフィルターすることで、Network Data Security の collection policy によって生成された分類イベントを確認できます。(Microsoft Learn)
運用担当者が見るべき項目は、単に「何件ブロックされたか」だけではありません。
| 確認項目 | 見る理由 |
|---|---|
| どの部門・ユーザーで発生しているか | 教育不足なのか、業務上必要な利用なのかを判断するため |
| どのアプリに送信しているか | 承認済みAIや社内代替サービスへ誘導するため |
| どの分類器に一致したか | 本当に機密情報なのか、誤検知なのかを判断するため |
| テキスト送信かファイルアップロードか | リスクの大きさとブロック優先度が異なるため |
| ブロック後の問い合わせ内容 | 業務影響と例外申請ルールを改善するため |
特に生成AI利用では、単純に禁止するだけではユーザーが別サービスへ流れることがあります。Activity explorer や DSPM for AI の情報を使い、「どの業務で外部AIを使おうとしているのか」を把握し、承認済みAI、社内ガイドライン、データマスキング手順をセットで整備することが重要です。
移行期限はあるのか
2026年7月1日に更新された「Learn about Microsoft Purview Network Data Security」の公式ページ上では、既存機能からの移行期限、旧機能の廃止日、強制切り替え日は確認できません。公式ページには最終更新日として 2026年7月1日が示されていますが、移行期限を示す記述はありません。(Microsoft Learn)
そのため、管理者は「期限までに置き換える」よりも、「リスクの高い通信から段階的に可視化する」方針で検討するのが適切です。
ただし、移行期限がないことは、対応を後回しにしてよいという意味ではありません。生成AI、個人クラウドストレージ、クラウドメール、フォーム送信は、ユーザーの利便性が高い一方で、社外へのデータ流出経路になりやすい領域です。DLP で守れている範囲と、ネットワーク層でしか見えない範囲を分けて整理する必要があります。
導入前に決めておくべき運用ルール
Network Data Security は、設定すれば終わりではありません。むしろ、導入後の問い合わせ、例外申請、アラート対応、ユーザー教育まで含めて設計しないと、誤検知対応や業務影響で運用が止まりやすくなります。
事前に決めるべき項目
| 項目 | 決める内容 |
|---|---|
| 承認済みAI | Microsoft 365 Copilot、社内AI、契約済みAIサービスなど利用可能な選択肢 |
| 禁止対象 | 個人アカウントの生成AI、未契約SaaS、個人クラウドストレージなど |
| 例外申請 | 誰が承認し、どの期間、どの条件で許可するか |
| ブロック時の案内 | ユーザーに何を表示・通知し、どこへ問い合わせるか |
| アラート対応 | SOC、情報システム、法務、部門管理者の役割分担 |
| ログ確認頻度 | 初期は毎日、安定後は週次などの確認サイクル |
| 海外拠点対応 | 国・地域ごとのプライバシー要件、労務上の監視ルール |
グローバル企業では、国や地域によって従業員監視、ログ取得、個人データの取り扱いに対する期待値や規制が異なります。Network Data Security の展開は、技術設定だけでなく、法務、プライバシー、労務、人事、情報セキュリティ部門を巻き込んで進めるべきです。
まず管理者が行うべきアクション
Microsoft Purview Network Data Security の更新ポイントを踏まえると、最初に行うべきことは、全社ブロックではなく「見える化の設計」です。
まず、生成AI、クラウドストレージ、個人メール、フォームサービス、SNS へのデータ送信リスクを棚卸しします。次に、Purview E5 相当、Entra Internet Access 相当、pay-as-you-go、GSA または SASE/セキュアブラウザー連携の前提条件を確認します。そのうえで、機密情報を扱う部門を対象に collection policy を作成し、Activity explorer で network イベントを確認します。
検出結果を見て、誤検知が少なく、業務影響が明確に管理できる範囲から DLP policy の Audit only、次に Block へ進めます。特にファイルアップロードと生成AIへのプロンプト送信は優先度が高い領域です。
Microsoft Purview Network Data Security は、シャドーAI時代の DLP をネットワーク層に広げるための重要な更新です。ただし、ライセンス、課金、統合ソリューション、対象外ユーザー、プレビュー制限を理解せずに展開すると、期待した検出ができない、コストが読めない、業務影響が大きいといった問題が起きます。まずは小さく検出し、実態を見てから制御を強める。この順序が、もっとも失敗しにくい導入方法です。
コメント