Microsoft Edge WebView2 Runtime 148 prereleaseで印刷ダイアログ不具合修正、.NETデスクトップ開発者が確認すべき点

Microsoft Edge WebView2 Runtime 148 prerelease のリリースノートでは、WebView2CompositionControl の印刷ダイアログでドロップダウン選択に問題が出る不具合の修正が明記されました。結論から言うと、WPF/.NET デスクトップアプリで埋め込み印刷フローを提供している開発チームは、まず 本番配布前の検証環境で Runtime 148 prerelease を使った回帰テストを行い、印刷ダイアログの操作性が改善するか確認すべきです。特に、請求書、配送ラベル、帳票、チケット、業務フォームなど「印刷できないと業務が止まる」画面を WebView2 で表示している場合は、優先度を上げて確認する価値があります。

Microsoft Learn の WebView2 リリースノートでは、Prerelease SDK 1.0.3965-prerelease, for Runtime 148 が 2026年4月13日付で掲載され、Runtime-only の修正として「WebView2CompositionControl の Print dialog dropdown selection issues」を修正したと記載されています。フル API 互換には、Microsoft Edge 148.0.3965.0 以上に同梱される WebView2 Runtime が必要です。(Microsoft Learn)

Microsoft Edge WebView2 Runtime 148 prerelease で何が修正されたのか

今回の注目点は、WebView2CompositionControl を使った WPF アプリで、印刷ダイアログ内のドロップダウン操作に問題が出ていたケースです。

GitHub の関連 Issue では、WPF アプリ内の WebView2CompositionControl から印刷を実行した際、プリンター、カラー、両面印刷などのドロップダウンをマウスで変更できない症状が報告されています。Issue では、矢印キーと Enter による変更は可能、通常の WebView2 コントロールでは再現しないが、WPF の airspace 問題のため WebView2CompositionControl を使わざるを得ない、という文脈も示されています。(GitHub)

つまり、この修正は単なる細かい UI バグではありません。デスクトップアプリに Web コンテンツを埋め込み、その画面からユーザーに印刷させるワークフローでは、印刷ダイアログのドロップダウンが操作できないだけで「正しいプリンターを選べない」「カラー設定を変えられない」「両面印刷を切り替えられない」といった実害につながります。

対象になりやすいアプリは、次のようなものです。

該当しやすい条件	確認すべきポイント
WPF アプリで `WebView2CompositionControl` を使っている	標準の `WebView2` ではなく CompositionControl かを確認する
WebView2 内の HTML 画面から印刷する	`window.print()`、コンテキストメニュー、アプリ側の印刷ボタンを確認する
ユーザーが印刷ダイアログで設定を変更する	プリンター、ページ、カラー、両面、用紙サイズ、倍率などを操作する
業務帳票・ラベル・PDF 表示など印刷依存度が高い	印刷失敗時の問い合わせ件数や代替手段を確認する
Evergreen Runtime を使っている	ユーザー環境の Runtime バージョンが自動更新に依存する

`WebView2CompositionControl` 利用アプリで重要度が高い理由

WebView2CompositionControl は、WPF アプリで WebView2 が最前面に表示されて WPF 要素を隠してしまう、いわゆる airspace 問題を避けるために使われるコントロールです。Microsoft の WPF 向け WebView2 ドキュメントでも、WebView2CompositionControl は標準の WPF WebView2 コントロールのドロップイン置換として説明されています。(Microsoft Learn)

ここでやや厄介なのは、WebView2CompositionControl は見た目や XAML 上では通常の WebView2 と似ていても、描画・入力・フォーカスまわりの挙動が異なる可能性がある点です。今回の印刷ダイアログのように、Web コンテンツ本体ではなくブラウザー側の UI が絡む機能では、通常のブラウザーや標準 WebView2 では再現しない不具合が起きることがあります。

開発現場では、次のような誤解が起きがちです。

誤解	実際に見るべき観点
Edge ブラウザーで印刷できるから WebView2 でも大丈夫	WebView2 Runtime、コントロール種別、ホストアプリの組み合わせで確認する
`WebView2` と `WebView2CompositionControl` は同じように動く	WPF の描画・入力処理が異なるため、印刷 UI も個別に検証する
NuGet の WebView2 SDK を上げればユーザー環境も直る	Runtime-only 修正の場合、実行環境の Runtime バージョン確認が必要
印刷できるかだけ見れば十分	ドロップダウン、キャンセル、プリンター切替、用紙設定まで操作確認する

今回の修正は Runtime-only として扱われているため、SDK の更新だけで本番ユーザーの問題が解消するとは考えない方が安全です。ユーザーの端末で実際に使われる WebView2 Runtime が修正済みバージョンに到達しているか、または固定バージョン Runtime を同梱しているならアプリ側で更新しているかを確認する必要があります。

まず確認すべき影響範囲

この不具合への対応では、いきなり全ユーザーへ prerelease を展開するのではなく、影響範囲を切り分けることが重要です。

自分のアプリが対象かを判定する

まず、次のチェックに当てはまるか確認してください。

チェック項目	該当する場合の優先度
WPF アプリである	高
`Microsoft.Web.WebView2.Wpf.WebView2CompositionControl` を使っている	高
WebView2 内から印刷ダイアログを表示している	高
ユーザーが印刷時に設定変更する	高
帳票、PDF、ラベル、申請書、領収書など業務印刷がある	高
WinForms の標準 WebView2 のみを使っている	低め。ただし印刷回帰テストは推奨
`PrintToPdfAsync` のみでユーザー操作の印刷ダイアログを使わない	今回の修正対象とは分けて確認

特に注意したいのは、「印刷機能がある」だけでなく「ユーザーが印刷ダイアログで値を変更する」かどうかです。固定プリンターに無人出力するだけの機能と、ユーザーが毎回プリンターや用紙設定を選ぶ機能では、リスクが大きく違います。

ランタイムバージョンをログに残す

問い合わせ対応を楽にするため、アプリ起動時または印刷処理前に WebView2 Runtime のバージョンをログへ出すようにしておくと有効です。

using Microsoft.Web.WebView2.Core;

try
{
    string runtimeVersion = CoreWebView2Environment.GetAvailableBrowserVersionString();
    // 例: アプリログ、診断情報、サポート用画面などに出力
    Console.WriteLine($"WebView2 Runtime: {runtimeVersion}");
}
catch (WebView2RuntimeNotFoundException)
{
    Console.WriteLine("WebView2 Runtime is not installed.");
}

すでに CoreWebView2Environment を作成済みであれば、BrowserVersionString を記録する方法もあります。重要なのは、ユーザーから「印刷設定を変えられない」と報告されたときに、アプリのバージョンだけでなく WebView2 Runtime の実行バージョンまで確認できる状態にすることです。

検証環境で実施したい印刷回帰テスト

今回のような印刷ダイアログの問題は、自動テストだけでは検出しにくい領域です。最低限、手動テストの観点を具体化しておくべきです。

テスト観点	確認内容
プリンター選択	既定プリンター以外を選べるか
カラー設定	カラー、白黒、グレースケールなどを変更できるか
両面印刷	片面、長辺とじ、短辺とじを切り替えられるか
用紙サイズ	A4、Letter、ラベル用紙などを変更できるか
ページ範囲	全ページ、指定ページ、現在ページを選べるか
キャンセル操作	ダイアログを閉じた後にアプリが固まらないか
再試行	一度キャンセルした後、再度印刷できるか
複数モニター	DPI やスケーリングが異なる環境で操作できるか
リモート環境	RDP、VDI、Citrix などでプリンター選択が崩れないか
ロケール差	日本語 Windows、英語 Windows などで表示と操作に問題がないか

グローバル向けに配布している .NET デスクトップアプリでは、プリンター名、OS 言語、地域設定、ドライバーの違いで印刷 UI の挙動が変わることがあります。日本語環境だけで再現しない場合でも、英語 Windows や欧州向けの用紙設定、仮想プリンター、PDF プリンターで確認しておくと安全です。

Evergreen と Fixed Version で対応方針は変わる

WebView2 Runtime の配布方式によって、今回の修正をどう取り込むかは変わります。Microsoft のドキュメントでは、WebView2 Runtime の配布方式として Evergreen と Fixed Version が説明されており、Evergreen はクライアント側で Runtime が自動更新され、Fixed Version はアプリに特定バージョンの Runtime を同梱する方式です。(Microsoft Learn)

配布方式	今回の対応ポイント
Evergreen Runtime	ユーザー環境の更新タイミングに差が出る。サポートログで Runtime バージョンを確認できるようにする
Fixed Version Runtime	アプリ同梱の Runtime を更新しない限り修正が入らない。次回リリースに組み込むか判断する
社内管理端末	Edge/WebView2 更新ポリシーにより更新が遅れる可能性がある。IT 管理者との調整が必要
オフライン端末	Evergreen の自動更新を期待しにくい。インストーラーやアプリ更新での配布計画が必要

本番アプリで最も避けたいのは、「開発者の端末では直ったが、ユーザー端末では直らない」という状態です。WebView2 はアプリ本体、NuGet SDK、Runtime の3つが絡むため、リリースノート確認だけで完了にせず、実行環境で使われている Runtime を必ず確認しましょう。

prerelease を本番投入する前に考えるべきこと

Microsoft Edge WebView2 Runtime 148 prerelease は、修正確認には有効ですが、すべての本番ユーザーへ即時展開する前にはリスク評価が必要です。

特に、以下のようなアプリでは慎重に進めるべきです。

医療、金融、公共、製造など、印刷ミスが業務リスクにつながるアプリ
店舗や倉庫など、現場端末で毎日ラベルや帳票を大量印刷するアプリ
オフライン環境や閉域網で WebView2 Runtime 更新が制御されているアプリ
Active Directory、Intune、WSUS、社内配布ツールで Runtime 更新を管理している環境
Fixed Version Runtime を同梱し、アプリ側で更新サイクルを管理している製品

現実的な進め方は、次の順序です。

フェーズ	実施内容
調査	対象画面、対象ユーザー、Runtime バージョン、再現手順を洗い出す
検証	Runtime 148 prerelease 環境で印刷ダイアログの操作を確認する
回帰確認	印刷以外の WebView2 機能、ログイン、PDF 表示、ファイルダウンロードも確認する
判断	prerelease を限定導入するか、安定版への反映を待つか決める
周知	サポート担当に確認手順、既知の回避策、必要ログを共有する
本番対応	Evergreen 更新待ち、Fixed Version 更新、アプリ更新のいずれかを選ぶ

prerelease で問題が解消することを確認できれば、サポート対応では「既知の Runtime 不具合であり、修正が prerelease に入っている」と説明しやすくなります。ただし、prerelease は検証用の意味合いが強いため、本番配布は利用者層や業務影響を見て判断してください。

既存ユーザー向けの暫定回避策

安定版 Runtime に修正が行き渡るまでの間は、サポート向けに暫定案を用意しておくと問い合わせ対応が楽になります。

回避策	向いているケース	注意点
キーボード操作を案内する	マウスでドロップダウン変更できないが、矢印キーと Enter が使える場合	すべての環境で保証できるとは限らない
既定プリンター設定を事前変更してもらう	プリンター選択だけが問題の場合	ユーザーの作業負担が大きい
アプリ内で印刷設定を絞る	用紙や向きが固定の業務帳票	汎用印刷には向かない
`WebView2CompositionControl` ではなく標準 `WebView2` で検証する	airspace 問題がない画面	WPF 要素の重なりがある場合は採用しにくい
PDF 出力後に外部ビューアーで印刷する	帳票の見た目を固定したい場合	ユーザー体験が1ステップ増える

回避策を案内する際は、「この操作で必ず直る」と断定しないことが重要です。プリンタードライバー、OS、WebView2 Runtime、アプリ側の実装により挙動が変わるため、サポート文面では「確認済みの暫定手順」として扱う方が安全です。

サポート担当に共有したい問い合わせテンプレート

印刷まわりの不具合は、ユーザーからの報告だけでは原因を特定しにくい傾向があります。次の項目をサポートフォームやログ収集に入れておくと、開発チームへのエスカレーションが速くなります。

確認したい情報:
- アプリ名とアプリバージョン
- WebView2 Runtime バージョン
- Windows バージョン
- WPF / WebView2CompositionControl を使っている画面名
- 印刷を開始した操作: ボタン、右クリック、Ctrl+P、window.print() など
- 変更できなかった項目: プリンター、カラー、両面、用紙サイズ、ページ範囲など
- マウス操作とキーボード操作の違い
- 物理プリンター、PDF プリンター、ネットワークプリンターのどれか
- RDP、VDI、Citrix などのリモート環境か
- スクリーンショットまたは画面録画の有無

このテンプレートのポイントは、単に「印刷できない」と聞くのではなく、「印刷ダイアログのどの部品が、どの入力方法で失敗したか」を切り分けることです。今回のようなドロップダウン選択問題では、クリック、キーボード、プリンター種別、表示スケールの違いが重要な手がかりになります。

実装側で見直したい印刷フロー

今回の修正を確認するだけでなく、アプリの印刷フロー自体も見直しておくと、将来の WebView2 Runtime 更新に強くなります。

印刷開始の入口を整理する

アプリ内に複数の印刷入口がある場合、すべてを把握しておく必要があります。

HTML 内の印刷ボタン
JavaScript の window.print()
WebView2 のコンテキストメニュー
ホストアプリ側のツールバー
ショートカットキー
PDF 表示画面の印刷
帳票プレビュー画面の印刷

入口が複数あると、ある画面では直っているのに別の画面では再現する、という状況が起きます。印刷機能を共通化できるなら、ホストアプリ側で印刷開始処理、ログ出力、エラーハンドリングをまとめると保守しやすくなります。

印刷結果だけでなく操作過程をテストする

開発者は印刷結果のレイアウトに目が行きがちですが、今回の問題では「印刷に至るまでのダイアログ操作」が焦点です。

確認すべきなのは、印刷物が出るかどうかだけではありません。

ドロップダウンが開くか
選択肢をクリックできるか
選択後に値が反映されるか
フォーカスが失われないか
ダイアログが意図せず閉じないか
キャンセル後に WebView2 が操作可能なままか
2回目以降の印刷でも同じように動くか

特に業務アプリでは、ユーザーが「一度だけ印刷」するとは限りません。同じ画面から連続で帳票を印刷する、プリンターを切り替える、失敗後に再印刷する、といった実運用に近い手順でテストしましょう。

今回の更新を受けた開発チームの次の行動

今回の Microsoft Edge WebView2 Runtime 148 prerelease の更新は、WebView2CompositionControl を使う .NET デスクトップアプリにとって、印刷フローの実害を減らせる可能性がある重要な修正です。ただし、Runtime-only の修正である点、prerelease である点、ユーザー環境の Runtime 更新タイミングに差が出る点には注意が必要です。

まず行うべきことは、次の3つです。

自社アプリで WebView2CompositionControl と印刷ダイアログを使っている画面を洗い出す
Runtime 148 prerelease の検証環境で、プリンター・カラー・両面・用紙サイズなどのドロップダウン操作を確認する
問い合わせ対応に備えて、WebView2 Runtime バージョンをログや診断情報に残す

印刷バグは、ユーザーにとって回避しづらく、サポート問い合わせに直結しやすい不具合です。今回の修正を単なるリリースノートの1項目として流さず、埋め込み印刷ワークフローの品質を見直すきっかけにすると、次の Runtime 更新や環境差にも強い .NET デスクトップアプリにできます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Edge WebView2 Runtime 148 prereleaseで印刷ダイアログ不具合修正、.NETデスクトップ開発者が確認すべき点

Microsoft Edge WebView2 Runtime 148 prerelease で何が修正されたのか

`WebView2CompositionControl` 利用アプリで重要度が高い理由