ローカルAI環境構築における「混沌」とした現実
Stable Diffusionをローカルで実行することは、最初は楽しいプロジェクトとして始まりますが、すぐにDevOps의 悪夢へと変わることがよくあります。ほとんどのチュートリアルでは、リポジトリをクローンし、仮想環境を作成してシェルスクリプトを実行するという、直接的なインストール方法を提案しています。これは最初の20分間はうまく機能しますが、やがて破綻します。ComfyUIに新しいカスタムノード（Custom Node）をインストールした途端、Pythonの依存関係が競合したり、CUDAのバージョンが一致しなくなったり、あるいはグローバルなライブラリのアップデートによってPyTorchの設定が消え去ったりするからです。
新しいモデルやワークフローを試そうとするたびに、私は何週間も環境のトラブルシューティングに時間を費やしてきました。同僚とワークフローを共有することも、ローカルマシンの構成が一致しないため、ほぼ不可能でした。生成AI専用のPython環境を維持するための摩擦は、創造性やプロダクションレベルの自動化に集中したい場合に、大きなボトルネックとなります。
根本的な原因：依存関係地獄とGPUの連携
核心的な問題はComfyUI自体ではなく、その基盤となるスタックにあります。Stable Diffusionは、NVIDIAドライバ、CUDAツールキット、PyTorchのバージョン、そして膨大な数のPythonパッケージが特定の組み合わせで交差することに依存しています。ComfyUIの最大の強みである「カスタムノードによる拡張性」は、ローカルインストールにおいてはアーキテクチャ上の弱点にもなります。各ノードが insightface や opencv といったライブラリの異なるバージョンを要求する可能性があるからです。
これをOS上で直接実行すると、AIツールをシステムのグローバルな状態に縛り付けることになります。システムドライバやPythonのバージョンを更新すると、画像生成パイプライン全体が壊れるリスクがあります。さらに、物理GPUをソフトウェアレイヤーにマッピングするには精密な設定が必要であり、標準的な仮想環境では完全に分離しきれないのが現状です。
解決策：ComfyUIのコンテナ化
これを解決するために、スタック全体をDockerに移行します。NVIDIA Container Toolkitを使用することで、ホストシステムをクリーンに保ったまま、GPUのパワーを分離されたコンテナに渡すことができます。このアプローチにより、メインOSで何が起きようとも、コンテナ内の環境は起動するたびに常に同一であることが保証されます。
私はこの手法を本番環境に適用してきましたが、結果は一貫して安定しています。バックアップが容易になり、サーバー間の移行も素早く行えるほか、カスタムノードのインストールで環境が乱れても「リセット」ボタン一つで元に戻せます。
ステップ1：ホストシステムの準備
Dockerを触る前に、ホストマシンに適切なNVIDIAドライバをインストールしておく必要があります。ホスト側にCUDAツールキットをフルでインストールする必要はありません（コンテナ側で処理されるため）が、ドライバは必須です。Linuxシステム（Ubuntu/Debian）では、ドライバが最新であることを確認してください：
nvidia-smiこのコマンドでGPUの詳細が表示されれば、準備完了です。次に、NVIDIA Container Toolkitをインストールします。これはDockerがハードウェアを「認識」できるようにするための架け橋となります：
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart dockerステップ2：Docker Compose設定の設計
長くて煩雑な docker run コマンドを実行する代わりに、Docker Composeを使用します。これにより、ボリューム（モデルや出力の保存先）や環境変数をクリーンなYAMLファイルで定義できます。comfyui-docker というディレクトリを作成し、docker-compose.yml ファイルを追加します：
services:
comfyui:
image: yanagiwara/comfyui-docker:latest-cuda12.1 # または同様の信頼できるイメージ
container_name: comfyui
runtime: nvidia
environment:
- NVIDIA_VISIBLE_DEVICES=all
ports:
- "8188:8188"
volumes:
- ./storage/models:/home/user/ComfyUI/models
- ./storage/output:/home/user/ComfyUI/output
- ./storage/input:/home/user/ComfyUI/input
- ./storage/custom_nodes:/home/user/ComfyUI/custom_nodes
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
restart: unless-stoppedこの設定では、ローカルのフォルダをコンテナ内部のComfyUIフォルダにマッピングしています。これは非常に重要です。5GBもあるモデルファイルをコンテナの揮発的なストレージに保存したくはないはずです。コンテナを削除しても、モデルや生成された画像は ./storage ディレクトリに安全に残ります。
ステップ3：起動と初期設定
次のコマンド一つでスタックを起動します：
docker compose up -dイメージのダウンロードと起動が終わったら、ブラウザで http://localhost:8188 にアクセスしてください。デフォルトのComfyUIグラフが表示されます。ただし、まだチェックポイントモデルを追加していないため、このままでは動作しません。
SDXLやSD1.5などの .safetensors ファイルを ./storage/models/checkpoints フォルダに移動してください。UIをリフレッシュすると、「Load Checkpoint」ノードにモデルが表示されます。custom_nodes フォルダをボリュームとしてマッピングしているため、ComfyUI Managerを使用してノードをインストールしても、後でDockerイメージを更新した際に設定が失われることはありません。
状態管理とカスタムノードの扱い
Dockerを利用する際によくあるハードルは、新しいノードが必要とするPythonライブラリの扱いです。最近の主要なComfyUI Dockerイメージの多くは、起動時にノードの requirements.txt に記載された依存関係を自動インストールするように設定されています。複雑なノードが読み込みに失敗した場合は、単純にコンテナを再起動してください：
docker compose restart comfyuiログを確認すれば、どのライブラリが不足しているか正確に把握でき、ホストマシンのOSを汚すことなくデバッグが可能です。この隔離環境こそが、このワークフローの最大の利点です。特定のノードが環境を壊してしまったとしても、custom_nodes 内のそのフォルダを削除するだけで、すぐにクリーンな状態に戻せます。
最後に
ComfyUIをDockerに移行することで、それは「壊れやすいスクリプト」から「信頼できるインフラ」へと進化します。storage フォルダと docker-compose.yml ファイルを同期するだけで、AIの作業環境全体をローカルワークステーションからクラウドのGPUインスタンスへ簡単に移動できるようになります。「自分の環境では動いたのに」という言い訳はなくなり、次の pip install で環境が壊れることを心配せずに、Stable Diffusionのための複雑なノードベースのワークフロー構築に集中できるようになります。
