MacのDockerは、めったに一度に巨大にはなりません。レイヤー単位で徐々に大きくなります。
最初は一つのイメージ、一つのプロジェクト、一つのデータベースボリューム、一つの停止したコンテナ、後で消すつもりのビルドキャッシュです。やがてマシンが狭くなり、Docker Desktopが怪しく見え始め、「Dockerがディスクを食っている」という漠然とした感情的に満足な結論に至ります。
その結論は方向性としては正しいですが、実用には精度が足りません。本当の問題は通常「Docker全体」ではありません。イメージ、レイヤー、ビルドキャッシュ、停止したコンテナ、ボリューム、誰も一つのシステムとして確認していないランタイムデータにまたがる蓄積です。
簡潔な回答
- MacでのDockerのディスク増加は、通常一つの壊れたフォルダではなく蓄積が原因です。
- 一般的なストレージ構成要素は、イメージ、共有レイヤー、ビルドキャッシュ、停止したコンテナ、ボリューム、ダングリングオブジェクトです。
- Macでは、Docker DesktopがLinuxコンテナとイメージを大きなディスクイメージ内に格納するため、Finderだけでは実態が不透明に見えることがあります。
- 最初のステップは削除ではなく確認です。pruneする前に、実際に何が回収可能かを確認しましょう。
- Docker管理下のパスでの直接的な
rmは、Dockerがランタイム状態とメタデータを追跡しているため、Docker対応のクリーンアップよりもリスクが高くなります。 pruneは有用ですが、再構築可能なキャッシュを削除しているのか永続的なデータを削除しているのかを理解している場合に限ります。
DockerがMacで静かに肥大化する理由
Dockerは、ユーザーが明示的に指示するまで有用な状態を保持するように設計されています。Docker自身のドキュメントでもクリーンアップは保守的と説明されており、未使用のイメージ、コンテナ、ボリューム、ネットワークは通常、ユーザーがDockerに指示しない限り削除されません。
これは開発者ワークフローにとって便利ですが、ディスク使用量が徐々に増加する正確な理由でもあります。
Macでは、Docker DesktopがLinuxコンテナとイメージを単一の大きなディスクイメージファイルに格納するため、さらに分かりにくくなります。ホスト側ではDockerのフットプリントが一つの大きな塊として表示されますが、実際の原因はランタイムデータの複数のレイヤーの奥に埋もれています。
増加パターンは通常、以下の組み合わせです：
- 複数のプロジェクトにわたるプルと再ビルドのイメージ
- タグやバージョン間で再利用される共有レイヤー
- 書き込み可能なレイヤーを保持し続ける停止したコンテナ
- データベース、アップロードファイル、ローカルサービスの状態を保持するボリューム
- ビルドを高速に保つものの、やがて高コストになるビルドキャッシュ
- リビルドや再タグ付け後に残されるダングリングオブジェクト
結果として、個々の追加は正常に感じられるため、フットプリントが静かに拡大し続けます。
MacでDockerのディスク容量を実際に消費しているもの
有用なクリーンアップ計画を立てるには、Dockerのフットプリントを一つの巨大なブラックボックスとして扱うのではなく、カテゴリに分けてください。
| 構成要素 | 増加する理由 | 最初に確認すべきこと | 盲目的なクリーンアップのリスク |
|---|---|---|---|
| イメージと共有レイヤー | ベースイメージのプル、再タグ付け、サービスの再ビルド、複数バージョンの保持 | どのイメージがアクティブなコンテナやプロジェクトでまだ使われているか | 中 |
| ビルドキャッシュ | BuildKitと繰り返しのイメージビルドが将来のビルドを高速にするためにキャッシュを保持 | 容量の大部分がキャッシュかどうか、今日の再ビルド速度が重要かどうか | 中 |
| 停止したコンテナ | 終了したコンテナも書き込み可能なレイヤーと参照を保持 | 意図的に停止されたものか、単に忘れられたものか | 低〜中 |
| ボリューム | データベース、アップロード、インデックス、パッケージレジストリ、ローカルサービスの状態がここに存在 | ボリュームがまだ必要な永続的なプロジェクトデータを保持しているかどうか | 高 |
| ダングリングオブジェクト | タグなしのイメージや孤立した成果物がリビルド後に蓄積 | 本当に参照されておらず回収可能かどうか | 低 |
| Docker Desktopのランタイムデータ | Mac側のディスクイメージとランタイム管理ストレージにより、すべてが一つの大きなブロックに見える | 表示されているホスト側フットプリントが実際の使用量、回収可能な領域、それとも単に割り当てられたランタイムストレージかどうか | 中〜高 |
これが、一般的な「最大フォルダ」ワークフローがDockerには弱い理由です。同じ合計サイズでも、その容量が主にビルドキャッシュなのか実際のボリュームデータなのかによって、クリーンアップの判断は大きく異なります。
| 対象 | 実際の正体 | 典型的なリスク | クリーンアップ後の予想される結果 |
|---|---|---|---|
| ビルドキャッシュ | ビルダーが保持する速度向上目的のリビルドキャッシュ | 低〜中 | キャッシュが再び温まるまで次回のビルドが遅くなる |
| 停止したコンテナ | 保持された書き込み可能レイヤーと容易な再開用コンテナ状態 | 低〜中 | 非アクティブな環境の便利な再開状態を失う |
| 未使用イメージ | アクティブなコンテナが現在必要としていないプル済みまたはビルド済みのイメージ | 中 | 次回の実行で再プルまたは再ビルドが必要になる可能性がある |
| ボリューム | データベース、アップロード、インデックスなどの永続的なローカルサービスデータ | 高 | 実際のローカルプロジェクトデータが消失する可能性がある |
Dockerイメージと共有レイヤー
イメージは開発者が最初に思い浮かべるものですが、より深い話題はレイヤーです。複数の言語ランタイム、CI的なローカルビルド、複数のマイクロサービスを持つマシンは、多くの共有レイヤーと固有レイヤーを急速に蓄積できます。
そのため、ディスク使用量は必ずしもプルした記憶のあるイメージリストときれいに対応するとは限りません。
Dockerビルドキャッシュ
ビルドキャッシュはアクティブな開発マシンで最も一般的な隠れた原因の一つです。将来のビルドを高速にするために存在し、クリーンするまで保持されます。つまり、削除することは通常、パフォーマンスのトレードオフであり、無料の利益ではありません。
停止したDockerコンテナ
開発者はこれを常に過小評価します。実行されていないコンテナもストレージオブジェクトです。存在している限り、ディスク容量を消費し続ける可能性があります。
Dockerボリューム
ボリュームはリスクが高まる領域です。データベース、パッケージミラー、アップロード、検索インデックス、ローカルレジストリの内容、サービスの状態など、実際に重要なデータを保持している可能性があります。
これがDockerのクリーンアップと通常のキャッシュクリーンアップの違いです。Dockerストレージの中には再構築可能なものがありますが、一部はあなたの環境そのものです。
ダングリングDockerイメージとオブジェクト
ダングリングオブジェクトは多くの場合、最も安全なクリーンアップ候補です。Dockerのpruneドキュメントはダングリングイメージを、タグ付けされておらずどのコンテナからも参照されていないイメージと定義しています。これらはまさに通常の反復作業を通じて増加するタイプの蓄積です。
MacでDockerのディスク使用量を確認する方法
最善の最初のステップはFinderではありません。デーモンが容量を消費していると認識しているもののDockerレベルのビューです。
MacでのDocker自身の推奨はdocker system df -vから始めることで、イメージ、コンテナ、ローカルボリューム、回収可能な領域の使用量が表示されます。これが推測をやめる最も早い方法です。
以下の確認順序を使用してください：
1. docker system df -vから始める
以下が表示されるため、最良の最初のサマリーです：
- イメージの合計および回収可能な使用量
- コンテナの使用量
- ローカルボリュームの使用量
- verboseフラグを使用した場合のより詳細な内訳
回収可能な領域が少ない場合、広範なクリーンアップはあまり役に立たないでしょう。
2. pruneする前に停止したコンテナを確認する
もう誰も必要としていない終了したコンテナが多くないか確認してください。これらはボリュームやアクティブなランタイム状態に比べて、通常は安全なクリーンアップ候補です。
3. イメージとビルドキャッシュを分けて確認する
イメージとビルドキャッシュは異なる問題を解決します。キャッシュが主な原因の場合、キャッシュに焦点を当てたクリーンアップは、Dockerが所有するすべてを広範にリセットするよりも通常良い結果をもたらします。
4. --volumesを使用する前にボリュームを確認する
これは人々が飛ばして後悔する部分です。ボリュームは現在実行中のコンテナからは切り離されているように見えても、明日再開する予定のプロジェクトの実際のローカルデータを表している可能性があります。
5. Docker DesktopのMac側のディスク状況を確認する
DockerのMac FAQでは、Docker DesktopがLinuxコンテナとイメージを単一のディスクイメージファイルに格納し、一部のツールは実際の消費量ではなく最大ファイルサイズを表示すると指摘しています。これは重要です。ホスト側の怖い数字は、必ずしも即座に回収可能な無駄と同じではありません。
Dockerクリーンアップのルール: 合計容量を確認する前に、回収可能な領域を確認してください。大きなフットプリントだけでは、どのクリーンアップアクションが安全かは分かりません。
pruneする前に確認すべきこと
- 実際の圧力がビルドキャッシュ、イメージ、停止したコンテナ、ボリュームのどれかを確認してください。
- 実行中または最近停止したコンテナがアクティブな作業の一部でないか確認してください。
- ボリュームはキャッシュ確認ではなくデータ確認として扱ってください。
- 問題を解決する最も狭いDocker対応のクリーンアップスコープを選んでください。
- クリーンアップ後のリビルド、再プル、または遅い起動コストを想定してください。
- 一つの大きな不透明なホスト側ディスクイメージの数字に感情的に反応してDockerクリーンアップを行わないでください。
Docker確認用のクイックコマンド
これらの確認コマンドは、何かを削除する前に役立ちます：
docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume lspruneスコープを選択する前に、実際に何が回収可能かを確認するために使用してください。
Dockerフォルダの直接削除が危険な理由
直接削除は決断力があるように見えるため魅力的ですが、Dockerクリーンアップをランタイムクリーンアップの賭けに変える方法でもあります。
理由は2つあります。
第一に、Dockerはランタイム状態とメタデータを追跡しています。Docker自身のワークフロー外でDocker管理ファイルを削除すると、ランタイムが存在すると認識しているものと実際にディスクにあるものの間の整合性が壊れるリスクがあります。
第二に、MacではDockerのフットプリントがDocker Desktopの管理するディスクイメージとランタイムストレージに紐付いています。Docker自身のMac向けドキュメントは、Finderで直接ディスクイメージを移動しないよう明確に警告しています。Docker Desktopがそれを見失う可能性があるためです。同じ教訓はDocker管理ストレージ内の力技削除にも当てはまります。Docker対応のアクションはファイルシステムの推測よりも安全です。
また、実行中のコンテナ内でファイルを削除することは、ホストのディスク容量を回収することと同じではありません。DockerのMac向けドキュメントは、ホスト側の領域はファイルが実行中のコンテナ内で消滅した時ではなく、イメージが削除された時に回収されると指摘しています。
pruneが役立つ場合
pruneは、すでにフットプリントを理解しており、Dockerが未使用と見なすオブジェクトを削除したい場合に有用です。
役立つ主なケースは単純です：
- 停止したコンテナ、未使用のネットワーク、ダングリングイメージ、未使用のビルドキャッシュが蓄積した時の
docker system prune - ビルドキャッシュが本当の問題である時の
docker builder prune - 未使用のボリュームが本当に使い捨てであることを確認した後の
docker volume prune - すべてを一掃するのではなくスコープを絞りたい時の時間やラベルによるフィルタ付きクリーンアップ
ここでは、Docker対応のクリーンアップが直接ファイル削除より明確に優れています。ランタイムはオブジェクトタイプを理解していますが、Finderは理解していません。
docker system pruneが危険な場合
危険なのはpruneが悪いということではありません。危険なのは、Dockerにおける「未使用」が「ワークフローにとって重要」を意味する可能性があるということです。
以下の場合に注意してください：
- 停止したコンテナが再開予定のローカル環境の一部である
- 次回のビルドが、これから消去しようとしているキャッシュを必要としている
- ローカルボリュームにまだ重要なデータベースやサービスデータが含まれている
docker system prune -aが現在は実行されていないがアクティブな作業の一部であるイメージを削除する- ボリュームが何を表しているかを確認せずにボリュームクリーンアップを追加しようとしている
Dockerのドキュメントは、データを破壊する可能性があるためボリュームは自動的には削除されないと明記しています。これがボリュームクリーンアップ全般における正しいメンタルモデルです。ボリュームはイメージやダングリングキャッシュよりも慎重に扱うべきです。
クリーンアップの前に影響を理解する方法
何かをクリーンアップする前に、平易な言葉で影響の質問に答えてください：
クリーンアップ後、何をリビルド、再プル、リストア、再作成する必要がありますか？
この質問は「どれくらい削除できるか？」よりも有用です。
Dockerの場合、実際の確認は通常次のようになります：
- メインのフットプリントはイメージ、ビルドキャッシュ、停止したコンテナ、ボリュームのどれか？
- 実行中のコンテナは計画の一部か、それともクリーンアップに先立って停止する必要があるか？
- キャッシュをpruneした場合、その後の遅いビルドや再プルに問題はないか？
- ボリュームをpruneした場合、どのサービス状態やデータが一緒に消えるか？
- Dockerクリーンアップは実際の回収可能領域の問題を解決するために行っているのか、それとも一つの大きな不透明なディスクイメージに反応しているだけか？
これが、制御された開発者クリーンアップとランダムなストレージパニックの違いです。
開発者向けクリーンアップが通常のファイルクリーンアップと異なる理由
通常のファイルクリーンアップは「どのフォルダが大きいか？」と尋ねます。
Dockerのクリーンアップには異なる質問が必要です：
- これは再構築可能なキャッシュか、永続的なサービスデータか
- ランタイムはこれを回収可能として報告しているか
- クリーンアップはファイルシステムの削除ではなくDockerコマンドを通じて行うべきか
- 実行中のコンテナ、停止したコンテナ、ボリュームは影響モデルの一部か
- リスクの高いクリーンアップパスを適用する前にガイド付き確認が必要か
だからこそ、Dockerはコンテナ対応のワークフローに属し、ダウンロードの削除や汎用キャッシュフォルダの空袋化と同じカテゴリで考えるべきではありません。
StorageRadarの位置づけ
これは重要です。Dockerは単なる「一つの大きなフォルダ」ではないからです。異なるクリーンアップの影響を持つオブジェクトタイプのエコシステムです。
ビルドキャッシュが問題であれば、アクションはボリューム中心のマシンとは異なります。実行中のコンテナを先に停止する必要がある場合、それはクリーンアップの前に可視化されるべきです。プロファイルがリスクの高い場合、ワークフローは意図的にペースを落とすべきです。
pruneする前にDockerのフットプリントを確認しましょう。
Dev Cleanupを見るやってはいけないこと
以下のよくある間違いを避けてください：
- すべての大きなDockerフットプリントを一つのコマンドで解決できる一つの問題として扱わないでください
- Docker管理ディレクトリ内でパスが大きく見えるという理由で直接
rm -rfを実行しないでください - 大きなDocker Desktopのディスクイメージが、その容量のすべてが今すぐ安全に回収可能であることを意味すると想定しないでください
- ボリュームが何を保持しているか確認せずに、安易にボリュームクリーンアップを追加しないでください
- 負えないデモ、リリース、ローカル環境のリビルドの直前に広範なpruneを使用しないでください
Dockerがより大きな開発マシンの問題の一部に過ぎない場合は、MacのXcode DerivedDataが多すぎる場合に最初に何をクリーンアップすべきかが次にお勧めの記事です。
まとめ
MacのDockerディスク使用量は、適切な分類に分ければ通常もはや謎ではありません。最大の要因は通常、イメージ、レイヤー、ビルドキャッシュ、停止したコンテナ、ボリューム、ダングリングオブジェクト、そしてDocker Desktopのランタイムストレージです。
安全なアプローチは、まずフットプリントを確認し、再構築可能な成果物と永続的なデータを分離し、影響を理解した上でのみDocker対応のクリーンアップを使用することです。
よくある質問
MacでDockerはなぜあんなにディスク容量を使うのですか？
Dockerは時間をかけてイメージ、共有レイヤー、停止したコンテナ、ビルドキャッシュ、ボリューム、ランタイムデータを蓄積します。Macでは、Docker DesktopがLinuxコンテナとイメージを大きなディスクイメージ内に格納するため、増加が不透明に感じられることがあります。
MacでDockerのディスク使用量を確認するにはどうすればよいですか？
docker system df -vから始め、イメージ、停止したコンテナ、ボリューム、大きな数値が実際に回収可能な使用量なのか、それとも設定されたディスクイメージの上限なのかを確認してください。
Finderやrm -rfでDockerフォルダを直接削除しても安全ですか？
通常は安全ではありません。Dockerは独自のランタイム状態とメタデータを管理しており、MacではDocker Desktopがディスクイメージファイルを管理しています。フォルダの直接削除はDockerの同期を崩し、重要な状態を失ったり、クリーンアップの混乱を引き起こす可能性があります。
Macでdocker system pruneはいつ役立ちますか？
停止したコンテナ、ダングリングイメージ、未使用のネットワーク、ビルドキャッシュが蓄積している場合に有用です。これは確認ファーストのクリーンアップ手順であり、あらゆるDockerの容量問題に対する万能策ではありません。
pruneが危険になるのはどんな時ですか？
ボリュームに実際のデータが含まれている可能性がある場合、停止したコンテナやキャッシュされたレイヤーにまだ依存している場合、または広範なクリーンアップが次回のビルド、プル、ローカル環境の復元を遅くする場合にリスクが高まります。
Dockerボリュームはイメージやビルドキャッシュと同じですか？
違います。イメージとビルドキャッシュは多くの場合再構築可能です。ボリュームには永続的なコンテナデータが格納される可能性があるため、クリーンアップ前により慎重な確認が必要です。