架空の人物の声を、文章から作る
AIキャラクターの声を選ぶ仕事は、聞き心地だけで終わらない。固有名詞をどう読むか、同じ台本で尺がどれだけ動くか、動画に組み込んだときに音量や字幕が合うかまで確認する必要がある。Gemini 3.8 Flash TTSのVoice Designを試したイノベトピアの記録は、この制作上の違いを具体的に示す。
同媒体の9月26日の記事では、文章で声を設計し、同じ原稿を3回生成して比較した。本稿はその観察と公式資料に基づく解説であり、AI最前線が音声を生成したり、Gemini APIを実行したりしたものではない。料金や操作の結果も、元記事の筆者の当時の環境の記録として扱う。
設計する声と、複製する声は別の入口
GoogleのVoice Design資料は、声質、年齢、アクセントなどを言葉で指定し、新しい話者を作る機能を説明する。短い録音から既存の話者を複製する機能とは異なり、実在の人物の録音を用意しなくても声を設計できる。
元記事の筆者は、架空のキャラクターに従来使っていた音声合成モデルを、そのまま複製する方法を選ばなかった。声の持ち主本人による同意録音を用意できないためだ。既存モデルを利用できることと、その声を別の仕組みで複製してよいことは、同じ許可ではない。
これは制作側が先に考えたい点でもある。キャラクターの設定を持っていることだけで、そのキャラクターに付けていたすべての音声の権利を持つとは限らない。新しい声を設計する場合も、特定の実在人物を装う指示や、その人の出演と誤認させる見せ方を避ける必要がある。
声の特徴と、その場の演技を分ける
公式資料は、恒常的な声の特徴を設計へ書き、場面ごとの感情や話し方は短いスタイル指示へ分ける考え方を示す。落ち着いた声質のキャラクターでも、驚く場面や小声で話す場面はある。毎回すべてを書き直すより、声の軸と演技を分けたほうが、管理もしやすい。
設計を文章にするときは、矛盾する形容を重ねすぎないことが大切だ。低く重い声と、非常に軽い高音を同時に求めるような指示では、どの特徴を優先するかが曖昧になる。用途、音域、明瞭さ、速さなど、比較できる要素で説明したい。
元記事では、日本語の説明から複数の候補が作られ、最後は筆者が聴いて選んだ。候補ができる速さは、声の品質を確かめる時間の代わりにはならない。短い試聴文だけでなく、実際の用途に近い原稿で確認することが重要になる。
声がそろっても、時間はそろわない
記事の比較原稿は311字で、読み間違えやすいサービス名や数字を含むものだった。Geminiで作った3回の長さは55.40秒、57.20秒、53.64秒。比較したAivisSpeechの音声は57.64秒だったと記録されている。
筆者には同じ声として聞こえても、最長と最短には数秒の差があった。間の取り方も変わる。これは、一度作った字幕の時刻を、同じ台本の別の音声へそのまま使えない場合があることを示す。ただし、3回という小さな試行を、製品全体のばらつきの保証値として使うことはできない。
編集部の考察では、固定尺の動画は音声が確定してから字幕を合わせるか、修正を吸収する余白を持つ構成がよい。字数から秒数を見積もる方法は下書きには使えても、公開版の長さを保証しない。最後の一文を速く押し込むより、台本の情報を整理するほうが自然に仕上がる場合もある。
音量と形式を、声の評価と別に調整する
元記事では、出力された音声のサンプリング周波数や平均音量が、従来の素材と違ったことも報告する。声がよいと感じても、ほかの動画と音量差があると、視聴者は聞きづらい。複数の話者を混ぜる場合も同じだ。
比較するときは、音量を大きくしただけで明瞭に感じる効果を避けるため、条件をそろえて聞く。ノイズ、息づかい、語尾、固有名詞、数字の読み方も分けて確認する。音の品質と、台本の内容を正しく読む能力を一つの感想にまとめないことが大切だ。
映像へ組み込む際は、使用する編集工程で周波数やチャンネル数を整え、音声の冒頭や末尾が切れていないかを確認する。生成ファイルを保存できたことと、最終動画で正常に聞こえることは別の検査になる。
支払いの入口と、生成一回の費用を混同しない
元記事の環境では、Voice Designの利用前に有料枠への切り替えと800円の前払いが必要になったという。これは、その利用者へ提示された購入単位であり、すべての人が同額を支払うという一般条件ではない。利用するプロジェクトや請求方式も関係する。
筆者は生成後に月の利用額として24円を確認し、音声出力だけの試算とは差があることを記した。残高の表示や特典の適用もあり、どの操作にいくらかかったかまでは確定できなかったとしている。画面の残高の増減だけで、一回の生成費用を逆算するのは難しい場合がある。
課金の公式説明と料金表を参照し、前払い残高、特典、利用額、個々の処理の使用量を分けて見る必要がある。試算には対象に含めた処理と、含めていない処理を明記したい。
声の名前だけでなく、識別子と利用先を残す
公式資料では、作成した声をvoice_で始まるIDで参照する。画面上の表示名は人が管理するための名前であり、プログラムが必要とする識別子とは別だ。元記事では、画面から得たサンプルコードとドキュメントの説明に差があり、そのコードを外部で動かす検証はしていないと報告した。
このような場合、コードが表示されたことだけで自動化が完成したとはいえない。必要なID、プロジェクト、権限、対応するモデルを確認し、検証できた工程を区別する。声を保存する仕組みには件数や保存期限の条件もあるため、長期運用では再取得や更新も考える必要がある。
編集部としては、声のID、設計文、確認した原稿、許可された用途、生成したファイルをひも付けて残す方法が有用と考える。モデルや設定が変わったときに、同じ比較原稿で違いを確かめられる。費用を減らすだけでなく、キャラクターの一貫性を保つ管理になる。
制作を安定させるのは、生成後の検品
元記事の筆者は、読みや声の一貫性を評価して一部のキャラクターを移行し、登場頻度の少ないほかの声は従来の環境へ残す判断をした。これは筆者の制作条件に基づく選択であり、すべての制作者に同じ移行を勧めるものではない。
日本語の制作では、読み方の辞書が必要か、訂正を何回行うか、尺を調整しやすいかまで含めて比べたい。生成時間や単価だけでは、人が直す時間は見えない。キャラクターの声を設計することは、好みの音色を探すことと、毎回の制作を再現できる形へ整えることの両方を含む。
確認日：2026年10月18日。本稿の制作にGemini APIは使用していない。運営会社：RO合同会社の公式HP。
PR
Notta →
