第2回では、病院の紹介状がFAXから消える未来を描いた。第3回では、AIが代わりに買い物をするECの世界を。第4回では、住宅ローン審査が3行同時に走る不動産の話を。
3つの業界で共通して繰り返し出てきたフレーズがある。
「AIエージェントに見つけてもらう」。
医療機関のエージェントが紹介先を探すとき、ECのエージェントが商品を比較するとき、不動産のエージェントが物件を検索するとき。いずれの場合も、あなたの会社のWebサイトがエージェントから認識されなければ、取引の候補にすら入らない。
人間の検索には「10ページ目まで粘り強くスクロールする」という行動がある。AIエージェントにそんな習慣はない。構造化されたデータを効率的に読み取り、条件に合致するサービスを瞬時に選別する。見つけてもらえるか、見つけてもらえないか。その境界はすでに技術的に定義されている。
この最終回では、あなたの会社のWebサイトが「AIエージェントから見つけてもらえる状態」になっているかを、具体的に検証する方法を示す。
すべては「サイトのルートに置くファイル」に収束する
Webの歴史を振り返ると、新しい種類の「読み手」が登場するたびに、サイトのルートに標準化されたファイルを置く慣行が生まれてきた。
Layer 1：robots.txt ― クローラーへの許可証（1994年〜）
最も古い「自己紹介ファイル」だ。検索エンジンのクローラーに対して「ここはクロールしていい、ここはダメ」と伝える。RFC 9309として正式に標準化されている。30年以上の歴史があり、すべてのWebサイト管理者が知っている存在だ。
ただし2026年現在、robots.txtの役割は拡張されている。AIクローラー（GPTBot、ClaudeBot、PerplexityBotなど）をどう扱うかという問題が加わった。Cloudflareが2025年7月からデフォルト設定でAIボットをブロックするよう変更したため、自社のrobots.txtがAIクローラーを意図せずブロックしていないかは、今すぐ確認すべき事項だ。
Layer 2：llms.txt ― AIへの自己紹介（2024年〜）
Answer.AIのJeremy Howardが2024年9月に提案したフォーマット。サイトの概要、構造、重要なページへのリンクをMarkdown形式で記述し、/llms.txtとして設置する。LLMが「このサイトは何のサイトで、何の情報が重要か」を効率的に把握するためのファイルだ。
正直な評価。 SE Rankingの30万ドメインを対象とした調査では、2026年時点での採用率は約10%にとどまる。さらに重要なのは、llms.txtの有無がAIによる引用頻度に統計的に有意な影響を与えていないという研究結果が出ていることだ。ALLMOの94,000以上の引用URLを分析した調査でも、llms.txt採用による引用増加は確認されなかった。Google、OpenAI、Anthropicいずれも、llms.txtを公式にサポートするとは表明していない。
それでも設置を推奨する理由。 llms.txtの実装コストはきわめて低い（1〜4時間程度）。仮にAIプラットフォームがこのフォーマットを正式採用しなかったとしても、デメリットはゼロだ。一方で、robots.txtもsitemap.xmlも、広範なプラットフォームサポートが普及に先行したのではなく、普及が先行してプラットフォームサポートが後追いした。llms.txtが同じ道を辿る可能性は排除できない。
Layer 3：Agent Card（agent-card.json） ― エージェントへの能力宣言（2025年〜）
ここからが本シリーズの核心に近い部分だ。
第1回で解説したA2Aプロトコルにおいて、Agent CardはA2Aサーバー（リモートエージェント）が自分自身の能力を宣言するJSON形式の「名刺」だ。A2A公式仕様では、/.well-known/agent-card.json に設置することが推奨されている（RFC 8615に準拠）。
Agent Cardには以下の情報が含まれる。
name / description： エージェントの名前と説明。クライアントエージェントがこの情報を読み取り、「このエージェントは自分のタスクに適しているか」を判断する。人間向けのコピーライティングではなく、AIが解釈しやすい明確で具体的な表現が求められる。
url： A2Aエンドポイントのサービス URL。
version： エージェントのバージョン。
provider： サービス提供者の情報（組織名、URL）。
capabilities： ストリーミング対応、プッシュ通知対応、タスク状態履歴の公開など、エージェントがサポートする技術的機能。
skills： これが最も重要な部分だ。エージェントが提供できる具体的なスキル（能力単位）を列挙する。各スキルにはid、name、description、tags、examples、対応する入出力のMIMEタイプが含まれる。
authentication： クライアントがこのエージェントと通信するために必要な認証方式（Basic、Bearer、OAuth 2.0など）。
2026年3月時点では、Agent Cardはまだ開発者向けプロトコルの域にある。一般企業のWebサイトがAgent Cardを公開している事例はほぼ存在しない。しかし、Spring AI、LangGraph、AWS Bedrock AgentCoreなどの主要フレームワークが次々にA2A対応を実装しており、「Agent Cardを読みに来るクライアントエージェント」は確実に増加する。
Layer 4：UCP Profile ― 商取引エージェントへの取引能力宣言（2026年〜）
第3回で解説したUCP（Unified Commerce Protocol）は、ECサイトがAIショッピングエージェントに対して「カート操作」「チェックアウト」「在庫照会」「注文管理」などの商取引能力を宣言するプロトコルだ。/.well-known/ucpに設置される。
4つのレイヤーに共通するパターンは明確だ。 新しい種類の「読み手」が登場するたびに、サイトのルート（または/.well-known/ディレクトリ）に標準化された構造化ファイルを置くことで、外部システムが自動的にそのサイトの情報を取得・理解できるようにする。robots.txt → llms.txt → agent-card.json → UCP profileと、「誰に向けた自己紹介か」が段階的に拡張されている。
reasoning.json ― 「推論の指示書」という新しい試み
4つのレイヤーに加えて、もう1つ注目すべき提案がある。Agentic Reasoning Protocol（ARP）が定義する/.well-known/reasoning.jsonだ。
reasoning.jsonは、既存の標準が「記述的」（何があるかを伝える）であるのに対して、「認知的」（どう考えるべきかを伝える）レイヤーを目指している。サイトオーナーがAIエージェントに対して「この情報をどのように推論すべきか」「何をハルシネーションしてはいけないか」「どのような文脈で解釈すべきか」を構造化して指示できる。
正直な評価。 reasoning.jsonは2026年3月時点でDraft / RFC（v1.1）の段階にある。MITライセンスのコミュニティ主導プロジェクトであり、W3CやLinux Foundationなどの標準化団体による支持はない。主要なAIプラットフォームがこのファイルを読み取って推論に反映している事実も、現時点では確認できていない。
ただし、reasoning.jsonが提起している問題そのものは本質的だ。robots.txtは「どこを見ていいか」を伝え、llms.txtは「何が重要か」を伝え、Agent Cardは「何ができるか」を伝える。しかし「どう考えるべきか」を伝える仕組みは、まだ存在していない。Schema.orgのJSON-LDは部分的にこの役割を果たすが、「推論の指示」に特化した標準が将来必要になる可能性は高い。
いま実装を急ぐ必要はない。ただし、この方向に標準化が進むことは意識しておくべきだ。
GEOの行方 ― 用語は退潮するが、問題は残る
GEO（Generative Engine Optimization）という用語は、2024年後半から2025年にかけてSEO業界で急速に広まった。「AIに引用されるためにコンテンツを最適化する」という概念だ。
2026年3月時点で、GEOの状況はこうなっている。
市場は確実に拡大している。 ChatGPTの週間アクティブユーザーは9億人に達し（2026年2月、OpenAI発表）、GeminiアプリはMAU 7.5億人に達した。AI Overviewsは検索結果の約25%に表示されている（Conductor 2026調査。調査機関により21〜30%の幅がある）。GEO市場はCAGR 40.6%で成長し、2034年に171億ドル規模に達するとの予測もある。
しかし「GEO」という用語自体は揺れている。 GEO、AEO（Answer Engine Optimization）、LLMO（Large Language Model Optimization）、AIサーチ最適化。業界はまだ単一の用語に収束していない。これは、この領域がまだ成熟していない証拠だ。
本質的な問題は用語ではなく構造にある。 AI OverviewsのソースとGoogle検索上位10件の重複率について、GEO分析企業Brandlightは「70%から20%以下にまで低下した」と報告している（LLMrefs経由）。一方、BrightEdgeの16ヶ月間の追跡調査では、AI Overview引用とオーガニック上位10件の重複率は2024年5月の32.3%から2025年9月に54.5%へ上昇しているという逆のデータもある。この乖離は、調査対象のクエリ種別や測定方法の違いによるものだが、いずれにせよ従来のSEOで上位に表示されることと、AIに引用されることは、単純にイコールではない。これは「GEO」という名前がどう定着するかとは無関係に、すべてのWebサイトオーナーが直面する構造的な変化だ。
GEOの実践で確実に言えること。 エンティティ（ブランド、製品、人物、場所などの明確に識別可能なもの）の一貫性がAI引用において最も重要だ。Schema.orgマークアップ（Organization、Product、Person、Article、FAQ）は、AIエンジンにサイトの構造化された文脈を伝える最も直接的な手段となる。そしてAIクローラーがサイトにアクセスできる状態を維持すること（robots.txtの確認）は、すべての前提条件だ。
用語の流行に振り回される必要はない。やるべきことは、ここまで本シリーズで解説してきた「構造化されたファイルを置く」という具体的な実装に集約される。
Schema.org ― 15年の蓄積が最強の武器になる
ここまで新しいプロトコルの話をしてきたが、実は最も効果的で、最も今すぐ実装できるのはSchema.orgだ。
Schema.orgは2011年6月にGoogle、Microsoft（Bing）、Yahoo!の3社が立ち上げた構造化データの語彙体系で、同年11月にYandexが参加した。15年の歴史を持ち、すべての主要検索エンジンがサポートしている。
llms.txtやAgent Cardと違い、Schema.orgはすでに効果が実証されている。Google検索のリッチリザルトの表示条件であり、AIシステムがWebページの内容を理解するための基盤的なシグナルでもある。
業種別の推奨Schema.orgマークアップは以下の通りだ。
医療機関： MedicalOrganization、Physician、MedicalClinic。診療科目、対応言語、予約可否、保険対応情報。
EC事業者： Product、Offer、AggregateRating、Review。価格、在庫状況、配送条件、返品ポリシー。
不動産事業者： RealEstateListing、Offer、Place、GeoCoordinates。物件種別、価格、面積、築年数、最寄り駅。
すべての企業： Organization、LocalBusiness、ContactPoint、Person（代表者やスタッフ）。基本的な企業情報の構造化は、業種を問わず有効だ。
JSON-LDで実装すれば、HTML本体に手を加える必要がない。<script type="application/ld+json">タグをページの<head>に追加するだけで、人間向けのデザインを一切変更せずにAI向けの構造化データを提供できる。
あなたのサイトは「見つけてもらえる」か ― 5つの確認項目
ここまでの話を、今すぐ確認できるチェックリストにまとめる。
1. AIクローラーのアクセス許可（robots.txt）
自社サイトの/robots.txtを確認する。GPTBot、ClaudeBot、PerplexityBot、Google-Extended（Geminiのクローラー）がブロックされていないか。Cloudflareを使用している場合、2025年7月のデフォルト設定変更でAIボットが自動的にブロックされている可能性がある。
確認方法： ブラウザでhttps://あなたのサイト/robots.txtにアクセスする。User-agent: GPTBotやUser-agent: ClaudeBotに対するDisallow: /が設定されていたら、AIクローラーをブロックしている。
2. サイトの要約（llms.txt）
/llms.txtを設置しているか。設置している場合、内容は最新の状態に保たれているか。リンク切れがないか。20〜50リンク程度に厳選されているか。
設置していない場合： 上述の通り、llms.txtの直接的な効果は現時点では実証されていない。しかし実装コストは極めて低く、リスクはゼロだ。余裕があれば設置しておくことを推奨する。
3. 構造化データ（Schema.org / JSON-LD）
主要なページにSchema.orgのJSON-LDマークアップが実装されているか。最低限、Organization（企業情報）、主要なサービスや製品のマークアップは入れておくべきだ。
確認方法： GoogleリッチリザルトテストにURLを入力する。または、ページのソースコードでapplication/ld+jsonを検索する。
4. ページ構造の明確さ
AIが読み取りやすいページ構造になっているか。見出し（H1〜H3）が論理的に階層化されているか。重要な情報が最初の200ワード以内に含まれているか。JavaScriptで動的に生成されるコンテンツが、クローラーに正しくレンダリングされるか。
5. エンティティの一貫性
自社ブランド名、代表者名、サービス名、所在地。これらの情報がWebサイト、SNS、ビジネスディレクトリ（Googleビジネスプロフィールなど）で一貫しているか。AIエンジンは複数のソースからエンティティ情報を三角測量的に検証する。不一致があれば信頼性スコアが下がる。
そしてAgent Cardの時代へ
5つの確認項目は、今すぐできることだ。
では「次にやるべきこと」は何か。それがAgent Cardの準備だ。
現時点でAgent Cardを公開する実用的な意味は薄い。Agent Cardを読みに来るクライアントエージェントがまだほとんど存在しないからだ。しかし、LangGraphやSpring AI、AWS Bedrock AgentCoreといった主要フレームワークがA2A対応を次々に実装している。A2AプロトコルはLinux Foundationのもとでオープン標準として管理されており、Google、IBM、Salesforceなどの主要企業が参画している。
「エージェントの時代」は、来るか来ないかの問題ではなく、いつ来るかの問題だ。そのとき、Agent Cardをいち早く設計できる知見を持っているかどうかが、先行者としての価値を決める。
第1回で述べた3つの判定基準を思い出してほしい。
- 自社だけでは完結しない業務があるか
- 相手に「判断」を委ねる場面があるか
- 相手の内部ロジックを知らなくても成立するか
この3つにYesと答えた業界・業種であれば、Agent Cardの設計は「将来の備え」ではなく「競争優位の源泉」になる。
自社サイトの状態を確認してみよう
ここまで読んで、「自分のサイトはどうなっているんだろう」と気になった方もいるだろう。
私たちunTypeは、AIエージェント互換性診断ツールを提供している。W3C、Schema.org、RFC 9309、llmstxt.orgの各基準に基づき、あなたのWebサイトが「AIエージェントに見つけてもらえる状態」にあるかどうかを、5カテゴリ32項目で診断する。URLを入力するだけで、数十秒で結果が出る。
診断結果をもとに、「今すぐ対応すべき項目」と「中期的に準備すべき項目」を優先度つきで確認できる。
シリーズまとめ ― AIエージェントがあなたの会社と取引する日
全5回を通じて伝えたかったことは、1つに集約できる。
Webサイトの「読み手」が変わる。
これまでWebサイトの読み手は、人間と検索エンジンのクローラーだった。これからは、AIエージェントが加わる。AIエージェントは、あなたの会社のサービスを検索し、比較し、交渉し、取引する。そのためにWebサイトが提供すべき情報の形式も変わる。
医療では、紹介状のFAXがA2Aの構造化メッセージに置き換わる未来が見えた。ECでは、AIショッピングエージェントがプロトコルスタック（A2A + UCP + AP2）を通じて購買を代行する世界を描いた。不動産では、住宅ローン審査を3行同時に並行処理できる非同期マルチエージェントの可能性を示した。
そしてこの最終回で示したのは、その未来に備えるために今できることは、驚くほど具体的で、驚くほどシンプルだということだ。
robots.txtを確認する。llms.txtを設置する。Schema.orgで構造化データを実装する。ページ構造を明確にする。エンティティの一貫性を保つ。
「AIエージェントがあなたの会社と取引する日」は、まだ来ていない。しかし、その日が来たときに「見つけてもらえる」準備は、今日から始められる。
この記事はシリーズ「AIエージェントがあなたの会社と取引する日」の最終回です。
参考情報
Agent2Agent Protocol 公式仕様 — Linux Foundation
Agent Skills & Agent Card — A2A Protocol チュートリアル
Agent Discovery, Naming, and Resolution - the Missing Pieces to A2A — Solo.io
Spring AI Agentic Patterns (Part 5): Building Interoperable Agents with the A2A Protocol — Spring Blog（2026年1月）
Developer's Guide to AI Agent Protocols — Google Developers Blog（2026年3月）
Linux Foundation Launches the Agent2Agent Protocol Project — Linux Foundation（2025年6月）
LLMs.txt: Why Brands Rely On It and Why It Doesn't Work — SE Ranking（30万ドメイン調査）
LLMs.txt for AI Search Report 2026 — ALLMO（94,000 URL分析）
llms.txt 提案 — Jeremy Howard / Answer.AI
Agentic Reasoning Protocol（ARP） — reasoning.json 公式サイト
Generative engine optimization (GEO): How to win AI mentions — Search Engine Land（2026年2月）
Generative Engine Optimization (GEO): The 2026 Guide to AI Search Visibility — LLMrefs
ChatGPT reaches 900M weekly active users — TechCrunch（2026年2月）
Cloudflare will now by default block AI bots — MIT Technology Review（2025年7月）
Introducing schema.org: Search engines come together — Google Blog（2011年6月）
RFC 8615 - Well-Known URIs — IETF
Schema.org — Google, Microsoft, Yahoo!, Yandex
この記事をシェアする
