A2Aプロトコル時代にAIエージェントへ自社を発見させる準備【2026年版】

A2Aプロトコル時代にAIエージェントへ自社を発見させる準備【2026年版】

この記事の結論: A2A（Agent2Agent）プロトコルは2026年3月にv1.0が正式リリースされ、Linux Foundationの管理下でエージェント間の標準通信規格として定着しつつあります。マーケター・Web担当者にとって重要なのは実装の詳細ではなく、「Agent Card」という自社の能力を公開するJSONファイルの存在と、それが検索エンジンのクローラーとは別の新しい発見経路を作るという事実です。今すぐ着手できるのは構造化データとllms.txtの整備、時期尚早なのは自前のA2Aサーバー構築です。段階を見極めて準備することが、2026年後半以降のエージェント経由の流入・取引を取りこぼさない鍵になります。

最終更新日: 2026年7月21日

はじめに

「A2A」「Agent2Agent」というキーワードで日本語の情報を探すと、出てくるのはエンジニア向けの実装記事ばかりです。SDKの使い方、MCP（Model Context Protocol）との技術的な違い、サーバー構築のチュートリアル——どれも開発者が読む前提で書かれており、マーケティング担当者やWeb担当者が「自社は何を準備すればよいのか」を知るための記事はほとんど見当たりません。

これは奇妙な空白です。A2Aは元をたどればGoogleが2025年4月に50社以上のパートナーとともに発表したオープンプロトコルであり、目的は「AIエージェント同士が互いの能力を発見し、連携して仕事を任せ合う」ことにあります。ここでいう「互いの能力」には、当然ながら企業のサービス・店舗・コンテンツも含まれます。つまりA2Aは単なるバックエンドの通信規格ではなく、自社が将来のエージェント経済の中で「見つけてもらえるかどうか」を左右するディスカバラビリティ（発見可能性）の新しいレイヤーなのです。

この記事では、実装コードには踏み込まず、事業者・マーケター・Web担当者が理解しておくべき範囲に絞ってA2Aを解説します。何が起きているのか、なぜLLMOやGEO（生成エンジン最適化）の次の主戦場になり得るのか、そして今すぐ着手すべき準備と、まだ手を出すには早い施策の境界線を整理します。

A2Aとは何か: 事業者が押さえるべき3つのポイント

A2Aの技術仕様を細部まで理解する必要はありません。事業者視点で押さえるべきポイントは次の3つに集約できます。

1. エージェント同士が「連携相手」を探すための共通言語である

従来のWebは「人間がブラウザで検索し、ページを読む」ことを前提に設計されていました。A2Aが想定するのは「AIエージェントが別のAIエージェント（あるいは企業のサービス）に対して、直接タスクを依頼する」世界です。旅行予約のエージェントが航空券手配のエージェントに連絡を取り、在庫確認のエージェントが物流のエージェントに問い合わせる——こうしたやり取りを標準化された手順で行えるようにするのがA2Aの役割です。

2. Googleが主導したが、現在は特定企業の所有物ではない

2025年4月の発表時点では、Google Cloudが中心となって50社以上のテクノロジー企業・SIパートナーとともに仕様を公開しました。しかしその後、A2Aプロジェクトの管理はLinux Foundationに移管されており、オープンソースのガバナンス体制のもとで開発が続けられています。特定ベンダーのロックインを避けたい企業にとって、この中立性は採用のハードルを下げる材料になっています。

3. 2026年にv1.0として仕様が固まった

A2Aは長らくプレビュー版の仕様として扱われてきましたが、2026年3月に正式版であるv1.0がリリースされ、同年5月には細部を修正したv1.0.1が公開されています。仕様が「固まった」ということは、これから実装するベンダー・SaaS事業者にとって「仕様が変わり続けるので様子見」という理由が弱くなったことを意味します。事業者側の準備を検討するタイミングとして、2026年後半は決して早すぎません。

なぜLLMO/GEOの次の主戦場になるのか

LLMO（大規模言語モデル最適化）やGEO（Generative Engine Optimization）という言葉が急速に広まったのは、ChatGPTやGoogleのAI OverviewsのようなAI検索が、ユーザーの情報収集の入口としてGoogleの通常検索と並ぶ存在になったからです。多くの企業がこの1〜2年で「AIに引用されるコンテンツ」を意識するようになりました。

しかしAI検索最適化がカバーしているのは、あくまで「AIが人間の質問に答えるためにWebページを参照する」という段階までです。A2Aが示す次の段階は、その先にあります。

この3段階は積み上がっていくものであり、後の段階に進むほど前の段階の土台が必要になります。コンテンツが構造化されておらず、AIにそもそも正しく理解されていない企業が、いきなりエージェント経由の取引に対応することはできません。逆に言えば、今LLMOやGEOに取り組んでいる企業は、A2A時代への準備の一部をすでに終えていることになります。ただし「一部」であって全部ではない点に注意が必要です。第2段階以降は、記事やページの最適化とは異なる準備——具体的にはAgent Cardのようなマシンリーダブルな能力宣言——が必要になります。

検索エンジンの検索結果に表示されなければ人間のユーザーに見つけてもらえなかったように、A2A時代にはAgent Cardが存在しない、あるいは内容が不十分な企業は、エージェントが選ぶ「連携候補」のリストにそもそも上がらない可能性があります。これがA2Aを軽視できない理由です。

Agent Cardと発見メカニズム: マーケター向けの平易な説明

A2Aの中核にある発見の仕組みが「Agent Card」です。技術的な正確さを多少犠牲にしてでも、マーケターに伝わる比喩で説明すると、**Agent Cardは「エージェント版の名刺」**です。

人間同士がビジネスの場で名刺を交換し、そこに書かれた会社名・肩書き・連絡先を見て「この人に何を頼めるか」を判断するように、AIエージェントはAgent Cardを読んで「このサービスに何を依頼できるか」を判断します。Agent CardはJSON形式のファイルで、主に次のような情報を含みます。

• 名前・説明: そのエージェント（サービス）が何者で、何をしてくれるのかの要約
• URL: エージェントへのアクセス先（エンドポイント）
• 入出力形式: どのような形式でリクエストを受け取り、どのような形式で応答を返すか
• 能力（Capabilities）: ストリーミング対応の有無など、そのエージェントが持つ技術的な特性
• スキル（Skills）: 具体的に実行できるタスクの一覧（例: 「在庫確認」「予約」「見積もり作成」）
• 認証方式: そのサービスを利用するために必要な認証の種類

このAgent Cardは、多くの場合「well-known URI」と呼ばれる決まった場所（ドメイン直下の特定のパス）に置かれ、公開されます。これは人間向けのSEOにおけるrobots.txtや、AI検索向けに近年広まりつつあるllms.txtと発想が似ています。決まった場所に、決まった形式で、機械が読める情報を置いておくことで、探しに来たエージェントが迷わず自社の能力を把握できるようにする、という考え方です。

発見のプロセスを単純化すると次の流れになります。

1. 何らかのタスクを持ったAIエージェントが、そのタスクを代行してくれそうな相手を探す
2. 候補となる企業・サービスのAgent Cardを取得し、スキルや入出力形式を確認する
3. 自分のタスクに合致すると判断すれば、Agent Cardに記載されたURLと形式でリクエストを送る

この一連の流れの中で、Web担当者が直接介入できるのは実質的に「1」で候補に上がるかどうかと、「2」でAgent Cardの内容が魅力的で正確かどうかの2点です。ここが、まさにディスカバラビリティ対策として意識すべき領域になります。

A2AとMCPの違い: 「発見」の観点から整理する

A2Aについて調べると必ず出てくるのが「MCP（Model Context Protocol）と何が違うのか」という疑問です。開発者向けの記事では通信方式やアーキテクチャの違いが詳しく説明されますが、マーケター・Web担当者にとって重要なのは発見の観点からの違いです。

重要なのは、両者は競合する規格ではなく補完関係にあるという点です。あるサービスが自社のデータベースやAPIをAIに使わせるためにMCPサーバーを立て、同時に他のエージェントから「連携相手」として見つけてもらうためにA2AのAgent Cardを公開する、という併用が現実的な形になりつつあります。事業者側の準備としては「MCPかA2Aか」の二者択一ではなく、自社サービスがどちらの立場でAIエコシステムに関わるのか——ツールとして使われたいのか、連携相手として発見されたいのか、あるいはその両方か——を整理することが先決です。

llms.txt・構造化データとの関係: 重複ではなく積み上げ

A2Aの登場によって、これまで進めてきたllms.txtや構造化データ（schema.org、JSON-LD）への投資が無駄になるわけではありません。むしろ逆で、これらは積み上げの関係にあります。

• 構造化データ（schema.org / JSON-LD）: ページ単位で「これは何の情報か」を機械に伝える仕組みです。商品ページのPrice・Availability、店舗のLocalBusiness情報などが該当します。A2Aのエージェントがサービス内容を裏取りする際、構造化データが整った公式ページは信頼度の高い参照先になります
• llms.txt: サイト全体・ドメイン単位で「AIに読んでほしい重要な情報はここにある」という道案内をするテキストファイルです。ページ単位の構造化データより粗い粒度で、AIクローラーの効率的な理解を助けます
• Agent Card: サービス・企業単位で「何を代行してもらえるか」という取引可能な能力を宣言するJSONファイルです。構造化データやllms.txtが「情報の提供」に主眼があるのに対し、Agent Cardは「タスクの実行依頼」を前提にしている点が最大の違いです

この3つを粒度で並べると、ページ（構造化データ）→サイト（llms.txt）→サービス（Agent Card）という階層になっており、どれか1つで完結するものではありません。すでにllms.txtや構造化データを整備している企業は、Agent Cardの準備段階で「すでにマシンリーダブルな情報が社内に存在する」という土台を活かせます。逆にこれらが手つかずの企業は、Agent Card単体を用意してもエージェントが裏取りする情報源が乏しく、信頼度の低い候補として扱われるリスクがあります。

エージェント経由の取引への導線: x402・AP2との接続

発見されるだけでは取引は完結しません。A2Aによって「候補として見つかる」ところまで到達した先には、実際にエージェントが決済・注文まで代行する世界が控えています。ここで登場するのが、エージェント同士・エージェントと事業者間の決済を標準化しようとする各種プロトコルです。

代表例として、HTTPのステータスコード402（Payment Required）を活用してエージェントが自律的に少額決済を行う仕組みを目指す「x402」や、Googleが提唱するエージェント決済のプロトコル群「AP2（Agent Payments Protocol）」が挙げられます。これらはA2Aそのものとは別のレイヤーの規格ですが、狙いは共通しています。**発見（A2A）→交渉・依頼（A2Aのタスク実行）→決済（x402やAP2）**という一連の流れをエージェントが人間の介在なしに完結できるようにすることです。

事業者にとっての示唆はシンプルです。Agent Cardで「発見される」準備を進めることは、将来的に「エージェント経由で注文・決済まで受け付ける」ための入口を整えることでもあります。決済プロトコルへの対応は多くの中小事業者にとってまだ先の話ですが、発見の入口だけは今のうちに整備しておく価値があります。決済の仕組みは後から追加できても、そもそも候補として見つけてもらえていなければ交渉の機会自体が発生しないためです。

Web担当者の準備チェックリスト: 今すぐやるべきこと・時期尚早なこと

ここまでの内容を踏まえ、実務担当者が着手すべき優先順位を整理します。すべてを一気に進める必要はなく、段階を踏むことが重要です。

今すぐ着手すべきこと（土台づくり）

• 主要ページに構造化データ（Organization、Product、LocalBusiness、FAQPage等）が正しく実装されているか棚卸しする
• llms.txtを設置し、AIに読んでほしい重要ページ・API情報へのリンクを整理する
• 自社が「何を代行できるサービスか」を、社内で言語化しておく（Agent Cardの下書きに相当する作業）
• 既存のAPIやチャットボット・予約システムなどが外部から機械的に呼び出せる状態になっているかを確認する
• 業界内でA2A・エージェント連携に先行している競合・プラットフォームの動向を定期的にウォッチする

準備を始めてよいが、本番導入はまだ検討段階でよいこと

• 実際のAgent Cardファイルの試作（開発チームと連携し、まずは非公開のテスト環境で）
• MCPサーバーとA2A対応のどちらを優先するか、自社サービスの性質に応じた方針決定
• エージェント経由の予約・注文フローの設計検討（決済プロトコル対応は含めない範囲で)

時期尚早、今は様子見でよいこと

• x402やAP2など決済プロトコルへの本格対応（規格間の主導権争いがまだ続いており、標準が固まりきっていない）
• 全社的なAPIのA2A全面移行（一部の主要サービスからスモールスタートするのが現実的）
• 自前のA2Aサーバーをゼロから構築するような大規模投資（まずは既存のSaaS・プラットフォームがA2A対応を進めるのを待ち、乗り換えコストで対応する選択肢も十分にある）

判断の軸は「発見される準備は前倒しで、取引の自動化は様子を見ながら」という考え方です。構造化データやllms.txtのような土台は、A2Aが普及してもしなくても既存のLLMO・GEO施策として無駄になりません。一方で決済プロトコルのような発展途上の領域に先行投資しすぎると、標準規格が定まった後に作り直しが発生するリスクがあります。

業種別シナリオ: EC・SaaS・ローカルビジネス

A2A時代の準備は業種によって優先度が変わります。3つの代表的な業態でのシナリオを見ていきます。

ECサイトの場合

購買代行エージェントが「予算◯万円以内で、条件に合う商品を探して注文してほしい」という依頼を受けて複数のECサイトを比較検討する未来が想定されています。この場合、商品ページの構造化データ（Product、Offer、AggregateRating）が整っていることは最低条件であり、その上で在庫確認・価格照会・注文処理をエージェントが機械的に呼び出せるAPIやAgent Cardの整備が競争力に直結します。特に価格変動や在庫状況をリアルタイムで返せる仕組みは、静的なページ情報しか持たない競合との差別化要因になります。

SaaSの場合

SaaSはもともとAPIを持っていることが多く、A2A対応への距離が最も近い業態です。他社のワークフロー自動化エージェントから「このタスクを代行してほしい」と依頼された際に、自社のSaaSが持つ機能をスキルとして正しく表現できているかがポイントになります。既存のREST APIドキュメントを整備している企業は、そのドキュメントをAgent Cardのスキル定義に翻訳する作業から着手するのが現実的です。

ローカルビジネス（店舗・飲食店等）の場合

「近くでこの条件に合う店を予約して」というエージェント経由の依頼は、Google ビジネスプロフィールやローカルSEOで培ってきた情報整備の延長線上にあります。営業時間・在庫・空席状況といった変動情報を構造化データで機械可読な形に保つことがまず重要です。予約システムを外部から呼び出せる形で公開できれば、エージェントが直接予約を完了させる導線につながります。多くのローカルビジネスにとって自前のAgent Card構築は現実的ではないため、予約プラットフォームやPOSベンダーがA2A対応を進めた際に、その仕組みに乗る形での対応が現実的な選択肢になります。

リスクと注意点

A2Aへの準備を進めるにあたり、事業者が見落としがちなリスクも整理しておきます。

認証・なりすましのリスク: Agent Cardは公開情報であるため、悪意のある第三者が自社を騙るAgent Cardを設置する可能性があります。公式ドメインでの公開と適切な認証方式の明示は必須であり、公開後も定期的な監視が欠かせません。

過剰な情報公開のリスク: Agent Cardに社内システムの詳細を書きすぎると、意図せず攻撃対象領域を広げることになります。外部に公開すべき能力と、社内利用に留めるべき機能を切り分けて設計する必要があります。

規格の未成熟な部分への過剰投資: A2A本体はv1.0として仕様が固まりましたが、決済プロトコルなど周辺領域はまだ複数の規格が競合している段階です。1つの規格に全面依存する意思決定は、標準が収斂するまで慎重に行うべきです。

エージェントに評価されるコンテンツの質: 従来のSEOで横行した「検索エンジンだけを騙す」施策と同様に、Agent Cardの記述だけを実態以上に盛る運用は、実際にタスクを依頼された際の失敗としてエージェント側・利用者側の信頼を損ないます。人間向けの誇大広告がブランド毀損につながるのと同じ構造が、エージェント向けの情報公開にも存在します。

よくある質問

Q1. A2Aプロトコルとは簡単に言うと何ですか?

AIエージェント同士が互いの能力を発見し、タスクを依頼し合うための共通の通信規格です。2025年にGoogle主導で発表されました。

Q2. Agent Cardとは何ですか?

自社サービスが「何を代行できるか」をJSON形式で公開する、いわばエージェント版の名刺です。名前・URL・スキル・認証方式などを含みます。

Q3. A2AとMCPはどちらを優先すべきですか?

対立する規格ではなく用途が異なります。外部ツールとして使わせたいならMCP、連携相手として発見されたいならA2Aを検討します。

Q4. 中小企業でもA2A対応は必要ですか?

自前のA2Aサーバー構築は時期尚早です。まず構造化データとllms.txtの整備、そして利用中のプラットフォームのA2A対応を待つのが現実的です。

Q5. llms.txtやschema.orgはA2A対応で無駄になりますか?

無駄になりません。ページ単位の構造化データ、サイト単位のllms.txt、サービス単位のAgent Cardは粒度が異なる積み上げの関係にあります。

Q6. x402やAP2にはいつ対応すべきですか?

まだ複数の決済プロトコルが並立し標準が固まっていない段階です。発見の準備を先に整え、決済対応は規格の収斂を見てからで問題ありません。

Q7. A2Aはいつ正式版になりましたか?

2026年3月にv1.0が正式リリースされ、同年5月にはv1.0.1が公開されています。管理はLinux Foundationに移管されています。

Q8. Agent Cardはどこに置けばよいですか?

多くの場合、ドメイン直下のwell-known URIと呼ばれる決まった場所に配置し、機械が自動的に発見できるようにします。

Q9. Agent Cardの内容を誇張してもよいですか?

推奨されません。実態と乖離した記述は、タスク失敗としてエージェント側・利用者側からの信頼低下を招きます。従来の誇大広告と同じリスクです。

Q10. GEOやLLMOへの取り組みはA2A対応の土台になりますか?

なります。構造化データやコンテンツの機械可読性は、Agent Cardの内容をエージェントが裏取りする際の信頼材料として活用されます。

関連用語

• LLMO
• GEO
• llms.txt
• 構造化データ
• schema.org
• JSON-LD
• クローラー

関連記事

• LLMO完全ガイド
• AI検索最適化ガイド
• x402: エージェント決済時代のEC事業者準備
• AP2: エージェント決済プロトコルとECチェックアウト
• Stripe Agentic Commerce Suiteの事業者向けセットアップ
• Visa×ChatGPTのエージェント決済とEC事業者の準備
• Googleユニバーサルカートとエージェントショッピングの準備
• llms.txtは必要か: GoogleとAgentic Commerceの狭間で
• LLMO対策は外注と内製どっち？判断基準7つと費用対効果の分岐点【2026年】
• LLMO対策は丸投げできる？代行に任せられる範囲・成果報酬の実態・失敗しない任せ方【2026年】
• LLMO対策の業務委託契約書チェックポイント12｜損しない条項の見方
• LLMO対策のセカンドオピニオンのすすめ｜今の会社を乗り換えるべきかの判断基準