テンプレート型画像生成UIの要件定義とテスト設計
この記事は、公開されているゲーム向け画像生成ページを例に、テンプレート選択、素材入力、生成、レビュー、書き出しを要件へ分解する方法を整理したものです。対象サービスのソースコードや内部APIを解析したものではありません。コード内のセレクタと契約は説明用です。
1. テンプレートを入力スキーマとして定義する
公開されている Minecraft thumbnail ページには、Hardcore 100 Days、PVP、Redstoneなどのテーマと、文字、スキン、モブ、環境を調整する流れがあります。
テンプレートごとに必要な入力が違う場合、背景画像だけでなくスロットの集合として定義します。
| スロット | 入力例 | 検証 | 失敗時の扱い |
|---|---|---|---|
| headline | 短い文字列 | 空文字・最大長 | 入力位置へ戻す |
| skin | 画像または識別子 | 形式・容量 | ほかの入力を保持 |
| mob | 選択または自由記述 | 対応値 | 候補を提示 |
| environment | biome・lighting | 対応値 | 既定値を明示 |
| ratio | 16:9・9:16 | テンプレート対応 | 選択不可を表示 |
2. 状態ごとの完了条件を決める
isLoading だけでは、アップロード中、生成中、書き出し中を区別できません。少なくとも choosingTemplate / editingBrief / uploadingAsset / generating / reviewing / recoverableError / exporting を分けます。
Thumbs.ai の公開サイトには、作成や再構成に関する複数の入口が示されています。入口が増えるほど、テンプレート変更時の入力保持、戻る操作、再試行の契約を明文化する必要があります。
3. 破壊的な遷移をテストする
テンプレート変更でスロットが変わる場合、互換入力は保持し、非互換入力は削除前に通知します。生成失敗時にブリーフを消さないことも重要です。
以下は説明用の Playwright 例です。実際のDOMセレクタや文言ではありません。
import { test, expect } from "@playwright/test";
test("keeps compatible values when the template changes", async ({ page }) => {
await page.goto("/illustrative-game-thumbnail-editor");
await page.getByRole("button", { name: "Hardcore template" }).click();
await page.getByLabel("Headline").fill("100 DAYS");
await page.getByRole("button", { name: "Survival template" }).click();
// Illustrative contract: both templates support the headline slot.
await expect(page.getByLabel("Headline")).toHaveValue("100 DAYS");
});
4. 最小受け入れテスト
- テンプレート名と選択状態が支援技術へ伝わる。
- 必須スロット不足時に生成できない。
- 非互換入力を削除する前に通知される。
- アップロード、生成、書き出しの失敗を区別できる。
- 失敗後もテンプレートと入力が保持される。
- 0件、1件、複数件、部分成功で候補一覧が破綻しない。
- 候補選択をキーボードで操作できる。
- 比率選択が書き出し契約へ反映される。
- 再生成前の候補へ戻れるかどうかが明示される。
5. 自動化と人手レビューを分ける
自動化できるのは状態遷移、入力検証、アクセシビリティ名、ファイル形式、寸法などです。スキンの再現、画像内文字、アイテムの形、ゲーム内容との一致、他制作者への過度な類似は人手で確認します。
クリック率はトピック、タイトル、チャンネル、公開タイミングにも左右されます。画像生成UIの受け入れテストで成果を保証してはいけません。ライセンスや出力条件も現在の規約を別途確認します。
まとめ
テンプレート型生成UIでは、テンプレートをスロットの契約として扱い、入力保持と失敗復旧を状態ごとに定義します。生成結果だけでなく、変更しても戻れること、何が失われるか分かることが信頼できる編集体験につながります。