生成が終わってURLが返ってきても、成果物を長く使える状態になったとは限りません。Comfy Routerを制作工程へ組み込むなら、生成結果を受け取った後に、自分で管理する保存先へ回収する工程を用意します。URLの保存と、画像・動画そのものの保存を分けて考えましょう。
処理結果の保持期限と、ファイルURLの期限は別
2026年11月8日に確認したキュー仕様では、終了したリクエストの結果は24時間保持され、期限後の取得は410となります。一方、結果に含まれるメディアURLは、別の期限で失効する可能性があります。「24時間以内なら、どのURLも必ず開ける」とは解釈できません。
たとえば夜間に生成し、翌日の担当者が確認する運用では、担当者の操作を待たずに保存まで自動で済ませます。人が確認するのは自分の保存先にあるファイルにすれば、作業開始時刻の違いで成果物を失う事態を減らせます。
返り値はモデルごとの契約として扱う
Routerの出力は、全モデル共通の画像配列に統一されているわけではありません。JSONの中にURLが入るモデルもあれば、バイナリで返る場合もあります。モデルを変更する際は、生成入力だけでなく結果を取り出す処理も確認してください。
| 受信したもの | 保存前の確認 |
|---|---|
| JSON | 対象モデルの出力スキーマに沿って成果物を取り出す |
| URL | 取得成功とContent-Type、想定するファイル内容を確認する |
| バイナリ | 応答形式と拡張子を対応させ、途中で切れていないか確認する |
すべての応答をimages[0].urlで読むような処理は、モデルを切り替えたときに壊れます。モデル別の小さな取出し関数を作り、後段には「保存対象の一覧」を渡す構成なら、変更の影響を限定できます。
保存の完了は、書き込めたことまで確認する
- 受付IDとモデルIDから、元の処理の結果を取得する。
- 成功結果の形式を確認し、必要な成果物を取り出す。
- 一時保存先へダウンロードする。
- サイズや形式を確認して、正式な保存先へ移す。
- 業務ID、保存先、保存日時、チェックサムを記録する。
保存先の容量不足やネットワーク切断も起こり得ます。生成の成功フラグだけで処理を完了にせず、保存失敗だけをやり直せるようにします。データベースに保存先を記録する前にファイルを確定させるなど、途中停止しても未完成ファイルを納品しない順番を選んでください。
失敗時は「再取得」から始める
ダウンロードが失敗しただけなら、まず既存の結果をもう一度取得します。新しい生成を送る必要はありません。リクエストIDを失っていると、保存の失敗が生成のやり直しへ広がるため、IDは完了後もしばらく保持する設計が役立ちます。
URLが失効したときも、結果の再取得で新しいURLが必ず発行されるとは仮定しないでください。保持期限を過ぎ、保存済みファイルもない場合は、元の成果物を回収できない可能性があります。再生成は同じ見た目になる保証のない別の仕事として、利用者に説明できる状態にします。
運用の確認は、生成件数より未保存件数を見る
日次の確認項目には「生成成功・保存未完了」「最後の保存失敗からの経過時間」「保存先の空き容量」を入れます。成功件数だけが増えていても、実ファイルが回収できていなければ制作は進んでいません。完成品と一時素材の保存期間も分けておくと、後から整理しやすくなります。
結果保持の条件は公式キュー仕様を確認してください。本記事は保存工程の設計例であり、特定ストレージへの接続を実測した記録ではありません。