音声AIの300msを100msに感じさせる5つの錯覚ハック

LLMを速くする方向に3ヶ月溶かしました。

GPU増強、モデル軽量化、STTの並列化。それでも実測300msは縮まらなかった。

ある晩、共同開発者のミサキがコーヒーを置いて振り返って言いました。「発想を変えよう。物理で無理なら、感じさせなければいい」

その一言で舵を切りました。

それから2週間で、物理レイテンシは変えずに体感を100ms近くまで削りました。マジシャンが物を消すのではない。消えたように見せるのと同じ発想です。

この記事では、実装してきた5つの錯覚ハックを整理します。すべて実装コードが数十行で済むもの、かつ体感短縮の効果が計測可能なものだけを選びました。Nielsenの三閾値と現行のRealtime API仕様に触れながら、なぜ「実測より知覚を設計する」方が費用対効果が高いのかも書きます。

この記事で扱う5つのハック

実装概要と体感短縮ミリ秒の対応表。単純加算ではなく相乗効果で効く

一枚に押し込みました。

全部足すと900ms近くになりますが、実際は相乗効果で100-200ms程度の体感短縮に収まります。それでも十分に会話が変わります。

なぜ「実測」より「体感」を設計するのか

Jakob Nielsenが1993年の『Usability Engineering』でまとめた三閾値は、いまだにUX設計の土台です。

• 0.1秒: システムが即応していると感じる限界
• 1秒: ユーザーの思考の流れが途切れない限界
• 10秒: ユーザーの注意が対話に留まる限界

音声AIは300msの領域です。0.1秒を超えて1秒未満のゾーン。ここは「遅延を感じているが、まだ会話は成立する」中間帯です。ここを「遅延を感じない」側に寄せるだけで体験が変わります。

OpenAIのRealtime API(GPT-Realtime-2.1)ですら、machine-side latencyは公称190ms、production環境の初回ターンでは500-1200msに膨らむと報告されています。

物理300msは、現状の音声AIエンジニアリングでは天井です。

天井を打ち破ろうとすると、GPUを増やす、モデルを蒸留する、STTとLLMを並列化する、といった打ち手になります。どれも効きます。でも投じた工数の割に、体感の改善は小さい。ユーザーは20msの改善を認識しないからです。Nielsen自身も1993年の時点で「人間の知覚は連続値ではなく段階的」と書いています。

そのため発想を変えます。

実測を1msでも削るためにGPUを積むより、体感を150ms縮める仕掛けを1つ入れる方が、ROIが桁違いに高い。

体感設計は「サボり」ではありません。人間の会話も、フィラーや相槌で「考えている時間」を隠しています。AIも同じ設計原理を借りるだけです。

ハック1: フィラー先行音声で200ms稼ぐ

LLMの推論を待たずに、先に「えーと」「そうですね」を再生します。これはPipecatが提唱するPreemptive Speech Generation(先行音声生成)の考え方に近いパターンです。VADが発話終端を予測した瞬間、確定を待たずにTTSで短いフィラーを流し始めます。

実装は驚くほど単純です。

async def on_utterance_end_predicted():
    # 推論を投げると同時に、フィラーを先行再生
    await tts_stream("えーと、")
    response = await llm.generate(user_input)
    await tts_stream(response)

「これ、ズルじゃないの」と最初は思いました。でも人間だって考える時間に「えーと」と言います。むしろ無音の方が不自然でした。

ACM CUI 2025の研究では、高遅延条件(4秒以上)で特にフィラーの効果が顕著だと報告されています。300msでも体感で200ms程度の短縮が見込めます。

注意点: フィラーが毎回同じだと機械感が出ます。5-8種類をランダム化してください。「えーと」「そうですね」「うーん」「そうですねえ」「なるほど」「ちょっと待ってくださいね」など、シーンごとに使い分けると自然さが増します。

もう一つの落とし穴は、フィラー再生中にLLMがエラーで返ってこなかった場合の設計です。フィラーだけ流れて本編がない、という事故が起きます。timeoutを設定して、フォールバック応答を用意しておいてください。

ハック2: 相槌の即時返しで150ms稼ぐ

フィラーが「AIが話し始める前の潤滑油」なら、相槌は「ユーザーが話している最中の潤滑油」です。

ユーザーが「昨日、渋谷で」と言った時点で、AIが「うん」と返す。この150msの相槌が入るだけで、体験は「聞いてくれている」に変わります。

実装のコアはVAD(音声区間検出)の閾値調整です。

# 発話中の短い息継ぎ(200-400ms)で相槌を挿入
if silence_duration > 200 and silence_duration < 400:
    if not is_end_of_turn(context):
        await play_backchannel()  # "うん" / "はい" / "なるほど"

ここで難しいのはターンテイキングの判定です。相槌のつもりで割り込むと、ユーザーは「話を遮られた」と感じます。詳細は音声AIのターンテイキング設計で書きました。

「うん」の1音だけ。それが150msの体感短縮になります。

相槌の頻度も設計対象です。人間同士の会話では、聞き手は3-8秒に1回のペースで相槌を打つと言われます。AIも同じペースを目安にすると自然です。5秒に1回程度、話者が息継ぎしたタイミングで軽く返す。多すぎるとうるさく、少なすぎると「聞いていない」印象になります。

タイプも重要です。「うん」「はい」「なるほど」「そうなんですか」など、内容に応じて選び分けると精度が上がります。感情推定と組み合わせて、ユーザーが困惑気味なら「大変ですね」を返すような設計もあります。Hume AIのEmpathic Voice Interfaceが採用している方向性です。

ハック3: 部分結果ストリームで180ms稼ぐ

STT(音声認識)もLLMも、内部的にはtokenを逐次生成しています。この中間tokenを確定を待たずに流し続けるだけで、体感が別物になります。

Google Speech-to-TextやOpenAI Realtime APIは、interim_resultsやresponse.deltaイベントで中間結果をストリーミング配信します。TTS側もchunked audio streamingに対応しているので、LLMのtokenが1つ出るたびにTTSに投げれば、first audio(最初の音声)までの時間が大きく縮みます。

体感的には「まだ考えているが、口は動き始めている」状態です。人間の会話とそっくりです。

async for token in llm.stream(prompt):
    await tts_stream_partial(token)

たった3行。

それで180ms稼げます。

ただし副作用もあります。中間tokenは訂正される可能性があるので、TTSに投げた後で「実は違いました」となると、音声がガタつきます。訂正頻度を計測して、閾値を超えたら中間ストリームを一時停止する設計が要ります。

SuperWhisperのようなアプリは、この設計を視覚UI側にも展開しています。ASRの生結果をグレー文字で先に表示し、整形後に差し替える。ユーザーは「入力が反映されている」ことを即座に確認できます。音声UIでも同じ原理が使えます。TTSは訂正が難しいので、代わりに「言い直し」を挿入する手もあります。「あ、正確には」の一言で、訂正が自然な会話の一部になります。

ハック4: プログレッシブ応答で120ms稼ぐ

「3つのポイントがあります。1つ目は...」

これだけで、ユーザーの脳内タイマーが止まります。全体像が示された瞬間、残りの時間は「答えを待つ時間」から「情報を受け取る時間」に切り替わるからです。

心理学的にはこれをフレーミング効果と呼びます。同じ30秒でも、「これから3分の話をします」と最初に言われれば、体感は短くなる。バーテンダーが「今日は少し珍しいカクテルを作ります」と一言添えるのと似ています。

プロンプト設計で簡単に実装できます。

あなたは音声AIです。回答は必ず以下の形式で始めてください:
「[要点数]つあります。1つ目は、」

体感短縮は120ms程度と控えめですが、実装コストがほぼゼロなので入れない理由がありません。

副次効果もあります。ユーザーが「あ、3つあるのね。じゃあ2つ目まで聞いてから判断しよう」と、聞く姿勢を事前に整えられる。情報の受け取り効率が上がります。長い解説を提供するプロダクトほど、この効果は大きい。

一方で、短い応答が多いプロダクトでは逆効果です。「今日の天気は」に対して「1つあります。それは晴れです」は不自然です。プロダクトのユースケースを見て、長文回答が中心のシーンだけに絞ってください。

ハック5: 優先ストリーム分割で250ms稼ぐ

これが一番効きました。

回答を「短い返答」と「長い解説」に分けます。短い返答を先にTTSで送り、長い解説は後追いで流す設計です。

たとえばユーザーが「今日の天気は」と聞いた場合。

• 先行ストリーム(即時): 「東京は晴れです。」
• 後追いストリーム(1-2秒後): 「最高気温は32度で、湿度が高めです。午後から...」

先行ストリームで250ms以内に音声が返れば、ユーザーの体感は「即答」です。後の解説は「補足」として受け取られます。

実装は2ストリーム設計です。

async def dual_stream_response(query):
    # 先にshort answerを生成して即再生
    short = await llm.generate(query, max_tokens=20, priority="high")
    await tts_stream(short)
    # 続いてfull answerを生成して追い再生
    full = await llm.generate(query, max_tokens=200)
    await tts_stream(full)

短い返答用のLLM呼び出しは、max_tokensを絞れば数十msで返ってきます。ここが250ms短縮の正体です。

「同じLLMを2回叩くのはコスト2倍じゃないの」と言われました。半分正解です。短い返答はmax_tokensが小さいので、実コストは1.2-1.3倍程度です。体感が250ms縮むなら、この差額は安いです。

もう一つのバリエーションは、短い返答をLLMで返さず、事前定義のテンプレートで返す設計です。天気、時間、簡単な確認応答などパターン化できる質問は、LLMを叩かずに数msで返せます。GetStreamが提案する「投機的ツール呼び出し」の考え方に近いパターンです。

5つを組み合わせるとどうなるか

単純加算では900ms短縮になりますが、実際はそうはなりません。フィラーと相槌は重なるとくどいし、部分結果ストリームと優先ストリーム分割は競合します。

実運用では以下の組み合わせが安定です。

ユースケース	推奨ハック	期待短縮
短い応答が多い会話AI	1 + 5	200ms
長文回答が多い解説AI	3 + 4	200ms
相談・カウンセリング系	1 + 2 + 3	250ms

300ms実測 - 200ms体感短縮 = 体感100ms です。Nielsenの0.1秒閾値、つまり「即応している」と感じる領域に踏み込めます。

もう一つ大事なのは、計測の設計です。「体感」は主観指標なので、A/Bテストで比較する必要があります。同じユーザーに両方の設定を短時間で体験させ、5段階評価(1: とても遅い / 5: とても速い)を取ります。10-20人のサンプルで、平均スコアが0.5点以上上がれば効いている、と判断できます。物理レイテンシは変わっていないのに主観スコアが上がった、という結果を見ると、体感設計の威力を実感します。

「速くする」から「速く感じさせる」への転換

3ヶ月GPUと格闘した後、2週間で体感を100msに近づけました。技術的な難易度は後者の方が低い。にもかかわらず、多くのチームは前者に人月を溶かしています。

物理レイテンシを削るのは、水を石から絞るような仕事です。300msから200msへの改善は、GPU予算を10倍にしても届かないかもしれない。

一方で体感設計は、コードを50行足すだけで150ms稼げることがあります。

もちろん物理レイテンシの改善も止めるべきではありません。ただし、優先順位を逆にする価値はあります。まず体感を100msに寄せてから、次に物理を削りに行く。この順番だと、ユーザーが待ってくれる時間が長くなるので、物理改善の期限も伸びます。

体感設計は「サボり」ではありません。「先に売上を立てる」設計です。

音声AIの体験がどこで崩壊するかは音声AIの体験が崩壊する3つの崖にまとめました。あわせて読むと、300ms/500ms/800msの各崖に対して、どのハックが効くかが見えてきます。

まとめ

• 音声AIの300ms実測は、GPU増強では縮まらない天井に近い
• 体感設計に転換すると、コード数十行で150-200ms稼げる
• 5つのハック(フィラー先行/相槌即時/部分結果/プログレッシブ/優先分割)の組み合わせで、体感100msに近づく
• 実装ROIは体感設計の方が桁違いに高い。優先順位を逆転させる価値がある
• Nielsenの三閾値(0.1s/1s/10s)は、いまも音声AI設計の羅針盤

「速くするより、速く感じさせろ」。この一言に3ヶ月分の授業料が詰まっています。同じ授業料を払わずに済むように、ここに置いておきます。

📖 この記事の内容を詳しく扱った本を公開しています
人間会話の200ms壁と音声AIの300ms問題を、心理学・実測・実装の3方向から扱った12章。
👉 音声AIの300ms問題: 体感を設計する

参考文献

• Nielsen, Jakob. "Response Times: The 3 Important Limits." Nielsen Norman Group, 1993.
• OpenAI. "How OpenAI delivers low-latency voice AI at scale." OpenAI Blog, 2026.
• ACM CUI 2025. "Mitigating Response Delays in Free-Form Conversations with LLM-powered IVAs."
• Pipecat (GitHub). "Preemptive speech generation option for seamless conversation." Issue #3321, 2025.