OpenAIはいかにして低レイテンシの音声AIを大規模に配信しているのか

#はじめに

リアルタイムの音声インタラクションは、急速に会話型AIの新たなフロンティアとなりつつある。ユーザーが画面上にトークンが流れるのを見ることに慣れているテキストベースのチャットとは異なり、音声コミュニケーションには全く異なる技術的パラダイムが求められる。人間の会話におけるレイテンシの許容度は極めて厳格だ。わずか数百ミリ秒の遅延でさえやり取りが不自然に感じられ、気まずい中断や会話のテンポの崩れにつながる。

最近、OpenAIは待望のエンジニアリングアップデートを公開し、驚異的な9億人の週間アクティブユーザーに対して、どのように低レイテンシの音声AIを提供しているのか、その詳細を明らかにした。この規模でリアルタイムメディアを配信することは、インフラストラクチャにおける巨大な課題である。彼らの記事では、従来のメディアサーバーアーキテクチャから脱却し、WebRTCプロトコル上に構築された高度に最適化された独自の構成へと移行するという、非常に興味深いアプローチが明かされた。

リアルタイムAIアプリケーションを構築するエンジニアにとって、彼らのアプローチは、暗黙の前提を疑い、特定のユースケースに合わせてネットワークトポロジーを最適化するための素晴らしい手本となる。本記事では、彼らが何を構築したのか、その理由、そしてそれが業界全体にもたらす技術的な影響について深く掘り下げていく。

#直面した課題

エンジニアリングチームが、1秒未満のリアルタイムな音声や映像をインターネット経由で転送する必要がある場合、WebRTCが疑いようのない標準技術となる。NAT越え、パケットロス隠蔽、輻輳制御、そしてセキュアな通信といった、パブリックインターネットの厄介な現実的な問題を標準で処理してくれるからだ。

しかし、WebRTCをスケールさせる際の一般的なアプローチは、SFU（Selective Forwarding Unit）を使用することである。SFUは主に、ZoomやGoogle Meetのような多人数参加型の会議システム向けに設計されている。1人の参加者からメディアストリームを受け取り、それを他の複数の参加者へ選択的に転送する役割を担う。

OpenAIは、自分たちのワークロードがそれらとは根本的に異なることに気づいた。AIとの音声インタラクションは、1人のユーザーが1つのモデルと話すという、完全な1対1の通信なのだ。1対1のアーキテクチャにSFUを採用すると、不要な計算コストとルーティングのオーバーヘッドが生じてしまう。さらに、規模を拡大する中で、OpenAIは従来のWebRTC終端における3つの致命的な制約に直面した。

• ポート管理: 標準的なWebRTC実装では、セッションごとに1つ以上のUDPポートを必要とすることが多い。9億人のユーザー規模で運用する場合、エッジサーバーでのポート枯渇は深刻なインフラのボトルネックとなる。
• セッションの安定性: WebRTCは、NAT越えのためのICE（Interactive Connectivity Establishment）や暗号化のためのDTLS（Datagram Transport Layer Security）といった、ステートフルなハンドシェイクに依存している。これらのプロトコルは、セッション状態を保持する特定のノードに対して極めて安定した接続を必要とする。
• グローバルルーティング: 人間同士の会話に近いレイテンシを実現するには、ユーザーの端末からOpenAIのネットワークまでの「ファーストホップ」を最小化しなければならない。そのためには、パブリックインターネットを経由してトラフィックを中央のデータセンターに引き込むのではなく、世界中に配置されたエッジのPoP（Point of Presence）で接続を終端する必要がある。

#解決策とその重要性

これらの大規模な制約を解決するため、OpenAIは推論バックエンドから重いWebRTCのロジックを切り離し、エッジに特化したレイヤーを導入する決断を下した。彼らはこれを**スプリットリレー・トランシーバー・アーキテクチャ（split relay plus transceiver architecture）**と呼んでいる。

バックエンドのPythonやC++の推論サーバーを、複雑なICEやDTLSの状態遷移を管理する必要がある完全なWebRTCピアとして動作させるのではなく、OpenAIはネットワークのエッジに特化したリレーノードを配置した。

これらの軽量なエッジノードが、クライアントが要求する複雑なプロトコルのセマンティクスを全て処理する。ユーザーのモバイルアプリから見れば、標準的なWebRTCエンドポイントと通信しているように見える。しかし内部的には、これらのエッジノードは極めて効率的なパケットルーターとして機能している。WebRTCのペイロードからメディアを展開し、最適化された決定論的な内部プロトコルを用いてバックエンドの推論サーバーへ転送するのだ。

このアーキテクチャの分離は、2つの理由で不可欠である。第一に、推論サーバーはすでに巨大なニューラルネットワークを実行するという計算コストの高いタスクを抱えている。メディアの転送ロジックをオフロードすることで、デプロイとスケーリングがシンプルになる。第二に、このエッジレイヤーによってOpenAIはトラフィックを積極的に多重化できるようになり、数百万の同時セッションを処理しながら、公開用UDPポートの消費を大幅に削減できる。

#技術的な影響

この新しいアーキテクチャの中心にあるのが、Go言語で書かれたオープンソースかつ高度にモジュール化されたWebRTC実装であるPionだ。PionがWebRTCコミュニティで非常に人気を集めている理由は、開発者を硬直化したSFUの枠組みに縛り付けない点にある。コンポーザブル（構成可能）な性質を持つため、エンジニアリングチームは必要なコンポーネントだけを抽出し、高度にカスタマイズされたトランスポートレイヤーを構築することができる。

OpenAIはこのPionを活用して、独自のトランシーバーを構築した。彼らのアプローチと従来のメディアサーバー構成を比較してみよう。

このアーキテクチャの際立った特徴が、**決定論的ルーティング（deterministic routing）**である。ルーティングのメタデータを標準的なプロトコルネイティブのフィールドにエンコードすることで、新規セッションの最初のパケットは、対象となるバックエンドの推論クラスターを即座に特定できる。これにより、接続セットアップのレイテンシは実質的にゼロになり、UI上で接続が確認された瞬間にユーザーは話し始めることができる。

さらに、極めて安定したメディアラウンドトリップタイム（RTT）を維持し、エッジレイヤーでのジッター（揺らぎ）を最小限に抑えることで、AIとの会話のやり取りが非常に小気味よく、自然なものに感じられるのだ。

#今後の展望

OpenAIによるアーキテクチャの公開は、業界にとって重要な転換点となる。テクノロジーの広範なエコシステムがテキストベースのLLMを超え、マルチモーダルでリアルタイムな音声エージェントの構築に向かう中、従来のネットワークインフラのパターンも進化を迫られるだろう。

この移行からは、いくつかのトレンドが浮上すると予想される。

• エッジ終端型メディアサービス: クラウドインフラプロバイダーは、1対1のAIワークロードに特化したマネージドなWebRTC終端レイヤーの提供を開始する可能性が高く、これによりスタートアップ企業の参入障壁が下がるだろう。
• Pionの継続的な成長: Go言語とPionエコシステムの柔軟性は、モダンでカスタマイズされたネットワークプログラミングにおけるデフォルトの選択肢となる。OpenAIのトランシーバーモデルを模倣したオープンソースフレームワークが続々と登場することが予想される。
• プロトコルの進化: AIワークロードに特化したWebRTC拡張の推進や、より高速なセッション再開に向けたハンドシェイクの最適化が進むかもしれない。

#まとめ

10億人近くのユーザーに対して、低レイテンシでリアルタイムな音声AIを配信することは、前例のないエンジニアリングの偉業である。従来の多人数向けメディアサーバーから脱却し、Go言語を活用した独自のスプリットリレーアーキテクチャを採用することで、OpenAIはAIネットワーキングの新たなゴールドスタンダードを確立した。

彼らのエンジニアリング上の決断は、システム設計における重要な教訓を示している。それは、アプリケーションのワークロードが根本的に変化する場合、基盤となるインフラも再構築しなければならないということだ。ビデオ会議向けに設計されたプロトコルは、標準のままでは1対1のAIインタラクションに最適とは言えない。しかし、軽量なルーティングレイヤーのようなインテリジェントな抽象化を施すことで、地球規模で魔法のような会話体験を提供できるようになるのである。