A2AとMCPの違いは？AIに調査や見積もりを任せる流れ

A2Aは、別々に作られたAIへ仕事を頼み、進み具合や結果を受け取るための共通ルールです。MCPは、AIから在庫表や料金計算などの道具を使うための共通ルール。例えば「仕入先に見積もりを頼む」連携にA2A、その見積もりを作るために「在庫を調べる」連携にMCPを使う構成が考えられます。[1]

通販店にとっての利点は、複数の業務システムをつなぐ際に、依頼や結果の渡し方をそろえられることです。ただし、相手のAI、在庫を調べる機能、利用権限は別に必要です。A2Aという商品登録サービスへ申し込む話ではありません。

この記事では、通販店がマグカップ100個の見積もりを取る例で、準備から結果の確認までを追います。契約済みの仕入先から接続先と商品カタログを受け取り、双方が同じ商品番号を使っている前提です。金額・数量・識別番号は説明用です。2026年9月10日に確認した公式仕様の「Latest Released Version 1.0.0」を参照し、HTTPでやり取りする方式の項目を使います。[2]

A2AとMCPは、つなぐ相手が違う

担当者がAIへ「仕入れの候補を調べて」と頼むと、AIは複数の作業を進めます。どの道具を使うかを判断して在庫を調べることもあれば、別の会社のAIへ見積もりを頼むこともあります。

したいこと	この例で使う仕組み	返してもらうもの
在庫システムから数量を調べる	MCPで公開された在庫確認の道具	在庫数など、その道具の結果
仕入先のAIへ見積もりを頼む	A2A	追加の質問、処理中の状態、見積もりの結果
人が購入を決めて発注する	別途用意する注文処理	注文の受付結果

A2Aの公式説明も、AI同士の協力と、AIから道具を使う連携を補い合うものとして説明しています。二つを必ずセットで入れるという要件ではありません。在庫を一度調べるだけなら、独立した相手のAIへ仕事を渡す仕組みまで必要とは限りません。[1]

複数の仕入先に依頼し、返事を待ち、不足条件に答えるような仕事では、進捗を持つA2Aの仕組みが検討材料になります。それでも、見積もりが正しいか、依頼先を信用できるかは別に判断します。

図の見積もり用AIと在庫確認の道具は、説明のために置いた構成です。A2AやMCPが、どの会社の在庫でも自由に読めるようにするわけではありません。

1. 依頼先と、使える仕事を確認する

最初に、依頼するAIの接続先が必要です。相手はAgent CardというJSON形式の案内を用意できます。これは、そのAIの名前、できる仕事、接続先、対応する通信方法、認証条件などを機械が読める形でまとめたものです。[2]

公式仕様には、/.well-known/agent-card.jsonを取得する例があります。例えば、仕入先がこの経路で案内している場合、依頼側はその案内を読み、見積もりの仕事を扱っているかを確認します。このファイルを置けば、すべてのAIに自動登録されるという意味ではありません。[2]

カードの接続先だけを抜き出すと、次のように読めます。URLは架空です。名前・機能一覧・認証条件などを省いた部分例であり、Agent Card全体としては使えません。

{
  "supportedInterfaces": [
    {
      "url": "https://supplier.example/a2a",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ]
}

supportedInterfacesは対応する接続方法の一覧です。依頼側は双方が使える方法と、そのURLを選びます。複数の方法を案内できるため、別の記事に出てきたURLや通信方法をそのまま当てはめず、相手のカードを確認します。[2]

認証が必要なら、案内された方法で接続用の資格情報も準備します。カードの公開と、実際の利用許可は別です。例では、契約済みの仕入先に接続でき、見積もりを依頼する権限があるところから始めます。

2. 同じ商品と数量を指定して依頼する

店の担当者は、マグカップ100個を希望しています。商品を区別する呼び名をmug-001、依頼側で付けるメッセージ番号をmsg-quote-001とします。商品番号とメッセージ番号は役割が違うため、混ぜません。

依頼側のAIは、A2AのSend Messageという操作で相手に要件を送ります。HTTP方式の公式例ではPOST /message:sendを使い、本文のmessageに依頼内容を入れます。接続URLの組み立てと認証は、実際に相手が案内する設定に従います。[2]

{
  "message": {
    "role": "ROLE_USER",
    "messageId": "msg-quote-001",
    "parts": [
      {"text": "mug-001を100個、東京都内へ届ける場合の税込総額と納期を見積もってください。発注はしません。"}
    ]
  },
  "configuration": {"returnImmediately": true}
}

これは、公式のメッセージ形式に説明用の依頼を入れた例です。partsには伝える内容を入れます。ここでは文章を使っていますが、仕様はファイルや構造を持ったデータも扱います。returnImmediately: trueは、処理中でも仕事の記録を先に返してもらう指定です。完了まで待つ指定とは区別します。[2]

「発注はしません」と書いたのは、今回の仕事の範囲を明確にするためです。実際のシステムでは、文章による指示だけでなく、利用できる操作や権限でも発注を制限する必要があります。依頼を送る資格があることと、購入を許可されたことは同じではありません。

3. 相手のAIが、道具を使って見積もりを作る

依頼を受けた仕入先のAIは、在庫と価格を調べます。この内部処理にMCPを使うなら、例えば在庫確認の道具へ商品番号を渡し、数量を受け取る構成になります。[1]

次は、仕入先が独自に用意する道具の説明例です。名前や項目はMCPが定めた在庫APIではありません。

道具へ渡す入力の例	道具から返す結果の例	AIが次に判断すること
商品番号：mug-001	在庫：120個	希望の100個を用意できるか
商品番号：mug-001、数量：100個	商品代：50,000円	数量に対応する価格か
配送先：東京都内	配送料：2,000円	見積もりに送料を含めたか

MCPの通信にすると、道具の呼び出しはtools/call、道具名はparams.name、入力はparams.argumentsに入ります。次はMCPの2025-11-25版の形式に沿った本文例です。MCPへの接続と初期化、道具の一覧取得を済ませた前提で、見積もり用AIから仕入先の道具へ送ります。[4]

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"check_stock","arguments":{"product_id":"mug-001"}}}

tools/callなどはMCPの項目です。一方、check_stockとproduct_idは仕入先が定義する名前で、MCP共通の商品APIではありません。道具側が次のように返したとします。[4]

{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"mug-001の在庫は120個です"}],"isError":false}}

依頼と返答のidが同じなので、どの照会の結果かを対応付けられます。ここでは100個を用意できますが、150個の依頼なら在庫が足りません。数量不足を返すか、分納を提案するかは仕入先の業務判断であり、共通ルールが自動的に決めるわけではありません。

ここでは、説明用の条件として商品代と送料がともに税込で、追加費用がないものとします。その場合の合計は52,000円です。実際には税や割引、納期の条件を、自社の業務ルールに合わせて計算します。

A2Aは相手のAIの内部にある在庫表や判断の過程をすべて共有させるものではありません。依頼側は、合意した仕事と返された結果を使って連携します。だからこそ、結果に必要な数量・送料・納期を依頼時に明確にしておくことが役立ちます。[1][2]

4. 返事待ちと完了を、仕事の番号で区別する

すぐ終わらない仕事では、相手はTaskという処理の記録を返せます。新しいTaskの番号は受け付けた側が発行します。依頼側が最初に付けたmessageIdとは別の番号です。[2]

処理中に返すSend Messageの応答の抜粋は、例えば次の形です。相手から受け取ったtask.idが、以降に追跡する番号になります。[2]

{"task":{"id":"task-quote-001","contextId":"context-quote-001","status":{"state":"TASK_STATE_WORKING"}}}

例えばtask-quote-001という番号が返った後は、その仕事の状態を追います。公式仕様には、処理中、追加の入力が必要、完了、失敗などの状態があります。単に通信が成功しただけで「見積もり完成」とは判断しません。[2]

追加条件が必要になった場合は、同じTaskを指定して回答を続けます。例えば、配送地域だけでは納期が分からず、希望日を聞かれる場合です。回答メッセージのtaskIdをtask-quote-001、contextIdをcontext-quote-001とし、新しいmessageIdを付けてSend Messageを送ります。parts[].textには希望日を入れます。同じ仕事の番号を使うことで、最初の100個の依頼に対する回答だと対応付けられます。[2]

進捗はGet Taskで問い合わせる方法のほか、連続して更新を受ける方法や通知を受ける方法もあります。後者には相手の対応状況や通知先の準備が必要です。どの相手でもすべての通知方法を使えるとは限りません。[2]

この例なら、依頼した100個の見積もりが返ったかを、Taskの番号と結果の内容で確認します。処理が失敗した場合は、失敗理由を確認してから対応します。結果を確認せず同じ仕事を何度も頼む運用は避けたいところです。

5. 結果を受け取り、発注は別に判断する

ここでは、依頼側がHTTP方式の GET /tasks/task-quote-001 でGet Taskを呼び、状態を確認します。URLの末尾が取得対象のidです。取得結果として返るTaskには、状態とartifactsを入れられます。artifactsは作業で出来上がったものを表し、この例では見積もりの文章です。[2]

次は、Get Taskが返すTaskの説明例です。Send Message応答のような外側のtask項目は付けません。金額は前の段階と同じで、相手のシステムから実際に取得した見積もりではありません。

{
  "id": "task-quote-001",
  "contextId": "context-quote-001",
  "status": {
    "state": "TASK_STATE_COMPLETED"
  },
  "artifacts": [
    {
      "artifactId": "quote-result-001",
      "name": "mug-001の見積もり",
      "parts": [
        {
          "text": "mug-001を100個。税込商品代50,000円、税込送料2,000円、合計52,000円。納期は発注後5営業日。発注は未実施です。"
        }
      ]
    }
  ]
}

担当者は、商品・数量・税込総額・納期が依頼と合うかを確認できます。TASK_STATE_COMPLETEDが表すのは、ここでは見積もり作成という仕事の完了です。商品を確保した、支払いが済んだ、発送されたという意味ではありません。見積もりの仕事が完了しても、数量不足や別の納期を回答する場合があるため、中身まで読みます。[2]

発注へ進むなら、購入内容の承認と、注文を受け付ける処理を別に用意します。A2Aは依頼と結果のやり取りをそろえますが、何をもって発注成立とするかまで、この見積もり例だけで決まりません。

自社では、どこに使うと役立つか

いま担当者が複数のシステムを往復している仕事を一つ選ぶと、使い道を考えやすくなります。例えば、仕入先への見積もり依頼、社内の請求担当への照会、予約サービスへの条件確認です。

在庫表から決まった項目を読むだけなら、まず必要なのはデータを読む道具です。相手のAIに調査を任せ、追加質問に答え、完了を待つ仕事なら、A2Aが扱う依頼・進捗・結果の仕組みが関係します。[1]

A2Aの公式発表では、2026年8月27日にAgentic AI Foundationへの参加を案内しています。これは2026年9月10日の新着ニュースではなく、運営の背景として参照しています。[3]

本記事のデータは、1.0.0と表示された公式ページの形式を読むための例です。実際の接続・認証・発注を試した結果ではありません。採用するSDKと相手の対応版をそろえ、まず「同じ依頼に対して、途中の状態と必要な結果を受け取れるか」を試すところが導入判断の出発点になります。