← ブログに戻る

voice AI TTFBを100msに詰めた実測

/ 5分で読めます / voice-ai · ttfb · streaming · latency · tts

音声AIのレイテンシを触ってきた中で、いちばん効いた指標がTTFB(Time-to-First-Byte)でした。過去の「5スタック実測比較」「barge-in制御」とは別軸で、TTFBだけを詰めた実測ノートです。

最初の1バイトが出るまでの時間を100ms台に詰めたとき、300msの壁が動きました。英語圏で「sub 300ms voice ai」と呼ばれる領域を、日本語話者向けに書き残します。

TTFB(最初の1バイト)が体験を決める

人間の会話は最初の一言で成立します。相手が「はい」と口を開いた瞬間、応答が返ってきたと認識します。その後の内容が20秒続いても、最初の反応が300msなら「テンポの良い会話」に分類されます。

音声AIも同じでした。

ユーザーが最初の音を聞くまでの時間、つまりTTFBが体験の評価を決めます。応答全体の処理時間はここでは効きません。私が最初にこの区別を怠ったとき、レイテンシ計測値は1.2秒。ユーザーテストの評価は最低でした。

TTFBを1指標として立てた瞬間、設計が変わりました。

逐次処理は寿司屋で全皿そろうまで待つ客

従来の設計はこうです。ユーザー発話をSTTで文字起こしし、LLMが応答全文を生成し、TTSが全文を音声合成してから再生する流れです。

[ユーザー発話] → STT(300ms) → LLM全文(1200ms) → TTS全文(600ms) → [再生]
                                                              ↑ ここまで2100ms

10語の応答を生成するとき、10語すべてがそろうまでTTSは動き出しません。寿司屋で全10貫がそろうまで1貫も出さないような設計です。回転寿司が偉大な発明である理由がここにあります。

私はこの設計を半年運用しました。ユーザーは「遅い」と評価しました。数字は嘘をつきません。

ストリーミング設計で最初の1文だけ先に出す

解決策は、全体の完了を待たずに最初の断片が生成された時点で次工程に渡すストリーミングです。

[ユーザー発話] → STT → LLM(1文目) → TTS(1文目) → [再生開始]
                        LLM(2文目) → TTS(2文目) → [継続再生]
                        LLM(3文目) → TTS(3文目) → [継続再生]

最初の文が生成された時点でTTSに渡す。TTSの最初のオーディオチャンクが生成された時点で再生を開始する。この設計に切り替えた瞬間、TTFBは600-1000msに落ちました。

TTFBと全体応答時間の対比。TTFBは最初の1バイトが出るまでの時間、全体応答時間は最後の音まで再生し終わるまで

体感が変わったのは、300msを切った瞬間でした。600-1000msでは足りません。人間のまばたきは100-150ms、まばたき3回以内に応答が返るなら会話として成立します。この不連続な閾値の存在は先行研究でも報告されています。

TTS公称値と実測値のギャップ

ここでハマりました。TTSベンダーの公称レイテンシと、私のユーザーが最初の音を聞くまでの時間、この2つは別物です。

サービス公称値実測TTFA中央値備考
Cartesia Sonic 3sub-90ms166-190ms42言語、感情対応
Cartesia Sonic Turbo40ms(計測せず)速度特化、9言語のみ
ElevenLabs Flash v2.575ms実測で上に往復が乗る32言語

Cartesia Sonic 3の公称sub-90msは、モデル推論時間のみを指しています。第三者による実測では、TTFA中央値は166-190ms。公称値の倍以上でした。

よく引用される40msはSonic Turbo(9言語) の数字で、Sonic 3のTTFAとは違います。引用されるうちにモデル名が落ちる、あの現象です。ElevenLabsは自社ドキュメントで「75msはモデル推論時間のみを指し、実際のend-to-endレイテンシはロケーションとエンドポイント種別で変動する」と明記しています。

バジェットに積むのは実測値のほうです。

公称値を根拠に300ms設計を組むと、丸ごと外します。

LLMのFirst Token Latencyも合算する

TTFBの正体は「STT + LLM first token + TTS first chunk + ネットワーク往復」の合算です。

  • STT: Deepgram Nova-3で sub-300ms、Fluxで自然なターン検出
  • LLM first token: GPT-4o(Realtime API)で実測300-500ms、コンテキスト短ければ下振れ
  • TTS first chunk: Cartesia Sonic 3で166-190ms(実測)
  • ネットワーク: リージョンによって30-100ms

合算すると600-1000ms。この時点で300msには届きません。

私は3段階で削りました。第1段階はTTSを高速サービス(Sonic 3 / Flash v2.5)に切り替えて500ms。第2段階は小型LLM(7-13Bクラス)に変えて300ms前後。第3段階でSTTとLLMをエッジで実行して100ms台。

300msの壁が動いた瞬間

第2段階で300msを切ったとき、ユーザーテストの評価が変わりました。応答が「返ってきた」から「会話が続いている」へ、分類そのものが動く。数字は300ms前後の差ですが、体験の分類は不連続です。

TTFB 300ms、これが今の私の設計原点です。

最初の1バイトが返るまでの時間、これを1指標として詰める対象に据えたとき、他のメトリクス(全体応答時間、品質、コスト) は自然に付随してきました。全体を追いかけていたときは、どれも中途半端でした。

まとめ

  • 音声AIの評価軸は TTFB(Time-to-First-Byte) 。全体応答時間より最初の1バイトを先に詰める
  • 逐次処理設計(2100ms)をストリーミング設計(600-1000ms)に切り替え、さらにTTS/LLMを高速サービスに置き換えて 300msの壁を突破
  • TTSベンダー公称値は推論時間のみ。実測TTFAは倍以上。バジェットは実測で組む
  • 300msを境に、体験の分類が「返ってきた」から「会話が続いている」に不連続に変わる

barge-inで割り込まれる問題を扱った 音声AIの barge-in 実装で認識精度が22%落ちる話 と組で読むと、音声AIのUX設計の両輪が揃います。

本記事の設計思想は書籍 voice AI 300msのUX設計 の「カスケードパイプライン分解 — STT / LLM / TTS」で扱っている全体設計を、私の実測で切り出したものです。

音声AIの300ms 関連書籍 音声AIの300ms 音声AI レイテンシ 設計 | Pipecat・LiveKit・Deepgram で525msの壁を突破 書籍ページを見る →

関連する記事

記事一覧を見る →