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

多くの人は、音声エージェントがカスケード型または融合型のアーキテクチャで構築されると考えています。実際には、エージェントは両者の間にある連続的な設計の中で構築され、用途に応じて通常5つのアーキテクチャが使われます。

エージェントのアーキテクチャは、本番環境での信頼性の高い動作、特定のビジネス要件への適応、自然な会話を左右します。OpenAIのRealtimeモデルのような融合ベースのアーキテクチャは、短い会話では驚くほど生き生きとした印象を与えるかもしれません。しかし、コンプライアンスのガードレールを適用したり、失敗した応答をデバッグしたり、来月より強力なLLMが登場したときに差し替えたりする必要がある場合、単一の融合ネットワークではできることが限られます。

ElevenLabsでは、高度なカスケードベースのアーキテクチャを採用しています。音声認識、推論、音声生成に特化したコンポーネントを活用し、高い知能と信頼性を実現します。さらに、文脈に応じたプロソディ、低レイテンシー最適化、インテリジェントなターンテイキングを組み合わせ、自然に会話が流れるようにしています。この設計を選んだのは、私たちが支援する企業や政府機関が、リアルな音声で複雑なタスクを本番環境でも安心して任せられるエージェントを必要としているためです。 

この記事では、主要な5つのアーキテクチャ、それぞれの得意分野と限界、そして重要なワークフローに導入するエージェントの基盤についての考え方を解説します。

アーキテクチャ選定時にチームが評価すること

チームが検討する項目は、通常3つのカテゴリーに分かれます。

複雑なタスクを処理できるか？

• 推論とモデルの柔軟性： ユースケースに最適なモデルを選び、利用可能な最も強力なLLMも含めて、より優れた選択肢が登場したらアップグレードできますか？
• エージェントロジック： エージェントが従う会話フロー、意思決定ルール、エスカレーション経路を定義・制御できますか？
• ツール利用： アーキテクチャは、複数ステップのツール呼び出しや外部システムとのインテグレーションをサポートできますか？

人間らしく聞こえ、感じられるか？

• プロソディ： エージェントは自然なリズム、イントネーション、感情的なトーンで話せますか？
• レイテンシー： 応答は会話として自然に感じられるほど速いですか？
• ターンテイキング： エージェントは、話す、間を置く、相手に発話を譲るタイミングを把握していますか？

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

• 信頼性： エージェントは予測可能かつ一貫して動作しますか？それとも時間とともに逸脱しますか？
• ガードレール： アーキテクチャは、意図しない応答や敵対的なユーザーから保護できますか？
• 透明性： アーキテクチャは中間出力を生成しますか？それともブラックボックスですか？

カスケード型と融合型アーキテクチャのトレードオフ

カスケードベースのアーキテクチャは、特化したコンポーネントを連結して構築されます。スピーチtoテキスト（STT）、大規模言語モデル、そしてテキスト読み上げ（TTS）です。各段階は独立して最適化、テスト、アップグレードできます。 

カスケード型アーキテクチャ

このモジュール性こそが、カスケード型アーキテクチャを大半のエンタープライズグレードのエージェントの基盤にしています。各段階で検査可能な出力が生成されます。STTとLLMの間、LLMとTTSの間には、人が読めるテキストがあります。テキスト層でガードレールを適用でき、音声モデルを変更せずに最新のフロンティアLLMを統合でき、問題が発生したときも一般に原因を特定できます。

カスケード型アーキテクチャへの長年の批判は、プロソディの手がかりが失われる点です。音声はテキストに変換され、イントネーション、リズム、感情は出力時に再構築する必要があります。こうした手がかりは明示的なモデリングによって一部を取り戻せますが、融合型アプローチほど自然には捉えられません。レイテンシーやターンテイキングなどの他の要素は、通常どちらのアプローチでも同等の性能レベルまで最適化できます。

融合モデル

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

中間段階がないことは、魅力であると同時に制約でもあります。音声がテキストへ分解されないため、融合型アーキテクチャはプロソディの手がかりを自然に保持できます。一方で、ガードレールの適用、個々のコンポーネントの差し替え、デバッグのための中間出力の検査には限界があります。また、業界固有の用語に合わせたSTTの微調整や、より強力な推論とツール呼び出しのための別のLLMの統合にも制約があります。システムは単一のネットワークであり、チームは搭載されている推論能力に制限されます。現時点では、複雑なタスクでフロンティアLLMに匹敵できない軽量なコアを意味します。

5つのアーキテクチャ

1. 基本カスケード型

オーディオを文字起こしし、LLMがテキストで回答を生成し、TTSがそれを読み上げます。すべての段階がプレーンテキストで動作するため、すべてを確認、テスト、制御できます。

信頼性における利点は明確です。テキスト層でのガードレール、決定論的な会話フロー、完全な監査証跡を実現できます。LLMは独立したコンポーネントなので、最も強力な推論またはツール呼び出し能力を持つフロンティアモデルとエージェントを組み合わせ、より優れたモデルが登場した時点ですぐにアップグレードできます。弱点は会話品質です。文脈対応TTSがなければ、エージェントの音声は機能的ではあっても平板です。感情への適応やプロソディの変化がないため、口座残高の読み上げには許容できても、不満を抱えた顧客への対応には不十分です。

ユースケースの例：

• 通信・公益事業におけるIVRの置き換え
• SaaSオンボーディングでのFAQ対応
• 温かみよりも一貫性が重視される、予約確認、処方箋のリマインダー、配送通知などのアウトバウンド通知

2. 高度なカスケード型

同じモジュール型アーキテクチャですが、複数のコンポーネントがより豊富な文脈で動作します。これはExpressive ModeをElevenAgentsで構築した方法です。

Scribe v2 Realtime STTモデルは、会話のこれまでの文脈を活用して高速かつ正確な文字起こしを生成します。LLMはテキストをもとに、何を言うかだけでなく、どのように話すかをTTSに指示します。たとえば「安心させるように」「強調して」「緊急性をもって」といった指示で、会話全体を通じてトーンを動的に調整します。ターンテイキングシステムも同じシグナルを利用し、エージェントが応答すべきタイミングと相手に発話を譲るタイミングを判断できます。音声モデルはコンポーネント間のネットワークホップなしに単一スタック内へ配置されるため、レイテンシーを低く保てます。

このアーキテクチャは、基本カスケード型のすべてを維持しています。完全な透明性、テキスト層のガードレール、コンポーネントの交換可能性、ドメインチューニング、利用可能な最強のツール呼び出し・推論モデルへのアクセスです。さらに、大幅に優れたプロソディ、レイテンシー、ターンテイキングを実現します。チームは、新しいフロンティアLLMをリリースされた週に統合したり、ほかのコンポーネントを再構築せずに医療向けSTTを医療用語に合わせて微調整したりできます。

ユースケースの例：

• 不正請求に関する通話での共感的な応対と、厳格なコンプライアンスガードレールおよび完全なインタラクションログを両立する金融サービスのカスタマーサポート
• 適切な緊急度、HIPAA準拠のフロー、医療用語向けにドメインチューニングされた音声認識で患者の電話をトリアージする医療受付
• 構造化されたプレイブックに従い、CRMに更新を反映しながら、温かく説得力のあるトーンを保つ営業アシスタント

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

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

これによりLLMは、何が言われたかだけでなく、どのように言われたかについても、より豊富な入力を得られます。これは特定のアプリケーションで価値があります。中間表現は人間が読めるものではなく埋め込みであるため、融合されたASR+LLMブロックは、明確なテキストの受け渡しよりも監査が困難です。また、LLMを簡単に差し替えられなくなるため、推論とツール呼び出しの能力は、融合ブロックの構築時に採用されたモデルに制約されます。

ユースケースの例：

• 生徒がどのように話すかを聞くことが、何を話すかと同じくらい重要な語学学習や発音コーチング
• 不満の検出は重要だが、タスク自体はシンプルな、低複雑性のトーンセンシティブなサポート。

4. 順次融合型

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

プロソディは優れたものになり得ます。音声がテキストに分解されないため、モデルはペース、イントネーション、感情的な手がかりを自然に維持します。短い会話なら、驚くほど滑らかに聞こえます。

ただし、テキスト層なしでガードレールを適用する能力、中間出力によるデバッグ、より優れたLLMへの差し替えやドメイン向けSTTの微調整の柔軟性には限界があります。推論コアはフロンティアLLMより軽量である傾向があり、複雑なツール呼び出しや複数ステップのタスクには不利です。複雑な問題解決が必要なタスクでは、プロソディだけでは不十分です。

ユースケースの例：

• 表現力がエンゲージメントを促進し、コンプライアンス要件が最小限のパーソナルコンパニオン、エンターテインメントチャットボット、アプリケーション。

5. 双方向同時融合型

入力と出力を同時に処理し、モデルは聞きながら話します。実際に発話が重なり、ターン移行も滑らかになるため、短いやり取りを驚くほど自然に感じさせることができます。

一方で、最も制御が難しいアーキテクチャでもあります。ガードレールの適用は非常に困難で、クロストークが予測不能なエラーを引き起こします。検査、ログ記録、デバッグは極めて難しく、システムは大部分がクローズドで、コンポーネントの差し替え、ドメインチューニング、カスタマイズの選択肢はほとんどありません。同時処理により複雑なロジックに割ける容量が少なくなるため、推論とツール利用は順次融合モデルよりもさらに制約されます。また、短いやり取りを自然に聞かせる同じ同時処理が、長い会話を不安定にします。

ユースケースの例：

• 予測不能な動作を許容できる、実験的なコンパニオンアプリ、ソーシャル音声プラットフォーム、研究デモ。

ユースケースに適したアーキテクチャの選び方

適切なアーキテクチャは、対象のアプリケーションに必要な要件によって決まります。自然に聞こえる音声が主要な機能の体験を構築する場合、フロンティアレベルの推論、ガードレール、透明性を妥協できるなら、融合型アーキテクチャには確かな強みがあります。融合モデルはプロソディで先行していますが、高度なカスケード型システムは四半期ごとに差を縮めています。一方、融合モデルはアーキテクチャレベルの制約により、複雑な推論や信頼性では大きな進歩を遂げていません。

大半の企業や政府機関にとって最適なアーキテクチャは、優れた音声に加え、高い能力、カスタマイズ性、信頼性、そして大規模導入への対応を備えたものです。だからこそ、ElevenAgentsを高度なカスケード型アーキテクチャで構築し、Expressive Modeと、最高水準で共同最適化されたスピーチtoテキストおよびテキスト読み上げモデルに投資しています。これによりチームは、エージェントを構築し、自然で人間らしい音声と、高度な知能、信頼性、制御性を両立できます。

AIエージェントがカスタマーサポート、教育、パーソナルアシスタントなどへと広がり続ける中、成功するエージェントは、それぞれの用途に合わせたアーキテクチャの上に構築されるでしょう。