「御社はA2Aに対応していますか」。この一問が、ベンダー選定の面談で最初に飛んでくるようになりました。機能の一覧より先に接続の規格を確かめる担当者が、この一年で明らかに増えています。賢さを比べるのは、そのあとの話になりました。

理由は、接続の規格が一社の持ち物から業界共通の土台へ移ったことにあります。どの製品とどう組み合わせられるかを、営業資料ではなく公開された仕様で確かめられる。判断の材料が、説明を受ける側の手元に来ました。

ただし、この一問だけで答えが決まるわけではありません。導入前の相談で聞かれることの重心が、機能の一覧から接続の条件へ寄っていくのを、この一年受け取ってきました。技術の話に見えて、中身は投資をどこに預けるかという配分の判断です。

A2A プロトコルとMCPは、いま何が確定しているのか

確定したのは二本立ての構図です。AIと道具・データをつなぐ層をMCPが、エージェント同士のやり取りをA2Aが受け持ち、どちらも特定企業の手元から中立の運営体へ移りました。

A2Aは2025年4月にGoogleが作り、同年6月23日にLinux Foundationのプロジェクトとして発足しています。発表には100社を超える企業が名を連ね、AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNowが賛同の言葉を寄せました。

発足時の発表文は、狙いをはっきり書いています。複数の提供元と基盤にまたがるエージェントを束ね、モジュール性を高め、ベンダーロックインを緩和し、革新を速める。需要側の不満が出発点にあったことが、この一文から読み取れます。

一年後の2026年4月9日、Linux Foundationは支持組織が150を超え、仕様がバージョン1.0に到達したと発表しました。Microsoft Azure AI FoundryとCopilot Studio、AWSのAmazon Bedrock AgentCore Runtime、Google Cloudに統合され、供給網・金融・保険・IT運用の現場で本番稼働が始まっています。

道具接続の側も、置き場所が変わりました。MCPは2025年12月9日に発足したAgentic AI Foundationへアンソロピックが寄贈し、Blockのgoose、OpenAIのAGENTS.mdとともに創設プロジェクトになっています。プラチナ会員にはAWS、アンソロピック、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAIが並びました。

規模の数字も添えられています。発表時点で公開されたMCPサーバーは1万件を超え、AGENTS.mdは6万を超えるオープンソースのプロジェクトが採用していました。実装が先に広がり、運営の器が後から整った順序です。

二つを混同しないほうが、判断は速く進みます。MCPが担うのは、AIから業務システムや文書へ手を伸ばす縦の接続です。A2Aが担うのは、別々に作られたエージェント同士が仕事を渡し合う横の接続になります。縦と横のどちらが自社の課題なのかで、確かめる資料も変わってきます。

バージョン1.0という表記も、調達では意味を持ちます。仕様が実験段階を抜け、互換を意識した改訂の局面に入ったという合図だからです。社内の稟議で「まだ固まっていない技術ではないか」と問われたとき、この一点は答えの材料になります。

経営として押さえたいのは、規格の行方が一社の経営判断から外れたという一点でしょう。仕様の変更が競合を締め出す手段になりにくくなり、採用の可否を数年単位の前提として扱えるようになりました。

なぜ「つながるか」が選定基準に上がったのか

一社の製品だけで業務が閉じないからです。受発注は基幹系に、問い合わせはSaaSに、承認はグループウェアに置かれていて、エージェントを入れる場所は必ず何かの隣になります。

以前はその「隣」との接続が、一件ごとの作り込みでした。接続に払った費用は資産として残らず、乗り換えを重くする錘だけが積み上がる。使うほど動けなくなるという、投資としては具合の悪い構造です。

共通の作法で組めるようになると、この錘が軽くなります。比較の土俵は「つなげるかどうか」から「つないだあとに何が残るか」へ移り、面談で出る質問もそれに合わせて変わりました。

150という組織数より、本番稼働という一言のほうが重い。参加を表明した段階と、止まると業務が困る場所で動いている段階では、規格の寿命に対する見立てが違ってきます。供給網や金融の現場で使われている事実は、数年先まで前提にしてよいという材料になります。

調達の言葉に直すと、接続は仕様ではなく条件になりました。

以前なら開発の見積りに紛れていた項目が、契約前に確かめられる条件として表に出てきた、ということです。見積書の一行だったものが、比較表の欄へ上がったと言い換えてもよいでしょう。

接続が前提になったぶん、比較の軸そのものも一段上がりました。少し前まではつながる製品であること自体が売り文句でしたが、いまはつながって当たり前です。差がつくのは、つないだ状態をどれだけ長く、どれだけ安く保てるかという運用の側になります。

私が受ける相談でも、問いは「御社は何ができますか」から「うちの基幹系と、いま使っている問い合わせ基盤の間に入れますか」へ寄りました。できることの広さではなく、置き場所の適合を先に聞く。単体性能の比較を後回しにする担当者が、目に見えて増えています。

標準化はロックインを消したのか、それとも移したのか

消えたのは接続層の囲い込みで、残ったのは記録と運用の囲い込みです。つなぐ手間が下がったぶん、閉じ込めの重心が別の場所へ動いた、と見るほうが実態に近い。

第一の移り先は、業務の記録です。どの依頼がどこまで進み、誰が承認し、何を根拠に処理したのか。この履歴が特定の製品の中にしか存在しない形になっていると、乗り換えは過去を捨てる決断とほぼ同じ意味になります。

第二は、業務の決め事の置き場所です。例外を誰に戻すか、何度まで再試行するか、いくらから人の承認に回すか。こうした線引きを製品固有の設定として書き込むほど、移設は設定の写しではなく再設計に変わります。

第三は運用の体制です。監視の当番、費用の按分、障害時の連絡先。仕組みが日々動くための人と手順は、規格が整っても自社と提供元の間に残ります。

三つに共通するのは、どれも導入の初日には見えないという点です。動き始めた仕組みは順調に見えますし、問題が姿を現すのは更新か解約の場面になります。まだ何も動いていない選定の段階でしか、この確認は落ち着いて進められません。

だから契約前の問いは一つに絞れます。やめるとき、手元に何が残りますか。記録の書き出し形式、設定の一覧、再現の手順。この三つを答えられる相手なら、接続の話は前へ進めてよいと判断しています。

本番運用まで含めた投資判断の組み立ては、エージェンティックワークフローの本番化で全体の順序として扱いました。標準化はその前提を一段軽くしましたが、判断の中身までは肩代わりしてくれません。

「対応しています」は、どこまでを保証するのか

その一言だけでは範囲が定まりません。版と役割まで聞いて、はじめて何と何がつながるのかが決まります。

MCPの仕様は、後方互換を壊す変更があった日付を、そのまま版の名前にしています。形式はYYYY-MM-DDで、現行の版は2026年7月28日版です。互換を保つ改善では版が上がらないため、版が動いた日は互換が切れた日だと読めます。

やり取りの作法も公開されています。要求ごとに使う版を宣言し、サーバーは要求単位で受理するか拒否するかを決める。支持していない版を受け取った場合は、対応できる版の一覧を添えたエラーが返ります。

先に確かめる道も用意されました。server/discoverという必須の呼び出しで、そのサーバーが支持する版と能力、身元を一度に取得できます。クライアントもサーバーも複数の版を同時に支持してよいので、「対応」の中身は本来、幅で答えられるはずのものです。

A2A側の入口は、エージェントカードと呼ばれる公開のJSON文書になります。身元、能力、提供するスキル、接続先の端点、認証の要件、対応するプロトコルの版が、そこに書かれています。

つまり確認は、口頭の請け合いではなく機械が読める文書で取れる。「対応しています」という回答は、次の三つに割って聞き直すと輪郭が出ます。

• どの版に対応しているのか。仕様の版表記で答えられるか
• サーバーとクライアントのどちら側を担うのか。片側だけではないか
• 能力と認証の要件は、公開の文書で確かめられるか

両側に対応しているかどうかも、意外と分かれます。呼ばれる側だけを実装した製品では、自社のエージェントから相手を呼び出す使い方ができません。将来どちら向きの連携を増やすのかを先に描いておくと、この一点だけで候補が絞れることもあります。

技術者でなくても聞ける質問です。答えが資料の所在で返ってくるか、言葉の請け合いで返ってくるか。その差だけでも、実装の成熟度はかなり見当がつきます。

相互運用性は、どの資料で確かめられるのか

公開仕様、エージェントカード、提供元の運用資料の三点です。カタログの対応表は出発点にすぎず、確かめる先は別のところにあります。

確かめること	見る資料	曖昧なまま進めたときに起きること
対応する規格と版	公開仕様の版表記、カードの版欄	古い版に留まった実装同士で接続が成立しない
どちら側を担うか	カードの端点と能力の記載	呼ばれる側にはなれても、呼ぶ側になれない
長時間処理の扱い	カードの能力欄（逐次配信・通知）	数分で終わらない処理の完了通知が届かない
認証の方式	カードの認証要件	社内の認証基盤に載らず、例外運用が生まれる
版が上がったときの挙動	版の交渉と失敗時の応答仕様	更新のあった日に、連携が静かに止まる
記録の持ち出し	契約書と運用の手引き	乗り換え時に、過去の履歴を再現できない

右端の列を先に読むと、この確認が後回しにされやすい理由が見えてきます。どれも導入した直後には表面化せず、更新や乗り換えの局面で初めて費用に化ける項目だからです。稟議の時点では、いちばん語られにくい欄でもあります。

六つとも、確認そのものは一往復のやり取りで済みます。

時間がかかるのは、社内で誰がこの質問を出すのかが決まっていない場合です。調達の様式に欄として刻んでおけば、担当者が代わっても確認は手順として残ります。

AIエージェント 標準化が進んでも、つながらないのはどんなときか

規格が合っても、業務の語彙と運用の作法が合わなければ、つながったとは言えません。準拠がそろえるのは共通の入口までで、その先は各社の仕事として残ります。

代表的なのは、項目の対応付けです。品目コードや取引先コードの表記が部署ごとに揺れていれば、規格に沿って受け渡しても中身が食い違う。名寄せと様式の統一という地味な下ごしらえは、標準化のあとも自社の宿題です。

呼び名がそろっても、扱いまではそろいません。処理が人の入力を待っている状態には仕様上の定義がありますが、その待ちを誰に何分で回すかは、製品の作りと自社の運用が決めます。同じ状態名を使う二つの製品が、同じ振る舞いをするとは限らない。

版の寿命も見落とされがちです。廃止予定と印の付いた機能は、原則として十二か月以上、迅速な削除の例外でも九十日以上は仕様に残ったうえで、将来の改訂で取り除かれます。組み合わせには有効期限がある、と読むべきところでしょう。

認証と網の境界も、規格の手前で詰まりやすい場所です。カードに書かれた認証方式が社内の基盤と噛み合わなければ、例外の運用を作るか、境界に中継を置くかの判断が要ります。仕様に沿っているのに現場で止まる事例の多くは、この段差から起きています。

規格が定義しない領域も広く残ります。監査の記録をどこまで保つか、費用をどう按分するか、障害の連絡をどこへ入れるか。接続の作法が共通でも、運用の契約は個別に結ぶことになります。

準拠は、品質の保証でもありません。同じ作法で話せることと、相手の処理が自社の水準で正しいことは、別の話だからです。接続の確認が済んだあとに業務の受け入れ試験が要る点は、これまでのシステム導入と変わりません。

いちばん危ういのは、対応済みの製品を選べば設計が済むという読み違えです。どの業務をエージェントに分けて渡すかという判断は標準の外にあり、マルチエージェントを業務で使う判断基準では責任範囲と切り分けやすさの側から整理しました。

選定の物差しに加わる三つの欄

従来の欄が消えるわけではありません。機能、価格、導入実績はこれまでどおり見ます。そこへ次の三つが足された、と考えるのが実態に合っています。

• 接続の可搬性。どの規格の、どの版に、どちら側として対応しているか
• 退出時に残るもの。記録、設定、手順を、どの形式で自社に持ち出せるか
• 版への追随。仕様が動いたとき、誰がいつ検証し、誰が費用を持つか

三つとも、稟議書に一行で書ける形にしておくと効きます。「相互運用性が高い」では決裁は通りませんが、「対応版はどれ、記録はこの形式で書き出し可、版の追随は保守契約に含む」なら、判断の対象になります。

この三欄は、比較表の隅ではなく最初の絞り込みに置くほうが実務的です。単体性能で三社に絞ってから接続条件で全滅するより、接続条件で候補を切ってから性能を比べたほうが、面談の回数は減ります。

提供元との会話も、性能の主張ではなく資料の突き合わせに変わります。営業の言葉づかいに左右されない比較ができるぶん、判断の再現性が上がります。

中堅・中小企業にとって、この転換は追い風になるのか

追い風です。ただし、自社の業務を言葉にできている会社に限られます。

大きいのは、接続にかかる費用が下がったことよりも、やめるときの費用が下がったことのほうです。少人数の体制で本番運用まで通す組み立てそのものはエージェンティックワークフローの本番化：2026年の到達点で扱いましたが、標準化がその手前で動かしたのは、候補を入れ替えるときに払う金額でした。

記録の書き出し形式と設定の一覧を契約前に押さえておけば、一社目の選定を外しても二社目でやり直せます。予備の候補を抱えておく体力のない会社ほど、この後戻りの余地が効きます。守りの条件に見えて、実際には最初の一歩を軽くする材料です。

どの業務を渡すか、どこで人が承認するか、例外を誰に戻すか。この線引きは標準がそろっても代わってもらえず、自社にしか書けません。

渡したい業務の入口と出口、そして例外の戻し先を、一枚の紙に書けるか。言葉にできているかどうかは、この一枚で見当がつきます。書けるなら接続の話へ進めますし、書けないなら製品を比べる前にそこからです。

ChatGPTは答えます。WindyFloは働きます。標準化が整えたのは道具と道具の間の通り道であって、その先で何をどこまで実行させるかは、各社の業務設計に残ります。私たちが完全管理型と日本語での運用にこだわるのも、この残った部分の負担を提供側で引き受けるためです。

日本の現場では、利用率が国際水準に並んだ一方で、用途が補助業務に偏っています。内訳は生成AIの利用率と用途の偏りで扱いましたが、接続の規格が整ったいま問われるのは、補助から実行へ渡す業務を一つ決められるかどうかだと考えています。

いま何を決め、何を先送りしてよいのか

決めるのは三つです。調達の質問票に接続の三欄を入れること、退出時に残るものを契約前に確認すること、版が動いたときの追随を誰が持つか取り決めること。どれも技術の選定ではなく、社内の手続きの整備にあたります。

先送りしてよいことも、はっきりしています。社内標準を特定の版に固定するのは早い。すでに動いている連携を、標準に沿っていないという理由だけで置き換えるのも急ぎません。支持組織の増減を追いかけるのは、四半期に一度で足ります。

先送りの線を引いておくと、現場は落ち着いて動けます。

決めた三つは、一度作れば次の案件でも使い回せます。質問票の欄も契約の確認事項も、製品が変わるたびに書き直す性質のものではないからです。一社目の選定でかかった手間は、二社目以降の速度として戻ってきます。

順序を一つ挙げるなら、業務、接続、製品の並びになります。渡したい業務を決め、その業務が触る道具との接続条件を書き出し、それを満たす製品を比べる。逆から入ると、機能の多い製品を選んだうえで現場に遊ばせることになりがちです。

選定基準に相互運用が入ったという変化は、買い手に有利な変化です。比べる材料が公開の文書に載り、乗り換えの費用が下がった。この一年の動きは、そう受け取ってよいと私は見ています。

よくある質問

出典

• ［1次］The Linux Foundation「Linux Foundation Launches the Agent2Agent Protocol Project to Enable Secure, Intelligent Communication Between AI Agents」（2025年6月23日発表、2026年8月27日確認）— GoogleがA2Aを2025年4月に作成しLinux Foundationへ持ち込んだこと、100社超の支持とAWS・Cisco・Microsoft・Salesforce・SAP・ServiceNowの参画、目的として「モジュール性を高め、ベンダーロックインを緩和し、革新を加速する」ことを明記: https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
• ［1次］The Linux Foundation「A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year」（2026年4月9日発表、2026年8月27日確認）— 支持組織150超、仕様バージョン1.0、Microsoft Azure AI Foundry・Copilot Studio／AWS Amazon Bedrock AgentCore Runtime／Google Cloudへの統合、供給網・金融・保険・IT運用での本番稼働: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
• ［1次］A2A Protocol 公式仕様 v1.0.0（2026年8月27日確認）— エージェントカードは「A2Aサーバーが公開するJSONメタデータ文書」であり、身元・能力・スキル・サービス端点・認証要件・対応プロトコル版を宣言する: https://a2a-protocol.org/latest/specification/
• ［1次］The Linux Foundation「Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)」（2025年12月9日発表、2026年8月27日確認）— MCP（Anthropic寄贈）・goose（Block寄贈）・AGENTS.md（OpenAI寄贈）を創設プロジェクトとするAAIFの設立、公開MCPサーバー1万件超、AGENTS.md採用6万プロジェクト超、プラチナ会員8社: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• ［1次］Model Context Protocol 公式ドキュメント「Versioning」（2026年8月27日確認）— 版はYYYY-MM-DD形式で「後方互換を壊す変更が最後に行われた日付」を示し、現行版は2026-07-28。要求ごとにプロトコル版を宣言してサーバーが個別に受理・拒否し、非対応時は対応版一覧を伴うエラーを返す。server/discoverは支持版・能力・身元を返す必須のRPC。廃止予定の機能は原則12か月以上（迅速な削除の例外では90日以上）仕様に残る: https://modelcontextprotocol.io/specification/versioning
• ［1次］A2A Protocol 公式ドキュメント「Agent Discovery」（2026年8月27日確認）— エージェントカードの探索方式として、ドメイン直下の所定パス（/.well-known/agent-card.json、RFC 8615に沿う）での公開は「公開エージェント、または特定ドメイン内で広く発見されることを意図したエージェント」に推奨される方式であり、ほかにレジストリ（カタログ）への照会、設定ファイルや環境変数などによる直接指定があること、機微な情報やより詳細な版には認証つきの拡張カードの利用が推奨されることを明記: https://a2a-protocol.org/latest/topics/agent-discovery/
• 選定面談での質問の変化、および確認項目の表に関する記述は、ハマダラボ（HAMADA LABS Japan）が日本市場での導入相談で得た一次観察に基づくものであり、特定企業の実在事例ではありません。