Microsoft Purview の分類、秘密度ラベル、DLP、Insider Risk Management を本格展開するなら、最初に確認すべきなのは個別の設定手順ではなく「データがどこで判定され、どこで保護され、どのログが調査に使われるか」です。
2026年4月14日時点で注目したい更新が、Microsoft Purview の参照アーキテクチャ図です。Microsoft Tech Community で公開された「Microsoft Purview Referential Architecture Diagrams」では、分類、秘密度ラベル、Endpoint DLP、Exchange DLP、SharePoint DLP、Browser DLP、Insider Risk Management、Microsoft 365 Copilot まわりの保護フローが図解されています。単なる説明資料ではなく、Purview architects や Microsoft 365 security teams が、設計レビュー、段階展開、関係者説明、運用設計に使える実務向けの参照資料と考えるべきです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview の新しい参照アーキテクチャ図が重要な理由
Microsoft Purview の導入で失敗しやすいのは、機能を個別に設定してしまうことです。
たとえば、DLP ポリシーだけを先に作ると、次のような問題が起きます。
- どの機密情報を検出対象にするのかが曖昧
- 秘密度ラベルの優先順位と DLP の条件がずれる
- Endpoint、Exchange、SharePoint、Browser で同じデータに違う制御がかかる
- Insider Risk Management のアラートが「何を根拠に危険と判断したのか」説明しづらい
- Copilot 利用時の情報露出リスクを既存のラベル・DLP設計に結び付けられない
今回の参照アーキテクチャ図が役立つのは、Purview の保護ワークフローを「機能単位」ではなく「データの流れ単位」で理解できるからです。Microsoft の説明でも、これらの図は単一の展開モデルを指示するものではなく、Microsoft 365 ワークロード全体で、ポリシー評価、シグナルの流れ、強制制御がどのように行われるかを理解するための参照図として位置付けられています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、この図を次のように使うと効果的です。
| 利用シーン | 参照アーキテクチャ図で確認すること |
|---|---|
| 初期設計 | 分類、ラベル、DLP、監査、調査の責任範囲 |
| 段階展開 | 先に有効化すべきワークロードと後回しにできる範囲 |
| セキュリティレビュー | データの流出経路ごとの検知・ブロック地点 |
| 経営層・法務説明 | 「何を守るか」ではなく「どこで守るか」の説明 |
| Copilot 展開前確認 | ラベル、アクセス権、DLP、監査が AI 利用時にも効くか |
分類は Purview 全体の出発点になる
Microsoft Purview のデータ保護では、分類が最初のシグナルになります。
分類とは、ファイル、メール、チャット、アップロードデータなどに含まれる情報を判定し、「これは個人情報か」「これは財務情報か」「これは契約書か」といった意味付けを行う処理です。Purview の参照アーキテクチャ図では、分類がクライアント、トランスポート、サービス側など複数の場所で行われ、結果が DLP、自動ラベル付け、データライフサイクル管理、eDiscovery などの下流制御に再利用されることが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
分類設計で特に重要なのは、最初から細かく作りすぎないことです。
よくある失敗は、部門ごとに独自の分類条件を大量に作り、運用開始後に誤検知と例外対応が増えすぎるパターンです。分類は精度が高いほど良いのではなく、後続の制御に使える粒度で安定していることが重要です。
分類設計で最初に決めるべきこと
分類を始める前に、少なくとも次の3点を整理します。
| 判断項目 | 実務上の確認ポイント |
|---|---|
| 守るべき情報 | 個人情報、認証情報、財務情報、知的財産、契約情報など |
| 検出方法 | Sensitive Information Types、Exact Data Match、文書フィンガープリント、トレーニング可能な分類子など |
| 後続制御 | ラベル付け、DLP、監査、Insider Risk、Copilot 利用制御に使うか |
たとえば、顧客のメールアドレスや電話番号を含むだけで即ブロックすると、営業活動やサポート業務が止まる可能性があります。一方、顧客ID、氏名、住所、契約番号が同時に含まれるファイルであれば、外部共有時に警告またはブロックする判断が現実的です。
分類は「検出できるか」ではなく、「検出結果をどの制御に使うか」から逆算して設計する必要があります。
秘密度ラベルは組織の保護意図を表す共通言語
秘密度ラベルは、Microsoft Purview における保護の共通言語です。
分類が「中身に何が含まれているか」を判定するものだとすれば、秘密度ラベルは「組織としてその情報をどう扱うべきか」を表します。Microsoft の参照アーキテクチャ図でも、秘密度ラベルは SharePoint、OneDrive、Teams、Outlook、Office アプリなどを横断し、暗号化、透かし、外部アクセス制御、DLP などの保護設定に結び付く統一的な制御面として説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
ラベル設計で重要なのは、名称を増やしすぎないことです。
「社外秘」「極秘」「機密」「重要」「制限付き」など、似た意味のラベルが並ぶと、ユーザーは判断できません。結果として、常に低いラベルを選ぶ、または高すぎるラベルを選んで業務が止まる、という運用になりがちです。
使いやすいラベル設計の例
| ラベル例 | 想定用途 | 制御例 |
|---|---|---|
| Public | 公開資料、採用ページ掲載資料 | 保護なし、監査のみ |
| Internal | 社内向け資料、一般的な業務文書 | 外部共有時に警告 |
| Confidential | 顧客情報、契約書、見積書 | 外部共有制限、DLP対象 |
| Highly Confidential | M&A、役員資料、重要な知財 | 暗号化、印刷制限、厳格な外部共有制御 |
Microsoft Learn でも、秘密度ラベルは優先順位が重要であり、より制限の強いラベルをリストの下位に配置する考え方が説明されています。また、1つのドキュメントやメールなどのアイテムに適用できる秘密度ラベルは基本的に1つであるため、優先順位の設計が自動ラベル付けやラベル変更時の挙動に影響します。(Microsoft Learn)
実務では、ラベル名だけでなく「ユーザーがどんな場面で選ぶべきか」を明文化することが欠かせません。ラベルポリシーより先に、社内向けの判断ガイドを作ると定着しやすくなります。
DLP は場所ごとの違いを理解して設計する
DLP は、機密データの不適切な共有や持ち出しを検知・警告・ブロックするための仕組みです。ただし、Microsoft Purview の DLP は1種類ではありません。Exchange、SharePoint、OneDrive、Teams、Endpoint、Browser、Copilot など、評価される場所によって保護できる行為が変わります。
Microsoft Learn では、Purview DLP はポリシーを定義して適用することで、企業アプリケーション、デバイス、インライン Web トラフィック内の機密情報を識別、監視、自動保護するものと説明されています。単純な文字列検索ではなく、キーワード、正規表現、検証関数、近接条件、機械学習などを使った深いコンテンツ分析が行われます。(Microsoft Learn)
DLP 展開で見るべき主な保護地点
| 領域 | 主なリスク | 設計時のポイント |
|---|---|---|
| Endpoint DLP | USB保存、印刷、クリップボード、未承認クラウドへのアップロード | デバイスのオンボード状況、ユーザー業務への影響 |
| Exchange DLP | メール誤送信、外部宛送信、添付ファイル流出 | ポリシーヒント、警告、ブロック、暗号化の使い分け |
| SharePoint / OneDrive DLP | 共有リンク、ゲストアクセス、既存ファイルの外部露出 | 共有時だけでなく、後から機密化したファイルも確認 |
| Browser DLP | 個人ブラウザ、未管理アプリ、生成AIサービスへの貼り付け・アップロード | 管理デバイスと非管理デバイスで制御を分ける |
| Copilot DLP | AI応答への機密情報露出、プロンプト経由の流出 | 既存のラベル、アクセス権、DLPポリシーとの整合性 |
参照アーキテクチャ図の価値は、この「どこで何が止められるのか」を一目で確認できる点にあります。
たとえば、メールの外部送信は Exchange DLP で制御できますが、ユーザーが同じファイルをUSBに保存する場合は Endpoint DLP が必要です。SharePoint の共有リンクは SharePoint / OneDrive 側の制御が中心になります。未管理の生成AIサービスにテキストを貼り付けるリスクは、Browser DLP や Edge for Business の制御を検討する領域です。
つまり、DLP は「1つのポリシーを作れば終わり」ではありません。データの出口ごとに、評価地点と強制地点を確認する必要があります。
Endpoint DLP はローカル作業の流出リスクを補完する
Endpoint DLP は、クラウドサービスに到達する前のローカル操作を監視・制御できる点が重要です。
Microsoft の参照アーキテクチャ図では、Endpoint DLP が Windows と macOS のデバイス上で評価・強制され、USBへのコピー、クラウドサービスへのアップロード、印刷、ブラウザへの貼り付けなどのユーザー操作を完了前に評価する流れが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learn でも、Endpoint DLP は Windows 10/11、macOS の直近3つのメジャーバージョン、特定の Windows Server に対して、DLP の監視・保護機能を拡張すると説明されています。デバイスが Microsoft Purview ソリューションにオンボードされると、機密アイテムに対するユーザー操作が Activity Explorer で可視化され、DLP ポリシーによる保護アクションを適用できます。(Microsoft Learn)
Endpoint DLP の段階展開例
| フェーズ | 推奨アクション | 目的 |
|---|---|---|
| 監査 | まずはブロックせず、USB保存・印刷・アップロードを記録 | 実際の業務パターンを把握 |
| 警告 | 高リスク操作にユーザー通知を表示 | 誤操作を減らし、教育効果を得る |
| 正当化要求 | 一部操作に理由入力を求める | 業務上必要な例外を可視化 |
| ブロック | 明確に禁止すべき操作を制限 | 重大な流出経路を閉じる |
最初からブロックを多用すると、現場の反発や例外申請が急増します。Endpoint DLP は特にユーザー体験に直結するため、監査から始め、影響範囲を確認してから警告・ブロックへ進めるのが現実的です。
Browser DLP は生成AI時代の見落としやすい防御線
従来のDLP設計では、メール、ファイル共有、エンドポイントが主な対象でした。しかし、生成AIサービスやSaaSの利用が増えると、ブラウザ上での貼り付け、ファイルアップロード、コピー、印刷が新たな流出経路になります。
今回の参照アーキテクチャ図では、Browser DLP が2つの観点で整理されています。
- 非管理デバイスまたは管理アプリへのアクセス
- 管理デバイスから未管理アプリやコンシューマーAIツールを利用するケース
特に後者は、多くの組織で見落とされがちです。会社貸与PCを使っていても、ユーザーが未承認のAIサービスに顧客情報やソースコードを貼り付ける可能性があります。この場合、端末は管理されていても、利用先のアプリは管理外です。
Microsoft Edge for Business の DLP ドキュメントでは、Endpoint DLP は Windows 10/11、macOS、Microsoft Edge に組み込まれており、追加エージェントやブラウザプラグインなしで、管理デバイス上のアプリケーションにポリシーを適用できると説明されています。また、ファイルアップロード、クリップボード、印刷、USBやネットワーク保存などのアクティビティを監査・管理できます。(Microsoft Learn)
Browser DLP で優先的に確認したい操作
| 操作 | リスク例 | 制御の考え方 |
|---|---|---|
| テキスト貼り付け | 顧客情報をAIプロンプトに貼る | 高機密ラベル付き情報は警告またはブロック |
| ファイルアップロード | 契約書を未承認SaaSにアップロード | 未承認ドメインへのアップロードを制限 |
| コピー | 社内文書から外部Webフォームへ転記 | ラベルやSITに応じて監査 |
| 印刷 | 機密資料の紙持ち出し | 高機密のみブロック、その他は正当化要求 |
Browser DLP は「AI利用を禁止するための仕組み」ではなく、業務を止めずに危険なデータ移動だけを制御するための仕組みとして設計するのが現実的です。
Insider Risk Management は DLP のアラートを文脈化する
Insider Risk Management は、単発のDLP違反を「ユーザー行動の文脈」で捉えるための機能です。
たとえば、1回だけ外部送信を試みたユーザーと、退職前に大量のファイルをダウンロードし、USB保存を試み、個人メールへの送信も行ったユーザーでは、リスクの意味が違います。DLPだけではイベント単位の判断になりがちですが、Insider Risk Management を組み合わせることで、複数のシグナルを相関させた調査が可能になります。
参照アーキテクチャ図では、Insider Risk Management がユーザーアクティビティ、DLP、監査ログ、Communication Compliance、Defender、サードパーティソースなどのシグナルを取り込み、ポリシーとしきい値に基づいてアラートを生成し、ケース管理で調査・エスカレーション・確認・却下を行う流れが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learn でも、Insider Risk Management は IP 盗難、データ漏えい、セキュリティ違反などの潜在的な内部リスクを識別するために複数のシグナルを相関し、プライバシー保護の観点から既定でユーザーが仮名化され、ロールベースのアクセス制御や監査ログが用意されていると説明されています。(Microsoft Learn)
DLP と Insider Risk を連携させる判断基準
| 判断項目 | DLPだけで見る場合 | Insider Risk と組み合わせる場合 |
|---|---|---|
| 外部送信 | 送信先と内容で判定 | 退職、異常な大量アクセス、過去行動と合わせて判断 |
| USB保存 | ファイル単位で警告・ブロック | 短期間の大量保存や他行動との組み合わせを評価 |
| ラベル引き下げ | 操作イベントとして記録 | 意図的な共有準備の兆候として評価 |
| Copilot利用 | プロンプトや応答の監査 | 高リスクユーザーのAI利用行動も含めて確認 |
特に Adaptive Protection を使う場合、Insider Risk のリスクレベルに応じて DLP などの制御を動的に強める設計が可能です。Microsoft Learn では、Adaptive Protection が機械学習を使って重要なリスクを特定し、DLP、Data Lifecycle Management、Conditional Access の保護制御を動的に適用できると説明されています。(Microsoft Learn)
ただし、内部不正対策は監視の強化だけで進めると従業員の不信感を招きます。法務、人事、労務、プライバシー担当を含め、調査権限、閲覧権限、通知方針、保存期間を事前に決めておくことが重要です。
Microsoft 365 Copilot 展開ではラベルとDLPの設計品質がそのまま表れる
Microsoft 365 Copilot を導入すると、既存のアクセス権、SharePoint の共有状態、秘密度ラベル、DLP設計の弱点が表面化しやすくなります。
Copilot 自体が既存の権限を無視してデータを読むわけではありません。しかし、ユーザーがアクセスできる範囲が広すぎる場合、Copilot によって「見つけやすくなる」ことがあります。そのため、Copilot 展開前には、Purview のラベル、DLP、監査、保持、eDiscovery、SharePoint の過剰共有対策をセットで確認する必要があります。
Microsoft Learn では、Microsoft 365 Copilot は Microsoft 365 サービス境界内で動作し、Microsoft 365 全体に適用されるデータ保護、アクセス制御、コンプライアンス機能を尊重すると説明されています。また、Copilot は Purview の秘密度ラベルと暗号化と連携し、ユーザーが許可されたコンテンツのみを要約・参照できること、暗号化されたコンテンツでは適切な利用権限が必要になることが示されています。(Microsoft Learn)
Copilot 展開前に確認すべき Purview 観点
| 確認項目 | 見落とした場合のリスク |
|---|---|
| SharePoint / OneDrive の過剰共有 | Copilot が本来見せたくない情報を発見しやすくなる |
| 秘密度ラベルの未整備 | Copilot 生成物に適切な保護が継承されにくい |
| DLP ポリシーの未調整 | AI応答やプロンプト経由の機密情報露出を検知しにくい |
| 監査・保持の未設計 | Copilot 利用後の調査や証跡確認が難しくなる |
| ユーザー教育不足 | 機密情報をプロンプトに入力してしまう |
今回の参照アーキテクチャ図では、Copilot に関する保護も複数の観点で整理されています。データ保護、過剰共有制御、監査と保持、Copilot向けDLPが分かれているため、Copilot 導入プロジェクトの設計レビュー資料として使いやすい構成です。(TECHCOMMUNITY.MICROSOFT.COM)
参照アーキテクチャ図を実装計画に落とし込む手順
参照アーキテクチャ図は、そのまま設定手順書として使うものではありません。重要なのは、図を見ながら自社の展開順序と責任分担に変換することです。
まずは保護対象データを3〜5種類に絞る
最初からすべての機密情報を対象にすると、設計が複雑になります。
初期展開では、次のように優先度の高いデータから始めるのが現実的です。
- 顧客個人情報
- クレジットカード情報や金融情報
- 契約書・見積書
- ソースコードや設計書
- 役員資料やM&A関連資料
各データについて、「誰が作るか」「どこに保存されるか」「誰と共有されるか」「どの経路で流出し得るか」を整理します。
次にラベルと分類条件を対応付ける
たとえば、契約書を「Confidential」とするなら、どの条件で契約書と判断するのかを決めます。
- ファイル名に「契約書」「NDA」「Agreement」が含まれる
- 契約書テンプレートに一致する
- 特定の部署のSharePointサイトに保存されている
- 取引先名、契約番号、署名欄などの組み合わせがある
ここで重要なのは、分類条件だけで完全判定しようとしないことです。自動分類、自動ラベル、ユーザーによる手動ラベル、既定ラベルを組み合わせ、業務に耐える精度に調整します。
DLP は「監査」から始めて「ブロック」に進める
DLP はいきなりブロックを有効にすると、想定外の業務停止を起こす可能性があります。
特にグローバル企業では、国・地域、部門、業務プロセスによってデータ共有の前提が違います。最初は監査モードで実態を確認し、誤検知、正当な共有、危険な共有を分けてから警告やブロックを適用します。
| 展開段階 | 実施内容 | 成功条件 |
|---|---|---|
| Discovery | Activity Explorer や監査ログで現状把握 | 主要な流出経路が見える |
| Pilot | 一部ユーザー・部門でラベルとDLPを試行 | 誤検知と業務影響を説明できる |
| Warning | 警告・ポリシーヒントを有効化 | ユーザーが自分で修正できる |
| Block | 高リスク操作をブロック | 例外申請と承認フローがある |
| Optimize | アラート、例外、しきい値を継続調整 | 運用負荷が管理可能な範囲に収まる |
Insider Risk は導入初期から関係者を巻き込む
Insider Risk Management は、技術部門だけで設計しない方がよい領域です。
理由は、検知対象がユーザー行動に関わるためです。セキュリティチームは「危険な行動を検知したい」と考えますが、人事・法務・コンプライアンス部門は「どの条件で調査してよいのか」「誰が閲覧できるのか」「本人通知は必要か」を重視します。
設計時には、少なくとも次を決めておきます。
- 調査ケースを作成できる担当者
- ユーザー名の表示を解除できる権限者
- アラートの確認期限
- 誤検知時の却下理由
- 人事・法務へエスカレーションする基準
- 監査ログとケース情報の保存期間
参照アーキテクチャ図は、技術的な信号の流れを説明するだけでなく、こうした非技術部門との合意形成にも使えます。
設計レビューで使えるチェックリスト
Purview architects や Microsoft 365 security teams が今回の参照アーキテクチャ図を活用するなら、設計レビューでは次の観点を確認すると実務に落とし込みやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| 分類 | SIT、EDM、フィンガープリント、トレーニング可能な分類子の使い分けが決まっているか |
| ラベル | ラベル数、優先順位、適用範囲、ユーザー説明が整理されているか |
| DLP | Endpoint、Exchange、SharePoint、Browser、Copilot の評価地点が明確か |
| ログ | Activity Explorer、監査ログ、アラート、ケース管理の確認担当が決まっているか |
| 例外 | 業務上必要な共有や持ち出しの承認フローがあるか |
| Copilot | 既存のアクセス権、過剰共有、ラベル継承、DLP、監査を確認したか |
| グローバル展開 | 地域ごとの法規制、言語、業務プロセス、データ所在を考慮したか |
| 教育 | ラベル選択、ポリシーヒント、ブロック時の対応をユーザーに説明できるか |
このチェックリストで「未定」が多い場合は、まだポリシーを本番ブロックに進める段階ではありません。まずは監査、パイロット、部門限定展開でデータを集めるべきです。
参照アーキテクチャ図をSEO・ナレッジ整備にも活用する
今回の Purview 参照アーキテクチャ図は、実装チームだけでなく、社内ナレッジや公開コンテンツの整備にも価値があります。
Microsoft Purview は機能名が多く、検索ユーザーの意図も分散しがちです。たとえば、同じDLPに関する検索でも、ユーザーは次のような異なる課題を持っています。
- Microsoft Purview DLP の設計方法を知りたい
- Endpoint DLP と Exchange DLP の違いを知りたい
- 秘密度ラベルと DLP の関係を整理したい
- Copilot 利用時の情報漏えい対策を知りたい
- Insider Risk Management と DLP の連携を理解したい
参照アーキテクチャ図は、こうした検索意図を「ワークフロー別」に整理する土台になります。ITメディアや社内ポータルで扱う場合も、単に新機能として紹介するより、「分類からDLP、Insider Risk、Copilotまでの設計順序」として解説した方が読者の行動につながります。
特にグローバル読者向けには、製品機能の説明だけでなく、次の観点を入れると実務性が高まります。
- 地域ごとのコンプライアンス要件に合わせて分類条件を調整する
- 部門ごとにラベル公開範囲を分ける
- 監査モードで国・地域別の業務影響を比較する
- DLP のブロック条件は一律ではなく、ユーザーリスクやデータ種別で変える
- Copilot 展開前に SharePoint の過剰共有を棚卸しする
検索流入を狙うだけなら機能名を並べることもできます。しかし、Purview の設計担当者が本当に求めているのは、「どの順番で何を決めればよいか」です。今回の参照アーキテクチャ図は、その設計検索ニーズに直接応えられる資料です。
Microsoft Purview 展開で避けたい失敗
最後に、今回の更新を踏まえて、Purview 展開で避けたい失敗を整理します。
ラベルだけ先に作ってDLPとつながっていない
秘密度ラベルは作ったが、DLP の条件やアクションと連動していないケースです。
この状態では、ユーザーがラベルを付けても保護効果が限定的になります。ラベルは「表示上の分類」ではなく、暗号化、外部共有制御、DLP、Copilot保護につながる前提で設計します。
DLP をブロック中心で始めてしまう
DLP は強力ですが、誤検知や業務影響が出やすい機能です。
最初は監査と警告を中心にして、実際のアクティビティを確認する方が安全です。特に営業、サポート、法務、開発部門では、外部共有やファイルアップロードが正当な業務である場合も多いため、現場確認なしのブロックは避けるべきです。
Endpoint と Browser のリスクを後回しにする
クラウド上のメールやファイル共有だけを見ていると、USB、印刷、クリップボード、未承認AIサービスへの貼り付けといった流出経路を見落とします。
生成AI利用が広がるほど、Browser DLP と Endpoint DLP の重要性は高まります。Microsoft 365 Copilot を導入している組織でも、外部のAIサービスや個人ブラウザ利用のリスクは別途確認が必要です。
Insider Risk をアラート機能としてだけ見る
Insider Risk Management は、アラートを増やすための機能ではありません。ユーザー行動の文脈を見て、調査すべきリスクを絞り込むための仕組みです。
DLP アラートが多すぎる場合こそ、Insider Risk や Adaptive Protection を組み合わせ、リスクの高いユーザーや行動に制御を集中させる設計が有効です。
まず何から始めるべきか
Microsoft Purview の新しい参照アーキテクチャ図は、分類、秘密度ラベル、DLP、Insider Risk、Copilot保護を別々の機能ではなく、1つのデータ保護ワークフローとして理解するための重要な資料です。
これから展開する組織は、まず次の順番で進めると失敗しにくくなります。
- 保護対象データを3〜5種類に絞る
- 分類条件と秘密度ラベルを対応付ける
- Endpoint、Exchange、SharePoint、Browser、Copilot の流出経路を洗い出す
- DLP は監査モードから開始する
- Insider Risk Management と Adaptive Protection の利用範囲を決める
- Copilot 展開前に過剰共有、ラベル、DLP、監査を確認する
Purview の設計では、個々の機能を早く有効化することよりも、データの流れに沿って「どこで検知し、どこで判断し、どこで止め、どこで調査するか」を揃えることが重要です。今回の参照アーキテクチャ図は、その共通認識を作るための出発点として活用できます。
コメント