Microsoft Edge で「ページ上のオーバーレイに埋め込んだ PDF だけが真っ白で表示されない」「Chrome では見えるのに Edge だけダメ」という問い合わせは、社内ポータルや業務システムを運用していると非常に起きやすいトラブルです。本記事では、その主な原因となる Edge のトラッキング防止機能と互換例外リスト（CompatExceptions）の仕組み、そして現実的な回避策・申請方法をまとめて解説します。
Edge のトラッキング防止で iframe 内 PDF が表示されない現象とは
社内ポータルや業務 Web アプリで、画面上に半透明のオーバーレイを表示し、その中に <iframe> で PDF を埋め込む UI はよく使われます。しかし Microsoft Edge では、トラッキング防止機能が有効な場合、以下のような現象が起こることがあります。
- iframe 内に読み込んだ PDF が真っ白のまま表示されない
- Edge の DevTools で確認すると、PDF の URL へのリクエストがブロックされている
- 同じ URL を新しいタブで直接開くと PDF は問題なく表示される
- Chrome や他のブラウザでは表示できるが、Edge のみ表示されない
これは多くの場合、Edge のトラッキング防止機能が「トラッカー」と判断したリソースを iframe 内から読み込もうとしたためにブロックされたことが原因です。単に PDF だからブロックされているのではなく、読み込み元のドメインがサードパーティ扱いになっている、あるいは 既知のトラッキングドメインとして判定されているために、PDF ビューアごと止められてしまう、というイメージです。
なぜオーバーレイの iframe だけが影響を受けるのか
「同じ PDF を直リンクで開けば表示できるのに、オーバーレイ iframe の時だけブロックされる」というケースでは、以下の要素が組み合わさっていることが多いです。
- 親ページのドメイン A と PDF を配信しているドメイン B が異なる
- ドメイン B が広告・トラッキング用途に使われがちな CDN や汎用ホスティングである
- Edge のトラッキング防止モードが「バランス」または「厳重」に設定されている
Edge は、サードパーティコンテキスト（別ドメインが iframe などで埋め込まれている状況）を特に厳しく監視します。その結果、PDF を表示するだけの iframe であっても、ドメインの履歴やフィルタリストの評価によっては「トラッカー」とみなされ、リクエスト自体をブロックしてしまします。
そのため、単純に「PDF ビューアのバグ」と捉えるのではなく、「トラッキング防止が働くコンテキストで PDF を読み込んでいる」という構造的な問題として理解することが重要です。
互換例外リスト（CompatExceptions）とは何か
Microsoft Edge には、トラッキング防止機能との互換性のために、Microsoft が中央管理している互換例外リスト（CompatExceptions）が存在します。ここに登録されたサイトは、トラッキング防止によるブロックが緩和され、通常のユーザー操作で問題なく利用できるように調整されます。
重要なのは、この互換例外リストがすべての Edge にオンライン更新で一括配信される点です。つまり、ここに自社ドメインが登録されれば、エンドユーザー側で個別設定を行わなくても、自社サイトがトラッキング防止によって壊れるリスクを大きく下げることができます。
しかし、現時点では次のような制約があります。
- 自社で自由に登録・削除できる公開フォームは存在しない
- 「このドメインを例外にしてほしい」という要望は、基本的に Microsoft へのフィードバックとして扱われる
- 採用されるかどうかは、再現性・影響範囲・要望の多さなどによって Microsoft 側で判断される
そのため、「フォームに申し込むだけで確実に入れてもらえる仕組み」ではないことを前提に、正式なルートから要望を上げていく必要があります。
エンドユーザーに Edge の例外設定をさせるのが現実的でない理由
理屈の上では、ユーザーに対して Edge の設定画面 edge://settings/privacy/trackingPreventionExceptions を開いてもらい、そこに自社サイトを登録してもらうことで、この問題を回避できます。しかし、現場では次のような理由から現実的ではありません。
- 毎回エンドユーザーに手順説明を行う必要があり、ヘルプデスク負荷が高い
- ミスや入力漏れが発生しやすく、トラブルの再発を完全には防げない
- PC を入れ替えるたびに再設定が必要で、運用コストがかかる
- セキュリティポリシー上、ユーザーに細かなブラウザ設定をさせたくない企業も多い
つまり、ユーザー操作による恒久回避策はスケールしないのが実情です。そこで現実的な解決策として、次の二つが主に検討されます。
- Microsoft に公式ルートで互換例外登録を要望する
- 企業管理の端末であれば、グループポリシーや Intune で例外設定を一括配信する
Microsoft への正式な申請ルート：Windows Feedback Hub
Microsoft 製品の挙動変更や新機能追加を Microsoft に直接要望する、もっとも公式かつ推奨されているルートは、Windows Feedback Hub アプリです。Microsoft Edge の挙動に関する要望も、基本的にはこの Feedback Hub から登録します。
Feedback Hub から要望を送る手順
Feedback Hub の基本的な操作の流れは以下の通りです。
- Windows のスタートメニューから「Feedback Hub」または「フィードバック Hub」で検索し、アプリを起動する
- 左側メニューの「フィードバックの送信」を選択する
- タイトル欄に、問題の概要（例：
「Microsoft Edge のトラッキング防止により iframe 内 PDF が表示されない」）を入力する - 詳細欄に、具体的な現象・再現手順・影響範囲をできるだけ詳しく記載する
- カテゴリで「Microsoft Edge」関連の項目を選択する
- 可能であれば、再現時のスクリーンショットや診断情報の送信も許可する
- 送信後、公開されたフィードバックに対して、社内・関係者からの投票を集める
Feedback Hub では、同じ問題に対して多くのユーザーからの共感票（投票）が集まるほど優先度が上がりやすいとされています。自社だけでなく、同様の構成を取っている他社・他部署にも協力を依頼し、複数の環境からフィードバックや投票を行ってもらうことで、採用される可能性を高めることができます。
要望文のポイント：単なる「お願い」ではなく「互換性の問題」として伝える
Feedback Hub の要望文を書く際は、単に「例外リストに入れてほしい」と書くだけでなく、既存サイトとの互換性問題であり、ビジネスの継続性に影響するという点を明確にすると良いでしょう。
例えば、次のような情報を含めると説得力が増します。
- 影響を受けているサイトの URL（できれば公開ドメイン）
- 利用者数や対象ユーザー（社内数千人が利用する業務システムなど）
- Edge のトラッキング防止を無効化すると再現しないこと
- Chrome や別ブラウザでは継続利用できるが、Edge のみで問題が出ること
- PDF をサードパーティドメインから iframe で読み込む技術的背景
こうした情報を盛り込むことで、Microsoft 側にとっても 「実際の業務に支障が出ている互換性問題」として認識されやすくなります。
企業で早期に対応したい場合の選択肢：サポート契約の活用
Feedback Hub 経由のフィードバックは重要ですが、対応時期や結果が保証されるものではありません。企業で早急に対処したい場合は、以下のような有償サポートルートも検討できます。
Edge Enterprise サポート／ビジネス向けサポートの利用
企業として Microsoft の有償サポート契約（Enterprise サポートなど）を結んでいる場合、次のような流れで対応を依頼できます。
- 社内の Microsoft 契約担当やパートナー企業に連絡する
- Edge のトラッキング防止が原因と考えられる互換性問題であることを説明する
- 再現手順・ログ・構成図などを添えてサポートチケットを起票してもらう
- 必要に応じて、Microsoft エンジニア部門にエスカレーションされる
このルートを使ったからといって必ずしも互換例外リストに登録されるわけではありませんが、少なくとも 「企業向け重要事象」として扱われ、技術的な分析や代替案の提示を受けやすくなるメリットがあります。
社内だけで例外を適用したい場合：グループポリシー／Intune
互換例外リストはすべての Edge に一括配信される仕組みですが、企業のイントラネットや VDI 環境であれば、自社テナント内だけでトラッキング防止の例外を配布する方法もあります。それが、グループポリシー（GPedit）や Microsoft Intune 管理テンプレートでの TrackingPreventionExceptions ポリシー設定です。
TrackingPreventionExceptions ポリシーの概要
TrackingPreventionExceptions ポリシーでは、特定のドメインに対してトラッキング防止を無効化（もしくは緩和）する設定を、一括展開できます。これにより、次のような構成が可能になります。
- 社内ポータル（
portal.example.co.jp）と PDF 配信サーバー（pdf.example.co.jp）をまとめて例外登録 - マルチテナント SaaS を利用している場合は、対象テナントのドメインのみ例外登録
あくまでテナント内の管理対象端末に対してのみ適用されるため、一般家庭のユーザーや BYOD 端末には影響しません。その代わり、企業環境ではユーザー操作なしで安定した動作を保証できる点が大きなメリットです。
グループポリシーでの設定イメージ
オンプレミス AD で GPO を利用している場合、大まかな手順は次のとおりです。
- 最新の Microsoft Edge 用 ADMX テンプレートをダウンロードしてドメインコントローラーに展開する
- グループポリシー管理エディターで、対象 OU に新しい GPO を作成する
- 「コンピューターの構成」または「ユーザーの構成」から、Microsoft Edge の管理テンプレートを開く
TrackingPreventionExceptionsに相当するポリシーを有効にし、例外としたいドメインを設定する- GPO をリンクし、クライアントで
gpupdate /forceを実行して反映を確認する
実際のキー名や構成形式は Edge のバージョンや ADMX の更新によって若干変わる可能性がありますが、基本的な考え方は「特定ドメインを Edge のトラッキング防止対象から除外する」ものとして理解すれば十分です。
Intune（Microsoft Endpoint Manager）での展開イメージ
Intune を利用している場合は、管理テンプレート／構成プロファイルから同様のポリシーを配布します。
- Intune 管理センターにサインインする
- 「デバイス」→「構成プロファイル」から新規プロファイルを作成する
- プラットフォームを「Windows 10 以降」、プロファイルタイプを「テンプレート」→「管理用テンプレート」にする
- Microsoft Edge のテンプレートから
TrackingPreventionExceptionsに相当する設定を探し、対象ドメインを入力する - 対象グループ（デバイスまたはユーザー）に割り当てる
このように、企業管理下の端末であれば、ユーザーの操作なしに一括で例外設定を展開できるため、社内向け業務システムでは非常に有効なアプローチとなります。
対処パターンの比較表
ここまでに登場した対処パターンをまとめると、次のようなイメージになります。
| 対処パターン | 対象範囲 | 即効性 | 運用コスト | 備考 |
|---|---|---|---|---|
| Feedback Hub からの要望 | 全世界の Edge ユーザー | 低い（反映時期は不明） | 中（情報整理と継続的な投票が必要） | もっとも公式なルート、互換性改善全般に寄与 |
| 有償サポート契約からのエスカレーション | 契約企業の案件として扱われる | 中（重要事象として扱われやすい） | 中〜高（契約費用・チケット起票が必要） | 技術的な調査や代替案の提示を受けやすい |
| グループポリシー／Intune で例外配布 | 社内の管理対象端末のみ | 高い（設定配布後すぐに有効） | 中（初期設計・検証が必要） | ユーザー操作が不要で運用が安定しやすい |
| ユーザー個別に Edge 設定で例外登録 | 設定したユーザーの端末のみ | 高い（その場で有効） | 高い（説明・サポートが必要） | 小規模テストや一時的な回避策としてのみ現実的 |
実装側でできる回避策・工夫
Microsoft による互換例外登録や企業ポリシー配布には時間がかかることがあります。その間の暫定対応として、実装側で取り得る回避策も検討しておきましょう。
PDF を同一ドメインで配信する
もっとも効果的なのは、PDF を可能な限り親ページと同じドメイン（またはサブドメイン）で配信することです。例えば、次のような構成になっている場合：
- 親ページ：
https://portal.example.co.jp/app - PDF：
https://cdn-files.example.net/docs/XXX.pdf
これを、可能な範囲で次のように変更します。
- PDF：
https://files.example.co.jp/docs/XXX.pdf
Edge のトラッキング防止は、「サードパーティコンテキスト」かどうかを重要視します。同一ドメイン（あるいは同一サイト扱い）での配信であれば、ブロックされる可能性を大きく減らせます。
Content-Disposition: inline ヘッダーを付与する
サーバーから PDF を返す際に、HTTP ヘッダーで Content-Disposition: inline を指定しておくと、ブラウザーは PDF を「添付ファイルとしてダウンロード」ではなく、「埋め込みで表示する」方向に動きやすくなります。
簡略化したレスポンスヘッダーのイメージは次の通りです。
Content-Type: application/pdf
Content-Disposition: inline; filename="document.pdf"
これだけでトラッキング防止のブロックが完全に解除されるわけではありませんが、「iframe 内 PDF は表示せずダウンロードのみ」というブラウザ側の振る舞いを避けるうえで有効なことがあります。
iframe 以外の表示方式を検討する
どうしてもトラッキング防止の影響が強く、互換例外登録や企業ポリシーでの回避も難しい場合は、PDF を iframe で直接表示しない UI に切り替えることも選択肢になります。
- <embed> タグで表示する
一部ブラウザでは<embed>を使った PDF 表示の方が安定することがあります。 - サムネイル＋ダウンロードボタン方式にする
プレビュー画像やタイトルだけを表示し、クリック時には別タブで PDF を開く／ダウンロードさせる方式です。 - PDF ビューアの JS ライブラリを導入する
Mozilla PDF.js などのライブラリを利用し、自前のビューア画面で表示する方法もあります。ただしライブラリ自体がサードパーティドメインから配信されている場合は、同様の問題が再発する可能性があります。
いずれの方法も、セキュリティポリシーやアクセシビリティ、操作性とのバランスを考慮しながら選択する必要があります。
Feedback Hub への要望テンプレート例
実際に Feedback Hub から互換例外リストへの登録を要望する際に使える、日本語の説明テンプレートの例を用意しておきます。自社の状況に合わせて書き換えて利用してください。
タイトル：
Microsoft Edge のトラッキング防止により iframe 内の PDF が表示されない
詳細：
当社の Web システム（https://portal.example.co.jp）において、
画面上のオーバーレイウィンドウに <iframe> で PDF を埋め込んで表示しています。
しかし Microsoft Edge のトラッキング防止機能が有効な環境では、
iframe 内の PDF が読み込めず、真っ白な画面のまま表示されない問題が発生しています。
Edge の設定画面で当該サイトをトラッキング防止の例外に登録した場合は、
問題なく PDF を表示できます。また、Google Chrome 等の他ブラウザでも再現しません。
本システムは社内ユーザー約 XXXX 名が業務で日常的に利用しており、
Edge のデフォルト設定のままでは業務に支障が出ております。
つきましては、互換性向上のため、当該ドメインを
Microsoft Edge の互換例外（CompatExceptions）の対象としてご検討いただけますでしょうか。
再現手順：
1. Edge でトラッキング防止を「バランス」以上に設定
2. https://portal.example.co.jp にアクセス
3. 任意の文書を開き、オーバーレイで表示される PDF を確認
4. 画面が真っ白で PDF が表示されない
期待する結果：
互換例外が適用され、通常のトラッキング防止設定のままでも
iframe 内の PDF が表示されること
このように、現象の再現手順・影響範囲・期待する結果を明確に書くことで、Microsoft から見て「どのような改善が求められているのか」が分かりやすくなります。
今後のバージョンアップと Preview ビルドの確認
Microsoft Edge は、セキュリティポリシーや管理テンプレートが四半期ごと、あるいはそれ以上の頻度で更新されています。Feedback Hub で要望が「受理済み」「進行中」となったケースでは、次のような形で反映状況を把握できることがあります。
- Edge の Beta/Dev チャンネルのリリースノートに、関連項目が追加される
- 新しいポリシー項目や互換性修正が、管理テンプレートの更新として配信される
- 一部のドメインで、トラッキング防止によるブロックが緩和される
企業のシステム担当者としては、本番環境とは別に検証用の Edge Preview 環境を用意し、互換性修正やポリシー変更が自社システムにどう影響するかを継続的に確認することが望まれます。これにより、本番反映前に問題の有無を把握し、必要に応じて UI や構成の微調整を行うことができます。
設計段階で意識しておきたいポイント
最後に、これから新しいシステムを設計する際に、同様の問題を避けるために意識しておきたいポイントをまとめておきます。
| 観点 | 推奨アプローチ | 備考 |
|---|---|---|
| PDF 配信ドメイン | 可能な限り親ページと同じドメイン／サブドメインを利用する | サードパーティ扱いを避けることでトラッキング防止の影響を軽減 |
| 表示方式 | iframe 以外の方式（<embed>、自前ビューア、別タブ表示など）も候補に入れる | UI/UX とセキュリティの要件に応じて選択 |
| HTTP ヘッダー | Content-Disposition: inline を付与し、ブラウザ埋め込み表示を前提とする | ダウンロードのみを想定したヘッダーは避ける |
| ブラウザ検証 | Edge（トラッキング防止有効）での検証を標準テストに含める | Chrome だけでの検証では問題を見落としやすい |
| 運用設計 | 問題発生時の回避策（GPO/Intune、Feedback Hub 要望など）をあらかじめ決めておく | ヘルプデスクと連携したエスカレーション手順も整備 |
まとめ：現時点での現実的な戦略
Microsoft Edge のトラッキング防止によって、オーバーレイ iframe 内の PDF が表示されない問題は、一見すると「ブラウザのバグ」のように見えますが、実際にはセキュリティと互換性のトレードオフの中で生じている挙動です。
現時点で取れるもっとも現実的な戦略は、次のような組み合わせになります。
- まずは実装側で、可能な限り同一ドメイン配信・適切な HTTP ヘッダー・代替表示方式を検討する
- 業務影響が大きい場合は、Feedback Hub から互換例外リスト登録を要望する
- 企業管理の端末については、グループポリシーや Intune の
TrackingPreventionExceptionsポリシーを活用し、ユーザー操作なしで例外設定を配布する - 必要に応じて、Microsoft の有償サポートやアカウントチームを通じて技術的な支援を得る
「ブラウザ側の問題だから Microsoft が何とかしてくれるはず」と受け身で待つのではなく、開発・インフラ・ヘルプデスク・ベンダー・Microsoft を巻き込んだ総合的なアプローチを取ることで、ユーザーにとってストレスの少ない安定した PDF 閲覧体験を実現していきましょう。
コメント