本稿は公開されている画面・説明をもとにした要件定義とテスト設計の例です。内部実装、モデル構成、API、品質、処理時間を確認したものではありません。ここでの型、画面、テストケースは類似した生成UIを設計するための提案です。

問題：同じ出力形式でも、利用者の目的は異なる

人物らしい画像や動画を作る機能は、画面上では「人物を選ぶ」「プロンプトを書く」「生成する」という似た操作に見えます。しかし、実務では少なくとも二つの目的を分ける必要があります。

一つは、継続して使うキャラクターや外見を作ることです。公開されている AI Avatar Generator は、テキストまたは写真を起点に、写実的、3D、アニメ風などの見た目を選べる例です。このモードでは、外見の一貫性、参照画像、利用許可、掲載先での見え方が中心になります。

もう一つは、特定の情報を説明する案内役を作ることです。AI Digital Human Generator の公開説明では、役割、画角、場面、台本、言語、出力比率などが扱われています。このモードでは、人物らしさだけでなく、台本の事実、発音、字幕、ローカライズ、画面構成を確認する必要があります。

同じ生成ボタンを共有しても、二つの目的を同じ承認フローに入れると、確認漏れが起きやすくなります。

要件：生成前の契約を明示する

生成UIは、入力値だけでなく「何を承認するか」を表現します。次のような判別可能な型を置くと、必須項目とレビュー項目をモードごとに変えられます。

type Review = "not_started" | "pending" | "approved" | "rejected";

type PersonBrief =
  | {
      mode: "avatar";
      style: "photorealistic" | "3d" | "anime";
      appearancePrompt: string;
      referenceAssetIds: string[];
      likenessReview: Review;
    }
  | {
      mode: "digital_human";
      role: "trainer" | "host" | "guide" | "custom";
      scriptRevision: number;
      locale: string;
      framing: "close" | "bust" | "full";
      messageReview: Review;
    };

この区別は表示上のラベルだけではありません。avatar では写真・外見・権利の確認が必要になり、digital_human では台本・言語・表示内容の確認が必要になります。

要件：生成結果は入力スナップショットに結びつける

非同期処理では、生成中に利用者が台本や言語を変更できます。完成した結果を現在のフォームへ直接ひも付けると、古い入力から作られた動画が最新の設定に見えてしまいます。

type GenerationAttempt = {
  id: string;
  briefSnapshot: PersonBrief;
  state: "queued" | "running" | "succeeded" | "failed";
  outputIds: string[];
  createdAt: string;
};

入力が変わったら、以前の出力を削除する必要はありません。ただし、stale と表示し、新しい契約での承認を引き継がせないことが重要です。同じスナップショットでの再試行と、新しい入力での再生成も別の試行として記録します。

状態表：出力完了と公開承認を分ける

状態	意味	次に必要な確認
Draft	入力を編集中	必須項目、参照素材
Ready	契約がそろった	生成開始前の確認
Generated	出力ファイルがある	事実、権利、字幕、発音
Reviewing	人が確認中	修正または承認
Approved	配布可能と判断	チャンネル固有の公開操作
Stale	上流入力が変更された	再生成または再確認

Generated は「ファイルがある」という事実であり、「正しい」「公開可能」という結論ではありません。人物の似姿、体験談に見える表現、商品情報、広告表示、各プラットフォームの規約は、生成後に人が確認する領域です。

テスト観点：UIの見た目ではなく遷移を確認する

以下の表は、Playwright 等で自動化する場合の観点です。セレクタや実際の画面要素は未確認なので、あくまで要件例として扱います。

ケース	操作	期待結果
台本変更	生成中に台本を編集	古い応答が最新結果を上書きしない
写真変更	アバターモードで参照を差し替え	依存出力が Stale になる
言語変更	案内役の locale を変更	台本・字幕レビューを再要求する
モード切替	avatar から digital_human へ変更	必須項目と承認項目が切り替わる
再試行	同じ入力で再実行	同一スナップショットの別 Attempt になる
公開準備	Generated のまま配布を選ぶ	未完了レビューを明示する

// 画面固有のセレクタではない、状態遷移の擬似テスト
expect(markStaleWhenScriptChanges(attempt, nextBrief)).toBe(true);
expect(canDistribute({ state: "generated" })).toBe(false);
expect(canDistribute({ state: "approved" })).toBe(true);

まとめ

UGCVideo.ai は、アバター作成と役割を持つデジタルヒューマンという近接した公開ワークフローを考えるための例です。実装を推測するのではなく、利用者の目的と確認責任を分離して設計することがポイントになります。

生成機能の価値は、出力数を増やすことだけではありません。どの入力版から作られ、何を確認し、どの状態なら配布できるのかを追跡できることが、チームで安全に使えるUIにつながります。

Tags

要件定義 テスト フロントエンド QA UI