AIREITERユーザーが黙るまで考え始めない音声エージェントは、速くてもどこか機械的に感じられる。GPT-Liveはこの制約をアーキテクチャの段階から見直し、音声の入出力を止めずに処理しながら、検索やツール呼び出し、より深い推論をオーディオループの外側で並行して実行する。会話はより自然になる一方、運用の難易度は確実に上がる。
GPT-LiveのフルデュプレックスAPIを1分で理解する
GPT-Liveは、単に音声入出力が速いエンドポイントではない。OpenAIの説明によれば、入力音声を処理しながら出力音声を生成し、1秒間に何度も会話上の判断を下しつつ、より深い処理をフロンティアモデルへ委譲できるフルデュプレックスの音声システムだ。OpenAIのエンジニアリング記事では、ストリーミング推論、状態を持つ会話、WebRTCによる通信、メディア経路の外側で行う非同期処理を中心に設計されたシステムだと説明されている。
実装上は、次のように捉えると分かりやすい。
| レイヤー | 役割 | 設計上のポイント |
|---|---|---|
| メディア経路 | クライアントと音声モデルの間で音声フレームを転送する | 短く予測可能に保ち、業務APIから切り離す |
| フルデュプレックス音声モデル | 聞く、話す、間を取る、割り込みに対応する、会話のタイミングを管理する | 無音ベースのターン検出を主制御にしない |
| 委譲レイヤー | 検索、推論、ツール処理を非同期で実行する | レイテンシーに敏感なバックグラウンドジョブとして扱う |
| アプリケーションレイヤー | ツール、権限、確認、業務ルールを検証する | 流暢な発話だけで重大な操作を承認させない |
| プロダクト記録 | 文字起こし、分析、UIメッセージを管理する | 暫定的な会話表示と確定済みの記録を分ける |
重要なのは、「時間」を誰が管理するかが変わることだ。従来の音声エージェントでは、ユーザーの発話が終わるのを待ち、それをモデルに送り、返答を再生する。GPT-Liveの設計では、音声セッションを維持したまま、複数の処理が同時に進む。
ターン制の前提は、もう主役ではない
カスケード型の音声システムでは、音声認識、言語モデル、音声合成を順番に実行する。音声から音声へ直接処理するモデルなら引き継ぎの一部は減るが、それでも別の音声区間検出器が、推論を始める前にユーザーの発話終了を判断する構成は残り得る。短い思考の間が発話終了と誤認されたり、周囲の音が新しい発話として扱われたりすることもある。
GPT-Liveのフルデュプレックス方式では、このタイミングの判断を音声モデル側に移す。モデルは話しながら聞き続け、割り込みを検知し、いったん止まったり、話を続けたり、短い相づちを返したりできる。ターン境界が完全になくなるわけではない。ターン境界によってライブ音声のループが止まることを避ける、というのが本質だ。
GPT-Liveがライブ経路で変えるもの
ターン待ちではなく、継続的な推論へ
フルデュプレックスのセッションでは、入力と出力は交互に届く音声データの塊ではなく、ストリームとして扱われる。モデルは直前の返答を再生している最中にも新しい発話を受け取り、それが意味のある割り込みなのか、短い相づちなのか、背景ノイズなのかを判断できる。
この変化はクライアントのロジックにも及ぶ。クライアントは、音声イベントの送信、受信、キャンセル、差し替えを同時に処理できなければならない。単一のawait response()に隠れた抽象化では、この動きに対応しにくい。重要なのは、発話開始、アシスタント音声の開始、割り込み検知、ツール要求、レスポンスのキャンセル、セッション終了といったイベントだからだ。
UIや分析、安全対策のために、音声区間の検出シグナル自体は残しておくべきだ。問題は、VADだけを「いつ推論を開始してよいか」を決める唯一の権威にしてしまうことにある。
音声は高速に。重い処理は経路の外へ
OpenAIのエンジニアリング記事では、専用の音声経路とアプリケーションロジックを分離している。音声はクライアントと音声モデルの間を直接流し、ツール呼び出し、ポリシーチェック、永続化、バックエンド処理は非同期の境界を越えて実行する。
この分離によって、明確なルールが生まれる。CRMの検索に時間がかかっても、その処理の返答が遅れるだけで、音声フレームの到着まで遅らせてはいけない。WebRTCは低レイテンシーのメディア転送を担い、マイクから届くすべてのフレームとモデルの間にアプリケーションサービスを同期的に挟むべきではない。
委譲したタスクの処理中に、音声レイヤーが短い説明を返すことはできる。ただし、つなぎの発話は、期限が定められていないジョブの代わりにはならない。すべてのツールに対して、タイムアウト、キャンセルのルール、安全な結果状態を設定しておこう。
処理の委譲で、応答性と知性を切り分ける
GPT-Liveは、検索やより深い推論、複雑な処理をフロンティアモデルへ委譲できる。OpenAIのローンチ記事とエンジニアリング記事では、ローンチ時の委譲先モデルとしてGPT-5.5が挙げられている。音声モデルは目の前の会話を担当し、低レイテンシーで話し続けるループに収まりにくい処理をフロンティアモデルが担う。
本番環境では、委譲処理を独立したパイプラインとして設計したい。
- 検索、推論、ツールが必要なリクエストだと判断する。
- メディア経路を止めずに、短く応答するか、いったん間を取る。
- 必要な会話コンテキストを付けてバックグラウンドジョブを開始する。
- ユーザーが話題を変えたり、セッションを終了したりしたらキャンセルする。
- 結果をアプリケーション側で検証する。
- 簡潔な結果をライブセッションへ戻す。
委譲先の推論セッションをあらかじめ初期化しておくこと、セッションアフィニティを維持すること、繰り返し使うコンテキストをキャッシュすることは、有用な出力が返るまでの時間を短縮する可能性がある。エンドツーエンドの予算に含まれるのは、モデルのトークンレイテンシーだけではない。ルーティング、プロンプト処理、モデル推論、ツール呼び出し、モデルとツールの間の往復をすべて見積もる必要がある。
状態を持つセッションには、もう一つのアーキテクチャが要る
長時間の音声通話は、使い捨てのリクエストを並べたものではない。コンテキストは増え、モデルワーカーは入れ替わり、セッションの圧縮が必要になることもある。OpenAIは、交換先のモデルインスタンスをあらかじめウォームアップし、現在のコンテキストを投入して、準備が整ってから切り替える方法を説明している。これならインフラの切り替えを通話相手に意識させずに済む。
コンテキストの圧縮も同じ問題を生む。過去のターンを要約すると、モデルのKey-Valueキャッシュを支えるコンテキストが変わる。そのキャッシュをフォアグラウンドで再構築すれば、通話に間が生じる。より安全なのは、コンテキストの圧縮を並行して行い、交換先のインスタンスを準備し、引き継ぎの準備が整うまで古いインスタンスで処理を続ける設計だ。
したがって、音声エージェントのバックエンドが持つセッション状態は、文字起こしだけでは足りない。
- 現在の音声とレスポンスの状態
- 実行中のツール呼び出しとキャンセルトークン
- モデルインスタンスまたはワーカーのアフィニティ
- 暫定メッセージと確定済みメッセージ
- コンテキスト圧縮の状態
- 再接続と復旧の状態
- 安全対策と確認の状態
APIの契約は、リクエスト／レスポンスではなくイベントで考える
フルデュプレックス化すると、外部APIが最終的に使い慣れたSDKメソッドを提供する場合でも、内部プロトコルは変わる。アプリケーションでは、混同されがちなイベントを明確に区別しなければならない。
| イベント | 意味 | 取るべき対応 |
|---|---|---|
| キャンセル | 保留中の処理を止める | ジョブをキャンセルし、リソースを解放する |
| 割り込み | 現在の出力に重ねてユーザーが話し始める | セッションを終了せず、アシスタント音声を止めるか修正する |
| セッション終了 | 通話または会話が終わる | メディア、ツール、永続化、課金の状態を閉じる |
| ツール失敗 | 委譲した処理が完了しなかった | 安全に説明し、代替手段を提示する |
| 再接続 | メディア経路が中断された | 操作を重複させずに状態を復元する |
GPT-Liveは継続的に動作できるが、プロダクトのUI、分析、安全対策の仕組みには、依然としてメッセージが必要だ。OpenAIは、文字起こしが届くたびに修正できる推測的なビューと、後から確定する権威ある記録を分けて管理する方法を説明している。これは有用なパターンだ。反応のよい字幕を表示しつつ、部分的な文字起こしを変更不能な事実として扱わずに済む。
音声エージェントチームが設計し直すべきポイント
メディアアダプターとエージェント制御を分離する
プロバイダー固有の通信処理とイベント処理は、アダプターの内側に閉じ込めよう。アプリケーション側が受け取るのは、user_audio_started、assistant_interrupted、tool_requested、confirmation_required、response_completedのような正規化済みイベントにする。
モデルID、音声、プロンプト、ツールスキーマ、コスト上限は設定として管理する。これは単なる移行対策ではない。現在はドキュメント化されたRealtimeモデルをテストしながら、将来的なGPT-Liveのセマンティクスを明確な目標として維持できる。
ツールについては、モデルが提案し、アプリケーションが検証する。支払い、アカウント変更、キャンセル、住所変更、医療トリアージ、金融操作、本人確認のフローでは、モデルが自信を持って話したこととは別に確認ルールを設ける必要がある。
音声をどこで制御するかで通信方式を選ぶ
音声を直接キャプチャーして再生するブラウザーやモバイルクライアントには、WebRTCが自然な選択肢になる。サーバー側でメディアを制御するパイプラインでは、WebSocketが引き続き有用な場合もある。ただし、すべてのリアルタイムモデルが、すべての通信方式で同じセッション形式を受け付けるとは限らない。
OpenClawの統合に関するIssueには、実際に起こり得る失敗例が記録されている。gpt-live-1を通常のGA版Realtime WebSocketセッションとして扱ったところ、invalid_modelのレスポンスが返された。一方、提案されたGPT-Liveのブラウザフローでは、別形式のWebRTCセッションが使われていた。このIssueは実装上の報告であり、OpenAI APIの契約そのものではない。ただし、モデルファミリーを判別し、対応するセッション形式を明示的にネゴシエーションするという設計原則を裏付ける事例ではある。
トークンレイテンシーではなく、音声フレームの期限内到着を測る
OpenAIのエンジニアリング記事によれば、本番テストではGPU容量より先に、ストリームを支えるコンポーネントが飽和した。実用的なキャパシティの単位は、GPUあたりのリクエスト数ではなく、音声フレームを期限内に届けながら維持できる同時セッション数だった。
最低限、次の指標を追跡したい。
- 音声フレームの遅延とドロップ
- 再生可能な音声が最初に届くまでの時間
- 割り込みから音声停止までの時間
- リージョン別の同時セッション数
- 再接続とツール呼び出しの重複
- 委譲処理の完了時間
- ツールのタイムアウト率とキャンセル率
- 暫定文字起こしから確定版への修正
- 放棄されたセッションとセッションあたりの支出
自然な会話には、操作感に関する問題もある。ある状況では割り込みや相づちが好まれても、別の状況では煩わしく感じられるかもしれない。初期ユーザーの報告には、そのリスクを端的に表すものがあった。「It's literally cutting her off constantly lmao」（@AutismCapital）。これは、台本どおりのデモではなく、実際の会話を基準に割り込みポリシーを調整すべきだという注意喚起として受け止めたい。
GPT-Liveと現在のRealtime、どう選ぶか
OpenAIの公式モデルカタログでは、GPT-Live 1は自然で表現力のある音声会話向けのモデルとして位置づけられ、滑らかな割り込み処理も強調されている。ただし、このカタログは完全な統合仕様書ではない。ここで確認したGPT-Live APIの別ページも、現時点ではエンドポイント、レート、上限の詳細ではなく、通知を受け取るためのフォームにとどまっている。ローンチ計画を固める前に、最新の開発者ドキュメントとアカウントの利用資格を確認しておくべきだ。
| 要件 | 現実的な選択 |
|---|---|
| ドキュメント化された音声エージェントを今すぐ出荷したい | ドキュメント化されたRealtimeスタックをアダプターの内側で使う |
| 自然な音声の重なりと、モデルが主導するターンテイキングを必須要件にしたい | GPT-Liveのフルデュプレックスなイベントモデルを前提に設計し、まず利用資格を確認する |
| ブラウザーまたはモバイルの音声 | プロバイダーがサポートするWebRTC経路を優先する |
| 複雑な業務操作 | 非同期ツールとアプリケーション側の確認処理を維持する |
| 長時間の通話 | ローンチ前に、引き継ぎ、圧縮、再接続、永続状態の処理を実装する |
このアーキテクチャは、すべてのアカウントでモデルを利用できるようになる前から採用する価値がある。継続的なメディア処理、正規化されたイベント、非同期ツール、明示的なキャンセルは、従来型のリアルタイムモデルで構築する音声エージェントにも有効だ。
GPT-LiveフルデュプレックスAPI FAQ
GPT-LiveはGPT-Realtimeと同じものですか？
いいえ。OpenAIはGPT-Liveを音声会話向けの独立したモデルファミリーとして扱っている。一方、GPT-Realtimeはドキュメント化されたリアルタイムAPIのファミリーだ。音声機能が似ていても、セッションのセマンティクス、通信方式、モデルIDまで同じだとは限らない。
フルデュプレックスなら、モデルは決して待たないのですか？
いいえ。フルデュプレックスとは、聞くことと話すことを同時に実行できるという意味だ。モデルが間を取ったり、黙っていたり、確認を求めたり、委譲した結果をより安全で有用なタイミングまで遅らせたりすることはある。
VADは今後も必要ですか？
必要だ。メディアUX、分析、字幕、安全対策のシグナルとして使える。ただし、モデルをユーザーのターンとアシスタントのターンに機械的に分ける唯一のゲートにしてはいけない。
音声エージェントはどの通信方式を使うべきですか？
対象のクライアントとモデルがサポートする通信方式を使う。一般に、ブラウザーやモバイルから音声を直接扱うならWebRTCが適しており、バックエンドのメディアパイプラインでは、ドキュメントに記載されている場合にWebSocketを使える。モデル名だけから通信方式の対応状況を推測してはいけない。
利用資格が確認できる前に、何を作っておくべきですか？
アダプター、正規化したイベントスキーマ、ツール検証レイヤー、キャンセルモデル、コストのテレメトリー、フォールバック、長時間セッションの復旧機構を作っておこう。最終的なGPT-Live APIの契約が変わっても、これらのコンポーネントは役に立つ。
選ぶべきはモデル名ではなく、アーキテクチャ
長く使える判断は、音声をテキストモデルにかぶせたリクエスト／レスポンスのラッパーとして扱うのをやめることだ。音声経路を常時利用可能に保ち、時間のかかる処理は非同期の境界の向こう側へ移し、割り込みとキャンセルを一級のイベントとして扱う。そして、権威ある記録になる前の文字起こしは、修正可能な状態で管理する。
GPT-Liveのトレードオフは明確だ。より自然な音声の重なりと処理の委譲を得るには、より多くの状態管理と可観測性が必要になり、単純なターン境界だけで制御する余地は小さくなる。その複雑さを受け入れられるチームは、今からフルデュプレックスの契約を前提に設計できる。一方、ドキュメント化された本番エンドポイントを必要とするチームは、同じイベント駆動の接続点を保ったまま、Realtimeで出荷すればよい。