2026年6月4日時点の公式情報では、Azure AI FoundryのFoundry Agent Serviceに、Agent-to-Agent（A2A）通信がPublic Previewとして追加されました。これにより、Prompt agentsとResponsesプロトコルに対応したHosted agentsが、別のAIエージェントへ処理を委譲できるようになります。
ただし、既存エージェントが自動的に他のエージェントと通信し始めるわけではありません。呼び出される側でA2Aエンドポイントを有効化し、呼び出す側では接続、認証、A2Aツールを設定する必要があります。また、現時点ではSLAのないプレビュー機能であり、Microsoftは本番ワークロードへの利用を推奨していません。まずは非本番環境で、権限、データ共有範囲、障害時の挙動を検証するのが現実的です。(Microsoft Azure)
Azure AI FoundryのAI／Copilot更新で何が変わるのか
今回のAzure AI Foundry A2A対応を簡潔に整理すると、1つの高機能なエージェントにすべてを実装するのではなく、専門分野ごとに分けたエージェントを連携させやすくなった更新です。
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| A2A通信の追加 | A2A互換エンドポイントを通じて、別のエージェントを呼び出せる | 部門や機能ごとにエージェントを分割できる |
| マネージドエンドポイント | Foundry上のエージェントに専用の呼び出し先を用意できる | 独自の中継APIやルーティング処理を減らせる |
| Agent Cardによる機能公開 | エージェントの説明、バージョン、スキルを他のエージェントに提示できる | 呼び出し側が対象エージェントの役割を判断しやすい |
| IDとアクセス制御 | Microsoft Entra IDとAzure RBACで呼び出しを制御する | APIキーの共有を減らし、呼び出し主体を識別できる |
| 安全性と監査 | 各ホップにID、コンテンツ安全性、監査ログを適用する設計 | エージェント間通信を追跡しやすくなる |
| 標準プロトコル対応 | Foundry外を含むA2A互換エージェントと連携できる | 異なるフレームワークやチーム間で再利用しやすい |
公式発表では、エージェントがマネージドエンドポイント経由で別のエージェントを呼び出し、各通信にID、コンテンツ安全性、監査ログを適用できる点が示されています。(Microsoft Azure)
対象となるエージェント
A2Aの受信エンドポイントを公開できる対象は、次のとおりです。
- Prompt agents：Responsesプロトコルに標準対応しており、A2Aエンドポイントとして公開できます。
- Hosted agents：コンテナ内のエージェントがResponsesプロトコルを処理できる場合に限り、A2Aを有効化できます。
- Invocationsプロトコルだけを実装したHosted agents：そのままではA2Aの受信に対応できません。Responsesプロトコルの実装と再デプロイが必要です。
Hosted agentsでは、利用するプロトコルをagent.yamlまたはSDKのcontainer_protocol_versionsで宣言します。単に管理画面でA2Aをオンにするだけではなく、コンテナ側のプロトコル実装まで確認しなければなりません。(Microsoft Learn)
既存環境への直接的な影響
A2Aは明示的に設定する機能です。受信側ではAgent CardとA2Aプロトコルを設定し、呼び出し側ではA2A接続とツールを追加します。したがって、A2Aを設定していない既存のPrompt agentやHosted agentの動作が、この更新だけで変わる可能性は低いと考えられます。(Microsoft Learn)
一方、今後エージェントを分割・再利用する計画がある組織では、エージェントの命名規則、所有チーム、アクセス権、ログ保存方針を早めに決めておく必要があります。A2Aを導入すると、エージェント自体が社内APIに近い共有コンポーネントになるためです。
A2AとWorkflow、MCPをどう使い分けるか
A2Aは、すべてのマルチエージェント構成を置き換える機能ではありません。用途に応じてWorkflowやMCP、OpenAPIと使い分けることが重要です。
| 方式 | 適した用途 | 処理の主導権 | 主な注意点 |
|---|---|---|---|
| A2A | 独立した専門エージェントへの委譲 | 呼び出し元エージェントが維持 | 認証、Agent Card、通信失敗への対応が必要 |
| Foundry Workflow | 順番や分岐が決まった業務プロセス | Workflowが制御 | フロー変更時の影響範囲を管理する |
| MCP | 検索、データ取得、処理機能をツールとして共有 | 呼び出し元エージェント | 接続先は通常「エージェント」ではなくツール |
| OpenAPI | 既存のREST APIを利用する | 呼び出し元エージェント | API仕様、認証、エラー処理が必要 |
| Function tool | アプリ内の処理を厳密な引数で呼ぶ | 呼び出し元エージェント | 実装との結合が強くなりやすい |
A2Aツールでは、専門エージェントの回答が呼び出し元に戻り、呼び出し元が内容を整理して利用者へ回答します。呼び出し元が会話の主導権を維持したい場合に向いています。一方、固定された順序、グループチャット、人による承認を含む処理は、Foundry Workflowの方が設計しやすい場合があります。(Microsoft Learn)
A2Aが向く具体例
例えば、社内IT問い合わせを処理する統括エージェントから、次の専門エージェントを呼び出す構成が考えられます。
- Azureコスト分析エージェント
- Microsoft 365ライセンス確認エージェント
- セキュリティインシデント要約エージェント
- 社内規程検索エージェント
利用者が「Azureの請求額が増えた原因を調べて」と入力した場合、統括エージェントがコスト分析エージェントへ調査を委譲し、その結果を利用者向けに整理します。
各専門エージェントを別チームが管理し、独立して更新したい場合はA2Aが適しています。一方、「ログ収集、原因分析、人による承認、チケット登録」という固定手順であれば、Workflowを中心に設計した方が処理を予測しやすくなります。
管理者が確認すべき設定とガバナンス
Microsoft Entra IDとRBAC
Foundryが公開する受信A2Aエンドポイントは、Microsoft Entra ID認証が必須です。キー認証や匿名アクセスには対応していません。呼び出し元のユーザー、エージェントID、サービスプリンシパル、マネージドIDには、呼び出される側のFoundryプロジェクトでFoundry User以上のロールが必要です。(Microsoft Learn)
認証方式は、用途によって次のように分けます。
| 用途 | 適した認証方式 |
|---|---|
| バックエンド同士の自動連携 | エージェントID、サービスプリンシパル、マネージドID |
| 利用者ごとに参照可能データを変える | OAuth On-Behalf-Of |
| 外部のA2AエンドポイントがAPIキーを要求する | プロジェクト接続に共有キーを保存 |
| プロジェクト内の全エージェントで同じIDを使う | プロジェクトマネージドID |
Foundryが受信するA2A通信はEntra ID必須ですが、Foundryから外部のA2Aエンドポイントを呼び出す場合は、接続先の仕様に応じてキー、Entra ID、OAuth、匿名アクセスなどを選べます。この違いを混同すると、接続設定は作成できても実行時に401や403が発生します。(Microsoft Learn)
なお、公式ドキュメントではロール名が「Azure AI User」から「Foundry User」へ変更されています。管理画面や既存スクリプトに旧名称が残る場合がありますが、ロールIDと主要な権限は変更されていません。(Microsoft Learn)
公開前後のエージェントIDを確認する
Prompt agentなどを公開すると、ツール呼び出しに使用されるIDが、プロジェクト共有IDから公開エージェント固有のIDに変わる場合があります。公開前のIDに付与したAzure RBACは、新しいエージェントIDへ自動的に引き継がれません。
公開後にA2Aやストレージ、Cosmos DBなどへのアクセスが403になる場合は、現在のagentIdentityIdを確認し、必要なロールを再割り当てしてください。Hosted agentsについては、デプロイ時にエージェントごとの専用Entra IDが作成されるため、そのIDに対して外部リソースの権限を設定します。(Microsoft Learn)
プロジェクト単位のアクセス範囲に注意する
受信A2Aでは、呼び出し元IDに対象プロジェクトのFoundry Userロールを付与します。エージェント単位で完全に異なるアクセス境界を求める場合は、用途や機密区分に応じてFoundryプロジェクトを分けることも検討すべきです。
例えば、人事情報を扱うエージェントと一般的な社内FAQエージェントを同一プロジェクトに置くと、ロール設計や監査範囲が複雑になります。A2Aを有効化する前に、プロジェクトをセキュリティ境界として利用できるかを確認してください。
データ共有とコンテンツ安全性
A2Aでは、呼び出し元の入力や会話コンテキストの一部が、別のエージェントへ送信されます。次の情報は、原則としてそのまま渡さない設計が必要です。
- APIキー、接続文字列、アクセストークン
- 個人情報や人事情報
- 顧客の契約情報
- 不要な過去の会話履歴
- 呼び出し先の処理に関係しない社内文書
Foundry Agent Serviceには、危険な出力やプロンプトインジェクションのリスクを軽減するコンテンツ安全機能があります。ただし、Hosted agentsは独自コードで動作するため、メタプロンプト、入力検証、出力検証、アクセス制限など、アプリケーション側の安全対策も必要です。(Microsoft Learn)
外部のA2Aエンドポイントへ接続する場合は、送信データの保存場所、保持期間、再利用方針も確認してください。Microsoft以外のサービスへ送った情報は、Azureのコンプライアンス境界外で処理される可能性があります。(Microsoft Learn)
ログと監視
A2Aでは、呼び出し元だけを監視しても原因を特定できない場合があります。少なくとも次の情報を、呼び出し元と呼び出し先の両方で追跡できるようにします。
- 呼び出したエージェント名
- 呼び出し日時と処理時間
- 成功、認証失敗、タイムアウト
- 委譲理由
- 再試行回数
- フォールバックの有無
- モデル呼び出し回数
- ツール呼び出し回数
Foundry Agent Serviceではモデル呼び出しやツール実行をトレースできます。Hosted agentsではApplication Insightsの接続情報がコンテナへ注入され、対応するプロトコルライブラリからOpenTelemetryトレースが出力されます。(Microsoft Learn)
開発者向けの導入手順
呼び出される側の役割を明確にする
最初に、Agent Cardへ記載する役割を決めます。説明は「何でもできます」ではなく、対応範囲と対応しない範囲が分かる内容にします。
悪い例は「Azureに関する質問に回答するエージェント」です。対象が広すぎるため、呼び出し元が適切な委譲先か判断できません。
良い例は「Azure VMとManaged Diskの月額概算を算出する。契約変更、リソース作成、購入承認は行わない」です。役割と権限の境界が明確で、誤った呼び出しを減らせます。
A2AエンドポイントとAgent Cardを有効化する
受信A2Aの有効化には、Agent Cardとエンドポイントのプロトコル設定が必要です。2026年6月時点では、Foundryポータルから受信A2Aを有効化できないため、REST APIまたはPython SDKを利用します。ただし、Python SDKではAgent Cardを設定できないため、両方を一度に設定する場合はREST APIが分かりやすい方法です。(Microsoft Learn)
設定内容の例は次のとおりです。
{
"agent_card": {
"description": "Azure VMとManaged Diskの月額概算を返します。契約変更やリソース作成は行いません。",
"version": "1.0",
"skills": [
{
"id": "estimate-azure-cost",
"name": "Azure cost estimate",
"description": "SKU、リージョン、利用時間から月額の概算を作成します"
}
]
},
"agent_endpoint": {
"protocols": [
"responses",
"a2a"
]
}
}Agent Cardは、他のエージェントから見たインターフェース仕様です。説明やスキルを変更する際は、通常のAPI仕様変更と同様に、呼び出し元への影響を確認してください。
呼び出し先へのA2A接続を作成する
Foundry上のA2Aエンドポイントは、次の形式です。
https://{account}.services.ai.azure.com/api/projects/{project}/agents/{agent}/endpoint/protocols/a2aA2A v1.0のAgent Cardは、次のパスから取得します。
/agentCard/v1.0FoundryのAgent Cardは、一般的なA2A実装で使われる.well-known/agent-card.jsonではなく、専用パスを利用します。呼び出し元のプロジェクト接続には、AgentCardPathとして/agentCard/v1.0を設定します。
現時点では、FoundryポータルからカスタムAgent Cardパスを設定できないため、Foundryエージェント同士を接続する場合でもREST APIによる接続作成が必要になるケースがあります。(Microsoft Learn)
Foundry間の接続では、主に次の値を使用します。
category: RemoteA2A
authType: AgenticIdentity
audience: https://ai.azure.com
AgentCardPath: /agentCard/v1.0呼び出し元にA2Aツールを追加する
接続を作成したら、呼び出し元のPrompt agentやHosted agentにA2Aツールを追加します。Prompt agentではA2APreviewToolなどをエージェント定義へ追加し、作成したプロジェクト接続を参照します。
ツールの説明には、呼び出し条件を具体的に記載します。
Azure VM、Managed Disk、App Serviceの利用料金を概算するときだけ使用する。
実際の購入、契約変更、リソース作成には使用しない。「必要に応じて使う」とだけ記載すると、関係の薄い質問でもA2A呼び出しが発生し、応答時間やコストが増える可能性があります。
正常系だけでなく拒否系もテストする
動作確認では、回答内容だけでなく次のケースを試します。
- 正しいエージェントIDから呼び出せる
- ロールを持たないIDからの呼び出しが拒否される
- Agent Cardを取得できる
- 呼び出し先が停止した場合にフォールバックできる
- タイムアウト時に無限再試行しない
- 不要な会話履歴を送信していない
- プロンプトインジェクションを含む出力を無条件に採用しない
- エージェント同士が相互に呼び出し続けるループが発生しない
A2Aの最大ホップ数、タイムアウト、再試行回数、1リクエスト当たりのコスト上限を、アプリケーション側で決めておくことも重要です。
移行時に確認すべきポイント
Connected Agentsやagent.as_toolからの移行
新しいFoundry Agent Serviceでは、従来のConnected Agentsツールは提供されていません。Microsoftは代替として、A2AツールまたはFoundry Workflowの利用を案内しています。(Microsoft Learn)
移行先は、次の基準で選びます。
- 呼び出し元が回答を受け取り、会話を継続するならA2A
- 固定フロー、分岐、人による承認を管理するならWorkflow
- 同じプロセス内で密結合した処理ならFunction tool
- エージェントではなくデータ取得機能を共有するならMCP
Connected Agentsの構成をそのままA2Aへ置き換えるのではなく、主導権、会話履歴、エラー時の責任範囲を再設計してください。
初期プレビュー版Hosted agentsからの移行
2026年4月以前の初期プレビューでHosted agentsをデプロイしていた場合は、A2A対応とは別に、新しいホスティング基盤への移行が必要です。
初期プレビューのバックエンドは2026年5月22日でサポート終了となり、自動移行されません。新しいプロトコルライブラリ、専用エージェントID、専用エンドポイントを使って再デプロイする必要があります。(Microsoft Learn)
特に次の変更を確認します。
- フレームワーク専用アダプターからプロトコルライブラリへ変更する
- 共有プロジェクトエンドポイントからエージェント専用エンドポイントへ変更する
- 新しいエージェントIDへAzure RBACを付与する
agent.yamlのプロトコル宣言を更新する- Responsesプロトコルを実装する
- 新しいバージョンとして再デプロイする
Invocations専用Hosted agentはコード修正が必要
Webhookや独自JSONを受け取るためにInvocationsプロトコルだけを使っているHosted agentは、受信A2Aを有効化できません。
A2A対応が必要な場合は、現在のInvocationsを残しながらResponsesを追加できるかを検討します。Hosted agentsは複数のプロトコルを同時に公開できますが、Responsesリクエストを処理するサーバー実装とプロトコル宣言が必要です。(Microsoft Learn)
Public Previewで特に注意したい制限
2026年6月時点の主な制限は次のとおりです。(Microsoft Learn)
| 制限 | 影響と対処 |
|---|---|
| A2A v1.0とv0.3のみ対応 | 新規実装はv1.0を選ぶ |
| バージョン未指定時はv0.3 | v1.0のAgent Cardを取得するか、バージョンを明示する |
| v1.0はJSON-RPCのみ | HTTP+JSONを使うクライアントは修正が必要 |
| gRPC非対応 | JSON-RPCを利用する |
| テキストのみ対応 | ファイル、画像、音声を直接渡す設計は避ける |
| SSEストリーミング非対応 | 呼び出し先からの逐次表示を前提にしない |
| Hosted agentsはResponses必須 | Invocations専用の場合はコード修正と再デプロイが必要 |
| ポータル設定に制約がある | REST APIやSDKを展開手順に含める |
| SLAなし | 本番の主要経路には直ちに組み込まない |
失敗しやすいポイントと対処方法
| 症状 | 主な原因 | 確認する内容 |
|---|---|---|
| Agent Card取得時に401または403 | 呼び出し元IDの権限不足 | 対象プロジェクトのFoundry Userロール |
| Agent Cardが見つからない | デフォルトの.well-knownを参照している | /agentCard/v1.0を指定 |
| Hosted agentでA2Aを有効化できない | Responsesプロトコルを実装していない | コンテナ実装とプロトコル宣言 |
| A2A v1.0で通信エラーになる | HTTP+JSONを使用している | JSON-RPCへ変更 |
| 公開後に下流リソースへアクセスできない | エージェントIDが変わった | 現在のagentIdentityIdとRBAC |
| ファイルが呼び出し先へ渡らない | A2A受信がテキストのみ | 必要部分をテキスト化するか別の共有手段を使う |
| 関係のないエージェントが呼ばれる | Agent Cardやツール説明が曖昧 | 対象範囲と対象外を明記 |
| 応答が極端に遅い | 多段呼び出しや再試行が多い | ホップ数、タイムアウト、フォールバック |
| コストが想定より増える | 各エージェントが個別にモデルやツールを実行 | 呼び出し回数と処理内容をトレース |
| エージェント間でループする | 相互にA2Aツールを公開している | 最大ホップ数と呼び出し許可リスト |
安全に展開するためのチェックリスト
- [ ] A2Aを利用する業務目的と、A2Aを使わない処理を決める
- [ ] 統括エージェントと専門エージェントの責任範囲を分ける
- [ ] Prompt agentまたはResponses対応Hosted agentであることを確認する
- [ ] Agent Cardに対応範囲と対象外の処理を記載する
- [ ] 呼び出し元IDへ必要最小限のRBACを付与する
- [ ] 外部エージェントへ送信するデータ項目を確認する
- [ ] A2A v1.0とJSON-RPCを明示的に使用する
- [ ] タイムアウト、再試行、最大ホップ数を設定する
- [ ] Application Insightsなどで両側のトレースを確認する
- [ ] 認証失敗、接続失敗、誤委譲を含むテストを実施する
- [ ] 非本番環境で評価してから段階的に対象を広げる
- [ ] GA時に仕様、料金、SLA、リージョン対応を再確認する
Azure AI FoundryのA2A対応は、AIエージェントを専門機能ごとに分割し、別チームや別フレームワークのエージェントを再利用しやすくする更新です。一方で、通信先が増えるほど、権限、データ共有、障害原因、処理時間、コストの管理は複雑になります。
最初の検証では、非本番プロジェクトに「呼び出し元1つ、呼び出し先1つ」の構成を作り、Entra ID認証、Agent Card、A2A v1.0、トレースを確認してください。その後、タイムアウトや誤委譲のテストを行い、問題なく監査できることを確認してから対象業務を広げるのが安全です。
コメント