はい、承知いたしました。Dockerの容量不足解消に役立つ docker system prune コマンドについて、詳細な解説を含む約5000語の記事を作成します。

---

Dockerの容量不足解消！docker system prune の使い方と効果を徹底解説

Dockerは、アプリケーションをパッケージ化し、隔離された環境で実行するための強力なプラットフォームです。開発、テスト、本番環境問わず広く利用されています。しかし、Dockerを使い続けるにつれて多くのユーザーが直面するのが「容量不足」の問題です。ビルドされたイメージ、停止したコンテナ、使用されなくなったボリュームなどが蓄積され、あっという間にディスク容量を圧迫してしまうことがあります。

この記事では、そんなDockerの容量不足を解消するための最も効果的なコマンドの一つである docker system prune に焦点を当て、その使い方、効果、そして利用する際の注意点について、初心者の方にも分かりやすく、かつ網羅的に解説します。この記事を読めば、あなたのDocker環境を常にクリーンで快適な状態に保つための知識が手に入ります。

1. なぜDockerは容量を消費するのか？ディスクを圧迫する要因

docker system prune コマンドの理解を深める前に、まずDockerがどのようなリソースを生成し、それがどのようにディスク容量を消費するのかを知っておきましょう。Docker環境における主な容量消費元は以下の通りです。

• イメージ (Images): アプリケーションとその依存関係を含む読み取り専用のテンプレートです。新しいコンテナを起動する際に使用されます。イメージは複数のレイヤーで構成されており、同じレイヤーを持つイメージ間でディスク容量を共有します。しかし、様々なバージョンのイメージや、開発中に頻繁にリビルドされるイメージは、ディスク容量を大きく消費します。特に、タグ付けされていない古いイメージ（<none> と表示されるもの）が溜まりやすい傾向があります。
• コンテナ (Containers): イメージから生成され、実際にアプリケーションが実行されるインスタンスです。コンテナが停止しても、そのファイルシステムの状態やログ、設定はディスク上に保持されます。多くのコンテナを起動・停止を繰り返すと、停止したコンテナのデータが蓄積されます。
• ボリューム (Volumes): コンテナの永続的なデータを保存するために使用されます。データベースのデータやユーザーがアップロードしたファイルなど、コンテナのライフサイクルとは独立して保持したいデータを格納します。ボリュームはコンテナが削除されてもデフォルトでは残るため、不要になったボリュームがディスクを圧迫することがあります。
• ネットワーク (Networks): コンテナ間の通信やホストとの通信を可能にする仮想ネットワークです。カスタムネットワークを作成した場合、その設定情報などが保存されます。ただし、ネットワーク自体が消費するディスク容量は通常微々たるものです。
• ビルドキャッシュ (Build Cache): イメージをビルドする際に、DockerはDockerfileの各ステップの結果をキャッシュします。これにより、次回のビルドで同じステップがあればキャッシュを再利用し、ビルド時間を短縮できます。しかし、このキャッシュもディスク容量を消費します。特に開発中に頻繁にイメージをビルドする場合、大量のビルドキャッシュが蓄積されます。

これらのリソースが時間と共に蓄積されることで、Dockerがインストールされているドライブの空き容量は徐々に減少していきます。開発環境であれば、様々なイメージを試したり、コンテナの起動・停止を繰り返したりすることで、すぐに容量不足に陥る可能性があります。CI/CDパイプラインなどでも、多数のビルド済みイメージや実行済みのコンテナが残存し、ストレージの問題を引き起こすことがあります。

2. docker system prune とは何か？

docker system prune は、Dockerが提供するコマンドの一つで、不要になったDockerリソースをまとめて削除し、ディスク容量を解放することを目的としています。個別に docker container rm や docker image rm などを実行するよりも、複数の種類のリソースに対して一度にクリーンアップを実行できるため、非常に便利です。

このコマンドは、以下の「不要な」リソースをターゲットとします。

• 停止状態のコンテナ (Stopped containers): 実行が終了し、現在稼働していないコンテナ。
• 未使用のネットワーク (Unused networks): どのコンテナにも現在接続されていないネットワーク。
• 「ぶら下がっている」イメージ (Dangling images): どのコンテナからも参照されておらず、かつタグ付けもされていないイメージ。これは、新しいイメージをビルドした際に、同じタグを持つ古いイメージが上書きされた場合などに発生します。docker images -f dangling=true で確認できます。
• 「ぶら下がっている」ボリューム (Dangling volumes): どのコンテナからも参照されていない、かつ匿名ボリューム（コンテナ作成時に名前を指定しなかったボリューム）であるボリューム。これは、匿名ボリュームを使用していたコンテナが削除された際に発生します。docker volume ls -f dangling=true で確認できます。

注意点: docker system prune を実行しても、デフォルトでは実行中のコンテナや名前付きボリューム、使用されているイメージは削除されません。これらのリソースは、ユーザーが意図的に保持したい可能性が高いため、安全のためにデフォルトの対象外となっています。

3. docker system prune の基本的な使い方と効果

最も基本的な使い方は、オプションなしでコマンドを実行することです。

bash
docker system prune

このコマンドを実行すると、削除されるリソースの種類とその合計サイズが表示され、実行を続行するかどうかの確認を求められます。

“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all dangling build cache
– all dangling volumes

Are you sure you want to continue? [y/N]
“`

ここで y を入力してEnterを押すと、削除が実行されます。削除が完了すると、解放されたディスク容量の合計が表示されます。

Total reclaimed space: 1.23GB

効果:

• ディスク容量の解放: 不要なリソースを削除することで、最も直接的にディスク容量を解放できます。特に開発環境では、驚くほど多くの容量が解放されることがあります。
• Docker環境の整理: 不要な停止コンテナやイメージリストの clutter を減らし、管理しやすくなります。
• パフォーマンスの向上 (限定的): ディスク空き容量が増えることで、OS全体のパフォーマンスが向上する可能性があります。また、Dockerデーモンが管理するリソースの数が減ることで、一部の操作（例: docker ps, docker images）が若干高速化される可能性もゼロではありませんが、これは副次的な効果です。

基本的な docker system prune は、比較的安全に多くの不要リソースを削除できるため、定期的なメンテナンスとして実行するのに適しています。

4. docker system prune のオプション詳解

docker system prune コマンドにはいくつかの便利なオプションがあり、より強力なクリーンアップを実行したり、特定の条件でフィルタリングしたりすることが可能です。これらのオプションを使う際は、削除される対象がデフォルトより広がる場合があるため、十分な理解と注意が必要です。

4.1. -a または --all: 全ての未使用リソースを削除

このオプションを付けると、デフォルトの対象に加えて、停止状態のコンテナ（デフォルトで対象）と「ぶら下がっている」イメージ（デフォルトで対象）に加え、どのコンテナからも参照されていない「未使用の」イメージも削除対象に含めます。

bash
docker system prune -a

または

bash
docker system prune --all

確認メッセージはデフォルトの場合と少し異なります。

“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all images without at least one container associated to them
– all build cache

Are you sure you want to continue? [y/N]
“`

注意点:

• docker images で表示される、特定のタグを持つイメージであっても、現在どのコンテナもそのイメージを使用していない場合は削除されます。
• このコマンドを実行すると、次にそのイメージが必要になった際にインターネットから再ダウンロードする必要が生じます。時間がかかったり、インターネット接続が必要になったりする可能性があります。
• 開発やテストで一時的にしか使わないイメージが多い場合は有効ですが、頻繁に利用するイメージや、インターネット接続が制限される環境では注意が必要です。
• docker system prune -a に --volumes オプションを組み合わせると、未使用のボリュームも削除されます（後述）。

4.2. --volumes: 未使用のボリュームも削除

デフォルトの docker system prune は「ぶら下がっている」ボリューム（匿名ボリュームかつどのコンテナも参照していないもの）のみを削除します。しかし、--volumes オプションを付けることで、名前付きボリュームを含め、現在どのコンテナからも参照されていないすべてのボリュームを削除対象に含めることができます。

bash
docker system prune --volumes

または -a オプションと組み合わせて、すべての未使用イメージ、コンテナ、ネットワーク、ボリュームを削除することも可能です。

bash
docker system prune -a --volumes

--volumes を指定した場合の確認メッセージには、ボリュームの削除が含まれる旨が明記されます。

“`
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all build cache
– all unused volumes

Are you sure you want to continue? [y/N]
“`

極めて重要な注意点:

• ボリュームには永続的なデータが保存されている可能性が高いです。 データベースのデータ、設定ファイル、アップロードされたファイルなど、失うと困る情報が含まれていることがあります。
• --volumes オプションは、現在どのコンテナも使用していないボリュームを無条件に削除します。これは、以前使っていたが今は使っていない、しかし将来また使うかもしれない名前付きボリュームや、手動で作成したがまだコンテナにアタッチしていないボリュームなども対象になるということです。
• このオプションを使用する前に、docker volume ls コマンドで既存のボリュームを確認し、削除しても問題ないか慎重に判断してください。
• 本番環境や重要なデータを扱う環境では、このオプションの使用は特に慎重に行うべきです。 誤って重要なデータを失うリスクがあります。

4.3. -f または --force: 確認プロンプトをスキップ

このオプションを付けると、通常表示される「実行を続行しますか？」という確認プロンプトが表示されずに、即座に削除処理が実行されます。

bash
docker system prune -f

または

bash
docker system prune --force

注意点:

• 自動化スクリプトなどで docker system prune を実行する場合に便利ですが、誤って重要なリソースを削除してしまうリスクが高まります。
• 特に -a や --volumes オプションと組み合わせて使用する場合は、細心の注意が必要です。意図しないデータ損失や環境破壊につながる可能性があります。
• 手動で実行する場合は、基本的にこのオプションを使用せず、確認プロンプトで削除対象を確認した上で実行することをお勧めします。

4.4. --filter: 条件を指定して削除対象を絞り込む

--filter オプションを使用すると、削除対象とするリソースに特定の条件を適用できます。これにより、より細かい制御が可能になります。フィルターは key=value の形式で指定し、複数のフィルターを指定することも可能です。

docker system prune で使用可能な主なフィルターは以下の通りです。

• until=<timestamp>: 指定したタイムスタンプよりも古いリソースのみを削除します。タイムスタンプはUnixタイムスタンプ、RFC3339形式の日付、またはGo言語のduration形式（例: 1h30m は1時間30分前）で指定できます。
• label=<label name> または label=<label name>=<label value>: 指定したラベルを持つ（または持たない）リソースのみを削除します。ラベル名の前に ! を付けると、そのラベルを持たないリソースが対象になります。

使用例:

• 1時間以上前に停止したコンテナや作成されたイメージのみを削除:
  bash
docker system prune --filter "until=1h"
• 特定のラベル com.example.cleanup=false が付いていないリソースのみを削除:
  bash
docker system prune --filter "!label=com.example.cleanup=false"
  これにより、特定のラベルを付けたコンテナやイメージを削除対象から除外できます。
• 24時間以上前に停止/作成され、かつ env=development というラベルを持つリソースのみを削除:
  bash
docker system prune --filter "until=24h" --filter "label=env=development"

注意点:

• --filter は docker system prune のデフォルトの対象（停止コンテナ、未使用ネットワーク、ぶら下がりイメージ/ボリューム）に対して適用されます。-a や --volumes オプションと組み合わせることで、フィルターの対象となるリソースの種類を広げることができます。
• フィルターのキーや値の指定方法に間違いがないか注意が必要です。
• ラベルによるフィルタリングを活用するには、コンテナやイメージ作成時に適切なラベルを付けておく必要があります。

--filter オプションは非常に強力で柔軟ですが、その分使い方が複雑になります。意図したリソースだけが削除されるように、事前に削除対象となるリソースを個別の docker container ls, docker image ls, docker volume ls コマンドに同じフィルターを付けて確認することをお勧めします。

5. docker system prune が削除するもの、しないもの（詳細）

各リソースタイプについて、docker system prune がどのように作用するかをさらに詳しく見てみましょう。

5.1. コンテナ (Containers)

• デフォルト (docker system prune): 停止状態のコンテナのみを削除します。実行中のコンテナは絶対に削除されません。
• -a オプション (docker system prune -a): デフォルトと同じく、停止状態のコンテナのみを削除します。-a オプションは主にイメージの削除対象を広げるためのもので、コンテナについては停止状態のものだけが対象です。

5.2. イメージ (Images)

• デフォルト (docker system prune): 「ぶら下がっている」イメージ (<none>:<none> と表示される、どのコンテナからも参照されておらずタグもついていないイメージ) のみを削除します。
• -a オプション (docker system prune -a): 「ぶら下がっている」イメージに加えて、現在どのコンテナからも参照されていない「未使用の」イメージも削除します。これはタグが付いていても、起動中のコンテナがそのイメージを使っていないものは対象になります。
  • 削除されないイメージ:
    • 実行中のコンテナが使用しているイメージ。
    • 停止中のコンテナが使用しているイメージ（デフォルトの prune では削除されないイメージに含まれます）。
    • docker images で表示される、タグ付きで、かつまだ削除対象になっていないイメージ（prune -a の対象外であるか、prune -a で削除される直前の状態）。

5.3. ボリューム (Volumes)

• デフォルト (docker system prune): 「ぶら下がっている」ボリューム（どのコンテナからも参照されておらず、かつ匿名ボリュームであるもの）のみを削除します。
• --volumes オプション (docker system prune --volumes): 「ぶら下がっている」ボリュームに加えて、現在どのコンテナからも参照されていないすべてのボリューム（名前付きボリュームを含む）を削除します。
  • 削除されないボリューム:
    • 実行中または停止中のコンテナによって現在使用されているボリューム。
    • 名前付きボリュームで、かつ --volumes オプションが指定されなかった場合。

5.4. ネットワーク (Networks)

• デフォルト (docker system prune): どのコンテナにも現在接続されていないネットワークのみを削除します。
• -a / --volumes オプション: ネットワークの削除対象には影響しません。常に未使用のネットワークのみが対象です。

5.5. ビルドキャッシュ (Build Cache)

• デフォルト (docker system prune): 「ぶら下がっている」ビルドキャッシュを削除します。これは、どのイメージからも参照されなくなったビルドステップのキャッシュです。
• -a オプション (docker system prune -a): デフォルトと同じく、「ぶら下がっている」ビルドキャッシュを削除します。
• 補足: ビルドキャッシュをより詳細に管理・削除したい場合は、docker builder prune コマンドを使用するのが適切です。docker builder prune は、--keep-storage などのオプションで保持するキャッシュのサイズを制限したり、特定の期間より古いキャッシュのみを削除したりといった高度な制御が可能です。docker system prune は docker builder prune が提供する機能の一部を包括的に実行するものです。

6. docker system prune を使用する上でのリスクと考慮事項

docker system prune は強力なツールですが、誤って使用すると予期せぬ結果を招く可能性があります。特に以下の点に注意が必要です。

6.1. データ損失のリスク（特にボリューム）

最も大きなリスクは、重要なデータを保持しているボリュームを誤って削除してしまうことです。特に --volumes オプションを使用する場合は、このリスクが非常に高まります。データベースのデータ、設定ファイル、ユーザーデータなどが失われる可能性があります。

• 対策:
  • docker volume ls で既存のボリュームを確認し、内容や用途を把握しておく。
  • --volumes オプションを使用する前に、必ずボリュームのバックアップを取る。
  • 本当に削除して良いボリュームか慎重に判断する。名前付きボリュームはデフォルトで削除対象にならないことを理解しておく。

6.2. イメージの再ダウンロード

-a オプションを使用して未使用のイメージを削除すると、次回そのイメージを使ってコンテナを起動する際に、レジストリからイメージを再ダウンロードする必要があります。

• 対策:
  • インターネット接続が必要になることを理解しておく。
  • ダウンロードに時間がかかる可能性があることを考慮に入れる。特にサイズの大きなイメージや、多数のイメージを削除した場合。
  • 頻繁に利用するイメージは削除対象から除外することを検討する（例: ラベルフィルタリングを使用する、または個別の docker image prune で特定のイメージは残す）。

6.3. 確認プロンプトのスキップ (-f オプション)

-f オプションを使うと、確認なしに削除が実行されます。これは自動化には便利ですが、意図しないタイミングで実行されたり、スクリプトのミスで本来残すべきリソースまで削除してしまったりするリスクがあります。

• 対策:
  • 手動実行では -f を避ける。
  • 自動化スクリプトに組み込む場合は、実行されるタイミングや条件を厳密に管理し、対象となるリソースが安全に削除できるものだけであることを確認するロジックを含める。
  • 重要な環境での自動化は特に慎重に行う。

6.4. ビルドキャッシュの削除によるビルド時間の増加

ビルドキャッシュが削除されると、次回のイメージビルド時にキャッシュが利用できなくなり、ビルド時間が長くなる可能性があります。

• 対策:
  • 開発中に頻繁にビルドする場合は、ビルドキャッシュを完全に削除しない方が効率的です。
  • ビルドキャッシュのクリーンアップは、docker builder prune でより詳細に制御できます。docker system prune よりも docker builder prune を検討するのも良いでしょう。
  • ディスク容量が逼迫している場合にのみ、ビルドキャッシュの削除を検討する。

6.5. Docker Compose との連携

Docker Compose は、サービスとしてコンテナ、ネットワーク、ボリュームなどを管理します。docker system prune は、Composeプロジェクト固有のリソースだけでなく、Docker全体のリソースに対して作用します。

• 考慮事項:
  • docker compose down -v コマンドは、そのComposeプロジェクトで定義されたコンテナ、ネットワーク、およびボリュームを削除します。これは特定のプロジェクトのリソースをクリーンアップする際に便利です。
  • docker system prune --volumes は、Composeプロジェクトで定義されたボリュームであっても、現在どのコンテナも参照していなければ削除してしまいます。Composeプロジェクトを停止（docker compose stop）した状態で docker system prune --volumes を実行すると、そのプロジェクトで使用していたボリュームが削除される可能性があるため注意が必要です。
  • Composeプロジェクトに関連するリソースのみを安全に削除したい場合は、docker compose down -v の方が適しています。

7. docker system prune の推奨される使用シナリオと頻度

docker system prune は、主に以下のようなシナリオで有効です。

• 開発環境のメンテナンス: 開発中は様々なイメージを試したり、コンテナの起動・停止を繰り返したりするため、不要なリソースが最も溜まりやすい環境です。週に一度、あるいはディスク容量が気になり始めたタイミングで実行するのが効果的です。通常はデフォルトの docker system prune で十分ですが、必要に応じて -a も検討できます。
• テスト環境やCI/CDパイプライン: テスト実行やビルドのたびに新しいコンテナやイメージが生成されるため、クリーンアップが重要です。CI/CDスクリプトの最後などで定期的に docker system prune -f （自動化のため）を組み込むことが考えられます。ただし、-f の使用はリスクを理解した上で行う必要があります。また、パイプラインによっては特定のイメージやキャッシュを残しておきたい場合もあるため、フィルターオプションの検討も重要です。
• ディスク容量が逼迫している場合: ディスク容量が警告レベルに達した場合、手っ取り早く容量を確保するための手段として非常に有効です。まずは docker system df で容量の内訳を確認し、最も消費しているリソースの種類に応じて prune のオプション（特に -a や --volumes）を検討します。

推奨される頻度:

環境によって大きく異なりますが、一般的な開発ワークステーションであれば、週に一度程度実行するのが良い目安です。CI/CDエージェントや頻繁にコンテナのデプロイ・削除が行われるサーバーであれば、日次やビルド/デプロイ後に自動実行を検討しても良いでしょう。ただし、本番環境のデータベースなど、永続データが重要な場合は --volumes オプションの使用は極めて慎重に行うか、避けるべきです。

8. docker system prune 以外のクリーンアップコマンド

docker system prune は複数のリソースをまとめて削除する便利なコマンドですが、特定のリソースタイプだけをクリーンアップしたい場合や、より細かい制御を行いたい場合は、それぞれのタイプに特化した prune コマンドを使用することもできます。

• docker container prune: 停止状態のコンテナのみを削除します。docker system prune のコンテナ削除部分と同等です。
• docker image prune: 「ぶら下がっている」イメージのみを削除します。-a オプションを付けると、未使用のイメージも削除します。docker system prune や docker system prune -a のイメージ削除部分と同等です。
• docker volume prune: 「ぶら下がっている」ボリュームのみを削除します。--filter オプションで特定のボリュームを対象にしたり、-f で確認をスキップしたりできます。docker system prune のボリューム削除部分（デフォルト）と同等です。ただし、このコマンドには --volumes オプションはありません。未使用の名前付きボリュームを含めて削除したい場合は、docker system prune --volumes を使うか、docker volume rm で個別に削除する必要があります。
• docker network prune: どのコンテナにも接続されていないネットワークのみを削除します。docker system prune のネットワーク削除部分と同等です。
• docker builder prune: ビルドキャッシュを削除します。docker system prune のビルドキャッシュ削除よりも詳細なオプション（例: --keep-storage, --filter until) を持っています。ビルドキャッシュの管理に特化したい場合に利用します。

これらのコマンドを使い分けることで、よりターゲットを絞ったクリーンアップが可能です。例えば、「停止コンテナだけを毎日削除したいが、イメージは手動で管理したい」といった場合は、docker container prune -f を cron などで定期実行するのが適切です。

9. Dockerの容量使用状況を確認する方法 (docker system df)

docker system prune を実行する前に、何が容量を消費しているのかを確認することは非常に重要です。docker system df コマンドを使用すると、Dockerリソースごとのディスク使用状況のサマリーを確認できます。

bash
docker system df

出力例：

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 25 12 5.1GB 3.2GB (62%)
Containers 20 5 200MB 200MB (100%)
Local Volumes 15 3 1.5GB 1.0GB (66%)
BuildCache 150 0 3.5GB 3.5GB (100%)

出力の各列の意味は以下の通りです。

• TYPE: リソースの種類 (Images, Containers, Local Volumes, BuildCache)。
• TOTAL: その種類のリソースの総数。
• ACTIVE: 現在使用中（実行中または参照されている）のリソース数。
• SIZE: その種類のリソースが消費しているディスク容量の合計。
• RECLAIMABLE: docker system prune またはそれぞれの prune コマンドによって解放可能な容量と、それが総容量に占める割合。

この RECLAIMABLE の列を見ることで、docker system prune （またはそのオプション付き）を実行することでどれくらいの容量が解放される可能性があるかを把握できます。特に、Images や BuildCache の RECLAIMABLE の割合が高い場合、docker system prune -a や docker builder prune が効果的である可能性が高いです。Local Volumes の RECLAIMABLE が高い場合は、docker system prune --volumes が有効かもしれませんが、データ損失のリスクを考慮する必要があります。

docker system df は、Dockerの容量管理における最初のステップとして、また docker system prune 実行後の効果確認としても非常に役立ちます。

10. 実践！docker system prune を使った容量解放手順

ここまでの内容を踏まえ、実際に docker system prune を使って容量を解放する際の推奨手順をまとめます。

ステップ1: 現在の容量使用状況を確認する

まず、何がディスク容量を消費しているのかを把握するために docker system df コマンドを実行します。

bash
docker system df

出力を見て、Images, Containers, Local Volumes, BuildCache のそれぞれのサイズと RECLAIMABLE (解放可能容量) を確認します。

ステップ2: 解放したいリソースの種類とリスクを考慮して prune オプションを選択する

docker system df の結果と、削除しても問題ないリソースの種類を考慮して、実行する docker system prune コマンドを決定します。

• 最も安全な解放: 停止コンテナ、未使用ネットワーク、ぶら下がりイメージ/ボリュームのみを削除したい場合
  bash
docker system prune
  これが最も一般的で推奨されるコマンドです。まずはこれから試しましょう。
• 未使用イメージも含めて解放: 開発環境などで、現在使っていないイメージはすべて削除しても良い場合
  bash
docker system prune -a
  インターネットからイメージを再ダウンロードする可能性と時間を考慮してください。
• 未使用ボリュームも含めて解放: 削除しても問題ない未使用ボリュームがある場合 (注意！データ損失リスクあり)。
  bash
docker system prune --volumes
  または未使用イメージもまとめて削除したい場合は
  bash
docker system prune -a --volumes
  このコマンドは非常に注意深く実行してください。 docker volume ls で削除対象になりうるボリュームを確認することを強く推奨します。
• 特定の条件で解放: 特定の期間より古いものや、特定のラベルを持つ（持たない）ものだけを削除したい場合。
  bash
docker system prune --filter "until=24h"
bash
docker system prune -a --filter "!label=com.example.keep"
  フィルター条件を間違えないように注意してください。事前に docker ... ls --filter ... で対象を確認しましょう。

ステップ3: 選択したコマンドを実行し、確認に応答する

ステップ2で選択したコマンドを実行します。

“`bash

例: 最も一般的なケース

docker system prune
“`

確認メッセージが表示されたら、削除されるリソースの種類と解放される容量を確認し、問題なければ y を入力してEnterを押します。-f オプションを付けている場合は確認なしに即実行されます。

ステップ4: 容量が解放されたことを確認する

削除完了後、再度 docker system df コマンドを実行して、容量が解放されたことを確認します。

bash
docker system df

RECLAIMABLE の容量が減少していること、そして Images や Containers などの SIZE が小さくなっていることを確認できます。

ステップ5: (必要に応じて) 個別リソースの確認やビルドキャッシュのクリーンアップ

まだ容量が不足している場合や、特定の場所（例えばビルドキャッシュ）が容量を圧迫している場合は、docker image ls, docker container ls -a, docker volume ls, docker builder prune といった個別コマンドでの確認やクリーンアップを検討します。

この手順を定期的に実行することで、Dockerがディスク容量を過剰に消費するのを防ぎ、快適な開発・実行環境を維持することができます。

11. より高度な容量管理のヒント

docker system prune は非常に便利ですが、容量問題の根本原因に対処したり、より効率的にスペースを利用したりするための方法もいくつかあります。

• Dockerfileの最適化:
  • マルチステージビルド (Multi-stage builds): ビルドに必要なツールや中間ファイルを含むステージと、実行に必要な最小限のファイルのみを含む最終ステージを分けることで、最終的なイメージサイズを大幅に削減できます。これにより、ダウンロードやストレージに必要な容量が減ります。
  • .dockerignore ファイルの使用: ビルドコンテキストに不要なファイル（ログファイル、キャッシュディレクトリ、バージョン管理ファイルなど）を含めないように .dockerignore ファイルを適切に設定することで、ビルドキャッシュのサイズを抑えることができます。
  • レイヤーのキャッシュ利用: Dockerfileの命令の順序を工夫し、変更頻度の低い命令（依存関係のインストールなど）を先に記述することで、ビルドキャッシュの再利用率を高め、ビルド時間を短縮しつつ、関連するキャッシュを意図的に残しやすくすることができます。
• ボリュームの管理ポリシー:
  • 永続化が必要なデータは必ず名前付きボリュームを使用し、そのライフサイクルをアプリケーションとは別に管理します。
  • 一時的なデータやキャッシュには匿名ボリューム（docker run -v /path/in/container ... の形式）を使用することを検討します。これらの匿名ボリュームは、コンテナが削除された際に「ぶら下がり」状態になり、docker system prune のデフォルト対象となるため、自動的にクリーンアップされやすくなります。
• Docker root directory の移動: ディスク容量が限られたドライブにDockerがインストールされている場合、docker info | grep "Docker Root Dir" で確認できるDockerのデータ保存場所 (/var/lib/docker on Linux by default) を、容量に余裕のある別のドライブやパーティションに移動することを検討します。これはDockerデーモンの設定変更が必要で、実行中のコンテナがない状態で行う必要があります。手順はOSやDockerのインストール方法によって異なりますが、一般的には /etc/docker/daemon.json ファイルを編集します。

これらの方法は、docker system prune による一時的な容量解放だけでなく、長期的なDocker環境の容量効率を改善するのに役立ちます。

12. トラブルシューティング: docker system prune が効かない？

docker system prune を実行しても、期待したほど容量が解放されない場合があります。そのような場合に考えられる原因と対処法です。

• 原因1: 解放対象外のリソースが容量を消費している:
  • 実行中のコンテナ: docker ps で確認し、不要なコンテナは停止・削除します。
  • 使用中のイメージ: 停止中のコンテナが参照しているイメージや、将来使うために残しておきたいタグ付きイメージが容量を消費しているかもしれません。docker system df の Images の RECLAIMABLE が低い場合、これが原因の可能性があります。不要なイメージは docker image rm で個別に削除するか、docker system prune -a を慎重に検討します。
  • 使用中の名前付きボリューム: 重要なデータを含むボリュームが容量を消費しているかもしれません。docker volume ls で確認し、本当に不要であれば --volumes オプション付きの prune を実行するか、docker volume rm で個別に削除します（データ損失注意！）。
  • バインドマウント: ホスト側のディレクトリをコンテナ内にマウントしている場合（docker run -v /host/path:/container/path）、容量はホスト側のファイルシステムで消費されています。Dockerコマンドではこの容量は解放できません。ホスト側のファイルシステムをクリーンアップする必要があります。
• 原因2: ビルドキャッシュのほとんどが参照されている、またはサイズが大きい:
  • docker system df の BuildCache の RECLAIMABLE が低い場合、ビルドキャッシュの大部分がまだ何らかのイメージから参照されている可能性があります。
  • docker builder prune を使用して、より詳細なオプション（例: until, keep-storage）でキャッシュをクリーンアップすることを検討します。
• 原因3: Docker root directory 以外の場所で容量が消費されている:
  • Dockerデーモン自体のログファイルや、外部のストレージドライバ（aufs, overlay2など）が管理する一時ファイルなどが容量を消費している可能性もゼロではありません。これはOSレベルでの調査が必要になる場合があります。
  • 特に /var/lib/docker が存在するパーティション以外の場所で容量が減っている場合、原因はDockerのコンテナやイメージではない可能性が高いです。
• 原因4: ファイルシステムの断片化など、OSレベルの問題:
  • 非常に稀ですが、ファイルシステムの断片化など、OS側のストレージ管理に起因する問題である可能性も考えられます。これはOSのディスク管理ツールで対応します。

多くの場合、docker system df で何が容量を占めているかを確認し、それに応じた prune オプション（特に -a や --volumes）を検討することで解決します。ただし、これらのオプションはリスクを伴うため、確認と注意が必要です。

13. まとめ：docker system prune を賢く活用しよう

docker system prune コマンドは、Docker環境で溜まりがちな不要リソース（停止コンテナ、未使用ネットワーク、ぶら下がりイメージ/ボリューム）をまとめて削除し、ディスク容量を効率的に解放するための非常に便利なツールです。

• 基本的な使い方 (docker system prune) は比較的安全で、定期的なメンテナンスに適しています。
• -a オプション は未使用のイメージも削除し、より多くの容量を解放できる可能性がありますが、イメージの再ダウンロードが必要になるリスクがあります。
• --volumes オプション は未使用の名前付きボリュームも含めて削除するため、データ損失のリスクが非常に高いです。使用する際は、削除対象のボリュームを十分に確認し、必要であればバックアップを取るなど、細心の注意が必要です。
• -f オプション は確認プロンプトをスキップし、自動化に便利ですが、誤操作のリスクを高めます。
• --filter オプション は、特定の条件（作成日時、ラベルなど）で削除対象を絞り込む高度な使い方です。
• 容量の現状把握には docker system df が役立ちます。
• より細かい制御が必要な場合や、特定のリソースタイプに特化したい場合は、docker container prune, docker image prune, docker volume prune, docker network prune, docker builder prune といった個別の prune コマンドも検討できます。

Dockerを快適に使い続けるためには、ディスク容量の管理は避けて通れない課題です。docker system prune とそのオプション、そして関連コマンドを理解し、ご自身の利用状況や環境に合わせて適切な方法で定期的にクリーンアップを実行しましょう。特に開発環境やテスト環境では、こまめな prune が環境の安定性維持や問題発生の予防に繋がります。重要なデータを含むボリュームの扱いにだけは十分注意して、賢く docker system prune を活用してください。

---