OpenAI の新音声システム「GPT-Live」、ターン検出なしで会話が止まらなくなったよ！

おつかれさま、しぃちゃんだよ！今日は OpenAI から届いた、ChatGPT Voice の中身をまるっと作り直したっていうエンジニアリングの話を紹介するよ。地味に聞こえるかもしれないけど、中身はかなり熱いから最後まで読んでみてね！

OpenAI News openai.com

なにが発表されたの？

OpenAI の News で、ChatGPT Voice を支える第 3 世代の音声システム「GPT-Live」の裏側が明かされたよ。GPT-Live はこれまでの音声 AI にあった「ターン検出器」を音声パスから取り除いた新しいアーキテクチャなんだって。

音声モデル自体がフルデュプレックス、つまり「聞きながら話す」ことができるようになっていて、より深い推論やツール利用が必要なときは GPT-5.5 のようなフロンティアモデルに、会話の流れを止めずに相談できるみたい。この土台の上で、ChatGPT デスクトップアプリで新しく始まった「パソコンを操作したり、エージェントを調整したりする」機能も動いているんだって。

今までどうだったの？

これまでの音声 AI は、テキスト LLM の「ターンベース」な仕組みをそのまま引き継いでいたの。各ターンがテキストじゃなくて音声のかたまり(オーディオブロブ)として扱われていただけで、仕組み自体はターン制のままだったんだって。

• カスケード方式: 音声認識(STT)→ LLM → 音声合成(TTS)を順番に実行。処理が直列だから、その分レイテンシが積み重なるし、声のトーンや間合いといった情報も失われがち
• 音声から音声へ直接変換するモデル: 文字起こしを挟まないぶん改善はしたけど、それでも「いつ推論を始めるか」の判断はターン検出器に頼ったままで、会話の主導権はやっぱりターン制だった

つまり、モデルがどれだけ賢くなっても、「相手の発言が終わったかどうか」を判定する小さなモデルの精度が会話のテンポを決めてしまっていたの。早すぎれば発言をかぶせて遮ってしまうし、遅すぎれば返事がもたついて聞こえちゃう、という悩ましい板挟みだったんだって。

これで何が変わるの？

GPT-Live では音声モデル自身が会話の主導権を持つようになって、音声はモデルの中を流れ続けながら、深い推論やツール実行は非同期で裏側に回るようになったの。システムの最優先事項は「途切れないメディアループを保つこと」で、フロンティアモデルの呼び出しや会話の永続化といった重い処理はライブパスの外側で行われるんだって。

これによって、会話の相槌やタイミングがより人間らしくなるだけじゃなく、ChatGPT Voice が「会話するだけ」の存在から「パソコン操作やエージェントの調整までこなす」存在へと広がる土台にもなったみたい。将来的には、この基盤の上に「GPT-Live API」も提供される予定なんだって。

深く潜ってみよう

ここからは技術寄りの話。OpenAI が半年かけて手を入れたポイントをいくつか紹介するね。

メディアフロントエンドを Go で書き直した

これまで Python の asyncio で書かれていたメディアフロントエンドと推論ロジックを、Go 言語で書き直したんだって。その結果、新システムの p95 レイテンシが、旧システムの p50 レイテンシと同じ水準になったと明記されているよ。中央値だった速さを、遅い方から数えて 95 % の地点でも出せるようになったってことだから、かなり大きな改善だね。

モデルインスタンスのシームレスな引き継ぎ

長時間の音声セッションだと、コンテキストがどんどん膨らんでいくし、モデルインスタンスも需要に応じて起動・終了を繰り返すの。そこで OpenAI は、新しいモデルインスタンスを既存のものと並行して立ち上げ、現在のセッションコンテキストを事前に読み込ませたうえで両方に推論をかけて、新しいインスタンスの準備が整った瞬間に切り替える、という引き継ぎの仕組みを作ったんだって。同じ仕組みはコンテキストの圧縮にも使われていて、上限に近づいても音声を途切れさせずに裏側で圧縮・差し替えができるようになっているよ。

GPT-5.5 への委任を会話の速度で行う

GPT-Live が深い推論やツール利用を GPT-5.5 のようなフロンティアモデルに任せるとき、レイテンシを抑えるためにいくつも工夫がされているの。

• 音声セッションの開始と同時に、フロンティアモデル側の推論セッションも作成し、初期コンテキストを事前に読み込ませておく
• そのセッションを会話が続く間ずっと保持し、同じセッションに安定して割り当て続ける(セッションアフィニティ)
• プロンプトキャッシュも併用してレイテンシをさらに縮める
• 推論の強度・出力上限・ツールのスキーマ・モデルとツールの往復回数といったパラメータも調整して、応答速度を稼ぐ

連続した音声から発言のまとまりを作る

音声モデル自体は連続したストリームとして会話を扱うけど、ChatGPT の会話 UI や分析・安全性まわりの仕組みは「ユーザーの発言」「アシスタントの発言」という単位を必要とするの。そこでアプリケーションサーバーが、部分的な文字起こしとタイミング情報から発言者を推定して、まだ確定していない速報版の会話ビューと、後から書き換わらない確定版の記録の 2 つを同時に持つようにしているんだって。UI 側は更新され続ける速報版を、分析ログには確定版を使う、という使い分けだよ。

WARP と Instant Connect でセッション開始を高速化

WebRTC は低遅延メディアには強い一方、素の状態だとハンドシェイクの回数が多くて接続開始までに時間がかかることがあるの。OpenAI は WebRTC コミュニティと協力して「WARP」というオープンな仕様を作り、IETF の TSVWG ワーキンググループで標準化を進めていて、すでに libwebrtc と Pion にサポートが追加されているよ。

さらに、接続前の SDP パラメータのやり取りを事前に済ませておく「Instant Connect」も開発したんだって。WARP と Instant Connect を組み合わせることで、クライアントはたった 1 つの UDP パケットでセッションを開始できるようになったみたい。

本番トラフィックでのサイレントテスト

GPT-Live をユーザーに公開する前に、実際の ChatGPT Voice セッションの一部を少しずつ新システムにも(読み取り専用の推論モードで)流す「サイレントテスト」を実施したんだって。ここでわかった教訓として、こんな点が挙げられているよ。

• 処理能力は GPU のスループットだけでは決まらない。CPU 側のストリームハンドラやキュー、ネットワーク経路も一緒にスケールさせる必要があった
• 遠く離れた拠点にセッションをルーティングすると起動時や配信中に遅延が乗ってしまうため、地理的な要因も重要な検討事項になった
• 長時間セッションではメモリと永続化の負荷が、再接続では圧縮と状態復元が、通常の切断ではシャットダウン処理の競合状態が、それぞれ短時間の負荷テストでは見えなかった問題として浮かび上がった

これを受けて、より細かいテレメトリの追加や、既知の正常な設定との突き合わせ、段階的なロールアウト、問題のある経路だけを素早く切り離す仕組みなども整備したんだって。

まとめ

• OpenAI が ChatGPT Voice を支える第 3 世代音声システム「GPT-Live」の中身を公開
• ターン検出器を音声パスから排除し、フルデュプレックスで「聞きながら話す」ことが可能に
• 深い推論やツール利用は GPT-5.5 などのフロンティアモデルに非同期で委任
• メディアフロントエンドを Go で書き直し、p95 レイテンシが旧システムの p50 相当まで改善
• WARP と Instant Connect の組み合わせで、セッション開始をたった 1 つの UDP パケットまで短縮
• 今後は「GPT-Live API」としても提供予定

音声インターフェースを作っているエンジニアや、レイテンシ最適化・リアルタイム通信のアーキテクチャに興味がある人には、じっくり読みたくなる一本だと思うよ。