Exact Data Match が機能しない場合の完全トラブルシューティングガイド

By Mirko Peters · 2026-04-21

Microsoft 365 の Exact Data Match (EDM) が機能しないと感じている場合、決して珍しいことではありません。このガイドでは、EDM ベースのデータ損失防止 (DLP) が想定どおりに動作しない理由を整理します。技術的な仕組みと必要な設定の理解から、重大なエラーの診断、複雑な問題の修正まで、段階的に解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft 365 の Exact Data Match (EDM) が機能しないと感じている場合、決して珍しいことではありません。このガイドでは、EDM ベースのデータ損失防止 (DLP) が想定どおりに動作しない理由を整理します。技術的な仕組みと必要な設定の理解から、重大なエラーの診断、複雑な問題の修正まで、段階的に解説します。

まず基本的な概念を確認し、そのうえで基本を超えた実際のトラブルシューティング手順を見ていきます。従業員情報を扱う場合でも顧客データを扱う場合でも、機密情報を保護するための有効な戦略を把握できるはずです。このヒントと方法は、規制対象の環境やエンタープライズ環境で Microsoft 365 を管理する管理者や技術チーム向けに特にまとめたものです。

Exact Data Match の概要と、よくある落とし穴

作業に取りかかる前に、Exact Data Match とは何か、そしてなぜ想像以上に多くの人がつまずくのかを明確にしておきましょう。EDM は、DLP ポリシーで極めて高精度な検出を行うための Microsoft 365 の機能です。マイナンバーや給与データなど、非常に機密性の高いフィールドを照合し、不要な情報を巻き込まないようにできます。目指すのは完璧な精度ですが、実際には、すぐにうまくいかないことも少なくありません。

このセクションでは、EDM の仕組みを解説します。暗号化ハッシュと、自分で設計する詳細なスキーマを使用する点がポイントです。また、EDM が常に完璧に動作しない理由にも触れます。多くの場合、その原因はスキーマの設定方法、データの準備方法、そして連携が必要な多数の技術的要素にあります。経験豊富な管理者でも、スキーマの問題、データの不一致、見落とされた設定手順によって苦労することがあります。

理論と、よく見られる「落とし穴」の両方を理解しておけば、よくあるミスを回避しやすくなります。この後の詳細セクションに進む前に、EDM が失敗する理由を把握し、自信を持って課題に対処できる状態を目指しましょう。

Exact Data Match とは何か、また本来どのように動作すべきか

Exact Data Match (EDM) は、従業員 ID や社会保障番号などの特定の機密情報を検出するための Microsoft 365 の機能です。環境内のデータを、安全にハッシュ化された参照リストと照合します。この処理では暗号化ハッシュを使用するため、元の平文データを Microsoft に公開することなく正確な値を照合できます。コンプライアンス要件の厳しい業界に適した仕組みです。

正しく設定されていれば、EDM によって DLP ポリシーを極めて精密に動作させ、追跡が必要な正確な機密データを含むファイルやメッセージだけをフラグ付けできます。組織が EDM を選ぶのは、正確で規制に準拠したデータ保護が不可欠な場面です。顧客、従業員、財務に関する実際のレコードを保護しつつ、一般的な DLP では避けられない誤検出を除外できます。

EDM 導入時のよくある落とし穴と課題

1. スキーマの不一致: EDM は緻密に設計されたスキーマに依存します。CSV の列が定義と一致しない場合、または順序が違う場合は、たった 1 つのミスでも照合処理全体が失敗する可能性があります。たとえば、ファイルのヘッダーで「従業員 ID」と「姓」を取り違えると、すぐに問題が発生します。
2. データ形式の不備: データの正規化や適切な形式設定を怠ると、たとえば SSN の形式が不統一だったり、余分な空白が含まれていたりすると、EDM が実際の機密レコードを検出できないことがあります。形式が時間の経過とともに変わるデータドリフトは、以前は正常に動いていた設定を静かに壊す可能性があります。
3. ハッシュ化またはアップロード手順の誤り: ハッシュ化されていないデータや、不適切にハッシュ化されたデータをアップロードすると、EDM は正しく動作しません。また、EDM Upload Agent を正しく使用しない場合や、アップロードの検証を省略した場合も、データが同期されない原因になります。
4. プライマリフィールドの問題: 一意ではないフィールド(例: 「生年月日」を「従業員 ID」の代わりに使用)を主要な要素として選ぶと、重複一致が発生したり、検出の信頼性が低下したりします。しきい値や完全一致モードの設定を誤解していると、検出漏れや不要な誤検出につながることもあります。
5. ユーザー定義データと回避: カスタムデータ型やユーザー定義のデータ型には、特有のリスクがあります。ユーザーが意図的に、あるいは偶発的にでもデータパターンを変更したり、フィールドを分割したりすると(電話番号を列ごとに分けてしまうなど)、照合ロジックが機能しなくなります。ユーザーの行動に注意し、パターンの変化に応じてスキーマを調整してください。
6. トークンとクエリの制限: EDMは、参照クエリと検索クエリの両方について、トークン(一意の単語や文字列)の数に厳しい上限を設けています。スキーマや環境が拡大すると、この上限を超えることがよくあります。超過するとエラーが発生し、慎重に監視していないと、検出機能が静かに停止してしまいます。
7. 監視の欠如とパフォーマンスの低下: 時間の経過とともに、「データドリフト」により、パフォーマンスや精度が低下することがあります。データドリフトとは、参照データの形式や値がEDMの想定から外れていく現象です。セキュリティ上の盲点が生じないようにするには、継続的な正常性チェックと定期的なスキーマの見直しが欠かせません。

断片化されたツールの所有権がMicrosoft 365の取り組みをどのように妨げるかについて詳しく知りたい場合は、こちらのディスカッションM365のガバナンスが失敗する理由をご覧ください。EDMを成功させるために必要な、システムレベルの考え方について補足的な背景が得られます。

EDM導入の前提条件とセキュリティ

Microsoft 365でEDMを稼働させるのは、スイッチを入れるだけの作業ではありません。機密性の高い従業員データや顧客データのアップロードを始めるずっと前に、技術面とセキュリティ面の確かな土台を整えることが重要です。このセクションでは、基盤となる要件を紹介します。インフラの準備状況、適切なアクセス許可の確認、そして既存のコンプライアンス戦略と実際に統合できるデータインポートポリシーの準備などが含まれます。

また、各段階でデータを保護する最善の方法も検討する必要があります。適切なセキュリティは、チェックボックスを埋めるだけのものではありません。転送や分析の最中でも、平文の記録が露出しないようにするための仕組みです。ここでは「何を」と「なぜ」の両方を理解していただくための基礎を説明します。ファイル構造、ユーザーロール、技術的な手順については次のセクションで詳しく取り上げますので、続く実践的なチェックリストとセキュリティの解説をお待ちください。

基本的なDLPの設定について詳しく知りたい場合は、Microsoft 365でDLPを設定する方法に関するポッドキャストのエピソードが参考になるでしょう。特にこの種のコンプライアンス制御が初めての方や、自動化のためにMicrosoft Copilotの検討を進めている方には、事前の予習として役立ちます。

インポートデータの技術要件と前提条件

• 現在のMicrosoft 365サブスクリプション: DLPおよびPurviewの機能が有効になっている、対象となるMicrosoft 365プランが必要です。EDMはすべてのプランで利用できるわけではありません。
• ロールベースのアクセス: 適切なコンプライアンス、DLP、またはPurviewのロールを持つ管理者のみが、EDMプロファイルを作成、管理、アップロードできます。セキュリティ・コンプライアンスチームのアクセス権を必ず再確認してください。
• データファイルの構造: 参照データはCSVファイルに保存する必要があります。これらのファイルは、スキーマと一致する一貫した列ヘッダーを持ち、余分なスペースや非表示文字があってはなりません。セルの結合や区切り文字の混在は避けてください。
• ファイルのアクセス許可とストレージ: 参照ファイルは、通常は保護された準拠のエンドポイント上で、アクセスを制限して安全に保存してください。認可されたアップロードエージェントだけがこれらのファイルを読み取れるようにする必要があります。
• アップロードツールとエージェント: 参照データを安全にハッシュ化して送信するには、公式のEDMアップロードエージェントを使用する必要があります。ブラウザーやサードパーティの方法はサポートされていません。
• ネットワークとシステムの準備: エージェントのホストには、信頼性の高いインターネット接続と、Microsoftが必要とするエンドポイントへの到達性が必要です。ファイアウォールやプロキシの問題があってはなりません。

EDMにおけるデータセキュリティとプライバシーへの配慮

EDMは、機密データがローカル環境から出る前に暗号化ハッシュを適用することで、セキュリティを真剣に扱っています。ハッシュ化の処理により、実際のマイナンバーや給与番号のような読み取り可能な平文が、Microsoftのクラウドに送信・保存されることは一切ありません。送信されるのは、EDMアップロードエージェントを介したハッシュ値(人間には判読できない文字列)のみです。

この設計により、Microsoft が実際のデータを見ることはありません。そのため、医療や金融など規制の厳しい分野における厳格なプライバシーおよびコンプライアンス要件を満たせます。転送中のすべてのデータは暗号化され、アップロードを管理できるのは承認された管理者のみです。これは、現代の企業および規制の要件に沿った仕組みです。DLP とテナントガバナンスの関連する手法を詳しく知りたい場合は、Microsoft Purview が高度なセキュリティと監視にどう役立つかをご覧ください。

正確なデータ照合のための EDM スキーマの構築

次は、EDM ソリューションの「設計図」であるスキーマについて説明します。スキーマの設定がわずかでも誤っていると、EDM プロジェクト全体が問題を起こす可能性があります。そのため、どのフィールドを主要フィールドにするか、列名をどう付けるか、そして論理が実際の業務シナリオとどう整合するかについて、特に慎重に検討する必要があります。

このセクションでは、適切に計画されたスキーマに時間をかけて投資することが、なぜ後々の利益につながるのかを解説します。その利益とは、検出精度の向上、誤検知の減少、そして組織のデータやワークフローが変化した際の将来への備えです。「必ず一致させる」フィールドと「一致すると望ましい」フィールドという、主要要素と副次要素の両方を整理することが、実際のポリシー適用を確実なものにするうえでなぜ重要なのかも紹介します。

以降のセクションでは、スキーマ設計へのアプローチ方法、ユースケースに合った照合ルールの定義方法、そして参照データの構造を実際に反映する照合モードの選び方を順に説明します。ここでの小さなミスが後に大きな問題を招くことがあるため、すぐに使える手順ベースのガイダンスを詳しく取り上げます。

EDM スキーマの作成と照合ルールの定義方法

1. 機密フィールドを特定する: まず、厳密な保護が必要なデータの種類を選びます（例: 従業員 ID、口座番号、SSN）。規制上の義務と事業上のリスクを把握してください。これらが主要なスキーマの候補になります。
2. フィールドの形式を標準化する: すべてのレコードで、各フィールドが同じ形式に従っていることを確認します。ハイフン、スペース、大文字と小文字が混在しないようにしてください。データの正規化（たとえば SSN を常に「123-45-6789」の形式で記録するなど）が重要です。
3. 主要要素と副次要素を設計する: 主要要素（一意の識別子）には、他の場所で重複しないフィールドを使用します（例: 従業員 ID）。副次要素には、近似一致や曖昧さを除外するのに役立つ補足情報（例: 生年月日）を使用できます。
4. CSV の列見出しをスキーマに合わせる: CSV ファイルの列見出しは、EDM スキーマ構成で定義されたものと（綴りと順序を含めて）完全に一致している必要があります。この手順は、ほかのどの手順よりも多くの失敗の原因になります。
5. データのドリフトと更新を考慮する: 実際のデータは時間とともに変化します（新しい形式や新しい値など）。定期的に列見出しとフィールドの種類を確認し、スキーマに柔軟性を持たせて、気付かないうちに精度が低下するのを防いでください。
6. サンプルデータでテストする: テスト用の CSV ファイルを使って、スキーマが実際にどのように一致するかをシミュレーションします。誤検知や検出漏れがないか確認し、必要に応じて照合ルールを調整してください。
7. 複雑にしすぎない: 不要なフィールドや「念のため」の列は含めないでください。実際に照合したい項目だけに絞ります。使われていない列は、EDM で混乱や照合エラーを招く可能性があります。

照合モードの設定と主要要素の選択

• 照合の種類を慎重に選ぶ: 参照値のみを検出したい場合は「完全一致」モードを使用します（SSN などの規制対象データに最適です）。「しきい値」や「あいまい」モードは、ある程度近い一致でも許容できる場合に利用できますが、誤検知が増えるリスクを考慮してください。
• 主要要素を慎重に割り当てる: 主要フィールドには、本当に一意のデータを使う必要があります。名（ファーストネーム）や部署のように重複しうるフィールドは使わないでください。従業員 ID や口座番号が、ベストプラクティスとして適しています。
• フィールドの制約を設定する: スキーマのフィールドの種類が、基になるデータ型（数値、文字列など）と一致していることを確認します。不整合があると、正しく照合できなかったり、ポリシーがスキップされたりする原因になります。
• 誤検知と検出漏れをテストする: サンプルの検出を実行して、機密レコードが正しく検出されること、そして無関係なレコードが DLP ポリシーを誤ってトリガーしないことの両方を確認します。

機密データの EDM プロファイル用の準備とアップロード

EDMの設定では、参照データのアップロード準備を丁寧に行うことが欠かせません。これは、試合当日に主力選手を準備するようなものです。単にファイルを置けばよいわけではなく、一貫した結果を得るために、エラーのないクリーンで安全に整形されたデータセットが必要です。

このセクションでは、データ準備（厳密な書式設定、検証チェック、安全なアップロード手順を含む）が、正確性だけでなく、開始から終了まで最高水準のデータ保護にもつながる理由を解説します。この工程を正しく行うことで、本番環境で問題が大きくなる前に発見でき、組織の機密性の高いレコードを危険から守ることができます。

次に、CSVファイルの構成手順、EDM Agentを使った安全なアップロードの手順とツール、検証の流れを順に説明します。これにより、元の平文が漏れることなく、データを準備した状態でMicrosoft 365に届けられます。

データの書式設定、ダウンロード、アップロード検証の手順

• CSVファイルをスキーマどおりに構成する: 参照用CSVの列見出しを、EDMスキーマで入力した内容と一致させます。余分な列、誤字、順序の入れ替えがないように注意してください。
• データ型と値を検証する: 欠損、重複、書式の誤りがある行を確認します。SSNはすべて同じパターンに従う必要があり、日付はYYYY-MM-DD形式にするなどの確認を行います。
• 余分な文字を削除する: 末尾の空白、印刷できない文字、フィールド内の不要な区切り文字を取り除きます。判断に迷う場合は、データ検証スクリプトでテストしてください。
• アップロード前の検証を実行する: 組み込みの検証ツールを使用するか（またはEDM Upload Agentでサンプルのドライランを実施して）、本番アップロードの前に、CSVとスキーマの不一致を検出します。
• 監査証跡を残す: ファイルのバージョンを管理し、アップロードや検証の実行ログを保存します。また、コンプライアンス監査に備えて、元データとハッシュ化されたデータの両方を安全に保管します。

機密データのハッシュ化と安全なアップロード

EDM Upload Agentは、平文の参照データを、お使いのインフラストラクチャ上で安全な暗号化ハッシュに変換します。つまり、実際の機密値が環境の外に出ることはなく、Microsoft 365のサーバーに送られるのはハッシュ化された値だけです。

この処理はアップロードの前と途中で行われるため、各段階で機密性が確保されます。クラウドへの送信は暗号化され、一致の判定に使われるのはDLPエンジンだけです。これによりコンプライアンスチームの懸念は解消され、組織の機密データが危険にさらされることを防げます。SharePointやPurviewなどのツールでも、エンタープライズコンテンツ管理と監査対応の取り組みを組み合わせて、この点を支えることができます。

EDMとデータ損失防止ポリシーの統合

参照データをMicrosoft 365のDLPポリシーのルールに直接結び付けたとき、EDMの真価が発揮されます。正しく行えば、Outlook、Teams、SharePoint、Power Platformのいずれを利用していても、細かく調整されたデータ保護を組織に適用でき、情報漏えいを防げます。

このセクションでは、DLPポリシーをEDMスキーマに実際に向ける際に必要な作業を説明します。これは単なる技術的な連携ではなく、どの種類のデータでアラートを発生させるか、インシデントをどのようにエスカレーションするか、実際に一致が見つかった場合に通知をどこへ送るかといった判断も伴います。

複雑な環境でDLPポリシーを調整している場合は、確かなガバナンスと環境戦略を軽視しないでください。この点は、DLPポリシーを管理するPower Platform開発者向けのポッドキャストや、内部者の視点に焦点を当てたDLPの回復力に関する議論でも取り上げられています。

EDMの検出結果の検証と確認

• テストデータセットをアップロードする: 実際のシナリオを再現するために、既知の参照データ（ダミーの従業員IDや口座番号など）を少量用意し、環境に投入します。
• DLPポリシーを作成し、EDMスキーマを参照する: DLPポリシーを設定済みのEDMスキーマに直接向け、検出ルールで正しいフィールドと一致モードが指定されていることを確認します。
• サンプルファイルでポリシーをトリガーする: テスト用の参照値を含むコンテンツを、監視対象のアプリ(Outlook、Teams、SharePoint)で共有またはアップロードし、ポリシーが実際にトリガーされるかを確認します。
• ポリシーのログとアラートを確認する: インシデントレポート、アラートログ、コンプライアンスダッシュボードをすぐに確認し、一致が記録されているかを調べます。誤検知(false positive)と、見逃した可能性のある検知(false negative)の両方に注意してください。
• エンドツーエンドのワークフローを検証する: DLP のアクション(通知や強制的な制限など)が実際にトリガーされたこと、そしてインシデントの確認などのワークフローがポリシーの想定どおりに動作していることを確認します。
• 検知率を定期的に監視する: 分析ツールやダッシュボード(継続的なコンプライアンス監視に関するこちらのガイドで紹介されているものなど)を使い、利用パターンの変化に合わせて一致率の推移を確認し、ずれ(ドリフト)やパフォーマンスの問題を早期に見つけます。

EDM のトークン上限とセットアップの障害のトラブルシューティング

適切にセットアップしていても、EDM は、必要なときに限って不具合を起こすことがあります。トークンの上限、スキーマ接続の不備、見落としたセットアップ手順によって、一致の機能が静かに停止したり、機密データが気づかないうちに外部へ流出したりすることがあります。

このセクションでは、EDM ポリシーの障害の根本原因、特に厄介なトークン上限エラーとセットアップ上の落とし穴について説明します。どのログやエラーメッセージを確認すればよいか、また実装を元に戻したり調整したりして機能を回復させる方法を解説します。

継続的な監視と運用チェックを行わないと、これらの障害はすぐに大きなコストにつながりかねません。そのため、理論だけでなく、実践的な診断と是正の方法をご紹介します。以下のヒントで「何が壊れているのか」を切り分け、DLP ツールキットの運用上の確実性を取り戻しましょう。

最大トークン数と EDM の制限のトラブルシューティング

• クエリにおけるトークンの過剰: EDM では、一致に使用できるトークンの上限が設定されており、通常はスキーマごとに数万トークンまでです。スキーマやクエリがこの上限を超えると、「maximumNumberOfTokens」エラーが表示されます。対処法: 参照データの範囲を絞るか、大きなインポートを複数の小さな EDM プロファイルに分割してください。
• 範囲が広すぎる DLP ルール: 広範囲のデータを対象とするポリシーは、意図せず多くのトークンを対象に含めてしまい、上限に達する原因になります。ポリシーのフィルターを絞るか、データセットごとに検出ルールを分けてください。
• 混在した、または変化するデータ形式: データのずれによって新しい値や形式が加わると、トークン数が急増することがあります。インポートしたデータを定期的に確認し、無関係または古くなった参照値を検出して除外してください。
• サイレントな障害の監視: クエリサイズに関する警告がないか、システムの正常性ダッシュボードを定期的に確認してください。トークンに関するエラーの多くは、ユーザーに目に見える通知を出さないためです。

EDM のセットアップと一致結果の障害の診断

• スキーマとデータの不一致: CSV の列ヘッダーと順序が EDM スキーマと完全に一致しているかを、もう一度確認してください。単純なタイプミスや列の欠落によって、すべての一致が失敗する可能性があります。
• 一致ルールまたはモードの誤り: 一致モード(「Exact」か「Threshold」か)が、ポリシーの意図と参照データの実態に合っているかを確認してください。必要に応じて調整します。
• ハッシュのアップロードの不完全または失敗: アップロードエージェントのログでエラーや未完了のアップロードがないか確認してください。ネットワーク障害や中断があった場合は、検証済みのデータを改めてアップロードする必要があります。
• 古くなった参照データ: 業務データは変わっているのに、EDM を更新していないことはありませんか。古いプロファイルは実態を反映しなくなるため、定期的な再アップロードをスケジュールしてください。
• ログの確認とエラーコード: 詳細なエラーを確認するため、コンプライアンス センターのログやシステムのイベントログを調べてください。一致の失敗、取り込みエラー、アップロードエージェントの警告を検索します。

信頼性の高い EDM の運用のためのベストプラクティスと重要なポイント

ここまで多くのことを見てきましたが、ここで一度立ち止まって、「期待だけ」の EDM 導入と、本番環境で本当に強固なソリューションを分けるポイントを確認しましょう。EDM を安定して動かし、新しい状況への対応、サイレントな障害の回避、独自のデータ型の処理を続けるには、導入直後の盛り上がりが過ぎても効果が続く戦略が必要です。

最も安定して運用されている環境では、スキーマを綿密に管理し、ユーザー定義フィールドを検証し、ビジネス環境の変化に合わせてEDMが実際の一致を検出し続けるよう、継続的なチェックを整備しています。セットアップを正しく行うことと同じくらい、コンプライアンスのドリフトやデータの変化がどのように起こるかを理解することも重要です。隠れたドリフトと長期的なコンプライアンスへの影響について関心がある場合は、Microsoft 365 のコンプライアンス ドリフトに関するポッドキャストと、Microsoft Fabric におけるセマンティック データ モデルのドリフトに関する解説もあわせてご覧ください。

この基盤を踏まえて、カスタム データを対象とした重点的なプラクティスと、EDM の導入を正しく維持するためのシンプルなチェックリストで締めくくります。

EDM におけるユーザー定義およびカスタム データの実践的なプラクティス

• 一貫した形式を維持する: 従業員 ID など、すべてのカスタム フィールドに標準の形式を定義し、この形式に合わないアップロードは拒否します。
• 新しいデータを定期的に対応付ける: 形式や値のドリフトがないか、業務システムとのスキーマの整合性を四半期ごとに確認します。
• フィールドの変更を文書化する: スキーマを変更するたび、または新しいフィールドを追加するたびに変更履歴を記録し、数か月後に誰も内容を追えなくなる事態を防ぎます。
• 実際のユーザーを巻き込む: 人事、財務、または業務部門のユーザーに「実際の」データがどのような形かを尋ね、スキーマが変化する作業慣行に追随するようにします。
• 誤検知ではなく見逃しを監視する: DLP が検出できなかったケースや回避の試みの後にフィードバックを収集し、それに応じて一致ロジックを調整します。

Exact Data Match を成功させるための重要なポイントと概要

• スキーマを慎重に設計する: 適切な設計は手戻りの時間を節約し、一致の精度を保ちます。
• 継続的に検証し、監視する: 定期的な監査とDLPインシデントのサンプル確認により、ビジネス リスクが拡大する前に問題を早期に発見できます。
• データ セキュリティを最優先する: すべての段階で、参照データをハッシュ化して保存し、最上級の暗号化ツールを使って送信するようにします。
• データ ドリフトに注意する: スキーマと参照リストを更新し、ビジネスの実態に合わせます。古い、または不整合なデータでは EDM は成功しません。
• フィードバック ループを活用する: ユーザーからの利用体験のレポートとインシデントのレビューが、ギャップを埋めポリシーを改善する最も速い方法です。