音楽ファイルを生成できたことと、映像の音が完成したことは同じではありません。ナレーションのプレビューが聞けたことと、視聴者が要点を理解できることも同じではありません。音声機能を評価する際は、単体出力の成功と、映像上での受け入れを分けて扱う必要があります。
これは公開UIと公開ページの情報を起点にしたブラックボックスQAメモです。内部モデル、処理時間、品質の保証を推測するものではありません。
入力の役割を型で分ける
公開 AI Picture Maker では、音楽とナレーションの入口が分かれています。Create Music では Prompt / Own Lyrics、Instrumental、タイトルが見え、公開ページはムード、スタイル、テンポの方向を含む音楽づくりとプレビューを説明しています。
Create Voice-over の公開情報では、テキスト、声や言語、速度、音量、プレビュー、一般的な音声形式での書き出しが案内されています。
次の型は実装の推測ではなく、レビュー可能な要求にするための提案です。
type MusicRequest = {
kind: 'music';
direction: string;
instrumental: boolean;
cuePurpose: 'intro' | 'explanation' | 'reveal' | 'outro';
expectedDurationSeconds: number;
};
type VoiceRequest = {
kind: 'voice';
script: string;
language: string;
voiceChoice: string;
speed: number;
volume: number;
requiredTerms: string[];
};
生成と承認の状態を区別する
単一の done は、何が終わったのかを曖昧にします。
type AudioState =
| 'input-invalid'
| 'draft-generated'
| 'source-previewed'
| 'synced-to-video'
| 'delivery-previewed'
| 'approved'
| 'revise';
音楽は source-previewed でも、声が入る場面を覆えば revise です。ナレーションは読みが自然でも、固有名詞が不明瞭だったり、映像の切り替わりより先に説明が終わったりすれば synced-to-video を通過できません。
最小の受け入れテスト
| ケース | 観察すること | 失敗時の記録 |
|---|---|---|
| 冒頭の音楽 | 最初の言葉を覆わないか | 声との競合 |
| 商品見せ場の音楽 | 視覚の変化を邪魔しないか | キューのずれ |
| 数字を含む台本 | 数字と固有名詞を聞き分けられるか | 発音または速度 |
| 長い台本 | 句読点が自然な間を作るか | 台本の分割 |
| 最終動画 | スマホ相当の環境で意味が通るか | 音量または構成 |
「音楽がよい」「声が自然」という感想だけでは、次の修正に使えません。どの区間で、どの要件が満たされなかったかを残すと、入力の変更が目的を持ちます。
成果物と一緒に渡す三行
音楽: 冒頭は控えめ、見せ場だけ少し前に出す。
ナレーション: 数字の前後に間を置き、説明部では声を優先する。
確認環境: ヘッドホンとスマホ相当の小型スピーカー。
この記録は、生成された音源を正解のファイルではなく、意図のある判断として次の編集者へ渡します。音楽と声を別々に作っても、最終品質は同じ映像の上で初めて確認できます。