社内にAIエージェントが増えてくると、次に突き当たるのが「エージェント同士をどうつなぐか」という問題です。経費精算、在庫照会、問い合わせ対応と、それぞれのエージェントは便利でも、ベンダーや開発基盤が違えば連携のたびに個別の接続処理を作ることになります。

こうした分断を解消するために生まれたのがA2Aです。この記事では、A2Aの基本的な考え方から仕組み、MCPとの違い、業務での活用イメージ、導入時の注意点までを解説します。

この記事を読むと理解できること

• A2Aの定義と、Googleが発表した背景

• A2Aが解決しようとしているAIエージェントのサイロ化の問題

• Agent Card、Task、Message、Artifactなど主要な構成要素の役割

• タスクの状態遷移と、人間の確認を挟む設計の考え方

• A2AとMCPの役割の違いと、両者を併用する構成

• A2Aを業務に取り入れたときの具体的な変化

• 導入時に押さえるべきセキュリティと進め方のポイント

A2Aとは何か、なぜ今注目されているのか

結論から言うと、A2Aは異なる開発元や基盤で作られたAIエージェント同士が、共通のルールで仕事を依頼し合うためのオープンなプロトコルです。正式名称はAgent2Agentで、エージェント間の「共通語」にあたります。

A2Aの定義と発表の経緯

A2Aは2025年4月にGoogleが発表し、発表時点で50社以上のテクノロジーパートナーが参加しました。その後、プロジェクトはLinux Foundationに寄贈され、特定企業に依存しない中立的な体制で仕様の策定が進められています。

公式サイトによると、技術運営委員会にはAWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNowの代表者が参加しています。クラウド大手と業務アプリケーションの主要ベンダーが同じテーブルについている点が、A2Aの大きな特徴です。

2026年4月のLinux Foundationの発表では、A2Aを支持する組織は150以上に広がったとされています。同じ発表の中で、最初の安定版となるバージョン1.0や、Google Cloud、Microsoft Azure、AWSの各基盤での対応にも触れられています。

A2Aが解決しようとしている課題

A2Aが求められる背景には、AIエージェントのサイロ化があります。営業支援ツールのエージェント、人事システムのエージェント、自社開発のエージェントが、それぞれ独自の方式で動いていると、横断的な業務を任せることができません。

連携のたびに個別のAPI接続を作り込む方式では、エージェントが増えるほど接続の組み合わせが膨らみます。A2Aは、相手のエージェントがどのベンダー製で中身がどうなっているかを知らなくても、決まった手順で依頼と結果の受け渡しができるようにすることを目指しています。

A2Aの5つの設計原則

多くの解説で共通して紹介されているのが、A2Aの5つの設計原則です。1つ目は、エージェントを単なるツールではなく自律的に考える主体として扱うことです。

2つ目はHTTPやJSON-RPCなど既存のWeb標準を使うこと、3つ目は企業利用を前提とした認証と認可を備えることです。4つ目は数時間から数日かかる長時間タスクに対応すること、5つ目はテキストだけでなく画像や音声、フォームなども扱えるモダリティ非依存であることです。

A2Aはどのような仕組みで動くのか

A2Aの仕組みは、相手を見つけるAgent Card、仕事の単位であるTask、やり取りの中身であるMessageとArtifactの組み合わせで理解できます。依頼する側をクライアントエージェント、引き受ける側をリモートエージェントと呼びます。

A2Aを構成する主要な要素

まず、それぞれの構成要素の役割を整理します。仕様上の細かな項目は版によって変わることがありますが、考え方の骨格は共通しています。

Agent Cardは、決められた場所にJSON形式で公開されます。クライアントエージェントはこれを読み、相手が自分の依頼に向いているか、どの方式で認証すべきかを判断します。

A2Aにおけるタスクの状態遷移

A2Aのタスクは、受け付け済み、処理中、入力待ち、完了、失敗、取り消しといった状態を持ちます。依頼側はタスクの状態を確認しながら、結果を待ったり追加の情報を渡したりします。

この中で業務設計上とくに重要なのが入力待ちの状態です。リモートエージェントが判断に迷ったときや、追加情報が必要なときにここで止まり、依頼側に問い返すことができます。

入力待ちの状態は、人間の承認を差し込むポイントとしても使えます。たとえば支払処理の直前で担当者の確認を求める、といった業務ルールをプロトコルの流れの中に自然に組み込めます。

A2Aの通信方式

A2Aの通信は、HTTPSの上でJSON-RPC 2.0を使う方式が基本です。処理に時間がかかるタスクでは、Server-Sent Eventsによるストリーミングで途中経過を受け取ったり、Webhookによるプッシュ通知で完了を知らせたりできます。

いずれも既存のWeb技術であるため、企業がすでに持っているAPIゲートウェイや認証基盤、ログ監視の仕組みを流用しやすい点がメリットです。新しい通信基盤を一から用意する必要がないことは、導入のハードルを下げる大きな要因になっています。

A2AとMCPは何が違うのか

A2AとMCPは競合する規格ではなく、役割の異なる補完関係にあります。MCPがエージェントとツールやデータをつなぐのに対し、A2Aはエージェントとエージェントをつなぎます。

縦の接続と横の接続

MCPはAnthropicが提唱したプロトコルで、AIエージェントがデータベースや社内文書、外部APIなどを道具として呼び出すための共通規格です。エージェントから見て下にある道具とつながるため、縦方向の接続と表現されることがあります。

一方のA2Aは、対等な立場のエージェント同士が仕事を依頼し合うための規格です。相手のエージェントの内部でどんなツールやモデルが使われているかは隠したまま、依頼と結果だけをやり取りします。

A2AとMCPを併用する構成

実際のシステムでは、A2AとMCPを組み合わせて使う構成が想定されています。たとえば受注管理エージェントがA2Aで在庫エージェントに確認を依頼し、在庫エージェントはMCPを通じて在庫データベースを参照する、という形です。

MCPを使った業務システム開発の具体的な進め方は、Claude APIとMCP連携で業務システムを開発する方法で詳しく解説しています。A2Aを検討する前に、まず個々のエージェントがMCPで必要な道具を使えているかを確認すると、全体の設計が整理しやすくなります。

A2Aを導入すると企業の業務はどう変わるのか

A2Aを導入すると、部門ごとに分かれていたエージェントを、1つの業務の流れとして連携させやすくなります。担当者が複数のシステムを行き来して転記していた作業を、エージェント間の依頼に置き換えられるのが最大の変化です。

A2Aによる部門横断の業務連携

たとえば出張申請では、申請受付、規程チェック、交通機関の手配、経費の事前計上といった工程が、それぞれ別のシステムに分かれていることが少なくありません。A2Aを使えば、受付エージェントが各工程のエージェントに順番に依頼し、結果を取りまとめて申請者に返すといった流れを組めます。

金融分野の不正検知や製造業の品質管理なども、よく挙げられる活用例です。取引監視、本人確認、通知といった役割を別々のエージェントに持たせ、異常を検知したときに連鎖的に処理を進める構成が考えられます。

A2Aで変わる人間の役割

エージェント同士が仕事を受け渡すようになると、人間の役割は作業者から確認者、判断者へと移っていきます。そのため、どの場面で人間に確認を求め、どの情報を見せれば適切に判断できるかという体験の設計が重要になります。

FAKEでは、業務システムのUI/UXを現場に入り込んで設計してきた立場から、この確認の場面こそが定着を左右すると考えています。エージェント時代の体験設計の考え方は、Agentic UXとは？AIエージェント時代の体験設計と進め方もあわせて参考にしてください。

A2Aが向いている業務と向いていない業務

A2Aは万能ではなく、向き不向きがあります。複数の部門やシステムにまたがり、途中で判断や問い返しが発生する業務は、A2Aの長所が生きやすい領域です。

反対に、1つのシステムの中で完結する定型処理であれば、A2Aを使わずに単体のエージェントやワークフローの自動化で十分な場合があります。導入の目的を「規格を使うこと」ではなく「分断された業務をつなぐこと」に置くと、判断を誤りにくくなります。

A2Aを導入する際の注意点と進め方は

A2Aを導入する際は、セキュリティと権限の設計、仕様の変化への追随、業務の切り分けの3点を先に考えておく必要があります。いきなり全社展開を目指すのではなく、範囲を絞った検証から始めるのが現実的です。

A2A導入時のセキュリティと権限設計

エージェント同士が自律的にやり取りするようになると、誰がどの権限で何を依頼したのかを追える仕組みが欠かせません。A2Aは企業向けの認証方式を前提としていますが、どのエージェントにどこまでの操作を許すかという権限設計は、利用する企業側で決める必要があります。

なりすましへの対策として、バージョン1.0ではAgent Cardに電子署名を付けて正当性を確認する仕組みも示されています。あわせて、タスクの履歴や成果物をログとして残し、後から検証できるようにしておくことが重要です。

A2Aの仕様の変化に備える

A2Aは発表から短期間で仕様が大きく進化してきました。初期の版で作った実装が、新しい版では書き換えを求められるケースも想定しておくべきです。

公式SDKや主要クラウドのマネージドサービスを活用すると、仕様変更への追随をある程度任せられます。自社で独自に実装する範囲を小さく保つことが、長期的な保守負担を抑えるポイントです。

A2A導入を小さく始める進め方

最初のステップは、社内にあるエージェントと業務の流れを棚卸しし、エージェント同士の連携で効果が出そうな業務を1つ選ぶことです。次に、その業務に関わるエージェントを2つか3つに絞り、A2Aで依頼と結果の受け渡しを検証します。

検証では、処理速度や精度だけでなく、入力待ちの場面で担当者が迷わず判断できたかも評価に含めると、本番運用に近い課題を早く洗い出せます。エージェント開発を外部に依頼する場合の観点は、AIエージェント開発会社の選び方が参考になります。

また、エージェントの権限や責任の範囲を社内ルールとして定めるには、AI活用全体の統制の考え方も欠かせません。全社的なルール作りについては、AIガバナンスとはの記事で整理しています。

まとめ

A2Aは、異なるベンダーや基盤で作られたAIエージェント同士が、共通のルールで仕事を依頼し合うためのオープンなプロトコルです。2025年4月にGoogleが発表し、現在はLinux Foundationのもとで多くの企業が参加して仕様が整備されています。

仕組みの中心は、相手を知るAgent Card、仕事の単位であるTask、やり取りの中身であるMessageとArtifactです。MCPがエージェントと道具をつなぐのに対し、A2Aはエージェント同士をつなぐもので、両者は併用を前提とした補完関係にあります。

導入にあたっては、権限とログの設計、仕様の変化への備え、そして人間がどこで判断するかという体験の設計が鍵になります。まずは部門をまたぐ業務を1つ選び、小さく検証するところから始めてみてください。

A2Aに関するよくある質問

A2Aは無料で使えますか

A2Aの仕様と公式SDKはオープンソースとして公開されており、仕様そのものの利用に料金はかかりません。ただし、エージェントを動かすクラウド基盤やAIモデルの利用料、開発や運用の費用は別途発生します。

A2Aを使うにはMCPも必要ですか

必須ではありません。A2Aはエージェント同士の連携、MCPはエージェントと道具の連携を担うため、目的が異なります。ただし、各エージェントが社内データや外部APIを使う場面ではMCPを併用する構成が一般的です。

A2Aは自社開発のエージェントでも使えますか

使えます。A2AはHTTPやJSON-RPCといった既存のWeb技術を土台にしているため、公式SDKなどを使えば自社開発のエージェントにも組み込めます。Agent Cardを公開し、決められた手順で依頼を受け付けられるようにすることが基本になります。

A2Aの導入は今から検討すべきですか

社内に複数のAIエージェントがあり、部門をまたいだ連携に課題を感じているなら、検討を始める価値は十分にあります。一方でエージェントが1つしかない段階では、まず単体の活用を定着させることを優先し、連携が必要になった時点でA2Aを検討する進め方でも遅くありません。