近頃は、リアルタイムでのブログ執筆が求められるようになってきました。数日でも温めていると、その内容がすぐに古くなってしまう時代です。 前回の記事では、音声インターフェースの使い勝手を妨げる要因——たとえば「割り込み」や「遅延」といった問題——について触れました。 それから2週間も経たないうちに、OpenAIがまさにそれらの課題を解決する「Realtime API」を発表しました。 ここでは、これに対する私の所見をまとめたいと思います。

「発話の終わり」の終わりの始まり

会話AIに関わる多くの人が、今回の「Realtime API」のリリースを前に、私と同じように頭を整理しようとしているのではないでしょうか。 これまで音声対話システムの最大の障害となっていたのは、「柔軟性のないターンテイキング（発話のやり取り）」でした。 そんな中で、リアルタイム音声入出力API（いわゆるフルデュプレックス通信、つまり同時認識・同時生成）がプロダクションレベルで登場したというのは、業界を揺るがす衝撃的な出来事と言えます。

さて、Realtime APIが会話AIの設計にもたらす影響について、いくつかの考察を挙げてみます。

1. 外部での意思決定処理（たとえば、ユーザー入力をLLMに渡す前にプロンプトを文脈に応じて更新するような処理）は、リアルタイム応答に比べて大きな遅延を生む。
   → 今後はこれは「アンチパターン」になる可能性が高い。
2. 「考える前に話す（talk before thinking）」ハイブリッド構成
   → 即時応答はLLMに任せ、必要なタイミングでのみ外部制御を取り戻す（例：LLMが関数呼び出しを行うときなど）。

つまりRealtime APIは、会話の時間的な流れを司る主体をLLMそのものに引き上げる一方で、 外部のルーターは必要に応じて非同期・ノンブロッキングで関数呼び出し結果やプロンプト更新を挿入することで、 会話の方向性を調整する役割へとシフトすることになります。

それでも自前でターン制御したい人は、Realtime APIで、クライアント側で独自の音声活動検出（VAD: Voice Activity Detection）を組み込むことも可能です。 これは、従来のモジュール設計思想への「敬意」とも言えますが、結果として遅延が増加するため、これもまた将来的にはアンチパターン化していく可能性があります。