Microsoft Edge WebView2ランタイムの不整合でアプリが崩れるときは、やみくもにアンインストールする前に、Evergreen の更新停止、別チャネルや Fixed Version の拾い違い、UDF（ユーザーデータフォルダー）の権限不足・破損、更新後の再起動漏れを切り分けるのが近道です。WebView2 は Edge 本体と混同されがちですが、更新ポリシーも参照先も別に管理できるため、Edge が動いていても WebView2 側だけが原因、ということが普通に起こります。(Microsoft Learn)
WebView2 は Outlook の一部機能や Quick Assist などの Windows アプリで使われており、ランタイムが欠落・古い・想定外のチャネルに切り替わっていると、該当機能が表示されない、起動できない、更新後に不安定になるといった形で表面化します。この記事では、Microsoft Edge WebView2ランタイム不整合の原因、確認すべき設定、すぐ使える復旧手順、管理者・開発者向けの再発防止まで実務寄りに整理します。(Microsoft Learn)
Microsoft Edge WebView2ランタイム不整合でまず知るべきこと
WebView2 Runtime は Edge 本体そのものではない
WebView2 Runtime は、デスクトップアプリの中で Web 表示を動かすための実行基盤です。Microsoft 365 Apps の一部機能は WebView2 に依存しており、Quick Assist も WebView2 を必要とします。一方で、WebView2 Runtime を入れても Edge フルブラウザーが新規に入るわけではなく、既定ブラウザー設定も変わりません。 (Microsoft Learn)
Windows 11 では Evergreen Runtime がプレインストールされ、対象となる Windows 10 端末の多くにも配布済みですが、Microsoft 自身も「未導入の端末がまだありうる前提」で配布や検出を組み込むことを勧めています。つまり、“普通は入っているはず” と “その端末で正しく使われている” は別問題です。(Microsoft Learn)
「不整合」は何がズレている状態か
Microsoft は基本的に Evergreen を推奨していますが、Evergreen ではアプリ側が特定バージョンの Runtime を全端末に強制できません。通常は SDK リリース時点で互換 Runtime も配布済みですが、IT 管理者が更新を止めていたり、端末がオフラインだったりすると、新しい SDK で更新されたアプリに古い Runtime が当たって互換性問題が起こりえます。(Microsoft Learn)
不整合が起きやすい主な原因
- Evergreen の自動更新が止まっている
WebView2 Runtime の自動更新は既定で有効ですが、Update (WebView)ポリシーで無効化したり、UpdatesSuppressedで抑止したりすると古いまま残ります。Microsoft も、最近追加された API を使う場合はQueryInterfaceやtry-catchで存在確認するよう案内しています。(Microsoft Learn) - 想定外のチャネルやフォルダーを拾っている
WebView2 の環境作成は、既定では WebView2 Runtime → Beta → Dev → Canary の順に検索します。さらにBrowserExecutableFolder、ReleaseChannels、ChannelSearchKind、WEBVIEW2_*環境変数やレジストリ上書きがあると、アプリが本来想定していない Runtime やプレビュー版を使うことがあります。しかもBrowserExecutableFolderは他のチャネル設定より優先されます。(Microsoft Learn) - Fixed Version と Evergreen を混同している
Fixed Version はアプリ同梱の特定バージョンを使う方式で、自動更新されません。しかも Fixed Version は通常の WebView2 Runtime 用レジストリキーを使わないため、Evergreen 前提の確認だけで「未インストール」と決めつけると誤診になります。(Microsoft Learn) - UDF の作成先に書き込み権限がない
Win32/.NET では既定の UDF が 実行ファイルの隣に.WebView2として作られるため、インストーラーの都合で保護領域に置かれていると起動時に失敗しやすくなります。Microsoft も Win32/.NET では、多くのケースで 書き込み可能なカスタム UDF を明示するよう案内しています。(Microsoft Learn) - UDF が壊れている
UDF には Cookie、権限、キャッシュなどが保存されます。Microsoft は データ破損からの復旧を UDF 削除の理由として挙げており、ブラウザープロセス終了後に UDF を削除または退避する手順を案内しています。(Microsoft Learn) - 更新後でもアプリを再起動していない
Evergreen は自動更新されても、新しい Runtime が使われるのはアプリ再起動後です。常駐アプリや長時間起動しっぱなしの業務アプリは、更新済みなのに旧 Runtime を使い続けることがあります。(Microsoft Learn) - 更新や再インストールそのものがブロックされている
権限制限、セキュリティソフト、ネットワークや TLS の問題、残骸、GPO/MDM などは、Edge WebView2 のインストール・更新・ロールバック失敗の典型原因です。企業端末ではここを見落とすと復旧が長引きます。(Microsoft Learn)
最短で復旧する切り分け手順
まずは WebView2 を使うアプリとプロセスを全部止める
更新や再インストール前に、Edge、Teams、Outlook（新しい Outlook）、Windows ウィジェット、対象の業務アプリを閉じ、タスクマネージャーで msedge.exe と msedgewebview2.exe が残っていないか確認します。ファイルロックが残ると、更新や修復が失敗しやすくなります。(Microsoft Learn)
Evergreen Runtime の有無と版数を確認する
Microsoft が案内している Evergreen の確認方法は、pv レジストリ値を見る方法と、GetAvailableCoreWebView2BrowserVersionString を使う方法です。現場ではまずレジストリ確認が手早いです。ただし、Fixed Version 同梱アプリはこの方法では判定できません。 (Microsoft Learn)
reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" /v pv
reg query "HKCU\Software\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}" /v pvpv が存在しない、空文字、0.0.0.0 の場合、Evergreen Runtime は未導入と判断できます。64 ビット Windows では上記の WOW6432Node 側も確認対象です。(Microsoft Learn)
ポリシーや上書き設定を確認する
企業端末や開発端末では、インストール/更新ポリシーとローダー上書き設定を必ず見ます。とくに BrowserExecutableFolder、ReleaseChannels、ChannelSearchKind、WEBVIEW2_* は、見た目以上に事故の原因になりやすい設定です。HKLM だけでなく HKCU 側の上書きも疑ってください。(Microsoft Learn)
reg query "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}"
reg query "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Update{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}"
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\ChannelSearchKind" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\ReleaseChannels" /s
powershell -NoProfile -Command "Get-ChildItem Env:WEBVIEW2*"ここで BrowserExecutableFolder が見つかったら、まずそのパスが正しいか確認してください。Microsoft のドキュメント上も、この設定は優先度が高く、ReleaseChannels の指定より先に効きます。(Microsoft Learn)
修復できるなら先に修復、だめなら公式の Evergreen で上書き再インストール
Windows では、アプリによっては「修復」や「変更」が使えます。表示される端末では先に試す価値がありますが、すべてのアプリで使えるわけではありません。WebView2 側の復旧では、最終的に Microsoft の公式ダウンロードページから Evergreen Bootstrapper か Evergreen Standalone Installer を使って上書き再インストールするのが確実です。オフラインや厳しいプロキシ環境なら Standalone が向いています。(Microsoft Support)
管理者権限で実行すると per-machine、非管理者で実行すると per-user のインストールになります。企業端末では、再起動、空き容量確認、管理者実行、関連アプリ停止もあわせて行ってください。(Microsoft Learn)
更新後はアプリ、できれば PC も再起動する
Evergreen は更新されても、アプリが旧環境オブジェクトを握ったままだと新しい Runtime に切り替わりません。更新したのに直らないときは、対象アプリの再起動だけでなく、利用者が多い端末では PC 再起動までやった方が早いケースがあります。(Microsoft Learn)
まだ崩れるなら UDF を退避して再生成させる
UDF には Cookie、権限、キャッシュが入るため、削除するとログイン状態や一部設定は消えます。それでも、更新後から特定ユーザーだけ壊れた、再インストールしても変わらないという場合は有効です。Microsoft も UDF 削除を「データ破損からの復旧」手段として挙げています。削除よりも、まずは フォルダー名を .bak に変更して退避する方が安全です。(Microsoft Learn)
Win32/.NET の既定 UDF は、実行ファイルの場所に .WebView2 として作られます。ただし最近のアプリはカスタム UDF を使うことも多いため、自社アプリなら実装で指定しているパス、製品アプリならベンダー資料を確認してください。いずれにせよ、UDF を触る前にブラウザープロセスが完全終了していることが前提です。(Microsoft Learn)
すぐ止血したいときの回避策
利用者視点の応急処置は、公式 Evergreen の再インストール → アプリ再起動 → UDF 退避が基本です。一方で、業務影響が大きく、直近の更新でだけ壊れた自社アプリや LOB アプリなら、管理者・開発者側で 既知の正常版に一時固定する選択肢があります。具体的には、Fixed Version を同梱するか、BrowserExecutableFolder で明示的な Runtime パスを使わせる方法です。(Microsoft Learn)
ただしこれは恒久対策ではありません。Fixed Version は自動更新されず、セキュリティ修正も自前で追従が必要です。Microsoft も、厳密な互換性要件がある場合を除き Evergreen を推奨しています。つまり、止血には使えても、放置すると別の問題を招きます。(Microsoft Learn)
症状から逆引きするときの見方
| 状況 | 最初に疑うこと |
|---|---|
| 更新直後に一部端末だけ崩れた | Update (WebView) や更新抑止、WSUS/MDM 配信差、またはアプリ再起動漏れを疑います。Evergreen は更新後も再起動まで旧 Runtime を使い続けます。(Microsoft Learn) |
| 開発機・検証機だけ再現する | BrowserExecutableFolder、ReleaseChannels、ChannelSearchKind、WEBVIEW2_* による上書きで Beta/Dev/Canary や別 Runtime を拾っている可能性があります。(Microsoft Learn) |
| インストール直後から起動しない | UDF の作成先が保護フォルダーで、書き込みに失敗している可能性があります。Win32/.NET の既定 UDF は exe の隣に作られるので要注意です。(Microsoft Learn) |
| レジストリでは未インストールに見える | Fixed Version 同梱アプリの可能性があります。Fixed Version は通常の Runtime レジストリキーを使いません。(Microsoft Learn) |
管理者・開発者が再発を防ぐポイント
管理者が見るべき設定
見落としやすいのは、Edge ブラウザーのポリシーと WebView2 のポリシーは別物だという点です。Microsoft も、ブラウザーポリシーをそのまま WebView2 に当てると意図しない破壊が起きるため、WebView2 専用ポリシーを使う設計にしていると明記しています。Edge の更新設定だけ見て安心しないことが大事です。(Microsoft Learn)
管理者が最低限押さえるべきなのは、Install{F301...}、Update{F301...}、BrowserExecutableFolder、ChannelSearchKind、ReleaseChannels の5系統です。特に Edge の更新無効化と WebView2 の更新無効化は別設定なので、片方だけ見て原因を断定しないでください。(Microsoft Learn)
また、WSUS や Configuration Manager での配布は可能ですが、Microsoft は 既定の Microsoft Edge Updater を使う更新経路を推奨しており、更新・サービス経路の改変は慎重に行うべきだとしています。端末差が出やすい運用をしているなら、まずそこを疑うのが現実的です。(Microsoft Learn)
開発者が入れておくべき保険
開発側の基本方針は、通常は Evergreen、厳密な互換性が必要なときだけ Fixed Versionです。Evergreen を使うなら、新しい API 呼び出しは QueryInterface や try-catch で機能検出し、必要なら CompareBrowserVersions で最小版数を比較してください。(Microsoft Learn)
加えて、障害調査のログには 実際に使われた BrowserVersionString とチャネル名を残すのが有効です。BrowserVersionString は Runtime 以外のチャネルを使っている場合にチャネル情報も返します。ここを記録しておくと、「本番だけ Canary を拾っていた」といった事故をすぐ見抜けます。(Microsoft Learn)
UDF は既定任せにしない方が安全です。Win32/.NET では、書き込み可能なカスタム UDF を明示して、アプリデータ用フォルダーに寄せた方がトラブルが減ります。さらに、長時間起動するアプリでは NewBrowserVersionAvailable を拾って再起動を促す設計にしておくと、更新後の旧 Runtime 残留を減らせます。(Microsoft Learn)
もう一歩踏み込むなら、Stable に来る前に Canary / Dev / Beta で事前検証してください。Microsoft も、プレビュー チャネルでの事前テストは、Stable の Evergreen Runtime に乗る前にアプリ固有の回帰を見つけるために有効だと案内しています。(Microsoft Learn)
Fixed Version を使うなら権限も確認する
固定版を自前同梱している Win32 アプリでは、Runtime の版数だけでなく配置フォルダーの ACLも見ます。Microsoft は、Windows 10 の unpackaged Win32 アプリで Fixed Version 120 以降を使う場合、App Container 用の権限設定が必要になるケースを案内しています。固定版だけが特定端末で起動しないなら、版数より先に配置フォルダー権限を疑った方が早いことがあります。(Microsoft Learn)
最後にやること
Microsoft Edge WebView2ランタイム不整合の対処は、関連プロセス停止 → Runtime の有無と版数確認 → ポリシー/上書き確認 → 公式 Evergreen で再インストール → UDF 退避の順で進めると、遠回りしにくくなります。社内端末や自社アプリなら、最後に 実際の BrowserVersionString、Install/Update のポリシー値、BrowserExecutableFolder / ReleaseChannels / ChannelSearchKind の設定、UDF パスまで記録しておくと、再発時の対応速度が一段上がります。(Microsoft Learn)
コメント