音声プロダクトの体感を決めるのは、合計合成時間ではなく初回パケット遅延
音声機能を作るチームの多くは、最初に測る指標を間違えている。一文を合成し、リクエスト全体の時間を計り、「1.4 秒」という数字を記録する。そしてリリースすると、ユーザーからは「遅い」と言われる——紙の上では 1.4 秒は十分速いはずなのに。
このズレは、ごく単純な事実から来ている。人は合計合成時間を知覚しない。人が知覚するのは沈黙である。
ユーザーが実際に計っているもの
音声エージェントに話し終えた瞬間、その人の中でストップウォッチが動き出す。そして最初の返答が聞こえた瞬間に止まる。最初の音声が耳に届いた後に起きること——残り 90% の文がまだ合成され、バッファされ、再生されていること——は、そのストップウォッチには見えない。その時点でユーザーはすでに聴いているからだ。
だから合計合成時間がまったく同じ 2 つのシステムでも、体感はまるで違う。
- システム A：1.4 秒かけて文全体を合成し、それから再生開始。体感待ち時間 1.4 秒。
- システム B：90ms で最初の音声チャンクを返し、再生しながら残りを合成。体感待ち時間 90ms。
同じ処理量、同じ総計算量。一方は壊れているように感じ、もう一方は即座に感じる。
この 2 つを分けるのが 初回パケット遅延（time to first packet） ——テキストを送ってから、再生可能な最初の音声チャンクが返るまでの時間だ。人間の実際の体験に対応する唯一の遅延指標である。
非ストリーミング API ではこれを解決できない理由
リクエスト／レスポンス型の TTS エンドポイントには構造的な問題がある。すべてが揃うまで、何も返せない。 レスポンスボディは 1 つの音声ファイルであり、音声ファイルは完成するまで無効だ。つまりモデルがどれだけ速くても、体感遅延の下限は合成完了時間に固定される。
モデルを速くすることには意味があるが、それは間違った制約と戦っている。合成時間を 1.4 秒から 0.7 秒に半減させるのは大きな工数だが、それでも待ち時間ははっきり聞こえる。同じ 1.4 秒の合成をストリーミングで返せば、モデル速度に一切手を触れずに体感待ち時間のほぼ全部が消える。
MiraEcho が合成をファイルエンドポイントだけでなく WebSocket ストリーミングで提供しているのはこのためだ。音声は生成されるそばからチャンク単位で送出される。Flash ティアでは初回パケットが 100 ミリ秒未満で返る——多くの聴き手が「間があった」と認識する閾値を下回る。
見落とされがちなもう半分：再生が生成に追いついてはいけない
ストリーミングは始まりの問題を解決するが、終わりに新しい問題を持ち込む。合成が実時間より遅ければ、プレイヤーは文の途中でバッファを使い切り、途切れる。**単語の途中で途切れるのは、きれいに 1.4 秒待たされるより悪い。**前者は故障として読まれ、後者は考えているように読まれるからだ。
つまりストリーミング実装には、1 つではなく 2 つの性質が要る。
- 初回パケットが十分に速いこと —— 再生を早く開始できる。
- 生成が再生より速いこと —— 開始後にバッファが枯渇しない。
90ms で再生を始めて、なお 30 秒の文章を途切れずに読み切れるのは 2 番目のおかげだ。ストリーミング TTS を評価するときは両方を測ること。初回パケットは優秀でも実時間より生成が遅い提供元は、初回パケットが平凡でも決して途切れない提供元より悪く聞こえる。
実務的な確認方法：長い文章を合成し、各チャンクの到着タイムスタンプを記録して、「受信済み音声の累計長」と「経過した実時間」を比較する。音声長の曲線が実時間の線より上にあり続けていれば余裕がある。2 本が収束していくなら、ネットワークの揺らぎ一回で途切れる状態だ。
どこで最も効くか
出力が長くなるほど合計時間と初回パケット時間の差は開くので、効果はプロダクトが「どれだけ喋るか」に比例する。
- 対話エージェントとコール自動化 —— 1 ターンごとに遅延コストを払うため、会話全体で累積する。ここではストリーミングは選択肢ではない。
- リアルタイムのナレーションや対話型アプリ —— ユーザーは何かが起きるのを見ている。沈黙はフリーズとして読まれる。
- 動画やオーディオブックのバッチ合成 —— ここでは初回パケット遅延より総スループットが実際に重要だ。リアルタイムで待っている人がいないからである。最適化すべき数字が違う。
最後の一点は明示しておく価値がある。**どの指標を見るべきかは、人が待っているかどうかで決まる。**2 時間のオーディオブックを夜間にレンダリングするなら初回パケット遅延は無意味で、測るべきは音声 1 時間あたりのコストだ。
まとめ
人が待つ場面では、合計合成時間ではなく初回パケット遅延を測る。そのうえで生成が再生を上回っていることを確認し、「出だしの速さ」が「途中の途切れ」に化けないようにする。この 2 つの数字は、どんな単一のスループット指標よりも、音声プロダクトの体感をよく予測する。
いまの構成がどのあたりにあるか確かめたければ、MiraEcho のストリーミング合成は無料で始められる——リクエストを 1 本投げ、チャンクのタイムスタンプを出力して、手元のものと比べてみてほしい。