WebView2更新後に業務アプリが動かないときの戻し方｜DowngradeVersionで限定復旧

WebView2の更新後に業務アプリが動かなくなった場合、企業・組織で管理しているWindows端末で、アプリがEvergreen版のWebView2 Runtimeを利用していれば、管理ポリシーのDowngradeVersionを使って、対象アプリだけを以前のRuntimeへ一時的に戻せます。

これはWebView2 Runtime全体をアンインストールする方法ではありません。対象アプリの実行ファイル名またはAUMIDと、戻したいRuntimeの4要素すべてを含む完全なバージョン番号を指定します。ほかのWebView2アプリは、原則として最新のRuntimeを使い続けます。([Microsoft Learn][1])

ただし、Microsoftの公式資料では、戻せる世代数や対応開始バージョンの記述に差があります。本番環境へ展開する前に、使用中のADMX、対象端末のRuntime、テスト端末での適用結果を照合することが重要です。

WebView2を以前のRuntimeへ戻せる条件

DowngradeVersionは、一般利用者が自由に使うロールバック機能ではなく、業務停止につながる不具合を一時回避するための企業向け機能です。

確認項目	適用条件
端末	企業・組織で管理されているWindows端末
Runtimeの配布方式	Evergreen WebView2 Runtime
対象アプリ	実行ファイル名またはAUMIDで個別に指定できるアプリ
ポリシーの適用範囲	コンピューター単位のポリシー
レジストリの適用先	HKEY_LOCAL_MACHINE
バージョン指定	151.0.2178.0のような4要素の完全な番号
必要な権限	GPOを管理できる権限、またはローカル管理者権限
適用後の操作	対象アプリの完全終了と再起動

次の環境では、DowngradeVersionを設定しても対象になりません。

• 個人利用など、組織で管理されていない端末
• アプリに同梱されたFixed Version Runtimeを使うアプリ
• HKEY_CURRENT_USERに設定したユーザー単位のポリシー
• ポリシーに個別登録していないアプリ
• 戻したいRuntimeの完全なバージョン番号が不明な場合

DowngradeVersionは端末全体のWebView2を戻すのではなく、指定したアプリにだけ適用されます。また、AUMIDと実行ファイル名の両方が登録されている場合は、AUMID側が優先されます。([Microsoft Learn][2])

ダウングレード前に更新が原因か切り分ける

WebView2更新後にアプリが動かなくなっても、原因が必ずWebView2 Runtimeとは限りません。次の順序で切り分けてから、ダウングレードを判断します。

発生時刻と更新時刻を照合する

以下を記録します。

• 最後に正常動作した日時
• 不具合が発生した日時
• WebView2 Runtimeの現在のバージョン
• 業務アプリのバージョン
• Windows Updateやアプリ更新の実施日時
• 発生している端末数
• エラーメッセージやイベントログ

WebView2の更新直後に複数端末で同じ症状が始まり、同じアプリだけが影響を受けているなら、Runtimeとの互換性問題を疑いやすくなります。

未更新端末やテスト端末と比較する

同じ業務アプリを使う未更新端末が残っている場合は、次の情報を比較します。

• 正常端末のWebView2 Runtimeバージョン
• 異常端末のWebView2 Runtimeバージョン
• 業務アプリの設定とバージョン
• セキュリティソフトやプロキシの状態

正常端末で使われているRuntimeの完全なバージョン番号は、戻し先を決める有力な情報になります。

アプリ側の修正版を先に確認する

業務アプリのベンダーが修正版や回避策を公開している場合は、原則としてアプリ側の更新を優先します。

DowngradeVersionは恒久対策ではありません。業務を再開するための緊急措置として利用し、その間に業務アプリの修正や最新Runtimeへの対応を進めます。

公式資料でN-1〜N-4とN-1〜N-2が食い違っている

2026年9月19日時点のMicrosoft公式資料では、DowngradeVersionの適用条件に次の差があります。

項目	WebView2ポリシーリファレンス	Runtimeダウングレード手順
対応開始	WebView2 149以降	WebView2 150以降
戻せる範囲	現在のメジャーバージョンをNとしてN-1〜N-4	N-1またはN-2
バージョン形式	4要素の完全なバージョン番号	設定手順では4要素の完全な番号
対象指定	AUMIDまたは実行ファイル名	AUMIDまたは実行ファイル名

ポリシーリファレンスでは、N-1からN-4までが対象と明記されています。一方、個別のダウングレード手順では、N-1またはN-2という説明が複数箇所に残っています。さらに同じ手順ページ内でも、設定手順では4要素の完全な番号を求めている一方、制限事項の表には異なる記載があり、文書内で整合していません。([Microsoft Learn][1])

そのため、本番運用では次の基準で判断するのが安全です。

• バージョン形式は、必ず4要素の完全な番号にする
• N-1またはN-2は、両資料の条件が重なる範囲として扱う
• N-3またはN-4を利用する場合は、最新のMSEdgeWebView2.admxと対象Runtimeを照合する
• N-3またはN-4は、隔離したテスト端末で実際に適用されたことを確認してから展開する
• WebView2 149で利用する場合も、使用中のADMXと実機で対応状況を確認する
• 文書の記述だけを根拠に、全端末へ一斉展開しない

少なくとも、151のようなメジャーバージョンだけの指定や、途中までしか一致しない指定は使えません。Microsoftのポリシーリファレンスでは、指定した完全なバージョン番号と一致するRuntimeフォルダーが見つからない場合、ポリシーは目的どおりに機能せず、通常のEvergreen Runtimeなどへ戻ると説明されています。([Microsoft Learn][1])

設定前に準備する情報

GPOを変更する前に、次の3点を確定します。

対象アプリの実行ファイル名またはAUMID

通常のデスクトップアプリでは、タスクマネージャーの「詳細」タブから実行ファイル名を確認できます。

たとえば、Microsoftの資料では次のような名前が例示されています。

• ms-teams.exe
• olk.exe

拡張子を含め、実際にWebView2を起動しているアプリのプロセス名を指定します。ショートカット名、製品の表示名、実行ファイルのフルパスではありません。

MSIXなどのパッケージアプリでは、実行ファイル名ではなくAUMIDを使う場合があります。AUMIDが必要なアプリでは、アプリベンダーの資料や端末上のパッケージ情報を確認してください。

戻したいRuntimeの完全なバージョン番号

バージョン番号は、次の形式です。

メジャー.マイナー.ビルド.パッチ

Microsoftの資料にある書式例は次のとおりです。

151.0.2178.0

この番号は設定例であり、そのまま指定するものではありません。次のいずれかから、実際に正常動作していた完全な番号を確認します。

• 正常に動作している未更新端末
• 障害発生前の端末管理記録
• WebView2のバージョンフォルダー
• 業務アプリの診断ログ
• Microsoftのリリース情報
• アプリベンダーから指定された対応バージョン

「おそらく前の版」という推測で設定しないことが重要です。

最新のWebView2用ADMX

DowngradeVersionは、WebView2の管理テンプレートに含まれるポリシーです。

使用するファイルは次のとおりです。

MSEdgeWebView2.admx

古いADMXでは、グループポリシーエディターにDowngradeVersionが表示されません。Microsoft Edge for Businessから最新のポリシーテンプレートを取得し、組織の運用に従ってローカルのPolicyDefinitionsまたはドメインのセントラルストアを更新します。

既存のADMXを更新する場合は、ほかのMicrosoft Edgeポリシーへの影響も考慮し、まず検証環境で読み込みを確認してください。

GPOでDowngradeVersionを設定する手順

最新のADMXが読み込まれているか確認する

グループポリシー管理エディターまたはローカルグループポリシーエディターを開き、次の場所を確認します。

コンピューターの構成
  > 管理用テンプレート
  > Microsoft Edge WebView2
  > Loader Override Settings

この中に、次のポリシーが表示されている必要があります。

Configure per-application WebView2 downgrade version

日本語のADMLを使用している環境では、表示名が日本語化されることがあります。技術上のポリシー名はDowngradeVersionです。ポリシーが見つからない場合は、設定を続けずADMXの更新状況を確認します。([Microsoft Learn][1])

ポリシーを有効にする

対象のGPOを編集し、Configure per-application WebView2 downgrade versionを開きます。

1. ポリシーを「有効」にします。
2. 一覧を入力する画面を開きます。
3. 名前に対象アプリの実行ファイル名またはAUMIDを入力します。
4. 値に戻したいRuntimeの完全なバージョン番号を入力します。
5. 設定を保存します。

設定例は次のようになります。

名前: ms-teams.exe
値:   151.0.2178.0

この例は書式を示すものです。実際には、対象の業務アプリ名と、正常動作を確認済みのバージョン番号へ置き換えます。

レジストリ上では、次の場所にアプリごとの文字列値として反映されます。

HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\DowngradeVersion

値の種類はREG_SZです。GPOで管理する場合は、レジストリエディターから直接作成せず、GPOの設定画面から登録します。([Microsoft Learn][1])

最初は少数のテスト端末へ適用する

いきなり全端末へ適用せず、次のように段階展開します。

1. 隔離した検証端末
2. 情報システム部門のテスト端末
3. 少人数のパイロットグループ
4. 対象部署
5. 必要な端末全体

ドメインGPOでは、テスト用OUやセキュリティフィルターを使い、適用対象を限定します。

同じアプリでも、端末によって業務データ、プラグイン、セキュリティソフト、認証方式が異なることがあります。1台で起動しただけではなく、実際の業務操作まで確認してください。

GPOを反映して対象アプリを再起動する

必要に応じて、管理者権限のコマンドプロンプトからポリシーを更新します。

gpupdate /force

その後、対象アプリを完全に終了します。通知領域やバックグラウンドにプロセスが残るアプリでは、タスクマネージャーの「詳細」タブも確認します。

PC全体の再起動は通常必要ありませんが、対象のWebView2アプリは再起動が必要です。また、Edge Updaterが対象Runtimeを取得するまで、反映に時間がかかることがあります。Microsoftの手順では、反映まで最大1時間程度かかる場合があると説明されています。([Microsoft Learn][2])

対象Runtimeの取得が完了していない間は、アプリが直ちに起動不能になるのではなく、最新のEvergreen Runtimeを使い続ける場合があります。設定直後に変化がなくても、すぐに設定ミスと判断しないでください。([Microsoft Learn][2])

以前のRuntimeが使われているか確認する

ポリシーを設定しただけでは、復旧確認は完了していません。次の4点を確認します。

レジストリに対象アプリとバージョンがあるか

管理者権限のコマンドプロンプトで、次のコマンドを実行します。

reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\DowngradeVersion"

対象アプリ名と、設定した完全なバージョン番号が表示されることを確認します。

値がない場合は、次を確認してください。

• GPOのリンク先
• セキュリティフィルター
• WMIフィルター
• コンピューターアカウントへの適用権限
• ADMXの更新状況
• GPOのレプリケーション状況

対象バージョンのフォルダーが作成されたか

Microsoftの手順では、次の場所でWebView2 Runtimeのバージョンフォルダーを確認します。

C:\Program Files (x86)\Microsoft\EdgeWebView\Application\

設定した完全なバージョン番号と同じ名前のフォルダーが存在するか確認します。

フォルダーがない場合は、次の可能性があります。

• Edge Updaterがまだ実行されていない
• ネットワークやプロキシでダウンロードできない
• 指定したバージョンがサポート範囲外
• バージョン番号が存在しない
• 4要素の番号が誤っている
• ディスク容量が不足している

対象フォルダーの存在は、Runtimeが端末へ配置されたことを示します。ただし、フォルダーがあるだけで業務アプリがその版を使っているとは限らないため、次の確認も行います。([Microsoft Learn][2])

実際に使用中のRuntimeを確認する

Microsoft Edgeで次の内部ページを開くと、実行中のWebView2プロセスや使用中のRuntimeを確認できます。

edge://webview2-internals

対象アプリを起動した状態で確認し、対象プロセスが指定したRuntimeを利用しているか照合します。

内部ページは診断用です。画面を記録するときは、ユーザー名、ファイルパス、URL、トークン、組織名などが含まれていないか確認してください。

業務機能をテストする

起動できるだけでは、復旧したとは判断できません。最低限、次の操作を確認します。

• ログイン
• 画面表示
• データ検索
• 登録・更新
• ファイルの読み込みと保存
• 印刷やPDF出力
• 外部システムとの連携
• アプリ終了後の再起動
• 複数ユーザーでの利用

可能であれば、「更新後のRuntime」「戻したRuntime」「修正版アプリ」の3パターンで同じ操作を比較します。

DowngradeVersionが反映されないときの確認項目

症状	主な原因	確認すること
GPOにポリシーが表示されない	ADMXが古い	MSEdgeWebView2.admxを更新する
レジストリに値がない	GPOが対象端末へ適用されていない	OU、フィルター、権限、gpresultを確認する
アプリが最新Runtimeのまま	アプリが完全終了していない	バックグラウンドプロセスも終了する
バージョンフォルダーが作成されない	対象版を取得できない	バージョン、ネットワーク、更新タスクを確認する
特定アプリだけ対象にならない	実行ファイル名やAUMIDが違う	実際のWebView2ホストプロセスを調べる
ポリシーを設定しても変化しない	Fixed Version Runtimeを利用している	アプリの配布方式をベンダーへ確認する
アプリが起動直後に終了する	共有User Data Folderの版不一致	同じUDFを使うアプリのRuntimeを揃える
戻した版でも動かない	原因がWebView2更新ではない	アプリ、認証、プロキシ、セキュリティ製品を再調査する

特に注意が必要なのが、User Data Folderの共有です。同じUDFを複数アプリで共有している場合、一部のアプリだけを異なるRuntimeへ戻すと、起動障害やデータ互換性の問題が起こる可能性があります。共有UDFを使用するアプリでは、関係するアプリを同じRuntimeへ揃える必要があります。([Microsoft Learn][2])

Runtimeを戻す場合のリスク

セキュリティ修正も以前の状態へ戻る

古いRuntimeへ戻すと、新しいRuntimeで修正された脆弱性が再び影響する可能性があります。

そのため、適用範囲は次のように絞ります。

• 問題が発生しているアプリだけ
• 必要な端末だけ
• 必要な利用者だけ
• 復旧までの短い期間だけ

長期的なバージョン固定には使わず、業務アプリの修正版が提供されたら最新Runtimeへ戻します。

ユーザーデータに互換性問題が起こる可能性がある

WebView2アプリは、Cookie、IndexedDB、Local Storageなどへデータを保存することがあります。新しいRuntimeで更新されたデータを古いRuntimeが読み込むと、保存形式やスキーマの差によって問題が起こる可能性があります。

重要な業務データは、アプリベンダーが定める方法でバックアップしてください。WebView2のUser Data Folderを、アプリの稼働中に手作業でコピーする方法は避けます。

新しいWebView2 APIを使うアプリは動かないことがある

業務アプリ側が新しいWebView2 Runtimeで追加されたAPIや動作に依存している場合、以前のRuntimeへ戻すことで別の障害が発生する可能性があります。

起動確認だけでなく、登録、保存、認証、印刷、終了処理など、実際の業務フローで検証する必要があります。Microsoftも、セキュリティ、データ整合性、API互換性などをダウングレードのリスクとして挙げています。([Microsoft Learn][2])

復旧後はGPOから設定を解除する

業務アプリの修正版が適用され、最新WebView2 Runtimeで正常動作することを確認したら、DowngradeVersionを解除します。

GPOで設定した場合は、次の手順で戻します。

1. 設定に使用したGPOを開きます。
2. Configure per-application WebView2 downgrade versionを開きます。
3. 「未構成」または組織の運用に応じて「無効」に戻します。
4. GPOを対象端末へ反映します。
5. 対象アプリを完全終了します。
6. アプリを再起動します。
7. 最新のEvergreen Runtimeへ戻ったことを確認します。
8. 主要な業務操作を再テストします。

GPOで作成されたレジストリ値を、レジストリエディターから直接削除しないでください。 GPO側に設定が残っていれば再適用されるほか、管理状態が分かりにくくなります。GPOで設定したものは、同じGPOで解除します。([Microsoft Learn][2])

WebView2更新後の障害に対応する流れ

WebView2更新後に業務アプリが動かなくなった場合は、次の順序で対応します。

1. WebView2更新との因果関係を切り分ける
2. 正常動作していた完全なバージョン番号を確認する
3. 最新のMSEdgeWebView2.admxを用意する
4. DowngradeVersionで対象アプリを個別指定する
5. 最初はテスト端末だけに適用する
6. 対象アプリを完全終了して再起動する
7. 使用中のRuntimeと業務機能を確認する
8. アプリの修正版が出たら最新Runtimeへ戻す
9. GPOで設定したポリシーはGPOで解除する

DowngradeVersionは、WebView2 Runtime全体を無理に削除するよりも影響範囲を限定しやすい方法です。一方で、公式資料には対応世代の記述差があるため、N-3やN-4を利用するときは、最新ADMXの確認と実機テストを省略できません。

確実に押さえるべきポイントは、対象アプリを個別に指定すること、4要素の完全なバージョン番号を使うこと、本番展開前に実際のRuntime切り替えと業務動作を確認することです。
[1]: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-webview-policies “https://learn.microsoft.com/en-us/deployedge/microsoft-edge-webview-policies“
[2]: https://learn.microsoft.com/en-us/deployedge/webview2-downgrade-runtime “https://learn.microsoft.com/en-us/deployedge/webview2-downgrade-runtime“