AIキャラクター制作の要件定義：画像と音声の割り当てを分けてテストする
AIキャラクターの制作画面では、画像生成と音声選択を同じ「完成」状態として扱いたくなります。しかし、画像だけレビュー済み、声だけ試聴済み、画像を更新したので組み合わせは未確認、という状態は珍しくありません。
この記事では、画像と音声を別の状態として持ち、最後に組み合わせを確認するための要件を整理します。特定の内部実装や出力品質を前提にせず、UIとQAの境界に絞ります。
要件を三つの層に分ける
まず、キャラクターを次の三層に分けます。
| 層 | 例 | 確認すること |
|---|---|---|
| Visual identity | 髪型、色、衣装、小物 | revision間で残す特徴 |
| Scene variation | 背景、ポーズ、光、画角 | 今回だけ変える要素 |
| Voice assignment | voiceId、ラベル、選定理由 | 台本と役割に合うか |
画像と説明から再利用可能な人物像を作る AI Character Generator のような用途では、プロンプト全文をアイデンティティの代わりにしない方が扱いやすいです。保存対象は、安定させたい特徴と、場面ごとに変更する特徴を分けます。
ホームの PhotoGenerator AI から制作機能へ進む場合でも、生成、保存、レビューを別イベントとして設計すると、再編集時の説明が明確になります。
TypeScriptで状態を表す
type Review = "empty" | "draft" | "needs-review" | "ready";
type Character = {
revision: number;
referenceUrl?: string;
identityNotes: string;
visualReview: Review;
voiceId?: string;
voiceReview: Review;
};
const isPairReady = (item: Character) =>
item.visualReview === "ready" &&
item.voiceReview === "ready" &&
Boolean(item.voiceId);
画像のrevisionが変わったとき、visualReview は needs-review に戻します。以前のvoiceIdを消す必要はありませんが、組み合わせ全体を再確認するフラグは必要です。
音声は試聴と割り当てを分ける
候補を探す Voice Library では、ナレーションやソフト、ドラマチックなどの分類を検索の入口にできます。ただし、試聴したことと、キャラクターへ割り当てたことは別の操作です。
割り当て時には、voiceId と選定理由を保存します。「初心者向けなので落ち着いたテンポ」「字幕に合わせて明瞭な発音」などの短文で十分です。カタログから候補が利用できなくなった場合も、再確認対象を特定できます。
QAで確認する遷移
最低限、次のケースを自動テストまたは手動チェックに入れます。
- 画像だけ保存した場合、次の行動が音声選択として表示される。
- 新しい画像revisionを作ると、全体のready表示が維持されない。
- 試聴中に別候補をクリックしても、保存済みのvoiceIdが即時に変わらない。
- 音声候補が消えた場合、画像側を利用可能なまま、ペアだけ保留にできる。
- リロード後もrevision、voiceId、レビュー状態が一致する。
Playwrightのイメージなら、次のように「ラベル」と「次の行動」を検証します。
await expect(page.getByText("Needs review")).toBeVisible();
await expect(page.getByRole("button", { name: "Assign voice" })).toBeEnabled();
await page.getByRole("button", { name: "Assign voice" }).click();
await expect(page.getByText("Voice assigned")).toBeVisible();
成功トーストだけを確認すると、リロード後に状態が消える問題を見逃します。保存後の表示と、失敗時の次の行動まで確認するのがポイントです。
ペアでレビューする
最終カードには、基準画像、identity notes、声のラベル、代表台本を並べます。画像だけ見るとよい、声だけ聞くとよい、という二つの合格が、組み合わせでは違和感になることがあるためです。
また、肖像、声の利用、商用利用、再配布などの条件は、UIのready状態とは別に確認します。サービスや投稿先の仕様は変わる可能性があるため、公開直前に最新情報を確認する運用にします。
画像と音声を別の入力として管理し、最後に一つのキャラクター体験としてレビューする。この分解は、制作機能が増えたときにもテスト範囲を説明しやすくします。