リアルタイム音声-音声モデルは、VAD→STT→LLM→TTSパイプラインを置き換える準備ができているのか？

2025年9月4日

コンテキストウィンドウが拡大し、モデルがユーザーの意図をより正確に読み取れるようになるにつれ、ユーザーは「バイブ・インタラクション（vibe interaction）」へと移行しつつあります。 つまり、あれこれ細かく指示を出すのではなく、背景や目的をざっと伝えて、あとはモデルに「魔法」のようにやってもらうという使い方です。 そして実際、最初の応答でもすでに十分満足できることが増えてきました。 その成功体験がこの使い方をさらに強化し、結果として「思考過程を細かく制御するような複雑なオーケストレーション」は、もはや不要どころか、モデルの推論を誤った方向に誘導してしまう危険さえあります。

同様に、長時間対話型のユースケース（例：エンタメ・セラピー・教育など）では、「正確な答え」ではなく、「会話が続くこと」が成功とされます。 そうした領域では、従来の 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は、会話の流れ全体をLLMに任せる設計をむしろ推奨しているのです。

OpenAIのRealtime APIドキュメントでは、このようなアプローチを冗談めかして 「プロンプトを書いて、あとは神頼み」と呼んでいる

OpenAI realtime manual stages

しかし、ゲームの物理エンジンと同じように、LLM単体では長いインタラクションの流れを完璧に扱うことはできません。物理エンジンに過度に依存した結果、かつてのゲームでは壁をすり抜ける（tunneling）、瓦礫がドアを塞いで進行不能になる（soft lock）といったおなじみの「バグ」が生まれました。 そして、LLMの純粋な会話制御にもそれに似た現象があります。たとえば——話の脱線（derailment）, ループ, プロンプトの脆弱性...

こうした問題を防ぐために、ゲーム開発の知恵を拝借します。つまり、LLMの「物理層（physics）」の上に、監督・制御のための「スーパービジョンレイヤー（supervision layer）」を重ねるのです。

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 （モデル以外すべて）

まとめると、もしスーパービジョン（監督・制御）が、出力音声の生成が始まる前に入力や出力のテキストを厳密に介入・処理することを必要とする場合、現時点のリアルタイムモデルは最適とは言えません。
今後の投稿では、こうした制約を回避するためのいくつかの典型的なパターンとそのワークアラウンド（解決策）を紹介していく予定です。