Mac の Docker が容量を使いすぎるときの安全な減らし方

macOS で Docker が巨大に見える理由

Docker Desktop は軽量 Linux 仮想マシン内でコンテナを動かします。イメージ、コンテナの書き込み層、ビルドキャッシュ、ボリュームは、Finder で編集する普通のフォルダではなく、大きなディスクイメージに保存されます。一般的なファイル名は Docker.raw です。

ディスクイメージの上限、Finder 上の見かけのサイズ、Docker が現在使う容量は同じとは限りません。スパースファイルは大きな論理サイズを持ちながら、ホスト上では少ないブロックしか使わないことがあります。

Docker.raw を手動削除すると、Docker の管理を迂回してローカルのイメージ、コンテナ、ボリュームをまとめて破壊する可能性があります。Finder で移動せず、場所の変更は Docker Desktop Settings から行います。

読み取り専用で容量を監査する

Docker Desktop を起動し、docker system df を実行します。イメージ、コンテナ、ローカルボリューム、ビルドキャッシュと再利用可能量が表示され、docker system df -v なら詳細を確認できます。

「Reclaimable」は文脈が必要です。共有イメージのタグ一つを消しても全容量は戻らず、未接続のボリュームにも再利用予定のデータベースが入っていることがあります。

Docker Desktop Settings > Resources でディスク使用上限と保存場所も記録します。Docker が起動しない場合は、リセットや再インストールの前に公式の復旧手順でデータファイルを保護してください。

1. docker system df -v の結果を日付付きで保存します。
2. docker ps -a で停止コンテナの所有プロジェクトを確認します。
3. docker image ls で大きなタグを現役プロジェクトへ対応付けます。
4. docker volume ls で各ボリュームの所有者とバックアップを確認します。
5. docker builder du など現在の Builder が提供する方法でビルドキャッシュを調べます。

実行中コンテナに接続されていないボリュームも、安全に削除できるとは限りません。停止したデータベースや Compose プロジェクトのデータかもしれません。

停止コンテナと未使用イメージを個別に削除する

不要と確認した停止コンテナは docker container rm と名前または ID で削除します。書き込み層は失われますが、明示的に要求しない限り名前付きボリュームは残ります。

未使用イメージは docker image rm とタグまたは ID で削除します。コンテナから参照されていると表示されたら、force ではなく参照元を確認してください。頻繁に使う重いベースイメージを残すのは合理的です。

docker container prune は全停止コンテナ、docker image prune は既定で dangling イメージを確認後に削除します。-a はコンテナ未参照の全イメージへ範囲を広げるため、確認内容を読んでください。

ボリュームに触れずビルドキャッシュを整理する

BuildKit は変更のない手順を再利用するためレイヤーを保持します。活発な開発用 Mac では最大の再利用可能カテゴリになることがあり、通常は Dockerfile とビルドコンテキストから作り直せます。

既定 Builder なら docker builder prune、buildx 管理なら docker buildx prune を使います。確認プロンプトを安全チェックとして残し、現在の Docker 版が示すオプションを確認します。

次のビルドは遅くなり、再ダウンロードが発生します。毎週巨大化するなら、.dockerignore、Dockerfile の命令順、CI のキャッシュ上限も改善してください。

docker system prune の範囲を理解する

既定の docker system prune は停止コンテナ、未使用ネットワーク、dangling イメージ、未使用ビルドキャッシュを削除します。監査後にその全カテゴリを受け入れる場合に使います。

既定ではボリュームを削除しません。--volumes は匿名ボリュームまで広げ、実データを失う可能性があります。出所不明のワンライナーへ安易に追加しないでください。

-a は dangling だけでなく、コンテナに使われていない全イメージへ広げます。データ損失がなくても再取得コストが大きいため、認識できる対象は個別削除を優先します。

1. 監査を終え、重要なボリュームをバックアップします。
2. 原因が一カテゴリなら builder prune や container prune を先に使います。
3. 確認内容をすべて受け入れるときだけ、-a と --volumes なしで system prune を実行します。
4. docker system df -v を再実行し、重要プロジェクトを起動します。
5. Docker Desktop がホストブロックを返した後、macOS の空き容量を確認します。

ボリュームをキャッシュではなくデータとして扱う

ボリュームはコンテナより長く生きるよう設計されています。停止済み PostgreSQL や MySQL のボリュームが唯一のローカルデータを持つことがあります。所有者とバックアップが分かるまで文書と同じ扱いにしてください。

Docker の案内どおりボリュームデータは別にバックアップします。可能ならデータベース固有のエクスポートを使い、復元テストを行います。稼働中データディレクトリの単純コピーは必ずしも整合したバックアップではありません。

Compose ではボリュームを明確に命名し、所有プロジェクト、復元方法、失効時期を記録します。

Docker Desktop の保存先・上限・リセット

オブジェクト整理でも足りない場合は Docker Desktop Settings からディスクイメージを管理します。利用できる設定は版によりますが、保存場所や上限の変更は対応 UI で行ってください。

Docker.raw を Finder でドラッグしないでください。Factory Reset、アンインストール、破壊的なサイズ変更の前に、必要なイメージをエクスポートまたは再取得可能にし、ボリュームを別途バックアップします。

削除後にホスト容量が戻るまで時間差がある場合があります。Docker の Mac FAQ では Docker.raw は旧 qcow2 より速く容量を返すと説明されています。すぐに追加削除せず再測定してください。

AskClean がすること、しないこと

AskClean は Docker Desktop のランチャーキャッシュと Mac 側の占有を表示しますが、Docker.raw、Group Container、認証情報、イメージ、ボリュームはプロバイダ管理または非選択として扱い、通常キャッシュのように捨てません。

コンテナオブジェクトと仮想ディスクには Docker の CLI と Settings を使います。AskClean で占有を見つけ、docker system df -v で診断し、正しいカテゴリだけを整理するのが安全な流れです。

Docker カテゴリ別の削除リスク

一つの仮想ディスクに再生成可能なレイヤーと永続データがあります。

よくある質問