HOME/ビジネス/AIエージェント関連サービス/A2A

AIエージェント間連携（A2A）支援
異なる基盤のAIエージェントをつなぐ、A2A・MCP併用設計と統制基盤

部門ごとに作られたAIエージェントを、それぞれの独立性を保ったまま全社でつなぎ、接続先・⁠認証・⁠権限を統制する仕組みの設計・⁠実装・⁠検証を支援します。

01/概要

A2A（Agent2Agent Protocol）とは：AIエージェント同士をつなぐオープンな通信規格

A2A（エーツーエー、Agent2Agent Protocol）は、異なるベンダーやフレームワークで作られたAIエージェントが、互いの能力を見つけ、タスクを依頼し、結果を受け取るための共通の通信規格です。エージェント間通信、エージェント間連携とも呼ばれます。Googleが発表した規格で、現在はMCPと同じLinux Foundation傘下のAgentic AI Foundation（AAIF）のプロジェクトとして、中立的な体制で運営されています。2026年3月には、初の安定版の仕様（v1.0）が公開されました。

A2Aでは、相手のエージェントの内部の作り（使っているモデル、ツール、データ）を知らなくても、公開された能力の説明をもとにタスクを委任できます。エージェントとツール・⁠データをつなぐMCP（Model Context Protocol）とは役割が異なり、両者は組み合わせて使います。当社は、AIエージェント開発の一環として、A2AとMCPを組み合わせたエージェント連携を支援します。

A2Aの要点
正式名称・⁠読み方 Agent2Agent Protocol（A2A、エーツーエー）。Agent-to-Agent、エージェント間通信プロトコルとも表記
定義 異なるベンダー・⁠フレームワークのAIエージェントが、能力を見つけ、タスクを委任し、結果を受け取るためのオープンな規格
運営・仕様 Linux Foundation傘下のAgentic AI Foundation（2026年8月から）。2026年3月に仕様v1.0
主な構成要素 Agent Card、タスク、メッセージ、成果物（Artifact）、認証方式の宣言、Agent Cardの署名
MCPとの関係 A2Aはエージェント同士、MCPはエージェントとツール・⁠データ。補完関係で併用する
当社の支援 A2A・MCPの併用設計、A2Aサーバーと接続処理の構築・⁠検証、認証・⁠接続先管理の統制設計
組み合わせごとに個別実装
Agent AAgent B
⇅ ⤨ ⇅
Agent CAgent D
個別のAPI連携 エージェントの組み合わせごとに、呼び出し方と認証を作り込みます。接続先が増えるほど、実装と改修の手間が増えます。
単一の製品・⁠基盤
Agent AAgent B
他社SaaSのエージェント ✕
単一基盤への集約 同じ製品の中では連携しやすい一方、部門が使う他社SaaSや別の基盤のエージェントを取り込みにくくなります。
Agent AAgent BSaaS
A2A：共通の発見・⁠委任・⁠結果の形式
A2Aによる標準接続 各エージェントが共通の形式で能力を公開し、タスクを受け付けます。基盤やベンダーが違っても、同じ方法で接続できます。

02/注目される背景

マルチエージェントの広がりと、Agentic AI FoundationでのA2A・MCPの標準化・Microsoft製品のA2A対応

企業では、部門ごとに異なる製品やSaaSでAIエージェントが作られるようになりました。1つのエージェントで完結しない業務では、複数のエージェントを組み合わせる必要があり、つなぎ方の標準が求められています。

→ 部門ごとのエージェント：業務部門が、Copilot Studio、Microsoft Foundry、SaaS付属の機能など、異なる手段でエージェントを作るようになった
→ 1つで完結しない業務：問い合わせ、分析、手続きなど、複数の専門エージェントを組み合わせる業務が増えている
→ 個別連携の限界：組み合わせごとのAPI連携は、接続先が増えるほど実装と改修の負担が大きくなる。ツール接続ではMCPが標準になった
→ ベンダーロックインの回避：特定の製品に寄せず、相互運用性（インターオペラビリティ）を保った構成が求められている
→ 縦のワークフローの先行：社内では、手順と制御を決めて動かすエージェンティックワークフローが先に広がり、ツール・⁠データへの接続（MCP）が標準になった。組織や企業をまたいでエージェントを提供する段階で、A2Aが必要になる
→ 規格の中立化：A2AとMCPが、Linux Foundation傘下の同じ財団で運営されるようになった
→ 統制の必要性：エージェント間で委任が連鎖すると、認証、権限、記録の設計が欠かせなくなる。ハーネスエンジニアリングの考え方が必要になる

標準化団体・Microsoftの公式発表での位置づけ

A2AとMCPは、2026年8月から同じAgentic AI Foundation（AAIF）で運営されています。ツール・⁠データへの接続と、エージェント同士の通信の規格が、同じ中立的な体制のもとにそろいました。

エージェント連携の規格の動き（各発表をもとに作図）
2025年 GoogleがA2Aを発表し、Linux Foundationへ移管
→
2025年12月 Agentic AI Foundation設立。MCPが創設プロジェクトに
→
2026年3月 A2Aの初の安定版の仕様（v1.0）が公開
→
2026年8月 A2AもAgentic AI Foundationへ
→
2026年9月 FoundryのA2A機能がv1.0に対応
発行主体
記載内容
出典
Agentic AI Foundation（A2Aプロジェクト）
A2Aを、異なる組織・⁠フレームワーク・⁠技術で作られたエージェントが、能力を見つけ、通信し、タスクを委任し、協調するためのオープンなプロトコルと位置づけています。内部の実装を共有せず、単一のベンダーやフレームワークに依存せずに、専門のエージェントをつなげるとしています。
A2A Protocol（2026年3月12日）
A2A v1.0を、初の安定版で本番運用に対応した仕様として公開しました。複数の通信方式とバージョンの調整、1つのエンドポイントで複数のエージェントを扱うマルチテナント、署名付きのAgent Cardを加えています。MCPは個々のエージェントのツール・⁠コンテキストの接続、A2Aはエージェント間の通信と調整を扱い、多くのシステムで両方を使うとしています。
A2A Protocol（A2A and MCP）
MCPを、1つのエージェントにツールやデータを加えて深める「縦」の接続、A2Aを、別のチーム・⁠部門・⁠取引先のエージェントとつながる「横」の接続と説明しています。MCPは各エージェントの深さを、A2Aはシステムの広がりを担うとしています。
Agentic AI Foundation Blog（2026年9月1日）
A2A v1.0の解説で、Agent Cardの公開場所（/.well-known/agent-card.json）、JSON-RPC・gRPC・HTTP+JSONの3つの通信方式、Agent Cardの署名による改ざん検知、タスクの途中で認可を求める状態（AUTH_REQUIRED）を説明しています。
Agentic AI Foundation Blog（2026年10月1日）
MCPとA2Aで通信の方法はそろった一方、どのツールやエージェントが存在し、どれを使うべきかを見つける仕組み（ディスカバリー）は、各団体で検討が続いていると整理しています。
Microsoft Foundry（Microsoft Community Hub）
Foundryのエージェントを外部から呼び出せるA2Aエンドポイントと、Foundryのエージェントから他のA2A対応エージェントを呼び出すA2Aツールが、A2A v1.0に対応して一般提供されています。Hosted Agentsでは、MCPとして公開したFoundry Toolbox経由でA2Aツールを使えます。認証には、Entra IDのエージェントIDやOAuthを使えます。
Microsoft Learn（Copilot Studio）
Copilot Studioのエージェントから、A2Aに対応した外部のエージェントに接続し、タスクを委任できます。APIの呼び出しにはカスタムコネクタ、MCPのツールにはMCPサーバーを使うなど、目的に応じた接続方法の使い分けも示されています。

03/仕組み

A2Aの構成要素：Agent Card、タスク、メッセージ、成果物（Artifact）

A2Aでは、タスクを依頼する側をクライアントエージェント、受け付けて処理する側をリモートエージェントと呼びます。v1.0では、通信方式（バインディング）をJSON-RPC、gRPC、HTTP+JSON（REST）から選べます。時間のかかる処理では、途中経過をストリーミングや通知で受け取れます。

A2Aのやり取りの流れ（仕様の構成要素をもとに作図）
クライアント
エージェント依頼する側
1 → Agent Cardを取得　相手の名前、スキル、接続先URL、認証方式を確認
2 → タスクを送信　依頼内容をメッセージとして渡す
3 ← 状態を通知　処理中・⁠追加入力が必要・⁠完了などを返す
4 ← 成果物を返却　文書やデータなどの結果をArtifactとして返す
リモート
エージェント処理する側（内部は非公開）
要素 1 Agent Card エージェントの名前、説明、スキル、接続先、対応する入出力、認証方式を記述した名刺のような情報です。決められた場所（/.well-known/agent-card.json）で公開し、クライアントはこれを読んで依頼先を選びます。
要素 2 タスク（Task） 依頼の単位です。受付、処理中、追加入力が必要、認可が必要、完了、失敗などの状態を持ち、時間のかかる処理も追跡できます。
要素 3 メッセージとパート エージェント間でやり取りする内容です。テキスト、ファイル、構造化データを、パートとして組み合わせて送ります。
要素 4 成果物（Artifact） タスクの結果として返す文書、データ、画像などです。依頼側は、成果物を次の処理や別のエージェントへの依頼に使います。
要素 5 ストリーミングと通知 処理の途中経過をSSEで受け取ったり、完了時に通知を受けたりできます。長時間の処理や、人の確認を挟む処理に使います。
要素 6 認証と署名 Agent Cardに、OAuthなどの認証方式を宣言します。v1.0では、Agent Cardに署名を付けて改ざんを検知できます。企業では、Microsoft Entra IDなどのID基盤と組み合わせて設計します。

04/MCPとの違い

A2AとMCPの違いと併用：エージェント同士の協調と、ツール・⁠データへの接続

A2Aは、独立したエージェント同士の協調を扱います。MCPは、1つのエージェントが外部のツール、データ、業務システムを使うための接続を扱います。専門エージェントの内部でMCPを使い、専門エージェント同士をA2Aでつなぐのが基本の組み合わせです。

A2AとMCPの組み合わせ例
オーケストレーター（受付のエージェント）
↓A2A　エージェント間の委任↓
経費精算エージェント ↓ MCP　ツール・データ
会計システム 規程文書
SaaSのエージェント ↓ MCP　ツール・データ
SaaSのデータ
データ分析エージェント ↓ MCP　ツール・データ
Databricks Fabric
観点
A2A（Agent2Agent）
MCP（Model Context Protocol）
接続の向き
横：別のチーム・⁠部門・⁠取引先のエージェントとつながる（AIがAIに依頼する）
縦：1つのエージェントにツールやデータを加えて深める（AIがツールを呼び出す）
つなぐ相手
独立したエージェント同士
エージェントと、ツール・⁠データ・⁠業務システム（当社のMCP支援）
相手の性質
自ら計画し、複数の手順で処理を進める
定義された機能を呼び出され、結果を返す
能力の公開
Agent Card（スキルの説明）
ツール・⁠リソース・⁠プロンプトの一覧
やり取り
タスクの状態を持つ、複数回の対話や長時間の処理
要求ごとの呼び出しと結果の受け取り
向く場面
別の部門・⁠ベンダーのエージェントに仕事を任せる
1つのエージェントに、社内データや操作の手段を持たせる
データの置き場所
相手のエージェントの側にあり、自社の基盤からは直接扱わない
自社のエージェント基盤から、直接参照・⁠操作できる
統制の形
分散型：部門や相手先に管理を任せ、自由度を上げやすい
中央集権型：IT部門がデータと権限をまとめて管理しやすい

05/設計の進め方

AIエージェント間連携の設計：棚卸しから接続方式、統制、検証までの5工程

接続の技術を選ぶ前に、どのエージェントを誰が管理し、どこまで全社でつなぐかを決めます。

1
エージェントと接続先の棚卸し 部門ごとのエージェント、SaaS、業務システムを洗い出し、管理する部門、基盤、A2A・MCPへの対応状況を一覧にします。
成果 エージェント一覧 接続先の対応状況
2
連携のパターン設計 どの業務で、どのエージェントが受付と振り分けを担い、どこへ委任するかを決めます。A2Aでつなぐ相手と、MCPやコネクタでつなぐ相手を分けます。
成果 連携パターン A2A・MCPの使い分け
3
統制の設計 認証方式、委任できる権限の範囲、接続先の承認と台帳、実行の記録、Human-in-the-Loopで人の確認を挟む箇所を設計します。
成果 接続先台帳 認証・権限の方針
4
検証環境での構築 A2Aサーバー、オーケストレーション層との接続、Copilot Studioなどとの双方向の通信を、検証環境で構築して動作を確かめます。
成果 検証環境 接続の検証結果
5
本番に向けた方針の整理 検証結果をもとに、対象のエージェントを広げる順番、運用体制、技術と運用の方針をまとめます。全社の運営はAI Agent CoEと組み合わせます。
成果 本番化のロードマップ 運用方針

06/当社の支援内容

AIエージェント間連携の4つの支援メニュー：設計、A2A接続、統制、内製化

当社は、A2Aサーバーと接続処理の構築・⁠検証、接続先の対応状況に応じたA2A・MCPの併用設計、認証・⁠権限・⁠接続先管理を含む統制設計を、一体で支援します。顧客の現場に入るX-Tech FDEの体制で、検証環境での構築から本番に向けた方針の整理まで進めます。

段階 1 連携を設計する
支援1棚卸しとA2A・MCP併用設計
→
段階 2 つなぐ
支援2A2Aサーバーと接続処理の構築・⁠検証
→
段階 3 統制する
支援3認証・⁠権限・⁠接続先管理
→
段階 4 根づかせる
支援4技術検証・⁠人材育成
X-Tech FDE専任チームが全段階に伴走し、必要な段階から組み合わせて提供
支援 1

A2A・MCPの併用設計

既存のエージェントとSaaSを棚卸しし、A2Aを基本としながら、A2Aに対応していない接続先ではMCPを使う構成を設計します。オーケストレーターの置き場所と、委任のパターンも決めます。Microsoft Foundryでは、A2AのエージェントをMCPのツールボックス経由で呼び出す構成もとれるため、工数と将来の拡張性を比べて方式を選びます。

支援 2

A2Aサーバーと接続処理の構築・⁠検証

言語・⁠フレームワークの選定、コンテナ環境、A2Aサーバーの構築、オーケストレーション層やCopilot Studioとの双方向の通信を、検証環境で構築・⁠検証します。開発と運用の流れはDevSecOpsとして整えます。

支援 3

認証・⁠権限・⁠接続先管理の統制設計

部門が管理するエージェントを、全社の統制基盤から探索・⁠検索・⁠実行できるようにし、どの接続先をつなぐかをIT部門が管理する仕組みを設計します。Entra IDによる認証も組み込みます。

支援 4

技術検証・⁠人材育成

A2Aサーバー、スキル、タスクの状態管理、成果物の実装例を使った勉強会やデモで、顧客のエンジニアが自ら接続を作り、評価できるようにします。

組み合わせるサービス HWS Agent Camp HWS Copilot Agent Camp X-Tech FDE

07/連携基盤

エージェント連携基盤の構成：オーケストレーション、A2A接続、MCP接続、統制

部門のエージェントとSaaSは各部門が管理し、全社の統制基盤からは、登録されたエージェントを探索・⁠検索・⁠実行できるようにします。どの接続先をつなぐかは、IT部門が管理します。

連携基盤の構成例（顧客環境に合わせて構成）
利用者・業務
Microsoft 365 Copilot Teams 業務アプリ
↕
オーケストレーション層
Copilot Studio Microsoft Foundry Microsoft Agent Framework 受付と振り分け
↕
A2A接続　部門のエージェント
部門A 部門B SaaSのエージェント 各部門が管理
↕
MCP接続　ツール・⁠データ
A2A非対応のSaaS 業務システム データ基盤
↕
統制（全層に適用）
Entra ID Agent 365 API Management 接続先台帳 IT部門が管理
要素 1 オーケストレーション層 利用者の依頼を受け、登録されたエージェントから適切な相手を選んで委任します。基盤は、Copilot StudioやFoundryなど顧客の環境から選びます。
要素 2 A2Aサーバー 部門のエージェントをA2Aの形式で公開します。Agent Cardの公開、タスクの受付、状態の通知、成果物の返却を担います。
要素 3 MCP接続 A2Aに対応していないSaaSや業務システムは、MCPサーバーやコネクタで接続し、エージェントのツールとして使います。
要素 4 認証・認可 Entra IDによる認証と、API Managementによる接続の制御を組み合わせ、誰の権限で委任が行われたかを追えるようにします。
要素 5 接続先台帳 接続を許可したエージェントとSaaS、管理部門、認証方式、用途を一覧にし、追加と廃止はIT部門が承認します。
要素 6 記録と監視 委任の経路、タスクの状態、成果物、エラーを記録し、問題が起きたときにどこで止まったかを確認できるようにします。記録はループエンジニアリングによる継続改善に使います。

08/特長

つなぐ技術と統制設計の組み合わせ：当社の4つの特長

特長 1/4

検証環境でのA2A接続の構築知見

A2Aサーバーの構築、オーケストレーション層やCopilot Studioとの双方向の通信、Entra IDによる認証の構築を、検証環境で行った知見をもとに支援します。

特長 2/4

接続先に応じたA2A・MCPの併用

A2Aを基本としながら、対応していない接続先ではMCPを使います。当社はMCP支援として、既存APIのMCP化やカスタムMCPサーバーの構築も提供しています。

特長 3/4

部門の独立性と全社の統制を両立

立ち上げ時はMCP中心でIT部門が集中して管理し、エージェントが増えた段階でA2Aを使って部門へ管理を移す、段階的な構成を設計します。部門に管理を任せても、全社の統制基盤から探索・⁠実行でき、接続先はIT部門が承認します。Microsoft Agent 365などの管理機能とも組み合わせます。

特長 4/4

A2A通信を保護するセキュリティ設計

当社は、A2A通信とMCP連携をトークン認証で保護し、エージェントごとにIDを発行して権限を管理する構成を、ハイパーパーソナライゼーション基盤として発表しています。

09/顧客価値

課題から価値へ：エージェント連携で解決する課題と、役割別の価値

課題
価値につながる仕組み
得られる価値
部門ごとのエージェントが、別々の窓口に散らばっている
オーケストレーション層から、登録されたエージェントをA2Aで呼び出す
1つの窓口から使える、全社のエージェント
接続先が増えるたびに、個別の連携を作り込んでいる
A2Aの共通形式と、A2A非対応の接続先へのMCPを使い分ける
接続の追加・⁠変更にかかる手間の抑制
特定の製品に寄せると、他社SaaSのエージェントを使えない
ベンダーに依存しないオープンな規格でつなぐ
基盤を選び直せる、相互運用性
エージェントの接続先を把握できていない
接続先台帳と、IT部門による追加・⁠廃止の承認
後から確認できる、統制された連携
エージェント間の委任で、権限の範囲が曖昧になる
Entra IDによる認証と、委任できる範囲の設計、実行の記録
誰の権限で何が行われたかを追える運用

役割別の価値

経営・DX推進責任者 部門の取り組みを、全社の資産にする 部門ごとに作られたエージェントを、作り直さずに全社で使える形にし、投資の重複を減らせます。
業務部門 自分たちのエージェントを、管理したまま提供できる 部門のエージェントやSaaSの運用を部門に残したまま、全社の窓口から呼び出してもらえます。
IT・基盤管理 接続先と認証を、一元的に管理できる 接続先台帳と認証の方針にもとづき、エージェントの追加・⁠廃止と、接続の経路を管理できます。
セキュリティ・⁠リスク管理 委任の経路と権限を確認できる エージェント間の委任の経路、認証、実行の記録が揃い、監査に必要な根拠を後から確認できます。

10/取り組み事例

公開されている取り組み：MCP導入支援、A2A通信の保護、CoE、Agent Camp

MCPによる接続、A2A通信の認証、組織での推進にかかわる、当社の公開済みの取り組みです。

カスタムMCPサーバー導入ハンズオンラボサービス
MCP導入支援

カスタムMCPサーバー導入ハンズオンラボサービス

AIエージェント基盤の導入やAI CoEを設置するMicrosoft Azure、Microsoft 365 Copilot利用企業向けに、MCPのワークショップ・⁠アセスメントから、カスタムMCPサーバーの構築、Foundry・Copilot Studio・GitHubでのMCP活用までを伴走型で支援しています。

お知らせを見る →
Entra IDを活用したハイパーパーソナライゼーション基盤
認証・⁠セキュリティ

Entra IDを活用したハイパーパーソナライゼーション基盤

マルチエージェント構成の基盤で、AIエージェントごとにMicrosoft Entra Agent IDを発行し、RBACとPIMで権限を管理します。A2A通信やMCP連携をトークン認証で保護し、外部API接続時の秘密管理を強化しています。

お知らせを見る →
AI Agent CoE
組織での推進

AI Agent CoE

大手企業の生成AI戦略推進組織を包括支援するサービスです。技術支援、人材育成、戦略策定支援を、専任チームの伴走で提供します。

お知らせを見る →
HWS Agent Camp
試作・内製化

HWS Agent Camp

マルチエージェント時代に対応した、ワークショップ型の実践ハッカソンです。専門エンジニアが伴走し、2日間でAIエージェントのプロトタイプを構築します。

お知らせを見る →

11/想定ROI

接続工数の試算：接続先の追加、仕様変更への対応、接続先の審査

エージェントの組み合わせごとに個別で接続する場合と、A2Aの共通形式と接続先の台帳を使う場合の差を、業務別に試算します。

対象業務
試算の前提
削減工数（年間）
接続先の追加
年間12件の新しい接続。個別のAPI連携で1件40時間（計480時間）。A2Aの共通形式とテンプレートで1件16時間に短縮
約290時間
仕様変更への対応
接続先の仕様変更が年間20件、1件12時間（計240時間）。接続の共通化で、影響範囲の確認と改修を1件5時間に短縮
約140時間
接続先の審査
接続の申請が年間12件、個別の審査に1件10時間（計120時間）。接続先台帳と審査項目の標準化で1件4時間に短縮
約70時間
合計
上記3業務の合計
約500時間

件数と所要時間は、試算のための仮の値です。

実際の削減幅は、接続するエージェントの数、接続先のA2A対応状況、審査の運用で決まります。当社は、スタートプランで現行の接続・⁠改修・⁠審査の工数を実測し、連携の範囲を決めたうえで広げます。

12/活用シーン

全社窓口・SaaS連携・⁠データ分析・⁠顧客対応・IT運用・⁠グループ会社連携での活用イメージと適性

01

全社の問い合わせ窓口

Microsoft 365 CopilotやTeamsの1つの窓口から、人事、総務、情報システムなど、部門のエージェントへ依頼を振り分けます。

02

SaaSのエージェントとの連携

CRMや人事などのSaaSが提供するエージェントを、A2Aに対応していればA2Aで、対応していなければMCPやコネクタでつなぎます。

03

データ分析と報告

分析のエージェントがDatabricksやMicrosoft Fabric（Fabric IQ）のデータを使い、結果を報告書作成のエージェントへ渡します。

04

顧客対応

受付のエージェントが、商品検索、価格、レビュー要約などの専門エージェントに依頼し、結果をまとめて回答します。

05

IT運用

障害の受付、ログの調査、手順の実行を、別々のエージェントが分担し、人の確認を挟みながら処理を進めます。一連の流れはエージェンティックワークフローとして設計します。

06

グループ会社・⁠取引先との連携

組織をまたぐエージェント同士を、内部の作りを公開せずに、認証された接続でつなぐ構成を検証します。

AIエージェント間連携の適性チェック

適合する顧客
  • 部門ごとに、異なる製品やSaaSでエージェントが作られている
  • 利用者が1つの窓口から、複数のエージェントを使えるようにしたい
  • 部門の独立性を保ちながら、接続先をIT部門で管理したい
  • Microsoft 365・Azure・Copilot Studioを基盤に全社展開したい
  • 特定のベンダーに依存しない連携の形を検証したい
適合しにくい顧客
  • エージェントが1つで、他と連携する予定がない
  • すべてを1つの製品内で完結させる方針が決まっている
  • ツールやAPIを呼び出すだけで足りる（MCPやコネクタで十分）
  • 接続先の管理や認証の方針を決める担当者を置けない

導入検討のDiscovery質問

→ 社内には、どの部門に、どの製品やSaaSで作られたエージェントがありますか。
→ 利用者は、どの窓口（Teams、Microsoft 365 Copilot、業務アプリ）からエージェントを使っていますか。
→ つなぎたい相手のエージェントやSaaSは、A2AやMCPに対応していますか。
→ エージェントの追加や接続を、誰が承認する決まりになっていますか。
→ エージェントが他のエージェントに委任するとき、どの権限で処理させる想定ですか。
→ Copilot Studio、Foundry、Entra IDは、すでに利用していますか。

13/他の手段との違い

個別のAPI連携・⁠単一製品への集約・MCPのみの接続・⁠製品付属のコネクタとの違いと使い分け

手段
主にできること
当社の支援との違い
個別のAPI連携
エージェントの組み合わせごとに、呼び出しと認証を作り込む
A2Aの共通形式でつなぎ、接続先の追加・⁠変更の手間を抑えます。既存のAPI連携は、MCPやコネクタとして残せます。
単一製品への集約
同じ製品の中で、エージェント同士を連携させる
製品内の連携は活かしたうえで、他社SaaSや別の基盤のエージェントも、オープンな規格で取り込みます。
MCPのみの接続
エージェントにツール・⁠データへの接続手段を持たせる
MCPは併用の前提とし、自ら計画して処理を進める独立したエージェント同士の委任には、A2Aを使います。
製品付属のコネクタ
製品が用意した接続先と、決められた方法でつなぐ
コネクタで足りる接続はそのまま使い、足りない接続先はA2AサーバーやMCPサーバーを構築します。
自社のみでの検証
社内の人材で、規格の調査と試作を進める
当社の構築・⁠検証の知見と実装例を使って検証を早め、勉強会とハンズオンで顧客側の内製化へ移します。

14/ガバナンス

接続先台帳・⁠認証・⁠権限・⁠委任範囲・⁠承認・⁠記録：エージェント間連携の統制設計

エージェント同士がつながると、1つの依頼が複数のエージェントとシステムに広がります。誰の権限で、どこまで委任できるかを、接続の前に決めます。

統制 1 接続先台帳 接続を許可したエージェントとSaaS、管理部門、用途、認証方式を台帳にまとめ、全社のAIガバナンスの方針に沿って、IT部門が追加と廃止を承認します。
統制 2 Agent Cardの管理 公開するスキルと説明を、管理部門が責任を持って更新し、利用者が依頼先を正しく選べるようにします。エージェントが参照する業務の文脈は、コンテキストエンジニアリングやオントロジーで整えます。
統制 3 認証・認可 Microsoft Entra IDによる認証を前提に、エージェント間の通信をトークンで保護します。
統制 4 委任できる範囲 利用者の権限で処理するのか、エージェントの権限で処理するのかを決め、委任が連鎖しても権限が広がらない設計にします。
統制 5 人の確認と記録 影響の大きい処理には、追加入力の状態を使って人の確認を挟み、委任の経路と結果を記録します。
統制 6 エージェントの統制基盤 Microsoft Agent 365とAgentic Securityを組み合わせ、エージェントの登録、ID、権限、監視を統制します。脅威の検知はDefenderやSentinelと連携します。

15/はじめ方

スタートプラン：HWS Agent Campで、最初のエージェント連携を2日間で試作・⁠検証

HWS Agent Campは、マルチエージェント時代に対応した、専門エンジニアが伴走する2日間の集中ハッカソンです。約2週間の事前準備のうえで、本格的なプロトタイプを構築します。最初につなぐ2〜3のエージェントと接続方式を決め、試作と評価を同時に進められます。

HWS Agent Camp
STEP 1事前準備（約2週間）既存のエージェントとSaaSの棚卸し、つなぐ業務、認証の前提を整理します。
STEP 22日間の集中開発顧客側のエンジニアと専門家が共同で、A2A・MCPによる連携のプロトタイプを構築します。
STEP 3検証・⁠連携方針の策定評価結果をもとに、接続方式、統制の設計、本番に向けたロードマップを策定します。

16/当社について

認定バッジ

Microsoft Azure の AI Platform/Agentic DevOps Specialization取得

ヘッドウォータースは「Microsoft Solutions Partner for Digital & App Innovation（Azure）」の認定に加え、上位資格である「AI Platform on Microsoft Azure」「Agentic DevOps with Microsoft Azure and GitHub」の2領域のSpecializationを取得しています。厳格な技術要件と導入実績を満たしたパートナーのみに付与される称号で、2領域の同時取得は国内でも限られています。

認定バッジ

Microsoft AI Innovation Partner of the Year 2024 受賞

「AI イノベーション パートナー オブ ザ イヤー アワード」は、マイクロソフト製品の活用によってAI分野で革新を起こしたパートナーに贈られるアワードとして2024年に新設され、ヘッドウォータースは同分野において最も優れた実績をあげたとの評価を受け、初代受賞パートナーとなりました。

17/関連ソリューション

AI Agent CoE

エージェントを全社で運営する組織

AI Agent CoE. 技術支援、人材育成、戦略策定支援を、専任チームの伴走で提供します。

MCP（Model Context Protocol）支援

ツール・⁠データへの接続を標準化

MCP（Model Context Protocol）支援. 既存APIのMCP化、カスタムMCPサーバーの構築、Foundry・Copilot Studioへの組み込み、認証・⁠統制まで支援します。

Entra IDを活用したハイパーパーソナライゼーション基盤

A2A通信をトークン認証で保護

Entra IDを活用したハイパーパーソナライゼーション基盤. エージェントごとのID発行、RBACとPIMによる権限管理、A2A通信とMCP連携の保護を組み合わせます。

Agentic Security

エージェントのID・権限・⁠データ接続の保護

Agentic Security. AIエージェントが利用するID、権限、データ接続、実行履歴を継続的に把握・⁠保護します。

Microsoft Foundry（Azure AI Foundry）エージェント

Azure上のエージェント実行基盤

Microsoft Foundry（Azure AI Foundry）エージェント. モデルの選定・⁠評価・⁠デプロイから運用まで、Azure上でAIエージェントを構築します。

HWS Agent Camp

最初の連携を2日間で試作

HWS Agent Camp. 専門エンジニアが伴走する2日間の集中ハッカソン。約2週間の事前準備のうえで、プロトタイプを構築します。

18/よくあるご質問

Q. A2A（Agent2Agent Protocol）とは何ですか。 A. 異なるベンダーやフレームワークで作られたAIエージェントが、互いの能力を見つけ、タスクを委任し、結果を受け取るためのオープンな通信規格です。Agent-to-Agent、エージェント間通信プロトコルとも呼ばれます。Googleが発表し、現在はLinux Foundation傘下のAgentic AI Foundation（AAIF）のプロジェクトとして運営されています。2026年3月に初の安定版の仕様（v1.0）が公開されました。
Q. A2AとMCPの違いは何ですか。 A. A2Aは独立したエージェント同士の協調を、MCP（Model Context Protocol）はエージェントとツール・⁠データ・⁠業務システムの接続を扱います。競合ではなく補完の関係で、専門エージェントの内部でMCPを使い、エージェント同士をA2Aでつなぐのが基本の組み合わせです。
Q. A2AとMCPは、どちらを先に導入すべきですか。 A. 接続先のデータの置き場所で判断します。自社のエージェント基盤から直接扱えるデータや業務システムはMCP、相手のエージェントの側にあるデータや処理はA2Aです。社内の決まった手順で動かすワークフローはMCPで始めやすく、公開事例も多いため、まずMCP中心で立ち上げ、組織や企業をまたぐ連携が増えた段階でA2Aを加える進め方が一般的です。当社は、接続先の対応状況と工数を比べたうえで、併用の構成を設計します。
Q. Copilot StudioやMicrosoft Foundryと組み合わせられますか。 A. はい。Copilot Studioでは、A2Aに対応した外部のエージェントに接続し、タスクを委任できます。当社は、Copilot StudioやMicrosoft Foundryをオーケストレーション層とし、部門のエージェントとつなぐ構成を設計・⁠検証します。
Q. A2Aに対応していないSaaSは、つなげられますか。 A. つなげます。A2Aに対応していない接続先は、MCPサーバーやコネクタで接続し、エージェントのツールとして使います。
Q. 既存のエージェントを作り直す必要はありますか。 A. 多くの場合、作り直す必要はありません。既存のエージェントの前にA2Aサーバーを置き、A2Aの形式で公開する方法を検討します。対象のフレームワークと構成に応じて判断します。
Q. セキュリティはどのように確保しますか。 A. Microsoft Entra IDによる認証、トークンによる通信の保護、委任できる権限の範囲の設計、接続先台帳、実行の記録を組み合わせます。エージェントの登録・ID・監視にはMicrosoft Agent 365やAgentic Securityも組み合わせます。
Q. 部門ごとにエージェントを管理したままでも、全社でつなげられますか。 A. はい。エージェントとSaaSの管理は部門に残し、全社の統制基盤から探索・⁠検索・⁠実行できるようにします。どの接続先をつなぐかは、IT部門が台帳で管理します。
Q. どのような環境で構築しますか。 A. 顧客の環境に合わせて構築します。Microsoft 365・Azureを中心に、Copilot Studio、Microsoft Foundry、Microsoft Agent Framework、Semantic Kernel、Pythonなど、接続するエージェントに応じて選びます。
Q. 何から始めればよいですか。 A. 既存のエージェントと接続先の棚卸しから始めます。短期間で試したい場合は、2日間のHWS Agent Campで、最初につなぐエージェントと接続方式を決めて試作します。
Q. 効果は、どのように測りますか。 A. 現行の接続、改修、審査の工数を実測し、接続するエージェントの数とあわせて、連携の範囲を決めます。一律の削減率や回収期間は、事前にお約束しません。
Q. エンジニア向けの勉強会はありますか。 A. あります。A2Aサーバー、スキル、タスクの状態管理、成果物の実装例を使った勉強会やデモを行い、顧客のエンジニアが自ら接続を作れるよう支援します。

AIエージェント間連携・A2Aに関するご相談

既存エージェントの棚卸し、A2A・MCPの接続方式、認証と接続先管理の設計、検証環境での構築まで、貴社の状況に合わせてご提案します。

お問い合わせ