Windowsで実際に解放できるメモリ量はどれくらいか
目次
実際に解放できるメモリは「メモリ最適化ツール」が約束するよりも少ない。この実験では、バックグラウンドコンポーネントを無効化することで、シリーズ2において利用可能メモリが1.0～1.5 GB解放され、コミット量（commit）が52 %削減された。しかし、よく知られた手っ取り早い方法は機能しない。シェルプロセスの終了 — Windowsは約20秒で自動的に再起動する。working setのクリア — ページアウトされたページはキャッシュとしてRAMに残る。メモリマネージャーのレジストリパラメータ — 確認された利点はない。すでに最適化されたシステム上での個別の無効化は、正直なところ+22～30 MBであった。standbyリスト内のメモリはキャッシュであり、「利用可能」にすでに含まれている。
ステータス: 最終的な数値は、Windows 11（26H2、build 26300.9457）を搭載した8 GB RAMの仮想マシンで取得された。方向性はMicrosoftのドキュメントと当社の管理された実験によって確認されている。別の構成での絶対値は異なる。
検証可能な主張
Section titled “検証可能な主張”私たちは4つの主張を検証した：
- 「不要な」バックグラウンドプロセスを終了するとメモリが解放される。
- working setまたはstandbyリストのクリア（「RAM最適化ツール」の仕組み）でメモリが解放される。
- メモリマネージャーのレジストリパラメータがメモリを著しく解放する。
- バックグラウンドコンポーネントを無効化すると大量のメモリが解放される。
- Windows 11 Pro、build 26300.9457（26H2）、仮想マシン、8 GB RAM；
- 同一インストールの2つの状態：初期状態（「前」）とBoosterX最適化プロファイル適用後 — 測定は2つの独立したシリーズで実施（詳細なプロトコルとその他の指標は「静かなアイドル：最適化前後のWindowsのバックグラウンド」に記載）；
- 「後」の状態の上に、バックグラウンドソースの個別無効化パッケージ（診断用ETW自動ロガー、通知サービス、シャドウコピー、更新オーケストレーター）；
- 指標：利用可能メモリと使用中メモリ、コミット量（commit）、nonpaged/paged pool、プロセスごとのworking setとprivate bytes、ページフォールト（hard faults）。
除外したもの：物理ハードウェア、異なるRAM容量のシステム、pagefile無効化の実験、サードパーティの「メモリ最適化」ユーティリティ。
- メモリインベントリは安定したアイドル状態で取得した：システムカウンター（利用可能、使用中、commit、プール）とworking setおよびprivate bytesを含むプロセスリスト。
- 管理された実験「シェルプロセスの終了」：2つのインターフェースプロセス（
SearchHost.exeとStartMenuExperienceHost）を停止し、20秒後と40秒後に状態を確認；commitは前後で記録。 - 個別無効化パッケージを「後」の状態に適用し、その後再起動して、パッケージなしの同じ状態の4回の対照起動と比較；起動テストでパフォーマンスのリグレッションがないことを確認。
- 測定レイヤー（トレース、カウンター、収集スクリプト）自体がメモリを消費する — 個別の測定ではworking setが数百MB以上に達することもある；これは制限事項に記載されている。
バックグラウンドが占める量
Section titled “バックグラウンドが占める量”アイドル時のインベントリスナップショット（シリーズ1）：
| 前 | 後 | 変化 | |
|---|---|---|---|
| 合計working set、MB | 3 841 | 1 868 | −51 % |
| 合計private bytes、MB | 1 524 | 660 | −57 % |
| 利用可能メモリ、MB | 5 490 | 6 518 | +1 028 |
シリーズ2：使用中メモリ3 017 → 1 538 MB、利用可能5 174 → 6 653 MB、コミット量2 617 → 1 249 MB。方向性は両シリーズで一致している：バックグラウンドコンポーネントはこのプロファイルの使用中メモリの約半分を保持している。
使用中メモリの構造
Section titled “使用中メモリの構造”「後」の状態では、メモリは次のように分布していた（合計working set、シリーズ1）：
- シェル（エクスプローラー、DWM、「スタート」メニューの検索、セッションホスト）— 約640 MB；
- バックグラウンドサービス — 約640 MB（39のホストプロセス内の57サービス）；
- 検索のウェブコンポーネント — 約320 MB；
- カーネルプール — 約167 MB、うち約76 MBはレジストリプール。
プロセスのworking setは解放可能なメモリとは等しくない：これには共有ページ（システムライブラリのコード、共有データ）が含まれ、それらは各プロセスで同時にカウントされる。「後」の状態のシリーズ1では、75プロセスのworking setの合計は1 868 MB、private bytesの合計は660 MBであった；個別無効化実験の対照起動では、合計working setは2 036 MBであった。最大のインターフェースプロセス（シリーズ2）：
| プロセス | Working set、MB | Private、MB |
|---|---|---|
SearchHost.exe（検索） |
187 | 80 |
explorer.exe（エクスプローラー） |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe（DWM） |
73 | 34 |
「後」の状態では、standbyリストは711 MBであった。これは失われたメモリではなくキャッシュである：standbyはすでに「利用可能」に含まれており、アプリケーションがメモリを要求するとWindowsはこれらのページを即座に再利用する。
実験：シェルプロセスの終了
Section titled “実験：シェルプロセスの終了”SearchHost.exeとStartMenuExperienceHostの停止後（シリーズ2）：
- 両方のプロセスは約20秒で新しい識別子で自動的に再起動した；40秒後もまだ動作していた；
- コミット量は減少せず、12.6 MB増加した（1 386.9から1 399.5 MBへ）— シェルプロセスの再起動自体が新たな作業を生み出す；
- 「利用可能」メモリの93 MBの一時的な増加は節約ではない：対象プロセスが戻り、commitは増加した。
別の測定でのエクスプローラーの終了（シリーズ1）も、空きメモリの持続的な増加をもたらさなかった：このウィンドウでは、standbyが13 MB増加する一方で空きメモリは97 MB減少した — ページアウトされたページはキャッシュとしてシステムに残り、シェルと関連プロセスは動作を続ける。
実験の結論：システムプロセスの強制終了はメモリを解放しない。Windowsはシェルコンポーネントを自動的に再起動し、節約の代わりに追加の負荷が発生する。
working setとstandbyリストのクリア
Section titled “working setとstandbyリストのクリア”仕組みはMicrosoftによって文書化されている。working setからのページのページアウト（例えば、関数EmptyWorkingSetまたは「空の」サイズを指定したSetProcessWorkingSetSize — まさに「RAM最適化ツール」が使用するもの）は、ページを遷移状態に移す：それらは再び必要になるか再利用されるまで、RAMにキャッシュされたままである。プロセスがそのようなページに次にアクセスすると、ソフトページフォールトとなり、working setに戻る。
したがって、working setのクリアはカウンターの「空き」の数値を変えるが、物理的に利用可能なメモリを生み出さない：ページはどこにも消えず、それらへの再アクセスはより高コストになる。standbyリストのクリアも同じ理由で無意味である：standbyはすでにシステムが利用可能なメモリである。当社の測定では、両方の状態でメモリのpressureは存在しなかった（hard faultsは低いままであった）ため、追加のページアウトは何も改善しなかった。
この実験からの私たちの基準：「メモリ解放」の結果は、一時的な「空き」行の増加ではなく、commit、ページフォールト、メモリの再使用時の遅延によって評価する必要がある。
個別の無効化：正直な増加
Section titled “個別の無効化：正直な増加”「後」の状態の上に、私たちは9つの診断用ETW自動ロガーと4つのバックグラウンドサービス（通知、シャドウコピー、更新オーケストレーター）を無効化し、結果を4回の対照起動と比較した：
| 指標 | 対照起動 | パッケージ適用時 | 差 |
|---|---|---|---|
| 空きメモリ、MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool、MB | 69,8–71,8 | 58,7 | −11…−13 |
| 合計working set、MB | 2 036 | 1 959 | −77 |
| テストのパフォーマンス | 変化なし | 変化なし | — |
自動ロガーのみが−13.2 MBのnonpaged poolをもたらした（別途測定）。重要：インベントリによる無効化されたコンポーネントのworking setの合計は約78 MBであったが、実際の空きメモリの増加は+22～30 MBであった。この差は、「無効化された」ものの一部がそもそも起動していなかったために生じる。これが、システムコンポーネントを削除せずに行う個別無効化の正直な限界である；副次的に、同じパッケージはアイドル時のバックグラウンド活動をさらに24 %削減した。
メモリマネージャーのレジストリパラメータ（プールサイズ、システムキャッシュなど）は、この実験では利益の源泉としてさえ検討されなかった：それらの読み取りと実用的な有用性は「Memory Managerとシステムcache」で分析されている — RAM解放に対する確認された利点はない。
確認されたこと
Section titled “確認されたこと”- 再現済み（2シリーズ）：バックグラウンドコンポーネントの無効化により1.0～1.5 GBの利用可能メモリが解放される；合計working setは51 %削減（シリーズ1）、使用中メモリは49 %、コミット量（commit）は52 %削減（シリーズ2）。
- 測定済み： 停止されたシェルプロセスの20秒以内の自動再起動；commitは減少しない（当社の実験では12.6 MB増加）。
- 測定済み： エクスプローラーの終了は空きメモリの持続的な増加をもたらさない；ページアウトされたページはstandbyに残る。
- 文書化済み： working setからのページのページアウトはそれらを遷移状態に移し、RAMにキャッシュされる；standbyメモリは利用可能に含まれる。
- 測定済み： 最適化されたシステム上での個別の無効化は、パフォーマンスを変えずに+22～30 MBの空きメモリをもたらす；無効化されたもののworking setの合計は空きの増加とは等しくない。
確認されなかったこと
Section titled “確認されなかったこと”- サードパーティの「RAM最適化ツール」は直接テストされていない：それらが基づく仕組み（working setのクリア）が検証された。
- pagefileの無効化は測定されていない；pagefileがクラッシュダンプとメモリコミットの上限に必要であることだけが知られている。
- 異なるRAM容量、異なるビルド、物理ハードウェアのマシンへの値の移行。
- 長いウィンドウでの節約の持続性：測定は安定したアイドル状態で実施された。
- 8 GB RAMの仮想マシン：絶対数値はこの構成に紐づく；バックグラウンドコンポーネントの多いプロファイルはより多く解放し、「静かな」システムはより少ない。
- プロセスごとのworking setの合計は、共有ページのために固有のフットプリントを過大評価する；私たちがprivate bytesを併記するのはまさにこの理由からである。
- 測定レイヤー自体がかなりのメモリを消費した（個別の測定ではworking setが数百MBに達した）— 状態の数値には測定の存在が含まれている。
- 実験ではメモリのpressureはなかった（hard faultsは低い）ため、RAM不足時に節約がスラッシングを減らすかどうかは検証していない。
- 解放の一部はMicrosoft Defenderの保護コンポーネントの無効化に関連している — これはセキュリティとのトレードオフであり、無償で得られたメモリではない。
調査と使用されたツールはBoosterXの開発者に帰属し、BoosterXはWindowsオプティマイザーであるため、最適化効果の測定はその直接の関心事である。方法論と適用範囲は上記に記載されており、結論は公開データと列挙された公開ソースによって検証できる。一般的な「メモリ解放」方法に関する否定的な結果は、肯定的な結果と同等に公開されている。
実用的な結論
Section titled “実用的な結論”この実験により、実際にメモリを解放するもの：
- 未使用のアプリケーションを閉じる — そのprivate bytesは完全に解放される；
- 本当に不要なバックグラウンドコンポーネントを無効化する — 測定された総合効果は「静かなアイドル」に記載されている；これは検証された中で唯一ギガバイトをもたらした方法であり、その代償は対応する機能の喪失である；
- 結果は「空き」行ではなく、commitと利用可能メモリ（タスクマネージャー → 「パフォーマンス」 → 「メモリ」）で評価する。
機能しないもの：
- システムプロセスの強制終了：Windowsは数秒でそれらを再起動し、commitは増加する；
- 「RAM最適化ツール」とstandbyのクリア：ページアウトされたページはキャッシュとしてRAMに残り、それらを再び動作させるにはソフトページフォールトのコストがかかる；
- メモリマネージャーのレジストリパラメータ。
Standbyメモリは問題ではなくキャッシュの働きである：「利用可能」はすでにそれを含んでいる。Pagefileはシステム管理のままにしておく：それはメモリコミットの上限とクラッシュダンプに必要である。
実験は状態のテストブランチ上の隔離された仮想マシンで実施された；測定後、テストブランチはリセットされ、マシンは初期状態に戻された。この記事はシステムプロセスの終了やpagefileの無効化を推奨していないため、ユーザーのコンピューターでの個別の復元操作は不要である。
公開一次ソース
Section titled “公開一次ソース”- Microsoft: Working Set — working setの構成、ページのページアウト、RAMにキャッシュされる遷移ページ、および関数
EmptyWorkingSet/SetProcessWorkingSetSize；確認日2026-09-20。 - Microsoft: EmptyWorkingSet — 「メモリ最適化」ユーティリティが使用するAPI；確認日2026-09-20。
- Microsoft: About Memory Management — 仮想メモリと共有ページのモデル；確認日2026-09-20。
- Microsoft: Introduction to the page file — commit charge、コミットの上限、pagefileの役割；確認日2026-09-20。
- Memory Managerとシステムcache — メモリマネージャーのレジストリパラメータの調査。
- 静かなアイドル：最適化前後のWindowsのバックグラウンド — 測定プロトコルと同じ実験のその他の指標。
- 私たちがWindowsを調査する方法 — 証拠のレベルと測定ルール。
- 2026-09-20: 数値をシリーズの表に合わせた：シリーズ1の「後」— 1 868/660 MB、指標とシリーズごとのパーセントの帰属を明確化；利益相反に関する免責事項を完全な文言に強化。
- 2026-09-20: 初回公開 — 2シリーズでのメモリインベントリ、プロセス終了とクリアに関する否定的な実験、個別無効化の正直な増加。