ElevenLabs Agentsの音声オーケストレーションと外部エージェントの統合

最先端のエージェントオーケストレーターは、複雑なタスクを処理し、企業向けツール群全体で稼働できるようになっています。そのため、アプリケーション、会話、システムの状態を綿密に管理する必要があります。音声以外のモダリティでは、コンテキストエンジニアリング、という包括的な概念のもと、エージェントのシステムプロンプトを、対話の進行に合わせて一貫して運用するための一般的なパターンが生まれています。音声を導入すると、音声対話の各コンポーネントを管理するための状態レイヤーが追加されるだけでなく、理想的には他のモダリティでのこれまでの作業成果も再利用できます。 

この記事では、ElevenLabs Agentsが外部エージェントをどのようにサポートし、そのインテグレーションをきめ細かく制御するためのパターンを紹介します。これらの仕組みにより、より広範なオーケストレーションの完全な所有権を維持しながら、ElevenLabsの業界最高水準の音声オーケストレーションを活用できます。

主要コンポーネント

ElevenLabs Agents

最もシンプルな形では、ElevenLabs AgentにはWebSocketクライアントを通じてアクセスできます。会話内のサーバーイベントとクライアントイベントを表す情報は、JSONオブジェクトとしてエージェントとの間で送受信されます。エージェントはユーザーの発話を文字起こしすると、直ちに生成リクエストをトリガーします。主要なモデルプロバイダーのほとんどをサポートしており、独自のCustom LLMも利用できます。Custom LLMの背後で、より複雑なオーケストレーター（エージェント）を使用して生成リクエストに応答する場合、OpenAIのChat Completions APIまたはResponses APIのいずれかをサポートしていることを確認する必要があります。幸い、このAPIフォーマット仕様は、主要なエージェント構築フレームワーク（CrewAI、LangChain、LangGraph、HayStack、LlamaIndexなど）のほとんどで容易にサポートされています。 

統合後、これらのエージェントは、背後にある音声オーケストレーターにかかわらず、いつでも内部および外部の状態を読み取り、更新できる必要があることがよくあります。これを効果的に管理することで、既存のテキスト専用エージェントとの一貫性を確保できます。 

状態管理

エージェントが環境内を効率的に動くために追跡すべきデータは、定義上、タスクに大きく依存します。外部エージェントを利用するElevenLabs Agentsでは、いくつかの明確に定義されたカテゴリにわたって状態を維持すると便利です。

内部状態は会話の動きを管理します。エージェントの内部状態の一部として追跡される要素には、次のようなものがあります。

• 音声アクティビティ、割り込み、現在の発話者の識別を含む、現在の会話フロー。
• 検出された意図、エンティティ、感情など、リアルタイムの文字起こし分析から得られるアプリケーション固有のインサイト。
• 中間的な思考、仮説、過去の解決策生成の試みを含む推論トレース。
• アクティブな目標、動作モード、対話中の振る舞いを導く一時的な制約など、設定および運用パラメータ。

一方、外部状態は主に、エージェントがやり取りする、または影響を与える関連システムや個人に焦点を当てます。エージェントの外部状態の一部として追跡される要素には、次のようなものがあります。

• 現在の目標、可用性、権限など、やり取りする他のユーザーやシステムの状態。
• API、データベース、インテグレーションなど、エージェントの行動能力に影響を与える可能性があるツールとナレッジベース。
• エージェントの次のステップに影響する、外部の関係者またはシステムが関わる進行中のタスクと依存関係。

ここでは、ユーザーとの関係におけるエージェントのライフサイクル全体で、この情報を確実に維持するための一般的なパターンを紹介します。

ソリューションのコンポーネント

概要 

このセクションでは、複雑な外部エージェントを適切に統合するために必要なアーキテクチャコンポーネントと実装の詳細を説明します。このアプローチの中核となるのは、セッションを表す任意かつ一意の識別子を、すべてのサービスにまたがってプロキシできることです。カスタムLLMを使用するElevenLabs Agentsでは、呼び出し開始時にextra bodyオブジェクト内のLLMパラメータとして必要な識別子を会話オーバーライドの一部として渡すだけで実現できます。これにより、識別子はユーザーからElevenLabs Agentを経由して外部エージェントへと渡されます。 

カスタムLLMの背後にあるステートフルプロキシに注目してください。通常は存在しないこのサービスにより、個々の生成リクエストを外部エージェントとの接続を表す任意の識別子にマッピングできます。このサービスの実装は、外部エージェントのデベロッパーが担います。最もシンプルな形では、プロキシはElevenLabsの会話または通話SID（電話の場合）にマッピングされる一意の識別子で表された接続を管理します。より高度なバージョンでは、複数の対話にまたがる、より複雑な顧客関係に会話をマッピングする際に階層構造を導入できます。

こうしたより高度な構成では、プロキシは単一のダウンストリームセッションに紐づく単一のリクエストを超えた追加の識別子を維持します。各識別子が1つの会話または通話SIDだけを表すのではなく、プロキシは1つの識別子に複数の関連する対話を関連付けられます。これにより、システムはチャネルをまたぐカスタマージャーニーを追跡し、履歴コンテキストを再利用し、複数の対話を同時に調整できます。たとえば、1つのマッピングで、複数のWebチャットセッション、フォローアップの音声通話、社内サポートワークフローを、同じ論理的な顧客識別子のもとにグループ化できます。プロキシは、カスタムLLMの背後で統一された状態を維持しつつ、シンプルなルールに基づいてリクエストを正しい識別子へルーティングできます。これにより、外部エージェントが管理する、より柔軟で持続的なマルチステップの対話が可能になります。

メッセージパッシング

生成リクエストを上位のエンティティに正しくマッピングするだけでなく、ステートフルプロキシはAPIリクエストを通じて、アプリケーションのフロントエンドや別のルーターサービスなどの外部ソースとの双方向メッセージパッシングもサポートできます。これが必要なアプリケーションでも、ElevenLabs Agentsはメッセージが他のサービスに渡されていることを認識する必要はありません。  

たとえば、外部エージェントが進行中の音声アクティビティを把握できると、ユーザーが発話しているか、どのくらい発話しているか、先回りして何らかの対応を取るべきかを判断できるため、役立つことがよくあります。こうしたインサイトは、ElevenLabs Agentsが提供する処理済みの音声活動検出（VAD）スコアを、クライアントイベントとして会話WebSocket経由で受け取り、渡すことで、直接取得して活用できます。ElevenLabsからスコアを受け取ると、クライアントアプリケーションは、アプリケーションの要件に応じて、任意のセッション識別子をメッセージに含めたうえでVADクライアントイベントをステートフルプロキシへ転送できます。ステートフルプロキシでは、セッションに対する既存の接続を最適に特定するリクエストマッピングロジックを実装する必要があります。 

このパターンは、JSONブロックとして表現できる限り、クライアントからのあらゆるイベントに拡張できます。ただし、エージェント自体に由来するイベントを公開することも有用です。一般的な例として、外部システムに対する操作を表すツール呼び出しやナレッジベースクエリのライフサイクルが挙げられます。これらの仕組みは、今日企業が構築しているエージェントの基盤です。

カスタムLLMを通じて外部エージェントを統合する場合、ElevenLabsのツール呼び出しと検索拡張生成（RAG）機能は、外部エージェント独自の実装が優先されるため、しばしば使用されません。その結果、これらのコンポーネントの所有権は完全に外部エージェントプロバイダーにあります。それでもアプリケーションはツールのアクティビティを可視化するメリットを得られます。エージェントの進捗を表示し、それに応じてエンドユーザー体験を更新できるためです。

この可視性を提供するため、外部エージェントはツールが呼び出されるたびに、リクエストとレスポンスの両方でメッセージを発行します。これらのメッセージはステートフルプロキシからクライアントアプリケーションへ転送され、専用のメッセージキューを通じて処理されます。これはElevenLabs Agentsのクライアントイベントで使用される仕組みを反映したもので、アプリケーションはエージェントが外部システムを読み取る、または変更するタイミングを追跡できます。

つまり、これらの主要コンポーネントを利用し、プロキシとクライアントアプリケーション間の双方向メッセージパッシングを有効にすることで、LLMオーケストレーションのすべての部分の所有権を維持しつつ、ElevenLabs Agentsに外部エージェントを統合し、提供される音声オーケストレーションのみを厳密に利用できます。 

状態との関係

複雑な外部エージェントを効果的にサポートするには、特に状態管理において、プロキシとエージェントの責任を明確に分ける必要があります。このモデルでは、プロキシがアプリケーションのニーズに応じてグループ化した関連対話のテーブルを維持し、ステートレスなロジックを使用して自身とエージェントの間でメッセージをルーティングします。一方、全体の状態に寄与する実質的な内部・外部情報はすべて、外部エージェントが処理・保存するべきです。

この分離を緩めれば、既存ソリューションの手戻りをさらに減らせる場合もあります。しかし、エージェントのタスクセットが増えるにつれて、厳密な境界を維持するほうが一般に、より堅牢でスケーラブルな結果につながります。

今後に向けて

組織による音声対応・非音声対応エージェントの導入が成熟するにつれ、これらのエージェントに必要な情報のパターンが明確になり、この記事で説明したサービスの開発と所有を簡素化できると期待しています。それまでの間も、すでに顕在化している要件に応えるための開発を続けています。Forward Deployed Engineeringチームは、お客様と緊密に連携し、こうした新たなニーズを具体的なプロダクト機能へと変換するとともに、実際の導入事例に合わせてソリューションを進化させています。

すでに既存のエージェントを利用しており、LLMオーケストレーションの所有権を維持しながらElevenLabs Agentsで音声を有効にしたい場合は、ぜひこのアプローチを試して、ご意見をお聞かせください。