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

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

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

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

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

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

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

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

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

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

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

会社が成長する過程を考えてみてください。CEOがエンジニアリング、マーケティング、人事のすべてで自ら意思決定していたら、会社は停滞します。より優秀なCEOを採用しても解決しません。明確な担当範囲を持つ専門チームを作ることで解決します。

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

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

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

正直なトレードオフ

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

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

同じ罠はライブの会話にも現れます。状態を共有しない交渉エージェントとコンプライアンスエージェントに、債権回収の電話対応を分割したとしましょう。役に立とうとした交渉エージェントは、顧客に6か月の分割払いプランを提示します。その提案を見ていないコンプライアンスエージェントなら、顧客の地域ではそのようなプランは3か月までに制限されているため、却下していたはずです。各エージェントは、それぞれに与えられた範囲では合理的に振る舞いました。しかし一緒になると、企業が履行できない約束を、リアルタイムで実在の人にしてしまいました。問題は弱いモデルでも音声レイヤーでもありません。交わることのなかった2つの狭い視点でした。

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

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

ROIを実際に左右するもの

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

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

推奨事項

これからのプロジェクトでは、最初にアーキテクチャを選ぶのではありません。まず業務を整理します。

システムに実際に必要な具体的な能力をリストアップしてください。真に独立している部分と、密に結び付いている部分を明確にします。分離されたコンテキストが、負債ではなく利点になる箇所を特定します。たとえば、主要な推論の流れから切り離しておきたいファクトチェック工程です。そのうえで初めて、責任を別々のエージェントに分割する場所を決めます。

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

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

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