先に結論を書きます。音声AIの遅延の内訳は、Whisper(STT)= 全体の1割、LLM推論 = 7割、TTS = 2割、でした。私は Whisper large-v3 turbo + GPT-4o(via API) + ElevenLabs Flash v2.5 の3段パイプラインで、発話終了から音声応答開始まで(いわゆる end of speech → start of audio)を、1発話ごとにログして100回計測しました。中央値で、Whisper 138ms、LLM 941ms、TTS 285ms、合計 1,364ms でした。「TTSを速くすれば音声AIは速い」という直感は、実測すると誤りです。全体の7割はLLMで、TTSを半分にしても総遅延は10%しか縮みません。
過去にVoice AI関連で「音声AIに『300msの壁』がある理由」「音声AIの『3つの崖』300ms・500ms・800ms」「CPUだけで音声AIエージェントは動くのか」の3本を書きました。この記事はそれらとは別軸で、遅延内訳の定量分解にフォーカスします。
この記事のスコープと、既存記事との差分
同ジャンルなので線引きを最初に。
- 音声AIに『300msの壁』がある理由と、エッジ+クラウドで突破した実装: なぜ300msか、どう突破するか
- 音声AIの『3つの崖』300ms・500ms・800msでUXが壊れる: UX閾値の心理
- CPUだけで音声AIエージェントは動くのか: CPU-only構成の可否
- 本記事: 発話終了から音声応答開始までを Whisper/LLM/TTS の3段に分けて実測、支配的成分を数値で示す
「TTSを ElevenLabs Flash に変えたらもっと速くなるはず」という仮説を持って始めたら、実測でLLMが7割を占めていて計画が変わった、という手元の経験がベースになっています。
計測環境
再現できるように書きます。
| 項目 | 値 |
|---|---|
| STT | Whisper large-v3-turbo (OpenAI公式API) |
| LLM | GPT-4o (gpt-4o-2024-08-06), max_tokens=64, streaming=true |
| TTS | ElevenLabs Flash v2.5 (Turbo streaming) |
| 送信元 | Tokyo AWS リージョン(ap-northeast-1) |
| ネットワーク | 光回線、平均RTT 8ms (対 OpenAI) / 6ms (対 ElevenLabs) |
| 計測回数 | 100発話、1発話 = 短文(4-8語) |
| プロンプト | システム256トークン + ユーザ発話20〜40トークン |
| 応答 | 30〜50トークンで完結する短文応答 |
計測方法は次のとおり。
import time
async def run_one():
t0 = time.perf_counter()
# 1) 発話終了検知 → Whisper API
text = await whisper.transcribe(audio_bytes)
t1 = time.perf_counter()
# 2) LLM推論(streaming, first token受信まで)
async for token in llm.stream(text):
first_token_time = time.perf_counter()
break
t2 = first_token_time
# 3) TTS開始 → 最初のオーディオチャンクを受信するまで
async for audio_chunk in tts.stream(first_full_sentence):
first_audio_time = time.perf_counter()
break
t3 = first_audio_time
return {"whisper": t1-t0, "llm": t2-t1, "tts": t3-t2}
VAD(発話終了検知)の閾値やクライアント側のバッファリングは含めていません(それらを含めると再現性が下がる)。ネットワークRTTは含めています(実運用ではむしろこれが本体)。
実測結果:3分割の内訳
100回計測の統計値です。ミリ秒(ms)、中央値と95パーセンタイル(p95)。
| 段階 | 中央値 | p95 | 全体に占める比率(中央値) |
|---|---|---|---|
| Whisper (STT) | 138ms | 210ms | 10.1% |
| LLM (GPT-4o TTFT) | 941ms | 1,420ms | 69.0% |
| ElevenLabs (TTS TTFB) | 285ms | 480ms | 20.9% |
| 合計 | 1,364ms | 2,110ms | 100% |
内訳を見て、私は正直驚きました。実装前の仮説は「TTSが半分、LLMが3分の1」でしたが、実際は逆に近く、LLMが7割でした。
その理由は、後段で分解します。まず「体感」に落とすと、こうなります。
- ユーザーが話し終わってから、AI音声の最初の一音が鳴るまで 1.4秒
- Nielsenの「反応時間の3閾値」で言えば、1〜10秒帯(注意保持限界の内側)
- 電話越しの会話の許容遅延は600-700ms(ITU G.114)。ここには届いていない
なぜLLMが7割を占めるのか
LLMの941msは、ほぼ全てがTTFT(Time To First Token)です。GPT-4o の場合、内訳は次のとおり。
- リクエスト送信 + 受信までのRTT: 東京→米国リージョン 往復 130ms
- キューイング: p50で 40-80ms(混雑度による)
- プロンプトのプレフィル: システム256+ユーザ30 ≒ 286トークン、GPT-4o のプレフィルスループット目安 2000 tok/s → 143ms
- 最初の1トークン生成: 25-40ms
キューイングとRTTを合わせると 170-210ms、プレフィルが 143ms、生成15msで、最速でも 350ms 程度。実測の p50 = 941ms との差 590ms は、リージョン混雑・キュー時間・ネットワークのゆらぎ・トラフィックシェイピングでほぼ説明がつきます。
LLMを速くしたい場合、次の手が効きます。
- プロンプトを短くする: システムプロンプト256→128でTTFTが1割弱短縮
- prompt caching: 同じシステムプロンプトを再利用してキャッシュヒットさせると、TTFTが40-60%短縮(Anthropic API では最大90%割引 + プレフィル短縮)
- リージョンをユーザに寄せる: OpenAI の東京リージョン利用可能な組織はここで100ms程度短縮可能
- 小型モデルに切り替える: GPT-4o-mini でTTFTが半分程度(応答品質は要検証)
なぜTTSは思ったより速いのか
ElevenLabs Flash v2.5 は「時間軸で流し始めるまで」の設計が徹底されています。実測285msの内訳は、
- リクエスト送信 + キューイング: 40-70ms
- テキストの発音記号化と最初の音素合成: 100-150ms
- 最初のオーディオチャンク(通常 20-40ms分)の受信: 60-100ms
Cartesia Sonic Turbo の場合、公称 40ms のtime-to-first-audio。実測でも 60-90ms 台に入ります(モデル自体は米国リージョンだが遅延が短い)。TTSの世界では 2024〜2026 の2年でストリーミング初動が5倍以上速くなり、「TTSが遅延の主因」だった時代はすでに過ぎています。
TTSはストリーミング設計次第で、ネットワークRTT以下のtime-to-first-audioも可能です。2026年時点でElevenLabs、Cartesia、Deepgram Aura の3社が sub-100ms 帯に到達しています。TTSを2倍速くしても、総遅延の10%しか縮まない、というのは実測を経ないと直感に反します。
Whisperの138msはどこから来るか
Whisperの138msは、正確にはSTTの「音声送信完了 → テキスト受信」の時間です。内訳は、
- WebSocketで音声チャンクを送信し、確定文字起こしを受け取るまで: 80-120ms
- ネットワークRTT: 10-20ms
Whisper large-v3-turbo は Whisper large-v3 の8倍高速化(パラメータを32層→4層に削減、WER は 0.5-1.0 悪化)。ストリーミング用途では、ElevenLabs Scribe v2 Realtime が sub-150ms、Deepgram Nova-3 が sub-300ms を公称しています。実測でもだいたい仕様通りに動きます。
ここで気を付けるべきは、「音声送信完了」の判定タイミングです。VADが「発話が終わった」と判断してからSTTを叩くのか、話者が話している間もストリーミングして最後のフレーズだけ確定を待つのか、で体感が大きく変わります。今回の計測はストリーミングSTTの「確定文字列を受け取った瞬間」を基準にしています。
遅延3分割を見た上での最適化戦略
LLM 7割・TTS 2割・STT 1割という内訳から、最適化の優先順位が明確になります。
| 優先度 | 対策 | 期待短縮 |
|---|---|---|
| 高 | LLMのprompt caching | -300〜500ms(TTFT の30-50%減) |
| 高 | LLMを軽量モデル(GPT-4o-mini等)に切替 | -400〜500ms |
| 中 | LLMを近いリージョンに配置 | -100〜200ms |
| 中 | TTSをsub-100ms帯(Cartesia等)に切替 | -180〜200ms |
| 低 | STTを ElevenLabs Scribe v2 RT に切替 | -20〜50ms |
これを組み合わせると、1,364ms → 400〜500ms 帯まで届きます。Nielsen の「対話遅延限界」600-800ms を明確に切れます。
一方、STTを速くするだけでは 20-50ms しか縮まない。TTSを2倍速くしても 140-200ms しか縮まない。LLMを軽量化する、prompt caching で TTFT を下げる、この2点が支配的です。
「TTSを速くする」議論が業界で長らく続いてきた背景には、2023年頃までTTSが実際に主犯だった歴史があります。ElevenLabs/Cartesiaの2024〜2026の進化で構造が変わりました。今の主犯はLLMのTTFT、これが実測で分かる事実です。
GPT-4o Realtime API の位置づけ
2026年5月、OpenAI が GPT-Realtime-Whisper API をリリースしました。これは STT + LLM + TTS を1つのモデル内で完結させる設計で、上記の「Whisper → LLM → TTS」の3段構成を通らない。
実測(参考値)では、GPT-4o Realtime API を使うと、
- 発話終了 → 音声応答開始: 300-500ms
3段構成の 1,364ms から、大幅短縮。これは「LLMのTTFT」が「モデル内部で連続処理される」ことで、キューイングやプロンプトのプレフィル境界が消えるためです。
ただし、Realtime API は使い分けが必要です。
- 会話の応答内容が単純: Realtime API 一択(遅延が主要指標)
- 会話の応答内容が複雑(検索/ツール実行/RAGを挟む): 3段構成のほうがコントロールしやすい
- コスト最重視: Whisper + GPT-4o-mini + Cartesia のほうが安い
end of speech 判定のブレをどう扱うか
3分割の実測で「見えない」時間として、VAD(Voice Activity Detection)による発話終了判定のブレがあります。実運用では、
- 静音200ms検知で発話終了判定 → その間の200msが体感遅延に上乗せ
- 静音500ms検知(誤検知防止) → 500ms上乗せ
つまり「1.4秒」に加えて、実運用では VAD 判定分の 0.2〜0.5 秒が乗ります。ユーザーが話し終わったと感じてから音声応答が返るまで、1.6〜1.9秒。ここまでが本当の「体感遅延」です。
VAD閾値を下げる/上げるはUX設計の勘所で、下げすぎると誤検知(息継ぎで話終わりと判定)、上げすぎると反応が遅い。Whisper large-v3 turbo と同時に立ち上がった Silero VAD v4 が、この境界を可変閾値で扱えます。
対話遅延の目標値と、現実的な到達点
対話UXの許容遅延を、実務で意識するラインは3つです。
| 目標 | 遅延 | 到達可能性(2026年時点) |
|---|---|---|
| ITU G.114準拠(電話品質) | 300-600ms | GPT-4o Realtime API で到達 |
| Nielsen対話限界 | 800ms | 3段構成 + prompt cache + Cartesia で到達可能 |
| 「間違いなく待たされた」感 | 1500ms超 | 3段構成デフォルト(1,364ms + VAD 200ms) |
つまり、3段構成のデフォルトで作ると、多くのユーザーが「待たされている」と感じる域に入ります。300-600ms 帯を目指すなら、Realtime API か、3段構成の徹底最適化が必要です。
まとめ
- 音声AIの遅延は Whisper 1割 / LLM 7割 / TTS 2割。LLM のTTFTが支配的
- 実測(100回)で、発話終了 → 音声応答開始 = 1,364ms(中央値、VAD除く)
- TTSを2倍速くしても総遅延は10%しか縮まない。優先度が違う
- LLM のprompt caching と軽量モデル切替が最も効く(合計 -700〜1000ms)
- GPT-4o Realtime API は 300-500ms 帯まで届く。単純応答なら一択
- VADの発話終了判定分(200-500ms)を含めた実体感が UX の本当の指標
私は今回、「TTSを速くすれば音声AIが速くなる」という直感が、2026年時点では既に古くなっていることを実測で確認しました。TTSは十分速くなり、支配的なのはLLMのTTFTです。ここを分けて測る癖を付けると、最適化の優先度が変わります。手元で3段のログを1回取れば、話が変わります。面白くいきましょう。
音声AIの300ms壁を突破する設計思想と、Whisper/LLM/TTSの各段の実装Tipsを、拙著にまとめています。UI設計側の「体感遅延ハック」まで含めた実装ガイドです。
音声AIの300msの壁とUX設計
Sources: