合同会社小村ソフト
日本語 English 한국어 繁體中文 العربية
相談する
メニュー

IEモードの次はWebView2でいいのか ── ActiveXが動かない制約と現実的な移行設計

· · WebView2, Windows, .NET, WPF, Windows Forms, IEモード, ActiveX, レガシー移行, 社内システム, 技術相談

以前の記事「IEモード依存の社内Webシステムをどう延命し、どう抜けるか」では、IE モードはあくまで期限付きの延命措置であり、並行して出口を設計すべきだと書きました。その「出口」の相談を受けていると、高い頻度で登場するのが WebView2 です。「社内 Web システムを専用アプリの中に表示したい」「デスクトップアプリの一部画面だけ Web 技術で作りたい」「Electron は重いと聞いたが代わりはあるか」──いずれも WebView2 が選択肢に挙がる場面です。

一方で、WebView2 には導入前に知っておくべき癖があります。ランタイムをどう配布するか、ユーザーデータフォルダーをどこに置くか、ネイティブ側と Web 側をどう会話させるか。そして何より、IE モードで動いていた ActiveX は WebView2 では動かないという、移行計画の根幹に関わる制約です。この記事では、WebView2 の基本構造から配布・設計・セキュリティ、IE モード脱出との現実的な組み合わせ方までを整理します。

1. まず結論

  • WebView2 は Chromium ベースの Microsoft Edge を Windows アプリに埋め込むコントロールです。WinForms / WPF / WinUI / Win32 C++ から使え、既存のデスクトップアプリに「一部だけ Web UI」を足す用途に向いています。1
  • ランタイムは原則 Evergreen（自動更新される共有ランタイム） を使います。Windows 11 には標準搭載ですが、「入っているはず」を前提にせず、インストーラーで存在確認とブートストラップを組み込むのが公式推奨です。2
  • オフライン環境や検証済み構成を固定したい工場・製造ライン向けには Fixed Version（アプリ同梱） がありますが、同梱物が 250MB 超になり、セキュリティ更新を自分で配る責任を負います。安易に選ばないでください。3
  • 最初にハマるのはユーザーデータフォルダー（UDF）です。既定では exe の隣に作られるため、Program Files 配下にインストールしたアプリでは起動に失敗します。%LOCALAPPDATA% 配下を明示指定するのを定石にしてください。4
  • ネイティブ⇔Web の連携は PostWebMessageAsJson / WebMessageReceived によるメッセージ交換を基本にし、AddHostObjectToScript（COM オブジェクトの公開）は信頼できるコンテンツに限定します。1
  • WebView2 の中で ActiveX は動きません。 ActiveX を含む IE モード依存ページを「WebView2 に載せ替えて終わり」にはできず、ActiveX が担っていた処理をネイティブ側へ移す設計が必要です。ここが IE モード脱出計画の本丸です。5

2. WebView2の基本構造

WebView2 は「SDK（アプリに組み込む API）」と「ランタイム（クライアントにインストールされる Edge ベースの実行環境）」の 2 つでできています。Visual C++ ランタイムや .NET ランタイムと同じ構図で、アプリは NuGet パッケージ Microsoft.Web.WebView2 を参照してビルドし、実行時にはクライアント上のランタイムを使って動きます。3

対応プラットフォームは広く、.NET Framework 4.6.2 以降 / .NET Core 3.1 以降の WinForms・WPF、WinUI、Win32 C++ から利用できます。既存の WinForms 業務アプリの 1 画面だけ WebView2 にする、といった段階的な使い方ができるのが、フレームワークごと乗り換える方式（Electron など）に対する大きな利点です。UI フレームワーク自体の選定は「WinForms / WPF / WinUI 判断表」も参照してください。

最小の組み込みは次のようなコードになります（WPF/WinForms 共通の考え方）。

var env = await CoreWebView2Environment.CreateAsync(
    browserExecutableFolder: null,   // Evergreen ランタイムを使う
    userDataFolder: Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "KomuraSoft", "MyApp", "WebView2"));
await webView.EnsureCoreWebView2Async(env);
webView.CoreWebView2.Navigate("https://internal.example.co.jp/app/");

ポイントは、既定値に任せず CoreWebView2Environment を自分で作っていることです。理由は次の 2 章で説明します。

導入手順そのものは素直で、WinForms / WPF なら次の流れです。

  1. NuGet で Microsoft.Web.WebView2 をプロジェクトに追加する（デザイナーのツールボックスにも WebView2 コントロールが現れます）
  2. フォーム／ウィンドウにコントロールを配置する
  3. 上のコードのように EnsureCoreWebView2Async で初期化してから Navigate する

ここで一つ、最初に必ず押さえておきたい API 上の注意があります。webView.CoreWebView2 は初期化が完了するまで null です。フォームのコンストラクターで CoreWebView2.WebMessageReceived += ... のようにイベントを購読しようとして NullReferenceException になるのは定番のつまずきで、初期化まわりの処理は「EnsureCoreWebView2Async の await 後」に集約するのが基本形です。Source プロパティへの代入は初期化を暗黙に開始してくれますが、環境（UDF の場所など）を指定したいアプリでは、明示的に EnsureCoreWebView2Async(env) を先に呼ぶ構成に統一したほうが事故がありません。

また、WebView2 のイベントはすべて UI スレッドで発火します。WebMessageReceived の中で重い処理（機器アクセスやファイル I/O）をそのまま書くと Web 側の操作感まで巻き添えで固まるので、ネイティブ側の処理は async/await で逃がします。このあたりの原則は「WPF/WinForms の UI スレッドと async/await」で書いた内容がそのまま適用できます。

3. ランタイム配布 ── EvergreenとFixed Version

3.1 Evergreen（推奨）

Evergreen は、クライアントにインストールされた共有ランタイムを全 WebView2 アプリが使い、ランタイムは自動更新される方式です。セキュリティパッチが自動で当たる、ディスク消費が小さい、という理由で公式が明確に推奨しています。6

実務での注意は 3 点です。

  • 存在確認を実装する。 Windows 11 には標準搭載され、Windows 10 にも広く配信されていますが、それでも「入っていない端末」は存在します。.NET では CoreWebView2Environment.GetAvailableBrowserVersionString() で確認できますが、ランタイム未導入の環境ではこの呼び出し自体が例外（WebView2RuntimeNotFoundException）で失敗するので、try/catch で包んで「例外＝未インストール」と判定し、ブートストラッパー（小さなオンラインインストーラー）またはスタンドアロンインストーラーの実行に進む形でセットアップに組み込みます。2
  • ランタイム更新への追従を設計する。 ランタイムが更新されても、実行中のアプリは古いバージョンを使い続けます。NewBrowserVersionAvailable イベントを拾って「再起動すると更新が反映される」導線を作っておくのが推奨パターンです。2
  • 社内の更新統制と整合させる。 Edge ブラウザーと WebView2 ランタイムの更新ポリシーは別物です。グループポリシーでランタイム更新を止めている環境では、Evergreen の前提（最新が入っている）が崩れるため、新しめの API を使う場合はフィーチャー検出を入れます。6

3.2 Fixed Version（限定用途）

Fixed Version は特定バージョンのランタイムをアプリに同梱する方式です。動作検証済みの構成を凍結できるため、オフラインの製造装置や、変更管理が厳格な環境では合理的な選択になります。ただし、

  • 同梱バイナリは 250MB を超え、配布物がその分大きくなる2
  • ランタイムは自動更新されないため、ブラウザーエンジンの脆弱性修正を自分のリリースで配る責任を負う
  • 更新を怠ると「古い Chromium を積んだ業務アプリ」が社内に残り続ける

という重い代償があります。表示するコンテンツが完全に閉域・自社管理で、リリースサイクルにランタイム更新を組み込める体制がある場合に限って選んでください。

4. 最初にハマる罠 ── ユーザーデータフォルダー

WebView2 は Cookie・キャッシュ・権限などをユーザーデータフォルダー（UDF）に保存します。UDF の場所を指定しないと既定の場所（多くの構成で exe と同じ場所の隣）に作ろうとするため、Program Files 配下にインストールされたアプリでは書き込みに失敗し、初期化エラーになります。開発機（デバッグ実行、書き込み可能なフォルダー）では動くのに、インストールした途端に動かない──という典型的な「配布して初めて発覚する」不具合です。4

対策はシンプルで、先のコード例のように %LOCALAPPDATA% 配下のアプリ専用フォルダーを常に明示指定することです。あわせて次も設計に入れておきます。

  • UDF はユーザーごと・アプリごとに分ける（複数アプリで共有しない）
  • ネットワークドライブ上に置かない（速度低下・破損・データ損失の原因になります）4
  • アンインストール時や「ログイン情報をクリア」機能で UDF を削除する手順を決めておく（Cookie やサイトデータが残る場所だと運用者が知らないと、退職者端末の整理などで漏れます）

前章の記事「業務Windowsアプリのローカルデータ保存」で書いた「exe の隣に書き込まない」原則の、WebView2 版だと考えてください。

5. ネイティブ⇔Webの連携設計

WebView2 を「ただのブラウザー枠」以上のものにするのが、ネイティブコードと Web コンテンツの相互連携です。手段は主に 2 つあります。1

5.1 Webメッセージ（基本形）

ネイティブ側から PostWebMessageAsJson で JSON を送り、Web 側は window.chrome.webview.addEventListener("message", ...) で受け取る。逆方向は window.chrome.webview.postMessage(...) と WebMessageReceived イベント。疎結合で、公開する操作を 1 か所で検査できるため、まずこちらを既定の連携手段にします。

// ネイティブ → Web
webView.CoreWebView2.PostWebMessageAsJson(
    JsonSerializer.Serialize(new { type = "deviceStatus", connected = true }));

// Web → ネイティブ
webView.CoreWebView2.WebMessageReceived += (s, e) =>
{
    // 想定オリジン以外（外部サイトへ遷移した後など）からのメッセージは処理しない
    if (!e.Source.StartsWith("https://internal.example.co.jp/", StringComparison.Ordinal))
        return;

    AppMessage? msg;
    try { msg = JsonSerializer.Deserialize<AppMessage>(e.WebMessageAsJson); }
    catch (JsonException) { msg = null; }
    if (msg?.Type is null)
        return;  // 形式不正はここで捨てる（必要ならログへ）

    // type ごとに許可された操作だけを実行する
};

Web 側（JavaScript）はこう受けます。特別なライブラリは不要で、WebView2 が注入する window.chrome.webview オブジェクトを使うだけです。

// ネイティブからのメッセージを受け取る
window.chrome.webview.addEventListener("message", (e) => {
    if (e.data.type === "deviceStatus") {
        updateStatusBadge(e.data.connected);
    }
});

// ネイティブへ依頼を送る
document.getElementById("print-label").addEventListener("click", () => {
    window.chrome.webview.postMessage({ type: "printLabel", copies: 2 });
});

受信側では、上のコードのように e.Source（メッセージを送ってきたページの URI）を先に検査し、そのうえで「メッセージの type をホワイトリストで検査し、想定外は無視してログに残す」を徹底します。Web 側はリンク 1 つ・リダイレクト 1 つで外部サイトへ遷移し得るので、「今表示しているのは自分のページのはず」という思い込みで発信元検査を省かないでください。逆に Web 側でも、window.chrome.webview が存在しない場合（通常のブラウザーで開かれた場合）のフォールバックを入れておくと、Web UI 部分を単体でブラウザーデバッグできて開発効率が上がります。

5.2 ホストオブジェクト公開（強力だが限定使用）

AddHostObjectToScript を使うと、.NET/COM オブジェクトを JavaScript から直接呼べるようになります。内部的には COM の仕組みで、当社が長く扱ってきた COM 技術がこんなところで現役なのは面白いところですが、Web コンテンツにネイティブオブジェクトを直接握らせるということは、そのページが侵害されたときの影響もそれだけ大きいということです。公開するのは自社管理のコンテンツに限定し、公開メソッドは必要最小限に絞ってください。信頼できないページを表示する可能性がある WebView には登録しない、が原則です。

5.3 ローカルコンテンツの読み込み

HTML/JS をアプリに同梱して表示する場合、file:// 直読みではなく SetVirtualHostNameToFolderMapping で仮想ホスト名にフォルダーをマップするのが定石です。コンテンツが https://appassets.example/ のようなオリジンを持つため、localStorage などオリジン前提の Web API が普通に使え、クロスオリジンアクセスの許可レベルも指定できます。ホスト名には実在し得ない予約ドメイン（.example など）を使い、アクセス種別は必要最小限（まず DenyCors）から始めます。7

6. IEモード脱出とWebView2 ── ActiveXは動かない

ここがこの記事で一番重要な節です。IE モードが延命できているのは、Edge の中で本物の IE11（Trident エンジン）が動いており、ActiveX やブラウザーヘルパーオブジェクトがそのまま動作するからです。5 一方 WebView2 は Chromium であり、ActiveX をホストする仕組みはありません。つまり、

「IE モードで動いている社内システムを WebView2 製のシェルに載せ替える」は、ActiveX に依存していない画面についてのみ成立する。

という制約から移行計画を組む必要があります。現実的な移行順序は次のようになります。

  1. 棚卸し: IE モード依存ページを「ActiveX 等の IE 固有技術を使う画面」と「単に古い作りなだけの画面」に分類する（IE モード記事のサイトリスト棚卸しがそのまま使えます）。
  2. IE 固有でない画面: モダンブラウザー対応に改修し、Edge そのもので表示するか、業務端末アプリに統合したければ WebView2 シェルに載せる。
  3. ActiveX 依存画面: ActiveX が担っていた機能（シリアル通信、ファイルアクセス、専用機器制御など）をネイティブ側（WebView2 のホストアプリ）に移し、Web メッセージ経由で呼び出す形に再設計する。「ブラウザーの中の ActiveX」を「アプリの中の Web UI ＋ネイティブ処理」に裏返すイメージです。
  4. ActiveX 自体を残すか・ラップするか・置き換えるかの判断は「ActiveX/OCX 維持・ラップ・置き換え判断表」の基準がそのまま適用できます。

この 3 番の再設計こそ WebView2 導入の実質的な工数であり、「WebView2 を入れれば IE モードから抜けられる」という単純な話ではない、という期待値調整が計画段階で必要です。逆に言えば、ActiveX の機能をホストアプリへ移す設計さえ済めば、UI は Web 技術で内製・保守しやすくなり、配布はデスクトップアプリとして統制できる、という両取りができます。

7. 社内システムで必ず聞かれる実装課題

WebView2 の採用を検討すると、業務側から必ず出てくる質問がいくつかあります。先回りして整理しておきます。

7.1 印刷と帳票

「IE のときは印刷ボタンで帳票が出ていた」という要件は、WebView2 では 2 系統で受けられます。

  • 画面をそのまま印刷: CoreWebView2.ShowPrintUI() で印刷ダイアログを出す、あるいは PrintAsync で無人印刷。ブラウザーの印刷と同等なので、CSS の印刷指定（@media print）がそのまま効きます。
  • PDF として出力: PrintToPdfAsync で表示中のページを PDF ファイルに落とせます。「帳票は PDF で保存して共有フォルダーへ」という業務フローには、ネイティブ側でファイル名・保存先を統制できるこちらが向いています。1

ピクセル単位の桁揃えが要求される複写式伝票のような帳票は、Web の印刷で追い込むより、ネイティブ側の帳票出力（Excel 帳票の作り方で整理した方式）に寄せる判断も含めて検討してください。

7.2 ファイルのダウンロードとアップロード

ダウンロードは既定でもブラウザー同様に動きますが、業務アプリでは DownloadStarting イベントで介入するのが定石です。保存先を固定する、拡張子で許可・拒否を判定する、既定のダウンロード UI を消してアプリ側の通知に置き換える、といった統制がかけられます。1アップロード（<input type="file">）は特別な実装なしに OS のファイル選択ダイアログが開きます。

7.3 認証と SSO

社内 Web システム側が Windows 統合認証（NTLM/Kerberos）なら、WebView2 でも概ねブラウザーと同様に通ります。Basic 認証を使う古いシステムには BasicAuthenticationRequested イベントで資格情報を供給でき、ログイン画面を出さずに済ませることも可能です──ただしその資格情報をどこに保存するかは、まさに DPAPI の記事で書いた話になります。Microsoft Entra ID（旧 Azure AD）の SSO を OS のサインイン情報で通したい場合は、環境オプション AllowSingleSignOnUsingOSPrimaryAccount の有効化を検討します。

Cookie は UDF に保存されるため、アプリを再起動してもログイン状態は維持されます。「ログアウト機能でセッションを確実に消したい」場合は CookieManager で明示的に削除する実装を入れてください。

7.4 開発時のデバッグ

WebView2 の中身は Chromium なので、開発中は F12 の DevTools がそのまま使えます（CoreWebView2Settings.AreDevToolsEnabled が既定で有効）。さらに前述のとおり Web UI 側を「ブラウザー単体でも動く」ように作っておくと、UI の開発・デバッグは普通の Web 開発として回し、ネイティブ連携だけ WebView2 上で確認する、という分業ができます。Web 資産をアプリに閉じ込めても、開発体験は Web のまま保てるということです。

8. セキュリティ設計の要点

WebView2 アプリは「ブラウザーを内蔵したアプリ」なので、ブラウザー相当の脅威モデルで考えます。

  • 表示するコンテンツを限定する: NavigationStarting で遷移先を社内ドメインのホワイトリストで検査し、想定外の URL は既定ブラウザーへ逃がす（NewWindowRequested も同様に処理する）。
  • 信頼境界をまたぐ機能を絞る: ホストオブジェクトの公開範囲、Web メッセージで許可する操作は最小限に。外部サイトを表示し得る WebView と、ネイティブ連携を持つ WebView を分けるのも有効です。
  • 利用者向け機能を環境に合わせて調整する: CoreWebView2Settings で「ブラウザーらしさ」を必要な分だけ残せます。キオスク端末や現場端末では絞っておくと事故が減ります。
  • Fixed Version なら更新計画に責任を持つ: 前述のとおり、脆弱性修正の配布はアプリ側の責務になります。6

CoreWebView2Settings でよく調整する項目を挙げておきます。本番ビルドでどうするかを、リリース前チェックリストに含めておくのがおすすめです。

設定 既定 現場端末・本番での典型
AreDevToolsEnabled（F12 開発者ツール） 有効 本番では無効化
AreDefaultContextMenusEnabled（右クリックメニュー） 有効 「戻る」「再読み込み」を使わせたくない画面では無効化
AreBrowserAcceleratorKeysEnabled（Ctrl+F5 等のショートカット） 有効 キオスク用途では無効化
IsStatusBarEnabled（リンク先表示） 有効 好みで
IsZoomControlEnabled（Ctrl+ホイールのズーム） 有効 レイアウトが崩れる業務画面では無効化
AreHostObjectsAllowed（ホストオブジェクト） 有効 使わないなら無効化

いずれも「無効化すれば安全」というより、「アプリとして意図した操作以外の入り口を閉じる」ための道具です。Windows アプリ全般のセキュリティの底上げは「Windowsアプリのセキュリティ最小チェックリスト」もあわせて参照してください。

9. 採用判断の整理

構成 向いている場面 注意点
Edge（ブラウザー）で表示 普通の社内 Web システム アプリ統合・ネイティブ連携は不可
既存アプリ＋WebView2 で一部 Web UI 画面単位のモダナイズ、Web 資産の再利用 UDF・ランタイム配布・連携設計（本記事）
WebView2 シェル＋ネイティブ機能移植 ActiveX 依存の IE モード資産の出口 ActiveX 機能の再実装が本丸
Electron 等 クロスプラットフォーム必須の場合 Windows 専用なら重い。配布物・メモリ増
フルネイティブ（WPF等）で作り直し Web 資産がない・オフライン前提 開発コストとの相談

「Windows 専用の社内アプリで、Web 技術の UI を使いたい」なら、Electron よりも WebView2 が既定の選択肢です。ランタイムを OS 側と共有できるぶん配布が軽く、既存の .NET 資産との統合も素直です。

10. まとめ

WebView2 は、Chromium ベースの Web UI を Windows アプリに部品として組み込める、社内システムのモダナイズと相性のよい技術です。導入時の実務ポイントは、Evergreen ランタイムの存在確認と更新追従、ユーザーデータフォルダーの明示指定、Web メッセージを基本にした連携設計の 3 つ。そして計画面では、ActiveX は動かないという制約を直視し、ActiveX の機能をネイティブ側へ移す再設計を工数の中心に据えることです。

IE モードの期限を横目に「そろそろ出口を」と考えている場合、まずは対象システムの棚卸しと、ActiveX 依存部分の機能分解から始めるのが着実です。このあたりの進め方は、実際のシステム構成を見ながらでないと判断しづらい部分も多いので、迷ったらご相談ください。

関連記事

関連する相談領域

合同会社小村ソフトでは、IEモード・ActiveX依存の社内システムの出口設計、WebView2 を使った段階的なモダナイズ、既存 Windows アプリへの Web UI 統合の相談を扱っています。

参考リンク

  1. Microsoft Learn, Overview of WebView2 APIs. ナビゲーション管理、ローカルコンテンツ読み込み、ホスト⇔Web 間通信（Web メッセージ、ホストオブジェクト）など WebView2 の機能全体像について。 ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Distribute your app and the WebView2 Runtime. ブートストラッパー／スタンドアロンインストーラーによる配布、インストール済み検出、NewBrowserVersionAvailable による更新追従、Fixed Version の同梱手順（250MB 超）について。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Evergreen vs. fixed version of the WebView2 Runtime. ランタイムの 2 つの配布モードの違い、Windows 11 への標準搭載、Fixed Version の長所と短所について。 ↩ ↩2

  4. Microsoft Learn, Manage user data folders. ユーザーデータフォルダーの役割、カスタム UDF に必要な読み書き権限、ネットワークドライブ上に置くと速度低下・クラッシュ・データ損失の原因になることについて。 ↩ ↩2 ↩3

  5. Microsoft Learn, What is Internet Explorer (IE) mode?. IE モードが Trident (MSHTML) エンジンで動作し、ActiveX コントロールやブラウザーヘルパーオブジェクトをサポートすることについて（＝Chromium ベースの WebView2 にはこのサポートがない）。 ↩ ↩2

  6. Microsoft Learn, Development best practices for WebView2 apps. Evergreen 推奨、ランタイム更新の扱い、フィーチャー検出、Fixed Version 利用時の定期更新の必要性について。 ↩ ↩2 ↩3

  7. Microsoft Learn, Using local content in WebView2 apps. 仮想ホスト名マッピングによるローカルコンテンツ読み込み、オリジンが付与されることの利点、アクセス種別（DenyCors 等）の指定について。 ↩

関連する記事

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

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

Microsoft Edge の IE モード依存をかかえた社内 Web システムを安全に延命しつつ脱却する実務手順を、サイトリスト集中管理、ニュートラルサイト、WebView2 ラッパー、段階的リファクタリング、VDI 隔離、ガバナンス設計まで読者がそのまま着手できる粒度...

記事を読む

タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計

Windowsタスクスケジューラの実行アカウントとログオン種別、「ユーザーがログオンしているかどうかにかかわらず実行」の意味、0x1で終わる典型原因、履歴の有効化、多重起動防止、PowerShellスクリプトの正しい呼び出し方まで、定期実行を運用に乗せるための設計指針を整理...

記事を読む

関連トピック

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

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

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

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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

お問い合わせ
ブログ一覧に戻る