WebView2 Runtime 147/148で、WDPクライアントがリモートデバッグサーバーへ接続できない問題に当たっている場合、まず確認すべきなのはWebView2 Runtimeの更新状況です。2026年4月18日時点で確認できるMicrosoft公式のWebView2 release notesでは、Runtime 147とRuntime 148の更新内容として「WDP clients being unable to connect to a remote debugging server」の修正が明記されています。Release SDK 1.0.3912.50はRuntime 147.0.3912.50以上、Prerelease SDK 1.0.3965-prereleaseはRuntime 148.0.3965.0以上を前提としています。(Microsoft Learn)
この修正は、WebView2アプリのリモート検査、DevTools接続、Windows Device Portal経由の診断、WebDriverによるテスト自動化に依存している開発者にとって重要です。画面表示や通常操作は動いているのに、edge://inspectやWDP経由の接続だけが失敗する場合、コードのバグではなくRuntime側のリグレッションや環境差分が原因になっている可能性があります。
WebView2 Runtime 147/148で修正されたWDPリモートデバッグ接続の問題
今回注目すべき修正は、WebView2 RuntimeのRuntime-only bug fixとして追加されたものです。Microsoftのリリースノートでは、Runtime 147向けのRelease SDK 1.0.3912.50と、Runtime 148向けのPrerelease SDK 1.0.3965-prereleaseの両方に、WDPクライアントがリモートデバッグサーバーへ接続できない問題の修正が記載されています。(Microsoft Learn)
ここでいうWDPは、一般にWindows Device Portalを指します。WebView2のUWP/WinUI 2アプリなどでは、通常の組み込みDevToolsではなく、Windows Device PortalやMicrosoft Edge DevToolsを使ってリモート検査する構成があります。MicrosoftのWebView2リモートデバッグ手順でも、Device Portalを有効化し、http://<Device Portal URL>/msedgeやedge://inspectからWebView2インスタンスを検査する流れが説明されています。(Microsoft Learn)
この問題が厄介なのは、アプリ本体の描画、API呼び出し、認証、ネットワーク通信が正常に見えても、デバッグ・診断・自動テストの入口だけが塞がる点です。開発現場では「アプリは起動するが、DevToolsで見えない」「WDPの/msedgeに対象が出ない」「WebDriverが既存のWebView2プロセスへアタッチできない」といった形で表面化します。
影響を受けやすい開発者と環境
今回の修正を優先して確認すべきなのは、次のようなチームです。
| 該当する開発・運用シーン | 起きやすい問題 | 優先して確認すべきこと |
|---|---|---|
| WebView2 WinUI 2 / UWPアプリをリモートデバッグしている | edge://inspectからWebView2が見えない、接続できない | WebView2 Runtimeが147.0.3912.50以上、または148.0.3965.0以上か |
| Windows Device Portal経由でWebView2を検査している | http://localhost:50080/msedgeなどで空の一覧になる | Device Portal、Remote Tools、Runtimeバージョンの組み合わせ |
| WebDriverで既存のWebView2インスタンスへ接続している | wdpAddressやwdpProcessId指定でもアタッチに失敗する | WDP接続経路とRuntime更新状況 |
| CIや検証端末でWebView2診断を自動化している | ローカルでは成功し、特定端末や特定チャネルだけ失敗する | Evergreen/Fixed VersionのどちらでRuntimeを配布しているか |
| 埋め込みEdgeランタイムで障害解析を行うツール開発者 | ユーザー環境でだけリモート検査できない | Runtimeの実バージョン、更新ポリシー、ポート、認証設定 |
特に、グローバルチームで開発している場合は注意が必要です。ある地域や検証端末ではEvergreen Runtimeが更新済みでも、企業管理端末、オフライン検証環境、固定バージョン同梱アプリでは古いRuntimeが残っていることがあります。結果として、同じコードでも「A拠点ではデバッグできるがB拠点ではできない」という再現性の低い障害に見えます。
まず確認すべきRuntimeバージョン
今回の修正に関しては、Runtime 147系と148系で確認すべき基準が異なります。
| 利用している系統 | 対応するSDK | 確認すべきRuntime | 位置づけ |
|---|---|---|---|
| Runtime 147 | Release SDK 1.0.3912.50 | 147.0.3912.50以上 | 安定版リリース向け |
| Runtime 148 | Prerelease SDK 1.0.3965-prerelease | 148.0.3965.0以上 | プレビュー検証向け |
実務では、まず安定版のRuntime 147.0.3912.50以上で再現するかを確認するのが現実的です。Runtime 148はPrerelease SDKの文脈で扱われているため、本番利用よりも、次期Runtimeでの互換性検証や先行テストに向いています。
アプリ内でRuntimeバージョンを確認する
.NET/C#であれば、CoreWebView2Environment.GetAvailableBrowserVersionString()を使って利用可能なWebView2 Runtimeのバージョン情報を取得できます。このAPIは、WebView2 Runtimeや非StableチャネルのMicrosoft Edgeのブラウザーバージョン情報を返すため、診断ログに出しておくと原因切り分けが速くなります。(Microsoft Learn)
using Microsoft.Web.WebView2.Core;
var version = CoreWebView2Environment.GetAvailableBrowserVersionString();
Console.WriteLine($"WebView2 Runtime: {version}");ログに出すなら、単にバージョンだけでなく、次の情報も一緒に記録しておくと便利です。
WebView2 Runtime version
WebView2 SDK version
OS version
App architecture: x64 / x86 / Arm64
Runtime distribution: Evergreen / Fixed Version
Remote debugging route: WDP / remote-debugging-port / WebDriver
Device Portal URLこれにより、「Runtimeは更新済みだがDevice Portal側のポートが違う」「固定バージョンRuntimeを同梱していて修正版を使っていない」といった切り分けがしやすくなります。
WDPリモートデバッグ接続が失敗する時の切り分け手順
WebView2のリモートデバッグ接続失敗は、Runtimeの不具合だけでなく、Device Portal、ポート、認証、起動引数、WebView2インスタンス生成タイミングでも起こります。いきなりコードを大きく変更するのではなく、次の順で確認するのがおすすめです。
| 手順 | 確認内容 | 判断基準 |
| -: | ————————————– | ——————————————- |
| 1 | WebView2 Runtimeのバージョンを確認 | 147.0.3912.50以上、または検証用途で148.0.3965.0以上か |
| 2 | Device Portalが有効か確認 | Windowsの開発者向け設定でDevice Portalが有効になっているか |
| 3 | http://<Device Portal URL>/msedgeを開く | 空配列なのか、WebView2インスタンスが表示されるのか |
| 4 | edge://inspectから接続 | Device Portal URLを指定して接続できるか |
| 5 | WebView2の起動引数を確認 | WDP用のFeature Flagやリモートデバッグポートが初期化前に設定されているか |
| 6 | 認証・HTTPS・ポートを確認 | 50080/50043以外のポートや認証設定が必要ではないか |
| 7 | Fixed Version配布なら同梱Runtimeを確認 | アプリに古いRuntimeを同梱したままではないか |
Microsoftの手順では、WebView2 WinUI 2 UWPアプリでリモートデバッグを有効にするため、CoreWebView2インスタンスを作成する前にWEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTSへ--enable-features=msEdgeDevToolsWdpRemoteDebuggingを設定する流れが示されています。(Microsoft Learn)
Environment.SetEnvironmentVariable(
"WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS",
"--enable-features=msEdgeDevToolsWdpRemoteDebugging"
);重要なのは、WebView2の初期化前に設定することです。EnsureCoreWebView2Async()を呼んだ後、またはWebView2.Sourceを設定した後に環境変数を変更しても、すでに生成されたWebView2環境には反映されません。ここは実装ミスが起きやすいポイントです。
edge://inspectで見えない場合に確認するポイント
edge://inspectからWebView2インスタンスが見えない場合、Runtime更新だけで解決しないケースもあります。次の順で確認すると、原因を絞り込みやすくなります。
Device PortalのURLとポートを確認する
Windows Device Portalでは、デスクトップWindowsの既定ポートとしてHTTPは50080、HTTPSは50043が使われることがあります。ただし、既存のポート要求との競合を避けるため、環境によっては一時的な範囲の別ポートになる場合があります。Microsoftのドキュメントでも、Device Portalで実際に使われているURLを確認する手順が案内されています。(Microsoft Learn)
よくある失敗例は次の通りです。
| 症状 | よくある原因 | 対処 |
|---|---|---|
localhost:50080にアクセスできない | Device Portalのポートが別番号になっている | Windows設定のDevice Portal欄で実URLを確認 |
edge://inspectで接続できない | HTTP/HTTPSやポートを取り違えている | http://IP:portまたはhttps://IP:portを正しく指定 |
| 認証ダイアログで失敗する | Device Portal側で認証が有効 | WDPのユーザー名・パスワードを確認 |
/msedgeが空配列になる | 対象アプリがリモートデバッグ可能な状態で起動していない | WebView2初期化前の起動引数を確認 |
| 端末によって成功・失敗が分かれる | RuntimeやEdgeチャネル、管理ポリシーが違う | Runtimeバージョンと配布方式をログ化 |
WebView2インスタンスが生成済みか確認する
リモートデバッグの一覧に対象が出ない場合、WebView2コントロールがまだ生成されていない可能性があります。ネイティブUIを操作してからWebView2画面が開くアプリでは、起動直後に/msedgeを確認しても対象が表示されないことがあります。
この場合は、対象画面まで遷移してWebView2インスタンスを生成してから、もう一度http://<Device Portal URL>/msedgeを開きます。CIや自動テストでは、WebView2インスタンスが表示されるまで数秒待つリトライ処理を入れると安定します。
1. アプリ起動
2. WebView2を含む画面へ遷移
3. /msedge をポーリング
4. browserProcessId を取得
5. DevToolsまたはWebDriverで接続WebDriverやテスト自動化への影響
WebView2のリモートデバッグ接続は、DevToolsで画面を検査するだけでなく、WebDriverによるテスト自動化でも重要です。MicrosoftのWebView2 WebDriver手順では、実行中のWebView2インスタンスに接続する場合、--remote-debugging-portを設定し、EdgeOptions.DebuggerAddressで接続する方法が説明されています。(Microsoft Learn)
EdgeOptions eo = new EdgeOptions();
eo.UseWebView = true;
eo.DebuggerAddress = "localhost:9222";
EdgeDriver driver = new EdgeDriver(eo);UWPアプリなどでRemote Tools for Microsoft Edgeを使う構成では、wdpAddressとwdpProcessIdを指定して特定のWebView2プロセスに接続します。Microsoftの手順では、/msedgeでbrowserProcessIdを確認し、それをwdpProcessIdとして渡す流れが示されています。(Microsoft Learn)
EdgeOptions eo = new EdgeOptions();
eo.AddAdditionalEdgeOption("wdpAddress", "localhost:50080");
eo.AddAdditionalEdgeOption("wdpProcessId", 47860);
// 認証が有効なWDPでは必要に応じて指定
// eo.AddAdditionalEdgeOption("wdpUsername", "username");
// eo.AddAdditionalEdgeOption("wdpPassword", "password");
EdgeDriver driver = new EdgeDriver(eo);今回のRuntime修正は、このようなWDP経由の接続に依存するテスト基盤にも影響します。特に、夜間ビルドや回帰テストで「アプリ起動は成功しているがWebDriverアタッチだけ失敗する」という場合は、テストコードの待機時間やセレクターより先に、Runtimeバージョンを確認すべきです。
Evergreen配布とFixed Version配布で対応が変わる
WebView2 Runtimeの更新確認では、アプリがEvergreen Runtimeを使っているのか、Fixed Version Runtimeを同梱しているのかで対応が変わります。
Microsoftのドキュメントでは、Evergreen配布モードではWebView2 Runtimeがアプリに同梱されず、クライアントマシンで自動更新されると説明されています。一方、Fixed Version配布では特定バージョンのRuntimeをアプリに同梱するため、開発側が更新を管理する必要があります。(Microsoft Learn)
| 配布方式 | Runtime更新 | 今回の修正への対応 |
|---|---|---|
| Evergreen Runtime | 原則としてクライアント側で自動更新 | 端末に修正版Runtimeが入っているか確認。管理環境では更新ポリシーも確認 |
| Fixed Version Runtime | アプリに同梱したRuntimeを使用 | 同梱Runtimeを147.0.3912.50以上など修正版へ差し替え、アプリを再配布 |
| Preview/Insider検証 | Beta/Dev/Canaryなどで先行確認 | Runtime 148系の検証ではPrerelease SDKの前提を確認 |
多くの一般的なWebView2アプリではEvergreen Runtimeが扱いやすいですが、企業向けアプリや医療・製造・金融系の管理環境では、Fixed Versionを選ぶこともあります。Fixed Versionを使っている場合、ユーザー端末のWebView2 Runtimeが更新されても、アプリが同梱Runtimeを参照していれば修正の恩恵を受けられません。
修正版Runtime適用後に実施したい確認項目
Runtimeを更新しただけで「完了」とせず、実際のリモート診断フローを一通り確認しましょう。特に、開発者向け機能は通常のUIテストでは見落とされがちです。
| 確認項目 | 成功条件 |
|---|---|
| アプリ起動 | WebView2を含む画面が正常に表示される |
| Runtimeバージョン取得 | ログ上で147.0.3912.50以上、または検証対象の148系が確認できる |
| Device Portal接続 | http://<Device Portal URL>/msedgeへアクセスできる |
| WebView2一覧表示 | /msedgeに対象WebView2インスタンスが表示される |
edge://inspect接続 | リモートWindowsデバイスへ接続できる |
| DevTools起動 | 対象WebView2の「検査」からDevToolsを開ける |
| WebDriverアタッチ | DebuggerAddressまたはWDP指定で既存インスタンスに接続できる |
| CI再実行 | 失敗していた診断・自動テストが安定して通る |
この確認をテンプレート化しておくと、今後のWebView2 Runtime更新時にも役立ちます。WebView2はWebプラットフォームの更新を取り込むため、描画やAPIだけでなく、開発者ツール、診断、セキュリティ関連の挙動も変わることがあります。
すぐに取るべき対応
今回のWebView2 Runtime 147/148の更新で重要なのは、WDPリモートデバッグ接続の失敗が開発環境・診断環境を直接止めるタイプの不具合である点です。通常のユーザー操作では見えにくくても、開発者にとっては調査・検証・自動化を止める大きな障害になります。
まずは、次の3点を実施してください。
- WebView2 Runtimeの実バージョンをログまたはAPIで確認する
- WDP、
edge://inspect、WebDriverアタッチの接続経路を再検証する - Fixed Version Runtimeを同梱している場合は、修正版Runtimeへの差し替え計画を立てる
WebView2 Runtime 147.0.3912.50以上で安定版の修正を確認し、必要に応じてRuntime 148系のPrerelease環境でも先行検証しておくと、リモート検査や診断ツールに依存する開発フローを止めずに済みます。
コメント