AI広告動画の生成フローをテスト可能な要件へ分解する

本稿は、Nextify の公開ページから読み取れる操作フローをもとにした、要件・テスト設計の例です。特定サービスのソースコード、API、DOMセレクタ、生成性能を分析したものではありません。目的は、画像やプロンプトから広告動画を作るUIで「生成できた」と「配信候補として確認できた」を分けることです。

まず、二種類の完了を区別する

生成処理が完了してプレビューが返ることは、技術的な完了です。一方、商品情報が読めるか、演出が商品の事実を損ねていないか、広告文が根拠を超えていないかを確認することは、運用上の完了です。この二つを同じ success にすると、後者のレビューが画面設計から抜け落ちます。

公開中の Video Commercial Maker は、UGCスタイルまたは商品デモのテンプレートを選び、参照画像またはテキストプロンプト、アスペクト比、品質などを設定し、生成後に Remix で調整する手順を示しています。この説明を要件に落とすなら、生成条件と改訂履歴を候補に紐付けるのが最小条件です。

要件を入力・生成・レビューに分ける

領域	保持する情報	受け入れ条件
brief	商品、オファー、掲載面、根拠	必須項目の不足を生成前に示せる
generation	テンプレート、素材、プロンプト、比率、品質	生成した候補から入力条件を確認できる
variation	変更軸、候補数、親候補	何を比較するかを候補ごとに追跡できる
review	商品表示、表現、媒体適合、差し戻し理由	生成成功とは別に人の判断を記録できる

公開ページの AI Marketing Content Generator は、広告テンプレートまたは商品コンセプトを選び、プロンプト、解像度、アスペクト比、変体数を設定してから、生成・調整・ダウンロードする流れを案内しています。変体数は単なる数値ではなく、レビューのキューを増やす入力です。そのため、候補数を増やした時点で未確認数も表示する設計が望ましいです。

状態と不変条件を先に置く

// 公開実装ではなく、要件議論用の最小モデル
type CreativeCandidate = {
  id: string;
  parentId?: string;
  briefId: string;
  changeAxis: "hook" | "scene" | "script" | "ratio";
  settings: { template: string; aspectRatio: string; quality?: string };
  review: "pending" | "needs-fix" | "approved" | "rejected";
};

この型に対して、次の不変条件を定義します。

• briefId がない候補は生成キューへ入れない。
• 比較目的のバッチでは changeAxis を一つ選ぶ。
• Remixは既存候補を更新せず、新候補に parentId を付ける。
• review が approved でない候補を配信候補として一括出力しない。

これにより、入力が同じ二本を別案と誤認したり、差し戻し理由が消えたりする問題を減らせます。

テストケースを画面の約束にする

ID	操作	期待結果
T01	商品briefなしで生成する	不足入力を表示し、入力済み設定を保持する
T02	変化軸を選ばず比較バッチを作る	比較用としては開始できない
T03	縦型比率で候補を生成する	候補に指定比率と元素材の参照が残る
T04	Remixでフックだけ変更する	元候補と新候補が別レコードで結び付く
T05	レビュー未完了の候補を出力する	人手確認が必要であることを示す

Playwrightで表すなら、セレクタを推測せず、画面上の意図を先に書きます。以下のラベルは未検証の例です。

test("comparison batch needs one change axis", async ({ page }) => {
  // Labels are illustrative; verify them against the actual UI.
  await page.getByLabel("product brief").fill("New product launch");
  await page.getByRole("button", { name: /generate/i }).click();
  await expect(page.getByText(/change axis|required/i)).toBeVisible();
});

自動化しない判断を明示する

入力必須、候補数、状態遷移、親子関係は自動テストの対象にしやすい一方、商品ラベルの正確さ、人物表現の権限、誇張された便益、掲載媒体の規約適合は人の確認が必要です。画面にレビューを置く理由は、生成AIを疑うためではなく、判断責任を見えなくしないためです。

まとめ

広告動画UIでは「生成可能」を完了条件にしないことが重要です。brief、生成設定、変更軸、レビューを別のデータとして残せば、候補は単なる動画ファイルではなく、検証可能な実験になります。実装では状態の遷移をテストし、最終的な広告表現と配信判断は人手レビューに残してください。