Comfy Routerのsubmitで連続生成する｜再送・待機・キャンセルの設計

複数の商品画像を順番に生成するなら、生成要求を送る処理と、結果を回収する処理を分けると扱いやすくなります。Comfy Routerのsubmitは、受付後のリクエストIDを使って状況を確認する方式です。「送信できた」を「画像が保存できた」と同じ状態にしないことが、連続処理の出発点になります。

一件の仕事を、送信前から記録する

アプリ側で商品番号などの業務IDを作り、モデルID、入力、冪等性キーを保存してからsubmitします。受付後にリクエストIDを追記すれば、途中でアプリが終了しても、未送信と結果待ちを区別できます。

{
  "job_id": "catalog-0042",
  "model_id": "catalogから選んだID",
  "idempotency_key": "送信前に保存した一意なキー",
  "request_id": null,
  "local_state": "ready"
}

これは自分のアプリで使う管理データの例であり、Routerへ送る入力ではありません。生成入力はモデルのスキーマに合わせて別に持ちます。入力を変えた再制作には新しい業務上の版を作り、同じ入力の通信再試行と分けましょう。

Routerの状態がCOMPLETEDでも、成功とは限りません。失敗やキャンセルも終了として扱われるため、エラー情報を確認します。SDKを使う場合も例外処理を用意し、「終了した全件を納品済みにする」集計は避けてください。

送信後に応答を受け取れなかったとき、無条件で新規submitを繰り返すと重複生成につながります。同じ論理要求を再送するために、保存済みの冪等性キーを使います。SDKが自動発行するキーだけに頼ると、別のsubmit呼び出しでは別キーになる点に注意が必要です。

リクエストIDが分かる仕事は、モデルIDと組にして元の処理を照会します。再起動のたびに全件を作り直す設計では、処理量も結果の候補も増えてしまいます。運用画面には「再照会」と「新しく生成」を別の操作として置くと、判断しやすくなります。

最初は一件ずつ処理して保存まで確かめ、その後にアプリ側の同時実行数を増やします。待機列が伸びたことと、生成そのものが遅くなったことを分けて計測してください。受け付けた時刻、実行開始を観測した時刻、結果を保存した時刻があれば、どこで時間を使ったかを説明できます。

状態照会を短い間隔で繰り返しても生成は速くなりません。応答のRetry-Afterなどに従い、レート制限時は待ちます。エラーを隠して即時再送するループは、かえって回復を遅らせます。

キャンセル要求の受付は、実行の停止保証ではありません。既に動いている仕事は完了し、課金される場合があります。キャンセルを押した直後にIDを消さず、最終結果まで追ってから不要な成果物を扱う方針を決めます。

2026年11月8日確認の仕様は公式キューガイドが確認先です。ローカルComfyUIのキュー操作については既存のAPIキュー解説を参照してください。RouterのリクエストIDとローカルのprompt IDは、別の仕組みとして管理します。