カスケード型 vs 融合型モデル：アーキテクチャが音声エージェントのエンタープライズ対応を左右する理由

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

エージェントのアーキテクチャは、本番環境での安定動作、ビジネス要件への適応、自然な会話の実現に大きく影響します。OpenAIのRealtimeモデルのような融合型アーキテクチャは、短い会話では非常にリアルに聞こえることがあります。しかし、コンプライアンスの徹底や失敗時のデバッグ、より強力なLLMへの切り替えが必要な場合、単一の融合ネットワークでは柔軟な対応が難しくなります。

ElevenLabsでは、先進的なカスケード型アーキテクチャを採用しています。音声認識・推論・音声生成の各専用コンポーネントを活用し、高い知能と信頼性を実現しています。さらに、文脈に応じたプロソディ（抑揚）、低遅延化、インテリジェントなターンテイクを重ねることで、自然な会話の流れを作り出しています。エンタープライズや政府機関が求める「リアルな音声」と「本番環境で信頼できる複雑なタスク対応」を両立するために、この設計を選びました。

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

アーキテクチャ選定時にチームが重視するポイント

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

複雑なタスクに対応できるか？ 

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

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

本番環境で信頼できるか？

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

カスケード型と融合型アーキテクチャのトレードオフ ツールが増えるほど、正しい順序でツールを呼び出すためのモデルの推論負荷も高まります。Agent Builderでは、ツールの説明欄にツールの機能や返却フィールドが記載されます。これが、言語モデルが利用シーンを理解するための情報となります。ツールの呼び出し条件は、エージェントのシステムプロンプトに記述します。例：

• lookup_orderのツール説明： 「注文IDで顧客の注文詳細を取得します。注文状況、購入商品、配送先住所、追跡番号を返します。」
• 音声認識（Speech to Text）「顧客の本人確認後、lookup_orderツールを呼び出して注文詳細を取得してください。」

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

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

カスケード型アーキテクチャの長年の課題は、プロソディ（抑揚など）の情報が失われやすいことです。音声がテキスト化されるため、イントネーションやリズム、感情は出力側で再構築する必要があります。明示的なモデリングで一部は再現できますが、融合型ほど自然にはなりません。その他、レイテンシやターンテイクなどは、どちらの方式でも最適化可能です。動的変数としてエージェントの保存情報に反映することも可能です。保存情報は、ツールのレスポンスから事前定義されたマッピングで抽出したシンプルなキーと値のペアとして管理されます。設定後は、これらの変数をシステムプロンプトや今後のツールパラメータ、ワークフロー条件に活用できます。このフィードバックループにより、エージェントはやり取りを通じて進化するワーキングメモリを持つことができます。

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

融合型アーキテクチャは、根本的に異なるアプローチです。認識・推論・生成がすべて単一のマルチモーダルネットワーク内で行われます。音声が入力され、音声が出力され、その間に確認できる層はありません。

中間ステージがないことは、魅力であると同時に制約でもあります。融合型アーキテクチャは、音声がテキストに分解されないため、自然なプロソディ（韻律）をそのまま保持できます。一方で、ガードレールの徹底や個別コンポーネントの入れ替え、中間出力の確認・デバッグが難しくなります。また、業界特有の用語に合わせてSTTを微調整したり、より強力な推論やツール呼び出しのために別のLLMを組み込むことも制限されます。システムは1つのネットワークで構成されており、チームはそのネットワークが持つ推論能力に縛られます。現状では、軽量なコアが中心となり、複雑なタスクでは最先端LLMに及びません。

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

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

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

音声をテキスト化し、LLMがテキストで返答を生成、TTSが読み上げます。すべてのステージがテキストで処理されるため、内容の確認・テスト・制御が容易です。

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

主なユースケース：

この方式は、

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

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

• システムプロンプトとサブエージェントの会話目標の連携
• エクスプレッシブモード

LLMはTTSに「何を話すか」だけでなく、「どう話すか」も指示します。たとえば「安心感を持って」「強調して」「緊急性を持って」など、会話中にトーンを動的に変化させます。ターンテイクシステムも同じ信号を活用し、応答や譲るタイミングを判断します。音声モデルは1つのスタック内に集約され、ネットワーク遅延も最小限です。

ベーシックカスケード型の特徴（透明性・テキスト層ガードレール・コンポーネントの入れ替え・ドメインチューニング・最強の推論/ツール呼び出しモデル利用）をすべて維持しつつ、プロソディ・レイテンシ・ターンテイクが大幅に向上します。新しい最先端LLMの即時統合や、医療用語に合わせたSTTの微調整も他のコンポーネントを再構築せずに可能です。

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

3. ハイブリッドカスケード＆融合型

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

一部のアーキテクチャでは、入力音声から得られる音響特徴（発音・感情・トーンなど）を、まずテキスト化せずに埋め込みとしてLLMに直接渡します。TTSはモジュール型のままです。

これにより、LLMは

主なユースケース：

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

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

ガードレール

単一のマルチモーダルモデルが認識・推論・生成を一度に一ターンずつ処理します。

プロソディの再現性は高く、音声がテキスト化されないため、ペースやイントネーション、感情表現が自然に残ります。短い会話では非常に滑らかに聞こえます。

ただし、テキスト層がないためガードレールの徹底が難しく、中間出力によるデバッグやLLMの入れ替え、STTのドメインチューニングも制限されます。推論コアは最先端LLMより軽量なことが多く、複雑なツール呼び出しや多段階タスクには不向きです。複雑な課題解決には、プロソディだけでは不十分です。

主なユースケース：

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

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

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