Microsoft

WinUI 3が高速化、Windows 11応答性向上へ

情報の灯台

2026年5月13日 22:4800

Windows 11のネイティブUIフレームワーク「WinUI 3」が、エクスプローラー起動時のパフォーマンス指標で大幅な改善を達成した。MicrosoftはWindows全体をWinUI 3へ寄せると同時に、フレームワーク自体も底上げしている。

エクスプローラー起動で示された4つの数値

Microsoftのソフトウェアエンジニアであるベス・パン（Beth Pan）が、GitHub上のWinUIリポジトリで進行中の最適化作業の成果を公開した。エクスプローラーの起動処理におけるWinUI部分について、メモリ確保回数が41%減、一時的なメモリ確保が63%減、関数呼び出しが45%減、WinUIコード内で費やす時間が25%短縮したという。

ここで挙げられているのはあくまで「フレームワーク内部の処理量」であり、起動時間そのものの短縮率ではない点に注意が必要だ。実際、GitHubのコメント欄ではユーザーのbogdan-patraucean氏が「起動時間自体への影響はどの程度か。まさか40%短縮ではないだろう」と早々に質問しており、パン氏も具体的な体感時間の数字には触れていない。

数字の改善は確かだが、ユーザーが「速くなった」と感じるかどうかは別の話だ。フレームワーク内部の改善は、その上で動くアプリ全体の挙動にどう波及するかで価値が決まる。

WinUI 3最適化:エクスプローラー起動処理の4指標

メモリ確保回数 41%減

一時的メモリ確保 63%減

関数呼び出し 45%減

WinUIコード内処理時間 25%短縮

※ フレームワーク内部の処理量の改善率であり、ユーザーが体感する起動時間そのものの短縮率ではない。

WinUI 3はWindows 11復権の二本柱の一つ

今回の発表は、Windows+Devices部門社長のパヴァン・ダヴルリ（Pavan Davuluri）氏が3月20日に公開したブログ記事「Our commitment to Windows quality」と一直線でつながっている。同氏はそこで、「より流動的で応答性の高いアプリ操作。Windowsのコア機能をWinUI 3フレームワークへ移行することで操作遅延を削減する」と明言していた。

つまり戦略は二段構えになっている。Windowsのコア部分(スタートメニュー、ファイル操作、設定など)をWinUI 3へ寄せること。そして、その受け皿となるWinUI 3自体を速くすること。今回の数値はその二本目に当たる。

このアプローチは、フレームワーク側でできることをやり、同時にWindowsの他チームも全体的な起動性能の改善に取り組んでいる。私たちは頻繁に連携し、改善が端から端まで届くようにしている。これは基礎と品質に対する長期的なコミットメントだ。

パン氏自身のコメントだ。「フレームワーク側でやれることはやる」「他チームと頻繁に連携」という言い回しは、裏返せば、これまでWindowsの各部門がバラバラに動いてきたことの自認でもある。

開発者コミュニティの反応は両論

GitHubのディスカッションには33件の返信が寄せられ、ユーザーの感想は真っ二つに分かれた。「WinUI 3を使い続ける判断を裏付けてくれる動き」と歓迎するduckheadsoftware氏のような声がある一方で、より厳しい指摘も並ぶ。

ekalchev氏はXamlBenchmarkプロジェクトを引いて、客観的なベンチマークでは「WinUI 3は今もWPFやUWPより測定可能なほど遅い」と指摘した。20年以上前のWPFにも性能で負けている現役の「ネイティブ」フレームワーク。これは尋常ではない、というわけだ。

Tiktack氏は、シンプルなWinUIアプリでもメモリ消費が50MBを超え、画面遷移のたびにメモリリークが発生し、ウィンドウのリサイズも事実上壊れていると述べる。「ネイティブフレームワーク」を名乗るには、起動時間以前の問題が積み上がっている。

torum氏の指摘はさらに本質的だった。

起動時間はAoT(事前コンパイル)を有効にすれば十分速い。むしろWinAppSDK・CsWinRT・BuildToolsに残る未解決バグの方が問題だ。優先順位は「起動時間」より、他の課題にあるはずだ。

最適化の優先順位として「起動時間」を選ぶことそのものへの疑問。フレームワーク内部の数値改善が、開発現場の痛みの本丸ではないという指摘だ。

「100% WinUI」の理想と現実のギャップ

議論はやがて、WinUI個別の問題から「Microsoftがそもそも自社のフレームワークを使っていない」という構造問題へと広がった。

MAUIチームはマップコントロールをWebView2の上に作らざるをえなかった。今日までネイティブのUWPマップが移植されていないからだ。

pjmlp氏のコメントは、WinUIの周辺ですら「ネイティブ」が成立していない実情を示している。WinUIマップコントロールもWebView2の薄いラッパーに過ぎず、オフラインマップも使えない、とnikolayvpavlov氏が補足した。

元Microsoft社員と名乗るelucidsoft氏の指摘はさらに重い。「ここで本当にやるべきは、Windows OOBE(初期セットアップ)を含めて社内のあらゆるものを自社フレームワークで書き直すこと。社内にいた頃、これが最も歯がゆかった。チームごとに独自路線だった」。

組織として一貫した技術選定をしてこなかったツケが、今のWindows 11のちぐはぐな操作感に表れている。ファイル操作で「白とび」が頻発するエクスプローラー、Webアプリで実装された通知センターのカレンダー、UWPのままのストアアプリと設定アプリ。「ネイティブ」という言葉が指すものが、Windowsの中ですら統一されていない。

Windows主要部分のUI実装フレームワーク現況

構成要素	WinUI 3	UWP	WebView2
エクスプローラー(一部)	●	—	—
スタートメニュー	移行中	●	—
設定アプリ	—	●	—
ストアアプリ	—	●	—
通知センターのカレンダー	—	—	●
マップコントロール(WinUI付属)	ラッパー	—	●

※ ●は実装済み、移行中はスタートメニューのWinUI 3再構築、ラッパーはWebView2を内包するWinUIコントロール。「100%ネイティブ」を掲げる一方、現状は3つのフレームワークが混在している。

数字の先にある期待と懸念

今回の最適化は近く開発ブランチを離れ、winui3/mainブランチに反映される。可能な範囲でWinAppSDK 2.xにも取り込まれる予定だ。ただし一部の最適化は破壊的変更を伴うため、当面は開発者がオプトイン(個別有効化)で取り込む形になる。例えばコントロールのデフォルトスタイル最適化は、テンプレート内の特定要素を直接参照しているアプリや、Setterではなくアニメーションでプロパティを設定しているアプリで挙動が変わる可能性がある。

WinUI 3が「3.0」ないし「4.0+」に到達する頃には、これらの最適化はオプトアウト方式(デフォルトで有効)に切り替わる見込みだという。最良のパフォーマンスがデフォルトになる日は、まだしばらく先だ。

並行して、Windows 11では「低遅延プロファイル(Low Latency Profile)」の検証も進んでいる。高優先度の操作を検知した瞬間、CPUクロックを1〜3秒間だけ最大付近まで引き上げる仕組みだ。Microsoftの内部情報源によれば、Edge・Outlookなど標準アプリの起動時間が最大約40%短縮、スタートメニューやコンテキストメニューの表示が最大70%短縮されるという。

フレームワーク内部の効率化、Windowsコア機能のWinUI 3移行、CPUブーストによる体感改善。Microsoftは複数のレイヤーで同時に手を入れている。それでも、20年前のWPFに性能で負けているとの指摘や、WinUIアプリのウィンドウをリサイズすると地が透けて見えるとの報告が、地道に積み重なってきた失望を物語っている。

「飛躍」を名乗るには、数字以上のものが要る。ユーザーがエクスプローラーを開いたとき、メニューを右クリックしたとき、ウィンドウの端をつかんで引っ張ったとき。その瞬間に「あ、変わった」と感じられるかどうか。Microsoftが本当に乗り越えなければならないのは、登頂困難で知られるK2のような開発組織の文化そのものなのかもしれない。

参照元