ウェビナー振り返り：テキストチャットボットに人間らしい声を加える方法

チャットエージェントは、企業向けソフトウェアスタックの標準的な一部になっています。ほとんどの企業が導入済み、または構築中です。しかし、ユーザーがテキストではなく話したいと感じたときにどうするかを解決できている企業は、まだ多くありません。

音声は、利便性を超えて重要な形でインタラクションを変えます。ユーザーは、テキストでは完全に失われる口調を通じて、苛立ち、緊急性、混乱を表現します。「注文品が届いていません」と入力する顧客と、不安をにじませて同じことを口にする顧客は、異なるシグナルを発しています。文字起こししか読めないエージェントが扱えるのは、情報の半分にすぎません。

今、多くのチームが問うているのは、音声を追加するかどうかではありません。すでに機能しているものをすべて作り直さずに、どう追加するかです。

「ライブワークショップ：テキストチャットボットに人間らしい音声を与える」では、Paul Asjes（デベロッパーエクスペリエンス）、Bhargavi Bhatt（カスタマーエクスペリエンス）、Fergal Burnett（プロダクトマーケティング、ElevenAPI）が、既存のエージェントに音声を追加する際の技術的な実情と、実際に動作するインテグレーションの仕組みを解説しました。

音声での構築が見た目以上に難しい理由

主要な課題の一つがターンテイキングです。人間は、イントネーション、リズム、文脈から、相手が話し終えたタイミングを判断できます。しかし、音声アクティビティ検出（標準的なアプローチ）が検出できるのは、無音だけです。

その結果、すべての間を発話の合図として扱うシステムになりがちです。途中で割り込んだり、考えを言い終える前に遮ったり、自然なためらいを完結した文であるかのように処理したりします。

技術的には動作していても、会話としては破綻しています。

文脈も問題のもう半分です。各ターンで会話履歴をLLMに渡すことは必要ですが、それだけでは不十分です。同じ言葉でも、伝え方によって意味が異なります。安堵して「大丈夫です」と言う場合と、苛立って「大丈夫です」と言う場合は、文字起こしは同じでも、インタラクションは異なります。この側面を無視する音声システムは、個々のモデルがどれほど優れていても、どこか不自然に聞こえ続けます。

エンジニアリング上の負担もあります。独自の音声オーケストレーションを担うチームは、ターンテイキングロジック、割り込み処理、レイテンシープロファイリングを継続的に保守することになります。一度構築すれば終わりではありません。

既存のエージェントに音声を追加する方法

最もすっきりしたアプローチは、デュアルWebSocketアーキテクチャです。 

1. 1つの接続はクライアントとElevenLabs APIの間、もう1つはサーバーとElevenLabs APIの間で確立します
2. ユーザーがマイクに話しかけると、オーディオがElevenLabs APIに送信され、文字起こしされた後にサーバーへ送られます
3. サーバーはElevenLabs APIから取得した会話履歴全体をLLMに渡し、ストリーミング応答はオーディオ合成のために戻されます
4. これはLLMが生成を終える前に開始できるため、最初のバイトまでのレイテンシーを低く保てます 

主要なインテグレーションポイントはonTranscript メソッドです。各ターンの終了時に実行され、会話履歴全体をLLMに渡します。 

セッション開始時のcontextualUpdate により、ユーザーが音声に切り替える前のテキスト会話で起きたことを引き継げます。これにより、1つのエージェントが文脈を失わずに両方のモダリティで動作できます。

構築時に押さえておきたいポイント：

1. 音声では、チャット以上にLLMの選択が重要です。 ディープリースニングモデルは、応答品質が高くても、オーディオでは不自然なためらいに聞こえる間を生じさせます。リアルタイム音声では、知覚される品質の面で、ほぼ常に高速なモデルが優位です。
2. オーディオにはWebSocketではなくWebRTCを使いましょう。 WebRTCにはエコーキャンセルとノイズキャンセルが組み込まれており、モバイルや騒がしい環境では特に重要です。オーディオ転送にWebSocketを使う場合は、これらを自分で処理する必要があります。
3. ユーザーに言語を選ばせないでください。 会話の流れが途切れます。発話の最初の数秒で言語を検出して固定するほうがよく、ユーザーが何もしなくてもスムーズに切り替えられます。
4. ターンテイキングモデルはLLMと分けてください。 ユーザーが話し終えたかどうかをLLMに判断させると、ターンごとにレイテンシーとコストが増加します。専用のターンテイキングモデルなら、より高速かつ正確に処理できるため、アーキテクチャ上の独立したコンポーネントとして扱う価値があります。

どこまでインフラを自社で持つべきか

最適な答えは、すでに何があるかによって異なります。すでに動作するチャットエージェントがあるなら、LLM、オーケストレーション、ビジネスロジックをそのままに音声レイヤーを追加するのが、通常は最も速く、リスクも最小の方法です。 

何かを作り直す必要はありません。すでに機能しているものに、オーディオインターフェースを追加するだけです。

電話機能、デプロイチャネル管理、組み込みテスト、分析まで要件が広がるなら、スタックのより多くを音声エージェントプラットフォームに任せるのが合理的です。この2つのアプローチは相反するものではありません。軽量な音声レイヤーから始め、ユースケースの成熟に合わせてプラットフォーム機能を追加していけます。

デモ：既存のチャットボットに音声を追加する

このデモでは、テキストベースの旅行計画チャットボットとの会話の途中で、日本旅行に向けた地域やグルメのおすすめを尋ねるユーザーを取り上げます。

取り上げた内容：

• 基盤となるエージェントを一切変更せずに、チャットボットを音声レイヤーで拡張しました。
• ユーザーは会話の途中で入力から発話に切り替えましたが、エージェントは両方のモダリティで完全な文脈を維持しました。
• ユーザーはオランダ語で話し、エージェントは言語の切り替わりを自動的に検出しました
• エージェントの発話中に割り込まれ、文の途中で英語に戻すよう求められると、その通りに切り替え、指示されなくてもわずかにオランダ語訛りで応答を終えました。
• 会話全体を通じて、割り込み検出により、エージェントが自分のターンを終えるのを待たずに、ユーザーは自然に発話を重ねられました。

重要な理由： 

このデモで示したのは、専用に構築された音声エージェントではありません。すでに動作しているテキストエージェントに、音声レイヤーを追加したものでした。文脈処理、言語検出、割り込み時の動作はすべて音声レイヤーが担い、基盤となるテキストエージェントは変更していません。 

フルセッションを視聴

ウェビナー全編はこちらからご覧ください。