MicrosoftのA2A Integrationは、AIエージェント同士を標準プロトコルで接続するための開発者向け機能です。結論から言うと、確認すべきポイントは「A2Aでつなぐべき境界があるか」「AgentCardで公開する情報は適切か」「認証・シークレット・セッション永続化を本番向けに設計できているか」「SDK v1移行に伴うAPI変更を吸収できているか」の4つです。
Microsoft LearnのA2A Integrationページは2026年5月11日に更新されており、Agent-to-Agentプロトコルによるエージェント発見、メッセージ通信、長時間タスク、異なるフレームワーク間の相互運用が整理されています。これはCopilotの画面機能ではなく、Microsoft Agent Frameworkで作ったエージェントを他のエージェントや外部システムと連携させるための実装・運用設計に関わる内容です。(Microsoft Learn)
MicrosoftのA2A Integrationとは
A2A Integrationは、Microsoft Agent FrameworkのエージェントをA2Aプロトコルで公開したり、外部のA2A対応エージェントに接続したりするための統合機能です。
A2Aは「Agent-to-Agent」の略で、エージェント同士が標準化された形式でやり取りするためのプロトコルです。公式情報では、次のような機能が示されています。
| 機能 | 何ができるか | 実務での意味 |
|---|---|---|
| AgentCardによる発見 | エージェントの名前、説明、バージョン、URL、機能などをメタデータとして公開する | 呼び出し側が「このエージェントは何ができるか」を事前に判断できる |
| メッセージベースの通信 | ユーザーまたは他エージェントからのメッセージを送受信する | 異なるサービス間でも会話形式で連携できる |
| タスクによる長時間処理 | すぐに完了しない処理をタスクとして扱う | 大量データ処理、調査、分析などを非同期的に扱いやすい |
| クロスプラットフォーム連携 | 異なる言語・フレームワークで作られたエージェントを接続する | .NET、Python、他社フレームワークの混在環境で使いやすい |
A2A Integrationの価値は、単に「エージェントをHTTPで呼べる」ことではありません。別チーム、別サービス、別言語、別クラウド、外部パートナーのエージェントを、密結合にせず連携させる点にあります。Microsoftの解説でも、A2Aはサービス境界、チーム境界、組織境界をまたぐ場合に有効であり、同一プロセス内で完結するなら「agents as tools」のほうがシンプルだとされています。(Microsoft Learn)
2026年5月11日更新情報で押さえる主なポイント
今回のA2A Integrationで管理者や開発者が見るべき点は、単なる機能追加ではなく「エージェントを外部に公開する設計」へ踏み込んでいることです。
| 観点 | 内容 | 確認すべきこと |
|---|---|---|
| .NETでのA2A公開 | Microsoft.Agents.AI.Hosting.A2A.AspNetCoreによりASP.NET Core経由でエージェントを公開できる | Web APIとして公開するURL、認証方式、ネットワーク境界を決める |
| PythonでのA2A連携 | agent-framework-a2aパッケージにより、外部A2Aエージェントへの接続とAgent Frameworkエージェントの公開が可能 | Python側の依存関係、非同期処理、HTTPクライアント設定を確認する |
| AgentCard | エージェントの発見・統合に使うメタデータ | 説明文に社内情報や機密情報を書かない。バージョンと機能を明確にする |
| Streaming | Server-Sent Eventsにより応答をリアルタイムに受け取れる | タイムアウト、切断、再接続、ログ出力を設計する |
| contextId | 同じ会話を継続するための識別子として使われる | 個人情報を直接入れない。保存期間と削除方針を決める |
| 認証 | Python例ではAuthInterceptorによるBearer認証の例が示されている | トークンの取得元、期限切れ時の処理、権限範囲を確認する |
.NET向けにはA2A Hosting用のNuGetパッケージ、Python向けにはagent-framework-a2aが示されています。公式ページのサンプルでは、ASP.NET Core Web APIプロジェクトにA2A関連パッケージ、Microsoft Foundry接続用ライブラリ、Swagger確認用ライブラリを追加する流れが紹介されています。(Microsoft Learn)
影響範囲：誰が対応すべきか
A2A Integrationは、Microsoft 365の一般ユーザーや通常のテナント管理者がすぐ設定変更を迫られる機能ではありません。影響が大きいのは、Microsoft Agent FrameworkでAIエージェントを開発・運用しているチームです。
| 対象者 | 影響 | 最初に確認すること |
|---|---|---|
| .NET開発者 | ASP.NET CoreでエージェントをA2A公開する実装に影響 | 利用中のパッケージ、API名、エンドポイント設計 |
| Python開発者 | 外部A2Aエージェントの呼び出し、A2Aサーバー公開に影響 | A2AAgent、A2AExecutor、非同期処理、認証処理 |
| 管理者・セキュリティ担当 | エージェントの外部公開、AgentCard、認証、通信ログに影響 | 公開範囲、トークン管理、監査ログ、機密情報の露出 |
| DevOps/SRE | HTTP経由の分散サービスとしての運用に影響 | タイムアウト、リトライ、スケールアウト、永続ストレージ |
| Microsoft 365管理者 | 直接影響は限定的。ただしM365連携エージェントを公開する場合は関与が必要 | Teams、SharePoint、Outlookなどに触れる権限とデータ境界 |
特に注意したいのは、A2Aを使うとエージェントが「アプリケーション内の部品」ではなく「ネットワーク越しに呼ばれるサービス」になる点です。HTTP呼び出しによる遅延、ネットワーク障害、タイムアウト、リトライ、バージョニングなど、通常のサービス間通信と同じ運用課題が発生します。(Microsoft Learn)
開発者が確認すべきSDK v1移行の注意点
A2A Integrationを見るときは、同時にA2A SDK v1 Migration Guideも確認すべきです。Microsoftの移行ガイドでは、Agent FrameworkのA2A統合パッケージがA2A SDK v1に更新され、従来のv0.3依存を置き換える破壊的変更として説明されています。影響範囲は、A2A Agentのクライアント側とA2A Hostingのサーバー側の両方です。(Microsoft Learn)
とくに混乱しやすいのは、A2A Integrationページの最小例と、A2A Hosting／Migration Guideで示される新しい構成の違いです。既存コードを持つチームは、サンプルをそのままコピーするのではなく、利用しているパッケージバージョンに対応したAPIを確認してください。
| 旧来の考え方・実装例 | 新しい確認ポイント | 実務での対応 |
|---|---|---|
MapA2Aで登録・エンドポイント・AgentCardをまとめて扱う | サーバー登録、エンドポイントマッピング、AgentCard公開が分離される | AddA2AServer、MapA2AHttpJson、MapA2AJsonRpc、MapWellKnownAgentCardの利用可否を確認する |
| JSON-RPC前提で通信する | 既定ではHTTP+JSONが優先され、JSON-RPCはフォールバックになる | JSON-RPCを維持したい場合はPreferredBindingsを明示する |
AgentCardをMapA2Aの引数で渡す | AgentCardを専用の呼び出しで公開する | URL、プロトコル、バージョン、機能説明を整理する |
A2AHostingOptionsを使う | A2AServerRegistrationOptionsに名称変更 | 設定クラス名の変更を移行時に確認する |
ITaskManagerの戻り値を前提にする | 直接公開されない構成に変わる | 内部処理に依存している箇所を修正する |
移行ガイドでは、旧来のMapA2A(agent, path, agentCard)が、AddA2AServerによる登録、MapA2AHttpJsonまたはMapA2AJsonRpcによるエンドポイント公開、MapWellKnownAgentCardによるAgentCard公開へ整理されています。既存のA2A実装がある場合、この差分はビルドエラーだけでなく、実行時のルーティングやクライアント互換性にも影響します。(Microsoft Learn)
管理者が確認すべき設定と運用ポイント
AgentCardに載せる情報を絞る
AgentCardは、呼び出し側がエージェントを発見し、能力を理解するためのメタデータです。公式ページでは、名前、説明、バージョン、URL、ストリーミングやプッシュ通知などのCapabilitiesがプロパティ例として示されています。(Microsoft Learn)
本番環境では、AgentCardを「自己紹介」ではなく「公開される仕様書」と考えてください。説明文に内部システム名、顧客名、非公開の業務プロセス、管理用URLを含めると、エージェントを呼び出す前の段階で情報を漏らすことになります。
実務では、次のように切り分けると安全です。
| 項目 | 書いてよい例 | 避けたい例 |
|---|---|---|
| Name | InvoiceReviewAgent | 顧客名や案件名を含む名称 |
| Description | 請求書の形式確認を支援するエージェント | 利用中の内部DB名や業務フローを詳細に書く |
| Version | 1.0.0 | 更新日や担当者名だけで管理する |
| Url | 公開を前提にしたA2Aエンドポイント | 管理画面、社内限定URL、検証用URL |
| Capabilities | streaming対応など必要な機能 | 実装予定だが未検証の機能 |
また、A2A Hostingの関連ドキュメントでは、well-known pathで公開できるAgentCardはホストごとに1つという注意が示されています。複数エージェントを同一アプリケーションで公開する場合は、どのエージェントを発見可能にするか、どのエージェントはURLを直接知っているクライアントだけが呼ぶかを設計する必要があります。(Microsoft Learn)
認証とシークレット管理を本番向けにする
A2A Integrationのサンプルでは、Microsoft Foundry接続情報をdotnet user-secretsまたは環境変数で設定する流れが示され、appsettings.jsonに直接書く方法は本番アプリでは推奨されないと説明されています。(Microsoft Learn)
本番環境では、次の方針を基本にしてください。
| 確認項目 | 推奨される考え方 |
|---|---|
| APIキー・エンドポイント | 環境変数、Key Vault、マネージドIDなどで管理する |
| ローカル開発 | dotnet user-secretsや開発用環境変数を使う |
| 本番の認証 | 可能なら特定の資格情報やマネージドIDを使う |
| ログ | Authorizationヘッダー、トークン、プロンプト内の機密情報を出力しない |
| トークン期限切れ | 自動更新、再試行、失敗時の監査ログを設計する |
公式サンプルではDefaultAzureCredentialが使われていますが、Microsoftは本番利用では慎重に検討し、遅延、意図しない資格情報探索、フォールバック機構によるセキュリティリスクを避けるため、ManagedIdentityCredentialなど特定の資格情報の利用を検討するよう注意しています。(Microsoft Learn)
contextIdとセッション状態を設計する
A2Aでは、contextIdが会話の継続に使われます。同じcontextIdを使うことで、エージェントは会話履歴を維持できます。逆に言えば、contextIdの扱いを誤ると、別ユーザーの文脈が混ざる、会話履歴が失われる、削除すべきデータが残り続けるといった問題が起きます。(Microsoft Learn)
避けたいのは、メールアドレス、社員番号、顧客IDなどをそのままcontextIdに入れることです。ランダムなIDやアプリケーション側で管理するセッションIDを使い、ユーザー情報との対応はサーバー側で安全に管理するほうが現実的です。
A2A Hostingでは、既定のInMemoryAgentSessionStoreとInMemoryTaskStoreは開発用途向けであり、アプリケーション再起動時に状態が失われ、複数インスタンス間で共有されません。本番展開では永続化された実装に差し替える必要があります。(Microsoft Learn)
Python開発者が見るべきポイント
Python側では、agent-framework-a2aパッケージにより、外部A2A対応エージェントへの接続と、Agent FrameworkエージェントのA2A公開の両方が扱えます。公式ページでは、A2AAgentを使ってリモートA2Aエンドポイントをラップし、AgentCardから機能を解決して通信する例が示されています。(Microsoft Learn)
Python実装で確認すべき点は次のとおりです。
| 項目 | 確認ポイント |
|---|---|
| 接続先の発見 | AgentCardを取得できるか。カード内のURLと実際の到達性が一致しているか |
| Streaming | Server-Sent Eventsを受け取るクライアント実装がタイムアウトしないか |
| 長時間タスク | continuation tokenを保存し、ポーリングや再接続に使えるか |
| context_id | AgentSessionから自動導出される場合と明示指定する場合の優先順位を理解する |
| 認証 | AuthInterceptorでBearerトークンなどを付与する場合、期限切れと更新処理を設計する |
注意したいのは、長時間タスクの扱いです。A2Aクライアント側では、リモートエージェントがタスクを返す場合にcontinuation tokenを使って結果を取得できます。一方、Agent FrameworkでA2Aホストされたエージェントについては、A2A Hostingドキュメントでbackground responsesはまだサポートされていないと記載されています。自社で公開するエージェントに長時間処理を持たせる場合は、公式の対応状況を確認し、代替としてジョブキューや外部タスク管理を用意する判断が必要です。(Microsoft Learn)
A2Aを使うべきケース、使わないほうがよいケース
A2A Integrationは便利ですが、すべてのエージェント連携に使うべきではありません。HTTP越しの通信になるため、単一アプリケーション内で完結する処理にまでA2Aを使うと、設計が複雑になり、遅延と障害ポイントが増えます。
| 判断基準 | A2Aが向いている | A2Aを避けたほうがよい |
|---|---|---|
| サービス境界 | エージェントが別サービスとして動いている | 同じプロセス内で呼べる |
| チーム境界 | 別チームがエージェントを所有している | 同じチームがすべて管理している |
| 組織境界 | 外部企業や別組織のエージェントを使う | 社内の単一アプリだけで完結する |
| 言語・フレームワーク | .NET、Python、他フレームワークが混在する | 同じ言語・同じランタイムで統一されている |
| 運用要件 | 独立したリリース、監査、認証が必要 | 低遅延で単純な関数呼び出しが重要 |
たとえば、社内の請求書確認エージェントと、外部パートナーの税務チェックエージェントを連携させる場合はA2Aが向いています。互いの内部実装を知らなくても、AgentCardで機能を把握し、標準プロトコルで通信できるためです。
一方、1つのWebアプリ内で「要約エージェント」と「分類エージェント」を順番に呼ぶだけなら、A2Aよりもアプリ内の関数やワークフローでつないだほうがシンプルです。
展開前に実施したいテスト手順
A2A Integrationを本番へ展開する前に、最低限次のテストを行ってください。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| エンドポイント確認 | A2AエンドポイントとAgentCardに到達できるか | 開発環境のURLが残っている |
| AgentCard検証 | Name、Description、Version、URL、Capabilitiesが正しいか | 内部情報を書きすぎる |
| 認証テスト | 正しいトークンで成功し、不正トークンで拒否されるか | 認証なしで公開されている |
| contextIdテスト | 同じcontextIdで会話が継続し、別contextIdで分離されるか | ユーザー間で文脈が混ざる |
| Streamingテスト | 長い応答を途中で受信できるか | プロキシやロードバランサーでSSEが切れる |
| 再起動テスト | アプリ再起動後も必要な状態が保持されるか | InMemoryストアのまま本番運用している |
| スケールアウトテスト | 複数インスタンスでセッションやタスク状態が整合するか | インスタンスごとに状態が分断される |
| プロトコル互換性 | HTTP+JSONとJSON-RPCのどちらを使うか明確か | SDK v1移行で既定プロトコルが変わり、既存クライアントが想定外の通信になる |
特にSDK v1移行後は、HTTP+JSONが優先され、JSON-RPCはフォールバックとして扱われます。既存クライアントがJSON-RPC前提で作られている場合は、A2AClientOptions.PreferredBindingsで明示的に指定するか、クライアント側をHTTP+JSON対応に更新する必要があります。(Microsoft Learn)
よくある失敗と回避策
A2A Integrationで失敗しやすいのは、プロトコルそのものよりも運用設計です。実装が動いた段階で完了にせず、公開範囲、権限、状態管理、障害時の動きを確認してください。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| サンプルコードのAPI名だけを見て実装する | 利用中のSDKバージョンと合わずビルドやルーティングで失敗する | A2A Integration、A2A Hosting、Migration Guideをセットで確認する |
| AgentCardに詳しすぎる説明を書く | 内部構成や業務情報が外部に見える | 公開仕様として必要な情報だけに絞る |
| 認証なしで検証環境を公開する | 意図しない呼び出しやコスト増につながる | 検証環境でも認証、IP制限、ログ監査を入れる |
DefaultAzureCredentialを本番で安易に使う | 意図しない資格情報探索やフォールバックが起きる | 本番ではマネージドIDなど明示的な資格情報を検討する |
| InMemoryストアで本番運用する | 再起動やスケールアウトで会話・タスク状態が失われる | 永続化ストアに差し替える |
| A2Aを同一プロセス内の単純連携に使う | 遅延と複雑性が増える | 同一アプリ内なら関数、ツール、ワークフローでつなぐ |
| contextIdに個人情報を入れる | ログや外部通信で個人情報が露出する | ランダムIDやアプリ側セッションIDを使う |
まず何をすべきか
A2A Integrationを導入する前に、最初にやるべきことは実装ではなく棚卸しです。自社のエージェント連携が、本当にサービス境界・チーム境界・組織境界をまたぐのかを確認してください。境界をまたがないなら、A2Aではなくアプリ内のツール呼び出しやワークフローで十分な場合があります。
A2Aを使う判断になったら、次の順に進めると安全です。
| 優先度 | 作業 | 目的 |
|---|---|---|
| 高 | 利用中のAgent FrameworkとA2A関連パッケージのバージョンを確認する | SDK v1の破壊的変更に対応する |
| 高 | AgentCardに公開する情報を決める | 不要な情報露出を防ぐ |
| 高 | 認証、シークレット、資格情報の管理方法を決める | 本番環境で安全に公開する |
| 高 | セッションとタスク状態の永続化を設計する | 再起動・スケールアウトに耐える |
| 中 | HTTP+JSONとJSON-RPCの利用方針を決める | 既存クライアントとの互換性を保つ |
| 中 | Streamingと長時間処理の動作を検証する | 切断、再接続、タイムアウトに備える |
| 中 | 監査ログと失敗時のアラートを設定する | 障害や不正利用を早期に検知する |
MicrosoftのA2A Integrationは、AIエージェントを単体アプリから分散サービスへ広げるための重要な仕組みです。ただし、導入効果が出るのは「境界をまたぐ連携」が明確な場合です。まずは対象エージェント、公開するAgentCard、認証方式、状態管理、SDK v1移行の影響を確認し、小さな検証環境で通信・ストリーミング・再起動時の挙動までテストしてから本番展開するのが現実的です。
コメント