AI駆動開発でDockerのネットワークが枯渇する？ 並行開発時に知っておきたい仕組み

AI駆動開発が進むと、これまであまり意識しなかった開発環境側の制約にぶつかることがあります。

その一つが、Dockerの

「ネットワーク用アドレスプールの枯渇」

です。

一見すると、

「Dockerのネットワークが枯渇するってどういうこと？」

となりますが、AIエージェントを使って複数タスクを同時並行で開発するようになると、意外と現実的な問題になってきます。

特に、Git worktreeとDocker Composeを組み合わせて並行開発している場合は知っておいたほうがよいポイントです。

そもそも、なぜDockerを使うのか

Webシステムを開発するときは、アプリケーションだけ動けばよいわけではありません。

たとえば、

• Webフロントエンド
• APIサーバー
• PostgreSQL
• Redis
• メール送信環境
• その他のミドルウェア

など、複数のサービスを組み合わせて動かします。

これらをMacやWindowsへ直接インストールすると、

「自分のPCでは動くけれど、別の人のPCでは動かない」

という問題が起こりやすくなります。

そこでDockerを使います。

Dockerでは、アプリケーションやDBなどをそれぞれ独立したコンテナとして起動できます。

たとえばDocker Composeを使えば、

services:
  web:
  api:
  db:
  redis:

という複数サービスを、

docker compose up

だけでまとめて起動できます。

つまりDockerは、

開発環境をコードとして定義し、誰でも同じ環境を再現するための仕組み

と考えると分かりやすいでしょう。

Dockerではコンテナ同士をネットワークでつなぐ

Dockerで起動したコンテナは、それぞれ完全に孤立しているわけではありません。

APIからDBへ接続したり、WebからAPIへアクセスしたりする必要があります。

そのためDockerでは、コンテナ同士を接続するための仮想ネットワークを作ります。

Docker Composeの場合、特に指定しなければ、

project_default

のようなネットワークが自動的に作成されます。

そして、

web
api
db
redis

といった複数のコンテナが、同じネットワークへ参加します。

ここで重要なのは、

1コンテナにつき1ネットワークではない

という点です。

4個のコンテナがあっても、通常は1個のDockerネットワークを共有します。

では、なぜネットワークが大量に増えるのか

通常の開発であれば、Dockerネットワークの数を意識することはほとんどありません。

しかしAI駆動開発では事情が変わってきます。

たとえばGit worktreeを使って、

worktree-A：ログイン機能を修正
worktree-B：検索機能を実装
worktree-C：管理画面を変更

というように、複数の作業環境を同時に持つことができます。

さらに、それぞれのworktreeで、

docker compose up

を実行すると、

worktree-a_default
worktree-b_default
worktree-c_default

のように、別々のDockerネットワークが作られます。

人間が一人で順番に開発していたころなら、せいぜい1〜2環境しか同時に立ち上げませんでした。

ところがAIエージェントを使えば、

Agent A → 機能Aを実装
Agent B → 機能Bを実装
Agent C → バグ修正
Agent D → テスト

という並行作業が可能になります。

その結果、

CPUやメモリより先に、Dockerネットワークのような開発基盤側の制約へ到達する

ことがあります。

Dockerのネットワークは無限ではない

Dockerがネットワークを作成するときは、それぞれにIPアドレスの範囲を割り当てます。

たとえば、

172.18.0.0/16
172.19.0.0/16
172.20.0.0/16

といった範囲です。

問題は、Dockerのデフォルト設定では比較的大きなアドレス範囲が1ネットワークごとに割り当てられることです。

そのため、

「IPアドレスを何百万個も使った」

わけではないのに、

新しいネットワークへ割り当てられるアドレス範囲がなくなる

ことがあります。

これが、

Dockerのネットワーク用アドレスプール枯渇

です。

環境によりますが、デフォルト設定では数十個程度のネットワークを作成した段階で問題になるケースがあります。

AI駆動開発では特に注意したい

たとえば1つの開発環境が、

frontend network
backend network

という2つのネットワークを使っているとします。

そしてGit worktreeを15個作り、それぞれDocker Composeを立ち上げれば、

15環境 × 2ネットワーク
= 30ネットワーク

です。

さらに過去に使ったDockerネットワークが残っていれば、もっと早く上限へ近づきます。

つまりAI駆動開発では、

「何個のAIエージェントを並列で動かせるか」だけではなく、「何個の完全な開発環境を並列で持てるか」

という観点も必要になります。

並行開発そのものの進め方は、worktreeで作業フォルダを分ける方法で解説しています。

まずは現在のネットワーク数を確認する

現在Dockerに存在するネットワークは、

docker network ls

で確認できます。

数だけ確認したければ、

docker network ls -q | wc -l

でも構いません。

長くDockerを使っている環境では、すでに使われていないネットワークが残っていることもあります。

不要なネットワークを削除する場合は、

docker network prune

が利用できます。

ただし、削除前に現在利用している環境へ影響がないか確認したほうが安全です。

根本対策はネットワークを細かく分けること

Dockerでは、ネットワークへ割り当てるアドレス範囲を変更できます。

たとえば1ネットワークへ巨大な /16 を割り当てるのではなく、

172.17.0.0/24
172.17.1.0/24
172.17.2.0/24

のように細かく分割すれば、作成できるネットワーク数を大幅に増やせます。

通常のWeb開発環境であれば、1つのDockerネットワークに6万台ものコンテナを接続することはまずありません。

それよりも、

小さなネットワークを大量に作れるほうがAI並行開発には適しています。

AI駆動開発では「開発環境の設計」も変わる

AI駆動開発というと、

• どのLLMを使うか
• プロンプトをどう書くか
• エージェントをどう分担するか

といった部分に注目しがちです。

しかし実際に並行開発を進めると、

• Git worktree
• Docker
• ポート番号
• DB
• Dockerネットワーク
• CPU
• メモリ
• テスト環境

といった、従来はあまり問題にならなかった部分がボトルネックになります。

これまでは、

人間1人
↓
1ブランチ
↓
1開発環境

だったものが、

人間1人
↓
複数AIエージェント
↓
複数worktree
↓
複数Docker環境

へ変わりつつあります。

AIによってコードを書く速度だけが上がるのではありません。

同時に存在する開発環境そのものが増える。

Dockerネットワークの枯渇は、その変化を象徴する問題の一つかもしれません。

AI駆動開発を本格的に並列化するなら、コードやAIエージェントだけではなく、

「何個の開発環境を安全に同時起動できるか」まで含めて開発基盤を設計する。

今後は、そこまで考える必要がありそうです。

AIに任せきれないのはネットワーク周りだけではありません。AI駆動開発で本当に難しいインフラ周りもあわせてどうぞ。

開発環境の設計から相談したい場合は、開発環境の設計を含めた受託開発をご覧ください。