リアルタイム音声-音声モデルは、VAD→STT→LLM→TTSパイプラインを置き換える準備ができているのか？
2025年9月4日
コンテキストウィンドウが大きくなり、モデルが意図を読み取る能力が向上するにつれ、ユーザーはバイブインタラクションへとシフトしています：コンテキストを積み上げ、タスクを説明し、モデルに魔法を委ねる。最初のレスポンスが機能することが増えており、これがそのパターンを強化しています。このような世界では、重い思考の連鎖オーケストレーションでモデルを導くことは、しばしば不要であり、あなた自身の間違った仮定に向けて推論を偏らせる可能性があるため、有害でさえあります。
同様に、長時間のインタラクション用途（エンターテイメント、セラピー、教育）において、成功が持続的なエンゲージメントと等しい場合、VAD → STT → LLM → TTSの厳格なオーケストレーションの時代は終わりに近づいています。人間はタイミング、トーン、非言語的手がかりを使って発話順序を調整します。これらの信号で訓練されたリアルタイム音声-音声モデルは、Pipecatのような低遅延のものであっても、ウォーターフォールパイプラインよりも自然にターンテイキングを処理できるはずです。
しかし、注意点があります：ゲームの物理エンジンと同様に、まだガードレールとフロー制御が必要です。
リアルタイム音声-音声LLMとゲーム物理エンジン
8ビット時代では、オブジェクト間のインタラクションをすべてスクリプトで記述できました：
if (ball.position.y near floor) reverse ball.velocity.y
同様に、ルールベースの対話システムは次のように言うかもしれません：
if (user greets) reply with a greeting.
リアリズムが高まると、すべてのインタラクションを手作業で作成するのが扱いにくくなりました。ゲーム開発者は、マリオカートのぶつかり合いや、ノーマン・リーダスのサムが深い雪に鮮明な足跡を残すことなど、何百万もの微細なインタラクションを正しく見せる物理レイヤーを導入しました。同様に、LLMは今や会話の重労働を行います。新しいリアルタイムAPIは、談話の流れ全体を彼らに委ねることさえ推奨しています。
OpenAI Realtime APIドキュメントからの「プロンプトして指をくわえて待つ」スタイルの対話管理
しかし、ゲーム物理エンジンと同様に、LLMだけでは長いインタラクションフローを処理できません。物理エンジンへの過度の依存は、壁を通り抜けたり、残骸がドアをソフトロックするような典型的なグリッチを生み出しました。純粋なLLMフローには類似点があります：脱線、ループ、脆弱なプロンプト。
そこで、ゲームのプレイブックを借用します：LLMの「物理」の上に監督レイヤーを追加するのです。
2つのタイプの監督
1. リアクティブ（番犬）
ゲームにおいて
キルプレーン（世界境界）＆タイムアウト
会話AIにおいて
対話がN秒/ターン漂流した場合 → 強制的で短い明確化でスナップバック。
ゲームにおいて
フロー中断
会話AIにおいて
ユーザーSTT転写とLLM出力ストリームの両方を、厳しい要件と決定論的ハンドリング（特定のトピックやフレーズ）について監視。トリガー時 → LLM/TTSをカットし、適切な出力を注入。
2. プロアクティブ（ガードレール）
ゲームにおいて
カットシーン挿入
会話AIにおいて
- ハンドオフ、開示、機密性の高い移行のための短い事前作成音声ビート（決定論的な表現、韻律）。
- 密接な質問応答インタラクションのための閉ループ質問
- 以下のような正確な条件のためのユーザー転写の前処理：
ユーザーが参照フレーズの単語の80%を正しく発音した。
ゲームにおいて
シーン移行
会話AIにおいて
長期および/または短期コンテキスト条件が満たされた時の決定論的フロー移行。
Death Stranding 2でリュックサックを掴むカットシーンの例
類推をまとめると：
| ゲーム | 会話AI | |
|---|---|---|
| 時間単位 | アニメーションフレーム | 会話ターン |
| シンプル/初期 | すべてのアニメーションフレームに適用されるルールベース物理 | VAD-STT-LLM-TTSループへの介入によるターンバイターン制御 |
| 複雑/現代 | ガードレールと外部ロジックを持つ物理エンジン | ガードレールと外部ロジックを持つリアルタイムLLM |
| リアクティブ監督（番犬） | キルプレーン、タイムアウト | 対話ドリフト/ループ分類器、トピックリセット、フロー中断 |
| プロアクティブ監督（レール） | 限定的インタラクティビティを持つカットシーンアニメーションシーケンス シーン移行 | 事前録音出力、閉ループ質問 フロー移行 |
今日のリアルタイムAPIが提供するもの（提供しないもの）
| OpenAI realtime | Gemini Live | |
|---|---|---|
| モデルレスポンス前のユーザー転写の割り込み |
セッション設定で有効化： "input_audio_transcription": { "model": "whisper-1" }
注：転写はレスポンス作成と非同期で実行されるため、このイベントはレスポンスイベントの前後どちらでも来る可能性があります。リアルタイムAPIモデルは音声をネイティブに受け入れ、したがって入力転写はwhisper-1などの別の音声認識モデルで実行される別のプロセスです。したがって、転写はモデルの解釈からある程度乖離する可能性があり、大まかなガイドとして扱うべきです。（Microsoft doc） |
BidiGenerateContentコールのResponseメッセージの一部として受信： serverContent.inputTranscription
注：転写は他のサーバーメッセージとは独立して送信され、順序の保証はありません。（Google doc） |
| モデル音声レスポンス前のモデル出力転写の割り込み |
Response.text.delta
Response.audio_transcript.delta
注：タイミングが不明確。 |
server_content.output_transcription
注：転写はモデルターンから独立しており、転写とモデルターンの間の順序付けを意味しません。（Google doc） |
| オンザフライコンテキスト更新 | Session.update （ボイス以外すべて） | generationConfig （モデル以外すべて） |
要約すると、監督が出力音声生成の開始前に入力または出力転写の厳密な割り込みを必要とする場合、リアルタイムモデルは適していない可能性があります。今後の投稿では、いくつかの典型的なパターンに対する回避策を提案する予定です。