AI広告バッチUIの要件定義：商品事実と変化軸を分離してテストする

本稿は、Nextify の公開ページの操作説明から組み立てた要件・テスト設計の例です。特定サービスのソースコード、内部API、DOMセレクタ、生成性能を分析したものではありません。実装がない段階でも、AI広告UIを「比較できる制作フロー」として定義するためのチェックリストを示します。

問題を二つの責務に分ける

広告バッチには、商品そのものを正しく見せる責務と、訴求の差分を試す責務があります。両者を一つのプロンプト欄に混ぜると、生成後に何を確認すべきかが分からなくなります。

公開されている Ad Creative Variation Generator は、listing image または avatar-led product video のワークフローを選び、数量と variation focus を設定する流れを案内しています。AI Packshot Generator は、商品写真を入力し、背景・照明・構図を指定してから生成結果を確認する流れです。

責務	入力	固定する条件	主な受け入れ条件
商品事実	商品写真、ラベル、色、形状	商品名、表示、物理的特徴	誤認を招く変形を承認前に発見できる
Packshot演出	背景、表面、照明、構図	商品事実	影・光・比率が新しい環境と矛盾しない
バリエーション	フック、シーン、画像役割、話者	商品とオファー、基本形式	変更軸と数量を候補ごとに追跡できる

状態と不変条件を定義する

// 公開実装の型ではなく、要件議論用の最小モデル
type CreativeBatch = {
  source: { kind: "phone-photo" | "white-background"; assetId: string };
  productFacts: { labelChecked: boolean; colorChecked: boolean; shapeChecked: boolean };
  direction: { background: string; light: string; surface: string };
  changedVariable: "hook" | "scene" | "proof" | "image-role" | "presenter";
  quantity: number;
  status: "draft" | "generated" | "review" | "approved" | "rejected";
};

最低限、次の不変条件を置きます。

• productFacts の確認前に承認へ進めない。
• changedVariable が未設定の候補は、比較用バッチに含めない。
• 再生成は既存候補の上書きではなく、新しい候補と変更記録を作る。
• 数量は生成前に表示し、レビュー可能な量を超える場合は警告する。

さらに、状態遷移の境界をUI上で見えるようにします。generated は処理が終わった状態であって、商品表示が正しい状態ではありません。review では、入力写真と生成結果を左右に置き、変化軸以外の条件が変わっていないかを確認します。rejected にした場合も、理由を「ラベル不鮮明」「影が不自然」「訴求が過剰」のように選択または記入できるようにします。理由が残れば、次のバッチで同じ失敗を繰り返しにくくなります。

数量設定にも受け入れ条件が必要です。たとえば画像タイプ別の数量合計が指定総数と一致しない場合、生成ボタンを有効にしない。動画の候補数を増やした場合は、レビュー一覧がページ送りやフィルタを持ち、どの候補が未確認かを分かるようにする。作れる数と確認できる数を同じ値として扱わないことが、運用上の重要な境界です。

テストケース

ID	操作	期待結果
T01	商品写真なしで生成を押す	不足入力を示し、入力済みの brief を保持する
T02	背景と照明を指定して生成する	packshot のレビュー項目が表示される
T03	変化軸なしでバッチを作る	比較テストには保存できない
T04	同じ brief で scene だけを変更する	元候補と差分メモが別レコードになる
T05	ラベルが不鮮明な候補を承認する	人手確認が未完了であることを示す

Playwrightで表すテスト意図

以下のラベルとセレクタは未検証のため、実装契約ではなくテスト意図の例です。

test("variation axis is required before batch generation", async ({ page }) => {
  // Labels are illustrative; verify them against the real UI.
  await page.getByLabel("product photo").setInputFiles("sample.png");
  await page.getByRole("button", { name: /generate batch/i }).click();
  await expect(page.getByText(/variation focus|required/i)).toBeVisible();
});

QAの境界

背景除去やリライトが成功しても、商品ラベルや素材表現の正確さ、広告ポリシー適合、クリック率は自動的には保証されません。レビュー画面では、生成物だけでなく入力写真、固定した商品事実、変更軸、配置先を並べるべきです。これにより「きれいだから採用」ではなく、「どの仮説を確認した結果か」を記録できます。

自動テストと人手レビューの責務も分けます。入力必須、数量計算、状態遷移、候補の上書き防止は自動化しやすい一方、商品が別物に見えないか、照明が素材感を誤認させないか、広告文が根拠を超えていないかは人が判断します。テスト計画にこの境界を書いておけば、画像比較の自動化だけで品質保証したと誤解しません。

まとめ

AI広告生成UIの要件は、生成ボタンの成功条件だけでは足りません。商品事実、packshot演出、バリエーションの変化軸を分離し、候補の状態と変更理由を保存することで、制作物を比較可能なテスト単位にできます。最終的な商品表示と配信判断は、人間の承認と実環境の測定に残してください。