# データを失わずに Mac の Docker を整理する > prune の前にイメージ、コンテナ、ビルドキャッシュ、状態を持つボリュームを確認し、スパースディスクの割り当ては別途測ります。 Published: 2026-06-26 | Updated: 2026-08-08 Docker Desktop は、イメージ、書き込み可能なコンテナレイヤ、ビルドキャッシュ、ボリュームが Linux 仮想ディスク内に置かれるため、数十ギガバイトを使うことがあります。これらの種類は、同じように捨ててよいわけではありません。ビルドキャッシュは通常、作り直せます。一方、データベース用ボリュームは、重要なデータの唯一のコピーであることもあります。安全な整理は、いちばん広い prune コマンドではなく、Docker 自身の内訳から始めます。 ## Docker の空きが戻ってこない理由 macOS 上の Docker Desktop は Linux VM を動かし、通常は `Docker.raw` というスパースな仮想ディスクにデータを保存します。Docker の [Mac ストレージガイド](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/#where-does-docker-desktop-store-linux-containers-and-images) では、場所・ディスク上限・実際に使っている容量の確認先として **Docker Desktop > Settings > Resources > Advanced** を案内しています。移動も Finder ではなく、この設定から行ってください。スパースファイルには論理上の最大サイズと、それより小さい物理割り当てがあるため、`ls -lh` だけでは、いま実際に占めている容量よりずっと大きく見えることがあります。 Docker 自身が何を使っていると考えているか、次で確認します。 ``` docker system df -v ``` 詳細表示では、イメージ、コンテナ、ローカルボリューム、ビルドキャッシュが分かれます。「Reclaimable」は、Docker から見てそのオブジェクトを必要とする現在の参照がない、という意味です。停止中のコンテナ、古いイメージ、ボリュームを明日も使わないことの証明ではありません。prune の前に `docker ps -a` と `docker volume ls` も確認してください。 ## まず狭い範囲から片付ける 必ず Docker の中から回収し、仮想ディスクファイルそのものは削除しないでください。理解できている種類から始めます。 ``` docker builder prune --filter until=168h docker image prune docker container prune ``` 最初のコマンドは 7 日より古いビルドキャッシュを削除します。作業に合わせて日数を調整してください。続く 2 つは、未参照のイメージと停止中コンテナを削除する前に確認を求めます。各ステップのあとで `docker system df -v` を再実行し、どの操作が効いたかを見ます。 Docker の [pruning ガイド](https://docs.docker.com/engine/manage-resources/pruning/) では、`docker system prune` をより広い一括コマンドとして説明しています。`-a` を付けると、ダングリングレイヤだけでなく未使用イメージ全体が対象になります。`--volumes` を付けると、未使用の匿名ボリュームまで広がり、データベースファイルなどの状態が含まれることがあります。`docker system prune -a --volumes` を、日常の掃除コマンドにしてはいけません。ボリュームを prune する前に、名前と所有関係を確認します。 ``` docker volume ls docker volume inspect ``` Compose が作ったボリュームには、通常プロジェクトとサービスのラベルが付いています。所有プロジェクトを特定し、作り直せないデータは、ボリュームを消す前にエクスポートするかバックアップしてください。 ## ディスクイメージそのものを回収する prune のあと、空きブロックはまず Linux ファイルシステムの中にでき、macOS がスパースディスクからそれを受け取るまでには、必ずしもすぐに反映されません。現行の Docker ドキュメントでは、`Docker.raw` イメージは通常、ホスト側の回収可能な空きを数秒以内に返すとされています。古い `Docker.qcow2` イメージはバックグラウンド処理を使い、数分かかることがあります。ファイルの論理最大値ではなく、実際のディスク使用量を測り直してください。工場出荷時リセットはコンパクションではありません。ローカルのコンテナ、イメージ、ボリューム、設定をすべて破棄します。その完全な損失が意図的で、重要なボリュームデータをすでにエクスポートしている場合にだけ使ってください。 ## 仕組み： なぜファイルは増え、小さくならないのか Docker Desktop は Linux VM を動かし、`Docker.raw` はその VM の仮想ディスクです。ゲストが書き込むと増えるスパースファイルで、ゲストが削除しても macOS へ自動で空きを返しません。イメージを消すと、VM 内ファイルシステム上ではブロックが空きとしてマークされますが、ホスト側のファイルが小さくなるのは、ゲストが TRIM/discard を発行し、Docker Desktop が discard とコンパクションで回収可能なブロックを返せる場合だけです。タイミングはバージョンとディスクイメージの実装に依存します。だから論理上の整理と、ホスト側の容量変化は別々に測る必要があり、ホストファイルを削除することは Docker 環境全体を破壊するのと同じです。
スパースな Docker.raw ファイルはゲスト VM の書き込みに応じて大きくなり、discard とコンパクションで適格なブロックを macOS に返せます
Docker オブジェクトの削除は、まず VM 内の空きを作ります。物理割り当てを macOS に返すのは、別のスパースディスク処理です。
## ディスクマップが役立つ場面 [Mole](https://mole.fit/) の Analyze のようなディスクマップは、仮想ディスクとその物理的なフットプリントを示せます。どの内部オブジェクトが参照されているかは、Docker 自身の CLI が判断します。二つの見方は別の問いに答えています。macOS は容量がどこに割り当てられているかを示し、Docker はその割り当てに何が入っているかを説明します。 ## 安全な作業順 `docker system df -v` を実行し、古いプロジェクトと状態を持つボリュームを特定し、唯一のデータをエクスポートし、種類ごとに一つずつ prune します。Docker 内部の合計と macOS の物理容量の両方を再確認します。広い prune フラグは、対象がどう広がるかを確認してから使い、工場出荷時リセットを日常の空き回収の近道にしてはいけません。いちばん早く、かつ安全に効くのは、多くの場合、正体不明のボリュームではなく、古いビルドキャッシュです。 --- Canonical HTML page: https://mole.fit/ja/blog/how-to-clean-up-docker-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt