アイドル時の負荷：最適化前後のWindowsバックグラウンド処理
目次
Windowsのバックグラウンドコンポーネントを無効にすると、アイドル時の動作が実際に静かになります。独立した2回の測定で、プロセス数は49～56 %、アイドル時のCPU使用率は17～67 %低下し、2回目の測定ではメモリコミット量が52 %減少しました。ただし、CPUに最大負荷をかけた状態でのスループット向上はわずか0,2～0,5 %でした。「静かなアイドル状態」とは、バックグラウンド処理とリソース競合が実際に減少したことを示すものであり、FPSの向上を意味するものではありません。この調査では、ゲームへの最終的な影響は測定していません。
ステータス: Windows 11の同一ビルドを使用した仮想マシンで、効果の傾向を独立した2回の測定で再現しました。測定回ごとに数値が異なるのは、Windowsのバックグラウンド処理が断続的に発生するためです。Microsoft Defenderのスキャン中の時間帯ではCPU使用率の差が−67 %に達し、すでに静かな時間帯では−17 %でした。
検証した主張
Section titled “検証した主張”次の4つの主張を検証しました。
- バックグラウンドコンポーネントを無効にすると、アイドル時のシステムアクティビティが大幅に低下する。
- 起動後の最初の数分間のアクティビティが大幅に低下する。
- メモリ消費量が大幅に減少する。
- CPUに最大負荷をかけた状態で、測定可能な性能向上が得られる。
- Windows 11 Pro、build 26300.9457 (26H2);
- 仮想マシン: 4 vCPU、8 GB RAM、VMware仮想化;
- 同一インストール環境の2つの状態: 初期状態（「変更前」）と、BoosterXの最適化プロファイルを適用した状態（測定日時点の最新ビルド）;
- 独立した2回の測定: 2026-09-18および2026-09-19。測定が互いに影響しないよう、独立したディスクコピー上で各状態を比較;
- フェーズ: 起動後5分、安定化5分、アイドル5分;
- 短時間の合成負荷: 1、4、8スレッド、メモリ負荷、周期的な負荷、優先度を混在させた負荷。
実際のゲーム、GPU負荷、物理ハードウェア、長時間（数時間から数日）の測定は対象外です。
Ryzen 7 7800X3D搭載の物理PCで、4段階の測定とゲーム測定を行った別のシリーズは、記事「BoosterX: Windowsのバックグラウンド処理とCS2のFPS」で公開しています。その結果は、仮想マシンで行った本シリーズの結果とは統合していません。
測定手順は「Windowsの調査方法」に準拠しています。
- 各フェーズをETWトレース（Windows Performance Recorder、CPU、ディスク、ファイル、ネットワークの軽量プロファイル）とパフォーマンスカウンターで記録。記録間隔はシステム全体で5秒、プロセスごとに15秒;
- 「起動後」フェーズは制御された再起動で開始し、稼働時間が約1分になった時点から記録;
- 各トレースでイベントの欠落数を確認。以下に示すすべての時間帯で欠落はゼロ;
- フェーズの範囲内にある完全な5秒間隔のみを平均化（1フェーズあたり59区間）;
- シリーズ2では、仮想マシンがスリープ状態になったため、最初の「変更前」測定を除外し、再測定を使用;
- 負荷テストは各2回実施し、中央値を記載。CPU使用率は4 vCPUを基準に正規化。
「変更前」と「変更後」は、同一のWindowsインストール環境の状態です。「変更後」は最適化プロファイルを適用した状態、「変更前」は初期状態です。設定一式をまとめて変更したため、個々の無効化による寄与は評価していません。
シリーズ1（2026-09-18）—アクティブなメンテナンスがない、安定したアイドル状態:
| 指標 | 変更前 | 変更後 | 変化 |
|---|---|---|---|
| CPU使用率、% | 2,48 | 2,06 | −17 % |
| DPC + ISR、CPU % | 1,73 | 1,59 | −8 % |
| コンテキストスイッチ、/秒 | 469 | 381 | −19 % |
| プロセス数（平均） | 134,9 | 69,3 | −49 % |
| スレッド数（平均） | 1 444,6 | 738,7 | −49 % |
| 全プロセスのCPU合計、% | 1,22 | 1,06 | −13 % |
| 使用可能メモリ、MB | 5 490 | 6 518 | +1 028 |
| ディスク読み取り、KB/秒 | 22,6 | 24,4 | +8 % |
| ディスク書き込み、KB/秒 | 311,3 | 262,1 | −16 % |
| ネットワーク（受信）、KB/秒 | 132,6 | 2,2 | −98 % |
| ネットワーク（送信）、KB/秒 | 43,2 | 4,7 | −89 % |
シリーズ2（2026-09-19）—同じアイドル時間帯。ただし「変更前」の状態では、Microsoft Defenderのバックグラウンドスキャンが実行されていました。
| 指標 | 変更前 | 変更後 | 変化 |
|---|---|---|---|
| CPU使用率、% | 33,37 | 11,03 | −67 % |
| コンテキストスイッチ、/秒 | 3 737 | 291 | −92 % |
| プロセス数（平均） | 142,3 | 61,9 | −56 % |
| スレッド数（平均） | 1 494,7 | 637,1 | −57 % |
| 使用可能メモリ、MB | 5 174 | 6 653 | +1 479 |
| 使用中の物理メモリ、MB | 3 017 | 1 538 | −49 % |
| メモリコミット量、MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool、MB | 298,2 | 212,9 | −29 % |
| Paged pool、MB | 258,5 | 86,0 | −67 % |
| DPC、CPU % | 0,89 | 0,19 | −78 % |
| ディスク読み取り、MB/秒 | 7,42 | 0,01 | −99,9 % |
| ディスク書き込み、MB/秒 | 4,57 | 0,23 | −95,0 % |
シリーズ2では、両方の状態でアイドル時のネットワーク通信がほとんどなかった（毎秒数十バイト）ため、ネットワークの行は記載していません。シリーズ間の差は矛盾ではなく、バックグラウンド処理そのものの特性です。Windowsがメンテナンスを実行している時間帯は、バックグラウンドコンポーネントを無効にすることでより多くの処理が削減され、すでに静かな時間帯では削減量が少なくなります。
起動後の最初の数分間
Section titled “起動後の最初の数分間”| 指標 | シリーズ1（変更前 → 変更後） | シリーズ2（変更前 → 変更後） |
|---|---|---|
| CPU使用率、% | 3,42 → 2,59 | 14,62 → 11,88 |
| コンテキストスイッチ、/秒 | 1 114 → 600 | 1 257 → 393 |
| プロセス数 | 132 → 74 | 139 → 64 |
| スレッド数 | — | 1 719 → 746 |
| 使用中の物理メモリ、MB | — | 2 821 → 1 581 |
| 使用可能メモリ、MB | — | 5 370 → 6 610 |
| ディスク読み取り、KB/秒 | — | 826 → 433 |
| ディスク書き込み、KB/秒 | 634 → 418 | 709 → 298 |
| ネットワーク（受信）、KB/秒 | — | 1,15 → ~0 |
ダッシュは、そのシリーズでは該当フェーズの指標を記録していないことを示します。
構成とメモリ
Section titled “構成とメモリ”アイドル時のインベントリスナップショット（シリーズ1）:
| 変更前 | 変更後 | |
|---|---|---|
| プロセス数 | 136 | 70 |
| スレッド数 | 1 679 | 842 |
| working set合計、MB | 3 841 | 1 868 |
| private bytes合計、MB | 1 524 | 660 |
最適化前の主なメモリ消費プロセス: ウイルス対策プロセスMsMpEng.exe（257 MB）、explorer.exe（213 MB）、StartMenuExperienceHost（144 MB）、msedge.exe（133 MB）、SearchHost.exe（122 MB）。最適化後は、explorer.exe（170 MB）、msedgewebview2（119 MB）、SearchHost.exe（115 MB）、StartMenuExperienceHost（106 MB）が上位を占めました。
使用可能メモリは1,0～1,5 GB増加し、コミット量は52 %減少しました。実際に「解放」できるメモリの量や、プロセスのworking set合計が空きメモリと同じではない理由については、「Windowsで実際に解放できるメモリの量」で解説しています。
短時間の合成テスト（シリーズ2、2回の測定の中央値）:
| シナリオ | スループットの変化 | CPU使用率: 変更前 / 変更後 |
|---|---|---|
| 1スレッド | +5,4 % | 21,9 / 22,6 % |
| 4スレッド（最大） | +0,19 % | 88,9 / 89,4 % |
| 8スレッド（最大） | +0,50 % | 88,9 / 88,8 % |
| メモリ負荷 | +11,2 % | 84,8 / 87,5 % |
| 周期的負荷（1 ms間隔） | +5,4 % | 64,3 / 67,7 % |
| 優先度混在 | +8,5 % | 21,2 / 22,5 % |
| バックグラウンド優先度 | +77,1 % | 38,8 / 65,2 % |
4スレッドで最大負荷をかけた場合、有用な処理が4 vCPUの容量の約89 %を、最適化の前後ともに使用しました。残りの約11 %を、仮想マシン内で除去可能な「Windowsのノイズ」とみなすことはできません。ハイパーバイザーのスケジューリングはゲストOSのトレースからは確認できないためです。ワーカースレッドには均等に処理が割り当てられ（スレッド間の処理量のばらつきは0,994～0,997）、飢餓状態は確認されませんでした。また、最適化後のアイドル時にはCPUキューはほぼ空でした。
バックグラウンド処理の内訳
Section titled “バックグラウンド処理の内訳”「変更前」の状態で測定されたバックグラウンドアクティビティの発生源:
- ウイルス対策スキャン — シリーズ2の時間帯における主な発生源。プロセス
MsMpEng.exeは、5分間のアイドル時間帯に212 CPU秒を消費; - 初期状態では、検索サービス、SysMainサービス、テレメトリ、印刷スプーラーなどが動作していました。最適化プロファイルにより、約50のバックグラウンドサービスと58のスケジュールされたタスクが無効状態に切り替わります;
- 起動後のアクティビティには、Windows Updateオーケストレーターが関与します。
バックグラウンドコンポーネントを無効にしても、バックグラウンド処理が完全になくなるわけではありません。最適化後も、アプリケーション互換性評価（メンテナンス時間帯に毎秒約3,7 msのCPU時間）が動作していました。安定したアイドル時に残ったバックグラウンド処理の合計は毎秒4,8 msのCPU時間で、4 vCPUの容量の約0,12 %でした（トレースで測定）。
確認できたこと
Section titled “確認できたこと”- 再現: 独立した2回の測定で、プロセス数は−49…−56 %、スレッド数は−49…−57 %、使用可能メモリは+1,0～1,5 GB。
- 測定: シリーズ2では、アイドル時のコミット量が−52 %、使用中の物理メモリがアイドル時に−49 %、起動後のフェーズで−44 %。
- 測定: アイドル時のCPU使用率は、静かな時間帯で−17 %、スキャン中の時間帯で−67 %。コンテキストスイッチは−19 %および−92 %、DPCは−78 %（シリーズ2の時間帯）。起動後のアクティビティは両シリーズで低下。
- 測定: CPUに最大負荷をかけた状態でのスループット向上は、+0,19 %（4スレッド）および+0,50 %（8スレッド）。部分負荷および混合負荷では+5,4～+11,2 %。
- 測定: バックグラウンド優先度の負荷は77,1 %高速化。変更前の状態では、ウイルス対策スキャンを含むWindows自体のバックグラウンド処理と競合していました。
- 観察: 主なバックグラウンド処理の発生源は、ウイルス対策スキャン、メンテナンス、互換性タスク。最適化後の残存バックグラウンド処理はほぼゼロですが、ゼロではありません。
確認できなかったこと
Section titled “確認できなかったこと”- 実際のゲームにおけるFPS向上、入力遅延やframetimeの低下: 未測定。合成CPUテストはGPUを使用するゲームを再現するものではなく、ゲームへの効果を証明しません。
- 個々の無効化による寄与: 設定一式をまとめて適用しました。
- 絶対値を物理ハードウェア、他のビルド、他の最適化プロファイルに適用すること。
- 長時間にわたる安定性: 各フェーズは5分です。Windowsのバックグラウンド処理は断続的に発生するため、「平均的な1日」は測定していません。
- 測定は仮想マシンで実施しました。仮想化自体がDPC/ISRに影響し、ホスト側のスケジューリングは確認できません。物理ハードウェアでは絶対値が異なります。同一条件で比較した場合の割合と「変更前／変更後」の傾向は維持されます。
- ISR指標は表から除外しました。仮想マシンでは、PDHによるISRカウンターの値がETWで記録した割り込みハンドラーの値と約10 %異なり、正確な合計値にならないためです。
- シリーズ2の「変更前」の時間帯にはDefenderのアクティブなスキャンが含まれており、時間帯ごとのホスト負荷も異なっていました（平均44 %対24 %）。そのため、数値は特定の時間帯に限られます。傾向は2回の測定で確認されています。
- シリーズ1では、アイドルフェーズの一部が仮想マシンの外部一時停止により約26秒中断されました。再開後に記録を終了し、イベントの欠落はありません。
- 負荷テストは2回の測定です。記述統計であり、統計的有意性は評価していません。
- アイドル時の改善の一部は、Microsoft Defenderの保護コンポーネントを無効にしたことによるものです。ウイルス対策保護のないシステムは、意図的なトレードオフであり、コストのない最適化ではありません。保護を無効にする場合は、その代償を理解したうえで行ってください。
- 測定用の仕組み（トレースとカウンター）自体もわずかなバックグラウンド負荷を発生させます。この負荷は両方の状態に存在します。
本調査と使用したツールはBoosterXの開発者が所有しているため、開発者には結果に対する直接的な利害関係があります。方法と適用範囲は上記のとおりです。結論は、公開データと記載した公開情報源を使って検証できます。
実用上の結論
Section titled “実用上の結論”バックグラウンドノイズの削減は、2回の測定で再現された実際の効果です。プロセス数とスレッド数は半減し、メモリコミット量も半減し、アイドル時のディスクおよびネットワークアクティビティは1桁以上減少しました。これはシステムの応答性、バックグラウンドタスク、温度、ファンの騒音、バッテリー駆動時間にとって、それ自体に価値があります。FPS向上を約束する必要はありません。
期待すべきでないのは、最大負荷時の性能向上です。CPUがすでに有用な処理で容量の約89 %まで使用されている場合、バックグラウンドアクティビティを無効にしても、残りの11 %が追加されるわけではありません。仮想マシンでは、その分はWindowsに属していません。比較時にシステムがどのような処理を行っているかによって、見える効果は変わります。メンテナンス中の時間帯では差が数倍になり、静かな時間帯では中程度です。
推奨事項: 他の人の割合を参考にするのではなく、自分のコンピューターで変更の前後にバックグラウンド処理を評価してください（タスク マネージャー →「パフォーマンス」と「プロセス」、リソース モニター）。特定のゲームのFPSが目的なら、変更の前後でそのゲームのFPSを測定してください。
両シリーズは、独立したディスクコピーを使用した隔離済みの仮想マシンで実施しました。測定後、各仮想マシンを初期状態に戻しました。この記事では読者に設定変更を求めていないため、ユーザーのコンピューターで個別に復元操作を行う必要はありません。
公開されている一次情報源
Section titled “公開されている一次情報源”- Microsoft: Windows Performance Recorder — 方法で使用したETWトレース記録ツール。確認日: 2026-09-20。
- Microsoft: About Event Tracing — ETWモデルとイベント欠落の確認。確認日: 2026-09-20。
- Microsoft: WindowsのMicrosoft Defender Antivirus — Defenderのプロセスとサービス。タスク マネージャーで「Antimalware Service Executable」と表示される
MsMpEng.exeを含む。確認日: 2026-09-20。 - Windowsの調査方法 — 証拠のレベルと測定手順。
- Service HostとWindows 11のバックグラウンドコンポーネント — Windowsがバックグラウンドサービスをプロセスに割り当てる仕組み。
- Windowsで実際に解放できるメモリの量 — 同じ実験におけるメモリの詳細な分析。
- デスクトップとサインイン画面の比較 — 続編: ユーザーセッションのノイズの内訳。
- 2026-09-20: 初版公開 — アイドル時の独立した2回の測定、起動後のフェーズ、インベントリ、負荷テスト。
- 2026-09-20: シリーズごとの結果の帰属を明確化（コミット量と使用中の物理メモリはシリーズ2のみ。プロセス数は−49…−56 %）。利益相反に関する免責事項を標準の表現に統一。