Building Enterprise Realtime Voice Agents from Scratch: A Technical Tutorial

本論文は、単一の高速モデルではなく、Deepgram、vLLM、ElevenLabs などの各コンポーネントをストリーミングでパイプライン化することにより、947ms という超低遅延を実現するエンタープライズ向けリアルタイム音声エージェントの構築手法を、完全なコードとともに解説する技術チュートリアルである。

要約

🍽️ 結論：「全部屋で料理する」のではなく、「流れるように調理する」

この研究の最大の特徴は、「リアルタイム（即時）」を実現する秘密を解明したことです。

❌ 昔の考え方（ネイティブ型）：「完璧な料理人」

「音声で聞いて、頭の中で考え、音声で答える」を1 人の天才料理人が全部やろうとするとどうなるか？

• 注文（音声入力）を聞く。
• 頭の中でレシピ（思考）を考える。
• 料理（音声出力）を完成させる。
• 結果： 料理が完成するまで13 秒もかかる！ お客さんは「えっ、まだ？」と待たされすぎてしまいます。
• さらに： この天才料理人は「冷蔵庫の在庫を確認する」といった複雑な作業（機能呼び出し）が苦手でした。

✅ 新しい考え方（カスケード型）：「流れる調理ライン」

この論文が提案するのは、**「3 人の専門家が、流れるように協力するライン」**です。

1. 聞き手（STT）： 注文を聞き、メモに書き取る。
2. 頭脳（LLM）： メモを読み、考え、回答を一言ずつ書き出す。
3. 話し手（TTS）： 書き出された言葉を聞きながら、「できた！」という部分からすぐに声に出す。

🌟 魔法のポイント：
3 人が同時に動きます。「頭脳」がまだ考えている途中でも、「話し手」はすでに最初の言葉を喋り始めています。
これにより、**「最初の音が聞こえるまで」が 1 秒未満（約 0.7 秒）**という驚異的な速さを実現しました。

---

🏭 具体的な仕組み：3 人の専門家チーム

このシステムは、以下の 3 つのパーツを組み合わせた「工場のライン」のようなものです。

1. 耳の専門家（Deepgram）：

   • 人の声を聞いて、すぐにテキスト（文字）に変換します。
   • 例：「あ、お客様が『予約したい』と言ったな」と即座にメモします。

2. 頭の専門家（LLM / vLLM）：

   • 文字を見て、どう返すか考えます。
   • ここが重要なのは、**「考えながら、できた部分から順に文字を流す」**こと。
   • 例：「はい、予約ですね。まず日付を...」と、文章が完成する前に「はい、予約ですね」だけを先に流します。
   • さらに、この頭脳は「病院の予約システム」や「在庫データベース」といった外部ツールと繋がる能力も持っています。

3. 口の専門家（ElevenLabs）：

   • 流れてくる文字を聞いて、**「できた部分からすぐに音声に変換」**して喋ります。
   • 例：「日付を...」という文字が来たら、まだ「何月何日？」という文字が来ていなくても、「日付を」という音をすぐに喋り始めます。

---

🚧 なぜこれが難しいのか？（「文の区切り」のジレンマ）

ここで大きな問題が起きます。
「頭の専門家」が「日付を...」と流し、「口の専門家」がそれを喋り始めたとします。でも、実は次の言葉は「何月何日ですか？」だった場合、「日付を」だけ喋って止まるのは不自然ですよね。

🔧 解決策：「文のバッファ（一時保管庫）」

• 頭脳から流れてくる言葉を、**「文が一度完成するまで（ピリオドや感嘆符が出るまで）」**少し待機させる「バッファ」という箱を用意します。
• 「日付を何月何日ですか？」という1 文が揃うと、一気に口へ渡します。
• これを繰り返すことで、**「途切れることなく、かつ文脈を無視しない自然な会話」**が生まれます。

---

📊 結果：どれくらい速くなった？

• 昔の「全部屋で料理する」方式： 最初の音が聞こえるまで 13 秒（待たされすぎ）。
• 新しい「流れるライン」方式： 最初の音が聞こえるまで 0.7 秒（ほぼ瞬時）。

まるで、注文してから 0.7 秒で「はい、お待たせ！」と言われたような感覚です。

---

🎓 この論文のすごいところ

1. 教科書として公開されている：
   単に「速い！」と言うだけでなく、「どうやって速くしたか」のコードをすべて公開しています。誰でもこの「流れるライン」を自分で組み立てられるように、9 つのステップで丁寧に解説されています。
2. 実用性を重視：
   最新の「音声だけで完結する AI」も研究されていますが、それらはまだ遅くて複雑な仕事（予約や検索など）ができません。この論文は、**「実務で使える（機能呼び出しができる）かつ超高速」**なシステムを、既存の最強のパーツを組み合わせて実現しました。

💡 まとめ

この論文は、**「AI 音声アシスタントを速くするには、1 人の天才に全部任せるのではなく、3 人の専門家を流れるラインでつなぎ、文が完成するたびに次へ渡す『連携プレー』が重要だ」**と教えてくれています。

まるで、工場でベルトコンベアが動いているように、音声・思考・発声が重なり合って動くことで、人間と会話しているような「リアルタイム感」が生まれるのです。

技術概要

論文要約：Enterprise Realtime Voice Agents from Scratch: A Technical Tutorial

Salesforce AI Research によるこの論文は、ゼロからエンタープライズグレードのリアルタイム音声エージェントを構築するための包括的な技術チュートリアルを提供しています。既存のオープンソースモデルやフレームワークの断片的な知識ではなく、個別コンポーネントから完全なストリーミング音声エージェント（関数呼び出し機能付き）までの統合パイプラインを体系的に解説しています。

以下に、問題定義、手法、主要な貢献、結果、および意義の詳細な技術的サマリーを記述します。

---

1. 問題定義 (Problem)

既存の音声 AI エージェント開発には、以下のギャップが存在します。

• ナティブ音声 - 音声モデルの限界: Qwen2.5-Omni や Moshi などの「ナティブな音声 - 音声（Speech-to-Speech: S2S）」モデルは存在しますが、これらはリアルタイムインタラクションには遅すぎます（初回音声生成までの時間：TTFA が約 13 秒）。また、エンタープライズで必須の「関数呼び出し（Function Calling）」をサポートしていません。
• フレームワークのブラックボックス化: Pipecat や LiveKit Agents などのプロダクション向けフレームワークは存在しますが、これらは「インストールして使う」ツールであり、内部のストリーミング機構やパイプラインの動作原理を教えるチュートリアルは不足しています。
• 評価基準の欠如: 既存の評価フレームワークはターンベース（非ストリーミング）の音声パイプラインに依存しており、真のリアルタイム性を評価できていません。

核心課題: 「リアルタイム」な音声エージェントを実現するには、単に高速なモデルを使うことではなく、**ストリーミングとコンポーネント間のパイプライン化（並列実行）**が鍵となります。

2. 手法とアーキテクチャ (Methodology)

著者らは、ナティブ S2S モデルの限界を立証し、カスケード型ストリーミングパイプラインを採用するアプローチを提案しました。

2.1. アーキテクチャの選択

• ナティブ S2S の検証: Qwen2.5-Omni-7B を NVIDIA A10G GPU で評価した結果、音声生成（Talker）部分がボトルネックとなり、TTFA が約 13.2 秒（文単位ストリーミング時）に達しました。また、関数呼び出しも未対応でした。
• 採用アーキテクチャ: 従来の STT（音声認識）→ LLM（言語モデル）→ TTS（音声合成） のカスケード型パイプラインを、各段階でストリーミングさせる方式を採用しました。

2.2. 実装コンポーネント

1. ストリーミング STT: Deepgram Nova-3 を使用。WebSocket 経由で 20ms 単位のオーディオチャンクを送信し、部分トランスクリプトと確定トランスクリプトを区別して処理します。
2. ストリーミング LLM: vLLM を使用して LLM をホストし、OpenAI 互換 API を経由してトークンをストリーミング生成します。関数呼び出し（Function Calling）をサポートし、ツール実行ループを実装しています。
3. ストリーミング TTS: ElevenLabs (eleven_turbo_v2_5) を使用。テキストが生成されるにつれて即座に音声チャンクを生成・送信します。
4. 文バッファ（Sentence Buffer）: 重要なオーケストレーション要素。LLM からストリーミングされるトークンを蓄積し、文の終わり（句読点など）を検知した時点で TTS に渡すことで、LLM の生成と TTS の合成を並列化します。
5. VAD（音声活動検出）とターン管理: Silero VAD を使用し、ユーザーの発話終了を検知して LLM 処理を開始し、エージェントの発話中にユーザーが割り込めるよう状態遷移を管理します。

2.3. エンタープライズ機能

医療受付シナリオ（予約確認、キャンセル、患者情報取得など）を例に、5 つのツールを実装し、LLM がツール呼び出しを判断し、結果をフィードバックする再帰的なループを実装しました。

3. 主要な貢献 (Key Contributions)

1. 包括的な調査: 25 以上の音声 - 音声モデルと 30 以上の音声エージェントフレームワークを調査し、現状のギャップ（特に関数呼び出しの欠如とリアルタイム性の不足）を明確化しました。
2. 実証的評価: ナティブ S2S モデル（Qwen2.5-Omni）とカスケード型ストリーミングパイプラインの比較を行い、後者がリアルタイム性のために不可欠であることを実証しました。
3. 完全な実装コード: エンタープライズ機能（関数呼び出し）付きのストリーミング音声エージェントの完全な実装コードをオープンソース化しました。
4. 9 章構成のチュートリアル: 各コンポーネント（STT, LLM, TTS, パイプライン, WebSocket, VAD, Web クライアント, エージェントロジック, ベンチマーク）の動作原理を解説する段階的なチュートリアルを提供しています。

4. 実験結果 (Results)

クラウド API（OpenAI GPT-4.1-mini）および自己ホスト型 vLLM（NVIDIA A10G）でのベンチマーク結果は以下の通りです。

• 初回音声生成までの時間 (TTFA):
  • ベストケース: 729ms（自己ホスト vLLM）、715ms（クラウド API）。
  • P50（中央値）: 947ms（自己ホスト）、958ms（クラウド）。
  • これは、従来のターンベース処理（約 1.6 秒）やナティブ S2S モデル（約 13 秒）と比較して劇的な改善です。
• コンポーネントごとのレイテンシ:
  • Deepgram STT: P50 337ms
  • vLLM (LLM) TTFT: P50 337ms
  • ElevenLabs TTS TTFB: P50 219ms
• ストリーミングの効果: 各コンポーネントの並列実行により、単純な合計値（STT+LLM+TTS）よりも低いレイテンシを達成しました。
• 関数呼び出し: カスケード型パイプラインでは関数呼び出しが完全にサポートされ、複雑なタスクの実行が可能になりました。

5. 意義と結論 (Significance & Conclusion)

• 実用性の証明: 「リアルタイム」な音声エージェントは、単一の超高速モデルに依存するのではなく、ストリーミングとパイプライン化によって実現可能であることを示しました。
• エンタープライズ対応: 関数呼び出しのサポートにより、単なるチャットボットから、データベースクエリや予約管理などの実務タスクを遂行できる真の「エージェント」へと進化しました。
• 教育価値: 既存のフレームワークのブラックボックス化を解き、ゼロから構築する際の技術的課題（VAD の状態遷移、文バッファのロジック、WebSocket のプロトコル設計など）を具体的に解説することで、開発コミュニティの技術基盤を強化します。

結論として: 著者らは、ナティブ S2S モデルがまだリアルタイム用途には適していない現状において、STT-LLM-TTS のカスケード型ストリーミングパイプラインが、低遅延（1 秒未満）かつ高機能なエンタープライズ音声エージェントを構築するための現実的かつ最適なアプローチであると結論付けています。すべてのコードは GitHub で公開されており、9 章にわたる実践的なチュートリアルとして利用可能です。