対話型AIをめぐる議論の多くは、基盤となる大規模言語モデル（LLM）の知能に集中しています。しかし、米国やインドで大量呼を扱うコンタクトセンターを運営するエンジニアリング／オペレーション責任者にとって、LLMの推論能力が主要な障害点になることはほとんどありません。真の課題はレイテンシです。
人間同士の会話では、応答までの平均的な間は200ミリ秒です。AI音声体験の往復レイテンシが1,200ミリ秒を超えると、会話は破綻します。ユーザーはエージェントに話しかぶせ、バージイン検出が機能せず、顧客満足度スコアが低下します。
本番品質のAI電話エージェントを構築するには、単純なAPIラッパーに頼ることはできません。メディアと推論のパイプライン全体を最適化する必要があります。本稿では、レガシーなコンタクトセンターソリューションのアーキテクチャ上のボトルネックを分解し、サブセカンドの音声エンジンをどう設計するかを解説します。
レイテンシスタック：ミリ秒はどこへ消えるのか
標準的な実装がなぜ破綻するのかを理解するには、発信者の電話からAIエンジンへ、そして戻ってくるまでの1つの音声パケットを追跡する必要があります。素朴なアーキテクチャは典型的に次の構成をとります。
- テレフォニー取り込み： Twilioのようなプログラマブル音声プラットフォームへのSIP/PSTNトランキング。
- 音声ストリーミング： WebSocket経由での生の音声ストリームの転送。
- 自動音声認識（ASR）： 音声のテキストへの書き起こし。
- LLMオーケストレーション： テキストをLLMに送り、プロンプトの生成完了を待つ処理。
- 音声合成（TTS）： 生成されたテキストを再び音声へ変換する処理。
- 再生： 音声を発信者へストリーミングして返す処理。
標準的な逐次実装では、このパイプラインは許容できない遅延を生みます。
| パイプラインの工程 | 素朴なアーキテクチャのレイテンシ | 最適化エンジンのレイテンシ |
|---|---|---|
| SIPからWebSocketへ | 150ms | 50ms |
| ASR（チャンク処理） | 400ms | 120ms |
| LLMのTime-to-First-Token（TTFT） | 800ms | 200ms |
| TTS生成（最初のチャンク） | 600ms | 150ms |
| ネットワークのジッタバッファ | 150ms | 50ms |
| 往復レイテンシの合計 | 2,100ms | 570ms |
2.1秒のレイテンシでは自然な会話は成立しません。これを600ms未満という目標まで削るには、スタックのあらゆる層を最適化する必要があります。
テレフォニー層を捉え直す
多くのレガシー企業は、Twilio Flexや従来型のオンプレミスPBXの上で業務を運用しています。対話型AIを組み込む際、複数の中継サーバーを経由してメディアをルーティングし、不要なネットワークホップを増やしてしまうケースが目立ちます。
TwilioのConversationRelayのような最新のAPIを使えば、テレフォニー事業者とAI音声エンジンとの間に、直接的で低レイテンシなメディア接続を確立できます。生の双方向音声ストリームをセキュアなWebSocket上で直接送る（可能な場合はgRPCや生のTCPを用いる）ことで、標準的なHTTPポーリングのオーバーヘッドを回避できます。
インドでの運用では、ネットワークルーティングがとりわけ重要になります。インド国内の通話を米国リージョンのAWS経由でルーティングすると、光速に起因する純粋なネットワークレイテンシだけで最低250msが上乗せされます。ASRとLLMの推論インスタンスは必ずローカルリージョン（例：ap-south-1）に配置し、ネットワーク転送を40ms未満に抑えてください。
ストリームイン／ストリームアウト：逐次処理のボトルネックを排除する
600ms未満のレイテンシを達成するには、逐次的なバッチアーキテクチャから、完全にストリーミング化されたパイプラインへ移行しなければなりません。
1. VADを用いた逐次ASR
ユーザーが文を言い終えるまで待つのではなく、ASRエンジンは音声チャンク（通常20msから40msのパケット）をストリーミングし、リアルタイムで書き起こす必要があります。
これには堅牢な音声区間検出（VAD）が欠かせません。ローカルで動作する軽量なVADモデルをエッジまたは取り込みサーバー上で実行し、ユーザーが話し始めた瞬間（エージェントの再生中の音声を中断するため）と話し終えた瞬間（LLM推論をトリガーするため）を即座に検出します。ターンテイキングの検出をLLMに任せるのは遅すぎます。ターン制御は音声フレームのレベルで扱わなければなりません。
2. LLMのストリーミングと投機的デコーディング
LLMが応答全体を生成し終えるのを待ってからTTSエンジンへ渡すのは、よくあるアーキテクチャ上の誤りです。LLMは応答をトークン単位でストリーミングしなければなりません。
さらに、投機的デコーディング（小さく高速なドラフトモデルが次の数トークンを予測し、より大きなモデルが並列に検証する手法）などを用いれば、Time-to-First-Token（TTFT）を最大40%短縮できます。
3. チャンク単位のTTS生成
TTSエンジンは、合成を始めるのに文全体を待つべきではありません。LLMが意味の通る節や意味単位のチャンク（通常4〜6語）を出力した時点で、音声の生成を開始すべきです。最新のニューラルTTSエンジンは、こうした短いテキストチャンクから高品質で自然な音声を150ms未満で生成できます。
[User Finishes Speaking]
│
├──► ASR Streams Last Chunk (120ms)
│ └──► LLM Starts Generating (200ms TTFT)
│ └──► First 5 Words Sent to TTS (150ms)
│ └──► Audio Playback Starts (Total: ~500ms)
バージインと状態同期という難題
デジタルカスタマーサービス向け音声アプリケーションで最も難しい問題の1つが、「バージイン」、つまりユーザーがAIエージェントの発話を途中で遮る状況への対処です。
エージェントが話している最中にユーザーが「いや、待って、それは違う」と言った場合、システムは次の処理を行う必要があります。
- テレフォニーサーバー上の音声再生バッファを即座に停止する。
- 下流のTTS生成キューをクリアする。
- LLMオーケストレーターに中断シグナルを送り、生成を停止させる。
- 新しいユーザー入力を取り込み、エージェントが中断されたことを示すマーカーを付けて会話履歴に追加し、新たな応答を生成する。
状態管理が音声トランスポート層から切り離されていると、「ゴーストスピーチ」が発生します。ユーザーが遮ったあともエージェントが1〜2秒話し続ける現象で、ユーザー体験を著しく損ないます。
オペレーション責任者にとっての意味
コンタクトセンターソリューションやAI電話エージェントを評価する際、デモの出来だけで判断してはいけません。デモが現実のネットワーク条件下で実施されたり、レガシーなCRMデータベースと連携された状態で行われたりすることはまずありません。
- レイテンシスタックを監査する： 負荷下での実環境のp95レイテンシ指標、とりわけユーザーの発話終了からエージェントの発話開始までの時間を提示させましょう。
- ローカルルーティングを優先する： 顧客基盤がインドや欧州にあるなら、音声プロバイダーがローカルのメディアゲートウェイと推論エンドポイントを備えているか確認してください。
- 硬直したエコシステムを避ける： テレフォニートランキングを丸ごと入れ替えることなく、既存の顧客エンゲージメント基盤と音声インフラを直接連携できるようにしておきましょう。
よくある質問
音声レイテンシは実際どこで積み上がるのか？
収音、エンドポイント検出、認識、生成、合成、そして転送の各段階です。エンドポイント検出と転送は過小評価されがちで、モデル推論は過大評価されがちです。
モデルが遅い場合でもストリーミングは有効か？
有効です。ストリーミングは発信者が最初に何かを聞くタイミングを変えます。体感レイテンシは処理時間の合計よりも、最初の音声が届くまでの時間に強く連動します。
スケール時に最初に壊れるのはどこか？
チェーンのどこかにある同時実行数の上限です。多くの場合、モデルではなく音声プロバイダーやメディアサーバーが先に限界を迎えます。
