Microsoft Learnの「Microsoft Edge WebView2 Policy Documentation」を確認する際、最も重要なのは、WebView2アプリを一時的に旧ランタイムへ戻せるDowngradeVersionポリシーです。
ただし、2026年6月15日公開のMicrosoft Edge Beta 150.0.4078.13で案内された内容は、バグ修正とパフォーマンス改善です。DowngradeVersionの詳細は、6月11日のEdge 150 Betaリリースノートや、6月4日のEdge 149 Stableリリースノートに記載されています。対象のポリシードキュメント自体には、最終更新日として2026年5月20日と表示されています。(Microsoft Learn)
今回の変更は、一般ユーザーがMicrosoft Learn上で設定を変更するものではありません。主な対象は、WebView2を利用するWindowsアプリを管理している企業のIT管理者やアプリ開発者です。設定方法、影響範囲、更新や移行の考え方、料金、期限まで順に整理します。
2026年6月15日の公式情報をどう理解すべきか
日付ごとの公式情報を整理すると、次のようになります。
| 日付 | 公式情報 | 実務上の意味 |
|---|---|---|
| 2026年6月15日 | Edge Beta 150.0.4078.13でバグとパフォーマンスの問題を修正 | WebView2の新しいポリシー追加を告知した更新ではない |
| 2026年6月11日 | Edge Beta 150.0.4078.5でDowngradeVersionを案内 | Edge 150以降で企業がWebView2アプリの一時的なダウングレードに利用できる |
| 2026年6月4日 | Edge Stable 149.0.4022.52で同機能を案内 | Stable環境でもN-1またはN-2への一時的な切り戻し機能が示された |
| 2026年5月20日 | WebView2 Policy Documentationの最終更新日 | ポリシーの値、対象バージョン、設定例を確認できる |
6月15日だけを見ると、DowngradeVersionがこの日に追加されたように誤解しやすいため注意が必要です。正確には、6月15日時点の最新Beta版を確認しつつ、機能の詳細は6月11日以前のリリースノートとポリシードキュメントで確認するという読み方になります。(Microsoft Learn)
Microsoft Edge WebView2 Policy Documentationの主な変更点
実務上の中心となる変更は、DowngradeVersionポリシーです。
WebView2 Evergreen Runtimeを更新した後、特定の業務アプリで表示崩れ、クラッシュ、認証エラーなどの重大な不具合が発生した場合に、そのアプリだけを以前のメジャーバージョンへ一時的に戻せます。
DowngradeVersionでできること
| 項目 | 内容 |
|---|---|
| 目的 | WebView2 Runtime更新後に発生した重大な回帰不具合の一時回避 |
| 設定単位 | 実行ファイル名またはアプリケーションユーザーモデルID |
| 対象バージョン | 現行バージョンのN-1またはN-2 |
| 指定方法 | 149のようにメジャーバージョンを数字だけで指定 |
| ランタイムの配置 | Edge Updaterが対象バージョンを並行して配置 |
| アプリの振り分け | WebView2 Loaderが指定したアプリを対象ランタイムへ誘導 |
| 対象端末 | ドメイン参加またはMDM登録された企業管理端末 |
| 有効期間 | 新しいWebView2リリースに合わせて自動的に終了 |
| ADMXファイル | MSEdgeWebView2.admx |
たとえば、対象端末の現在のメジャーバージョンが150であれば、N-1は149、N-2は148です。teams.exeだけを149へ戻し、別のアプリは最新のEvergreen Runtimeを使い続ける、といった切り分けができます。(Microsoft Learn)
設定イメージは次のとおりです。
teams.exe = 149
outlook.exe = 148指定できるのはメジャーバージョンの数字だけです。
149 有効な形式
149.0.4022 無効な形式
149.* 無効な形式
v149 無効な形式完全なバージョン文字列、ワイルドカード、数字以外の文字や区切り記号はサポートされません。また、指定したメジャーバージョンに一致するランタイムが見つからなければ、ポリシーは機能せず、BrowserExecutableFolderまたは通常のEvergreen Runtimeが使われます。(Microsoft Learn)
恒久的なバージョン固定機能ではない
DowngradeVersionは、旧バージョンを長期間固定するためのポリシーではありません。
N-1に戻したアプリは、次のメジャーリリース時にも同じバージョンを使い、その時点でN-2になります。その次のリリースで最新のEvergreen Runtimeへ自動更新されます。
N-2に戻したアプリは、次のメジャーリリースで最新のEvergreen Runtimeへ戻ります。(Microsoft Learn)
つまり、管理者には次のリリースまでに原因調査、アプリ修正、ベンダーへの問い合わせを進めることが求められます。
誰に影響するのか
Windows端末のIT管理者
最も影響が大きいのは、Active Directory、グループポリシー、MDMなどでWindows端末を管理している担当者です。
対象はドメイン参加端末またはMDM登録端末に限定されています。管理されていない個人所有PCへ、この企業向けダウングレードポリシーを適用することは想定されていません。(Microsoft Learn)
WebView2アプリの開発者と運用担当者
アプリが新しいWebView2 SDKのAPIを利用している場合、ランタイムを戻すことで必要なAPIが使えなくなる可能性があります。
たとえば、2026年6月11日公開のWebView2 SDK 1.0.4022.49は、完全なAPI互換性を得るためにWebView2 Runtime 149.0.4022.49以降を必要とします。新しいSDKで構築したアプリを148以前へ戻す場合は、画面表示だけでなく、API呼び出しやイベント処理まで検証しなければなりません。(Microsoft Learn)
一般ユーザー
一般ユーザーがポリシーを設定する必要はありません。
ただし、管理者が特定アプリを旧ランタイムへ戻すと、そのアプリだけ挙動や表示が更新前の状態に戻る可能性があります。問い合わせを受けるヘルプデスクは、OSやアプリのバージョンだけでなく、実際に使用されたWebView2 Runtimeも確認できるようにしておくと原因を切り分けやすくなります。
設定前に確認すべきポイント
最新のWebView2用ポリシーファイルを用意する
DowngradeVersionは、WebView2専用のMSEdgeWebView2.admxに含まれるポリシーです。従来の管理用テンプレートを使い続けている環境では、設定項目が表示されない可能性があります。
現行ドキュメントにはADMXファイル名とレジストリのサンプル値が示されています。一方で、同じページのGPパスと必須・推奨レジストリパスは「なし」と記載されています。最新のポリシーファイルを取得したうえで、管理画面に項目が表示されるか、設定値が端末へ配布されるかをテスト端末で確認してから展開するのが安全です。(Microsoft Learn)
対象アプリを正確に特定する
設定値の名前には、実行ファイル名またはアプリケーションユーザーモデルIDを指定します。
製品名やショートカット名ではなく、実際にWebView2を起動しているプロセスを確認してください。ランチャーと本体が別プロセスになっているアプリでは、ランチャー側を指定しても効果がない場合があります。
確認時は、タスクマネージャー、Process Explorer、アプリベンダーの管理資料などを利用し、対象の実行ファイルを特定します。
現在のWebView2 Runtimeを記録する
設定前後の比較ができるように、対象端末にインストールされているWebView2 Runtimeのバージョンを記録します。
Microsoftの配布ドキュメントでは、64ビットWindowsの場合、次のレジストリ配下にあるpv値から、マシン単位またはユーザー単位のランタイムバージョンを確認できます。(Microsoft Learn)
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\
{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
HKEY_CURRENT_USER\Software\Microsoft\EdgeUpdate\Clients\
{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}32ビットWindowsでは、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EdgeUpdate\Clients配下を確認します。
ただし、インストール済みバージョンだけを確認しても、対象アプリが実際にどのランタイムを読み込んだかまでは判断できません。アプリのログやWebView2 APIを利用できる場合は、実行時のバージョンも併せて取得してください。
管理者向けの確認・展開手順
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 1 | 不具合が発生したアプリを特定する | 実行ファイル名、発生条件、影響ユーザーを記録 |
| 2 | 現在のランタイムを確認する | インストール済みバージョンと実行時バージョンを分けて確認 |
| 3 | アプリの対応ランタイムを確認する | SDKの最低要件やベンダーのサポート条件を確認 |
| 4 | 最新のADMXをテスト環境へ配置する | DowngradeVersionが管理画面または配布設定で利用できるか確認 |
| 5 | 少数端末へアプリ単位で設定する | N-1から試し、必要な場合のみN-2を検討 |
| 6 | アプリを完全終了して再度検証する | 起動、認証、印刷、ファイル操作、画面遷移を確認 |
| 7 | 監視期間と解除条件を決める | 次回メジャー更新前に修正版へ移行できるか確認 |
| 8 | 問題解消後に設定を撤回する | 不要な旧ランタイム利用を残さない |
最初から全端末へ展開するのではなく、再現端末、IT部門、限定ユーザーの順に対象を広げると、ランタイム変更による別の不具合を抑えられます。
Edgeブラウザーのポリシーとの違い
Microsoft Edgeブラウザー向けのポリシーは、原則としてWebView2アプリには適用されません。ブラウザーと組み込みアプリでは利用目的が異なり、ブラウザー向け設定をそのまま適用すると、WebView2アプリのJavaScriptなどを意図せず停止させる恐れがあるためです。(Microsoft Learn)
管理時は、次の役割を分けて考えます。
| ポリシーの種類 | 主な役割 |
|---|---|
| Microsoft Edgeブラウザーポリシー | Edge本体の機能、サイトアクセス、ユーザー設定などを制御 |
| Edge Updateポリシー | EdgeとWebView2 Runtimeのインストールや更新を管理 |
| WebView2固有ポリシー | WebView2アプリのランタイム選択や動作を制御 |
| アプリ独自ポリシー | 対象アプリ固有の機能やWebView2利用方法を制御 |
「Edgeの自動更新を止めればWebView2も管理できる」と単純に考えるのは危険です。Microsoftは、古いWebView2 Runtimeを継続利用すると最新の品質更新やセキュリティ更新を受け取れないため、Evergreen Runtimeの継続利用を推奨しています。DowngradeVersionは、更新停止の代替ではなく、重大障害から復旧するまでの一時措置として使うべきです。(Microsoft Learn)
更新・移行・料金・期限で確認すべきこと
更新
通常運用では、引き続き自動更新されるEvergreen Runtimeを利用します。DowngradeVersionを適用したアプリだけが一時的に旧バージョンへ誘導され、ほかのアプリは通常のランタイムを利用できます。(Microsoft Learn)
旧バージョン利用中も、次の項目を継続的に確認してください。
- アプリベンダーから修正版が提供されたか
- 最新Runtimeで不具合が解消されたか
- 次のメジャーバージョンが公開されたか
- ダウングレード対象の端末やアプリが増えていないか
移行
今回の変更に伴い、ユーザーデータやMicrosoft 365テナントを移行する必要はありません。また、Evergreen RuntimeからFixed Version Runtimeへ切り替えることを求める変更でもありません。
ただし、アプリが新しいWebView2 APIに依存している場合は、旧Runtimeで正常に動作するかを確認する必要があります。ダウングレードは「更新前の状態に戻せば必ず動く」という保証ではありません。
料金
今回確認できるMicrosoft Learnのポリシードキュメントとリリースノートには、DowngradeVersionに伴う料金改定や追加ライセンス購入の案内はありません。したがって、今回の情報は料金変更の告知ではなく、企業管理端末向けのポリシー機能に関する更新として扱います。(Microsoft Learn)
ただし、端末管理に利用するMDM製品や管理サービスの契約条件は別です。現在使用している管理方式でカスタムポリシーやADMX取り込みが可能かは、各サービスの契約内容を確認してください。
期限
特定の日付までに設定や移行を完了しなければならない、という期限は示されていません。
一方、ダウングレードにはメジャーリリース単位の実質的な期限があります。
- N-2を指定した場合は、次のメジャーリリースで最新Evergreenへ戻る
- N-1を指定した場合は、次のリリースでN-2となり、その次のリリースで自動更新される
ポリシーが自動的に失効する前に、修正版アプリの配布やベンダー対応を完了させる計画が必要です。(Microsoft Learn)
失敗しやすい設定と注意点
完全なバージョン番号を入力する
149.0.4022.52のような完全なバージョン番号は無効です。149のようにメジャーバージョンだけを指定します。(Microsoft Learn)
Edgeブラウザー用ADMXだけを更新する
WebView2固有の設定にはMSEdgeWebView2.admxが必要です。既存のEdgeブラウザー用テンプレートだけでは、目的の設定が見つからない可能性があります。
対象ランタイムが利用できると思い込む
ポリシードキュメントでは、指定したメジャーバージョンに一致するランタイムフォルダーが見つからない場合、ポリシーは機能しないと説明されています。一方、リリースノートではEdge Updaterが対象バージョンを並行インストールするとされています。(Microsoft Learn)
プロキシ、ファイアウォール、更新停止ポリシー、オフライン環境などの影響で取得できないケースを想定し、設定後に対象ランタイムが実際に配置されたかを確認してください。
アプリのSDK要件を確認しない
旧Runtimeで不具合が解消しても、新しいAPIを利用している画面や処理だけが失敗する可能性があります。起動確認だけで合格とせず、認証、ファイル操作、印刷、ダウンロード、ポップアップ、外部リンクなど、主要機能を一通りテストします。
解除計画を作らない
DowngradeVersionは緊急回避策です。設定時点で、担当者、監視期間、解除条件、次回確認日を決めてください。
「不具合が再発しない限り放置する」という運用では、次回リリース時の自動失効によって問題が突然再発する恐れがあります。
まず実施すべき対応
2026年6月15日時点で確認すべきポイントは、次の3つです。
- WebView2更新後に不具合が発生している業務アプリがないか確認する
- 最新の
MSEdgeWebView2.admxとDowngradeVersionの利用可否をテスト端末で確認する - ダウングレードを使う場合は、N-1から小規模に検証し、解除期限と修正版への移行計画を決める
6月15日のEdge Beta更新自体はバグとパフォーマンスの修正です。管理者が実務上注目すべきなのは、特定のWebView2アプリだけを一時的にN-1またはN-2へ戻せるDowngradeVersionと、その自動失効の仕組みです。
恒久的に更新を止めるのではなく、障害を切り分けるための短期的な復旧手段として利用してください。
コメント