エラーの概要
イメージをビルドしたり、レジストリからプルしたり、コンテナを起動しようとした瞬間、Dockerが突然止まります：
no space left on device
もう少し長いメッセージの中に埋め込まれていることもあります：
Error response from daemon: failed to create rootfs for container: ...: no space left on device
failed to solve: failed to read dockerfile: error from sender: write /tmp/...: no space left on device
Error pulling image: write /var/lib/docker/...: no space left on device
Dockerはため込み癖があります。キャッシュされたレイヤー、停止中のコンテナ、タグなしイメージ、未使用ボリューム――これらがディスクの限界に達するまで、気づかないうちに積み重なっていきます。それが今起きていることです。
実際に容量を食っているものを確認する
やみくもに削除し始めるのは禁物です。まずこの2つのコマンドを実行してください：
# Dockerの使用容量内訳
docker system df
# ホスト全体のディスク使用量
df -h
docker system dfの出力はこのようになります：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 42 5 18.4GB 15.1GB (82%)
Containers 12 2 1.2GB 1.1GB (92%)
Local Volumes 8 3 4.3GB 2.1GB (48%)
Build Cache - - 3.8GB 3.8GB
RECLAIMABLEの列に注目してください。現在稼働中のものに手を加えずに回収できる容量がわかります。
手順を追った解決方法
手順1 — 素早い解決策（安全）
Dockerのオールインワンクリーンアップコマンドです。停止中のコンテナ、未使用のネットワーク、タグなしイメージ、ビルドキャッシュを削除します：
docker system prune
Dockerは削除対象を明示して確認を求めます。-fで確認をスキップできます：
docker system prune -f
最も安全な選択肢です。現在使用中でないものにしか触れません。まずここから始めましょう。
手順2 — 未使用イメージを削除する（より大きな節約）
デフォルトでは、system pruneはダングリングイメージ（名前のないタグなしレイヤー）しか削除しません。コンテナから参照されていないイメージも削除するには：
docker image prune -a
アクティブな開発マシンで数ギガバイトを解放できます。デメリットとして、ベースイメージも削除されます。次のビルド時に再ダウンロードされますが、回線が遅いか従量制でなければ問題ありません。
手順3 — ボリュームを整理する
ボリュームは意図的にsystem pruneから除外されています。データベースのデータや設定など、大切なデータが含まれている可能性があるからです。未使用のものを明示的に削除するには：
docker volume prune
またはオールインワンコマンドに組み込むこともできます：
docker system prune --volumes
手順4 — 最終手段
Docker関連のすべてを一度に消去したいですか？これがそのコマンドです：
docker system prune -a --volumes -f
実行中のコンテナとそのイメージはそのまま残ります。それ以外はすべて削除されます。何も保存する必要のないCIマシンや開発環境に最適です。
手順5 — ホストのディスクがまだ満杯の場合
常にDockerが原因とは限りません。古いログ、コアダンプ、ビルド成果物も溜まっていきます。これらを探し出しましょう：
# システム上で最も大きなディレクトリ
du -sh /* 2>/dev/null | sort -rh | head -20
# 500MB以上のファイル
find / -size +500M -type f 2>/dev/null
よくある原因：アプリログで膨れ上がった/var/log、/tmp内のコアダンプ、CIジョブの残留ビルド成果物。
手順6 — Dockerのデータディレクトリを移動する
ルートパーティションが小さく、より大きなマウント済みディスクがある場合は、Dockerの保存先をそちらに変更しましょう。/etc/docker/daemon.jsonを編集します：
{
"data-root": "/mnt/large-disk/docker"
}
その後、Dockerを再起動します：
sudo systemctl restart docker
移動後はイメージを再プルする必要があります。しかし、限界に何度もぶつかるようであれば、これで症状ではなく根本原因が解決されます。
修正を確認する
容量が回復したことを確認します：
df -h
docker system df
その後、失敗していた操作を再試行します：
docker pull nginx:latest
# または
docker build -t myapp .
# または
docker run --rm hello-world
エラーが出なければ完了です。
再発を防ぐには
- CI/ビルドサーバーで週次プルーンをスケジュールする。
docker system prune -fを週1回実行するcronジョブを設定しておくと、問題になる前に蓄積を防げます。 - ビルドキャッシュサイズを制限する（
/etc/docker/daemon.json）：
{
"builder": {
"gc": {
"enabled": true,
"defaultKeepStorage": "10GB"
}
}
}
- Docker Desktopの場合 — Settings → Resources → ディスクイメージのサイズ制限を増やす。またはダッシュボードから：Troubleshoot → Clean / Purge data。
- 100%ではなく80%でアラートを設定する。 ディスクが満杯になる頃にはすでにビルドが失敗しています。早めに監視のしきい値を設定しましょう。
- キャッシュが古い場合は
--no-cacheを使う。 古いレイヤーが積み重なるのではなく置き換えられるため、イメージサイズを適正に保てます。