カスケード型 vs 融合型モデル：会話型エージェントのアーキテクチャ比較

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

エージェントのアーキテクチャによって、どれだけ自然で知的か、一貫した応答ができるか、そして長期的に予測通りに動作するかが決まります。例えば、フュージョン型アーキテクチャで構築されたエージェントは、短い会話では特にリアルに聞こえますが、長い会話では推論や一貫性の維持が難しくなることがあります。

ElevenLabsでは、音声認識・推論・音声生成の各専門コンポーネントを連携させるカスケード型アーキテクチャを採用しています。一方、OpenAIのRealtimeモデルは、これらの工程を1つのネットワークにまとめたフュージョン型アプローチを取っています。

この記事では、現在主流の5つの会話型エージェントアーキテクチャについて、それぞれの基本設計や特徴、トレードオフ、そしてチームが目的に応じてどのように選択しているかを解説します。ツール、そしてナレッジベースにアクセスできると考えるのが妥当です。厳密な手順の検証があまり必要ない場合や、エージェント内で知識の分断（サイロ化）を避けたい場合は、ワークフローよりも独立型エージェントを選ぶのがおすすめです。知識のサイロ化は、特定のツールやドキュメント、履歴コンテキストが一部のサブエージェントにしか共有されない場合に発生します。これはマルチエージェントワークフローに固有のもので、柔軟性と決定性のトレードオフを生みます。

エージェント構築時に重視されるポイント

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

会話コンテキストの構築 

同時処理や連携、音声品質なども重要ですが、上記の観点はアーキテクチャによってより直接的に影響を受けます。成功しているチームは、用途に合わせてこれらの観点を最適化できるアーキテクチャを選択しています。

カスケード型アーキテクチャは、専門的なコンポーネントを連結して構築されます： 、大規模言語モデル（LLM）、そしてテキスト読み上げ（Text to Speech）です。各工程は個別に最適化・テスト・アップグレードできます。以前の記事でご紹介しています。これにより、最新のユーザー入力がフォローアップや確認、明確な質問がない場合でも、信頼性の高いドキュメント検索が可能です。

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

このモジュール構成により、最新のLLMを組み込んで推論力を強化したり、テキスト層で明確なガードレールを適用したり、コンテキストに応じたTTSでエージェントの話し方を細かく制御できます。主なトレードオフは、カスケード型では音声をテキストに分解してから再生成するため、イントネーションやリズム、感情などのプロソディ的な手がかりが失われやすい点です。これらは明示的なモデリングで一部補えますが、フュージョン型ほど自然には捉えられません。レイテンシやターンテイキングなど他の要素は、どちらのアプローチでも最適化が可能です。

一方、融合型アプローチでは、これらの工程を1つのマルチモーダルモデルに統合します。音声を入力し、音声を出力する仕組みで、音声認識・推論・生成が同じネットワーク内で行われます。 ツールが増えるほど、正しい順序でツールを呼び出すためのモデルの推論負荷も高まります。Agent Builderでは、ツールの説明欄にツールの機能や返却フィールドが記載されます。これが、言語モデルが利用シーンを理解するための情報となります。ツールの呼び出し条件は、エージェントのシステムプロンプトに記述します。例：

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

この設計により、融合型アーキテクチャは発音やイントネーションなどのプロソディをより効果的に保持・再現できます。ただし、中間出力が見えないためテストや制御が難しくなります。また、軽量なLLMコアに依存しやすく、カスケード型のように強力なモデルと組み合わせた場合に比べて推論やツール呼び出しの性能が制限されます。プロンプトガイドで詳しく解説しています。この枠組みでは、主に以下の種類のツールが定義できます：

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

5つの代表的なアーキテクチャ動的変数としてエージェントの保存情報に反映することも可能です。保存情報は、ツールのレスポンスから事前定義されたマッピングで抽出したシンプルなキーと値のペアとして管理されます。設定後は、これらの変数をシステムプロンプトや今後のツールパラメータ、ワークフロー条件に活用できます。このフィードバックループにより、エージェントはやり取りを通じて進化するワーキングメモリを持つことができます。

1. ベーシックカスケード

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

ベーシックカスケード型アーキテクチャでは、音声をテキスト化し、LLMがテキストで返答を生成し、そのままTTSで読み上げます。すべての工程がテキスト上で行われるため、チームは全体を可視化・制御できます。ガードレールもテキスト層で適用でき、ツール呼び出しやAPI連携もLLMが直接処理。決定論的なフローで会話の流れやビジネスロジックも予測通りに制御できます。

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

主な利用例：

1. カスタマーサポート1文または短い箇条書きで、複数のゴールを1つの基準にまとめないようにしましょう。
2. 営業アシスタントゴールは、書き起こし（発言内容、エージェントの行動、ユーザーの質問）から達成可否が判断できるように記述します。LLMが持たない外部情報が必要なゴールは避けてください。
3. AI受付LLMは、ゴールを満たせば成功、満たさなければ失敗、不明なら判定不能とする前提で動作します。そのため、「達成」「未達成」が明確になるように記述してください。曖昧だと不明や誤判定になりやすくなります。
4. エンタメ・ゲームのNPC複数の評価基準をまとめて送信する場合もあるため、長文はノイズや誤認識の原因になります。
5. IVR（自動音声応答）代替LLMが評価基準を満たしたかどうかの理由を返す際、その説明は基準説明と同じ言語になります。これを意識して記述しましょう。

2. アドバンスドカスケード

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

アドバンスドカスケード型アーキテクチャでは、コンテキスト対応TTSを導入し、LLMが「安心感を持って話す」「強調して返答する」など、どのように話すかの指示もTTSモデルに渡します。これにより、よりリアルなトーンやスタイルで話せる一方、ベーシックカスケード型と同じガードレールや決定論的フロー、ツール利用、監査性も維持できます。

この方式は、

主な利用例（より表現力豊かな用途）：

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

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

専門的な会話目標

一部のカスケード型アーキテクチャでは、入力音声から得られる発音・感情・トーンなどの音響特徴を、そのまま埋め込みとしてLLMに渡します。この構成により、ユーザーの意図をより多く保持しつつTTSのモジュール性も維持できます。ツール利用やガードレールも可能ですが、ASR+LLMが一体化しているため、テキストでの明確な受け渡しより監査が難しくなり、LLMの入れ替えもカスケード型ほど容易ではありません。

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

4. シーケンシャル融合型

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

シーケンシャル融合型アーキテクチャでは、1つのマルチモーダルモデルが認識・推論・音声生成を担当します。1ターンごとに、ユーザーの発話が終わるまで聞き、直接音声を生成。音声をエンドツーエンドで処理するため、発音や間、イントネーションなどの情報を自然に捉え、より滑らかで表現力豊かな発話が可能です。

ただし、テキスト層がないためガードレールの適用が難しく、推論コアが軽量なためツール利用も制限され、中間出力が見えないため可視性も限定されます。

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

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

5. デュプレックス融合型

ガードレール

デュプレックス融合型アーキテクチャでは、入力と出力を同時に処理します。短い会話でより人間らしい重なり合う発話が実現できる一方、設計が非常に複雑になります。ガードレールの適用が難しく、クロストークや割り込みでエラーが発生しやすく、カスケード型に比べて可視性も最小限です。

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

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

用途に合ったアーキテクチャの選び方

会話型エージェントに万能なアーキテクチャはありません。それぞれに強みとトレードオフがあり、カスケード型の予測性・制御性と、融合型の自然なプロソディのどちらを重視するかで選択が変わります。

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

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