Microsoft EdgeのWebView2 Runtimeで障害が起きたとき、これまでは「更新を止める」「アプリ側でFixed Versionを同梱する」「問題が解消するまで運用回避する」といった対応になりがちでした。今回の「Enterprise WebView2 runtime downgrade via Downgrade Version policy」は、その選択肢を増やす変更です。
結論から言うと、企業管理端末では、特定のWebView2アプリだけを前世代または2世代前のEvergreen Runtimeへ一時的に戻せるようになります。全端末・全アプリを古い状態に固定する機能ではなく、重大なリグレッションが発生したアプリを限定して回避するための管理ポリシーです。Microsoft 365 RoadmapではID 561329として掲載され、一般提供は2026年6月予定、状態は「In development」とされています。ロードマップ情報は変更される可能性があるため、展開前に最新の公式情報を確認してください。(Microsoft)
WebView2 RuntimeのDowngrade Version policyで何が変わるのか
今回の変更では、msedgewebview2.admxに追加される新しいDowngrade Version policyを使い、管理者がWebView2 Evergreen Runtimeのバージョンをアプリ単位で一時的に下げられるようになります。指定できるのは、現在のRuntimeをNとした場合のN-1またはN-2です。(Microsoft)
ポイントは「アプリ単位」であることです。たとえば、社内業務アプリAだけが最新WebView2 Runtimeで画面崩れを起こし、TeamsやOutlook、別の社内アプリは問題なく動いている場合、アプリAの実行ファイルだけを旧Runtimeへ向ける運用が可能になります。
Microsoftの説明では、管理者はアプリケーションのexeと対象バージョンの対応関係を指定します。Edge Updaterは対象Runtimeをサイドバイサイドでインストールし、WebView2 Loaderが対象アプリを指定されたRuntimeへリダイレクトします。(Microsoft)
| 項目 | 従来の対応で起きやすかった課題 | 新ポリシーで期待できる対応 |
|---|---|---|
| 障害対象 | WebView2 Runtime全体の更新停止になりやすい | 問題のあるアプリだけを対象化できる |
| バージョン管理 | Fixed Version同梱や更新抑制に寄りがち | Evergreen Runtimeを前提に一時的な回避ができる |
| セキュリティ | 古いRuntimeに残り続けるリスクがある | ダウングレードが自動失効する設計 |
| 展開単位 | 端末全体・Runtime全体の影響が大きい | exe単位のマッピングで影響を絞れる |
対象になる環境と対象外になる環境
このポリシーは、ドメイン参加済みまたはMDM登録済みの企業管理端末にのみ適用されると説明されています。個人PCや管理外端末で、ユーザーが任意にWebView2 Runtimeを戻すための機能ではありません。(Microsoft)
対象になりやすいのは、次のような環境です。
- Microsoft Edge WebView2を利用する社内業務アプリを多数展開している企業
- MDM、Intune、グループポリシーなどで端末を集中管理している組織
- WebView2 Runtimeの自動更新後に、特定アプリで表示・認証・入力・印刷などの問題が起きる可能性がある環境
- Fixed Version Runtimeの同梱を避け、Evergreen Runtimeを標準にしたい開発・運用チーム
一方で、単に「古いほうが安定していそうだから全社で固定したい」という用途には向きません。MicrosoftはWebView2 Runtimeについて、原則としてEvergreen Runtimeの利用を推奨しており、古いRuntimeでは最新の品質更新やセキュリティ更新を受けられないと説明しています。(Microsoft Learn)
この機能の本質は「恒久的なバージョン固定」ではなく「短期の障害回避」
Downgrade Version policyを理解するうえで重要なのは、これは長期的なバージョン固定機能ではないという点です。
Microsoftのロードマップでは、ダウングレードは新しいWebView2リリースごとに自動失効すると説明されています。N-1に固定されたアプリは次のリリース時点で同じバージョンに残り、その時点ではN-2扱いになります。その次のリリースでは自動更新されます。N-2に固定されたアプリは、次の新リリースで現在のEvergreen Runtimeへ戻ります。(Microsoft)
たとえば、仮に次のような状態だとします。
| 時点 | 現在のRuntime | アプリAの指定 | その後の動き |
|---|---|---|---|
| 初期状態 | N | N-1へダウングレード | アプリAだけ旧Runtimeを使用 |
| 次のWebView2リリース後 | 新しいN | 旧N-1はN-2相当 | 一時的に継続 |
| さらに次のリリース後 | さらに新しいN | 自動更新 | Evergreen Runtimeへ戻る |
この仕組みは、管理者が問題を回避する時間を確保しつつ、端末が古いRuntimeに残り続けることを防ぐための設計と考えられます。
Edgeブラウザーのロールバックとは何が違うのか
Microsoft Edgeには、ブラウザー本体を以前のバージョンへ戻すエンタープライズ向けロールバック機能があります。ただし、これはEdgeブラウザーのバージョンを戻す仕組みであり、WebView2アプリ単位のRuntime切り替えとは目的が異なります。MicrosoftもEdgeブラウザーのロールバックは一時的な修正手段であり、古いバージョンへ戻すと既知のセキュリティ問題にさらされるリスクがあると説明しています。(Microsoft Learn)
| 比較項目 | Edgeブラウザーのロールバック | WebView2 Downgrade Version policy |
|---|---|---|
| 主な対象 | Microsoft Edgeブラウザー | WebView2 Runtimeを使う特定アプリ |
| 適用単位 | Edgeのインストール単位 | exeとバージョンの対応付け |
| 目的 | Edge更新によるブラウザー問題の一時回避 | WebView2アプリの重大なリグレッション回避 |
| 運用上の注意 | ブラウザーデータやセキュリティリスクに注意 | 古いRuntimeへ残し続けない設計が必要 |
| 今回の変更点 | 既存機能 | 新たに追加予定のWebView2向けポリシー |
実務では、「Edgeブラウザーで問題が起きているのか」「WebView2を利用する特定アプリで問題が起きているのか」を切り分けることが重要です。WebView2アプリの不具合なのにEdge本体をロールバックすると、影響範囲を広げてしまう可能性があります。
管理者がまず確認すべき設定と運用ポイント
最新の管理テンプレートを確認する
この機能はmsedgewebview2.admxに追加されるポリシーとして説明されています。既存のWebView2ポリシーは、Microsoft Edge WebView2の管理テンプレートから構成でき、MicrosoftのポリシードキュメントではWebView2の実行方法を組織内で制御できると説明されています。(Microsoft)
展開前には、次の点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| ADMX/ADML | Downgrade Version policyが管理テンプレートに反映されているか |
| 管理方式 | グループポリシー、MDM、Intuneなど、対象端末へ確実に配布できるか |
| 対象端末 | ドメイン参加済み、またはMDM登録済みか |
| 対象アプリ | exe名が正確か。複数バイナリやランチャー経由の起動がないか |
| Runtime更新 | WebView2 Runtimeの更新ポリシーを過度に止めていないか |
WebView2 Runtimeの更新ポリシーと競合しないか確認する
Microsoft Edge Updateには、WebView2 Runtimeのインストール可否や自動更新を制御するポリシーがあります。たとえば、Install (WebView)ではWebView2 RuntimeをMicrosoft Edge Update経由でインストールできるかを制御でき、Update (WebView)では自動更新の有効・無効を制御できます。自動更新は既定で有効であり、無効化するとWebView2依存アプリの互換性問題を引き起こす可能性があると説明されています。(Microsoft Learn)
Downgrade Version policyを使う場合でも、WebView2 Runtime全体の自動更新を長期停止する運用は避けるべきです。ダウングレードは「問題のあるアプリを一時的に戻す」ためのものであり、Runtime更新を止めるための代替手段ではありません。
対象アプリをexe単位で正確に洗い出す
このポリシーでは、アプリケーションごとのexeとバージョンのマッピングが要点になります。ここで失敗しやすいのは、実際にWebView2を起動しているexeと、ユーザーが普段起動しているショートカットのexeが異なるケースです。
たとえば、次のような構成では注意が必要です。
- ランチャーアプリから本体アプリを起動する
- 自動更新用プロセスと本体プロセスが分かれている
- 32bit版と64bit版のexe名が異なる
- 同じ製品内に複数のWebView2利用プロセスがある
- VDIや公開アプリ環境で実行パスが端末ごとに異なる
展開前には、タスクマネージャー、Process Explorer、アプリログ、WebView2関連プロセスの起動状況を使い、実際に対象にすべきexeを確認しておく必要があります。
開発者が確認すべき互換性・移行上のポイント
Evergreen Runtime前提のテストを強化する
WebView2のEvergreen Runtimeは自動更新され、最新機能やセキュリティパッチを利用できるのが利点です。Microsoftは、多くのWebView2アプリではFixed Version RuntimeではなくEvergreen Runtimeを推奨しています。(Microsoft Learn)
今回のポリシーが追加されても、開発側の基本方針は変わりません。ダウングレードできるからテストを省くのではなく、次のリリースで壊れないように前方互換性テストを継続する必要があります。
実務では、次のテストをリリース前チェックに入れてください。
| テスト観点 | 確認内容 |
|---|---|
| 表示 | CSS、フォント、拡大率、PDF表示、ポップアップ、印刷 |
| 認証 | Entra ID連携、Cookie、SSO、条件付きアクセス |
| 入力 | IME、日本語入力、フォームバリデーション、ショートカットキー |
| 通信 | CORS、プロキシ、証明書、社内API接続 |
| 更新 | Runtime更新後の再起動、長時間起動時の挙動 |
| 障害時 | Runtimeプロセス異常終了時の復旧、ログ出力 |
新しいAPIは機能検出を前提にする
WebView2アプリで新しいAPIを使う場合、クライアント側のRuntimeが最新とは限りません。Microsoftは、QueryInterfaceやtry-catchなどを使い、インストール済みRuntimeが新しいAPIをサポートしているかを確認することを推奨しています。(Microsoft Learn)
Downgrade Version policyによって、特定アプリが一時的にN-1またはN-2で動く可能性が出てきます。そのため、開発者は「最新Runtimeなら動く」だけでなく、「一時的に旧Runtimeで起動しても致命的に壊れない」設計を意識すべきです。
具体的には、次のような実装が有効です。
- 新APIを呼ぶ前に対応可否を判定する
- 非対応時の代替処理を用意する
- Runtimeバージョンをログに出力する
- 画面崩れやAPI失敗をユーザーに分かる形で通知する
- 管理者が調査できるよう、アプリ名・exe名・Runtimeバージョン・OS・発生時刻を記録する
長時間起動するアプリは再起動設計を見直す
Evergreen WebView2 Runtimeの新しいバージョンは自動的にダウンロードされますが、実行中のWebView2アプリは前のRuntimeを使い続ける場合があります。新しいRuntimeを使うには、古いWebView2環境オブジェクトへの参照を解放するか、アプリを再起動する必要があります。MicrosoftはNewBrowserVersionAvailableイベントを使って、ユーザーに再起動を促す方法にも触れています。(Microsoft Learn)
常駐型アプリ、コールセンター端末、工場端末、VDI上の業務アプリでは、数日間アプリを閉じない運用も珍しくありません。この場合、ダウングレードや復帰のタイミングが実際のアプリ動作に反映されるまで遅れる可能性があります。
運用ルールとして、次のような設計を用意しておくと安全です。
- 業務終了時にアプリを終了するルールを定める
- 更新・切り戻し後は対象アプリを再起動する
- 重要アプリでは再起動通知をアプリ内に表示する
- ユーザー状態を保存してから再起動できるようにする
- 再起動できない端末はメンテナンス時間を確保する
展開前に作っておきたい判断基準
Downgrade Version policyは便利ですが、安易に使うと原因調査が遅れます。適用するかどうかは、影響度と回避策の有無で判断するのが現実的です。
| 状況 | 推奨判断 |
|---|---|
| 1つの社内アプリで業務停止レベルの障害がある | 限定的なダウングレードを検討 |
| 表示崩れはあるが業務継続できる | まずアプリ修正・設定変更・回避手順を検討 |
| 複数アプリで広範囲に問題が出ている | Runtime更新、ポリシー、セキュリティ製品、プロキシなどを横断調査 |
| 原因がEdgeブラウザー本体にある | WebView2ではなくEdge側のロールバックや修正情報を確認 |
| 旧Runtimeへ戻す理由が「念のため」だけ | 適用しない。検証環境で監視する |
| N-2へ戻さないと動かない | 重大度は高い。アプリ改修計画を同時に開始 |
特にN-2へのダウングレードが必要な場合は、単なる一時回避ではなく、アプリ側に最新Webプラットフォームへの追従課題がある可能性があります。ポリシー適用と同時に、開発チームへ再現条件、エラーログ、影響範囲を共有しましょう。
推奨される展開手順
実際の展開では、いきなり全社適用せず、段階的に進めるべきです。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 事前調査 | 障害アプリ、exe名、Runtimeバージョン、発生端末を特定 | ショートカット名だけで判断してしまう |
| 検証 | 検証端末でN-1、必要ならN-2を試す | アプリ再起動を忘れ、反映されていないと誤判定する |
| 限定展開 | 影響部門・数台の端末に絞って配布 | MDM登録外端末が混在する |
| 監視 | 起動可否、表示、認証、印刷、ログを確認 | 「起動した」だけで業務OKと判断する |
| 原因修正 | アプリ改修、Webコンテンツ修正、設定変更を進める | ダウングレードを恒久対応にしてしまう |
| 解除確認 | 新リリース後の自動復帰、またはポリシー削除を確認 | ポリシーが残り、再発時の原因になる |
展開時には、ユーザー向けにも短い案内を出しておくと問い合わせを減らせます。たとえば「対象アプリで表示不具合を回避するため、一時的にWebView2 Runtimeの参照先を変更します。作業後はアプリを再起動してください。Edgeブラウザーの通常利用には影響しません」といった説明です。
トラブル時に確認すべきログと切り分け
WebView2 Runtimeのインストール、更新、ロールバックで問題が起きる場合、権限、ネットワーク、TLS、セキュリティソフト、システムコンポーネント破損、残存インストール情報などが原因になり得ます。Microsoftのトラブルシューティング資料でも、GPO、MDM、セキュリティポリシーが企業環境で失敗原因になることがあると説明されています。(Microsoft Learn)
まず確認すべき項目は次のとおりです。
- 対象端末がドメイン参加またはMDM登録済みか
- 新しいADMX/ADMLが管理環境に反映されているか
edge://policyで関連ポリシーが反映されているか- 対象アプリを完全に終了してから再起動したか
msedge.exeやmsedgewebview2.exeが残っていないか- WebView2 Runtimeのインストールに必要な空き容量があるか
- セキュリティ製品が
msedgeupdate.exeやインストーラーの動作をブロックしていないか
Microsoftの資料では、更新ログとして%ALLUSERSPROFILE%\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log、インストールログとして%WINDIR%\Temp\msedge_installer.logなどが案内されています。管理者は、ポリシーJSONのエクスポートやProcess Monitorログも含めて、再現時の証跡を残しておくと調査が進めやすくなります。(Microsoft Learn)
Fixed Version Runtimeとの使い分け
WebView2には、Evergreen RuntimeとFixed Version Runtimeがあります。Fixed Versionでは特定バージョンのRuntimeをアプリと一緒に配布できますが、Runtimeをアプリ側で定期的に更新する責任が生じます。Microsoftのドキュメントでは、Fixed Versionのバイナリは250MBを超え、アプリパッケージがその分大きくなるとも説明されています。(Microsoft Learn)
今回のDowngrade Version policyは、Fixed Versionを完全に置き換えるものではありません。次のように使い分けると分かりやすいです。
| 選択肢 | 向いているケース |
|---|---|
| Evergreen Runtime | 通常の業務アプリ。最新機能・セキュリティ更新を重視する場合 |
| Downgrade Version policy | Evergreen前提だが、特定更新で重大なリグレッションが出た場合の一時回避 |
| Fixed Version Runtime | オフライン、閉域、厳密な互換性要件があり、アプリ側でRuntime更新を管理できる場合 |
多くの企業では、標準はEvergreen Runtime、緊急時の回避策としてDowngrade Version policy、特殊要件のアプリだけFixed Versionという整理が現実的です。
管理者と開発者が今すぐ準備すべきこと
この機能が一般提供される前に、管理者と開発者は次の準備を進めておくと、リリース後の対応が速くなります。
管理者向けチェックリスト
- WebView2を使っている社内アプリ一覧を作る
- アプリごとのexe名、インストールパス、利用部門を整理する
- WebView2 Runtimeの更新ポリシーを棚卸しする
- 検証端末でEdge Update、WebView2 Runtime、MDM配布の動作を確認する
- 障害時の連絡経路を、情シス、開発、業務部門で決めておく
- ダウングレード適用時の解除基準を事前に決める
開発者向けチェックリスト
- Runtimeバージョンをアプリログに出せるようにする
- 最新Runtimeとプレビュー系チャネルで前方互換性テストを行う
- 新API利用時は機能検出と代替処理を入れる
- WebView2プロセス異常終了時の復旧処理を実装する
- アプリ再起動時にユーザー状態が失われないようにする
- N-1、N-2相当のRuntimeで最低限のスモークテストを用意する
まとめ：アプリ単位の一時回避策として使い、恒久対応はアプリ修正で進める
Microsoft Edgeの「Enterprise WebView2 runtime downgrade via Downgrade Version policy」は、WebView2 Evergreen Runtimeの更新で特定アプリに重大な問題が出たとき、管理者がアプリ単位でN-1またはN-2へ一時的に戻せる新しい選択肢です。サイドバイサイドで対象Runtimeを用意し、WebView2 Loaderが対象アプリを指定Runtimeへ向けるため、影響範囲を絞った障害回避が期待できます。(Microsoft)
ただし、これは古いRuntimeへ恒久的に固定する機能ではありません。古いWebView2 Runtimeに残るとセキュリティ更新を受けられないリスクがあるため、適用は重大障害時の短期回避に限定し、並行してアプリ修正、互換性テスト、更新運用の見直しを進めるべきです。管理者はADMX、MDM/GPO、exeマッピング、Runtime更新ポリシーを確認し、開発者はEvergreen前提のテストと機能検出を強化しましょう。(Microsoft Learn)
コメント