Microsoft Edge WebView2のダウングレードポリシー変更で最初に押さえるべき結論は、企業管理端末で、WebView2 Evergreen Runtimeをアプリ単位で一時的に前のメジャーバージョンへ戻せるようになるという点です。Edgeブラウザー全体を戻す機能ではなく、特定のWebView2アプリだけを対象にした障害回避策です。Microsoft Edge Stable 149.0.4022.52の機能更新として、DowngradeVersionポリシーにより、特定アプリをWebView2 Evergreen RuntimeのN-1またはN-2へ一時的にロールバックできることが案内されています。(Microsoft Learn)
WebView2は、デスクトップアプリ内にWebコンテンツを表示するための埋め込みブラウザー基盤です。Evergreen Runtimeは自動更新されるため、通常はセキュリティや互換性の面でメリットがあります。一方で、更新直後に社内アプリや業務アプリの画面表示、認証、PDF表示、JavaScript処理などに不具合が出た場合、アプリ所有者とIT管理者は「アプリを止めずに、どこまで戻せるのか」をすぐ判断する必要があります。今回の変更は、その判断と初動対応をしやすくするためのものです。
Microsoft Edge WebView2のダウングレードポリシーで何が変わるのか
今回のポイントは、WebView2 Evergreen Runtimeのロールバックを端末全体ではなく、アプリ単位で指定できることです。
従来、WebView2 Runtimeの更新後に特定アプリだけで不具合が起きた場合、対応は難しくなりがちでした。アプリ側の修正を待つ、更新を抑制する、Fixed Version Runtimeへ切り替える、端末ごとに手作業で対処する、といった運用になりやすく、影響範囲の切り分けにも時間がかかります。
DowngradeVersionポリシーでは、アプリの実行ファイル名またはApplication User Model IDと、使用させたいWebView2 Runtimeのメジャーバージョンを対応付けます。Microsoftのポリシー文書では、値名にteams.exeのような実行ファイル名、値に145のような数字のみのメジャーバージョンを指定する例が示されています。フルバージョン文字列やワイルドカード値、区切り文字を含む値はサポートされません。(Microsoft Learn)
| 観点 | これまで起きやすかった課題 | DowngradeVersionで変わる点 |
|---|---|---|
| 対象範囲 | WebView2を使う複数アプリへの影響を分けにくい | 特定の実行ファイルまたはアプリID単位で指定できる |
| 障害対応 | Runtime更新後の一時回避策が重くなりやすい | N-1またはN-2への一時退避を選択肢にできる |
| 更新管理 | Evergreen更新を止める判断になりやすい | 対象アプリ以外は通常のEvergreen運用を続けやすい |
| アプリ所有者の役割 | 「WebView2が原因らしい」だけでは依頼しにくい | 対象アプリ、再現条件、戻したいメジャー版を明確に依頼できる |
重要なのは、このポリシーが「古いRuntimeに固定し続けるための仕組み」ではないことです。Microsoftのリリースノートでは、ダウングレードはWebView2の新しいリリースごとに自動失効する設計であり、N-1に固定したアプリは次のリリース時に同じ版がN-2相当となり、その次のリリースで自動更新され、N-2に固定したアプリは次のリリースで現在のEvergreen版へ戻ると説明されています。(Microsoft Learn)
アプリ所有者が「戻せるもの」と「戻せないもの」
アプリ所有者や業務部門が誤解しやすいのは、「WebView2を戻せる」という表現の範囲です。実際に戻せるのは、対象アプリが利用するWebView2 Evergreen Runtimeのメジャーバージョンです。アプリ本体、Edgeブラウザー、OS更新、すべてのWebView2アプリを一括で戻す機能ではありません。
戻せるもの
対象になるのは、企業管理されたWindows端末上のWebView2 Evergreen Runtimeを利用する特定アプリです。リリースノートでは、ドメイン参加またはMDM登録された企業管理端末に適用されると説明されています。(Microsoft Learn)
具体的には、次のようなケースで検討します。
| 状況 | DowngradeVersionを検討できる例 |
|---|---|
| Runtime更新後に特定アプリだけ起動しない | 社内業務アプリAだけが白画面になる |
| WebView2内の認証画面だけ失敗する | SSO画面が開かない、リダイレクト後に止まる |
| 表示や入力の不具合が更新後に再現する | 特定フォームで入力欄が反応しない |
| 業務停止を避ける必要がある | 月末処理や問い合わせ対応など、短期間でも停止できない |
戻せないもの
次の用途には向きません。
| 誤解 | 実際の考え方 |
|---|---|
| Microsoft Edgeブラウザー全体を戻せる | 対象はWebView2 Runtimeであり、Edgeブラウザーの通常ロールバックとは別です |
| 任意の古いバージョンを指定できる | リリースノート上の説明ではN-1またはN-2が対象です |
145.0.1234.56のように細かいビルドまで固定できる | DowngradeVersionの値は数字のみのメジャーバージョン指定です |
| ずっと古いRuntimeに固定できる | 自動失効する一時的な回避策として扱うべきです |
| すべての端末で使える | 企業管理端末が前提です |
DowngradeVersionポリシーの設定で確認すべき項目
DowngradeVersionは、Microsoft Edge WebView2の「Loader Override Settings」に追加されたポリシーです。WindowsではMicrosoft Edge 149以降が対象とされ、ADMXファイル名はMSEdgeWebView2.admxです。ポリシー文書では、データ型は文字列リスト、動的ポリシー更新は対応とされています。(Microsoft Learn)
設定で特に重要なのは、値名と値の組み合わせです。
| 項目 | 指定内容 | 注意点 |
|---|---|---|
| 値名 | Application User Model ID、または実行ファイル名 | 例としてteams.exe、outlook.exeのような形式が示されています |
| 値 | 対象のメジャーバージョン番号 | 145のように数字のみで指定します |
| 指定できない値 | フルバージョン、ワイルドカード、区切り文字付きの値 | 145.0.1234.56や145.*は不可です |
| 動作条件 | 対象メジャーバージョンのRuntimeフォルダーが見つかること | 見つからない場合、ポリシーは効果を持ちません |
公式文書の例は、次のような考え方です。
SOFTWARE\Policies\Microsoft\Edge\WebView2\DowngradeVersion
Name: teams.exe, Value: 145
Name: outlook.exe, Value: 146ただし、実務では「ポリシーを入れたら必ずその版に切り替わる」と考えない方が安全です。ポリシー文書では、WebView2 LoaderがRuntimeのインストールディレクトリをスキャンし、指定したメジャーバージョンに一致するインストール済みフォルダーを探すと説明されています。一致するフォルダーがない場合、BrowserExecutableFolderポリシーまたは既定のEvergreen Runtimeへフォールバックします。(Microsoft Learn)
一方で、リリースノートではEdge Updaterが対象バージョンをサイドバイサイドでインストールし、WebView2 Loaderが対象アプリをリダイレクトすると説明されています。(Microsoft Learn) そのため展開時は、ポリシー配布だけでなく、対象端末で実際に該当Runtimeが配置され、対象アプリが想定バージョンを使っているかまで確認する必要があります。
自動失効を前提にした運用設計が必要
DowngradeVersionは、緊急避難用のスイッチです。アプリ所有者にとっては便利な保険ですが、恒久的な互換性対策ではありません。
例えば、ある時点のWebView2 Evergreen RuntimeのCurrentが149だったとします。このとき、148はN-1、147はN-2として扱えます。
| 指定内容 | 期待される使い方 | 次のリリース時の考え方 |
|---|---|---|
| N-1へ戻す | 直近更新で発生した不具合の一時回避 | 次のリリースで同じ版がN-2相当となり、さらに次のリリースで自動更新される前提 |
| N-2へ戻す | N-1でも問題が残る場合の短期回避 | 次のリリースでCurrent Evergreenへ戻る前提 |
| それ以前へ戻す | 想定しない | 長期固定が必要ならFixed Version Runtimeなど別の設計を検討 |
この自動失効は、セキュリティ面では重要です。WebView2アプリが外部サイトや信頼できないコンテンツを扱う場合、古いRuntimeを使い続けることはリスクになります。MicrosoftのWebView2配布ドキュメントでも、Evergreen Runtimeの新バージョンはアプリ再起動後に使われ、古いRuntimeを使い続けることにはセキュリティ上の影響があると説明されています。(Microsoft Learn)
そのため、DowngradeVersionを使う場合は、最初から「いつ戻すか」を決めておくべきです。障害チケットには、適用日、対象端末、対象アプリ、指定メジャーバージョン、解除予定日、恒久対応の担当者を残しておくと、古いRuntimeが放置されにくくなります。
管理者が導入前に確認すべきチェックリスト
DowngradeVersionは強力ですが、設定ミスや切り分け不足のまま使うと、問題の原因が見えにくくなります。管理者は、少なくとも次の項目を確認してから展開してください。
| 確認項目 | 確認する理由 | 失敗しやすいポイント |
|---|---|---|
| 対象端末が企業管理端末か | ポリシー適用対象を満たす必要がある | 個人所有端末や未管理端末で同じ動作を期待する |
| 対象アプリの実行ファイル名またはAUMID | ポリシーはアプリ単位で指定するため | ランチャーのexeと実際のWebView2ホストexeを取り違える |
| 現在のWebView2 Runtimeバージョン | N、N-1、N-2の判断に必要 | Edgeブラウザーのバージョンだけを見て判断する |
| 戻したいメジャーバージョン | 値は数字のみで指定する | フルバージョンやワイルドカードを入れる |
| ADMXと管理基盤の対応 | MSEdgeWebView2.admxの最新化が必要 | 古い管理テンプレートのまま設定項目を探す |
| 展開リング | いきなり全社適用しないため | 検証端末なしで本番一括適用する |
| 解除条件 | 一時回避を恒久化しないため | 問題が収束してもポリシーが残る |
特に注意したいのは、対象アプリの特定です。ユーザーが起動しているアプリ名と、実際にWebView2をホストしているプロセス名が一致しないことがあります。開発者またはアプリベンダーに、WebView2を生成している実行ファイル名、ユーザーデータフォルダー、Runtime検出方法を確認してから指定する方が安全です。
開発者とアプリ所有者が管理者へ渡すべき情報
アプリ所有者が「WebView2を戻してください」と依頼するだけでは、管理者は安全に判断できません。DowngradeVersionを使うには、技術情報と業務影響をセットで渡す必要があります。
| 渡す情報 | 具体例 |
|---|---|
| 対象アプリ | アプリ名、バージョン、インストール方式、実行ファイル名 |
| 発生条件 | 起動直後、ログイン後、特定画面表示時、PDF表示時など |
| 影響範囲 | 全ユーザーか、特定部署か、特定OS・端末だけか |
| 再現手順 | 何をクリックし、どの画面で止まるか |
| 正常だった時期 | いつまでは動いていたか |
| 現在のRuntime版 | 問題発生端末のWebView2 Runtimeメジャー版 |
| 戻したい候補 | N-1でよいのか、N-2が必要なのか |
| 恒久対応 | アプリ修正、SDK更新、回避パッチの予定 |
開発者側では、WebView2の新しいAPIに依存しているか、Runtimeが古い場合に機能検出できているかも確認してください。MicrosoftのWebView2ドキュメントでは、Evergreen Runtimeは自動更新される一方、アプリは特定バージョンを要求できないという前提が説明されています。Fixed Versionではアプリ側がRuntimeのバージョンを制御できますが、Runtimeの管理と更新もアプリ側の責任になります。(Microsoft Learn)
展開手順の実務例
DowngradeVersionを本番環境に入れる場合は、次の順序で進めると失敗しにくくなります。
影響アプリとRuntime更新の関係を切り分ける
まず、障害が本当にWebView2 Runtime更新に起因するかを確認します。同じアプリの旧端末、新端末、異なるRuntimeメジャー版の端末で再現性を比べます。アプリのサーバー側変更、認証基盤、プロキシ、証明書、DLP、EDRなどの変更と時期が重なっていないかも確認してください。
テスト端末でN-1を先に検証する
いきなりN-2へ戻すのではなく、まずN-1で問題が解消するかを見ます。N-1で解消するなら、セキュリティと互換性のバランスを取りやすくなります。N-2が必要な場合は、業務影響が大きいこと、N-1でも解消しないこと、解除予定が明確であることを条件にします。
小さなグループへ展開する
最初はIT部門、アプリ所有者、影響部署の代表ユーザーなど、限定したグループへ配布します。起動、ログイン、主要画面、印刷、ファイル添付、外部リンク、PDF表示、クリップボード操作など、業務フローに沿って確認します。
問題が解消したら期限付きで広げる
本番展開するときは、対象端末グループを明確にし、解除予定日を設定します。DowngradeVersionは「問題が起きたから戻す」だけでなく、「戻している間に何を直すか」まで管理して初めて効果があります。
修正後にポリシーを解除する
アプリ修正、Microsoft側の新しいRuntimeリリース、または回避策の確認が済んだら、ポリシーを解除してCurrent Evergreenへ戻します。解除後も、対象アプリが最新Runtimeで正常に動くかを再確認します。
Fixed Version RuntimeやBrowserExecutableFolderとの使い分け
DowngradeVersionは、WebView2のバージョン管理に関する選択肢の一つです。すでにFixed Version RuntimeやBrowserExecutableFolderを使っている環境では、どの方式を使うべきか整理しておく必要があります。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| DowngradeVersion | Evergreen運用中の特定アプリで、直近更新による重大な回帰を一時回避したい | N-1/N-2を前提にした短期運用。恒久固定には向かない |
| BrowserExecutableFolder | 特定アプリに特定のWebView2 Runtimeフォルダーを使わせたい | フォルダー管理や配布設計が必要。既存ポリシーとの優先関係を確認する |
| Fixed Version Runtime | 厳格な互換性要件があり、アプリとRuntimeを一体で管理したい | Runtimeは自動更新されず、アプリ側で定期更新が必要。パッケージサイズも大きくなりやすい |
Microsoftのドキュメントでは、Evergreen Runtimeは多くの開発者に推奨され、自動更新と共有Runtimeによる運用メリットがあります。一方、Fixed Version Runtimeはアプリに特定バージョンを同梱して制御できますが、Runtime更新を開発者側で管理する必要があります。(Microsoft Learn)
判断基準はシンプルです。通常運用はEvergreen、緊急回避はDowngradeVersion、長期的に特定Runtimeをアプリと一体管理したい場合はFixed Versionを検討します。DowngradeVersionで長期間しのぐ設計にすると、セキュリティ更新の取り込みや将来互換性の確認が遅れます。
展開時に起きやすいトラブルと対処
WebView2のインストール、更新、ロールバックでは、権限、ネットワーク、TLS、セキュリティソフト、システムコンポーネントの破損、残存インストール情報などが原因で失敗することがあります。Microsoftのトラブルシューティング文書でも、WebView2ダウングレード後にアプリが起動しない、Runtimeが見つからない、Edge Updateが再試行を繰り返す、MSIエラーが出るといった症状が挙げられています。(Microsoft Learn)
実務でまず確認したいのは、次の項目です。
| 症状 | 確認ポイント |
|---|---|
| ポリシーを配布したのに切り替わらない | 対象exe名、AUMID、指定メジャー版、Runtimeフォルダーの有無を確認 |
| アプリが起動しない | アプリ再起動、msedgewebview2.exe残存プロセス、ユーザーデータフォルダーを確認 |
| 一部端末だけ失敗する | 端末がMDM登録済みか、GPO適用済みか、管理テンプレートが最新かを確認 |
| Runtime更新や配置に失敗する | 空き容量、管理者権限、プロキシ、TLS、EDRやウイルス対策のブロックを確認 |
| 切り戻し後も症状が同じ | WebView2以外の変更、サーバー側更新、認証基盤、ネットワーク制御を再調査 |
アプリが長時間起動し続ける設計の場合、ポリシー反映後にすぐ新しいRuntime選択が行われないことがあります。WebView2 Runtimeの新バージョン利用には、既存のWebView2環境オブジェクトの解放またはアプリ再起動が必要になるため、検証時はアプリを完全終了し、関連プロセスが残っていない状態で再起動して確認するのが安全です。(Microsoft Learn)
セキュリティと運用ガバナンスの注意点
DowngradeVersionは、障害対応を速くする一方で、古いRuntimeを使う期間を意図的に作る設定です。そのため、セキュリティ部門や運用管理者を含めたルールが必要です。
特に、WebView2内で外部Webサイト、ユーザー投稿コンテンツ、メール本文、添付ファイル、OAuthログイン画面などを扱うアプリは、古いRuntimeを長く使うほどリスクが高くなります。業務影響が大きい場合でも、対象アプリと対象端末を最小限に絞り、解除期限を明確にしてください。
社内ルールとしては、次の基準を設けると運用しやすくなります。
| 判断項目 | 推奨する基準 |
|---|---|
| 利用目的 | 業務停止を避けるための一時回避に限定 |
| 承認者 | アプリ所有者、IT管理者、必要に応じてセキュリティ担当 |
| 適用範囲 | 影響部署または検証済み端末グループに限定 |
| 期限 | 次回Runtimeリリースまたはアプリ修正完了まで |
| 証跡 | 変更理由、対象、指定版、解除予定、検証結果を記録 |
| 恒久対応 | アプリ修正、SDK更新、互換性テストの計画を必須化 |
管理者と開発者が今すぐやるべきこと
今回のMicrosoft Edge WebView2のダウングレードポリシー変更は、トラブル発生時の選択肢を増やします。ただし、準備なしに使える魔法のロールバックではありません。効果を出すには、アプリ単位での棚卸し、ポリシー配布基盤、検証手順、解除ルールを事前に整えておく必要があります。
まずは、社内でWebView2を使っている主要アプリを洗い出してください。次に、各アプリについて実行ファイル名、アプリ所有者、業務重要度、外部コンテンツの扱い、過去のWebView2起因トラブルを整理します。そのうえで、MSEdgeWebView2.admxの管理状況を確認し、DowngradeVersionを使う場合の申請テンプレートと検証手順を作成します。
アプリ所有者にとっての実務上の結論は明確です。WebView2更新で重大な不具合が起きた場合、これからは「対象アプリをN-1またはN-2へ一時的に戻す」という選択肢を管理者へ相談できます。ただし、その依頼には、対象exe、再現手順、影響範囲、希望する戻し先、解除見込みをセットで出す必要があります。DowngradeVersionは、障害対応の時間を稼ぐための安全弁として使い、最終的にはアプリ修正と最新Runtimeへの復帰につなげるのが正しい運用です。
コメント