ボイスAIのベンダーはどこもレイテンシーの数値を掲げています。Vapiは500ms、Retellは800ms、SynthflowはSTT ~300msをうたうDeepgramのブログを引用します。しかし問題は、それらの数値のどれ一つとして、電話の向こう側にいる発信者が実際に耳にしているものを表していない、という点です。
私たちは6週間かけて、本番稼働中の5つの音声プラットフォーム（Retell、Vapi、Synthflow、Deepgram Voice Agent、Finn）に対し、US-East、EU-West、インドの各ルートでオープンなテストハーネスを走らせました。本記事では、P50/P90/P99の実測値、読者自身が再現できる測定手法、そしてベンダーがマーケティング用グラフから静かに省いているパイプラインの各段階を公開します。
「レイテンシー」という数値が的外れな理由
ベンダーがlatency: 500msと打ち出すとき、それはほぼ必ずTTFB、つまりユーザーの発話終了からTTSが最初の音声バイトを出力するまでの時間を指します。エンジニアリング上は有用な指標です。ただし、ユーザーが体感するものではありません。
ユーザーが体感するのはターンテイキングの遅延、すなわち自分が話し終えてから自分がエージェントの声を聞くまでの沈黙です。この数値には次が含まれます。
- エンドポインティングの遅延 — VADが「話し終わった」と判断するまでの待ち時間（通常は意図的な無音200〜600ms）。
- SIP/WebRTC区間におけるネットワークジッターバッファ（40〜120ms）。
- TTSの初回バイトから再生可能になるまで — 最初のチャンクは、ジッターに耐える再生ができるだけの大きさが必要です。
- ユーザーが応答の途中で割り込んだ際の**バージインからの復帰**。
TTFBを500msと公表していてもエンドポインティングに600msかけるプラットフォームでは、体感のターンテイキング遅延は1.2sを超えます。一方、800msとうたっていても150msの積極的なセマンティックエンドポインティングを備えたベンダーは、通話中に明らかに速く感じられます。マーケティング上の数値と人間が体感する数値は、そもそも同じ軸にありません。
CX研究から得られた目安：体感のターンテイキングが800msを下回れば会話らしく感じられます。800〜1200msは「AIだが許容範囲」。1.2sを超えると、発信者はエージェントに話しかぶせ始めます。
ボイスAIリクエストの内訳
以下は1ターン分のパイプライン全体と、2026年に5つのプラットフォームを横断して計測した中央値の内訳です。
| 工程 | 何が起きるか | 中央値 (ms) | P90 (ms) |
|---|---|---|---|
| SIP/WebRTC受信 | 音声フレームがメディアサーバーに到達 | 20 | 60 |
| VAD + エンドポインティング | ユーザー発話の終端を検出 | 280 | 520 |
| STTの確定処理 | 部分認識結果を強制的に確定 | 90 | 180 |
| LLMのTTFT | モデルからの最初のトークン | 320 | 780 |
| LLM → TTSの受け渡し | 文の区切り＋ストリーム開始 | 40 | 120 |
| TTSの初回バイト | 最初の音声チャンクを出力 | 180 | 410 |
| TTS → 再生可能 | 安全に再生を始められるバッファ量 | 60 | 140 |
| 送出側ジッターバッファ | キャリア側での平滑化 | 50 | 110 |
| 体感の合計 | 発話終了 → 最初の音声が聞こえるまで | ~1040 | ~2320 |
ベンダーが最も激しく競い合う2つの工程、すなわちLLMのTTFTとTTSの初回バイトは、中央値の予算全体のわずか~48%にすぎません。テール部分を支配しているのは、エンドポインティングとジッターの積み重ねです。
2026年ベンチマーク表 — 宣伝値ではなく実測値
以下の数値はすべて体感のターンテイキング遅延で、US-Eastの発信者 → 各ベンダーのデフォルトリージョン、8ターン固定のアポイント調整スクリプトを用いてプラットフォームごとに500ターンを記録したものです。ハードウェアはMac mini M4、Twilio Programmable Voiceの番号を介してPSTNへブリッジし、録音は当社のオープンなスクリプト（下記リポジトリにリンクあり）で解析しました。詳細な測定手法は次のセクションに記載します。
| プラットフォーム | 宣伝値 | P50実測 | P90実測 | P99実測 | バージインからの復帰 |
|---|---|---|---|---|---|
| Retell | ~800ms | 1180 | 1740 | 2680 | 410ms |
| Vapi（デフォルト） | ~500ms | 1020 | 1620 | 2510 | 380ms |
| Vapi（STT/LLMをカスタム） | — | 880 | 1410 | 2240 | 360ms |
| Synthflow | ~600ms | 1240 | 1980 | 3120 | 520ms |
| Deepgram Voice Agent | ~300ms STT | 940 | 1480 | 2390 | 290ms |
| Finn | — | 820 | 1290 | 1980 | 240ms |
ベンダーのベンチマークの多くが埋もれさせている要点は次のとおりです。
- どのプラットフォームもP90はおおむね**P50の1.5〜2×**です。平均値しか見ていなければ、下位10%の通話はまるで別製品のように感じられます。
- P99は必ず2秒を超えます。ユーザーが電話を切るのは、このテールレイテンシーの領域です。
- バージインからの復帰、つまり割り込まれたときにエージェントがどれだけ速く黙るかは、2×の開きがあります。この一つの数値こそが、TTFBよりも多くの「通話品質が悪い」という苦情を生んでいます。
この数値を再現する方法
テストハーネスは意図的に地味な作りです。独自の負荷生成ツールも合成SIPも使わず、実際の電話番号から実際のエージェントに発信し、マイクループバックによるタイムスタンプ計測装置で記録します。
よくある質問
sub-secondのレイテンシーとは実際には何を指しますか？
何を測っているかによります。モデルの推論時間、最初の音声までの時間、そしてマウス・トゥ・イヤーのレイテンシーは互いに別物であり、発信者が体験するのは最後の一つだけです。
ベンダーにはどのレイテンシー指標を求めるべきですか？
実際のキャリアを経由した実通話でのマウス・トゥ・イヤーを、平均ではなくテールで測った値です。平均が良くてもp95が悪ければ、20件に1件は使いものにならない通話ということになります。
なぜテスト時よりも本番のほうがレイテンシーが悪化したのですか？
たいていはネットワーク経路が原因です。ローカル接続でのデモは、本番の通話が負担しているキャリア区間とリージョン間のホップを飛ばしています。
