Skip to Content
Docs12. モダリティ応用音声合成(TTS)と声の設計
中級text-to-speechvoice-designvoice-cloning更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

音声合成(TTS)と声の設計

この記事の目的

対話ループ以外も含む音声合成(TTS: text-to-speech)の実務 — 読み上げ・ナレーション・通知 — を設計し、「声」というプロダクト資産を扱えるようになります。選定軸(自然さ・レイテンシ・日本語品質・スタイル制御・コスト)・ストリーミングLLM の応答を生成と同時に逐次受信・表示する方式。Agent の体感品質を左右する基本技術。 TTS と応答設計・声のブランド設計・音声クローンの統制・発音制御・評価を、実務判断として持ち帰れる状態を目指します。対話エージェントのループ全体は 音声エージェント(voice agents) が正本で、本記事は出力部品としての TTS と非対話用途に絞ります。

対象読者

  • 読み上げ・ナレーション・音声通知など、対話に限らない TTS 機能を組み込む実装担当
  • 「プロダクトの声」をブランド資産として設計し、音声クローンの利用可否を判断する立場の人

前提知識

本文

概要: TTS は「対話ループの外」にも要る

音声合成は、対話エージェントの出力段だけのものではありません。読み上げ(記事・ドキュメント)・ナレーション(教材・動画)・音声通知など、非対話の用途が広くあります。本記事はこの出力部品としての TTSと、「声」というプロダクト資産の設計を扱います。音声対話のループ設計(ターンテイキング・割り込み・speech-to-speech とパイプラインの選択)は 音声エージェント(voice agents) が正本です。

最終確認日: 2026-09-10。 本記事で触れる TTS サービス・モデル名・日本語対応・音声クローンの条件は変化が速いため、代表例は「2026-08 時点」の一般類型として読み、採用時は各社公式ページで再確認してください(後述の TODO)。

選定軸

TTS の選定は、次の軸で行います(具体サービスは変化が速いため 2026-08 時点の代表例)。

軸見るポイント
自然さ用途に足る音質か(ナレーションは高品質、通知は軽量でよい)
レイテンシストリーミング対応か・最初の音声までの速さ
日本語品質・声の種類ja-JP のボイス・スタイル制御の有無
スタイル制御感情・速度・トーンの制御手段(SSML か自然言語指示か)
発音制御固有名詞・読み仮名を制御できるか(後述の分岐点)
コスト文字数・秒あたりの課金構造
  • 主要な TTS サービス(2026-07 時点で OpenAI TTS・Google Cloud Text-to-Speech・Amazon Polly・Microsoft Azure・ElevenLabs 等)は、いずれもマネージド API + ストリーミング TTSを提供しており、「ストリーミング対応の有無」だけでは差がつきにくいです
  • 差が出るのは日本語の声・スタイル制御・発音制御・音声クローンの条件です。以下、この差を扱います

ストリーミング TTS と応答設計

音声出力の体感は、最初の音声が返るまでの速さで決まります(ストリーミングと Agent の UX 実装パターンの音声版)。

  • ストリーミング TTS: テキスト全体の合成完了を待たず、先頭から逐次音声を返します。長い読み上げでは、これがないと「無音の待ち時間」が体感を大きく損ないます
  • 文単位で流す: LLM の出力をストリーミングで受けつつ、文が確定したそばから TTS に送ると、体感レイテンシを下げられます。パイプライン全体の応答設計は 音声エージェント のレイテンシ設計と同じ考え方です
  • 音質とレイテンシのトレードオフ: 高品質モデルは遅くなりがちです。ナレーション(品質優先)と通知(速度優先)で使い分けます

声の設計: ブランドとしての声

プロダクトの「声」は、ブランド資産です。行き当たりばったりに選ばず、設計します。

  • ブランドとの整合: 声のトーン・話速・性別・雰囲気を、プロダクトのブランド・ペルソナに合わせます。堅い金融サービスと親しみやすい教育アプリでは、ふさわしい声が違います
  • 一貫性を保つ: 同じプロダクト内で声がばらつくと、体験が壊れます。使う声・スタイルを決め、資産として管理します(プロンプト管理の考え方を声の設定に応用)
  • 声の設計思想の 2 類型: サービスによって「共通ボイスが多言語を話す」型と「言語別に専用ボイスが用意される」型があります。日本語主体なら、日本語ボイスの選択肢と品質を確認します

音声クローンの利用と統制

音声クローン(voice cloning) — 特定の人の声を再現する機能 — は強力ですが、同意と統制が必須です。悪用は重大な被害を生みます。

  • 提供各社が統制手段を課している: 音声クローンを提供するサービスは、規約上の統制を課しています。2026-08 時点の例では、「本人の声のみクローン可」「同意文言の録音提出を必須」「アクセス審査(allowlist / limited access)」「本人確認」などです。セルフサーブでなく個別エンゲージメントを要するサービスもあります
  • 本人同意を必ず取る: 実在の人の声をクローンするなら、本人の明示的な同意が前提です。第三者の声を無断でクローンするのは、規約違反であり法的・倫理的に重大な問題です
  • 社内承認プロセスを設ける: 音声クローンの利用は、社内でも承認プロセス(誰の声を・何に使うか・同意は取れているか)を設けます。技術的にできることと、やってよいことは別です
  • 法的可否は確認先を示すに留める: 音声クローンの適法性・第三者の声の可否・商用条件は、各社規約・地域法(肖像権・パブリシティ権等)で異なり変化も速いため、本記事は断定せず、各社規約と法務、および規制の入口(業界別規制マップ)での確認を促します

発音制御: 固有名詞・読み仮名

ナレーション・読み上げの実務でつまずくのが、固有名詞・専門用語の読み間違いです。ここは TTS の設計上の分岐点になります。

  • 発音制御の有無で分かれる: TTS サービスは、発音制御の手段で二分されます。SSML(音声合成マークアップ)や発音辞書を持つものは、固有名詞・読み仮名・数値の読み方を明示的に制御できます。一方、自然言語の指示のみで SSML・発音辞書を持たないサービスもあり(2026-08 時点で一部の TTS はこの型)、厳密な読み制御が苦手です
  • 厳密な読みが要るなら発音制御を持つものを: 社名・人名・専門用語を正確に読ませたいナレーション用途では、SSML・発音辞書を持つサービスを選びます。「だいたい読めればよい」通知用途なら、自然言語指示型でも足ります
  • 日本語の読み仮名は個別確認: 日本語特有の「読み仮名(ルビ)指定」の対応は各社で差があり、SSML の対応タグも異なります。日本語ナレーションでは、対象サービスの日本語発音制御を実機で確認します(下記 TODO)

評価: 了解性と自然さ

TTS も評価します。ただし音声の評価は、テキストと違う観点が要ります。

  • 了解性(聞き取れるか): まず「正しく聞き取れる」ことを確認します。固有名詞の読み間違い・不自然な区切りは了解性を下げます。重要用途では人が聞いて確認します
  • 自然さ(不自然でないか): イントネーション・間・感情が用途に合うか。ナレーションでは特に重要です
  • 崩れやすいケースを含める: 長文・固有名詞・数値・記号・外国語混じりなど、崩れやすいケースを評価に含めます(Agent 評価の基礎の考え方を音声出力に適用)。「短い定型文は綺麗だが、実際の原稿で崩れる」を見逃さないようにします

WebSocket はモデルとエンドポイントの組合せで選ぶ

「製品が WebSocket に対応している」だけでは接続先を決められません。2026-09-10 確認の ElevenLabs には次の別経路があります。

経路モデル・音声の指定入力契約
/v1/text-to-speech/{voice_id}/stream-inputFlash / Multilingual v2 等。eleven_v3 は非対応URL で 1 音声を固定し、text を送ります
/v1/text-to-dialogue/stream-inputeleven_v3 系初回に voices を登録し、以後は inputs の要素ごとに text / voice_id を送ります

モデル名だけを v3 に変えて従来の TTS メッセージを送る移行はできません。対話側のターン境界、バッファ、割込み、セッション枠も確認し、音声品質と応答遅延を同じ条件で測ります。

実務での注意点

アンチパターン

  • ストリーミング TTS なしで長文を読み上げる → 合成完了までの無音で体感が壊れる → ストリーミング TTS で文単位に逐次再生する
  • 発音制御を確認せず固有名詞を読ませる → 社名・人名を誤読したナレーションが出る → SSML・発音辞書の有無を選定時に確認し、日本語の読みは実機で検証する
  • 音声クローンを本人同意なしに使う → 規約違反・法的/倫理的な重大問題になる → 本人同意・社内承認・各社統制要件を満たす
  • 声を場当たりで選ぶ → プロダクト内で声がばらつき体験が壊れる → ブランドに合う声を決め、資産として一貫管理する
  • 短い定型文だけで品質判断する → 実原稿(長文・固有名詞)で崩れる → 崩れやすいケースを評価に含める

チェックリスト

  • 用途(ナレーション / 通知 / 読み上げ)に応じて自然さとレイテンシのバランスで選んだ
  • ストリーミング TTS で最初の音声までの体感を設計した
  • 日本語ボイス・スタイル制御の提供を確認した
  • 固有名詞・読み仮名の発音制御(SSML・発音辞書)の要否を判断し、日本語の読みを実機確認した
  • 音声クローンを使う場合、本人同意・社内承認・各社統制要件を満たしている
  • クローンの適法性・商用条件を各社規約と法務で確認した(断定していない)
  • 声をブランド資産として一貫管理している
  • 了解性・自然さを、崩れやすいケースを含めて評価している

関連トピック

参考資料

TODO・未確認事項

動画生成・理解の概観リアルタイムマルチモーダル Agent