Dockerを消してもCドライブの空きが増えない理由
WindowsでDocker Desktopを使っていると、いつの間にかCドライブを数十GB、場合によっては100GB以上使っていることがあります。
原因になりやすいのは次のデータです。
Dockerイメージ
停止したコンテナの書き込みレイヤー
名前付きボリューム
BuildKitのビルドキャッシュ
コンテナログ
WSL 2の仮想ディスク
さらに分かりにくいのが、Docker内のファイルを削除しても、Windowsから見た仮想ディスクファイルがすぐには小さくならないことです。
Docker内の使用量を減らす
↓
WSL 2仮想ディスク内に空き領域ができる
↓
VHDXを縮小する
↓
Windowsの空き容量が増える
この2段階を区別しないと、「docker system pruneを実行したのにCドライブが空かない」という状態になります。
この記事では、いきなり全削除せず、何が容量を使っているか確認してから安全な順番で減らします。
最初にDockerの使用量を確認する
PowerShellまたはコマンドプロンプトで次を実行します。
docker system df
詳細を確認する場合は-vを付けます。
docker system df -v
主に見る項目は次の4つです。
Images イメージ本体
Containers コンテナの書き込みレイヤー
Local Volumes DBやアップロードファイルなどの永続データ
Build Cache docker buildで作られたキャッシュ
RECLAIMABLEは回収できる可能性がある容量です。ただし、回収可能と表示されることと、削除して困らないことは同じではありません。
特にボリュームには、PostgreSQL、MySQL、Minecraftワールド、Open WebUIの会話履歴、Ollamaのモデルなどが入っていることがあります。
現在のコンテナを確認する
実行中だけでなく、停止中も含めて表示します。
docker ps -a
Composeプロジェクトも確認します。
docker compose ls -a
使っていない停止済みコンテナが明確なら、名前を指定して削除できます。
docker rm コンテナ名
すべての停止済みコンテナを対象にする場合は次です。
docker container prune
実行前に削除対象の警告が出ます。開発中に一時停止しているだけのコンテナも対象になるため、docker ps -aを先に確認します。
使っていないイメージを削除する
まずイメージ一覧とサイズを確認します。
docker image ls
タグがなく、どのコンテナからも参照されていないdanglingイメージだけを削除します。
docker image prune
未使用イメージをすべて対象にする場合は-aを付けます。
docker image prune -a
-aを使うと、現在コンテナから参照されていないイメージが削除されます。Composeを停止・削除したあとに実行すると、次回の起動でイメージの再ダウンロードが必要になることがあります。
古いものだけに限定する方法もあります。
docker image prune -a --filter "until=168h"
168hは7日です。最近取得したイメージを残したい場合に使えます。
ビルドキャッシュを削除する
アプリを頻繁にビルドするPCでは、イメージよりBuildKitのキャッシュが大きいことがあります。
docker buildx du
不要なビルドキャッシュを削除します。
docker buildx prune
より広い範囲のキャッシュを対象にする場合は次です。
docker buildx prune --all
ビルドキャッシュを削除してもソースコードは消えません。ただし、次のdocker buildではキャッシュが使えないため、依存関係のダウンロードやビルドに時間がかかります。
ボリュームは最後に確認する
ボリューム一覧を表示します。
docker volume ls
どのコンテナがマウントしているかは、コンテナ側から確認できます。
docker inspect コンテナ名
特定のボリュームの情報を確認します。
docker volume inspect ボリューム名
使わないことが確実なボリュームだけ、名前を指定して削除するのが安全です。
docker volume rm ボリューム名
未使用ボリュームをまとめて削除するコマンドもあります。
docker volume prune
ただし、現在コンテナに接続されていないボリュームが対象です。「使っていない」のではなく、「今はコンテナが参照していない」だけかもしれません。
例えば、docker compose downでコンテナを削除したあとでも、次回使うデータをボリュームへ残していることがあります。その状態でボリュームをpruneすると、データを失う可能性があります。
Composeプロジェクト単位で削除する
プロジェクトのフォルダへ移動して、コンテナとネットワークを停止・削除します。
docker compose down
このコマンドだけなら、通常は名前付きボリュームを残します。
ボリュームまで削除する場合は次です。
docker compose down -v
-vを付けると、そのComposeプロジェクトで定義した名前付きボリュームも削除されます。DBやユーザーデータを初期化する意図がある場合だけ使います。
イメージも含めて整理したい場合は、削除範囲を確認してからオプションを追加します。
docker compose down --rmi local
プロジェクト単位で消せるなら、PC上の全Dockerデータを対象にするpruneより管理しやすくなります。
docker system pruneは何を消すのか
まとめて整理するコマンドです。
docker system prune
標準では、主に次が対象になります。
停止済みコンテナ
未使用ネットワーク
danglingイメージ
未使用ビルドキャッシュ
ボリュームは標準では対象外です。ボリュームも対象にするには明示的に指定します。
docker system prune --volumes
このコマンドは削除範囲が広いため、容量不足を見つけた直後に実行するのではなく、次の順番をおすすめします。
1. docker system df -v
2. docker ps -a
3. docker volume ls
4. プロジェクト単位で不要データを削除
5. image prune / buildx prune
6. 必要ならsystem prune
確認プロンプトを飛ばす-fは、スクリプト以外では付けない方が安全です。
Docker内を削除してもCドライブが空かない仕組み
WSL 2はLinuxのファイルシステムをVHDXという仮想ディスクへ保存します。Docker DesktopのLinuxコンテナデータも、現在の構成に応じた仮想ディスク内へ保存されます。
VHDXは必要に応じて拡張しますが、内部のファイルを削除しても物理ファイルが自動的に同じサイズまで縮むとは限りません。
例えば次の状態が起こります。
Dockerデータを80GB保存
VHDXが約80GBまで拡張
Dockerデータを60GB削除
Linux内部では約60GB空く
Windows上のVHDXは約80GBのまま
この場合、削除自体には成功しています。Windowsへ容量を返すには、DockerとWSLを完全に停止したうえで仮想ディスクを縮小します。
まずDocker Desktopの機能で容量を回収する
Docker Desktopのバージョンによっては、設定画面のResourcesやTroubleshootにディスク使用量の管理・回収機能があります。
画面上に容量回収やディスクイメージ管理の項目がある場合は、それを先に使います。Docker Desktop自身が管理するディスクの場所や形式はバージョンによって変わるため、内部ファイルを直接操作するより安全です。
設定画面の名称が異なる場合は、Docker Desktopを更新し、公式のバックアップ手順も確認してください。
VHDXを手動で縮小する前の注意
手動圧縮は、Docker Desktopの機能で回収できない場合の手段です。作業前に重要なボリュームをバックアップしてください。
また、古い記事に書かれたVHDXパスをそのまま使わないでください。Docker Desktopの保存方式やファイル名はバージョンにより異なります。
次の条件を満たしてから進めます。
必要なDockerデータをバックアップした
docker system dfで内部データを整理済み
Docker Desktopを終了した
WSLを停止した
対象VHDXの正確なパスを確認した
WSLディストリビューション一覧と状態を確認します。
wsl --list --verbose
WSLを停止します。
wsl --shutdown
タスクマネージャーなどでDocker Desktopが終了していることも確認します。
DiskPartでVHDXを縮小する
管理者としてPowerShellまたはWindows Terminalを開き、DiskPartを起動します。
diskpart
DiskPart内で、対象のVHDXを選択します。
select vdisk file="C:\正確なパス\対象ファイル.vhdx"
選択内容を確認します。
detail vdisk
パスと対象が正しいことを確認してから縮小します。
compact vdisk
終了します。
exit
Microsoftの仕様上、compact vdiskの対象は動的拡張VHDで、デタッチされているか読み取り専用で接続されている必要があります。そのため、先にDocker Desktopを終了し、wsl --shutdownを実行します。
作業後にDocker Desktopを起動し、コンテナとボリュームが正常か確認します。
docker ps -a
docker volume ls
docker system df
VHDXの場所を推測しない
WSLディストリビューションのVHDXは、Microsoft Store版ディストリビューション、wsl --importで作った環境、Docker Desktop管理領域で保存場所が異なります。
一般的なWSLディストリビューションについては、PowerShellからレジストリ情報を確認できます。
Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss |
ForEach-Object { Get-ItemProperty $_.PSPath } |
Select-Object DistributionName, BasePath
表示されたDistributionNameとBasePathを照合します。ただし、Docker Desktopのデータが通常のディストリビューションと同じ方法で列挙されるとは限りません。
Dockerについては、Docker Desktopの設定に表示されるディスクイメージの場所や、公式のバックアップ資料を優先してください。別のVHDXを誤って選ぶと、Ubuntuなど他のWSL環境へ影響する可能性があります。
バックアップしてからボリュームを削除する
重要なボリュームは、内容に合う方法でバックアップします。
DBの場合は、ボリュームのファイルを直接コピーするより、DB自身のダンプ機能を使う方が安全です。
PostgreSQL pg_dump
MySQL mysqldump
MongoDB mongodump
一般ファイルを保存したボリュームなら、一時コンテナを使ってアーカイブできます。次はmy_volumeを現在のフォルダへバックアップする例です。
docker run --rm `
-v my_volume:/source:ro `
-v "${PWD}:/backup" `
alpine `
tar czf /backup/my_volume-backup.tar.gz -C /source .
バックアップファイルが作成され、展開できることを確認してから元のボリュームを削除します。
ログが巨大化している場合
コンテナの標準出力へ大量にログを出し続けると、Dockerのログファイルが大きくなることがあります。
Composeではログローテーションを設定できます。
services:
app:
image: example/app:latest
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
この例では、1ファイルを10MB、最大3ファイルに制限します。既存コンテナへ設定を反映するには、Compose設定を変更してコンテナを再作成します。
docker compose up -d --force-recreate
アプリ側で同じエラーを無限に出している場合は、ログを消すだけでなく原因も修正します。
容量不足を繰り返さない運用
月に1回程度、次を確認すると急な容量不足を防ぎやすくなります。
docker system df -v
docker ps -a
docker buildx du
おすすめの運用は次の通りです。
使い終わったComposeプロジェクトはdownする
不要になったプロジェクトだけボリュームを削除する
DBは定期的に論理バックアップする
ログローテーションを設定する
ビルドキャッシュが増えたらbuildx pruneする
VHDX圧縮は頻繁に行わず、必要なときだけ実施する
Docker Desktopにはディスク使用量の上限や保存場所を設定できる場合があります。Cドライブが小さいPCでは、余裕のあるドライブへディスクイメージを移す方法も検討できます。ただし、エクスプローラーでVHDXを直接移動するのではなく、Docker Desktopが提供する設定や公式の移行手順を使います。
まとめ
Docker DesktopでCドライブが減る問題は、次の順番で対応すると安全です。
docker system df -vで内訳を見る
↓
不要なプロジェクト・イメージ・キャッシュを個別に削除
↓
ボリュームは中身とバックアップを確認してから削除
↓
Docker Desktopの容量回収機能を使う
↓
必要な場合だけWSL停止後にVHDXを縮小
最も危険なのは、原因を確認せずにdocker system prune --volumesを実行することです。空き容量は増えても、DBやアプリの永続データまで消える可能性があります。
Docker内部の削除とWindows上のVHDX縮小は別の処理です。この違いを理解し、対象を確認しながら段階的に整理すれば、データを守りながら容量を回収できます。