ハクソク

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

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

2026年5月5日原文(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を使ってるなら、待つ時間を変更することもできるよ。

Hacker Newsで議論の続きを見る