「WSLを起動しておくだけでPC全体が重くなる」「タスクマネージャーの VmmemWSL が何GBも食っている」「Linux側でファイルを消したのにCドライブの空きが戻らない」——WSLを日常的に使っている人なら、一度はぶつかる問題です。

これらはすべて「重い」と一括りにされがちですが、原因はメモリ・ファイルI/O・ディスクの3つにはっきり分かれ、対処法もそれぞれ違います。本記事では切り分け方から、.wslconfig のマシン別テンプレート、そしてネットに多い誤った情報までを、Microsoft公式ドキュメントにあたって整理します。

WSLが重いと感じるとき、実態は次の3つのどれかです。ここを先に切り分けないと、効かない設定を廻って時間を浪費します。

flowchart TB
    A["WSL が重い"] --> B{"何が起きているか"}
    B -->|"Windows 全体が重い<br>VmmemWSL が大きい"| C["原因① メモリ<br>→ .wslconfig で上限を切る"]
    B -->|"git や npm のコマンドが遅い"| D["原因② ファイルI/O<br>→ /mnt/c をやめる"]
    B -->|"C ドライブの空きがない"| E["原因③ ディスク<br>→ VHDX を sparse 化する"]

• 原因① メモリ：WSLを起動しているとWindows側のアプリが重くなる。タスクマネージャーに VmmemWSL が大きく出る
• 原因② ファイルI/O：git status や npm install が体感でわかるほど遅い。メモリは空いている
• 原因③ ディスク：動作は普通だが、Cドライブの空き容量がじりじり減る

推測で設定をいじる前に、数字を見ます。

メモリ（Windows側）

タスクマネージャーの「詳細」タブで VmmemWSL を探します（古い環境では Vmmem）。これがWSLのVMがWindowsから実際に占有している量です。

メモリ（Linux側）

free -h

ディスクの使用量

# PowerShell で実行（<distro> は wsl -l -v で確認した名前）
wsl.exe --system -d <distro> df -h /mnt/wslg/distro

このコマンドが使えない場合は wsl --update でStore版にWSLを更新するか、wsl df -h / を試してください。

ここが最も誤解されている点です。Microsoft公式ドキュメントによると、.wslconfig の主要な既定値は次のとおりです。

つまり、何も設定していなければ、WSLはRAMの半分まで膨らむのが仕様どおりの振る舞いです。故障ではありません。上限を切りたければ、明示的に memory を指定する必要があります。

ネットでよく見る「[experimental] に autoMemoryReclaim=gradual を追加すればメモリが戻る」という助言は、前提が古いです。

この機能は2023年9月のWSLアップデートで導入され、現在の公式ドキュメントでは既定値が dropCache（キャッシュを即時回収）となっています。つまり回収はすでに動いています。

では gradual に意味がないかというと、そうではありません。dropCache は即時にキャッシュを捨てるため、ビルドなどで同じファイルを繰り返し読むワークロードだと、捨てては読み直す動きになりがちです。体感速度を優先するなら gradual を検討する価値があります。

いずれにしても、メモリを減らしたいならまず memory で上限を切るのが先です。

「メモリは空いているのに git status が遅い」場合、ほぼ間違いなくこれです。

WSL2はHyper-Vの軽量VM内でLinuxを動かしているため、Windows側のファイル（/mnt/c/...）へのアクセスはOSをまたぐ分だけ遅くなります。Microsoft公式の比較表でも、「OSをまたぐファイルシステム性能」は WSL1 ✅ / WSL2 ❌ と明記されています。

flowchart LR
    A["プロジェクトを<br>/mnt/c/Users/... に置く"] -->|"OS をまたぐ<br>遅い"| B["Windows ファイルシステム"]
    C["プロジェクトを<br>~/projects/... に置く"] -->|"ネイティブ<br>速い"| D["Linux ファイルシステム"]

対処はシンプルです。プロジェクトをLinux側に移すだけ。

# 悪い例：Windows 側に置いている
cd /mnt/c/Users/yourname/projects/myapp

# よい例：Linux 側に置く
cd ~/projects/myapp

VS Codeからは WSL 拡張機能で接続すれば、Linux側に置いたままWindowsのGUIで編集できます。速度を捨てずに使い勝手を保てるので、これが推奨構成です。

WSL2はディストリビューションごとに ext4.vhdx という仮想ディスクを作ります。このファイルは使うにつれて大きくなりますが、Linux側でファイルを削除しても自動では小さくなりません。これが「消したのにCドライブが空かない」の正体です。

2023年9月のWSLアップデートで、使った分だけ自動で縮むVHDのサポートが入りました。既存のディストリに適用するには次のとおりです。

# 先に完全に停止させる
wsl --shutdown

# 既存のディストリを sparse 化する
wsl --manage <distro> --set-sparse true

今後作るディストリをすべてsparseにしたい場合は、.wslconfig に次を入れます。

[experimental]
sparseVhd=true

VHDの上限（既定1TB）に到達しているなら、拡張するのが正解です。WSL 2.5以降ならコマンド一発です。

wsl --shutdown
wsl --manage <distro> --resize 2TB

サイズは B/M/MB/G/GB/T/TB の形式で指定します。小数点（2.5TB など）は現時点で非対応です。

.wslconfig は %UserProfile%\.wslconfig（通常は C:\Users\<ユーザー名>\.wslconfig）に作ります。既定では存在しないので、自分で新規作成します。

以下は、搭載RAM別の実用的な出発点です。いずれもWindows側に十分な余地を残すことを優先しています。

RAM 8GB のマシン

[wsl2]
memory=4GB
processors=2
swap=2GB

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

RAM 16GB のマシン（標準的な開発機）

[wsl2]
memory=8GB
processors=4
swap=4GB

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

RAM 32GB 以上のマシン

[wsl2]
memory=16GB
processors=8
swap=8GB

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

ファイルを保存しただけでは反映されません。WSLのVMが完全に停止してから再起動する必要があります。

Microsoft公式はこれを「8秒ルール」と呼んでいます。ディストリのシェルをすべて閉じてから、サブシステムが停止するまで約8秒かかるためです。

# 確実な方法：全ディストリとVMを即時に停止
wsl --shutdown

# 本当に止まったか確認する
wsl --list --running
# 「実行中のディストリビューションはありません」と出ればOK

特定のディストリだけ止めたい場合は wsl --terminate <distro> を使います。

最も多いミスです。別物です。

メモリを減らそうとして /etc/wsl.conf に memory=8GB と書いても、何も起きません。

これが厄介です。公式ドキュメントにはこうあります。

If the file is missing or malformed (improper markup formatting), WSL will continue to launch as normal without the configuration settings applied.

（訳：ファイルがないか、書式が不正な場合、WSLは設定を適用せずに普段どおり起動します）

つまり、タイポしても黙って無視されるのです。「設定したのに効かない」ときは、まずセクション名 [wsl2] の綴りとキー名を見直してください。

サイズ値は単位を省略するとバイト扱いです。

memory=8      # ✖ 8バイトと解釈される
memory=8GB    # ⭕ 正しい

パスを指定するキー（swapFile や kernel）では、バックスラッシュを二重にする必要があります。

swapFile=C:\temp\wsl-swap.vhdx     # ✖
swapFile=C:\\temp\\wsl-swap.vhdx   # ⭕

上の「8秒ルール」です。ディストリを閉じてすぐ開き直しても、サブシステムがまだ生きているため新設定は読まれません。

• 「WSLが重い」はメモリ・ファイルI/O・ディスクの3つに切り分けるところから始める
• メモリは既定でRAMの50%まで膨らむ仕様。.wslconfig の memory で上限を切るのが最も効く
• 「autoMemoryReclaim を追加しろ」は半分古い。既定はすでに dropCache で回収は動いている。gradual は体感速度優先の選択肢
• ファイルI/Oが遅いなら、プロジェクトを /mnt/c からLinux側に移すだけで大幅に改善する
• ディスクは自動では縮まない。wsl --manage <distro> --set-sparse true で自動縮小を有効化する
• 反映には wsl --shutdown が必要。書式ミスはエラーを出さずに無視されるので注意

まずは16GBマシン向けテンプレートをそのまま置いて wsl --shutdown し、タスクマネージャーで VmmemWSL が落ちているかを見てみてください。

目安は搭載RAMの半分以下です。16GBマシンなら 8GB、エディタ中心の使い方なら 6GB まで下げても実用上困りません。ドックコンテナやローカルLLMを回す場合は多めに確保してください。下げすぎてOOMが出るようなら増やす、という順で調整するのが安全です。

典型的な原因は3つです。（1）wsl --shutdown をしていない、（2）ファイルを /etc/wsl.conf に置いている（正しくは %UserProfile%\.wslconfig）、（3）書式ミスで黙って無視されている。この順に確認してください。

用途次第ですが、基本的には推奨しません。 WSL1はOSをまたぐファイルアクセスが速い一方で、Linuxカーネルがなく、Dockerが使えず、システムコール互換性も部分的です。「どうしてもWindows側のファイルを直接扱う必要がある」ケース以外は、WSL2のままプロジェクトをLinux側に移す方が良い結果になります。

基本は残しておいて問題ありません。既定ではメモリサイズの25%が割り当てられます。ただしスワップ用のVHDが %Temp% に作られるため、ディスク容量を節約したい場合は swap=0 で切るという選択もあります。その場合はメモリ不足時にプロセスが落ちやすくなる点に注意してください。

どちらもWSLの仮想マシンが使っているメモリを表します。新しいWSLでは VmmemWSL という名前で表示され、古い環境や他のHyper-VのVMと混ざる環境では Vmmem と表示されます。

📄WSLとは？簡単に図解で解説｜WindowsでLinuxを使うメリットとWSL2インストール手順【2026年版】

📄WSL3は存在しない｜Microsoftが公式否定した誤報の正体とWSL container（wslc）の実際【2026年7月訂正】

📄WSL container（wslc.exe）とは？導入手順と使い方を解説【パブリックプレビュー対応・2026年7月更新】

📄WSLでローカルAIを動かす｜GPUパススルーの実際と手順【WSL3・NPUパススルーは誤報：2026年7月訂正】

• Microsoft Learn — Advanced settings configuration in WSL（.wslconfig / wsl.conf の公式仕様）
• Microsoft Learn — How to manage WSL disk space
• Microsoft Learn — Basic commands for WSL
• Microsoft Learn — Comparing WSL Versions
• Windows Command Line Blog — WSL September 2023 update（sparse VHD / autoMemoryReclaim の導入）

• WSLとは？WindowsでLinuxを使う方法を図解で解説
• WSL3は存在しない｜誤報の正体とWSL containerの実際