音声AIは、回答内容が正しくても、返答までに間が空いたり、ユーザーの発話を途中で遮ったりすると使いにくく感じます。人同士の会話では、相手が話し終えるタイミングを自然に読み取り、必要に応じて相づちを打ち、少し考えながら会話を続けています。音声AIで同じ体験を実現するには、モデル性能だけでなく、通信、推論、状態管理、ツール実行を含むシステム全体の設計が必要です。
OpenAIは2026年8月3日、リアルタイム音声システム「GPT-Live」を6か月で構築した方法を公式技術ブログで公開しました。GPT-Liveは、音声を聞きながら同時に話せるフルデュプレックス型の音声モデルを中心に、深い推論やツール利用を別経路へ非同期で委譲する設計を採用しています。
この発表で重要なのは、新しい音声モデルの性能だけではありません。低遅延のメディア経路と業務ロジックを分離し、長時間会話の状態を引き継ぎ、通信開始時の往復回数を削減し、本番トラフィックで段階的に検証した点です。音声AIを開発しないSEにとっても、リアルタイム処理やAIエージェントを設計する際の実践的な判断材料になります。
GPT-Liveとは
GPT-Liveは、OpenAIが公開した第3世代の音声システムです。従来の音声AIでは、ユーザーが話し終えたと判定してからモデルが処理を始める方式が一般的でした。これに対してGPT-Liveは、音声モデル自体が会話の流れを扱い、入力音声を受け取りながら出力音声を返します。
OpenAIの説明では、GPT-Liveの音声モデルはフルデュプレックスです。フルデュプレックスとは、電話のように送信と受信を同時に行える方式を指します。ユーザーが話している途中でもシステムは音声を理解し続け、必要に応じて応答を生成できます。
さらに、複雑な調査、深い推論、ツール利用が必要な場合は、GPT-LiveがGPT-5.5などのフロンティアモデルへ処理を委譲します。音声モデルは会話を止めずに進行し、別のモデルが裏側で検索や推論を行う構成です。
2026年8月4日時点では、OpenAIはこのアーキテクチャがChatGPT Voiceの基盤として使われ、今後提供予定のGPT-Live APIにもつながると説明しています。ただし、APIの料金、一般提供日、具体的な利用上限は公式記事では明示されていません。導入を検討する場合は、今後の公式発表を確認する必要があります。
従来の音声AIが遅く感じられる理由
以前の音声AIは、音声認識、言語モデル、音声合成を順番に処理するカスケード構成が中心でした。ユーザーの声を文字へ変換し、その文字をLLMへ渡し、生成された文章を再び音声へ変換します。
この方式は各部品を独立して改善しやすい反面、処理が直列になるため待ち時間が積み重なります。文字起こしの途中結果が確定するまでLLMが動けず、LLMの回答が完成するまで音声合成を始められない設計では、自然な会話のテンポを作りにくくなります。
音声を直接扱うSpeech-to-Speechモデルは、声の調子、間、話す速さなど、文字変換で失われやすい情報を保持できます。しかし、従来型では「ユーザーが話し終えたか」を判定するターン検出器が残っていました。
ターン検出器が早く判断すると、ユーザーの発話を遮ります。遅く判断すると、返答までの無音時間が長くなります。GPT-Liveは、この判定器を音声経路から外し、モデル自身が連続した会話を扱う方向へ設計を変えました。
GPT-Liveの中心はストリーミング設計
GPT-Liveでは、受信した音声を小さな単位でモデルへ送り、生成された音声も順次クライアントへ返します。リクエストを最後まで受け取ってから一括処理するのではなく、音声が流れている間ずっと推論が続きます。
この設計では、音声フレームが予定どおり届くことが重要です。通常のAPIでは数十ミリ秒の揺れが目立たない場合でも、音声ストリームでは遅延がそのまま無音、途切れ、音質の乱れとして現れます。
OpenAIは、音声を運ぶ経路をアプリケーションロジックから分離しました。音声は専用の高速経路を通り、ツール呼び出し、業務処理、会話の保存などは非同期RPC境界の裏側で動きます。
この分離により、外部APIや社内システムの応答が遅くても、音声そのものは流れ続けます。音声AIを業務へ組み込む場合、すべての処理を同じ同期フローへ入れないことが重要です。遅い処理を音声経路へ直結すると、バックエンドの小さな遅延が会話体験全体へ影響します。
メディア処理と業務ロジックを分離する意味
GPT-Liveの設計から最も学びやすい点は、リアルタイム性が必要な処理と、それ以外の処理を明確に分けたことです。
低遅延が必要な経路には、音声の受信、モデルへの転送、音声出力など、会話を止めないために不可欠な処理だけを置きます。一方で、顧客情報の検索、予約システムへの登録、長文の推論、ログ保存などは別経路で動かします。
たとえば音声による社内ヘルプデスクを作る場合、次のような分離が考えられます。
- 高速経路：音声入出力、相づち、聞き返し、会話継続
- 非同期経路：ナレッジ検索、チケット照会、権限確認
- 確定処理：チケット登録、アカウント変更、担当者への転送
この構成なら、チケットシステムの応答が遅い場合でも、「確認しています」と会話をつなぐことができます。ただし、AIが結果を得ていない段階で処理済みと案内しないよう、会話状態と業務状態を分けて管理する必要があります。
PythonからGoへ置き換えた理由
OpenAIは、メディアフロントエンドと推論ロジックをGoで実装し、以前のPython asyncioベースの実装から置き換えたと説明しています。その結果、新システムのp95が旧システムのp50と同等になるほど、音声フレーム配信の安定性が改善したとしています。
p50は全体の中央値、p95は遅い側から見て上位5%の境界です。p95が旧構成のp50と同程度になったという説明は、平均的なケースだけでなく、遅延しやすいケースでも改善したことを示します。
ただし、この事例から「リアルタイム処理は必ずGoで作るべき」と結論付けるのは適切ではありません。言語選定だけでなく、ガベージコレクション、非同期処理の設計、スケジューリング、負荷特性、チームの運用能力が影響します。
SEが言語選定を行う場合は、平均速度だけでなく、遅延のばらつき、障害時の挙動、プロファイリングのしやすさ、既存資産との統合を確認する必要があります。リアルタイム音声では、平均100ミリ秒よりも、通常は速いのに一部の接続だけ数秒止まる問題の方が利用者へ強く影響します。
WebRTCを使う理由
GPT-Liveは、音声通信の基盤としてWebRTCを利用しています。WebRTCは、ブラウザやアプリ間で低遅延の音声・映像通信を行うための技術です。パケット損失、時計のずれ、ネットワーク切り替えなどが起きても、会話を継続しやすい仕組みを備えています。
音声パケットの到着が遅れた場合、WebRTCは音声をわずかに伸ばして隙間を防ぎ、その後に再生速度を調整して現実時間へ追いつく処理が可能です。HTTPで音声ファイルを順番に送るだけでは、同じ品質を実現するための制御を個別に実装しなければなりません。
一方で、WebRTCは接続開始時に複数のハンドシェイクを必要とします。音声通話では、会話中の遅延だけでなく、開始ボタンを押してから話せるまでの時間も利用体験に影響します。
WARPで接続開始を高速化
OpenAIは、WebRTCの接続開始に必要なネットワーク往復を削減するため、WebRTC Abridged Roundtrip Protocol、略称WARPを開発しました。
公式記事によると、通常のメディア・データ接続開始では6回のネットワーク往復が必要だったところ、WARPでは1回へ減らしています。DTLSハンドシェイクをICEへ重ねる方法、DTLS 1.3、SCTPハンドシェイクやデータチャネルの事前合意などを組み合わせています。
OpenAIはWARPをオープンな仕様として設計し、IETFの作業部会で提案を進めています。また、libwebrtcとPionにはすでにWARP対応が追加され、他のWebRTC実装でも対応が進行中と説明しています。
さらに、SDPパラメータ交換を接続開始の重要経路から外すため、Instant Connectという仕組みも開発しました。事前交渉した値が利用できれば、最初のメディアパケット到着時にサーバー側でセッションを具体化します。値が古い場合は通常のシグナリングへ戻れるため、最適化が失敗しても追加遅延を増やさない設計です。
長時間会話を支える状態管理
リアルタイム音声セッションは、通常の1回完結型APIより状態管理が難しくなります。会話が長くなるほどコンテキストが増え、モデルインスタンスの入れ替えや負荷分散も必要です。
GPT-Liveでは、既存のモデルインスタンスを動かしたまま、交換先のインスタンスを準備します。現在の会話コンテキストを新しいインスタンスへ事前入力し、両方で並行して推論できる状態を作った後、準備が完了した時点で切り替えます。
この仕組みは、コンテキスト圧縮にも利用されます。長い会話では、過去の内容を短くまとめてコンテキスト上限へ収める必要があります。しかし圧縮によって過去の内容が変わると、モデルが保持していたKVキャッシュを再構築しなければなりません。
そこで、元のインスタンスが会話を続けている間に、別のインスタンスで圧縮済みコンテキストを準備します。準備完了後に切り替えることで、圧縮処理による音声停止を避けます。
業務システムで同様の設計を採用する場合は、単に会話履歴を短くするだけでは不十分です。顧客名、予約日時、承認状況など、失ってはいけない業務情報を構造化データとして別に保持し、要約文へ依存しすぎない設計が必要です。
音声モデルと推論モデルを分ける設計
GPT-Liveでは、話す役割と深く考える役割を分けています。音声モデルは自然なテンポで会話を続け、検索や複雑な推論は別のフロンティアモデルへ委譲します。
この二層構成には利点があります。すべての音声フレームを大規模な推論モデルで処理すると、コストと遅延が増えやすくなります。逆に、高速な音声モデルだけでは、複雑な質問やツール利用へ対応しにくくなります。
役割を分けることで、日常的な相づち、聞き返し、会話継続は高速なモデルへ任せ、必要なときだけ高性能モデルを使えます。AIエージェントを設計する際にも、すべての処理を同じモデルへ任せるのではなく、速度、精度、コスト、権限に応じて役割を分ける考え方が有効です。
ただし、委譲結果が遅すぎると会話の流れへ間に合いません。OpenAIは、音声セッション開始時にフロンティアモデルの推論セッションも準備し、初期コンテキストを事前入力しています。さらに、同じワーカーへ接続し続けるセッションアフィニティやプロンプトキャッシュを利用して遅延を抑えています。
連続音声を会話履歴へ変換する難しさ
音声モデルは連続したストリームを扱いますが、ChatGPTの画面、分析基盤、安全性システムなどは、ユーザーとアシスタントの発言を個別のメッセージとして扱います。
GPT-Liveのアプリケーションサーバーは、部分的な文字起こしと発話タイミングを使い、どちらが話しているかを推定してメッセージ列を構築します。最新メッセージは仮の状態で保持され、音声が増えると文面、時刻、話者判定が変わる場合があります。
短い相づちは独立したアシスタント発言として残す必要がない一方、内容のある割り込みは記録する必要があります。ユーザーとAIが同時に話す状況では、単純な無音区切りだけで正しい会話履歴を作れません。
OpenAIは、更新可能な暫定ビューと、確定済みの正本記録を分けています。画面表示には新鮮さを優先した暫定ビューを使い、分析ログには確定した文字起こしを使います。
この考え方は、音声以外のストリーミング処理にも応用できます。途中結果をすぐ見せる用途と、監査や集計に使う確定データを同じ扱いにすると、後から値が変わる問題やログ不整合が起こりやすくなります。
本番トラフィックでのサイレントテスト
OpenAIは、新システムを利用者へ直接聞かせる前に、既存のChatGPT Voiceセッションの一部を新旧両方へ流すサイレントテストを行いました。利用者には従来のAdvanced Voice Modeが応答し、新しいGPT-Live側は読み取り専用で推論します。
この方法なら、実際の端末、ネットワーク、地域、会話時間を使って負荷を確認しながら、利用者の体験を変えずに検証できます。
テストでは、GPUの推論能力だけを見ても容量を正しく判断できないことが分かりました。音声セッションは長時間接続し、音声フレームを継続して送るため、CPU側のストリーム処理、キュー、ネットワーク経路も同時に拡張する必要があります。
OpenAIは、容量の問いを「GPUが何リクエスト処理できるか」から「すべての音声フレームを予定どおり処理しながら、何セッションを同時維持できるか」へ変えたと説明しています。
これは業務システムの性能試験でも重要です。短いAPI呼び出しを大量に送る負荷試験だけでは、長時間接続、再接続、状態復元、メモリ増加、切断時の競合を再現できません。実際の利用時間と接続ライフサイクルを想定した試験が必要です。
地域差とエンドツーエンド遅延
音声AIでは、利用者と推論基盤の物理的な距離も遅延へ影響します。遠い地域のサーバーへ接続すると、セッション開始、音声転送、ツール呼び出しの各段階で遅延が積み重なります。
OpenAIは、モデルの展開だけでなく、地域ごとの容量とトラフィック制御を同時に検証し、音声処理を利用者へ近づけました。モデルサーバーだけを高速化しても、その前後のネットワークや業務サービスが遅ければ、会話全体は速くなりません。
日本向けの音声サービスを構築する場合は、推論リージョン、顧客データの保存場所、外部システムの配置、海外リージョンへの通信を確認する必要があります。速度だけでなく、データ保護、契約条件、障害時の切り替えも含めて判断します。
SE実務で参考になる設計原則
GPT-Liveの技術解説は大規模な音声基盤の事例ですが、一般的な業務システムにも応用できる考え方があります。
重要経路を小さく保つ
ユーザーが待つ処理には、本当に必要な処理だけを置きます。ログ保存、分析、補助的な検索まで同期実行すると、関係するサービスが増えるほど障害と遅延の影響を受けます。
遅延の平均値だけを見ない
平均応答時間が短くても、一部の利用者だけ数秒待たされるシステムは実用上の問題があります。p95やp99、地域別、端末別、処理経路別の遅延を確認する必要があります。
状態の引き継ぎを前提にする
長時間セッションでは、サーバー交換、障害復旧、スケール変更が起こります。1台のインスタンスが最後まで動く前提ではなく、途中で引き継げる設計にします。
途中結果と確定データを分ける
画面へすぐ表示する仮データと、請求、監査、分析へ使う確定データは役割が異なります。更新される可能性のある情報を正本として扱わないようにします。
本番に近いライフサイクルで試験する
短時間の負荷試験だけでなく、長時間接続、切断、再接続、状態圧縮、バックエンド遅延を含むシナリオを用意します。
音声AI導入前に確認したい点
GPT-Live APIの詳細は今後の発表待ちですが、音声AIを業務へ導入する場合は、技術だけでなく運用条件を先に整理する必要があります。
音声データと文字起こしの保存範囲
音声そのものを保存するのか、文字起こしだけを保存するのか、保存期間はどの程度かを決めます。個人情報や機密情報を扱う場合は、アクセス権、削除方法、監査ログも必要です。
AIが実行できる操作
検索と回答だけなのか、予約、変更、送信、承認まで行うのかでリスクが変わります。取り消し可能な操作と、取り消しにくい操作を分け、重要処理には確認画面や人の承認を入れます。
聞き間違いへの対策
音声では、氏名、金額、住所、製品番号などを誤認識する可能性があります。重要項目は復唱し、画面表示や別認証で確認する設計が必要です。
無音や割り込みの扱い
利用者が考えているだけなのか、通話が切れたのかを完全には判別できません。待機時間、聞き返し回数、終了条件を業務ごとに設定します。
有人対応への切り替え
AIが答えられないときだけでなく、感情的な問い合わせ、本人確認失敗、重要な契約変更など、初めから人へ渡す条件を決めます。
メリット
GPT-Live型の設計には、会話の自然さ以外にも利点があります。
- ツール処理中も会話を継続しやすい
- 音声経路と業務ロジックを独立して改善できる
- 高速モデルと高性能モデルを役割分担できる
- 長時間セッションを途中停止せずに管理しやすい
- 本番負荷をGPU以外も含めて評価できる
特に、モデルを1つ選べば完成するという考え方から、会話、推論、ツール、状態管理を組み合わせるシステム設計へ視点を移せる点が重要です。
デメリットと注意点
一方で、構成は複雑になります。音声モデルと推論モデルの状態を同期し、暫定的な会話履歴と確定ログを管理し、複数リージョンへ容量を配置する必要があります。
非同期処理を増やすと、会話上は処理中なのにバックエンドでは失敗している状態も発生します。利用者へ何を案内したか、実際の処理がどこまで進んだかを追跡できる仕組みが必要です。
また、低遅延を優先しすぎると、確認不足の回答や操作につながる可能性があります。会話速度と業務の正確性は別の指標です。金銭、契約、権限変更などでは、多少遅くても確認を優先すべき場面があります。
音声AIでは周囲の雑音、通信品質、端末性能、方言、固有名詞によって精度が変わります。デモ環境で自然に動いても、実際の職場や移動中に同じ品質が出るとは限りません。
向いている業務と向いていない業務
音声AIは、手が塞がっている場面、短い確認を繰り返す業務、会話しながら情報を探す業務と相性があります。社内ヘルプデスク、設備点検支援、受付、予約案内、作業中のナビゲーションなどが候補になります。
一方、正確な数値や長い表を確認する業務、大量のコードや契約文を精読する業務、複数案を並べて比較する業務では、画面を使った方が適しています。すべてを音声へ置き換えるのではなく、音声と画面を組み合わせる設計が現実的です。
また、誤操作の影響が大きく、人による確認を省けない業務は、音声だけで完結させるべきではありません。AIが情報を集め、候補を整理し、最終確定は画面と人の操作で行う分担が安全です。
小さく試すなら何から始めるか
音声AIを試す場合、最初から基幹システムを操作させる必要はありません。まず、回答のみで完結し、誤りが起きても修正しやすい用途を選びます。
- 対象業務を1つに限定する
- 音声AIが答えてよい範囲を決める
- 重要項目の復唱ルールを作る
- 応答時間だけでなく割り込み率や聞き返し率を測る
- 有人対応へ切り替える条件を決める
- 実利用時間に近い長時間テストを行う
評価指標には、回答正確性、最初の音声が返るまでの時間、会話終了までの時間、ユーザーを遮った回数、聞き返した回数、ツール実行の成功率を含めます。音声が自然だったという感想だけでは、本番導入の判断材料として不足します。
まとめ
GPT-Liveは、音声モデルが聞くことと話すことを同時に行い、深い推論やツール利用を別経路へ非同期で委譲するリアルタイム音声システムです。
OpenAIの技術解説からは、低遅延を実現するにはモデルだけでなく、専用のメディア経路、WebRTC、状態の引き継ぎ、コンテキスト圧縮、接続開始プロトコル、本番トラフィックによる検証が必要だと分かります。
SE実務で特に参考になるのは、重要経路を小さく保つこと、遅い業務処理を非同期化すること、平均ではなく遅延分布を見ること、途中結果と確定データを分けることです。
今後GPT-Live APIが提供されたとしても、APIを接続するだけで安全な業務システムが完成するわけではありません。音声データの扱い、実行権限、確認方法、有人切り替え、長時間セッションの運用を先に設計する必要があります。
参考情報
本記事の情報は2026年8月4日時点で確認した公式発表に基づきます。今後提供されるAPIの仕様、料金、利用条件は変更または追加される可能性があります。
コメント