音声AI遅延の3つの崖 200/300/800ms

音声AIの応答遅延はなだらかに悪化しません。崖のように、段階的に落ちます。

私は最初、これを勾配だと思って設計していました。「500msを400msに、400msを300msに」と直線で改善していけば、体験は徐々に良くなるはず。半年運用した結論は真逆です。数字が10ms動いても体験が全く変わらない区間があり、10ms動いた瞬間に評価が反転する区間もある。改善は階段状に効きました。

カスケード構成を525msから300ms未満に詰めた実装を回しながら気づいたのは、この階段の位置が200ms/300ms/800msに揃うことです。私の勘ではありません。会話言語学とベンダー各社のUX調査が、独立にこの3つの数字に到達しています。

3つの閾値の内訳はこうです。

• 200ms: 人間の会話ターンの中央値 (Stivers et al. 2009, PNAS)
• 300ms: AI応答が「機械っぽい」に転じる境界 (AssemblyAI 300ms Rule)
• 800ms: 「もしもし?」が発生する会話崩壊点 (Retell AI benchmark)

3つは意味も出典も違います。まとめて「レイテンシ」と丸めて設計すると、どこで壊れているのか特定できません。

第1の崖 200ms: 人間の会話ターンの物理

Stivers et al. の2009年のPNAS論文は、10言語を横断してターンテイキング(話者交代)の間隔を実測しました。英語、日本語、デンマーク語、オランダ語、イタリア語、韓国語、ラオ語、ツェルタル語、イェリ・ドニェ語(パプアニューギニア)、ǂĀkhoe Haiǁom語。全10言語で、発話終端から次発話開始までのタイミングが約200msに集約されます(言語横断中央値は+100ms、モードは0-200msに分布)。

これは相当な発見でした。文化や言語構造の違いを越えて、人間の会話ターンは200ms前後で回っている。0.2秒。まばたきよりも短い時間です。

音声AIが「自然な会話」を目指す限り、この200msが最終目標になります。ただし人間はここに達するために「聞きながら考える」並列処理をしています。相手の発話が終わる前に応答準備を始めている。同じ論文で著者らが指摘しているとおり、聞き取り完了を待ってから応答計画を始める逐次処理では物理的に間に合いません。

つまり200msは目標であって、越えられる崖ではないと私は理解しました。

第2の崖 300ms: 「機械っぽい」が始まる境界

AssemblyAIが「The 300ms Rule」として提唱している閾値です。応答レイテンシが300ms以下なら、ユーザーはAIと話していることを意識せず対話を続ける。300msを越えると体験の分類が「会話」から「機械の応答」に移る、という主張です。GoodCallのリアルタイム音声認識ベンチマークも、推奨閾値として同じ300msを置いています。

私自身、TTFBを100ms台に詰めた記事で書いたとおり、300msの前後で「返ってきた」から「会話が続いている」に体感の分類が不連続に動くのを確認しました。数字は300ms前後の差でも、体験の分類は連続関数ではありません。

なぜ300msが境界なのか。人間の会話ターンが200msなのに、300msだけで既に「機械」と判定されるのは奇妙に見えます。ここには2つの要因があります。

1. 人間側の余裕代: 200msは中央値であって、人間同士でもばらつきがあります。300msは人間側の分布上限に近い
2. 不連続な認知処理: 300msを越えると聞き手は「相手が処理している」ことを意識し始める。処理を意識した瞬間、対話モードから評価モードに切り替わる

私は最初、この「不連続」を数字を丁寧に測れば解けると思っていました。無理でした。人間の脳がどこで会話モードから抜け出すかは、私のストップウォッチの外側の話です。

第3の崖 800ms: 「もしもし?」が発生する会話崩壊

Retell AIのAI Voice Agent Latency Face-Off 2025というベンチマーク調査は、800msを「会話が失われ始める閾値」と位置づけ、この境界を越えるとユーザーが被せ話しを始め信頼が落ちると報告しています。800msは人間の会話リズム(200ms)の4倍。人間の脳は「相手が聞き取れなかった」と誤判定します。

この崖を越えると、以下の行動が発生します。

• 同じ質問を繰り返す。STTが新入力を受け直し、処理がリセットされる
• 「聞こえてますか?」と割り込む。Vapi AIの解説記事でも、500msを越えたあたりからユーザーがAIに被せて話し始める現象が報告されています
• 通話を切る

800msに落ちる構成は、部分ストリーミングでもフィラーでも救えないというのが実装上の実感です。ここに落ちる設計は、部分最適化を積み重ねるより根から作り直したほうが早い。

Nielsenの3閾値との違い

「音声AIの3つの崖」を語るとき、Jakob Nielsenの3閾値(100ms / 1秒 / 10秒)を持ち出す解説を見かけます。両者は別物です。

Nielsenの100msは「ボタンを押した反応が即応に見える限界」であって、会話ターンの話ではありません。会話は「相手のターンを待つ」という別の物理を持っています。私も最初は同じ100msだろうと甘く見て、Nielsenの教科書を音声AIに輸入しかけました。輸入禁制品でした。

カスケード構成で3つの崖をどう越えるか

音声AIのカスケード構成(STT→LLM→TTS)は、最速部品でも合計525msから逃げられません。300msの崖を越えるのは、そのままでは物理的に不可能です。

私が実運用で使っている手法は3つあり、カスケード525ms→300ms未満の3手法記事に実装ノートを書きました。

• 部分ストリーミング: 逐次処理を捨て、20-30msフレームでSTT/LLM/TTSを並行実行
• 予測発話: 初回ターンでKVキャッシュが効かない510ms問題を、短いフィラーの先出しで隠す
• TTS早出し: TTFBが75-100ms台で固定できるベンダーを選ぶ

これら3手法を積んで、体感TTFA (Time to First Audio) を50-210msに落とせました。300msの崖はここで越えられます。800msの崖は、この300ms未満の位置に近づく設計を組めば自然に遠ざかります。

Speech-to-Speech統合モデル (OpenAI Realtime API、Gemini Live API) は、STT→LLM→TTSの2度のホップを畳み込むことで別ルートで崖を越えます。ただし2026年時点で私が5スタック実測した結果では、P95で300ms未満に届いていたのはOpenAI RealtimeとLiveKit+Gemini Liveの2つだけでした。統合モデルであれば自動的に速いわけではありません。

まとめ

音声AIの応答遅延には、200ms/300ms/800msの3つの物理閾値があります。200msは人間の会話ターンの物理、300msはAI体験の「機械っぽい」境界、800msは会話崩壊点。3つは意味も出典も違う独立した閾値です。

• 「遅延」を1変数として扱うと、どこで壊れているか特定できない
• カスケードで300msを越えるには部分ストリーミング / 予測発話 / TTS早出しの3手法
• 統合モデルは別ルートだが、自動的に速いわけではない

崖を測るストップウォッチと、崖の手前で設計するストップウォッチは、別物です。

この3閾値がなぜ独立に成立するのか(会話言語学、知覚心理学、電話帯域のUX)は、書籍 voice AI 300msのUX設計 の第1章から第4章で解剖しています。設計チェックリストは第12章に置きました。

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev