静かなアイドル状態：最適化前後の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負荷、物理ハードウェア、長時間の時間枠（数時間から数日）は含まれていません。
プロトコルは「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で実際に解放できるメモリはどれくらいか」で詳しく解説されています。
完全な負荷時
Section titled “完全な負荷時”短時間の合成テスト（シリーズ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ノイズ」と宣言することはできません。ハイパーバイザーのスケジューリングはゲストトレースからは見えません。ワーカースレッドは均等に分散され（スレッド間の作業量のばらつきは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）：アイドル時のcommit −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向上、input lagや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度再現された実際の効果です。プロセスとスレッドは半分になり、メモリコミットは半分になり、アイドル時のディスクとネットワークの活動は桁違いに減少します。これはそれ自体で有用であり — システムの応答性、バックグラウンドタスク、温度、ファンの騒音、バッテリー駆動時間にとって — FPSの約束を必要としません。
これに期待すべきでないこと：完全な負荷時のパフォーマンス向上。CPUがすでに容量の約89 %まで有用な作業で負荷されている場合、バックグラウンド活動の無効化は残りの11 %を追加しません — 仮想マシンではそれはWindowsに属していません。比較の瞬間にシステムが何で忙しいかによって、見える効果は大きくなります。メンテナンス時間枠では差は何倍にもなり、静かな時間枠では moderate です。
推奨：自分のコンピューターで変更の前後でバックグラウンドを評価してください（タスクマネージャー → 「パフォーマンス」と「プロセス」、リソースモニター）。他人のパーセンテージに頼らないでください。特定のゲームの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のプロセスとサービス、
MsMpEng.exe（タスクマネージャーでは「Antimalware Service Executable」）を含む；確認日 2026-09-20。 - Windowsをどのように調査するか — 証拠レベルと測定プロトコル。
- Service HostとWindows 11のバックグラウンドコンポーネント — Windowsがバックグラウンドサービスをプロセスにどのように配置するか。
- Windowsで実際に解放できるメモリはどれくらいか — この同じ実験からのメモリの詳細な分析。
- デスクトップ対サインイン画面 — 続き：ユーザーセッションのノイズは何で構成されているか。
- 2026-09-20: 初回公開 — アイドルの2つの独立した測定シリーズ、起動後フェーズ、インベントリ、負荷テスト。
- 2026-09-20: シリーズ別の結果の帰属を明確化（commitと使用中物理メモリはシリーズ2のみ；プロセス −49…−56 %）；利益相反に関する免責事項を標準的な文言に統一。