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

フロンティアエージェントオーケストレーターは、ますます複雑なタスクを処理し、エンタープライズツール全体で操作できるようになっています。これには、アプリケーション、会話、システムの状態を慎重に管理する必要があります。音声以外のモダリティでは、一般的なパターンが「コンテキストエンジニアリング」という包括的な用語の下で出現しています。これは、エージェントのシステムプロンプトに一貫した実践を構築することを目的としています。音声を導入することで、音声インタラクションのコンポーネントを管理するための追加の状態が導入されるだけでなく、他のモダリティでの以前の作業からの成果物を再利用することも理想的です。

この投稿では、ElevenLabs Agentsが外部エージェントをサポートし、統合を細かく制御するためのパターンを紹介します。これらのメカニズムにより、ElevenLabsの最高クラスの音声オーケストレーションを活用しながら、広範なオーケストレーションの完全な所有権を維持できます。

コアコンポーネント

ElevenLabs Agents

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

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

状態管理

定義上、エージェントが効率的に環境をナビゲートするために追跡しなければならないデータは、非常にタスク固有です。外部エージェントによって強化されたElevenLabs Agentsの場合、いくつかの明確に定義されたカテゴリにわたって状態を維持することが有用です。

内部状態は会話のダイナミクスを支配します。エージェントの内部状態の一部として追跡される要素の例には以下が含まれます：

• 音声活動、割り込み、アクティブな話者の識別を含む現在の会話の流れ。
• 検出された意図、エンティティ、感情など、リアルタイムのトランスクリプト分析から得られるアプリケーション固有の洞察。
• 中間的な考え、仮説、解決策の生成における以前の試みを含む推論の痕跡。
• アクティブな目標、操作モード、インタラクション中の行動を導く一時的な制約などの設定および運用パラメータ。

一方、外部状態は主にエージェントが対話または影響を与える関連システムや個人に焦点を当てます。エージェントの外部状態の一部として追跡される要素の例には以下が含まれます：

• 対話する他のユーザーやシステムのステータス、例えば現在の目標、利用可能性、または権限。
• エージェントの行動能力に影響を与える可能性のあるAPI、データベース、統合などのツールと知識ベース。
• エージェントの次のステップに影響を与える外部アクターやシステムを含む進行中のタスクと依存関係。

ユーザーとの関係のライフサイクル全体を通じてこの情報を確実に維持するための一般的なパターンを示します。

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

概要

このセクションでは、複雑な外部エージェントを成功裏に統合するために必要なアーキテクチャコンポーネントと実装の詳細をカバーします。このアプローチの中心には、すべてのサービスにわたってセッションを表す任意の一意の識別子をプロキシする能力があります。カスタムLLMを使用するElevenLabs Agentsの場合、必要な識別子を追加ボディオブジェクト内のLLMパラメータとして渡すことで簡単に実行できます。会話のオーバーライドを通話開始時に渡すことで、識別子がユーザーから外部エージェントまでElevenLabs Agentを通じて流れることができます。

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

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

メッセージの受け渡し

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

例えば、外部エージェントが進行中の音声活動を把握することはしばしば有用です。これにより、ユーザーが話しているかどうか、どのくらいの時間話しているか、事前に何らかのアクションを取るべきかを判断できます。これらの洞察は、ElevenLabs Agentsが提供する音声活動検出（VAD）スコアをクライアントイベントとして会話のWebsocketを通じて受信することで直接得られ、実行されます。ElevenLabsからスコアを受け取ると、クライアントアプリケーションはアプリケーションの要件に基づいてVADクライアントイベントをステートフルプロキシに転送し、メッセージに任意のセッション識別子を含めることを確認します。ステートフルプロキシは、セッションの既存の接続を最適に識別するリクエストマッピングロジックを実装する必要があります。

このパターンは、クライアントからの任意のイベントをJSONブロックとして表現できる限り拡張可能です。しかし、エージェント自体から発生するイベントを公開することも有用です。一般的な例としては、外部システムでの操作を表すツールコールや知識ベースクエリのライフサイクルが含まれます。これらのメカニズムは、今日の企業が構築しているエージェントにとって基本的なものです。

カスタムLLMを通じて外部エージェントを統合する場合、ElevenLabsのツールコールおよびRAG（取得強化生成）機能は、外部エージェントの独自の実装に優先されることがよくあります。その結果、これらのコンポーネントの所有権は完全に外部エージェントプロバイダーにあります。アプリケーションは、ツール活動の可視性から利益を得ることができます。これにより、エージェントの進捗を表示し、エンドユーザーの体験を更新することができます。

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

したがって、これらのコアコンポーネントを使用し、プロキシとクライアントアプリケーション間のメッセージの双方向受け渡しを可能にすることで、顧客はElevenLabs Agents内で外部エージェントを統合し、提供される音声オーケストレーションを厳密に使用しながら、LLMオーケストレーションのすべての部分の所有権を保持できます。

状態へのリンク

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

この分離を緩和することで既存のソリューションの再作業をさらに減らすことができるかもしれませんが、エージェントのタスクセットが成長するにつれて、厳密な境界を維持することは一般的により堅牢でスケーラブルな結果をもたらします。

今後の展望

組織が音声および非音声対応エージェントの採用を成熟させるにつれて、これらのエージェントに必要な情報のパターンが結晶化し、この投稿で説明したサービスの開発と所有を簡素化できるようになると期待しています。その間、すでに出現している要件に対応するための構築を続けています。私たちのForward Deployed Engineeringチームは、これらの新たなニーズを具体的なプロダクト機能に変換し、実際の展開と歩調を合わせてソリューションを進化させるために顧客と緊密に連携しています。

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