開発者のためのディスク容量削減ガイド — node_modules・Docker・WSL2・キャッシュを一掃する
はじめに
「また容量が足りない…」
開発者なら誰もが経験するこの悩み。気づけばSSDの空き容量が数GBしかなく、ビルドが止まったり、新しいプロジェクトをクローンできなくなったり。
主な原因は以下の通りです。
- node_modules: プロジェクトごとに数百MB〜数GB
- Dockerイメージ・キャッシュ: 数十GBに膨らむことも珍しくない
- WSL2 仮想ディスク: 自動拡張するが縮小しない隠れた容量泥棒
- 各種キャッシュ: npm、pip、Homebrew、IDE…
この記事では、開発環境のディスク容量を数十GB単位で削減できる実践的なテクニックを紹介します。
現状把握：何が容量を食っているか
まずは敵を知ることから。容量を圧迫している原因を特定しましょう。
Mac / Linux
# ホームディレクトリ配下の容量確認
du -sh ~/* 2>/dev/null | sort -hr | head -20
# 隠しフォルダも含めて確認
du -sh ~/.* 2>/dev/null | sort -hr | head -10Windows (PowerShell)
# ユーザーフォルダの容量確認
Get-ChildItem $env:USERPROFILE -Directory |
ForEach-Object {
$size = (Get-ChildItem $_.FullName -Recurse -Force -ErrorAction SilentlyContinue |
Measure-Object -Property Length -Sum).Sum / 1GB
[PSCustomObject]@{Name=$_.Name; SizeGB=[math]::Round($size,2)}
} | Sort-Object SizeGB -DescendingGUI ツール
コマンドラインが苦手な場合は、視覚的にディスク使用状況を確認できるツールが便利です。
| OS | ツール | 特徴 |
|---|---|---|
| Windows | WinDirStat, TreeSize | ツリーマップで視覚化 |
| Mac | GrandPerspective, DaisyDisk | 美しいUI、直感的操作 |
| Linux | Baobab (GNOME Disk Analyzer) | 標準搭載されていることが多い |
node_modules の容量削減
問題の規模
典型的なフロントエンドプロジェクトの node_modules は 300MB〜1GB になることも珍しくありません。10個のプロジェクトがあれば、それだけで数GB〜10GB です。
解決策1: 不要なプロジェクトの node_modules を削除
アクティブでないプロジェクトの node_modules は削除してしまいましょう。必要になったら npm install すればいいだけです。
# 特定ディレクトリ配下の全 node_modules を検索
find ~/projects -name "node_modules" -type d -prune
# 容量も一緒に表示
find ~/projects -name "node_modules" -type d -prune -exec du -sh {} \;
# 一括削除（危険！確認してから実行）
find ~/projects -name "node_modules" -type d -prune -exec rm -rf {} \;解決策2: pnpm への移行
pnpm は node_modules をグローバルストアでシンボリックリンク管理します。同じパッケージを複数プロジェクトで使っていても、実体は1つだけ。
# pnpm のインストール
npm install -g pnpm
# 既存プロジェクトで pnpm に移行
cd your-project
rm -rf node_modules package-lock.json
pnpm install効果: モノレポや複数プロジェクトを扱う環境では、50%以上のディスク容量削減が報告されています。
解決策3: npm キャッシュのクリア
npm はダウンロードしたパッケージをキャッシュしています。これが 500MB〜2GB になることも。
# キャッシュサイズの確認
npm cache ls 2>/dev/null | wc -l
du -sh ~/.npm
# キャッシュのクリア
npm cache clean --forceDocker の容量削減
Docker は最も容量を消費しやすいツールの一つです。放置すると 数十GB〜100GB以上 になることも。
現状確認
# Docker が使用している容量を確認
docker system df
# 詳細表示
docker system df -v出力例:
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 45 5 12.5GB 8.2GB (65%)
Containers 8 2 1.2GB 850MB (70%)
Local Volumes 12 3 4.5GB 3.1GB (68%)
Build Cache - - 8.3GB 8.3GB解決策1: 不要なリソースの一括削除
# 安全な一括削除（停止コンテナ、未使用ネットワーク、dangling イメージ、ビルドキャッシュ）
docker system prune
# より強力な削除（未使用イメージも全て削除）
docker system prune -a
# ボリュームも含めて全削除（データ消失注意！）
docker system prune -a --volumes推奨: 開発環境では docker system prune を 週1回程度 実行するのがおすすめです。
解決策2: ビルドキャッシュの削除
# ビルドキャッシュのみ削除
docker builder prune
# 古いキャッシュのみ削除（24時間以上前）
docker builder prune --filter "until=24h"WSL2 仮想ディスクの圧縮（Windows）
Windows で WSL2（Docker Desktop を含む）を使っている場合、仮想ディスク（ext4.vhdx）は自動で拡張されますが、ファイルを削除しても自動では縮小されません。これがディスク容量を圧迫する大きな原因になります。
なぜ縮小されないのか
WSL2 は仮想ハードディスク（VHD）形式でLinuxファイルシステムを管理しています。内部でファイルが増えると VHD は自動拡張されますが、ファイルを削除しても VHD のサイズは元に戻りません。つまり、一度膨らんだ ext4.vhdx は手動で圧縮しない限り、ずっとそのサイズのままです。
VHDXファイルの場所を確認
WSL2 の仮想ディスクは、インストール方法やバージョンによって保存場所が異なります。以下のパターンを確認してください。
パターン1: Microsoft Store版（従来型）
C:\Users\<ユーザー名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu<バージョン>_<ID>\LocalState\ext4.vhdxパターン2: 新しいWSL2ストア形式（GUIDフォルダ）
最近のWSL2では、GUIDフォルダ内に保存されることがあります：
C:\Users\<ユーザー名>\AppData\Local\wsl\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\ext4.vhdxパターン3: Docker Desktop
C:\Users\<ユーザー名>\AppData\Local\Docker\wsl\data\ext4.vhdx
C:\Users\<ユーザー名>\AppData\Local\Docker\wsl\distro\ext4.vhdxパターン4: 新しいDocker Desktop
C:\Users\<ユーザー名>\AppData\Local\DockerDesktop\vm-data\ext4.vhdx確実にVHDXを見つける方法
保存場所がわからない場合は、PowerShellでWindows全体を検索します：
# AppData\Local 配下を検索（高速）
Get-ChildItem -Path "C:\Users\$env:USERNAME\AppData\Local" -Recurse -Filter "*.vhdx" -ErrorAction SilentlyContinue
# 見つからない場合はCドライブ全体を検索（5分程度かかる）
Get-ChildItem -Path "C:\" -Recurse -Filter "*.vhdx" -ErrorAction SilentlyContinueまたは、レジストリからWSLディストリビューションのパスを取得：
# ディストリビューション名を指定してパスを取得
(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss |
Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu' }).GetValue("BasePath") + "\ext4.vhdx"GUIDフォルダへのアクセス方法
PowerShellでは {} を含むフォルダ名は特殊扱いされるため、引用符で囲む必要があります：
# 間違い（エラーになる）
cd C:\Users\taiko\AppData\Local\wsl\8ff0ed39-1e39-48df-99c6-3f9267ac2022
# 正しい（引用符で囲む）
cd "C:\Users\taiko\AppData\Local\wsl\{8ff0ed39-1e39-48df-99c6-3f9267ac2022}"
# 中身を確認
lsVHDXファイルのサイズ確認
# サイズをGB単位で表示
(Get-Item "C:\Users\<ユーザー名>\AppData\Local\wsl\{GUID}\ext4.vhdx").Length / 1GB75GB以上になっている場合は、かなり肥大化している状態です。
Step 1: 圧縮前の準備（重要）
圧縮前に WSL 内と Windows 側で不要なデータを削除しておくと、より多くの容量を回収できます。私の実体験では、この準備をしっかり行うことで圧縮率が大きく向上しました。
Windows 側の一時ファイル削除:
# Windows の一時ファイルを削除（管理者権限で実行）
Remove-Item -Recurse -Force C:\Users\$env:USERNAME\AppData\Local\Temp\*WSL 内のクリーンアップ:
# Docker の不要リソースを削除
docker container prune -f
docker image prune -a -f
docker volume prune -f
docker builder prune -a -f
docker system prune -a --volumes -f
# APT キャッシュの削除（Ubuntu/Debian系）
sudo apt clean
sudo apt autoclean
sudo apt autoremove -y
# システムログの削除（7日以上前）
sudo journalctl --vacuum-time=7d
# 一時ファイルの削除
sudo rm -rf /tmp/*
sudo rm -rf /var/tmp/*Step 1.5: fstrim の実行（推奨）
WSL2 内で fstrim を実行すると、未使用ブロックが解放され、圧縮効果が大幅に向上します。
# 未使用ブロックを解放（圧縮前に実行推奨）
sudo fstrim /あるユーザーの報告では、fstrim 実行後に圧縮したところ、85GB から 60GB まで縮小できたとのことです。この一手間で圧縮効果が大きく変わることがあります。
Step 2: サービスの停止
圧縮を実行する前に、WSL と Docker を完全に停止する必要があります。
# Docker Desktop を終了（タスクトレイから終了）
# WSL をシャットダウン
wsl --shutdown
# 完全に停止したか確認（何も表示されなければOK）
wsl --list --runningStep 3-A: Optimize-VHD で圧縮（Windows Pro / Enterprise）
Windows Pro 以上をお使いの場合は、Hyper-V の Optimize-VHD コマンドが最も簡単です。
事前準備: Hyper-V 機能の有効化
- 「設定」→「アプリ」→「オプション機能」→「Windowsのその他の機能」を開く
- 以下の両方にチェックを入れる:
- Hyper-V 管理ツール
- Hyper-V プラットフォーム
- PC を再起動
圧縮の実行:
# 管理者権限で PowerShell を起動
# Docker Desktop の VHD を圧縮
Optimize-VHD -Path "C:\Users\<ユーザー名>\AppData\Local\Docker\wsl\data\ext4.vhdx" -Mode Full
# WSL Ubuntu の VHD を圧縮
Optimize-VHD -Path "C:\Users\<ユーザー名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_xxxxx\LocalState\ext4.vhdx" -Mode FullStep 3-B: diskpart で圧縮（Windows Home）
Windows Home では Hyper-V が使えないため、diskpart コマンドを使用します。
# 管理者権限でコマンドプロンプトまたはPowerShellを起動
diskpart以下のコマンドを順に入力:
select vdisk file="C:\Users\<ユーザー名>\AppData\Local\Docker\wsl\data\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exitcompact vdisk の実行には 20〜30分以上 かかることがあります。進捗表示がないため、完了まで待ちましょう。
Step 3-C: 自動化ツール「WSL2 Compacter」
複数の WSL ディストリビューションを使っている場合は、WSL2 Compacter が便利です。システム内のすべての vhdx を自動検出して圧縮してくれます。
# スクリプトをダウンロードして実行（管理者権限で）
.\compact-wsl2-disk.ps1圧縮効果の実例
以下は実際に圧縮を行った結果です。最初の行は私自身の実体験です：
| ケース | 圧縮前 | 圧縮後 | 削減量 |
|---|---|---|---|
| 筆者の環境（WSL Ubuntu） | 75GB | 52GB | 23GB |
| Docker + ビルドキャッシュ蓄積 | 100GB | 22GB | 78GB |
| 開発環境 1年使用後 | 70GB | 25GB | 45GB |
| docker system prune 後に圧縮 | 50GB | 15GB | 35GB |
| fstrim 実行後に圧縮 | 85GB | 60GB | 25GB |
WSL本体とDocker Desktop の両方を圧縮すると、合計で 30GB〜100GB以上 の容量を回収できることがあります。
よくあるトラブルと解決法
PowerShell で GUID フォルダにアクセスできない
{} を含むパスは PowerShell で特殊扱いされます。必ず引用符で囲んでください：
# NG: 波括弧なしや引用符なしはエラー
cd C:\Users\taiko\AppData\Local\wsl\8ff0ed39-1e39-48df-99c6-3f9267ac2022
# OK: 波括弧を含むパス全体を引用符で囲む
cd "C:\Users\taiko\AppData\Local\wsl\{8ff0ed39-1e39-48df-99c6-3f9267ac2022}"Optimize-VHD が見つからない
Windows Home エディションでは Hyper-V が利用できないため、Optimize-VHD コマンドは使えません。代わりに diskpart を使用してください（Step 3-B 参照）。
圧縮しても効果が少ない
圧縮前に以下を確認してください：
docker system prune -a --volumes -fを実行したかsudo fstrim /を実行したか- WSL が完全にシャットダウンされているか（
wsl --list --runningで確認）
注意事項
- 必ずバックアップを取る: 万が一の破損に備え、
ext4.vhdxをコピーしておく - すべてのWSL関連アプリを停止: Docker Desktop、VS Code Remote WSL 等も終了する
- 処理中は中断しない:
compact vdisk実行中に中断すると破損の恐れ - 定期的に実行: 月1回程度の実行を推奨
その他のキャッシュ削除
Homebrew (Mac)
# キャッシュ削除
brew cleanup
# 古いバージョンも削除
brew cleanup -s
# 削除されるファイルの確認（dry-run）
brew cleanup -npip (Python)
# キャッシュ場所の確認
pip cache dir
# キャッシュ削除
pip cache purgeIDE・エディタ
| ツール | キャッシュ場所 |
|---|---|
| VS Code | ~/.vscode/extensions (不要な拡張機能を削除) |
| JetBrains | ~/Library/Caches/JetBrains (Mac) |
| Xcode | ~/Library/Developer/Xcode/DerivedData |
Git
# リポジトリの GC（ガベージコレクション）
git gc --aggressive --prune=now
# 不要なリモートブランチの参照を削除
git remote prune origin自動化のすすめ
毎回手動でクリーンアップするのは面倒です。定期的に実行されるようにしましょう。
シェルスクリプト例
#!/bin/bash
# ~/scripts/cleanup-dev.sh
echo "🧹 開発環境クリーンアップを開始..."
# npm キャッシュ
echo "📦 npm キャッシュを削除..."
npm cache clean --force 2>/dev/null
# Docker（起動している場合のみ）
if command -v docker &> /dev/null && docker info &> /dev/null; then
echo "🐳 Docker の不要リソースを削除..."
docker system prune -f
docker builder prune -f
fi
# Homebrew（Mac のみ）
if command -v brew &> /dev/null; then
echo "🍺 Homebrew キャッシュを削除..."
brew cleanup -s
fi
echo "✅ クリーンアップ完了！"cron で定期実行（Linux/Mac）
# 毎週日曜の深夜3時に実行
0 3 * * 0 ~/scripts/cleanup-dev.sh >> ~/logs/cleanup.log 2>&1まとめ
開発環境のディスク容量削減は、以下の4つに集中するのが効果的です。
| 対象 | 削減効果 | 頻度 |
|---|---|---|
| WSL2 仮想ディスク | 30GB〜100GB+ | 月1回 |
| Docker | 10GB〜50GB+ | 週1回 |
| node_modules | 5GB〜20GB | プロジェクト整理時 |
| 各種キャッシュ | 1GB〜5GB | 月1回 |
特に Windows ユーザーの場合、WSL2 仮想ディスクの圧縮が最も効果が大きいことが多いです。Docker と WSL2 は放置すると際限なく膨らむため、定期的なメンテナンスを習慣にすることをおすすめします。
ディスク容量に余裕ができると、ビルドの高速化や新プロジェクトへの着手がスムーズになり、開発体験が大きく向上します。ぜひ今日から実践してみてください。
参考リンク
- Docker公式ドキュメント - Prune unused Docker objects
- pnpm公式サイト
- WSL ディスク領域を管理する方法 | Microsoft Learn
- 仮想ディスクが肥大化してディスク容量が枯渇したので解消してみた | DevelopersIO
- WSL2 のディスクサイズを簡単に最適化できる WSL2 Compacter のご紹介 | つくみ島だより
- Optimize-VHD を使えない場合のディスク容量削減方法 | Qiita
- Shrink WSL2 and Docker Virtual Disks to Reclaim Disk Space | David Quispe
- How to Shrink a WSL2 Virtual Disk | Stephen Rees-Carter
- Shrink your WSL2 Virtual Disks and Docker Images | Scott Hanselman
- Reclaim Tons of Disk Space by Compacting Your Docker Desktop WSL 2 VM | Nick Janetakis