SSD256GB環境で発生した深刻な容量不足
今回のトラブルが深刻だった理由は、
SSD256GBという比較的容量の小さい環境でWSL2＋Dockerを運用していた点です。
ディスクが逼迫した結果、
- WSLが頻繁にクラッシュする
- 開発用コンテナが起動しない
- Windows Updateが容量不足で失敗する
- セキュリティソフトの定義ファイル更新すら行えない
という、Windows全体の運用に支障が出る状態に陥っていました。
今回のWSLクラッシュの原因
原因は複合的でした。
- メモリ16GB環境でのメモリ不足
- WSL2・Dockerが使用するVHDXファイルの肥大化
- EC-CUBEエンタープライズ版特有の環境設定による負荷増大の可能性
特にVHDXの肥大化は気づきにくく、
SSD256GB環境では致命的になりやすいと感じました。
VHDX肥大化を解消する全体の流れ
今回行ったクリーンアップは、次の3ステップです。
- Windows側の一時ファイル削除
- WSL／Docker内部の不要データ削除
- WSLを完全停止し、VHDXを物理的に最適化（圧縮）
手順① 一時ファイル（Temp）の削除
対象パス
C:\Users\[USER_NAME]\AppData\Local\TempDockerやWSL関連アプリを終了した状態で、
Windowsの「記憶域」設定から削除します。
手順② 仮想ディスク内部のクリーンアップ
Docker（docker_data.vhdx）
docker system prune -a --volumes未使用のコンテナ・イメージ・ボリュームを削除します。
WSL2（ext4.vhdx）
sudo apt autoremove
sudo apt clean不要なパッケージとキャッシュを削除し、
VHDX内部に空き領域を作ります。
手順③ WSL完全停止とVHDXの最適化
注意点wsl --shutdown を実行する際、VS Code などで WSL 内のディレクトリを開いたままにしていると、WSL が自動的に再起動されてしまいます。
VHDX の最適化を確実に行うためには、
- VS Code（Remote – WSL 接続）
- WSL を参照しているターミナルやエクスプローラー
これらをすべて閉じた状態で wsl --shutdown を実行する必要があります。VScodeなどでWLS内のディレクトリを開いている場合は、wslが再起動されるので閉じる必要がある。
管理者権限のPowerShellで以下を実行します。
wsl --shutdown停止確認：
wsl --list --runningVHDX最適化の結果（圧縮前・圧縮後）
実際にどの程度効果があったのか、
圧縮前後のVHDXファイルサイズを比較します。
圧縮前
- Docker VHDXファイル：12.14GB
- WSL VHDXファイル：117.19GB
圧縮後
- Docker VHDXファイル：12.14GB（変化なし）
- WSL VHDXファイル：28.74GB
WSLのVHDXは、
約88GBの削減となりました。
なお、WSL側は
必要なコンテナまで削除した状態でのサイズです。
環境によっては、ここまで削減できない場合もあります。
大容量ファイルの洗い出し
以下のディレクトリへ移動します。
cd C:\Users\[USER_NAME]\AppData\5GB以上のファイルを一覧表示します。
Get-ChildItem -Recurse -File |
Where-Object { $_.Length -gt 5GB } |
Select-Object FullName, LastWriteTime,
@{N='Size(GB)';E={[math]::Round($_.Length / 1GB, 2)}} |
Sort-Object 'Size(GB)' -Descending |
Format-Table -AutoSize定期メンテナンスの重要性
今回の対応で、
SSD256GB環境でも実用レベルまで復旧できました。
ただし、DockerとWSLを使い続ける限り、
VHDXは再び肥大化します。
- 月1回のDockerクリーン
- WSL完全停止＋VHDX最適化
この2点は、
SSD容量が小さい環境ほど必須だと感じました。
まとめ
- WSL2のVHDXは117GBまで肥大化していた
- Optimize-VHDにより約88GB削減できた
- SSD256GB環境では放置するとWindows全体に影響する
- クラッシュ後ではなく、定期的な最適化が重要
WSLが重くなったと感じた時点で対応することが、
結果的に一番楽だと思います。
