Why WebRTC is the Wrong Choice for Voice AI

OpenAI が最近、大規模な低遅延ボイスAIをどのように提供しているかについての技術的な深掘り記事を公開しました。そのエンジニアリングの成果は素晴らしいものですが、そこには根本的な緊張関係が明らかになっています。彼らは、人間同士の会議用に設計されたプロトコルである WebRTC を、人間とAIのインタラクションのために使用しているのです。

多くの開発者にとって、WebRTC はリアルタイムオーディオのデフォルトの選択肢です。しかし、ボイスAIの要件が進化するにつれて、激しいパケット損失から悪夢のような接続ハンドシェイクに至るまで、WebRTC の制限が重大なボトルネックとなっています。真にスケーラブルで高品質なボイスAI体験を構築するには、WebRTC という「プロトコルのトレンチコート」を超え、QUIC に目を向ける必要があります。

The Product Mismatch: Latency vs. Accuracy

WebRTC は、主に一つの目的、つまりリアルタイムの人間同士の会話のために構築されました。会議通話では、最も重要な要素は「今」です。パケットが失われた場合、WebRTC はそれを気にせず、会話を継続させるためにオーディオをドロップします。これが、通話品質が悪いときにロボットのようなグリッチや歪んだ音声が聞こえる理由です。

ボイスAIの文脈では、この挙動は逆効果です。ユーザーが複雑なプロンプトを入力した場合、例えば「Should I walk or drive to the car wash?」のように、パケットがドロップされると「Should I walk or drive to the car?」に変わってしまう可能性があります。不完全なプロンプトは、不完全な回答を招きます。

低遅延は重要ですが、ユーザーは一般的に、プロンプトが正確にキャプチャされることを確実にするために、200ms の遅延を好むでしょう。WebRTC の、信頼性よりもリアルタイム配信を優先するというハードコードされた執着は、AI インタラクションの「プロンプト・レスポンス」という性質に適合していません。

The Technical Debt of WebRTC

WebRTC を実装するのは非常に困難です。なぜなら、それは単一のプロトコルではなく、約 45 個の RFC と様々なデファクトスタンダードの集合体だからです。この複雑さは、いくつかの重要な方法で現れます。

1. The Connection Handshake Nightmare

WebRTC の接続を確立することは、コストの高いプロセスです。シグナリングサーバー (TCP, TLS, HTTP) とメディアサーバー (ICE, DTLS, SCTP) の間で、セッションを開始するまでに 8 回以上のラウンドトリップ (RTT) が必要になることがあります。エッジノードを使用しても、このオーバーヘッドは顕著です。この複雑さは、WebRTC が Peer-to-Peer (P2P) 接続用に設計されているために存在しており、サーバーが静的な IP を持つ場合に、サーバーに不要な「ダンス」を強いることになります。

2. The Port Scaling Problem

WebRTC は通常、IP の変更（WiFi からセルラーへの切り替えなど）を処理するために、各接続に対してエフェメラルポートを使用することを想定しています。大規模な運用では、これは災難です。サーバーのポートが不足し、企業のファイアウォールによってブロックされます。

これを解決するために、OpenAI を含む多くのサービスは「ハック」に頼っています。複数の接続を一つのポートにマルチプレックス（mux）し、STUN ヘッダーや ufrag を使用してパケットをルーティングします。これは本質的にプロトコルのネイティブな IP 変更への対応能力を損なうものであり、開発者は単にセッション中にユーザーのソース IP が変わらないことを祈るだけになります。

3. Artificial Latency and Buffering

Text-to-Speech (TTS) は、しばしばリアルタイムよりも速く音声を生成できるため、ネットワークの瞬断を滑らかにするためにクライアント側で音声をバッファリングする機会があります。しかし、 WebRTC は到着時間に基づいてレンダリングし、実質的にバッファリング機能を持っていません。音声が速すぎる再生を防止するために、サーバーはパケットを送信する前に人工的な「スリープ」期間を導入しなければならず、これが皮肉にも混雑時のパケット損失のリスクを増大させます。

The Alternative: Why QUIC is the "Chad" of Protocols

WebRTC が問題であるなら、QUIC (HTTP/3 の基盤) は解決策です。QUIC は、設計段階から WebRTC の最も深刻な問題を解決しています。

Connection IDs vs. IP Mapping

TCP や WebRTC とは異なり、QUIC は（受信側が選択する）CONNECTION_ID を使用します。これにより、ユーザーの IP アドレスが変更されても接続を維持することができます。サーバーはソース IP/ポートを追跡する必要はなく、パケット内の ID を参照するだけです。

Stateless Load Balancing

QUIC-LB を使用すると、バックエンドサーバーは自身の ID を CONNECTION_ID にエンコードできます。これにより、ロードバランサーは、パケットをどこに送るべきかを知るためにグローバルな Redis クラスターや共有状態を必要とせず、単に ID を読み取って正しいサーバーへパケットをフォワードできることがれます。これにより、ステートレスなグローバル Anycast ルーティングが可能になります。

Rapid Setup

QUIC はトランスポート層と暗号化のハンドシェイクを組み合わせ、接続セットアップを単 1 回の RTT で完了させます。WebRTC の多段階プロセスと比較して、「音声への到達時間」の時間は劇的に異なります。

Counterpoints and Considerations

WebRTC が利点を持たないわけではないことは重要です。業界の専門家が指摘するように、WebRTC は、以下のような成熟した Audio DSP (Digital Signal Processing) パイプラインのエコシステムを失うことを意味します。

  • Acoustic Echo Cancellation (AEC)
  • Noise Suppression
  • VAD (Voice Activity Detection)
  • NAT Traversal maturity

WebSocket や QUIC への移行には、開発者がこれらの機能を再実装するか、代替ライブラリを見つける必要があります。さらに、真の「リアルタイム」感を得るために、WebRTC の積極的なパケットドロップは、AI の「魔法」がラグによって損なわれるのを防ぐための必要悪であると主張する人もいます。

Final Verdict

WebRTC は、2005 年時代の P2P ビデオ通話のための素晴らしい解決策でした。しかし、2026 年時代のボイスAIのための、レガシーな負担となっています。OpenAI のエンジニアリングチームが、前例のない規模で WebRTC を動作させるために WebRTC をハックすることに成功したとしても、それは本質的に欠陥のあるプロトコルに対する複雑な回避策を構築しているに過ぎません。

次世代のボイスAIを構築する人たちにとって、進むべき道は明確です。QUIC の効率性と WebTransport の柔軟性を活用しましょう。WebRTC を無理に使いこなそうとするのは、やめておきましょう。

Sources