Microsoft Purview Endpoint DLPを使っている組織で、Copilot+ PCのRecallを許可するか検討している場合、今回の更新で最初に見るべきポイントは「Recallを一律に禁止するか」ではなく、「機密情報が表示されたウィンドウをRecallスナップショットに残さないポリシーを作れているか」です。2026年5月16日更新相当のMicrosoft 365ロードマップ項目では、Microsoft Purview Endpoint Data Loss PreventionがCopilot+ PCに保護範囲を広げ、Recallスナップショットで制限付き秘密度ラベルやSensitive Information Types（SITs）を含むウィンドウのキャプチャを防ぐためのカスタムポリシーに対応することが示されています。(Microsoft)
管理者がすぐに行うべきことは、Copilot+ PCの導入有無を棚卸しし、Endpoint DLPのオンボード状況、Recallを許可するIntune設定、Microsoft Purview側のDLPカスタムポリシーをセットで確認することです。特に、Recallは管理対象デバイスでは既定で無効または削除され、管理者が保存を強制開始することはできません。ユーザーの明示的なオプトインが必要です。(Microsoft Learn)
Microsoft Purview Endpoint DLPの今回の変更点
今回の更新は、Microsoft Purview compliance portalのEndpoint Data Loss Preventionに、Copilot+ PCのRecallスナップショット向け保護を追加するものです。ロードマップIDは502519で、製品はMicrosoft Purview、クラウドインスタンスはWorldwide、リリースリングはPreviewとGeneral Availabilityです。公式ロードマップAPIでは、プレビューは2025年11月、一般提供は2026年4月、ステータスはLaunched、更新日時は2026年5月15日22:00 UTCとされています。日本時間では2026年5月16日更新相当です。(Microsoft)
これまでのEndpoint DLPは、主にファイルのコピー、印刷、USBへの移動、ネットワーク共有へのコピー、制限付きクラウドサービスへのアップロードなど、エンドポイント上のデータ持ち出し操作を監査・制御する用途が中心でした。Endpoint DLPでは、オンボード済みのWindows 10/11、macOS、対応するWindows Server上で、機密アイテムの利用状況をActivity Explorerに可視化し、DLPポリシーで保護アクションを適用できます。(Microsoft Learn)
今回のポイントは、保護対象が「ファイル操作」だけでなく、Copilot+ PCのRecallスナップショットに拡張されることです。つまり、機密ラベル付き文書、SITに一致する情報、機密性の高いTeamsチャットやメールなどが画面に表示されたときに、その内容をRecallの保存対象から除外する運用を設計しやすくなります。
RecallスナップショットとDLPの関係
Recallは、Copilot+ PC上で画面のスナップショットをローカルに保存・解析し、自然言語で過去に見た内容を探せるようにする機能です。Microsoftの説明では、スナップショットの保存と解析はローカルデバイス上で行われ、Microsoftに送信されません。また、利用にはWindows Helloによる本人確認が必要で、スナップショットや関連情報は暗号化されます。(Microsoft Learn)
ただし、ローカル保存だから安全と単純に判断してはいけません。業務PCの画面には、顧客情報、契約情報、人事情報、未公開の財務情報、ソースコード、アクセスキーなどが表示されます。これらがRecallのタイムラインに残ると、端末紛失、誤操作、内部不正、共有PC利用時のトラブルにつながる可能性があります。
Microsoft Purview DLP連携では、Recallがキャプチャを行う前にDLPプロバイダーへ問い合わせ、プロセス、ウィンドウ、ファイル、ラベルなどのコンテキストをもとに「保存してよいか」を判断します。Recall側は返された制御結果に基づき、許可、監査、警告、ブロックなどを適用します。(Microsoft Learn)
特に重要なのは、DLPの適用がウィンドウ単位で行われる点です。Microsoft Learnでは、DLPプロバイダーが機密データを含むと判断した特定のウィンドウだけをRecallスナップショットから除外し、その他の部分は保持できると説明されています。(Microsoft Learn)
影響を受ける範囲
今回の更新で影響を受けるのは、単にMicrosoft Purview管理者だけではありません。Recallを有効化するにはWindows、Intune、Endpoint DLP、秘密度ラベル、業務アプリの実装が関係するため、複数チームで確認が必要です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Purview管理者 | Endpoint DLPポリシーにRecall向け制御を追加するか。対象ラベルやSITをどう定義するか |
| Intune/Windows管理者 | Copilot+ PCでRecallを許可するか。Windows AIポリシー、保存期間、ストレージ、DLPプロバイダー設定をどう配布するか |
| セキュリティ・コンプライアンス担当 | Recallに残してはいけない情報の基準を決める。監査ログとインシデント対応フローを整える |
| 開発者 | 自社アプリが秘密度ラベル情報をRecallへ渡せるか。キャプチャ除外が必要な画面がないか |
| ヘルプデスク | ユーザーからの「Recallが記録しない」「一部ウィンドウが保存されない」問い合わせに対応できるか |
Recall向けDLP保護を使うには、Endpoint DLPがテナントで有効化され、対象のCopilot+ PCがEndpoint DLPにオンボードされている必要があります。さらに、IntuneでWindowsテナントポリシーを作成できること、対象PCが指定されたWindowsビルド、Anti-malware Client、Teams、Officeアプリ、Microsoft Edge for Businessなどの要件を満たすことも前提になります。(Microsoft Learn)
保護対象になるデータの具体例
Microsoft Learnでは、Recall向けDLP保護の対象として、秘密度ラベル付きTeamsチャネル、秘密度ラベル付きTeams会議チャット、Microsoft 365 Copilot AppのWeb版OfficeアプリでMicrosoft Edge for Businessから開いたSITまたは秘密度ラベル付きファイル、ラベル付きOutlookメール、ローカル保存ファイル、Officeアプリで開いたクラウド上のラベル付きまたはSITを含むファイルなどが挙げられています。(Microsoft Learn)
実務では、次のようなケースを優先的にポリシー化すると効果的です。
| 業務シーン | 想定される機密情報 | 推奨する初期対応 |
|---|---|---|
| 経理・財務 | 決算資料、売上予測、銀行口座情報、請求データ | 高い秘密度ラベルはBlockから開始 |
| 人事 | 評価情報、給与、異動、採用候補者情報 | SITと秘密度ラベルを組み合わせてBlock |
| 法務 | 契約書、訴訟関連資料、NDA対象情報 | 「社外秘」「極秘」ラベルをRecall除外対象にする |
| 開発 | ソースコード、APIキー、設計資料 | コード系SITや特定アプリの画面を監査対象にする |
| 営業 | 顧客リスト、提案書、価格表 | 初期はAudit onlyで実態を把握し、重要ラベルを段階的にBlock |
すべてを最初からBlockにすると、ユーザー体験に影響が出やすくなります。まずAudit onlyで実際にどの画面が検出されるかを把握し、誤検知や業務影響を確認したうえで、重要度の高いラベルやSITからBlockへ移行するのが現実的です。
管理者が確認すべき設定
Endpoint DLPが対象端末で有効になっているか
Endpoint DLPでは、対象デバイスをMicrosoft Purviewにオンボードして初めて、DLPセンサーのテレメトリを受け取り、ポリシーを適用できます。Windows 10/11デバイスをオンボードする場合は、クラウドDLPサービスと通信できるようにプロキシやネットワーク接続も確認する必要があります。(Microsoft Learn)
既にMicrosoft Defender for Endpointへオンボードしている環境では、デバイスがDLPのデバイス一覧に表示される場合があります。ただし、Endpoint DLPを使うにはデバイス監視を有効にする必要があります。(Microsoft Learn)
確認ポイントは次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| デバイス一覧 | Copilot+ PCがMicrosoft Purviewの管理対象として表示されているか |
| 通信要件 | プロキシやファイアウォールでDLPサービスへの通信が妨げられていないか |
| ライセンス | Endpoint DLPと必要なPurview機能を利用できる契約か |
| ポリシースコープ | 対象ユーザーと対象デバイスがポリシー範囲に入っているか |
| Activity Explorer | 端末イベントやDLP一致イベントが記録されているか |
Endpoint DLPのポリシースコープでは、ユーザーとデバイスの両方が対象に含まれていないとポリシーが適用されないプレビュー機能も説明されています。ユーザーだけ、またはデバイスだけを対象にしたつもりで運用すると、想定より保護範囲が狭くなる可能性があります。(Microsoft Learn)
Recallを許可するWindows AIポリシー
管理対象デバイスでは、Recallは既定で利用できません。組織でRecallを許可する場合は、少なくとも「Allow Recall to be enabled」と「Turn off saving snapshots for Recall」に関するポリシーを正しく設定する必要があります。(Microsoft Learn)
ここで失敗しやすいのが、設定名の読み違いです。「Turn off saving snapshots for Recall」は、名前の通りスナップショット保存をオフにするポリシーです。ユーザーにRecall保存の選択肢を与えるには、このポリシーを無効化する必要があります。Microsoft Learnでも、管理者はユーザーの代わりにスナップショット保存を有効化できず、保存にはユーザー本人のオプトインが必要だと説明されています。(Microsoft Learn)
DLPプロバイダー設定
RecallでMicrosoft PurviewをDLPプロバイダーとして使うには、Copilot+ PC側で「Set Data Loss Prevention Provider」を設定します。Microsoft Learnでは、Microsoft Purview Endpoint DLPを使う場合の値として、Windows Defender配下のendpointdlp.dllを指定する例が示されています。(Microsoft Learn)
この設定を配布しないと、Microsoft Purview側でDLPポリシーを作成しても、RecallがDLPプロバイダーへ問い合わせず、期待した制御が効かない可能性があります。Microsoft Learnでは、このポリシーを削除またはクリアするとRecallがDLPプロバイダーを呼び出さなくなり、以前保存されたスナップショットには影響しないと説明されています。(Microsoft Learn)
Microsoft PurviewでRecall向けDLPポリシーを作る手順
Recall向けのDLP保護は、新規DLPポリシーを作るか、既存のDLPポリシーを編集して追加します。Microsoft Learnでは、Enterprise Applications & devicesのポリシー編集フローで、Actions、Audit or restrict activities on devices、Restrictions in Windows Recall in Copilot+ PCs、Restrict content in Windows Recallの順に設定し、Audit onlyまたはBlockを選べると説明されています。(Microsoft Learn)
実務向けには、次の順序で進めると安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 対象端末を棚卸しする | Copilot+ PC、管理対象デバイス、BYODを分ける |
| 2 | 保護すべき情報を決める | 「極秘」「社外秘」などの秘密度ラベル、個人情報や金融情報などのSITを優先 |
| 3 | DLPポリシーをAudit onlyで作成する | まず検出範囲と誤検知を確認する |
| 4 | Activity Explorerでイベントを確認する | どのユーザー、端末、ラベル、SITで検出されているかを見る |
| 5 | 高リスク条件だけBlockへ変更する | 経営情報、人事情報、法務情報、認証情報などから適用 |
| 6 | IntuneでRecallとDLPプロバイダー設定を配布する | 検証グループから段階展開する |
| 7 | ヘルプデスク向けFAQを用意する | Recallに保存されない理由、ユーザー通知、業務影響を説明できるようにする |
Audit onlyを選ぶと、機密情報を含むスナップショットが取得されてもユーザー通知は出ず、イベントがDLPレポートに記録されます。一方、Blockを選ぶと、機密情報を含む内容はスナップショットに含まれません。(Microsoft Learn)
Audit onlyとBlockの使い分け
Recall向けDLPポリシーでは、いきなり全社Blockにするよりも、段階的に適用する方が失敗しにくくなります。
| モード | 向いている場面 | メリット | 注意点 |
|---|---|---|---|
| Audit only | 初期検証、影響調査、誤検知確認 | ユーザー業務を止めずに実態を把握できる | 機密情報の保存自体は防げない |
| Block | 高リスク情報、本番運用、明確に保存禁止のデータ | Recallスナップショットへの残存を抑制できる | ユーザーから「Recallで見つからない」と問い合わせが増える可能性がある |
おすすめは、まず限定グループでAudit onlyを2〜4週間運用し、Activity Explorerで検出傾向を確認することです。人事、経理、法務、役員部門などリスクの高い部門では、特定ラベルや特定SITに限定してBlockを先行適用してもよいでしょう。
展開時に注意すべき落とし穴
既存のEndpoint DLPポリシーだけではRecall対策にならない可能性がある
USBコピーや印刷をブロックするEndpoint DLPポリシーがあっても、それだけでRecallスナップショットへの保存制御まで完了したとは限りません。Recall向けには、Windows Recall in Copilot+ PCsの制限設定を明示的に確認する必要があります。
特に「機密ファイルの持ち出しはブロックしているが、同じファイルを画面に表示した状態のRecall保存は未確認」という状態は見落とされやすいです。DLPポリシーを棚卸しするときは、操作ベースの制御と画面キャプチャベースの制御を分けて確認してください。
ポリシー同期には時間差がある
Endpoint DLPのポリシー更新は、Microsoft Purview側で更新してすぐに全端末へ反映されるわけではありません。Microsoft Learnでは、ポリシー更新は通常約1時間でサービス全体に同期され、対象デバイス上のアイテムは次回アクセスまたは変更時に再評価されると説明されています。(Microsoft Learn)
また、デバイスがオフラインの場合、新しいポリシーは反映されません。オフライン中は、端末に残っている古いポリシーが引き続き適用される点にも注意が必要です。(Microsoft Learn)
アプリ・Webサイトフィルターには限界がある
Recallでは、特定のアプリやWebサイトをスナップショット対象から除外できます。ただし、Webサイトフィルターは前面または現在開いているタブに対して機能し、埋め込みコンテンツ、ブラウザー履歴、前面ではないタブなどの一部がスナップショットに現れる可能性があると説明されています。また、フィルターはWebサイトにアクセスした事実や履歴の生成を防ぐものではありません。(Microsoft Learn)
つまり、アプリ・URLフィルターだけに依存するのは不十分です。機密データは秘密度ラベルやSITで検出できるようにし、必要に応じてDLPポリシー、アプリ除外、ブラウザー制御を組み合わせるべきです。
BYODは別枠で考える
管理対象デバイスでは、IT管理者がRecallの利用可否を制御できます。一方、未管理のCopilot+ PCではRecallが利用可能で、ユーザーがオプトインすれば保存を有効にできます。Microsoft Learnでは、未管理デバイスに対してRecallを条件にした組み込みのIntuneまたはMicrosoft Entraの条件付きアクセスポリシーは現時点でないと説明されています。(Microsoft Learn)
そのため、BYODで社内データへアクセスさせる組織では、Recallだけでなく、端末管理、条件付きアクセス、ブラウザー制御、ダウンロード制御、仮想デスクトップ利用などを含めて設計する必要があります。
以前のスナップショットは自動的に「なかったこと」にはならない
DLPポリシーを追加しても、過去に保存済みのRecallスナップショットが自動的にすべて再評価・削除されるとは考えない方が安全です。Microsoft Learnでは、DLPプロバイダー設定を削除またはクリアしても、以前保存されたスナップショットには影響しないと説明されています。(Microsoft Learn)
一方で、Recall自体を無効化するポリシーでは、以前保存されたスナップショットが削除される説明もあります。運用上は、「Recallを許可する前にDLPを整える」ことが最も重要です。後追いでポリシーを入れるより、導入前の設計でリスクを下げてください。
Activity Explorerで確認するべきログ
Recall向けDLP保護を展開したら、Activity Explorerで検出状況を確認します。Activity Explorerはラベル付きコンテンツのアクティビティ履歴を確認できる機能で、最大30日分のデータをレポートします。フィルターには日付範囲、アクティビティタイプ、場所、秘密度ラベル、ユーザー、クライアントIP、デバイス名、保護状態などがあります。(Microsoft Learn)
確認時は、次の観点で見ると改善点が見つかりやすくなります。
| 観点 | 見るべきサイン | 次のアクション |
|---|---|---|
| ラベル別 | 特定ラベルで検出が多い | そのラベルをBlock対象にするか検討 |
| ユーザー別 | 一部ユーザーで検出が集中 | 業務内容か誤操作かを確認 |
| デバイス別 | 特定PCだけイベントが出ない | Endpoint DLPオンボード、Intune設定、通信要件を確認 |
| アプリ別 | 想定外のアプリで機密情報が表示 | アプリ除外、ラベル付け、業務フロー見直し |
| 誤検知 | 一般情報が機密として検出 | SIT条件、しきい値、例外条件を調整 |
Activity ExplorerにはEndpoint DLP activitiesなどのフィルターセットも用意されています。初期検証では、Recall関連イベントだけでなく、USB、印刷、コピー、ネットワーク共有、制限付きアプリなどのエンドポイント操作と合わせて確認すると、ユーザーのデータ利用パターンを把握しやすくなります。(Microsoft Learn)
開発者が確認すべきポイント
自社アプリが秘密度ラベル情報をRecallへ渡せるか
開発者にとって重要なのは、アプリ側が保持しているコンテンツの機密状態をRecallへ正しく伝えられるかです。Microsoft Learnでは、Windows RecallがUserActivity.ContentInfoで提供されたJSONメタデータを評価し、DLPポリシーのもとでウィンドウをキャプチャするか、どう分類するかを判断すると説明されています。(Microsoft Learn)
アプリは、次のタイミングでUserActivityを送信または更新することが推奨されています。
| タイミング | 理由 |
|---|---|
| アクティブな文書やアイテムが変わったとき | 前の文書のラベル情報が残るのを防ぐ |
| 秘密度ラベルが追加・削除・変更されたとき | DLP判断を最新状態にする |
| 機密状態が未判定から確定に変わったとき | 未判定のまま不要にブロックされるのを防ぐ |
| アプリ起動時 | ベースラインの状態をRecallへ伝える |
UserActivity.ContentInfoでは、コンテンツ状態を「Sensitive」「Non-sensitive」「Undetermined」の3つで扱えます。Microsoft Learnでは、機密の場合はinformationProtectionオブジェクトとlabels配列を含め、非機密の場合はinformationProtectionを省略し、未判定の場合はinformationProtection.state = "undetermined"を指定すると説明されています。未判定では、状態が解決されるまでRecallのキャプチャがブロックされます。(Microsoft Learn)
業務アプリでは、ラベル判定が遅れる画面や、読み込み直後に機密情報が表示される画面で未判定状態を適切に使うと、漏えいリスクを下げられます。
キャプチャ除外が必要な画面を洗い出す
DLPラベル連携だけではなく、アプリ側で画面キャプチャ自体を除外すべきケースもあります。Microsoft Learnでは、リモートデスクトップ接続クライアントがスクリーンキャプチャ保護を実装していない場合、WindowsのSetWindowDisplayAffinityを使ってウィンドウをスクリーンショットから除外でき、WDA_EXCLUDEFROMCAPTUREを設定するとRecallや他のスクリーンショットアプリにウィンドウ内容が表示されないと説明されています。(Microsoft Learn)
Win32 APIのドキュメントでも、WDA_EXCLUDEFROMCAPTUREはウィンドウがモニター上には表示される一方で、それ以外の場所には表示されない設定として説明されています。(Microsoft Learn)
特に次の画面は、アプリ開発側でキャプチャ除外を検討する価値があります。
| 画面 | 理由 |
|---|---|
| APIキーやトークン表示画面 | 一度表示されるだけで重大な漏えいにつながる |
| 管理者用の個人情報検索画面 | 大量の顧客情報や従業員情報が表示されやすい |
| 決済・金融情報画面 | 口座番号、カード情報、送金情報が含まれる可能性がある |
| リモートデスクトップ・仮想デスクトップ画面 | 別環境の機密データがローカルPCのRecallに残る恐れがある |
| 監視・運用ダッシュボード | 内部IP、ホスト名、障害情報、セキュリティアラートが表示される |
独自DLPプロバイダーを作る場合の注意
Microsoft Purviewは現時点でRecall向けのサポート対象DLPプロバイダーとして説明されていますが、Microsoft Learnでは、他のDLPプロバイダーが同様の統合を作るための公開APIも用意されていると説明されています。(Microsoft Learn)
Recall DLP Provider APIでは、DLPプロバイダーDLLがEnterpriseContextProvider_QueryEnterpriseContextとEnterpriseContextProvider_FlushEnterpriseContextをエクスポートし、Recallからの問い合わせに対してキャプチャ制御やラベル情報を返す構成が示されています。実装時は、バッチ処理、キャッシュ、非同期処理、エラーハンドリング、入力検証、デジタル署名、レジストリ保護などが重要です。(Microsoft Learn)
特に、DLLはAIContext.exeプロセス内で読み込まれるため、メモリ管理や入力検証の不備はユーザー体験だけでなくセキュリティにも影響します。独自プロバイダーを作る場合は、パフォーマンスよりもまず安全側の既定動作、署名、改ざん防止、ログ設計を優先してください。
導入判断の基準
Recallを全面禁止するか、DLPで制御しながら許可するかは、組織のデータリスクと業務価値のバランスで判断します。
| 判断軸 | Recallを許可しやすい条件 | 禁止または限定導入が向く条件 |
|---|---|---|
| データ分類 | 秘密度ラベルとSITが整備されている | ラベル運用が未整備で、機密情報の所在が分からない |
| 端末管理 | Copilot+ PCがIntuneで管理されている | BYODや未管理端末から業務データへアクセスしている |
| 業務価値 | 過去作業の検索やナレッジ再利用の効果が高い | 表示される情報の多くが規制対象または高度機密 |
| 監査体制 | Activity ExplorerやDLPアラートの確認フローがある | 検出後の対応者やルール調整の責任者が未定 |
| 開発体制 | 自社アプリでラベル連携やキャプチャ除外を実装できる | 独自アプリに機密画面が多いが改修予定がない |
判断に迷う場合は、全社展開ではなく「管理対象Copilot+ PC」「特定部門」「Audit only」「高リスクラベルのみBlock」の組み合わせから始めるのが安全です。
実務で使える展開プラン
検証フェーズ
まず、セキュリティ部門、情シス、法務、人事、経理など、機密データの扱いが多い代表ユーザーを含めた小規模グループを作ります。対象端末はIntune管理下のCopilot+ PCに限定し、Endpoint DLPオンボードとDLPプロバイダー設定を確認します。
この段階では、Microsoft Purview側のRecall向けDLP制御をAudit onlyにします。目的はブロックではなく、どの情報がRecall保存対象になり得るかを把握することです。
パイロットフェーズ
Activity Explorerで2〜4週間のイベントを確認し、次の分類に分けます。
| 分類 | 例 | 対応 |
|---|---|---|
| 明確にブロックすべき | 人事評価、決算前資料、APIキー | Blockへ変更 |
| 監査で十分 | 一般的な社内資料、公開予定の提案資料 | Audit only継続 |
| 誤検知 | 一般文書が過剰に検出される | SITやルール条件を調整 |
| アプリ側対応が必要 | 独自アプリの管理画面 | ラベル連携またはキャプチャ除外を検討 |
この時点で、ユーザー向け説明も用意します。「Recallに一部画面が残らないのは不具合ではなく、組織のDLPポリシーによる保護である」と伝えることが重要です。
本番展開フェーズ
本番展開では、部門や端末グループごとに段階展開します。いきなり全社に適用すると、ヘルプデスク対応や誤検知調整が追いつかない可能性があります。
おすすめの順序は次の通りです。
| 順序 | 対象 | 方針 |
|---|---|---|
| 1 | IT・セキュリティ部門 | Audit onlyとBlockの動作確認 |
| 2 | 人事・経理・法務 | 高リスクラベルをBlock |
| 3 | 営業・企画 | 重要ラベルのみBlock、その他はAudit |
| 4 | 全社管理対象Copilot+ PC | ポリシーを標準化 |
| 5 | 例外端末・特殊業務 | 個別にアプリ除外や追加ルールを設計 |
よくある質問
Recallを有効にすると、Microsoftに画面データが送られますか
Microsoftの説明では、Recallのスナップショット保存と解析はローカルPC上で行われ、Microsoftに送信されません。スナップショットはローカルに保存され、暗号化されます。(Microsoft Learn)
ただし、ローカル保存でもリスクは残ります。端末の管理状態、ユーザー権限、端末紛失、内部不正、画面共有、バックアップなどを含めて対策してください。
管理者がユーザーの代わりにRecall保存を開始できますか
できません。Microsoft Learnでは、IT管理者はユーザーにスナップショット保存の選択肢を与えるポリシーを設定できますが、管理者がエンドユーザーの代わりに保存を開始することはできないと説明されています。保存にはユーザー本人のオプトインが必要です。(Microsoft Learn)
既存の秘密度ラベルをそのまま使えば十分ですか
既存ラベルが業務リスクを正しく表しているなら有効です。ただし、ラベルが粗すぎる場合はRecall向け制御に向きません。たとえば「社内用」ラベルに一般資料と人事情報が混在していると、Blockにすると業務影響が大きく、Audit onlyにするとリスクが残ります。
Recall向けには、少なくとも「Recallに残してよい情報」と「残してはいけない情報」を区別できるラベル設計が必要です。
他テナントの秘密度ラベル付き文書も検出できますか
Endpoint DLPのドキュメントでは、別テナントのドキュメントに付与された秘密度ラベルは検出できないと説明されています。(Microsoft Learn)
取引先やグループ会社のテナントでラベル付けされた文書を扱う場合は、SITやアプリ制御、URL・アプリフィルターなど別の制御も組み合わせるべきです。
仮想デスクトップやリモートデスクトップではどう考えるべきですか
Microsoft Learnでは、一部のリモートデスクトップ接続クライアントはRecallスナップショットからフィルターされると説明されています。ただし、クライアントがスクリーンキャプチャ保護を実装していない場合は保存される可能性があり、必要に応じて特定アプリのフィルターやスクリーンキャプチャ保護を確認する必要があります。(Microsoft Learn)
Azure Virtual DesktopやWindows 365などを使って機密データを分離している組織では、ローカルPCのRecallに仮想環境の画面が残らないかを必ず検証してください。
まとめ：Recallを許可する前にDLPポリシーを整える
今回のMicrosoft Purview Endpoint DLP更新は、Copilot+ PCのRecallを業務利用するうえで重要なセキュリティ強化です。ポイントは、Recallを単にオン・オフで考えるのではなく、秘密度ラベルやSITに基づいて「残してはいけない画面」を制御できるようにすることです。
管理者は、次の順で対応してください。
| 優先度 | 対応 |
|---|---|
| 高 | Copilot+ PCの導入状況とIntune管理状態を確認する |
| 高 | Endpoint DLPのオンボード、ライセンス、デバイス監視を確認する |
| 高 | Recall向けDLPポリシーをAudit onlyで作成し、検出状況を確認する |
| 高 | 高リスクの秘密度ラベルやSITをBlock対象にする |
| 中 | Activity Explorerで30日以内のイベントを継続監視する |
| 中 | ユーザー向けにRecallとDLP制御の説明を用意する |
| 中 | 自社アプリのラベル連携やキャプチャ除外を開発チームと確認する |
Copilot+ PCとRecallは、業務効率を高める一方で、画面に表示された情報をどう扱うかという新しい管理課題を生みます。Microsoft Purview Endpoint DLPを使って、導入前に「何を保存させないか」を定義し、監査からブロックへ段階的に移行することが、現実的で失敗しにくい展開方法です。
コメント