Text to Speech の仕組み｜正規化からボコーダまでのパイプライン解説

Text to Speech の仕組みを「パイプライン」として捉える

Text to Speech（TTS）を単なる「テキストを音声に変換するAPI」として扱うと、品質劣化の原因が特定できず、改善の打ち手を見失う。実装者が最初に押さえるべきなのは、TTSが独立した5つの処理ステージを直列に繋いだパイプラインであるという構造だ。各ステージが前段の出力を受け取り、加工して次段へ渡す。どのステージで誤差が生じたかによって、出力音声の崩れ方がまったく異なる。

以下の図は、テキスト入力から波形出力までの処理の流れを示している。

G2P (書記素→音素) ②フロントエンド

韻律 推定 ③フロントエンド

音響 モデル ④バックエンド

ボコーダ (波形生成) ⑤バックエンド

NICTの研究報告「ニューラル音声合成技術」（NICT技術報告 2022）でも、フロントエンド（言語処理）とバックエンド（音響生成）の分離構造は現代TTSシステムの基本設計として位置づけられている。各ステージの役割と品質への影響を順に解説する前に、一点だけ設計原則を示しておく。ステージを細かく分離するほどデバッグしやすくなるが、ステージ間の誤差伝播リスクが増す。End-to-end型アーキテクチャはこの問題をステージ統合で回避しようとするが、それはまた別の制御困難を生む。以下では古典的なパイプライン構造に則り、各段の仕組みと実装上の注意点を掘り下げる。

ステージ1〜2の仕組み：テキスト正規化とG2P（書記素→音素変換）

パイプラインの最前段はテキスト正規化（Text Normalization）だ。入力テキストには、後段の音響モデルがそのままでは処理できない表記が混入する。数字、略語、記号、URLなどがその代表例である。「3,500円」を「さんぜんごひゃくえん」と読むか「さんてんごひゃくえん」と読むかは文脈に依存し、「Dr.」を「ドクター」と読むか「どらいぶ」と読むかも同様だ。

正規化モジュールの実装方式は主に2つある。規則ベース（正規表現＋辞書）とニューラルモデルベースだ。規則ベースは高速で制御しやすいが、カバレッジに限界がある。ニューラルモデルベースは汎化性能が高い一方、誤りが予測しにくい傾向がある。日本語では助数詞（「3個」「3回」「3冊」）の読み分けが特に難しく、正規化品質が最終音声の自然さに直結する。なお、正規化の誤りはパイプライン全体を通じて訂正されることはなく、必ずそのまま音声に出力される。これがこのステージをデバッグ対象の筆頭に置く理由だ。

正規化を経たテキストは次にG2P（Grapheme-to-Phoneme）変換へ渡される。書記素（文字）を音素系列へマッピングするステージであり、日本語では仮名から音素への変換、英語ではスペルから発音記号への変換がこれに相当する。J-STAGEに収録された音声合成研究「音声合成のための言語処理と韻律制御」（J-STAGE, 人工知能学会誌）では、G2P変換の精度が発音品質の基盤であることが示されている。

英語G2Pの難しさは、同じスペルでも文脈によって読みが変わる同綴異音語（heteronym）にある。”lead” は名詞か動詞かで発音が異なる。日本語では同音異義語（「橋」と「箸」）のアクセント付与がG2P相当の課題として機能する。現代的な実装では、形態素解析器（MeCab、Sudachiなど）をG2Pの前処理として挟み、品詞情報を活用して曖昧性を解消するアプローチが一般的だ。G2Pモジュール単体の出力（音素列）を独立してロギングし、異常な音素列が後段に流れていないことを定常的に確認することが、運用安定性の要となる。

英語TTS固有の実装課題については英語テキスト読み上げツールの比較・解説も参照されたい。

ステージ3〜4の仕組み：韻律推定と音響モデルが「自然さ」を決める

韻律推定（Prosody Estimation）は、TTSパイプラインの中で人間が最も敏感に感知するステージだ。韻律とは、ピッチ（基本周波数F0）、デュレーション（音素・音節の長さ）、エネルギーの時系列パターンを指す。これが不自然であると、たとえ個々の音素が正確に発音されていても、聴衆は「ロボット的」と判断する。

NICTの多言語音声合成研究（NICT技術報告 vol.58）においても、韻律モデリングは多言語TTS品質の主要な変動因子として扱われている。韻律は言語ごとに構造が大きく異なり、日本語の高低アクセント、英語の強勢アクセント、中国語の声調がそれぞれ異なる韻律表現を要求する。このことは、多言語TTSを構築する際に韻律推定モジュールを言語ごとに設計する必要があることを意味する。

韻律推定には、言語情報（品詞列、文境界、強調語）をF0軌跡とデュレーション系列にマッピングする回帰モデルが使われる。古典的にはHMM（隠れマルコフモデル）ベースのアプローチが主流だったが、現在はTransformerベースのシーケンス変換モデルが精度・柔軟性の両面で支持されている。実装上の注意点として、韻律推定モデルは学習データのスピーカースタイルに強く依存するため、ナレーション調のデータで学習したモデルを会話体テキストに適用すると、句読点の無視や文末の不自然なイントネーションとして現れやすい。

韻律推定の出力を受け取る音響モデルは、音素列と韻律パラメータからスペクトル特徴量（メルスペクトログラムなど）を生成する。ここはTTSバックエンドの中核であり、アーキテクチャ選択が音声品質・推論速度・話者適応性のトレードオフを決定づける。各アーキテクチャの詳細な比較については無料AI音声合成の解説に譲るが、実装者として押さえておくべき落とし穴を一点だけ示す。

アテンション崩壊だ。Tacotron系のエンコーダ・デコーダ構造では、長文入力においてアテンション機構が途中でフォーカスを失い、音素のスキップや繰り返しが発生することがある。FastSpeech2はこの問題をduration predictorによる明示的なアライメント制御で解決しているが、duration予測器の学習データ品質に依存する別のトレードオフを生じさせる。この種のトレードオフは、アーキテクチャを選定する前に「どのような入力テキスト分布が来るか」を想定して評価する必要がある。

ステージ5の仕組み：ボコーダが最終音質を左右する理由

パイプラインの最終段であるボコーダ（Vocoder）は、音響モデルが出力したスペクトル特徴量（通常はメルスペクトログラム）から実際の音声波形を合成する。このステージは往々にして「最後の仕上げ」と軽視されるが、ボコーダの品質が最終出力のリアリティを大きく左右する。

古典的なボコーダはGriffin-Lim法のような位相推定アルゴリズムを使用していたが、出力がこもった印象になりやすかった。現代ではニューラルボコーダが主流であり、HiFi-GANに代表する生成的敵対ネットワーク（GAN）ベースの方式は、波形レベルの高周波成分まで再現する能力を持ち、かつ推論速度がリアルタイム以上になるよう最適化されている。IBM「Text to Speechとは」（IBM Think Topics）でも、ニューラルネットワークを活用した音声合成が自然さの向上に大きく寄与しているとされている。

エンジニアが設計時に考慮すべきトレードオフを以下の表に整理する。

代表的なボコーダ方式の比較（設計選定用）

方式	音質	推論速度	学習コスト	主な用途
Griffin-Lim	低〜中	高速	不要（アルゴリズム）	プロトタイプ・試験実装
WaveNet系	高	低速（自己回帰）	高	高品質オフライン生成
WaveGlow / Glow系	高	中速（並列フロー）	高	品質重視のオンライン生成
HiFi-GAN	高	高速（GAN）	中	リアルタイムTTS・エッジ推論
VITS（統合型）	高	高速	高	エンドツーエンド構成

ボコーダとアップストリームの音響モデルは共同学習（joint training）するか、個別に学習するかという設計判断がある。個別学習は汎用性が高いが、音響モデルとボコーダの分布ミスマッチが音声にノイズや歪みとして現れることがある。共同学習はこれを軽減するが、パイプライン全体の学習安定性を管理する難易度が上がる。個別学習構成でミスマッチを抑える実践的なアプローチとして、音響モデルの推論出力分布でボコーダをファインチューニングする「fine-tuning on synthesized mel」が知られている。学習時と推論時のスペクトログラムの分布差を縮小するこの手法は、追加データ収録なしで実施できる点で費用対効果が高い。

パイプライン全体設計の実装指針：誤差伝播を抑える3つの原則

TTSパイプラインを実装・運用するエンジニアが直面する最大の課題は、上流の誤差が下流で増幅されることだ。テキスト正規化で「2,500人」を「にせんごひゃくにん」と誤変換すれば、その誤りはG2P、韻律推定、音響モデルを通じてそのまま音声に出力される。パイプラインのどのステージも、誤りを「修正」するのではなく「引き継ぐ」構造であることを設計の前提として置く必要がある。

NICTの多言語音声合成研究（NICT技術報告 vol.58）は、言語依存フロントエンドと言語非依存バックエンドを分離するアーキテクチャの有効性を示している。この分離原則を含め、実装者が取るべき対策を3点に集約する。

1. ステージ間インターフェースの可視化：各ステージの入出力を検査可能にするロギング層を挟む。正規化後テキスト、G2P後の音素列、韻律パラメータをそれぞれ独立して確認できる設計にすることで、品質劣化の原因ステージを素早く特定できる。本番運用では、特定の入力パターン（長文・数式混在・URLなど）に対してステージ出力をサンプリングし、定期的に人手確認する仕組みを持つことが望ましい。
2. 言語依存モジュールの明確な分離：日本語TTSと英語TTSでは正規化ルールもG2Pモデルも異なる。言語依存処理を言語非依存の音響バックエンドから切り離すことで、多言語対応時の保守性が大幅に向上する。フロントエンドの差し替えだけで新言語に対応できる構造を最初から意識した設計が、後工程での手戻りを防ぐ。
3. ボコーダのミスマッチ対策：前述の「fine-tuning on synthesized mel」に加え、音響モデルのデコーダ出力にPostNetを挟んでスペクトログラムを補正するアプローチも有効だ。ボコーダの入力分布を安定させることが、最終音声のノイズ低減に直結する。

弊社クリスタルメソッドが開発するバーチャルヒューマンソリューション「DeepAI」では、音声合成パイプラインとリップシンク・表情生成を組み合わせた構成を採用している。音声合成パイプラインの出力タイミングが口唇動作の生成と同期される必要があるため、ボコーダのレイテンシが実用上の制約として直接効いてくる。リアルタイム対話AIにTTSを組み込む場合、ボコーダ方式の選定はレイテンシ予算の観点で音質と同等に重要な設計判断となる。この点はデジタルヒューマン用途に限らず、音声アシスタントや会話AIに組み込む場面でも共通して問題になる。

TTSの応用先やサービス選定を検討している場合は、テキスト読み上げアプリの選び方やかわいい声のTTS解説も参照されたい。フリーの音声合成AI実装については無料AI音声合成の解説が詳しい。またTTSと組み合わせて使われることの多いテキストマイニングの実装についてはPythonによるテキストマイニングを、ディープフェイク技術との関係を理解したい場合はディープフェイクの仕組み解説を参照されたい。

---

参考文献

• NICT「ニューラル音声合成技術」（技術報告 2022）
  https://www.nict.go.jp/publication/shuppan/kihou-journal/houkoku68-2_HTML/2022U-02-02-06.pdf
• NICT「多言語音声合成システム」（技術報告 vol.58 No.3-4）
  https://www.nict.go.jp/publication/shuppan/kihou-journal/kihouvol58-3_4/kihouvol58-3_4-0303.pdf
• J-STAGE「音声合成のための言語処理と韻律制御」（人工知能学会誌 Vol.3 No.4）
  https://www.jstage.jst.go.jp/article/jjsai/3/4/3_431/_pdf/-char/ja
• IBM「Text to Speechとは」
  https://www.ibm.com/jp-ja/think/topics/text-to-speech
• Zilliz「テキストから音声へ：TTS技術の深層」
  https://zilliz.com/jp/learn/from-text-to-speech-deep-dive-into-tts-technologies