OpenAIが大規模で低遅延な音声AIを提供する仕組み

openaijamodel: gpt-5-mini-2025-08-07

公開日: 2026-05-04 — 著: Yi Zhang と William McDonald（メンバー・オブ・テクニカル・スタッフ）

音声によるAIは、会話が話速のまま進むときにのみ自然に感じられます。ネットワークが妨げになると、ユーザーはすぐに違和感のある間（ポーズ）、切れた割り込み、あるいはバージイン（割り込み応答）の遅延としてそれを認識します。これは ChatGPT voice、Realtime API を用いる開発者、インタラクティブなワークフローで動作するエージェント、そしてユーザーがまだ話している最中に音声を処理する必要があるモデルにとって重要です。

OpenAI の規模では、これが具体的に三つの要件に落とし込まれます:

9 億以上の週次アクティブユーザーに届くためのグローバルなリーチ
セッション開始後すぐにユーザーが発話を始められるようにする高速な接続セットアップ
ターンテイキングが鮮明に感じられるよう、低ジッタと低パケットロスを伴う低く安定したメディア往復時間

OpenAI のリアルタイム AI インタラクションを担うチームは最近、WebRTC スタックを再設計しました。これによりスケール時に衝突し始めた三つの制約に対処しました: 1) セッションごとにポートを割り当てる媒体終端の方式は OpenAI のインフラに合わない、2) ICE（Interactive Connectivity Establishment）と DTLS（Datagram Transport Layer Security）のようなステートフルなセッションは確実な所有権を必要とする、3) グローバルルーティングはファーストホップのレイテンシを低く保つ必要がある。本記事では、クライアントにとって標準の WebRTC 振る舞いを維持しつつ、OpenAI のインフラ内でのパケットルーティングを変更するために構築した「split relay + transceiver」アーキテクチャを説明します。

WebRTC がリアルタイム AI 製品を可能にする理由

WebRTC はブラウザ、モバイルアプリ、サーバ間で低遅延の音声・映像・データを送るためのオープン標準です。ピアツーピア通話と結びつけて語られることが多いですが、クライアント→サーバのリアルタイムシステムの実装基盤としても実用的です。理由は、インタラクティブなメディアの難しい部分を標準化しているからです:

NAT 越えと接続確立のための ICE
暗号化トランスポートのための DTLS と SRTP
音声圧縮・復号のためのコーデック交渉
品質制御のための RTCP
エコーキャンセレーションやジッタバッファなどクライアント側の機能

この標準化は AI 製品にとって重要です。もし WebRTC がなければ、各クライアントは NAT 越え方法、メディア暗号化、コーデック交渉、変化するネットワーク条件への適応方法を個別に備える必要があります。WebRTC を使うことで、既にブラウザやモバイルプラットフォームで実装されているプロトコルスタックの上にビルドでき、我々はリアルタイムメディアをモデルにつなぐインフラ構築に注力できます。

また、成熟したオープンソース実装やブラウザ・モバイル・サーバの相互運用性を維持する標準作業など、WebRTC のエコシステム自体にも依拠しています。Justin Uberti（WebRTC の初期アーキテクトの一人）や Pion の作成者 Sean DuBois による基盤的な取り組みは、低レベルのトランスポート、暗号化、輻輳制御の動作を再発明するのではなく、実績あるメディアインフラに基づいて構築できるようにしてくれました。幸いにも Justin と Sean は現在 OpenAI の同僚でもあり、我々が WebRTC とリアルタイム AI を近づける方法を導いてくれています。

AI にとって最も重要な特性は、音声が連続したストリームとして到着することです。話すエージェントは、ユーザーがまだ話している間に逐次的に文字起こしや推論、ツール呼び出し、あるいは音声生成を始められます。これは会話のように感じるシステムと、プッシュトゥートークのように感じるシステムとの違いです。

メディアアーキテクチャの選択

WebRTC を選んだ後の次の問いは、どこでそれを終端するか（つまりどこで WebRTC 接続を受け入れ所有するか、例: エッジ）と、それらのセッションを推論バックエンドにどう接続するかでした。終端方式は、リアルタイムセッションの状態、メディアトランスポート、ルーティング、レイテンシ、障害分離の扱い方を決定します。

SFU（Selective Forwarding Unit）は、各参加者から WebRTC ストリームを受け取り、選択的に他の参加者へ転送するメディアサーバです。このモデルでは SFU が各参加者ごとに WebRTC 接続を終端し、AI はセッションのもう一人の参加者として参加します。これはグループ通話、教室、共同会議など本質的にマルチパーティな製品に適します。音声コーデック、RTCP メッセージ、データチャネル、録音、ストリームごとのポリシーを一箇所にまとめられます。

クライアント→AI の製品でも、SFU は信号、メディアルーティング、録音、観測性、将来の拡張（例えば人間へのハンドオフや参加者追加）に proven なシステムを再利用できるため、しばしば初期選択肢になります。

我々のワークロードは異なります。ほとんどのセッションは 1:1—ユーザー1人がモデル1つと話す、またはアプリケーション1つがリアルタイムエージェント1つと話す—で、各ターンのレイテンシ感度が高いです。このトラフィック形態に対して我々はトランシーバモデルを選びました: WebRTC エッジサービスがクライアント接続を終端し、その後メディアとイベントをモデルの推論、文字起こし、音声生成、ツール利用、オーケストレーション向けのより単純な内部プロトコルに変換します。

この設計では、トランシーバが WebRTC セッション状態（ICE 接続チェック、DTLS ハンドシェイク、SRTP 暗号鍵、セッションライフサイクルなど）を唯一所有するサービスです。「終端」とは、トランシーバがこれらのハンドシェイクを完了し、メディアを暗号化・復号するエンドポイントであることを意味します。状態を一箇所に保持することでセッション所有権の理解が容易になり、バックエンドサービスは WebRTC ピアとして機能するのではなく通常のサービスとしてスケールできるようになりました。

コア展開の問題: WebRTC が Kubernetes に出会うと

トランシーバモデルを選択した後、最初の実装は Pion 上に構築した単一の Go サービスでした。このサービスはシグナリングとメディア終端の両方を扱い、ChatGPT voice、Realtime API の WebRTC エンドポイント、いくつかの研究プロジェクトを支えています。操作上、そのトランシーバサービスは二つの仕事をします:

シグナリング: SDP 交渉、コーデック選択、ICE 資格情報、セッションセットアップ
メディア: 下流の WebRTC 接続を終端し、推論やオーケストレーションのために上流のバックエンドサービスへ接続を維持

我々はこのサービスを他のインフラと同様に Kubernetes 上で動かしたかった: ワークロードがスケールアップ・スケールダウンし、需要に応じてホスト間を移動できる環境です。しかし、従来の「セッションごとに1ポート」な WebRTC モデルはこの環境に合いません。というのも、大きなパブリック UDP ポートレンジに依存するため、ポートの公開、セキュリティ確保、ポッドが追加・削除・再スケジュールされる状況での保持が難しいからです。

ポート枯渇

最初の問題は、セッションごとに 1 ポートを割り当てるモデルそのものです。高い同時接続数では、とても大きな UDP ポートレンジを公開・管理することになります。クラウドのロードバランサや Kubernetes のサービスは、一サービスあたり数万のパブリック UDP ポートを前提とした設計になっていません。各ポートレンジを追加するたびに、ロードバランサ設定、ヘルスチェック、ファイアウォールポリシー、ロールアウトの安全性などの運用上の複雑さが増します。

大規模な UDP ポートレンジは外部から到達可能な表面積を拡大するためセキュリティ上も扱いにくく、ネットワークポリシーの監査を困難にします。またオートスケーリングとの相性も悪いです。Kubernetes ではポッドが常に追加・削除・再スケジュールされます。各ポッドが大きな安定したポートレンジを予約して広告することを要求すると、その弾力性が脆弱になります。

このため、多くの WebRTC システムはサーバあたり単一 UDP ポートへ移行し、そのポートの背後でアプリケーションレベルのデマルチプレクスを行うようになります。

ステートのスティッキー性（所有権の固定）

サーバあたり単一ポート設計はポート数問題を解決しますが、フリート全体で各セッションの所有権を保持するという別の問題を生みます。ICE と DTLS はステートフルなプロトコルです。セッションを作成したプロセスは、そのセッションのパケットを受け続ける必要があります。そうでないと接続チェックの検証、DTLS ハンドシェイクの完了、SRTP の復号、ICE 再起動のような後続のセッション変更の処理に失敗する可能性があります。もし同一セッションのパケットが別のプロセスに到達すると、セットアップ失敗やメディアの破綻が発生します。

そこで明確な目標ができました: 公開する UDP 面を小さく固定しつつ、各パケットを対応する WebRTC セッションを所有するトランシーバへ確実にルーティングすること。

WebRTC メディアアーキテクチャの比較

我々は複数のアプローチを評価しました。たとえば TURN（Traversal Using Relays around NAT）では、エッジリレーがクライアントの割当てを終端し、その代行でトラフィックを転送します。以下は各アプローチの長所と短所の概観です:

ユニーク IP:port per session（ネイティブな直接 UDP）
- 長所: クライアント→サーバの直接メディアパス
- 短所: セッションごとに一つのパブリック UDP ポートが必要。大規模ポートレンジは公開・セキュア化が困難で、Kubernetes やクラウドロードバランサには不向き
ユニーク IP:port per server（サーバごとに1つの共有ソケット）
- 長所: セッションごとに公開するポート数を大幅に削減。1つの共有ソケットで多くのセッションをデマルチプレクス可能
- 短所: 単一ホスト上ではクリーンだが、共有のロードバランスされたフリート全体で初回パケットが間違ったインスタンスへ到達する問題は残る。したがって各セッションを所有するプロセスへ決定論的に誘導する手段が必要
TURN リレー（プロトコル終端型）
- 長所: クライアントは TURN リレーのアドレスとポートに到達すれば良い。エッジでポリシーを集中できる
- 短所: TURN 割当てはセットアップでラウンドトリップを追加する。TURN サーバ間で割当てを移動・復旧するのは依然として困難
ステートレスフォワーダ + ステートフルトランシーバ（OpenAI の relay + transceiver）
- 長所: 小さいパブリック UDP フットプリント。トランシーバがフル WebRTC セッション状態を引き続き所有
- 短所: メディアが所有するトランシーバに到達する前に 1 つの転送ホップを追加する。relay と transceiver 間でのカスタムな協調が必要

アーキテクチャ概要: relay + transceiver

我々が導入したアーキテクチャは、パケットルーティングとプロトコル終端を分離します。シグナリングは依然としてセッションセットアップのためにトランシーバへ届きますが、メディアはまず relay を経由して入ってきます。

Relay: 軽量な UDP フォワーディング層で、パブリック面は小さく保たれる。メディアを復号したり ICE 状態機械を実行したり、コーデック交渉に参加したりはしない。パケットメタデータを読み、宛先を選んで転送するだけ。
Transceiver: その背後にあるステートフルな WebRTC エンドポイント。トランシーバは通常の WebRTC フローを受け取り、すべてのプロトコル状態を所有する。

クライアント視点では WebRTC セッションに変化はありません。シグナリングとメディアのやり取りは、従来通りの WebRTC セッションとして振る舞います。

ICE 資格情報によるルーティング

ファーストパケットルーティング（初回パケットの誘導）がこのセットアップの鍵です。リレーは、セッション自体がパケットパス上に存在する前にクライアントからの初回パケットをその場でルーティングする必要があります。外部の検索サービスで一旦停止して調べるのでは間に合いません。

すべての WebRTC セッションは既にプロトコルネイティブなルーティングフックを持っています: ICE のユーザーネームフラグメント、つまり ufrag です。ufrag はセッションセットアップ時に交換され、STUN の接続チェック内でエコーされる短い識別子です。我々はサーバ側の ufrag を生成し、それがリレーに宛先クラスタと所有トランシーバを推測させるのに十分なルーティングメタデータを含むようにしています。

シグナリング中、トランシーバはセッション状態を割り当て、SDP アンサー内で共有された relay VIP と UDP ポートを返します。VIP はリレーフリートのフロントを務める仮想 IP アドレスで、ポートと組み合わせることでクライアントには 203.0.113.10:3478 のような単一の安定した送信先を与えます（多くの relay インスタンスがその背後に存在します）。
クライアントの最初のメディアパスパケットは通常、ICE が広告されたアドレスにパケットが到達できるか検証するための STUN binding request です。relay はその最初の STUN パケットのうち ufrag を読むのに十分な部分だけを解析し、ルーティングヒントをデコードしてセッションを所有する transceiver にパケットを転送します。
各トランシーバは共有 UDP ソケット上でリスンします。つまり、内部 IP:port にバインドされた一つの OS レベルのエンドポイントであって、セッションごとにソケットを持つわけではありません。リレーがクライアントの source IP:port からそのトランシーバ宛へのセッションを作成すると、以後クライアントからの後続パケットは所有するトランシーバへ直接転送され、トランシーバは通常の WebRTC フローとしてそれらを処理します。

（注: ここまでが本稿で扱う主要な概念と設計の概要です。実運用での実装細部、フォールトトレランス、ルーティングの最適化、観測性とスケーリング戦略については、続編や技術レポートで詳述します。）

How OpenAI delivers low-latency voice AI at scale

要約

Summary

Key Points

翻訳