業務をすべてSalesforceのエージェントだけで完結させたいと思っても、現実はそう簡単にはいきません。
あるプロジェクトでAgentforceの設計を検討していたとき、調達プロセスは外部のERP、在庫確認は別ベンダーのシステム、コールセンター対応だけがSalesforce上で動くという状況に直面しました。
それぞれのシステムは単体で見れば優秀でも、境界をまたぐ瞬間にコンテキストが途切れます。そこで注目したのが、Agentforce A2A（Agent-to-Agent）プロトコルです。
Summer '26でGAになったマルチエージェントオーケストレーションは、Salesforce内の複数エージェントを連携させるだけでなく、A2Aプロトコルを通じてSalesforce外のプラットフォームで動くAIエージェントとも連携できる仕組みを提供しています。
よく似た概念として語られるMCP（Model Context Protocol）とは役割がまったく異なるため、この記事ではA2Aの基本構造、MCPとの違い、Salesforceでのマルチエージェント設計パターン、そして実際に取り組む際の注意点を整理します。
A2A プロトコルとは何か
A2A（Agent2Agent）プロトコルは、異なるプラットフォームで動くAIエージェント同士が、互いを見つけ、認証し、構造化されたメッセージをやり取りするためのオープン標準です。
2026年4月時点で Salesforce が公式に説明している通り、このプロトコルを使えば、Salesforce 上の Agentforce エージェントが Google Vertex AI のエージェントや Microsoft Azure Agent Mesh 上のエージェントなどと連携できます。
重要なのは、A2A が「Salesforce の機能」ではなく「業界横断のオープン標準」という位置づけであることです。Linux Foundation のオープンソース財団の下で管理されており、特定ベンダーへのロックインを避けつつ、AI エージェントの連携基盤として活用できます。
つまり
「うちのシステムは Salesforce と Google Cloud と Azure が混在している」
という現実の企業環境に対して、A2A はベンダーを横断してエージェントが協調するための共通言語を提供する、ということです。
A2A の4つのコアコンポーネント
A2A で定義されている主要な構成要素は以下の4つです。
１. Agent Card：
エージェントが「自分が何をできるか」を外部に宣言するメタデータファイルです。
対応可能なタスク、エンドポイント URL、認証要件、入出力フォーマットなどが記載されます。
別のエージェントはこのカードを参照して
「このタスクは誰に頼めばいいか」
を判断します。
2. Task：
作業の単位です。固有のIDを持ち、ライフサイクル（開始・進行中・完了・エラー）を管理します。
複数のメッセージにわたってコンテキストを保持できるため、
「さっき言ったことをもう一度」
という無駄な繰り返しが発生しません。
3. Message：
タスクのスコープ内でやり取りされる情報です。
指示・状態更新・追加コンテキストなどを含みます。
4. Artifact：
リモートエージェントが返す構造化された出力です（レポート、計算結果、生成ファイルなど）。
A2A の技術的な基盤
A2A は特別なインフラを必要としません。
HTTP（通信）、JSON-RPC（構造化メッセージ）、Server-Sent Events（リアルタイム更新）という、現代のエンタープライズ環境に既に存在するウェブ標準の上に成り立っています。
正直、最初は「もっと複雑な仕組みが必要なのでは」と思っていたのですが、使い慣れた標準を組み合わせた設計は、導入のハードルを下げているという印象があります。
A2A vs MCP：混同しやすい2つのプロトコル
Salesforce に限らず、A2A と MCP（Model Context Protocol）は同じ文脈で語られることが多く、最初は「何が違うのか」と迷う人も多いのではないかと思います。両者は明確に異なる問題を解いています。
| 観点 | A2A プロトコル | MCP（Model Context Protocol） |
|---|---|---|
| 主な用途 | エージェント間の連携・委任 | LLMから外部ツール・データへのアクセス |
| 通信の相手 | AIエージェント同士 | LLMとツール・API・データソース |
| 目的 | マルチエージェントオーケストレーション | 情報取得・ツール実行の標準化 |
一言で言えば、
MCP はエージェントが「外を見るための窓」、
A2A はエージェント同士が横に話しかけるための回線です。
Summer '26 では Salesforce はこの両方を同時にサポートしています。
Salesforce Hosted MCP Servers によって外部システムをツールとして取り込みつつ、A2A によって他プラットフォームのエージェントと協調できる。
つまり一方が他方を代替するのではなく、用途に応じて組み合わせて使うものです。
Salesforce のマルチエージェント設計：2つの協調パターン
A2A の具体的な活用イメージをつかむために、Salesforce 環境でよく参照される2つの設計パターンを紹介します。
1. スウォームパターン（並列実行）
複数のサブエージェントが並列でそれぞれの専門領域を調査し、結果をオーケストレーターに返すパターンです。
例えば、新規の大型契約を審査するシナリオでは、オーケストレーターエージェントが以下の3つのサブエージェントに同時に問い合わせます。
- 法務サブエージェント → 契約条項のレビュー
- 与信サブエージェント → 顧客の直近の支払い履歴
- 在庫サブエージェント → 見積もり品目の在庫状況
各エージェントが結果を返すと、オーケストレーターがそれをまとめて判断を出す流れです。すべての調査が並列に動くため、逐次実行と比べて処理時間を大幅に短縮できます。
2. シーケンシャルパターン（直列ハンドオフ）
前のエージェントの出力が次のエージェントへの入力になる、アセンブリライン型のパターンです。
例えば、受注処理のフローであれば、
営業エージェント（商品リスト確定）
→ 経理エージェント（税計算・割引適用）
→ プロビジョニングエージェント（ERP 連携・出荷指示）
という順序で処理が進みます。各ステップの整合性を担保しやすい反面、前のエージェントが誤った情報を渡すと後続全体に影響が出るため、エージェント間でのデータ検証が重要になります。
Agentforce Builder でのマルチエージェント設定
※この設定は Summer '26 時点で Beta 版です。
Agentforce Builder でマルチエージェントオーケストレーションを構成する基本的な手順は以下の通りです。
- 設定のクイック検索で「Agentforce スタジオ」を開く
- オーケストレーター役となるエージェントを開き「Builderで開く」をクリック
- 左パネル（エクスプローラー）の「+」ボタンをクリック
- 「エージェントをサブエージェントとして接続（Beta）」を選択
- 接続するサブエージェントを選択し、説明文（Description）を記述する
- Agent Router を使う場合は、サブエージェントを「推論に使用できるアクション」に追加し、
@で参照する
この手順で構成できるのは、まず Salesforce 内のエージェント同士の連携です。
A2A による Salesforce 外エージェントとの接続については、現時点でクロスプラットフォームの詳細な設定手順が公式ヘルプで確認できていないため、実装前に最新の公式ドキュメントを参照することをお勧めします。
説明文（Description）がすべてを決める
設定で最も重要になるのが、サブエージェントの説明文です。Atlas Reasoning Engine 3.0 はこの説明文を元に「このリクエストをどのサブエージェントに渡すべきか」をリアルタイムで判断します。
つまり説明文は人間向けのドキュメントではなく、Atlas に対するルーティング仕様書です。
「何ができるか」だけでなく「何を扱わないか」まで書いておくと、意図しないルーティングが減ります。
試してみると、説明文の粒度と品質が、そのままエージェントの動作精度に直結するという感触があります。
つまずきポイント・注意事項
① 「縫い目の問題（Seam Problem）」に備える
マルチエージェント特有の失敗として注意したいのが、エージェント間のハンドオフ時のコンテキスト欠落です。
単一エージェントであれば失敗箇所は1か所ですが、複数エージェントを組み合わせると、境界（縫い目）の数だけ潜在的な障害ポイントが増えます。
特にシーケンシャルパターンで、最初のエージェントが誤った情報を渡した場合、後続エージェントが全員「正しく」動いても結果は間違いになります。
実務的な対処：
まず2エージェント（オーケストレーター＋1サブエージェント）で小さく始め、動作が安定したら段階的に増やすことを強くお勧めします。
最初から5つを並べると、どこで問題が起きているかの切り分けが非常に難しくなります。
② A2A クロスプラットフォーム連携はガバナンス設計が先
A2A を使って外部プラットフォームのエージェントと接続する場合、技術的なプロトコル対応より先に整理が必要なのがデータガバナンスです。
コンテキストがクラウド境界を越える場合、データの越境・残存・コンプライアンスの問題が発生します。
実装前に、どの情報が外部エージェントに渡ってよいか、それは社内規定・法令・契約上問題ないかを確認することが必須です。
③ 「ルーピング（再帰ループ）」に注意
2つのエージェントが互いに同じタスクを押し付け合う無限ループは、マルチエージェントシステムで起きやすい失敗の一つです。
サブエージェントの説明文のスコープが重複していると発生しやすくなります。
エージェントごとに「これは扱う」「これは扱わない」を明確に書き分けることが予防策になります。
④ 観測可能性（Observability）の設計を先に決める
マルチエージェントの動作をあとから追うには、どのエージェントが何を判断してどこに渡したかのトレースが必要です。
Summer '26 では Agentforce Observability として 40 以上のメトリクスが確認できる機能が提供されていますが、モニタリングの設計をデプロイ後に後追いで入れるのは難しいです。
本番展開前に、エージェント間ハンドオフのイベントも可視化できるモニタリング設計を先に固めておくことをお勧めします。
まとめ
- A2A（Agent2Agent）プロトコルは、異なるプラットフォームのAIエージェント同士が連携するためのオープン標準で、Salesforce Summer '26（2026年6月15日）でコア機能が GA
- MCP はLLMのツール/データアクセス、A2A はエージェント間連携、という役割分担で両者は補完関係にある
- マルチエージェント設計の主な協調パターンは「スウォーム（並列）」と「シーケンシャル（直列）」の2種類
- Agentforce Builder でのサブエージェント接続設定は現在 Beta。サブエージェントの説明文（Description）がAtlasのルーティング精度を決める
- クロスプラットフォーム A2A 連携はデータガバナンス設計・ループ防止・観測可能性を先に固めてから着手する
A2A は技術プロトコルというより、「AIエージェントが企業システム全体の中でどう協調するか」という設計思想の基盤だという印象を持っています。
Salesforce 環境で完結するユースケースからまず試してみて、クロスプラットフォーム連携はその先で検討していくのが現実的な進め方ではないかと思います。
AI×資格学習・Salesforce業務活用の情報をnoteでも発信しています。