2026-10-06 発行（読了 7 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
音声エージェントの設計論争は長く「STT→LLM→TTS のカスケード構成」か「音声を音声のまま扱う speech-to-speech（S2S）」かの二択で語られてきた。カスケードは制御しやすく監査しやすいが遅い。S2S は速く自然だが、ツール呼び出しや推論の深さで劣る。9月にこの構図が動いた。OpenAI は 9月10日に全二重音声モデル GPT-Live-1 を API 公開し、推論とツール実行を裏側のテキストモデルへ委譲する二層構成を前面に出した。Google は 9月15日の Gemini 3.8 Live で非同期関数呼び出しを既定にし、同時期の論文も同じ分割を提案している。一方カスケード陣営は、ターン検出を独立モデルとして切り出す方向で応答品質を詰めている。
GPT-Live-1 は「聞きながら話す」全二重モデルで、間・割り込み・相槌（バックチャネル）の処理を担う。検索や深い推論、ツール呼び出しが必要になると、別系統の非同期パスで裏側のテキストモデルやエージェントに処理を委譲し、その間も音声層はユーザーとの会話を続ける。エンドポイントは専用の v1/live/sessions のみで、料金は音声層が 1 分 0.05 ドル（秒課金）、裏側のモデル利用とツール実行は別課金だ。OpenAI の告知は、委譲先に自前の既存サービスを接続でき、権限とタスク状態を音声層とは独立に管理できる点、ユーザーが割り込んでも進行中の裏側の処理が自動でキャンセルされない点を明記している。9月16日に arXiv へ投稿された論文も同じ構造を提案しており、全二重の音声フロントエンドが「委譲トークン」を出力すると、ストリーミング ASR の書き起こしがテキストのバックエンド LLM に転送される。
この分割に各社が行き着いたのは、S2S モデル単体に会話の自然さと推論の深さを両立させるのが難しかったからだ。音声を直接生成するモデルは応答が速いぶん、複雑な判断やツールの正確な引数組み立てではテキストモデルに及ばない。逆にテキストモデルに会話のテンポを任せると、ターンごとに考え込む「間」が生じる。論文が「通常の全二重のターンテイキング・割り込み処理・低遅延をほぼ保ったまま、フロントエンドへの変更を最小限に抑えられる」と主張しているように、二層化は両者の弱点を役割分担で回避する設計であり、「カスケードか S2S か」ではなく「S2S を前段、テキストを後段に置くハイブリッド」が実質的な第三の選択肢になった。
Google は 9月15日、Live API 向けに音声→音声モデル Gemini 3.8 Live と Gemini 3.8 Live Extended Thinking を GA にした。標準版はリリースノートで「推論の遅延がない低遅延な音声エージェント向けの既定の選択肢」とされ、インターリーブ推論と非同期関数呼び出しを既定で備える。従来の同期（ブロッキング）呼び出しは後方互換のためにだけ残っている。Extended Thinking 版は、ライブ音声の対話中に裏で推論を回す「バックグラウンド推論」に対応した高推論モデルで、深い推論が必要なときに使うよう案内されている。
同期呼び出しでは、ツールの応答が返るまでモデルが音声を生成できず、ユーザーは数秒の無音を待たされる。テキストのチャットなら許容される待ち時間も、電話の向こうでは「切れたのか」と思われる長さになる。OpenAI が委譲を非同期パスに分けたのも、Google が非同期呼び出しを既定にしたのも、音声 UI では待ち時間を短くするより「待ち時間中に会話を続ける」設計のほうが効くという同じ判断に基づく。速い標準版と推論の深い版を別モデルとして並べた Google の構成も、一つのモデルに速さと深さの両方を求めない点で OpenAI の二層化と考え方が近い。
カスケード構成の体感品質を最も左右するのは、ユーザーが話し終えたかどうかを判定するターン検出（エンドポインティング）だ。無音の長さだけで判定すると、言いよどみで話を遮るか、逆に応答が遅れる。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 側が「会話の進行」を音声モデルに集約したのとは逆に、カスケード側は同じ機能を専用モデルに切り出しており、二つの陣営は異なる方法で同じ課題に取り組んでいる。