9月2日、Eran Stillerが「OpenAI Details GPT-Live's Architecture for Continuous Stateful Voice Interaction」と題した記事を公開した。OpenAIが連続音声インタラクションを実現するGPT-Liveのアーキテクチャ設計を公式ブログで公開したことを受けた報道で、その設計思想の核心は一言で言えば「声は止めてはならない」という原則にある。レイテンシーに敏感なメディアパスをアプリケーションロジックから非同期境界で切り離し、いかなる状況でも音声の継続性を守る——この一点を起点に、トランスポート層から負荷テスト手法まで一貫した設計判断が貫かれている。
リアルタイム音声AIの最大の技術的難題は、応答性を保ちながらいかにスケールするかだ。GPT-Liveは、2024年に発表されたRealtime APIや従来のGPT-4oリアルタイム音声機能をプロダクションレベルで支える基盤として位置づけられており、本記事ではそのエンジニアリング詳細が明らかにされている。
「声は止めない」──非同期境界によるパス分離
GPT-Liveアーキテクチャの核心は、レイテンシーに敏感なメディアパスとアプリケーションロジックを非同期RPC境界で明確に分離するという設計判断にある。
OpenAI Realtime AI責任者のJustin Uberti氏はInfoQに対してこう語っている。
「目標とするレイテンシーを達成するには、一貫したメディア配信が不可欠でした。要するに『声は止めてはならない』ということです。そこで、ライブパスにはメディアパイプラインと推論ループだけを置き、デリゲーション、ツール使用、永続化、その他のアプリケーションロジックはすべて非同期RPC境界の裏側で処理するという原則を採用しました。」
この設計により、外部サービスへの依存や可変レイテンシーを持つ処理が、会話の応答性に影響を与えない構造になっている。Uberti氏はフロンティアモデルへのデリゲーション速度と、音声データを安全システムへフィードする方法の再設計が特に難しかったと述べており、これらはクリティカルパスから切り離したことで個別に最適化できたという。
ステートフル推論と文脈のライブマイグレーション
連続音声会話は本質的にステートフルだが、スケールや障害復旧との両立が難しい。GPT-Liveが採用したアプローチは、セッションごとに専用のステートフル推論インスタンスを割り当てつつ、必要に応じてセッションコンテキストをリアルタイムで別インスタンスへ移行するというものだ。
具体的には以下の2つの条件でマイグレーションが発生する。
- 割り当てインスタンスがドレイン（縮退処理）に入ったとき
- セッションがコンテキストの上限に近づいたとき
この仕組みにより、需要に応じてインスタンスを柔軟に増減させながら、会話の継続性を保てる。可用性・弾力性・運用複雑性のトレードオフを、文脈マイグレーションという機構で解決した点はエンジニアとして参考になる設計だ。
WebRTCを捨てずに拡張──WARPとInstant Connect
トランスポート層では、WebRTCを基盤として維持しつつ、WARP（WebRTC Abridged Roundtrip Protocol）とInstant Connectによる起動レイテンシーの削減を図った。
RTP over QUICといった新興標準も検討されたが、Uberti氏はその理由をこう説明する。
「RTP over QUICには期待しているのですが、現時点ではトランスポート層しか提供しておらず、完全なメディアパイプラインではありません。GCCの輻輳制御やRTT対応パス選択といった機能も欠けています。WebRTCのハンドシェイクを簡略化する方が、クライアント・サーバー双方でトランスポート層を置き換えるより現実的でした。」
ここで言及されるGCC（Google Congestion Control）とは、WebRTCが標準的に採用するネットワーク輻輳制御アルゴリズムで、パケットロスや遅延の変化をリアルタイムに検知して送信ビットレートを動的に調整する仕組みだ。またRTT（Round-Trip Time）対応パス選択とは、クライアントとサーバー間の往復遅延を計測し、複数のネットワーク経路の中から最も低遅延なものをリアルタイムに選ぶ機能を指す。これらはリアルタイム音声品質を維持するうえで不可欠な機能であり、RTP over QUICが現時点でこれらを提供していないことが、WebRTCを継続採用した主な根拠となっている。
WARPは以下の3つの改善で構成されており、各改善を独立してデプロイ・検証できる設計になっている。
- SPED（Single-message Protocol Exchange for DTLS）：DTLSハンドシェイクのラウンドトリップ数を削減し、接続確立を高速化する拡張
- DTLS 1.3：DTLS（Datagram Transport Layer Security）の最新版。ハンドシェイクの効率化とセキュリティ強化を両立する
- SNAP（Session Negotiation Acceleration Protocol）：セッションネゴシエーションのオーバーヘッドを圧縮し、初回接続レイテンシーをさらに短縮する仕組み
既存のWebRTCアプリケーションはコード変更なしにこれらの恩恵を受けられるという。WebRTCという枯れた標準を置き換えるのではなく、その上に薄い改善層を積み重ねることで後方互換性と性能向上を同時に達成している点は、実運用を意識した現実的な判断といえる。
本番トラフィックを使った「サイレントテスト」
負荷テストの手法として特筆すべきは、本番の音声セッションをGPT-Liveにミラーリングしつつ、出力を破棄するサイレントテストだ。アプリケーションサービスを実質的に読み取り専用モードで動作させ、ユーザー資格情報なしで音声データをモデルに流した。
このテストにより、合成トラフィックでは検出できなかった問題が明らかになった。Uberti氏は一例を挙げている。
「特定の地域で、GPUとそれにデータを供給するCPUが同一ロケーションに配置されていないケースがあり、予期せぬレイテンシーが発生していました。実際の本番トラフィックに対してこれらの修正を検証できたことで、ローンチ当日に持ちこたえるという確信が得られました。」
合成テストが見逃しやすい地理的分布や実際の音声の多様性を捉えられる点で、このアプローチはリアルタイムAIシステムの検証手法として実践的だ。
詳細はOpenAI Details GPT-Live's Architecture for Continuous Stateful Voice Interactionを参照していただきたい。
