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

チャットエージェントは、エンタープライズソフトウェアの標準的な構成要素になっています。多くの企業がすでに導入しているか、構築中です。一方で、ユーザーがテキストではなく話したい場合にどうするかを解決できている企業は、まだ多くありません。

音声は、単なる利便性を超えて対話を変えます。苛立ち、緊急性、混乱といった感情は、テキストでは完全に失われる声のトーンによって伝わります。「注文した商品がまだ届かない」と入力する顧客と、不安を声ににじませながら同じことを言う顧客では、発しているシグナルが異なります。文字起こししか読めないエージェントは、情報の半分しか扱えていません。

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

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

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

中核となる課題の一つが、発話のターン管理です。人間はイントネーション、リズム、文脈から相手が話し終えたタイミングを判断します。一方、音声アクティビティ検出（標準的な手法）は、無音状態しか検出しません。

その結果、あらゆる間を話し始める合図として扱うシステムになりがちです。話を遮ったり、考えの途中で打ち切ったり、自然なためらいを文が終わったものとして応答したりします。

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

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

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

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

最もシンプルな方法は、2本のWebSocketを使うアーキテクチャです。 

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

統合の重要なポイントは、onTranscript メソッドです。各ターンの終わりに呼び出され、会話履歴全体をLLMに渡します。 

セッション開始時のcontextualUpdate では、ユーザーが音声に切り替える前のテキスト会話で起きた内容を引き継げます。これにより、文脈を失うことなく、単一のエージェントが両方のモダリティで機能します。

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

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

どこまでインフラを自前で管理するか

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

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

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

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

このデモでは、日本旅行のエリアや食事のおすすめを、テキストベースの旅行計画チャットボットに尋ねている会話の途中のユーザーを例に紹介します。

紹介した内容：

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

重要な理由： 

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

フルセッションを見る

ウェビナー全編はこちら。