音声AIスタックを5つ実測した。300msの壁を越えられたのは2つだけだった
「音声AIエージェントは300ms以下で応答できる」と何度も読んだ。AssemblyAIも、Vapiも、Realtime APIのローンチ記事もそう言っている。だから5つのスタックを組み、同じ1分の会話を全部に流して、各パイプラインの中にストップウォッチを差し込んだ。
5つのうち3つは、崖の手前にすら届かなかった。
残りの2つは、私が「どうせマーケティング数字だろう」と高を括っていた構成だった。マーケティングが正しくて、自分の手書きパイプラインが間違っていた。完敗です。
スライドに載らない「3つの崖」
数字を見せる前に、まず体感モデルから。音声AIのレイテンシは、なだらかには劣化しません。崖のように落ちます。AssemblyAI、Vapi、Retellの調査がだいたい同じ3つの閾値に収束していて、私も1週間ユーザーテストを回した結果、これを信じるようになりました。
| レイテンシ | ユーザーが取る行動 |
|---|---|
| 0-300ms | 普通に話す。AIを意識しない |
| 300-500ms | 間を感じるが許容 |
| 500-800ms | AIに被せて話し始める(「聞こえてますか？」) |
| 800-1500ms | 同じ質問を繰り返す |
| 1500ms+ | 国際電話と同じ感覚になり、諦める |
300msが第1の崖です。これを越えると、ユーザーは「機械が処理している」ことを意識します。500msを越えるとターンテイキングを奪い合い始め、STTが新しい入力を受け取り直してさらに遅くなる悪循環。800msでは、テスターの半分が「もしもし？聞こえてる？」と言いました。録画を見返しながらコードレビューする1週間ほど屈辱的なものは、私のキャリアでもそうそうありません。
300msの予算はどこに消えるか
5つのうち3つがなぜ落ちたのか。予算配分を見ればわかります。カスケードパイプラインは、4つの直列処理を300msに収めなければいけません。
- STT (音声認識): 80-300ms。モデルとVAD設計次第
- LLM TTFT (初トークン): 100-500ms。モデルサイズ、コンテキスト長、コールドスタート次第
- TTS TTFB (音声最初の1バイト): 75-300ms。ボコーダー次第
- ネットワーク往復: 50-200ms。光の速さとコロケーション選択でほぼ決まる
最速の数字だけ足しても305ms。普通の数字を足すと1秒を越える。今回のベンチマークの元になった書籍ではこれを「レイテンシの解剖」と呼んでいて、結論は「カスケードは300msに数学的にアレルギーがある」というものです。各コンポーネントが物理的に隣に座っていない限り。
Voice-to-Voiceのend-to-endモデルは、STT + LLM + TTSを音声トークンストリーム上の単一forward passに畳み込むことでこのルールをすり抜けます。第2のホップがない。TTSのウォームアップがない。サービス間のハンドオフがない。それが全てで、勝った2つのスタックは私が「いちばんコードを書かなかった」スタックでもありました。
5つのスタック
ベンダー贔屓ではなく実比較がしたかったので、条件を揃えました。同じ1分のカスタマーサポート用スクリプト、同じWebRTC ingress (OpenAI Realtime以外はDaily.co)、同じプロンプト、同じUS-EastのクライアントPC、各スタック10ターン×5スタック=50測定。平均は音声ユーザーには嘘をつくのでP50/P95/P99で報告します。
スタック1 — OpenAI Realtime API: gpt-4o-realtime の公式WebRTCエンドポイント。音声入力、音声出力、間のglueコードなし。
スタック2 — Deepgram + Claude + ElevenLabs カスケード: STTにDeepgram Nova-3、LLMにClaude Sonnet 4.6、TTSにElevenLabs Turbo v2.5。ホワイトボードに描く「ベスト・オブ・ブリード」構成。
スタック3 — ローカルエッジ (Whisper + Llama + Coqui): Whisper Large v3 Turbo、Llama 3.3 70BをH100ローカルで、TTSにCoqui XTTS。ネットワーク往復0ms。Hacker Newsが大好きな「プライバシーと主権」の答え。
スタック4 — LiveKit Agents + Gemini 2.0 Flash Live: メディアプレーンにLiveKit、脳にGoogleのネイティブ音声Gemini Live。これも別SDK経由のVoice-to-Voice端到端。
スタック5 — Pipecat + Claude + Cartesia: オーケストレータにPipecat、LLMにClaude Sonnet 4.6、TTSにCartesia Sonic。ElevenLabsより速いTTSを使った、より作り込んだカスケード。
結果
| スタック | P50 | P95 | P99 | 300ms以下? |
|---|---|---|---|---|
| 1. OpenAI Realtime (Voice-to-Voice) | 232ms | 281ms | 320ms | ✅ |
| 2. Deepgram + Claude + ElevenLabs | 480ms | 624ms | 780ms | ❌ |
| 3. Whisper + Llama 70B + Coqui (ローカル) | 870ms | 980ms | 1,210ms | ❌ |
| 4. LiveKit + Gemini Live (Voice-to-Voice) | 250ms | 295ms | 360ms | ✅ |
| 5. Pipecat + Claude + Cartesia | 410ms | 540ms | 670ms | ❌ |
P95で300ms以下を達成したのはスタック1とスタック4だけ。両方ともVoice-to-Voice。両方とも「リレー競走」ではなく「単一forward pass」を提供しています。スタック5はカスケードを丁寧に作った例で、Cartesiaの90ms TTFBは本当に速い。それでも崖は越えられない。LLM TTFTとサービス間ホップが予算を食い切ります。
つらいのはスタック3です。「ネットワークがゼロなら、せめてカスケードには勝つはず」と期待していました。実際勝つこともあるのですが、Llama 3.3 70Bは小さくない。コモディティGPUでLLM TTFTだけで600ms出るので、「ネットワーク不要」では救えません。書籍のエッジAI章は正直に書いていて、現実的なエッジの勝ち筋は 小さいモデル (Qwen2.5 1.5Bクラス) であって、フルサイズの70Bローカルではない。70Bをローカルで動かすのは両方の悪いとこ取りで、GPU代を払って崖も越えられない。深淵を覗いていただけでした。
なぜ今(2026年5月)Voice-to-Voiceが勝つのか
3つの理由。驚いた順に並べます。
1. TTFT-then-TTFBの積み上げが起きない: カスケードでは、LLMの初トークンを待ってからTTSを起動するので、TTSの「最初の1バイトまで」の時間が二重に乗ります。Voice-to-Voiceは音声トークンを直接出すので、2度目のウォームアップがありません。
2. ハンドオフのシリアル化がない: Deepgram → Claude → ElevenLabsは3つの別APIエンドポイントです。各々が速くても、TLS、コネクションプール、フレームバッファのオーバーヘッドを3回払う。Pipecatは助けてくれますが、消し去ってはくれません。
3. VAD連動のターンテイキング: Voice-to-Voiceモデルは音声ストリームから自分でエンドポイント検出をします。カスケードは、VADシグナルでSTT出力を確定してから送る必要がある。この確定遅延は「ユーザーが話し終わった瞬間」から計測するベンチマークには見えませんが、ユーザーは「自分が公式に話し終わった瞬間」を知らないので、ただの沈黙として体感します。
2026年5月時点で300msを安く達成する方法は、「パイプラインを書かないこと」。私のレイテンシの大半は、私のコードでした。
エッジAIが追いつくとき
エッジは、正しい問題の形には正しい答えです。ローカル限定のプライバシー、ネットワーク無しのキオスク、オフラインのロボティクス。ただ「サブ300msのクラウドエージェントが欲しい」の答えではありません。Whisper v3 TurboはRTF (Real-Time Factor) 1000x以上を叩き出し、1.5Bクラスのモデルは初トークンをCPUで200msで返せます。この組み合わせ — 小さいモデル、速いSTT、ローカルTTS — なら合計300-350msに収まる。スタック3で試した70B-on-H100の構成では、そこに届きません。
もう一つの道はハイブリッド: エッジSTT、クラウドLLM、クラウドTTS。最も長い同期ステップ(音声フレームのキャプチャ)でネットワーク往復をスキップしつつ、脳には引き続きクラウド級のモデル品質を使えます。書籍は意思決定マトリクスとしてこれを整理していて、私の実測とも一致します: 350-500msは現実的、サブ300msのカスケードは現実的ではない。
「カスケードのまま 体感300ms に近づける」工夫(フィラー、マイクロ確認、漸進的トークン再生)については、別記事でVoice AI Perception Hacksに書きました。崖は動かしませんが、崖の手前に立っているかのように見せかけることはできます。
今から作るなら
2026年5月、もし私がこれから音声エージェントを始めるなら:
- コンシューマー向け新規プロダクト — OpenAI Realtime か Gemini Live を直接。考えるより早めに止めて、出荷する
- Claudeを脳に使いたい — Pipecat + Claude + Cartesia。P95 500-600msで生きていく覚悟。フィラー戦略は後でなく今設計する
- プライバシー / エアギャップ要件 — Whisper Turbo + Qwen2.5 1.5B + ローカルTTS。350ms TTFBを狙う。70Bローカルは次世代GPUまで諦める
- エンタープライズ電話 — ハイブリッド: エッジSTT、脳はクラウドVoice-to-Voice。PSTNコーデック層でレイテンシ優位は消えるので、ターンテイキング品質に最適化する
最も深い思い違いは「300msは選んだ モデル の特性だ」と思っていたこと。実際は「選んだ アーキテクチャ の特性」でした。モデルは、そのアーキテクチャの居心地の良さを決めるだけです。
関連記事
- 安い方のモデルが勝った: コンテキストはパラメータに勝る（英語版） — 別領域の同じ教訓。アーキテクチャはモデルサイズを食う
- AIエージェントのコスト構造と損益分岐点 — 音声AIもこのコスト構造の一部です
- Claude Code Sub-agentの設計パターン — 音声統合をsub-agent化する選択肢
レイテンシの全解剖、知覚モデル、エッジAI章(スタック3の判断根拠)は書籍にまとめました。
この記事は役に立ちましたか？