Microsoft Purview DLPのOutlook向け更新とは？Exchange Onlineの分類エラー制御を管理者向けに解説

Outlookで送信されるメールのDLP制御を管理している組織は、Microsoft Purview Data Loss Preventionの新しい「Granular classification error controls」に注意が必要です。今回のポイントは、Exchange Onlineで添付ファイルなどの分類・テキスト抽出に失敗した場合に、失敗理由を一括で扱うのではなく、タイムアウト、スロットリング、その他のスキャンエラーといった種類別にDLPポリシーを設計できるようになる点です。管理者は、既存の「スキャンできなかったメールをどう扱うか」というDLPルールを棚卸しし、公開プレビュー段階ではシミュレーションや限定スコープで検証してから本番展開するのが安全です。

Outlookのセキュリティ更新で何が変わるのか

今回の更新は、Outlookアプリの画面やボタンが変わる機能ではなく、Outlook利用時のメール送信・転送に関わるExchange Online側のDLP制御に関する更新です。Microsoft 365 Roadmap ID 561916では、「Microsoft Purview: Data Loss Prevention – Granular classification error controls (Exchange online)」として登録されており、分類処理やテキスト抽出の失敗タイプに基づいてDLPポリシーを作成できるようになると説明されています。公式API上の作成・更新時刻は2026年5月11日23:15:11 UTCで、日本時間では2026年5月12日に相当します。プレビュー予定は2026年6月、一般提供予定は2026年7月、状態はIn developmentです。(Microsoft)

確認項目	内容
対象	Exchange OnlineのDLP制御。Outlookから送信されるメールに影響する可能性がある
関連サービス	Microsoft Purview Data Loss Prevention、Exchange Online、Outlook
Roadmap ID	561916
主な変更	分類・テキスト抽出の失敗を、タイムアウト、スロットリング、その他のスキャンエラーなどに分けて制御できる
プレビュー予定	2026年6月
一般提供予定	2026年7月
管理者が最初にやること	既存の「スキャン失敗時」のDLPルールを棚卸しし、過剰ブロックまたは過小検知がないか確認する

なお、Microsoft 365 Roadmapの公開情報は予定情報であり、リリース時期や内容は変更される可能性があります。展開時期を運用計画に入れる場合は、Roadmapだけでなく、自社テナントのMicrosoft 365管理センターのメッセージセンターやMicrosoft Purviewポータル上の実装状況も確認してください。(Microsoft)

これまでのDLPルールで起きやすかった問題

Microsoft Purview DLPは、機密情報の不適切な共有を防ぐために、メール、SharePoint、OneDrive、Teams、デバイスなどの場所に対してポリシーを適用します。Exchange OnlineメールもDLPの対象であり、DLPは単純なテキスト検索だけでなく、キーワード、正規表現、関数検証、近接条件、機械学習などを使ってコンテンツを分析します。(Microsoft Learn)

ただし、実務では「内容が危険だからブロックされた」のではなく、「内容を十分にスキャンできなかったため、安全と判断できなかった」ケースがあります。例えば、次のようなケースです。

添付ファイルの解析に時間がかかり、分類処理がタイムアウトした
サービス側の処理制限やスロットリングでスキャンが完了しなかった
ファイル形式や圧縮形式などの理由で、添付ファイルを認識できなかった
一時的なスキャンエラーにより、本文や添付ファイルのテキスト抽出が完了しなかった

従来の運用では、こうした失敗をまとめて「スキャン失敗」として扱い、一律にブロック、隔離、通知、監査のいずれかに寄せがちでした。その結果、セキュリティを優先しすぎると業務メールが止まり、業務継続を優先しすぎると本当に危険な未解析メールを通してしまう、という板挟みが起きます。

今回のGranular classification error controlsは、この「一律対応」を細分化するための更新です。分類タイムアウトは厳しめに扱う、スロットリング由来の失敗はまず監査対象にする、その他のスキャンエラーは高リスク宛先だけブロックする、といった設計がしやすくなります。

既存のExchange Online DLP条件との関係

Microsoft LearnのExchange向けDLP条件リファレンスでは、添付ファイル関連の条件として「Any email attachment’s content could not be scanned」「Any email attachment’s content didn’t complete scanning」「Document scan failures」などが示されています。特に「Document scan failures」は、分類タイムアウト、スロットリング、その他の失敗といった細かなスキャンエラーシナリオに対してアクションを適用するために、スキャン不可やスキャン未完了の条件と併用することが推奨されています。(Microsoft Learn)

条件の考え方	代表的な意味	実務での使いどころ
添付ファイルをスキャンできない	Exchange Onlineが添付ファイルを認識できない、または内容確認が困難	未対応形式、特殊な圧縮ファイル、解析不能な添付ファイルへの対応
添付ファイルのスキャンが完了しない	ルールエンジンが添付ファイルのスキャンを完了できない	大容量ファイル、複雑なファイル、処理上限に近いメールへの対応
Document scan failures	分類タイムアウト、スロットリング、その他のスキャンエラーを細分化して扱う	失敗理由ごとにブロック、監査、通知、例外を分ける設計

重要なのは、「スキャン失敗＝すべて危険」とも「スキャン失敗＝一時的な問題なので許可」とも決めつけないことです。宛先、送信者、添付ファイルの種類、業務プロセス、機密ラベルの有無を組み合わせて判断する必要があります。

影響を受ける管理者・利用者・開発者

今回の更新で主に影響を受けるのは、Outlookの一般利用者よりも、Microsoft Purview DLPやExchange Onlineを管理する担当者です。ただし、DLPルールの変更結果はOutlook利用者の送信体験に現れます。メールがブロックされる、ポリシーヒントが表示される、承認フローに回る、隔離される、インシデントアラートが発生する、といった影響が出る可能性があります。

立場	確認すべきこと
Microsoft Purview管理者	DLPポリシー内でスキャン失敗系の条件を使っているか、どのアクションを設定しているか
Exchange Online管理者	メールフロー、添付ファイル制限、外部宛先、共有メールボックス、アプリ送信メールへの影響
セキュリティ・SOC担当	アラートの重大度、監査ログ、インシデント対応手順、誤検知時の一次対応
ヘルプデスク	「メールが送れない」「添付ファイル付きメールが止まる」問い合わせへの切り分け手順
開発者・業務アプリ担当	Graph API、SMTP、業務システムから送る自動メールや添付ファイルがDLPに抵触しないか

特に注意したいのは、業務アプリが送信する自動メールです。月次レポート、請求書、顧客データ、CSV、PDF、圧縮ファイルなどを添付するアプリでは、利用者本人がOutlookで手動送信していなくてもExchange Online側のDLP制御にかかる可能性があります。

管理者が最初に確認すべきDLP設定

まずは、新しい機能を使う前に既存ポリシーの棚卸しを行います。いきなり新しい条件を追加するより、現在どのメールが「スキャン失敗時」にブロックまたは許可されているかを把握する方が重要です。

確認対象	見るべきポイント	判断基準
既存DLPポリシー	Exchange Onlineを対象にしているルールがあるか	Outlook利用者に影響する可能性がある
スキャン失敗系の条件	スキャン不可、スキャン未完了、処理上限超過に関する条件があるか	今回の細分化対象になりやすい
アクション	ブロック、隔離、リダイレクト、承認、通知、監査のどれか	業務影響の大きさを判断する
対象範囲	全社、部門、特定ユーザー、外部宛先、特定ドメイン	過剰適用を避けるために重要
例外設定	信頼済み送信者、業務アプリ、内部宛先など	例外が広すぎると抜け道になる
アラート	重大度、通知先、頻度、担当チーム	SOCやヘルプデスクの運用負荷に影響する

Microsoft Purview DLPのポリシーでは、条件が「何に一致したか」を決め、アクションが「一致した結果として何をするか」を決めます。メールをリダイレクトする場合には転送先などの追加プロパティが必要になるように、アクションごとに追加設定が必要です。(Microsoft Learn)

シナリオ	推奨される初期対応	理由
外部宛先への添付メールで分類タイムアウト	まずシミュレーション。高リスク部門ではブロックまたは承認フローを検討	内容を判定できないまま社外送信されるリスクが高い
内部宛先のみでスロットリング由来のスキャン失敗	監査・アラートから開始	一時的な処理要因で業務を止めすぎないため
業務アプリから定期送信される大容量レポート	送信元、宛先、添付形式を限定して例外または別ルール化	一律ブロックすると月次・日次業務が止まりやすい
未対応形式や解析不能な添付ファイルを外部送信	機密部門ではブロック、一般部門では警告・承認を検討	内容が見えない添付ファイルは情報漏えいリスクが高い
その他のスキャンエラー	監査ログを見ながら段階的に制御	原因が多様なため、最初から強制ブロックすると誤検知が増える

展開前に必ずシミュレーションで確認する

新しいDLP条件は、最初から本番ブロックに使わない方が安全です。Microsoft Purview DLPのシミュレーションモードでは、ポリシーが強制適用された場合と同じように評価されますが、実際のブロックなどのアクションは適用されません。結果は専用のダッシュボードに分離されるため、ユーザーや業務プロセスに影響を与えずにポリシーの影響を確認できます。(Microsoft Learn)

ステップ	作業内容	完了条件
棚卸し	Exchange Online対象の既存DLPルールを確認	スキャン失敗系ルールとアクションが一覧化されている
影響分類	外部宛先、部門、送信元アプリ、添付形式ごとにリスクを分類	強制ブロックすべきケースと監査から始めるケースが分かれている
シミュレーション	新しい条件を使ったルールを限定範囲で検証	誤検知、業務影響、アラート量を確認できている
パイロット	特定部門または特定メールフローで本番適用	問い合わせ対応とロールバック手順が整っている
段階展開	対象範囲を広げる	重大な誤検知や業務停止が発生していない
運用定着	アラート、ヘルプデスク、例外申請を見直す	月次でポリシー改善できる状態になっている

シミュレーションは最大15日間実行されることがあり、Exchange、Teams、Devicesではシミュレーション開始後の新しいアイテムが評価対象になるため、短時間だけ実行して判断しないようにしてください。結果データの保持期間にも注意が必要です。(Microsoft Learn)

Outlook利用者への影響をどう説明するか

利用者向けには、技術用語をそのまま伝えるよりも、「添付ファイル付きメールの安全確認がより細かくなる」と説明すると理解されやすくなります。

例えば、次のように案内できます。

会社の情報保護ポリシーにより、Outlookで添付ファイル付きメールを送信する際、内容確認が完了しないメールは送信が一時停止されたり、承認が必要になったりする場合があります。これはメール本文や添付ファイルの安全性を確認するための仕組みです。業務上必要な送信でブロックされた場合は、送信先、添付ファイル名、エラー表示、業務目的を添えてヘルプデスクへ連絡してください。

この案内で大切なのは、「ユーザーが悪いことをした」と受け取られないようにすることです。スキャン失敗は、機密情報の検出とは別の理由で起きる場合があります。利用者への説明では、セキュリティ強化と業務継続の両方を目的としていることを明確にしましょう。

開発者・業務アプリ担当が確認すべきポイント

開発者や業務アプリ担当者は、Outlook画面だけでなく、Exchange Onlineに流れる自動送信メールを確認する必要があります。特に、顧客データ、個人情報、契約情報、売上データなどを添付するアプリは、DLPの影響を受けやすい領域です。

確認すべきポイントは次の通りです。

添付ファイルのサイズが極端に大きくないか
パスワード付きZIPや多重圧縮ファイルを多用していないか
CSV、PDF、Excel、独自拡張子などのファイル形式がDLPで解析しやすいか
件名や本文に業務上必要な識別情報が入っているか
送信元メールボックスをアプリごとに分けているか
Message-ID、送信ジョブID、送信日時、宛先ドメイン、添付ファイル名、サイズをログに残しているか
DLPブロック時に再送を無制限に繰り返さない設計になっているか

避けたいのは、「DLPで止まるので、すべての自動送信メールを例外にする」という対応です。例外設定は便利ですが、広すぎる例外はDLPの抜け道になります。アプリ単位、宛先単位、添付形式単位で必要最小限に絞り、監査ログやアラートは残す設計にしてください。

移行・展開時に失敗しやすいポイント

今回の更新で最も避けたい失敗は、既存の一律ルールをそのまま残したまま、新しい細分化ルールを追加してしまうことです。ルール同士の優先順位やアクションが衝突すると、想定以上にメールが止まる可能性があります。

失敗例	起きる問題	対策
既存の一律ブロックルールを確認せず新ルールを追加	新しい細分化制御が効く前に旧ルールでブロックされる	既存ルールの条件、優先順位、例外を先に確認する
スロットリング由来の失敗まで強制ブロック	一時的な処理問題で業務メールが大量停止する	まず監査・アラートで傾向を見る
例外を送信元ドメイン単位で広く作る	業務アプリや共有メールボックスがDLPを回避しすぎる	送信元、宛先、添付形式、業務用途を限定する
ヘルプデスクに周知しない	「Outlook障害」と誤認され、切り分けが遅れる	エラー表示、問い合わせテンプレート、一次対応手順を用意する
アラート重大度を見直さない	SOCに低優先度アラートが大量に流れる	失敗理由ごとに重大度と通知先を分ける
プレビュー機能を本番前提で自動化する	UIや仕様変更でスクリプトが壊れる可能性がある	プレビュー中は手順書と検証環境を分ける

既存ルールを見直す際の判断基準

DLPの見直しでは、「どの失敗を止めるか」ではなく、「どの業務リスクを下げたいか」から逆算すると設計しやすくなります。

外部送信は厳しめ、内部送信は段階的に

社外宛てメールは情報漏えいリスクが高いため、分類タイムアウトや解析不能な添付ファイルを厳しめに扱う価値があります。一方、内部宛先だけのメールまで強制ブロックすると、業務効率が大きく落ちる場合があります。内部送信は最初に監査や通知から始め、実際の検出状況を見て強化するのが現実的です。

機密部門は別ルールにする

法務、人事、経理、研究開発、営業企画など、機密性の高いデータを扱う部門では、一般部門と同じ基準では不十分な場合があります。高リスク部門は、添付ファイルのスキャン失敗時に承認または隔離を入れるなど、別ポリシーに分けると運用しやすくなります。

自動送信メールは送信元を分離する

業務アプリが個人ユーザーのメールボックスから送る設計だと、DLPの切り分けが難しくなります。可能であれば専用メールボックスやアプリ用送信元を使い、どのアプリがどの添付ファイルを送っているか追跡できる状態にしておきましょう。

例外は「恒久」ではなく「期限付き」にする

プレビュー期間中に作った例外をそのまま放置すると、後から見直されない抜け道になります。例外申請には理由、対象、期限、承認者、再評価日を持たせると、運用が崩れにくくなります。

管理者向けの実践チェックリスト

本番展開前に、少なくとも次の項目を確認してください。

Exchange Onlineを対象にしたDLPポリシーを一覧化した
スキャン不可、スキャン未完了、処理上限、Document scan failuresに関する条件を確認した
既存ルールの優先順位と例外設定を確認した
外部宛先と内部宛先で対応を分けた
高リスク部門と一般部門で適用範囲を分けた
自動送信メール、共有メールボックス、業務アプリの送信パターンを確認した
シミュレーションモードで検出件数と誤検知を確認した
アラートの重大度、通知先、対応SLAを決めた
ヘルプデスク向けの問い合わせテンプレートを用意した
例外申請とロールバック手順を文書化した

よくある疑問

Outlook利用者は何か設定変更が必要ですか

通常、利用者側で設定変更する機能ではありません。管理者がMicrosoft Purview DLPポリシーを設計・展開し、その結果としてOutlook利用者にポリシーヒント、送信ブロック、承認要求などが表示される可能性があります。

既存のDLPポリシーは自動で移行されますか

現時点のRoadmap情報だけでは、既存ポリシーが自動的に細分化ルールへ移行されるとは判断できません。既存の一律ルールが残る可能性を前提に、管理者がポリシーの条件、優先順位、アクション、例外を確認するべきです。

SharePointやOneDriveにも同じ変更が適用されますか

今回のRoadmap項目はExchange Online向けです。Microsoft Purview DLP自体はSharePoint、OneDrive、Teams、デバイスなどにも対応しますが、今回の変更はOutlookから利用されるExchange OnlineメールのDLP制御として理解するのが適切です。Exchange email onlineでは、DLPで機密情報の種類と秘密度ラベルを使った定義がサポートされていますが、保持ラベルは同じ扱いではありません。(Microsoft Learn)

すぐにブロックルールを強化すべきですか

まずはシミュレーションと限定展開を推奨します。スキャン失敗には、機密情報の可能性が高いケースだけでなく、一時的な処理問題や業務アプリ特有の添付形式が原因のケースもあります。いきなり全社ブロックにすると、問い合わせ増加や業務停止につながる可能性があります。

今回の更新で取るべき次の一手

Microsoft Purview Data Loss PreventionのGranular classification error controlsは、Outlookを使ったメール送信時の情報漏えい対策を、より現実的に設計するための更新です。ポイントは、スキャン失敗を一括で扱わず、失敗理由、宛先、送信元、添付ファイル、部門リスクを組み合わせて判断することです。

管理者はまず、Exchange Online対象の既存DLPポリシーを棚卸ししてください。そのうえで、分類タイムアウト、スロットリング、その他のスキャンエラーを分けたルール案を作り、シミュレーションで検出件数と業務影響を確認します。開発者や業務アプリ担当は、自動送信メールの添付ファイル形式、サイズ、送信元、ログ設計を見直してください。

本番展開では、監査から始め、外部送信や高リスク部門に限定して段階的に強制アクションを適用するのが安全です。DLPは「止める仕組み」ではなく、「止めるべきメールと通すべき業務メールを見分ける仕組み」として設計することで、セキュリティと業務継続の両立がしやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。