docker system pruneしてもディスク容量が減らない時の原因と対処法【Mac/OrbStack 2026年版】

エンジニアのゆとです。

先週、Macの空き容量が「あと3GB」まで減っていることに気づいた。Docker関連のイメージやコンテナは定期的に消してるはずなのに、なぜか減らない。とりあえずdocker system prune -aを叩いた。

数字上は「12.4GB解放しました」と出た。でもFinderの空き容量表示は変わらなかった。

「え、消えたんじゃないの」と一瞬フリーズした。この記事は、そのときに調べて分かった「pruneしても減らない理由」と、実際にやった対処を整理したものだ。

まず状況を確認する — docker system df

pruneする前に、何にどれだけ食われてるかを見る。

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          38        6         14.2GB    11.8GB (83%)
Containers      9         2         421MB     380MB (90%)
Local Volumes   14        3         3.1GB     1.9GB (61%)
Build Cache     124       0         6.7GB     6.7GB (100%)

自分の環境では、ビルドキャッシュだけで6.7GB、使ってないイメージが11.8GB分あった。合計すると20GB超が「解放できるはず」の領域だった。

内訳をもう少し細かく見たいなら-vをつける。

docker system df -v

イメージごと・ボリュームごとのサイズが一覧で出るので、「このイメージ、なんでこんなにデカいんだ」を個別に特定できる。ここでよく見つかるのが、<none>タグの付いたdangling image。ビルドし直すたびに古いレイヤーが<none>として残り続け、消し忘れると静かに積み上がる。

docker system pruneの基本と、それぞれの範囲

# 停止中コンテナ・未使用ネットワーク・dangling imageを削除
docker system prune

# 未使用イメージも全部削除（tagが付いていても使われてなければ消す）
docker system prune -a

# ボリュームも含めて削除（データが消えるので要注意）
docker system prune -a --volumes

# 一定期間より前に作られたものだけ削除
docker system prune -a --filter "until=24h"

自分がよくやる事故が、-aを付け忘れて「あれ、イメージ全然減ってない」と焦るパターン。docker system prune単体だとdangling imageしか消さない。tagが付いた未使用イメージまで消したいなら-aが必須になる。

逆に--volumesは名前付きボリュームも巻き込むので、DBのデータが入ってるボリュームを不用意に消すと詰む。案件で使ってるプロジェクトなら、docker volume lsで中身を確認してから実行したほうがいい。

それでもホスト側のディスクが減らない理由

ここが今回一番ハマったポイントで、docker system dfの数字とMacの「空き容量」表示が一致しない。

MacにはLinuxカーネルがないので、DockerもOrbStackも裏でLinux VMを動かしている。コンテナやイメージの実体は、そのVM専用の仮想ディスクファイル（Docker DesktopならDocker.raw、OrbStackなら内部のディスクイメージ）の中に置かれている。

docker system pruneはVM内部のファイルシステムからデータを消してくれる。ただし、それによって「VM内で空いた領域」がそのまま「Mac本体の空き容量」として返ってくるかどうかは別問題になる。

仮想ディスクはAPFS上のスパースファイルとして作られていて、理屈上は使ってない部分は実サイズを取らない。でも実際には次のようなケースで「減ったはずなのに減らない」が起きる。

• ファイルシステムの断片化で、削除した領域がホストOSに正しく返還されない
• Docker Desktop/OrbStackの自動リサイズ処理が、直後ではなく一定間隔でしか走らない
• 仮想ディスクの「最大到達サイズ」自体は縮まらず、内部の空き領域が増えるだけ

要するに、コンテナの中身を消しても、それを包んでる箱（仮想ディスクファイル）自体は縮まないことが多い。

Docker Desktopの場合の対処

Docker Desktop側で確実に効くのは、仮想ディスクの再作成・上限設定・完全リセットの3つ。

上限を決めて運用する場合は、Settings → Resources → Advanced → Disk usage limit で仮想ディスクの最大サイズを固定する。上限を超えそうになるとDocker Desktop側が古いレイヤーを自動整理してくれるようになるので、青天井で膨らむのをそもそも防げる。

それでも実際に減らない場合、最終手段は Troubleshoot → Clean / Purge data。これは仮想ディスクを含めて全データを初期化する操作で、コンテナもイメージもボリュームも全部消える。案件用のDBデータが残ってる場合は、事前にdocker execでダンプを取ってからにする。

# 実行前にDBデータをバックアップしておく例
docker exec -t my-postgres pg_dumpall -U postgres > backup.sql

Purge data後は仮想ディスクファイル自体が最小サイズで再生成される。数字上ではなく、Finderの空き容量表示が実際に戻ることを確認できるのはこのタイミングだった。

OrbStackの場合の対処

自分は普段OrbStackを使っている（Docker Desktopのメモリ問題に耐えられなくなって乗り換えた経緯は

に書いた）。OrbStackはディスク管理も「基本的に自動でやってくれる」設計になっていて、Docker Desktopより気にしなくていい場面が多い。

ただしOrbStackでも詰まるケースがある。自分が実際に踏んだのは次の2つ。

1つ目は、大量のイメージをpull & 削除を繰り返した後、内部ディスクイメージのサイズが増えたまま高止まりするケース。OrbStackのメニューバーアイコン → Settings → General から「ディスク領域の再利用」に相当する操作を実行すると、内部的にコンパクト化が走って空き容量が戻る。

2つ目は、コンテナのログファイルが肥大化しているケース。長時間動かしっぱなしのコンテナは、標準出力へのログがそのままjson-fileドライバーで無制限に溜まり続ける。

# ログサイズの上限を設定する（daemon.jsonに追記）
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

これを設定しておくと、1コンテナあたりのログが最大30MBで頭打ちになる。長時間稼働のバックエンドコンテナを動かしてる人は、これを最初から設定しておいたほうがいい。地味だが、気づいたら数GB溶かしてるパターンの犯人は大体これだった。

Claude Codeでworktreeを並行運用してると特に溜まりやすい

これは自分の環境特有の話かもしれないが、書いておく価値はあると思う。

で書いたとおり、自分はClaude Codeで複数のgit worktreeを並行運用して、ブランチごとに別々の作業を同時に進めることがある。この構成だと、ブランチごとに検証用のDocker環境を都度立てるので、コンテナとイメージの数が単純作業のときより増える。

さらに厄介なのが、Claude Codeにテストやビルドを丸投げしてる時ほど「動作確認が終わったコンテナを手動で消す」作業を忘れがちになることだ。人間が手を動かさない分、docker stopやdocker rmを打つタイミングが自然発生しない。気づいたら止まったコンテナが十数個溜まっていて、それぞれがベースイメージを個別に持っていて、というのが自分の実際のパターンだった。

対策として、CLAUDE.mdに「作業完了時にdocker composeで立てたコンテナをdownすること」を明記して、Claude Code自身にクリーンアップまでやらせるようにした。これでだいぶマシになった。人間が忘れるならAIに忘れさせないルールを書けばいい、という当たり前の話ではある。

再発防止 — 定期的にチェックする仕組みを作る

一回きれいにしても、開発を続ければまた溜まる。自分は次の2つだけ運用に組み込んだ。

エイリアスで「今の状況」をワンコマンドで見れるようにする。

# ~/.zshrc に追記
alias dfd='docker system df'
alias dclean='docker system prune -a --filter "until=168h"'

dcleanは1週間以上前に作られた未使用リソースだけを消す設定にしてある。稼働中のプロジェクトを巻き込まずに、古いゴミだけ定期的に片付けられる。

週に1回、dfdを打つ習慣をつけるだけで「気づいたら空き容量が3GB」という事態はかなり防げる。プルーニングは事後対応より、定期チェックの方が効く。

まとめ

• docker system pruneはVM内部のデータは消すが、ホスト側の空き容量にすぐ反映されるとは限らない
• 原因は仮想ディスクファイル（Docker.rawなど）が縮みにくい構造にあること
• Docker Desktopは上限設定＋最終手段のPurge dataで確実にリセットできる
• OrbStackは自動でやってくれる場面が多いが、ログ肥大化とディスク再利用の手動実行は覚えておく価値がある
• Claude Codeでworktreeを並行運用してると、クリーンアップ忘れでゴミが溜まりやすい。CLAUDE.mdに片付けルールを書いておくと解決する
• docker system dfを週1回見る習慣が、一番コスパのいい対処法だった

この記事は自分の環境（Docker Desktop / OrbStack両方を実際に運用中）で実際にディスク容量の問題に遭遇した上で、原因調査と対処を行った内容をまとめています。

よくある質問

docker system prune とは何ですか?

停止中のコンテナ、未使用のネットワーク、dangling image（タグなしの未使用イメージ）をまとめて削除するコマンド。-aオプションを付けると、タグが付いていても使われていないイメージまで削除対象になる。--volumesを付けるとボリュームも削除されるが、データが消えるため実行前に中身の確認が必要。

docker system prune を実行してもディスク容量が減らないのはなぜですか?

MacやWindowsのDockerはLinux VMの中でコンテナを動かしており、実データはVM専用の仮想ディスクファイルに格納されている。docker system pruneはVM内部のデータを削除するが、その仮想ディスクファイル自体のサイズはすぐには縮まないことが多い。断片化や自動リサイズ処理のタイミングの問題で、Finderの空き容量表示に反映されるまでタイムラグが生じる、あるいは反映されないケースがある。

Dockerのディスク使用量はどうやって確認しますか?

docker system dfでイメージ・コンテナ・ボリューム・ビルドキャッシュそれぞれの使用量と削除可能量が一覧表示される。-vオプションを付けると、イメージ1つ1つのサイズまで細かく確認できる。

Dockerのディスク容量に上限は設定できますか?

Docker Desktopなら Settings → Resources → Advanced → Disk usage limit で仮想ディスクの最大サイズを固定できる。上限に近づくと自動的に古いレイヤーの整理が走るようになるため、青天井の肥大化を防げる。OrbStackにも同様のリソース制限設定がある。

OrbStackでもディスクが減らないことはありますか?

ある。よくある原因は、稼働中コンテナのログファイル肥大化と、大量のイメージをpull・削除した後の内部ディスクイメージの高止まり。ログはdaemon.jsonでmax-sizeとmax-fileを設定して上限を切り、ディスクイメージはOrbStackのSettingsからディスク領域の再利用を手動実行すると解消することが多い。

関連記事

Jun 23, 2026 OrbStack vs Docker Desktop 徹底比較 — Macのメモリを半分取り戻す方法【2026年版】OrbStack と Docker Desktop を料金・メモリ・機能・ユースケースの4軸で比較。個人開発者が乗り換えるべきタイミング、ライセンスが必須になる条件（年$10k超・商用・フリーランス）、Docker Desktop を残すべき理由まで正直に書く。2026年6月更新。読む →

Jun 13, 2026 MacのDockerが重い・遅い問題を解決する2026——OrbStack・Colima・Limaを比較して選ぶDocker DesktopのメモリをMacで食いすぎる問題の根本原因と、OrbStack・Colima・Limaそれぞれの特徴・設定・使い分けを実測データをもとに解説。個人開発者がどれを選ぶべきか結論を出す。読む →

Apr 27, 2026 Docker DesktopからOrbStackに3ヶ月乗り換えた結果レポート — メモリ・CI連携・ハマりどころの実測記録Docker Desktop から OrbStack に乗り換えて3ヶ月が経過。メモリ使用量の実測値・Docker Composeの互換性・GitHub Actions連携・日常業務でのパフォーマンス変化を正直にレポート。移行を迷っている人向けの実体験記録。読む →