ハクソク

世界を動かす技術を、日本語で。

OpenAIが大規模に低遅延の音声AIを提供する方法

6時間前原文(openai.com)

概要

  • OpenAIはリアルタイムAI対話のためにWebRTCスタックを再設計
  • 低遅延・安定性・グローバル対応を重視したアーキテクチャ
  • 分割リレー＋トランシーバ方式でパケットルーティングを最適化
  • WebRTC標準の利点を活かしつつ、クラウド環境に最適化
  • セッション管理・メディア転送の効率化による自然な音声体験の実現

OpenAIのリアルタイム音声AI体験を支えるWebRTC再設計

  • Voice AIの自然さは会話のスピード維持が鍵
  • ネットワーク遅延が発生すると、即座に「不自然な間」や「途切れ」が発生
  • ChatGPT voiceやRealtime API利用開発者、インタラクティブなワークフローのエージェントにも影響
  • OpenAI規模（週9億アクティブユーザー）での具体要件
    • グローバル対応
    • セッション開始時の高速接続
    • 低遅延・安定したメディア往復時間（低ジッター・低パケットロス）

スケーラビリティとWebRTCの課題

  • 従来のWebRTC（セッションごとに1ポート）はOpenAIのインフラに適合しにくい
  • ICE/DTLSの状態管理と安定したセッションオーナーシップが必要
  • グローバルルーティングでファーストホップ遅延を最小化
  • WebRTCは低遅延音声・映像・データ伝送のオープン標準
    • ICE：接続確立・NAT越え
    • DTLS/SRTP：暗号化
    • コーデックネゴシエーション：圧縮・復号
    • RTCP：品質制御
    • エコーキャンセルやジッターバッファなどのクライアント機能

AIプロダクトにWebRTCが重要な理由

  • NAT越え・暗号化・コーデック管理をクライアントごとに実装不要
  • WebRTCエコシステム（オープンソース実装・標準化）の恩恵
    • Justin Uberti（WebRTC設計者）, Sean DuBois（Pion開発者）もOpenAIに参加
  • AI体験では音声が連続ストリームで届くことが最重要
    • ユーザー発話中に逐次認識・推論・音声生成が可能
    • 「会話的」体験と「プッシュ・トゥ・トーク型」の違い

メディア終端方式の選択

  • SFU（Selective Forwarding Unit）：多者通話・グループ向けに最適
    • 各参加者のWebRTC接続をSFUが終端し、音声ストリームを選択的に転送
    • シグナリング・録音・ポリシー管理が一元化
  • OpenAIの用途は1:1が大半（ユーザー1人⇔モデル1つ）
    • トランシーバモデルを採用
      • エッジサービスがWebRTC接続を終端
      • メディア・イベントを内部プロトコルに変換し、モデル推論・音声生成・オーケストレーションへ

トランシーバサービスの役割と課題

  • シグナリング：SDP交渉・コーデック選択・ICE認証情報・セッション設定
  • メディア：WebRTC接続終端・バックエンドとの接続維持
  • Kubernetes上での運用を想定
    • 従来の「セッションごとに1ポート」モデルは大規模UDPポート管理が困難
    • クラウドLBやKubernetesサービスは数万ポート単位の管理に非対応
    • セキュリティ・監査・オートスケールにも不向き

シングルポート設計とセッションオーナーシップ

  • 1サーバあたり1UDPポート＋アプリ層でのデマルチプレクス
    • ポート数問題は解決
    • ただし、セッションの所有権維持が新たな課題
      • ICE/DTLSは状態フルなため、同一プロセスでパケット受信が必須
      • パケットが別プロセスに届くと接続失敗やメディア破損リスク

各方式の評価とOpenAIの選択

  • ユニークIP:port/セッション：直結だが大規模運用に不向き
  • ユニークIP:port/サーバ：ポート数減だが負荷分散環境では不十分
  • TURNリレー：一元管理可能だがセットアップ遅延や移動時の困難
  • OpenAIのリレー＋トランシーバ方式：UDP公開範囲最小・セッション所有維持・カスタム連携が必要

分割リレー＋トランシーバアーキテクチャの詳細

  • シグナリングはトランシーバが担当、メディアはまずリレーを経由
  • リレーはUDPパケットの軽量転送レイヤー
    • メディア復号・ICE管理・コーデック交渉は行わず、最小限のメタデータで宛先決定
  • トランシーバはWebRTCセッション状態を全て保持
    • クライアントから見れば標準的なWebRTCセッションと同等
  • ファーストパケットルーティングが肝
    • **ICE username fragment（ufrag）**にルーティング情報を埋め込み
    • シグナリング中にトランシーバがufrag生成、リレーVIPとUDPポートをSDPで返却
    • クライアントはVIP:port（例：203.0.113.10:3478）へ送信
  • リレーは最初のSTUNパケットからufragを抽出し、トランシーバへ転送
    • トランシーバは共有UDPソケットで受信、以降はセッション情報でルーティング
  • リレーのセッション情報はメモリ上の最小構成
    • カウンタ・タイマーのみ保持し、再起動時もufragから再構築可能

まとめ

  • OpenAIはWebRTCの標準挙動を維持しつつ、大規模・低遅延・高信頼性を実現
  • 分割リレー＋トランシーバ方式でクラウド・Kubernetes環境に最適化
  • 音声AI体験の自然さと拡張性を両立

Hackerたちの意見

> 音声AIは、会話がスピーチのスピードで進むと自然に感じるんだよね。 […] OpenAIの規模だと、これには3つの具体的な要件があるんだ。900万人以上の週次アクティブユーザーに対するグローバルなリーチ。これって、ChatGPT全体のユーザー数を指してるんだろうけど、音声機能を使ってるのはその中のかなり少ない割合だよね？ こういうことが、ハードウェアやソフトウェアの最適化にどれだけリソースを投資するかっていうビジネスの決定に影響するんだ。
└
そうそう、だから「リーチ」って言葉を使ったんだよね。エンゲージメントに関係なく、その機能に触れる可能性のあるユーザーの総数を指してるんだ。
誰かこれに興味があるなら、pipecatは素晴らしいオープンソースのリポジトリとコミュニティだよ。 https://github.com/pipecat-ai/pipecat
└
これ見てたんだ！いいプロジェクトだね。
└
Pipecatについてもっと早く知っていればよかったな。数週間前に知ったんだけど、Gemma 4が出てから、Gemma 4 + Kokoro TTS + Whisperを使って、自分だけの完全にローカルな音声アシスタントをゼロから作ってるんだ。 https://github.com/pncnmnp/strawberry。PipecatのスマートターンモデルはVADにすごくいいよ。 https://huggingface.co/pipecat-ai/smart-turn-v3
もっと考えられる良いモデルを通しての回答を待つのは全然構わないよ。中断するのに良いサポートがあって、1秒間止まったらすぐに答え始めるんじゃなくて、ちゃんと話し終わったことを理解してくれるならね。
ストリーム中にトランシーバーがクラッシュしたら、アクティブセッションはどう回復されるの？ システムは新しいWebRTCセッションで自動的にコンテキストを再構築するの？
└
今はできないけど、こんな感じのことならできるよ。すべてのWebRTCの状態を保存したり、一時停止したりして、次のプロセスで戻すことができるんだ。
低遅延って、実装の仕方によっては良いことよりも痛点になってるよね。カジュアルな会話をしようとすると、人間は自然に間を取るけど、GPTはそれを「終わった」と受け取って勝手に喋り始めちゃう。年を取るにつれて、言いたい言葉を見つけるのが難しくなってきたし、この速い音声のGPTは、助けになるどころか余計にイライラさせるだけなんだ。何か言う前に、頭の中で文全体を考えなきゃいけないから、全然自然じゃないよ。
└
これは2つの異なる「レイテンシー」のレイヤーだと思う。記事で言ってるレイテンシーは音声ストリーム自体の輸送に関するもので、君のシナリオのレイテンシーは音声ストリーム内でどれくらい早く反応を始めるかに関するものだよ。
└
難しい問題だね。無駄話を止めるためにフィラーを入れちゃうことが多いよ。問題を考えるより、いい感じに聞こえることにIQの大半を使ってる気がする。「うん、絶対そう思うよ…」みたいな感じで。これって、タイマーがあるからか、音声処理がテキストよりもコストがかかるからかもしれないね。テキストの応答はタスクにもっと時間をかけるから。
└
APIを使ってるなら、待つ時間を変更することもできるよ。
└
音声会話では、全く返事をしないか、「了解」とだけ言うように指示してる。完璧ではないけど、あまり干渉しないからいい感じ。
└
レイテンシが高いと、もっと問題になるね。話を一時停止して再開すると、モデルはそれに気づく前にもう話を遮ってしまう。実際の実装に問題があると思う。モデルに「考えを終えたら質問するまで『うん』だけ返事して」って指示したら、だいぶマシになった。でも、声モードは別の理由で完全に使えないと思った。モデルとやり取りするとすごく頭が悪く感じるし、言ったことを繰り返したり言い換えたりするし、毎回の回答が「フック」で終わって、全体のやり取りが馬鹿みたいにロボット的になる。指示を無視して止めてって言っても全然聞かないし、最も重要なのは、ブレインストーミングには全く役立たないってこと。実際に使ってみて、こんなにひどいとは思わなかった。これが彼らのキラーアプリになるはずなのに、モデルがすごく調整不足に感じる。
└
これも経験したことがあって、本当にイライラする。考えが終わってないのに話し続けなきゃいけないプレッシャーがあって、少なくとも自分には不自然に感じる。正しい言葉を探しているときは、それを見つける機会が欲しい。解決策は、レイテンシの高いプロトコルを使うのではなく、もっと賢く一時停止を扱うことだと思う。低レイテンシなら、話を遮ってもボットがすぐにおしゃべりをやめられる。
└
これは、記事で説明されているレイテンシよりも、音声活動検出（VAD）に関係している。
└
そうそう、ユーザーが話し終わったって強い信号を得るには、ある程度の「500msの静寂を待つ」が必要なんだよね。処理を始めて、話し続けたら放棄することもできるけど、それは過剰最適化な気がする。1〜2秒の返信は自然だし、君が指摘したように、文の途中で2〜3秒の間を取るのはすごく普通だよ。
└
強く同意するよ、LLMとやり取りする時は言葉を慎重に選びたい人もいるからね。OpenAIにいろんなチャンネル（開発フォーラムやアプリのフィードバックなど）を通じてこのことを伝えようとしてるんだけど。Grokはプッシュ・トゥ・トークモードをオプションで用意してるけど、ハンズフリーじゃないから、ユーザーが設定できる変数（例えば、音声入力を送る前の秒数の遅延）を持つ方が楽だと思う。
OpenAIが記事を公開して、僕が関わっているPionというライブラリの使い方を広めてくれて本当に感謝してるよ。WebRTCに詳しくないなら、めっちゃ面白い分野だからおすすめ！「WebRTC for the Curious」って本も書いてるんだ。どうやって動くか詳しく説明してるよ。
└
ちょっと関係ないけど、なんでコードベース全体をルートディレクトリに置いて、ネストされたsrcフォルダにしないの？READMEにアクセスするのがすごく難しくなるよね。
└
「WebRTC for the Curious」とPionに感謝！後者は直接使ってないけど、両方を使ってWebRTCをよりよく理解するのに役立ったよ。
└
本を全部オンラインにしてくれてありがとう！前に、webRTCデータチャネルを使ってデータベースからブラウザクライアントにCLI経由でデータを渡すアイデアを考えていたときに、少し読んだことがある。君の本のおかげで、自分のユースケースにはあまり合わないってことが分かった。結局、集中管理のコントロールプレーンとウェブソケットを使ったよ。webRTCデータチャネルとゼロコピーのApache Arrow arraybuffers、duckdbのWASMを組み合わせて面白いことができる気がするけど、まだうまくいってない。
└
ソフトウェア開発者だけが、参照を0から始めるんだよね、笑
└
pion使ってるよ、作ってくれてありがとう！彼らのアプローチが必要だと思ったか気になるな。音声AIのセットアップの速い部分を減らすために、すごく複雑になってる気がした。速いモデルと正確なVADが、WebRTCの遅延時間を微調整するよりずっと重要だと思うんだけど。
これって、OpenAIがもうLivekitをWebRTC/audioに使ってないってことなのかな？
└
確かにそう見えるね。LiveKitサーバーは、このアーキテクチャにはあまり適していない（SFUの議論で基本的に言ってる通り）。ただ、クライアントSDKにはたくさんの便利なものがあるけど。
個人的には、これって単にレイテンシの問題じゃないと思う。音声で人をつなげることで、テキストでは得られないトレーニングデータを得られるからじゃないかな。それが、彼らがSFUを使ってトランシーバーを選んで、マルチパーティをほとんど無視している理由？
ちょっと待って… 本当に彼らがこれを共有してくれて嬉しいけど、OpenAIのリアルタイムオーディオモデルは、能力的にはまだ4oファミリーに縛られていることを忘れないでほしい。今でもすごく役立つと思うけど、このセグメントに本当の競合がいないのが残念。リアルな会話を体験することで、アイデアや概念を表現するのにすごく助けられた。でも、これらはリリースされたときとは違って、最前線のモデルではないことを念頭に置いておく価値があるよ。（サム、これを読んでいたら、新しいリアルタイムオーディオモデルをリリースしてほしい）
└
そうそう、OpenAIのリアルタイム/音声モードはいいけど、新しいモデルと比べるとちょっとバカだよね。よく自分を繰り返しちゃうし。GoogleのGemini flash live 3.1の方がいいよ、特にAPI経由で使うと。ツール呼び出しもできるし（自分で設定すれば、もっと賢いLLMにも呼び出せる）、推論レベルも設定できるし（高めにしてもリアルタイムに近いし）、Google検索で答えを裏付けることもできる。双方向音声が好きで、今のところこれが一番の選択肢だと思う。AIスタジオで試してみてね。
└
うん、タイトルの質問には答えられるよ：「最前線から2年遅れのモデルgpt-4oを使って音声応答を提供することによって」
└
これが彼らの音声モードを使えなくしてる理由なんだよね。4oの返答の仕方が耐えられないし、テキストモードからの質の差がすごいんだ。
└
Grokの音声は意外と良いよ。フロンティアモデルの思考モードには劣るけど、他のプロバイダーの音声モードよりはマシだね。
RFC 9297のサポートがブラウザに早く来てほしい。クライアント-サーバーのシナリオでWebRTCを扱う必要がなくなるからね。