【ITニュース解説】Audio Deadlines: Running On-Device TTS Without Audible Glitches

デバイス上でテキストを音声に変換するTTS（Text-to-Speech）技術は、近年、研究段階から実用段階へと進化してきた。これは、単に音声合成モデルの性能向上だけでなく、スマートフォンなどのエッジデバイスでこの技術を安定して実行できるようになったことを意味する。しかし、この「デバイス上での音声合成」を現実のアプリケーションに組み込む際には、モデルの性能以上に、オーディオ処理の厳格なリアルタイム性という、これまで多くのエンジニアが直面してこなかった課題が浮上する。

一般的なウェブアプリケーションのリクエスト処理が900ミリ秒かかっても問題にならないのに対し、オーディオ処理はわずか20ミリ秒の期間に特定の処理を終えなければならない。例えば、24kHzのサンプルレートで20ミリ秒ごとに音声を出力する場合、各期間で480サンプルを生成する必要がある。この期限を少しでも過ぎると、バッファが空になり「アンダーラン」という状態が発生する。これにより、クリック音、ポップ音、またはロボットのような途切れが生じ、ユーザーは「アプリが壊れている」と感じてしまう。CPUが熱で性能を制限される「サーマルスロットリング」や、OSがバックグラウンドで他のタスクを実行しているような状況下でも、この厳格な期限は守られなければならないのだ。

このような制約があるため、音声合成エンジンの最適化目標も変わる。処理速度の平均値や、処理時間の半分が特定の時間内に収まる「P50レイテンシ」のような指標は、あまり重要ではない。最も重視すべきは「最悪ケースのチャンク処理時間」である。一つでも処理の遅いチャンクがあれば、それが直接、ユーザーに聞こえる不具合となるからだ。また、システムが分単位で安定して動作し続ける「持続的なリアルタイムファクター（RTF）」も極めて重要となる。短時間のRTFは良好に見えても、長時間稼働するとSoC（System on Chip）が省電力モードに移行し、性能が低下してRTFが悪化する事例は少なくない。

RTFは「音声合成にかかった時間」を「合成された音声の再生時間」で割った値で、一般的にこの値が1.0未満であれば、再生速度より合成速度が速いと判断される。しかし、これは平均値であり、システムの安定性を保証するものではない。例えば、RTFが平均0.55と良好に見えても、数分後には1.1に悪化し、アンダーランを引き起こすことがある。これは、デバイスの高性能コアから省電力コアへの切り替えなどが原因で起こる現象だ。このような問題を見過ごさないためには、短時間の測定ではなく、実際のデバイスで10分以上動作させ、各チャンクの処理時間のばらつきや最悪値を評価することが不可欠となる。具体的には、平均RTFだけでなく、処理時間の99パーセンタイル（P99）値、最悪値、そして「スラック（余裕）」、すなわち、処理の遅れを吸収できるバッファの残量を確認することが重要となる。

処理時間の変動（ジッター）は、モデルを高速化するだけでは解決できない問題である。これを吸収するために「プリバッファ」という技術が用いられる。これは、音声の再生を開始する前に、あらかじめ数百ミリ秒分の音声を生成しておき、バッファに貯めておくことで、一時的な処理の遅れがあっても音途切れを防ぐ仕組みだ。しかし、プリバッファはユーザー体験とのトレードオフになる。音声アシスタントでは、プリバッファの量だけユーザーの発話からアシスタントが話し始めるまでに遅延が生じる。画面読み上げアプリでは、カーソル移動のたびにわずかなラグが生じる。そのため、対話型アプリケーションでは150-250ミリ秒と短く、ナレーションのような用途では400-800ミリ秒と長く設定するなど、アプリケーションの特性に応じた適切なプリバッファ量を設定する必要がある。

ストリーミング方式で音声合成を行う場合、テキストを小さな塊（チャンク）に分割し、生成された音声もチャンク単位で扱うことになる。このチャンクの境界で「シーム（継ぎ目）」の問題が発生する。テキストを文単位で分割すると、文の切れ目でイントネーションやリズムが不自然になることがある。また、音声データを細かく分割して生成する際に、音声の端で不連続な音（ノイズ）が発生することがある。これを避けるためには、チャンクの境界で音声データを重ね合わせ、音量を徐々に変化させる「クロスフェード」という技術を用いる。5～10ミリ秒のクロスフェードが効果的だが、短すぎると破裂音でノイズが生じ、長すぎると子音が不明瞭になる場合がある。また、無音部分にクロスフェードを適用すると、本来の「間」が詰まって聞こえるという問題も起こりうるため、音声のエネルギーを見てクロスフェードの適用を制御する必要がある。

モデルの性能を最適化する「量子化」という技術も注意が必要だ。Int8量子化のようにモデルの精度を落とすことで処理速度は向上するが、多くの場合、音声の「明瞭度」よりも「自然さ」が先に損なわれる。例えば、AIによる音声認識（ASR）を経由して単語誤り率（WER）を測定しても数値に変化がなくても、生成される音声は平板で、わずかにバズ音を伴うようになる。ユーザーはこのような微妙な変化をすぐに聞き分けるため、WERのような客観的な指標だけでは品質を十分に評価できない。そのため、F0（基本周波数）の輪郭のずれや、持続母音のスペクトル距離といった、より細かな音声の品質指標を測定することが重要だ。また、デバイス内蔵スピーカーとイヤホンでは聞こえ方が異なる場合があるため、両方でテストを行うべきだ。

システム全体として見ると、スレッド数を増やすことが常にパフォーマンス向上につながるわけではない。スレッド数を増やすと、確かに一つのチャンクを高速に処理できる可能性があるが、その反面、消費電力が増大し、SoCの加熱を招く。結果としてサーマルスロットリングが発生し、長時間の運用ではかえってRTFが悪化することがある。スマートフォンなどのデバイスでは、スレッド数を2つに抑え、その分プリバッファを大きくとる方が、4スレッドでプリバッファを小さくするよりも、10分間といった長時間のセッションで安定した性能を発揮するケースも存在する。

さらに、各プラットフォームには特有の注意点がある。Androidでは、低レイテンシモードを利用する際に、デバイスが要求するネイティブサンプルレートに合わせる必要がある。24kHzで合成した音声を48kHzにリサンプルさせると、追加のレイテンシや意図しないフィルターが適用される可能性があるため、デバイスのレートに合わせるか、自分で高品質なフィルターを用いてリサンプルすべきだ。iOSでは、AVAudioSessionのカテゴリとモード設定が低レイテンシ経路の利用可否に影響するため、シミュレーターではなく実機での確認が不可欠となる。組み込みLinux環境でALSAを使用する場合も、コールバック期間を明示的に設定し、開始しきい値を確認することが重要だ。また、モデルの重みをメモリマップする際に、コールドスタート後最初の発話で多くのページフォルトが発生し、デッドラインを逃すことがあるため、アプリ起動時にモデルをウォームアップするか、重要なメモリ領域をロックしておくなどの対策が必要となる。

アプリケーションの安定稼働のためには、品質低下や障害発生時のフォールバック（代替手段）戦略を事前に定めておくことが重要だ。例えば、フル品質のデバイス内音声から、サンプルレートを下げた（48kHzから24kHzなど）音声へ切り替える、あるいは短い発話にはより多くのプリバッファを使用する、といった段階的な品質低下を許容する。最終手段として、ネットワークが利用可能でユーザーが従量課金接続でない場合に限り、サーバー側のTTSを利用することも考えられる。ただし、最も重要な注意点として、文の途中で声を切り替えることは避けるべきだ。文の区切りでの声の変化は個性として許容される可能性があるが、句の途中での声の変化は、音声データが破損しているかのように聞こえ、ユーザーに不快感を与えるからだ。

最後に、陥りやすい間違いとして、平均RTFだけを報告してエンジンが「リアルタイムより高速」だと主張すること、ラップトップやエミュレーターでベンチマークを行うこと、そして単一の短い文章だけでテストすることなどが挙げられる。これらはすべて、実際のユーザー環境における熱特性やオーディオルーティング、長時間にわたるCPU負荷などを正しく反映しないため、実運用で予期せぬ問題を引き起こす原因となる。実際のデバイスで、多様な長さのテキストを用いて長期間テストを実施することが、真に安定した音声合成エンジンを開発する上で不可欠となる。