9月9日、The Next Webが「How multi-agent AI is redefining enterprise software」と題した記事を公開した。この記事では、WorkdayのプロダクトマネージャーであるSwaroop Borukarの視点から、マルチエージェントAIがエンタープライズソフトウェアを「記録するシステム」から「行動するシステム」へと転換しつつある実態について詳しく紹介されている。チャットボットや「コパイロット」型AIが一巡した今、なぜ単一エージェントでは企業の複雑な業務フローに対応できないのか——その問いへの答えが、マルチエージェント・アーキテクチャという設計思想の根本的な転換にある。

「質問に答えるAI」では足りない理由

エンタープライズ向けの生成AI第一世代は、チャットボットやコパイロット型が主流だった。ユーザーが質問し、AIが情報を返し、次の判断は人間が行う。このモデルは依然として有用だが、複雑な業務フローには対応しきれない。

例えば顧客サービスの対応一つとっても、アカウント履歴の確認、契約条件のチェック、解決策の特定、チケット更新、他部署への連絡と、複数のステップが連鎖する。単一のAIアシスタントは個々のステップを補助できても、ワークフロー全体を調整するには力不足だ。

現代の企業はCRM、財務システム、プロジェクト管理ツール、社内データベース、コミュニケーションアプリなど、数十から数百の相互接続されたアプリケーションをまたいで業務を動かしている。それぞれが固有の権限設定、データ構造、業務ルールを持つ。

「汎用の単一エージェントは、複雑なエンタープライズ環境に必ずしも最適なアーキテクチャではない。専門化されたエージェントは特定の機能、権限、業務ルールに基づいて設計できるため、システム全体の制御性・観測性・信頼性が向上する」
— Swaroop Borukar（Workday、プロダクトマネージャー）

ここで登場するのがマルチエージェント・オーケストレーションだ。情報取得、分析、アクション決定、ポリシー検証といった責務をエージェントに分担させる。重要なのは「複数のAIモデルを並列実行する」ことではなく、エージェントが定義された役割を持ち、互いに制御された方法で協調するアーキテクチャを構築することだ。

この方向性はWorkdayに限らず、エンタープライズSaaS全体のトレンドでもある。SalesforceはCRMワークフローへの自律型AI組み込みを目指す「Agentforce」を発表し、ServiceNowもNow Assistにおいてエージェント的な業務自動化を強化している。各社が独自のアーキテクチャでマルチエージェント化を推進しており、エンタープライズSaaSにおける「エージェント設計力」が競争の主戦場となりつつある。

アーキテクチャの内側：オーケストレーション層が鍵

よく設計されたマルチエージェントシステムは、従来のチャットボットより「組織」に近い構造を持つ。中核となるのはオーケストレーション層だ。どのエージェントがどのタスクを担当し、どの情報を受け取り、完了後に何が起きるかを制御する。

専門化することには実用的な利点がある。財務照合専用のエージェントは、顧客対応エージェントとは異なるルールのもとで動作できる。コンプライアンス担当エージェントが提案されたアクションを検証してから、別のエージェントが実行するという流れも組める。

「エージェントの知能はあくまで方程式の一部に過ぎない。エンタープライズシステムには、強固なオーケストレーション、明確に定義されたインターフェース、データとツールへのセキュアなアクセス、そしてワークフロー全体にわたる観測性も必要だ。これらの基盤がなければ、エージェントを増やすことは複雑性を増やすだけになる」
— Swaroop Borukar

オーケストレーション自体もエンジニアリング上の難題を抱える。エージェント間の通信、矛盾する推奨結果、不完全な情報、誤った前提に基づく判断への対処が必要で、エラー検出と人間へのエスカレーションの仕組みも欠かせない。マルチエージェントAIはAIの問題であると同時に、分散システムのエンジニアリング問題でもある。

なお、マルチエージェントシステムの設計パターンや標準化の動向については、LangChainやAutoGen（Microsoft）といったオープンソースフレームワークの実装が参考になる。エージェント間通信の標準化に向けたAnthropicのModel Context Protocol（MCP）も、この領域での注目仕様の一つだ。

ガードレール設計：「自律性」はエンジニアリングするもの

AIに「答えを生成する」能力を与えることと、「エンタープライズ環境で何かを変更する」能力を与えることは根本的に異なる。誤った要約は不便だが、誤った支払い処理や顧客アカウントの変更は深刻な結果を招く。

Swaroop氏はこう言い切る。

「エンタープライズ環境における自律性は、前提とするものではなく、エンジニアリングするものだ」
— Swaroop Borukar

具体的なガードレールとして記事が挙げるのは以下の3点だ：

• 権限の最小化：エージェントは割り当てられた責務に必要な情報とツールにのみアクセスできる
• 人間によるオーバーサイト：すべてのアクションに承認は不要だが、高リスクな決定は自動的に人間にルーティングする閾値を設ける
• 監査可能性：エージェントが何をしたか、どの情報が意思決定に影響したか、他のどのエージェントやシステムが関与したかを追跡できる

自律性は「オン/オフのスイッチ」ではなくスペクトラムとして設計する。リスクの低い反復タスクはエンドツーエンドで自動化し、影響の大きいアクションは検証や人間の承認を必須とする構成が現実的な導入経路になる。

インフラ経済学：見落とされがちなコスト問題

記事がとくに強調するのが、技術者以外にはあまり語られないインフラコストの問題だ。

単一のAIインタラクションを実行するのは比較的単純だ。しかし複数エージェント、繰り返されるモデル呼び出し、検索システム、ツール実行、検証プロセスを伴う複雑なエージェンティックワークフローは、大幅に多くの計算リソースを要する。

「マルチエージェントシステムは異なるインフラ課題をもたらす。1つのタスクがモデル呼び出し、ツール実行、下流のアクションの連鎖を引き起こす可能性があるからだ。アーキテクチャはレイテンシ、キャパシティ、コストを考慮しつつ、ワークフローの各部分に適切なモデルを使うよう設計する必要がある。すべてのタスクを計算コストが同等であるかのように扱ってはならない」
— Swaroop Borukar

全タスクで最強のモデルを使う必要はない。シンプルな処理は小型・高速なモデルに、複雑な推論は大規模モデルにルーティングする構成が合理的だ。ロードバランシング、キューイング、キャッシング、フォルトトレランスといった分散システムの古典的な知見がそのままAIアーキテクチャに適用できる局面が増えている。

「記録するシステム」から「行動するシステム」へ

記事の核心にあるのは、エンタープライズソフトウェアの役割定義の転換だ。

従来のSaaSは「従業員が情報を見つけ、入力し、整理し、分析する」ことを支援してきた。マルチエージェントAIはその情報を解釈し、ワークフローの実行に参加する可能性を開く。

Swaroop氏はこの転換の先を見据え、エンタープライズSaaSの設計思想そのものが変わる可能性を示唆する。画面やフォームを中心とした設計から、ゴール・エージェント・ツール・権限・アウトカムを中心とした設計へ。

競争優位の源泉はどのモデルを使うかではなく、そのモデルの周囲に何を構築するか、つまりオーケストレーション、信頼性、セキュリティ、データアクセス、インフラ経済学の設計力に移行しつつある。WorkdayがIlluminateと呼ぶAI基盤戦略もこの文脈に位置づけられており、同社がHCM・財務領域で持つ固有のデータ資産と組み合わせることで、汎用LLMとの差別化を図ろうとする姿勢が読み取れる。

詳細はHow multi-agent AI is redefining enterprise softwareを参照していただきたい。