パソコンのCドライブの空き容量が、いつの間にか残りわずかになっていました。
動画編集やAI関連のツールをいろいろ試しているので、心当たりがないわけではありません。でも、何がどれだけ容量を使っているのか、Windowsの設定画面を見てもよくわからない。
そこで、ストレージの使用状況を調べられる「WizTree」でCドライブを解析してみることに。
すると、まさかの結果が。
Dockerだけで約110GB。
最近は強化学習の環境をDockerで動かしていたので、容量を使っていること自体は理解できます。ただ、いくらなんでも大きすぎる気がします。
そこでChatGPTに相談しながら、PowerShellでDockerの不要データを削除していくことにしました。
ところが、20GB以上削除できたはずなのに、Cドライブの空き容量はまったく増えません。
結局、Dockerの内部データを削除するだけでは不十分で、最後に「VHDX」という仮想ディスクを圧縮する必要がありました。
一連のストレージ整理を終えた時点で、Cドライブの空き容量は97.8GBまで回復。
今回は、実際に実行したコマンドと結果、途中でつまずいたポイントを記録しておきます。
Cドライブの容量を調べたら、Dockerが110GBも使っていた
最初に使ったのは、ストレージ解析ツールのWizTreeです。
Windows標準のストレージ設定でも大まかな使用量は確認できますが、WizTreeなら、どのフォルダが何GB使用しているのかを階層ごとに調べられます。
Cドライブをスキャンしてみると、ユーザーフォルダ内のAppDataが約278GBを占有。その中でも目立っていたのがDockerでした。
| フォルダ | 使用容量 |
|---|---|
| Docker | 110.8GB |
| 41.7GB | |
| Programs | 20.9GB |
| pip | 12.6GB |
| CapCut | 10.1GB |
Googleやpip関連のフォルダも容量を使っていますが、中でもDockerが目立っていました。
これをなんとかしないと、Cドライブの容量不足は根本的に解決しそうにありません。
まずはDockerが何に容量を使っているのか調査
Docker Desktopを起動した状態で、PowerShellから次のコマンドを実行しました。
docker system df
これはDockerが使用しているディスク容量を確認するコマンドです。
実際の結果はこちら。
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 8 1 72.51GB 27.3GB (37%)
Containers 1 1 3.326MB 0B (0%)
Local Volumes 18 0 7.723GB 7.723GB (100%)
Build Cache 50 0 22.51GB 17.96GB
Dockerに詳しくない人にとっては、何が何だかわからない表示かもしれません。私も最初はそうでした。
ざっくり説明すると、次のような意味です。
| 項目 | 主な役割 |
|---|---|
| Images | コンテナを作るためのプログラムや実行環境 |
| Containers | イメージから作成された実行環境 |
| Local Volumes | データベースや設定などを保存する領域 |
| Build Cache | イメージ作成を効率化するための一時データ |
注目したいのはRECLAIMABLEの列です。
これは、Dockerが解放可能と認識している容量を表しています。
私の環境では、イメージだけで27.3GB、ビルドキャッシュにも約18GBの削減余地がありました。
ただし、RECLAIMABLEと表示されたデータがすべて不要とは限りません。
例えばVolumeには、現在動いていないアプリのデータが保存されていることもあります。削除前の確認が必要です。
Dockerの不要データを実際に削除してみた
① docker builder pruneで約18GB削減
最初に手をつけたのはBuild Cacheです。
docker builder prune
実行すると、次の確認が表示されました。
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N]
yを入力してEnter。
削除後にもう一度docker system dfを実行すると、Build Cacheが次のように変化していました。
| 削除前 | 削除後 | |
|---|---|---|
| Build Cache | 22.51GB | 4.585GB |
約17.9GBの削減に成功!
docker builder pruneは、標準では、ほかから参照されなくなったビルドキャッシュ(dangling)を削除するコマンドです。現在のコンテナやイメージ自体は削除しません(Docker公式資料、2026年11月11日確認)。
キャッシュを消すと、次回のビルドでは処理に時間がかかることがありますが、実行環境そのものを消すよりは取り組みやすい方法です。
より広い範囲の未使用ビルドキャッシュを消す場合は、docker builder prune -aという方法もあります。
② docker image pruneで約8.6GB削減
次はDockerイメージです。
詳しい内訳を調べるため、以下を実行しました。
docker system df -v
すると、次のようなイメージが残っていました。
| イメージ | 容量 | 使用コンテナ数 |
|---|---|---|
強化学習用のイメージ(simulator_dist-dev1) | 44.6GB | 1 |
| openclaw | 4.55GB | 0 |
| ollama/ollama | 9.04GB | 0 |
| open_notebook | 2.57GB | 0 |
| speaches | 3.04GB | 0 |
| その他・タグなし | 約9.1GB | 0 |
この強化学習用のイメージだけで44.6GB。これは現在利用中なので残しておきます。
一方、古いイメージには、現在のコンテナから使われていないものが複数ありました。
まずは、タグがなく、どのコンテナからも参照されていないイメージを削除します。
docker image prune
実行後、イメージの使用量は次のようになりました。
| 削除前 | 削除後 | |
|---|---|---|
| Images | 72.51GB | 63.94GB |
ここでも約8.6GBの削減に成功です。
なお、次のコマンドを使えば、現在どのコンテナからも参照されていないイメージを、タグ付きも含めて削除できます。
docker image prune -a
ただし、未使用でも今後再利用したいイメージまで削除対象になります。
私の環境にもOpenClawなどのイメージが残っていたので、安易に全部消すのは避けたいところです。
③ Volumeは削除せずに残した
もう一つ、気になっていたのがVolumeです。
Local Volumes 18 0 7.723GB 7.723GB (100%)
18個のVolumeがあり、現在のコンテナからは使用されていません。
しかし、Volumeは単なるキャッシュではありません。データベースやアプリの設定など、後から復元できないデータが入っている可能性があります。
そのため、今回は削除しないことにしました。
同じ理由で、以下のような一括削除コマンドも、内容を理解せずに実行するのはおすすめしません。
docker system prune -a --volumes
強化学習や開発環境を使っている人は、特に慎重に判断した方がよいと思います。
20GB以上削除したのに、Cドライブの空き容量が増えない!
ここで思わぬ問題が発生しました。
Build Cacheと古いDockerイメージを合わせて約26GB削減したのに、WindowsのCドライブの空き容量がほとんど変わっていません。
WizTreeで再スキャンしても、Dockerのフォルダは依然として巨大なまま。
「コマンドは成功したはずなのに、なんで?」
調べてみると、原因はDockerが使用している仮想ディスクファイル(VHDX)の仕組みにありました。
Docker内部のファイルを消しても、仮想ディスクは縮まない
私が利用しているDocker DesktopのWSL2環境では、DockerのデータがVHDXという仮想ディスクファイルに保存されています。
通常、次の場所にあります。
C:\Users\ユーザー名\AppData\Local\Docker\wsl\
この仮想ディスクは、データが増えるにつれて大きくなります。
ところが、内部のファイルを削除しても、Windows上の仮想ディスクファイルが自動で小さくなるとは限りません。
イメージとしては、こんな感じです。
【削除前】
仮想ディスク 110GB
[使用中のデータ ]
【Docker内部で削除後】
仮想ディスク 110GB
[使用中のデータ][空き領域]
【仮想ディスク圧縮後】
仮想ディスクを縮小
[使用中のデータ]
Docker内部に空き領域ができても、Windows側では大きな仮想ディスクファイルとして容量を占有したままになっているわけです。
Microsoftの公式資料にも、動的に拡張する仮想ディスクは、内部のファイルを消しても自動的には小さくならないことが説明されています。
つまり、Docker内部の不要データを削除した後に、仮想ディスク自体を圧縮する必要があったのです。
解決編:DockerのVHDXを圧縮してCドライブの容量を取り戻す
ようやく原因がわかったので、仮想ディスクの圧縮に進みます。
ここからは、Dockerの内部データではなく、Windows上の仮想ディスクを操作します。
作業前にDockerの処理を正常に終了してください。また、重要なデータがある場合はバックアップを取っておきましょう。操作対象のVHDXを間違えないことも重要です。
手順① Docker Desktopを完全に終了する
まず、動いているコンテナや学習処理を正常に停止します。
その後、タスクトレイのDockerアイコンからDocker Desktopを完全終了します。
続いて、PowerShellで次のコマンドを実行します。
wsl --shutdown
WSLを終了するコマンドです。Docker以外のWSL環境も停止するため、そちらで作業中のプログラムがないことも確認しておきましょう。
手順② VHDXファイルの場所とサイズを確認する
次に、対象のVHDXファイルを探します。
PowerShellに以下を入力してください。
Get-ChildItem "$env:LOCALAPPDATA\Docker\wsl" -Recurse -Filter *.vhdx |
Select-Object FullName,@{N="SizeGB";E={[math]::Round($_.Length/1GB,1)}}
これで、DockerのWSLフォルダ内にあるVHDXファイルのパスとサイズを確認できます。
私の環境で対象となったファイルは、次の場所にありました。
C:\Users\user\AppData\Local\Docker\wsl\disk\docker_data.vhdx
保存場所は環境によって異なる場合があるため、必ず自分のパソコンで確認したパスを使用してください。
手順③ DiskPartで仮想ディスクを選択する
ここからは管理者権限が必要です。
PowerShellを「管理者として実行」で開き、次を入力します。
diskpart
すると、コマンドの入力画面が次のように切り替わります。
DISKPART>
この状態で、先ほど確認したVHDXファイルを選択します。
select vdisk file="C:\Users\user\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
※パスは自分の環境のものに置き換えてください。
成功すると、次のメッセージが出ます。
DiskPart により、仮想ディスク ファイルが選択されました。
実はここでも一度つまずきました。
PowerShellで直接select vdiskを実行したところ、こんなエラーが。
Select-Object : 引数 'file=...' を
受け入れる位置指定パラメーターが見つかりません。
PowerShellではselectがSelect-Objectという別のコマンドとして認識されるためです。
必ずdiskpartを起動し、DISKPART>と表示された状態で入力しましょう。
手順④ compact vdiskで圧縮する
仮想ディスクを選択できたら、いよいよ圧縮です。
compact vdisk
これだけです。
処理中は時間がかかることもあるようですが、今回は無事に完了しました。
実際に表示されたメッセージがこちら。
100% 完了しました
DiskPart により、仮想ディスク ファイルは正常に圧縮されました。
成功!
最後に、
exit
でDiskPartを終了します。
なお、compact vdiskは、対象の仮想ディスクが切り離されているか、読み取り専用で接続されている場合に実行できます。Dockerを終了しても使用中のままの場合は、無理に操作を続けず、実行中のWSLやDockerの状態を確認してください。
結果:Cドライブの空き容量が97.8GBまで回復!
仮想ディスクの圧縮が終わったところで、Cドライブの容量を再確認。
空き容量は97.8GBまで回復していました。
やっと解決です。
今回はDocker以外にもPythonのpipやuv、npmのキャッシュなどを整理しているため、97.8GBがすべてDockerの圧縮によるものではありません。
ただ、少なくともDocker内部の不要データを削除するだけでは、Windows側の空き容量に十分反映されなかったことは確認できました。
今回の作業を簡単にまとめると、次のようになります。
| 作業 | 実際の結果 |
|---|---|
| WizTreeで容量を調査 | Dockerが約110.8GBを占有 |
docker builder prune | 約17.9GBのキャッシュ削減 |
docker image prune | 約8.6GBのイメージ削減 |
compact vdisk | 仮想ディスクの圧縮に成功 |
| 一連のストレージ整理後 | Cドライブの空き容量97.8GB |
Dockerを使っていると、イメージのビルドや実行環境の更新によって、知らないうちにストレージを消費していることがあります。
今回は強化学習用のイメージだけでも44.6GBあったので、今後も定期的にチェックした方がよさそうです。
まとめ:Dockerの容量削減は「内部の掃除」と「仮想ディスクの圧縮」が別だった
今回の教訓は、Docker内部の容量とWindowsのCドライブの空き容量は、必ずしも連動しないということです。
Dockerの不要データを消しても空き容量が増えないときは、次の順番で確認するのがよいと思います。
docker system dfで使用状況を確認するdocker builder pruneなどで不要データを削除する- Windows側の空き容量が増えたか確認する
- 増えない場合はVHDXのサイズを調べる
- 必要であればDockerを停止し、VHDXを圧縮する
特に注意したいのは、DockerのフォルダやVHDXファイルを直接削除しないことです。
大容量だからといってエクスプローラーから丸ごと削除すると、必要なイメージや保存データまで失うおそれがあります。
また、今回の手順で必ず同じ容量が戻るわけではありません。圧縮できる領域の大きさは、仮想ディスク内部の状態によって異なります。
それにしても、Cドライブの容量を空けるだけのつもりが、こんなにコマンドを叩くことになるとは思いませんでした。
同じように「Dockerのデータを消したのにCドライブが全然空かない!」と困っている人の参考になれば幸いです。

