OpenAI は 5 月 4 日に音声 AI 基盤の詳細を公開—毎週 9 億のアクティブユーザー（Weekly Active Users）向けの音声 AI サービスを支えるため、チームが WebRTC スタックを再設計し、メディア接続層を従来の「1 ポートにつき 1 session」の構成から、Go で書かれた薄型 relay に書き換え、すべての WebRTC session の状態を「transceiver」というサービスに集約した。OpenAI 公式ブログでは、このアーキテクチャが同時に ChatGPT の音声モード、Realtime API、そして複数の研究プロジェクトを支えることを説明している。音声 AI エンジニアリングに携わるあらゆるチームにとって、本件は「世界規模の音声 AI をどう成立させるか」を示す貴重な技術文献だ。
3 つの技術的制約：OpenAI 規模では従来の WebRTC がすべて壁に突き当たる
OpenAI のエンジニアリングチームは、記事の中で「規模を拡大した後に互いに衝突する」3 つの制約を明確に挙げている。
従来の「1 session につき 1 ポート」のメディア終端（per-session port termination）方式は OpenAI の基盤には不向き—毎週 9 億ユーザーが同時に音声 session を開始し得る状況では、各 session がそれぞれ 1 つのポートを占有する設計だとネットワーク資源が尽きてしまう
状態を持つ ICE（Interactive Connectivity Establishment）と DTLS（Datagram Transport Layer Security）の会話は、安定した所有者（owner）が必要—分散システムでは、session の状態が複数のサービスに分担されると、フォールトトレランスや移行が極めて複雑になる
グローバルなルーティングは低い最初のホップ遅延（first-hop latency）を維持しなければならない—音声 AI の「自然さ」は turn-taking（会話の切り替え）のスムーズさに左右され、最初のホップが 100ms を超えると明確に途切れる
OpenAI の要件リストも同様に明確だ：グローバル到達（9 億+ ユーザーをカバー）、迅速な session 立ち上げ（ユーザーが話し始めれば話せる）、低く安定したメディアの往復時間（低 jitter とパケットロスを含む）。
解決策：Go で書かれた薄型 relay + 集中型 transceiver サービス
OpenAI のアーキテクチャは 2 つの層で構成されている。
Relay 層—Go で実装され、意図的にシンプルさを保つ。普通の Go プロセスがソケットからパケットのヘッダを読み取り、少量のトラフィック状態を更新し、パケットを転送するだけで、WebRTC を終端しない。relay を水平スケールできるようにするのが、この設計の鍵だ—完全な WebRTC 状態を維持する必要がなく、relay 同士の互換性も損なわれず、単一障害点があっても session 全体が途切れない。
Transceiver 層—唯一 WebRTC session の状態を持つサービスで、ICE の接続チェック、DTLS ハンドシェイク、SRTP の暗号鍵、そして session のライフサイクル管理を含む。これらの状態を 1 つのサービスに集約することで session の帰属を推論しやすくし、バックエンドサービスは通常のサービスのように拡張できるため、各自が WebRTC の peer になる必要はない。
この設計の巧みさは、「状態が必要な部分」と「無状態の部分」を厳密に分離している点にある。Relay は無状態のデータプレーン（大量に複製可能）、transceiver は状態を持つコントロールプレーン（少量だが状態は完全）。このレイヤ分離により、OpenAI は使用量に応じて水平拡張でき、WebRTC 接続数の爆発を心配する必要がなくなる。
なぜ Go を使うのか：音声 AI 工学における選択ロジック
OpenAI は記事の中で、relay を Go で書き、意図的に狭い設計（窄い範囲）に保って実装していると明確に述べている。その背景にあるエンジニアリング上の理由：
Go の goroutine は「 1 ポートで数万の接続を処理する」といった IO バウンドのタスクに対して素の支援があり、複雑なイベントループを用意する必要がない
標準ライブラリの net パッケージで UDP パケットを直接読み取れるため、C のライブラリへの紐づけは不要
コンパイルすると単一の静的 binary となり、デプロイやコンテナ化、さらにアーキテクチャ間（x86/ARM）の対応が容易
Go のメモリ管理は「大量の短命オブジェクト」（各パケットを解析するたびに必要になる）に相性が良く、GC 停止時間もコントロールしやすい
これらからも、Cloudflare、Tailscale、HashiCorp などといった現代の基盤層で Go の浸透率が引き続き上がっている理由が説明できる。これは「Go が他の言語よりすごい」という話ではなく、「Go は IO バウンドで、水平拡張が必要な基盤のシーンで、書くのがいちばん素直」だからだ。
Cloudflare の対置：Realtime Voice AI の戦場
Cloudflare も同期間（5 月上旬）に技術ブログ〈Cloudflare は建構即時語音代理最好的地方〉を公開し、OpenAI と対位する形で自社の案を提示している。両者の方針は分かれる。
OpenAI：自社で WebRTC relay／transceiver スタックを構築し、サードパーティに依存しない。メディア層も自社の技術スタックに組み込む
Cloudflare：WebRTC のメディアサービスを自社 Workers プラットフォームの延長として位置づけ、開発者に「ワンストップ」基盤を提供する
中小規模の AI アプリケーションチームにとっては、Cloudflare の路線のほうがより実用的だ。API を直接呼び出せばよく、WebRTC 基盤を自作する必要がない。一方で OpenAI 規模のチームにとっては、自前構築が必須の道筋になる。外部サービスの SLA、課金構造、地理分布は、完全に自社の要件に合わせられるとは限らない。
今後の観察：transceiver のオープンソース化、Realtime API の規模、競合の対応
次の段階で注目すべきポイントは以下だ。
OpenAI が transceiver／relay の部分をオープンソースにするか—Anthropic、Google、xAI などの競合も自社で音声スタックを構築している。もし OpenAI が公開すれば、産業標準になる可能性が高い
Realtime API の課金と規模—現状は主に ChatGPT のサブスクリプションでの上乗せ（按分）に頼っているが、API の収益が伸びた場合、独立したプロダクトラインになり得るか
Anthropic と Google の対応—Claude と Gemini はどちらも音声に対応済みだが、遅延と規模の面で OpenAI にはまだ差がある。今回の技術開示が、彼らのエンジニアリングの追随を加速させるか
台湾の AI アプリ開発者にとって、音声 AI は 2026 年下半期の重要な戦場になる。コールセンター、教育、車載、IoT などの場面では、低遅延の対話が必要になる。OpenAI が今回行った技術開示は、「音声スタックを自前で作るべきか、それとも第三者の API を使うべきか」を判断するための、最重要な参考の 1 つだ。
この記事：OpenAI が WebRTC 音声スタックを再構築—900M の週活ユーザー、Go 製 relay が中核。最初に出現したのは 鏈新聞 ABMedia。
