【マルチエージェント】A2Aの現状：マルチエージェント実装エンジニア向け技術整理

1. 結論

A2A、Agent2Agent Protocolは、異なるフレームワーク、異なるベンダー、異なるサーバー上で動くAIエージェント同士を接続するための標準プロトコルである。

現状の重要ポイントは次の通り。

• A2AはGoogle発だが、現在はLinux Foundation配下のオープン標準として運営されている。
• 2026年時点ではA2A v1.0が公開され、production-readyな標準として位置づけられている。
• MCPが「Agent-to-Tool」の標準であるのに対し、A2Aは「Agent-to-Agent」の標準である。
• 実装上の中心概念は、Agent Card、Message、Task、Part、Artifactである。
• Python、JavaScript、Java、Go、.NETなど複数SDKが整備されつつある。
• 企業利用では、認証、Agent Card署名、multi-tenancy、streaming、push notification、TCK/Inspectorが重要になる。

A2Aは、単なる「エージェント同士のチャット仕様」ではない。
実装エンジニアの視点では、エージェントをHTTPベースの分散サービスとして公開し、能力発見、タスク委譲、長時間処理、成果物交換、進捗監視を標準化する仕組みと見るべきである。

---

2. A2Aとは何か

A2Aは、AIエージェント同士が安全に通信し、タスクを委譲し、結果を受け取り、必要に応じて多段階・長時間の協調作業を行うためのプロトコルである。公式ドキュメントでは、A2AはGoogleが開発し、現在はLinux Foundationに寄贈されたオープン標準と説明されている。

A2Aの目的は、以下のような状況を解くことである。

LangGraph製のAgent
  ↔ CrewAI製のAgent
  ↔ Semantic Kernel製のAgent
  ↔ 自社Python Agent
  ↔ SaaSベンダーのAgent

従来は、これらを連携させるには個別APIを作る必要があった。
A2Aは、その間に共通の通信モデルを置く。

A2Aの公式GitHubでは、A2Aは「opaque agentic applications」間の通信と相互運用性を可能にするプロトコルと説明されている。ここでopaqueとは、相手Agentの内部メモリ、ツール、プロンプト、実装詳細を公開せずに連携できる、という意味である。

---

3. 現状：A2Aはv1.0段階に入った

2026年時点で最も重要なのは、A2A v1.0が公開され、production-readyな標準として打ち出されている点である。A2A v1.0は、複数プロトコルバインディング、バージョンネゴシエーション、共通セマンティックモデルにより、異なるシステム間で予測可能なAgent連携を可能にすることを狙っている。

v1.0で特に重要な強化点は以下である。

項目	内容
Enterprise対応	multi-tenancy、Agent Card署名、セキュリティ強化
Web整合性	HTTP、JSON-RPC、gRPC、HTTP+JSON/REST
長時間処理	polling、streaming、webhook/push notification
型安全性	enum、Part、Message、Task構造の整理
検証性	TCK、Inspector、SDK整備

v1.0のロードマップでは、A2A ProjectがPython、Go、JS、Java、.NETの5言語SDKをホストしていること、またA2A InspectorとTechnology Compatibility Kit、TCKによる検証が進められていることが示されている。

---

4. MCPとの違い

A2Aを理解する上で最も大事なのは、MCPとの違いである。

MCPは、Agentが外部ツール、API、データベース、リソースを使うためのプロトコルである。
A2Aは、Agentが別のAgentと協調するためのプロトコルである。公式ドキュメントでも、MCPはツール・リソース接続、A2AはAgent間協調を扱う補完関係と説明されている。

整理するとこうなる。

観点	MCP	A2A
対象	Tool / API / DB / Resource	Agent / Agentic system
主な役割	Agentが道具を使う	AgentがAgentに仕事を頼む
入出力	比較的構造化・単発	会話的・状態あり・長時間
典型例	DB検索、CFD実行、PDF検索	CFD Agentへ解析依頼、購買Agentへ調達依頼
関係	Agent内部で使う	Agent間で使う

実務では、MCP inside, A2A outside と考えると分かりやすい。

User
 ↓
Project Manager Agent
 ↓ A2A
CFD Agent
 ↓ MCP
Mesh Tool / Solver Tool / Post Tool

つまり、A2A Agentの内部ではMCPを使ってツールを呼ぶ。
外部Agentとの協調にはA2Aを使う。

---

5. A2Aの基本アーキテクチャ

A2Aの基本構成はシンプルである。

User
 ↓
A2A Client / Client Agent
 ↓ A2A Protocol
A2A Server / Remote Agent
 ↓
Internal Agent Runtime
 ↓
Tools / MCP / DB / Workflow

A2Aの登場人物は、User、A2A Client、A2A Serverである。A2A ServerはHTTP endpointを公開するRemote Agentであり、クライアントから見ると内部メモリやツールを公開しないブラックボックスとして動作する。

重要なのは、A2A Serverは必ずしも単一LLMではないことである。

A2A Server =
  LangGraph workflow
  CrewAI team
  Microsoft Agent Framework workflow
  Semantic Kernel agent
  自社Python orchestration
  既存業務システム + LLM wrapper

つまりA2Aは、Agentの中身を標準化するものではない。
Agentの外部インターフェースを標準化するものである。

---

6. コア概念

A2Aの実装で最低限押さえるべき概念は、Agent Card、Message、Part、Task、Artifactである。

概念	意味
Agent Card	Agentの名刺。能力、endpoint、認証、skillを記述
Message	ClientとAgentの1ターン通信
Part	MessageやArtifact内のコンテンツ単位
Task	状態を持つ作業単位
Artifact	Agentが生成した成果物

公式ドキュメントでは、Agent CardはAgentのidentity、capability、endpoint、skills、authentication requirementsを記述するJSONメタデータとされている。また、Taskは一意IDとライフサイクルを持つstatefulな作業単位、Artifactはドキュメント、画像、構造化データなどの具体的成果物と説明されている。

A2Aでは、軽い問い合わせならMessageだけで返してよい。
一方、時間がかかる処理、進捗管理が必要な処理、追加入力が必要な処理はTaskとして扱う。

単純応答:
Client → Message → Agent
Agent  → Message

長時間処理:
Client → Message
Agent  → Task created
Client → GetTask / SubscribeToTask
Agent  → Status update / Artifact

Taskは、completed、failed、canceled、rejected、input-required、auth-requiredなどの状態を持つ。A2Aでは、Taskが終端状態に達したら再開せず、修正や追加依頼は同じcontextId内の新しいTaskとして扱う設計になっている。これはトレーサビリティ上かなり重要である。

---

7. Agent Discovery：Agent Cardをどう見つけるか

A2Aの発見機構は、Agent Cardをどう取得するかが中心である。

代表的な方法は3つある。

方式	内容	向く用途
Well-known URI	/.well-known/agent-card.jsonに配置	公開Agent、ドメイン単位
Registry	中央カタログでAgent Cardを管理	企業内Agent marketplace
Direct config	設定ファイルや環境変数に直接指定	開発、閉じた社内連携

公式ドキュメントでは、well-known URI、curated registry、direct configuration/private discoveryの3方式が整理されている。企業利用ではRegistryが有効だが、現時点のA2A仕様はRegistry API自体を標準化していない点に注意が必要である。

実装方針としては、最初は以下でよい。

開発初期:
- Direct config

社内PoC:
- Git管理されたAgent Card一覧
- または簡易Registry

本番:
- 認証付きRegistry
- Agent Card署名
- 権限別のSelective Disclosure

Agent Cardは、Agentの能力を外部に見せる入口なので、機密情報を書きすぎないことが重要である。公式ドキュメントでも、内部URLや機密skillを含むAgent Cardは認証・認可で保護すべきとされている。

---

8. 実装例：タービンCFD AgentをA2A化する

ここでは、タービン設計システム向けに、CFD AgentをA2A Serverとして公開する例を考える。

8.1 Agent Card例

以下は概念例である。実実装では、利用SDKのv1.0型定義に合わせる。

{
  "name": "Turbine CFD Agent",
  "description": "Runs turbine CFD cases, monitors convergence, and returns post-processed results.",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/turbine-cfd",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Internal Engineering AI",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": true
  },
  "defaultInputModes": [
    "text/plain",
    "application/json"
  ],
  "defaultOutputModes": [
    "text/plain",
    "application/json"
  ],
  "skills": [
    {
      "id": "run-cfd-case",
      "name": "Run CFD Case",
      "description": "Creates CFD setup, launches solver, monitors convergence, and returns summary artifacts.",
      "tags": ["cfd", "turbine", "mesh", "postprocess"],
      "examples": [
        "Run CFD for case SEC001 with inlet total pressure and outlet static pressure."
      ],
      "inputModes": ["application/json"],
      "outputModes": ["application/json", "text/plain"]
    }
  ]
}

v1.0のAgent Cardでは、name、description、supportedInterfaces、version、capabilities、defaultInputModes、defaultOutputModes、skillsなどが定義される。supportedInterfacesにはURL、protocol binding、protocol versionを持たせる構造で、JSON-RPC、gRPC、HTTP+JSONなどのバインディングを表現できる。

8.2 Client側の流れ

A2A Client側は、だいたい以下の流れになる。

# 擬似コード

agent_card = fetch_agent_card(
    "https://agents.example.com/.well-known/agent-card.json"
)

if not supports_skill(agent_card, "run-cfd-case"):
    raise RuntimeError("CFD skill is not available")

endpoint = select_interface(
    agent_card,
    preferred_binding="HTTP+JSON",
    protocol_version="1.0"
)

task = send_message(
    endpoint=endpoint,
    message={
        "role": "ROLE_USER",
        "parts": [
            {
                "data": {
                    "case_id": "SEC001",
                    "geometry": "blade_row_A",
                    "inlet_total_pressure": 250000.0,
                    "inlet_total_temperature": 420.0,
                    "outlet_static_pressure": 101325.0,
                    "working_fluid": "air"
                },
                "mediaType": "application/json"
            }
        ]
    }
)

while not is_terminal(task.status.state):
    task = get_task(endpoint, task.id)
    print(task.status.state)

artifacts = task.artifacts

A2A v1.0のProtocol Definitionでは、SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTaskなどの操作が定義されている。HTTP+JSONでは、例えばPOST /message:send、POST /message:stream、GET /tasks/{id}のようなエンドポイントになる。

8.3 Server側の考え方

Server側では、A2A SDKのExecutorが受け取ったMessageを、自社の内部Agentやワークフローに渡す。

# 擬似コード

class TurbineCfdExecutor:
    async def execute(self, context, event_queue):
        request = parse_user_message(context)

        task = create_task(
            name="run-cfd-case",
            context_id=context.context_id
        )

        await event_queue.publish_status(
            task_id=task.id,
            state="TASK_STATE_WORKING",
            message="Creating mesh..."
        )

        mesh_result = await run_mesh_tool(request)

        await event_queue.publish_status(
            task_id=task.id,
            state="TASK_STATE_WORKING",
            message="Launching CFD solver..."
        )

        solver_result = await run_solver_tool(mesh_result)

        post_result = await run_postprocess_tool(solver_result)

        await event_queue.publish_artifact(
            task_id=task.id,
            name="cfd_summary",
            data={
                "converged": post_result.converged,
                "efficiency": post_result.efficiency,
                "loss_coefficient": post_result.loss_coefficient,
                "max_mach": post_result.max_mach
            },
            media_type="application/json"
        )

        await event_queue.publish_status(
            task_id=task.id,
            state="TASK_STATE_COMPLETED",
            message="CFD case completed."
        )

Python SDKでは、Agent ExecutorがA2A Agentの中核ロジックを担当し、executeでリクエスト処理、cancelでキャンセル処理を扱う構造になっている。ExecutorはEventQueueを通じてMessage、Task、TaskStatusUpdateEvent、TaskArtifactUpdateEventなどを返す。

---

9. A2Aのユースケース

9.1 企業内Agent Marketplace

大企業では、部署ごとにAgentが乱立する可能性が高い。

経理Agent
法務Agent
調達Agent
設計Agent
解析Agent
営業Agent
品質保証Agent

A2Aを使うと、それぞれを独立サービスとして公開し、Agent Cardで能力を発見し、必要なAgentへタスクを委譲できる。

例えば、設計Agentが調達Agentに材料コストを問い合わせ、法務Agentに輸出規制確認を依頼し、品質保証Agentに検査基準を確認する、といった構成である。

9.2 マルチベンダーAgent連携

A2Aの本命ユースケースは、異なるベンダーのAgent同士の連携である。Googleの発表時点で、Atlassian、Box、Cohere、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、Workdayなど多数のパートナーが言及されている。

これは、以下のような世界を想定している。

社内Agent
  ↔ Salesforce Agent
  ↔ ServiceNow Agent
  ↔ SAP Agent
  ↔ Workday Agent
  ↔ Box / Google Drive / Atlassian Agent

企業システムでは、1つのAgentが全SaaSを直接制御するより、それぞれのSaaS側Agentに仕事を委譲する方が自然である。

9.3 タービン設計システム

タービン設計システムでは、A2Aは以下のように使える。

Project Manager Agent
  ↔ Requirement Agent
  ↔ 1D Design Agent
  ↔ CFD Agent
  ↔ Optimization Agent
  ↔ Knowledge Agent
  ↔ Report Agent

内部ではそれぞれがMCPでToolを使う。

CFD Agent
  ↓ MCP
Mesh Tool
Solver Tool
Post Tool

Knowledge Agent
  ↓ MCP
PDF Search Tool
Design DB Tool
Trouble Case Search Tool

Optimization Agent
  ↓ MCP
DOE Tool
Surrogate Model Tool
Optimizer Tool

この構成のメリットは、各Agentを独立に改善できることだ。
CFD Agentだけを高性能化したり、Knowledge AgentだけをRAG/GraphRAG対応にしたりできる。

9.4 長時間タスクの委譲

A2Aは、CFD、CAE、最適化、レポート生成のような長時間タスクと相性がよい。

Client:
  「この設計案のCFDを回して」

CFD Agent:
  Task created
  Mesh generating
  Solver running
  Convergence checking
  Post-processing
  Artifact returned

Messageだけのチャット仕様では、このような処理は扱いにくい。
A2AのTaskライフサイクルは、長時間実行、進捗更新、成果物返却に向いている。

---

10. 実装パターン

パターン1：Thin Wrapper型

既存システムをA2A Serverとして包む。

A2A Server
  ↓
既存API
  ↓
既存設計ツール

最も現実的な初期実装である。
既存のCFDジョブ投入API、設計DB検索API、レポート生成APIをA2A Agentとして公開する。

パターン2：Workflow Agent型

Agent内部にLangGraphやMicrosoft Agent Frameworkのようなワークフローを持つ。

A2A Server
  ↓
Workflow Runtime
  ├─ Step 1: validate input
  ├─ Step 2: call tool
  ├─ Step 3: verify result
  └─ Step 4: return artifact

タービン設計やCAE連携では、この形が本命である。

パターン3：Agent Broker型

A2A Clientが複数Agentを探して、最適なAgentへ仕事を割り振る。

Broker Agent
  ↓ Agent Registry
  ↓ Agent Card selection
  ↓ A2A delegation

社内Agent Marketplaceを作る場合に有効である。

パターン4：External Partner Agent型

社外ベンダーやSaaSのAgentへタスクを委譲する。

Internal Design Agent
  ↔ Supplier Agent
  ↔ Cost Estimation Agent
  ↔ Compliance Agent

この場合は、認証、署名、監査ログ、入力サニタイズが必須になる。

---

11. セキュリティ設計

A2AはAgent同士をつなぐため、セキュリティ設計が非常に重要である。

公式ドキュメントでは、本番環境のA2A通信はHTTPSで行うべきであり、認証はOAuth2、OpenID Connect、API Keyなど標準的なHTTPレイヤーの仕組みに委譲される。A2A payload自体にuser identityを直接入れるのではなく、HTTP headerで資格情報を渡す設計である。

実装時の注意点は以下である。

- 外部Agentを信用しない
- Agent CardをそのままLLMプロンプトに入れない
- skill.descriptionをサニタイズする
- Artifactを検証してから利用する
- credentialsをA2A message内に入れない
- HTTP headerで認証する
- Agent Card署名を検証する
- 監査ログを残す

A2A samplesリポジトリでも、外部Agentから受け取るAgentCard、messages、artifacts、task statusesは信頼できない入力として扱うべきであり、LLMプロンプトに未サニタイズで入れるとprompt injectionの危険があると明記されている。

---

12. 現在の技術トレンド

A2Aのトレンドは、以下の5つに整理できる。

12.1 Framework競争からProtocol標準化へ

これまでは、AutoGen、CrewAI、LangGraph、Semantic Kernelなど、Agent framework単位の競争が中心だった。
A2Aは、その上位にある相互運用レイヤーである。

今後は、

どのAgent frameworkを使うか

だけでなく、

そのAgentをどう標準インターフェースで公開するか

が重要になる。

12.2 Agentはmicroservice化する

A2Aでは、AgentはHTTP endpointを持つRemote Agentとして扱われる。これは、Agentをmicroserviceのように設計する方向である。

1 Agent = 1 Capability Service

この考え方は、企業システムにかなり合っている。

12.3 Agent CardがAPI仕様書に近づく

REST APIでOpenAPIが重要だったように、A2AではAgent Cardが重要になる。

Agent Cardには、Agentの能力、認証、endpoint、input/output mode、skillsが含まれる。つまり、Agent CardはAgentの仕様書である。

将来的には、Agent Cardの品質がAgent連携の品質を左右する。

12.4 長時間タスク管理が標準機能になる

A2Aは、単発チャットよりも長時間タスクを重視している。
Task、contextId、Artifact、streaming、push notificationは、CAE、設計、データ分析、業務処理などと相性がよい。

特に工学設計では、CFDや最適化は数分から数時間かかるため、Taskベースの設計は必須である。

12.5 検証・互換性ツールが重要になる

A2Aのロードマップでは、A2A InspectorとTCKが検証ツールとして挙げられている。これは、A2A Agentが仕様通りに動くかをテストするために重要である。

今後は、A2A Agentを作るだけでなく、

- Agent Cardが正しいか
- protocol versionが合っているか
- Task状態遷移が正しいか
- streamingが仕様通りか
- 認証が正しいか

を自動検証する流れになる。

---

13. 導入判断

A2Aを今すぐ導入すべきケースは以下である。

- 複数Agentを別サービスとして運用したい
- 異なるframeworkのAgentを接続したい
- 社内Agent marketplaceを作りたい
- 長時間タスクをAgentに委譲したい
- 外部SaaS Agentや社外Agentと連携したい
- Agentの内部実装を隠して能力だけ公開したい

逆に、まだA2Aが重いケースもある。

- 単一アプリ内で数個のAgentを動かすだけ
- すべて同じframework内で完結する
- 外部Agent連携がない
- Tool呼び出しだけで十分
- まずはPoCを最短で作りたい

この場合は、まずLangGraph、Microsoft Agent Framework、CrewAIなどの内部ワークフローで十分である。
A2Aは、Agentを外部公開・分散連携・企業間連携する段階で効いてくる。

---

14. タービン設計システムへの実務的提案

タービン設計システムでは、最初から全AgentをA2A化する必要はない。

おすすめは次の順番である。

Phase 1:
内部ワークフローとして
Requirement Agent
Design Agent
Verification Agent
Report Agent
を構築する

Phase 2:
1D設計、CFD、最適化、RAG検索をMCP Tool化する

Phase 3:
CFD AgentやKnowledge Agentなど
境界が明確なAgentからA2A Server化する

Phase 4:
Agent Card Registryを作り
社内Agent marketplace化する

Phase 5:
調達、コスト、品質保証、PLM/PDMとA2A連携する

特にA2A化すべきAgentは以下である。

Agent	A2A化の優先度	理由
CFD Agent	高	長時間Task、Artifact返却と相性がよい
Knowledge Agent	高	他Agentから横断利用される
Optimization Agent	高	DOE/最適化が長時間処理
Report Agent	中	Artifact生成が明確
Requirement Agent	中	対話が多く内部Agentでもよい
Verification Agent	中	内部ワークフロー密結合でもよい

結論として、タービン設計システムでは、A2Aは初期実装の中心技術というより、Agent群が増えてからの分散連携・標準化技術として使うのがよい。

---

15. まとめ

A2Aの現状は、かなり明確である。

A2A = Agent間通信の標準化
MCP = AgentとToolの標準化

今後の実装トレンドは、以下になる。

Agent内部:
  LangGraph / Microsoft Agent Framework / CrewAI
  + MCP Tool連携

Agent外部:
  A2A endpoint
  + Agent Card
  + Task lifecycle
  + Artifact
  + Streaming / Push notification
  + 認証・署名・監査

タービン設計システムのような工学設計では、A2Aは特に以下で効く。

- CFD Agentへの解析依頼
- 最適化AgentへのDOE実行依頼
- Knowledge Agentへの設計基準検索依頼
- Report Agentへの成果物生成依頼
- 社内外Agentとの役割分担

ただし、最初からA2Aを全面導入する必要はない。
まずは内部ワークフローとMCP Tool群を整備する。
その後、境界が明確で再利用価値の高いAgentからA2A Serverとして公開する。

これが、2026年時点で最も現実的なA2A導入戦略である。