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