Microsoft Purview DLP を導入してしばらく問題なく運用していたのに、「ある日から特定の PDF 添付だけブロックされなくなった」「分類テストでは SIT に一致しているのに、実際のメールフローでは素通りする」。そんな一見不可解な挙動は、多くの場合「DLP 設定のバグ」ではなく、PDF の中身（構造）と、Exchange トランスポート側のテキスト抽出の差異が原因です。本記事では、このギャップの仕組みと、現場で使える具体的な対処手順を整理します。
現象の整理：SIT には一致しているのにメールがブロックされない
今回のシナリオは、Microsoft Purview DLP／Exchange Online を使った典型的なトラブルです。まずは、現象を整理しておきましょう。
- 2月頃から、設定変更を行っていないにも関わらず、特定の PDF 添付ファイルを含むメールだけ DLP でブロックされなくなった
- ポータルの「テスト」や Test-DataClassification（分類テスト） では、対象 PDF 内の SIT（機密情報の種類） が確信度 85% で検出されている
- しかし Test-Message（DLP ルール トレース） を実行すると「条件不一致」と判定され、実際のメールは通過してしまう
- 他の PDF や他のメールでは、同じ DLP ポリシーで問題なくブロックされている
つまり、ポリシー全体が壊れているわけではなく、一部の PDF 添付だけが DLP に引っかからない状況です。この時点で、「設定ミス」よりもPDF ファイルの中身や構造の違いが怪しいと考えられます。
| 項目 | 正常にブロックされるメール | 通過してしまうメール |
|---|---|---|
| 添付ファイル | 一般的な PDF（テキスト選択可能など） | 特定の PDF（暗号化・画像ベース等の可能性） |
| 分類テスト（Test‑DataClassification） | SIT 検出あり（高確信度） | SIT 検出あり（高確信度） |
| DLP ルール トレース（Test‑Message） | SIT 条件に一致 → ブロック | 条件不一致 → 通過 |
| DLP ポリシー設定 | 同じポリシー・同じルールを使用 | |
ここから導かれるポイントはひとつです。「同じポリシーでも、ファイルによって検出結果が変わる」＝「ファイル構造に依存する問題」だということです。
Purview DLP と SIT の基本をおさらい
原因を理解しやすくするために、Microsoft Purview DLP と SIT（機密情報の種類）の動き方をざっくり整理します。
SIT（機密情報の種類）とは何か
- クレジットカード番号、マイナンバー、運転免許番号など、機密情報をパターンとして定義したもの
- 正規表現・チェックサム・キーワード・周辺語などを組み合わせて判定し、確信度（低／中／高）を付与
- DLP ルールでは「SIT が中以上で 1 件以上検出されたらブロック」などと条件を設定
Test‑DataClassification（分類テスト）の特徴
ポータル上から実行できる「分類テスト」は、SIT 定義が期待通りヒットするかを確認するための機能で、次のような特徴があります。
- 単一のファイルやテキストを対象に、よりリッチな解析を行える
- 時間制約が比較的緩く、複雑な構造のファイルでも、可能な範囲で丁寧に解析しようとする
- メールフローとは切り離されているため、Exchange トランスポートの制約を受けない
Test‑Message（DLP ルール トレース）の特徴
一方、Test‑Message は実際のメールフローを模擬し、トランスポートルールとして DLP を評価するテストです。
- Exchange Online 側のエンジンが、実運用時と同じロジック・制約でメッセージを評価
- 添付ファイルから一定量のテキストを抽出した結果だけをもとに、SIT 条件を判定
- 暗号化・パスワード保護・特殊形式などでテキスト抽出に失敗すると、SIT 条件まで到達せず「不一致」となる
重要なのは、分類テストとメールフローのエンジンは同じではないという点です。
したがって、「分類テストでは SIT に一致」しても、「メールフローでは不一致」になることは、仕様上あり得る挙動です。
原因の本筋：PDF のテキスト抽出差による SIT 条件不一致
問題の核心は、次の一文に集約できます。
分類テスト側は PDF からテキストを十分に抽出できるが、Exchange トランスポート側は同じ PDF からテキストを十分に取り出せず、SIT 条件まで到達しない。
実際、次のような PDF ではテキスト抽出がうまくいかず、「SIT があるはずなのに検出されない」という現象が発生しやすくなります。
- 暗号化された PDF（パスワード保護された PDF）
- 画像だけで構成された PDF（紙をスキャンしただけの PDF など）
- 特殊なエンコードやフォント埋め込みが多用された PDF
- フォームフィールド・コメント・注釈・埋め込みオブジェクトが中心の PDF
- 入れ子構造が複雑な PDF（大量の添付・埋込みファイルを含むなど）
| PDF のタイプ | メールフローでの典型的な影響 | 簡単な確認方法 |
|---|---|---|
| 暗号化／パスワード保護 | Exchange が中身を読めず SIT 未検出 → DLP 不発 | 開くときにパスワード入力が必要か確認 |
| 画像のみ（スキャン PDF） | テキスト層なし → 抽出テキスト 0 → SIT 未検出 | テキストをドラッグで選択できるか確認 |
| 特殊フォント／エンコード | 抽出テキストが欠損・文字化け → パターンが崩れる | コピー＆ペーストして文字化けしないか確認 |
| フォーム中心の PDF | フォーム値が抽出されず、SIT 文字列に届かない | 印刷プレビューで文字が見えるかを確認 |
ここまでを踏まえると、今回のような事象では、まず「問題の PDF がテキスト抽出しにくい構造になっていないか」を疑うのが最短ルートです。
実務での対処フロー：原因切り分けから解決まで
ここからは、現場の管理者が実際に行うべき対処手順を、ステップ形式で解説します。上から順に試していくことで、設定の問題か PDF 側の問題かを効率よく切り分けられます。
ステップ 1：問題の PDF の「中身」をクイックチェック
最初に行うべきは、DLP ポリシーではなく、該当 PDF 自体の確認です。
- 問題の PDF をローカル PC で開く（Adobe Acrobat、ブラウザなど）
- 本文の文字をドラッグしてみて、テキストが選択できるか確認する
- Ctrl+F（検索）で、SIT に関係する文字列（例：カード番号、番号の一部など）を検索してみる
- 開くときにパスワードを求められないか確認する
- 別名保存しようとしたとき、「暗号化」「保護」などの表示がないか確認する
この確認で、文字が一切選択できない／検索にヒットしない／暗号化マークが付いている場合は、テキスト抽出に失敗している可能性が非常に高いです。
ステップ 2：PDF を整形（再保存・OCR）して DLP の挙動を比較
テキスト抽出が怪しければ、次のような方法でPDFを「整形」し、その前後で DLP の挙動を比較します。
- PDF/A 形式で再保存する
多くの PDF 編集ソフトには「PDF/A で保存」「長期保存用 PDF」といったオプションがあります。これにより、テキスト層が明確な PDF に変換されることが多く、抽出精度の向上が期待できます。 - OCR を実行して「検索可能 PDF」にする
紙をスキャンしただけの PDF は、画像ファイルと同じです。OCR（光学文字認識） をかけて「検索可能テキスト」を付与することで、DLP が中身を読めるようになります。 - 暗号化・パスワード・IRM 保護を外す
送信元側の運用として、DLP で検査したい PDF には可能な限り保護をかけない／IRM ではなく DLP 側で保護する、といったルールを検討します。 - フォームや埋め込みオブジェクトの平坦化（フラット化）
フォームフィールドの値やコメントだけに重要情報があると、抽出しきれない場合があります。「印刷用に出力」「画像として書き出し → OCR」などで、目に見えるテキストをすべて平文テキストとして固めるイメージです。
| 整形方法 | 期待できる効果 | 目安となる使いどころ |
|---|---|---|
| PDF/A で再保存 | テキスト層の再構築、フォント・エンコードの標準化 | 一般的な PDF だが一部が検出されない場合 |
| OCR で検索可能化 | 画像だけの PDF にテキスト情報を付加 | スキャン PDF、FAX 取り込み PDF |
| 暗号化・保護解除 | 内容抽出を可能にする | パスワード付与／IRM 保護された文書 |
| フォームのフラット化 | フォームの値を通常テキストとして扱えるようにする | 申込書等の電子フォーム系 PDF |
これらの整形を行った前後の PDF を自分宛てにメール送信し、DLP がブロックするかどうかを比較すると、原因が PDF 側にあるかどうかがはっきりします。
ステップ 3：DLP ポリシー／ルール設定の再点検
PDF 側の問題だけでなく、DLP の設定が「やや厳しすぎる」ために結果的に不一致となっているケースもあります。次のポイントを順に確認しましょう。
メッセージと添付を正しく評価しているか
- 条件に 「メッセージの内容は…」「添付ファイルの内容は…」 など、メッセージおよび添付を評価する条件が含まれているか
- 誤って「メッセージ本文のみ」を評価対象にしていないか
機密情報の種類（SIT）の確信度・一致数が厳しすぎないか
- SIT の条件が 「高のみ」になっている場合、まずは 「中以上」 に緩和して挙動を確認する
- 一致数（インスタンス数） が 5 件や 10 件など高く設定されていると、
抽出できたテキストが少ない PDF では条件を満たせない - 切り分け段階では、一致数を 1 件にして「抽出さえできれば発火する」状態にしておくと原因が把握しやすい
ファイル種別の制限をかけていないか
- DLP ルールで、対象とするファイル種別を限定していないか確認する
- もしフィルタを掛ける運用であれば、必ず PDF を含めるよう設定を確認
圧縮ファイル・入れ子添付の扱い
- ZIP 等の 圧縮ファイル内のコンテンツも検査する設定になっているか
- PDF が ZIP の中に入っている、さらにその中に PDF が入っている…といったケースでは、
入れ子の深さ制限にかかる場合もあるため注意
例外条件・他ポリシーとの干渉
- 「メッセージの種類が権限で保護されている場合は除外」 などの例外に該当していないか
- 上位の DLP ポリシーやトランスポートルールで、先に処理されてしまい評価対象から外れていないか
適用モード・ルールの優先順位
- ポリシーが 「シミュレーション」「監査のみ」 になっていないか（通知はされるがブロックされない）
- ブロックを行うルールが、他ルールに比べて優先順位が低く、先に別ルールがマッチして終了していないか
- ポリシー変更後、確実に「発行（Publish）」されているか
| 確認項目 | 見るべきポイント | よくある落とし穴 |
|---|---|---|
| 評価対象 | メッセージ本文＋添付が対象か | 本文だけに限定されており、添付が検査されていない |
| SIT 閾値 | 確信度：中以上／一致数：1 から検証 | 「高のみ」「一致数 10」など厳しすぎる設定 |
| ファイル種別 | PDF を対象に含めているか | 「Office ファイルのみ」を対象にしていて PDF が外れている |
| 圧縮ファイル | ZIP 内も検査対象にしているか | ZIP の中の PDF が検査されていない |
| 例外条件 | 保護付きメール等を除外していないか | IRM／RMS 保護メールを丸ごと除外している |
| ルール優先度 | ブロックルールが上位にあるか | 上位ルールの「許可」で処理が完了してしまう |
ステップ 4：DLP ルール トレース（Test‑Message）で「不一致の理由」を確認
設定を見直したうえで、改めて Test‑Message を実行し、どの条件で不一致が発生しているのかを確認します。
- SIT 条件だけが不一致なのか
- ファイル種別条件や例外条件で除外されているのか
- そもそも該当 DLP ポリシーが評価対象になっていないのか
ログを読み解く際は、「SIT が 0 件と判定されているのか」「評価前に除外されているのか」を意識すると、原因のあたりがつけやすくなります。
よくある勘違いと落とし穴
「分類テストで一致＝本番でも必ず一致」ではない
現場で非常に多い誤解が、「分類テストで SIT がヒットしている＝本番の DLP でも必ずブロックされるはず」という思い込みです。
しかし実際には、分類テストとメールフロー (Exchange トランスポート) では、テキスト抽出の仕組みや制約が異なるため、
- 分類テスト：SIT ヒット
- メールフロー：SIT 未検出 → ルール条件不一致 → 通過
という結果は普通に起こり得ます。
したがって、トラブルシュートでは必ず Test‑Message 側の結果も併せて確認することが重要です。
「ポリシー全体がおかしい」のではなく「PDF 個体差」の可能性が高い
本件のように、「ほとんどの PDF はブロックされているが、一部だけ通過する」という場合、ポリシー全体が壊れている可能性は低いです。
そのため、いきなりポリシーを大幅に作り替えるのではなく、
- 問題の PDF の構造を疑う（暗号化・画像ベース・特殊フォント等）
- 整形（再保存／OCR／保護解除）後の挙動を比較する
- 必要に応じて閾値や対象範囲を微調整する
という順番で進めるのが、もっともトラブルを増やさないアプローチです。
シミュレーションモードのままになっている
意外と見落としがちなのが、DLP ポリシーが「監査のみ」や「シミュレーション」モードのままになっているケースです。
- 分類テストや Test‑Message では「一致」しているように見える
- しかし本番動作としては「レポートのみ」でブロックされていない
という状況になりがちなので、
- 現在のポリシーモード（シミュレーション／本番）
- ブロックではなく「通知のみ」「監査のみ」になっていないか
を必ず確認するようにしましょう。
再発防止のための運用上の工夫
一度トラブルを解消しても、PDF の作り方やツールが変われば、同じ問題が再び発生する可能性があります。再発防止のために、次のような運用ルールやベストプラクティスも検討するとよいでしょう。
送信元部門へのガイドライン整備
- 重要情報を含む文書は、可能な限り 暗号化なし・パスワードなし の PDF で作成し、
DLP で検査したうえで、必要に応じて別チャネルで保護する - 紙のスキャンをそのまま PDF として送るのではなく、OCR で検索可能にする運用を徹底する
- 専用業務システムから出力される PDF について、
DLP で検出できるかどうかを事前にテストし、問題があればベンダーと協議する
DLP ポリシー変更時のチェックプロセス
- ポリシーやルールを変更する際には、代表的な PDF パターン（普通の PDF／スキャン PDF／フォーム PDF 等）を用意して発火テストを行う
- 変更後は、必ず Test‑Message でルールトレースを確認し、「分類テストだけ見て安心しない」ことを徹底する
ログ・アラートの活用
- ユーザーから「おかしい」と問い合わせが来る前に、DLP のログを定期的にレビューし、
特定のパターンだけ検出件数が急に落ちていないか確認する - 検出件数が急減した場合、システム側の変更（アップデート）だけでなく、
業務側の文書フォーマット変更も疑う
チェックリスト：この問題に遭遇したら確認したいポイント
最後に、本記事で解説した内容をもとに、「SIT は一致しているのにメールがブロックされない」問題に対するクイックチェックリストをまとめます。
| チェック項目 | OK の状態 |
|---|---|
| PDF の暗号化・パスワード保護 | 暗号化やパスワード保護がなく、開くときにパスワードを求められない |
| PDF のテキスト選択・検索 | 文字がドラッグで選択でき、Ctrl+F の検索で該当文字列がヒットする |
| DLP の評価対象 | 「メッセージおよび添付ファイル」を評価しており、PDF が対象外になっていない |
| SIT の確信度・一致数 | 切り分け段階では「中以上／1 件」程度に設定している |
| 圧縮ファイルの設定 | 必要に応じて ZIP 等の圧縮ファイル内も検査している |
| 例外条件 | 権限保護メールなどの例外条件に該当していない |
| ポリシーモード | シミュレーション・監査のみではなく、ブロック動作が有効になっている |
| ポリシー発行 | 変更後のポリシーが正しく「発行」されている |
| Test‑Message の結果 | どの条件で不一致になっているか把握している |
まとめ：PDF の“内容抽出可否”と DLP 閾値を両輪で見直す
「SIT は一致するのにメールがブロックされない」という現象は、どうしても DLP ポリシーや Microsoft 側の不具合を疑いたくなる問題です。しかし、実際には
- 分類テストとメールフローの実施エンジンの違い
- PDF からテキストを抽出できるかどうか
- SIT の閾値や評価対象の設定
といった「仕組み上のギャップ」が重なって起きているケースがほとんどです。
まずは、問題の PDF を整形（PDF/A で再保存、OCR、保護解除、フォームのフラット化など）して内容抽出のしやすさを改善することで、DLP が本来の力を発揮できる状態にします。そのうえで、
- SIT の確信度・一致数を一時的に緩める
- 評価対象を「メッセージおよび添付ファイル」にする
- 圧縮ファイルや例外条件、ポリシーモードを見直す
- Test‑Message で実際の評価結果を確認する
といったポリシー側の調整を行うことで、「抽出できれば発火する」状態を確実に作り込むことができます。
要点をもう一度まとめると、
- PDF の“内容抽出可否”を改善する（OCR・再保存・保護解除など）
- Purview DLP のルール閾値と評価対象を見直し、Test‑Message で必ず確認する
この 2 本柱でアプローチすることが、「SIT は一致するのにメールがブロックされない」問題を最短で解決する現実的な方法です。運用の中で同様の事象が発生した際には、本記事の手順とチェックリストをそのままトラブルシュートのテンプレートとして活用してみてください。
コメント