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

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

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

最初のエージェントがうまくいくと、さらに多くを与えたくなるのが自然です。ツールを増やす。コンテキストを増やす。責任範囲を広げる。1つの仕事をうまく処理できたなら、10個だってできるはずです。

しかし、その発想がボトルネックを生みます。1つのエージェントが広範な領域で、計画、実行、記憶、振り返りのすべてを担うと、いくつもの問題が同時に起こります。

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

最初から最後まで受信する保険金請求を処理するために構築された、1つの音声エージェントを想像してください。1回の通話で、発信者の本人確認、適切な保険契約の取得、補償内容の確認、請求内容の解釈、想定支払額の見積もり、やり取りの記録、人間の担当者へエスカレーションすべきかの判断まで行う必要があります。回線がクリアで協力的な発信者を相手にするデモでは、すべてを問題なく処理できます。本番環境では、ノイズの多い携帯電話回線で、最初のステップで発信者の名前を聞き間違えるかもしれません。すると、エージェントは立ち直れません。誤った保険契約を取得し、発信者には存在しない補償について自信を持って判断し、購入したことのないプランの支払額を提示してしまいます。名前を聞き取ることと、それに基づいて行動することの間に何のチェックもないため、たった1つの文字起こしミスが、顧客に口頭で伝えられる誤った約束になってしまうのです。

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

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

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

考え方の基本：すべてを決めるCEOではなく、部門

企業が成長する仕組みを考えてみましょう。CEOがエンジニアリング、マーケティング、人事にまたがるすべての判断を自ら下していたら、会社は停滞します。より優秀なCEOを採用しても解決しません。役割範囲が明確な専門チームを作ることで解決します。

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

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

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

正直なトレードオフ

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

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

同じ罠はライブ会話にもあります。状態を共有しない交渉エージェントとコンプライアンスエージェントに、回収の電話を分担させるケースを想像してください。交渉エージェントは役に立とうとして、顧客に6か月の支払いプランを提案します。しかし、その提案を見ていないコンプライアンスエージェントなら、顧客の地域ではそのようなプランは3か月までに制限されているため、却下していたでしょう。各エージェントは、自分に与えられた範囲では合理的に振る舞っています。しかし、組み合わさると、会社が守れない約束をリアルタイムで実在の人物にしてしまいます。問題はモデルの弱さでも、音声レイヤーでもありません。決して交わらなかった、2つの狭い視点です。

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

実務上の要点は、選択がタスクに依存するということです。マルチエージェントは、調査、検索、検証のように、各部分が真に独立した並列の読み取り中心タスクで力を発揮します。一方、1つのまとまったコードを書くように、すべてに一貫性が求められる密結合の作業では苦戦します。リアルタイム音声パイプラインのようにレイテンシーに敏感な処理では、エージェント間のホップが1つ増えるたびに、限られた予算の中で往復時間が加わります。そのため、深いエージェントチェーンはデフォルトでリスクがあります。ここでインフラストラクチャも重要になります。ElevenAgentsは、音声認識、ターンテイキング、音声生成を単一のスタックに統合しているため、オーケストレーションのオーバーヘッドが加わる前から、ベースラインのレイテンシーを最小限に抑えています。

ROIを実際に左右するもの

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

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

推奨事項

今後のプロジェクトでは、最初にアーキテクチャを選ぶべきではありません。まず作業を整理してください。

システムに実際に必要な具体的な機能を列挙します。真に独立している部分と、密結合している部分を区別します。分離されたコンテキストが、負債ではなく利点になる場所を特定します。たとえば、メインの推論スレッドとは切り離しておきたいファクトチェックの工程です。そのうえで初めて、責任を別々のエージェントに分ける場所を決めます。

本番運用のローン返済リマインダー回線では、次のようになります。顧客の言葉、口調、やり取りは密結合であり、ホップが1つ増えるごとに発信者に聞こえる遅延が加わるため、ライブ会話は1つの連続したエージェント内にとどめます。その単一の会話コアの周囲に、フローを妨げない、範囲を限定した専門機能を付加します。口座と未払残高を取得するツール呼び出し、支払い提案を口にする前にエージェントが参照するコンプライアンスガードレール、状況に応じた人間へのスムーズな転送、そして翌朝に録音を品質とリスクの観点から評価する、独立した評価エージェント群です。

会話は密結合なので、全体を一貫して保ちます。検索、チェック、評価は独立しているため、それぞれに独自の境界を設けます。これは分割自体を目的とするのではなく、選択的に専門化するアプローチであり、優れたエージェントプラットフォームがすでに提供するプリミティブに直接対応します。

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