ElevenAgentのオーケストレーションエンジンを徹底解説

ElevenAgentsは、リアルタイム会話のために設計された低レイテンシーのオーケストレーションエンジンを搭載しており、オーバーヘッドは100ms未満です。このアーキテクチャは、ElevenLabsの研究成果と、OpenAI、Google、Anthropicなどの主要プロバイダーによる最先端LLM、さらにElevenLabsがホストする厳選されたオープンソースモデルを組み合わせています。応答パイプラインのさまざまな段階で複数のモデルを活用することで、エージェントは高い応答性と文脈理解を両立します。各モデルの強みを動的に組み合わせ、知能、速度、コストのバランスを最適化しながら、幅広いエンタープライズタスクや会話シナリオで信頼性と拡張性に優れたパフォーマンスを実現します。

この記事では、複雑な環境でエージェントが稼働するために必要な中核機能を、これらのモデルがどのように連携して提供するのか、特にどのモデルがいつどのトークンを見るのかを解説します。その中心となるのが、インタラクションのさまざまな時点における会話履歴の管理です。会話履歴がどのように、どこで共有されるかをあらためて確認し、独立型エージェントとマルチエージェントのワークフローにおけるオーケストレーションでの役割を明らかにします。

独立型エージェント 

まず、独立型エージェントとその中核コンポーネントを見ていきます。最小限の価値を持つエージェントには、システムプロンプトと、複数のツール、そしてナレッジベースへのアクセスがあると考えるのが妥当です。厳密な手順の順序を検証する必要性が限定的なユースケースや、エージェント内の知識のサイロ化を避けることが重要な場合は、ワークフローより独立型エージェントを選ぶべきです。知識のサイロは、特定のツール、ドキュメント、履歴コンテキストに一部のサブエージェントはアクセスできても、他のサブエージェントはアクセスできないときに発生します。これはマルチエージェントワークフローに固有のものであり、柔軟性と決定性のトレードオフをもたらします。 

ElevenLabsの独立型エージェントでは、次の仕組みを理解することが重要です。

• 効果的な生成リクエストを構築する
• 関連ドキュメントを取得して組み込む
• エージェントの応答に必要なツール呼び出しを生成・実行する
• 評価とデータ収集のために結果を出力する

会話コンテキストの構築 

顧客とElevenLabsエージェントの会話は、一連のターンで構成され、各ターンでは双方がメッセージをやり取りします。このエージェントとユーザーのメッセージが交互に並ぶリストが、会話コンテキストを構築する出発点となります。各ターンで基盤となるLLMは、前のターンより1メッセージ多い、エージェントとユーザーのメッセージが交互に並んだ生成リクエストを受け取ります。もちろん、このメッセージ列の先頭には、エージェントのシステムプロンプトを表す単一のシステムメッセージが付加されます。

ElevenLabsのオーケストレーターは、ユーザーが話し終えたタイミングを予測することで、体感LLMレイテンシーを低減します。場合によっては、1つのターン内で同じ会話コンテキストを持つ複数のLLM生成リクエストが発生することがあります。 オーケストレーションはエージェントの応答速度を最適化しますが、応答品質は知識へのアクセス方法にも同じくらい大きく左右されます。 利用が進むと、通常は独自ドキュメントと公開コンテンツを組み合わせて、エージェントの応答を根拠づけるようになります。これを実現する標準的なアプローチは、長年にわたり検索拡張生成（RAG）でした。ElevenAgentsナレッジベースは、RAGを基盤とし、以前の記事で詳しく紹介した、最適化されたマルチモデルアーキテクチャを採用しています。これにより、直近のユーザー入力が追加質問、説明への確認応答、あるいは明示的な質問を含まない場合でも、信頼性の高いドキュメント検索が可能になります。

ただし、検索はエージェントが外部システムと連携する方法の一つにすぎません。

ツールを使ったアクション実行と情報取得

ElevenLabsエージェントは、柔軟なツールシステムを通じて、会話の途中で現実世界のアクションを実行したり、最新情報を取得したりできます。この機能には重要な設計上の考慮事項があります。有効にするツールごとに、名前、説明、パラメータスキーマがシステムプロンプトや会話履歴とともに含まれるため、シリアライズされたプロンプトのサイズが増加します。 ツールを追加するほど、正しい順序でツールを呼び出すためにモデルにかかる推論負荷も増加します。Agent Builderでは、ツールの説明に、そのツールの機能と返されるフィールドを記載します。言語モデルはこの情報を使って、ツールの使用に関するコンテキストを理解します。ツールを呼び出す具体的な条件は、定義後にエージェントのシステムプロンプトに記述します。たとえば、次のようになります。

• ツールの説明：lookup_order：「注文IDで顧客の注文詳細を取得します。注文ステータス、購入商品、配送先住所、追跡番号を返します。」
• システムプロンプトの指示：「顧客の本人確認後、】【lookup_orderツールを呼び出して注文詳細を取得してください。」

この関心の分離により、ツール定義を複数のエージェントで再利用しながら、各エージェントのシステムプロンプトでツールを呼び出す正確なタイミングを制御できます。こうしたシステムプロンプトを効果的に設計できるよう、プロンプトガイドではより詳しいガイダンスを提供しています。このフレームワークでは、主に次の種類のツールを定義できます。

• 外部APIを呼び出すWebhookツール。
• 会話WebSocketを通じてイベントとしてツールリクエストを送信するクライアントツール。
• 通話転送などの組み込みアクション用システムツール。
• Model Context Protocolサーバーに接続するMCPツール。

エージェントがツールの使用を決定すると、会話から必要な詳細を取得して実行リクエストを送ります。ツールが結果を返すと、その結果が会話に追加され、モデルは次の応答で自然に参照できます。必要に応じて、ツールの出力はエージェントに保存された情報を動的変数として更新することもできます。この保存情報は、事前定義されたマッピングでツールの応答から抽出されたシンプルなキーと値のペアとして保持されます。設定後、これらの変数はシステムプロンプト、将来のツールパラメータ、ワークフロー条件を通じてエージェントにフィードバックできます。このフィードバックループにより、エージェントは対話に応じて変化する作業記憶のようなものを得られます。

ここまではツールがエージェントの推論に統合される仕組みを説明しましたが、実行タイミングも設定できます。ツールは、会話上の異なるニーズに適した3つの実行モードで動作します。Immediate Modeでは、LLMからリクエストされるとすぐにツールが実行されます。これは注文ステータスの確認など、ユーザーがほぼ即時の応答を期待する高速な検索でのデフォルトです。ツール実行前の発話と組み合わせると、エージェントはまず「確認します」のような短い応答を生成してユーザーに返し、ツールを並行実行するため、無音時間を最小限に抑えられます。低速なツールの場合、プラットフォームは予想される待機時間に合わせて、こうしたつなぎのメッセージを自動的に延長します。一方、Post-Tool Speech Modeでは、エージェントが話し終えるまで実行を遅らせます。これは、通話の転送、セッションの終了、支払いの送信など、現実世界に影響するアクションで不可欠です。ユーザーは「これから経理部門におつなぎします」といった完全な説明を聞き、アクションが実行される前に割り込むことができます。Async Modeでは会話を止めず、ツールを完全にバックグラウンドで実行します。このモードは、メール送信、外部ワークフローのトリガー、データ記録など、エージェントが応答内で結果を参照する必要がない一回限りの操作に最適です。

実行とオーケストレーションを整えたら、次はパフォーマンスの測定方法を理解します。

パフォーマンスの測定

Agentとの通話が完了した後、詳細な分析や保存のために通話の一部を抽出したい場合や、通話が成功したかどうかを判断したい場合があります。そこで活用するのがデータ収集と評価基準です。データ収集では、後続の分析や集計に向けて、通話の文字起こしから構造化情報を抽出できます。これらの出力は、レポート作成やデータ拡充ワークフローのために、エンタープライズのデータレイクハウスへエクスポートされることがよくあります。たとえば営業開発エージェントは、会話から見込み客の詳細を自動抽出し、顧客関係管理（CRM）システムでリードを作成または更新できます。一方、評価基準は通話が成功と見なされるかを判断します。設定したすべての基準を満たす場合、通話自体が成功としてマークされ、そうでない場合は失敗としてフラグが付けられます。これにより、会話が品質と完全性について定義された基準を一貫して満たすことを保証しつつ、迅速なフィードバックを提供します。通話が終了して通話後Webhookがトリガーされると、エージェントは、ツール実行とメタデータを含む確定済みの文字起こしを、設定済みのすべてのデータ収集ポイントと評価基準とともにLLMで処理します。モデルはこの組み合わせたプロンプトを使い、各評価基準が満たされているかを判定し、後続分析用の指定データポイントを抽出します。LLMはこれらの設定を入力プロンプトの一部として直接解釈するため、モデルが正確に理解・適用できるよう、明確かつ一貫して書式設定することが重要です。そのため、評価基準とデータ収集の説明を記述する際は、次のベストプラクティスを推奨します。

評価基準

1. 基準ごとに明確な目標を一つ：一つの基準に複数の目標を入れるより、1文または短い箇条書きにする方が適しています。 
2. 観測可能で文字起こしに基づくこと：文字起こし（何が話されたか、エージェントが何をしたか、ユーザーが何を尋ねたか）から成功／失敗を判断できるように目標を記述します。LLMが持たない外部コンテキストを必要とする目標は避けてください。
3. 成功／失敗／不明の結果を明示すること：LLMには、目標が満たされれば成功、満たされなければ失敗、文字起こしから判断できなければ不明とマークするというコンテキストがすでにあります。そのため、「満たされた」と「満たされていない」が明確に定義されるよう目標を書く必要があります。曖昧な場合、モデルは不明または誤った分類に傾く可能性があります。
4. 簡潔にすること：複数の評価基準がまとめて送られることがあります。そのため、評価基準が長いとノイズが増え、ハルシネーションを引き起こす可能性があります。
5. 言語も重要：評価基準が満たされたかどうかについてLLMが示す根拠は、基準の説明と同じ言語で提供されます。この点を念頭に置くことが重要です。

データ収集

1. 抽出する内容を正確に説明すること：説明はLLMにとって最も重要なシグナルです。フィールドの意味、設定すべき状況、不明な場合の扱いを記載してください（例：「顧客が希望日を述べなかった場合はnullのままにする」）。
2. 期待する型に合わせること：LLMが提供する値は、データ収集ポイントに割り当てられたデータ型（boolean、string、integerなど）と常に一致します。そのため説明もその型に合わせる必要があります。たとえばintegerには「リクエストされた商品の数を抽出」、booleanには「顧客が提案に同意したかどうかをYes／Noで示す」のように記述できます。
3. 可能な場合はenumを使うこと：string型で値の集合が固定されている場合は、スキーマでenumを使用してください。モデルの出力を制約し、無効な出力を減らせます。
4. 項目ごとに抽出対象を一つにすること：一つの項目の説明に無関係な複数の事実を詰め込まず、各呼び出しに明確な抽出対象が一つだけあるよう、別々の項目に分けてください。
5. 説明は短くすること：説明は数文で十分で、長い段落は必要ありません。文字起こしはすでにユーザーメッセージに含まれているため、スキーマと短い説明だけで足ります。

現在、この評価・抽出ステップで使用するLLMは、高速処理を実現するため低レイテンシーモデルに固定されています。近い将来、より柔軟に利用できるオプションを導入する予定です。 

次に、構造化されたオーケストレーション、決定性、または複数の会話ロールにまたがる専門化が必要なユースケースに目を向けます。こうした場合、代わりにWorkflowsを使用できます。

Workflows

Workflowsは、複雑な会話フローを設計するためのビジュアルインターフェースを提供します。最終的に、独立型エージェント識別子のもとで複数のサブエージェント、ツール、転送を管理するために、オーケストレーターが使用する論理オブジェクトを生成します。Workflowsでは、独立型エージェントですでに説明した要素に加え、次の点も考慮する必要があります。

• システムプロンプトとサブエージェントの会話目標がどのように連携するか。
• グラフ内のさまざまな遷移ポイントをどのようにたどるかが決まる仕組み。

専門化された会話目標

Workflowsは独立型エージェントの機能を再利用し、インタラクション全体で一貫した動作を実現します。これには、ワークフローのどの部分がアクティブかにかかわらず常に利用できるべき、ベースシステムプロンプト、コアツール、グローバルナレッジベースなどの共有要素が含まれます。包括的なシステムプロンプトは通常、グローバルな会話コンテキスト、期待されるトーン、セーフティ制約、ブランド固有またはプロダクト全体に関する指示を定義します。

この共有基盤に加え、Workflowsでは有向グラフ内で動作する専門化されたサブエージェントを導入します。各サブエージェントには範囲を限定した目標が割り当てられ、そのロールにのみ関連する追加のプロンプト指示、ツール、知識ソースによってベース設定を拡張します。会話設定全体を再定義するのではなく、サブエージェントはプロンプトの構成と選択的なコンテキスト拡張を通じて、ベースエージェントに意図を重ねます。継続性を保つために、サブエージェント間の遷移をまたいで会話履歴は保持されますが、各サブエージェントは意図的に制限されたシステムビューで動作します。ナレッジベースとツールは選択的に公開され、責務間の情報漏れを防ぐ明確なサイロが作られます。この分離を強化するため、オーケストレーターオブジェクトは遷移のたびに独立型エージェントであるかのように再構築されます。これにより、アクティブなサブエージェントのプロンプト状態、設定、利用可能な機能は完全に決定的に保たれます。この設計により、Workflowsは局所的な専門化をサポートしながらグローバルな一貫性を維持し、予測可能な動作、明確な関心の分離、そしてインタラクションの各段階でコンテキスト、知識、アクションを適用する方法の精密な制御を実現します。

この制御を可能にする重要な仕組みの一つが、サブエージェント間の遷移を管理する方法です。

LLM条件によるワークフロー遷移の制御

Workflowsはサブエージェントの有向グラフをたどって進み、ノード間の遷移は明示的な条件で制御されます。これらの条件は、制御をあるサブエージェントから別のサブエージェントへ移すタイミングを決定し、ワークフローがユーザー入力、ツールの結果、動的変数に応答できるようにします。グラフ条件は、決定的なものとLLMで評価されるものがあります。無条件遷移、動的変数の式に基づくチェック、ツール結果の条件などの決定的な条件は、制御フローを強く保証し、ワークフロー内の厳密な進行を強制するのに適しています。対してLLMベースの条件では、ユーザーの意図を検出したり、特定の情報が提供されたことを認識したりするなど、自然言語の基準を意味的に評価できます。

重要なのは、LLM条件はアクティブなエージェントのシステムプロンプトの外部で評価され、エージェントの生成動作には影響しないことです。代わりに、オーケストレーターが現在の会話状態に対して並行して評価します。この分離により、遷移ロジックがエージェントのプロンプトを汚染したり、応答の生成方法に影響したりすることはありません。同時に、ワークフローはLLMの推論を活用して柔軟にグラフをたどれます。決定的な条件とLLM評価条件を組み合わせることで、ワークフローは予測可能性と適応性の両方を実現できます。正確性が重要な場面では決定的な遷移を、意味的な解釈が必要な場面ではLLMベースの遷移を使用します。

会話が新しい段階に進むと、システムはそのステップに特化したバージョンのエージェントを有効化します。各段階は、焦点を絞った独自の指示と、その責務に関連する知識とツールだけへのアクセスで動作します。たとえば返金処理の段階では、オンボーディングやトリアージに関する無関係なコンテキストを引き継ぐことなく、返金ポリシーを参照できます。段階間の移動は明示的な遷移条件によって管理されます。これらの条件によって責務を移すタイミングが決まり、会話の進行に合わせて自然にルーティング判断を行えます。継続性を保つため、各段階は関連する会話コンテキストを継承しつつ、引き継ぎの仕組みを見せないため、ユーザー体験は遷移をまたいでもシームレスに保たれます。また、非生産的なルーティングの循環を防ぐためのセーフガードが遷移を監視し、ワークフローが安定し、目標に沿った状態を維持します。

セーフティとセキュリティ

より高度なセーフティとセキュリティの制御が必要な場合、オーケストレーターの追加機能を利用できます。 

ガードレール

ElevenLabs Agentsは、ユーザーとエージェントのメッセージをリアルタイムで評価する、設定可能なモデレーションおよびアラインメントシステムによりセーフティガードレールを実装しています。受信コンテンツは、性的コンテンツ、暴力、ハラスメント、ヘイト、自傷行為など複数のリスクカテゴリに分類され、それぞれに個別設定可能なしきい値があります。ガードレールが発動すると、会話は直ちに終了し、明確な失敗理由がクライアントに通知されます。これにより、プロンプトベースの緩和策だけに頼らず、安全でないやり取りを早期かつ一貫してブロックできます。ガードレールはエージェントのプロンプトロジックの外部で動作し、モデルの挙動やユーザー入力では回避できない信頼性の高い実施レイヤーを提供します。このアプローチにより、実行時の決定的な適用を維持しながら、ドメインに応じてセーフティの感度を調整できます。

コンプライアンスに準拠したデータ管理

話者がエージェントと共有する情報には、HIPAA準拠の取り扱いが必要な医療データなど、厳格な保存・処理要件の対象となる機密情報が含まれる場合があります。こうしたユースケースをサポートするため、AgentまたはWorkspaceレベルでZero Retention Mode（ZRM）を提供しています。有効にすると、すべての通話データはメモリ内でのみ処理され、永続ストレージには一切書き込まれません。通話と処理が完了すると、ElevenLabsは情報を保持しません。そのため、文字起こし、音声録音、分析出力はAgents Dashboardで利用できず、このポリシーは顧客向けシステムと内部ログの両方に適用されます。データは保持されませんが、通話中には処理され、設定済みの通話後Webhookは出力を受け取ります。必要に応じて、文字起こしや分析結果を自社システムに保存できます。 

ZRMが有効な場合、利用可能なLLMを、顧客データでのトレーニングや顧客データの保持を禁止する契約上の義務を負うプロバイダーに限定することで、サブプロセッサーもデータを保持しないようにします。現在はGoogle GeminiおよびAnthropic Claudeのモデルが対象です。ZRM下で別のLLMを使用したい場合は、そのプロバイダーと独自に契約を締結し、その契約の対象となるAPIキーを使用してカスタムLLMとして設定できます。これは標準のトラストバウンダリーを超えてデータ処理を拡張するため、有効化する前にSafetyチームがユースケースを手動でレビューし、承認する必要があります。ZRMによりElevenLabsとそのサブプロセッサーは通話データを保持しませんが、Agentが使用する外部ツールやWebhookが適用される保持要件および規制要件に準拠していることを確認する責任は顧客にあります。

今後に向けて

この記事では、ElevenLabs Agentsが会話コンテキスト、ツール、評価、構造化ワークフローを管理し、大規模でも信頼性の高いリアルタイム体験を提供する仕組みを解説しました。エージェントがさらに複雑な環境に導入される中、設定可能な評価モデルやより豊富な遷移制御から、段階ごとのプロンプト構成とトークン使用量をより深く可観測にする機能まで、オーケストレーションエンジンの柔軟性を継続的に拡張しています。

Forward Deployed Engineeringチームは、これらの機能が実際の導入環境と歩調を合わせて進化するよう、顧客と密接に連携しています。次世代のAgentsは、リアルタイム会話を可能にする低レイテンシーパフォーマンスを損なうことなく、さらに優れた透明性、決定性、適応性を提供します。