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モードでは、LLMがリクエストした時点ですぐにツールが実行されます。これは注文状況確認など、即時応答が期待される用途のデフォルトです。ツール実行前に「確認しますね」などの短い応答を生成し、ツール実行中もユーザーに返すことで無音時間を最小化します。ツールが遅い場合は、プラットフォームが自動でフィラー応答を延長します。Post-Tool Speechモードでは、エージェントの発話が終わるまでツール実行を遅らせます。通話転送やセッション終了、支払い処理など、現実世界に影響するアクションに必須です。「これから請求担当におつなぎします」など、ユーザーが割り込めるタイミングを確保します。Asyncモードは、会話を止めずにツールをバックグラウンドで実行します。メール送信や外部ワークフローのトリガー、データ記録など、結果を応答で参照しない用途に最適です。

実行とオーケストレーションの仕組みが整ったら、次はパフォーマンスの測定方法を理解しましょう。

パフォーマンスの測定

エージェントとの通話が完了した後、顧客は通話内容の一部を抽出して分析や保存を行ったり、通話が成功したかどうかを判断したい場合があります。ここで活躍するのが、データ収集と評価基準です。データ収集では、通話の書き起こしから構造化情報を抽出し、後続の分析や集計に活用できます。多くの場合、これらの出力はエンタープライズのデータレイクハウスにエクスポートされ、レポートやワークフローに利用されます。例えば、営業開発エージェントが会話から見込み客情報を自動抽出し、CRMシステムのリード作成や更新を行うことができます。一方、評価基準は通話が成功と見なされる条件を定めます。すべての基準を満たせば通話は成功、満たさなければ失敗としてフラグが立ちます。これにより、会話の品質や一貫性を保ちつつ、迅速なフィードバックが得られます。通話終了後、ポストコールWebhookが発火すると、エージェントは最終的な書き起こし（ツール実行やメタデータを含む）を、すべてのデータ収集ポイントと評価基準とともにLLMに渡して処理します。モデルはこの複合プロンプトを使い、各評価基準の達成可否を判定し、指定されたデータポイントを抽出します。LLMはこれらの設定をプロンプトの一部として直接解釈するため、明確かつ一貫したフォーマットで記述することが重要です。評価基準やデータ収集の説明文を書く際は、以下のベストプラクティスを推奨します。

評価基準

1. 1つの基準につき明確なゴールを設定：1文または短い箇条書きで、複数のゴールを1つの基準にまとめないようにしましょう。
2. 観察可能かつ書き起こしベース：ゴールは、書き起こし（発言内容、エージェントの行動、ユーザーの質問）から達成可否が判断できるように記述します。LLMが持たない外部情報が必要なゴールは避けてください。
3. 明確な成功／失敗／不明の判定：LLMは、ゴールを満たせば成功、満たさなければ失敗、不明なら判定不能とする前提で動作します。そのため、「達成」「未達成」が明確になるように記述してください。曖昧だと不明や誤判定になりやすくなります。
4. 簡潔にまとめる：複数の評価基準をまとめて送信する場合もあるため、長文はノイズや誤認識の原因になります。
5. 言語にも注意：LLMが評価基準を満たしたかどうかの理由を返す際、その説明は基準説明と同じ言語になります。これを意識して記述しましょう。

データ収集

1. 抽出対象を正確に記述：説明文はLLMへの主なシグナルです。フィールドの意味、どんな状況で値を設定するか、不明な場合の対応（例：「希望日が明言されなければnullにする」）を明記してください。
2. 期待する型と合わせる：LLMが返す値は、データ収集ポイントに割り当てた型（boolean、string、integerなど）と必ず一致します。説明文もそれに合わせてください。例：「リクエストされた商品の数を抽出」（integer）、「顧客がオファーに同意したか（はい／いいえ）」（boolean）など。
3. 可能な場合はenumを使う：string型で値が固定の場合は、スキーマでenumを指定しましょう。モデルの出力が制約され、不正な値が減ります。
4. 1項目につき1つの抽出対象：複数の無関係な情報を1つの説明文に詰め込まず、項目ごとに明確な抽出対象を設定してください。
5. 説明文は短く：説明文は数文で十分です。書き起こしはすでにユーザーメッセージに含まれているため、スキーマ＋短い説明でOKです。

現在、この評価・抽出ステップで使用するLLMは低遅延モデルに固定されており、迅速な処理を実現しています。今後は、より柔軟な選択肢も提供予定です。

次に、構造化されたオーケストレーションや決定性、複数の会話役割での専門性が求められるユースケースについて、Workflowsの活用方法を紹介します。

ワークフロー

ワークフローは、複雑な会話フローを設計できるビジュアルインターフェースを提供します。最終的には、複数のサブエージェントやツール、転送を独立型エージェントIDのもとで管理するための論理オブジェクトを生成します。ワークフローでは、独立型エージェントで説明した内容に加え、以下のような追加要素も考慮します：

• システムプロンプトとサブエージェントの会話目標の連携
• グラフ内の各遷移ポイントをどのように進むかの決定方法

専門的な会話目標

ワークフローは、独立型エージェントの機能を再利用し、やり取り全体で一貫した動作を担保します。これには、ベースとなるシステムプロンプトやコアツール、常に利用可能なグローバルナレッジベースなど、共有要素が含まれます。全体のシステムプロンプトは、グローバルな会話コンテキストや期待されるトーン、セーフティ制約、ブランドやプロダクト全体の指示を定義する役割を担います。

この共通基盤の上に、ワークフローは有向グラフ内で動作する専門サブエージェントを導入します。各サブエージェントには限定的な目標が割り当てられ、その役割に必要な追加プロンプト指示やツール、ナレッジソースをベース設定に上乗せします。会話全体を再定義するのではなく、サブエージェントはプロンプト合成や選択的なコンテキスト拡張を通じて意図を重ねます。会話履歴はサブエージェント間で引き継がれ、連続性を保ちますが、各サブエージェントは意図的に制限されたシステムビューで動作します。ナレッジベースやツールは選択的に公開され、責任範囲ごとに明確なサイロが作られます。この分離を強化するため、オーケストレーターオブジェクトは遷移ごとに独立型エージェントとして再構築され、アクティブなサブエージェントのプロンプト状態・設定・利用可能な機能が完全に決定的に保たれます。この設計により、ワークフローはグローバルな一貫性とローカルな専門性を両立し、予測可能な動作・明確な責任分離・各段階でのコンテキストや知識、アクションの精密な制御を実現します。

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

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

ワークフローは、サブエージェントの有向グラフをたどることで進行し、ノード間の遷移は明示的な条件で制御されます。これらの条件によって、どのタイミングで制御を次のサブエージェントに移すかが決まり、ユーザー入力やツールの結果、動的変数に応じて柔軟に対応できます。グラフ条件には決定的（deterministic）なものとLLM評価型のものがあります。決定的条件（無条件遷移、動的変数式によるチェック、ツール結果条件など）は、ワークフローの厳密な進行を保証しやすく、制御フローの担保に適しています。一方、LLM条件は、ユーザーの意図検出や特定情報の提供確認など、自然言語基準の意味的評価を可能にします。

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

会話が新しい段階に進むと、そのステップ専用に調整されたエージェントバージョンが有効化されます。各段階は、それぞれの責任範囲に必要な指示や知識、ツールのみを利用できる状態で動作します。例えば、返金対応段階では返金ポリシーのみを参照し、オンボーディングやトリアージの文脈は引き継ぎません。段階間の移動は明示的な遷移条件で制御され、会話の流れに沿って自然にルーティングが行われます。連続性を保つため、ユーザー体験は遷移を意識させずシームレスに進み、各段階で必要な会話コンテキストのみが引き継がれます。遷移時には非生産的なループを防ぐセーフガードも働き、ワークフローの安定性と目標指向性を維持します。

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

より高いセーフティやセキュリティ管理が必要な場合、オーケストレーターの追加機能を活用できます。

ガードレール

ElevenLabs Agentsは、ユーザー・エージェント双方のメッセージをリアルタイムで評価する、設定可能なモデレーション＆アラインメントシステムによってセーフティガードレールを実装しています。受信コンテンツは、性的内容・暴力・嫌がらせ・ヘイト・自傷など複数のリスクカテゴリで分類され、それぞれ独立して閾値を設定できます。ガードレールが発動すると、会話は即座に終了し、クライアントには明確な失敗理由が通知されます。これにより、プロンプトベースの対策だけに頼らず、危険なやり取りを早期かつ一貫してブロックできます。ガードレールはエージェントのプロンプトロジック外で動作し、モデルやユーザー入力による回避ができない信頼性の高い強制レイヤーとなります。この仕組みにより、顧客は自社ドメインに合わせてセーフティ感度を調整しつつ、実行時の決定的な強制力を維持できます。

コンプライアンス対応のデータ管理

話者がエージェントに医療データなど厳格な保存・処理要件のある機密情報を共有する場合に備え、Agentまたはワークスペース単位でZero Retention Mode（ZRM）を提供しています。有効化すると、すべての通話データはメモリ上のみで処理され、永続ストレージには一切保存されません。通話と処理が完了すると、ElevenLabs側には情報が一切残りません。そのため、書き起こし・音声録音・分析結果はAgentsダッシュボードで閲覧できず、この方針は顧客向けシステム・内部ログの両方に適用されます。データは保持されませんが、通話中は処理され、設定したポストコールWebhookには出力が送信されるため、必要に応じて顧客側システムで保存できます。

ZRM有効時は、サブプロセッサもデータを保持しないよう、利用可能なLLMを顧客データの学習や保持を契約上禁止しているプロバイダー（現時点ではGoogle GeminiとAnthropic Claude）に限定しています。他のLLMをZRM下で利用したい場合は、顧客自身がそのプロバイダーと契約し、APIキーでカスタムLLMとして設定できます。この場合、データ管理がElevenLabsの標準的な信頼境界を超えるため、セーフティチームによる個別審査・承認が必要です。ZRMによりElevenLabsおよびサブプロセッサは通話データを保持しませんが、エージェントが利用する外部ツールやWebhookについては、顧客側で適用法令や保持要件への対応が必要です。

今後の展望

本記事では、ElevenLabs Agentsが会話コンテキスト・ツール・評価・構造化ワークフローをどのように管理し、信頼性の高いリアルタイム体験を大規模に提供しているかを解説しました。顧客がより複雑な環境にエージェントを導入する中で、評価モデルの設定や高度な遷移制御、プロンプト構成やトークン使用状況の可視化など、オーケストレーションエンジンの柔軟性をさらに拡張し続けています。

私たちのForward Deployed Engineeringチームは、現場での導入と連携しながら、これらの機能が実際のニーズに合わせて進化するようお客様と密に協力しています。次世代のAgentsは、リアルタイム会話を可能にする低遅延性能を損なうことなく、さらなる透明性・決定性・適応性を提供します。