【2026年】エージェント同士をつなぐ規格｜MCPとの違いを整理

「AIをつなぐ規格はもう決まったので、対応と書いてある製品を選んでおけば当面は困らない」「うちはエージェントを社外に出す段階ではないから、この手の話はまだ先でいい」——AIの連携が議題に上がる会議で、同じ日に並んで出てくる二つの言い分です。前者は規格が一種類だと思っており、後者は連携する相手が社外だけだと思っています。どちらも実際とはずれています。つなぐための規格には向きの違う二種類があり、いま多くの会社が触れているのは、そのうち片方だけです。AIが道具や社内の仕組みに手を伸ばすための取り決めと、AI同士が仕事を頼み合うための取り決めは、決めている中身も、つなぐ前に確かめるべき点も別ものです。この記事では、2026年時点で二つの規格がどこまで来たのか、役割の違いをどう整理するのか、そして他社のエージェントと接続する話が来たときに何を確かめるのかまでを整理します。

この記事で扱うのは、道具の側ではなく相手の側

AIと社内システムをつなぐMCPそのものについては、規格が生まれた背景、つなぐまでの工程、道具ごとに触らせる深さの決め方、記録の残し方まで、当サイトの別の記事で一通り扱っています。本記事はそこを繰り返しません。MCPは既に知っているものとして扱い、その隣にあるもう一種類の規格、つまりエージェント同士をつなぐ側だけを扱います。二つを並べる場面では、MCPは比較の相手として出てくるだけで、使い方の説明には戻りません。

向きで分けると整理しやすくなります。一方は、AIが自分の手を伸ばす向きです。顧客の管理台帳、広告の管理画面、文書の保管場所、表計算。AIが自前では持っていない機能に届くための差込口をそろえた取り決めで、これがMCPにあたります。もう一方は、AIが横に声をかける向きです。別の場所で動いているAIに仕事を頼み、結果だけを受け取る。この横向きの取り決めがA2Aです。前者は手を増やす話、後者は話し相手を増やす話だと考えると、混ざらなくなります。

混同が起きるのは、どちらも「AIをつなぐ規格」として紹介されるからです。製品の対応表に両方の丸印が並んでいても、それだけでは何ができるようになったのかが読み取れません。違いは、つないだ先に人が作った道具があるのか、それとも自分で考えて動くものがあるのかです。道具は指示した通りにしか動きませんが、相手側のエージェントは自分で手順を決めて動きます。確かめるべき点が変わるのは、この一点からです。

2026年、エージェントをつなぐ規格はどこまで来たか

エージェント同士をつなぐ規格が最初に公開されたのは2025年4月9日で、このときは50社を超える企業が賛同する形で始まりました。約1年後の2026年3月に最初の正式版が出て、採用したと公表している組織は150を超えています。主要なクラウド基盤のいずれでも本番で動く状態になりました。ただし公表されている数には試験的な採用も含まれるため、150という数字は普及の到達点ではなく、様子見が終わりつつある目安として読むのが妥当です。

道具につなぐ側の規格は、もう少し早く広がっています。配布された数は累計で9,700万を超え、公開されている接続窓口は1万を上回りました。いずれの規格も当初は特定の企業が主導していましたが、2025年末から2026年にかけて中立的な開発者団体の管理下に移っています。一社の都合で仕様が変わる段階は過ぎたと見てよい状況です。

ただし落ち着いたわけではありません。2026年の後半には、複数の規格をまたぐ統一的な相互運用の仕様をまとめる動きが予定されています。いま特定の規格の細部に合わせて作り込むと、1年後に作り直しになる可能性があります。この時期に社内で進めるなら、細部の実装ではなく、後半で挙げる確認項目のほうを先に決めておくほうが無駄になりません。確認項目は仕様が変わっても残ります。

一覧で比べる：二つの規格は何が違うのか

先に押さえておきたいのは、二つが対立するものではないことです。片方が他方を置き換えるのではなく、両方を使う設計が2026年時点の推奨です。手が無ければ仕事はできず、相手がいなければ分担はできません。ただし検討の順番と、つなぐ前に確かめる点はまったく違います。

比べる点	道具につなぐ側（MCP）	エージェント同士をつなぐ側（A2A）
つなぐ相手	社内外の道具・データ・機能	別の場所で動いているエージェント
目的	AIができることを増やす	仕事の一部を他所に頼む
渡すもの	操作の指示と、その結果	依頼と、返ってくる成果物
相手の中身	何ができるかは定義書で分かる	中身は見えない。宣言された能力だけが手がかり
動き方	指示した通りに動く	相手が自分で手順を決める
主に効く場面	一つの部署の中で作業を早くする	部署や会社をまたいで受け渡す
先に確かめる点	触らせる範囲と、記録の残し方	相手の身元と権限と、責任の所在

表のうち実務に効くのは、下から三行です。道具は指示した通りにしか動かないので、間違いが起きたときの原因は指示か設定のどちらかに絞れます。相手側のエージェントは自分で手順を決めるため、同じ依頼を出しても毎回同じ経路をたどるとは限りません。原因を追う難しさが一段上がり、その分だけ記録の重みが増します。

費用のかかり方も違います。道具につなぐ側は、つないだ数だけ管理の手間が増える形です。相手側とつなぐ場合は、つないだ数ではなく、やり取りの回数と、止まったときの調整の手間が効いてきます。社外の相手と組むと、片方だけでは直せない不具合が出るためです。接続の数ではなく、やり取りの回数で費用と手間が伸びる点が、道具側との大きな違いです。

エージェント同士をつなぐ側が取り決めているもの

この規格が実際に決めているのは、大きく三つです。一つ目は、相手が何者で何ができるかを書いた名刺にあたる情報です。名前と提供者、受けられる仕事の一覧、依頼を出す先、対応している認証の方式、そして名刺そのものが本物であることを示す署名までが含まれます。中央の管理者を置かずに相手を見つけられるのは、この名刺を各自が公開する形にしているためです。

名刺にあたる情報に書かれるもの
・名前と提供者：誰が動かしているのか
・受けられる仕事の一覧：どんな依頼を出せるのか
・依頼を出す先：どこへ投げるのか
・対応している認証の方式：どうやって身元を示すか
・追加機能の有無：折り返しの通知や逐次の返答に対応するか
・署名：この名刺が本物であることを示す印

二つ目は依頼の単位です。一件の依頼はタスクとして扱われ、受付済み、作業中、入力待ち、承認待ち、完了、失敗、取り消し、拒否という八つの状態のどれかを持ちます。相手から追加の入力や承認を求められる状態が、はじめから正規の状態として用意されているのが特徴です。途中で止まるのは異常ではなく、想定された動きとして扱われます。

三つ目は、やり取りと成果物の分け方です。会話のためのやり取りと、結果を入れる成果物は別のものとして扱われ、結論は会話の本文ではなく成果物のほうに入ります。長くかかる仕事は、返事を待たずにいったん受け取り、終わったときに相手から折り返し連絡してもらう形も選べます。依頼して待つのではなく、依頼して別の作業に移る前提で設計されています。

中身を見せ合わない、という設計

この規格の設計思想で、企業にとって最も重要なのは相手の内部の状態や記憶や道具に触れずに仕事を任せられるという一点です。相手がどんな指示文で動いているか、どの道具を持っているか、どの基盤の上で動いているかは、原則として見えません。手がかりは名刺に書かれた能力の宣言と、やり取りされる依頼と成果物だけです。

見えないことは、まず利点として働きます。社外と組むときに、自社が作り込んだ手順や社内の接続先を相手に開示せずに済みます。相手側の作りが変わっても、宣言されている能力が同じであれば手直しは要りません。異なる会社、異なる言語、異なる作り方のもの同士がつながる前提は、ここから来ています。

代償もあります。品質を確かめる材料が、返ってきた成果物とやり取りの記録だけになることです。途中でどんな判断をしたのかを覗きに行けないので、後から原因を切り分けるには、依頼と結果の記録を自社側で残しておくしかありません。相手の中が見えない設計だからこそ、記録は相手任せにせず自社側で取ります。

自社は今どちらを検討すべきか

順番を間違えると、使われない仕組みだけが増えます。判断は、いま自社の業務が止まっている場所を見るところから始めます。止まっている場所によって、必要な規格が変わるためです。

この順番で見ると、多くの会社が今いる位置は一段目か二段目です。エージェント同士をつなぐ話が実際に必要になるのは、社外の相手と定期的に受け渡しが発生する業務からです。広告運用の外部委託、問い合わせ対応の外部窓口、調査や制作の外注が代表例になります。

逆に、社内の道具にすら届いていない段階で相手側の規格に手を出すと、つないだ先で何もできないエージェント同士が挨拶を交わすだけの状態になります。手が無いエージェントを二つ並べても、できる仕事は増えません。この見極めは、規格の知識ではなく自社の業務の見立てで決まります。

他社のエージェントとつなぐ話が来たら確かめる5項目

接続の提案は、たいてい技術の話として持ち込まれます。しかし判断に必要なのは技術の詳細ではありません。確かめる項目は五つに絞れます。

1. 身元：相手が名乗っている通りの相手かを、どうやって確かめるのか
2. 権限：誰の資格で動き、どこまで触れるのか。範囲は誰が変えられるのか
3. 記録：いつ、どちらの指示で、何をしたかを、後から追えるのか
4. 責任：間違いが起きたとき、一次の窓口はどちらで、直す費用は誰が持つのか
5. 止め方：途中で止める手段と、関係そのものを切る手順があるのか

この五つは、どれも技術の話に見えて、実際には契約と運用の話です。規格そのものが定めていない領域に集中しているためです。2026年に公開された規格の比較研究でも、責任の特定、権限の委譲、監査と透明性、停止と取り消し、利用の同意、紛争の解決、資源の配分という七つの統治上の要件について、主要な規格のいずれもが十分に表現できていないと指摘されています。

言い換えると、規格に対応していることはつながる保証ではあっても、安全に任せられる保証ではありません。この5項目は、規格が空けている穴を書面と運用で埋めるための一覧です。次の見出しから順に見ていきます。

確認1 相手の身元：名刺は誰でも書ける

名刺にあたる情報は、相手が自分で書いて公開します。規格の側は、その名刺が本物かどうかをどう検証するかまでは義務づけていません。能力を偽った名刺を置くこと自体は、技術的に妨げられていないということです。依頼を出す先が差し替えられていれば、依頼はそのまま別の場所へ届きます。

対策は進んでいます。2026年の改訂で、名刺に電子的な署名を付けてなりすましを防ぐ仕組みが入りました。ただし署名を実際に検証するかどうかは、つなぐ側の作り込み次第です。相手が署名に対応していても、自社側で確かめていなければ意味がありません。提案書に署名対応と書いてあることと、自社が検証していることは別の話です。

実務での確認は三つで足ります。相手の名刺の署名を検証しているか。依頼を出す先が変わったときに気づく仕組みがあるか。相手の担当者と、契約書上の窓口が一致しているか。三つ目は技術ではなく書面の話ですが、実際に事故が起きたときに最初に効きます。名乗りをそのまま信じる設計になっていないかを、つなぐ前に確かめます。

確認2 権限：誰の資格で動くのか

規格には、認証の方式を名刺に書く場所は用意されています。しかし誰にどこまで許すのかという認可の決め方そのものは定義されていません。実装する側に任されています。社内の道具につなぐ場合より危ういのは、この空白が社外との間に置かれるためです。

実務で起きやすいのは、資格の使い回しです。相手のエージェントが、こちらから預かった資格をそのまま別の外部サービスへの認証に使う。悪意がなくても、依頼を果たすために必要だと判断すれば起こります。預ける資格は、その依頼に必要な範囲だけに絞って発行し、期限を切るのが原則です。期限のない資格は、契約が終わっても生き続けます。

もう一つは、範囲がじわじわ広がることです。最初は読むだけだったものが、便利だからと下書きの作成に広がり、次に送信まで広がる。広がったこと自体は誰も記録していません。権限は増やした日と理由を書き残し、四半期に一度は元に戻せるかを見直します。範囲の書き方は機能名ではなく業務名にします。読み取り可、ではなく、先月分の配信結果の閲覧まで、と書くほうが後から判断できます。

確認3 記録：後から追えるようにする

規格には、監査のための記録をどう残すかという取り決めが含まれていません。何がどこまで残るかは、つないだ双方の作り方次第です。相手の中が見えない設計である以上、記録が無ければ、うまくいかなかった理由は永久に分かりません。ここは規格の対応可否ではなく、こちら側の運用で決まります。

残す項目は多くありません。依頼を出した日時、誰の指示か、どの範囲の権限で動いたか、返ってきた結果、そして状態がどう変わったか。特に入力待ちと承認待ちで止まった記録は、後から手順を直すときの材料になります。止まった回数が多い場所は、依頼の書式が足りていない場所だからです。

• 依頼と結果は、相手側の記録に頼らず自社側でも残す
• 記録には、その時点で許していた権限の範囲を併記する
• 相手から追加の入力や承認を求められた回数を数えておく
• やり取りに顧客名や取引条件が混ざる場合は、残す前に伏せる範囲を決める
• 保存の期間と、閲覧できる人を先に決める。決めないと誰も見に行かない

保存の期間と、誰が見られるかも先に決めます。記録は残しているが担当者しか開けない、という状態は、記録が無いのとほとんど変わりません。記録は、取ることではなく、事故の当日に人が開けることまで含めて設計します。

確認4 責任の所在：規格が定めていない部分

規格の比較研究が挙げた七つの統治要件のうち、実務で最初に問題になるのは責任の特定です。相手のエージェントが誤った結果を返し、それを自社のエージェントが受け取ってそのまま次の工程へ流した場合、どちらの責任なのかを規格は決めていません。決めているのは、つなぎ方と依頼のやり取りの形までです。

先に決めておくのは三点です。一次の窓口はどちらか。誤りが判明したときの訂正にかかる費用は誰が持つか。同じ依頼をやり直す場合、料金は再度発生するのか。三点目は見落とされがちですが、やり取りの回数で費用が決まる形だと、再実行の繰り返しが静かに費用を押し上げます。月末に請求を見て気づくのでは遅すぎます。

もう一つ、依頼が二重に実行される事故があります。同じ依頼が何らかの理由で再送され、相手が二回実行してしまう形です。読み取りだけなら実害は出ませんが、送信や発注が絡む業務では取り返しがつきません。同じ依頼が二度届いたときにどう扱うかを、つなぐ前に書面で決めます。

確認5 止め方：止める条件を数で決める

規格の側にも、止める仕組みは用意されています。依頼の状態に取り消しと拒否があり、相手が受けられない依頼を断ることも、こちらから途中で取り消すこともできます。ただし、関係そのものを切る手順は規格には含まれていません。接続をやめる段取りは、こちらで書いておく必要があります。

実務では、止める条件を人の判断に任せないほうが確実です。連続して失敗した回数、想定していない宛先が出た場合、一日あたりの依頼件数の上限。この三つを数で決めておき、超えたら自動で止めて人に知らせます。止めるかどうかの判断そのものをAIに任せないのが要点です。判断を任せると、止まるべき場面ほど止まりません。

切る手順も先に書きます。預けた資格を無効にする、依頼を出す先を外す、相手に通知する、それまでの記録を保全する。順番を決めておかないと、慌てて資格だけ止めて記録を消してしまうことが起こります。止め方を決めていない接続は、そもそも始めないという判断でかまいません。

マーケの現場で来る接続の形と、見送るべき形

話が持ち込まれる順番は、だいたい決まっています。外部に任せている業務のうち、やり取りが定型で回数が多いものからです。マーケの領域では次の四つが先に来ます。

接続の相手	頼む内容	最初に許す範囲
広告運用の外部委託先	配信実績の収集と、改善案の提示	読み取りと提案まで。設定の変更は人が行う
問い合わせ対応の外部窓口	一次回答の下書きと、社内への振り分け	下書きの作成まで。送信は人が行う
調査や制作の外注先	進行状況の確認と、素材の受け渡し	受け渡しと確認まで。検収は人が行う
販売の代理店	在庫や納期の照会への応答	照会の応答まで。価格の提示はしない

共通しているのは、最初に許すのは読むことと提案することまでで、実行は人が行うという線です。この線を引いておけば、相手の品質が想定と違ったときにも実害が出ません。実行まで広げるのは、記録が三か月ぶん貯まり、止める条件が実際に働いた実績を見てからで十分です。

• 相手の名刺の署名を検証していない：依頼を出す先が差し替えられても気づけない
• 資格を範囲も期限も切らずに預ける：依頼と関係のない場所まで届いてしまう
• 記録を相手側にだけ任せる：原因を追う段になって、こちらには何も残っていない
• 止める条件を人の判断に任せる：気づいたときには件数が積み上がっている
• 読み取りから実行まで一度に許す：送信や発注が絡むと、取り消せない結果が出る
• 規格に対応という一文だけで判断する：つながることと任せられることは別

見送る判断は、相手の技術力ではなく、書面と記録がそろうかどうかで決めます。技術的につながることと、業務として任せられることは別の話です。断る理由を技術に求めると話が長くなりますが、書面がそろわないという理由は誰にでも通じます。

つないでも、AIに判断させない範囲は変わらない

規格が整い、相手とつながっても、線の引き方は変わりません。AIに判断させない範囲は、つなぐ相手が誰であっても同じ場所に引きます。価格の最終決定、取引先への謝罪の最終稿、契約条件の変更、採用の合否。重要な判断は人が行う、という書き方では線が引けないので、職場で通じる業務名で書き出します。

人が確認する範囲も先に決めます。相手から返ってきた成果物のうち、数字、固有名詞、日付の三つだけを元の資料と照らす、と決めてしまう。全部を確認すると決めるのは、決めていないのとほとんど同じです。範囲が三つに固定されていれば、依頼を出した本人でなくても確認できます。

根拠を書かせる運用も、相手が社外のエージェントになると価値が上がります。何をもとにその結論を出したのかを一行で添えさせると、相手の中が見えなくても、材料が届いているかどうかは判定できます。根拠が依頼文の言い換えだけになっていれば、相手にはこちらの材料が渡っていません。

• AIに判断させない業務を、業務名で一覧にしてある
• 確認する項目を、数字と固有名詞と日付の三つに絞ってある
• 成果物に根拠を一行で添えさせている
• 止める条件を数で決めてあり、超えたら自動で止まる
• 預けた権限の範囲と期限を、一覧で管理している
• 接続を切る手順を、記録の保全まで含めて書いてある

よくある質問

MCPとA2Aは、どちらかを選ぶものですか

選ぶものではありません。向きが違うため、必要になる場面も違います。AIができることを増やしたいなら道具につなぐ側、仕事を他所に頼みたいなら相手につなぐ側です。2026年時点では両方を使う設計が推奨されており、実際の構成では、依頼を受けたエージェントが道具側の規格で社内の情報を取りに行く形になります。ただし検討の順番はあり、道具にすら届いていない段階で相手側を進めても、できる仕事は増えません。

社内にエージェントが一つしかない場合、相手側の規格を今から見る意味はありますか

あります。ただし作るためではなく、断るためです。外部の委託先やツールの提供元から接続の提案が来たときに、確かめる項目を持っていないと判断そのものができません。身元、権限、記録、責任、止め方の五つを先に一覧にしておけば、提案が来た日に返事の方向が決まります。作る予定が無くても、この一覧を用意する費用はほぼかかりません。

規格に対応していれば、相手の品質も保証されますか

保証されません。規格が定めているのは、つなぎ方と依頼のやり取りの形までです。相手がどんな手順で考え、どの情報をもとに答えを出すかは、名刺に書かれた能力の宣言以上のことは分かりません。品質は、実際に依頼を出して返ってきた結果を、こちらの基準で確かめるしかありません。試験的に一か月ぶんの依頼を流し、返ってきた結果を人が採点する期間を設けるのが現実的です。

社内の別部署のエージェントとつなぐ場合も、同じ確認が要りますか

身元の確認は軽くできますが、残りの四つは同じように要ります。むしろ社内のほうが、権限の範囲が曖昧なまま広がりやすい傾向があります。相手が社内だと資格を絞る手続きが省かれ、記録も取られないまま動き始めるためです。責任の所在についても、部署をまたぐと担当が空白になりがちです。社外より緩くしてよいのは、書面の形式だけだと考えてください。

まとめ

AIをつなぐ規格には向きの違う二種類があり、道具や社内の仕組みに手を伸ばすのがMCP、別の場所で動くエージェントに仕事を頼むのがA2Aです。前者は手を増やす話、後者は話し相手を増やす話で、検討の順番も確かめる点も別ものです。2026年時点で後者は正式版が出て採用組織は150を超え、いずれの規格も中立的な団体の管理下に移りました。ただし後半には統一的な相互運用の仕様をまとめる動きが控えているため、細部に合わせて作り込むのは早すぎます。相手のエージェントは中身が見えない設計になっており、品質を確かめる材料は返ってきた成果物と記録だけになります。だからこそ記録は相手任せにせず自社側で取ります。規格が定めていないのは、身元、権限、記録、責任、止め方の五つで、ここは書面と運用で埋めるしかありません。まずは自社の業務が止まっている場所が材料なのか分担なのかを見分けたうえで、接続の提案が来たときに使う5項目の一覧を1枚だけ作ってください。作る予定が無くても、断る判断がその場でできるようになります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。