選択的な専門化：本番環境で通用するエージェントの設計方法

執筆者: Adarsh Shiragannavar
公開日: 2026年7月6日

聴くこの記事を聴く

0:00

0:000:00

デモレベルのエージェントを作るのは、これまでになく簡単になりました。高性能なモデルをつなぎ、いくつかのツールを与えれば、午後のうちにミーティングの予約や返信の下書き、レポートの取得などができるものが完成します。問題はその後にやってきます。CX担当VPやオペレーション責任者、プラットフォームリードなど、本番環境でエージェントを動かす責任者が壁にぶつかります。デモでうまくいったものが、実際のボリュームや重要な場面になると急に遅くなったり、不安定になったりします。多くの場合、基盤となるプラットフォームが原因ではありません。その上にあるアーキテクチャが問題なのです。

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

最初のエージェントがうまく動くと、つい機能を追加したくなります。もっと多くのツール、もっと多くの情報、より広い役割。1つの仕事ができたなら、10個でもできるはずだと考えてしまいます。

しかし、その発想がボトルネックを生みます。1つのエージェントが広い範囲で計画・実行・記憶・振り返りまで全てを担当すると、いくつかの問題が一度に発生します。

意思決定が遅くなり、コントロールもしづらくなります。なぜなら、すべてのステップが1つのコンテキストウィンドウと1回の推論に詰め込まれるからです。ツールの選択も信頼性が下がります。利用できるツールが増えるほど、精度が落ちやすくなるためです。また、システム自体も脆弱になります。最初のステップで小さな誤解があっても、そのまま見過ごされてしまいます。役割の境界がないため、初期のミスが静かに後のすべてを台無しにしてしまうのです。

例えば、保険請求の受付を最初から最後まで担当する1つのボイスエージェントを想像してください。1回の通話で、発信者の本人確認、適切な保険契約の取得、補償範囲の確認、請求内容の解釈、支払い見積もり、やり取りの記録、必要に応じて人間へのエスカレーションまで行います。デモでは、協力的な発信者とクリアな回線なら問題なくこなせます。しかし本番では、ノイズの多い携帯電話で最初に名前を聞き間違えた時点で、エージェントは立て直せません。間違った契約を取得し、持っていない補償について自信満々に説明し、購入していないプランの支払い額を提示してしまいます。名前を聞いてから行動に移すまで何のチェックポイントもなかったため、1つの文字起こしミスがそのまま顧客への誤った約束になってしまいました。

規制業界では、これは単なる悪い体験ではなく、責任が伴うコンプライアンス上の問題になります。そのため、エージェントの保険加入がプロダクション導入の前提条件になりつつあり、ElevenAgentsをAI保険の対象となる初の会話型AIプラットフォームとして開発しました（AIUC経由）。

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

ここは正確に伝えたいポイントです。これは主にモデル自体の限界ではありません。より強力なモデルは上限を引き上げますが、構造的な問題を解決するわけではありません。これはシステム設計の問題です。

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

これらのために特別なインフラは必要ありません。ElevenAgentsはすでに

これがマルチエージェントアーキテクチャの魅力であり、適切な用途では本当に効果を発揮します。コンタクトセンターの例で考えてみましょう。昨日の1万件のサポート通話を品質評価したい場合、作業はきれいに分割できます。1つのエージェントがコンプライアンススクリプトの順守を確認し、別のエージェントが共感やトーンを評価、さらに別のエージェントがエスカレーションすべき通話をフラグ付けし、また別のエージェントが顧客の問い合わせ理由を抽出します。これらの判断は互いに依存せず、同じ通話記録で並行して実行できます。まさにマルチエージェントが得意とする形です。各パートが独立しており、読み取り中心の作業で、個別のコンテキストで判断を分離することで精度も高まります。

ホストアプリケーション認証

これがマルチエージェントアーキテクチャの魅力であり、適切な業務では実際に効果を発揮します。例えばコンタクトセンターの場合、昨日の1万件のサポート通話を品質評価したいとします。作業は明確に分割できます。あるエージェントは担当者がコンプライアンススクリプトに従ったかを確認し、別のエージェントは共感やトーンを評価し、さらに別のエージェントはエスカレーションが必要だった通話をフラグし、また別のエージェントは顧客が電話した理由を抽出します。これらの判断は互いに依存せず、同じ通話記録で並行して実行できます。これこそがマルチエージェントが得意とする形です。各パートは独立しており、作業は読み取り中心で、判断を個別の文脈で行うことで、より鋭い結果が得られます。

正直なトレードオフ

Documentation on Dynamic Variables:

https://elevenlabs.io/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime

マルチエージェントは万能ではありません。このアーキテクチャを検討する技術リーダーは、導入前に連携コストをしっかり見極めるべきです。最も重要な注意点はここにあります。

よくある失敗パターンは、コンテキストの分断です。エージェント同士が完全な情報を共有せずにタスクを分担すると、それぞれが部分的な視点で動き、調整役が解決できない矛盾が生じることがあります。

この落とし穴は、リアルタイムの会話でも起こります。例えば、回収業務の通話を交渉エージェントとコンプライアンスエージェントに分け、状態を共有しない場合を想像してください。交渉エージェントは親切心から顧客に6か月の分割払いを提案しますが、コンプライアンスエージェントはその提案を見ていないため、顧客の地域では3か月までしか認められていないことから却下したはずです。それぞれのエージェントは自分の役割では正しく動いていますが、結果として会社が守れない約束をリアルタイムで顧客にしてしまいました。これはモデルの弱さや音声レイヤーの問題ではなく、2つの狭い視点が交わらなかったことが原因です。

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

実際にROIを生むもの

エージェントで本当に成果を出しているチームは、最も賢いモデル1つに頼るのではなく、どこを専門化し、どこを一続きのコンテキストに保ち、必要なときにどう連携させるかを意図的に設計しています。

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

おすすめの進め方

新しいプロジェクトでは、まずアーキテクチャを決めるのではなく、作業内容を整理することが大切です。

実際のローン返済リマインダーの例を挙げます。リアルタイムの会話は1つのエージェント内で完結します。なぜなら、顧客の発言やトーン、やり取りが密接に関連し、エージェントを増やすごとに遅延が発生し、顧客に伝わってしまうからです。その会話のコアの周りに、流れを妨げない範囲で専門エージェントを配置します。例えば、アカウント情報や未払い残高を取得するツール呼び出し、支払い提案前に参照するコンプライアンスガードレール、必要な場合に人間へスムーズに転送する仕組み、翌朝に録音を品質やリスクで評価するバッチ処理のエージェント群などです。

会話は連続性があるため、全体としてまとまります。一方で、検索やチェック、スコアリングは独立しているので、それぞれに境界を持たせます。これは単なる分割ではなく、必要な部分だけを専門化するやり方で、優れたエージェントプラットフォームが提供する基本機能にそのまま当てはまります。

こうすることで、専門化のメリットを得ながら、不要な調整コストを避けられます。予測しやすい動作、限定的な障害、そして意図的に設計した複雑さを持つシステムが実現できます。このように使えば、エージェントプラットフォームはスケールするほど不安定になるデモではなく、各パートに明確な役割を与えるほど安定するインフラになります。これがElevenAgentsを開発した理由です。

会話は密接に関連しているので一つにまとめます。検索やチェック、スコアリングは独立しているので、それぞれに境界を設けます。これは単なる分割ではなく、選択的な専門化であり、優れたエージェントプラットフォームがすでに提供している基本要素に直結します。

ドキュメントはこちら：https://elevenlabs.io/docs/eleven-agents/customization/agent-workflows#edges-and-flow-control

ワンタイムコード

この方法は汎用的で、ワンタイムコードをSMSやメールでユーザーの端末に送信します。ユーザーはそのコードをエージェントに伝え、認証を受けてアクセスします。

実装ワークフロー：

コード生成：エージェントがサーバーツールコールで専用エンドポイントにリクエストし、安全なワンタイムコードを生成して、ユーザーの希望するチャネル（SMSやメール）に送信します。
ユーザープロンプト：エージェントがユーザーに受け取ったコードの入力を求めます。音声モードでは、ユーザーがコードを口頭で伝え、音声認識で取得します。
コード検証：エージェントがユーザー入力のコードを2回目のツールコールでバックエンドの検証サービスに送信します。バックエンドはコードが一致し、有効期限切れや既使用でないかを確認します。
ワークフロー分岐：エージェントは検証結果に応じて処理します。成功：コードが正しければ、成功条件で認証後のワークフローへ進みます。失敗：コードが間違っていれば、再入力を促すか、リカバリー手順（例：新しいコード送信）を実行します。

セキュリティ考慮点：総当たり防止のためレート制限を設け、コードの有効期限は3～5分程度にし、再試行回数も管理・制限してください。音声認識の場合は、コード取得時の確認プロンプトも検討しましょう。

まとめ

これらの認証方法は柔軟な構成要素であり、決まった解決策ではありません。選択肢はリスクプロファイルや規制要件、ユーザー体験の目標に合わせて選んでください。カスタマーサービスボットと銀行取引を扱うアシスタントでは必要なセキュリティが異なります。プラットフォームの柔軟性により、脅威や要件の変化に合わせてセキュリティ戦略を進化させ、常に保護とユーザー体験のバランスを保てます。