ComfyUI ワークフロー API を Web サイトに組み込む方法：フロントエンド、バックエンド、キュー、結果表示

Fri, 10 Jul 2026 06:24:49 +0800

ComfyUI ワークフローを Web サイトに組み込む作業は、単に API を 1 回呼ぶだけではありません。実用的な流れには、フォーム、バックエンドのタスク API、パラメータ変換、画像アップロード、キュー、状態ポーリング、結果保存、エラー処理が必要です。

基本方針は、workflow JSON をバックエンドで管理し、ユーザーには安全なパラメータだけを入力させることです。

2 つの API 層を分ける

通常は次の 2 層です。

ブラウザが呼ぶ自サイトの API。
バックエンドが呼ぶ ComfyUI API。

ComfyUI API をそのまま公開インターネットに出すべきではありません。

最小のサイト機能

ユーザーがフォーム入力
  -> バックエンドがタスク作成
  -> workflow JSON にパラメータを反映
  -> ComfyUI に送信
  -> フロントエンドが状態をポーリング
  -> 結果ファイルを取得
  -> 表示または保存

これで最初のバージョンは成立します。

バックエンド API 設計

1
2
3

POST /api/generate
GET  /api/tasks/{taskId}
GET  /api/tasks/{taskId}/result

POST /api/generate はタスクを作って taskId を返すだけにします。生成完了まで HTTP リクエストを待たせない方が安全です。

タスク状態は自分で管理する

queued
running
succeeded
failed
expired

ComfyUI の queue や history だけに頼らず、プロダクト側の状態を持ちます。

workflow JSON をユーザーに渡さない

ユーザーが操作できるのは安全な項目に限定します。

prompt;
negative prompt;
style;
size;
seed;
uploaded image;
制限内の strength や steps。

任意の workflow JSON を受け付けると、モデル、ノード、ファイルパス、高コスト処理を露出する可能性があります。

パラメータマッピングを分ける

form.prompt -> workflow node text
form.seed -> sampler seed
form.width -> latent width
form.height -> latent height

マッピング層を作ると、ワークフロー変更時にフロントエンドを大きく変えずに済みます。

画像アップロード

image-to-image や参照画像では：

バックエンドにアップロード。
種類とサイズを検証。
一時保存。
ComfyUI が読める場所に渡す。
期限後に削除。

ブラウザのファイル名や MIME type だけを信用しないでください。

フロントエンドの体験

表示すべきもの：

入力検証;
アップロード進捗;
キュー中または生成中の状態;
待ち時間の説明;
結果プレビュー;
再試行;
分かりやすいエラー。

ただのスピナーだけでは不十分です。

ComfyUI 送信の擬似コード

receive request
validate user input
create task record
load workflow template
patch safe parameters into workflow
submit prompt to ComfyUI
save prompt_id and task status
return taskId

その後 worker またはポーリングで状態を更新します。

結果ファイルの保存

方法 1：バックエンドでプロキシする

小さな内部ツールなら簡単です。バックエンドが ComfyUI から取得し、ブラウザへ返します。

方法 2：オブジェクトストレージに保存する

公開サイトでは S3、R2、OSS などへ保存し、DB には URL とメタデータだけを残す方が扱いやすいです。

キューが必要な理由

画像生成は遅く、GPU は限られます。キューなしでは連打で簡単に詰まります。

制御すべきもの：

concurrency;
user rate limit;
retry;
timeout;
priority;
GPU utilization。

分かりやすいエラーにする

内部エラーをユーザー向けに変換します。

prompt が不正;
ファイルが大きすぎる;
生成がタイムアウト;
モデルが一時的に使えない;
キューが満杯;
結果が期限切れ。

スタックトレースはログに残し、ブラウザへ出さないでください。

本番前の保護

認証または quota;
アップロード制限;
prompt と内容ポリシー;
workflow パラメータ制限;
キュー並列数;
timeout と cancellation;
結果の期限切れ;
コスト監視;
モデルとノードの allowlist;
内部 API 保護。

RunningHub と自前 ComfyUI の選び方

RunningHub のようなホスト型は検証が速く、インフラ負担が少ないです。自前 ComfyUI はモデル、ノード、GPU コスト、データ境界、カスタム workflow を細かく制御できます。

素早い検証はホスト型、深い制御が必要なら自前運用が向きます。

FAQ

フロントエンドから直接 ComfyUI API を呼べますか？

公開サイトでは推奨しません。バックエンドを境界にします。

WebSocket は必要ですか？

最初はポーリングで十分です。後から進捗表示を改善できます。

workflow JSON をユーザーにアップロードさせてもよいですか？

通常は避けます。バックエンド管理にして安全な入力だけ受けます。

結果はどこに保存すべきですか？

本番では ComfyUI マシンではなくオブジェクトストレージが扱いやすいです。

1 つのサイトで複数 workflow を扱えますか？

可能です。workflow ID と個別マッピングで管理します。

動画 workflow も同じですか？

構造は似ていますが、動画は timeout、保存容量、キュー、進捗表示がより重要です。

まとめ

ComfyUI をサイトに組み込むときは、内部レンダリングエンジンとして扱うのが安全です。バックエンドが workflow、キュー、状態、保存、制限を持ち、フロントエンドは安全な入力と結果表示に集中します。

Workflow on KnightLiブログ