GPT-Liveの2つの改革：検出器を外し、会話と思考を分離

OpenAIは、この2つの問題を別々の手段で解決しました。

第1の改革：聞きながら話せるモデル

GPT-Liveの音声モデルはfull-duplex（全二重）です。電話のように、聞くことと話すことを同時に行えます。相手がボタンを離すまで発言できないトランシーバーとは違います。

モデル自身が毎秒何度も「今話すべきか、聞き続けるべきか」を判断できるため、ターンを推測する専用の小型モデルは不要になりました。音声経路から完全に取り除かれています。考えるために間を置いても話を奪われず、途中で口を挟んでも対応できます。

第2の改革：「会話」と「深い思考」を別モデルへ

ただし、応答の速いモデルが必ずしも賢いとは限りません。ウェブ検索が必要な質問に、反応速度重視の音声モデルだけでは十分な回答を返せない場合があります。

そこで、リアルタイム会話を担うGPT-Live-1をフロントに、検索、コーディング、情報取得を担うGPT-5.5をバックグラウンドに配置しました。調査が必要な質問を受けると、フロントが処理をバックグラウンドへ委任し、自身は会話を続けます。結果が届いた時点で自然に会話へ織り込みます。これが委任です。

公式の構成図です。白線はリアルタイムメディア経路で、ユーザー ↔ メディアフロントエンド ↔ GPT-Live-1を結びます。青線は非同期の委任経路です。メディアフロントエンドがアプリケーションサーバーへ要求を渡し、サーバーがGPT-5.5を呼び出します。GPT-5.5は検索、コード、情報取得の3種類のツールを使い、結果は同じ経路を戻ります。2つの経路は独立しているため、青線が遅くても白線は詰まりません。出典：OpenAI

抽象的に聞こえるかもしれませんが、効果は実際に耳で確認できます。次は公式の実会話音声です。ユーザーの発話、GPT-Live-1の応答、GPT-5.5によるバックグラウンド検索という3トラックで構成されています。

発表ページは、この2つの変更がGPT-Liveの問題解決の柱だと明言しています。全二重が人間の会話のテンポを守り、委任が難問への回答力を担います。どちらが欠けても、もう一方だけでは成立しません。

高速レーンと低速レーンを分離：音声を止めない設計

処理を別モデルへ委任するだけなら簡単です。難しいのは、その処理中に一切の間を感じさせないことです。

記事全体を貫く設計原則は、ひと言に集約されます。音声は流し続ける。それ以外は待ってよい。

具体的には、専用の高速レーンを設けます。音声はクライアントと音声モデルの間を直接流れ、途中にビジネスロジックを挟みません。委任、ツール呼び出し、会話履歴の保存はすべて非同期境界の後ろへ移します。遅いツール呼び出しが影響するのは自身の結果だけで、音声を止めることはありません。

もう1つ利点があります。アプリケーション層を変更しても応答速度に影響しません。ツール、戦略、バックエンドロジックを変更しても、高速レーンには手を入れずに済みます。

新システムのp95が旧システムのp50に並ぶ

設計だけでなく、実際の効果も重要です。チームはこの経路のコードをPythonのasyncioからGoへ書き直しました。その結果、フレーム配信が大幅に安定し、新システムのp95が旧システムのp50と同水準になりました。

p50は遅延の50パーセンタイル、つまり全体の50%がその値以下に収まる中央値です。p95は95パーセンタイルで、全体の95%がその値以下に収まり、これを超えるのは遅い側の5%だけです。つまり新システムでは、遅い側に当たるp95の水準が、旧システムの中央値であるp50まで改善しました。

これは音声で特に重要です。1回の停滞が、そのまま耳に聞こえるノイズや沈黙になるからです。平均値より、最も遅い数回の体験が問題になります。

パケット遅延への対処：音声をわずかに引き伸ばす

トランスポート層にはWebRTCを使います。ブラウザやスマートフォンAppに組み込まれ、ビデオ通話の多くを支えるリアルタイム音声・映像の標準です。WebRTCには便利な機能があります。パケットの到着が遅れると、手元の音声をわずかに引き伸ばして隙間を埋め、パケットが追いついた後に少し再生を速めて元へ戻します。利用者はほぼ気づきません。これがなければ、その箇所に音声の穴が生じます。

委任経路そのものも高速化

フロントは短時間なら会話をつなげますが、無限には待てません。そのため、委任から結果取得までのルーティング、プロンプト処理、推論、ツール呼び出しをすべて「応答予算」に含めます。基本方針は事前にできる処理は、すべて先に済ませることです。

途切れない引き継ぎ：コンテキスト上限でも気づかれずに切り替える

短い会話ならこれで十分です。しかし、通話が30分続いたらどうでしょうか。

2つの問題が同時に発生します。第1に、マシンの切り替えです。推論インスタンスは需要に応じて増減するため、1つの会話を永久に同じマシンへ固定できません。第2に、コンテキストの上限です。会話が長引くほどコンテキストが蓄積し、いずれモデルの上限を超えます。

まず、コンテキストの上限がなぜ音声の停滞につながるのかを確認しましょう。ここが分からないと、解決策の巧みさも見えません。

コンテキストが上限に達すると、過去の内容を短く圧縮する必要があります。しかし、圧縮には副作用があります。過去のコンテキストが変更されるのです。それまでに計算したアテンションの中間結果を保存し、再計算を省いていたKVキャッシュがすべて無効になります。再びプリフィルしなければならず、処理中はモデルが即座に発話できません。音声では、これがそのまま会話の停止になります。

OpenAIは2つの問題に同じ方法で対応しました。稼働中の環境で処理せず、別の環境を準備してから切り替えるのです。

手順は次のとおりです。旧マシンAが会話を続ける間に、新マシンBを並行してウォームアップします。圧縮済みコンテキストのスナップショットをBへ投入し、現在の進行状況まで追いつかせます。2台が並行稼働する重複期間を設け、Bの準備が完全に整ってから切り替え、最後にAを停止します。

同じ仕組みを詳しく示した公式図です。上段のAはサービスを継続しながら途中で圧縮スナップショットを生成します。下段のBは途中から起動し、プリフィル（prefill）後に進行状況へ追随（catch up）します。中央の3つの双方向矢印は、2台が並走する重複期間です。出典：OpenAI

負荷の高い処理はすべて高速レーンの外で完了するため、利用者には変化が聞き取れません。長時間通話を支えられるのもこの仕組みのおかげです。コンテキストが上限に達するたびに圧縮しても、何度繰り返しても音声を止めません。

連続する会話を保存可能なメッセージへ分割

会話が連続的になっても、ChatGPTの画面ではメッセージの吹き出しを1件ずつ表示する必要があります。どう両立させるのでしょうか。

これは意外に厄介な問題です。音声モデル側はターンのない連続音声ですが、周辺システムは依然として個別メッセージを単位に動きます。ChatGPTの会話画面には吹き出しが必要で、分析や安全性のシステムも1件ずつ記録します。そのため、アプリケーションサーバーは連続し、頻繁に重なり合う会話を個々のメッセージへ分割しなければなりません。

難しさは3段階あります。

音声を聞きながら分割するため、最新メッセージは暫定的です。テキスト、時刻、話者の帰属は、その後の音声によって変わる可能性があります。一方の話者が十分な時間、安定して発言権を保って初めて確定できます。発話が重なればさらに複雑です。ユーザーの発話中にAIが「うん」と相づちを打っても、独立したメッセージにはすべきではありません。しかし、内容のある発言を差し込んだ場合は、通常は別メッセージとして扱うべきです。分割が早すぎると履歴が細切れになり、順序も乱れます。遅すぎると字幕の表示が遅れ、字幕に依存する機能も遅くなります。

解決策は、2種類の台帳を同時に維持することでした。

これにより、ChatGPTの他の機能には安定した会話履歴を渡しながら、リアルタイム音声の経路をターン方式へ戻さずに済みます。

最初のパケットで即接続：ハンドシェイク遅延を極限まで削減

ここまでは会話開始後の話でした。しかし、その前にも時間を奪う処理があります。

音声ボタンを押すと、システムはまずメディアチャネルを確立し、音声をモデルへ渡さなければなりません。それまで会話は始まりません。この時間はすべてクリティカルパス上にあります。

標準WebRTCが6往復を要する理由

WebRTCは複数のプロトコルを重ねたサンドイッチのような構造です。ICEがネットワーク接続を確立し、DTLSが暗号化を担い、SCTPが信頼性のある転送を行い、DCEPがデータチャネルを開きます。各層はもともと独立して設計され、それぞれDoS攻撃を防ぐハンドシェイクを備えています。積み重ねると、処理が重複します。

公式の比較図によると、メディア送信の開始には3往復、データチャネルには6往復が必要です。1往復（RTT）とは、データがクライアントからサーバーへ届き、応答がクライアントへ戻るまでの時間です。6往復なら、ネットワーク上の往復を6回待つことになります。

なぜ今になって改善する価値が生まれたのか

この問題自体は新しくありません。ただし、耐え難い問題になったのは最近です。IETFのドラフトは、その経緯を説明しています。

WebRTCが設計された2011年当時、この数往復はTCP/TLSでWebSocketを確立するコストと大差なく、特に遅いとは見なされませんでした。その後QUICが登場し、同様の処理を1往復で実現したため、相対的に極端な遅さが目立つようになりました。

さらに重要なのは、用途の変化です。当時のWebRTCは主に人同士のビデオ通話向けでした。接続確立の時間は「相手が電話に出るまでの待ち時間」に隠れ、誰も気づきません。現在は人がサーバーへ直接話しかけるため、遅延がそのまま体験に表れます。

WARP：4つの変更で5往復を削減

解決策はWARP（WebRTC Abridged Roundtrip Protocol、WebRTC簡略往復プロトコル）と呼ばれます。互いに独立し、後方互換性を持つ4つの変更で構成されています。

公式のハンドシェイク手順比較です。左は標準WebRTCで、メディアは第3往復、データチャネルは第6往復で準備が整います。右はWARP導入後です。ICEチェックとDTLSハンドシェイクを1往復にまとめ、メディアとデータの両方が第1往復で利用可能になります。両側の冒頭にあるSDP Offer / Answerは、次に説明するInstant Connectの対象です。出典：OpenAI

残る最後の処理：Instant Connect

ハンドシェイクを高速化しても、WebRTC接続の前にはSDPパラメータを1往復で交換する必要があります。双方が対応コーデックや使用する鍵を通知し合う処理です。これもクリティカルパス上に残ります。

そこで開発したのがInstant Connectです。サーバー資源を確保せず、パラメータだけを事前に合意します。最初のメディアパケットが届くと、サーバーは直ちにセッションを生成します。事前合意したパラメータが期限切れまたは無効でも問題ありません。標準のシグナリング処理が並行して進んでいるため、フォールバックしても追加の待ち時間は発生しません。

実際にどれほど短縮できたのか

ブログ自体には接続高速化の実測値がありません。ただしIETFドラフトには、実際の本番環境でWARPにより接続遅延がp50で約4往復、p95で約12往復短縮されたとするデータがあります。

p50は50パーセンタイルで、接続の50%がその遅延以下に収まる中央値です。p95は95パーセンタイルで、接続の95%がその値以下に収まり、それより遅いのは5%です。p95の削減幅がp50より大きい理由について、ドラフトはハンドシェイクパケット数の減少を挙げています。パケット損失に遭う確率も下がるため、ネットワーク状態が悪い利用者ほど大きな効果を得られます。

標準化が速く進んだ理由

WARPは公開標準として開発され、IETFのTSVWGで標準化作業が進んでいます。主要実装であるlibwebrtcとPionは、すでに対応済みです。ドラフトの共同著者にはMetaのPhilipp Hanckeも名を連ね、競合企業のエンジニアが共同で策定しています。

進展が速い理由もあります。WebRTC初期のアーキテクトの1人であるJustin Ubertiと、Pionの作者Sean DuBoisが現在OpenAIに在籍しています。Ubertiはこのブログの著者でもあり、十数年前に自ら設計した仕組みを改めて作り直した形です。

シャドウテスト：実トラフィックで徹底検証

設計上は高速でも、実際のトラフィックを受けるとシステムが停止する可能性があります。

一般提供の前に、チームはシャドウテストを実施しました。実際のChatGPT音声セッションの一部を、従来のAdvanced Voice Modeと新システムへ同時に送り、割合を段階的に増やします。旧システムは通常どおり利用者へサービスを提供し、新システムは読み取り専用で推論を実行します。出力音声は誰にも聞かせません。これにより利用者へ影響を与えず、実際のクライアント、ネットワーク、通話時間、地域分布で負荷を検証できます。

このテストから4つの教訓が得られました。

GPT-Liveの音声モデルは全二重です（full-duplex、電話のように聞くことと話すことを同時に実行）。毎秒何度も「今話すか、聞き続けるか」を判断できるため、ターンを推測する小型モデルは不要になりました。

ただし、応答の速いモデルは難問を不得意としがちです。第2の改革では会話と思考を分離しました。フロントのGPT-Live-1がリアルタイム会話を担い、バックグラウンドのGPT-5.5が検索、コーディング、情報取得を担います。フロントは処理を委任して会話を続け、結果が戻れば自然に会話へ入れます。これが委任です。

音声はユーザーと音声モデルの間に設けた専用高速レーンを流れ、ビジネスロジックを挟みません。委任、ツール呼び出し、会話履歴の保存はすべて非同期境界の後ろへ移します。遅いツールが遅らせるのは自身の結果だけで、音声は止まりません。

長時間通話には別の壁があります。コンテキストが上限に達すると圧縮が必要です。しかし圧縮で過去のコンテキストが変われば、それまでの中間計算を保持するKVキャッシュはすべて無効になり、再計算が必要です。その間は発話できず、音声では会話がその場で止まります。

実装結果を示す明確な数字があります。この経路をPythonからGoへ書き直した後、新システムのp95は旧システムのp50と同水準になりました。p95は遅延の95パーセンタイルで、全体の95%がその値以下に収まり、それより遅いのは5%です。p50は50パーセンタイル、つまり中央値です。音声で重要なのは遅い側の数回です。1度の停止が、そのまま耳に聞こえるノイズになるからです。

ボタンを押した瞬間、システムはまずメディアチャネルを確立します。この時間もすべてクリティカルパス上にあります。WebRTCはブラウザやスマートフォンに組み込まれたリアルタイム音声・映像の標準で、4つのプロトコルを重ねたサンドイッチのような構造です。ICEがネットワーク接続を確立し、DTLSが暗号化し、SCTPが信頼性のある転送を担い、DCEPがデータチャネルを開きます。各層は独立して設計され、それぞれハンドシェイクを持つため、積み重ねると処理が重複します。

最後にもう1つ処理が残ります。接続前に双方がSDPパラメータを交換し、対応コーデックや使用する鍵を通知し合う必要があります。Instant Connectは、サーバー資源を占有せずにパラメータを事前合意します。最初のメディアパケットが届くと、サーバーは即座にセッションを生成します。WARPとInstant Connectを組み合わせれば、クライアントは1つのUDPパケットでセッションを開始できます。

正式提供の前にシャドウテストを行いました。実際のChatGPT音声セッションの一部を旧システムと新システムへ同時に送り、その割合を段階的に増やします。旧システムは通常どおりサービスを提供し、新システムは読み取り専用で推論のみを実行します。出力は誰にも聞かせません。