GPT-Live-1 は「聞きながら話す」全二重モデルで、間・割り込み・相槌（バックチャネル）の処理を担う。検索や深い推論、ツール呼び出しが必要になると、別系統の非同期パスで裏側のテキストモデルやエージェントに処理を委譲し、その間も音声層はユーザーとの会話を続ける。エンドポイントは専用の v1/live/sessions のみで、料金は音声層が 1 分 0.05 ドル（秒課金）、裏側のモデル利用とツール実行は別課金だ。OpenAI の告知は、委譲先に自前の既存サービスを接続でき、権限とタスク状態を音声層とは独立に管理できる点、ユーザーが割り込んでも進行中の裏側の処理が自動でキャンセルされない点を明記している。9月16日に arXiv へ投稿された論文も同じ構造を提案しており、全二重の音声フロントエンドが「委譲トークン」を出力すると、ストリーミング ASR の書き起こしがテキストのバックエンド LLM に転送される。
この分割に各社が行き着いたのは、S2S モデル単体に会話の自然さと推論の深さを両立させるのが難しかったからだ。音声を直接生成するモデルは応答が速いぶん、複雑な判断やツールの正確な引数組み立てではテキストモデルに及ばない。逆にテキストモデルに会話のテンポを任せると、ターンごとに考え込む「間」が生じる。論文が「通常の全二重のターンテイキング・割り込み処理・低遅延をほぼ保ったまま、フロントエンドへの変更を最小限に抑えられる」と主張しているように、二層化は両者の弱点を役割分担で回避する設計であり、「カスケードか S2S か」ではなく「S2S を前段、テキストを後段に置くハイブリッド」が実質的な第三の選択肢になった。
", "examples": [ { "product": "OpenAI GPT-Live-1（Live API）", "approach": "全二重の音声層が会話を担い、推論・ツール実行は裏側のテキストモデルや自前エージェントへ非同期に委譲する", "detail": "音声層（1 分 0.05 ドル）と裏側のモデル利用を別課金にしている点に、「話す層」と「考える層」を別部品として扱う設計思想がそのまま表れている", "source_url": "https://community.openai.com/t/introducing-gpt-live-1-in-the-api/1396471" }, { "product": "全二重音声モデルのツール呼び出し向けフロントエンド／バックエンド構成（arXiv 2609.19334）", "approach": "音声フロントエンドが委譲トークンを出すと、ストリーミング ASR の書き起こしをテキストのバックエンド LLM に渡してツールを実行させる", "detail": "単発ターンのツール呼び出しで 92〜97% の再現率、ツール呼び出しの拒否判定で 81.2% の精度を報告しており、二層化が研究側でも検証可能な形で提案された例", "source_url": "https://arxiv.org/abs/2609.19334" } ], "takeaway": "音声エージェントに業務ツールを持たせるなら、音声モデルにすべてを任せず、ツール実行と権限管理は既存のテキストエージェント側に残して音声層は会話の進行に絞る。こうしておけば、音声モデルを差し替えても業務ロジックに手を入れずに済む。" }, { "heading": "「ツール実行中も黙らない」が音声直結モデルの既定動作になった", "body_html": "Google は 9月15日、Live API 向けに音声→音声モデル Gemini 3.8 Live と Gemini 3.8 Live Extended Thinking を GA にした。標準版はリリースノートで「推論の遅延がない低遅延な音声エージェント向けの既定の選択肢」とされ、インターリーブ推論と非同期関数呼び出しを既定で備える。従来の同期（ブロッキング）呼び出しは後方互換のためにだけ残っている。Extended Thinking 版は、ライブ音声の対話中に裏で推論を回す「バックグラウンド推論」に対応した高推論モデルで、深い推論が必要なときに使うよう案内されている。
同期呼び出しでは、ツールの応答が返るまでモデルが音声を生成できず、ユーザーは数秒の無音を待たされる。テキストのチャットなら許容される待ち時間も、電話の向こうでは「切れたのか」と思われる長さになる。OpenAI が委譲を非同期パスに分けたのも、Google が非同期呼び出しを既定にしたのも、音声 UI では待ち時間を短くするより「待ち時間中に会話を続ける」設計のほうが効くという同じ判断に基づく。速い標準版と推論の深い版を別モデルとして並べた Google の構成も、一つのモデルに速さと深さの両方を求めない点で OpenAI の二層化と考え方が近い。
", "examples": [ { "product": "Google Gemini 3.8 Live（Gemini API Live API）", "approach": "非同期関数呼び出しを既定にし、同期（ブロッキング）モードは後方互換のためだけに残す", "detail": "前世代からの移行ガイドで既定値そのものを非同期に切り替えた。ツール実行中も音声を止めない挙動を、オプションではなく標準として位置づけた点が象徴的", "source_url": "https://ai.google.dev/gemini-api/docs/models/gemini-3.8-live" } ], "takeaway": "音声エージェントのツールは「数秒かかる前提」で設計し、呼び出しは非同期にして、実行中に話す内容（進捗の伝達や確認の質問）を会話設計に組み込んでおく。同期呼び出しのまま応答を速くする最適化は、効果のわりに手間がかかる。" }, { "heading": "カスケード構成はターン検出を独立モデルとして切り出した", "body_html": "カスケード構成の体感品質を最も左右するのは、ユーザーが話し終えたかどうかを判定するターン検出（エンドポインティング）だ。無音の長さだけで判定すると、言いよどみで話を遮るか、逆に応答が遅れる。LiveKit が 6月に公開した Turn Detector v1.0 は、書き起こしの意味（文として完結しているか）と音響的な手がかり（ピッチやイントネーション）を一つの予測に統合する。判定まで 300ms の設定で誤カットオフ率は 9.9%（比較対象は 12.9%）、600ms では 4.5% で、14 言語に対応する。6月30日の設定ガイドでは、相槌と本当の割り込みを音響的に区別する adaptive モードや、誤検知した割り込みのあとに発話を再開する resume_false_interruption などの調整項目を解説している。Sierra も、ノイズや複数話者の環境向けに調整した独自の発話区間検出（VAD）モデルを入れ、反応の遅れを数百ミリ秒縮めたと公表している。
LiveKit がこの判定を STT サービスの付属機能ではなくフレームワーク側の機能に置いた理由として挙げるのは、STT・LLM・TTS のどのベンダーを組み合わせてもターンテイキングの挙動を一定に保つためだ。カスケードの利点は部品を差し替えられる点にあるが、ターン検出を STT ベンダーに任せると、STT を替えるたびに会話の間合いまで変わってしまう。会話品質を決める判定を独立した部品として持つことで、差し替えやすさと品質の安定を両立させている。S2S 側が「会話の進行」を音声モデルに集約したのとは逆に、カスケード側は同じ機能を専用モデルに切り出しており、二つの陣営は異なる方法で同じ課題に取り組んでいる。
", "examples": [ { "product": "LiveKit Turn Detector v1.0（LiveKit Agents）", "approach": "意味と音響の手がかりを統合したターン検出モデルを、STT から独立したフレームワーク側の部品として提供する", "detail": "フル版は LiveKit Cloud 上で無料、CPU で動く軽量版 v1-mini はオープンウェイトで SDK に同梱されており、どの STT と組み合わせても同じ判定ロジックを使える", "source_url": "https://livekit.com/blog/solving-end-of-turn-detection" }, { "product": "Sierra（顧客対応音声エージェント）", "approach": "発話終了検出・推論・音声合成の 3 区間ごとに遅延を削り、指標は「話し終えてから最初の音声が出るまで」の Time to First Audio に統一する", "detail": "独自の VAD モデルに加え、独立した処理の並列実行、複数プロバイダーへの同時リクエスト（ヘッジング）、定型句の音声キャッシュを組み合わせている。カスケードで遅延を詰める手法を一通り公開している数少ない例", "source_url": "https://sierra.ai/blog/voice-latency" } ], "takeaway": "カスケードで組むなら、ターン検出を STT の付属機能に任せず独立した部品として選び、誤カットオフ率と判定遅延のトレードオフを自社の通話データで測ってから閾値を決める。体感品質の差は LLM の選定よりここで大きく開く。" } ] }, "editorial": "音声エージェントの論点は「どのアーキテクチャを選ぶか」から「会話の進行をどこに置くか」に変わった。S2S 陣営は進行を音声モデルに任せて推論を裏へ逃がし、カスケード陣営は進行の判定を専用モデルに切り出した。どちらの陣営も、速さと賢さを一つの部品に背負わせない、という同じ結論に達している。", "quick_picks": [ { "title": "ChatGPT Voice がメール・カレンダー・Slack のプラグインと ChatGPT Work に対応", "summary": "OpenAI は 9月23日、ChatGPT Voice からプラグインを使い、GPT-6 系モデルを裏側に据えて ChatGPT Work のタスクまで音声で実行できるようにした。音声層が会話を担い、実作業は裏側のモデルとツールが担うという、本号で扱った二層構成を自社のコンシューマー製品に適用した例だ。", "url": "https://x.com/OpenAI/status/2102808325742322002" }, { "title": "LiveKit Agents のターン検出と割り込み処理の設定ガイド", "summary": "ターン検出の 5 方式（音響＋意味モデル、STT 任せ、Realtime LLM 任せ、VAD のみ、手動）と、割り込み判定の調整項目を整理した公式ガイド。カスケードと音声直結モデルのどちらにターン判定を任せるかを、同じフレームワーク内で切り替えられる設計になっている。", "url": "https://livekit.com/blog/turn-detection-and-interruption-handling" }, { "title": "Sierra の Voice Sims — 模擬通話で音声エージェントを回帰テストする", "summary": "目的・気分・言語・忍耐度を設定した模擬顧客に背景ノイズや割り込みを加え、同じ通話を何度でも再現して LLM 評価器で採点する仕組み。テキストの書き起こしだけでは見えない間合いや割り込み対応を評価対象にしており、本号で扱ったターン検出の品質を検証する手段にあたる。", "url": "https://sierra.ai/blog/how-voice-sims-work" } ] }