音声 AI にとって、いつ話すべきかを判断するのは、想像以上に難しい課題です。人はほんの一瞬で自然に話者を交代できますが、従来の音声 AI システムはこのリズムについていけませんでした。従来のターン制アーキテクチャは、ターン検出器と呼ばれる小型モデルに頼っていました。しかし、ターン検出器には非常に難しい判断が求められました。判断が早すぎればユーザーの発話を遮り、遅すぎれば応答が鈍く感じられます。検出器の判断が終わるまで、はるかに大規模な LLM は処理を開始できませんでした。
第 3 世代の音声システムである GPT‑Live は、音声経路からターン検出器を取り除きます。その音声モデルは全二重で、聞くことと話すことを同時に行えます。これにより、別個の検出器が不要となり、会話がより即時的で自然に感じられます。より深い推論やツール利用が必要な場合、GPT‑Live は会話の流れを中断せず、GPT‑5.5 などのフロンティアモデルに問い合わせることもできます。これらの機能により、GPT‑Live は会話の応答性と高度な推論能力を、かつてない水準で両立します。
この体験を大規模に提供するには、低遅延に最適化された新しいシステムアーキテクチャが必要でした。一般的なリクエスト・レスポンス型の推論とは異なり、私たちのシステムは入力音声を音声モデルへ、出力音声をユーザーへストリーミングしながら、別の非同期経路で委任を処理します。この 6 か月間で、音声をエンドツーエンドで滑らかに流し続けるため、モデル推論、コンテキスト管理、メディア転送を作り直しました。
このアーキテクチャは、音声の中核経路とアプリケーションロジックの間に明確な境界も設けます。これにより、応答性に影響を与えずに、アプリケーションの動作を容易にカスタマイズできます。この基盤は、ChatGPT デスクトップアプリで新たに提供を開始した、コンピューターの操作やエージェントの連携を行う機能など、拡大を続ける ChatGPT 音声モードの機能を支えています。
この記事では、従来のターン制システムが要件を満たせなかった理由と、あらゆる層で応答性を確保するために新システムをどう設計したかを説明します。ステートフル推論、動的なコンテキスト管理、非同期委任、プロトコルレベルの最適化が連携し、GPT‑Live を真にライブと感じられるものにする仕組みを紹介します。
従来の音声アーキテクチャは、テキスト LLM のターン制を受け継いでいました。ただし、各ターンはテキストではなく、個別の音声データの塊として表現されます。カスケード型システムでは、音声認識、LLM、音声合成を順番に実行していました。この逐次処理は遅延を増やし、声の調子や話す速さといった手がかりを取りこぼしていました。
音声変換モデルは、音声を直接処理することでこの方式を改善しました。音声を直接理解して生成するようモデルをトレーニングすることで、文字起こしでは失われる細部を保持し、より迅速に応答できるようになりました。それでもシステムは、推論を開始するタイミングの判断をターン検出器に依存していました。モデルが担う対話処理は増えましたが、対話そのものは依然としてターン制でした。
GPT‑Live では音声モデルが会話を制御します。音声がモデルへ出入りする一方、より深い推論やツール利用は非同期で行われます。システムの主な役割は、中断のないメディアループを維持することです。フロンティアモデルの呼び出しや会話の永続化など、その他の処理はライブ経路の外で行われます。
このメディアループを中断させないことは、必ずしも容易ではありません。転送、処理、推論の遅れは、聞き取れるほどの間や音声の乱れにつながる可能性があります。従来のターン制システムでは、音声データの塊が届くタイミングに多少のばらつきがあっても許容できました。しかし、ライブメディアシステムでは、すべての音声フレームを所定のタイミングで配信する必要があります。
ChatGPT 音声モードと Realtime API に関するこれまでの取り組みが、重要な基盤となりました。私たちはすでに、音声と映像をシステムへ直接ストリーミング入出力し、より低く予測可能な遅延を実現するため、音声インフラを再構築していました。GPT‑Live ではこの設計をさらに進化させ、継続的な会話向けに構築した新しいステートフル推論システムを通じて、モデルまでメディアをストリーミングします。
ただし、ストリーミング推論は解決策の一部にすぎません。本番環境で適切に機能させるには、クライアントから推論スタックまで音声を確実に届け、ステートフル性に伴う課題にも対処する必要がありました。
初期に下した重要な判断の一つは、メディアフローをアプリケーションロジックやビジネスロジックから明確に分離することでした。音声は、クライアントと音声モデルの間を専用の高速経路で移動します。委任、ツール利用、その他のアプリケーション処理は、非同期 RPC 境界の背後で実行されます。遅いツール呼び出しやバックエンドサービスによって、その結果自体は遅れても、メディアの流れが止まることはありません。
この分離により、システムにはカスタマイズのための明確な境界も生まれます。アプリケーションは、音声の流れを維持するメディアフロントエンドに影響を与えずに、ツール、ポリシー、バックエンドの動作を変更できます。ライブ経路は小規模で予測可能なまま維持され、リアルタイムで必須の処理に集中します。
従来の Python asyncio 実装を置き換え、メディアフロントエンドと推論ロジックを Go で記述しました。これによりフレーム配信が大幅に滑らかになり、新システムの p95 は従来システムの p50 と同等になりました。
転送基盤には WebRTC を採用しています。WebRTC は低遅延メディア向けに設計されており、パケット損失、クロックドリフト、クライアント接続の変化があっても動作を継続できます。パケットの到着が遅れた場合、WebRTC は音声をわずかに引き伸ばして途切れを防ぎ、その後、再生を短時間だけ速めてリアルタイムに追いつかせます。
システム全体でバッファリングとブロッキングを最小限に抑えることで、人が会話に期待する 1 秒未満の応答性を実現できます。
ステートフル推論には、運用上のトレードオフがあります。音声セッションは長時間続く場合がありますが、その間もコンテキストは増え続け、モデルインスタンスは需要に応じて起動、停止します。
こうした課題に対処するため、モデルインスタンス間をシームレスに引き継ぐ仕組みを構築しました。移行が必要になると、既存のモデルインスタンスと並行して代替インスタンスをウォームアップし、現在のセッションコンテキストをプリフィルして、両方で並行して推論を実行し、新しいインスタンスの準備が整った時点で切り替えます。
同じ基本的な仕組みは、動的なコンテキストのコンパクションにも対応します。会話が続くと、蓄積されたコンテキストがやがてモデルのコンテキスト上限を超えることがあります。コンパクションによりコンテキストを上限内に収められますが、この処理には時間がかかります。また、過去のコンテキストが変わるため、処理済みトークンのアテンションキーと値を保存する、モデルの Key-Value（KV）キャッシュも無効になります。その状態を再構築するには新たなプリフィルが必要となり、さらに遅延が生じます。
そこで、コンパクションも管理された移行の一つとして扱います。元のモデルインスタンスが会話を続けている間に、システムはコンテキストをコンパクションし、新しいコンテキストを設定した代替モデルインスタンスを準備します。そのインスタンスの準備が整えば、メディアを一切中断せずに切り替えられます。これにより、必要に応じてコンパクションしながら、長時間の通話を継続できます。
負荷の高い処理はライブ経路の外で行われるため、引き継ぎ中も会話の流れが途切れることはありません。
GPT‑Live は既存のフロンティアモデルを呼び出せるため、「話すこと」と、より深く「考えること」を実質的に分離し、大きな力を発揮します。ただし、この 2 モデル構成を一つのシステムのように感じさせるには、関連する二つのエンジニアリング課題を解決する必要がありました。
より深い作業への委任
GPT-Live は高速で自然な応答を提供し、GPT-5.5 はバックグラウンドで検索を処理します
まず、進行中の会話で役立つよう、結果を十分に早く返す必要があります。そのため、ルーティング、プロンプト処理、推論、ツール呼び出しに至る委任経路全体の遅延を最小限に抑えました。同時に、プロダクト内の他のシステムでは個別のメッセージが必要なため、進行中の会話をそれらが理解できる形式で表現する必要もありました。
委任を送信する際は、フロンティアモデルが会話に役立つ情報を生成するまでの時間を最適化します。フロンティアモデルが推論やツール利用を行う間、音声モデルは短時間なら会話をつなげられますが、際限なく遅い応答まで隠すことはできません。そこで、ルーティング、プロンプト処理、推論、ツール呼び出しを含む委任ループ全体を、応答時間の予算に含めました。
最初の最適化は、委任が要求される前にフロンティアモデルと必要なツールを準備することです。音声セッションの開始時に、アプリケーションサーバーはフロンティアモデル用の推論セッションを作成し、会話の初期コンテキストをプリフィルします。これにより、最初の委任リクエスト前にプロンプトの処理を完了させます。
その後、音声会話の間は推論セッションを利用可能な状態に保ち、連続するリクエストには安定したセッションアフィニティを使用します。これらの手法をプロンプトキャッシュと組み合わせることで、ワーカーに障害が発生しても容易に復旧できる状態を保ちながら、遅延を改善します。
推論の深さ、出力上限、ツールスキーマ、モデルとツール間の往復も、有用な結果が会話へ届くタイミングに影響します。そこで、これらを調整して応答を高速化しました。委任経路で必要な処理を最小限に抑えることで、音声モデルがフロンティアモデルの結果を迅速に取り込めるようになりました。
音声モデルは連続した音声ストリームを扱いますが、ChatGPT の会話 UI や分析・安全性インフラの一部など、周辺の多くのシステムは今もユーザーとアシスタントのターン単位で動作します。そのため、アプリケーションサーバーは、発話が重なり、ときに曖昧になる会話を個別のメッセージへと整理します。
音声が届くと、サーバーは途中段階の文字起こしとタイミング信号を使って誰が発話中かを推定し、メッセージのキューを構築します。最新のメッセージは暫定扱いです。音声が追加されるにつれ、テキスト、タイミング、話者の割り当てはいずれも変わる可能性があります。一人の話者が十分な時間にわたって発話を続け、帰属を信頼できるようになると、サーバーは対応するメッセージを確定します。
話者の発話が重なると、処理はさらに複雑になります。ユーザーが話している間のアシスタントによる短い相づち（「うんうん」「わかりました」など）を、必ずしも独立したメッセージにする必要はありません。一方、内容のあるアシスタントの割り込みは、多くの場合、独立したメッセージにすべきです。同様に、ユーザーが途中で話しても、表示されるアシスタントの応答では一貫性を優先します。
どの分割ポリシーにも、即時性と確実性のトレードオフがあります。確定が早すぎると履歴が断片化して順序も不安定になり、遅すぎると文字起こしや、それに依存する機能が遅れます。そのため、システムは会話について二つの関連するビューを維持します。現在の状態を示す暫定ビューと、発言内容の正式な記録です。アプリケーション UI の会話ビューは更新に対応できるため、暫定ビューを使用します。一方、分析パイプラインへのログ記録には、確定した文字起こしが必要です。
これにより、ライブ音声経路にターン制を強いることなく、ChatGPT の他の部分へ会話の安定したビューを提供できます。
応答性は、ユーザーがボタンをクリックした瞬間から始まります。GPT‑Live では、会話を始める前にメディア経路を確立し、モデルへの音声供給を開始する必要があります。つまり、起動シーケンスのあらゆる処理がクリティカルパス上にあります。
前述のとおり、WebRTC は優れたリアルタイム基盤ですが、標準の WebRTC セッションを開始するには、驚くほど多くのプロトコルハンドシェイクとネットワーク往復が必要です。WebRTC は、QUIC など後発のプロトコル設計に影響を与えた、往復回数を最小限に抑えるという考え方が重視される以前に誕生しました。そのため、基盤となる各プロトコルを組み合わせると、同じ処理を繰り返す場合があります。たとえば、WebRTC スタック全体の文脈では不要な場合でも、各プロトコルに独自の DoS 対策機構が含まれていました。
私たちはスタックを分析し、メディアとデータの起動に必要なネットワーク往復を 6 回からわずか 1 回へ削減する WebRTC Abridged Roundtrip Protocol（WARP（新しいウィンドウで開く））を開発しました。WARP は、後方互換性を備えた複数のプロトコル改善によってこれを実現します。具体的には、ICE 上での DTLS ハンドシェイクの相乗り（SPED（新しいウィンドウで開く））、高速な DTLS 1.3（新しいウィンドウで開く） ハンドシェイクの利用、SCTP ハンドシェイクの事前ネゴシエーション（SNAP（新しいウィンドウで開く））、DCEP（新しいウィンドウで開く） を使わないデータチャネルの事前ネゴシエーションです。
より広範なエコシステムが成果を活用できるよう、WebRTC コミュニティの協力者と連携し、WARP をオープンな仕様群として設計しました。現在、IETF の TSVWG ワーキンググループを通じて提案を進めています。WARP 対応はすでに libwebrtc と Pion の両方に追加され、他の WebRTC 実装でも作業が進行中です。
メディアハンドシェイクを最適化した後も、一つの遅延が目立っていました。WebRTC の接続前に SDP パラメーターを共有するためのシグナリング交換です。この交換をクリティカルパスから外すため、Instant Connect と呼ぶ仕組みを開発しました。Instant Connect は、サーバーキャパシティを予約せず、既存の WebRTC 実装にも変更を加えずに、これらのパラメーターを事前にネゴシエーションします。
Instant Connect は、標準のシグナリングフローと並行して動作します。事前にネゴシエーションしたパラメーターが有効なら、最初のメディアパケットが届いた時点で、サーバーはセッションを実体化できます。パラメーターが古いか無効な場合も、シグナリングフローはすでに進行しているため、クライアントは追加の遅延なくフォールバックできます。
Instant Connect と WARP を組み合わせることで、ユーザーの操作からライブメディアの開始までの時間を大幅に短縮できます。SDP 交換をクリティカルパスから外し、WARP で転送ハンドシェイクを集約したことで、クライアントは 1 個の UDP パケットだけでセッションを開始できるようになりました。サーバーは即座に応答でき、システムの他の部分も、ユーザーが本当に求める「聞いて応答する」処理を開始できます。
設計上は高速に見えるシステムでも、実際の音声トラフィックでは停止することがあります。GPT‑Live をユーザーとの会話に導入する前に、本番環境の ChatGPT 音声モードのセッションのうち、少量から徐々に比率を増やしながら、既存の高度な音声モードと新システムの両方へ振り分けるサイレントテストを実施しました。高度な音声モードは通常どおりユーザーにサービスを提供し、シャドウパスでは読み取り専用モードで推論を実行しました。これにより、ユーザーが聞く内容を変えずに、実際のクライアント、ネットワーク、セッション時間、地理的分布の下でシステムを検証できました。
最初に得た教訓の一つは、キャパシティを GPU のスループットだけでは評価できないということでした。音声セッションは接続を維持したまま継続的にフレームを送信するため、CPU 側のストリームハンドラー、キュー、ネットワーク経路も推論とともにスケールさせる必要があります。実負荷の下では、補助コンポーネントの一つが負荷テストの予測より早く飽和し、推論リクエストが蓄積して遅延が連鎖的に増大しました。そこで、キャパシティに関する問いを「GPU は何件のリクエストを処理できるか？」から「すべてのフレームを所定のタイミングで処理しながら、システムはいくつの同時セッションを維持できるか？」へと変更しました。
このテストでは、地理的条件も最優先の課題として浮上しました。遠隔地のキャパシティへセッションをルーティングすると、起動時やストリーミング中の複数箇所で遅延が生じる可能性があります。そこで、モデルのロールアウトを地域別キャパシティやトラフィック制御設定と併せて検証し、送信元の地域別に遅延を分析するようにしました。推論をユーザーの近くへ移すことで改善しましたが、より広い教訓も再確認できました。エンドツーエンドの応答性はモデルサーバーだけでなく、経路上のすべてのサービスに左右されます。
現実的なセッションのライフサイクルを通じて初めて現れる障害もありました。長時間のセッションでは、メモリと永続化への負荷が明らかになりました。再接続によって、コンパクションと状態復元の処理が試されました。通常のクライアント切断からは、終了ハンドシェイクの競合状態が判明しました。こうした問題は、時間、蓄積された状態、サービス境界をまたぐ動作に依存するため、短時間の負荷テストではほとんど現れませんでした。
さらに、本番テストを通じて、可観測性とロールアウト制御の改善も迫られました。異なる遅延要因を混同した指標、個々の不健全なエンジンを集計値で隠してしまうダッシュボード、テスト環境とデプロイ環境の設定差異が見つかりました。そこで、より詳細なテレメトリ、正常と確認済みの設定に照らした検証、段階的な増強、個々の経路を迅速に分離または無効化する機能を追加しました。サイレントテストは、システムが受け入れられるトラフィック量だけでなく、障害をどれだけ迅速に検知、封じ込め、復旧できるかを確認する、早期のリリース予行演習となりました。
GPT‑Live を ChatGPT の規模で提供するには、「音声の流れを止めない」という基本原則に基づく、まったく新しいシステムが必要でした。ストリーミング推論により、全二重モデルへ音声を供給し続けます。専用のメディア経路により、フレームを確実に配信します。非同期委任により、より深い思考を並行して実行できます。最適化された転送により、ユーザーに届くまで一貫した応答性を保ちます。
GPT‑Live を支えるアーキテクチャは、リアルタイム対話のための、より広範なプラットフォームへと発展し始めています。会話からエージェント型の連携へと進化する ChatGPT 音声モードを支え、今後登場する GPT‑Live API の基盤にもなります。将来的には、音声会話のライブ感を生む即時性を損なうことなく、より多くのデバイス、アプリ、モダリティへ音声体験を広げられるようになります。
このようなエンジニアリング課題に取り組みたい方は、ぜひ私たちと一緒に働きませんか。
