はじめに
OpenAIは2026年8月3日、公式ブログで音声AI「GPT-Live」の内部構造を解説する記事を公開しました。ターン検出を排した全二重会話の仕組みと、応答速度を支える通信・推論基盤の設計について、本稿で紹介します。
参考記事
- タイトル: How we built a realtime system for responsive voice AI in six months
- 著者: Justin Uberti、Zahan Malkani
- 発行元: OpenAI
- 発行日: 2026年8月3日
- URL: https://openai.com/index/continuous-voice-interaction-with-gpt-live/
関連記事
要点
- GPT-LiveはOpenAIの第3世代音声システムであり、全二重(フルデュプレックス)モデルの採用によって会話のターン検出処理を廃止している
- 音声処理を担う「ライブパス」と、GPT-5.5などフロンティアモデルへの処理委任を担う経路を非同期RPCで分離する設計である
- メディアフロントエンドと推論ロジックをPythonからGo言語に書き換え、フレーム配信のp95レイテンシが従来システムのp50相当まで改善した
- WebRTCの起動を6往復から1往復に短縮する新プロトコル「WARP」と、SDP交換を事前に済ませる「Instant Connect」を独自開発した
- 本番のChatGPT Voiceトラフィックの一部を用いたサイレントテストにより、GPU性能だけでなくCPU側の処理能力やネットワーク経路もボトルネックになりうることが判明した
詳細解説
ターン交代からストリーミングへ
従来の音声AIは、テキストLLMのターンベースの性質を引き継ぎ、各ターンをテキストではなく音声のまとまりとして扱っていました。音声認識・LLM・音声合成を順に処理する「カスケード方式」ではこの直列処理が遅延を生み、話者の抑揚や間の取り方といった手がかりも活用できなかったと元記事は説明しています。Speech-to-Speechモデルの登場で音声を直接処理できるようになったものの、発話の切れ目を判定する「ターン検出器」が動くまで推論を開始できない仕組みは残っていたとのことです。
GPT-Liveはこの前提を転換し、音声モデル自体が会話の主導権を持ちます。音声が途切れなく流れ続けることを最優先事項とし、フロンティアモデルの呼び出しや会話履歴の保存といった処理はライブパスの外側で非同期に行われる設計です。OpenAIは2026年5月にもRealtime API系の音声モデルを刷新しており、今回のGPT-Liveはその技術的な蓄積の延長線上にある取り組みと考えられます。
会話を止めないステートフル推論
OpenAIによれば、GPT-Liveのメディアフロントエンドと推論ロジックは、従来のPython asyncio実装からGo言語に書き換えられました。これによりフレーム配信の安定性が大きく改善し、新システムのp95(全体の95%が収まる遅延)が旧システムのp50(中央値)に匹敵する水準になったとされています。音声の伝送にはWebRTC(ブラウザ間などでリアルタイム通信を行うための技術規格)が採用され、パケットの到着が遅れた際には音声をわずかに伸縮させて途切れを防ぎ、遅延が解消されれば再生速度を上げて追いつく仕組みも備えています。
長時間の音声セッションでは、会話の文脈(コンテキスト)が蓄積してモデルの処理上限を超えることがあります。要約による圧縮(コンパクション)を行うと、それまでの処理結果を保持するKVキャッシュ(注意機構が過去のトークンについて計算した情報を保存する仕組み)が無効化され、再構築に時間がかかる課題がありました。GPT-Liveでは、新しいモデルインスタンスを立ち上げて現在の文脈を事前に読み込ませ、既存のインスタンスと並行して推論を走らせたうえで切り替える「ハンドオフ」の仕組みによって、会話を途切れさせずにモデルの入れ替えやコンテキスト圧縮を行えるようにしたと説明されています。長時間の音声対話を安定して提供したい開発者にとって、参考になる設計だと思います。
深い思考を裏側で任せる非同期デリゲーション
GPT-Liveは、より深い推論やツール利用が必要な場面で、GPT-5.5のようなフロンティアモデルに処理を委任(デリゲーション)します。会話を継続しながら結果を返す必要があるため、OpenAIはルーティングからプロンプト処理、推論、ツール呼び出しまでの全経路を「応答性の予算」として扱い、遅延の削減に取り組んだとしています。具体的には、音声セッション開始時にフロンティアモデル用の推論セッションをあらかじめ作成し、初期の会話文脈を事前に読み込ませておくことで、実際に委任が発生した時点ではすでに処理済みの状態から応答できるようにしています。
また、音声モデルは連続的な音声ストリームを扱う一方で、ChatGPTの会話UIや分析・安全性の仕組みは「ユーザーの発言」「AIの発言」という離散的なターン単位で動いています。そのため、アプリケーションサーバーが部分的な文字起こしとタイミング情報から発話者を推定し、暫定的な「速報版」の会話履歴と、確定後の「正式な記録」を並行して管理しているとのことです。相手の発言中の短い相槌は独立したメッセージにせず、実質的な発言だけを確定させるなど、確定のタイミングにも工夫があるようです。
起動を高速化する新プロトコル
音声AIの応答性は、ユーザーがボタンを押した瞬間から問われます。OpenAIは通常のWebRTC接続確立に必要な複数回の往復を分析し、独自プロトコル「WARP(WebRTC Abridged Roundtrip Protocol)」を開発しました。DTLSハンドシェイクをICEに便乗させる、より高速なDTLS 1.3を使う、SCTPハンドシェイクを事前に済ませるなどの改善を組み合わせ、メディアとデータの起動に必要な往復回数を6回から1回に減らしたとしています。WARPはIETFのTSVWGワーキンググループを通じて標準化が進められており、libwebrtcやPionといった主要なWebRTC実装にもすでに対応が加わっているそうです。
さらに、WebRTC接続前に必要なSDP(通信条件を記述するパラメータ)の交換をあらかじめ済ませておく「Instant Connect」も開発されました。事前に用意したパラメータが有効であれば最初の音声パケット到着時にセッションを確立でき、無効な場合は通常のシグナリングにフォールバックするため遅延が増えることもないとされています。これらの改善により、クライアントは1つのUDPパケットだけでセッションを開始できるようになったと元記事は述べています。
本番環境でのテストから得られた教訓
GPT-Liveを実際のユーザーに提供する前に、OpenAIは既存の「Advanced Voice Mode」に加えて、本番のChatGPT Voiceトラフィックの一部を新システムにも流す「サイレントテスト」を実施しました。新システムは読み取り専用モードで推論を行い、ユーザーが聞く内容には影響を与えない形で実環境の負荷を検証したとのことです。
このテストを通じて、処理容量の制約はGPU性能だけでは測れず、CPU側のストリーム処理やキュー、ネットワーク経路も同様にスケールさせる必要があることが分かったと報告されています。また、利用者との物理的な距離がレイテンシに影響するため、モデルのロールアウトを地域ごとの容量計画と合わせて検証する必要があったとも述べられています。長時間セッションやネットワーク再接続、通常の切断など、実際の利用パターンを踏まえたテストでなければ見つからない不具合も多かったようです。こうした知見は、リアルタイム性が求められるシステムを検証する際に広く参考になる内容だと考えられます。
まとめ
OpenAIは全二重音声モデルと非同期デリゲーション、WARP・Instant Connectによる通信高速化を組み合わせ、GPT-Liveを6か月で構築しました。今後はChatGPT Voiceのエージェント連携やGPT-Live APIにも広がる見通しです。前身のgpt-realtimeについては過去記事でも整理していますので、ご覧ください。
