OpenClawにおけるリアルタイム会話：実際のエージェントに相談できる割り込み可能な音声

エージェントに声を与えるために音声認識とTTSを配線しているなら、それは根本的に間違った道かもしれません。これはr/openclawの投稿からの結論で、ある開発者が音声認識＋TTSパイプラインに「時間とトークン」を浪費したものの、結果はChatGPTやGeminiアプリのライブ音声体験に「はるかに及ばない」ものだったと述べています。

投稿によると、解決策はRealtime Talk — 具体的には設定キー.talk.realtime.providerです。

Realtime Talkが実際にやること

重要なアーキテクチャ上の違いは、Realtime Talkがエージェントに後付けされた文字起こしレイヤーではないことです。音声会話はOpenClawエージェントを参照し、エージェントの完全なコンテキストとツールを組み込んだ、選択したLLMを通じて処理されます。つまり、基盤モデルの推論能力を失わずに、ライブ音声の挙動（割り込み処理、スタイルやペースの指示）が得られます。

著者がChatGPT/Geminiスタイルの体験から明示的に挙げている機能：

• 文の途中で音声を割り込ませる
• 特定のスタイルで応答するよう指示する（例：「ドラキュラのように話して」）
• もっとゆっくり、または速く話すよう頼む
• 応答は依然としてエージェントと好みのLLMから来ており、音声専用のダウングレードモードではない

著者の評価：音声フロントエンドが応答品質から分離されているため、OpenAIやGoogleが自社アプリで提供するものより優れている。

設定で迷子にならないこと

新規参入者への著者の警告は率直です — そこら中に、エージェントを間違った方向に導く、隣接的・時代遅れ・誤った道の資料が溢れています。投稿によれば、以下は無視すべきです：

• STT/TTSのセットアップ
• voice-callとラベルされたものすべて
• ClawHubプラグイン
• 数ヶ月前のYouTubeチュートリアル

設定すべきは.talk.realtime.providerの一つだけです。それがリアルタイムの道であり、別々の音声コンポーネントから組み立てるパイプラインではありません。

なぜ重要なのか

有能な音声ループを自分で構築するには、エージェントが考える前にVAD、エンドポインティング、バージイン、レイテンシ予算を解決する必要があります。Realtime Talkは、会話の仕組みをすでに処理するプロバイダーに音声をルーティングすることでこれを回避しつつ、OpenClawエージェントは記憶とツールをループに保ちます。エージェントのコンテキストにすでに投資し、音声のおもちゃではなく音声インターフェースを求めている開発者にとって、これはデモと実用の違いです。

STT/TTSの道を追いかけてきたなら、ここでの推奨は、リアルタイム体験のはるか下で頭打ちになるパイプラインにこれ以上トークンを費やす前に、立ち止まってRealtime Talkに切り替えることです。