Media over QUIC の記事「OpenAI's WebRTC Problem」は、OpenAIの技術ブログに触発されて書かれた、かなり攻撃的で、でも中身は妙に濃い解説記事です。
ひと言でまとめると、「Voice AIにWebRTCを使うの、ほんとにそれでいいの？」という問題提起ですね。
著者はWebRTCの実装経験がかなり深く、TwitchでもDiscordでもWebRTC関連の仕事をしてきたと語っています。なので単なる机上の空論ではなく、**“実際に地獄を見た人の文句”**として読むと説得力があります。個人的には、こういう「実装して嫌いになった人の文章」はかなり信用できると思っています。きれいごとじゃないからです。
WebRTCは、ブラウザ同士、あるいはブラウザとサーバーの間で、音声や映像をリアルタイムにやり取りするための仕組みです。
たとえばWeb会議サービスではよく使われます。
ざっくり言うと、
というのが強みです。
ただし記事では、ここがそのまま Voice AI には不向き だと主張されています。
理由はシンプルで、WebRTCは「人間どうしの会話」のために強く最適化されているのに対し、Voice AIでは音声をそのままの精度で送る価値が高いからです。
記事のかなり重要なポイントがここです。
WebRTCは、ネットワーク状況が悪くなると、音声パケットを積極的に捨ててでも遅延を低く保とうとする設計です。
これは会議通話なら理にかなっています。会話はテンポが命なので、「少し欠けてもいいからすぐ返す」が正解になりやすいからです。
でもVoice AIでは話が変わります。
たとえばユーザーが
should I walk or drive to the car wash?
みたいな質問をするとき、AI側にはその音声を正確に受け取ってほしい。
多少200msくらい遅れてもいいから、ちゃんと聞き取ってくれたほうが価値が高い、という考え方です。
ここはかなり納得感があります。
人間同士の雑談なら多少途切れても許せますが、AI相手だと「聞き間違い」はそのまま回答品質の悪化に直結します。
つまり、WebRTCが得意な“低遅延”が、AIでは必ずしも正義ではないわけです。
記事のもう一つの面白い指摘がこれです。
Voice AIでは、ユーザーの音声を送るだけでなく、AIが返答を音声で読み上げます。
このとき、Text-to-Speech（TTS、テキストを音声に変換する処理）が、実際の再生時間より速く生成できることがあります。
たとえば、
なら、本当は生成しながらストリーミングして、クライアント側で少しずつ再生すれば快適です。
ところが記事によると、WebRTCは到着時間ベースで再生を管理するので、細かな制御やバッファリングがやりづらい。
ここで著者はかなり強めに、
「WebRTCは無駄に人工的な遅延を入れて、そのうえパケットを落として“低遅延”を維持しようとする」
と批判しています。
このあたりは言い過ぎ感もありますが、要するに言いたいのは、**“すぐ届くこと”より“安定して順番通りに届くこと”のほうが大事な場面がある**ということです。
Voice AIはまさにその代表例だと思います。
記事の後半はかなり技術寄りになります。
でも、一般の人向けに言い換えると、WebRTCは接続の準備が面倒くさいんです。
通常のTCP通信では、サーバーが決めたポートで待ち受けます。
「この住所に届けてね」という感じですね。
でもWebRTCは、
などを乗り越えるために、かなり複雑な手順を踏みます。
著者は、WebRTCの接続確立には最低でも複数回のRTT（Round Trip Time、往復遅延）が必要だと説明しています。
要するに、話し始めるまでに何往復も交渉が必要ということです。
Voice AIで「ユーザーがアプリを開いて、すぐ話せる」ことを目指すなら、この複雑さはかなり痛い。
ここはまさに、WebRTCの弱点が出る場面だと思います。
WebRTC関連の実装では、サーバー側のポート番号の扱いが大きな問題になります。
ポートは、ざっくり言えば「同じサーバーの中のどの窓口に通すか」を表す番号です。
Webサービスなら 443 番ポート（HTTPS）が有名ですね。
ところがWebRTCでは、接続をうまくさばくために、IPアドレスやポートの変化に対応する必要がある。
でもサーバー側のポート数は有限だし、企業ネットワークやFirewallが変なポートを塞いでくることもある。
その結果、現場ではWebRTCの仕様をそのまま守るというより、**実用のためにいろいろ“ごまかす”**ことになる、というのが著者の実感です。
TwitchではUDP 443 を使ったとか、DiscordではCPUコアごとにポートを割り当てるとか、そういう話が出てきます。
こういうの、技術者としてはすごくわかる話です。
仕様に忠実であることより、現実のネットワークで通ることが大事なんですよね。
そしてそれが、WebRTCの複雑さをさらに増やしていく。
記事では、OpenAIがWebRTCの標準仕様をかなり限定的にしか使っていない点も取り上げられています。
たとえば、STUNだけ見て、それ以外は独自の状態管理でさばくようなやり方です。
著者はこれを、
「スケールのための必要なハックだけど、結局はWebRTCの本質的なつらさを回避しているにすぎない」
と見ています。
ここは私もかなり同意です。
大規模サービスでは、理想のプロトコルをそのまま使うより、実際に動く最小限のサブセットに落とし込むほうが多い。
でもそれってつまり、最初からそのプロトコルが用途に合っていない可能性がある、ということでもあります。
記事の提案はわりと明快です。
最初は WebSockets でいいのではないか、という話です。
WebSocketsは、ブラウザとサーバー間で長くつながる通信手段で、WebRTCほど複雑ではありません。
メリットは：
もちろん、WebSocketsはTCPベースなので、遅延や詰まりの影響を受けます。
でも著者は、Voice AIではそれをそこまで大きな欠点と思っていないようです。
そして将来的には、WebTransport / QUIC が本命だと主張しています。
QUICは、HTTPSの新しい土台にもなっている通信プロトコルで、TCPの弱点をかなり改善します。
特に注目されるのは、接続ID（Connection ID） です。
通常のTCPでは、通信相手をIPアドレスとポート番号で見ます。
でもQUICでは、それとは別にConnection ID を使えるので、スマホがWi-Fiから4Gに切り替わってIPが変わっても、通信を続けやすい。
これはかなり大きいです。
モバイル環境では、接続先が変わるのは日常茶飯事ですからね。
さらに著者は、QUICの良さとして ステートレスな負荷分散 を挙げています。
要するに、「どの接続をどのサーバーに割り振ったか」を大きな共有DBで管理しなくても済む、という話です。
これ、運用者から見るとかなり嬉しい。
Redisや独自DBを挟むと、壊れる場所が増えますから。
この文章、かなり煽りが強いです。
「WebRTC is the problem」というタイトル通り、ほぼ敵視しているレベルです。
ただ、冷静に見ると、言っていることは全部が雑というわけではありません。
むしろ、
という指摘は、かなり筋が通っています。
個人的には、「WebRTCが悪い」というより、「WebRTCを万能だと思うとつらい」というのが本質ではないかと思います。
用途に合えば便利。でもVoice AIのように、入力品質やサーバー側の制御が重要な場面では、もっと素直な選択肢のほうが合っている可能性が高い。
この記事はそのことを、かなり気持ちよく、そしてかなり辛辣に突いています。
この記事が面白いのは、単に「OpenAIの技術選定を批判している」からではありません。
WebRTCの“正しさ”が、そのままVoice AIの“正解”にはならないという視点を、実装経験ベースで強く押し出している点です。
結局のところ、技術選びは「何が最新か」ではなく、
その用途で何が一番自然に、壊れにくく、運用しやすく動くか
で決まります。
Voice AIの世界では、WebRTCがその最適解ではないのかもしれない。
少なくとも著者はそう考えていて、読んでいるこちらも「たしかにそれはある」と思わされます。
技術記事としても、愚痴記事としても、かなり味のある一本でした。
