Comfy APIは、自分のComfyUI workflowに必要な環境をまとめ、管理されたGPU上のエンドポイントから呼び出す仕組みです。ローカルで動くJSONを渡すだけで準備が終わるとは限りません。Build、Release、Deploymentを分け、モデル・ノード・Python依存をそろえてから一件の実行を確かめます。
三つの名前は、環境・固定版・実行先を指す
| 名前 | 意味 | 記録するもの |
|---|---|---|
| Build | ComfyUIと依存関係の環境定義 | モデル・ノード・パッケージ |
| Release | 配布対象向けに固定したBuildの版 | リリースIDと検証結果 |
| Deployment | Releaseを使う実行エンドポイント | 接続URL、GPU、リージョン、ワーカー設定 |
たとえば商品写真workflowを作った段階で必要なのは、使用する環境の定義です。その環境を固定したReleaseを用意し、実行するDeploymentへ結び付けます。三つを同じ「公開設定」と呼ぶと、環境を更新しただけで本番も変わったのか判断できなくなります。
最初に、手元で動く最小workflowを残す
試験用ノードや使わない分岐が多い状態から始めるより、実際に提供する処理へ絞ります。入力一つ、出力一つから通し、必要な機能を増やします。最低限、次の情報を手元へ残してください。
- 編集用JSONとAPI形式JSON
- 使うモデル・LoRAの名前と版
- カスタムノードの配布元と版
- ComfyUIとPython依存の構成
- 試験用入力と、期待する出力の条件
API形式の書き出しはGUI用JSONとの違いで確認できます。ローカルの絶対パスを入力に埋めている場合は、外部環境でも使える素材の受け渡しへ変更します。
Buildの定義と実ファイルを混同しない
comfy-build.yamlは環境定義とリモートの状態を記録するファイルで、モデル本体を内包するものではありません。定義をGitへ保存しても、必要なモデルがどこから取得できるか、利用できるかの確認は残ります。
CLIで現在の状態を確認する入口は次のコマンドです。既にBuildを用意したプロジェクトで使います。
comfy build statusローカル、Build定義、リモートのどこに変更があるかを確認してから更新します。依存関係の自動検出を使う場合も、提案された版が実際の制作条件と一致するかを読み直してください。
公開前に、一件の入力から保存までを通す
Deploymentが起動したことと、目的のworkflowを実行できることは別です。SDKの接続先を対象のURLへ設定し、API形式workflowと小さな入力で試します。認証キーはサーバー側で扱い、ブラウザのコードへ埋め込みません。
合格条件は、ジョブが終了したことだけではありません。必要な出力が取り出せること、保存形式やサイズが合っていること、失敗時に原因を確認できることまで含めます。最初から大量投入せず、一件で作った記録を基準にしてください。
ワーカー設定は、待ち時間と費用を分けて考える
ワーカーの最小・最大数は、待ち時間と同時処理の設計に関わります。最低数をゼロにする運用には、最初の要求で起動を待つ場面があります。また、計算処理が止まっていることと、保存領域を含む利用額がすべてゼロになることは同じではありません。契約・料金と現在の設定を確認して決めます。
現行の操作と条件は公式Comfy API Deployment Guideが確認先です。まずは試験用Deploymentで一件を完走させ、その記録を基準に本番向けの構成を選びます。