音楽トラックが生成されたことと、動画の音声が完成したことは同じではありません。台本が音声になったことと、聞き手が内容を理解できることも同じではありません。音声系のUIでは、生成成功を最終成果の承認と混同しない状態設計が重要です。
これは公開画面の情報を起点にしたブラックボックスのQAメモです。モデル、内部処理、処理時間、品質を推測するものではありません。
観察できる入力を分ける
公開 VEME の音声ツールでは、音楽とナレーションの入口が分かれています。Create Music には Prompt / Own Lyrics、曲の説明、Instrumental、タイトルが表示され、公開ページはスタイルと長さの選択、プレビュー、書き出しを案内しています。
Create Voice-over にはテキスト、声、速度、感情が表示されます。公開ページは台本からナレーションへ変換し、トーンとテンポを調整し、プレビューと書き出しを行う流れを説明しています。
この違いを、提案する型で明示します。
type MusicRequest = {
kind: 'music';
prompt: string;
instrumental: boolean;
targetDurationSeconds: number;
cuePurpose: 'intro' | 'transition' | 'product-reveal' | 'outro';
};
type VoiceRequest = {
kind: 'voice';
script: string;
speed: number;
emotion: string;
requiredWords: string[];
voicePermissionConfirmed: boolean;
};
これはサイトの実装ではなく、入力の違いをレビュー可能にするための提案です。
完了状態を細かく定義する
generated を一つだけ置くと、音源単体の成功と映像上の成功が区別できません。
type AudioReviewState =
| 'input-invalid'
| 'draft-generated'
| 'source-previewed'
| 'synced-to-video'
| 'delivery-previewed'
| 'approved'
| 'revise';
たとえば音楽は source-previewed を通っても、映像の切り替わりと合わなければ synced-to-video には進めません。ナレーションは自然に聞こえても、固有名詞が聞き取れない、画面上の説明より早い、といった理由で revise になります。
最小テストマトリクス
| ケース | 入力 | 期待する観察 | 失敗時の記録 |
|---|---|---|---|
| 冒頭用の音楽 | 短い導入の役割 | 最初の台詞を覆わない | 声との競合 |
| 見せ場用の音楽 | 強調するカット | 映像の切り替わり後に変化が来ない | キューのずれ |
| 数字を含む台本 | 速度と感情を指定 | 数字と固有名詞を聞き分けられる | 発音または速度 |
| 長い一文の台本 | 改行と句読点を変更 | 息継ぎが意味を壊さない | 台本の分割 |
| 認識可能な声 | 権限情報あり | 用途と表示の条件が確認できる | 承認不足 |
最後のケースは音質試験ではありません。本人の声または認識可能な声を使う場合は、用途に対する適切な許可を確認し、なりすましや誤解を招く用途に使わないことが前提です。
受け渡し情報を成果物に添える
最終ファイルだけを渡すと、次の編集で理由が失われます。短いメモを添えます。
音楽: 0〜3秒は控えめ、製品カットで上げる。
ナレーション: 数字の前後に間を置く。説明部では声を優先。
確認環境: スマホスピーカーとヘッドホン。
この三行があれば、再編集する人は音源を「正解のファイル」としてではなく、意図のある判断として扱えます。音楽とナレーションを別々に生成しても、最終的な品質は映像と合わせて初めて評価できます。