200msの壁 — Voice AIエージェントのレイテンシ設計

人間の会話における応答速度

人間同士の会話では、一方が話し終わってから相手が話し始めるまでの時間（ターンギャップ）が驚くほど短いことが、言語学の研究で明らかになっています。 Stivers et al.（2009）の大規模な多言語調査によると、ターンギャップの中央値はわずか約200msです。 これは日本語を含む10言語で共通して観察された普遍的な特性であり、人間の会話処理能力の根本的な制約を反映しています。

200msという値は、人間が相手の発話を聞き終わる前から次の応答を準備し始めていることを意味します。 実際、脳科学の研究では、相手の発話が終わる約600ms前から応答の言語プランニングが開始されることが確認されています。 つまり、人間は「聞いてから考えて話す」のではなく、「聞きながら考えて、聞き終わると同時に話す」のです。

Voice AIパイプラインの構成

Voice AIエージェントが音声入力を受け取ってから応答を返すまでには、複数のステージを順次処理する必要があります。 各ステージが積み重なった合計がエンドツーエンドのレイテンシとなるため、パイプライン全体を俯瞰して設計することが重要です。

graph LR
  A["🎤 VAD\n発話検出\n~30-50ms"] --> B["📝 STT\n音声認識\n~100-300ms"]
  B --> C["🧠 LLM\n推論\n~200-800ms"]
  C --> D["🔊 TTS\n音声合成\n~100-500ms"]
  D --> E["▶️ 再生\nバッファリング\n~20-50ms"]
  style A fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
  style B fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
  style C fill:#5b2333,stroke:#ef4444,color:#e2e8f0
  style D fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
  style E fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0

1. VAD（Voice Activity Detection）: 30-50ms

VADは音声ストリームの中からユーザーが「話し始めた」「話し終えた」タイミングを検出するステージです。 Silero VADやWebRTC VADなどの軽量モデルが主流で、このステージ自体のレイテンシは小さいものの、発話終了の検出精度がパイプライン全体の体感レイテンシに大きく影響します。 発話終了の判定に長い沈黙閾値（例: 700ms）を設定すると、その分だけ応答開始が遅れます。

2. STT（Speech-to-Text）: 100-300ms

音声を文字列に変換するステージです。 バッチ処理方式では発話全体を受け取ってから変換しますが、ストリーミングSTTを使えば 発話途中から逐次テキストを生成できるため、後続のLLMに早期にデータを渡すことが可能です。 Deepgram Nova-2やGoogle Cloud Speech-to-Textのストリーミングモードが代表的です。

3. LLM推論: 200-800ms

パイプラインの中で最もレイテンシが大きくなりやすいステージです。 TTFT（Time to First Token）が特に重要で、最初のトークンが生成されるまでの時間が体感的な応答速度を左右します。 GPT-4oやClaude 3.5 Sonnetのようなモデルではストリーミング出力に対応しており、 最初のトークンが出力された時点でTTSに渡し始めることが可能です。

4. TTS（Text-to-Speech）: 100-500ms

テキストを音声波形に変換するステージです。 従来のTTSは文全体を受け取ってから処理するバッチ方式でしたが、 最新のサービス（Cartesia Sonic、ElevenLabs Turbo v2.5等）はチャンク単位のストリーミングTTSに対応しており、 数単語ずつ音声に変換して逐次再生することが可能です。

5. 再生バッファリング: 20-50ms

生成された音声データをクライアントで再生するまでのバッファリング時間です。 WebRTCを利用する場合はネットワーク伝送の遅延も加わりますが、 通常は数十ms程度で全体に占める割合は小さいです。

レイテンシバジェットの設計

レイテンシバジェットとは、目標とする総レイテンシ（例: 500ms）を各ステージに配分する設計手法です。 すべてのステージを均等に最適化するのではなく、ボトルネックとなるステージに集中的にリソースを投入することが効率的です。

最適化テクニック

ストリーミングパイプライン

最も効果が大きい最適化は、各ステージを直列のバッチ処理からストリーミングのパイプラインに変換することです。 STTが部分的なテキストを出力した時点でLLMに渡し、LLMが最初のトークンを出力した時点でTTSに渡し、 TTSが最初の音声チャンクを生成した時点で再生を開始します。 これにより各ステージの処理が重なり（overlap）、体感レイテンシはほぼ「最も遅いステージのTTFT」まで短縮されます。

投機的実行（Speculative Execution）

ユーザーの発話が終わる前に、途中までの音声認識結果を使ってLLMの推論を先行して開始するテクニックです。 発話が完了したら、最終的な認識結果で推論を修正（または再実行）します。 「はい」「いいえ」のような短い応答では特に効果的で、発話終了とほぼ同時に応答を返せる場合もあります。

フィラー生成

LLMの推論に時間がかかる場合に、「えーと」「そうですね」といったフィラー（つなぎ言葉）を先に再生して 体感的な待ち時間を埋めるテクニックです。 人間の会話でもフィラーは自然に使われるため、適切に挿入すれば違和感なくレイテンシを隠蔽できます。 ただし、過度なフィラーは逆効果になるため、LLMのTTFTが閾値（例: 300ms）を超えた場合にのみ発動するよう制御します。

チャンク単位処理の設計

TTSへの入力をどの単位で区切るかは、レイテンシと音声品質のトレードオフです。文単位で区切ると韻律（イントネーション）は自然になりますが、文の終わりまで待つ必要があります。句読点単位やフレーズ単位で区切ると早く再生を開始できますが、韻律が不自然になる可能性があります。 多くの実装では、句読点（。、！？）やLLMが出力する改行をチャンクの区切りとして利用しています。

パイプライン型 vs エンドツーエンド型

Voice AIのアーキテクチャは大きく2つのアプローチに分かれます。パイプライン型はSTT→LLM→TTSを個別のモデルとして組み合わせる従来の手法で、エンドツーエンド型は音声入力から音声出力までを単一のモデル（またはマルチモーダルモデル）で処理します。

2026年現在、エンドツーエンド型はレイテンシ面で優位ですが、パイプライン型は柔軟性とコスト制御の面で優れています。 多くのプロダクションシステムでは、パイプライン型をベースにしつつストリーミング最適化を徹底することで 500ms以下の応答速度を実現しています。

主要サービスのレイテンシ比較

Voice AIパイプラインを構成する際に選択肢となる主要サービスの実測レイテンシを比較します。 値はストリーミングモードでのTTFB（最初のバイトが返るまでの時間）を基準としています。

STTサービス

TTSサービス

実践的な設計指針

Voice AIエージェントのレイテンシ設計で特に重要なポイントを整理します。

• 目標レイテンシを先に決める: 一般的な目標は「最初の音声が再生されるまで500ms以内」。これをステージごとに配分する
• ボトルネックを特定する: 各ステージのレイテンシを計測し、最も時間がかかるステージから最適化する
• ストリーミングを前提に設計する: バッチ処理はプロトタイプ段階でのみ使用し、本番ではすべてのステージをストリーミング化する
• VADの閾値チューニングを怠らない: 発話終了の検出が遅いと、後続の最適化がすべて台無しになる
• エッジロケーションを活用する: ユーザーに近いリージョンでSTT/TTSを処理することでネットワークレイテンシを削減する
• フォールバック戦略を用意する: 高負荷時にはより軽量なモデルに切り替えるなど、レイテンシSLAを守るための戦略を事前に設計する