なぜWindowsは重くなるとタスクマネージャーまで固まるのか？ Microsoftのベテラン開発者が解説

PCに高い負荷がかかると、原因となっているプロセスを終了させたいのに、肝心のタスクマネージャーまで反応しなくなることがある。なぜWindowsは、こうした状況に備えてタスクバーやタスクマネージャーを高い優先度で動かさないのだろうか。Microsoftで30年以上Windowsの開発に携わってきたRaymond Chenが、2026年10月27日付のブログ『The Old New Thing』で、この疑問に答えた。

Chenによると、CPU時間が不足するとすべてのプロセスが影響を受けるため、問題を解決するためのタスクマネージャーも例外ではない。単純に実行優先度を上げても、他のスレッドが占有している資源の解放を待つ必要があれば、その間は処理を進められない。Windowsには操作中のアプリを優先する仕組みがすでに備わっているが、それでも解消できない待機が存在するという。なお、今回の説明はWindowsの既存のスケジューリング機構に関するものであり、Windows 11の新機能や不具合修正を発表したものではない。

タスクマネージャーを高優先度にしても応答性を保証できない理由

CPUに余裕がなくなると、負荷の原因となったプロセスだけでなく、タスクバーやタスクマネージャーの動作も遅くなる。これらのツールを高優先度で実行すれば問題を解決できそうだが、Chenは、共有資源の待機を避けられないことが根本的な問題だと説明する。

Chenは、この仕組みをスーパーマーケットの優先レジに例えている。優先パスがあれば列の先頭に並べるものの、レジでは前の客が大量の商品を精算しているかもしれない。いくら優先されても、その客の会計が終わるまでは自分の番にならない。CPUの実行優先度を上げることも同様で、処理を開始する順番は早められても、他の処理が保持している資源を即座に利用できるようになるわけではない。

こうした待機には、大きく分けて2つの問題がある。1つ目は、共有資源を保持するスレッドの処理が終わるのを待たなければならないことだ。高優先度のスレッドが低優先度のスレッドの保持するロックを取得しようとした場合、低優先度のスレッドが処理を完了してロックを解放するまで先へ進めない。さらに、中程度の優先度のスレッドが低優先度のスレッドに割り込むと、資源の解放が遅れ、高優先度のスレッドまで待たされ続ける可能性がある。

この現象は「優先度逆転（Priority Inversion）」と呼ばれる。Windowsには、資源を保持するスレッドの優先度を一時的に引き上げることで、優先度逆転による遅延を抑える仕組みがある。ただし、Chenが指摘するように、資源を保持しているスレッド自身がネットワーク上のファイルにアクセスするなど、時間のかかる処理を実行している場合には効果がない。優先度を引き上げても、その処理が終わるまで待たなければならないからだ。

2つ目は、ユーザーインターフェース（UI）の処理に伴う競合である。タスクバーやタスクマネージャーを含むUIアプリケーションは、最終的にWindowsのUIシステムを呼び出す必要がある。その際、同じシステムを利用する他のUIスレッドと競合する可能性があるため、アプリケーション側の優先度を上げるだけでは応答性を保証できない。Chenは、こうした問題が特にUI処理で顕著になると説明しているが、具体的にどのロックやコンポーネントで競合が発生するかまでは特定していない。

Windowsはすでに操作中のアプリを優先している

Windowsでは、CPUの実行時間を各スレッドに割り当てるため、0から31までの32段階のスケジューリング優先度を使用する。最も低い優先度の0は、空きメモリページをゼロで埋めるシステムスレッド「ゼロページスレッド」専用だ。Microsoft Learnのスケジューリング優先度に関する文書によると、Windowsのスケジューラーは、実行可能なスレッドのうち最も優先度の高いものにCPU時間を割り当てる。同じ優先度のスレッドにはラウンドロビン方式で順番に実行時間が与えられ、より高い優先度のスレッドが実行可能になると、現在のスレッドが割り当て時間を使い切る前でも処理を切り替える。

Windowsには、ユーザーが現在操作しているアプリを優遇する仕組みもある。その一つが、スレッドの動的優先度を一時的に引き上げる「優先度ブースト（Priority Boost）」だ。各スレッドには基本優先度があり、スケジューラーは必要に応じて動的優先度を引き上げ、応答性を改善する。ただし、優先度ブーストの公式文書によると、この仕組みの対象となるのは基本優先度が0〜15のスレッドで、16〜31のスレッドには適用されない。

優先度が引き上げられる主な条件は3つある。まず、通常の優先度クラス（NORMAL_PRIORITY_CLASS）で動作するプロセスが前面に表示されると、そのプロセスの優先度クラスがバックグラウンドのプロセス以上になるよう調整される。次に、ウィンドウがマウスやキーボード、タイマーなどの入力を受け取ると、そのウィンドウを所有するスレッドの動的優先度が引き上げられる。さらに、ディスクI/Oの完了などによって待機中のスレッドが実行可能になった場合にも、優先度が一時的に上昇する。

ただし、引き上げられた優先度は永続的なものではない。スレッドが割り当てられた実行時間を使い切るたびに動的優先度は段階的に下がり、最終的に基本優先度へ戻る。この仕組みによって、入力に応答する処理を優先しながら、他のスレッドにもCPU時間を割り当てられるようにしている。

AutoBoostが優先度逆転による待機を軽減する

Windowsには、共有資源の待機によって発生する優先度逆転に対処する「AutoBoost」も用意されている。Microsoft Learnの優先度逆転に関する文書では、この仕組みを3つのスレッドを使って説明している。

まず、優先度4のスレッドT1がロックを取得する。その後、優先度8のT2が実行を開始すると、T1の処理は中断される。さらに優先度12のT3が実行可能になり、T1の保持するロックを取得しようとすると、T3はT1がロックを解放するまで待機することになる。しかし、T3が待機状態になっても、優先度8のT2は優先度4のT1より先に実行されるため、T1がロックを解放できず、結果として最も優先度の高いT3の処理が進まなくなる。

AutoBoostは、この問題を軽減するため、共有資源を保持するスレッドの優先度を一時的に引き上げる。上記の例では、T1の優先度が待機中のT3と同じ12まで引き上げられ、ロックを解放するまで維持される。これにより、T1が中程度の優先度を持つT2に妨げられる時間が減り、T3も資源を取得しやすくなる。

ただし、AutoBoostが解消できるのは、資源を保持するスレッドが他のスレッドに実行を妨げられることで生じる遅延だ。T1自身がネットワークアクセスなどの時間のかかる処理を実行している場合、その処理時間を短縮できるわけではない。Chenが指摘するように、優先度逆転を防ぐ仕組みが正しく働いていても、共有資源の解放を待つ時間は残る。

QoSはCPUコアの選択と電力管理を調整する

もう一つの仕組みが、QoS（Quality of Service）だ。これはスレッドに求められる性能や電力効率を指定するもので、特に性能の異なるCPUコアを組み合わせたプロセッサーで重要になる。

Microsoft LearnのQoSに関する文書によると、Windowsが次に実行するスレッドを決める主な基準は、あくまでスケジューリング優先度である。一方、QoSは使用するCPUコアの選択やプロセッサーの電力管理に影響し、場合によっては実行可能なコアを制限したり、特定の種類のコアを優先したりする。

ウィンドウを持つアプリケーションの場合、QoSは主に表示状態やフォーカスの有無に応じて変わる。

アプリケーションの状態	QoS	主な扱い
前面に表示され、フォーカスがある	High	高い性能を優先
表示されているがフォーカスがない	Medium	性能と電力効率のバランスを調整
最小化されている、または完全に隠れている	Low	特にバッテリー駆動時に電力効率を優先
音声を再生している	High	表示状態とは別に高い性能を優先

また、バッテリー駆動時には、一定時間ユーザーからの入力がない場合、前面に表示されているアプリでもQoSがMediumへ引き下げられることがある。これは、操作されていないアプリに必要以上の電力を使わないようにするための仕組みだ。ChenもこのQoSの公式文書を参照し、Windowsはフォーカスのあるプログラムをすでに優遇していると説明している。

Windowsが操作中のアプリを優先する主な仕組みを整理すると、次のようになる。

仕組み	調整する内容	主な目的・効果
前面プロセスの優先度クラス調整	前面のプロセスをバックグラウンドのプロセス以上の優先度クラスにする	操作中のアプリを優先する
入力を受けたスレッドの優先度ブースト	動的優先度を一時的に引き上げる	マウスやキーボードなどの入力への応答を早める
AutoBoost	資源を保持するスレッドの優先度を一時的に引き上げる	優先度逆転による遅延を軽減する
QoS	使用するCPUコアや電力管理を調整する	性能と電力効率を両立させる

これらの仕組みによって、WindowsはCPU時間の割り当てや実行環境を調整し、ユーザーが操作しているアプリの応答性を高めている。しかし、CPUの実行順序を優先しても、別のスレッドが保持する資源をすぐに使えるようになるわけではない。AutoBoostも優先度逆転による遅延を軽減するものであり、資源を保持するスレッド自身の処理時間は短縮できない。また、QoSはCPUコアの選択や電力管理に関わる仕組みであり、共有資源の競合を直接解消するものではない。

したがって、これらの仕組みが正常に動作していても、UIシステムで他のスレッドと競合したり、共有資源の解放を待ったりすることで、タスクバーやタスクマネージャーの応答が遅れる可能性は残る。なお、ここで挙げたのはWindowsの代表的な仕組みであり、待機状態から復帰したスレッドへの優先度ブーストなど、ほかにもスケジューリングを調整する機構が存在する。各仕組みの説明はMicrosoftの技術文書に基づくもので、高負荷時の応答時間を比較した測定結果ではない。

タスクマネージャーをリアルタイム優先度にするのは危険

興味深いことに、Microsoft自身の技術文書にも、システム負荷が高い状況で素早く応答する必要があるプロセスの例が記載されている。SetPriorityClass関数の公式文書では、高優先度クラス（HIGH_PRIORITY_CLASS）の使用例として「Task List」が挙げられており、OSの負荷にかかわらず、ユーザーが呼び出した際に迅速に応答する必要があるものとして説明されている。ただし、ここでいうTask Listと現在のタスクマネージャーの関係や、taskmgr.exeが実際にどの優先度クラスで動作しているかについては明記されていない。

同じ文書では、高優先度クラスのプロセスがCPU時間のほぼすべてを消費する可能性があるため、設定には細心の注意が必要だと警告している。高優先度で長時間処理を続けるスレッドがあると、それより優先度の低いスレッドが十分に実行されなくなるためだ。また、複数のスレッドを同時に高優先度へ設定すると、優先度を引き上げる効果自体が薄れる。同じ優先度のスレッドは対等に扱われるため、すべてを高優先度にしても実行順序の問題は解決しない。

さらに危険なのが、リアルタイム優先度クラス（REALTIME_PRIORITY_CLASS）だ。この優先度は、マウスやキーボードの入力、ディスクのバックグラウンド書き込みなどを管理するシステムスレッドよりも高く設定される可能性がある。そのため、CPUを長時間占有する処理をリアルタイム優先度で実行すると、入力操作すら受け付けなくなるおそれがある。Microsoftは公式文書で、リアルタイム優先度クラスを通常のアプリケーションに使用することはほぼ避けるべきだとしている。

Chenは、2010年6月10日のブログ記事でも、この問題を取り上げていた。CPUを100%使用するプログラムをリアルタイム優先度で動かすと、入力を処理するスレッドにもCPU時間が割り当てられず、ユーザーが操作してプログラムを終了させることができなくなる場合があるという。そこでタスクマネージャーをリアルタイム優先度で実行すればよいという考えに対しても、Chenは否定的な見解を示している。

その理由の一つは、タスクマネージャーを起動したり、既存のウィンドウへ切り替えたりする操作自体が、リアルタイム優先度で実行されないことだ。仮にタスクマネージャーをリアルタイム優先度で実行できたとしても、今度は同じ優先度で処理を続けているプログラムからCPU時間を奪うことになる。リアルタイム優先度を指定したプログラムは、ほかの処理に実行を妨げられないことを前提としているため、タスクマネージャーだけを特別扱いすることも、優先度の設計思想と矛盾する。

2026年の記事でも、Chenは同様の問題を指摘している。すでに過負荷に陥ったシステムを、そのシステム内部で動作するツールによって修復することは難しい。問題を解決するためのツール自体が負荷の影響を受けている可能性があり、原因となったプロセスと重要な資源を共有していれば、なおさら対応が難しくなるからだ。

Windowsは、フォーカスのあるアプリを優先する仕組みをすでに備えている。そのため、タスクバーやタスクマネージャーにフォーカスを移せれば、既存の仕組みによる優遇を受けられる。しかし、優先されたスレッドが別のスレッドの保持する資源を待っている場合、その優遇だけでは応答を回復できない。2010年の記事がリアルタイム優先度によるCPUの占有を問題にしていたのに対し、今回の記事は、優先度が高くても共有資源やUI処理の待機からは逃れられないことを説明している。

高負荷時の応答性を改善するには、重い処理を抑える方法もある

タスクマネージャー自身の優先度を上げる代わりに、CPUを大量に使用しているアプリケーションの処理を抑える方法もある。その一つが、Windows 11のタスクマネージャーに搭載されている「効率モード（Efficiency Mode）」だ。

Microsoftは2022年2月16日のWindows 11 Insider Preview Build 22557の発表で、タスクマネージャーへの効率モードの導入を案内した。これは2021年4月に試験導入した「Eco mode」を改称したもので、資源を大量に消費するアプリの使用量を制限し、ほかのアプリを優先しやすくする機能だ。Microsoftは、これにより前面アプリの応答性と電力効率の改善が期待できると説明している。

効率モードは、タスクマネージャーの「プロセス」画面から、対象のプロセスを右クリックするか、コマンドバーの操作によって適用できる。ただし、適用できるのは個々のプロセスであり、プロセスグループ全体をまとめて切り替えることはできない。また、選択肢がグレーアウトしている場合は、一般にWindowsの重要なプロセスであり、使用量を制限するとシステムの性能に悪影響を与える可能性がある。

ただし、効率モードによってすべての応答遅延が解消するわけではない。重い処理によるCPUの競合を軽減できても、共有資源を保持するスレッドの処理が長引いている場合や、UIシステムで競合が発生している場合には、待機が残る可能性がある。Microsoftの説明も、効率モードがこうした問題をどの程度改善できるかを定量的に示したものではない。

CPUコアの使用数を制限して応答性を確保する事例も

Chenの記事のコメント欄では、実際に高負荷時の応答性を改善する方法を試したユーザーの報告も寄せられている。Shawn Van Nessは、大規模なコードベースをビルドすると24コアすべての使用率が数分間100%に達し、エクスプローラーやタスクバーがほとんど操作できなくなると説明した。

Van Nessは、WindowsのImage File Execution Optionsを使い、コンパイラのCL.exeとビルドツールのMSBuild.exeの優先度を下げる一方、TaskMgr.exeの優先度を引き上げた。しかし、応答性の改善はわずかだったという。そこで、ビルド処理が使用できるCPUコアを制限する「プロセッサーアフィニティ」を利用し、24コアのうち2コアを使用対象から外した。ビルド処理を残りの22コアで実行することで、PCの応答性を確保する運用を始めたと報告している。

もっとも、これは一人のユーザーによる経験談であり、同じ設定がほかの環境でも有効とは限らない。CPUの構成や処理内容、使用するアプリケーションによって結果は変わり得る。また、アフィニティを制限すると、Windowsのスケジューラーが使用できるコアの選択肢も減るため、処理性能との兼ね合いを考える必要がある。

今回のChenの説明から分かるのは、Windowsの応答性が単純なCPU優先度だけで決まるわけではないということだ。Windowsには前面アプリの優遇や優先度逆転への対策がすでに組み込まれているが、共有資源の解放待ちやUI処理の競合は、それらの仕組みでも解消できない場合がある。タスクマネージャーの優先度を上げるだけでは不十分な理由は、ここにある。

一方、効率モードやCPUコアの使用制限は、負荷の原因となる処理を調整することで、操作中のアプリに必要な実行資源を確保する方法だ。ただし、Microsoftが説明する効率モードの効果と、ユーザーが報告したコア制限による改善は、検証の水準が異なる。実際に高負荷時の操作遅延を減らすには、自分の環境でどの処理がCPUを占有しているか、どのような待機が発生しているかを見極めたうえで、設定変更の効果を確かめる必要がある。