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

この記事を一言で

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

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

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

なぜ 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 側ポリシーより優先される

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

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

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

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

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

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

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

• ニュートラルサイト（Neutral Site） を正しく設定する → SSO サーバーを明示的に指定
• 必要に応じて Cookie 共有 を設定する
• どうしても認証サーバーを特定できない間は、一時的に「IE モードでページ内ナビゲーションを保持する」ポリシーを使う（ただし確定したら無効化する）

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

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

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

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

パターン比較表

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

各パターンの使いどころ

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

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

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

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

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

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

ステップ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[廃止判定]

ステップ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月

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

規模別の推奨戦略

よくある間違いと対策

まとめ

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

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

参考リンク

• IE と Edge のライフサイクル FAQ ─ IE モードの 2029 年方針
• IE モードの概要 ─ サポート範囲の基本資料
• IE モードのポリシー構成 ─ 統合設定の三段階
• Enterprise site configuration strategy ─ ニュートラルサイト、Cookie 共有、schema v.2
• 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 ─ 独立ビルド統合

関連する記事

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

関連トピック

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

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

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

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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