音声AIの体験が崩壊する3つの崖 — 300ms・500ms・800msで何が起きるか
音声AIに話しかけて、2秒後に完璧な回答が返ってきた。内容は100点。でも会話としては0点。それは「正しい答えを遅く返す」のは「間違った答えを速く返す」より体験が悪い場合がある、という残酷な事実を示しています。
その違和感の正体は レイテンシ です。
筆者はWebRTCを用いたリアルタイム通信プロダクトの開発に長年携わり、AIとの会話プロダクトを構築した際に、まさにこの「レイテンシの壁」に直面しました。本記事では、その現場経験と2026年3月時点の最新技術動向を交えて、音声AIのレイテンシがユーザー体験に与える影響を体系的に解説します。
人間の会話は200msで回っている
まず前提を共有します。 人間同士の会話のターン交代は平均200msです。
2009年、Max Planck Institute for Psycholinguisticsが10言語(英語、日本語等)を対象に調査した結果、すべての言語で話者交代時の沈黙は平均約200msでした。
200ms。まばたきよりも短い時間。しかも相手が話し終わってから200msで応答を開始するには、 話し終わる前に応答の準備を始める 必要があります。人間は「聞きながら考える」並列処理をしているのです。
一方、現在の音声AIは700-1000ms。 人間の3-5倍遅い。 対面の会話と国際電話くらいの差があります。
第1の崖: 300ms — 自然な会話の限界
AssemblyAIの「300msルール」によれば、 300ms以下の応答は「自然な会話」として成立 します。ユーザーはAIと話していることを意識せず、対話に集中できます。
GoodCallの調査でも、リアルタイム音声認識のベンチマークとして300ms以下が推奨されています。
300msを超えた瞬間、「コンピュータが処理している」という意識が生まれます。Alexaに話しかけたときの、あの微妙な「間」です。
第2の崖: 500ms — 被せ話しの閾値
Vapi AIの分析によると、 500msを超えるとユーザーがAIに被せて話し始めます。 ZoomやGoogle Meetで何度も相手と被ってしまう、あの現象の原因がまさにこれです。ネットワーク遅延で500msの沈黙が生まれると、双方が「自分のターンだ」と判断して同時に話し始めます。
人間は沈黙が500ms続くと、「相手が話さないなら自分が話す」と判断します。これは人間同士の会話でも同じ。500msの沈黙は「あなたのターンですよ」というシグナルです。
これが起きると、STT(音声認識)が新しい入力を受け取り、処理がリセットされます。結果、レイテンシがさらに増大する 悪循環 に陥ります。
| レイテンシ | ユーザーの行動 |
|---|---|
| 0-300ms | 自然に会話を続ける |
| 300-500ms | やや間を感じるが許容 |
| 500-800ms | 被せて話し始める |
| 800ms-1.5s | 「聞こえてますか？」 |
| 1.5-4s | タスク放棄を検討 |
| 4s超 | 離脱 |
第3の崖: 800ms — 会話の崩壊
Retell AIのベンチマーク調査では、 800ms超の応答は「国際電話のような違和感」 を生むと報告されています。
800msは人間の会話リズム(200ms)の4倍です。国際電話で「もしもし？聞こえますか？もしもし？」を繰り返した経験がある人なら、この感覚がわかるはずです。
この遅延では、ユーザーは以下の行動を取ります。
- 同じ質問を繰り返す
- 「聞こえてますか？」と確認する
- 通話を切る
Crestaの研究では、 1.5秒を超えると体験が「急激に劣化」 し、回復が困難になることが確認されています。1.5秒あれば、ユーザーは「このAI大丈夫かな」と思い、3秒あれば別のアプリを開いています。
さらに800msを超えるとレイテンシ以上に体験を悪化させる現象が発生します。 エコー です。ユーザー自身の声が1-2秒遅れて返ってくる現象は極めて不快で、会話の継続を困難にします。
なぜ遅いのか — パイプラインの解剖
パイプラインを分解して計測してみましょう。
マイク → 音声キャプチャ → STT(音声認識) → LLM(推論) → TTS(音声合成) → スピーカー
各段階のレイテンシを積み上げると、普通に設計しただけで合計2秒を超えます。料理に例えるなら、一流シェフが5皿のコースを順番に作るようなもの。前菜が終わるまでメインには手をつけない。お客は空腹で倒れます。
各コンポーネントのレイテンシ
| コンポーネント | 最速 | 通常 | 最悪 |
|---|---|---|---|
| STT | 200ms | 350ms | 500ms |
| LLM | 150ms | 500ms | 1000ms |
| TTS | 75ms | 200ms | 300ms |
| ネットワーク | 50ms | 150ms | 300ms |
| その他(VAD等) | 50ms | 100ms | 200ms |
| 合計 | 525ms | 1,300ms | 2,300ms |
最速で構成しても525ms。通常なら1.3秒。 第1の崖(300ms)はおろか、第3の崖(800ms)すら超えます。 F1マシンのパーツを全部集めたのに、組み立てたら軽自動車より遅い。それがカスケードパイプラインの皮肉です。
カスケードパイプラインのもう1つの問題 — エラー伝播
遅延だけではありません。カスケード(STT→LLM→TTS)には エラー伝播問題 があります。
STTが"flight"を"fright"と誤認識した場合、LLMは間違った前提で推論を行い、TTSは間違った内容を自信満々で音声化します。伝言ゲームの恐怖です。最初の1人が「飛行機」を「恐怖」と聞き間違えたら、最後の人は堂々と「あなたの恐怖体験をお聞かせください」と返してくる。
2026年3月 — 各社の回答
では、現時点で各社はこの問題にどう取り組んでいるのか。
OpenAI Realtime API: 150-250ms
2024年10月に公開されたOpenAI Realtime APIは、音声AI業界のパラダイムシフトです。
WebRTC接続時の実測値:
- テキスト応答: 150-250ms
- 音声応答: 220-400ms
従来のSTT→LLM→TTSカスケードではなく、 Speech-to-Speech統合モデル(GPT-4o) が音声から音声への直接変換を行います。中間変換ステップを省略し、エラー伝播も回避。
ただし電話回線(SIP)経由ではコーデック圧縮によりレイテンシ優位が消失するため、WebRTCダイレクト接続時のみ真価を発揮します。高速道路専用のスポーツカーを一般道で走らせても意味がないのと同じです。
Gemini Live API: sub-800ms
Googleは10年超のGoogle Assistant開発の教訓を結晶化し、 Gemini 2.5 Flash Native Audio モデルでSTT→LLM→TTSパイプラインを単一モデルに統合しました。
sub-800msの一貫したレイテンシを実現。カスケード処理を排除した統合推論により、中間バッファリング遅延を大幅に削減しています。
Pipecat + LiveKit: 500ms voice-to-voice
オープンソース勢も健闘しています。 Pipecat (AIパイプラインオーケストレーション、Python) + LiveKit (WebRTC SFUサーバー、Go) の組み合わせで、同一GPUクラスター内に全モデルをホスティングすることで 500ms voice-to-voice を達成。
Pipecatは20-30msのフレーム単位で処理を行うFrame-basedストリーミングモデルを採用し、自動割り込みハンドリングも備えています。
Deepgram Nova-3: sub-300ms STT
STT単体では、Deepgram Nova-3が sub-300ms を実現。さらに Flux端末検出 により、従来のVAD(Voice Activity Detection)を超えた自然なターンテイキングを提供しています。
Fluxは音声活動の有無だけでなく、 意味的な文脈 を考慮した端末検出を行うため、「えーと」の後の自然なポーズを発話終了と誤検出しません。
Cartesia Sonic 3: 40ms TTS
TTS側では、Cartesia Sonic 3が 40ms Time-to-First-Audio を達成。人間のまばたき(100-150ms)より速い。感情表現対応、15言語ネイティブ対応です。
各アーキテクチャの比較
| アーキテクチャ | E2Eレイテンシ | 300msの崖 | 800msの崖 |
|---|---|---|---|
| OpenAI Realtime(WebRTC) | 150-250ms | ✅ クリア | ✅ クリア |
| Gemini Live(統合) | sub-800ms | ✗ | ギリギリ |
| Pipecat+LiveKit(OSS) | 500ms | ✗ | ✅ クリア |
| カスケード(最適化済み) | 525ms+ | ✗ | ✅ クリア |
| カスケード(通常) | 1,300ms | ✗ | ✗ |
計測から始めよう
レイテンシの最適化は計測から始まります。
- コンポーネント別計測: STT / LLM / TTS 各段階のレイテンシを個別に記録
- E2E計測: 実際の通話をシミュレーションし、ユーザー体感レイテンシを記録
- パーセンタイル計測: 平均値ではなくP50/P95/P99で評価
平均500msでも、P99が3秒なら、100回に1回は体験が崩壊します。レストランの平均待ち時間が10分でも、100回に1回1時間待たされるなら、そのレストランのレビューは荒れます。
まとめ
音声AIのレイテンシには、ユーザー体験が段階的に崩壊する 3つの明確な崖 があります。
| 崖 | 閾値 | 何が起きるか | 設計対応 |
|---|---|---|---|
| 第1の崖 | 300ms | 「自然な会話」の終わり | 目標ライン |
| 第2の崖 | 500ms | ユーザーが被せて話す | フィラー必須 |
| 第3の崖 | 800ms | 会話が崩壊する | 設計見直し |
2026年3月時点で、OpenAI Realtime API(WebRTC)が150-250msで第1の崖をクリアしている一方、通常のカスケードパイプラインは最適化しても525ms — 第2の崖の手前が精一杯です。
しかし希望はあります。ストリーミング設計、知覚ハック(フィラー挿入や感情認識)、エッジAI実行を組み合わせることで、カスケード構成でも 体感300msは射程圏内 です。
技術の最適化で600msまで縮め、心理学で体感300msにする。どちらか一方では不十分。 両方を組み合わせる のが、2026年現在の現実的な解です。エンジニアリングだけでも心理学だけでもダメ。音声AIは「速さの科学」と「待たせ方の芸術」の合作なのです。
参考文献
- Stivers, T. et al. "Universals and cultural variation in turn-taking in conversation." PNAS, 2009.
- AssemblyAI. "The 300ms Rule: Why Latency Makes or Breaks Voice AI Applications."
- Cresta. "Engineering for Real-Time Voice Agent Latency."
- OpenAI. "Realtime API Guide." 2024.
- DEV.to CloudX. "Cracking the <1-second Voice Loop: What We Learned After 30+ Stack Benchmarks." 2025.
Discussion