レガシー電話基盤への Voice AI 統合アーキテクチャ

エグゼクティブ・サマリー

WebチャットやテキストワークフローへのLLM導入は比較的容易です。しかし、既存の電話インフラ（従来のPBXシステム、SIPトランク、PSTN回線など）にリアルタイムな対話型ボイスAI（Voice AI）を統合しようとすると、重大な技術的ボトルネックに直面します。それが「レイテンシ（遅延）」です。

人間同士の日常会話におけるターンテイキング（発話の交代）の間隔は200ms〜800msとされています。自動音声エージェントが音声処理と回答生成に2〜3秒を費やしてしまうと、ユーザー体験は一気に破綻します。

本プレイブックでは、既存のPBXやキャリアインフラを全面刷新することなく、レガシーな電話スタックと1秒未満（Sub-second）で応答する現代的なVoice AIパイプラインを架橋するためにIsotope Blueが採用しているアーキテクチャ設計図を解説します。

1. レガシー電話インフラが抱えるボトルネック

従来のエンタープライズ向け電話システム（Asterisk、Cisco Unified Communications、Avaya、あるいはクラウドPBX）は、SIP（Session Initiation Protocol）をはじめとする標準的な音声プロトコルと、非圧縮または狭帯域のコーデックであるG.711 (µ-law/a-law)を用いたRTPメディアストリームに依存しています。

これらのシステムを最新のAIに接続するには、以下3つの明確な課題を解決しなければなりません：

• メディアストリームのインターセプト： 連続する双方向のG.711 RTP音声ストリームを、超低遅延なWebSocketフレームへ変換すること。
• シリアルパイプラインの遅延解消： 音声認識（STT）、大規模言語モデル（LLM）の推論、音声合成（TTS）を順次処理（シリアル処理）する際の合計レイテンシを制御すること。
• 割り込み（Barge-In）制御： AIが発話中に人間のユーザーが割って話しかけた際、即座にAIの音声出力を消音（ミュート）すること。

sequenceDiagram
    autonumber
    actor Caller as 発信者 (ユーザー)
    participant PBX as 既存 PBX / キャリア<br/>(Cisco / Avaya / SIP)
    participant Gateway as Media Gateway<br/>(Twilio / FreeSWITCH)
    participant VAD_STT as VAD & Streaming STT<br/>(Deepgram Nova-2)
    participant Orchestrator as Orchestrator / LLM<br/>(Claude 3.5 / Groq)
    participant TTS as Streaming TTS<br/>(Cartesia / ElevenLabs)

    Caller->>PBX: 通話開始 (PSTN / SIP)
    PBX->>Gateway: SIP Trunk ルーティング
    Gateway->>VAD_STT: G.711 RTP 音声ストリーム (8kHz PCMU/PCMA)
    
    loop リアルタイム双方向通信 (WebSocket)
        VAD_STT->>VAD_STT: 音声アクティビティ検知 (VAD)
        VAD_STT->>Orchestrator: テキスト変換データの逐次送信 (~150ms)
        Orchestrator->>Orchestrator: CRMデータ照会 & LLM生成
        Orchestrator->>TTS: チャンク単位のテキスト送信 (TTFT最適化)
        TTS->>Gateway: 合成音声ストリーム (G.711 再エンコード)
        Gateway->>Caller: 音声再生 (合計レイテンシ ~500ms - 700ms)
    end

    opt 割り込み処理 (Hard Barge-In)
        Caller->>Gateway: ユーザーが発話 (割り込み)
        Gateway->>VAD_STT: 発話検知
        VAD_STT->>Gateway: clear_audio_buffer シグナル (<50ms)
        Gateway--xCaller: AI音声再生を即座に停止
    end

2. ハイレベル・アーキテクチャ & データフロー

エンドツーエンドでの応答時間を800ms未満に抑えるため、従来のバッチ処理を排除し、ストリーミング型マイクロサービスパイプラインを採用します。

graph TD
    A[既存 PBX / SIP Trunk] -->|1. G.711 RTP 音声| B[Media Gateway / WebSocket]
    B -->|2. Dual-channel 8kHz PCMU/PCMA| C[VAD & Streaming STT]
    C -->|3. テキストデータ ~150ms| D[Orchestrator & LLM]
    D -->|CRM / DB 照会 & TTFT最適化| D
    D -->|4. フレーズ単位テキスト| E[Streaming TTS]
    E -->|5. G.711 再エンコード音声| B
    B -->|音声再生| A

パイプラインにおける 5 つのステップ

1. SIPセッション & メディアゲートウェイ： 既存のPBXに着信が入ると、SIPトランキング経由でメディアゲートウェイ（Twilio Media Streams、SignalWire、あるいは内部構築したFreeSWITCHクラスタなど）へルーティングされます。音声はデュアルチャネルの8kHz PCMU/PCMA WebSocketストリームとしてパイプ処理されます。
2. 音声アクティビティ検知（VAD） & ストリーミングSTT： 高周波VADフィルターが人間の発話境界（開始と終了）を特定します。生の音声データチャンクはWebSocket経由で超低遅延STTエンジン（Deepgram Nova-2やWhisper Liveなど）へ直接ストリーミング送信され、約150ms以内にテキストへ変換されます。
3. コンテキスト挿入 & オーケストレーション： 文字起こしされたテキストに発信者コンテキスト（CRMやデータベースからAPI経由で取得）を統合し、高速なLLM推論エンドポイント（Claude 3.5 SonnetやGroqホストのLlamaモデルなど）に投入します。
4. ストリーミング音声合成（TTS）： LLMの全文応答完了を待つのではなく、生成されたトークンを句単位（フレーズ単位）でTTSジェネレーター（ElevenLabsやCartesiaなど）へストリーミング送信し、音声チャンクを即座に生成します。
5. RTP音声パケット化： 合成された音声チャンクは再びG.711形式へ再エンコードされ、WebSocket経由でSIPセッションへと送り返されます。

3. 1秒未満（Sub-Second）の応答速度を実現するエンジニアリング

自然な会話のテンポを生み出すには、パイプラインのすべての工程でミリ秒単位の最適化を図る必要があります。

4. エッジケース（特殊状況）への現場対応

A. ハード・バージイン（ユーザーによる発話割り込み）の実装

自動電話システムにおける最大の摩擦の1つは、AIが話している最中にユーザーが途中で割り込めないことです。

• 解決策： 着信音声トラック上でVAD層を常時稼働させます。AIが音声を出力している最中にユーザーが話し始めたことを検知すると、システムはWebSocket経由で即座に clear_audio_buffer シグナルを発行します。これにより、SIPゲートウェイ上の送信TTSストリームが50ms以内に停止され、稼働中のLLM実行スレッドも即座にキャンセルされます。

B. ファンクションコーリング & データベース連携

発信者が「明日の予約状況を確認できますか？」と尋ねた場合、処理速度が極めて重要になります。

• 解決策： 非同期マイクロサービスを用いてツール呼び出しを分離します。LLMが自然な繋ぎの言葉（例：「お調べいたしますので、少々お待ちください…」）を生成している裏で、ツール呼び出しシグナルを発行します。データベース照会が並行して完了するため、音声出力を途切れさせることなく、更新された情報をLLMストリームへフィードバックできます。

5. デプロイメント・フレームワーク

Isotope Blueでは、既存の通信環境と同層に、高可用性クラウドインフラ（GCP / AWS）上のDocker化されたマイクロサービスとしてVoice AI層を構築します。

graph LR
    subgraph Enterprise["Enterprise Infrastructure"]
        PBX["既存 PBX / Cisco / Avaya"]
        PSTN["PSTN / Carrier Network"]
    end

    subgraph GatewayLayer["Media Gateway Layer"]
        Gateway["Twilio / FreeSWITCH Gateway"]
    end

    subgraph Cloud["High-Availability Cloud (GCP / AWS)"]
        subgraph Microservices["Dockerized Microservices"]
            VAD["VAD Filter"]
            STT["Streaming STT Engine"]
            Orchestrator["Orchestration Service"]
            LLM["LLM Inference Service"]
            TTS["Streaming TTS Engine"]
        end
        CRM[("Enterprise CRM / DB")]
    end

    PSTN --> PBX
    PBX <-->|"SIP / G.711 RTP"| Gateway
    Gateway <-->|"WebSocket Stream"| VAD
    VAD --> STT
    STT --> Orchestrator
    Orchestrator <--> CRM
    Orchestrator --> LLM
    LLM --> TTS
    TTS --> Gateway

この構成により、以下のメリットが約束されます：

• インフラ刷新不要（ゼロ・オーバーホール）： 既存のキャリア契約、電話番号、社内PBXのルーティングロジックをそのまま維持できます。
• エンタープライズ・セキュリティ： 音声ストリームおよび顧客の個人情報（PII）は暗号化されたチャネルで処理され、自動マスキングが適用されます。
• 高い拡張性（スケーラビリティ）： 入電数がスパイクした際も、オートスケーリング設定されたDockerコンテナが動的に拡張対応します。