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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

率直なトレードオフ

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

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

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

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

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

ROIを実際に左右するもの

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

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

推奨事項

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

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

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

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

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