MicrosoftはWindows 11のタスクマネージャーで、NPU（Neural Processing Unit）の負荷をプロセス、ユーザー、詳細情報の単位まで追えるようにした。従来のPerformanceページで装置全体の使用率を見る段階から、どのアプリが、どのNPU内部エンジンを使っているかを探る段階へ進む。機能はWindows 11 24H2／25H2向けの2026年5月26日プレビュー更新に記載され、6月9日の累積更新にも収録された。8月20日にNeowinが取り上げた内容は、この日に実装された新機能ではない。AIワークロードをどの計算資源が引き受けているかを、標準ツールでどう切り分けられるかが焦点となる。
4つのNPU列で負荷の主体を追う
今回追加されたのは、NPUを搭載した対象PCのProcesses、Users、Detailsで選べるNPU列とNPU Engine列である。NPU列はプロセスまたはユーザーごとの現在の稼働割合を示し、NPU Engine列は同じNPU内部でどの実行エンジンが動いているかを読む手掛かりになる。Detailsでは、NPU Dedicated MemoryとNPU Shared Memoryも選択できる。結果として、DetailsではNPUの負荷と実行エンジンに加え、専用メモリーと共有メモリーという4種類の情報をプロセスごとに並べられる。
表示の追加は、各ページの列見出しを右クリック、タッチ操作では長押しして、メニューから該当列を選ぶ。既定の画面を眺めるだけでは現れない情報であり、負荷の原因を探す場面では列を明示的に増やす必要がある。総使用率が上がっているという表示だけでは、バックグラウンドで動く会議エフェクトや検索・画像処理、ローカル推論のいずれが動いたのかは分からない。プロセス別の列は、その問いをアプリ名とユーザー名へ戻す。
Microsoftは、どのアプリまたはユーザーがNPUをどれだけ使い、どのエンジンが実行中かを見れば、性能やバッテリー持続時間へ影響する負荷を特定しやすくなるとしている。効率のよいAIハードウェアが実際に使われているかを確認する用途も挙げる。利用率は、理論性能やモデルの処理速度を直接測るベンチマークではない。それでも、処理の出所を突き止める最初の画面としては、装置全体のメーターより情報が多い。
ProcessesとDetailsにはIsolation列も加わった。これはAppContainer内で動くアプリを識別する列で、性能を測る項目ではない。高負荷のプロセスを停止してよいかを自動で決めるものでもないが、負荷を出しているプロセスの実行境界と役割を読む補助材料になる。
GPU内ニューラルエンジンも同じ画面へ
Microsoftは、GPU内のニューラルエンジンをPerformanceページに表示し、既存のGPU Engine列もニューラルワークロードを示すよう更新した。専用NPUの使用率とGPU側のAI処理を、タスクマネージャーの同じ診断導線で見分けられる。アプリがAI処理を起動したとき、専用NPUで走ったのか、GPUのニューラルエンジンへ載ったのかを切り分ける入口が整ったことになる。
背景には、MicrosoftがMCDM（Microsoft Compute Driver Model）で扱う計算資源の考え方がある。MCDMはGPUやNPUなどを共通のドライバー枠組みで扱い、アプリが投入した計算作業をコンテキスト、ソフトウェアキュー、エンジンへ結び付ける。OS側のスケジューラーは、公平性や優先度に応じて実行を調整する。タスクマネージャーの表示は、その実行経路のすべてを説明するものではないが、計算専用デバイスもOSが管理する仕事として扱う仕組みと接続している。
ここで見たいのは、NPUかGPUかという名称そのものではない。NPU向けに実装されたワークロードが期待した計算資源へ到達しているか、あるいはCPUやGPUへフォールバックしているかである。NPU列、NPU Engine列、GPU Engine列を同時に開くと、負荷が移った時点を初動で追いやすくなる。もっとも、タスクマネージャーに現れる情報量は、OSの版、対象ハードウェア、ドライバーと実装が公開する能力に左右される。
利用率と実性能を混同しない
NPU利用率が高いことだけで、アプリが異常に動作しているとは言えない。対象の処理がNPU用に実装され、継続的に仕事を投入している可能性もある。反対に、表示がゼロであっても、直ちにNPU非対応とは判断できない。ドライバーがNPUを認識しているか、ワークロードがNPUへ割り当てられる実装か、CPUまたはGPUへフォールバックしていないかを合わせて確認する必要がある。
NPU Engineは、同一NPU内部のどの実行エンジンが動くかを知る手掛かりである。一方、NPU列の使用率は現在の稼働割合であり、カタログ上の理論性能や、特定モデルの処理速度を表す数値ではない。この二つを混同すると、利用率の上下を性能比較へ置き換えてしまう。アプリがどのエンジンを使ったかという観測と、同じ処理を何秒で終えたかという評価は、別々に扱う必要がある。
バッテリー持続時間の調査でも、列の意味は限定される。MicrosoftはNPUの消費量と実行エンジンを見ることで、バッテリーへ影響する負荷の特定に役立つとしているが、今回の追加列が消費電力そのものを測定するわけではない。タスクマネージャーで高いNPU利用率を確認した後に、どのアプリがその状態を維持しているかを特定する。そこで得たアプリ名、エンジン名、実行時の条件を、性能や電池持続時間の検証へ持ち込む順序になる。
温度、電圧、長時間ログの境界
タスクマネージャーは今回、リアルタイムの初動診断を厚くした。ただし、温度や電圧、ファン回転数が加わったわけではない。スロットリング理由や長時間ログも加わっていない。センサー値や記録を必要とする調査は、HWiNFOなどのセンサーツール、Windows Performance Recorder／Analyzerで扱う領域に残る。NPU列はそれらを置き換えるものではなく、詳細な解析に入る前に、どのプロセスとエンジンを追うべきかを絞り込む表示である。
タスクマネージャーは2019年にもGPU温度表示を加えたが、当時Microsoftは専用GPUとWDDM 2.4以降のドライバーを条件とした。GPU温度が見えるという前例から、CPU温度やすべてのセンサーが同じ画面で見えると一般化することはできない。今回のNPU監視も、対応するハードウェアとソフトウェアの条件から切り離して読むべきではない。
Isolation列にも同じ注意が要る。AppContainerは最小権限の実行環境だが、列の有無だけでアプリの安全性を判定することはできない。NPU負荷を出しているアプリがどの実行境界にあるかを知る材料として使い、セキュリティ状態の結論は別の情報で確かめる必要がある。
OS・ハードウェア・ドライバーが決める表示範囲
対象となるのは、June non-security update以降を導入した対応デバイスである。Windows 11 24H2／25H2では、KB5089573のプレビュー更新が2026年5月26日にOS Build 26100.8524／26200.8524として出ており、2026年6月9日のKB5094126はその非セキュリティ改善を収録した。したがって、このNPU監視強化はInsider向けの将来機能ではない。6月以降の対象環境で利用できる機能として確認するのが時系列に合う。
もっとも、更新プログラムを導入しただけで、すべてのPCが同じ列と値を返すとは限らない。NPUの搭載有無、GPU内ニューラルエンジンの実装、ドライバーが公開する能力で表示範囲は変わる。NPU利用率が見えない場合も、まずOSの版と更新履歴、対象ハードウェア、ドライバーの認識状態を分けて確認する。これは機能の不在と、ワークロードがそのエンジンを使っていない状態を区別するためである。
実用上の検証は、同じアプリ、同じ処理、同じOSビルドの条件で、NPU列とNPU Engine列、GPU Engine列がどう変わるかを記録するところから始まる。さらに、アプリがNPUを使う実装か、ドライバーがどの能力を報告するかを揃えなければ、表示の差を性能差と結び付けられない。2026年6月以降の更新を入れた対応PCで、これらの列が実ワークロードに対して一貫した値を示すかが、次の確認点になる。
