Windows 11 の LowLatencyProfile とは？仕組みと有効・無効を確認する専用ツールを公開

Windows 11 には、スタートメニューや検索、アクションセンター、アプリの起動など、操作直後の応答性を改善するための新しい性能制御が導入されています。

Microsoft は、この改善について、よく利用される OS 機能やアプリ起動時に性能と電力の制御を一時的に調整し、スタートメニュー、検索、アクションセンターなどの処理を高速化するものと説明しています。

ただし、すべてのアプリ起動や Windows シェル操作で、一律に LowLatencyProfile が要求されるわけではありません。

今回、WinDbg を使用して Windows の実際の動作を追跡したところ、スタートメニュー、Windows 検索、通知センターの表示や、スタートメニュー、検索結果、タスクバーからアプリを起動する際に LowLatencyProfile が要求されることを確認しました。

一方、エクスプローラーのウィンドウを開く操作や、ファイルのダブルクリックなどでは、今回の検証では要求を確認できませんでした。

Windows 11 の内部では、この仕組みに関連する機能として、次の名前が確認できます。

LowLatencyProfile

しかし、LowLatencyProfile には通常の Windows 設定画面がなく、タスクマネージャーを見ても有効かどうかは判断できません。

ViVeTool で関連する Feature ID を確認する方法もありますが、それだけでは LowLatencyProfile が Windows 内部で実際に有効かどうかを判断できない場合があります。

そこで本記事では、Windows 11 のシステムファイルを解析し、LowLatencyProfile の内部処理を調査しました。

その結果、ViVeTool の設定値ではなく、Windows カーネル側が実際に行う Feature 判定を利用して、LowLatencyProfile が有効かどうかを確認できることが分かりました。

この仕組みを利用した専用ツール「LowLatencyProfile 確認ツール」も公開します。

本記事の解析および動作確認は、Windows 11 ビルド 26200.8655および26200.8737で行っています。

LowLatencyProfile が有効かどうかだけ確認したい方は、こちらから確認ツールの使い方へ進めます。

LowLatencyProfile 確認ツールの使い方へ進む

LowLatencyProfile とは

LowLatencyProfile は、特定の操作が行われたときに、一時的に応答性を重視した性能制御を要求するための Windows 内部機能です。

Microsoft は、主に次のような処理を対象として説明しています。

• アプリの起動
• スタートメニューの表示
• Windows 検索
• アクションセンター
• Windows シェルの主要操作

さらに今回、WinDbg を使用して Windows の各プロセスを監視し、実際にどの操作で NtUserRequestLowLatencyProfile が呼び出されるのかを確認しました。

その結果、次の操作で LowLatencyProfile の要求を確認できました。

操作	LowLatencyProfile の要求
スタートメニューを開く	確認できた
タスクバーの検索を開く	確認できた
通知センターを開く	確認できた
スタートメニューからアプリを起動する	確認できた
Windows 検索の結果からアプリを起動する	確認できた
タスクバーのピン留めアプリを起動する	確認できた
エクスプローラーのウィンドウを開く	確認できず
.txt ファイルをダブルクリックしてアプリを起動する	確認できず
右クリックメニューからアプリを起動する	確認できず
エクスプローラーのアドレスバーからアプリを起動する	確認できず

なお、各操作で LowLatencyProfile が要求される際の詳しい呼び出し経路については、後半の「WinDbg で LowLatencyProfile が実際に要求される操作を追跡」で解説しています。

「確認できず」は、その操作で LowLatencyProfile が絶対に使用されないことを意味するものではありません。

今回監視した Windows 11 のビルドと操作方法では、NtUserRequestLowLatencyProfile の呼び出しを確認できなかったという意味です。

この結果から、LowLatencyProfile は、すべてのアプリ起動や Windows シェル操作で自動的に要求される機能ではないことが分かります。

Windows の特定のシェル操作では、シェルコンポーネントから LowLatencyProfile が明示的に要求されます。

LowLatencyProfile という名前だけを見ると、CPU を常に最大クロックで動作させる機能のようにも見えますが、そのような単純な仕組みではありません。

目的は、CPU を常時高速化することではなく、操作直後の遅延を小さくし、必要な処理を短時間で完了させることだと考えられます。

そのため、LowLatencyProfile が有効でも、タスクマネージャーの CPU 速度が常に最大値になるわけではありません。

LowLatencyProfile はすべてのプロセスで使用できるわけではない

LowLatencyProfile は、一般のアプリケーションが自由に利用できる機能ではないようです。

Windows の内部処理を調査したところ、LowLatencyProfile の要求を受け取ると、最初に機能そのものが有効かどうかを確認し、その後、要求元のプロセスが必要な条件を満たしているかを確認する処理が行われていました。

処理の流れを簡単に表すと、次のようになります。

LowLatencyProfile の要求
        ↓
LowLatencyProfile が有効か確認
        ↓
    ┌───┴───┐
    │           │
   無効        有効
    │           │
エラー 50    プロセスの条件を確認
                │
            条件を満たさない
                │
             エラー 5

この仕組みが、今回作成した確認ツールで LowLatencyProfile の有効・無効を判定する重要なポイントになります。

LowLatencyProfile の内部処理を調査

LowLatencyProfile がどのように動作しているのかを確認するため、Windows 11 のシステムファイルを調査しました。

その結果、win32u.dll に次の関数が存在することを確認しました。

NtUserRequestLowLatencyProfile

この関数からシステムコールを通じてカーネル側の処理が呼び出され、最終的に win32kfull.sys 内で LowLatencyProfile の状態確認や要求の処理が行われます。

大まかな流れは次のとおりです。

Windows のコンポーネント
        ↓
user32.dll
        ↓
win32u.dll
        ↓
NtUserRequestLowLatencyProfile
        ↓
システムコール
        ↓
win32kfull.sys
        ↓
LowLatencyProfile が有効か確認
        ↓
要求元のプロセスを確認
        ↓
条件を満たす場合は LowLatencyProfile を要求

ここで特に重要なのは、カーネル側の処理の最初に LowLatencyProfile が有効かどうかを確認していることです。

LowLatencyProfile が無効な場合はエラー 50 が返る

調査した Windows 11 ビルドでは、LowLatencyProfile が無効と判定された場合、それ以上の処理には進まず、次のエラーが返されます。

戻り値       = 0
GetLastError = 50

エラー 50 は、Windows では次の意味を持ちます。

ERROR_NOT_SUPPORTED

つまり、「この要求はサポートされていない」という意味です。

LowLatencyProfile が無効な状態では、プロセスの条件確認など、その後の処理へは進みません。

LowLatencyProfile が有効な場合は次の判定へ進む

LowLatencyProfile が有効と判定された場合は、そこで処理が終了せず、要求元のプロセスが LowLatencyProfile を使用するための条件を満たしているか確認されます。

通常の AutoIt プロセスから確認した場合、この条件を満たさないため、次の結果になりました。

戻り値       = 0
GetLastError = 5

エラー 5 は次の意味です。

ERROR_ACCESS_DENIED

一見すると、「アクセスが拒否されたのだから確認に失敗した」と思うかもしれません。

しかし、今回の確認では、このエラー 5 が重要な意味を持ちます。

なぜなら、LowLatencyProfile が無効なら、その前の段階でエラー 50 を返して処理が終了するからです。

エラー 5 が返ったということは、少なくとも LowLatencyProfile の有効判定を通過し、その次のプロセス条件の確認まで処理が進んだことを示しています。

この違いを利用すれば、LowLatencyProfile が Windows 内部で有効と判定されているかどうかを確認できます。

エラー 5 とエラー 50 の違いを利用して状態を確認

今回の確認方法をまとめると、次のようになります。

戻り値	GetLastError	確認結果
0	5	LowLatencyProfile の有効判定を通過
0	50	LowLatencyProfile の有効判定を通過していない
その他	その他	判定不能

重要なのは、ViVeTool の設定値を読み取っているわけではないという点です。

Windows 内部の NtUserRequestLowLatencyProfile を実際に呼び出し、カーネル側の処理がどこまで進んだかを、返された結果から判断しています。

実際に有効・無効を切り替えて検証

この判定方法が本当に機能するのかを確認するため、LowLatencyProfile に関係するとされていた Feature ID 58989092 の状態を変更し、実際の戻り値を比較しました。

Feature ID 58989092 が無効の場合

結果は次のとおりです。

戻り値       = 0
GetLastError = 50

LowLatencyProfile の有効判定を通過せず、ERROR_NOT_SUPPORTED が返されました。

Feature ID 58989092 が有効の場合

結果は次のように変化しました。

戻り値       = 0
GetLastError = 5

今度は LowLatencyProfile の有効判定を通過し、その後のプロセス条件の確認まで処理が進んだことになります。

実際の変化をまとめると、次のとおりです。

58989092 無効
        ↓
GetLastError = 50

58989092 有効
        ↓
GetLastError = 5

有効と無効を切り替えることで、実際に返される結果が変化することを確認できました。

58989092 は LowLatencyProfile 本体の Feature ID ではない

ここで少し複雑なのが、Windows 内部にはLowLatencyProfileという名前が付いた Feature ID が別に存在することです。

今回確認できた関連 Feature は次のとおりです。

Feature ID	名前
58989092	TestLoc02
60716524	LowLatencyProfile

さらに、win32kfull.sys 内の Feature 情報を調査したところ、LowLatencyProfile 本体に対応する Feature ID は 60716524 であることを確認できました。

一方、ネット上で LowLatencyProfile の有効化に使われている 58989092 の内部名は TestLoc02 です。

では、なぜ 58989092 を有効化すると LowLatencyProfile が有効になるのでしょうか。

さらに調査を進めたところ、LowLatencyProfile（60716524） は、TestLoc02（58989092） を必須 Feature として直接参照していることが分かりました。

関係は次のようになります。

60716524（LowLatencyProfile）
        ↓ 必須
58989092（TestLoc02）

そこで、次の状態でも検証しました。

58989092 → 無効
60716524 → 有効

しかし、結果は次のままでした。

戻り値       = 0
GetLastError = 50

つまり、60716524 を単独で有効化しても、必須 Feature である 58989092 が無効な状態では、LowLatencyProfile の内部判定は有効側へ変化しませんでした。

一方、58989092 を有効化すると、結果は次のように変化しました。

戻り値       = 0
GetLastError = 5

この結果は、Windows 内部で確認した Feature の依存関係とも一致します。

つまり、LowLatencyProfile 本体の Feature ID は 60716524 ですが、58989092（TestLoc02） は LowLatencyProfile が直接必要とする必須 Feature です。

そのため、ネット上では 58989092 が LowLatencyProfile の有効化 ID として広く紹介されていますが、内部的には 58989092 自体が LowLatencyProfile 本体というわけではありません。

LowLatencyProfile を有効にするために 60716524 を別途有効化する必要はありません。実際の検証では、58989092 を有効化することで、LowLatencyProfile の内部判定が有効側へ変化することを確認しています。

LowLatencyProfile の要求は一定時間だけ維持される

さらに内部処理を調査すると、LowLatencyProfile は一度要求されると永久に維持される仕組みではなく、一定時間だけ状態を保持するように設計されていることが分かりました。

LowLatencyProfile の要求を処理する内部関数では、主に次の情報を記録しています。

• LowLatencyProfile が要求された時刻
• LowLatencyProfile を要求した理由
• 要求理由ごとの有効時間

初めて要求を受け取ると、その時点の時刻と要求理由を保存します。

同じ理由による要求が再度行われた場合は、記録されている時刻を更新します。

その後、Windows 内部のタイマー処理によって経過時間が確認され、設定された有効時間を過ぎると LowLatencyProfile の状態が解除されます。

つまり、LowLatencyProfile は、

CPU を常に高速な状態に固定する機能

ではなく、

特定の操作が行われたときに要求され、必要な期間だけ状態を維持する仕組み

と考えるのが自然です。

実際に WinDbg で動作を追跡したところ、スタートメニューなどの対象操作を行っても、毎回必ず NtUserRequestLowLatencyProfile が呼び出されるわけではありませんでした。

短時間に同じ操作を繰り返した場合など、新しい呼び出しが確認できないことがあります。

ただし、今回の追跡だけでは、呼び出しが省略される正確な条件までは断定できません。

カーネル側で LowLatencyProfile の状態が一定時間維持されることに加え、ユーザーモード側でも現在の状態や直前の要求に応じて、重複する要求を抑制している可能性があります。

LowLatencyProfile の開始と終了は Windows 内部で通知される

LowLatencyProfile の状態をさらに追跡したところ、開始と終了のタイミングで Windows 内部の通知機構が使用されていることも確認できました。

使用されているのは、Windows Notification Facility、通称 WNF です。

確認できた State Name は次のとおりです。

WNF_SEB_GUI_ACTIVITY_STARTUP

LowLatencyProfile の最初の要求が開始されると通知が行われ、すべての要求が終了すると再び状態が更新される仕組みになっています。

このことからも、LowLatencyProfile が単純なオン・オフ設定ではなく、必要なタイミングで開始され、一定時間後に終了する動的な仕組みであることが分かります。

なお、この WNF の状態を通常のユーザープロセスから直接確認できないかも検証しましたが、今回の環境ではアクセスが拒否されました。

そのため、今回作成した確認ツールでは WNF を使用していません。

WinDbg で LowLatencyProfile が実際に要求される操作を追跡

ここまでの調査では、Windows のシステムファイルを解析し、LowLatencyProfile の内部判定や Feature の依存関係、要求を維持する仕組みを確認してきました。

さらに、LowLatencyProfile が実際にどの操作で要求されるのかを確認するため、WinDbg を使用して Windows の動作を追跡しました。

WinDbg では、win32u.dll に存在する次の関数へブレークポイントを設定しています。

NtUserRequestLowLatencyProfile

そして、次のプロセスを個別に監視しました。

StartMenuExperienceHost.exe
SearchHost.exe
explorer.exe

その結果、スタートメニュー、Windows 検索、通知センター、タスクバーなどの操作から、実際に NtUserRequestLowLatencyProfile が呼び出されることを確認できました。

LowLatencyProfile の要求に共通する呼び出し経路

今回検出した操作では、ほとんどが最終的に次の共通処理へ到達していました。

Windows の各シェルコンポーネント
    ↓
windowsudk_shellcommon.dll
    ↓
LowLatencyAction::TriggerBoost
    ↓
TriggerLowLatencyProfileInternal
    ↓
user32.dll
    ↓
RequestLowLatencyProfile
    ↓
win32u.dll
    ↓
NtUserRequestLowLatencyProfile

特に重要なのが、windowsudk_shellcommon.dll に存在する次の処理です。

LowLatencyAction::TriggerBoost

スタートメニュー、検索、通知センター、タスクバーなどの異なる操作が、この共通処理を経由して LowLatencyProfile を要求していました。

つまり、LowLatencyProfile は、アプリやシェル操作を自動的に監視して適用されるのではありません。

各 Windows シェルコンポーネントが、必要な操作で LowLatencyAction::TriggerBoost を明示的に呼び出す設計になっています。

スタートメニューを開く際の呼び出し

タスクバーのスタートボタンをクリックした際には、次の呼び出し経路を確認できました。

Taskbar_View.dll
    ↓
TaskbarResources::OnExperienceToggleButtonClick
    ↓
LaunchListItemViewModel::OnClick
    ↓
ShellViewCoordinator::TryShowAsync
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

この結果から、スタートメニューを表示する処理に LowLatencyProfile の要求が組み込まれていることを確認できます。

ただし、スタートメニューを開くたびに、必ず新しい要求が発生するわけではありませんでした。

短時間に繰り返しスタートメニューを開いた場合など、NtUserRequestLowLatencyProfile の新しい呼び出しが確認できないことがあります。

Windows 内部では LowLatencyProfile の状態を一定時間維持する処理が存在しますが、今回の追跡だけでは、新しい呼び出しが省略される正確な条件までは断定できません。

ユーザーモード側で、現在の状態や直前の要求に応じて、重複する要求を省略している可能性もあります。

タスクバーの検索を開く際の呼び出し

タスクバーの検索ボタンをクリックした際には、次の経路を確認できました。

SearchUx_UI.dll
    ↓
SearchButtonControl::OnSearchButtonClick
    ↓
SearchItemViewModel::OnClick
    ↓
ShellViewCoordinator::TryShowAsync
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

この結果から、Windows 検索の画面を表示する操作でも、LowLatencyProfile が要求されることを確認できます。

また、検索結果からアプリを起動した際にも、別の経路から LowLatencyProfile の要求が行われていました。

SearchUx_InternalWebApi.dll
    ↓
Launcher::LaunchSearchItemAsync
    ↓
TileAppItem::LaunchAsync
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

したがって、Windows 検索では、検索画面の表示と、検索結果からのアプリ起動の両方で、LowLatencyProfile が使用される場合があります。

通知センターを開く際の呼び出し

タスクバー右端の時計や通知アイコンをクリックして通知センターを開いた際には、explorer.exe 内の SystemTray.dll から LowLatencyProfile が要求されました。

確認できた主な経路は次のとおりです。

SystemTray.dll
    ↓
ClockSystemTrayIconDataModel2::OnIconClicked
    ↓
ShellViewHelperSingleton::ToggleShellViewAsync
    ↓
ShellViewCoordinator::TryShowAsync
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

通知アイコン側から開いた場合には、次の処理も確認できました。

NotificationBadgeSystemTrayIconDataModel::OnIconClicked

時計側と通知アイコン側では起点となる処理が異なりますが、どちらも最終的に ShellViewCoordinator::TryShowAsync と LowLatencyAction::TriggerBoost を経由していました。

この結果は、Microsoft が対象として挙げているアクションセンターの処理で、実際に LowLatencyProfile が要求されることを裏付けています。

タスクバーからアプリを起動する際の呼び出し

タスクバーにピン留めしたアプリを起動した際には、次の明確な呼び出し経路を確認できました。

Taskbar.dll
    ↓
CTaskBand::CLauncherTask::ThreadProc
    ↓
CTaskBand::CLauncherTask::_Launch
    ↓
LaunchFromTaskbar
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

実際にタスクバーへピン留めしたペイント 3D を起動した場合にも、この経路で LowLatencyProfile が要求されました。

特に次の関数名から、タスクバーからのアプリ起動処理に LowLatencyProfile の要求が明示的に組み込まれていることが分かります。

Taskbar!LaunchFromTaskbar

これは、アプリの種類に応じて自動的に LowLatencyProfile が適用されるという意味ではありません。

タスクバーから起動するという Windows シェル側の経路で、LowLatencyAction::TriggerBoost が呼び出されています。

スタートメニューからアプリを起動する際の呼び出し

スタートメニューにピン留めされたアプリをクリックした場合には、次の経路を確認できました。

StartMenu.dll
    ↓
PinnedList::OnItemClick
    ↓
PinnedListTileViewModel::LaunchAsync
    ↓
Tile::LaunchWithOptionsAsync
    ↓
LowLatencyAction::TriggerBoost
    ↓
NtUserRequestLowLatencyProfile

スタートメニューからアプリを起動する場合も、アプリの起動処理に入る前に LowLatencyProfile が要求されていました。

すべてのアプリ起動で要求されるわけではない

今回の検証では、次のアプリ起動方法では NtUserRequestLowLatencyProfile の呼び出しを確認できませんでした。

• .txt ファイルをダブルクリックしてメモ帳を起動する
• 右クリックメニューからアプリを起動する
• エクスプローラーのアドレスバーからアプリを起動する

また、エクスプローラーのウィンドウを開く操作でも、LowLatencyProfile の要求は確認できませんでした。

一方、次の Windows シェル経由では要求を確認できています。

• スタートメニューからの起動
• Windows 検索結果からの起動
• タスクバーのピン留めからの起動

この違いから、Microsoft が説明している「アプリの起動」は、あらゆる起動方法を意味するものではないと考えられます。

少なくとも今回の Windows 11 ビルドでは、スタートメニュー、Windows 検索、タスクバーなど、LowLatencyProfile の要求が組み込まれた特定の Windows シェル経路から起動した場合に使用されています。

すべての要求で同じ Reason が指定されていた

今回捕捉した NtUserRequestLowLatencyProfile の呼び出しでは、第2 引数に次の値が指定されていました。

Reason = 1

この値は、内部の LOW_LATENCY_PROFILE_REQUEST_REASON に渡されます。

スタートメニュー、Windows 検索、通知センター、タスクバーからのアプリ起動など、今回確認した異なる操作では、いずれも Reason = 1 でした。

ただし、1 が内部的にどのような名称や意味を持つのかは、現時点では確認できていません。

そのため、本記事では「同じ要求理由が指定されていた」という事実にとどめます。

実際の要求はアクセス拒否として処理された

今回の WinDbg ログでは、LowLatencyProfile の要求後に、次のエラーも記録されました。

0x80070005
アクセスが拒否されました

これは、これまでの内部解析で確認した GetLastError = 5 と一致します。

つまり、LowLatencyProfile の Feature 判定は通過していますが、その後のプロセス条件によって、要求自体はアクセス拒否として処理されています。

この動作は、確認ツールが次の違いを利用して有効・無効を判定している仕組みとも一致します。

GetLastError = 50
    ↓
LowLatencyProfile の有効判定を通過していない

GetLastError = 5
    ↓
LowLatencyProfile の有効判定を通過し、
その後のプロセス条件確認まで進んでいる

今回の WinDbg 検証によって、確認ツールで利用している判定方法だけでなく、実際の Windows シェルコンポーネントが LowLatencyProfile を要求する経路も確認できました。

LowLatencyProfile 確認ツールを公開

今回の調査結果を基に、LowLatencyProfile が Windows 内部で有効と判定されているかどうかを確認する専用ツールを作成しました。

ツール名は、

LowLatencyProfile 確認ツール

です。

英語環境では、

LowLatencyProfile Checker

と表示されます。

このツールは ViVeTool を使用せず、Windows 内部の判定結果から LowLatencyProfile の有効・無効を確認します。

主な特徴は次のとおりです。

• ViVeTool は不要
• Feature ID の入力は不要
• 起動すると自動的に状態を確認
• 「有効」「無効」「判定不能」をシンプルに表示
• Windows の完全なビルド番号を表示
• 日本語と英語に対応
• Windows 11 64 ビット専用
• LowLatencyProfile の設定変更は行わない

ツールを起動すると、LowLatencyProfile の判定結果が「有効」「無効」「判定不能」のいずれかで表示されます。

LowLatencyProfile 確認ツールの使い方

対応環境：Windows 11
確認済みビルド：26200.8655、26200.8737

対象ファイル:「LowLatencyProfileChecker.exe」（Ver 1.0.0.0）
ハッシュ値(SHA256):7920017bf354dc5d817d5262f7e028fdc2363117e36bb512bfe129d26c5ffe98

LowLatencyProfileChecker.zip

使い方は簡単です。

1. 上記のリンクからLowLatencyProfileChecker.zip をダウンロードし、解凍します。
2. 解凍したフォルダー内の LowLatencyProfileChecker.exe を実行します。
3. 自動的に LowLatencyProfile の状態が確認されます。

管理者として実行する必要はありません。

もう一度確認したい場合は、画面中央にある「もう一度確認」ボタンをクリックしてください。

ツールの判定結果について

ツールを起動すると、自動的に LowLatencyProfile の状態を確認します。

「有効」と表示された場合

有効

LowLatencyProfile は有効です。
Windows の内部 Feature 判定を通過しました。

これは、LowLatencyProfile の有効判定を通過し、その後の処理まで進んだことを意味します。

「無効」と表示された場合

無効

LowLatencyProfile は無効です。
Windows の内部 Feature 判定を通過しませんでした。

これは、LowLatencyProfile の有効判定を通過せず、エラー 50 が返された場合です。

「判定不能」と表示された場合

判定不能

現在の結果から状態を判定できません。
Windows の実装が変更された可能性があります。

既知の結果と異なる戻り値やエラーコードが確認された場合は、無理に有効または無効とは判定しません。

Windows の完全なビルド番号も表示

LowLatencyProfile は Windows の内部実装に依存しているため、Windows のビルド番号も重要です。

そのため、本ツールでは、

26200

だけではなく、更新リビジョンを含めて、

26200.8655

のように完全なビルド番号を表示します。

また、確認を実行した日時も表示されます。

最終確認: 2026/07/12 15:20:30 / Windows Build 26200.8655

将来の Windows Update によって内部処理が変更された場合も、どのビルドで結果が変化したのかを確認しやすくしています。

このツールが行っていること

本ツールは、Windows 内部の NtUserRequestLowLatencyProfile を呼び出し、その結果から LowLatencyProfile の有効判定を通過したかどうかを確認しています。

判定の考え方は次のとおりです。

NtUserRequestLowLatencyProfile を呼び出す
        ↓
戻り値とエラーコードを確認
        ↓
エラー 5
→ LowLatencyProfile の有効判定を通過

エラー 50
→ LowLatencyProfile の有効判定を通過していない

その他
→ 判定不能

Windows Update 後は判定できなくなる可能性がある

今回の確認方法は、Windows 11 ビルド 26200.8655 で実際に内部処理を調査し、動作を確認した結果に基づいています。

NtUserRequestLowLatencyProfile は一般のアプリケーション向けに公開された API ではありません。

将来の Windows Update によって内部仕様が変更される可能性があります。

そのため、ツールでは既知の結果と異なる場合に、無理に「有効」または「無効」と表示せず、

判定不能

と表示するようにしています。

まとめ

LowLatencyProfile は、Windows 11 のアプリ起動や主要なシェル操作などで、応答性を改善するために使用される内部機能です。

今回、Windows の内部処理を調査し、実機で検証した結果、次のことを確認しました。

• Windows 内部に NtUserRequestLowLatencyProfile が存在する
• LowLatencyProfile の要求時には、最初に機能が有効かどうか確認される
• 無効の場合はエラー 50 が返る
• 有効の場合は次のプロセス条件の確認へ進む
• 通常の AutoIt プロセスでは、その段階でエラー 5 が返る
• この違いを利用して、LowLatencyProfile の有効判定を通過したか確認できる
• 検証した環境では、Feature ID 58989092 の有効・無効によって実際の結果が変化した
• Feature ID 60716524 は LowLatencyProfile という名前を持つが、単独で有効化しても判定結果は変化しなかった
• LowLatencyProfile の要求は一定時間だけ維持される
• 開始と終了時には Windows 内部の通知機構が使用されている

今回公開する「LowLatencyProfile 確認ツール」は、ViVeTool の設定値を表示するツールではありません。

Windows 内部の LowLatencyProfile 処理を実際に呼び出し、その判定結果から有効・無効を確認するための専用ツールです。