Google A2AがAAIF参加AIエージェント標準化は次の段階へ

AIエージェントを1つの業務で使う段階から、複数のエージェントを連携させる段階へ進む企業が増えています。そこで問われるのが、製品ごとに異なる接続方法を使い続けるのかという判断です。

この記事の対象読者

A2AやAIエージェントの標準化を、自社の接続設計や導入判断に結び付けたい方が対象です。

• 複数のAIエージェントを連携したい企業
• ベンダーロックインを避けたい企業
• 業務システムとAIを接続したい組織
• AI基盤の将来性を見極めたい企業
• マルチエージェントの統制を考える企業
• 特定業務に特化したAIエージェントを導入したい企業
• 日常の業務タスクやフローにAIエージェントを活用したい企業

A2AがAAIFに加わった日付と主体

報道の概要

Forkast Newsは、GoogleのAIエージェント間通信プロトコルA2AがAAIFへ加わったと報じています。日付は2026年8月20日。Agentic AI Foundation（AAIF）は、Linux Foundation系の標準化に関わる基盤です。

同記事によると、Anthropicなどが関わる標準化の枠組みとA2Aが同じ基盤に入ります。エージェント経済を支えるプロトコル層の統合が進む動きと伝えられているのが、今回の報道の骨子でしょう。

A2Aの参加で、異なるベンダーのエージェントが相手を発見し依頼を送る仕組みが共通仕様として議論しやすくなります。個別の製品連携に頼らず、処理結果の受け渡しを標準的に扱える枠組みが生まれつつある段階です。

• 誰が：Googleが開発したA2A
• いつ：2026年8月20日
• どこへ：Linux Foundation系のAgentic AI Foundation
• 何が変わるか：エージェント間通信を共通仕様として検討しやすくなる

今すぐ問い合わせる

MCPとA2Aの役割分担

それぞれの接続先と用途

MCPはModel Context Protocolの略称です。AIエージェントやLLMが外部のツール、データ、業務機能へ接続する際の境界を扱います。

たとえば、営業エージェントが顧客管理システムの情報を参照する接続はMCPの領域として整理しやすいでしょう。営業エージェントが見積エージェントへ作成を依頼する流れは、A2Aの領域として考えられます。

実際の業務では、MCPとA2Aをどちらか一方だけ選ぶとは限りません。エージェント間の連携と、業務システムへの接続を分けて設計すると、障害や権限の所在を確認しやすくなります。

交換性を残すAIエージェント設計

接続先を変えても業務ルールを作り直さない構成

海外では、A2Aのようなプロトコルを含むAIエージェントの標準化が議論されています。私たちが見てきた範囲では、現場で先に問題になりやすいのは通信規格そのものより、接続先を変えた際に業務ルールまで作り直す構成です。

そのため、エージェント本体と通信の境界を分けます。特定ベンダーの画面や独自形式を業務フローの中心に置かず、依頼、結果、エラー、監査情報の形式を自社側で定義しておく考え方です。

• 通信境界：エージェントの発見、依頼、応答、失敗時の扱い
• データ境界：入力項目、出力項目、形式、保持期間
• 権限境界：誰の依頼で、どの操作を許可するか
• 監査境界：判断材料、実行結果、承認者を何に残すか
• 交換境界：別ベンダーへ替えても維持する契約や業務ルール

標準化する範囲を広げすぎると、業務固有の判断まで共通仕様に押し込むことになります。まずは発見、依頼、結果受け渡しの流れを切り出し、業務固有のルールはエージェントの外側で管理する構成が候補でしょう。

認証と責任分界の設計

識別と記録の設計

A2Aで接続できても、依頼元と実行元を識別できなければ業務上の責任は曖昧になりがちです。認証では、エージェント名だけでなく、依頼した利用者、呼び出し元システム、実行対象を記録できる形を検討します。

責任分界は、エージェントが出した結果と、人が承認した判断を分けて記録します。自動実行を許す処理と、人の確認を挟む処理も、業務ごとに線引きが必要です。

• 認証：どの利用者とエージェントが依頼したか
• 認可：どのデータ参照と操作を許可するか
• 検証：結果を誰がどの条件で確認するか
• 監査：依頼、判断材料、結果、承認をどこへ残すか
• 障害対応：誤処理や停止時に誰が止めて復旧するか

今すぐ無料相談する

導入時に先に決める境界

業務の流れを1つ選んで切り出す

A2AとMCPの使い分けを決める前に、対象業務の流れを1つ選びます。たとえば問い合わせ対応で、受付、検索、回答案作成、承認、送信を別の処理として並べましょう。

次に、交換したい情報と固定してよい情報を分けます。エージェントを替えても残す項目を先に決めると、通信方式の変更が業務全体へ波及しにくくなるでしょう。

• 最初に連携する業務を1つに限定する
• エージェント間の依頼と業務システムへの接続を分ける
• 認証情報と利用者の権限を別々に記録する
• 結果の検証者と自動実行の上限を決める
• ベンダー変更時も残すデータ形式と監査項目を定義する

この順番なら、標準化の対象と業務固有の判断を切り分けやすくなります。全社のマルチエージェント基盤を先に作るより、限定した業務で接続と監査の実効性を確かめる進め方です。

自社で詰まりやすい設計判断

自社だけで進める場合、A2AとMCPの境界を決めても、既存システムの権限体系やログ形式と合わないことがあります。業務ごとに異なる承認条件を、共通の通信仕様へ無理に合わせる場面も出てくるでしょう。

• 既存システムの利用者権限とエージェント権限が一致しない
• 結果の正しさを確認する担当と承認記録が決まっていない
• ベンダー固有の形式が業務フローやログに入り込んでいる

外部の支援を使う場合は、通信規格の選定だけでなく、現場の業務整理と現状診断を先に行えるかを確認します。BinxAI株式会社のみっちゃくんは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。

見積は一式ではなく、要件を整理したうえで詳細を示す形です。契約後に要件が動いても、決めた範囲の中で優先順位を入れ替えて進められます。企画、課題整理、要件整理から開発まで同じ担当が受け持ち、内製化と社内定着も支援します。

• 課題の整理と現状の診断
• 要件定義と設計
• 開発と本番環境への展開
• 運用の引き継ぎと内製化の支援
• 担当者向けの研修

無料相談で自社の接続境界を整理する

よくある質問

A2AとMCPの違いは？

MCPはエージェントと外部ツールやデータをつなぐ境界です。A2Aはエージェント同士が依頼や結果を交換する境界として整理できます。

A2AがAAIFに参加するとすぐ標準化されますか？

すぐに全製品の接続方法が統一されるとは限りません。Forkast Newsが報じたのは、A2Aと他の標準化の枠組みが同じ基盤に入る動きです。

ベンダーロックインを避けるには何を残しますか？

依頼、結果、エラー、監査情報の形式を自社側で定義します。業務ルールと承認条件を特定ベンダーの画面や独自形式だけに置かないことも確認しましょう。

認証では何を記録すればよいですか？

依頼した利用者、呼び出し元システム、実行したエージェント、対象データ、実行結果を追える形にします。エージェント名だけでは、業務上の責任を確認しにくいでしょう。

最初から複数のエージェントを導入すべきですか？

最初は1つの業務で、発見、依頼、結果受け渡し、承認までを確認します。標準化できる部分と業務固有の部分を分けてから、他の業務へ広げる進め方が現実的です。

GoogleのA2AがAAIFへ加わったことで、AIエージェントは単独の性能競争だけでなく相互運用性や認証、監査、責任分界を含めて設計する段階へ進みつつあります。まずは1つの業務で、MCPとA2Aの境界、交換するデータ、承認の線引きを書き出してください。