Multi-Agent Orchestration を前提とした Agentforce へのマインドシフト 〜 AIエージェントは「詰め込む」から「組み合わせる」へ 〜
はじめに：Agentforce構築の前提が変わった
2026年1月、SalesforceはAgentforceにおいて「A2A（Agent-to-Agent Protocol）」と「MCP（Model Context Protocol）」という2つのオープン標準への対応、そして「Agent Registry」という新機能を発表しました。これにより、ノーコードでエージェント間連携の設定が可能になります。
この発表は、単なる技術アップデートではありません。AIエージェントの「作り方」「使い方」に対する根本的なマインドシフトを迫るものです。
キーワードは「Multi-Agent Orchestration」——複数の専門エージェントを組み合わせ、1つのワークフローとして機能させるアーキテクチャです。
本記事では、利用部門の責任者として「何を意識すべきか」「チームにどう伝えるべきか」を整理します。
なぜ「万能エージェント」では通用しないのか
よくある要望
利用部門からIT部門への要望として、こんな声をよく聞きます。
「うちの部門専用の、何でも答えてくれるAIアシスタントが欲しい」 「1回の会話で、問い合わせから承認まで全部完結させたい」 「Topicをどんどん追加して、対応範囲を広げてほしい」
気持ちはわかります。優秀な「万能秘書」がいれば便利ですよね。
「詰め込み」が失敗する構造的な理由
しかし、AIエージェントを作成していて、「単一エージェントに多くの責任を持たせすぎて、思うように動いてくれなくなってしまった」という経験をお持ちの方は多いのではないでしょうか？
たとえば、Topicやインストラクションを追加するたびに、指示への準拠度が下がっていきます。「必ず確認してから回答して」と設定したはずなのに、対応範囲が広がった途端にそのルールを忘れてしまう。専門外の質問にも無理に答えようとして的外れな回答を返したり、責任範囲が広がるほど「もっともらしいウソ」——いわゆるハルシネーション——のリスクも高まります。さらに厄介なのは、問題が起きたときのデバッグです。エージェントの守備範囲が広いほど「なぜ間違えたのか」の特定に膨大なログの精査が必要になり、改善のサイクルが回しにくくなります。
つまり、「何でも屋」を目指したばかりに「すべてうまくいかない」という事態に陥りがちなのです。
これは個々のエージェントの性能の問題ではなく、アーキテクチャの問題です。ソフトウェア開発の世界では、｢単一責務の原則｣という考え方があります｡エージェントAIにあてはめると､一つのエージェントには一つの役割のみを割り当てた方がスマートである､と言えます｡つまり、Multi-Agent Orchestration という発想への転換が必要になるのです。
Multi-Agent Orchestration とは何か
ソフトウェア開発に学ぶ設計思想
ソフトウェア開発の世界では一つの複雑なパーツを作るよりも「小さな専門パーツの組み合わせながらソフトウェアを開発した方が､開発効率が良いという考え方があります｡Multi-Agent Orchestration は、この設計思想をAIエージェントの世界に持ち込んだものと言えるでしょう｡
従来の発想（モノリシック）
1つの優秀なAgentforce
├── 顧客対応
├── 在庫確認
├── 発注処理
├── 請求管理
└── レポート作成
Multi-Agent Orchestration
オーケストレーター（司令塔）
├── 顧客対応エージェント ← 顧客対応のプロ
├── 在庫エージェント ← 在庫確認のプロ
├── 発注エージェント ← 発注処理のプロ
├── 請求エージェント ← 請求管理のプロ
└── 分析エージェント ← レポート作成のプロ個々のエージェントは自分の専門領域に集中し、オーケストレーターがタスクの振り分けと全体の進行を管理します。顧客から見れば「1人のアシスタント」ですが、裏では専門家チームが連携しているイメージです。
A2AとMCP——Orchestrationを支える2つの標準規格
このアーキテクチャを現実のものにするのが、A2AとMCPという2つのオープン標準です。
MCP（Model Context Protocol） は、エージェントが外部のツールやデータに安全にアクセスするための「共通言語」です。たとえるなら「AIのUSB-C」。どのエージェントも、この規格に対応したツールなら簡単に使えるようになります。
A2A（Agent-to-Agent Protocol） は、エージェント同士が会話するための「共通言語」です。Salesforceのエージェントが、GoogleやSAPのエージェントと直接やり取りできるようになります。
これまでは「他社システムとの連携」といえば、IT部門が個別にAPIを開発する必要がありました。A2A/MCPが普及すれば、エージェント同士が「初対面でも仕事ができる」 世界が実現します。
Agent Registry——Orchestrationの管理基盤
A2A/MCP対応の発表と同時に登場した「Agent Registry」は、Salesforce Platform内でエージェントやMCPサーバーを登録・管理する機能です。Multi-Agent Orchestration の実運用を支える管理基盤として、3つの役割を担います。
ノーコードで設定可能： 従来、外部システムとの連携にはApex開発やAPI設計が必要でした。Agent Registryを使えば、IT部門がMCPサーバーを「登録」しておくことで、利用部門はノーコードで連携を設定できます。
中央管理によるガバナンス： どのエージェントが、どのツールにアクセスできるかを一元管理できます。「知らないうちに機密データに外部エージェントがアクセスしていた」という事態を防げます。
再利用と発見： AgentExchangeを通じて、検証済みのMCPサーバーやエージェントを発見・導入できます。車輪の再発明を避け、すでに実績のあるコンポーネントを活用できます。
具体例：住宅ローン申請プロセスで見るOrchestration
抽象的な話だけでは伝わりにくいので、具体例で考えてみましょう。
従来のアプローチ
「住宅ローン申請を受け付けるAIアシスタント」を作ろうとすると、1つのエージェントに以下を全部詰め込もうとしがちです。顧客との対話、必要書類の案内、与信審査の依頼、物件評価の取得、契約書類の作成、進捗状況の通知——これらをすべて1体のエージェントに担わせると、前述のとおり複雑すぎて精度が出ない、問題が起きても原因を切り分けにくい、という壁にぶつかります。
Multi-Agent Orchestration アプローチ
役割ごとに専門エージェントを分け、Agent Registryで連携させます。
役割 担当 顧客対応 Agentforce（自社） 顧客情報参照 Data Cloud 与信審査 外部A2Aエージェント 物件評価 外部MCPツール 書類作成 社内エージェント 進捗通知 Slack連携（Slack MCP）
オーケストレーターが全体の進行を管理し、各ステップで最適な専門エージェントにタスクを振り分けます。顧客は「たらい回し」を感じることなく、一貫した体験を得られます。
マインドシフト：利用部門が変えるべき3つの意識
Multi-Agent Orchestration を前提にすると、利用部門の考え方も変わる必要があります。
1. 「万能」を求めない ── 専門性を活かす
Before:
「なんでも答えられるAIが欲しい」
After:
「この業務に特化した、精度の高いAIが欲しい。他の業務は別のエージェントと連携すればいい」
2. 「境界」を自分で考える ── 責任範囲を定義する
Before:
「どこまでやれるかはIT部門に任せる」
After:
「自部門のエージェントの責任範囲はここまで。ここから先は○○部門のエージェントに引き継ぐ」
これは組織設計と同じです。人間のチームでも「誰が何を担当するか」を曖昧にすると、責任の押し付け合いや重複作業が発生しますよね。AIエージェントも同じです。
3. 「引き継ぎ」の顧客体験を考える ── Orchestrationの品質を問う
Before:
「AIが全部やってくれればいい」
After:
「エージェントが切り替わるとき、顧客はどう感じるか？」
複数エージェントが連携する場合、「たらい回し感」を与えないための設計が必要です。人間のコールセンターで「担当が変わるたびに同じ説明をさせられる」と不満が出るのと同じです。Orchestration の品質は、この「引き継ぎ体験」で決まります。
ビジネスオーナーが問うべき5つの質問
エージェント導入を検討する際、以下の質問を自分に投げかけてみてください。
Q1. この業務は「汎用」か「専門」か？
汎用的な問い合わせ対応なら、幅広いTopicを持つエージェントが適切です。しかし、与信審査や在庫最適化のような専門業務は、専門エージェントに任せた方が精度が出ます。
Q2. エージェントの責任範囲は明確か？
1つのエージェントに詰め込みすぎていないか？「この業務はここまで」「ここから先は別のエージェントに引き継ぐ」という境界線は明確か？を確認しましょう。
Q3. エージェント間の「引き継ぎ」で顧客体験が損なわれないか？
複数エージェントが連携するとき、顧客に「たらい回し」感を与えないか？コンテキスト（文脈）は適切に引き継がれるか？を確認しましょう。
Q4. 外部エージェントに「何を見せていいか」？
A2A/MCPで外部連携が簡単になる一方、「どのデータへのアクセスを許可するか」はガバナンスの問題です。IT部門・法務部門と協議して、アクセス権限のルールを定めましょう。
Q5. エージェント呼び出しの「コスト」はどうなるか？
外部エージェントやMCPサーバーを呼び出すたびに、課金が発生する可能性があります。「何回呼び出すか」がコストに直結するため、必要以上に複雑な連携は避けるべきです。
注意すべきリスク
新しいアーキテクチャには、必ずリスクも伴います。
エコシステムの成熟度
A2A/MCPは2024〜2025年に登場した比較的新しい標準です。すべてのベンダーが対応しているわけではありません。「連携したいシステムがA2A/MCP非対応」という状況もありえます。
運用の複雑化
複数エージェント・複数ベンダーを組み合わせると、運用管理の負荷が増えます。1つのエージェントのアップデートが、ワークフロー全体に影響する可能性もあります。
過剰設計の罠
業界事例として「完璧なマルチエージェントシステムを18ヶ月かけて構築したが、ローンチ時には陳腐化していた」という失敗談も報告されています。最初から完璧を目指すのではなく、小さく始めて改善を繰り返すアプローチが重要です。
まとめ：「組み合わせる力」が競争優位になる
AIエージェントの世界は、「1つの優秀なエージェントを作る競争」から「専門エージェントを上手く組み合わせる競争」へと移行しつつあります。
A2A/MCPの普及とAgent Registryの登場により、Multi-Agent Orchestration はもはや将来構想ではなく、今日から取り組むべきアーキテクチャです。
利用部門の責任者に求められるマインドシフトは：
「万能」を求めず、「専門性」を活かす
境界と責任を明確にする
顧客体験を中心にOrchestrationを設計する
小さく始めて、改善を繰り返す
「どんなエージェントを作るか」ではなく、「どんなエージェント構成を設計するか」。
この視点の転換が、デジタルワークフォース時代の競争優位を左右することになるでしょう。
本記事は2026年1月のSalesforce発表内容に基づいています。A2A/MCPおよびSalesforce Agentforceの機能は継続的にアップデートされているため、最新情報は公式ドキュメントをご確認ください。