TTS音声品質は「テキストの渡し方」で決まる

TTSエンジンにテキストを入力すれば、自然な音声が返ってくる。そう期待して導入を始めたものの、実際には数値の誤読、固有名詞のイントネーション崩れ、音声の不自然な途切れが続出する——。

私たちはあるプロダクトの音声読み上げ機能を開発する中で、まさにこの壁にぶつかりました。そして3フェーズ・20回超のテスト・100回超の変換実行を経て、ひとつの結論にたどり着きます。TTS音声の品質を最も左右するのは、エンジンの選定ではなく「テキストの渡し方」でした。

本記事では、この検証プロセスと得られた技術的知見を実験記録として共有します。

TTSに「そのまま」テキストを渡してはいけない理由

TTSエンジンにテキストをそのまま渡すと、プロダクト品質の音声にはなりません。数値・固有名詞の誤読、不自然なイントネーション、音声の途切れが高い頻度で発生します。

最初のテストで確認されたのは、こうした問題の多さでした。英語のサービス名が意図しないカタカナで読み上げられる。「1/3」が日付として解釈される。句読点の処理が不安定で、文の途中に長い沈黙が入る。

これらは特定のエンジンに限った話ではありません。複数のクラウドTTSエンジンで同様の傾向が確認されました。TTSエンジンは渡されたテキストを忠実に音声化しようとしますが、テキストの「意味」を人間と同じように理解しているわけではないのです。品質問題の多くは「エンジンが悪い」のではなく、エンジンが解釈しやすい形でテキストを渡していないことに起因しています。

テキスト前処理パイプラインという考え方

TTS音声の品質を決定する最大の要因は、エンジン選定ではありません。エンジンに渡すテキストの前処理——私たちはこれを「Text Formatting」と呼んでいます——の設計品質が、最終的な音声品質を左右します。

パイプラインの全体像

私たちが構築したパイプラインは、次の構造です。

原文テキスト
  → LLMによるテキスト変換（Text Formatting）
    → 変換済みテキスト + SSML
      → TTSエンジン
        → 音声出力 → 人間による聴取評価

原文をTTSエンジンに直接渡すのではなく、間にLLM（大規模言語モデル）を挟んでテキストを最適化します。LLMがテキスト中の数値を読み上げ用の表現に変換し、固有名詞にカタカナの読みを付与し、句読点をSSMLのブレイクタグに置き換える。こうした前処理を経ることで、TTSエンジンが迷わず音声化できる入力テキストを生成します。

なぜLLMをテキスト変換に使うのか

ルールベースの正規表現でもある程度の変換は可能です。しかし自然言語には揺らぎがあります。同じ漢字でも文脈によって読みが変わる。英語略語の読み方が確立されていない。文の切れ目の判断が一意に定まらない。こうしたケースをルールだけで網羅するには限界があります。

LLMであれば「弾き出す→はじきだす」「重複→ちょうふく」のような文脈依存の読み分けを、プロンプトの指示ひとつで処理できます。変換ルールの追加・変更にコード修正が不要で、プロンプトの編集だけで対応できる点も大きい。改善のイテレーションを高速に回せる柔軟性が、品質を短期間で引き上げる原動力になりました。

20回のテストで分かった、前処理プロンプト設計の勘所

前処理プロンプトの改善によって、フォーマット安定性は初版の60%から最終版で100%に到達しました。ただし、そこに至るまでには想定外の発見と方針転換がありました。

Before/After例示が安定性を跳ね上げる

プロンプトの初期バージョンでは「句読点を削除してブレイクタグに置換してください」のような抽象的な指示を出していました。LLMはルールを理解してはいるものの、出力の一貫性が低い。5回実行すると3回しかルール通りにならないという状態です。

転機になったのは、全ルールにBefore/Afterの具体例を追加したことでした。「このテキストが入力されたら、この形式で出力する」という変換例を1つ加えるだけで、安定性は3/5から5/5に跳ね上がります。

LLMは抽象的なルール文より、具体的な入出力ペアから変換の意図を汲み取る傾向があります。この発見はTTSに限らず、LLMにテキスト変換を任せるあらゆる場面で応用が効く知見だと考えています。

エンジンごとに最適な前処理は異なる

当初は1つの前処理プロンプトを複数のTTSエンジンで共用する想定でした。テストを重ねるうちに、この前提が崩れます。

あるエンジンではSSMLタグの簡素化と語区切りの明示が効果的でした。別のエンジンでは、漢字を残しつつ問題のあるカテゴリのみを変換するハイブリッド方式が最適解に。SSMLの対応タグ、読み上げエンジンの内部辞書、イントネーション推定のアルゴリズム——エンジンごとに特性が異なるため、共通プロンプトでは最適品質に到達できません。

TTSエンジンの数だけ、専用の前処理設計が必要になる。工数は増えますが、品質を追求するなら避けられないステップです。

「全ひらがな変換」は逆効果だった——漢字はTTSの味方

誤読を防ぐために、全テキストをひらがなに変換してからTTSに渡すアプローチも試しました。読みを完全に指定すれば、誤読は起きないはずです。論理的には正しそうに見えました。

結果は逆でした。

全ひらがな化するとイントネーションが著しく悪化し、音声がフラットで不自然な読み上げになったのです。漢字はTTSエンジンにとって単語境界とアクセント情報の手がかりとして機能しています。「弾き出す」を「はじきだす」にすると、エンジンは「はじ・きだす」なのか「はじき・だす」なのか判断できなくなる。漢字であれば「弾き出す」という塊を正しく認識できます。

最終的に採用したのは、漢字を基本的に保持しつつ、誤読が確認されたカテゴリのみを個別に変換するハイブリッド方式でした。全ひらがな化という「正しそうな」アプローチが裏目に出た経験は、私たちにとって大きな学びになっています。

テキスト変換を実行するLLMモデルの選定

同じプロンプトでもLLMモデルによって変換精度は大きく異なります。全チェック項目のルール遵守率が0%から100%まで開くこともあり、コストだけでモデルを選定するのは危険です。

軽量モデルの落とし穴——ルール遵守率0〜9%の現実

コスト削減を目的に軽量モデルへの切り替えを検証したところ、想定以上に厳しい結果が出ました。

プロンプトに明示的な変換例がある項目は処理できる。しかし「すべての英字略語を変換する」のような汎用ルールの適用、句読点の削除操作、文脈を読んだ数値表現の変換——これらが軒並み不安定でした。全チェック項目を同時に満たせた割合は12回のテストで0%。別のテキストパターンでも9%にとどまります。

さらに深刻だったのは出力の非決定性です。同じ入力に対して毎回異なるパターンで出力が分散し、品質の予測ができない。プロダクトに組み込む以上、再現性のない出力は致命的です。

モデルの「弱点の性質」を見極める

3つのスペックが異なるモデルを比較して見えてきたのは、弱点には2種類あるという事実でした。

ひとつは「プロンプトに明示ルールがあるのに失敗する」ケース。これはモデル側の能力限界であり、プロンプトの改善では解消しません。もうひとつは「プロンプトに該当ルールが不足しているために失敗する」ケース。こちらはプロンプトの追加・修正で対処できます。

最終的に採用したモデルは後者のタイプでした。テストで検出された課題がすべてプロンプト側の改善で対処可能であり、指示追従性が極めて高い。全12回の実行で文字レベルで完全に同一の出力が得られたことが、採用の決め手になっています。

実験から導いた、TTS品質改善の優先順位

20回超のテストを通じて得られた最大の結論は、TTS音声品質に影響を与える要因の優先順位です。

エンジン比較に時間をかけるよりも、前処理の設計品質を高めるほうが費用対効果は高い。これが一連の実験を通じた私たちの実感です。

もうひとつ強調しておきたいのは、TTS品質の改善は「一度設定して終わり」ではないということです。入力テキストのパターンが変わるたびに新しいエッジケースが出てきます。テスト→問題検出→プロンプト改修→再テストのサイクルを短く回し続けること。この地道な反復が、実用水準の品質を維持する鍵でした。

まとめ——TTSの品質は「テキストの渡し方」で決まる

TTSエンジンにテキストをそのまま渡して品質を期待するのは、翻訳エンジンに推敲前の文章を渡すようなものです。入力の質が出力の質を決めます。

本記事の知見を集約すると、次の3点になります。

• TTSの品質問題の多くはエンジン側ではなく、テキストの前処理で解決できる
• 前処理プロンプトはエンジンごとに最適化が必要で、具体的なBefore/After例の提示が安定性を大きく左右する
• LLMモデルの選定ではコストだけでなく、ルール遵守の安定性と出力の再現性を重視すべきである

AI音声をプロダクトに組み込む際、「エンジンをどれにするか」だけでなく「エンジンにどうテキストを渡すか」まで設計することで、品質は大きく変わります。

私たちはこうしたAI機能の技術的なチューニングや導入支援を日々行っています。TTS品質の改善やAI機能の実装に本気で取り組む方は、お問い合わせページよりご相談ください。