OpenAIが8月3日、ChatGPT Voiceを動かしている音声システム「GPT-Live」をどう作ったかを解説する技術記事を公開しました。会話の切れ目を推測するターン検出器を音声の経路から取り除き、接続開始時のネットワーク往復を6回から1回まで縮めるなど、6カ月かけて作り直した設計の中身が明かされています。モデルの発表そのものではなく、それを実サービスとして毎日動かすための土台の話です。

「いつ話し始めるか」をモデル自身に決めさせる

従来の音声AIは、ユーザーが話し終えたかどうかをターン検出器（turn detector）と呼ばれる小さなモデルが判定し、その結論が出てから初めて大きなLLMが動き出す構成でした[1]。早く判定すれば発話を遮ってしまい、遅く判定すれば返答がもたつく。どちらに転んでも不自然になるという、なかなか報われない役回りです。

GPT-Liveは7月8日に発表された第3世代の音声モデルで、聞くことと話すことを同時にこなす全二重（フルデュプレクス）構成を採ります[2]。話す、聞き続ける、黙る、割り込む、ツールを呼ぶといった判断を、モデル自身が毎秒何度も下します[2]。ターン検出器という中間の審判が音声経路から消えたことで、会話のリズムを外部の推測に委ねずに済むようになった、というのが今回の記事の出発点です[1]。

音声の通り道と、それ以外を分ける

設計の早い段階で決めたのは、メディアの流れとアプリケーション側の処理を明確に分けることでした[1]。音声はクライアントと音声モデルを結ぶ専用の高速経路を通り、フロンティアモデルへの委任やツール実行といった作業は非同期のRPC境界の裏側で走ります。遅いツール呼び出しは自分の結果を遅らせるだけで、音声の流れそのものは止められません。

この分離は拡張のしやすさにも効いています。ツールやポリシー、バックエンドの挙動を変えても、音声を流し続ける役目のメディアフロントエンドには影響しません。リアルタイムで必ず起きなければならない仕事だけを、小さく予測可能な経路に閉じ込める設計です[1]。

実装面では、メディアフロントエンドと推論ロジックをPythonのasyncioからGoへ書き換えています。その結果、フレーム配信の滑らかさは新システムのp95が旧システムのp50に並ぶ水準まで改善したとしています[1]。伝送にはWebRTCを使い、パケット損失やクロックのずれ、接続の切り替わりをまたいでも動き続けます。パケットの到着が遅れたときは音声をわずかに引き延ばして隙間を埋め、その後少し早回しして実時間に追いつくという、WebRTCらしい振る舞いも活かされています[1]。

会話が長引いても、無停止でモデルを入れ替える

ステートフルな推論には運用上の悩みがついて回ります。音声セッションは長く開いたままなのにコンテキストは増え続け、モデルのインスタンスは需要に応じて起動と停止を繰り返します。

そこでOpenAIは、インスタンス間の引き継ぎ機構を用意しました。切り替えが必要になると、代わりのインスタンスを温めて現在のセッションコンテキストを流し込み、両方で並行して推論を走らせ、新しい側の準備が完全に整った時点で切り替えます[1]。

同じ仕組みは、コンテキストの動的な圧縮（compaction）にも使われます。会話が長くなってコンテキストが上限に近づくと圧縮が必要になりますが、圧縮は過去のコンテキストを書き換えるためKVキャッシュ（処理済みトークンのアテンションのキーと値を保持する領域）が無効になり、プリフィルのやり直しで遅延が生まれます。これを個別の処理ではなく引き継ぎの一種として扱い、元のインスタンスが会話を続けている裏で圧縮済みの新インスタンスを用意しておく。重い処理をライブ経路の外に追い出しているので、切り替えの最中も会話は途切れません[1]。

深く考える仕事は、裏でGPT-5.5に回す

GPT-Liveは、検索や踏み込んだ推論が必要になるとGPT-5.5のようなフロンティアモデルへ処理を委任します[1][2]。ここで問題になるのは、委任の結果が会話に間に合うかどうかです。音声モデルは相手をしばらく引き留めておけますが、いつまでも待たせることはできません。そのためルーティング、プロンプト処理、推論、ツール呼び出しまでを含めた委任の往復全体を、応答性の予算に組み込んで最適化したとしています[1]。

具体的には、音声セッションが始まった時点でフロンティアモデル側の推論セッションを先に作り、初期コンテキストを流し込んでおきます。最初の委任リクエストが来る前にプロンプトの処理を終わらせておく段取りです。以降は同じセッションを使い回し、セッションアフィニティとプロンプトキャッシュで待ち時間を削ります[1]。

もう一つ、地味ですが効いているのが、連続した音声を離散的なメッセージに切り分ける処理です。ChatGPTの会話UIや分析・安全性の基盤は、いまも発話の単位でものを見ています。そこでアプリケーションサーバーが、途中経過の文字起こしとタイミング信号から誰が話しているかを推定し、メッセージの列を組み立てます。最新のメッセージは暫定扱いで、話者や区切りは後から変わります。アシスタントの短い相づちは独立したメッセージにせず、実質的な割り込みは分ける、といった線引きも必要です[1]。

早く確定させれば履歴が細切れになり、待てば文字起こしが遅れる。この二律背反に対して、システムは会話について暫定の見え方と確定した記録の2つを保持し、更新に耐えるUIには暫定を、確定した文字起こしを求める分析パイプラインには後者を渡す形で折り合いをつけています[1]。

接続の往復を6回から1回へ、WARPとInstant Connect

応答性はボタンを押した瞬間から問われます。ところがWebRTCは低遅延メディア向けでありながら、セッションを始めるまでに驚くほど多くのハンドシェイクとネットワーク往復を必要とします。QUICのように往復回数の削減を重視した後発プロトコルより前の設計で、複数のプロトコルがそれぞれ独自のDoS対策を持つなど、重複した仕事が残っているためです[1]。

OpenAIはこのスタックを解析し、メディアとデータの起動を6往復から1往復に減らすWARP（WebRTC Abridged Roundtrip Protocol）を開発しました。DTLSハンドシェイクをICEに相乗りさせるSPED、より高速なDTLS 1.3、SCTPハンドシェイクの事前ネゴシエーションであるSNAP、そしてDCEPを使わないデータチャネルの事前ネゴシエーションという、いずれも後方互換な改良の組み合わせです[1]。

自社だけで囲い込まず、WebRTCコミュニティの協力者とともにオープンな仕様として公開し、IETFのTSVWGワーキンググループで標準化を進めている点は注目に値します。構成要素のSPEDはIETFのデータトラッカーに草案として登録されており、ICEとDTLSを並行して進められる後方互換な拡張として説明されています[3]。WARPへの対応はlibwebrtcとPionに取り込み済みで、他の実装でも作業が進んでいるとしています[1]。

これに加えて、接続前のSDPパラメータ交換をクリティカルパスから外す「Instant Connect」も用意されました。標準のシグナリングと並行して走り、事前に交換したパラメータが有効ならサーバーは最初のメディアパケットが届いた時点でセッションを実体化します。無効だった場合も通常のシグナリングが既に走っているため、追加の遅延なくフォールバックできます。WARPと組み合わせると、クライアントはUDPパケット1つでセッションを開始できるところまで到達しました[1]。

本番トラフィックを流す「サイレントテスト」で分かったこと

紙の上で速いシステムが、実際の音声トラフィックで詰まることはあります。そこでOpenAIは、ユーザーに届ける前に本番のChatGPT Voiceセッションの一部を新旧両方の系に流すサイレントテストを実施しました。既存のAdvanced Voice Modeはそのまま使われ続け、新システム側は読み取り専用で推論を走らせるだけなので、ユーザーが聞く音は変わりません[1]。

最初に得られた教訓は、容量をGPUの処理能力に還元できないということでした。音声セッションは開いたままフレームを送り続けるため、CPU側のストリーム処理やキュー、ネットワーク経路も一緒にスケールする必要があります。実際の負荷では、負荷試験の見積もりより早く周辺コンポーネントが飽和し、推論リクエストが滞留して遅延が積み上がりました。そこで問いを、GPU 1台が何リクエストを捌けるかから、全フレームを定刻通りに届けながら同時に何セッションを維持できるかへ置き換えたとしています[1]。

地理的な配置も一次的な関心事になりました。遠くの容量にセッションを振ると、起動時とストリーミング中の複数箇所で遅延が乗ります。長時間のセッションはメモリと永続化の圧力を、再接続は圧縮と状態復元を、ごく普通の切断はシャットダウン処理の競合を露呈させました。いずれも時間の経過と蓄積された状態に依存するため、短い負荷試験では表に出てこない種類の問題です[1]。

観測とロールアウトの仕掛けも作り直しています。異なる原因の遅延を混ぜてしまう指標や、不調なエンジンを平均値で覆い隠すダッシュボード、テスト環境と本番の設定のずれが見つかり、より細かいテレメトリ、既知の正常な構成との照合、段階的な流量増加、経路を素早く隔離・停止できる仕組みを追加したとしています[1]。

まとめ

GPT-Liveの技術記事が一貫して置いている原則は、音声を止めないという1点です。ストリーミング推論、専用のメディア経路、非同期の委任、伝送層の最適化は、すべてそのために積み上げられています。この基盤はChatGPT Voiceを支えるだけでなく、今後提供予定のGPT-Live APIの土台にもなるとされており、音声インターフェースを扱う開発者にとっては、WARPの標準化の行方も含めて追いかける価値のある内容です。

[1] 出典: https://openai.com/index/continuous-voice-interaction-with-gpt-live

[2] 出典: https://openai.com/index/introducing-gpt-live/

[3] 出典: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/