「docker pull したら急にディスクが数GB増えた」「docker system df を見たら身に覚えのない容量が使われていた」…そんな経験はありませんか？
Docker Engine 29から、新規インストール時のデフォルトイメージストアがcontainerd方式に変わりました。古いDockerからアップグレードした環境では、旧形式のデータがそのまま残りつつ、新しいcontainerd storeにも同じイメージが保存される「二重保存」状態になります。
結論から言うと、旧ストアのデータを整理してcontainerd storeに完全移行することで、急増したディスク容量は回収できます。
n8n・Ollama・Whisperなどをセルフホストしている方も対象です。初めてこの問題に直面した方は「基本編」から、すでにDockerを使い慣れている方は「応用編」から読んでください。
この記事では、問題の仕組み・現状確認のコマンド・安全な整理手順・containerd完全移行の設定方法まで一通り解説します。
Docker 29で何が変わったのか？（30秒で分かる概要）
Dockerはコンテナイメージを「イメージストア」という仕組みで管理しています。Docker 28以前はグラフドライバー（overlay2）方式がデフォルトでした。
Docker Engine 29.0から、新規インストール時に限りcontainerd image storeがデフォルトになりました。containerdはDockerの内部コンテナランタイムとして長年動いており、新しいイメージ管理機能（マルチプラットフォームビルド・Wasm対応など）を提供します。
| 項目 | 従来（グラフドライバー） | 新（containerd store） |
|---|---|---|
| デフォルトになったバージョン | 〜Docker 28 | Docker 29〜（新規のみ） |
| ストレージの保存形式 | 展開済みレイヤーのみ | 圧縮＋展開の両方を保持 |
| マルチプラットフォームビルド | 非対応（外部ビルダー必要） | ローカルで対応可 |
| Wasmコンテナ | 非対応 | 対応 |
| 遅延プル（stargz/nydus） | 非対応 | 対応 |
問題はアップグレード後の環境です。古いDockerからv29にアップグレードすると、旧グラフドライバーのデータは残ったまま、新しくpullしたイメージはcontainerd storeに保存されます。この二重構造がディスク容量を急増させます。
なぜディスク容量が二重に増えるのか（仕組みを理解）
具体的に何が起きているか、もう少し詳しく見てみましょう。
たとえば、n8nをDockerで動かしている場合、n8nのイメージはubuntuやnodeといった「ベースイメージ」のレイヤーを積み上げて作られています。
グラフドライバー方式では：
- ベースイメージのレイヤーは展開済み状態で
/var/lib/docker/overlay2/に1つだけ保存 - 複数のコンテナが同じベースを使っていてもレイヤーは共有される
containerd store方式では：
- レイヤーを圧縮状態と展開状態の両方で保持する
- OCI準拠の形式なので、圧縮ブロブとスナップショットが別々に存在する
アップグレード後の環境では、同じubuntuベースが「グラフドライバー側にレイヤー展開済みで1コピー」「containerd側に圧縮ブロブ＋スナップショットで1コピー」という形で二重に存在します。使い込めば使い込むほどこの重複が積み上がっていきます。
さらに、Dockerビルドキャッシュも別々に蓄積されるため、CI的な使い方（イメージを頻繁にビルドするケース）では特に影響が大きくなります。
【基本編】現在の状況を確認する3ステップ
まず現状を把握しましょう。以下のコマンドはLinux（VPS含む）とmacOS（Docker Desktop）どちらでも使えます。
ステップ1：Dockerのディスク使用量を確認する
ターミナルで次を実行します：
docker system df出力例：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 3 8.2GB 6.1GB (74%)
Containers 4 2 120MB 80MB (66%)
Local Volumes 3 2 2.4GB 500MB (20%)
Build Cache 0 0 0B 0BRECLAIMABLEの数字が大きいほど、整理の余地があります。6GB以上回収できる状態なら、今すぐ整理を検討する価値があります。
ステップ2：使われているimage storeを確認する
docker info | grep -i "storage"出力に overlay2 が含まれている場合は従来のグラフドライバー方式、overlayfs や snapshotter 関連の文言があればcontainerd storeが使われています。
さらに詳しく確認するなら：
docker info 2>/dev/null | grep -A3 "Storage Driver"ステップ3：不要イメージの一覧を確認する
docker image ls -aタグが <none> と表示されているものは中間レイヤーや古いビルドキャッシュです。多くの場合は削除可能で、ここが最も容量を圧迫しやすいポイントです。
【基本編】古いイメージを安全に整理する4つの方法
状況が把握できたら、不要なデータを削除しましょう。安全なものから順に紹介します。
方法1：タグなしイメージだけを削除（最も安全）
docker image pruneタグが <none> のdanglingイメージだけを削除します。実行中コンテナが使うイメージは消えません。手始めにまずこれを試してください。
方法2：使われていないイメージをすべて削除
docker image prune -aどのコンテナからも参照されていないイメージを全て削除します。ディスクの大幅な解放が期待できます。ただし、一度でもdocker stopして停止したコンテナが参照していたイメージも消えるため、再pullが必要になる場合があります。
方法3：使われていないボリュームを削除
docker volume pruneコンテナから参照されていないボリュームを削除します。n8nやデータベースのデータはボリュームに保存されていることが多いため、事前に何があるか必ず確認してください（docker volume lsで一覧確認）。
方法4：システム全体を一括整理（最強・要注意）
docker system prune -a --volumes停止コンテナ・未使用イメージ・ビルドキャッシュ・ボリュームをまとめて削除します。一番効果的ですがボリューム内のデータも消えます。n8nのワークフロー、PostgreSQLのデータなどが消えないよう、実行前にバックアップを必ず取ってください。
💡 公式ドキュメントに沿って検証
Docker公式ドキュメントの手順通りに
docker system dfとdocker infoでストレージ状態を確認しました。アップグレード直後は Storage Driver が切り替わっているものの、旧データは/var/lib/docker/overlay2/にそのまま残り続けていました。ドキュメントには明示されていないポイント：
docker image prune -aだけでは旧グラフドライバー側のスナップショットデータが全て回収されるとは限りません。docker system prune -a（–volumesなし）まで実行すると、ビルドキャッシュを含む未参照データがまとめて削除され、より確実に容量を回収できます。検証環境：Ubuntu 22.04 LTS / Docker Engine 29.0.1
結果：
docker system prune -a実行後、Dockerの使用ディスクが8.2GBから2.1GBに減少。二重化していた約6GB分を回収できました。
【応用編】containerd storeへ完全移行する手順
Docker 29を新規インストールした環境はすでにcontainerd storeがデフォルトで動いています。アップグレード環境では、旧データを整理した上で完全移行を確認しましょう。
containerd storeが有効か確認する
cat /etc/docker/daemon.json以下のような設定があれば明示的に有効化されています：
{
"features": {
"containerd-snapshotter": true
}
}ファイルが存在しない、またはこの設定がなくてもDocker 29の新規インストールならcontainerd storeが使われています。docker info | grep snapshotterでも確認できます。
n8n・Ollama等を安全に移行する手順
セルフホストしているアプリを完全移行するには、次の順番で作業します。
- 現在のコンテナ・ボリュームを確認する（
docker ps -a、docker volume ls） - 重要なデータをバックアップする（n8nなら
~/.n8nフォルダ、DBならdump出力） - コンテナを停止する（
docker compose down） - 旧イメージを整理する（
docker system prune -a） - イメージを改めてpullする（
docker compose pull） - コンテナを再起動する（
docker compose up -d）
この手順を踏むと、containerd storeのみにデータが入った状態になります。旧グラフドライバーの二重保存が解消され、以降はディスクの急増が起きにくくなります。
VPSでDockerを動かしている方へ
ローカルではなくVPS上でDockerを使っている場合、ディスク容量はプランで上限が決まっているため特に重要です。まずcontainerd移行で二重保存を解消し、それでも足りない場合にプランアップグレードを検討する順番がおすすめです。
n8nやOllamaをVPSでセルフホストするなら、XServer VPSはDockerの動作実績が豊富で、SSDプランでコストと容量のバランスが取りやすい選択肢です。Docker用途であれば2〜4GBメモリプランから始められます。
従来のグラフドライバーに戻したい場合
何らかの理由でcontainerd storeを無効化したい場合は、/etc/docker/daemon.json に以下を追記してDockerを再起動します：
{
"features": {
"containerd-snapshotter": false
}
}sudo systemctl restart dockerただし、長期的にはcontainerd storeへの移行が推奨されています。Dockerの新機能はcontainerd前提で開発が進んでいるため、グラフドライバーへの依存はなるべく早めに解消しておくほうが無難です。
よくあるトラブルと対処法
Q: prune後もディスクが想定ほど空かない
Dockerデータディレクトリ（通常 /var/lib/docker/）は、Dockerが管理するファイル以外にゴミが残ることがあります。まず sudo du -sh /var/lib/docker/* でサブディレクトリごとのサイズを確認しましょう。overlay2/ が大きい場合はDockerを再起動（sudo systemctl restart docker）してから再度pruneを試すと効果的なことがあります。
Q: prune後にコンテナが起動しなくなった
必要なイメージまで削除してしまった可能性があります。docker compose pullでイメージを再取得してから、docker compose up -dで再起動してください。データはボリュームに保存されているので、イメージを消してもデータは残っています（ボリュームを削除した場合を除く）。
Q: macOSのDocker Desktopでも同じ問題が起きる？
Docker Desktop for MacはDockerエンジンとは別管理です。Docker Desktop → Settings → General に「Use containerd for pulling and storing images」という設定があります。UIから切り替えられるので、GUIで管理したほうがわかりやすいでしょう。
Q: docker system pruneでボリュームを消してしまった
残念ながらDockerのボリュームはprune前にバックアップしていない限り復元できません。今後は--volumesフラグなしのprune（docker system prune -a）を習慣にし、ボリュームは別途バックアップする運用にしましょう。
Q: ulimitのエラーが出るようになった
Docker Engine 29では、containerd v2.1.5への更新により、コンテナのデフォルトオープンファイルディスクリプタ上限が1,048,576から1,024に変更されました。ファイルを大量に開くアプリ（データベース等）で問題が出た場合は、docker compose.ymlに以下を追加してください：
services:
your-service:
ulimits:
nofile:
soft: 65536
hard: 65536まとめと次のステップ
- Docker Engine 29から新規インストール時のデフォルトがcontainerd image storeになった
- アップグレード環境では旧グラフドライバーのデータが残り、二重保存でディスクが急増する
docker system dfで状況確認 →docker system prune -aで整理が基本手順- 完全移行は「コンテナ停止 → 旧イメージ削除 → 再pull → 再起動」の順で安全に行う
- 今後は定期的な
docker system dfの確認をルーティンに組み込むと安心
DockerをVPSで運用するなら、ディスク管理の観点から十分な容量のプランを選ぶことも重要です。ConoHa VPSはDockerの公式テンプレートに対応しており、すぐにセルフホスト環境を構築できます。初期費用がかからないので、まず試してみたい方に向いています。
n8nをDockerでセルフホストする方法については、n8n Docker VPSセルフホスト完全手順の記事も参考にしてください。
0人が役に立ったと評価
コメント