OpenAIが音声AIを世界規模で低遅延配信する仕組み
当サイトではアフィリエイトプログラムを利用して商品を紹介しています。
OpenAIが音声AIを再設計した理由
OpenAIは2026年5月、音声AIを世界規模で安定提供するためWebRTCスタックの大規模な再設計を公開しました。ChatGPT音声機能やリアルタイムAPI、さらには会話型エージェントまで、すべてを支えるインフラの中身が詳しく語られています。
再設計の背景には三つの課題があります。週間アクティブユーザー9億人以上へのグローバル対応、セッション開始直後から話せる高速な接続確立、そして自然な会話ターンのための安定した低遅延です。これらが同時に求められる規模で、従来のアーキテクチャが限界を迎えていました。
WebRTCが音声AIに選ばれた理由
WebRTCはブラウザやモバイルアプリで広く実装されているオープン規格で、NAT越えの接続確立や暗号化通信、コーデック交渉などリアルタイム通信の難しい部分をすでに標準化しています。OpenAIはこの仕組みを採用することで、クライアント側の実装を変えずに済みます。
音声AIにとって最大の利点は、音声ストリームを連続データとして受け取れる点です。ユーザーが話し終わる前から文字起こし・推論・ツール呼び出し・音声生成を並行して処理でき、ボタンを押して話すシステムとは全く異なる自然な会話体験を実現します。
Kubernetes環境との相性問題
OpenAIは当初、シグナリングとメディア終端を担う単一のGoサービスをKubernetes上で稼働させていました。しかし従来のWebRTCはセッションごとに1つのUDPポートを占有する設計で、大規模な同時接続ではポート枯渇が深刻な問題になります。
さらにICEとDTLSはステートフルなプロトコルのため、同じセッションのパケットを常に同じプロセスが受け取る必要があります。Kubernetesではポッドが頻繁に増減・再配置されるため、セッションの「オーナーシップ」を維持することが難しく、接続失敗や音声途切れのリスクがありました。
リレーとトランシーバーを分けた新設計
これらの課題を解決するため、OpenAIはリレーとトランシーバーを分離したアーキテクチャを構築しました。公開インターネットには最小限の固定UDPポートのみを露出し、バックエンドのトランシーバーへのルーティングはインフラ内部で解決する設計です。
トランシーバーはWebRTCセッション状態（ICE接続確認・DTLSハンドシェイク・SRTP暗号化キー）をすべて一元管理します。これによりバックエンドサービスはWebRTCの複雑な状態管理から切り離され、通常のマイクロサービスとして柔軟にスケールできるようになりました。
関連商品をチェック
9億人の音声会話を支えるインフラ、ちょっと規模感が想像できなくて面白い。自分がChatGPTに話しかけるたびにこんな複雑な仕組みが動いてると思うと、なんかありがたいなと感じる。