選択的な専門化：本番環境で機能し続けるエージェントの設計方法

デモ品質のエージェントを作ることは、かつてないほど速くなりました。高性能なモデルをつなぎ、いくつかのツールを与えれば、半日もせずに会議の予約、返信文の下書き、指示に応じたレポートの取得を行う仕組みが完成します。問題はその後に始まります。CX担当VP、オペレーション責任者、プラットフォームリードなど、そのエージェントをエンタープライズ規模で機能させる責任を担う人は、やがて壁にぶつかります。デモでは機能していたものが、実際の利用量と重大な業務が伴った途端、遅くなり、予測不能になります。失敗しているのは、たいてい基盤となるプラットフォームではありません。その上に構築されたアーキテクチャです。

ボトルネック：すべてを担う1つのエージェント

最初のエージェントがうまくいくと、機能を追加したくなるのが自然です。ツールを増やす。コンテキストを増やす。責任範囲を広げる。1つの仕事をうまくこなせたなら、10個の仕事もできるはずだ、と考えます。

その考え方がボトルネックを生みます。1つのエージェントが広範な領域にわたり、計画、実行、記憶、振り返りを担うと、複数の問題が同時に起こります。

すべてのステップが1つのコンテキストウィンドウと1回の推論処理の容量を奪い合うため、意思決定は遅くなり、制御も難しくなります。利用可能なツールが増えるほど精度は下がりやすいため、ツール選択の信頼性も落ちます。さらに、最初のステップで生じた小さな誤解が検証されないため、システムは脆弱になります。責任の境界がなければ、初期のエラーが気付かれないまま後続のすべてを損ないます。

最初から最後まで受電する保険金請求を処理する、1つの音声エージェントを想像してみてください。1回の通話で、発信者の本人確認、適切な保険契約の取得、補償内容の確認、請求内容の解釈、支払見込額の算出、対応履歴の記録、人にエスカレーションすべきかの判断まで行う必要があります。デモでは、協力的な発信者と良好な回線であれば、すべてを問題なく処理できます。本番環境では、ノイズの多いモバイル回線で、最初のステップで発信者の氏名を聞き間違えるかもしれません。エージェントはそこから回復できません。誤った保険契約を取得し、発信者にはない補償について自信を持って判断し、購入したことのないプランに対する支払額を案内してしまいます。氏名を聞き取ってから行動に移すまでの間に検証がないため、1つの文字起こしミスが、顧客に口頭で伝える誤った約束になってしまうのです。

規制業界では、これは単なる悪い体験ではありません。責任を伴うコンプライアンス上の問題です。エージェントの保険適格性が本番導入の前提条件になりつつある理由の1つであり、ElevenLabsがAIUCを通じてAI保険の対象となる初の会話型AIプラットフォームとしてElevenAgentsを構築した理由でもあります。

実際に何が壊れたのかに注目してください。エージェントは会話が苦手だったわけではありません。何かを理解してから行動するまでのチェックポイントなしに、すべての責任を単独で抱えていたことが問題でした。必要なのは、目標を小さくすることでも、控えめなエージェントにすることでもありません。構造です。

ここは正確に捉える必要があります。これは主にモデルそのものの限界ではありません。より強力なモデルは可能性を広げますが、構造的な問題を解消するわけではありません。これはシステム設計の問題です。

考え方のモデル：何でも決めるCEOではなく、部門

企業が成長する過程を考えてみてください。CEOがエンジニアリング、マーケティング、人事にまたがるあらゆる意思決定を自ら行えば、会社は立ち行かなくなります。より優秀なCEOを採用しても解決しません。明確な責任範囲を持つ専門チームを作ることで解決します。

同じ考え方がAIシステムにも当てはまります。巨大な1つのエージェントではなく、責任範囲を限定した専門エージェントへとシステムを分割できます。あるエージェントはデータを取得し、別のエージェントはコードを書き、さらに別のエージェントはファクトチェックだけを行います。各エージェントの焦点が絞られるため、個々の判断は低コストで、より速く、信頼しやすくなります。

これに特別なインフラストラクチャは必要ありません。ElevenLabsのプラットフォームであるElevenAgentsには、すでにそのための構成要素が備わっています。中心となる会話エージェント、検索や更新のためのツール呼び出し、対象範囲が変わった際にスムーズに引き継ぐエージェント転送、根拠を保つためのナレッジ検索、そして各要素をつなぐワークフローです。これらを適切に構築する鍵は、すべての責任を1つのプロンプトに詰め込み、うまく機能することを期待するのではなく、これらの基本要素を意図して使うことにあります。

それがマルチエージェントアーキテクチャの魅力であり、適切な種類の業務では実際に効果を発揮します。コンタクトセンターの例を考えると具体的です。昨日の1万件のサポート通話を品質評価したいとします。業務は明確に分割できます。あるエージェントは担当者がコンプライアンススクリプトに従ったかを確認し、別のエージェントは共感性や口調を評価し、別のエージェントはエスカレーションすべきだった通話を抽出し、さらに別のエージェントは顧客の問い合わせ理由を取り出します。これらの判断は互いに依存せず、同じ文字起こしデータに対してすべて並列に実行できます。これはまさにマルチエージェントが力を発揮する形です。各部分は独立しており、読み取り中心の業務であり、判断ごとにコンテキストを分離することで、むしろ判断の精度が高まります。

正直なトレードオフ

マルチエージェントは無条件に得をする仕組みではありません。このアーキテクチャを評価する技術リーダーは、導入を決める前に、連携にかかるコストを慎重に検証すべきです。最も重要な注意点は次のとおりです。

最も一般的な失敗パターンは、コンテキストの断片化です。完全なコンテキストを共有しないエージェントにタスクを分割すると、それぞれのエージェントは部分的な情報に基づいて行動します。その結果、コーディネーターが調整できない形で判断が衝突することがあります。

同じ落とし穴は、ライブ会話にもあります。状態を共有しない交渉エージェントとコンプライアンスエージェントに、債権回収の電話を分担させる場面を想像してください。交渉エージェントは役に立とうとして、顧客に6か月の分割払いプランを提案します。しかし、その提案を知らないコンプライアンスエージェントであれば、その顧客の地域ではこうしたプランは3か月までに制限されているため、却下していたはずです。各エージェントは、それぞれに与えられた範囲では合理的に行動しました。しかし組み合わさることで、企業が履行できない約束を、リアルタイムで実在する相手にしてしまいました。問題はモデルの性能でも、音声レイヤーでもありません。交わることのなかった2つの限定的な視点にありました。

解決策はエージェントを増やすことではありません。会話を一貫した状態で保ち、約束をする前にツールとしてコンプライアンスルールを参照させることです。そうすれば、何かを口に出す前にルールと提案を照合できます。これは設計上の選択であり、高機能なプラットフォームなら簡単に実現できます。

実践的な要点は、選択はタスクによって異なるということです。マルチエージェントは、リサーチ、検索、検証のように、各部分が真に独立した並列の読み取り中心業務で力を発揮します。一方で、1つのコードベースを書くように、すべてが整合していなければならない密結合の業務は苦手です。リアルタイム音声パイプラインのようにレイテンシーが重要な処理では、エージェント間のホップが1つ増えるごとに、限られた時間予算の中で往復時間が増えます。そのため、エージェントを深く連鎖させる構成は、基本的にリスクがあります。ここでインフラストラクチャも重要になります。ElevenAgentsは、音声認識、ターンテイキング、音声生成を単一のスタックに配置しているため、オーケストレーションのオーバーヘッドが加わる前から、ベースラインレイテンシーを最小限に抑えられます。

ROIを実際に左右するもの

エージェントから実際の成果を得ているチームは、通常、最も賢い単一モデルに負荷をすべて任せようとするチームではありません。どこを専門化するか、どこを連続した1つのコンテキストとして保つか、必要なときにエージェントをどう連携させるかについて、意図的なアーキテクチャ上の選択をしているチームです。

言い換えれば、答えが「1つの巨大なエージェント」になることも、「すべてを分割する」ことになることも、ほとんどありません。必要なのは選択的な専門化です。成果はエージェントの数や個々の能力ではなく、適切な場所に境界を設けることで生まれます。業務が密結合でコンテキストを連続的に保つ必要があるなら、1つのエージェントで処理します。業務が並列でコンテキストを明確に分離できるなら、専門エージェントに分割します。

推奨事項

これから始めるプロジェクトでは、最初にアーキテクチャを選ぶべきではありません。まず業務を整理してください。

システムに実際に必要な具体的な能力を挙げます。真に独立している部分と、密結合している部分を区別します。分離されたコンテキストが欠点ではなく利点になる箇所を特定します。たとえば、主要な推論の流れとは別に保ちたいファクトチェック工程です。その上で初めて、責任を別々のエージェントに分割する箇所を決めます。

本番環境のローン返済リマインダー電話では、次のようになります。顧客の言葉、口調、会話のやり取りは密接に結び付いており、ホップが1つ増えるごとに発信者にも分かる遅延が生じるため、ライブ会話は1つの連続したエージェント内で維持します。この会話の中核の周囲に、流れを妨げない責任範囲を限定した専門機能を組み込みます。口座情報と未払い残高を取得するツール呼び出し、支払い提案を口にする前にエージェントが参照するコンプライアンスガードレール、状況に応じた人へのスムーズな転送、そして翌朝に録音を品質とリスクの観点から評価する独立した評価エージェント群です。

会話は密結合なので、全体を維持します。検索、確認、評価は独立しているので、それぞれに境界を設けます。これは分割自体を目的とするのではなく、選択的に専門化するアプローチです。そして、優れたエージェントプラットフォームがすでに提供している基本要素に、そのまま対応します。

こうすれば、不要な連携コストを抱え込むことなく、専門化の利点を得られます。予測可能な挙動、影響範囲を抑えた障害、そして本番環境で偶然見つかるのではなく、意図して選んだ複雑さを持つシステムです。このように使えば、エージェントプラットフォームは規模を拡大するほど不安定になるデモではありません。各部分に明確な役割を与えるほど、より安定するインフラストラクチャです。それこそが、ElevenLabsがElevenAgentsを構築した目的です。