はい、承知いたしました。使わないDockerネットワークを安全に削除するための詳細な手順と解説を含む記事を記述します。約5000語を目指し、安全性を最優先に考慮した内容とします。

使わないDockerネットワークを削除する安全な方法：詳細な解説と実践ガイド

はじめに：Dockerネットワークの重要性とクリーンアップの必要性

Dockerはコンテナ化されたアプリケーションの開発、デプロイ、実行を劇的に簡素化する強力なプラットフォームです。Dockerを効果的に利用する上で、コンテナ間の通信や外部との接続を司る「Dockerネットワーク」は不可欠な要素です。Dockerネットワークは、コンテナがどのように互いに、そして外部世界と通信するかを定義し、コンテナの分離性と接続性を同時に実現します。

Dockerを使用するにつれて、様々な目的でネットワークが作成されることがあります。新しいプロジェクト、テスト環境、異なるアプリケーションスタックなど、それぞれのシナリオでカスタムネットワークが構築されます。しかし、プロジェクトが終了したり、コンテナが削除されたり、環境が再構築されたりすると、これらのネットワークの一部は不要になることがあります。不要になったDockerネットワークは、システムのリソース（IPアドレス、ディスクスペース、メモリなど）を占有し続け、ネットワークリストを cluttered（煩雑）にし、管理を困難にする可能性があります。

さらに、IPアドレスの枯渇は特に注意すべき問題です。カスタムネットワークを作成すると、DockerはデフォルトでプライベートIPアドレスのサブネットをそのネットワークに割り当てます。多数の不要なネットワークが残っていると、利用可能なIPアドレス範囲が消費され尽くし、新しいネットワークやコンテナを作成できなくなる可能性があります。

これらの理由から、不要になったDockerネットワークを定期的にクリーンアップすることは、Docker環境を健全に保ち、リソースを最適化し、管理を容易にするために非常に重要です。しかし、ネットワークの削除は慎重に行う必要があります。誤って現在使用されている、あるいは将来必要になるネットワークを削除してしまうと、実行中のコンテナ間の通信が切断されたり、コンテナの起動に失敗したりするなどの深刻な問題を引き起こす可能性があります。

本記事では、Dockerネットワークを安全に削除するための詳細な方法について、その重要性、リスク、正確な手順、そして推奨されるツールやコマンドを網羅的に解説します。特に「安全」であることに焦点を当て、誤って必要なネットワークを削除するリスクを最小限に抑えるための具体的な確認方法やベストプラクティスを詳しく説明します。Docker環境のメンテナンスと最適化を目指すすべてのユーザーにとって、必読の内容となるでしょう。

第1章：Dockerネットワークの基礎

安全な削除方法を理解するためには、まずDockerネットワークの基本的な概念を把握することが重要です。

1.1 Dockerネットワークの役割

Dockerネットワークは、以下の主要な役割を果たします。

コンテナ間の通信: 同じネットワーク上のコンテナは、互いの名前やIPアドレスを使って通信できます。異なるネットワーク上のコンテナは、通常、直接通信できません。
コンテナと外部との通信: ネットワーク設定を通じて、コンテナはホストマシンやインターネットと通信できます。
ネットワークの分離: ネットワークごとにコンテナを分離することで、セキュリティと管理性を向上させます。

1.2 主要なネットワークドライバー

Dockerはいくつかの組み込みネットワークドライバーを提供しており、それぞれ異なる用途に適しています。

bridge (ブリッジ): デフォルトのネットワークドライバーです。新しいコンテナをネットワークを指定せずに起動すると、自動的にこのネットワークに接続されます。同じホスト上のコンテナが互いに通信したり、ホストマシンを通じて外部と通信したりするのに適しています。最も一般的に使用されるタイプです。Dockerは内部的に仮想ブリッジを作成し、コンテナの仮想ネットワークインターフェースをそれに接続します。各ブリッジネットワークは独自のIPアドレスサブネットを持ちます。
host (ホスト): このドライバーを使用するコンテナは、Dockerホストのネットワークスタックを直接共有します。コンテナはホストのIPアドレスを使用し、ポートマッピングは不要になります。ネットワークの分離性は失われますが、ネットワークパフォーマンスはわずかに向上する可能性があります。ほとんどのユースケースでは推奨されません。
none (なし): このドライバーを使用するコンテナは、ネットワークインターフェースを持ちません。外部との通信はもちろん、他のコンテナとの通信もできません。隔離された環境でコンテナを実行する場合にのみ使用されます。
overlay (オーバーレイ): 複数のDockerホストにまたがるネットワークを作成するために使用されます。Docker Swarmなどのオーケストレーションツールで使用され、クラスタ内のコンテナがホストを越えて通信できるようにします。
macvlan (Macvlan): コンテナに物理ネットワーク上のMACアドレスを割り当て、ホストを介さずに直接物理ネットワークに接続できるようにします。レガシーアプリケーションや特定のネットワーク構成が必要な場合に使用されます。
カスタムネットワーク: ユーザーは docker network create コマンドを使用して、上記のドライバーに基づいたカスタムネットワークを作成できます。カスタムブリッジネットワークは非常に一般的で、関連するサービス群（例: Webサーバーとデータベース）を同じネットワークに配置して分離性を高めるのに役立ちます。

本記事でクリーンアップの対象となるのは、主にユーザーが作成したカスタムネットワークや、特定の用途のために一時的に作成されたネットワークです。bridge、host、none といったシステムによって管理されるデフォルトネットワークは、通常削除すべきではありません。 これらのネットワークはDockerの基本的な機能に不可欠であり、削除すると予期しない問題が発生します。

第2章：不要なDockerネットワークをクリーンアップする理由

前述の通り、不要なDockerネットワークの放置はいくつかのデメリットをもたらします。具体的にどのような理由でクリーンアップが必要なのか、詳しく見ていきましょう。

2.1 リソースの消費

IPアドレスの枯渇: 各カスタムブリッジネットワークは、通常 /24 などのサブネット（256個のIPアドレスを含む）を消費します。これはプライベートアドレス空間から割り当てられますが、システム全体で利用可能なアドレス範囲は有限です。多数の不要なネットワークが残っていると、新しいネットワークの作成が不可能になったり、コンテナにIPアドレスが割り当てられなくなったりする可能性があります。
ディスクスペース: 各ネットワークの定義や関連する設定情報は、Dockerのデータディレクトリに保存されます。一つあたりのサイズは小さいですが、大量に蓄積されると無視できない量になることがあります。
メモリ: ネットワーク設定や状態は、Dockerデーモンのメモリ上に保持されます。ネットワーク数が増えると、デーモンが必要とするメモリ量も増加します。
カーネルリソース: ブリッジネットワークは、ホストOSのカーネル内に仮想ネットワークインターフェースやiptablesルールなどのリソースを作成します。これらもシステムリソースを消費します。

2.2 管理の複雑化

docker network ls コマンドで表示されるネットワークのリストが長くなると、必要なネットワークを見つけるのが難しくなります。どのネットワークが何のために使われているのか、一見して判断できなくなるため、環境の管理やデバッグが煩雑になります。

2.3 セキュリティとパフォーマンスの低下

不要なネットワーク構成要素が残っていると、潜在的な攻撃対象が増えたり、ネットワークトラフィックの処理にオーバーヘッドが発生したりする可能性があります。クリーンな環境は、セキュリティの維持とパフォーマンスの最適化にも寄与します。

2.4 混乱の防止

特に複数のプロジェクトや環境が混在するサーバーでは、どのネットワークがどのアプリケーションに関連しているのかが不明瞭になりがちです。不要なものを削除することで、現在の環境に必要なネットワークだけがリストアップされ、混乱を防ぎます。

第3章：「未使用」の定義と安全性の重要性

Dockerネットワークを安全に削除するための最も重要な第一歩は、「未使用」が何を意味するのかを正確に理解することです。単に「現在実行中のコンテナが接続されていない」というだけでは、「未使用」とは限りません。

3.1 「未使用」の真の意味

Dockerの文脈において、安全に削除できる「未使用」のネットワークとは、以下の条件をすべて満たすネットワークです。

現在、実行中のコンテナが一つも接続されていない。
現在、停止中のコンテナが一つも接続されていない。
将来的に使用する予定がない。 (例えば、今後起動する予定のコンテナや、Docker Composeファイルなどで定義されているがまだ起動されていないサービスなど)。
システムによって管理されるデフォルトネットワーク (bridge, host, none) ではない。
他のシステム機能や外部サービスによって参照されていない。 (例えば、特定のオーケストレーションツールや監視システムの設定でネットワーク名がハードコードされている場合など)。

特に重要なのは、停止中のコンテナです。docker network prune コマンドは、デフォルトでは実行中のコンテナに接続されているネットワークのみを未使用と判断しません。つまり、停止中のコンテナに接続されているネットワークは、prune コマンドのデフォルト動作では「使用中」と見なされ、削除対象になりません。これは安全のための設計ですが、停止中のコンテナが多数残っている場合、そのネットワークも多数残り続けることになります。

完全に不要になったネットワークを削除するためには、停止中のコンテナの状態も考慮に入れる必要があります。しかし、停止中のコンテナが将来再起動される可能性がある場合は、そのコンテナが使用するネットワークは削除すべきではありません。この判断には、システム管理者による意図の把握が必要です。

3.2 削除のリスクと安全性の確保

誤って必要なネットワークを削除してしまった場合、以下のような問題が発生します。

実行中のコンテナの通信断: 削除されたネットワークに接続していたコンテナは、他のコンテナや外部リソースとの通信ができなくなります。これはアプリケーションのサービス停止に直結します。
コンテナの起動失敗: 停止中のコンテナを起動しようとした際に、必要なネットワークが存在しないため起動に失敗します。
Docker Composeなどのオーケストレーションツールのエラー: 定義ファイルで参照されているネットワークが存在しないため、サービス全体の起動や管理に失敗します。
データ損失や不整合: 通信障害により、データベース接続が切断されたり、分散システムでデータ不整合が発生したりする可能性があります。

これらのリスクを避けるためには、ネットワークを削除する前に、そのネットワークが本当に不要であることを徹底的に確認することが不可欠です。確認プロセスは削除作業そのものよりも重要と言えます。

安全な削除方法とは、以下の原則に基づいています。

現状把握: 現在存在するすべてのネットワークとその用途を把握する。
使用状況の確認: 各ネットワークに現在接続されている（実行中および停止中の）コンテナを確認する。
将来の使用予定の確認: 停止中のコンテナやDocker Composeファイルなどで、そのネットワークが将来必要になる可能性がないか判断する。
システムネットワークの除外: bridge, host, none などのシステムネットワークを削除対象から明確に除外する。
安全なツールの使用: 使用状況を確認し、不要なネットワークのみを安全に特定して削除するツール（主に docker network prune）を優先的に使用する。
手動削除は慎重に: docker network rm は、ネットワークが使用中でないことを十分に確認した場合のみ使用し、-f (force) オプションは極めて危険なので避ける。
確認プロンプトの利用: ツールが表示する削除対象リストを必ず確認し、意図しないネットワークが含まれていないかチェックする。

これらの原則に従うことで、安全なDockerネットワークのクリーンアップを実行できます。

第4章：未使用ネットワークの特定方法

安全な削除のための第一歩は、どのネットワークが本当に未使用であるかを正確に特定することです。ここでは、そのための具体的なコマンドと手順を解説します。

4.1 docker network ls でネットワークの一覧を表示する

まず、システム上に存在するすべてのDockerネットワークを一覧表示します。

bash docker network ls

このコマンドの出力は以下のようになります。

NETWORK ID NAME DRIVER SCOPE 0f6b37e11402 bridge bridge local f5b18873f2e9 host host local a3b5c6d7e8f0 my_custom_network bridge local e1f2g3h4i5j6 another_project_net overlay swarm none none null local ... (その他のネットワーク)

出力から以下の情報を読み取ります。

NETWORK ID: ネットワークの一意な識別子。
NAME: ネットワークの名前。ユーザーが作成したネットワークには分かりやすい名前が付いていることが多いですが、自動生成された長い名前の場合もあります。
DRIVER: 使用されているネットワークドライバー (bridge, host, overlay など)。
SCOPE: ネットワークのスコープ (local は単一ホスト、swarm はクラスタ全体)。

ここで注目すべきは NAME 列です。bridge, host, none という名前のネットワークは、Dockerによって管理されるデフォルトネットワークであり、絶対に削除してはいけません。 これらの名前を持つネットワークが複数リストアップされている場合でも、これらはシステムネットワークです。特に bridge は多くのコンテナがデフォルトで接続する可能性があるため、削除はシステムの正常な動作を妨げます。

削除対象候補となるのは、これらシステムネットワーク以外の、ユーザーが作成したカスタムネットワークです。出力例では my_custom_network や another_project_net がこれにあたります。（ただし、another_project_net は overlay ドライバーであり、Swarmクラスタで使用されている可能性が高いため、これも慎重な確認が必要です。単一ホスト環境であれば、おそらくカスタム bridge ネットワークが主な対象となるでしょう）。

4.2 docker network inspect でネットワークの詳細と使用状況を確認する

docker network ls で候補を絞り込んだら、次に各ネットワークの詳細と、それに接続されているコンテナを確認します。これには docker network inspect コマンドを使用します。

bash docker network inspect <NETWORK_ID または NETWORK_NAME>

例：

bash docker network inspect my_custom_network

このコマンドは、指定したネットワークに関する詳細なJSON形式の情報を出力します。重要なセクションは Containers フィールドです。このフィールドは、そのネットワークに接続されているすべてのコンテナ（実行中および停止中）の情報を含みます。

json [ { "Name": "my_custom_network", "Id": "a3b5c6d7e8f0...", "Created": "2023-10-27T10:00:00.000Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { ... }, "Internal": false, "Attachable": true, "Ingress": false, "ConfigOnly": false, "Containers": { "b1c2d3e4f5a6...": { "Name": "my_web_server", "EndpointID": "...", "MacAddress": "...", "IPv4Address": "172.18.0.2/16", "IPv6Address": "" }, "c7d8e9f0a1b2...": { "Name": "my_database", "EndpointID": "...", "MacAddress": "...", "IPv4Address": "172.18.0.3/16", "IPv6Address": "" } // もし他のコンテナが接続されていればここに追加される }, "Options": {}, "Labels": {} } ]

上記の例では、my_custom_network には my_web_server と my_database という名前の2つのコンテナが接続されていることがわかります。これらのコンテナが現在実行中であろうと停止中であろうと、このネットワークは使用中と見なされます。

もし Containers フィールドが空のJSONオブジェクト {} であれば、そのネットワークには現在、どのコンテナも接続されていません。

json "Containers": {},

Containers が空であることは、そのネットワークが未使用である可能性が高いことを示しますが、まだ確定ではありません。そのネットワークがDocker Composeファイルで定義されており、将来的にサービスが起動される可能性がある場合は、物理的にはコンテナが接続されていなくても「将来使用される予定」のネットワークと見なすべきです。

4.3 docker ps -a でコンテナの状態を確認する

docker network inspect で接続されているコンテナの名前がわかったら、それらのコンテナが現在どのような状態にあるかを確認します。また、すべてのコンテナの状態を確認することで、停止中のコンテナがどのネットワークに接続しているかも間接的に確認できます。

bash docker ps -a

このコマンドは、実行中、停止中、作成済みなど、すべての状態のコンテナを一覧表示します。

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b1c2d3e4f5a6 nginx:latest "nginx -g 'daemon of…" 2 days ago Up 2 days 80/tcp my_web_server c7d8e9f0a1b2 postgres:latest "docker-entrypoint.s…" 2 days ago Exited (0) 23 hours ago my_database d9e0f1a2b3c4 ubuntu:latest "echo 'Hello Docker!'" 3 weeks ago Exited (0) 3 weeks ago my_old_task ...

上記の出力例を見ると、my_web_server は Up (実行中) です。my_database は Exited (停止中) です。my_old_task も Exited です。

docker network inspect で my_custom_network に接続されていることが分かった my_web_server が Up 状態であることから、my_custom_network は現在アクティブに使用されています。my_database が Exited 状態でも、my_custom_network に接続している限り、そのネットワークはコンテナに「紐づいている」状態です。

もし docker network inspect <network_name> の Containers フィールドが空であり、かつ、そのネットワーク名がどの実行中または停止中のコンテナ (docker ps -a の出力や docker inspect <container_id> の NetworkSettings セクションで確認可能) の設定にも現れない場合、そのネットワークは物理的にはどのコンテナからも参照されていません。

4.4 未使用ネットワークの最終的な判断

上記の確認作業を経て、あるカスタムネットワークが以下の条件をすべて満たす場合に限り、安全に削除できる「未使用」ネットワークであると判断できます。

docker network ls のリストに表示されるカスタムネットワークである (システムネットワークではない)。
docker network inspect <network_name> の Containers フィールドが空である {}。
docker ps -a の出力で、そのネットワーク名に接続しているコンテナ（実行中、停止中を問わず）が存在しないことを確認した（これは Containers フィールドが空であることと重複しますが、確認の徹底が重要です）。
そのネットワークが、Docker Composeファイルやその他の設定ファイルで将来的に使用される予定がないことを確認した（環境の構成を理解している必要がある）。

この厳格な判断プロセスを経ることが、安全なネットワーク削除の鍵となります。少しでも疑念があるネットワークは、安易に削除すべきではありません。

第5章：安全なネットワーク削除の実践方法 – `docker network prune`

未使用ネットワークを安全に削除するための最も推奨される方法は、docker network prune コマンドを使用することです。このコマンドは、Dockerが提供するクリーンアップ機能の一つであり、その設計思想に安全性が組み込まれています。

5.1 docker network prune とは

docker network prune コマンドは、どのコンテナにも現在接続されていないネットワーク を自動的に特定し、削除を提案するツールです。デフォルトでは、実行中のコンテナに接続されているネットワークは削除しません。停止中のコンテナに接続されているネットワークも、デフォルトでは削除対象から除外されます。これは、停止中のコンテナが再起動された際にネットワークが必要になる可能性があるため、誤削除を防ぐための安全機構として機能します。

5.2 docker network prune の基本的な使い方

基本的な使い方は非常にシンプルです。

bash docker network prune

このコマンドを実行すると、Dockerはシステム上のネットワークをスキャンし、現在実行中のどのコンテナにも接続されていないネットワークのリストを作成します。そして、それらのネットワークを削除するかどうかをユーザーに尋ねます。

WARNING! This will remove all networks not used by at least one container. Are you sure you want to continue? [y/N]

ここで y と入力して Enter を押すと、リストアップされたネットワークが削除されます。N と入力して Enter を押すと、操作はキャンセルされます。

この対話形式のプロンプトが、docker network prune の主要な安全機能です。 削除されるネットワークの名前がリストアップされるので（上記の警告メッセージの前に表示されることが多いですが、表示されない場合もあります。後述の --verbose オプションを参照）、削除を実行する前にそのリストを確認できます。意図しないネットワークが含まれていないかを必ず確認してください。

docker network prune のデフォルトの挙動:

実行中のコンテナに接続されていないネットワークを対象とします。
停止中のコンテナに接続されているネットワークは、デフォルトでは削除対象としません。
システムネットワーク (bridge, host, none) は対象としません。

5.3 docker network prune の安全性

docker network prune が安全である理由は、以下の点にあります。

コンテナ接続チェック: 削除候補とするネットワークが、実際にコンテナに接続されていないかをDockerデーモン自身が確認します。このチェックは非常に信頼性が高いです。
対話式プロンプト: 削除を実行する前にユーザーの確認を求めます。これにより、意図しない削除を防ぐ最後の機会が得られます。削除候補リストが表示される場合は、特に注意深く確認すべきです。
停止中コンテナのネットワーク除外 (デフォルト): 停止中コンテナのためのネットワークを残すことで、将来の再起動に備えることができます。これは保守的なアプローチであり、安全側に倒れた設計です。

5.4 docker network prune のオプション

docker network prune にはいくつかの便利なオプションがあります。

-f または --force: 確認プロンプトを表示せずに、自動的に削除を実行します。このオプションは注意して使用してください。 特にスクリプトなどで自動化する場合、削除対象リストを事前に確認できないため、予期しないネットワークが削除されるリスクがあります。手動実行の場合は、通常はこのオプションを使用せず、対話式プロンプトで確認することをお勧めします。

bash docker network prune --force
--filter: 削除対象とするネットワークを、特定の条件で絞り込むことができます。これにより、より詳細な制御が可能になり、安全性が向上します。フィルターの形式は key=value です。
- until=<timestamp>: 指定したタイムスタンプ以前に作成されたネットワークのみを対象とします。
- label=<label>, label!=<label>: 指定したラベルを持つ/持たないネットワークのみを対象とします。ネットワーク作成時にラベルを付けておくと、後で管理しやすくなります。
例：1週間以上前に作成され、かつ cleanup=true というラベルが付いている未使用ネットワークのみを削除する（もちろん、事前にネットワークにラベルを付けておく必要がある）。

bash docker network prune --filter "until=7d" --filter "label=cleanup=true"

例：production というラベルが付いていない未使用ネットワークをすべて削除する。

bash docker network prune --filter "label!=production"
--verbose: 削除されるネットワークの名前を詳細に表示します。確認プロンプトの前に削除対象リストが表示されない環境の場合、このオプションを使うと削除されるネットワークを事前に把握できます。

bash docker network prune --verbose
このオプションを使用すると、確認プロンプトの前に削除されるネットワークの名前がリストアップされるため、安全性を高めるために非常に推奨されます。

“`
WARNING! This will remove all networks not used by at least one container.

Listing of networks to be removed:
my_old_unused_network
another_temporary_net

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

5.5 docker network prune の限界と注意点

停止中コンテナのネットワーク: 前述の通り、デフォルトでは停止中コンテナに接続されているネットワークは削除されません。これにより、システムによっては不要と思われるネットワークが多数残り続ける可能性があります。これらのネットワークを削除したい場合は、まずそのネットワークに接続している停止中のコンテナを削除する必要があります (docker rm <container_id>)。コンテナを削除すれば、そのコンテナが使用していたネットワークは「どのコンテナにも接続されていない」状態になり、次回の docker network prune の実行時に削除対象としてリストアップされる可能性があります。
将来の使用予定: prune コマンドは現在のコンテナ接続状況のみを判断基準とします。Docker Composeファイルなどで定義されているがまだ起動されていないサービスが使用するネットワークは、物理的にはコンテナに接続されていません。prune はこれを「未使用」と判断してしまう可能性があります。このようなネットワークを誤って削除しないためには、prune の確認プロンプトで表示されるリストを慎重に確認するか、または --filter オプションを使って削除対象から除外するなどの対策が必要です。ネットワークに特定のラベル（例: purpose=compose-app-a, state=reserved）を付けておき、そのラベルをフィルター条件に使用するのが効果的です。
Swarmモードのオーバーレイネットワーク: prune はSwarmモードのオーバーレイネットワークも対象としますが、クラスタ全体のコンテナ使用状況に基づいて判断します。Overlayネットワークの削除は、クラスタ全体のサービスに影響を与える可能性があるため、Swarm環境では特に慎重に行う必要があります。

第6章：手動によるネットワーク削除 – `docker network rm` (慎重な使用)

docker network prune が自動的に削除してくれない特定のネットワークを削除したい場合など、手動でネットワークを削除する必要が出てくることがあります。これには docker network rm コマンドを使用します。しかし、このコマンドは prune とは異なり、コンテナが接続されているかどうかのチェックが削除実行時に行われるため、意図しない強制削除につながるリスクがあります。

6.1 docker network rm とは

docker network rm <NETWORK_ID または NETWORK_NAME> [...] コマンドは、指定したネットワークを削除します。複数のネットワークを一度に指定することも可能です。

例：

bash docker network rm my_old_unused_network

またはIDで指定：

bash docker network rm a3b5c6d7e8f0

6.2 docker network rm の安全性機能 (およびその限界)

docker network rm コマンドには、基本的な安全機能が組み込まれています。それは、もしそのネットワークに一つでもコンテナが接続されている場合、削除は失敗する という挙動です。

bash docker network rm my_custom_network

Error response from daemon: network my_custom_network is in use by container b1c2d3e4f5a6

このように、ネットワークが使用中である場合はエラーメッセージが表示され、削除は実行されません。これは誤って使用中のネットワークを削除するのを防ぐための重要な安全機能です。

しかし、この安全機能には限界があります。

-f または --force オプション: docker network rm コマンドには -f オプションがあり、これを使用するとネットワークが使用中であるかどうかにかかわらず、強制的に削除が試みられます。

bash docker network rm -f my_custom_network

このコマンドを実行すると、ネットワークに接続されているコンテナは、突然ネットワークを失います。実行中のコンテナであれば、通信が途絶え、予期しないエラーやサービス停止を引き起こします。これは非常に危険な操作であり、絶対に避けるべきです。 -f オプションは、ネットワークが本当に使用されておらず、かつ何らかの理由で通常の削除ができないような、極めて特殊な状況でのみ、そして最大限の注意を払って使用されるべきです。（実際には、ほとんどのケースでコンテナを先に停止・削除することで通常通り削除できます）。

6.3 docker network rm を安全に使用するための前提条件

docker network rm を安全に使用するためには、そのネットワークにコンテナが一切接続されていないこと を事前に厳密に確認する必要があります。確認方法は第4章で解説した通りです。

docker network ls でネットワーク名を特定。
docker network inspect <network_name> で Containers フィールドが空であることを確認。
念のため docker ps -a でそのネットワーク名に接続しているコンテナが存在しないことを確認。
将来の使用予定がないことを確認。
システムネットワークでないことを確認。

これらの確認がすべて完了し、そのネットワークが本当に不要であると確信できた場合にのみ、-f オプションを付けずに docker network rm <network_name> を実行します。ネットワークが使用中でない限り、このコマンドは成功します。

6.4 docker network prune と docker network rm の使い分け

複数の不要なネットワークをまとめて削除したい場合: docker network prune を使用するのが最も安全かつ効率的です。特に prune の確認プロンプト（または --verbose で表示されるリスト）をしっかり確認することで、安全に一括削除できます。
特定のネットワークをピンポイントで削除したい場合: そのネットワークが未使用であることを十分に確認した後、docker network rm <network_name> を使用します。この場合も、ネットワークが使用中であればエラーになるため、-f を付けない限り一定の安全性は保たれます。

いずれの場合も、削除対象となるネットワークが本当に不要であるという事前の確認が、安全性の根幹をなすことを忘れてはいけません。

第7章：ステップ・バイ・ステップ安全なネットワーククリーンアッププロセス

これまでの解説を踏まえ、安全なDockerネットワーククリーンアップのための具体的なステップをまとめます。

ステップ 1: 現在のネットワーク状況を把握する

まず、システムに存在するすべてのDockerネットワークをリストアップします。

bash docker network ls

出力されるリストを見て、見慣れない名前や、古くなったプロジェクト名に関連しそうな名前のネットワークがないかを確認します。ここで、bridge, host, none といったシステムネットワークは削除対象から除外することを改めて認識します。

ステップ 2: 各カスタムネットワークの使用状況を詳細に確認する

ステップ1でリストアップしたカスタムネットワークの中から、削除候補となりそうなネットワークを一つずつ docker network inspect コマンドで詳しく調べます。

bash docker network inspect <NETWORK_ID または NETWORK_NAME>

特に Containers フィールドを確認します。

"Containers": {} となっている場合：現在どのコンテナも接続していません。このネットワークは未使用である可能性が高いです。
"Containers": { ... } となっており、コンテナ情報がリストアップされている場合：このネットワークは使用中です（実行中または停止中のコンテナが接続しています）。このネットワークは現時点では削除できません。 削除したい場合は、まず接続しているコンテナを停止・削除する必要があります（後述）。

ステップ 3: 全コンテナの状態を確認し、ネットワークとの関連性を把握する

docker ps -a コマンドで、すべてのコンテナ（実行中および停止中）の状態を一覧表示します。

bash docker ps -a

このリストと、ステップ2で確認したネットワークの使用状況を照らし合わせます。

もし docker network inspect で特定のネットワークに接続しているコンテナがリストアップされていたら (Containers フィールドが空でなかったら)、そのコンテナの名前を docker ps -a の出力で探し、その状態（Up, Exited など）を確認します。実行中のコンテナが接続しているネットワークは削除できません。停止中のコンテナが接続しているネットワークは、そのコンテナが本当に不要であれば、コンテナを削除することでネットワークも削除可能になります。
もし docker network inspect で Containers フィールドが空のネットワークがいくつか見つかったら、それらが本当に将来使用される予定がないかを確認します。

ステップ 4: 将来の使用予定がないか判断する

ステップ2と3で、物理的にコンテナが接続されていないネットワークが見つかった場合、それがDocker Composeファイルや別の設定ファイルで参照されていないか、あるいは今後手動で再起動する予定の停止中コンテナが使用するネットワークではないかを判断します。これは、環境の構成や運用方針を理解している管理者のみが行える重要な判断です。

明らかに一時的な目的で作成され、もう必要ないネットワークである。
関連するすべてのコンテナが既に削除された。
Docker Composeファイルで定義されていたが、そのComposeファイルやサービスはもう使用しない。

これらの条件を満たすと判断できたネットワークが、安全に削除できる最終的な候補となります。

ステップ 5: docker network prune でまとめて削除する (推奨)

安全に削除できると判断されたネットワークの多くは、docker network prune のデフォルトの条件（実行中のコンテナに接続されていない）を満たしている可能性があります。特に、一時的にコンテナを起動・停止したが、もう使わないといったシナリオで作成されたネットワークは、prune の対象になりやすいです。

最も安全な方法として、まず docker network prune --verbose を実行します。

bash docker network prune --verbose

Dockerは削除候補となるネットワークのリストを表示し、確認を求めます。

“`
WARNING! This will remove all networks not used by at least one container.

Listing of networks to be removed:

…

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

表示されたリストを非常に慎重に確認します。 ステップ4で削除しても安全だと判断したネットワークのみがリストに含まれているかを確認します。

リストの内容が意図通りであれば、y と入力して Enter を押し、削除を実行します。
もしリストに、削除すべきでないネットワーク（例えば、将来使用する予定のネットワークなど）が含まれている場合は、絶対に y を入力せず、N と入力して操作をキャンセルします。 その後、なぜそのネットワークがリストに含まれたのか（例: 停止中コンテナが接続していると思ったが、実際にはDockerはそれを「未使用」と判断した、または将来の使用予定の判断が誤っていたなど）を再調査します。必要であれば、そのネットワークにラベルを付けて prune --filter で除外するなどの対策を検討します。

ステップ 6: prune で削除されなかったネットワークを検討する (オプション/高度)

docker network prune は、デフォルトでは停止中コンテナに接続されているネットワークを削除しません。もし、停止中のコンテナに接続されているネットワークで、かつそのコンテナもネットワークも完全に不要であると判断した場合、以下の手順で削除できます。

対象の停止中コンテナを特定します (docker ps -a)。
そのコンテナを削除します (docker rm <CONTAINER_ID>)。コンテナを削除すれば、そのコンテナとネットワークの関連付けが解除されます。
コンテナ削除後、改めて docker network inspect <network_name> を実行し、Containers フィールドが空になったことを確認します。
docker network rm <network_name> コマンドでそのネットワークを手動で削除します（-f オプションは付けないでください）。コンテナとの関連付けが解除されていれば、-f なしで成功するはずです。

“`bash

例: my_old_database コンテナが network_for_old_db に接続しており、両方不要な場合

docker ps -a | grep my_old_database # コンテナIDを確認
docker rm # コンテナを削除
docker network inspect network_for_old_db # Containersが空になったか確認
docker network rm network_for_old_db # ネットワークを削除 (使用中でなければ成功)
“`

この手動削除のステップは、コンテナの削除という追加のアクションが必要であり、より慎重な確認を要するため、 prune で削除できるネットワークを優先的にクリーンアップし、このステップは本当に必要な場合のみ行うのが良いでしょう。

ステップ 7: 定期的なクリーンアップの実施

一度クリーンアップを行ったら、以後も定期的にこのプロセスを実施することをお勧めします。手動で行うか、後述する docker system prune を検討するか、あるいは特定の環境で自動化されたスクリプトを検討します（ただし、自動化はリスクが高まるため、十分に検証が必要です）。

第8章：`docker system prune` による包括的クリーンアップ

Dockerは、ネットワークだけでなく、停止中のコンテナ、使用されていないイメージ、ビルドキャッシュなど、様々な不要なリソースをまとめてクリーンアップする docker system prune という包括的なコマンドを提供しています。

8.1 docker system prune とは

docker system prune コマンドは、以下の種類の不要なDockerリソースを削除します。

停止中のコンテナ (stopped containers)
ネットワークに接続されていないネットワーク (networks not attached to a container) – これは docker network prune と同じ基準です
タグ付けされていないイメージ (dangling images) – どのコンテナからも参照されておらず、名前もタグもないイメージ
ビルドキャッシュ (build cache)

このコマンドも、デフォルトでは対話式プロンプトを表示して、削除されるリソースの合計容量などを通知し、実行の確認を求めます。

bash docker system prune

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

Total reclaimed space: 1.23GB

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

ここで y と入力すると、上記のすべての不要リソースが削除されます。

8.2 docker system prune とネットワーククリーンアップ

docker system prune は内部的に docker network prune と同様のロジックで未使用ネットワークを特定します。したがって、docker system prune を実行することは、docker network prune を実行することを含みます。

8.3 docker system prune のオプション

docker system prune にもいくつかの便利なオプションがあります。

-a または --all: 停止中のコンテナだけでなく、使用されていないイメージ（タグ付けされているが、どのコンテナにも使用されていないイメージも含む）も削除対象とします。これは、明示的にキープしたいイメージまで削除してしまう可能性があるため、使用にはさらに注意が必要です。
--volumes: デフォルトでは削除されない、どのコンテナからも参照されていないボリューム (dangling volumes) も削除対象に含めます。ボリュームには重要なデータが保存されている可能性があるため、このオプションの使用は非常に危険です。 どのボリュームが削除されるかを事前に十分に確認する必要があります。
-f または --force: 確認プロンプトをスキップします。自動化などで使用する場合は、最大限の注意と検証が必要です。
--filter: リソースの削除を特定の条件で絞り込みます。例えば、一定期間以上更新されていないリソースのみを対象とするなど。

8.4 docker system prune を使用する際の安全性に関する考慮事項

docker system prune は非常に強力なクリーンアップツールですが、その分リスクも伴います。特に --all や --volumes オプションを使用する場合は、失っては困るリソース（特定のバージョンのイメージ、ボリュームに保存されたデータ）が含まれていないかを厳重に確認する必要があります。

ネットワークの安全な削除という観点からは、docker system prune のデフォルト動作は docker network prune と同等に安全です（実行中のコンテナに接続されていないネットワークのみを対象とし、確認プロンプトがあるため）。しかし、他のリソース（コンテナ、イメージ、キャッシュ）も同時に削除されるため、ネットワークだけでなくシステム全体のリソース状態を理解している必要があります。

もしネットワークのみをクリーンアップしたい場合は、よりターゲットを絞った docker network prune を使用するのが適切です。システム全体を定期的にクリーンアップする運用であれば docker system prune が便利ですが、削除対象リストを必ず確認し、特に --volumes オプションは安易に使用しないでください。

第9章：クリーンアップの自動化とベストプラクティス

定期的なDocker環境のメンテナンスには、クリーンアッププロセスの自動化を検討することも有効です。しかし、自動化は利便性をもたらす一方で、意図しない削除のリスクを高めるため、極めて慎重に行う必要があります。

9.1 自動化の検討

不要なネットワークを含むリソースのクリーンアップを自動化する方法としては、以下のようなものが考えられます。

cron ジョブ: ホストOSのcron機能を使用して、定期的に docker network prune または docker system prune コマンドを実行します。
スクリプト: クリーンアップ処理をシェルスクリプトなどに記述し、cronなどで実行します。スクリプト内で、削除対象リストをログに出力したり、特定のネットワークをフィルターで除外したりといったカスタマイズが可能です。
コンテナとして実行: クリーンアップを実行するコンテナを作成し、それを定期的に起動します。

9.2 自動化における安全性に関する警告

クリーンアップを自動化する場合、以下の点に厳重に注意する必要があります。

確認プロンプトのスキップ (-f): 自動化スクリプトでは、通常、対話式の確認プロンプトをスキップするために -f (または --force) オプションを使用せざるを得ません。これは非常に危険です。 -f オプションを使用する場合、削除対象となるリソースが常に期待通りであるという強い確証が必要です。例えば、特定のルール（例: 30日以上前に作成された、特定のラベルを持つ）に基づいてフィルタリングし、そのルールが誤削除を引き起こさないことを十分に検証する必要があります。
削除対象のフィルタリング: 自動化では、--filter オプションを積極的に活用し、削除対象を厳密に定義することが不可欠です。例えば、「production 環境で現在使用されている」ネットワークやイメージは絶対に削除しないように、ラベルや名前でフィルタリングします。
実行前のドライラン/ログ出力: 削除を実行する前に、削除されるリソースのリストを事前に取得し、ログに出力するなどして確認するステップを自動化スクリプトに組み込むことを強く推奨します。docker network prune --verbose の出力をパースして、削除対象リストを確認するなどの処理が考えられます。（ただし、Dockerコマンドの出力形式は将来変更される可能性があるため、パース処理は壊れやすいかもしれません）。
権限管理: 自動化スクリプトを実行するユーザーやコンテナには、必要な権限（Dockerデーモンへのアクセス権）のみを付与し、不用意にシステム全体に影響を与えないようにします。

結論として、自動化されたクリーンアップは便利ですが、誤削除によるリスクは手動実行よりも格段に高くなります。特にプロダクション環境では、安易な自動化は避け、まずは手動での定期実行から始めることを推奨します。自動化を導入する場合も、厳重なテストと検証、そしてフォールバック戦略（万が一削除してしまった場合の復旧手順）の準備が不可欠です。

9.3 Dockerネットワーク管理のベストプラクティス

クリーンアップを容易にし、不要なネットワークの発生を抑えるためのベストプラクティスをいくつか紹介します。

意味のあるネットワーク名を使用する: ネットワークを作成する際に、その用途や関連するアプリケーションが分かるような名前を付けます（例: myapp_backend_net, development_database). これにより、docker network ls の出力を見ただけでネットワークの目的を理解しやすくなります。
アプリケーションごとにカスタムネットワークを作成する: 複数のコンテナで構成されるアプリケーション（例: Webサーバー、アプリケーションサーバー、データベース）は、それぞれ専用のカスタムブリッジネットワークに配置することを検討します。これにより、関連するコンテナ間の通信は分離されたネットワーク内で行われ、アプリケーションが不要になった際にそのネットワークごとクリーンアップしやすくなります。デフォルトの bridge ネットワークに多数の無関係なコンテナを接続するのは避けるべきです。
ラベルを積極的に使用する: ネットワーク作成時にラベルを付与します（例: docker network create --label environment=development --label project=myapp myapp_dev_net). ラベルは、docker network ls --filter label=<key>=<value> や docker network prune --filter label=<key>=<value> の際にネットワークをフィルタリングするために使用でき、管理やクリーンアップが格段に容易になります。
Docker Composeを効果的に使用する: Docker Composeファイル内でネットワークを定義すると、サービスと一緒にネットワークが作成・管理されます。docker-compose down コマンドを実行すると、サービスと一緒にそのネットワークも（他のサービスが使用していない限り）削除されるため、ライフサイクル管理が容易になります。Composeファイルでネットワークを定義する際は、外部ネットワークとの接続方法（例: bridge, overlay）や、Composeネットワークの名前付けルール（プロジェクト名_ネットワーク名）を理解しておきましょう。

第10章：トラブルシューティング

安全な手順を踏んでいても、稀にネットワーク削除に関連する問題が発生することがあります。一般的な問題とその対処法を解説します。

10.1 エラー：「network is in use by container …」

原因: 削除しようとしているネットワークに、コンテナが接続されています。docker network rm を実行した場合に表示される最も一般的なエラーです。
対処法:
1. エラーメッセージに表示されているコンテナIDまたは名前を確認します。
2. docker ps -a コマンドでそのコンテナの状態を確認します。
3. もしコンテナが実行中（Up）であれば、そのコンテナがそのネットワークを必要としている可能性が高いです。そのネットワークは削除できません。必要であれば、まずコンテナを停止 (docker stop <container_id>) してから削除を検討してください。
4. もしコンテナが停止中（Exitedなど）であれば、そのコンテナが本当に不要かどうかを判断します。不要であれば、そのコンテナを削除します (docker rm <container_id>)。コンテナを削除すれば、ネットワークとの関連付けが解除され、ネットワークを削除できるようになります。
5. もしエラーメッセージにコンテナIDが表示されない場合や、docker network prune で特定のネットワークが削除対象にならない場合で、それが使用中であると判断される場合、docker network inspect <network_id> コマンドで Containers フィールドを確認し、接続されているコンテナを特定してください。

10.2 誤って必要なネットワークを削除してしまった

原因: 事前の確認が不十分であったり、自動化スクリプトのミスなどにより、誤って現在使用中または将来使用予定のネットワークを削除してしまった。
対処法:
1. 影響範囲の確認: どのコンテナが影響を受けているかを確認します。通信エラーや起動エラーが発生しているコンテナを特定します。
2. ネットワークの再作成: 削除してしまったネットワークと全く同じ名前、同じドライバー、同じ設定（特にIPアドレス範囲、ゲートウェイ、オプション、ラベルなど）でネットワークを再作成します。docker network create コマンドを使用します。元のネットワーク設定が分からない場合は、ネットワークを作成した時のコマンド履歴を探したり、Docker Composeファイルなどの定義ファイルを確認したりする必要があります。可能であれば、元のネットワークの docker network inspect の出力をバックアップしておくと、復旧時に役立ちます。
3. コンテナのネットワーク再接続/再起動: 再作成したネットワークに、影響を受けたコンテナを再接続します。
  - 実行中のコンテナの場合、ネットワーク設定を変更するのは難しい場合があります。コンテナを再起動するのが最も確実な方法です (docker restart <container_id>)。再起動時に、元のネットワークに自動的に再接続されることを期待します。
  - 停止中のコンテナの場合、ネットワーク設定を修正するか、コンテナを削除して再作成する必要があるかもしれません。最も簡単なのは、コンテナを削除 (docker rm <container_id>) し、元の設定で再作成・起動することです。Docker Composeを使用している場合は、docker-compose up -d を実行すれば、サービスとネットワークが正しく再作成・起動されるはずです。
4. アプリケーションの動作確認: ネットワークが復旧し、コンテナが再接続されたら、アプリケーションが正常に動作するかを確認します。
重要: このような事態を避けるためにも、事前の厳重な確認と、prune コマンドの確認プロンプトの重要性を改めて強調します。

10.3 ネットワークが削除できないが、どのコンテナも使用していないように見える

原因: 非常に稀ですが、Dockerデーモンの内部状態が不整合を起こしている、ネットワークが他のシステムリソース（例えば、Docker Swarmのサービスなど）によって参照されているが inspect に表示されない、あるいはファイルシステム上にネットワーク関連のゴミファイルが残っているなどの可能性があります。
対処法:
1. Dockerデーモンの再起動: Dockerデーモンを再起動することで、内部状態がリフレッシュされ、問題が解決することがあります。サービスの停止・再起動は、システム上のすべてのコンテナに影響を与える可能性があるため、計画的に実行してください。
2. Docker Swarmサービスの確認: Swarmモードを使用している場合、そのネットワークがSwarmサービスによって参照されていないか docker service inspect <service_name> などで確認します。
3. 強制削除の検討 (最終手段): 前述の通り非常に危険ですが、他に手段がない場合に限り、影響を十分に理解した上で docker network rm -f <network_id> を試みることも考えられます。ただし、これにより予期しない問題が発生するリスクがあることを覚悟する必要があります。
4. Dockerコミュニティやドキュメントの参照: 特定のエラーメッセージや状況に合わせて、Dockerの公式ドキュメントやコミュニティフォーラムで同様の問題が報告されていないか検索します。

第11章：まとめと結論

Dockerネットワークのクリーンアップは、システムの健全性、リソース効率、管理の容易さを維持するために重要な運用タスクです。しかし、誤ったネットワークを削除してしまうと、アプリケーションの停止など深刻な問題を引き起こす可能性があります。そのため、安全な手順と確認を徹底することが最も重要です。

本記事では、Dockerネットワークを安全に削除するための以下の主要なポイントを詳細に解説しました。

不要なネットワークを削除する理由（リソース消費、管理の複雑化、IP枯渇など）。
「未使用」の定義は、単に実行中のコンテナが接続されていないだけでなく、停止中のコンテナや将来の使用予定も考慮する必要があること。
ネットワーク削除の際のリスクとその深刻性。
ネットワークの使用状況を正確に把握するための docker network ls および docker network inspect コマンドの使い方。
最も安全で推奨される削除方法である docker network prune の詳細な使い方、その安全性、確認プロンプトの重要性、および --verbose や --filter といったオプションの活用方法。
手動でネットワークを削除する docker network rm コマンドについて、その基本的な使い方、コンテナが接続されている場合の安全機能、そして極めて危険な -f オプションは避けるべきであるという警告。手動削除を行う場合の厳格な確認手順。
docker system prune による包括的なクリーンアップについても触れ、ネットワーククリーンアップとの関連性や、他のリソース削除に伴うリスクについて説明しました。
安全なネットワーククリーンアップのためのステップ・バイ・ステップの手順。
クリーンアップの自動化における注意点とリスク。
クリーンアップを容易にするためのネットワーク管理のベストプラクティス（命名規則、ラベル、Composeの活用など）。
ネットワーク削除に関連する一般的なトラブルシューティング。

最も重要なメッセージは、削除対象となるネットワークが本当に不要であるという事前の確認を徹底し、クリーンアップツールの提供する安全機構（特に docker network prune の確認プロンプト）を必ず利用するということです。安易な自動化や -f オプションの使用は避け、リスクを十分に理解した上で行うべきです。

定期的なネットワークの棚卸しとクリーンアップを習慣化することで、Docker環境を常に最適な状態に保ち、将来的な問題発生を防ぐことができます。本記事が、皆様のDocker環境における安全なネットワーク管理の一助となれば幸いです。