Docker「no space left on device」エラーの原因と対処法｜容量不足を解消

Dockerでビルドや起動を実行した時、以下のエラーが発生した場合の対処法

docker: Error response from daemon: failed to register layer: 
  Error processing tar file(exit status 1): write /var/lib/docker/...: no space left on device.

ERROR: failed to solve: ... no space left on device

failed to copy files: copy file range failed: no space left on device

Error response from daemon: mkdir /var/lib/docker/tmp/...: no space left on device

これは「Dockerが必要としているディスク領域が枯渇した」というエラーです。原因はディスク全体の空き不足だけでなく、/var/lib/dockerの肥大化、未使用イメージの蓄積、ボリュームの放置、ビルドキャッシュ、ログファイル巨大化など、複数箇所に分散しているため切り分けが難しいトラブルです。

• ビルドを繰り返したらディスクが圧迫された
• 起動していないコンテナがあるはずなのに容量が空かない
• df -hで見るとパーティションは余裕がある
• Docker Desktopのディスク使用量が異常
• WSL2のディスクが膨らみ続ける
• CI/CDの実行で何度も失敗する

本記事では、「no space left on device」エラーのすべての原因と対処法を、Linux/Mac/Windows それぞれの環境別に整理します。ディスク状況の特定方法、各種prune コマンドの使い分け、/var/lib/dockerの移動、ログローテーション、Docker Desktop特有の対処、CI/CD予防策、FAQまで完全網羅。この1本でDockerのディスク問題と完全に決別できます。

結論：今すぐ試すべき3ステップ

時間がない方向けに、まず試すべき手順を示します。

ステップ1：Dockerのディスク使用量を確認

docker system df

出力例:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          47        12        15.6GB    8.2GB (52%)
Containers      8         3         1.2GB     800MB (66%)
Local Volumes   25        6         4.3GB     3.1GB (72%)
Build Cache     0         0         2.8GB     2.8GB (100%)

RECLAIMABLEが大きければ、不要データが大量に蓄積されています。

ステップ2：一括クリーンアップ（よくある対処）

# 停止中のコンテナ・未使用ネットワーク・タグなしイメージ・ビルドキャッシュを一括削除
docker system prune

# ボリュームも含めて削除（要注意）
docker system prune --volumes

# 未使用イメージも完全削除（最も解放できる）
docker system prune -a --volumes

⚠️ --volumesはデータが消えます。重要なボリュームは事前に確認・バックアップ。

ステップ3：ホストのディスク状況も確認

df -h
df -i  # inode使用量

# Dockerデータディレクトリの実使用量
sudo du -sh /var/lib/docker

それでも解決しない場合は、以下の詳細分析へ進んでください。

まず押さえる：エラー発生箇所の特定

「no space left on device」と言っても、何の容量が不足しているかで対処法が変わります。

5つの容量不足パターン

全パターンを一気に確認するコマンド

echo "=== ホストディスク ==="
df -h

echo ""
echo "=== inode使用量 ==="
df -i

echo ""
echo "=== Dockerディスク使用量 ==="
docker system df

echo ""
echo "=== /var/lib/docker 実使用量 ==="
sudo du -sh /var/lib/docker

echo ""
echo "=== Dockerログのサイズ ==="
sudo du -sh /var/lib/docker/containers/*/*-json.log 2>/dev/null | sort -h | tail -10

これでどこに問題があるか一目で分かります。

Dockerのディスク使用状況を詳しく見る

docker system df

基本的な容量サマリーを表示:

docker system df

docker system df -v（詳細版）

docker system df -v

各イメージ・コンテナ・ボリュームの個別サイズが見られます。容量を食っている犯人を特定できます。

イメージごとのサイズ

docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k 3 -h

コンテナごとのサイズ

docker ps -a --size --format "table {{.Names}}\t{{.Image}}\t{{.Size}}"

SIZE列が「12MB (virtual 800MB)」のような表示の場合:

• 12MB: コンテナの書き込みレイヤー
• virtual 800MB: 元イメージを含む合計サイズ

ボリュームごとのサイズ

# 全ボリューム
docker volume ls

# 各ボリュームの実サイズ（要root）
sudo du -sh /var/lib/docker/volumes/*/_data 2>/dev/null | sort -h

クリーンアップコマンド完全ガイド

Docker には用途別のクリーンアップコマンドが揃っています。

docker system prune（万能クリーンアップ）

docker system prune

デフォルトで削除されるもの:

• 停止中のコンテナ
• 未使用ネットワーク
• タグの付いていない（dangling）イメージ
• ビルドキャッシュ

確認プロンプトを省略:

docker system prune -f

未使用イメージ（タグ付きも含めて参照されていないもの）も削除:

docker system prune -a

ボリュームも含めて削除（データロス注意）:

docker system prune -a --volumes

docker image prune（イメージ専用）

# danglingイメージ削除
docker image prune

# 未使用イメージすべて
docker image prune -a

# 期間で絞り込み（24時間以上前）
docker image prune -a --filter "until=24h"

docker container prune（コンテナ専用）

# 停止中コンテナを削除
docker container prune

# 24時間以上停止中のものだけ
docker container prune --filter "until=24h"

docker volume prune（ボリューム専用・要注意）

# 未使用ボリュームを削除
docker volume prune

# 全ボリューム（コンテナに紐づいていないもの）
docker volume prune --all

⚠️ ボリュームには永続データ（DB、設定ファイル等）が入っている可能性があります。docker volume lsで確認してから実行してください。

docker builder prune（ビルドキャッシュ専用）

# 未使用ビルドキャッシュ削除
docker builder prune

# 全ビルドキャッシュ削除（次回ビルドは遅くなる）
docker builder prune -a

# 期間絞り込み
docker builder prune --filter "until=24h"

# サイズで絞り込み
docker builder prune --keep-storage 10GB

BuildKit を使っている場合、ビルドキャッシュは予想以上に大きくなりがちです。

docker network prune（ネットワーク専用）

docker network prune

ディスク容量への影響は少ないですが、不要なネットワークを整理できます。

段階的なクリーンアップの推奨手順

# 1. 停止コンテナを削除（最も安全）
docker container prune -f

# 2. dangling イメージを削除
docker image prune -f

# 3. 未使用ネットワーク
docker network prune -f

# 4. ビルドキャッシュ
docker builder prune -f

# 5. 確認しながら未使用イメージ
docker image prune -a -f

# 6. 最終手段：ボリューム含む完全削除
docker system prune -a --volumes -f

ログファイル肥大化問題

Dockerは標準でコンテナのstdout/stderrをJSON形式ログとして保存し続けます。長期稼働コンテナでは数十GBになることもあります。

ログサイズの確認

# 各コンテナのログサイズ
sudo du -sh /var/lib/docker/containers/*/*-json.log 2>/dev/null | sort -h

# 巨大ログトップ10
sudo du -h /var/lib/docker/containers/*/*-json.log 2>/dev/null | sort -h | tail -10

個別コンテナのログ削除

# 特定コンテナのログをゼロにリセット（コンテナ稼働中もOK）
sudo truncate -s 0 /var/lib/docker/containers/CONTAINER_ID/CONTAINER_ID-json.log

# 全コンテナのログをまとめてリセット
sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log

ログローテーション設定（恒久対処）

/etc/docker/daemon.json でログサイズに上限を設定:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

設定後にDocker再起動:

sudo systemctl restart docker

max-sizeを超えると自動でローテーションされ、max-file数より古いログは削除されます。上記設定なら、1コンテナあたり最大30MBに制限されます。

⚠️ 既存コンテナには反映されません。コンテナを作り直す必要があります。

docker-compose.yml でコンテナ単位設定

services:
  myapp:
    image: myapp:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

journald / syslog への移行

ログを Docker から OS のログ管理に委譲する方法もあります:

{
  "log-driver": "journald"
}

logrotate やsystemd-journald の機能でローテーション管理できます。

/var/lib/docker の場所変更（パーティション圧迫対策）

/varパーティションが小さい環境では、/var/lib/dockerを別の大容量パーティションに移動するのが根本対処です。

手順（Linux）

# 1. Docker停止
sudo systemctl stop docker
sudo systemctl stop docker.socket

# 2. 既存データを新場所にコピー
sudo rsync -aP /var/lib/docker/ /data/docker/

# 3. daemon.json で新場所を指定
sudo vi /etc/docker/daemon.json

{
  "data-root": "/data/docker"
}

# 4. Docker起動
sudo systemctl start docker

# 5. 動作確認
docker info | grep "Docker Root Dir"

# 6. 元データ削除（動作確認後）
sudo rm -rf /var/lib/docker

symlinkを使う方法（緊急時）

設定変更を避けたい場合:

sudo systemctl stop docker
sudo mv /var/lib/docker /data/docker
sudo ln -s /data/docker /var/lib/docker
sudo systemctl start docker

ただし長期運用ならdaemon.json設定の方が分かりやすいです。

inode 不足の場合

ディスク容量は余裕があるのに「no space left on device」が出る場合、inode（ファイル数）が枯渇している可能性があります。

確認

df -i

IUse%が100%付近なら inode 枯渇です。

Filesystem      Inodes  IUsed   IFree   IUse%   Mounted on
/dev/sda1      1310720 1310720      0    100%   /

Dockerが大量inodeを使う理由

各イメージレイヤーが多数の小ファイルから構成されるため、レイヤー数 × ファイル数の inode を消費します。

対処

# 未使用イメージ・レイヤーを削除
docker image prune -a -f
docker builder prune -a -f

# 停止コンテナも削除
docker container prune -f

これでもダメな場合、ファイルシステム自体の inode 上限が小さい可能性。mkfs時に-Nオプションで再フォーマットしか手がありません（最終手段）。

大量inode使用ディレクトリの特定

# inode使用が多いディレクトリTop20
sudo find / -xdev -type d -exec sh -c 'echo "$(ls -1 "{}" 2>/dev/null | wc -l) {}"' \; | sort -rn | head -20

Docker Desktop（Mac/Windows）の対処

Docker Desktopは独自の仮想ディスクを使うため、Linux環境と挙動が異なります。

Mac

Docker Desktopの仮想ディスク容量確認

Docker Desktop → Settings → Resources → Disk image size

Mac上でのディスク使用箇所

# 仮想ディスクの場所
ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Windows（WSL2バックエンド）

WSL2の仮想ディスク（ext4.vhdx）の場所

%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx
%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx

WSL2の仮想ディスク圧縮（PowerShellで）

WSL2は使った領域が自動で縮小されないため、Docker内でクリーンアップしてもホスト側のディスク使用量は減らないことがあります。

# WSL停止
wsl --shutdown

# diskpartで圧縮
diskpart

DISKPART> select vdisk file="%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

より簡単な方法

wsl --shutdown
# Optimize-VHD コマンド（要Hyper-V機能）
Optimize-VHD -Path "$env:LOCALAPPDATA\Docker\wsl\disk\docker_data.vhdx" -Mode Full

Docker Desktopでのリセット（最終手段）

Docker Desktop → Settings → Troubleshoot → Clean / Purge data

⚠️ すべてのコンテナ・イメージ・ボリュームが削除されます。

Docker Desktopのディスク容量上限を増やす

Settings → Resources → Advanced → Disk image size スライダーで調整。

Docker Compose環境での対処

Docker Composeで運用している場合の対処パターン。

Compose環境の整理

# 全サービス停止＆削除＆ボリューム削除
docker-compose down -v

# イメージも削除
docker-compose down -v --rmi all

# 別Composeプロジェクトのリソースが残っているか確認
docker ps -a
docker volume ls
docker image ls

Composeプロジェクト名フィルタ

特定のComposeプロジェクトのリソースだけ削除:

# プロジェクト名で絞り込み
docker ps -a --filter "label=com.docker.compose.project=myproject"

# 削除
docker rm $(docker ps -aq --filter "label=com.docker.compose.project=myproject")

Compose設定のログ制限例

services:
  app:
    image: myapp:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
  
  db:
    image: postgres:15
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

すべてのサービスにlogging設定を入れるのが標準的なベストプラクティスです。

CI/CD環境での対処

GitHub Actions・GitLab CI・Jenkins等で頻発する問題です。

GitHub Actions

Runnerのディスクは限られているため、ビルド前にクリーンアップ:

- name: Free disk space
  run: |
    sudo rm -rf /usr/share/dotnet
    sudo rm -rf /opt/ghc
    sudo rm -rf "/usr/local/share/boost"
    sudo rm -rf "$AGENT_TOOLSDIRECTORY"
    docker system prune -af --volumes
    df -h

または便利な専用 Action:

- name: Free Disk Space
  uses: jlumbroso/free-disk-space@main
  with:
    tool-cache: false
    android: true
    dotnet: true
    haskell: true
    large-packages: true
    swap-storage: true

GitLab CI

job:
  before_script:
    - docker system prune -af --volumes
    - df -h
  script:
    - docker build ...

ジョブ実行ごとのクリーンアップ

after_script:
  - docker system prune -af

Self-Hosted Runnerの定期メンテナンス

# cronで毎週日曜深夜に実行
0 3 * * 0 /usr/bin/docker system prune -af --volumes >/var/log/docker-cleanup.log 2>&1

自動クリーンアップ（cron）の実装

定期メンテナンスを cron に登録しておくと、ディスク問題の予防になります。

毎週日曜深夜にクリーンアップ

# crontab -e で追加
0 3 * * 0 /usr/bin/docker system prune -af --filter "until=168h" >> /var/log/docker-cleanup.log 2>&1

until=168hは1週間以前の未使用リソースのみ削除する安全な指定です。

毎日のログトリミング

# crontab -e で追加
0 2 * * * find /var/lib/docker/containers -name "*-json.log" -size +100M -exec truncate -s 0 {} \;

スマートなクリーンアップスクリプト例

#!/bin/bash
# /usr/local/bin/docker-cleanup.sh

LOG=/var/log/docker-cleanup.log
echo "=== $(date) Cleanup start ===" >> $LOG

# 使用率を取得
USAGE=$(df -h /var/lib/docker | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$USAGE" -gt 80 ]; then
    echo "Disk usage: ${USAGE}% - starting aggressive cleanup" >> $LOG
    docker system prune -af --volumes --filter "until=24h" >> $LOG 2>&1
elif [ "$USAGE" -gt 60 ]; then
    echo "Disk usage: ${USAGE}% - normal cleanup" >> $LOG
    docker system prune -f --filter "until=168h" >> $LOG 2>&1
else
    echo "Disk usage: ${USAGE}% - skipping cleanup" >> $LOG
fi

echo "=== End ===" >> $LOG

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# cron登録
0 4 * * * /usr/local/bin/docker-cleanup.sh

トラブルシューティング：特殊ケース

「docker pull」で no space

イメージダウンロード中に発生:

# 古いイメージを先に削除
docker image prune -a
docker pull イメージ名

「docker build」で途中失敗

# ビルドキャッシュを全削除して再試行
docker builder prune -a -f
docker build -t myimage .

巨大な multi-stage build で頻発します。COPYの対象を絞る・.dockerignoreを活用するのも有効。

「docker exec」中に発生

実行中コンテナの書き込みレイヤーが満杯。コンテナ再起動でリセット:

docker stop CONTAINER
docker rm CONTAINER
docker run ...

データ永続化が必要な場合は volume mount で外部に保存しておく設計に修正。

overlay2 ディレクトリが巨大

sudo du -sh /var/lib/docker/overlay2
# 例: 50GB

docker system prune -a で減らないなら、orphanedレイヤー（参照されていない孤児）の可能性。Docker停止→/var/lib/docker/overlay2内の孤児ディレクトリ削除（上級者向け・データロスト注意）。

# 安全な方法：いったんDocker全リセット
sudo systemctl stop docker
sudo mv /var/lib/docker /var/lib/docker.bak
sudo mkdir /var/lib/docker
sudo systemctl start docker
# 動作確認後
sudo rm -rf /var/lib/docker.bak

⚠️ 全イメージ・コンテナ・ボリュームが消失します。バックアップとイメージpush先の確認を。

予防策・ベストプラクティス

ディスク問題を起こさない運用のポイント。

1. Dockerfile を Multi-stage build で最適化

最終イメージサイズを大幅に削減できます:

# Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Final stage（軽量）
FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]

2. .dockerignore でビルドコンテキスト削減

.git
node_modules
*.log
*.md
test/
.env

巨大なディレクトリをビルドコンテキストから除外してビルドを高速化。

3. ベースイメージを小さく

ubuntu:22.04    → 約77MB
debian:slim     → 約30MB  
alpine:latest   → 約7MB
distroless      → 約2MB

可能な範囲で軽量イメージを採用。

4. ログ設定をデフォルトで制限

/etc/docker/daemon.json で全体設定:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

5. ボリュームの命名規則

匿名ボリューム（自動生成）は誰のものか分からなくなりがち。名前付きボリュームに統一:

# ❌
services:
  db:
    image: postgres
    volumes:
      - /var/lib/postgresql/data

# ✅
services:
  db:
    image: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

6. 定期監視

# crontab で毎日チェック
0 9 * * * docker system df | mail -s "Docker disk usage" admin@example.com

7. ディスク監視アラート

# 80%超で通知
THRESHOLD=80
USAGE=$(df /var/lib/docker | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
    # Slack通知など
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"Docker disk usage: ${USAGE}%\"}" \
        $SLACK_WEBHOOK
fi

8. CI/CD では毎ジョブ後にクリーンアップ

shared runner では特に重要。1ジョブ終わるたびに docker system prune -af を実行。

トラブルシューティング・チェックリスト

エラーが出た時の対処手順:

1. docker system df でDocker使用量確認
2. df -h でホストディスク確認
3. df -i でinode確認
4. docker container prune -f で停止コンテナ削除
5. docker image prune -a -f で未使用イメージ削除
6. docker builder prune -a -f でビルドキャッシュ削除
7. 必要なら docker volume prune でボリューム削除（注意）
8. ログ巨大化チェック → truncate でリセット
9. それでもダメなら /var/lib/docker 移動 or Docker Desktop圧縮
10. 最終手段：Docker完全リセット

よくある質問（FAQ）

Q1. docker system prune と docker system prune -a の違いは？

-aの方が大量に削除できますが、よく使うイメージも削除される可能性があるため再ダウンロードが必要になります。

Q2. ボリューム削除でデータが消えますか？

Dockerが管理するボリューム（docker volume lsに表示されるもの）は消えます。ホストの特定パスをマウントしているバインドマウントは影響されません。

volumes:
  - postgres_data:/var/lib/postgresql/data  # 管理ボリューム（prune対象）
  - /host/path:/container/path              # バインドマウント（影響なし）

Q3. df -h では空きがあるのに「no space」と言われます

考えられる原因:

• inode 枯渇（df -iで確認）
• 別パーティションが満杯（/varが小さい等）
• ファイルシステム破損
• quota設定で制限がかかっている

Q4. WSL2のディスクが減りません

WSL2の仮想ディスク.vhdxファイルは、内部の使用量が減っても自動縮小されない仕様です。本記事のWSL2セクションの手順で手動圧縮してください。

Q5. Docker Desktopのディスク使用量がDocker内部の合計と一致しません

Docker Desktopは仮想ディスクに最大上限まで割り当てを行う場合があるため、内部の実使用量より大きく見えます。docker system dfの合計に、追加でログ・キャッシュ等が乗ったサイズが実態です。Mac/Windowsでは仮想ディスク圧縮で詰めるしかありません。

Q6. docker build でキャッシュを使わずビルドしたい

docker build --no-cache -t myimage .

ただしキャッシュを使わないとビルド時間が長くなります。容量削減なら--no-cacheではなくdocker builder pruneの方が適切です。

Q7. dangling イメージとは何ですか？

タグが付いていない（または<none>）イメージで、通常は古いビルドの中間レイヤーです:

docker images -f "dangling=true"

実害は少ないですが、ディスク容量を消費するので定期的に削除推奨:

docker image prune  # danglingのみ削除

Q8. Docker Composeで個別サービスだけクリーンアップしたい

# 特定サービスのコンテナを止めて削除
docker-compose rm -fsv service_name

# 特定サービスのイメージを再ビルド
docker-compose build --no-cache service_name

Q9. プロダクション環境で実行しても安全なpruneは？

最も保守的なコマンド:

# 24時間以上前の停止コンテナのみ削除
docker container prune -f --filter "until=24h"

# 24時間以上前のdanglingイメージのみ
docker image prune -f --filter "until=24h"

untilフィルタを必ず付けて、最近のデータは保護しましょう。

Q10. CI/CD で並列ビルドするとよくこのエラーが出ます

並列ビルドはディスクを大量消費します。対策:

• Runner自体をスケールアップ（大きいディスク）
• 並列度を下げる
• ビルド前後に強制クリーンアップ
• Layer caching を活用してビルド時間短縮（Docker BuildKit）

# GitHub Actions例
- uses: docker/setup-buildx-action@v3
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Q11. Linuxのrootfsが満杯になりました

/var/lib/dockerを別パーティションに移動が王道（本記事の/var/lib/docker移動参照）。

Q12. オーバーレイファイルシステムが原因と言われました

overlay2はDocker標準のストレージドライバで、コピーオンライト方式で動作します。複雑な内部構造のため、overlay2ディレクトリだけを部分的に削除すると Docker が起動不能になります。問題があればDocker全体を再初期化するのが安全です。

参考リンク・関連資料

Docker公式ドキュメント

• Docker – Prune unused Docker objects – prune公式
• Docker – System reference – dockerシステムコマンド
• Docker – Engine daemon configuration – daemon.json 設定
• Docker – Configure logging drivers – ログドライバ設定
• Docker – Manage data with volumes – ボリューム管理
• Docker – Storage drivers – ストレージドライバ詳細

BuildKit

• Docker BuildKit Documentation – BuildKitガイド
• docker buildx prune – buildxキャッシュ削除

Docker Desktop

• Docker Desktop – Manage Resources – リソース設定
• Docker Desktop – Troubleshoot – トラブルシューティング

WSL2

• Microsoft Learn – WSL Disk Space – WSL2ディスク管理
• WSL2 vhdx ファイル圧縮 – 仮想ディスク圧縮

CI/CD

• GitHub Actions – free-disk-space action – GitHub Actions用ツール
• Docker Build Cloud – 公式キャッシュサービス

関連記事（本サイト）

• 「Address already in use」エラーの対処法 – ポート競合
• SSH「Host key verification failed」エラーの対処 – SSH エラー
• UbuntuでIPアドレスを確認する全方法 – ネットワーク
• Ubuntuでアンインストールする全方法 – パッケージ管理

まとめ

Docker の「no space left on device」は、原因が複数箇所に分散する複合的なエラーですが、順序立てて切り分け→クリーンアップすれば確実に解決できます。要点を再整理します。

• まず状況確認: docker system df + df -h + df -i
• 使い分け:
  • docker container prune → 停止コンテナ削除（安全）
  • docker image prune -a → 未使用イメージ削除（再DLが必要）
  • docker volume prune → ボリューム削除（データ消失注意）
  • docker builder prune → ビルドキャッシュ削除
• ログ巨大化対策: daemon.jsonでmax-size設定、既存はtruncate
• /var/lib/docker移動: パーティション圧迫の根本対処
• Docker Desktop / WSL2: 仮想ディスクの圧縮が必要
• inode枯渇: ファイル数の問題、df -iで確認
• 予防策: ログ制限、定期prune、CI/CDで毎ジョブ後cleanup

これらの知識は、開発環境の安定運用・CI/CD構築・本番Docker運用などあらゆる場面で必須です。本記事をブックマークしておけば、Dockerのディスク問題に遭遇した時の対応が大幅に効率化されます。

本記事は2026年6月時点の情報をもとに、Docker Engine 25.x / 26.x、Docker Desktop 4.x、Ubuntu 22.04/24.04、Windows 11 + WSL2、macOS Sonoma/Sequoia での動作確認に基づき作成しています。Docker のバージョンによってオプション名が変わる場合があるため、最新の情報はDocker公式ドキュメントもあわせてご確認ください。