ComfyUIの構造

ComfyUIは、実は「2つ」に分かれています。

サーバ（ComfyUI本体）

workflowを実行して、画像・動画・音声などを生成する“エンジン”側です。
ComfyUIを起動すると、ローカルでは http://127.0.0.1:8188 のようなURLで待ち受けているのがこのサーバです。

フロントエンド（操作画面）

サーバに対して「このworkflowを実行して」と指示を出す “操作” 側です。
普段使っているWebのノードUIは、このフロントエンドの一つに過ぎません。

APIは“サーバに命令を送る窓口”

フロントエンドとサーバは、勝手に繋がっているわけではありません。
その間をつないでいるのが API（命令を渡す窓口） です。

WebのノードUIも、内部的にはAPIを通してサーバに命令を送っています。
つまり、UIで ▷Run を押した瞬間、裏ではサーバに「このworkflowを実行して」というリクエストが送られているのです。

APIがあると「実行する方法」が増える

APIの一番面白いところは、同じComfyUIサーバを、ブラウザ以外の入口からも動かせるようになる ことです。

たとえば、以下のようなことができます。

  • コマンド（CLI）やスクリプトからworkflowを回す
  • 自作の小さなUI（フォームだけの画面など）を作って実行する
  • seedやテキストだけ差し替えて連続実行する

ノードUIは自由度が高い一方で、自由度が高すぎて混乱の原因になることもあります。
また、バッチ処理のように「同じworkflowをちょっとずつ変えながら何度も回す」際には、ノードをいじるよりスクリプトで回したほうがシンプルなときもあります。

用途に応じて入口を選べる、というのがAPIの利点ですね。

注意点

サーバは起動している必要がある

APIは「ComfyUIを起動しなくてよくなる仕組み」ではありません。

生成を実行するのはサーバ側なので、サーバは起動して待っている必要があります。

できるのは主に“実行”の自動化

「好きな方法で実行できる」といっても、基本的には “実行”の入口が増えるという話です。
workflowの組み立て自体は、基本的にはノードUIで行います。

そのうえで、seedやテキストなどのパラメータを少しずつ変えたり、workflowごと切り替えたりして連続実行できる、というイメージです。