IEモード依存システムの脱却ガイド

1. この記事を一言で

「IEモードを正式運用で安全に使いながら、依存を少しずつ減らして、最終的にIEモードをゼロにする」 ── これが現実的な戦略です。捨てる前に、まずはきちんと管理しましょう。

この記事で使う用語

以降で繰り返し出てくる用語を先にまとめます。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全23件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 背景：IEモードは「いつまで」使えるのか

ここで押さえておきたいのは、2029年まで使えるからといって安心して放置してよいわけではない、という点です。この期間はあくまで「計画的に脱却するための猶予」であり、2029年ギリギリになって慌てないためには、今から準備を始めておくしかありません。

3. なぜ IE モード依存から抜けられないのか

IE モードは、Chromium ベースの Edge の中で、古いサイトだけを Trident（MSHTML）エンジン で描画する仕組みです。この Trident エンジンが引き受けているものは次のとおりです。

• 古い文書モード（Document Mode）
• ActiveX コントロール / BHO（Browser Helper Object）
• 古いセキュリティゾーン設定
• Enterprise Mode の互換設定

これらに依存している限り、ブラウザを最新にしただけでは問題は解決しません。依存の正体を見極めることが第一歩です。

現場でよく起きるトラブル

1. 文書モードの設定ミス → 画面が崩れる、スクリプトエラー
2. ニュートラルサイトの設定漏れ → SSO（シングルサインオン）で再認証ループやリダイレクトループが発生
3. Enterprise Mode Site List の形式違い → IE モード連携では schema v.1 がサポートされず、schema v.2 への移行が必要
4. Edge はサイトリストを1つしか処理しない → Edge 側ポリシーが IE 側ポリシーより優先される

依存の分類：まず「何に依存しているか」を見極める

4. ステップ1：延命策 ── まずは安全に運用する

1. サイトリストをちゃんと管理する（最重要）

ユーザー任せの「再読み込み」は危険です。ポリシーで正式に管理しましょう。

やるべきこと: Cloud Site List Management に移行し、誰が・どのサイトを・いつまで IE モードで使うのかを一元管理する。

サイトリスト XML の最小例

サイトリストは Enterprise Mode Site List の schema v.2、つまりルート要素が <site-list> の XML で書きます。最小構成はこれだけです。

<site-list version="1">
  <!-- IE モードで開くサイト -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- 認証サーバー: 遷移元のエンジンのまま開く（ニュートラルサイト） -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

書くときの注意点は次のとおりです。

• url にプロトコルは書きません。contoso.local と書けば http と https の両方に適用されます。
• <open-in>IE11</open-in> を指定したサイトが IE モードで開きます。
• <compat-mode> は IE モード側で使う文書モードの指定です（IE8Enterprise、IE7Enterprise、Default など）。
• <open-in>None</open-in> がニュートラルサイトの指定です。認証サーバーはこちらに入れます。
• version はサイトリストの版番号です。リストを更新したら値を上げます。

配布に使うグループポリシー

サイトリストを配るには、グループポリシーを2つ設定します。どちらも「ユーザーの構成」「コンピューターの構成」のどちらからでも設定できます。

サイトリストの場所には、HTTPS の URL（推奨）、ネットワーク共有のパス、ローカルファイルのパスを指定できます。IE 側にも同じ役割の「Use the Enterprise Mode IE website list」（管理用テンプレート > Windows コンポーネント > Internet Explorer）がありますが、Edge 側のポリシーを設定するとそちらが優先されます。全社には IE 側のポリシーで本番リストを配り、パイロット部署にだけ Edge 側のポリシーで検証用リストを配る、という使い分けができます。

2. 認証まわりの設定を固める

SSO が絡むと、IE モード⇔Edge モード間の遷移で認証が壊れることがよくあります。

ニュートラルサイト（Neutral Site） は、IE モードと Edge モードのどちらでも「遷移元のエンジンのまま開く」ことを指定する設定です。認証・SSO の中継サイトをここに登録しておかないと、IE モードで開いているページから認証サーバーへ飛んだ瞬間に Edge 側へリダイレクトされ、認証が失敗します。Microsoft のドキュメントでも、IE モードを正しく動かすには認証・SSO サーバーを明示的にニュートラルサイトとして構成する必要がある、と説明されています。

• ニュートラルサイト を正しく設定する → SSO サーバーを <open-in>None</open-in> で明示的に指定
• 必要に応じて Cookie 共有 を設定する（既定では Edge と Internet Explorer のプロセスはセッション Cookie を共有しません）
• 認証サーバーがどれか分からない間は、edge://net-export でネットワークログを取って遷移先を洗い出す
• どうしても認証サーバーを特定できない間は、一時的に「IE モードでページ内ナビゲーションを保持する」ポリシーを使う（ただし確定したら無効化する）

3. 診断ツールを使いこなす

感覚ではなく、観測データ で判断します。

4. どうしても直せない部分は「隔離」する

5. ステップ2：脱却策 ── 依存をどう減らすか

パターン比較表

★ が実務上の第一候補です。

「目安工数」の読み方

表の人月は、社内システム1つ分を想定したレンジであり、そのまま見積もりに使える数字ではありません。同じパターンでも、画面数、IE モード対象 URL の数、ActiveX / BHO の種類、SSO 経路の数、外部連携の本数、必要な受け入れテストの量で数倍変わります。この表は「パターン間の相対的な重さ」を比べるためのものだと考えてください。

実際に見積もる場合は、まず次を数え、自社の実績（1画面あたりの改修工数、1経路あたりの認証検証工数）を掛けて積み上げます。

• 画面数と帳票数
• IE モード対象 URL の数（Enterprise Site Discovery の棚卸し結果）
• ActiveX / BHO の種類と、それぞれの代替手段の有無
• 認証・SSO 経路の数
• 旧新が並行稼働する期間
• 回帰テストのケース数と、そのうち手動確認が必要な割合

各パターンの使いどころ

段階的リファクタリング が最も現実的です。

• いきなり全部作り直す必要はない
• 画面や機能を1つずつモダン化していけばよい
• 新旧が混在する期間の「導線設計」（どの画面がどのエンジンで動くか）が重要

WebView2 ラッパー は「境界を切り直す」ために使います。

• ActiveX や COM 依存をそのまま温存するためではない
• 「ファイル操作」「機器連携」「Windows 認証」などの OS 側の責務をネイティブ側に寄せ、Web UI 側をモダン化する
• ただし WebView2 Runtime の配布責任が発生する点に注意

マイクロフロントエンド は「チーム境界」と「デプロイ境界」が一致している場合にのみ有効です。流行っているからという理由で採用すべきではありません。

全面リライト は最後の手段です。ActiveX や BHO への依存が深すぎて、どうしても分解できない場合に限ります。

6. ステップ3：具体的な進め方（ロードマップ）

評価 → 優先順位付け → PoC → テスト → 展開 → 運用

1. 評価 ── 依存の棚卸し

• Enterprise Site Discovery で対象 URL をリストアップ
• edge://net-export でネットワーク遷移を可視化
• 依存を「文書モード」「ActiveX/BHO」「認証」「クライアント証明書」「ファイル/印刷」「機器/COM」に分類

2. 優先順位付け ── どこから手をつけるか

以下の観点で並べ替えます。

• 重要度（止まったらまずい順）
• 利用者数
• セキュリティ露出度
• 他システムへの波及度
• 切り出しやすさ（境界が明確かどうか）

特に「境界を切れば進む機能」と「境界ごと持ち替えが必要な機能」を分けておくと、その後の計画が立てやすくなります。

3. PoC（概念実証） ── 小さく試す

最初の対象は「業務価値が高く、依存が中程度」の 1ワークフロー から。

成功条件は以下の4点です。

1. IE モードが不要になること
2. SSO が維持されること
3. 応答性能が比較可能なレベルであること
4. ロールバック（元に戻せる）可能であること

4. テスト ── 新旧混在に対応する

• モダン経路 → Playwright で Edge を自動テスト
• IE モード経路 → 診断ページ + 手動確認
• 新旧混在期は「どの導線がどのエンジンで動くか」を明示する（明示しないと不具合の再現が困難）

5. 展開 ── 徐々に広げる

• カナリア配布（一部ユーザーから先行展開）
• Extended Stable（8週間サイクル）で検証窓を確保
• サイトリストの更新間隔やブラウザ再起動要件を運用フローに組み込む
• クラウドサイトリストを使う場合は Edge サインインが前提 になることを忘れない

6. 運用 ── 減らし続ける

• Cloud Site List Management のフィードバック機能で、ユーザーが追加したサイトや誤設定を回収
• 毎月 IE モード対象リストを縮小する運用サイクルを回す
• 「延命策」は必ず「減らす運用」とセットにする

全体の流れ（フローチャート）

flowchart TD
    A[対象資産の棚卸し] --> B[依存分類]
    B --> C{依存の種類は？}
    C -->|文書モード・SSO中心| D[IEモード正式運用]
    C -->|OS連携・COM中心| E[ラッパー化]
    C -->|画面単位で切れる| F[段階的リファクタリング]
    C -->|複数チーム並行開発| G[マイクロフロントエンド]
    C -->|依存が深すぎる| H[全面リライト]

    D --> I[ニュートラルサイトとCookie調整]
    E --> J[WebView2/ネイティブ境界]
    F --> K[旧新共存と段階置換]
    G --> K
    H --> L[新アーキテクチャへ再設計]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[自動テストと運用テスト]
    N --> O[段階展開]
    O --> P[利用状況とフィードバック収集]
    P --> Q[IEモード対象の縮小]
    Q --> R[廃止判定]

7. ステップ4：ガバナンス ── 管理的な枠組み

IE モードを「例外運用」として明文化する

• 新規追加する IE モード対象 URL には、必ず以下の項目を設定します。
  • 業務オーナー（誰が責任者か）
  • 技術オーナー（誰が技術的に管理するか）
  • 失効日（いつまでに脱却するか）
  • 代替計画（どうやって脱却するか）
• 既存の XML サイトリストが schema v.1 の場合は、IE モード連携で使える schema v.2 へ移行する
• 変更履歴は Cloud Site List Management または構成管理ツールで追跡する

セキュリティ面での注意

• 古い Edge を固定して運用するのは危険 → 最新の Stable/Beta 系列を使う
• 検証期間が必要なら Extended Stable（8週間サイクル）を使う
• GPO の品質確認には Security Compliance Toolkit や Policy Analyzer を使う
• 「IE モードそのものの脆弱性」よりも「周辺のブラウザ運用が雑であること」のほうが事故につながりやすい

時間軸を逆算する

• IE モードサポート終了: 2029年
• Win10 22H2 の Edge/WebView2 更新終了: 2028年10月

これらは「撤退期限の外枠」です。サポートが切れる前に依存をゼロにする逆算表を先に作るべきです。

8. 規模別の推奨戦略

この表の人月も、ステップ2の「目安工数」と同じ前提のレンジです。典型条件の欄（画面数、SSO の複雑さ、部門数）が自社と大きく違う場合は、そのまま当てはめず、画面数と経路数から積み上げ直してください。

9. よくある間違いと対策

10. まとめ

標準戦略 = 正式な IE モード運用（事故防止）
           + 依存の可視化（棚卸し）
           + 段階的な削減（1つずつ脱却）

• 小規模なら段階的リファクタリング
• 大規模ならサイトリスト統制 + ポートフォリオ管理
• 予算が厳しいなら仮想化で封じ込めつつ、新規の依存を止める
• 全面リライトは最後の切り札
• コンテナは通常候補外、VDI は避難所、IE モード は滑走路（離陸するためのもの）

参考リンク

• IE と Edge のライフサイクル FAQ ─ IE モードの 2029 年方針
• IE モードの概要 ─ サポート範囲の基本資料
• IE モードのポリシー構成 ─ 統合設定の三段階
• Enterprise site configuration strategy ─ ニュートラルサイト、Cookie 共有、schema v.2
• Enterprise Mode schema v.2 guidance ─ サイトリスト XML の要素と記述例
• Microsoft Edge の更新チャネルの概要 ─ Stable と Extended Stable のサイクル
• IE mode troubleshooting and FAQ ─ 診断ページ、net-export の使い方
• Cloud Site List Management ─ 管理センターでの一元管理
• Enterprise Site Discovery ─ 棚卸しの出発点
• WebView2 ドキュメント ─ ラッパー化の検討に
• Azure Virtual Desktop / RemoteApp ─ 隔離策として
• Windows Containers 移行ガイド ─ GUI 延命先として不向き
• App Assure ─ IE モード設定支援の範囲
• Playwright ─ Edge 自動テスト
• single-spa ─ マイクロフロントエンドの基礎
• webpack Module Federation ─ 独立ビルド統合

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

EdgeのIEモードはいつまで使えますか？

EdgeのIEモードは少なくとも2029年までサポートされ、廃止の1年前に通知される方針です。またWindows 10 22H2でのEdge / WebView2 Runtimeの更新は少なくとも2028年10月までです。ただし、この期間はあくまで計画的に脱却するための猶予であり、2029年は準備開始ではなく脱却完了の期限として逆算すべきです。IE11デスクトップアプリ自体はすでに退役済みです。

IEモード依存から抜けられないのはなぜですか？

IEモードはChromiumベースのEdgeの中で、古いサイトだけをTrident（MSHTML）エンジンで描画する仕組みで、このTridentが古い文書モード、ActiveXコントロールやBHO、古いセキュリティゾーン設定、Enterprise Modeの互換設定を引き受けているためです。これらに依存している限り、ブラウザを最新にしただけでは解決しません。まず依存を文書モード・ActiveX/BHO・認証SSO・クライアント側連携・古い運用前提に分類して、正体を見極めることが第一歩です。

IEモード脱却にはどんな方法がありますか？

主な選択肢は、IEモード継続運用、WebView2ラッパー、段階的リファクタリング、マイクロフロントエンド、全面リライト、VDI / RemoteApp隔離の6つです。実務上の第一候補は段階的リファクタリングで、画面や機能を1つずつモダン化していけます。WebView2ラッパーはActiveXを温存するためではなく、ファイル操作や機器連携などOS側の責務をネイティブへ寄せて境界を切り直すために使います。全面リライトは依存が深すぎて分解できない場合の最後の手段です。

IEモードを当面使い続ける場合、何をすべきですか？

まずサイトリストをユーザー任せの再読み込みではなく、ポリシーで正式に管理することです。Cloud Site List Managementに移行すると、複数リスト配布、変更履歴、グループ別割り当てが可能になります。SSOが絡む場合はニュートラルサイトを正しく設定し、必要ならCookie共有を設定します。あわせて、新規追加するIEモード対象URLには業務オーナー・技術オーナー・失効日・代替計画を必ず設定し、毎月対象リストを縮小する運用サイクルとセットにすべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。