専門分野の異なるAIエージェントが連携すれば、人が作業を細かく指示しなくても、複雑な業務を進められます。A2Aは、こうした連携を支える規格として注目されています。一方で、誤った判断が次の処理へ引き継がれる危険や、AIが実行した操作に誰が責任を負うのかという懸念も生まれました。A2Aは、異なるエージェント同士が機能を確認し、依頼や成果物をやり取りする手順を定めています。A2Aを実務で使うには、規格で決められている範囲と、導入企業が決める範囲を区別する必要があります。

【シリーズ「AIトランスフォーメーション（AX）」】
AIトランスフォーメーションを成功へ導くステップとは？
Difyで始める最速AX！AIのビジネス活用の成否は「ナレッジ管理」で決まる
【2026年最新版】業務変革の要！AIエージェント導入ガイド
「神エクセル」がAXを阻害する？AIフレンドリーなExcel運用・管理法
オフライン駆動可能！ローカルLLM＋RPAでパーソナルなAIエージェント
データアナリティクス最前線！AI時代のデータ分析は何が変わったのか
AIエージェントはどこまで届く？MCPが広げる可能性とリスク
GeminiはAIモデル競争から脱落したのか？Googleの勝ち筋とは
「Claude Fable 5」規制騒動から考えるモデルルーティング戦略の必要性
ダッシュボードで「見える化」する時代は終わったのか

期待と不安が先行するA2A

A2Aを導入するだけで業務を自動化できるかのような期待も広がっています。しかし、A2Aだけで業務を自動化できるわけではありません。AIの判断や成果物の品質は、規格の対象外です。

AIエージェントの連携で何が変わるのか

これまでの生成AIは、利用者の質問や指示に対して、文章や画像、プログラムなどを生成する使い方が中心でした。利用者は作業を細かく分け、必要な情報を入力し、出力を確認しながら次の指示を出します。AIの性能が上がっても、作業の順序を決め、結果を確認しながら次の指示を出すのは利用者でした。

AIエージェントは、こうした作業の一部を利用者に代わって進めます。利用者が目標を示すと、必要な作業を洗い出し、外部のツールやデータを使いながら複数の手順を実行します。営業、調達、会計、顧客対応などを担うエージェントが連携すれば、1つのエージェントだけでは完結しない業務も処理できます。

例えば、営業支援エージェントが商談内容をもとに見積書を作成し、在庫管理エージェントへ納期を問い合わせ、契約確認エージェントへ取引条件の確認を依頼します。必要な情報がそろえば、顧客への回答案まで作成できます。従来は、担当者が各システムを開き、同じ情報を何度も入力していました。複数のエージェントが連携すれば、担当者が各システムから情報を集め、別のシステムへ入力する手間を減らせます。

Googleは2025年4月の発表で、異なる企業や開発基盤のエージェントを連携させれば、自律性と生産性が高まり、長期的な費用も抑えられると説明しました。発表時点で、開発参加企業と支持企業は計50社を超えており、その後も参加組織は増えています。参加企業が増えたことで、A2Aを導入すれば企業の業務を一気に自動化できるという期待も高まりました。

しかし、複数のエージェントを接続するだけで生産性が大きく向上するわけではありません。業務を効率化するには、各エージェントが依頼内容を正しく理解し、適切な相手を選んだうえで、受け取った結果を検証する必要があります。A2Aは、エージェント同士が依頼や結果をやり取りするための手順を定めているにすぎません。

複数のエージェントを連携させるリスク

複数のAIが人の確認を経ずに処理を続けるのではないかという不安も広がりました。あるエージェントが顧客名を取り違えれば、その誤った情報が在庫確認や契約書の作成にも使われてしまいます。誤回答が画面に表示されるだけでなく、別のシステムへの登録や外部への送信まで自動化されていれば、誤りによる被害も広がります。

外部から受け取った情報が、新たな攻撃経路になるおそれもあります。NISTは、Webページや文書に不正な指示を埋め込み、それを読んだAIエージェントに意図しない操作をさせる「エージェント・ハイジャッキング」を問題視しています。顧客対応エージェントが不正な指示を読み取り、その結果を別のエージェントへ渡せば、攻撃の影響が複数の処理に広がる可能性があります。

OWASPも、複数の自律的なエージェントが共通の目標に向けて連携すると、攻撃経路が増え、構成も複雑になると指摘しています。問題が起きたときに、どのエージェントが誤ったのか、最初に受け取った情報は何か、どの権限で操作したのかを追跡できなければ、原因の特定も難しくなります。

被害の大きさは、AIにどこまで権限を与え、どの処理まで自動化するかによって変わります。独自のAPIでエージェントを接続しても同じ危険は残ります。接続方法が統一されていなければ、認証や操作記録の仕組みも個別に用意しなければなりません。

A2Aを使ったシステムの安全性を検討する際は、通信、AIの判断、操作権限を分けて考える必要があります。エージェント同士が正常に通信できても、判断まで正しいとは限りません。判断が正しくても、必要以上の権限を与えれば、事故が起きた際の被害は大きくなります。権限を制限し、操作を記録して重要な処理に人の承認を挟めば、自動化を進めても事故の被害を抑えられます。

A2Aは何を定めているのか

A2Aは、Agent2Agent Protocolの略です。異なる企業や開発基盤で作られたAIエージェントが、互いの内部実装を公開せずに連携できるようにする共通規格です。Googleが開発を始めた後、Linux Foundationへ移管されました。

A2Aには、依頼先の機能を確認し、仕事を依頼してから成果物を受け取るまでの手順が定められています。作業中の進捗確認や追加情報の送信にも対応しています。各エージェントが使うAIモデルやツール、処理の手順を、依頼元へ公開する必要はありません。企業は内部の仕組みや業務知識を守りながら、エージェントの機能を外部へ提供できます。

共通規格がなければ、航空券予約エージェントと宿泊予約エージェント、会計エージェントと購買エージェントなど、組み合わせごとに接続機能を開発しなければなりません。接続先が増えるほど開発対象も増え、仕様が変わるたびに修正が必要です。A2Aに対応したエージェント同士なら、共通の形式で依頼や結果を交換できるため、接続にかかる負担を減らせます。

ただし、A2Aは各エージェントの推論方法、学習データ、業務知識、回答の正確性まで統一する規格ではありません。A2Aに対応していても、共通の形式で通信できるだけで、仕事の品質まで保証されるわけではありません。A2Aに対応したからといって、エージェント自体の性能が高まるわけではありません。

A2Aで依頼と成果物をやり取りする仕組み

A2Aは、一度の応答で終わる処理だけでなく、数時間から数日に及ぶ仕事にも対応しています。海外出張を手配する場合、依頼先を探し、条件を調整しながら、最終的な旅程を受け取ります。

Agent Cardで依頼先の機能を確認する

利用者が「来月のニューヨーク出張を手配してほしい」と社内のAIエージェントへ依頼したとします。社内のAIエージェントは、必要な作業をほかのエージェントへ依頼します。A2Aでは、依頼する側をクライアントエージェント、航空券や宿泊先を調べて結果を返す側をリモートエージェントと呼びます。

依頼元はまずAgent Cardを参照し、依頼先が必要な機能を備えているか確認します。Agent Cardは、リモートエージェントが公開するJSON形式の文書です。エージェントの名前、提供元、接続先、通信方法、認証方式、得意分野、入出力できるデータなどが記載されています。

出張手配を担当するクライアントエージェントは、Agent Cardを参照し、航空券を検索できるエージェント、会社の出張規定に沿って宿泊先を選べるエージェント、空港からホテルまでの移動方法を調べられるエージェントを探します。機能と認証方法を確認したうえで、依頼先が受け付ける形式に合わせて情報を送ります。

Agent Cardは、所定のURL、承認済みのエージェントを集めた企業内カタログ、設定ファイルなどから取得できます。社内だけで使うのか、外部の多数のエージェントと接続するのかによって、Agent Cardの管理方法は変わります。

現行のA2A仕様は、Agent Cardの書式と公開方法を定めています。一方、世界中のエージェントを一括検索するための登録簿やAPIは、A2Aの仕様に含まれていません。企業が業務で使う場合は、利用を認めたエージェントだけを登録し、提供元、用途、権限、契約条件を管理する仕組みが必要です。

Agent Cardに記載される機能は、提供元の自己申告です。航空券を検索できると記載されていても、検索結果の正確さや情報の更新頻度、障害の発生率までは分かりません。Agent Cardの記載だけで依頼先を決めず、事前の試験や運用実績から、精度や安定性も確認する必要があります。

Taskで長時間の仕事を管理する

依頼先が決まると、クライアントエージェントはA2AのMessageを送ります。Messageは、利用者からの依頼、エージェントからの質問、追加条件、進捗報告などに使います。文字だけでなく、ファイルや構造化されたデータも送信できます。

航空券を探すには、出発地、日程、予算などの情報が必要です。日程が「来月」としか指定されていなければ、検索エージェントが具体的な日付を尋ね、依頼元が利用者の回答を返します。条件が不足していても、対話を続けながら必要な情報を補えます。

処理の進み具合はTaskで管理します。Taskには、受付済み、作業中、完了、失敗、中止、追加情報待ちなど、依頼ごとの進捗が記録されます。数時間かかる調査でも、依頼元は現在の状況を確認できます。

処理結果はArtifactとして返されます。出張手配なら、航空券の候補一覧、宿泊先の比較結果、旅程表などが該当します。Messageには会話や進捗、Artifactには成果物を記録します。依頼元はArtifactだけを保存し、別のエージェントへ渡すこともできます。

短時間で終わる処理なら、依頼元は接続を維持したまま結果を待てます。長時間かかる場合は、定期的な問い合わせ、ストリーミング、Webhookによる通知から、結果の受け取り方を選べます。長時間の処理では、依頼元が通信を維持していなくても、依頼先は作業を続けられます。

A2A v1.0は、JSON-RPC、HTTP＋JSON、gRPCという3つの通信方式に対応しています。いずれも企業のWebシステムで広く使われてきた技術です。既存の負荷分散機能やAPIゲートウェイ、通信監視の仕組みを利用できるため、A2A専用のネットワークを新たに構築する必要はありません。

Message、Task、Artifactを使い分ければ、エージェント同士で条件を確認しながら長時間の処理を進め、進捗と成果物を共有できます。

MCPはツール、A2Aはエージェントをつなぐ

A2AはMCPとよく比較されますが、両者は接続する相手が異なります。

MCPは、AIエージェントからデータベース、検索機能、ファイル、業務システムのAPIなどを呼び出す手順を共通化します。例えば、航空券検索エージェントが予約システムへ条件を送り、該当する便の一覧を受け取る際に使えます。入力と出力があらかじめ決まっている機能を、ツールとして呼び出す用途に適しています。

A2Aは、計画や判断を担うAIエージェント同士を接続します。航空券検索エージェントは、条件が足りなければ依頼元へ質問し、複数の候補を比較します。会社の規定に合う便がなければ、条件を変更して探し直す場合もあります。条件の確認や再検索など、複数回のやり取りが必要になるため、1回のツール呼び出しだけでは処理を完結できません。

出張手配の依頼を取りまとめるエージェントは、A2Aを使って航空券検索エージェントと連携します。航空券検索エージェントが予約データベースや社内の出張規定を参照する際には、MCPを利用できます。依頼元は、内部でどのツールが使われたかを意識せず、検索結果とその根拠だけを受け取れます。

外部のエージェントとのやり取りにはA2Aを、社内のデータやツールの利用にはMCPを使えば、接続先に応じて権限を分けられます。外部のエージェントにはデータベースを直接操作させず、自社のエージェントを経由させる方法もあります。この方法なら、社内の権限設定に従って処理できます。

MCPとA2Aは競合する規格ではありません。A2Aはエージェント同士の通信に、MCPはエージェントとツールの接続に使います。 両者を組み合わせれば、外部のエージェントと連携しながら、社内システムへのアクセスは自社で管理できます。

A2Aの現状と導入後の課題

発表から約1年でA2Aの最初の安定版が公開され、大手クラウドにも組み込まれました。しかし、通信方法が統一されても、エージェントの選定、成果の検証、権限、費用といった運用上の課題は残ります。

異なる製品のエージェントを組み合わせやすくなる

Googleは2025年4月にA2Aを発表し、同年6月には仕様、SDK、開発ツールをLinux Foundationへ移管しました。AWS、Cisco、Microsoftなどもプロジェクトの設立に参加し、共同で仕様を管理しています。

2026年には、最初の安定版となるv1.0が公開されました。v1.0では、3つの通信方式に加え、複数の企業や利用者を扱うマルチテナントへの対応、Agent Cardの署名、異なるバージョン間の調整機能が追加されました。

Linux Foundationによると、2026年4月時点で150以上の組織がA2Aを支持し、Google、Microsoft、AWSのクラウドサービスにも組み込まれています。公式SDKはPython、JavaScript、Java、Go、.NET向けに提供されています。物流、金融、保険、IT運用では本番利用も始まっています。

ただし、150以上という数字は支持組織の数であり、すべての組織が本番運用しているわけではありません。エージェントの登録簿や相互運用試験に加え、セキュリティ対策や導入手順も引き続き整備する必要があります。

A2Aが普及すれば、顧客対応には自社のエージェント、請求処理には会計サービスのエージェントを使うなど、業務に合った製品を組み合わせやすくなります。提供元を変更する際も、業務全体を作り直す負担を抑えられます。

エージェントの提供企業もA2Aに対応すれば、取引先ごとに独自の接続機能を開発する負担を減らせます。

通信できても仕事の質はそろわない

共通規格に対応していても、各エージェントの業務知識や出力品質は異なります。Agent Cardに「契約書を確認できる」と記載されていても、業界固有の慣行や自社の承認基準まで理解しているとは限りません。記載された機能だけで依頼先を選ぶと、実務では使えない成果物が返る可能性があります。

導入前に試験を行い、Agent Cardに記載された機能が実際に使えるか確かめます。処理時間、失敗率、費用に加え、判断の根拠を説明できるか、機密情報を適切に扱えるかも確認します。運用後は業務ごとの成功率を測り、失敗が続いた場合に別のエージェントへ切り替えられるようにします。

複数のエージェントを連携させる場合は、最終結果だけでなく、各エージェントが途中で出した回答も確認します。誤った前提が後続のエージェントへ渡ると、最終結果だけを見ても原因を特定できません。Message、Task、Artifact、外部システムで実行した操作を関連づけて記録し、どの段階で誤りが生じたのかを追跡できるようにします。

公開情報から候補を探す作業はAIに任せても、契約、送金、顧客への正式回答は担当者が承認してから実行します。処理を途中で止めたり、やり直したりできる仕組みも必要です。さらに、問題が起きる前の状態へ戻せれば、事故による被害を抑えられます。

AI駆動開発では、要件整理、実装、テスト、レビューを別々のエージェントに任せ、A2Aで連携させる方法も考えられます。例えば、実装を担当するエージェントが作ったプログラムを、テストを担当するエージェントへ送ります。問題が見つかれば、テスト結果とプログラムを修正担当のエージェントへ送り返します。こうした手順を統一すれば、異なる開発ツール間でも作業を引き継げます。

ただし、役割を細かく分ければ開発が必ず速くなるわけではありません。METRは2025年、16人の経験豊富な開発者を対象に実験を行いました。使い慣れた大規模OSSの実務課題に当時のAIツールを使って取り組んだところ、作業時間は19％増えました。2026年の追試では、AIを使わない条件で作業する開発者が減ったため、現在の効果を正確に測れないと報告されています。

A2Aでエージェント間の連携手順をそろえても、要件が曖昧だったり、テストが不十分だったりすれば、開発は速くなりません。AIが作った成果物を正しく評価できる担当者も必要です。

品質と安全性は導入する企業が管理する

A2Aは、APIキー、OAuth 2.0、OpenID Connect、相互TLS認証などに対応しています。Agent Cardには必要な認証方式を記載し、通信にはHTTPSを使用します。

接続先を認証した後も、許可する操作は別に決めなければなりません。誰にどのデータの閲覧や操作を許可するかは、導入企業が決めます。購買エージェントなら、商品検索、見積もり、発注などの操作ごとに権限を分け、金額に応じて担当者の承認を求めます。

Agent Cardの署名を検証すれば、改ざんの有無と発行元を確認できます。ただし、署名が正しくても、エージェントの判断や成果物まで保証されるわけではありません。Agent Cardの発行元を信頼できるか、どの機能の利用を認めるか、処理結果に問題がないかを個別に確認しなければなりません。

機密情報は依頼に必要な範囲だけを渡し、保存期間と削除方法を決めます。外部企業のエージェントを使う場合は、データの保管場所、再利用の有無、障害や情報漏えいが起きた際の責任も契約で確認します。情報が複数のエージェントへ渡る場合は、誰がどの情報をどこへ送ったのかを記録します。

エージェント同士のやり取りが増えるほど、AIモデルの利用料に加え、通信、監視、データ保存、処理のやり直しにかかる費用も増えます。担当者の作業時間が減っても、確認や修正が増えれば総費用は下がりません。成功率、修正時間、再実行回数を測り、外部サービスの利用料を含めて費用を計算する必要があります。

A2Aによって統一されるのは、エージェント同士の通信手順に限られます。どの業務をAIへ任せ、その結果に誰が責任を負うのかは、導入企業が決めなければなりません。 複数のエージェントを継続的に利用するには、操作権限を制限し、承認が必要な処理や異常時の停止条件を決め、操作内容を記録する必要があります。

まとめ

A2Aが普及すれば、専門分野の異なるAIエージェントが企業や製品の枠を越えて連携し、人がシステムごとに情報を入力し直さなくても業務を進められるようになります。接続方式が統一されれば、接続先ごとの個別開発を減らし、目的に合ったエージェントを組み合わせやすくなります。

ただし、A2Aが定めているのは、依頼や成果物をやり取りする手順にすぎません。判断の正確さや成果物の品質まで保証する規格ではありません。依頼先を選び、アクセス権限や処理状況、費用を管理するのは導入企業です。共通規格で通信できても、そのエージェントへ安心して業務を任せられるとは限りません。

導入時には、AIへ任せる業務と権限の範囲を決めます。あわせて、責任者の承認を求める条件、異常時に処理を止める条件、記録する情報、効果を測る指標も決めます。

A2Aを導入しただけで生産性が上がるわけではありません。A2Aを業務に生かすには、各エージェントに任せる役割、結果の確認方法、問題が起きたときの責任者をあらかじめ決めておく必要があります。

参考文献

Announcing the Agent2Agent Protocol (A2A)

Google Cloud donates A2A to Linux Foundation

What is A2A?