音声AIインフラストラクチャ：リアルタイム音声エージェントの構築

2025年12月11日更新

2025年12月アップデート： Deepgram STTは150ms、ElevenLabs TTSは75ms—それでもほとんどのエージェントはスタックレイテンシの累積により800ms〜2秒かかっています。人間の会話には300〜500msの応答時間が必要です。パイプラインレイテンシ：STT（100〜500ms）+ LLM（350ms〜1秒以上）+ TTS（75〜200ms）。本番環境の音声エージェントでは、1ミリ秒たりとも無駄にできません。

Deepgramは150ミリ秒で音声からテキストへの変換を実現します。ElevenLabsは75ミリ秒で音声を合成します。それでもほとんどの音声AIエージェントは応答に800ミリ秒から2秒かかります—レイテンシはスタック全体で累積するからです。¹ コンポーネント単体の性能とエンドツーエンドのパフォーマンスのギャップは、音声AIの核心にあるインフラストラクチャの課題を示しています：音声認識、言語モデル、音声合成を、人間の会話タイミングに合わせたパイプラインに統合することです。

人間の会話は300〜500ミリ秒の応答時間内で行われます。² 500ミリ秒を超える遅延は不自然に感じられます。1.2秒を超えると、ユーザーは電話を切るか、割り込んできます。これらの閾値を満たす音声エージェントを構築するには、スタックの各レイヤーを理解し、適切なコンポーネントを選択し、1ミリ秒が重要なシステムを設計する必要があります。

音声AIスタック

すべての音声エージェントは、連携して動作する4つのコンポーネントに依存しています：³

音声テキスト変換（STT/ASR）： 音声を文字起こしする「耳」。ストリーミング設定に応じて、レイテンシは100〜500ミリ秒の範囲です。

大規模言語モデル（LLM）： 文字起こしされたテキストを処理し、応答を生成する「脳」。レイテンシは最適化されたモデルで350ミリ秒から、最先端モデルでは1秒以上の範囲です。

テキスト音声変換（TTS）： 応答テキストを音声に合成する「声」。最新のストリーミングTTSは75〜200ミリ秒の最初の音声出力時間を実現します。

オーケストレーション： コンポーネント間のリアルタイムフローを管理し、ターンテイキング、割り込み、セッション状態を処理する「指揮者」。

レイテンシの方程式

音声AIのレイテンシはパイプライン全体で累積します：⁴

総レイテンシ = STT + LLM + TTS + ネットワーク + 処理
           = 200ms + 500ms + 150ms + 50ms + 100ms
           = 1000ms（典型的な値）

500ミリ秒未満の応答を実現するには、各コンポーネントを圧縮するか、ストリーミングによってパイプラインを並列化する必要があります—LLMが生成を完了する前に音声合成を開始し、ユーザーが話し終わる前に部分的な文字起こしを処理します。

音声テキスト変換インフラストラクチャ

ASRレイヤーは音声ストリームを言語モデルが処理できるテキストに変換します。プロバイダーの選択には、レイテンシ、精度、コストのバランスが必要です。

プロバイダー比較

Deepgram Nova-3：⁵ - 最初のトークンまでの時間：約150ms（米国）、250〜350ms（グローバル） - 単語エラー率：18.3% - リアルタイムファクター0.2〜0.3xでストリーミング最適化 - 価格：$0.0043/分（従量課金） - 最適な用途：速度を優先する低レイテンシ音声エージェント

AssemblyAI Universal-2：⁶ - レイテンシ：300〜600ms - 単語エラー率：14.5%（ストリーミングモデルの中で最高精度） - 医療や営業などのドメイン固有のパフォーマンスが優秀 - 価格：$0.00025/秒 - 最適な用途：生の速度よりも精度を必要とするアプリケーション

Whisper（セルフホスト）：⁷ - レイテンシ：1〜5秒（バッチ）、380〜520ms（WhisperX最適化） - オフライン文字起こしで最高精度 - 本番ストリーミングには相当なエンジニアリングが必要 - 最適な用途：バッチ処理、ハイブリッドアーキテクチャ

Groqアクセラレーテッド Whisper： - レイテンシ：LPUハードウェアで300ms未満 - Whisperの精度とストリーミングレイテンシを両立 - GroqCloudを通じた限定的な可用性 - 最適な用途：品質重視のリアルタイムアプリケーション

ASRインフラストラクチャパターン

ストリーミングアーキテクチャ： 完全な発話を待つのではなく、音声が到着したらすぐに文字起こしを開始します。部分的な結果は、ユーザーが話し終わる前に下流のコンポーネントに送られます。

# ストリーミングASRパターン
async def transcribe_stream(audio_stream):
    async for chunk in audio_stream:
        partial = await asr_client.transcribe_chunk(chunk)
        if partial.is_final:
            yield partial.text
        else:
            # 予測用に中間結果を送信
            yield partial.interim_text

音声活動検出（VAD）： ユーザーがいつ話し始め、いつ話し終わるかを検出します。VADが貧弱だと、早すぎるカットオフ（ユーザーを遮る）か、過度な遅延（すでに発生した沈黙を待つ）のいずれかが発生します。

エンドポインティング： ユーザーが自分のターンを終えたかどうかを判断します。積極的なエンドポインティングはレイテンシを削減しますが、話者を遮るリスクがあります。保守的なエンドポインティングは完全性を確保しますが、遅延が追加されます。

セルフホストASRのGPU要件

セルフホストのWhisperデプロイメントにはGPUアクセラレーションが必要です：⁸

本番環境の音声テキスト変換は通常、H100ではなくA100またはRTX 6000 Adaで実行されます—ワークロードは生のコンピューティングよりもメモリ帯域幅から恩恵を受けます。

大規模言語モデルレイヤー

LLMは文字起こしされた音声を処理し、応答テキストを生成します。モデルの選択はレイテンシと会話品質の両方に大きく影響します。

モデルレイテンシプロファイル

超高速（350ms未満）：⁹ - Gemini Flash 1.5：最初のトークンまで約300ms - Groqで提供されるLlama：LPUで約200ms - 最適な用途：最大の応答性、シンプルなクエリ

高速（350〜700ms）： - GPT-4o-mini：約400ms - Claude 3.5 Haiku：約350ms - 最適な用途：速度と能力のバランス

標準（700ms〜1秒以上）： - GPT-4o：約700ms - Claude 3.5 Sonnet：約800ms - 最適な用途：複雑な推論、品質重視のアプリケーション

最適化戦略

ストリーミング生成： 完全な応答を待つのではなく、LLMトークンが到着したらTTS合成を開始します。最新のオーケストレーションパイプラインは、トークンを直接音声合成にストリーミングします。

投機的実行： 部分的な文字起こしに基づいて可能性の高い応答を予測します。ユーザーが話し終わる前に応答の生成を開始し、最終的な意図と一致しない予測は破棄します。

モデルルーティング： シンプルなクエリは高速モデルに、複雑なクエリは高性能モデルにルーティングします。分類器は数ミリ秒でクエリの複雑さを判断します。

# モデルルーティングパターン
def route_query(transcript, context):
    complexity = classify_complexity(transcript)
    if complexity == "simple":
        return "gemini-flash"
    elif complexity == "moderate":
        return "gpt-4o-mini"
    else:
        return "gpt-4o"

プロンプト最適化： 短いプロンプトは処理時間を短縮します。プロバイダーがプロンプトキャッシングをサポートしている場合は、システムプロンプトをキャッシュします（Anthropicはキャッシュされたプレフィックスで90%のコスト削減を実現）。

テキスト音声変換インフラストラクチャ

TTSはLLMが生成したテキストを自然な音声に変換します。このレイヤーはボトルネック（歴史的に2〜3秒）から強み（最新プロバイダーで75〜150ms）へと変化しました。

プロバイダー比較

ElevenLabs Flash v2.5：¹⁰ - 最初の音声出力時間：75ms - 音声品質：業界最高レベルの自然さ - 感情表現：優れた表現力 - 価格：$0.050/1,000文字 - 最適な用途：品質重視のアプリケーション

Cartesia Sonic：¹¹ - 最初の音声出力時間：40〜95ms - リアルタイム会話専用に構築 - 負荷下でも一貫した低レイテンシ - 価格：$0.038/1,000文字 - 最適な用途：レイテンシ重視のアプリケーション

Deepgram Aura-2：¹² - 最初の音声出力時間：150ms未満 - エンタープライズグレードの信頼性 - 大規模でコスト効率が良い - 価格：$0.030/1,000文字 - 最適な用途：大量のエンタープライズデプロイメント

PlayHT： - レイテンシ：約300ms - 豊富な音声ライブラリ - 音声クローン機能 - 低価格帯 - 最適な用途：コスト重視のアプリケーション

TTSインフラストラクチャパターン

ストリーミング合成： LLMからテキストが到着するに従って、順次音声を生成します。完全な文が合成される前に、音声チャンクをユーザーに送信します。

音声バッファリング： 合成タイミングのばらつきにかかわらず、再生をスムーズにするために小さなバッファを維持します。バッファが大きすぎるとレイテンシに影響し、小さすぎると音声が途切れます。

音声キャッシング： 頻繁に使用されるフレーズ（挨拶、一般的な応答）を事前に合成された音声としてキャッシュします。キャッシュされたコンテンツのTTSレイテンシを完全に排除します。

オーケストレーションプラットフォーム

オーケストレーションレイヤーはASR、LLM、TTSコンポーネントを接続し、テレフォニー、ターンテイキング、セッション管理を処理します。プラットフォームの選択が開発速度と本番環境の信頼性を決定します。

プラットフォーム比較

Vapi：¹³ - 焦点：ターンキー音声エージェントプラットフォーム - テレフォニー：ネイティブSIP/PSTN統合 - カスタマイズ：モジュラーコンポーネント選択 - 価格：$0.05/分 + コンポーネント費用 - 最適な用途：迅速なデプロイメント、電話中心のアプリケーション

LiveKit：¹⁴ - 焦点：オープンソースのリアルタイムインフラストラクチャ - アーキテクチャ：エージェントフレームワーク付きのWebRTCネイティブ - カスタマイズ：フルコントロール、セルフホスト可能 - 価格：無料ティア（100同時接続、5,000分/月）、有料は$50/月から - 最適な用途：カスタムアプリケーション、フルコントロールを必要とするチーム

Retell AI：¹⁵ - 焦点：自然な会話フロー - 差別化要因：最適化されたターンテイキングと割り込み処理 - コンプライアンス：HIPAAおよびSOC 2 Type II - 価格：$0.07+/分 - 最適な用途：会話品質優先、エンタープライズコンプライアンス

Pipecat： - 焦点：オープンソースエージェントフレームワーク - 統合：主要クラウドプロバイダーと連携 - カスタマイズ：非常に柔軟なパイプライン構築 - 最適な用途：プラットフォームロックインなしでフレームワークを求める開発者

選択基準

アーキテクチャパターン

カスケードパイプライン（ASR → LLM → TTS）

従来のアーキテクチャは、音声を個別のステージで処理します：¹⁶

音声 → ASR → テキスト → LLM → 応答テキスト → TTS → 音声

利点： - コンポーネントのモジュール性（プロバイダーの簡単な交換） - 成熟したツールとデバッグ - 予測可能なコスト構造（会話の長さに関係なく約$0.15/分） - 透明な中間表現（テキストは検査可能）

課題： - ステージ間でのレイテンシ累積 - テキスト表現での情報損失（韻律、感情） - 複雑なストリーミング調整

Speech-to-Speech（S2S）

エンドツーエンドモデルは音声を直接音声に処理します：¹⁷

音声 → マルチモーダルモデル → 音声

例： - GPT-4o音声モード - Moshi（Kyutai Labs） - Ultravox

利点： - 韻律情報の保持 - 潜在的に低いレイテンシ（単一モデル） - オーバーラップする発話の自然な処理

課題： - 高コスト（長い会話で約$0.30〜1.50/分） - 限られたカスタマイズ（コンポーネント交換不可） - デバッグの不透明性（中間テキストなし）

ハイブリッドアプローチ

本番システムはアーキテクチャを組み合わせることが増えています：

S2Sフォールバック付きカスケード： 標準的なインタラクションにはカスケードを使用し、複雑なオーバーラップダイアログにはS2Sに切り替えます。

並列処理： ASRと意図予測を同時に実行します。ASRが完了する間に、予測された意図に基づいて応答生成を開始します。

投機的TTS： 可能性の高い応答音声を事前生成します。予測が一致すればキャッシュされた音声を即座に再生し、そうでなければ合成にフォールバックします。

音声AIインフラストラクチャのスケーリング

同時キャパシティプランニング

音声AIはテキストベースのAIとは異なるスケーリングをします。各同時通話には、パイプライン全体で専用の処理リソースが必要です。¹⁸

GPU当たりのキャパシティ（セルフホスト）：

マネージドサービスのキャパシティ： クラウドプロバイダーはスケーリングを自動的に処理します