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

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

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

主要コンポーネント

ElevenLabs Agents

最もシンプルな形では、ElevenLabs AgentにはWebSocketクライアントからアクセスできます。会話内のサーバーイベントとクライアントイベントを表す情報は、JSONオブジェクトとしてエージェントとの間で送受信されます。エージェントはユーザーの発話を書き起こすと、即座に生成リクエストをトリガーします。主要なモデルプロバイダーのほとんどに対応しており、独自のカスタムLLMを利用することもできます。 カスタム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はメッセージが他のサービスに渡されていることを認識する必要はありません。  

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

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

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

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

つまり、これらの主要コンポーネントを使用し、プロキシとクライアントアプリケーション間のメッセージの双方向送受信を有効にすることで、LLMオーケストレーションのあらゆる部分の所有権を維持しながら、ElevenLabs Agentsが提供する音声オーケストレーションのみを活用する形で外部エージェントを統合できます。 

状態との関連付け

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

この分離を緩めれば既存ソリューションの手戻りをさらに減らせる可能性はありますが、エージェントのタスクセットが拡大するにつれて、厳格な境界を維持するほうが、一般に堅牢性とスケーラビリティに優れた結果につながります。

今後に向けて

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

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