Comfy Routerで呼び先を選ぶときは、現在のカタログにあるprovider/model形式のIDを確認します。似た名前のモデルでも、対応する入力や結果形式が同じとは限りません。障害時に別の呼び先へ移す場合も、単に文字列を置き換える前に、入力と実行状態を確認してください。
発表時の例と、現行APIの指定方法を混ぜない
2026年9月の発表にはSDKのprovider引数で呼び先を選ぶ例がありました。一方、11月8日に確認したHTTP APIの案内では、カタログのidを呼び出しパスへ入れます。使うSDKの版とHTTP APIの契約を確かめず、異なる時点のコードをつぎ足さないようにします。
まずモデル一覧か個別モデルのページを確認し、実際に呼び出せるIDを記録します。現在の呼び先を知る目的なら、アプリが送信したIDと、返ってきたリクエストIDを対にして残すと追跡できます。
呼び先を比較する表は、価格だけにしない
| 比較項目 | 確認する理由 |
|---|---|
| 対応するモデルの版 | 同じブランド名でも異なる能力を比較しないため |
| 画像・動画などの入力形式 | 今のアプリの入力をそのまま渡せるかを見るため |
| 返り値と保存期限 | 結果を取り出すコードと保存処理が変わるため |
| 単価・課金単位 | 一回、秒数、解像度などの条件をそろえるため |
| 待ち時間・失敗時の扱い | 利用者へ約束できる動作を決めるため |
同じ商品画像を作る比較なら、入力画像、指示、出力サイズをできるだけそろえます。採用できる画像が何枚できたかも残すと、表示単価だけでは見えない修正負担を考慮できます。測っていない呼び先を「最速」「最安」と決める必要はありません。
現行の同期APIは自動フォールバックの設定も確認する
2026年11月8日のAPIリファレンスでは、同期呼び出しのfallback_providerは省略時に有効です。無効にする値はfalse。成功時のX-Comfy-Router-Fallback-Providerで切り替え先を確認できます。キュー経由のsubmitには、この自動切り替えはありません。初期発表だけを根拠に「常に同じprovider」と考えないでください。
別の提供経路はmodel_providerで指定します。対応先はモデル詳細で確認します。入力変換の有無はstrict_modeで変わり、変換時に落ちた項目はX-Comfy-Router-Dropped-Paramsに示されます。BYOK・multipart編集・strict modeではフォールバックが働かないため、通常のテキスト入力と同じ前提で設計しないようにします。
入力の形式が誤っている場合は、送信先を変えても解決しない可能性があります。また、通信が切れたことは、生成が始まっていない証拠ではありません。元の処理が動いているまま別経路へ送れば、二つの生成が成立することがあります。
再送と別の生成を、台帳上でも分ける
同じ要求を再送する場合は、冪等性キーと入力を維持します。providerや入力を変える場合は別の実行として記録し、元の実行IDとの関係を残します。以下はアプリ側で持つ記録の例です。Routerへそのまま送るJSONではありません。
{
"task_id": "product-photo-0042",
"attempt": 2,
"reason": "operator_selected_another_route",
"previous_request_id": "saved-request-id",
"input_hash": "sha256-of-normalized-input"
}「元の処理の結果を取り直す」のか「別の生成を注文する」のかが分かれば、結果が遅れて届いても採用版を選べます。利用者には同じ一件に見えても、運用側では試行を消さずに追える設計にしてください。
呼び先・入力変換・フォールバックの条件は現行の公式APIリファレンスで確認できます。価格比較では、最初の見積もりと実際に処理した経路を別々に記録しておくと、想定との差を調べやすくなります。