人間が「うんうん」と相槌を打つまでの平均反応時間は200msです。「会話している」と感じる上限は300ms。これを超えると、相手が考え込んでいる気配が漂い始め、500msを超えると会話が「壊れた」感覚になります。
ところが、普通に作った音声AIエージェントの応答は 1,200ms前後。STT (音声認識) + LLM (推論) + TTS (音声合成) + ネットワーク往復を足すと、簡単に1秒を超えます。
この記事では、なぜ音声AIに「300msの壁」が存在するのか、2026年5月時点でクラウドAPIだけで300msに到達できるのか、エッジ+クラウドのハイブリッド構成で実際に突破した実装を、実測値と一緒に書きます。
なぜ300msなのか
技術側の話に入る前に、UXの数字を先に置きます。
| 反応時間 | 人間の体感 |
|---|---|
| 〜200ms | 「自然な会話」 |
| 200〜300ms | 「ちょっとテンポが遅い」 |
| 300〜500ms | 「考え込んでいる」 |
| 500ms〜 | 「会話が壊れている」 |
| 1,000ms〜 | 「フリーズしたかと思った」 |
Jakob Nielsenの古典的なUI応答時間研究 (0.1秒 / 1秒 / 10秒の3閾値) や、人間の口頭会話における turn-taking 研究を踏まえると、音声インタフェースで「自然」と感じる上限は300ms という結論にエンジニア界隈はほぼ収束しています。
ところが、実装側の数字を並べると、これがいかに厳しいかが分かります。
カスケードパイプラインの限界
従来型の音声AIエージェントは、以下の流れで動きます。
マイク → 音声キャプチャ → STT(音声認識) → LLM(推論) → TTS(音声合成) → スピーカー
各段階の典型的なレイテンシ:
| コンポーネント | 典型レイテンシ |
|---|---|
| VAD (発話終了検出) | 80〜200ms |
| STT (例: Whisper Large) | 200〜500ms |
| LLM (例: GPT-4o TTFT) | 200〜400ms |
| TTS (例: ElevenLabs) | 40〜150ms |
| ネットワーク (往復) | 50〜200ms |
| 合計 | 570〜1,450ms |
最速構成でも570ms。300msの壁を 物理的に超えられません。
これがカスケード型の本質的な問題です。料理にたとえると、5皿のコースを順番に作っているようなもの。前菜が終わるまでメインには手をつけない。お客が空腹で帰る。
エラー伝播のおまけ
カスケードにはもう一つの問題があります。エラー伝播です。
STTが "flight" を "fright" と誤認識すると、LLMは間違った前提で推論し、TTSが間違った内容を自信満々で音声化する。伝言ゲームの恐怖です。最初の人が「飛行機」を「恐怖」と聞き間違えたら、最後の人が「あなたの恐怖体験をお聞かせください」と返してきます。
レイテンシだけでなく、品質の観点でもカスケードはツライ構造です。
Speech-to-Speech統合モデルの登場
2024年10月、OpenAIが Realtime API (GPT-4o realtime) を公開し、状況が変わりました。
カスケードではなく、音声から音声へ直接変換する Speech-to-Speech 統合モデル です。中間のテキスト化を経由しないため、エラー伝播が起きにくく、レイテンシも大幅に減ります。
2026年5月時点の実測 (WebRTC接続、米国リージョン):
| 指標 | 値 |
|---|---|
| Time to first audio chunk (中央値) | 300〜600ms |
| API time-to-first-byte | 約 500ms |
| 残り (キャプチャ + VAD + ネットワーク + レンダリング) | 約 300ms |
参考: openai.com/index/introducing-gpt-realtime
「中央値300ms」がコアラインで、これに音声キャプチャ・VAD・ネットワーク往復が乗ると、実体験で 400〜700msあたり が現実的な数字です。
Gemini Live API (2026-03)
Googleは2026年3月、Gemini 3.1 Flash Live をリリースしています。
価格はOpenAIより圧倒的に安く、$0.00165/分 vs OpenAI $0.30/分 (182倍差)。GoogleCloud近接環境ではレイテンシでOpenAIを上回るケースも報告されています。
参考: speko.ai/benchmark/openai-vs-gemini-live
つまり 2026年5月時点では、 「クラウドAPI単体で300ms前後」までは到達できる ようになっています。ただし、これは「米国リージョン」「WebRTC接続」「Wi-Fi安定」の条件付きです。日本ユーザーが日本のサーバーから米国APIを呼ぶと、ネットワーク往復だけで150ms以上加わります。
エッジ+クラウドハイブリッドの実装
クラウドAPI単体では条件次第で届くが、安定して300ms以下に収めるには別の手が要ります。私が試したのは エッジ+クラウドのハイブリッド構成 です。
構成図
[エッジ (ローカル)] [クラウド]
VAD: 0〜5ms ──→
STT (Whisper v3 Turbo): 50〜150ms LLM (GPT-4o-realtime 等): 200〜400ms
TTS (Cartesia / ElevenLabs): 40〜75ms
←──
ポイントは2つ。
- STTをエッジに置く — Whisper v3 Turbo (RTF 1300x) が出てからエッジSTTが実用化した
- ネットワークにはテキストだけ流す — 音声ストリームより圧倒的に軽い
Whisper v3 Turbo のインパクト
エッジSTTの実用化を一気に推し進めたのが Whisper v3 Turbo (2024年10月) です。
| モデル | RTF | 精度 (WER) |
|---|---|---|
| Whisper v3 Turbo | 1,300x | Large V3 と同等 |
| Whisper Large V3 | 206x | 最高 |
| Whisper Medium | 300x | 中-高 |
RTF 1,300x は「10秒の音声を7.7ms で文字起こしできる」速度です。あなたが「こんにちは」と言い終わる前に、Turbo は1,300回その文字起こしを終えている計算です。
CPU-only でも数百ms、GPU + Coreml 等の最適化を加えると 50〜150ms で実用域に入ります。エッジ STT が本当に動く時代になりました。
LLMもエッジに置けるか
私も試しました。Qwen2.5:1.5b や Phi-3.5-mini をローカルで動かして音声会話を成立させられるか。
結論: TTFT (Time to First Token) は届くが、品質が会話レベルに到達しない。
| モデル | パラメータ | CPU-only TTFT | 日本語品質 |
|---|---|---|---|
| Qwen2.5:1.5b | 1.5B | 200〜500ms | 簡単な応答ならOK |
| Qwen3.5:0.8b | 0.8B | 100〜300ms | thinking暴走で不安定 |
| Gemma-3:2b | 2B | 300〜500ms | まずまず |
| Phi-3.5-mini | 3.8B | 400〜700ms | 良好 |
TTFT は確かに 200〜500ms に収まります。けれど、複文の理解、文脈保持、敬語などを総合すると、現時点では Sonnet 4.6 / GPT-4o レベルにエッジモデルでは届きません。
なので私の構成では、LLMだけはクラウドに残し、STTをエッジで処理 という分担にしました。
全体のレイテンシ
実測値 (私のMacBook Pro M3 + Wi-Fi 6 + OpenAI Realtime API):
| 段階 | 実測 |
|---|---|
| VAD (Silero VAD) | 5〜30ms |
| STT (Whisper v3 Turbo, MLX) | 70〜120ms |
| Network (HTTP POST → OpenAI) | 60〜180ms |
| LLM TTFT (GPT-4o-realtime) | 180〜380ms |
| TTS first byte (内蔵) | 30〜80ms |
| 合計 (Time to first audio) | 345〜790ms |
中央値で 約430ms。クラウド単体 (500〜700ms) より100ms以上速くなります。
「フィラー戦略」(後述) を併用すると、ユーザー体感で 300ms を切ることが可能になりました。
私の構成では、Whisper v3 Turbo を Apple Silicon MLX バックエンドで動かしています。これにより RTF 1,000x 超の速度がCPU+Neural Engineで実現できます。ローカル LLM を VRAM 8GBクラスの GPU で動かすより、こちらの方が圧倒的にコスパが良いです。
体感を縮める「フィラー戦略」
技術的なレイテンシをこれ以上削れない時に効くのが フィラー戦略 です。
人間は実際の会話でも「えーっと」「うん」「あー」というフィラーを発します。これは「相手の発話を受け取ったよ、いま処理してるよ」というシグナルです。
音声AIでも同じことをします。
ユーザーの発話終了を検出
↓ (50〜100ms以内に)
"はい、" / "えー" / "なるほど" 等のフィラーを再生開始
↓ (この間にLLMが本処理)
本応答の音声ストリームを開始
フィラーがユーザーの耳に届くまでが100ms以下なら、ユーザーは「ほぼ即応答」と認識します。実際の本応答が400ms後に始まっても、体感は300msを切る感覚になります。
これは音声AI実装で最も「効果vs実装コスト」のレバレッジが高い手法だと、個人的には思っています。
実装で押さえるべきポイント (チェックリスト)
300ms (体感) を狙うときに、よく落とすポイントをまとめます。
ネットワーク
- WebRTC接続を選ぶ (HTTP POSTより低レイテンシ)
- 日本ユーザーなら東京リージョンのAPIを優先 (Azure OpenAI Japan East 等)
- TCP slow start の影響を減らすため、HTTP/2 か QUIC を使う
VAD
- Silero VAD などの軽量モデルでフレーム単位 (20ms) で判定
- 「無音が0.5秒続いたら発話終了」のような単純しきい値を避ける
- AGC (自動ゲイン調整) と AEC (エコーキャンセル) を必ず併用
STT
- Whisper v3 Turbo か、商用ならDeepgram Nova-3
- ストリーミングモードを使う (バッチ処理は遅い)
- Apple Silicon なら MLX、NVIDIA なら CTranslate2 等のバックエンドを選ぶ
LLM
- OpenAI Realtime API か Gemini 3.1 Flash Live を第一候補にする
- 日本語の自然さで選ぶなら GPT-4o-realtime > Gemini Live
- コスト優先なら Gemini Flash Live (182倍安い)
TTS
- ElevenLabs Turbo v2 (40ms TTFB) か Cartesia Sonic を選ぶ
- ストリーミング合成必須 (チャンク単位で再生開始)
- pre-warming (初回呼び出しの遅延を回避するため、空打ちで温める)
フィラー
- 短い相槌音声 (200〜500ms) を5〜10種類用意
- 発話終了検出から100ms以内に再生開始
- ランダム選択でリピート感を消す
「300msの壁」は越えられるが、コストはかかる
ここまで読んで「結局クラウドAPI使えば届くんでしょ」と思った方、半分正解です。
クラウド単体で米国リージョン・WebRTC・安定回線なら300msに届きます。けれど 日本からの呼び出し で 安定して 届かせるには、エッジでSTTを処理 + フィラー戦略 + ネットワーク最適化、を全部やる必要があります。
そして、これらを実装するエンジニア工数は決して小さくありません。Whisper v3 Turbo のローカル組み込み、Silero VAD のチューニング、WebRTC接続管理、フィラー音源の制作。最低でも1ヶ月のエンジニア工数を見ておくべきです。
音声AIのレイテンシ削減、コンポーネント選定、エッジ+クラウドハイブリッドの完全な実装ガイドはVoice AI 300ms UXにまとめています。STT/LLM/TTS各層のベンチマーク、Whisper v3 Turbo の MLX 組み込みコード、フィラー戦略の実装サンプル、Gemini Live と GPT Realtime のコスト比較まで含めて書きました。
実装で踏んだハマりどころ
きれいな構成図を描くと簡単そうに見えますが、実装では何度かハマりました。あとから振り返ると恥ずかしいレベルのものもあるので、共有しておきます。
マイクのAGCがVADを狂わせる
Silero VADを動かしているのにユーザーの無音区間を検出してくれない、という症状に丸一日ハマりました。原因はmacOSのマイク設定でAGC (自動ゲイン調整) が常時オンになっていたこと。無音時にゲインが上がり続け、エアコンの吹き出し音まで「音声」として増幅していました。AGCを切ったら一発で解決。3行のコードで解決する問題に8時間かけました。
TTS pre-warming を忘れて初回だけ遅い
ElevenLabsの初回呼び出しは1秒近くかかります。2回目以降は40msなのに、最初の一言だけユーザーが「あ、遅いな」と気づく。アプリ起動時に空のテキストで一度叩いておく、これだけで体感が変わります。これに気づくまで「うちのTTSはなんで初回だけ遅いんだ」と提供元を疑っていました。
フィラーが固定だとロボット感が出る
最初は「はい、」だけを再生していました。テストユーザーから「3回連続で同じ「はい」が来るとロボットっぽい」と指摘され、なるほどとなりました。「はい」「えー」「なるほど」「うんうん」「ふむ」と5種類用意してランダム選択するだけで、印象は別物になります。
まとめ
- 音声AIの「300msの壁」は、人間の会話reaction time由来。500ms超えると会話が壊れる
- 従来カスケード型 (STT→LLM→TTS) は最速でも570ms。物理的に300msに届かない
- 2026年5月時点、Realtime API / Gemini Live で米国リージョンなら300〜600ms中央値
- 日本ユーザー向けに安定300msを狙うなら、エッジSTT + クラウドLLM のハイブリッド
- Whisper v3 Turbo (RTF 1,300x) によりエッジSTTが実用化
- フィラー戦略で体感レイテンシを100ms以上削れる
- 実装工数は最低1ヶ月。コストはかかるが、UXは決定的に変わる
音声インタフェースは、UXがレイテンシで決まる珍しい領域です。技術スタックの選定が、ユーザー体感に直結します。
面白くいきましょう。