WebView2 SDK 1.0.4129.50の要件｜必要なRuntimeと更新時の確認点

WebView2 SDK 1.0.4129.50を採用する場合、実行端末にはWebView2 Runtime 151.0.4129.50以降を用意する必要があります。これは、SDKに含まれるAPIを完全な互換性で利用するための要件です。古いRuntimeでもWebView2自体が起動したり、既存APIが動作したりする場合はありますが、本番環境のサポート条件にはできません。さらにRuntime 151では、legacy WebView2クライアントにおけるsingleton host-pipe accessが制限されています。SDKとRuntimeのバージョンをそろえるだけでなく、ホスト連携やメッセージ送受信を重点的に再テストすることが重要です。(Microsoft Learn)

WebView2 SDK 1.0.4129.50に必要なRuntimeバージョン

WebView2 SDK 1.0.4129.50は、2026年8月3日に公開されたRelease版SDKです。Microsoftは、完全なAPI互換性を確保するために、WebView2 Runtime 151.0.4129.50以降が必要だと明記しています。(Microsoft Learn)

確認項目	内容
SDK	Microsoft.Web.WebView2 1.0.4129.50
SDKの種類	Release版
公開日	2026年8月3日
対応するRuntime	WebView2 Runtime 151.0.4129.50
本番環境の最低条件	Runtime 151.0.4129.50以降
推奨するRuntime方式	Evergreen WebView2 Runtime
主な追加確認	legacy singleton host-pipe access変更の再テスト

運用上は、「Runtime 151が入っていればよい」ではなく、4つの数値を含む完全なバージョンが151.0.4129.50以上であることを確認してください。

たとえば、次のバージョンは同じ151世代でも要件を満たしません。

151.0.4129.49

一方、次のような後続バージョンは、151.0.4129.50以降という条件を満たします。

151.0.4129.50
152.x.x.x
153.x.x.x

WebView2のRelease SDKは、同じかそれより新しいRuntimeとの組み合わせで利用することが基本です。SDKよりRuntimeのビルド番号が古い場合、SDKから参照できる新しいAPIの実装がRuntime側に存在しない可能性があります。(Microsoft Learn)

「完全なAPI互換性」と「起動できる最低バージョン」は異なる

WebView2 SDK 1.0.4129.50の要件を理解する際は、「WebView2を起動できる最低バージョン」と「SDKのAPIを完全に利用できる最低バージョン」を分けて考える必要があります。

Microsoftの一般的な説明では、WebView2インスタンスを作成するための歴史的な最低Runtimeは86.0.616.0です。しかし、これはWebView2 SDK 1.0.4129.50の機能を完全に利用できるという意味ではありません。(Microsoft Learn)

組み合わせごとの考え方は次のとおりです。

SDKとRuntimeの組み合わせ	判定	実務上の扱い
SDK 1.0.4129.50＋Runtime 151.0.4129.50	対応	完全互換性を満たす最低構成
SDK 1.0.4129.50＋151.0.4129.50より新しいRuntime	対応	通常はこちらを推奨
SDK 1.0.4129.50＋151.0.4129.50未満のRuntime	非推奨	新しいAPI実装が不足する可能性がある
古いRelease SDK＋Runtime 151.0.4129.50以降	原則利用可能	新しいSDK APIは利用できない
Prerelease SDK＋Evergreen Runtime	用途が異なる	Experimental APIの検証にはEdgeプレビューチャネルを使う

Runtimeが古いからといって、必ずアプリが起動しなくなるわけではありません。使用しているAPIが古いRuntimeにも存在すれば、一見正常に動くことがあります。

ただし、この状態には次の問題があります。

開発端末では動くが、管理対象端末では特定機能だけ失敗する
新しいプロパティやイベントを呼び出したときだけ例外になる
一部画面だけ初期化に失敗する
SDK更新後の不具合なのか、Runtime不足なのか判断しにくくなる
Microsoftが示す完全互換の組み合わせから外れる

そのため、本番環境では「今の機能がたまたま動くか」ではなく、Microsoftが指定したRuntime 151.0.4129.50以降を最低要件として管理するのが安全です。

SDKとRuntimeの違いを理解する

WebView2 SDKとWebView2 Runtimeは、役割も配布方法も異なります。

項目	WebView2 SDK	WebView2 Runtime
主な役割	アプリの開発、ビルド、API参照	利用者の端末でWebコンテンツを実行
主な配置先	開発環境、アプリの成果物	利用者のWindows端末
更新方法	NuGetパッケージの更新	Evergreen更新、インストーラー、Fixed Version配布
バージョン確認場所	プロジェクトファイル、NuGet	Runtime API、レジストリ、実行ログ
古い場合の影響	新しいAPIをコードから利用できない	SDKにあるAPIの実装が存在しない可能性がある

SDKを1.0.4129.50に更新しても、利用者の端末にあるRuntimeが自動的に同じバージョンになるとは限りません。

特に注意が必要なのは、次のような環境です。

WebView2 Runtimeの自動更新を管理ポリシーで延期している
インターネットに接続できない閉域環境
VDIや共有端末でマスターイメージを固定している
Fixed Version Runtimeをアプリに同梱している
アプリを長期間再起動せず連続稼働させている
per-userとper-machineのRuntimeが混在している

開発者が最新のEvergreen Runtimeを使っていても、利用者の端末が同じ状態とは限りません。SDK更新時は、アプリ側と端末側を別々に確認してください。

Microsoft Edgeのバージョンだけを確認してはいけない

Microsoft EdgeブラウザーとWebView2 Runtimeは、同じChromium系の技術を利用していますが、確認すべき製品は別です。

Microsoft Edgeの設定画面に表示されるブラウザーのバージョンが151以上でも、それだけではWebView2 Runtime 151.0.4129.50以降が利用されている証明にはなりません。

Release版WebView2 SDKを使うアプリは、通常、Microsoft Edge StableではなくEvergreen WebView2 Runtimeを対象にします。MicrosoftもRelease SDKにはEvergreen Runtimeを使用するよう案内しています。(Microsoft Learn)

したがって、次の確認方法は不十分です。

Microsoft Edgeが151だから問題ない

確認すべき内容は、実際にWebView2アプリが検出または読み込んだRuntimeのバージョンです。

WebView2 Runtimeのバージョンをアプリから確認する方法

.NET版WebView2では、CoreWebView2Environment.GetAvailableBrowserVersionStringを使って、利用可能なRuntimeのバージョンを取得できます。

さらに、文字列を単純比較するのではなく、CoreWebView2Environment.CompareBrowserVersionsを使って比較します。

using Microsoft.Web.WebView2.Core;

public static class WebView2RuntimeChecker
{
    private const string RequiredRuntimeVersion = "151.0.4129.50";

    public static string CheckRuntime()
    {
        try
        {
            string detectedVersion =
                CoreWebView2Environment.GetAvailableBrowserVersionString();

            int comparison =
                CoreWebView2Environment.CompareBrowserVersions(
                    detectedVersion,
                    RequiredRuntimeVersion);

            if (comparison < 0)
            {
                return $"WebView2 Runtimeの更新が必要です。" +
                       $" 検出: {detectedVersion}" +
                       $" 必要: {RequiredRuntimeVersion}以降";
            }

            return $"WebView2 Runtimeは要件を満たしています。" +
                   $" 検出: {detectedVersion}";
        }
        catch (WebView2RuntimeNotFoundException)
        {
            return "WebView2 Runtimeがインストールされていません。";
        }
    }
}

GetAvailableBrowserVersionStringは、WebView2 Runtimeが見つからない場合にWebView2RuntimeNotFoundExceptionを発生させます。CompareBrowserVersionsを利用すれば、4つの数値を含むWebView2のバージョン文字列を適切に比較できます。(Microsoft Learn)

次のような文字列比較は使用しないでください。

// バージョン判定としては不適切
if (detectedVersion.CompareTo("151.0.4129.50") >= 0)
{
    // ...
}

通常の文字列比較では、数値の桁数によって誤判定する可能性があります。

実際に読み込まれたRuntimeも記録する

Fixed Version Runtime、Edgeプレビューチャネル、環境変数、レジストリポリシーなどによる上書きがあると、事前確認したRuntimeと実際に選択されるRuntimeが異なる可能性があります。

WebView2の初期化後に、実際のRuntimeバージョンもログへ記録しておくと、障害調査が容易になります。

await webView.EnsureCoreWebView2Async();

string actualRuntimeVersion =
    webView.CoreWebView2.Environment.BrowserVersionString;

少なくとも次の情報を、診断ログに残しておくと有効です。

SDKバージョン
検出したRuntimeバージョン
実際に読み込まれたRuntimeバージョン
EvergreenまたはFixed Versionの区分
browserExecutableFolderの指定有無
ユーザーデータフォルダー
アプリの実行権限
WebView2初期化時の例外内容

GetAvailableBrowserVersionStringは、指定されたRuntimeフォルダーやチャネル設定、各種上書きの影響を受けます。Fixed Versionを使う場合は、実際の環境作成時と同じフォルダーやオプションを用いて確認してください。(Microsoft Learn)

インストーラーや管理ツールでRuntimeを確認する方法

WebView2 Runtimeの有無は、APIだけでなくレジストリのpv値でも確認できます。

64ビットWindowsの主な確認先は次のとおりです。

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では、per-machineの確認先が次の場所になります。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EdgeUpdate\Clients\
{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}

キー内のpvが空欄、存在しない、または0.0.0.0の場合は、Runtimeが利用できない状態として扱います。Microsoftは、Runtimeの検出方法としてレジストリ確認またはWebView2のバージョン取得APIを案内しています。(Microsoft Learn)

ただし、レジストリの値だけでは、アプリがFixed Versionを明示的に読み込んでいるケースやチャネル上書きを正確に把握できません。

用途に応じて、次のように使い分けます。

確認方法	適した用途
WebView2 API	アプリが利用できるRuntimeの事前確認
初期化後のBrowserVersionString	実際に読み込まれたRuntimeの確認
レジストリの`pv`	インストーラー、端末棚卸し、管理スクリプト
タスクマネージャーから実行ファイルの場所を確認	障害調査時の手動確認

EvergreenとFixed Versionのどちらを使うべきか

WebView2 SDK 1.0.4129.50はRelease版なので、通常はEvergreen WebView2 Runtimeを使用します。

方式	特徴	向いている環境	注意点
Evergreen Runtime	自動更新され、複数アプリで共有される	一般的な業務端末、インターネット接続環境	更新を止めるとSDKとのバージョン差が発生する
Fixed Version Runtime	指定したRuntimeをアプリと一緒に配布する	閉域環境、厳格なバージョン固定が必要な環境	Runtimeの更新とセキュリティ管理を開発側で行う
Edgeプレビューチャネル	Experimental APIや将来変更を検証する	開発・先行検証環境	通常の本番環境には使用しない

Evergreen Runtimeは自動更新され、同じ端末上のWebView2アプリが共有して利用します。Release SDKを利用する一般的なアプリでは、Evergreen方式が推奨されています。(Microsoft Learn)

一方、Fixed Versionを使っている場合は、アプリに含めているRuntimeフォルダーを151.0.4129.50以降へ更新しなければなりません。端末に最新のEvergreen Runtimeが入っていても、アプリがbrowserExecutableFolderで古いFixed Versionを指定していれば、その古いRuntimeが利用されます。

Runtimeはアプリ更新より先に配布する

SDK 1.0.4129.50でビルドしたアプリを先に配布すると、Runtime更新が遅れている端末だけで問題が発生する可能性があります。

安全な展開順序は次のとおりです。

対象端末のRuntimeバージョンを棚卸しする
Runtime 151.0.4129.50以降を先行配布する
先行端末でRuntime更新後の既存アプリを確認する
SDKを1.0.4129.50へ更新して再ビルドする
検証用グループへ新しいアプリを配布する
エラー率やWebView2初期化ログを確認する
問題がなければ全体へ展開する

オンライン端末では、Evergreen Runtime Bootstrapperを利用できます。

MicrosoftEdgeWebview2Setup.exe /silent /install

オフライン端末では、Evergreen Standalone Installerをアプリのインストーラーや管理システムから配布します。Microsoftはオンライン環境ではBootstrapper、オフライン環境ではStandalone Installerを使う展開方法を案内しています。(Microsoft Learn)

SDKのNuGetパッケージを更新した後は、既存バイナリをそのまま使わず、アプリを再ビルドしてください。WebView2のリリースノートでも、SDK更新後の再コンパイルが推奨されています。(Microsoft Learn)

legacy singleton host-pipe access変更とは

WebView2 Runtime 151.0.4129.50のリリースノートには、legacy WebView2クライアントにおけるsingleton host pipeへのアクセスを制限したことが記載されています。非推奨のWebView2に対する同様のアクセス制限も、修正項目に含まれています。(Microsoft Learn)

同じRuntimeでは、次のようなホスト通信やオリジン検証に関係する修正も行われています。

ホストパイプにブラウザー側で確定したオリジン情報を付与
WebMessageReceivedEventArgs.Sourceの偽装防止
ネイティブオブジェクトへアクセスするメソッドからoriginパラメーターを削除
仮想ホストのkDeny適用を強化
renderer spoofingやNTFSジャンクションを利用した回避への対策
AddScriptToExecuteOnDocumentCreatedのリグレッション修正

これらの記載から、Runtime 151ではホストアプリとWebコンテンツ間の通信、オリジン判定、ネイティブオブジェクト連携に関するセキュリティ強化が行われたと考えられます。(Microsoft Learn)

ただし、公開リリースノートでは「legacy WebView2クライアント」が具体的にどのSDKやラッパーを指すのか、明確な境界は示されていません。特定のSDKバージョンだけを見て影響なしと判断せず、古くから運用しているWebView2アプリや独自のホスト連携を持つアプリは実機で再確認する必要があります。

host-pipe変更で再テストすべき項目

host-pipeは公開API名ではなく、WebView2内部の通信経路に近い表現です。そのため、単体のAPIだけを確認するのではなく、ホストとWebコンテンツの境界を横断する機能をまとめてテストします。

テスト対象	具体的な確認内容	注目する症状
Webメッセージ送信	`window.chrome.webview.postMessage`からホストへ送信する	メッセージが届かない、重複する、順序が変わる
Webメッセージ受信	`WebMessageReceived`でデータと送信元を確認する	`Source`の値が想定と異なる、許可判定で拒否される
ホストオブジェクト	`AddHostObjectToScript`で公開したメソッドやプロパティを呼ぶ	オブジェクト取得失敗、呼び出し例外、戻り値の欠落
オリジン切り替え	別ドメインへの遷移、リダイレクト、ログイン画面を確認する	遷移後だけホスト連携が失敗する
iframe	同一オリジンと別オリジンのiframeを確認する	親フレームでは動くが子フレームで失敗する
仮想ホスト	`SetVirtualHostNameToFolderMapping`を使う画面を確認する	ローカルリソースの拒否、想定外のアクセス許可
複数WebView2	複数ウィンドウ、複数コントロールを同時に開く	片方だけ初期化失敗、終了後に再作成できない
再作成処理	WebView2を閉じて再表示する	2回目以降だけ通信できない
ユーザーデータ共有	同じUser Data Folderを使う複数画面を確認する	プロセス競合、初期化の待機、予期しない共有状態
権限	標準ユーザーと管理者実行を比較する	昇格時だけ動く、または標準ユーザー時だけ失敗する
長時間稼働	Runtime更新後も起動し続けるアプリを確認する	更新後も旧Runtimeを使い続ける

特に、JavaScriptからホストオブジェクトを直接操作しているアプリ、WebメッセージのSourceを使って許可判定しているアプリ、複数のWebView2インスタンスを管理しているアプリは優先度を上げてください。

なお、Runtime 151のリリースノートでは、WebView2ホストアプリを昇格実行ではなく標準ユーザーの整合性レベルで動かすことも推奨されています。現在、管理者権限を前提としているアプリは、host-pipeテストと併せて標準ユーザー実行へ移行できるか確認すると安全です。(Microsoft Learn)

SDK変更とRuntime変更を切り分けるテスト方法

SDKとRuntimeを同時に更新すると、不具合がどちらに起因するのか分からなくなります。

次の4パターンを用意すると、原因を切り分けやすくなります。

検証パターン	SDK	Runtime	目的
A	現行版	現行版	既存動作の基準を取る
B	1.0.4129.50	現行版	SDK更新や再ビルドの影響を確認する
C	現行版	151.0.4129.50以降	Runtime側のhost-pipe変更を確認する
D	1.0.4129.50	151.0.4129.50以降	本番予定構成を確認する

パターンBは、現行Runtimeが151.0.4129.50未満の場合、完全互換性を満たさない検証用構成です。本番配布には使用しません。

結果は次のように判断できます。

Cだけで問題が起きる場合は、Runtime 151側の挙動変更が有力
Bだけで問題が起きる場合は、SDK更新、参照DLL、ビルド条件の影響が有力
Dだけで問題が起きる場合は、新SDKと新Runtimeを組み合わせた処理を確認する
A以外すべてで問題が起きる場合は、複数の変更点やテスト環境差を疑う

legacy singleton host-pipe accessの変更はRuntime側の修正です。SDKだけを古い版へ戻しても、Runtimeが151.0.4129.50のままであれば、host-pipeの新しい制限は残ります。

問題を回避する目的でNuGetパッケージだけを戻すのではなく、SDKとRuntimeを分けた検証環境を用意してください。

Runtime更新後はアプリの再起動が必要

Evergreen Runtimeの新しいバージョンが端末へインストールされても、起動中のWebView2アプリが即座に新しいRuntimeへ切り替わるとは限りません。

すでに作成済みのWebView2環境がある場合、そのプロセスは従来のRuntimeを使い続けます。新しいRuntimeを使用するには、WebView2環境への参照を解放するか、アプリを再起動する必要があります。(Microsoft Learn)

次のようなアプリでは特に注意してください。

常駐型の業務アプリ
POSや受付端末
サイネージ
VDI上で長時間起動するアプリ
Windowsログオン後に自動起動し、ログオフまで終了しないアプリ

Runtime更新の完了だけを確認するのではなく、アプリ再起動後のBrowserVersionStringが151.0.4129.50以降になっていることまで確認します。

更新時に起きやすい失敗

SDKのバージョンだけ確認する

プロジェクトのNuGetパッケージが1.0.4129.50でも、利用者端末のRuntimeが古ければ完全互換性はありません。

アプリのビルド情報と、端末のRuntime情報を別々に管理してください。

Runtimeのメジャーバージョンだけ確認する

151という先頭番号だけでは不十分です。

最低条件は次の完全なバージョンです。

151.0.4129.50

インストーラー、起動チェック、端末棚卸しのいずれでも4つの数値を比較します。

開発端末だけでテストする

開発端末ではEvergreen Runtimeが最新でも、業務端末では更新延期ポリシーやネットワーク制限により古いRuntimeが残っていることがあります。

最低でも次の環境をテスト対象に含めます。

標準的なEvergreen端末
更新が延期された管理端末
オフライン端末
Fixed Version利用端末
標準ユーザー権限の端末

SDK更新後に再ビルドしない

参照パッケージを更新しただけでは、配布済みの実行ファイルは変わりません。

クリーンビルドを行い、成果物に含まれるWebView2Loader.dllや関連アセンブリも更新されていることを確認します。

SDKを戻せばhost-pipe変更も戻ると考える

host-pipe accessの制限はRuntime 151側の変更です。

Runtimeを変更せずにSDKだけを戻しても、同じRuntimeの内部動作が利用されます。SDKとRuntimeを分けた検証が必要です。

Runtime更新後にアプリを再起動しない

レジストリ上のRuntimeが更新されていても、起動中のアプリが古いRuntimeプロセスを利用している可能性があります。

再起動後に、実際のBrowserVersionStringを確認してください。

運用担当者向けの確認チェックリスト

WebView2 SDK 1.0.4129.50へ更新する前に、次の項目を確認します。

SDK 1.0.4129.50を使用する対象アプリを特定した
対象端末のRuntimeバージョンを棚卸しした
Runtime 151.0.4129.50以降を最低要件に設定した
4つの数値を含むバージョン比較を実装した
Evergreen、Fixed Version、プレビューチャネルの利用状況を確認した
Runtimeをアプリより先に配布する計画を立てた
SDK更新後にクリーンビルドした
Webメッセージとホストオブジェクトを再テストした
WebMessageReceivedEventArgs.Sourceを使う許可判定を確認した
複数WebView2と再作成処理を確認した
標準ユーザー権限でテストした
Runtime更新後にアプリを再起動した
実際に読み込まれたRuntimeバージョンをログへ記録した
少数端末から段階的に展開した

WebView2 SDK 1.0.4129.50の採用では、Runtime 151.0.4129.50以降を用意することが出発点です。ただし、バージョンをそろえるだけでは十分ではありません。

まずRuntimeを先行配布し、アプリ側でバージョンを検出します。そのうえで、SDKとRuntimeを分けた検証を行い、legacy singleton host-pipe access変更の影響を確認してください。特にWebメッセージ、ホストオブジェクト、オリジン判定、複数WebView2、標準ユーザー権限での動作を確認してから、本番環境へ段階的に展開するのが安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

WebView2 SDK 1.0.4129.50の要件｜必要なRuntimeと更新時の確認点

WebView2 SDK 1.0.4129.50に必要なRuntimeバージョン

「完全なAPI互換性」と「起動できる最低バージョン」は異なる

SDKとRuntimeの違いを理解する

Microsoft Edgeのバージョンだけを確認してはいけない

WebView2 Runtimeのバージョンをアプリから確認する方法

実際に読み込まれたRuntimeも記録する

インストーラーや管理ツールでRuntimeを確認する方法

EvergreenとFixed Versionのどちらを使うべきか

Runtimeはアプリ更新より先に配布する

legacy singleton host-pipe access変更とは

host-pipe変更で再テストすべき項目

SDK変更とRuntime変更を切り分けるテスト方法

Runtime更新後はアプリの再起動が必要

更新時に起きやすい失敗

SDKのバージョンだけ確認する

Runtimeのメジャーバージョンだけ確認する

開発端末だけでテストする

SDK更新後に再ビルドしない

SDKを戻せばhost-pipe変更も戻ると考える

Runtime更新後にアプリを再起動しない

運用担当者向けの確認チェックリスト

この記事を書いた人

コメント

コメントするコメントをキャンセル

WebView2 SDK 1.0.4129.50の要件｜必要なRuntimeと更新時の確認点

WebView2 SDK 1.0.4129.50に必要なRuntimeバージョン

「完全なAPI互換性」と「起動できる最低バージョン」は異なる

SDKとRuntimeの違いを理解する

Microsoft Edgeのバージョンだけを確認してはいけない

WebView2 Runtimeのバージョンをアプリから確認する方法

実際に読み込まれたRuntimeも記録する

インストーラーや管理ツールでRuntimeを確認する方法

EvergreenとFixed Versionのどちらを使うべきか

Runtimeはアプリ更新より先に配布する

legacy singleton host-pipe access変更とは

host-pipe変更で再テストすべき項目

SDK変更とRuntime変更を切り分けるテスト方法

Runtime更新後はアプリの再起動が必要

更新時に起きやすい失敗

SDKのバージョンだけ確認する

Runtimeのメジャーバージョンだけ確認する

開発端末だけでテストする

SDK更新後に再ビルドしない

SDKを戻せばhost-pipe変更も戻ると考える

Runtime更新後にアプリを再起動しない

運用担当者向けの確認チェックリスト

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル