Comfy Routerでモデルを替えるときは、モデルIDだけでなく、入力項目と結果の読み方も変更対象です。アプリの画面から各モデル固有の形式を直接組み立てるより、入力・出力を変換する小さな層を設けると、差し替え時の修正を限定できます。
共通化するのは、アプリの仕事に必要な条件
商品画像の背景案を作るアプリなら、利用者が指定するのは説明文、縦横比、参照画像などです。これをアプリ側の入力として定義し、各モデルが受け取る項目へ変換します。すべてのモデルが同じパラメーターを受け取ると仮定しないことが出発点です。
type ImageTask = {
instruction: string;
aspect: "square" | "landscape";
referenceAssetId?: string;
};
type SavedImage = {
assetId: string;
width: number;
height: number;
};これは自作アプリの型の例であり、Routerへそのまま送る形式ではありません。参照画像の内部IDを外部で使える入力へ変換し、対応するサイズや比率へ写し替える部分をモデル別に用意します。
対応できない条件を、黙って捨てない
あるモデルが参照画像を受け取れない場合、画像指定を落として文章だけ送ると、依頼とは違う仕事になります。未対応の入力は送信前に拒否するか、利用者へ別の方法を選んでもらいます。「生成に成功した」だけで、元の依頼を満たしたとは判断できません。
| 項目 | 変換層の責任 |
|---|---|
| 縦横比 | モデルで使える指定へ変換する |
| 参照画像 | 対応形式と入力数を確認する |
| モデル固有の調整値 | 未指定時の扱いを決める |
| 非対応の入力 | 送信せず理由を返す |
結果はunknownから検証して取り出す
公式仕様では、Routerの結果はモデル固有で、共通の画像配列へ統一されていません。JSONとは限らず、出力スキーマが整備されていない場合もあります。型を強制変換するだけでは実際の応答を検査したことになりません。
アダプターは、期待する項目の存在と型、メディア形式を確認してから保存処理へ渡します。想定外の応答を空の画像一覧に変えて成功扱いするより、モデルIDと応答の概要を残して失敗として扱う方が調査できます。ログにはキーや個人情報を含む入力を丸ごと残さないようにします。
スキーマは版と一緒に保存して比較する
モデルのOpenAPI文書で入力と出力を確認できます。ただし、入力の検証と出力の保証は別です。文書上の型があることを理由に、実行結果の確認を省略しないでください。
採用したスキーマと取得日を記録し、更新時に差分を読みます。テスト用の入力は、通常の一件だけでなく、参照画像なし、非対応の比率、結果項目が欠けた応答などを含めます。実APIへ何度も送らず、保存した応答例で変換層を検査できる構成にすると調査しやすくなります。
モデル変更の合格条件を先に決める
新モデルの採用は、コードが通ったことに加え、アプリの用途を満たすかで判断します。商品全体が残るか、指定比率で保存できるか、処理時間が運用に合うかを、同じ課題で比較します。画質や速度の優劣を測っていない段階では、互換対応と品質評価を別の進捗として残してください。
スキーマと結果形式の確認先は公式のモデルスキーマガイドです。まず一つのモデルで変換層を作り、二つ目を追加した際に画面側のコードを変えずに済むか確かめます。