マルチモデル生成UIの要件定義：入力契約とレビュー状態を分離する
AI生成UIでは、モデル選択・プロンプト・ファイル添付を一つのフォームにまとめがちです。しかし、台本から動画を作る場合と、文字入りの静止画を作る場合では、入力の意味も受け入れ条件も異なります。VideoAIのように複数の入口を持つサービスを考えると、この差を要件として明示する必要があります。本稿は公開情報から整理した設計・テストメモであり、内部実装や実測性能の解説ではありません。
先に入力契約を決める
モデル名を中心にすると、利用者は「何をアップロードすればよいか」を後から考えることになります。先に素材の種類を定義すると、画面の必須項目とレビュー項目を分けやすくなります。
| 入力契約 | 例 | 守る対象 | 主なレビュー |
|---|---|---|---|
| script | 台本、場面の順番 | リズム、出来事 | シーンの連続性 |
| subject-reference | 人物、商品、場所 | 同一性 | 見た目の維持 |
| footage | 既存動画 | 動き、編集意図 | 変更範囲 |
| image-brief | 文言、構図、色 | 文字、情報の優先順位 | 小サイズでの可読性 |
Seedance 2.5 は、文章や画像、複数の参考素材から連続した動画を作り、局所的な修正へ進むワークフローとして整理できる。Wan 2.7 は台本・静止画・人物参照・既存動画を入口にし、音声や環境音を映像と同時に確認する契約を持つ。Flux 2 Pro は、文字を含む長い画像ブリーフ、参考画像、生成後のプロンプト編集という静止画向けの確認軸になる。
上記は公開説明をUI要件へ翻訳した設計案で、各サービスのAPI型を示すものではありません。
レビュー理由を状態に残す
生成が成功したかだけでは、次に何を直すべきか分かりません。理由を別の値として残すと、再生成の操作とテストが具体化します。
type ReviewReason = "continuity" | "audio" | "identity" | "copy" | "composition";
type Candidate = {
id: string;
status: "queued" | "review" | "needs-revision" | "accepted";
reasons: ReviewReason[];
};
たとえば動画の場面がつながらない場合は continuity、セリフや環境音を確認する場合は audio、画像の見出しが読めない場合は copy を使います。これは実装済みのレスポンスではなく、画面とQAで共有する語彙の例です。
最小限のテストケース
- 入力種別を切り替えたとき、不要な項目が残らない。
- 参考素材に付けた役割が、再生成後も保持される。
- 動画のレビューで音声と画面を別々に確認できる。
- 画像のレビューを実表示サイズで行える。
- 受け入れ前に、権利・人物・ブランド文言の確認を促せる。
Playwrightで自動化する場合も、未検証のセレクタや出力件数を固定値として扱わない。まずは入力契約の切り替え、レビュー理由の保存、再試行時の参照順序をテスト対象にする。
まとめ
複数モデルのUIで重要なのは、一つのプロンプト欄に機能を詰め込むことではありません。「何を渡すか」「何を残すか」「何を見て採用するか」を同じ状態モデルで追えることです。モデルの追加にも耐えやすく、ユーザーの修正理由も記録できます。