マルチエージェントパターンには、何らかの形でエージェント間の相互作用が必要です。 エージェントは安全な機能メッシュに参加し、各エージェントは協調的かつ礼儀正しく信号を交換して作業を調整します。
最小権限、シンプルさ、監査可能性、堅牢なガバナンスの原則を用いて、クロスエージェントおよびツールの呼び出しを実装します。 複雑さを軽減するには、可能な限り内部フローにプラットフォームネイティブオーケストレーションを使用し、モデル コンテキスト プロトコル (MCP) を使用して、ツールとデータに対するセキュリティで保護された認証されたaccessを使用します。 クロスプラットフォームのエージェント統合には、公開された契約およびMCPフロントエージェントと共に、Linux FoundationのAgent2Agent (A2A)プロトコルを使用してください。 ネイティブMCPおよびA2A対応の公開ソフトウェア開発キット(SDK)を使用して、接続されたエージェントのセキュリティと管理を標準化します。
複雑なユース ケースには、magentic、シリアル、および同時実行エージェントの種類のハイブリッドが含まれる場合があります。 例えば、ドキュメント生成ワークフローでは、テンプレートの選択、グラウンディングコンテンツ生成、コンプライアンスチェックなどの連続ステップと、複数のコンプライアンスチェックを並行して実行する同時処理の両方が必要になる場合があります。 ワークフロー内では、単純なマゼンティック剤から複雑なものまで、さまざまな種類のエージェントを使用できます。
マルチエージェント間の相互作用推奨事項
可能な限りサブエージェントを含む内部フローでは、オーケストレーションをシンプルに保つためにプラットフォームネイティブのオーケストレーションを優先してください。
ツールとデータへのアクセスには、Microsoft 365サービスツールを含むMCPを使用します。 データとアクションを、企業レベルのセキュリティ、認証、監査を利用してエージェントに表示する推奨される方法です。
クロスプラットフォームのエージェント間メッセージングにはA2Aを使いましょう。 能力発見およびタスク契約のための設計。 エージェントに「エージェントカード」(能力)を公開させ、A2Aのタスクおよびアーティファクトモデルを使用することで、ワークフローが実行時に長期間実行されるタスクを発見、呼び出し、追跡できるようにします。
成熟または抽象化されたエージェントをMCPまたはA2Aを通じて統合することで、ロジックの再実装を避け、再利用やエンドツーエンドのトレーサビリティと制御を向上させます。
公開されたSDKを用いて、セキュリティ、登録、監視性を標準化するために、接続された外部エージェントを統合します。
Agent 365のようなフレームワークを用いてコントロールプレーン層でポリシーと監査を強制し、エージェントのコンプライアンスと監視性を維持しましょう。
MCPホストのツールを呼び出す際は、ワークフローステップからデータ検索やアクションを行う際に最小権限スコープを使いましょう。
表面積を制限し、パフォーマンスを向上させるには、ステップとコンポーネント間で型指定されたペイロードを検証し、定義されたスキーマを利用し、必要に応じてコンテキストを渡します。 記述的誤りを設計し、エージェントがエラーメッセージに基づいて自己修正できるようにしましょう。
並列性を重視し、エージェント間のコンテキストを厳密に必要な範囲に限定し、重複作業を避けるために短期記憶を活用します。
ユーザーをワークフローに組み込み、エージェント同士が協力する場合は連絡を取りましょう。 高影響のクロスエージェント行動には人間の承認を義務付けること。 キャンセルとスキップを許可し、実行時間の長いステップおよび概要を表示します。 相反する出力を調整すること。
エージェントアーキテクチャにおけるMCPおよびA2Aの評価
MCP (モデル コンテキスト プロトコル) と A2A (Linux Foundation の Agent2Agent) は、エージェント アプリケーションを構築するための補完的なopen source標準です。
両標準ともクライアント・サーバーフローやスキル発見において類似の機能を提供しています。 以下の表は、複数のエージェントを接続する方法を選ぶ際に、各プロトコルが明確な差別要因を持つ箇所を示しています。
| 能力 | MCP | A2A |
|---|---|---|
| マルチモーダリティ | MCPホストのサポートが必要です | サポートされているメディアタイプを公開し、型付けの厳密なデータ交換を可能にします。 |
| 積極的な通知と購読 | システム通知サポート | システムおよびコンテンツの通知。 |
| 多ターン相互作用 | MCPサーバーはオプションで追加情報を引き出すこともできます。 コンテキスト管理はホストに留まります。 | contextIdはエージェント間のコンテキスト管理を可能にします。 単一の文脈内に複数のタスクが存在することもあります。 「入力が必要」はMCPの誘導に相当します。 |
| オーケストレーション | MCPホストはどのツールを呼び出すかをオーケストレーションし、最終出力を統合します | Invoked Agentは独自の思考の連鎖とオーケストレーションを用いています。 ツールやAPIはリクエストエージェントには不透明です。 |
| 交渉 | 新しいモダリティや機能のためにMCPクライアントの更新が必要 | サポートされたフローの動的交渉は、サービス更新に対してより堅牢です。 |
MCPは、エージェントがAPIやデータソース、その他のエージェントなどの外部オブジェクトとやり取りするためのシンプルでわかりやすい方法を提供します。 単一のオーケストレーターが結果を選択し、呼び出し、フィルタリングし、推論し、統合するための強力なコントロールを提供します。 このプロトコルは、柔軟性やダイナミズムよりも推論や重み付けのコントロールを好む場合に適しています。
A2Aは、エージェント同士が互いに不透明である、または不透明でなければならない状況により適しています。 たとえば、マルチエージェント ワークフローで外部エージェントからの入力が必要な場合や、2 つの異なるエンジニアリング組織が所有するエージェントが必要な場合です。 交渉のサポートにより、サービスが新機能を公開した際のクライアント・サーバーコード更新への依存性が減ります。
詳細情報：