5月4日、OpenAIが「How OpenAI delivers low-latency voice AI at scale」と題した記事を公開した。この記事では、ChatGPTの音声機能やRealtime APIを9億人以上の週間アクティブユーザーに低遅延で配信するために、OpenAIがWebRTCの根本的な制約を乗り越えた技術的挑戦について詳しく紹介されている。
音声AI時代が露呈したWebRTCの限界
ChatGPTの音声機能やAdvanced Voice Modeの登場により、リアルタイム音声AI体験への需要が爆発的に増加している。しかし、従来のビデオ会議システム向けに設計されたWebRTC（Web Real-Time Communication）は、大規模な音声AI配信において致命的な制約を抱えていた。
WebRTCの標準実装では「1セッション1UDPポート」というモデルが採用されている。つまり、各音声セッションが個別のネットワークポートを占有する仕組みだ。これは小規模なビデオ通話では問題ないが、OpenAIのような規模では以下の深刻な問題を引き起こす：
- クラウドインフラの限界：AWS ELBやGoogle Cloud Load Balancerなど、現代のクラウドロードバランサーは数万のUDPポートを前提としていない
- セキュリティリスクの拡大：大量のUDPポート開放はファイアウォール設定を複雑化し、攻撃面を広げる
- Kubernetesとの相性問題：コンテナの頻繁な再起動・スケーリングでポート管理が破綻する
革新的な解決策：パケット転送とプロトコル処理の分離
OpenAIが開発したのは、WebRTCスタックをRelay（中継層）とTransceiver（処理層）に分離する新アーキテクチャだ。この設計により、従来の1対1対応の制約を打ち破った。
Transceiver：WebRTCの「頭脳」
- ICE（インターネット接続確立）やSRTP暗号化などWebRTCの複雑な状態管理を担当
- SDP（Session Description Protocol）によるコーデックネゴシエーション
- OpenAIのAIモデルとの実際のデータ交換
Relay：パケットの「配達員」
- 軽量なUDPパケット転送のみに特化
- メディア内容を復号せず、宛先判断のみ実行
- 複数のRelayが同一UDPポートを共有可能
ICE usernameを使った巧妙なルーティング戦略
最も技術的に興味深いのは、WebRTCの接続確立プロトコルであるICEのusername fragment（ufrag）を活用したルーティング手法だ。
WebRTCでは、クライアントとサーバーがNAT（ネットワークアドレス変換）を越えて接続するために、STUNプロトコルで接続性をテストする。この際、各セッションは一意のufragを持つ。OpenAIは、このufragにルーティング情報を巧妙に埋め込んだ。
従来の流れ：
クライアント → 専用UDPポート → 専用Transceiver
OpenAIの新方式：
クライアント → 共有UDPポート → Relay（ufrag解析）→ 適切なTransceiver
この仕組みにより、外部データベースへの問い合わせなしに、パケット内の情報だけで宛先を決定できる。
音声AI特有の3つの厳格な要件
OpenAIが音声AIで目指したのは、単なる技術デモではなく、実用的な会話体験だ。そのために以下の要件を満たす必要があった：
- 即座の応答開始：ユーザーが話し終わる前から、転写・推論・音声生成を並列実行
- グローバル低遅延：世界中の9億ユーザーに対して会話レベルの応答速度
- プッシュ・トゥ・トーク不要：自然な会話のように、いつでも話し始められる体験
WebRTC採用の決定的理由：ストリーミングの力
音声AIにWebRTCが適している理由は、音声データが連続ストリームとして到着することにある。従来のHTTP APIでは、ユーザーが話し終わってから処理が始まるが、WebRTCなら話している最中からリアルタイム処理が可能だ。
また、WebRTCは以下の複雑な処理を標準化している：
- NAT越え（ICE）
- エンドツーエンド暗号化（DTLS/SRTP）
- 音声品質の動的調整（RTCP）
- コーデック自動選択
興味深いことに、OpenAIにはWebRTCの原設計者の一人であるJustin Uberti氏と、Go言語WebRTC実装「Pion」の創設者Sean DuBois氏が在籍している。この専門知識が、今回の革新的アーキテクチャを可能にした。
グローバル展開：地理的分散による遅延最小化
この仕組みをグローバルに展開したのがGlobal Relayシステムだ。世界各地にRelay入口点を配置し、Cloudflareのgeolocation steeringと連携して、ユーザーを最寄りのエントリーポイントに誘導する。
シグナリング（接続確立）段階でHTTP/WebSocketリクエストを近くのTransceiverクラスタに向け、実際のメディア通信も同じ経路を使用する。これにより、接続確立とデータ転送の両方で遅延を最小化している。
実装の技術的詳細
RelayサービスはGo言語で実装され、パフォーマンスを重視した設計となっている：
機能の意図的制限
- プロトコル終端処理なし（STUNヘッダー解析のみ）
- セッション状態の最小保持（短期メモリキャッシュのみ）
- 複雑なWebRTC状態管理はTransceiverに委譲
Linuxカーネル機能の活用
SO_REUSEPORT：複数プロセスが同一UDPポートをバインドruntime.LockOSThread：UDP読み取りgoroutineをOSスレッドに固定
この設計により、クライアント側は標準WebRTCライブラリをそのまま使用でき、サーバー側のみでスケーラビリティ問題を解決している。
詳細はHow OpenAI delivers low-latency voice AI at scaleを参照していただきたい。
