WebView2 Runtimeの更新後に、旧クライアントだけが起動しない、画面が表示されない、補助プロセスとの接続に失敗するといった問題が発生した場合は、singleton host pipeへのアクセス制限が関係している可能性があります。
MicrosoftはWebView2 Runtime 151.0.4129.50で、legacy WebView2 clientによるsingleton host pipeへのアクセスを制限しました。この変更はRuntime 152にも引き継がれています。基本的な対処は、制限を無効化することではありません。WebView2内部のパイプに依存したコードや古いコンポーネントを特定し、公開APIを使う構成へ更新したうえで再テストします。
なお、1.0.4129.50と1.0.4181-prereleaseは主にSDKパッケージのバージョンです。実際に端末上で動作するRuntimeのバージョンと混同しないことが、切り分けの第一歩になります。
WebView2のsingleton host pipe制限とは
WebView2 Runtimeは、ホストアプリケーションのプロセスだけで完結して動くものではありません。ブラウザープロセス、レンダラープロセス、GPUプロセスなど、複数のプロセスによって構成されています。
1つのWebView2プロセスグループには、基本的に1つのブラウザープロセスが存在します。同じユーザーデータフォルダーを使うWebView2インスタンスは、そのブラウザープロセスや関連プロセスを共有できます。(Microsoft Learn)
今回のリリースノートにある「singleton host pipe」は、こうしたWebView2のホスト側とRuntime側の連携に使われる内部通信経路を指していると考えられます。ただし、Microsoftは公開リリースノートで、パイプ名、アクセス判定の条件、対象となる旧クライアントの一覧までは公表していません。
そのため、次のように判断するのは適切ではありません。
- SDKが古ければ必ず影響を受ける
- 同じユーザーデータフォルダーを共有する構成が禁止された
- Windowsの名前付きパイプ自体がWebView2で使えなくなった
- パイプのアクセス権を広げれば正式に解決できる
制限の対象は、WebView2の内部実装に属するsingleton host pipeへ、legacy clientがアクセスする経路です。アプリケーションが独自に作成した名前付きパイプまで一律に禁止する変更ではありません。
Runtime 150から152までの変更を整理
singleton host pipeに関する強化は、Runtime 151で突然始まったわけではありません。
Runtime 150では、非推奨のWebView2におけるsingleton host pipeアクセスが制限されました。その後、Runtime 151ではlegacy WebView2 clientに対する制限が追加され、Runtime 152でも同様の制限が維持されています。(Microsoft Learn)
| 公開時期 | WebView2 Runtime | 対応する主なSDK | singleton host pipeに関する変更 |
|---|---|---|---|
| 2026年7月7日 | 150.0.4078.44 | 1.0.4078.44 | 非推奨WebView2からのアクセスを制限 |
| 2026年8月3日 | 151.0.4129.50 | 1.0.4129.50 | legacy clientからのアクセスを制限 |
| 2026年8月3日 | Preview 152.0.4181.0 | 1.0.4181-prerelease | Runtime 152向けの事前検証 |
| 2026年8月28日 | 152.0.4191.53 | 1.0.4191.47 | legacy clientへの制限を正式版でも継続 |
SDK 1.0.4129.50は、完全なAPI互換性を得るためにRuntime 151.0.4129.50以降を必要とします。一方、1.0.4181-prereleaseはRuntime 152向けのプレリリースSDKであり、Microsoft Edge 152.0.4181.0以降のRuntimeとの組み合わせが前提です。(Microsoft Learn)
つまり、「1.0.4129.50に更新したら制限された」というより、実際には端末上のRuntimeが151以降へ更新され、Runtime側のアクセス制御が変わった可能性があります。
影響を受けやすい構成
通常のWebView2アプリケーションが、単に古いSDKでビルドされているだけで必ず停止するわけではありません。影響を受けやすいのは、WebView2内部の通信経路や非推奨の実装に依存している構成です。
| 構成 | 影響の可能性 | 確認するポイント |
|---|---|---|
| WebView2内部の名前付きパイプへ直接接続している | 高い | \\.\pipe\、NamedPipeClientStream、WaitNamedPipeなどの利用 |
| 古いWebView2ラッパーや独自組み込みコンポーネントを使っている | 高い | コンポーネントの更新履歴、同梱DLL、非推奨API |
| 補助プロセスが既存のWebView2ブラウザープロセスへ独自接続している | 高い | 2つ目のプロセスだけ失敗しないか |
| WebView2プロセスへDLLを注入またはフックしている | 高い | セキュリティ製品、監視製品、プラグイン |
| 管理者権限と標準ユーザー権限のプロセスが混在している | 中程度 | 整合性レベルや起動元の違い |
| 同じユーザーデータフォルダーを異なる設定で開いている | 中程度 | 言語、追加引数、チャンネル、環境オプション |
| 公開されたWebView2 APIだけを使っている | 低い | SDK、Runtime、初期化方法がサポート範囲内か |
| 同じ設定のCoreWebView2Environmentとユーザーデータフォルダーを使う | 低い | 正式にサポートされた共有方法か |
Microsoftは、同じユーザーデータフォルダーを使って複数のWebView2コントロールやアプリケーションがセッションを共有できることを文書化しています。複数プロセスでの共有自体が今回禁止されたわけではありません。(Microsoft Learn)
ただし、同じユーザーデータフォルダーを使いながら、CoreWebView2Environmentの言語や環境オプションが異なる場合は、後から起動したWebView2の作成に失敗することがあります。これはhost pipe制限とは別に確認すべきポイントです。(Microsoft Learn)
関連が疑われる症状
singleton host pipe制限に固有のエラーコードは、公開リリースノートでは示されていません。そのため、症状だけで断定せず、Runtimeのバージョンと構成を組み合わせて判断します。
関連性が疑われるのは、次のようなケースです。
- アプリケーションを変更していないのに、Runtime更新後から起動できなくなった
- 1つ目のWebView2は起動するが、2つ目のプロセスや補助ツールだけ失敗する
- 古いビルドでは失敗するが、最新SDKで再ビルドした版は動作する
- 初期化時にアクセス拒否やプロセス間通信の失敗が記録される
- 標準ユーザー起動と管理者起動で結果が変わる
- 古いWebView2ラッパーを無効にすると起動する
- 組織内の既知正常Runtimeでは動き、151または152で失敗する
白画面や初期化失敗は、ユーザーデータフォルダーのアクセス権、セキュリティ製品、DLL注入、Runtimeファイルの実行制限などでも発生します。host pipe制限だけに絞り込まず、ほかの要因も並行して確認する必要があります。
WebView2の旧クライアントが動かない場合の対応手順
実際に使用しているRuntimeのバージョンを記録する
最初に確認するのは、プロジェクトへ追加したNuGetパッケージではなく、問題が発生した端末で実際にロードされているWebView2 Runtimeです。
.NETアプリケーションでは、GetAvailableBrowserVersionStringまたはBrowserVersionStringを使って確認できます。(Microsoft Learn)
using Microsoft.Web.WebView2.Core;
using System.Diagnostics;
var installedVersion =
CoreWebView2Environment.GetAvailableBrowserVersionString();
Debug.WriteLine($"Available WebView2 Runtime: {installedVersion}");
var environment = await CoreWebView2Environment.CreateAsync(
browserExecutableFolder: null,
userDataFolder: userDataFolder,
options: null);
Debug.WriteLine(
$"Loaded WebView2 Runtime: {environment.BrowserVersionString}");
await webView2.EnsureCoreWebView2Async(environment);障害ログには、最低でも次の情報を残します。
- アプリケーションのバージョン
- WebView2 SDKのバージョン
- 実際にロードしたRuntimeのバージョン
- Evergreen版かFixed Version版か
- x86、x64、Arm64の別
- ホストプロセスの権限
- ユーザーデータフォルダーのパス
- 単一プロセスか複数プロセスか
- 初期化時に指定した環境オプション
- 例外メッセージとHRESULT
SDKとRuntimeを一緒に「WebView2のバージョン」として記録すると、原因を特定しにくくなります。必ず分けて保存してください。
既知正常版と151・152でA/Bテストする
開発環境では、組織内で正常動作が確認できているRuntimeと、151・152を比較します。
| テスト条件 | 確認できること |
|---|---|
| 既知正常Runtime＋現在のアプリ | 比較基準 |
| Runtime 151＋現在のアプリ | legacy client制限との関連 |
| Runtime 152＋現在のアプリ | 制限が継続しているか |
| Runtime 152＋更新済みアプリ | コード更新で解消するか |
| 新しいユーザーデータフォルダー | UDF破損や権限問題の切り分け |
| 既存のユーザーデータフォルダー | 実運用データで再現するか |
| 標準ユーザー起動 | 推奨権限で動くか |
| 管理者起動 | 整合性レベルの影響 |
| 単一プロセス | 基本的な初期化の確認 |
| 複数プロセス | 共有や接続処理の確認 |
検証目的でFixed Versionを利用すると、Runtime更新のタイミングを固定できます。ただし、Microsoftは一般的な運用では自動的にセキュリティ修正を受け取れるEvergreen Runtimeを推奨しています。Fixed Versionを使う場合も、検証後は定期的に更新しなければなりません。(Microsoft Learn)
ソースコードと依存コンポーネントを調査する
アプリケーション本体だけでなく、プラグイン、ネイティブDLL、古いラッパー、別プロセスで動く補助ツールも対象にします。
Visual Studioの「ファイル内の検索」などで、次の文字列やAPIを確認します。
\\.\pipe\
NamedPipeClientStream
NamedPipeServerStream
CreateNamedPipe
WaitNamedPipe
CallNamedPipe
CreateFile
WebView2Loader.dllNamedPipeClientStreamが見つかったからといって、すべてが問題というわけではありません。確認すべきなのは、その接続先がアプリケーション自身のパイプなのか、WebView2やMicrosoft Edgeが作成した内部パイプなのかです。
ソースコードに該当処理がない場合は、次の項目も調べます。
- 古いWebView2 SDKを内包するサードパーティ製コンポーネント
- 複数世代の
WebView2Loader.dll - インストール先に残った旧DLL
- 更新されていないネイティブラッパー
- WebView2のプロセスへDLLを注入する監視製品
- ブラウザープロセスの内部情報を探索するコード
- パイプ名を列挙して接続先を決めるコード
Microsoftは、WebView2プロセスへのDLL注入を避け、WebView2 Runtimeの子プロセスやRuntimeフォルダーへのアクセスを妨げない構成を推奨しています。(Microsoft Learn)
内部パイプ依存を公開APIへ置き換える
WebView2内部のhost pipeを直接利用している場合は、その目的に対応した公開APIへ移行します。
| 実現したいこと | 推奨される方法 |
|---|---|
| Webページからホストへデータを送る | window.chrome.webview.postMessageとWebMessageReceived |
| ホストからWebページへデータを送る | PostWebMessageAsJsonまたはPostWebMessageAsString |
| JavaScriptからネイティブ機能を呼ぶ | AddHostObjectToScript |
| Cookieやログイン状態を共有する | 同じユーザーデータフォルダーとプロファイルを使う |
| 複数のWebView2をまとめて管理する | 共通のCoreWebView2Environmentを使う |
| アプリ独自のプロセス間通信を行う | アプリ専用の名前付きパイプやローカルIPCを作る |
| Runtime更新を検知する | NewBrowserVersionAvailableを使う |
| プロセス障害を記録する | ProcessFailedとBrowserProcessExitedを使う |
Web側とネイティブ側の通信には、WebView2が提供するWeb Message APIを利用できます。Microsoftは文字列を手作業でスクリプトへ埋め込むより、JSONライブラリを使ってPostWebMessageAsJsonで送る方法を推奨しています。(Microsoft Learn)
JavaScriptからネイティブオブジェクトを操作する必要がある場合は、AddHostObjectToScriptを利用できます。ただし、信頼できないページへ強い権限を持つオブジェクトを公開しないようにしてください。(Microsoft Learn)
複数のネイティブプロセス間で通信する必要がある場合は、WebView2 Runtimeの内部パイプを流用せず、アプリケーション専用のIPCを作成します。その際は、接続可能なユーザー、プロセス、セッションを明示し、受信データの形式や長さを検証してください。
CoreWebView2Environmentとユーザーデータフォルダーを整理する
複数のWebView2インスタンスでセッションを共有したい場合は、内部パイプへ接続するのではなく、CoreWebView2Environmentとユーザーデータフォルダーを正しく共有します。
同じユーザーデータフォルダーを使うプロセスでは、次の設定を揃えます。
- Runtimeの種類とチャンネル
- ブラウザー実行ファイルの場所
- 言語設定
- 追加ブラウザー引数
- 環境オプション
- プロファイルの扱い
- アプリケーションのログオンセッション
ユーザーデータフォルダーを共有する必要がないアプリケーションでは、アプリごとに専用フォルダーを割り当てた方が、障害の影響範囲を限定できます。
一方、複数プロセスで共有する構成では、片方のプロセスが利用中にユーザーデータフォルダーを削除したり、設定を変更して環境を再作成したりしないようにします。Runtimeのプロセスが完全に終了したことを確認するには、BrowserProcessExitedを利用できます。(Microsoft Learn)
問題の切り分けとして新しいユーザーデータフォルダーを試すことは有効ですが、最初から既存フォルダーを削除するのは避けてください。Cookie、ログイン状態、キャッシュ、権限設定などが失われるうえ、本来の原因が隠れる可能性があります。
WebView2ホストを標準ユーザー権限で動かす
Microsoftは、WebView2をホストするプロセスを管理者権限ではなく、標準ユーザーの整合性レベルで実行することを推奨しています。最小権限で動かすことで、Webコンテンツやレンダラープロセスが侵害された場合の影響を抑えられます。(Microsoft Learn)
管理者権限が必要な処理がある場合でも、WebView2を含む画面全体を常に昇格させるのは避けます。
現実的な構成は、次のようになります。
- WebView2を含むUIプロセスは標準ユーザーで起動する
- 管理者権限が必要な機能だけを別プロセスやサービスへ分離する
- UIプロセスから、用途を限定した独自IPCで処理を依頼する
- 管理者側で要求内容、送信元、引数を検証する
「管理者として実行すると動く」という結果が出ても、それを恒久対策にしないでください。アクセス制御の不整合が一時的に隠れているだけの場合があります。
SDKとラッパーを更新してクリーンビルドする
SDKを更新するときは、NuGetパッケージだけでなく、アプリケーションに含まれるすべてのWebView2関連ファイルを確認します。
実施する作業は次のとおりです。
Microsoft.Web.WebView2パッケージをサポート対象のRelease SDKへ更新する- プレリリースSDKを本番向けパッケージに残していないか確認する
binフォルダーとobjフォルダーを削除する- ソリューション全体を再ビルドする
- x86、x64、Arm64ごとの配置ファイルを確認する
- 古い
WebView2Loader.dllがインストール先に残っていないか確認する - サードパーティ製ラッパーやプラグインも更新する
- インストーラーで旧ファイルが確実に置換されるか確認する
1.0.4181-prereleaseはRuntime 152向けの事前検証用SDKです。本番アプリケーションでは、原則としてRelease SDKとEvergreen Runtimeを組み合わせます。Microsoftは、Prerelease SDKの検証にはMicrosoft EdgeのPreviewチャンネルを使い、Release SDKにはEvergreen WebView2 Runtimeを使うことを推奨しています。(Microsoft Learn)
SDKだけを更新しても、内部パイプへ接続しているサードパーティDLLが残っていれば問題は解消しません。アプリケーション全体の依存関係を更新する必要があります。
初期化失敗とプロセス障害をログへ残す
初期化前に失敗する場合は、EnsureCoreWebView2AsyncやCoreWebView2Environment.CreateAsyncで発生した例外を記録します。
初期化後にWebView2プロセスが終了する場合は、ProcessFailedを登録しておくと、障害の種類、理由、終了コード、対象プロセスなどを記録できます。(Microsoft Learn)
webView2.CoreWebView2.ProcessFailed += (_, e) =>
{
Debug.WriteLine(
$"Kind={e.ProcessFailedKind}, " +
$"Reason={e.Reason}, " +
$"ExitCode={e.ExitCode}, " +
$"Process={e.ProcessDescription}");
};Evergreen Runtimeの新しいバージョンがインストールされた場合は、NewBrowserVersionAvailableが通知されます。ただし、新しいRuntimeを実際に使うには、古いWebView2環境を終了して新しい環境を作成するか、アプリケーションを再起動する必要があります。(Microsoft Learn)
environment.NewBrowserVersionAvailable += (_, _) =>
{
Debug.WriteLine(
"新しいWebView2 Runtimeが利用可能です。再起動が必要です。");
};長時間起動し続ける業務アプリでは、Runtimeが更新されても、アプリケーションが再起動されるまで古いRuntimeプロセスを使い続けることがあります。問い合わせ時には、端末にインストールされているバージョンだけでなく、アプリケーションが実際にロードしたバージョンを確認してください。
再テストで確認すべき項目
修正後は、WebView2が一度表示できることだけで完了としないでください。singleton host pipeの問題は、複数プロセス、再起動、Runtime更新などの条件で表面化する可能性があります。
最低限、次のテストを実施します。
- アプリケーションのコールドスタート
- 連続した起動と終了
- アプリケーションの多重起動
- WebView2画面を閉じて再作成する操作
- 複数ウィンドウでの同時表示
- 補助プロセスとの連携
- 標準ユーザーでの動作
- 管理者権限が混在する場合の動作
- 既存ユーザーデータフォルダーでの動作
- 新規ユーザーデータフォルダーでの動作
- Cookieやログイン状態の共有
WebMessageReceivedによる双方向通信- Runtime更新後の再起動
- ブラウザープロセスの異常終了からの復旧
- x86、x64、Arm64の各ビルド
- セキュリティ製品が導入された端末での動作
Runtime 152からは、WebView2 Runtimeのリリース周期がMicrosoft Edgeに合わせた2週間間隔へ移行しました。Runtime 151は4週間間隔で提供された最後のバージョンです。更新頻度が上がるため、正式版の公開後に初めて確認する運用では対応が遅れやすくなります。(Microsoft Learn)
開発チームでは、Previewチャンネルを使った起動テストをCIや定期検証へ組み込み、将来のRuntimeでアプリケーションが起動できるかを早めに確認する運用が有効です。
緊急時の一時回避策
業務アプリが起動できず、修正版をすぐ配布できない場合は、影響を抑えるための一時対応を検討します。
| 一時対応 | 評価 | 注意点 |
|---|---|---|
| 問題のある旧プラグインを無効化する | 推奨 | WebView2本体を最新状態に保ちやすい |
| legacy clientを使う機能だけ停止する | 推奨 | 影響範囲を限定できる |
| ベンダー提供の更新版へ差し替える | 推奨 | SDKだけでなく内包DLLも確認する |
| 検証済みFixed Versionで一時固定する | 条件付き | セキュリティ更新が自動適用されない |
| Runtimeの更新を組織全体で止める | 非推奨 | 他のWebView2アプリやセキュリティへ影響する |
| 内部パイプのACLを広げる | 避ける | hardeningを弱め、将来の更新でも壊れやすい |
| 非公開のブラウザーフラグで制限を無効化する | 避ける | 本番利用を前提とした互換性がない |
| 古いRuntimeを恒久利用する | 避ける | 修正済みの脆弱性や不具合が残る可能性がある |
WebView2のブラウザーフラグは、開発時のテストや診断には利用できますが、本番アプリケーションでの利用は推奨されていません。フラグは将来削除されたり、動作が変更されたりする可能性があります。(Microsoft Learn)
Fixed Versionによる一時固定を行う場合は、対象端末、期限、解除条件、次に検証するRuntimeを明確にします。「動いたのでそのまま固定する」という運用にしないことが重要です。
原因を判断するための切り分け表
| 確認結果 | 疑うべき原因 | 次の対応 |
|---|---|---|
| Runtime更新直後から失敗した | Runtime側の互換性変更 | 既知正常版とのA/Bテスト |
| 151と152の両方で失敗する | legacy clientまたは内部依存 | ラッパー、DLL、パイプ処理を調査 |
| 新規ユーザーデータフォルダーでは動く | UDFの権限や構成 | ACL、保存場所、環境オプションを確認 |
| 単一プロセスでは動く | 複数プロセス共有の問題 | UDF、起動順、独自IPCを確認 |
| 2つ目のプロセスだけ失敗する | 内部パイプへの再接続依存 | 公開APIまたはアプリ専用IPCへ移行 |
| 標準ユーザーでは動く | 昇格プロセスとの不整合 | UIを標準ユーザーへ戻す |
| 管理者起動だけ動く | ACLや権限不足 | UDFと実行ファイルの権限を確認 |
| SDK更新後も変わらない | サードパーティDLLの旧実装 | 依存コンポーネントを更新 |
| セキュリティ製品停止時だけ動く | プロセスやIPCの監視・遮断 | 製品側の正式な除外方法を確認 |
| WebView2作成前に失敗する | Runtime検出や環境作成 | 例外、HRESULT、配置ファイルを確認 |
| WebView2作成後に終了する | 子プロセス障害 | ProcessFailedの情報を確認 |
ベンダーへ問い合わせる場合は、「WebView2が動かない」だけではなく、Runtime、SDK、権限、ユーザーデータフォルダー、再現条件、終了コードをまとめて提示します。特に「Runtime 151以降だけで再現する」「補助プロセスだけ失敗する」といった差分は、legacy client依存を特定する重要な情報になります。
WebView2ホストパイプ制限への対応をまとめると
WebView2 Runtime 151と152で導入されたsingleton host pipe制限は、旧クライアントや非推奨の内部接続経路を対象としたhardeningです。通常のWebView2アプリケーションであれば、制限を回避するのではなく、公開されたSDKとAPIに沿って構成を更新します。
最初に、端末で実際にロードされているRuntimeのバージョンを記録してください。次に、既知正常版とのA/Bテストを行い、単一プロセス、複数プロセス、標準ユーザー、新規ユーザーデータフォルダーの条件で差を確認します。
内部パイプへの直接接続、古いラッパー、補助プロセス、DLL注入が見つかった場合は、Web Message API、AddHostObjectToScript、共通のCoreWebView2Environment、アプリ専用IPCへ置き換えます。
最終的には、Release SDKと最新のEvergreen Runtimeで再ビルドし、Runtime 152およびPreviewチャンネルを含む回帰テストを実施します。古いRuntimeへの固定や内部パイプの権限変更は恒久対策にせず、Microsoftのhardeningに追従できる実装へ移行することが重要です。
コメント