Microsoft PurviewのEndpoint DLPで、DLPポリシーの「file extension condition」に指定する拡張子が、従来の自由入力から、事前に用意された拡張子リストから選ぶ方式へ変わります。結論から言うと、管理者は2026年7月の一般提供予定までに、既存ポリシーで手入力している拡張子を棚卸しし、サポート対象外またはスキャンできない拡張子を「File extension is」条件に混ぜていないか確認すべきです。今回の変更は、保護漏れを減らし、エンドポイント側の不要な処理負荷を抑えるためのアップデートです。(Microsoft)
Microsoft 365 Roadmapの情報では、この機能はRoadmap ID 562993として公開され、ステータスは「In development」、対象サービスはMicrosoft Purview、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）、一般提供は2026年7月予定とされています。ロードマップ上の作成・更新時刻は2026年5月27日 23:15:50 UTCで、日本時間では2026年5月28日にあたります。(Microsoft)
Microsoft Purview Endpoint DLPの拡張子条件は何が変わるのか
今回の変更点は、Endpoint DLPのポリシー条件で使う「ファイル拡張子」の指定方法です。
これまでは、管理者が拡張子を自由入力できました。自由入力は柔軟な一方で、Endpoint DLPがサポートしていない拡張子や、コンテンツスキャンに適さない拡張子まで指定できてしまう問題がありました。その結果、想定した検査が行われず保護に穴ができたり、エンドポイントで不要な処理が発生したりする可能性がありました。
今回のアップデート後は、Microsoftが事前に用意した拡張子リストから選択する形になります。つまり、管理者は「Endpoint DLPが扱える拡張子」を選びやすくなり、ポリシーの信頼性と運用しやすさが上がります。(Microsoft)
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 拡張子の指定方法 | 自由入力 | 事前に用意されたリストから選択 |
| 主なリスク | サポート外・非スキャン対象の拡張子を指定しやすい | 選択肢が整理され、誤設定を減らしやすい |
| エンドポイント負荷 | 不要なスキャン処理が発生する可能性 | 不要な処理を抑えやすい |
| 管理者の作業 | 拡張子の妥当性を個別に判断 | リストを基準に判断しやすい |
| 影響を受ける箇所 | Endpoint DLPポリシーの拡張子条件 | Microsoft Purviewポータル上のポリシー設定 |
重要なのは、この変更が「すべてのファイルを自動的に保護できるようになる」という意味ではない点です。あくまで、Endpoint DLPの「File extension is」条件で指定できる拡張子を、サポートしやすい形に整理する変更です。
対象になる管理者・開発者
この変更の影響を受けやすいのは、次のような担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Purview管理者 | DLPポリシーで拡張子条件を使っているか |
| セキュリティ・コンプライアンス担当者 | 既存ルールが実際に検査・ブロックできているか |
| Intune・端末管理者 | 対象デバイスがEndpoint DLPにオンボードされているか |
| SOC・監査担当者 | アラートやActivity explorerで想定どおり記録されているか |
| 業務アプリ開発者 | 独自拡張子のファイルに機密情報を書き出していないか |
| 情シス・ヘルプデスク | ユーザー通知やブロック時の問い合わせ対応を準備しているか |
Endpoint DLPは、Microsoft Purview DLPの一部として、オンボード済みのWindows 10、Windows 11、macOSデバイス上で機密アイテムの利用や共有を検出する機能です。対象端末がオンボードされていない場合、ポリシーを整えても端末上のファイル操作を期待どおりに監視できません。(Microsoft Learn)
まず確認すべき既存ポリシー
管理者が最初に行うべき作業は、既存のDLPポリシーの棚卸しです。特に、Devicesを対象にしたEndpoint DLPポリシーで「File extension is」またはそれに相当する拡張子条件を使っているルールを確認します。
確認時は、単に拡張子の一覧を見るだけでは不十分です。次の情報をセットで整理してください。
| 確認項目 | 見るべきポイント |
|---|---|
| ポリシー名・ルール名 | どの業務・規制要件のためのルールか |
| 対象ユーザー・グループ | 全社適用か、特定部門のみか |
| 対象デバイス | Windows、macOS、VDIなどの範囲 |
| 指定している拡張子 | Office、PDF、CSV、画像、独自拡張子など |
| 条件の組み合わせ | 機密情報の種類、ラベル、ファイルサイズなど |
| アクション | 監査のみ、通知、ブロック、上書き許可付きブロック |
| 例外設定 | 除外ユーザー、除外アプリ、除外拡張子 |
| アラート運用 | 誰が確認し、どの基準で対応するか |
特に注意したいのは、独自拡張子や業務アプリ固有の拡張子です。たとえば、社内システムが顧客情報を.custのような独自形式で出力している場合、その拡張子を「File extension is」条件に入れていても、Endpoint DLPが内容を正しくスキャンできるとは限りません。今回の変更後、事前定義リストに含まれない拡張子は選択できない、または従来どおりの設定方法では扱えない可能性があります。
「File extension is」と「スキャンできないファイル対策」は分けて考える
Endpoint DLPの拡張子関連設定で混同しやすいのが、「File extension is」条件と「Document could not be scanned」を使った制御です。
Microsoft Learnでは、「File extension is」条件ではEndpoint DLPがコンテンツをスキャンし、イベントやアラートで機密情報の種類を確認できる一方、スキャンできないファイルに対する制御ではファイル内容をスキャンしないと説明されています。また、「File extension is」条件によるコンテンツスキャンは、ファイル種類によってCPUやメモリなどの端末リソースを多く使う可能性があります。(Microsoft Learn)
| 目的 | 使うべき考え方 | 注意点 |
|---|---|---|
| 対応ファイルの内容を検査したい | File extension is条件と機密情報条件を使う | サポート対象の拡張子か確認する |
| スキャンできないファイルの持ち出しを止めたい | Document could not be scannedと未対応拡張子向け制御を使う | 機密情報の種類までは判定できない |
| 既知の無害な独自拡張子を除外したい | Unsupported file extension exclusionsを使う | 除外しすぎると保護範囲が狭くなる |
| 特定拡張子だけにアクションを割り当てたい | File extension groupsを使う | 拡張子入力時にドットを付けない |
つまり、拡張子がリストにない場合に「保護できない」と考えるのではなく、「内容をスキャンして機密情報を判定する対象なのか」「内容は見ずに持ち出し操作を制御する対象なのか」を分けて設計することが重要です。
管理者が実施すべき準備手順
既存の拡張子指定を棚卸しする
Microsoft Purviewポータルで、Endpoint DLPに関連するポリシーを確認します。対象は、Data Loss Preventionのポリシーで「Enterprise applications & devices」や「Devices」をスコープにしているルールです。
特に次のような拡張子が含まれていないか確認してください。
- 社内アプリ独自の拡張子
- ログ、バックアップ、エクスポートファイルの拡張子
- CAD、設計、研究データなど部門固有の拡張子
- 実体はCSVやテキストだが、拡張子だけ独自化しているファイル
- 実体はバイナリで、DLPによる内容検査に向かないファイル
この段階では、削除や変更を急がず、まず「何のために指定していたのか」を確認します。過去の担当者が念のために追加しただけの拡張子と、実際に監査・ブロック要件がある拡張子を分けることが大切です。
拡張子を3種類に分類する
棚卸しした拡張子は、次の3つに分類すると判断しやすくなります。
| 分類 | 例 | 対応方針 |
|---|---|---|
| スキャン対象として扱いたい拡張子 | Office文書、PDF、CSV、テキストなど | 新しい事前定義リストで選択できるか確認 |
| スキャンできないが持ち出しを制御したい拡張子 | 独自バイナリ、業務アプリの出力ファイルなど | Document could not be scannedとFile extension groupsを検討 |
| 業務上問題が少なく除外したい拡張子 | 一時ファイル、既知の無害な形式など | Unsupported file extension exclusionsを検討 |
Microsoft Learnでは、File extension groupsを使うことで、ファイル拡張子のグループを定義し、スキャンできないファイルに対するポリシーアクションに割り当てられると説明されています。なお、既存のファイル拡張子グループや分類無効化の設定では、拡張子を入力するときに.を付けない点にも注意が必要です。(Microsoft Learn)
スキャンできないファイルは別ルールで制御する
Endpoint DLPがスキャンしない、またはスキャンできないファイルを扱う場合は、「File extension is」条件に無理に含めるのではなく、「Document could not be scanned」を使った制御を検討します。
たとえば、社内の設計データや独自形式のエクスポートファイルをUSBやネットワーク共有へコピーさせたくない場合、次のような設計が考えられます。
| 要件 | 設定の考え方 |
|---|---|
| スキャンできないファイルのUSBコピーを止めたい | Document could not be scannedを条件にし、Copy to removable USB deviceをブロック |
| ネットワーク共有へのコピーも止めたい | Copy to a network shareも対象アクションに含める |
| 特定の独自拡張子だけ対象にしたい | File extension groupsで対象拡張子をグループ化 |
| ユーザーに理由を伝えたい | ポリシーヒント通知を有効化 |
| 業務継続の余地を残したい | 最初はAuditまたはBlock with overrideで検証 |
Microsoft Learnの手順では、Unsupported file extension exclusionsはMicrosoft Purviewポータルの「Settings > Data Loss Prevention > Endpoint DLP settings > Unsupported file extension exclusions」から追加できます。(Microsoft Learn)
ただし、Document could not be scannedを使うシナリオでは、他の条件と組み合わせられない制約が示されています。機密情報の種類やラベル条件と組み合わせて精密に判定する設計ではなく、「スキャンできないこと自体」を前提にした制御として設計してください。(Microsoft Learn)
展開時に起きやすい失敗と対策
事前定義リストにない拡張子を「保護対象外」と誤解する
新しいリストに表示されない拡張子があった場合、それは「一切制御できない」という意味ではありません。多くの場合、内容をスキャンして機密情報を検出する条件として適さない、またはサポート対象として選ばせないという意味で理解すべきです。
対策は、目的に応じて制御方法を分けることです。内容検査が必要なら、ファイル形式や保存方法を見直します。持ち出し操作を止めたいだけなら、スキャンできないファイル向けの条件や拡張子グループを使います。
独自拡張子の中身を確認しないまま移行する
業務アプリが出力する独自拡張子の中には、実体が単なるテキストやCSVに近いものもあります。一方で、完全なバイナリ形式で、DLPによる内容検査に向かないものもあります。
たとえば、顧客一覧を.reportxとして保存している場合、実体がCSV相当なら、開発側で.csvや.xlsxなど運用しやすい形式に変更するほうが、DLP・監査・電子証跡の面で扱いやすくなることがあります。逆に、独自バイナリである必要がある場合は、Endpoint DLPだけに頼らず、アプリ側のアクセス制御、暗号化、ダウンロード制御、保存先制限も組み合わせるべきです。
テストなしでブロックに切り替える
拡張子条件の変更は、ユーザーのファイル操作に直接影響します。いきなり全社でブロックすると、正当な業務ファイルのコピー、印刷、アップロードが止まり、ヘルプデスクへの問い合わせが増える可能性があります。
展開時は、次の順で進めると安全です。
| フェーズ | 推奨アクション |
|---|---|
| 事前確認 | 既存ルールと拡張子一覧を棚卸し |
| 検証 | 少数ユーザーでAuditまたは通知のみを有効化 |
| 調整 | 誤検知、業務影響、端末負荷を確認 |
| 段階展開 | 部門別・デバイスグループ別に範囲を広げる |
| 本番化 | 必要なアクションだけをブロックに変更 |
| 運用 | アラート、例外申請、ポリシーヒント文面を定期見直し |
Microsoft 365 Roadmapのリリース時期は予定であり、一般提供、延期、中止などにより情報が変更される可能性があります。2026年7月予定という日付だけで本番展開日を固定せず、自社テナントで機能が表示されたタイミングを基準に検証計画を組みましょう。(Microsoft)
開発者が見直すべきファイル出力設計
この変更は管理者向けのUI改善に見えますが、業務アプリの開発者にも関係があります。特に、アプリが機密情報をローカルファイルとして出力する場合、拡張子設計はDLP運用に影響します。
独自拡張子に機密情報を入れない
独自拡張子は、業務上は便利でも、セキュリティ運用では扱いにくくなることがあります。たとえば、個人情報を含むファイルを.tmpdataや.exportのような形式で保存すると、管理者がそれをDLPでどう扱うべきか判断しにくくなります。
機密情報を含む出力は、可能であれば管理しやすい形式に寄せます。Excel、CSV、PDFなど、監査・ラベル付け・DLPポリシーの対象として扱いやすい形式を選べるなら、そのほうが運用負荷は下がります。
一時ファイルにも注意する
アプリが処理途中でローカルに一時ファイルを作成する場合、その一時ファイルに機密情報が含まれていないか確認してください。ユーザーが直接触らないファイルでも、USBコピー、同期アプリ、バックアップツール、クラウドストレージクライアントの対象になることがあります。
開発側では、次の点を確認するとよいでしょう。
| 確認項目 | 具体例 |
|---|---|
| 一時ファイルの保存先 | ユーザープロファイル、Temp、AppData、作業フォルダー |
| 拡張子 | 独自拡張子、汎用拡張子、拡張子なし |
| 内容 | 平文の個人情報、認証情報、設計情報、ログ |
| 保存期間 | 処理後に削除されるか、残り続けるか |
| 保護方法 | 暗号化、アクセス権、削除処理、サーバー側処理 |
DLPで止める前提ではなく、そもそも端末に不要な機密ファイルを残さない設計にすることが重要です。
既存設定で特に注意したいポイント
拡張子を変えても完全な回避策にはならない
一部のファイル種類では、Endpoint DLPは拡張子だけでなくMIMEタイプにも基づいてアクティビティを捕捉します。Microsoft Learnでは、Word、Excel、PowerPoint、PDFなどについて、拡張子が変更された場合でも監視対象となるケースが説明されています。(Microsoft Learn)
そのため、「拡張子を変えればDLPを回避できる」と考えるのは危険です。一方で、すべてのファイル形式で同じように内容検査できるわけでもありません。管理者は、拡張子名だけで判断せず、実際のファイル形式、DLPイベント、アラート内容を確認する必要があります。
サポート対象外のファイルを無理にスキャン対象にしない
Microsoft Learnでは、Endpoint DLPが監視をサポートしないファイルタイプとして、.exe、.dll、.sys、.lib、.objなどが挙げられています。これらのような実行ファイルやバイナリ系ファイルを、機密情報検出のために通常の文書ファイルと同じように扱うのは適切ではありません。(Microsoft Learn)
このようなファイルは、内容スキャンではなく、持ち出し経路の制限、実行制御、アプリ制御、端末管理、アクセス権管理などと組み合わせて保護するほうが現実的です。
分類無効化設定を安易に使わない
Endpoint DLP settingsには、特定の拡張子をEndpoint DLP分類から除外する「Disable classification」設定があります。この設定に追加した拡張子のファイルは内容がスキャンされず、コンテンツに基づくポリシー評価も行われません。調査時にコンテンツ情報を確認できない点にも注意が必要です。(Microsoft Learn)
「端末負荷を下げたい」「誤検知を減らしたい」という理由で広く除外してしまうと、本来検出すべき機密ファイルまで見えなくなる可能性があります。除外する場合は、対象拡張子、理由、承認者、見直し期限を記録しておきましょう。
推奨される移行チェックリスト
今回の変更に備えるなら、次のチェックリストを使って準備を進めるのが実務的です。
| チェック | 内容 |
|---|---|
| □ | Devicesを対象にしたEndpoint DLPポリシーを一覧化した |
| □ | 「File extension is」条件を使うルールを特定した |
| □ | 手入力している拡張子を業務目的ごとに分類した |
| □ | 独自拡張子・非スキャン対象と思われる拡張子を洗い出した |
| □ | 事前定義リストで選べる拡張子と選べない拡張子を確認する準備をした |
| □ | 選べない拡張子の代替制御を決めた |
| □ | File extension groupsやUnsupported file extension exclusionsの利用方針を決めた |
| □ | Audit、通知、Block with override、本番Blockの展開順を決めた |
| □ | Activity explorerとアラートで検証する観点を決めた |
| □ | ユーザー通知文とヘルプデスク向けFAQを用意した |
| □ | 開発チームに独自拡張子・一時ファイル・出力形式の確認を依頼した |
| □ | ロードマップの日付変更に備え、展開計画に余裕を持たせた |
よくある質問
既存ポリシーは自動的に変更されるのか
現時点のロードマップ情報だけでは、既存ポリシーの値が自動変換されるのか、既存設定がそのまま保持されるのかまでは読み取れません。したがって、機能が自社テナントに表示されたら、既存ルールの拡張子条件がどのように表示されるかを必ず確認してください。
事前定義リストにない拡張子は使えなくなるのか
少なくとも「File extension is」条件では、リストに含まれるサポート対象拡張子を選択する方向に変わります。ただし、リストにない拡張子を一切制御できないとは限りません。スキャンできないファイルとして扱う、ファイル拡張子グループで持ち出し制御する、アプリ側で出力形式を変えるなど、目的に応じて代替策を選びます。
管理者は何から始めればよいか
最初にやるべきことは、既存のEndpoint DLPポリシーで拡張子条件を使っているルールを洗い出すことです。次に、指定している拡張子を「内容スキャンしたいもの」「スキャンできないが持ち出しを止めたいもの」「除外してよいもの」に分けます。この分類ができれば、アップデート後の移行判断がかなり楽になります。
開発者には何を依頼すべきか
業務アプリが出力するファイルの拡張子、保存先、内容、保存期間を確認してもらいましょう。特に、機密情報を独自拡張子や一時ファイルに保存している場合は、DLPで検出しやすい形式への変更、端末に保存しない設計、暗号化やアクセス制御の追加を検討すべきです。
今回の変更で取るべき次の行動
今回のEndpoint DLPの変更は、派手な新機能というより、DLPポリシーの誤設定を減らすための実務的な改善です。自由入力で拡張子を指定できる状態は便利ですが、サポート外の拡張子を指定して「守れているつもり」になる危険がありました。事前定義リストへの移行により、管理者はサポート対象を意識しながらポリシーを作りやすくなります。
まずは、Microsoft PurviewのEndpoint DLPポリシーを棚卸しし、拡張子条件を使っているルールを確認してください。次に、独自拡張子やスキャンできないファイルを別管理に切り分け、必要に応じてFile extension groups、Unsupported file extension exclusions、Document could not be scannedを使った制御へ整理します。最後に、少人数の検証から始め、アラート内容、ユーザー影響、端末負荷を確認してから本番展開するのが安全です。
コメント