Comfy API、ComfyUIワークフローを本番エンドポイントに変換

ComfyUIで何か役立つものを作ったことがある人なら誰でも知っている、ある種の苛立ちがあります。ワークフローは自分のマシンでは動き、何週間もかけて調整され、適切なカスタムノード、適切なLoRA、すべての適切に固定されたバージョンが揃っています。ところが、それをチームの他のメンバーや製品で使えるようにしてほしいと誰かに頼まれると、終わったと思っていた作業が実は半分しか終わっていなかったと分かります。

ComfyUIワークフローを本番環境に導入するには、従来はその環境をどこか別の場所で再構築する必要がありました。GPUを借り、すべてのカスタムノードとモデルを再インストールし、Pythonの依存関係が競合しなくなるまで解きほぐし、その周囲にスケーリングロジックを書きます。グラフは同じでも、エンジニアリングはまったく新しく、しかもそれはそもそもなぜそのワークフローを作ったのかとは何の関係もない種類の作業です。

ComfyUIはそのギャップを埋めるため、9月末にComfy APIをローンチしました。有料のComfyプランを利用していれば誰でも利用でき、その名のとおりのことをします。つまり、ワークフローを変更することなく、ComfyUIワークフローをオートスケーリングするAPIエンドポイントに変換します。

一度パッケージ化すれば、選んだGPUにデプロイできる

仕組みを理解する価値があります。というのも、価値の大部分はそこにあるからです。ワークフローJSONから始めるか、Comfy Desktopからスナップショットをエクスポートします。ビルダーがワークフローを読み取り、必要なモデルとカスタムノードを見つけ、競合するPython依存関係の解決を支援します。ビルダーが選んだバージョンはどれでも上書きできます。

この解決ステップはBuildに取り込まれます。ワークフローが想定するComfyUIのバージョン、カスタムノード、モデル、LoRA、Python依存関係がすべて一緒に固定されます。Buildからイミュータブルなリリースを切り出し、そのリリースを独自のURLを持つマネージドエンドポイントとしてデプロイします。

重要なのはイミュータブルなリリースです。リリースは切り出した後は変わらないため、テストした環境がそのままデプロイされる環境になります。変更が必要なときはBuildを更新して新しいリリースを切り出し、稼働中のリリースには触れません。依存関係が下で勝手に変わったせいで動いていたパイプラインが壊れるのを見たことがある人なら、これが単なる便利機能以上のものだと分かるでしょう。

デプロイはComfyUIのDeveloper Platform上で実行され、ビルド、デプロイ、使用量、支出、APIキーが1つのコンソールにまとまります。ブラウザ、ターミナル、またはコーディングエージェントから作業できます。コマンドラインの手順は簡潔です。`comfy build init` を実行するとComfyUIインストールをスキャンしてカスタムノード、モデル、固定された依存関係を見つけます。`comfy build push --release` を実行するとパッケージ化して公開します。Comfy APIページにはコピー＆ペーストできるエージェント用プロンプトもあり、すべてをコーディングアシスタントに任せたい人に適しています。

料金と、実際に誰向けなのか

ワークロードはアイドル時にゼロまでスケールするため、ワーカーが動いていないときはGPU時間に課金されません。バースト的なクリエイティブパイプラインにとって、これは固定の月額GPU請求と、実行した作業にだけ支払うことの違いです。レイテンシに敏感なリクエストを抱えるチームは、代わりにワーカーをウォーム状態に保つことができ、コストと引き換えにコールドスタートをなくせます。

GPU課金は秒単位で、料金は公開されています。RTX PRO 6000が1時間4.54ドル、H100が6.23ドル、H200が7.71ドル、B200が11.23ドルです。Standard以上の有料プランが必要で、使用量は別途請求されます。

このローンチで最も正直なのは、誰が使うべきでないかについてComfyUIが述べている点です。チームは、RunPodやModalがすでに自分たちに合っているなら使い続けるようにと述べ、Comfy APIはComfyUI環境そのものの管理が頭痛の種である場合に適していると位置づけています。これはよくある「何でもできるプラットフォーム」という売り込みより有用なポジショニングであり、ターゲット顧客が誰かも示しています。つまり、ボトルネックが生のコンピュート調達ではなく依存関係管理にある人たちです。

これが小規模チームの提供可能なものを変える理由

この変化を最も明確に見るには、引き継ぎの問題を通して見るのがよいでしょう。ワークフローを作る人が、それを実行する必要がある唯一の人であるとは限りません。デザイナーがカスタムノードと微調整済みLoRAを使って商品撮影ワークフローを調整し、その後チームの他のメンバーがComfyUIを開かずに実行できる簡単なインターフェースを必要とします。製品チームは、顧客が画像のスタイルを変更できるようにしたいと考え、アプリが各リクエストをチームが管理するワークフローに送り、トラフィックに応じてスケールさせます。運用チームは、誰もグラフを監視することなく、新しいカタログ項目が毎週自動的にワークフローを通ることを望みます。

この3つはすべて同じニーズのバリエーションです。実際の専門知識をエンコードしたグラフを、それを公開したり再構築したりすることなく、他の人に使ってもらうことです。Comfy APIはまさにそこを狙っています。チームにツールを提供し、製品に機能を追加し、繰り返し可能なクリエイティブ作業を自動化できます。しかも、それらの利用者はグラフを理解する必要がありません。

TeamおよびEnterpriseプランでは、チームメンバーは同じBuildから作業でき、バージョン、モデル、カスタムノード、依存関係が一緒に固定されます。Enterprise顧客はManaged Buildsとガバナンスコントロールを利用でき、承認済みのバージョンと依存関係をチーム間で標準化できます。この最後の機能は、大規模組織における実際のリスクに対処します。3つのチームが3つの互換性のないComfyUI環境を維持し、どの環境が特定のアセットを生成したのか誰にも分からない、というリスクです。

より大きな展望

ComfyUIが実質的に行ったのは、自らをローカルツールからホスト型メディア生成スタックへとアップグレードすることです。エンジンはオープンソースのままで、Buildは自分が所有するハードウェアにもポータブルなままなので、同社はワークフローを自社クラウド内に閉じ込めようとしているわけではありません。このポータビリティは、ホスト型ツールが通常は逆方向に引っ張る市場において、注目すべき選択です。

このローンチは、画像および動画生成における価値がどこへ移ったかについても語っています。1年前は差別化はモデルにありました。今では高性能なモデルが誰でも利用でき、オープンウェイトによって多くがローカルハードウェア上で動くようになったため、差別化はワークフローへ移りつつあります。汎用モデルを1つの狭い目的に対して信頼できる出力に変える、ノードと設定の特定の並びです。そうしたワークフローにこそドメイン専門知識がエンコードされており、これまではそれを運用可能にするのが難しかったのです。

Comfy APIがその標準的な道になるかどうかは未解決の問題です。有料プランが必要で、ComfyUI自社プラットフォーム上で動作し、専門のGPUクラウドと生の価格で競争しているわけではありません。しかし、AIメディアを出荷するうえで最も創造的でなく、最もエラーが起きやすい部分を取り除いてくれます。多くの小規模チームにとって、そのトレードオフこそが、社内ツールを販売できるものに変えられる理由そのものなのです。