WebView2のタイトルバーボタンがちらつく原因と修正方法｜Runtime 152へ更新

WebView2でカスタムタイトルバーを実装した際、右上の最小化・最大化・閉じるボタンが一瞬消えたり、マウスを重ねるたびにちらついたりすることがあります。この症状がWindow Controls Overlayのボタン部分に限られる場合、アプリ側のCSSや再描画処理ではなく、WebView2 Runtimeの不具合である可能性があります。

Microsoftは、2026年8月3日に公開したPreview Runtime 152.0.4181.0で、Window Controls OverlayのMin／Max／Closeボタンがちらつく問題を修正したと明記しています。まず実際に使用されているWebView2 Runtimeのバージョンを確認し、本番環境ではStable版の152.0.4191.53以降、またはそれより新しいRuntimeへ更新してください。(Microsoft Learn)

WebView2のウィンドウ操作ボタンがちらつく問題を修正

今回の修正対象は、Window Controls Overlayを使ってカスタムタイトルバーを表示しているWebView2アプリです。

典型的には、次のような症状が発生します。

最小化・最大化・閉じるボタンが一瞬消える
マウスポインターをボタン上へ移動すると表示が点滅する
最大化と元のサイズを切り替えた直後にボタンがちらつく
ダークテーマでボタンのアイコンが不安定に表示される
Webコンテンツは正常だが、右上のウィンドウ操作ボタンだけが乱れる

Microsoftのリリースノートでは、Preview Runtime 152.0.4181.0の修正項目として、Min／Max／Closeボタンのちらつき修正が掲載されています。同じリリースでは、暗いWindow Controls Overlay背景でキャプションボタンのアイコンが見えなくなる問題も修正されています。(Microsoft Learn)

修正対象となるバージョン

項目	内容
問題が発生する機能	Window Controls Overlayを利用したカスタムタイトルバー
主な症状	Min／Max／Closeボタンのちらつき
修正が明記されたRuntime	Preview Runtime 152.0.4181.0
公開日	2026年8月3日
対応するPrerelease SDK	1.0.4181-prerelease
本番環境の更新目安	Stable Runtime 152.0.4191.53以降、または最新のStable版

152.0.4181.0は早期テスト向けのPreview Runtimeです。そのため、本番端末へPreview版を一律導入するのではなく、修正を取り込んだ後続のStable版を利用するのが基本です。

Microsoft Edge Stable 152.0.4191.53は2026年8月27日に公開されています。WebView2 Evergreen RuntimeにはMicrosoft Edge Stable相当の更新が配信されるため、本番環境では152.0.4191.53以降を一つの判断基準にできます。(Microsoft Learn)

最初に実行中のWebView2 Runtimeを確認する

トラブル対応で最も多い失敗は、NuGetパッケージのバージョンだけを確認し、実際に動作しているWebView2 Runtimeのバージョンを確認しないことです。

WebView2には、大きく分けて次の要素があります。

要素	役割	今回の修正との関係
WebView2 SDK	C#やC++から利用するAPI、型定義、ローダー	SDK更新だけではRuntimeが切り替わらない
WebView2 Runtime	Chromiumベースの描画・実行エンジン	今回のちらつき修正が含まれる部分
Microsoft Edgeブラウザー	通常のWebブラウザー	本番WebView2アプリの実行基盤として直接使用しない
Fixed Version Runtime	アプリに同梱する特定バージョン	開発者が手動で差し替える必要がある

今回の問題はRuntimeのリリースノートに修正内容が掲載されています。そのため、第一に確認すべきなのはMicrosoft.Web.WebView2パッケージのバージョンではなく、アプリが実際に使用しているRuntimeのバージョンです。

C#で実際に使用中のRuntimeを確認する

WPFまたはWindows Formsでは、WebView2の初期化後にBrowserVersionStringを取得できます。

await webView2.EnsureCoreWebView2Async();

string runtimeVersion =
    webView2.CoreWebView2.Environment.BrowserVersionString;

System.Diagnostics.Debug.WriteLine(
    $"WebView2 Runtime: {runtimeVersion}");

ここで表示された値が、現在のWebView2環境で実際に使用されているバージョンです。

修正後の本番環境であれば、例えば次のような値が表示されます。

WebView2 Runtime: 152.0.4191.53

CoreWebView2Environment.GetAvailableBrowserVersionString()を使えば、WebView2を初期化する前に利用可能なRuntimeを確認することもできます。

using Microsoft.Web.WebView2.Core;

string version =
    CoreWebView2Environment.GetAvailableBrowserVersionString();

System.Diagnostics.Debug.WriteLine(
    $"Available WebView2 Runtime: {version}");

ただし、環境変数やBrowserExecutableFolderでFixed Versionやプレビューチャネルを指定している場合があります。最終的には、初期化後のEnvironment.BrowserVersionStringを確認する方が確実です。(Microsoft Learn)

PowerShellでEvergreen Runtimeを確認する

Evergreen Runtimeを使用している端末では、レジストリのpv値からインストール済みバージョンを確認できます。

$runtimeId = '{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}'

$registryPaths = @(
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\$runtimeId",
    "HKLM:\SOFTWARE\Microsoft\EdgeUpdate\Clients\$runtimeId",
    "HKCU:\Software\Microsoft\EdgeUpdate\Clients\$runtimeId"
)

foreach ($path in $registryPaths) {
    $runtime = Get-ItemProperty -Path $path -ErrorAction SilentlyContinue

    if ($null -ne $runtime -and $runtime.pv) {
        [PSCustomObject]@{
            RegistryPath = $path
            Version      = $runtime.pv
        }
    }
}

64ビットWindowsの端末では、通常はWOW6432Node側に登録されています。ユーザー単位でインストールされている場合は、HKEY_CURRENT_USER側に記録されます。(Microsoft Learn)

Fixed Version Runtimeはこのレジストリに登録されません。Fixed Versionを利用しているアプリでは、アプリ側のバージョン出力やBrowserExecutableFolderの設定を確認してください。

Evergreen Runtimeを152以降へ更新する方法

Evergreen Runtimeは通常、自動的に更新されます。ただし、端末が長期間オフラインだった場合や、組織の更新ポリシー、プロキシ、セキュリティ製品などによって更新が止まっている場合があります。

オンライン端末で更新する

オンライン端末では、Microsoftが提供するEvergreen Bootstrapperを使用できます。

実施手順は次のとおりです。

WebView2を使用しているアプリをすべて終了する
現在のRuntimeバージョンを記録する
Microsoft公式のEvergreen Bootstrapperを実行する
アプリを再起動する
BrowserVersionStringで更新後のバージョンを確認する
Min／Max／Closeボタンの表示を再テストする

無人インストールやアプリのセットアップ処理から実行する場合は、次のコマンドを使用できます。

MicrosoftEdgeWebview2Setup.exe /silent /install

管理者権限で実行するとコンピューター単位、通常権限で実行するとユーザー単位のインストールになります。Bootstrapperは端末のアーキテクチャを判定し、適切なRuntimeをダウンロードします。(Microsoft Learn)

オフライン端末で更新する

インターネットに接続できない端末では、Evergreen Standalone Installerを使用します。

x64版のインストーラーを無人実行する例は次のとおりです。

MicrosoftEdgeWebView2RuntimeInstallerX64.exe /silent /install

端末に合わせて、x86、x64、ARM64のインストーラーを選択してください。

インストーラーをアプリの配布パッケージへ含める場合は、次の流れにすると管理しやすくなります。

セットアップ開始時にRuntimeの有無とバージョンを確認する
必要なバージョンより古い場合にインストーラーを実行する
インストール後にアプリを起動する
アプリのログへ実行中のRuntimeバージョンを出力する

Evergreen RuntimeのBootstrapperとStandalone Installerは、Microsoft公式のWebView2ダウンロードページから入手できます。(Microsoft Developer)

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

Evergreen Runtimeの更新ファイルが端末へ配信されても、起動中のWebView2アプリはそのまま古いRuntimeを使用し続けます。

新しいRuntimeへ切り替えるには、以前のCoreWebView2Environmentへの参照をすべて解放するか、アプリを再起動する必要があります。単に画面を閉じて開き直すだけでは、同じWebView2環境が再利用されることがあります。(Microsoft Learn)

更新直後は、タスクマネージャーで対象アプリと配下のmsedgewebview2.exeが終了していることを確認してから、アプリを起動し直してください。

Fixed Version Runtimeを使用している場合の修正方法

Fixed Version Runtimeは、アプリと一緒に特定バージョンのWebView2 Runtimeを配布する方式です。端末に新しいEvergreen Runtimeをインストールしても、アプリがFixed Versionを明示していれば、そちらは使用されません。

この場合は、アプリに同梱しているRuntime自体を更新する必要があります。

Fixed Versionの更新手順

現在使用しているFixed Versionのフォルダーを確認する
152系以降のFixed Version Runtimeを取得する
パッケージを正しいフォルダー構成で展開する
アプリの配布物に新しいRuntimeを含める
BrowserExecutableFolderを新しいフォルダーへ変更する
テスト環境で動作確認する
アプリを再ビルドまたは再配布する

.NETでは、次のようにRuntimeのフォルダーを指定しているケースがあります。

using Microsoft.Web.WebView2.Core;

string runtimeFolder =
    Path.Combine(
        AppContext.BaseDirectory,
        "FixedRuntime",
        "152.0.4191.53");

CoreWebView2Environment environment =
    await CoreWebView2Environment.CreateAsync(
        browserExecutableFolder: runtimeFolder);

await webView2.EnsureCoreWebView2Async(environment);

古いRuntimeフォルダーを残したまま、新しいRuntimeを追加しただけでは切り替わりません。BrowserExecutableFolder、CreationProperties、環境変数WEBVIEW2_BROWSER_EXECUTABLE_FOLDERのいずれかが、古いパスを指していないか確認してください。

Microsoftは、Fixed Versionのパッケージをエクスプローラーで展開すると正しいフォルダー構造にならない場合があるため、expandコマンドまたは対応する展開ツールの利用を案内しています。(Microsoft Learn)

SDKだけを更新しても直らない場合がある

WebView2 SDKとWebView2 Runtimeは別のコンポーネントです。

Visual StudioのNuGetパッケージマネージャーで、次のパッケージを更新しただけでは、端末上のRuntimeが更新されるとは限りません。

Microsoft.Web.WebView2

SDKは主に、アプリからWebView2を操作するためのAPIやライブラリを提供します。一方、ウィンドウ操作ボタンの描画やWindow Controls Overlayの内部処理はRuntime側で実行されます。

今回のちらつきに対する直接の修正はRuntimeのリリースノートへ掲載されているため、対応の優先順位は次のようになります。

優先順位	対応
1	実際に使用中のRuntimeバージョンを確認する
2	Runtimeを修正済みの152系以降へ更新する
3	アプリを完全に再起動する
4	修正後のRuntimeで再現テストする
5	新しいAPIが必要な場合のみSDK更新を検討する

SDK 1.0.4181-prereleaseはRuntime 152向けのPrerelease SDKですが、既存APIを使ったアプリで今回のRuntime不具合だけを解消するために、Prerelease SDKへの変更が必須とは限りません。Preview SDKを使用する場合は、Beta、Dev、Canaryなどのプレビューチャネルと組み合わせて事前検証を行います。(Microsoft Learn)

更新後に確認するテスト項目

Runtimeを更新した後は、単にアプリを起動できるかだけではなく、Window Controls Overlayに関係する操作をまとめて確認します。

テスト項目	確認内容
Runtimeバージョン	152.0.4191.53以降になっているか
マウスホバー	Min／Max／Close上で表示が点滅しないか
最大化と復元	状態切り替え直後にボタンが消えないか
最小化と復帰	タスクバーから戻した後も正常か
ウィンドウサイズ変更	ボタン位置や背景がずれないか
ダーク／ライトテーマ	アイコンが背景へ埋もれないか
DPI変更	100％、125％、150％などで正常か
マルチモニター	DPIの異なる画面間を移動しても正常か
リモート接続	リモートデスクトップ環境でも再現しないか
アプリ再起動	更新後のRuntimeが実際に読み込まれているか

特に、ノートPCと外部モニターで拡大率が異なる環境では、ウィンドウをモニター間で移動した際の表示も確認してください。

Runtime更新後もちらつく場合の切り分け

152系以降へ更新しても症状が残る場合は、Microsoftが修正したRuntime側の問題とは別の原因を疑います。

実際には古いRuntimeが使われている

最初に、アプリのログへ出力したBrowserVersionStringを再確認します。

次のような状態では、更新済みのつもりでも古いRuntimeが使用されます。

Fixed Versionのパスが古いまま
アプリを完全に終了していない
常駐プロセスがWebView2環境を保持している
環境変数で別のRuntimeが指定されている
テスト用のBeta、Dev、Canaryチャネルへ切り替わっている
ユーザー単位とコンピューター単位のRuntimeが混在している

インストール済みバージョンではなく、アプリが実際に使用しているバージョンを基準に判断してください。

タイトルバー全体がちらつく

Microsoftが修正した問題は、主にWindow Controls OverlayのMin／Max／Closeボタンに関するものです。

右上のボタンだけではなく、ロゴ、タイトル文字、背景などカスタムタイトルバー全体がちらつく場合は、アプリ側の再描画処理を確認します。

主な確認ポイントは次のとおりです。

タイトルバーに不要なCSSトランジションが設定されていないか
geometrychangeイベント内でレイアウトを繰り返し変更していないか
ResizeObserverとスタイル変更が相互に呼び出されていないか
テーマ切り替え処理が短時間に何度も実行されていないか
ウィンドウサイズ変更のたびにWebView2を再生成していないか
ネイティブ側でSetWindowPosなどを過剰に呼び出していないか
Window Controls Overlayの領域へ独自ボタンや透明要素を重ねていないか

切り分けでは、タイトルバーのCSSアニメーションを一時的にすべて無効化し、Window Controls Overlayを使わない通常のタイトルバーへ戻して比較すると原因を特定しやすくなります。

Preview版を本番へ固定しない

不具合修正を急ぐために、CanaryやDevチャネルを本番端末へ固定する方法は避けた方が安全です。

プレビューチャネルは、将来のRuntimeに対する互換性テストや早期検証を目的としています。Microsoftも、Beta、Dev、Canaryを利用した事前テストを推奨していますが、本番環境の実行基盤にはWebView2 Runtimeを使用するよう案内しています。(Microsoft Learn)

本番では最新のStable Runtimeを利用し、プレビュー版は開発端末や検証端末に限定してください。

WebView2のタイトルバーボタンちらつき対応まとめ

WebView2のカスタムタイトルバーでMin／Max／Closeボタンがちらつく問題は、MicrosoftによってRuntime 152で修正されています。

対応では、次の順序が重要です。

BrowserVersionStringで実行中のRuntimeを確認する
本番環境をStable Runtime 152.0.4191.53以降へ更新する
WebView2を使用するアプリと関連プロセスを完全に終了する
アプリを再起動してRuntimeバージョンを再確認する
ホバー、最大化、DPI変更、マルチモニター環境で再テストする
症状が残る場合はFixed Versionの指定やアプリ側の再描画処理を調査する

右上のウィンドウ操作ボタンだけがちらつく場合、CSSを大幅に書き換える前にRuntimeを更新することが最も効率的です。一方、タイトルバー全体が点滅する場合は、Runtime更新と並行してCSS、geometrychange、ウィンドウサイズ変更処理を切り分けてください。

この記事を書いた人

佐藤健司

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

WebView2のタイトルバーボタンがちらつく原因と修正方法｜Runtime 152へ更新

WebView2のウィンドウ操作ボタンがちらつく問題を修正

修正対象となるバージョン

最初に実行中のWebView2 Runtimeを確認する

C#で実際に使用中のRuntimeを確認する

PowerShellでEvergreen Runtimeを確認する

Evergreen Runtimeを152以降へ更新する方法

オンライン端末で更新する

オフライン端末で更新する

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

Fixed Version Runtimeを使用している場合の修正方法

Fixed Versionの更新手順

SDKだけを更新しても直らない場合がある

更新後に確認するテスト項目

Runtime更新後もちらつく場合の切り分け

実際には古いRuntimeが使われている

タイトルバー全体がちらつく

Preview版を本番へ固定しない

WebView2のタイトルバーボタンちらつき対応まとめ

この記事を書いた人

コメント

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

WebView2のタイトルバーボタンがちらつく原因と修正方法｜Runtime 152へ更新

WebView2のウィンドウ操作ボタンがちらつく問題を修正

修正対象となるバージョン

最初に実行中のWebView2 Runtimeを確認する

C#で実際に使用中のRuntimeを確認する

PowerShellでEvergreen Runtimeを確認する

Evergreen Runtimeを152以降へ更新する方法

オンライン端末で更新する

オフライン端末で更新する

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

Fixed Version Runtimeを使用している場合の修正方法

Fixed Versionの更新手順

SDKだけを更新しても直らない場合がある

更新後に確認するテスト項目

Runtime更新後もちらつく場合の切り分け

実際には古いRuntimeが使われている

タイトルバー全体がちらつく

Preview版を本番へ固定しない

WebView2のタイトルバーボタンちらつき対応まとめ

この記事を書いた人

関連記事

コメント

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

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