SpeakStream: Streaming Text-to-Speech with Interleaved Data

（SpeakStream: インターリーブデータを用いたストリーミング音声合成）

田中専務

拓海先生、最近会話AIが喋るのが早くなってきたと聞きましたが、うちの社員が言う「遅延が減った」とは具体的に何が変わったのでしょうか。

AIメンター拓海

素晴らしい着眼点ですね！一言で言うと、テキストが届いたら待たずに音声を作り始める方式が進化して、最初の一音（first-token）の待ち時間が劇的に短くなっているんですよ。

田中専務

なるほど。でも、従来の音声合成（TTS）って一文まるごと学習してから喋るんじゃなかったですか。それを変えたのですか。

AIメンター拓海

その通りです。従来はテキストを全部受け取ってから音声を合成する流れが多く、会話の応答性で不利でした。新しい方式はテキストと音声を交互に扱う学習で、流れてくる文章に合わせて小刻みに音声を生成できるようにしたんです。

田中専務

それは現場で役立ちそうですね。ただ、品質が落ちる心配はありませんか。瞬間で出すと不自然になりませんか。

AIメンター拓海

大丈夫、そこが肝で、音声の区切りに始まりと終わりのトークン（BOS/EOS）を付けてつなぎ目を滑らかにしているのです。まるで演者が小さなフレーズごとに息継ぎして滑らかに話すように見せる仕組みですよ。

田中専務

これって要するにテキストと音声を交互に学ばせることで、最初の音を早く出せるようにした、ということですか。

AIメンター拓海

その理解で合っていますよ。要点は三つです。第一に、decoder-only（デコーダーオンリー）という構造でテキストと音声を同じ流れで扱えること。第二に、インターリーブ（interleaved）データを作って次の音声を予測する学習をすること。第三に、生成を小さな区間で繰り返すことで最初の音の遅延を下げることです。

田中専務

なるほど、投資対効果で見ると初動の遅さが減れば顧客体験は上がりますね。導入で注意すべき点は何でしょうか。

AIメンター拓海

導入では三点注意です。既存のTTSデータをインターリーブ形式に整備する工程、リアルタイムでの音声品質管理、そしてLLM（Large Language Model、大規模言語モデル）から来るテキストのストリーミング設計です。それぞれ現場での工数と運用ルールが必要になりますよ。

田中専務

分かりました。では、社内会議で簡単に説明できる言い方を最後に一つお願いします。

AIメンター拓海

はい、大丈夫です。一言で言うなら「SpeakStreamはテキストと音声を交互に学ばせて、届いた言葉を待たずに喋り始めることで応答の遅れを劇的に減らす技術」です。導入はデータ整備と運用ルールの整備が肝ですね。大丈夫、一緒にやれば必ずできますよ。

田中専務

分かりました、要するに「テキストを待たずに小分けで音声を出すことで、会話のレスポンスが早くなる仕組み」で、導入ではデータ整備と音声品質の運用が重要ということですね。ありがとうございました。

1.概要と位置づけ

結論から述べると、本研究はストリーミング時の初動遅延（first-token latency）を大幅に改善し、対話型AIの応答性を実用レベルへ引き上げる技術である。Text-to-Speech (TTS、テキスト音声合成) と Large Language Model (LLM、大規模言語モデル) を直列に繋ぐ従来のカスケード系システムでの「テキスト完了待ち」問題を解消する点が最も大きく変わった点である。具体的にはテキストと音声を交互に並べたインターリーブ（interleaved）データでdecoder-only（デコーダーのみ）モデルを学習し、受信したテキストの長さに応じて小さな音声区間を順次生成する方式を提案している。これにより、ユーザーが話し終えるのを待たずに最初の音が出るため、電話応対や接客ボットなどリアルタイム性が重要な業務でのユーザー体験が向上するのだ。経営的観点では、顧客満足度向上という効果を低レイテンシで実現できるため、投資対効果の観点から導入価値が高い。

2.先行研究との差別化ポイント

先行研究は大きく二つに分かれる。一つはLLMが直接音声トークンを出すエンドツーエンド方式で、もう一つはLLMからテキストを出し、それをTTSで変換するカスケード方式である。本研究は後者の延長線上にありながら、従来のTTSが前提としていた「一文完了を入力として全体を合成する」設計を破壊する点で差別化する。具体的には、従来のテキストエンコーダー型TTSが持つ再エンコードのオーバーヘッドを避けるため、デコーダーのみのアーキテクチャでテキストと音声トークンを同列に扱う学習を行う。さらに、音声区間の先頭と末尾にBOS/EOSという境界トークンを設け、区切りごとの生成を安定化させて接続時の音声アーティファクトを抑えている。結果として、遅延低減と音声品質の両立という従来難しかった両立を達成している点が本研究の差異である。

3.中核となる技術的要素

本研究の技術の核は三つある。第一に、インターリーブ（interleaved）データという考え方である。これはテキスト片と対応する音声片を交互に並べ、モデルに次に来る音声片を予測させる訓練データ整備法である。第二に、decoder-only（デコーダーオンリー）アーキテクチャである。これにより、新たに到着するテキストを逐次吸収しながら音声生成を続けられる構造となる。第三に、ロス関数の取り扱いで、モデルは学習時に音声トークンのみで損失を計算し、テキスト部分はコンテキストとして扱うことで音声生成精度を担保する。技術的には、強制整列（force-aligner）で既存データの区切りを作る工程と、BOS/EOSトークンで区間を囲む設計が滑らかな接続と低遅延を両立させている点が肝である。

4.有効性の検証方法と成果

有効性はまず指標としてfirst-token latency（最初の音声トークンの遅延）を採用し、従来型TTSと比較した。実験ではストリーミングテキストを入力として連続応答を生成させ、最初の出力が出るまでの時間と全体の音声品質を評価した。結果として、first-token latencyは従来方式に比べて有意に短縮され、音声の自然さや滑らかさも非ストリーミングTTSと同等の水準を維持したと報告されている。加えて、接続部のアーティファクトはBOS/EOSと区間学習により抑制され、ユーザー体験に直結する「会話らしさ」は改善された。これらの成果は、実用的な対話システムへの適用可能性を示す強いエビデンスとなる。

5.研究を巡る議論と課題

本手法には実運用で考慮すべき点がある。第一に、インターリーブデータを作るための既存コーパスの整備コストである。force-alignerによる区切り付与は自動化できるが、品質担保のための手作業確認が必要になる場合がある。第二に、ストリーミング文字列の特性に依存するため、LLM側の出力戦略や改行・修正の扱いが生成品質へ影響を及ぼす点である。第三に、低遅延を優先するあまりセキュリティや発話内容の検査が間に合わないリスクがあり、コンプライアンス面での運用設計が不可欠である。総じて技術は成熟しつつあるが、データ整備と運用ルールの整備が導入の鍵を握る。

6.今後の調査・学習の方向性

今後は三方向の延長が有望である。第一に、LLMとTTSの共同最適化で、テキスト生成側がストリーミングを意識した出力をするプロトコル設計である。第二に、話者適応や感情表現など音声のパーソナライゼーションをインターリーブ学習に組み込む研究である。第三に、リアルワールドでの評価指標の確立で、単に遅延や音声品質だけでなく、顧客満足度や業務効率向上といったビジネス指標と結びつけることが必要だ。以上を踏まえ、企業はまず小規模なパイロットでデータ整備と運用フローを検証し、段階的に本格導入へ進めるべきである。

検索に使える英語キーワード: “SpeakStream” “streaming TTS” “interleaved text-speech” “decoder-only TTS” “first-token latency”

会議で使えるフレーズ集

・「SpeakStreamはテキストを待たずに小区間で音声を生成するため、顧客応答の初動遅延が劇的に下がります。」

・「導入の初期はデータのインターリーブ化と品質チェックの工数が必要ですが、投資対効果は高いです。」

・「リスクはテキストのストリーミング特性と品質管理なので、LLM側の出力方針と合わせて運用設計を行いましょう。」

引用元: R. Bai et al., “SpeakStream: Streaming Text-to-Speech with Interleaved Data,” arXiv preprint arXiv:2505.19206v1, 2025.