Microsoft developer platformでWebView2を使っている開発者が今回まず見るべき点は、WebView2 SDK 148のRelease SDK 1.0.3967.48では大きなAPI昇格はなく、Runtime更新時のクラッシュにつながる不具合修正が中心という点です。一方で、Prerelease SDK 1.0.4015-prereleaseではWorker APIの安定化、Enhanced security mode stateの実験API追加、Service Worker関連の改善など、次期機能を先行検証したいチーム向けの変更が含まれます。なお、2026年5月5日時点で確認できる情報はGitHub PR上のドキュメント更新であり、PRはレビュー中、Microsoft Learnでの公開予定日は2026年5月11日とされています。正式な導入判断は、NuGetパッケージとMicrosoft Learnの公開状態を確認してから行うのが安全です。(GitHub)
WebView2 SDK 148のRelNotes更新で何が変わるのか
今回の「RelNotes for WebView2 SDK 148 (May 2026)」は、Microsoft Edge WebView2 SDKのリリースノートに、主に次の2つのセクションを追加するドキュメント更新です。
| 追加予定のセクション | 対象Runtime | 主な位置づけ | まず確認すべき人 |
|---|---|---|---|
| Prerelease SDK 1.0.4015-prerelease | Runtime 149 | 先行検証向け。実験API追加、Worker APIのPhase 2昇格、複数のRuntime修正 | 新APIを早期検証する開発者、Worker/API連携を使うチーム |
| Release SDK 1.0.3967.48 | Runtime 148 | 本番採用候補。API昇格なし、Runtime-onlyの不具合修正 | WebView2アプリを本番運用している開発者、情シス、配布担当 |
PRでは、この2つがWebView2 SDKリリースノートの新セクションとして追加予定で、Release SDK 1.0.3967.48はWebView2 Runtime 148.0.3967.48以上を要求するとされています。Prerelease SDK 1.0.4015-prereleaseは、Microsoft Edge 149.0.4015.0以降に同梱されるWebView2 Runtimeが必要です。(GitHub)
実務上の結論はシンプルです。本番環境で今すぐ注目すべきなのはRelease SDK 1.0.3967.48とRuntime 148の不具合修正、開発・検証環境で注目すべきなのはPrerelease SDK 1.0.4015-prereleaseのWorker APIとEnhanced security mode stateです。
正式公開前のPR情報として扱うべき理由
今回の情報は、MicrosoftDocs/edge-developerリポジトリのPR #3781で確認できます。PRは「Open」状態で、6件のコミットをmainブランチへマージする内容として表示されています。また、2026年5月5日のコミットとビルド確認が記録されていますが、Build statusにはwarningsも残っています。(GitHub)
そのため、開発チームでは次のように扱うのが現実的です。
| 状況 | 判断 |
|---|---|
| 仕様理解・影響調査 | PR情報を使って先行確認してよい |
| 本番導入計画 | Microsoft Learnの正式公開後に再確認する |
| NuGet更新 | 対象パッケージがNuGetで利用可能になってから実施する |
| 顧客向け告知 | PRではなく正式リリースノートを根拠にする |
| 自動アップデート検証 | Evergreen Runtimeの実機検証を優先する |
特に、Release SDK 1.0.3967.48やPrerelease SDK 1.0.4015-prereleaseというバージョン番号を使ってCI/CDや社内手順を更新する場合は、NuGetで該当パッケージが利用可能か、Microsoft Learnのリリースノートが更新済みかを確認してください。
Release SDK 1.0.3967.48で本番運用チームが見るべき変更
Release SDK 1.0.3967.48では、Phase 2からPhase 3、つまりRelease SDKで安定扱いになるAPIの追加昇格はありません。今回のRelease SDK側の中心は、Runtime-onlyの不具合修正です。具体的には、新しいバージョンのWebView2 Runtimeをインストールした後、現在使用中のRuntimeが削除され、既に起動しているアプリで新しいControllerを作成するとクラッシュする可能性がある問題が修正対象として記載されています。(GitHub)
これは、デスクトップアプリを長時間起動し続ける環境では見逃せない修正です。たとえば、次のようなアプリは確認優先度が高くなります。
| アプリの種類 | 確認したい理由 |
|---|---|
| 社内業務端末で常時起動するWPF/WinFormsアプリ | Runtime更新後もアプリを再起動せずに使い続ける可能性がある |
| WebView2を複数画面で動的に生成するアプリ | 新しいController作成タイミングで問題が出やすい |
| キオスク端末・受付端末 | 端末再起動の頻度が低く、Runtime更新の影響を受けやすい |
| 自動更新機能を持つ業務アプリ | アプリ更新とWebView2 Runtime更新のタイミングが重なりやすい |
Microsoftの配布ドキュメントでは、Evergreen Runtimeは自動更新されますが、起動中のアプリは前のRuntimeを使い続け、新しいRuntimeを使うにはWebView2環境オブジェクトの参照を解放するか、アプリを再起動する必要があると説明されています。NewBrowserVersionAvailableイベントを使って、ユーザーに再起動を促す設計も推奨されています。(Microsoft Learn)
本番環境での確認ポイント
Release SDK 1.0.3967.48を採用する場合、単にNuGetパッケージを更新して終わりにしないでください。次の順で確認すると、トラブルを減らせます。
| 手順 | 確認内容 | 合格基準 |
|---|---|---|
| Runtimeバージョン確認 | WebView2 Runtimeが148.0.3967.48以上か | 対象環境で必要バージョンを満たす |
| 長時間起動テスト | アプリ起動中にRuntime更新を想定 | 更新後も新規WebView2生成でクラッシュしない |
| 再起動導線 | NewBrowserVersionAvailable発生時の案内 | ユーザーが安全に再起動できる |
| Fixed Version利用時 | 同梱Runtimeの更新計画 | アプリ更新パッケージに反映されている |
| ログ確認 | Controller作成失敗、Runtimeロード失敗 | 例外やクラッシュが監視できる |
WebView2の新しいAPIやRuntimeを使う場合、Microsoftは最近追加されたAPIの存在確認を行うよう案内しています。Evergreen環境でも、管理者が更新を止めている場合や端末がオフラインの場合、クライアントに最新Runtimeが入っていないことがあるためです。(Microsoft Learn)
Prerelease SDK 1.0.4015-prereleaseで注目すべき新機能
Prerelease SDK 1.0.4015-prereleaseは、本番導入というより、次期APIの先行検証に使うリリースです。MicrosoftのWebView2リリースノートでは、新APIは「Experimental in Prerelease」「Stable in Prerelease」「Stable in Release」という段階で追加されます。Release SDKに入る前のAPIは、仕様や名前が変わる可能性を前提に扱う必要があります。(Microsoft Learn)
今回のPrerelease SDKで特に見るべき変更は、次の3つです。
Enhanced security mode stateの実験API追加
Prerelease SDK 1.0.4015-prereleaseでは、Enhanced security mode stateが実験APIとして追加されています。PR上のリリースノートでは、Profileクラス上のプロパティとenumとして説明され、.NET/C#ではCoreWebView2EnhancedSecurityModeStateとCoreWebView2Profile.EnhancedSecurityModeState、Win32/C++ではICoreWebView2ExperimentalProfile17やCOREWEBVIEW2_ENHANCED_SECURITY_MODE_STATEが挙げられています。(GitHub)
実務では、次のようなチームが検証対象になります。
| 対象 | 検証観点 |
|---|---|
| セキュリティ要件が強い業務アプリ | プロファイル単位での制御が既存設定と競合しないか |
| 複数プロファイルを使うWebView2アプリ | ユーザー別・用途別の設定反映が期待通りか |
| Win32/C++でCOM APIを使うチーム | Experimental API名からStable API名へ移行する可能性を考慮できているか |
| .NETアプリ | プロパティ利用前にRuntime対応を確認しているか |
注意点は、これが「Experimental APIs」です。本番コードに直書きするのではなく、検証用ブランチやフィーチャーフラグで囲み、正式Release SDKに入るまでは依存しすぎない設計にしてください。
WebView2 Worker APIsがPhase 2へ昇格
Prerelease SDK 1.0.4015-prereleaseでは、WebView2 Worker APIsがPhase 1からPhase 2、つまり「Stable in Prerelease」に昇格する内容が含まれています。対象はDedicated Workers、Shared Workers、Service Workersで、ホストアプリがWorkerの作成・破棄を監視し、PostMessageやWebMessageReceivedで通信し、登録やインスタンスを取得できるAPI群です。(GitHub)
これは、WebView2アプリを単なる「Webページ表示」から、よりアプリケーションらしいバックグラウンド処理・オフライン対応へ広げるための重要な変更です。たとえば、次のようなケースで効果が出ます。
| 活用シーン | Worker APIで確認したいこと |
|---|---|
| オフラインキャッシュを持つ業務アプリ | Service Workerの登録・アクティブ状態をホスト側で把握できるか |
| 重い処理をUIスレッドから逃がす画面 | Dedicated Workerの生成や破棄を追跡できるか |
| 複数WebView間で状態を共有する構成 | Shared WorkerのOriginやScriptUriを確認できるか |
| ホストアプリとWorkerがメッセージ連携する機能 | JSON/Stringメッセージ送受信時のエラー処理が十分か |
ただし、Phase 2はまだPrerelease SDK内での安定段階です。Release SDKで安定化する前に本番機能の中核へ組み込む場合は、API名変更や挙動変更に備えた抽象化を入れておくべきです。
Prerelease側のRuntime-only修正
Prerelease SDK 1.0.4015-prereleaseには、Runtime-onlyの修正として、UWPでの二重文字入力、Caption controlsの背景色設定API、独立したCDPセッションを持つiframeのネットワークイベント転送、Service WorkerへのPost Message呼び出し時のエラー処理、GetDefaultHostAppExeNameの文字列割り当て削減、Runtime更新後のController作成クラッシュ問題などが記載されています。(GitHub)
この中で特に検証優先度が高いのは、Service Workerとiframe/CDPを使っているアプリです。DevTools Protocol連携、ネットワーク監視、テスト自動化、埋め込みiframe内の通信を実装している場合、単なる表示確認ではなく、イベントが期待通りに流れるかをテストしてください。
Runtime 148で既に注意が必要なProcessFailedの変更
今回のMay 2026更新とは別に、Runtime 148の文脈で引き続き重要なのが、ProcessFailedイベントの理由値が細分化される変更です。現在のWebView2 SDKリリースノートでは、CoreWebView2ProcessFailedEventArgs.Reasonが従来Unexpectedとして返していたケースについて、機能フラグ有効時にNormalExit、AbnormalExit、IntegrityFailureなどの値を返すようになると説明されています。148および149ではフラグは既定で無効、150から既定で有効になる予定とされています。(Microsoft Learn)
検証用の環境変数は次の形です。
set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--enable-features=msWebView2GranularProcessFailedReason開発チームがやるべきことは、ProcessFailedのハンドラーを見直すことです。特に、次のような実装は修正候補になります。
| 実装パターン | リスク | 対応 |
|---|---|---|
Unexpectedだけを見て復旧処理を分岐している | 新しい理由値で復旧処理が走らない | default分岐を用意し、新しいenumを明示的に扱う |
| プロセス終了をすべてクラッシュ扱いしている | NormalExitまで障害扱いになる | 正常終了と異常終了を分けてログ化する |
| コード整合性エラーを通常クラッシュと同じ扱いにしている | セキュリティ原因の切り分けが遅れる | IntegrityFailureを別カテゴリで監視する |
| テストがRuntime 147以前だけ | 150以降で挙動差が出る | 148/149でフラグ有効テストを先に行う |
この変更は「今すぐ壊れる」ものではなく、150以降の既定有効化に向けた準備期間と見るべきです。WebView2を業務アプリの基盤として使っている場合は、Runtime 148/149のうちにログ設計と復旧ロジックを直しておくと安全です。
SDK更新前に確認すべきバージョンと配布方式
WebView2 SDK 148の対応で失敗しやすいのは、SDKだけを上げてRuntimeの配布状態を見落とすことです。Microsoftのドキュメントでは、WebView2の変更によってRuntime、SDK、またはその両方の更新が必要になることがあり、多くの新APIではRuntimeとSDKの両方が必要になると説明されています。(Microsoft Learn)
まず、現在の配布方式を確認してください。
| 配布方式 | 特徴 | 今回の確認ポイント |
|---|---|---|
| Evergreen Runtime | Runtimeが自動更新される。多くの本番アプリ向け | Runtime更新後の再起動導線、API存在確認、管理ポリシーの影響 |
| Fixed Version Runtime | 特定Runtimeをアプリに同梱する | 148.0.3967.48以上を同梱するか、更新時期を決める |
| Preview channel利用 | Beta/Dev/Canaryで先行検証する | Prerelease SDK 1.0.4015-prereleaseの検証に使う |
| オフライン端末 | 自動更新が期待できない | Standalone InstallerやFixed Versionの更新計画が必要 |
Evergreen Runtimeは便利ですが、全端末が常に最新とは限りません。Microsoftの配布ドキュメントでは、Runtimeの存在確認方法としてレジストリのpv値確認やGetAvailableCoreWebView2BrowserVersionString APIの利用が紹介されています。(Microsoft Learn)
PowerShellでRuntimeバージョンを確認する例
64bit WindowsでWebView2 Runtimeのバージョンを確認する場合、次のようなPowerShellを使えます。
$paths = @(
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}",
"HKCU:\Software\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}"
)
foreach ($path in $paths) {
if (Test-Path $path) {
Get-ItemProperty $path | Select-Object PSPath, pv
}
}32bit Windowsでは参照するレジストリパスが異なるため、配布対象に32bit OSが残っている場合はMicrosoftの配布ドキュメントに沿って確認してください。(Microsoft Learn)
移行・検証の優先順位
すべての変更を同じ重みで見る必要はありません。WebView2 SDK 148のRelNotes更新を受けて、まずは自社アプリがどのパターンに当てはまるかを分けてください。
| 優先度 | 対象 | やること |
|---|---|---|
| 高 | 本番でWebView2を使う長時間起動アプリ | Runtime更新後のController作成、再起動導線、クラッシュログを確認 |
| 高 | ProcessFailedを監視しているアプリ | NormalExit、AbnormalExit、IntegrityFailureを想定した分岐へ見直す |
| 中 | Service WorkerやShared Workerを使うアプリ | Prerelease環境でWorker APIのイベント・メッセージングを検証 |
| 中 | UWP、Caption controls、iframe/CDP連携を使うアプリ | Prerelease Runtime修正の影響を回帰テストする |
| 低 | WebView2で単純なページ表示のみ | Runtime 148の更新状況と基本表示テストを確認する |
特に、Worker APIは魅力的ですが、Release SDKに安定搭載される前に本番依存を強めると、将来のAPI名変更や仕様変更に追従しづらくなります。実装時は、WebView2呼び出し部分をサービスクラスやアダプターに分離し、APIが変わっても画面側のコードに影響が広がらないようにしておくと保守しやすくなります。
よくある失敗と回避策
SDKだけ更新してRuntime条件を満たしていない
WebView2 SDKのNuGetパッケージを更新しても、実行端末のRuntimeが必要バージョンを満たしていなければ、新しいAPIは使えません。Release SDK 1.0.3967.48ではRuntime 148.0.3967.48以上が必要とされているため、ビルド環境だけでなく、実行環境のRuntimeバージョンを確認してください。(GitHub)
Prerelease APIを本番コードへ直接組み込む
Enhanced security mode stateやWorker APIは、検証価値の高い変更です。ただし、Prerelease SDKのAPIは段階的に変更される可能性があります。Win32/C++ではExperimental API名からStable API名へ移ることもあるため、#ifdef、ラッパークラス、フィーチャーフラグで切り替えられる構成にしておくと安全です。
Runtime更新後の再起動をユーザー任せにする
Evergreen Runtimeは自動更新されますが、起動中アプリが新しいRuntimeを使うには再起動や環境オブジェクトの再作成が必要になる場合があります。業務アプリでは、「更新があるため再起動してください」と表示するだけでなく、入力中データの保存、画面状態の復元、再ログインの要否まで設計してください。(Microsoft Learn)
Worker APIの検証をブラウザーだけで済ませる
WebView2はMicrosoft Edgeとコードやバイナリを共有しますが、WebView2アプリではホストアプリとの連携、Runtime配布、プロファイル設定、権限処理が絡みます。Microsoftのドキュメントでも、WebView2 RuntimeはMicrosoft Edgeブラウザーと同時期にリリースされることが多く、Edge更新情報も関連すると説明されています。(Microsoft Learn)
ブラウザーで動くからWebView2でも同じ、と判断せず、WebView2ホスト内でWorker、Service Worker、メッセージング、権限、ネットワークイベントを確認してください。
開発チームが次に取るべき行動
まず、PR情報をもとに影響調査を始めます。次に、Microsoft Learnの正式なWebView2 SDKリリースノートとNuGetパッケージ公開を確認し、Release SDK 1.0.3967.48を本番検証へ回すか、Prerelease SDK 1.0.4015-prereleaseを先行検証だけに使うかを分けてください。
本番運用チームは、Runtime 148.0.3967.48以上の配布状態、Runtime更新後の再起動導線、ProcessFailedの分岐、長時間起動時の新規Controller作成を重点的に確認します。新機能を追う開発チームは、Worker APIとEnhanced security mode stateを検証環境で試し、正式Release SDKへ昇格したときにすぐ移行できるよう、実装を疎結合にしておくのが現実的です。
今回のWebView2 SDK 148のRelNotes更新は、派手な新機能追加よりも、Runtime更新時の安定性、次期Worker APIの準備、ProcessFailed変更への事前対応が重要です。正式公開後にバージョンとパッケージを確認し、まずは検証環境でRuntime更新シナリオを再現するところから始めてください。
コメント