Windows 11

Windows 11爆速化のLLP、肥大化を覆い隠すハックか

情報の灯台

2026年5月10日 07:5900

Windows K2の新機能Low Latency Profileが波紋を呼んでいる。CPUを1〜3秒だけ最大周波数に跳ね上げてUIを最大70%速く見せるこの仕組みを、Neowinは『肥大化したコードを覆い隠す手抜き』と切り捨てた。

「速さ」の正体は、CPUを瞬間的に最大化する仕掛け

Microsoftが進めるWindows K2(ウィンドウズ K2)のなかで、いま最も議論を呼んでいるのがLow Latency Profile(以下LLP)だ。Windows Centralのザック・ボウデン(Zac Bowden)氏が5月7日(米国時間)に初報を伝え、その2日後にNeowinのウサマ・ジャワド(Usama Jawad)氏がオピニオン記事「Windows 11 is getting faster the lazy way」(Windows 11は手抜きで速くなっている)で正面から批判した。論点はシンプルだが重い。Microsoftはコードを直していない。CPUを叩いているだけだ、というものだ。

LLPの仕組みを先に押さえておく。アプリの起動、スタートメニューの展開、コンテキストメニューの呼び出しといった「ユーザー操作の起点」を検知すると、OSスケジューラーがCPUを最大周波数まで瞬間的にブーストする。継続時間は1〜3秒。終わればCPUは元の省電力状態に戻る。Microsoftは「Race to Halt」(処理を素早く済ませて寝かせる)と呼ばれる古典的な手法の応用だと説明している。

ボウデン氏の取材によれば、Edge・Outlookといった内蔵アプリの起動が最大40%、スタートメニューやコンテキストメニューといったUI要素は 最大70% まで高速化するという。サードパーティ製アプリの起動も恩恵を受ける。CPUブーストはユーザーには見えず、ON/OFFのトグルもない。完全自動だ。

Low Latency Profileによる操作別の高速化率

スタートメニュー / コンテキストメニューUI要素の展開最大70%

Edge / Outlook内蔵アプリの起動最大40%

サードパーティ製アプリ起動速度に効果あり(具体数値は非公表) 非公表

※ Microsoft Insiderへの取材に基づく数値(Windows Central, 2026年5月7日)。CPUを1〜3秒だけ最大周波数までブーストすることで実現される高速化率の上限値。

機能IDは「60716524」(LowLatencyProfile)と「61391826」(LowLatencyProfileForApplicationLaunch)。Insiderの最新ビルドで、サードパーティ製ツール「ViVeTool」を使えばすでに有効化できる。Microsoftが正式にアナウンスしていない段階での非公式な操作なので、動作は保証されない。

Neowinの批判、「直すべきはCPUではなくコード」

ジャワド氏の主張は、要点を抜き出すと次のようになる。

CPUの瞬間ブーストは、最適化が不十分なソフトウェアを覆い隠すための単なるハックである。OSが「使える」と感じさせるためにプロセッサ速度を上げる必要があるなら、問題はソフト側にあって、ハード側にあるのではない。

そのうえで彼は、Microsoft自身のファーストパーティ製ソフトウェアにも最適化不足が散見されると指摘する。Windows Latestが行った実機テストでは、LLPを有効にするとスタートメニュー、ファイルエクスプローラー、Outlookの起動が劇的に速くなった。だがジャワド氏に言わせれば、これは「Microsoftが自社OSの肥大化を自社のCPUブーストでごまかしている」としか見えない。

サードパーティ開発者が最適化されたコードを書くインセンティブを、この機能はむしろ下げる、というのが彼の懸念の核心だ。OS側がCPUを叩いて辻褄を合わせてくれるなら、開発者は自分のコードを磨かなくてよくなる。古いPCは「ブースト分の余裕がない」という理由で見捨てられ、ユーザーは新しいハードウェアに買い換えるよう誘導される。最適化のコストは、最終的にユーザーの財布から支払われる。

彼はさらに、これは一夜にして起きた方針転換ではないと付け加える。Microsoftは昨年、ファイルエクスプローラーを起動時にメモリへプリロードする実装も試みていた。性能の根本原因に向き合う代わりに、ハードウェアの力技で症状を抑える。同じパターンの繰り返しではないか、と。

ただし、K2全体を見ると話は変わる

ジャワド氏の批判は鋭い。だがLLP単体を切り取って判断するのは早計でもある。LLPはWindows K2という大きな再設計プロジェクトの一部であり、その全体像はハック一辺倒ではない。

K2は2025年後半に立ち上がった社内イニシアチブで、性能・安定性・「クラフト」の3本柱を掲げている。Microsoftはこの旗のもとで、Windows 11のUI要素を片端からWinUI 3(ウィンユーアイ 3)に置き換えている。Win+Rで呼び出すRun dialog(ファイル名を指定して実行)は、C#とWinUI 3で書き直された。.NET Native AOTでコンパイルされたモダンアプリで、起動時間の中央値は 94ミリ秒 まで縮んでいる。従来版の103ミリ秒を下回る数字だ。スタートメニューも刷新中で、Microsoftは最大60%の高速化を約束している。WinUI 3向けの新しいSystem Compositorも開発が進んでおり、UI遅延とメモリ消費を削減する設計になっているという。

つまりMicrosoftは、レガシーコードの置き換えと、ハードウェアブーストによる体感改善の両方を並行して進めている。LLPは「コードを直さない代わりにCPUを叩く」というよりは、「コードの書き直しが完了するまでの体感を底上げする時限的な施策」と捉えるほうが、技術的には正確に近い。

事実、AndroidのUIスケジューラーも同じような瞬間ブースト戦略を採用している。Nintendo Switchも2019年のファームウェア8.0.0で、ロード画面中だけCPUを1.020GHzから1.75GHzへ引き上げる「ブーストモード」を導入した。短時間のクロック引き上げでロード時間を縮める手法は、業界では珍しくも何ともない常套手段だ。

Windows K2の主要施策とアプローチ分類

施策	アプローチ	主な効果
Run dialog刷新	コードの構造改善	起動の中央値 94ミリ秒 (従来103ミリ秒)
スタートメニュー刷新	コードの構造改善	最大60% 高速化を約束
System Compositor新設	コードの構造改善	UI遅延とメモリ消費の削減
Low Latency Profile	ハードウェアブースト	UI操作最大70% アプリ起動最大40%

※ Microsoft K2は2025年後半に立ち上がった社内イニシアチブ。施策はコードの書き直しによる構造改善と、CPUの瞬間ブーストによる体感改善の二系統で進行している。

それでも、批判が消えない理由

Microsoftの取り組みが多面的だとしても、ジャワド氏の指摘の重さは消えない。

問題は、LLPが直さず隠す機能だという点にある。Run dialogが94ミリ秒で開くようになったのは、コードを書き直したからだ。スタートメニューが60%速くなる予定なのも、WinUI 3への移行と新しいCompositorによる改善が効いているからだ。これらは構造的な手当てであり、ハードウェアの恩恵を受けないユーザーにも届く。

LLPは違う。古いCPUや、すでに常時ターボで動いているデスクトップPCでは、効果が薄い。恩恵を受けるのは、節電のためにクロックを下げているノートPC利用者で、しかも「人間が体感できる短時間」だけだ。HotHardwareの記者が指摘した通り、「最高のソフトウェアは、CPUを瞬間的に最大化する必要のないソフトウェアだ」という見方は、技術的にも正当性がある。

ノートPCのバッテリー寿命への影響について「軽微」と説明されているとはいえ、長期的にどう響くかはまだ未知数だ。古い冷却システムを抱えたノートPCで、頻繁にCPUがピークに達する状況が続けば、サーマルスロットリングの頻度が上がる可能性は否定できない。Neowinのコメント欄でも、この点を懸念する声が上がっていた。

これはバッテリー寿命に響く。AIがコードを吐いた粗悪品でないことを願う。 ── pickytech氏

別のユーザーも「Windowsノートはすでにバッテリー寿命でMacBookに劣っている。LLPが差を縮めることはなさそうだ」と応じている。

「症状を抑える薬」と「病気を治す手術」

LLPが症状を抑える鎮痛剤だとすれば、WinUI 3への移行と新Compositorは外科手術だ。両方が必要な患者もいれば、手術が終わるまでの間だけ薬で凌ぐ患者もいる。Microsoftが進めているのは、おそらくこの両方を並行する治療だと考えていいだろう。

問題は、ユーザーから見て「いま自分が受け取っているのはどっちなのか」がわからないことにある。LLPは自動でバックグラウンド動作し、トグルもない。ジャワド氏が苛立っているのは、おそらくここだろう。Microsoftは「速くなりました」と言うが、その速さが構造改善由来なのかCPUブースト由来なのか、ユーザーには判別できない。

Neowinのコメント欄では、論点が鮮明に割れていた。