タスクマネージャー（Task Manager）でCPU使用率が「100%」と表示されているのに、動画のエンコードもファイルコピーも問題なく動く。個別のプロセスの数値を上から足し合わせても、合計値がどこにも一致しない——そんな奇妙な経験をしたことはないだろうか。その違和感はユーザー側の勘違いではない。1990年代のシングルコア時代に書かれた計算ロジックと、ターボブーストや動的周波数スケーリングを駆使する現代のプロセッサの挙動がズレていた結果だ。初代開発者であるDave Plummer氏が明かした「CPUメーターの数値は直近の死亡記事に過ぎない」という告白と、MicrosoftがWindows 11で30年ぶりに実施した計算式の刷新を見ていきたい。
「100%の矛盾」を引き起こしたターボブーストと計算方式の限界
12コアのプロセッサを搭載したPCで8コアのみをフル稼働させた場合、タスクマネージャーは全体のCPU使用率を「100%」として示す。個別のプロセスの数値を上から順に足し合わせても、上部に表示される全体のパーセンテージと全く一致しない——こうした現象がこれまでのWindowsで頻発してきた。テック系ニュースサイトのWindows Latestが過去に検証した事例では、1つのコアを完全に占有するプロセスが、システム全体のわずかな負荷しか生じさせていない場面でも「100%」の表示を引き起こした。動画のエンコードやファイルコピーを同時にこなせる余力が残っているにもかかわらず、メーターは赤く染まり続ける。
Windows 8以降の再設計に伴い、タスクマネージャーはプロセッサのベースクロック（定格周波数）を基準にする「プロセッサユーティリティ（% Processor Utility）」と呼ばれる指標を採用した。現代のプロセッサはターボブースト機能により一時的にベースクロックを大きく超える周波数で動作する。計算上の使用率は容易に100%を超過するが、ユーザーインターフェース（UI）上は100%で頭打ちになる仕様だ。1つのスレッドしか使えない古い設計のソフトウェアを実行した場合、マルチコア環境では全体の10%未満の負荷しかかかっていないにもかかわらず、その1コアが限界に達しているという理由だけで全体が100%と表示されることもあった。
Windows 7およびWindows Server 2008 R2までの時代は、プロセッサの動作周波数が固定されていることが多く、単純な稼働時間の計算で正確な負荷を把握できた。電力効率を高めるために周波数を動的に変動させる現代のアーキテクチャでは、稼働時間だけではどれだけの処理が完了したかを測れない。この複雑な挙動を考慮するために導入されたのが「ユーティリティ」という概念だった。100%のキャップを設けたことで、結果的にシステム全体の処理能力の何割を使っているかという直感的な理解を妨げていた。システム全体のコア数を正しく反映していないこの表示仕様は、ユーザーに誤った危機感を与えてきた。
タスクマネージャーの計算が合わない問題は、長年オンラインフォーラムや技術系掲示板で議論を呼んできた。ユーザーが不審なバックグラウンドプロセスを特定しようとしても、数値の合計が100%に届かないため、隠れたマルウェアがいるのではと疑う声も出ていた。実際には、バックグラウンドで動く無数の小さなプロセスがそれぞれ微小なリソースを消費し、UIの丸め誤差が合計値との乖離を広げていた。PCの限界が来たと勘違いしたユーザーは、不要なトラブルシューティングに時間を費やすことになる。
リアルタイム表示ではなく「直近の死亡記事」が生まれる理由
Microsoftの元エンジニアであり、Windows NT時代にZIPフォルダサポートや「Space Cadet Pinball」の移植も手がけたDave Plummer氏は、自身のYouTubeチャンネル「Dave's Garage」やITニュースサイトThe Registerの取材を通じてタスクマネージャーの構造を解説した。同氏によれば、プログラム内部ではグラフィカルユーザーインターフェース（GUI）のタイマーが一定間隔で発火する仕組みになっている。タイマーが作動するたびに、コードはWindowsのカーネルに対して各プロセスが消費した累積の実行時間を問い合わせる。現在の累積CPU時間から前回の累積CPU時間を差し引き、その差分を全プロセスが消費した合計の差分で割ることで、プロセスごとのパーセンテージを算出している。
Plummer氏はこの仕組みについて「タスクマネージャーのCPUの数値は、直近の過去の動く小さな死亡記事だ」と独特の表現で語った。あなたの眼球がその行に着地した瞬間に何が起きていたかを示すものではない。プロセッサの動作周波数が固定されていた時代には、この時間ベースの計算方式は極めて正確に機能した。動的周波数スケーリングやサーマルスロットリング（熱による性能制限）、ディープアイドルステートといった技術が標準化した現代では、経過時間がそのままこなした仕事量とイコールにはならない。あるプロセスが100ミリ秒だけ限界まで処理を行い、すぐにスリープ状態に入った場合、その極端な負荷は更新間隔全体で平均化され、ごく小さな数値として表示される。
Plummer氏はこの状況を交通事情に例え、「現代のCPU使用率は、実際に何マイル走ったかではなく、高速道路がどれくらい混んでいたかのようなものだ」と説明した。フェラーリが走る空いた高速道路と、古いセメントミキサー車で渋滞した高速道路では、同じ使用率でもこなせる仕事の量が全く異なる。数字が実態とずれて感じるのはツールが壊れているからではなく、単一のパーセンテージでシステムの状態を表現できるほどハードウェアが単純ではなくなった結果だ。
Plummer氏が設計したこの計算ロジックは、開発当時のハードウェア環境では最も合理的かつ軽量なアプローチだった。1990年代半ばのPCは、メモリ容量が数メガバイトから数十メガバイト程度しかなく、システム監視ツール自体が重い処理を要求することは許されなかった。タイマー駆動による差分計算は、CPUのサイクルを無駄に消費せず、システム全体のパフォーマンスに影響を与えずに状態を把握するための苦肉の策だった。現代のタスクマネージャーは、グラフィックス・プロセッシング・ユニット（GPU）の負荷やネットワーク帯域など、監視すべき対象が劇的に増大している。それでも、CPU使用率の計算の根幹には、このタイマーベースの差分計算という古い設計思想が色濃く残っていた。
85KBに詰め込まれた「最後の砦」としての設計思想
1995年11月、Plummer氏が開発してWindows NT 4.0に搭載された初代タスクマネージャーのファイルサイズは、わずか85KB（キロバイト）に抑えられていた。同氏は当時のリソースの厳しさについて「すべてのコード行にはコストがあり、すべてのメモリ割り当ては足跡を残す。すべての依存関係は、あなたの食べ物を食べながら家賃を払わないルームメイトのようなものだ」と振り返る。システムがフリーズしそうな極限状態でも確実に起動させるため、極限まで無駄を削ぎ落とした軽量なアプローチが選ばれた。
当時の開発現場では、わずかなメモリリークや無駄な描画処理がシステム全体のクラッシュを招くリスクが常に存在していた。Plummer氏は、Charles Petzold（チャールズ・ペゾルド）氏が執筆したWindowsプログラミングの解説書と大量のコーヒーを相棒に、オフィスに閉じこもってこのツールのコードを書き上げた。現代のソフトウェア開発では、巨大なフレームワークやライブラリを組み合わせてアプリケーションを構築するのが一般的だ。タスクマネージャーの初期バージョンは、OSの深淵に直接触れ、限られたリソースの中で最大の効果を引き出す職人芸の結晶だった。
タスクマネージャーの起動プロセスには、独自のフェイルセーフ機構が組み込まれている。一般的なアプリケーションは、すでに別のインスタンスが起動しているかを確認し、起動していればそれをアクティブにする。タスクマネージャーは既存のインスタンスにプライベートメッセージを送信し、返答を待つ仕組みを備えている。沈黙が返ってきた場合は既存のインスタンスが完全にフリーズしているとみなし、ユーザーを窮地から救うために新しいインスタンスを強制的に立ち上げる。
プロセスツリーの描画処理でも、プログラムを個別に照会するのではなく、カーネルに対してプロセス全体のテーブルを一括で要求する。アプリケーション・プログラミング・インターフェース（API）呼び出しの回数を劇的に減らし、もしバッファが小さすぎた場合はサイズを拡張して再試行する。同氏は動画の中で、CPUの数値報告に関する奇妙なバグを追跡している最中に、ソースコードのコメント欄に自身の電話番号を残したというエピソードも披露した。1990年代の限られたハードウェアリソースの中で培われたマインドセットが、タスクマネージャーの根底には流れている。
新旧メトリクスの切り替えと、明日から変わるパフォーマンス管理
Microsoftは2025年2月28日、Windows 11 Insider Preview Build 26120.3360をDevおよびBetaチャネル向けにリリースした。公式ブログで同社は、業界標準およびサードパーティ製ツールと一致する標準的なメトリクス（測定基準）を新たに採用したと明らかにした。新しい計算式はシステム全体のコア数を分母としてCPU使用率を割り出す。8コアのシステムで1つのアプリケーションが1コアをフルに使えば、タスクマネージャーは100%ではなく正確に12.5%という数値を返す。
このアップデートにより、個別のプロセスの数値を手動で足し合わせれば、タブ上部に表示される合計値とピタリと一致する。これまで、より正確なシステム監視を求めるITプロフェッショナルは、Sysinternals（シスインターナルズ）のProcess Explorer（プロセスエクスプローラー）や、標準搭載のResource Monitor（リソースモニター）などを併用する必要があった。今後はタスクマネージャーを立ち上げるだけで、業界標準に則った信頼性の高いワークロードを確認できる。
「詳細」タブの列の選択オプションには、Microsoftが新たに「CPU Utility（CPUユーティリティ）」という項目を追加した。デフォルトでは非表示だが、ユーザーがこれを有効化すれば、プロセスごとの旧方式に基づく数値を引き続き閲覧できる。過去のデータとの比較や、プロセッサのブースト状態を含めた旧来の指標を必要とするユーザーへの配慮も残っている。新旧の指標を一つのツール内で切り替えられるため、環境移行の混乱を避けながら段階的に新メトリクスへ慣れていける。
この変更は、Windows 11 バージョン24H2ベースのアップデートとして、まずはBetaチャネルのWindows Insider向けに提供が開始された。DevチャネルとBetaチャネルの間で同じビルド番号のアップデートが提供されている期間中は、ユーザーが一時的にチャネルを切り替えて新機能を試すことも可能だ。Microsoftは、この移行期間が終了した後に、より広範なユーザー層へ向けて段階的に新機能の展開を進めていく。
Microsoftはこのアップデートを今年後半には推奨アップデートとして広く展開する計画を立てている。サーバー管理者やインフラエンジニアは、CPU使用率が100%に張り付いた際、本当にシステムリソースが枯渇しているのか、単一のプロセスが1コアを占有しているだけなのかを即座に見分けられるようになる。
新メトリクスを一足先に試したいユーザーは、「設定」>「Windows Update」>「Windows Insider Program」からBetaチャネルに参加すれば、Build 26120.3360以降で新方式を確認できる。既存システムで「CPU 100%」が恒常的に出ている場合、Sysinternals Suiteに含まれるProcess Explorerを併用して1コア占有型のプロセスを特定するのが現時点での次善策だ。次にタスクマネージャーを開いたとき、その100%が本物のボトルネックなのか、それとも30年越しの計算式が見せている幻なのか——新しい数値を前にすれば、判断の根拠は一変する。
Sources