OpenAI の WebRTC に関する問題

2026 年 5 月 6 日発表

数日前、OpenAI から技術ブログの記事が公開されました。正直に申し上げますと、その投稿は私にとってあまりにも個人的な刺激となり、キーボードを叩いて即興のレビューを書き殴る衝動を抑えることができませんでした。OpenAI の手法を模倣してはなりません。音声 AI に WebRTC を採用すべきではありません。WebRTC こそが根本的な問題です。

私自身について言及しておきましょう。6 年前、Twitch で WebRTC SFU（Selective Forwarding Unit）を開発しました。当初は OpenAI と同様に Pion（Go ライブラリ）を使用しましたが、ベンチマークの結果、速度が遅すぎることを確認したためフォークし、すべてのプロトコルを再実装しました。これは当然の成敗です。さらに一年前、Discord に在籍していた際にも WebRTC SFU を Rust で再設計しました。やはりもちろんそうしておいたわけです。ここから通じることが分かるでしょう。

面白い事実（だが実装者は苦労する）：WebRTC は約 45 の RFC に基づいており、その多くは 2000 年代初頭にさかのぼります。また、非公式ながら事実上標準として扱われている仕様も存在します（例：TWCC、REMB）。これらすべてを実装しなければならないため、決して「面白い」ことではありません。

私は公認の WebRTC 専門家ですが、だからこそ二度と WebRTC を使いたくありません。

プロダクトとの適合性について

熱い話題から冷めてしまう前に、若干便宜を図り、まず OpenAI の投稿や負荷分散に関連する内容に戻りたいと思います。ご安心ください。

WebRTC は音声 AI にとって不適切な選択肢です。直感に反するように思えるかもしれませんが、WebRTC は会議システムのために設計されており、発言という行為自体を含んでいます。ロボットも話し声を発し得るはずです。しかし、WebRTC の根本的な欠陥は「過度に攻撃的」である点にあります。

例えば、OpenAI アプリをスマートフォンで起動して Sky さんに挨拶した後、「車洗い場へ徒歩で行くべきか、自家用車で向かうべきか」と問い合わせたとします。この瞬間、ネットワーク状態が悪化すると WebRTC はプロンプト（音声コマンド）を遮断したりドロップさせたりしてしまいます。「えっ？」と絶叫したくなるような挙動です。WebRTC は低遅延を保つために意図的に音声パケットをドロップする傾向があります。電話会議で音声が乱れたり切れたりする経験がある方は、それがまさに WebRTC の仕業であることをお分かりいただけるでしょう。会議は双方向の即時性を必要とするため、待ち時間を導入することは許されないと考えられていますが、利用者としては、低品質なプロンプトに代わり正しい回答を得るために 200ms ほど待つ方がマシだと考えます。結局のところ、私たちは高価なコストを支払って「大鍋で煮物を作る」わけですが、プロンプトが不適切であれば回答もゴミになります。LLM が特に応答性が低いわけではないのに、ユーザーには待てないという矛盾があります。さらに致命的なのは、ブラウザ内では WebRTC の音声パケットを再送信することが不可能であることです（Discord でも同様の試みが行われましたが、実装レベルで遅延優先のハードコードが決まっています）。

将来的に音声 AI エージェントは遅延を会話領域まで低下させるでしょうが、遅延低減には常にトレードオフが存在します。あえてプロンプト品質を低下させるアプローチが意味のあるものになるかさえ疑わしいのが現状です。

二つの道があり、その一方を選んで進んだ（R.S. トマスの詩による比喩）。申し訳ありませんが両方を行くことはできません。長い間立ち止まり、どちらの道を見下ろしました。やがてトークンを使い尽すまで眺めていた次第です。

TTS はリアルタイムより速い

マイクで話すと、その音声は OpenAI の数十億台あるサーバーの一つに送られ、GPU がテキストから音声へ変換します（TTS）。画期的といえば画期的ですが、仮に 2 秒間の GPU 計算で 8 秒の音声を生成する場合、理想的には生成途中からストリーミングし、クライアントも同時に再生を開始すべきです。そうすれば、ネットワークの一時的な不安定さが起きても一部の音声がローカルでバッファされており、ユーザーは無意識のうちに無問題に進めることができます。しかし残念ながら、WebRTC はバッファリング機能を備えておらず、パケットが到達した順序に基づいて再生されます。スタンプ時刻（timestamp）は単なる推奨事項に過ぎません。ビデオが含まれる場合さらに複雑になり、OpenAI はパケットを正確なタイミングで到達させるために、各パケットの前に意図的な遅延処理（sleep）を追加しなければなりません。もしネットワーク拥塞が起きたら、そのパケットは失われ、再送信も不可能です。OpenAI はまさに人為的に遅延を導入し、それを「低遅延維持」の名目でパケットをドロップする矛盾した行為を行っております。これは YouTube 動画を画面共有形式で表示して画質劣化を受け入れるのと同様の愚行です。

感謝すべきは「Mr. Robot」の友人からいただいた明確な助言です（※ジョークですが、真実です）。WebRTC は実は遅延を増加させます。量は大きくありませんが、オーディオ用では 20ms から 200ms の動的ジャッタバッファを備えており、ネットワークの振れ（ジッター）を整える目的があります。しかし、リアルタイムより速くデータを送信すれば、こうした調整は一切不要です。

ポートに関する課題

さて、OpenAI の記事における技術的な核心部分であるポートの問題について触れてみたいと思います。TCP サーバーをホストする際、特定のポート（例：443 番）を開いて incoming コネクションを受信します。TCP クライアントはランダムに仮想的なエフェメラルポートを選択し、接続はソース/宛先 IP アドレスとポートの組み合わせによって識別されます。例えば、「123.45.67.89:54321 → 192.168.1.2:443」のような形式になります。しかし小さな問題があります。クライアントアドレスは変わり得ます。スマートフォンの接続方式が Wi-Fi からモバイル通信に切り替わると IP が変更され、NAT デバイスも意図せずしてソース IP やポートを任意に変化させ得ます。これらの状況下では接続が切断され、新しい接続確立のための TCP ＋ TLS ハンズシェイク（少なくとも 2〜3 往復の RTT を必要とする）を行わなければなりません。特にライブストリーミング中にネットワークのひっかかりを感じるユーザーは確実に存在します。

WebRTC はこの問題を解決しようと試みましたが、結果として事態を悪化させました。WebRTC インプレメンテーションでは、各接続に対してエフェメラルポートを割り当てる必要があります。これにより、セッションは宛先 IP とポートのみで識別可能になり、ソース情報は不要になります。仮にソース IP/ポートが変更されても、宛先ポートが同じであれば「あの Bob だ」と認識できます。しかし OpenAI が指摘している通り、大規模展開では以下のような問題が発生します。

サーバー側に利用可能なポート数が限定されている
ファヤウォールはエフェメラルポートをブロックする傾向がある（Kubernetes の場合も同様）

IPv6 を活用することで回避できるかもしれませんが、Twitch ですら IPv6 をサポートしていない事実があります。

必要に応じたハック

多くのサービスが WebRTC 仕様の無視を選択しています。これも「当然」の選択ですが、複数の接続を一つのポートに Multiplexing（複数接続の統合）して運用します。Twitch では UDP:443 で WebRTC サーバーを実装しました。本来これは HTTPS/QUIC ポートですが、この偽装によりより多くのファイアウォールを通過できました（例：Amazon 社内ネットワークは約 30 ポートのみを許可）。Discord では CPU コア数に応じたポート範囲（50000〜50032）を使用し、結果としてより多くの企業ネットワークでブロックされます。Amazon 社内ネットワーク上に Discrod Voice コール中なら、長くてもそこへいないでしょうね。

しかし重大な問題は、WebRTC が実質的に「タキシード姿の標準規格群」であり、そのうち 5 つは UDP 上で直接動作します。どのプロトコルがパケットに含まれているか判別するのは容易ですが、各パケットのルートをどのように決定するかは難しい課題です。

STUN：一意な ufrag を選択し、それに基づいてルーティング
SRTP/SRTCP：ブラウザが無作為に選択した ssrc（u32）を利用可能だが、必ずしも確実ではない
DTLS：RFC9146 の普及を祈るしかない状態
TURN：未経験であり、実装経験がない

OpenAI は STUN のみを使用しているようです。プロトコル終端を行わず、 Relay は STUN ヘッダー/ufrag のみ解析し、後続の DTLS、RTP、RTCP ではキャッシュされたステートを利用してパケットを不透明なまま処理します。これは「ソース IP/ポートが変更されることのないことを心から願っています（機能は破損している）」というポジティブな表現です。

OpenAI 規模で負荷分散を実現することは驚異的ですが、このカスタム実装はハックの産物です。しかしコアプロトコル自体に問題があるため、回避策として不可欠と言えます。個人的には「3 つのコビタ」の方が好ましいですね（※ジョーク）。面白い事実：ブラウザはランダムに同じ ssrc を生成することがあり、衝突が発生した場合、ソース IP/ポートのマッピングがない Discord はすべての暗解鍵を試してパケットを復号化します。鍵が合えば接続を識別できます！

往復 RTT と U

OpenAI の投稿では最初の要件の一つとして「セッション開始と同時にユーザーが発話できるよう、高速な接続確立」が挙げられていますが、これは冗談の域を出ません。WebRTC 接続を確立するには最低でも 8 回の RTT（Round Trip Time）が必要です。CDN エッジノードをユーザー近くに配置して RTT を最小化するのは試みましたが、それでも累積誤差は避けられません。

シグナリングサーバー（例：WHIP）：TCP×1、TLS 1.3×1、HTTP×1
メディアサーバー：ICE×1、DTLS 1.2×2、SCTP×2

計算は複雑で、あるプロトコルをパイプライン化することで 0.5 RTT を削減できます（A-Press と同様の概念）。これは非常にマニアックな話題です。WebRTC は P2P 接続をサポートする必要があり、たとえサーバーに静的 IP があってもこの「ダンス」は避けられません。特にシグナリングとメディアサーバーが同一ホスト/プロセスで動作する場合、冗長かつ高コストのハンズシェイクを二重に行わなければなりません。まるで車を運転しながら同時に歩いているようなものです。

プロトコルのフォークについて

これはもともと「面白い事実」として紹介すべき内容でしたが、独立したセクションに升级しました。WebRTC は実質的にプロトコル自体をフォークすることを推奨しています。制限が多すぎて表面的な理解で片付けられません。ブラウザの実装は Google 所有であり、Google Meet に特化しており、会議アプリにとっては存在上の脅威です。そのため、全ての会議アプリ（Google Meet を除く）はネイティブアプリを採用して WebRTC を回避しようとしています。OpenAI は資金面でこのアプローチも可能です。しかし「ベビーカーを風呂場に捨ててしまう」ような過激な選択は避け、ブラウザ対応のある代替プロトコルへの移行を検討すべきです。Discord は WebRTC をこれほどまでにフォークしており、ネイティブクライアントでは SDP/ICE/STUN/TURN/DTLS/SCTP/SRTP などの大部分を実装していません。Web クライアント向けには全て実装する必要がありますが、ここにも課題が残ります。

代わりに何をすべきか

WebRTC でないなら音声 AI 用什么？OpenAI で働いているとしたら、WebSocket を使って音声をストリーミングするでしょう。独自に WebRTC 負荷分散システムを発明する代わりに、既存の TCP/HTTP インフラを有効活用できます。ブログ記事として退屈ですが、シンプルで Kubernetes と互換性があり、スケーラビリティが高いソリューションです。将来的には音声パケットを意図的にドロップしたい状況や、同じ接続でビデオも送信したい場合が来るでしょう。その時は QUIC/WebTransport に切り替えるべきです。

QUIC はこの問題を解決する

長期間 WebRTC を批判してきた私ですが、いよいよ QUIC の良さを称賛すべき時が来ました。前に触れた RTT 問題について振り返ります。QUIC 接続を確立するには QUIC＋TLS で 1 回の RTT 就够了。これは簡単です。さらに深層的な QUIC の仕組み（ turbo_QUIC な人の話ですが）を説明しましょう。

Connection ID：RFC9146 の DTLS セクションで言及されなかった概念です。QUIC はソース IP/ポートに基づくルーティングを放棄し、代わりに各パケットに CONNECTION_ID（0〜20 バイト）を含めます。重要なのは「受信側が選択する」点で、QUIC サーバーは各接続に対して一意の CONNECTION_ID を生成します。これにより、単一のポートで運用しつつソース IP/ポートの変化を検出できます。TCP のような切断ではなく、自動的地址変更が可能です。「バイト浪費だ！」と怒鳴るかもしれませんが、これらバイトは極めて重要です。

Stateless Load Balancing（ステートレス負荷分散）

OpenAI の負荷分散器（大多数同様）は共有状態に依存していますが、これは問題です。スティッキーパケットルーターがあっても負荷分散サーバー自体が再起動/クラッシュする可能性があります。ソース IP/ポートとバックエンドサーバーのマッピングをどこかに保存する必要があります。現在は Redis でマッピングを維持していますが、さらにシンプルなのは「データベースを持たない」設計です。QUIC-LB の仕組みは以下の通り：

クライアントから QUIC 接続が開始されると、負荷分散器は健全なバックエンドサーバーにパケットを転送
バックエンドサーバーでハンドシェイクを完了し、自身の ID を CONNECTION_ID にエンコード
その結果、以降のすべての QUIC パケットにバックエンドサーバーの ID が含まれる

このため、負荷分散器は暗号化鍵やルータ表が必要なく、最初の数バイトをデコードして該当する先へ転送すれば十分です。サーバーの再起動でも影響ありません。また「ステートレス」は「グローバルステートもゼロ」を意味し、Cloudflare は全球アニュキャストアドレス上でこれを実装しています。グローバル Redis クラスターは不要です。

Anycast＋Unicast の活用

OpenAI の投稿によれば、地域ごとの負荷分散器に接続を割り当てるように見えます。機能しますが面白味がありません。Anycast が格段に優れています（過去の QUIC Powers ブログで言及した内容ですが、未読でも構いません）。QUIC の preferred_address 機能が負荷分散を革命的に変える可能性があります。世界中に数千のバックエンドサーバーがあり、同じ anycast アドレス（例：1.2.3.4）をアデバイスします。クライアントがこのアドレスに接続すると、インターネットルーターが適切なサーバーへパケットを転送します。QUIC-LB で指示されたバックエンドへ流量をルーティングすることも可能ですが、それは退屈です。代わりに各 QUIC サーバーにユニキャストアドレス（例：5.6.7.8）を割り当て、ハンドシェイクでは anycast、接続確立後はユニキャストを使用する方式を採用します。

サーバー：1.2.3.4 と 5.6.7.8 の両方で QUIC パケットを受信
クライアント：1.2.3.4 へハンドシェイクパケットを送信
サーバー：QUIC 接続を確立し、preferred_address=5.6.7.8 を指示
クライアント：以降のパケットを 5.6.7.8 へ送信

サーバーが過負荷で新しい接続を受け付けたくない場合、1.2.3.4 のプロモーションを停止すればよいだけで済みます。既存のユニキャスト接続は安全のため切断されません。つまり負荷分散器が不要になり、any cast アドレスは事実上のヘルスチェック役目を果たします。このスケールを実装したいです（オレンジ色の会社勤務者の方は連絡ください）。

まとめ

WebRTC：プロダクトに害を及ぼし、負荷分散にも被害を与え、犬さえも傷つける可能性がある
QUIC：プロダクトを愛し、負荷分散を愛し、確実に犬をも愛する
私にとって QUIC は「チャッド」として上位プロトコルである

公平に言及すると

OpenAI のエンジニアは非常に才能豊かで、前例のないストレス下で活動しています。規模拡大は必須であり、今すぐ必要です。私が退職して情熱プロジェクトに没頭し、ネットミームを追跡する暇人からすれば、批判することは容易ですが、映画評論家がジェレミー・レートを再キャストしたことに憤慨するような高みからの批評とは異なります。明らかな解決策が音声 AI にとって最適な選択肢ではないと考えるべきです。また、明らかな解決策はスケーラビリティ面で困難を伴います。WebRTC はまさに「ジェレミー・レト」そのものです。ここに至った以上、MoQ（Multi-Owner QUIC）も音声 AI には完全適合とは言えません。キャッシュ/ファナウトなどのセマンティクスは 1:1 オーディオでは無意味です。いずれにせよ、QUIC の採用を強く推奨します。

最後に

もし議論や交流を望む場合は、meself@kixel.me までご連絡ください。私はフレンドリーです。後悔されないでしょう。おそらく…

執筆：@kixelated

Japanese Translation: