Microsoft Purview の「Use Network Data Security to help prevent sharing sensitive information with unmanaged AI」は、ChatGPT、Gemini、Claude などの未管理AIアプリへ、機密情報を含むプロンプトやファイルが送信・アップロードされるのを防ぐための DLP ポリシー作成シナリオです。結論から言うと、これは単なるAI利用禁止の設定ではなく、Microsoft Purview の分類・DLP、SASE またはセキュアブラウザー連携、ネットワークレイヤーでの検査を組み合わせて、未承認AIへの情報流出を抑える仕組みです。
2026年7月1日に更新された公式ドキュメントでは、Microsoft Purview の DLP ポリシーで「Inline web traffic」を選び、「All unmanaged AI apps」を対象にし、「Network and non-Microsoft secure browsers」で制御する流れが示されています。特に重要なのは、一部機能がプレビューであること、ネットワーク経由の制御には SASE または非Microsoftのセキュアブラウザー連携が必要であること、そして本番展開ではいきなりブロックせず、対象部門・機密情報タイプ・通知設計を事前に整理すべき点です。 (Microsoft Learn)
Microsoft Purview の新機能・変更点：「Use Network Data Security to help prevent sharing sensitive information with unmanaged AI」で確認すべきポイント
Microsoft Purview の今回の更新ポイントは、未管理AIアプリへの情報共有を「ネットワークデータセキュリティ」と DLP ポリシーで制御する具体的な手順が整理されたことです。
従来の DLP は、Exchange、SharePoint、OneDrive、Teams、エンドポイントなど、Microsoft 365 内や管理済みデバイス上の操作を中心に考えられることが多くありました。しかし、生成AIの利用が広がると、ユーザーがブラウザー、ローカルアプリ、アドイン、外部クラウドアプリを経由して、会社の機密情報を未承認AIへ入力するリスクが高まります。
今回のシナリオでは、このリスクに対して、以下のような制御を行います。
| 確認項目 | 内容 |
|---|---|
| 対象 | 未管理AIアプリ、未承認クラウドアプリ、ネットワーク経由のWeb通信 |
| 主な制御 | 機密情報を含むテキスト送信やファイルアップロードを監査またはブロック |
| 使用する機能 | Microsoft Purview DLP、Network Data Security、SASEまたはセキュアブラウザー連携 |
| 想定シナリオ | 経理・人事・法務・開発部門などが、顧客情報、財務情報、個人情報、機密文書をAIへ送信しないようにする |
| 注意点 | 一部機能はプレビュー。事前検証、課金設定、対象範囲の設計が必要 |
公式ドキュメントでは、Finance 部門を例に、財務情報、個人識別情報、機密ラベル付き文書などが未承認の生成AIアプリに共有されないようにブロックし、発生時にはセキュリティチームへアラートを送る構成が紹介されています。 (Microsoft Learn)
何ができるようになるのか
この機能の実務上の価値は、「AIアプリを全面的に禁止する」のではなく、「危険なデータだけを検出して止める」運用に近づける点にあります。
たとえば、社員が生成AIを使って文章の要約や一般的な調査を行うことは許可しつつ、次のような操作はブロック対象にできます。
- 顧客の氏名、住所、口座番号、クレジットカード番号を含む文章をAIチャットへ貼り付ける
- 機密ラベルが付いたExcel、PDF、Word文書を未承認AIへアップロードする
- 社内の未公開資料や契約書を外部AIアプリで要約しようとする
- 開発中のソースコードや設計資料をAIサービスへ送る
- Gmail、Google Forms、クラウドストレージなど、Microsoft 365 外の宛先へ機密情報を送る
Microsoft Purview Network Data Security は、生成AIアプリ、クラウドストレージ、Webメール、オンラインフォーム、SNS などへの通信を対象に、機密コンテンツの検出、ブロック、アラートを行える仕組みとして説明されています。 (Microsoft Learn)
影響範囲：誰が確認すべきか
今回の更新は、Microsoft Purview の管理者だけでなく、セキュリティ、ネットワーク、ID管理、AI活用推進の担当者にも影響します。理由は、DLP ポリシー単体では完結せず、SASE、Microsoft Entra Global Secure Access、セキュアブラウザー、ライセンス、課金、ユーザーグループ設計が関係するためです。
| 担当者 | 確認すべきこと |
|---|---|
| Purview / コンプライアンス管理者 | DLP ポリシー、機密情報タイプ、秘密度ラベル、アラート設定 |
| セキュリティ管理者 | 未管理AIアプリの利用リスク、ブロック時のインシデント対応 |
| Entra / ID管理者 | Entra ID 参加デバイス、条件付きアクセス、対象ユーザーグループ |
| ネットワーク管理者 | SASE、Global Secure Access、TLS検査、トラフィック転送 |
| 情報システム部門 | AI利用ルール、例外申請、ユーザー通知、問い合わせ対応 |
| 法務・監査部門 | 個人情報、契約情報、規制対象データの扱い |
特に Microsoft Entra Global Secure Access を利用する場合、デバイスが Entra ID に参加していることや、Global Secure Access 側のコンテンツポリシー設定が前提になります。サードパーティ製 SASE を使う場合は、各プロバイダー側の統合手順も完了している必要があります。 (Microsoft Learn)
設定変更のポイント
公式手順で中心になるのは、Microsoft Purview の DLP ポリシー作成画面で「Inline web traffic」を選び、対象アプリ、適用場所、条件、アクション、アラートを順に設定する流れです。
DLP ポリシーで選ぶ主な設定
| 設定箇所 | 推奨される確認内容 |
|---|---|
| Policy type | Inline web traffic を選択する |
| Cloud apps | Adaptive app scopes から All unmanaged AI apps を選ぶ |
| Scope | 全社ではなく、まずは経理、人事、開発など高リスク部門に絞る |
| Enforcement location | Network and non-Microsoft secure browsers を有効化する |
| Conditions | Sensitive info types、Sensitivity labels を使う |
| Actions | Text sent、File uploaded などを Audit または Block にする |
| Incident reports | 重大度、管理者アラート、通知先グループを設定する |
| Policy mode | 本番ではシミュレーションまたはパイロットから始めるのが安全 |
公式シナリオでは、条件として銀行口座番号、クレジットカード番号、社会保障番号などの機密情報タイプや、Confidential の秘密度ラベルを利用し、アクションとして「Text sent to or shared with cloud or AI apps」と「File uploaded to or shared with cloud or AI apps」を Block に設定する例が示されています。 (Microsoft Learn)
Global Secure Access 側の設定も必要
Microsoft Entra Global Secure Access を使う場合、Purview 側の DLP ポリシーだけでは不十分です。Global Secure Access 側でコンテンツポリシーを作成し、必要に応じて「Scan with Purview」を選び、セキュリティプロファイルや条件付きアクセスと関連付けます。
公式情報では、Scan with Purview を使う場合、対応する Microsoft Purview DLP ポリシーが必要であり、対応するポリシーがないと、選択したファイルやテキストの検査、監査、ブロック判断を実行できないと説明されています。 (Microsoft Learn)
移行期限はあるのか
2026年7月1日更新の公式情報を確認する限り、このシナリオに関して「いつまでに移行しなければならない」という明確な移行期限は示されていません。したがって、既存の DLP ポリシーが即座に無効になる、または従来設定から強制移行されるという内容ではありません。
ただし、これは「急がなくてよい」という意味ではありません。生成AIアプリの利用は部門単位で急速に広がりやすく、ユーザーが個人判断で外部AIへファイルをアップロードするケースもあります。期限がない場合でも、管理者は次の順番で早めに確認するのが現実的です。
| 優先度 | 対応内容 | 理由 |
|---|---|---|
| 高 | 未管理AIアプリの利用実態を把握する | どの部門・ユーザーがリスクを持つか分からないと設計できない |
| 高 | 機密情報タイプと秘密度ラベルを整理する | 誤検知・過検知を減らすため |
| 高 | pay-as-you-go とライセンス要件を確認する | ネットワーク制御を選択できない場合がある |
| 中 | SASE / Global Secure Access の前提条件を確認する | ネットワーク経由の検査には連携が必要 |
| 中 | パイロット部門でシミュレーションする | 業務停止や問い合わせ増加を避ける |
| 中 | AI利用ポリシーと例外申請ルールを整備する | 技術的ブロックだけでは現場運用が混乱する |
Microsoft Purview のネットワークデータセキュリティでは、ポリシー作成前に pay-as-you-go の設定が必要とされ、Network Data Security はリクエスト単位を課金上の測定単位として扱うと説明されています。 (Microsoft Learn)
管理者が最初に確認すべきチェックリスト
本番設定に入る前に、次の項目を確認してください。ここを飛ばすと、「ポリシーを作ったのに効かない」「必要な通信まで止まる」「アラートが多すぎて運用できない」といった失敗につながります。
ライセンスと課金
Microsoft Purview の Network Data Security では、構成によって Microsoft 365 / Purview 系のライセンス、Entra Internet Access、pay-as-you-go の設定が関係します。特に Network and non-Microsoft secure browsers の選択は、pay-as-you-go が設定されている場合にのみ利用できると説明されています。 (Microsoft Learn)
確認すべきことは次の通りです。
- Microsoft Purview DLP を利用できるライセンスがあるか
- Microsoft Entra Global Secure Access を使う場合、必要なライセンスがあるか
- Microsoft 365 テナントと Azure サブスクリプションの関連付けが済んでいるか
- pay-as-you-go のコスト見積もりを行ったか
- プレビュー期間中の課金扱いが自社の構成にどう影響するか確認したか
対象ユーザーとグループ
最初から全社に適用すると、業務影響が読みづらくなります。まずは、機密情報を扱う頻度が高い部門から始めるのが現実的です。
候補になりやすい部門は、経理、人事、法務、営業企画、経営企画、情報システム、開発部門です。たとえば経理部門であれば、銀行口座情報、請求書、決算資料、取引先情報などがAIへ送信されるリスクを重点的に見るべきです。
機密情報タイプと秘密度ラベル
DLP ポリシーの精度は、何を機密情報として扱うかで大きく変わります。
日本企業であれば、公式例にある米国向けの社会保障番号やABA Routing Numberをそのまま使うのではなく、自社の実データに合わせて設計する必要があります。日本向けでは、マイナンバー、クレジットカード番号、銀行口座情報、顧客ID、従業員番号、契約書、見積書、設計書などが候補になります。
既に Microsoft Purview Information Protection で秘密度ラベルを運用している場合は、「Confidential」「Highly Confidential」「社外秘」「極秘」などのラベルを DLP 条件に組み込むと、文書の意味に近い制御ができます。
アクションは「監査」から始める
公式シナリオでは即時ブロックの例が示されていますが、本番環境では最初から Block にすると、業務影響が大きくなることがあります。
Microsoft の DLP 展開ガイダンスでは、ポリシーの状態、アクション、スコープを使って段階的に展開し、シミュレーションから本番適用へ進める考え方が示されています。管理者が影響を把握する前に強制ブロックを広げると、ユーザーの反発や例外申請の急増につながります。 (Microsoft Learn)
おすすめは次の流れです。
| フェーズ | 設定 | 目的 |
|---|---|---|
| 検証 | テスト環境または少人数で Audit | 誤検知、対象通信、ログ出力を確認 |
| パイロット | 高リスク部門で Simulation + 通知 | ユーザー影響と問い合わせ内容を把握 |
| 段階適用 | 一部条件を Block | 本当に止めるべき操作だけを制御 |
| 本番展開 | 対象部門を拡大 | 監査ログとアラートを見ながら調整 |
実務で使いやすいポリシー設計例
実際に設定する場合は、「AIアプリを禁止するかどうか」ではなく、「誰が、どのデータを、どの宛先へ、どの操作で送る場合に止めるのか」を明確にします。
例：経理部門の未管理AI利用を制御する
| 項目 | 設定例 |
|---|---|
| 対象ユーザー | Finance、Accounting、経理部門グループ |
| 対象アプリ | All unmanaged AI apps |
| 条件 | 銀行口座番号、クレジットカード番号、請求書、Confidential ラベル |
| 操作 | テキスト送信、ファイルアップロード |
| アクション | 初期は Audit、検証後に Block |
| 通知先 | SecurityOps、情報システム、部門管理者 |
| 確認方法 | Purview の DLP Alerts、Activity explorer、SASE側ログ |
この設計では、経理部門が一般的なAI利用をすること自体は必ずしも止めません。一方で、請求書や顧客の支払い情報をAIに貼り付ける、機密ラベル付きのExcelをアップロードする、といった高リスク操作を重点的に制御します。
例：開発部門のソースコード持ち出しを監査する
開発部門では、ソースコードや設計書をAIへ送ることで、知的財産や脆弱性情報が外部に出る可能性があります。この場合、最初からブロックするより、まず監査で利用実態を把握するのが有効です。
| 項目 | 設定例 |
|---|---|
| 対象ユーザー | 開発部門、委託先用グループ |
| 対象アプリ | 未管理AIアプリ、コード生成AI、未承認クラウドストレージ |
| 条件 | ソースコード拡張子、秘密度ラベル、機密プロジェクト名 |
| 操作 | ファイルアップロード、テキスト送信 |
| アクション | Audit only から開始 |
| 次の判断 | 誤検知率、業務必要性、代替AI環境の有無で Block を検討 |
ポイントは、開発者のAI活用を一律に妨げるのではなく、会社として許可したAI環境や契約済みサービスへ誘導することです。DLP は禁止のためだけでなく、安全な利用先へ行動を変えるための仕組みとして使うと運用しやすくなります。
失敗しやすいポイント
Purview 側だけ設定して満足してしまう
Network Data Security は、Purview の DLP ポリシーだけでは完結しません。SASE、Microsoft Entra Global Secure Access、または非Microsoftのセキュアブラウザーが統合されていなければ、ネットワーク上の通信を検出・制御できません。
Global Secure Access で Scan with Purview を使う場合も、Purview 側に対応する Inline web traffic の DLP ポリシーが必要です。片側だけ設定しても、期待通りに検査やブロックが行われない可能性があります。 (Microsoft Learn)
対象アプリの通信先を単純に考えすぎる
生成AIアプリは、画面上のドメインだけで通信が完結しないことがあります。ファイルアップロード、認証、API、添付ファイル処理などで、別のURLやFQDNを使う場合があります。
公式情報でも、Webアプリケーションは裏側で複数のURLやFQDNを使うことがあるため、ブラウザーの開発者ツールやネットワーク分析で実際のアップロード先を確認することが推奨されています。 (Microsoft Learn)
ブロック対象を広げすぎる
「All unmanaged AI apps」を対象にするのは強力ですが、対象ユーザーや条件を絞らないと、業務に必要なAI利用まで止まる可能性があります。
最初は、以下のように段階的に広げるのが安全です。
- 全社ではなく高リスク部門から始める
- すべての情報ではなく、明確な機密情報タイプや秘密度ラベルに限定する
- すぐに Block ではなく Audit または Simulation で実績を見る
- アラートの通知先を絞り、対応フローを決めてから拡大する
アラート運用を設計しない
ブロックや監査が増えると、アラートも増えます。通知先を SecurityOps にするだけでは不十分です。
事前に、次の運用ルールを決めておく必要があります。
| 項目 | 決めること |
|---|---|
| 初動対応 | 誰がアラートを確認するか |
| 優先度 | どの機密情報タイプを重大扱いにするか |
| ユーザー連絡 | 違反ユーザーへ誰が連絡するか |
| 例外対応 | 業務上必要なAI利用をどう承認するか |
| チューニング | 誤検知をどの頻度で見直すか |
既存環境への影響
既存の Microsoft Purview DLP を利用している企業にとって、今回の更新は「既存ポリシーを置き換えるもの」ではなく、「ネットワーク経由のAI・クラウドアプリ利用にDLPの適用範囲を広げるもの」と考えると分かりやすいです。
既に秘密度ラベルや機密情報タイプを整備している組織は、それらを活用して未管理AIアプリ向けのポリシーを作れます。一方、ラベル運用が未整備の場合は、先に分類ルールを固めないと、ブロック精度が低くなります。
影響が出やすいのは、次のような環境です。
- 社員が自由にブラウザーやAIサービスを使える
- 部門ごとにAI利用ルールが異なる
- 取引先情報、個人情報、設計情報を扱う部門が多い
- Microsoft 365 外のクラウドアプリ利用が多い
- ゼロトラストやSASE導入を進めている
- 生成AI利用の監査証跡を求められている
管理者が次に取るべき行動
Microsoft Purview の「Use Network Data Security to help prevent sharing sensitive information with unmanaged AI」を導入検討する管理者は、まず本番設定ではなく、現状把握から始めるべきです。
次の順番で進めると、無理なく導入できます。
| 手順 | 作業内容 |
|---|---|
| 1 | 未管理AIアプリの利用実態を確認する |
| 2 | 機密情報タイプ、秘密度ラベル、対象部門を整理する |
| 3 | Purview DLP、Entra Global Secure Access、SASE、pay-as-you-go の前提条件を確認する |
| 4 | テスト環境または少人数で Inline web traffic の DLP ポリシーを作成する |
| 5 | Audit または Simulation でログと誤検知を確認する |
| 6 | 高リスク操作だけ Block に変更する |
| 7 | アラート対応、例外申請、ユーザー教育を整備する |
| 8 | 対象部門を段階的に拡大する |
特に重要なのは、「AI利用を止める」ことを目的にしないことです。目的は、顧客情報、個人情報、財務情報、契約情報、知的財産が、未管理AIアプリへ不用意に渡るのを防ぐことです。安全に使えるAI環境と、送ってはいけないデータの境界を明確にすることで、現場の生産性と情報保護を両立しやすくなります。
まとめ
Microsoft Purview の「Use Network Data Security to help prevent sharing sensitive information with unmanaged AI」は、未管理AIアプリへの機密情報共有を防ぐための重要なDLPシナリオです。2026年7月1日更新の公式情報では、Inline web traffic、All unmanaged AI apps、Network and non-Microsoft secure browsers、Sensitive info types、Sensitivity labels、Block / Audit、アラート設定を組み合わせる具体的な手順が示されています。
現時点で明確な移行期限は示されていませんが、生成AIの利用拡大を考えると、早めに検証を始める価値があります。管理者は、まずライセンスと pay-as-you-go、SASEまたは Global Secure Access 連携、対象部門、機密情報タイプ、アラート運用を確認し、いきなり全社ブロックではなく、監査・シミュレーション・パイロットから段階的に展開してください。
コメント