ComfyUIを読む：ノードグラフで組み立てる生成ワークフローの実像

ComfyUIが扱う制作範囲

ComfyUIのメタデータは、グラフとノードのインターフェースを備えた拡散モデルのGUI、API、バックエンドとしてプロジェクトを説明しています。READMEの表現では、モデル、パラメータ、出力を細かく制御したいビジュアル制作者向けのAI制作エンジンです。対象は画像に限られません。画像、動画、3Dモデル、音声、テキストのワークフローを同じ考え方で組み立てられます。オープンソースモデルに加えて、Partner nodesを通じてNano Banana、Seedance、Hunyuan3Dなどのクローズドソースモデルへ接続できると記載されています。ただし、各サービスの認証方法、利用料金、必要なアカウントはREADMEだけでは判断できません。Windows、Linux、macOSでのローカル利用、Windows向けポータブル版、公式の有料クラウド版が案内されており、手元のGPUを使うか、クラウドを選ぶかを入口で分けられる構成です。

ノードグラフが生む再利用性

中心にあるのは、処理をノードとして並べ、入力と出力の関係を線で結ぶビジュアルグラフです。コードを書かずに画像生成や動画処理の手順を可視化でき、完成したワークフローを保存して再利用できます。READMEは、再利用可能なサブグラフ、テンプレート、App Mode、アプリケーションから呼び出すローカルAPIを挙げています。実行時には非同期キューが使われ、変更されたグラフの一部だけを再実行する仕組み、VRAMとRAMの管理、モデルオフロード、量子化モデルへの対応も説明されています。これは単に画面上でノードを置く道具というより、試行錯誤の履歴を構造化して残すための形式です。対応する生成メディアからシードを含むワークフローを復元できる場合もあるため、結果だけでなく、どの処理を通ったかを共有しやすくなります。

モデルとメディア処理の広がり

READMEが示すモデル一覧は代表例です。画像生成ではStable Diffusion 1.5、SDXL、SD3.5、Flux.1、Flux.2、Qwen Image、Hunyuan Image 2.1など、動画ではWan 2.1と2.2、LTX-Video 2と2.3、HunyuanVideo 1.5、CogVideoXなどが挙げられています。音声生成にはACE-Step 1.5とStable Audio 3、音声と動画をまたぐ用途にはMiniMax H3とLTX-AVがあります。3Dと視覚処理ではHunyuan3D 2.1、TripoSplat、SAM 3と3.1、Depth Anything 3など、テキストではGemma 3と4、Qwen3、Qwen3.5、Qwen3-VLなどが列挙されています。読み込める単位も、完全なチェックポイントだけではありません。拡散モデル、VAE、テキストエンコーダ、LoRA、ControlNet、アダプタ、アップスケーラを分けて扱えます。インペイント、アウトペイント、マスク合成、モデル統合、アップスケール、フレーム補間、セグメンテーション、深度推定などを組み合わせられる一方、READMEは対応モデルの総数や品質比較を保証していません。

導入経路とモデル配置

最初に試す経路として、WindowsとmacOS向けのデスクトップアプリが案内されています。Windowsには最新コミットを含むポータブルパッケージもあります。手動導入ではリポジトリを取得し、チェックポイントをmodels/checkpoints、VAEをmodels/vaeへ置き、依存関係をインストールしてpython main.pyを起動します。GPUの選択肢はNVIDIAだけでなく、AMD、Intel、Apple Silicon、AscendなどがREADMEに記載されています。ROCm、Intel XPU、CUDA、Apple Silicon、Ascend NPU、Cambricon MLU、Iluvatar Corex向けのPyTorch導入例も示されています。comfy-cliを使う場合は、インストール後にcomfy installを実行する流れです。モデルファイルは別途用意する必要があり、どのモデルを選ぶかで必要なメモリや追加ノードが変わります。READMEは広い対応範囲を示していますが、すべての組み合わせが同じ条件で動くとは書いていません。導入時は利用するワークフローを先に決め、必要なモデル形式と保存場所を照合するのが現実的です。

起動オプションとオフライン運用

基本の起動方法はpython main.pyです。カスタムノードの導入と管理を行うComfyUI-Managerを使う場合は--enable-managerを指定でき、旧UIや管理UIに関するオプションもあります。プレビューは--preview-method autoで有効にでき、TAESDのデコーダをmodels/vae_approxに置けばtaesd方式を使えます。TLSを使う起動オプションとして鍵と証明書の指定も用意されていますが、READMEは自己署名証明書を共有環境や本番環境に使わないよう注意しています。コアは、要求しない限り何もダウンロードしない完全オフラインの実行を説明しています。外部の有料Comfy API nodesを切り、組み込み機能をオフラインに限定するには--disable-api-nodesを使います。これは外部通信を減らす設定として読めますが、カスタムノードや利用者が組み込んだ処理の通信まで自動的に評価するものではありません。ネットワーク境界、モデルの出所、拡張機能のコードは、運用側で確認が必要です。

CoreとFrontendを分けるリリース構成

ComfyUIのリリースは、単一のパッケージだけを見ると理解しにくい構成です。READMEはCore、Desktop、Frontendの三つの関連リポジトリを説明しています。Coreはおおむね二週間ごとに安定版のメジャーリリースを出し、v0.4.0以降は安定版へ戻した修正にパッチ番号を使う方針です。Desktopは安定したCoreを基盤に配布物を作り、Frontendは別リポジトリで更新され、次のCoreリリースに向けて変更が取り込まれます。全体のリリース周期は週次を目標にしながら、モデル公開や大きなコード変更で変動します。READMEは、安定タグ以外のコミットが非常に不安定で、多数のカスタムノードを壊す可能性があると警告しています。したがって、検証環境では最新コミットをそのまま採用するより、Core、Frontend、カスタムノード、利用モデルの組み合わせを固定して記録する方が判断しやすいでしょう。

GPLとREADMEに残る確認事項

リポジトリのライセンスはGPL-3.0です。READMEのライセンス説明は、プログラムを共有・改変する自由を守るコピーレフトであること、改変版であることを示す必要があること、保証がないことを示しています。これはComfyUI本体の配布条件を考える材料であり、各モデル、LoRA、ControlNet、カスタムノード、外部APIの利用条件を一括で許可するものではありません。サポート窓口としてDiscordとMatrixへのリンク、Managerリポジトリ、GPU購入ガイドを含むQAへの導線があります。反対に、READMEからは性能ベンチマーク、完全なハードウェア要件、クラウドの価格と容量、APIノードの認証や保持方針を確認できません。ComfyUIは細かな制御を必要とする制作環境として有力ですが、導入判断は機能一覧だけで決めず、目標ワークフローを固定した小規模な試行、ライセンス確認、拡張ノードの保守状況の確認を順に行うべきです。

編集部の結論

ComfyUIは、モデルや処理工程を自分で組み替えたい制作者、研究者、既存パイプラインへ生成処理を組み込みたい開発者に向きます。導入前には使用するモデルのライセンス、GPUとメモリの条件、カスタムノードの互換性、クラウド機能の料金を個別に確認してください。READMEは広い機能範囲を示しますが、性能ベンチマーク、完全なハードウェア要件、クラウドの容量や料金までは示していません。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes