500ms以下の遅延時間の音声エージェントを自前で構築した方法

 (ntik.me)
12 ポイント 投稿者 GN⁺ 2026-03-03 | 1件のコメント | WhatsAppで共有
  • 音声ベースのAIシステムの遅延時間を400ms水準まで縮めた自前構築型の音声エージェントの開発事例を紹介
  • STT、LLM、TTSをリアルタイムのパイプラインで接続し、既存の商用プラットフォーム（Vapiなど）より2倍速い応答速度を達成
  • Deepgram Fluxで発話検知とターン切り替えを処理し、Groqのllama-3.3-70bモデルを使って最初のトークン生成時間を大幅に短縮
  • 地理的配置とネットワーク最適化により、EU地域へのデプロイ時に遅延時間を半分以下に削減
  • 音声エージェントの核心はリアルタイムのオーケストレーションとパイプライン設計であり、これを自前で実装すると性能ボトルネックを明確に把握できる

音声エージェント構築の背景

  • 消費財大手企業向けの音声エージェントのプロトタイプ開発経験をもとに、商用プラットフォームの複雑さを直接扱うために自前構築を試みた
  • ElevenLabsやVapiのようなプラットフォームは便利だが、内部動作を理解しにくく、細かな遅延時間の制御が不可能
  • 目標はVapi水準の性能を自分で実装することで、1日と約100ドル分のAPIクレジットで実現した

音声エージェントの複雑さ

  • テキストベースのチャットボットと異なり、音声では**リアルタイムのターン管理（turn-taking）**が必要
  • ユーザーが話し始めた瞬間にシステムは即座に発話を止め、止まったらすばやく応答を開始しなければならない
  • 単純な音声検知（VAD）だけでは発話終了を正確に判断しにくく、遅延・発話の重なり・不要な無音が発生する

第1段階の実装: VADベースのテスト

  • FastAPIサーバーとTwilio WebSocketを使ってμ-lawオーディオストリームを受信
  • Silero VADで音声の有無を判定し、発話終了時にあらかじめ録音したWAVファイルを再生
  • 単純ではあるが、即時の反応性と自然な会話フローを確認できた
  • この段階で遅延時間の下限を測る基準を確保

第2段階の実装: Deepgram Fluxとリアルタイムパイプライン

  • Deepgram Fluxを導入し、ストリーミング文字起こしとターン検知を統合
  • Fluxが発話終了を検知すると、次の順序で処理
    • 文字起こし結果と会話履歴をLLMに渡す
    • 最初のトークンが生成され次第、**TTS（WebSocket）**へストリーミング
    • 生成された音声をTwilioへリアルタイム送信
  • **TTS接続を事前維持（warm pool）**して約300msの遅延を削減
  • ユーザーが話し始めたらLLM・TTS・音声送信を即時キャンセルし、自然な割り込み処理を実装

遅延時間の測定と地域デプロイ

  • トルコ現地でローカル実行した場合、平均1.6〜1.7秒の遅延が発生
  • Railway EUリージョンにデプロイし、Twilio・Deepgram・ElevenLabsもEUリージョンに揃えると
    • 平均**690ms（合計790ms）**まで短縮し、Vapiより約50ms高速化
  • 遅延の減少により会話の応答性が大きく向上し、発話の割り込み処理も滑らかになった

モデル選定と性能向上

  • 初期にはgpt-4o-miniを使用し、その後Groq llama-3.3-70bに置き換え
  • テストの結果、Groqモデルの**最初のトークン生成時間（TTFT）**はOpenAI比で最大3倍高速
  • 平均400ms以下のエンドツーエンド遅延を達成し、最初の音声が500ms以内に到着
  • この水準では人間よりエージェントのほうが速く反応すると感じられる

主な技術的学び

  • 遅延時間の最適化では、発話終了から最初の音声出力までの全経路の管理が核心
  • TTFTが全体遅延の半分以上を占めるため、低遅延モデルの選定が重要
  • STT→LLM→TTSを逐次処理せず、ストリーミングパイプライン化する必要がある
  • 発話の割り込み時には全コンポーネントを即時キャンセルしてこそ自然な会話を維持できる
  • サービス間の地理的近接性が遅延に決定的な影響を与える

商用プラットフォームとの比較

  • Vapi・ElevenLabsはAPI、安定性、可観測性などの付加機能を提供するため、大半のチームにとって依然として有用
  • しかし自前構築により実際のボトルネックやパラメータの意味を理解でき、
    特定要件に合わせたカスタムオーケストレーションが可能
  • 音声システムは結局のところオーケストレーションの問題であり、構造を明確に見れば解決可能なエンジニアリング課題

ソースコード

関連記事

1件のコメント

 
GN⁺ 2026-03-03
Hacker Newsのコメント

  • この記事は本当に興味深い。以前 Amazon Alexa チームでこの問題を研究していて、関連特許もある。
    会話中の人間同士の平均遅延は 0ms、つまり相手が話し終える前に次の人がすでに話し始める。脳が相手の発話を予測しながら同時に返答を準備しているからだ。
    一方で、人は音声アシスタントには遅延があるものだと期待している。理由は2つで、コンピュータは「考える」必要があるという認識と、携帯電話通話の遅延のためだ。
    Alexa の応答で 500ms 以下のものはほとんどない。以前は単に 300ms の無音を「ターン終了」とみなしていたが、本当の核心は semantic end-of-turn にある。
    今は計算資源も十分あるので、この部分がどれほど進化したのか気になる。地理的に近い場所で処理すること（エッジコンピューティング）が大きな転換点だった。

    • 携帯電話通話の遅延は、特に 高齢の人たち にとってストレスになる。有線電話の時代にはほとんど遅延がなかったため、なぜ不快なのか分からないままもどかしさを感じる。
    • 2つ目の点には同意しない。音声アシスタントの レイテンシー(latency) は今でも遅すぎる。「動いたのかな？」と待たされる。携帯電話の遅延が他の機器にも期待されるとは思わない。
    • 300ms の無音をターン終了とみなすのは非常に不便だった。だからわざと「えーと…」のような フィラー(filler) を入れなければならず、結局ボイスチャットをやめることになった。
    • 興味深い内容の共有に感謝する。ただ、なぜ Amazon/Google/Apple がここ数年、音声アシスタントの革新を止めてしまったのか気になる。既存のユーザーベースだけでも市場を再定義できたはずなのに。
    • LLM がユーザーの発話を 予測的に引き継ぐ構造 のことを言っているのだと思う。発話が実際に終わったときに予測と一致していれば、遅延なしですぐに応答できる。複数の候補スレッドを同時に予測して枝刈りしていく方式も可能に見える。

  • 音声は結局 ターンテイキング(turn-taking) の問題だと思う。誰も手を付けていない簡単な改善点がある。つまり フィラーとテンポ調整 だ。
    LLM が一時的な沈黙を検知したら、実際の応答が生成されるまでの間に「えーと」「そうですね」のような文脈に合ったフィラーを入れる、という形だ。こうすると会話がずっと自然になる。

    • 完全に同感だ。小さな 低遅延モデル が先に短い応答を生成し、TTS の結果をキャッシュしておけば、遅延を極端に減らせる。「少々お待ちください、考えています」のような文はミリ秒単位で応答可能だ。
    • ただし「簡単な改善」ではないかもしれない。ロボットのようなシステムを人間らしくするのは難しく、単に文の構造を変えるだけではかえって 機械的 に聞こえる。実際に試したが失敗した。
    • 関連して、LiveKit の 「Prompting Voice Agents to Sound More Realistic」ブログ は興味深い。
    • ユーザーが話し終える前にシステムが 応答を予測 できれば、ずっと自然になるはずだ。
    • ターン終了を誤検知したとき、音素単位の filler で自然につなぎ直す方法もあり得る。逆に検知が遅すぎた場合は、最初の音節をあらかじめ決めておき、それで返答を始めるようプロンプトに入れることもできる。

  • 素晴らしい記事だ。OpenAI Responses client は最近 WebSocket を導入して遅延が減った。
    別の方法としては、極小の LLM を ローカルで直接実行 することだ。私は ova プロジェクト を通じて完全ローカルのパイプラインを作り、ストリーミングなしでも 1 秒未満の往復時間を得られた。

    • すばらしいプロジェクトなのでブックマークに追加した。後で経験を共有しながら話してみたい。

  • 記事の ストリーミングパイプライン構造 と段階ごとの遅延分析は非常に役立った。実際にターンテイキングのループを実装している点が印象的だった。
    ただし「Vapi より 2 倍速い」という比較はやや不正確だ。Vapi は ツール呼び出し、Webhook、マルチテナントルーティング など、はるかに多くの処理を行っている。
    この記事の本当の価値は、「自作したオーケストレーションループから得た洞察」にある。単に「自分で作ってみて学んだこと」としてまとめていれば完璧だっただろう。

  • 私も Twilio + Deepgram + ElevenLabs + LLM API の組み合わせで商用音声エージェントを構築中だ。
    核心は STT の精度ではなく ターンテイキング UX だった。固定の無音しきい値ではなく semantic end-of-turn に切り替えたところ、体感がまったく変わった。
    地域間の遅延も重要だ。インドから米国サーバーへ接続すると、Twilio のエッジホップだけで 150〜250ms 追加される。地域別ルーティングで改善した。
    Barge-in（途中割り込み） の処理も複雑だ。LLM と TTS を止めるだけでなく、すでに実行された 自動化ワークフロー を巻き戻さなければならない。以前は予約確認の途中で割り込まれると、予約が実際に完了してしまうバグもあった。

  • Soniox Real-time（60 言語対応）は endpoint detection をモデルレベルで処理する。VAD よりはるかに正確だ。
    技術文書、Daily のベンチマーク、デモページ を参照できる。
    以前 Soniox で働いていた。リアルタイム endpoint detection を最初に実装したサービスだった。

    • 原文を見ると Deepgram Flux を使ったとある。これも endpointing をサポートしており、VAD より上位の抽象化レイヤーにある。
    • 現在 Soniox を使っているが、社内で働いていたときの様子が気になる。競合より 低価格 で SoTA 性能を出せる秘訣が何なのか知りたい。

  • 個人的には STT → LLM → TTS 構成には限界があると思う。未来は end-to-end 音声モデル だ。
    2 年前に Chirpy デモ を作ってみたが、実用レベルに持っていくには専用の学習が必要だった。サイドプロジェクトでは手に負えなかった。

    • その観点なら NVIDIA の PersonaPlex 研究 が興味深いはずだ: https://research.nvidia.com/labs/adlr/personaplex/
    • 私はここ数年、音声エージェントだけを扱ってきた。カスケーディングモデル(cascading model) は当面なくならないだろう。
      企業顧客は 監査可能性(auditability) と 信頼性 を重視する。医療・金融のような規制産業では、STT と LLM の出力をそれぞれ検証しなければならない。
      一方で end-to-end 音声モデル は、インタビューやアンケートのような叙述的な用途により向いている。実際の顧客は最新モデルよりも エンジニアリングの完成度 を求めている。
    • 根本的には「いつ自分の番かを予測する能力」がモデルに内蔵されている必要がある。Moshi の full-duplex モード はその方向性をよく示している: https://arxiv.org/abs/2410.00037
    • カスケード構造の利点は、各段階ごとに 新しいモデルへ置き換え られる点だ。STT、TTS、LLM では進化の速度が異なるため、柔軟性が高い。
    • 最新の音声トークナイザーは 1 秒あたり約 12Hz 程度に達している。一般的な LLM よりはるかに多くのトークンを使う。

  • 今回のアプローチは、ゲームエンジンのネットコード初期の発展 を思い出させる。遅延はモデルの問題ではなく オーケストレーションの問題 だ。
    Carmack の 2013 年の VR 論文 でも同じ主張がされていた。つまり、ミリ秒単位のボトルネックを見つけるにはパイプライン全体を追跡しなければならないということだ。
    Latency Mitigation Strategies は参考になる。TTS の WebSocket プールを事前に開いて 300ms 節約した事例は、まさに完璧な例だ。

  • オープンソースの音声認識アプリ Handy を紹介したい。完全に オフラインで動作 し、拡張性もある。
    私は毎日 Claude と一緒に使っているが、macOS の標準音声入力よりずっとよく動く。

  • 良い記事ではあるが、ターンテイキングだけで会話を説明 するのは単純化しすぎだ。
    実際の会話には オーバーラップ発話、相づち、聞いていることを示す発話(phatic messages)、さらには相手の発話を 補完してあげる協調的な行動 も含まれる。
    こうした要素は単純なターンテイキングモデルではうまく表現できず、モデルがそれらを生成し理解できる必要がある。