WebMCP：Webサイトがアクションを話す時代 第4回：WebMCPがSEO/GEOを変える ― アクション可能なサイトが選ばれる時代

はじめに

第1回で「なぜ」を、第2回で「何を」を、第3回で「どうやるか」を解説してきました。ここまでの内容で、WebMCPの技術的な全体像は把握できたはずです。

第4回の今回は視点を変え、WebMCPがWebサイトの「見つけられ方」と「選ばれ方」をどう変えるのか——SEO/GEOへのインパクトを論じます。

技術SEOの第一人者Dan Petrovicが「構造化データ以来最大のテクニカルSEOの変革」と評したのは、第1回で紹介しました。今回はその意味を具体的に掘り下げます。構造化データ（Schema.org）との併用戦略、llms.txtとの役割分担、そしてトランザクショナルインテント検索で「アクション可能なサイト」が持つ圧倒的なアドバンテージを解説します。

SEOからGEO、そして「エージェンティックSEO」へ

まず、検索最適化そのものがどう変化しているかを整理しましょう。

SEO（Search Engine Optimization）は、検索エンジンにコンテンツを「見つけてもらう」ための最適化です。20年以上にわたりWebマーケティングの中核を担ってきました。

GEO（Generative Engine Optimization）は、AIが生成する回答に自社コンテンツを「引用してもらう」ための最適化です。ChatGPT、Gemini、Perplexityなどの生成AI検索が台頭する中で、2025年頃から重要性が急増しました。

そして今、WebMCPの登場によって第3の概念が浮上しています。

エージェンティックSEO——AIエージェントに「選んで使ってもらう」ための最適化です。

この3つの違いは、ユーザー（または代行するAI）の行動目的で明確に分かれます。

Brainz Digitalの分析が的確に表現しています。従来のSEOは「ページを見つけてもらう」ことに集中してきた。WebMCPが導入するのは「ページを使ってもらう」という全く異なる目的であり、サイトが「引用される」だけでなく「実行される」ことが重要になる、と。

「何であるか」×「何ができるか」— Schema.orgとWebMCPの二重レイヤー

第1回で、Schema.orgとWebMCPの関係を「記述 × 実行」と整理しました。ここではより実務的に、両者を組み合わせた戦略を掘り下げます。

Schema.org = 名詞（コンテンツの記述）

Schema.orgは、Webページの内容を機械可読にする構造化データ標準です。「これは商品です。価格は5,000万円です。所在地は渋谷区です。評価は4.5です」というように、ページ上のエンティティ（実体）を意味的に記述します。

Googleはこの情報をリッチスニペット、ナレッジパネル、商品カルーセルなどに活用しています。生成AIもまた、構造化データを持つコンテンツからより正確な回答を生成する傾向があります。

WebMCP = 動詞（アクションの公開）

WebMCPは、ページで何ができるかを公開します。「物件検索ツールがあります。エリア、価格帯、間取りをパラメータとして受け付けます」「内覧予約ツールがあります。物件ID、希望日、連絡先が必要です」というように、サイトの操作可能な機能を構造化します。

二重レイヤーの実践例：不動産サイト

Visbyがホテルの例で説明しているパターンを、不動産サイトに適用すると次のようになります。

Schema.org（記述レイヤー）で物件情報を構造化：

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "name": "渋谷区松濤 3LDK マンション",
  "price": "52,000,000",
  "priceCurrency": "JPY",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都"
  },
  "numberOfRooms": "3LDK",
  "floorSize": {
    "@type": "QuantitativeValue",
    "value": 85,
    "unitCode": "MTK"
  }
}

WebMCP（実行レイヤー）で操作を公開：

<form toolname="bookPropertyViewing" tooldescription="この物件の内覧予約を行う">
  ...
</form>

Schema.orgが「この物件は渋谷区の3LDK、5,200万円」と記述し、WebMCPが「この物件の内覧予約はこちら」とアクションを提供する。AIエージェントにとって、情報の取得と行動の実行が一つのサイト上でシームレスに完結します。

Schema.orgだけでは「読めるが操作できないサイト」、WebMCPだけでは「操作できるが何のサイトかわからない」。両方を組み合わせることで、AIエージェントにとって最も価値のあるサイトになります。

llms.txt × WebMCP — 静的ガイドと動的ツールの組み合わせ

弊社のllms.txt記事で解説したとおり、llms.txtはサイトの最も重要なコンテンツをMarkdownで一覧化し、AIクローラーに効率的なサイト理解を提供する静的ファイルです。なお、llms.txtは正式なWeb標準ではなく、コミュニティが推進するベストプラクティスとして普及が進んでいる段階です。

これにWebMCPを重ねると、3つの最適化レイヤーが完成します。

llms.txtが「地図」なら、WebMCPは「店の中のサービスカウンター」です。

llms.txtでサイトの構造と主要コンテンツをAIに伝え（「うちのサイトにはこういうページがあります」）、Schema.orgで各ページの意味的情報を記述し（「このページは渋谷区の3LDK物件の詳細です」）、WebMCPでアクションを公開する（「この物件の内覧予約はこのツールで実行できます」）。

3つを組み合わせることで、AIエージェントは「サイトを理解し」「情報を取得し」「タスクを完了する」という一連の流れをワンストップで実行できます。

Tool Descriptionは「新しいメタディスクリプション」

SEOにおいて、メタディスクリプション（<meta name="description">）が検索結果でのクリック率を左右してきたように、WebMCPのtooldescriptionはAIエージェントの「ツール選択率」を左右します。

Brainz Digitalの分析では、ツール名と説明文の品質がエージェント最適化において、タイトルタグとメタディスクリプションがオーガニック検索で果たすのと同じ役割を担う、と指摘されています。

具体例で比較しましょう。

悪い例：

toolname="submit"
tooldescription="フォームを送信する"

良い例：

toolname="searchProperties"
tooldescription="東京都内の不動産物件をエリア・価格帯・間取り・駅徒歩分数で絞り込み検索する。検索結果には物件名・価格・間取り・最寄り駅・築年数が含まれる"

AIエージェントがユーザーの「渋谷区で5,000万円以下の2LDKを探して」というリクエストを受けた場合、前者のdescriptionでは「このツールがその目的に合うかどうか」を判断できません。後者であれば、パラメータの対応関係まで含めて明確に理解できます。

これは従来のSEOにおけるコンバージョン最適化のコピーライティングと同じスキルです。明確な動詞で始め、入力パラメータの概要を示し、戻り値の内容を説明する。この原則を守るだけで、AIエージェントによるツール選択率は大きく変わります。

トランザクショナルインテント検索でのアドバンテージ

WebMCPの影響が最も顕著に表れるのが、トランザクショナルインテントの検索です。

検索意図は大きく3つに分類されます。インフォメーショナル（情報を知りたい）、ナビゲーショナル（特定のサイトに行きたい）、トランザクショナル（何かを実行したい——買いたい、予約したい、申し込みたい）。

トランザクショナルインテントの検索で、AIエージェントは「情報を集める」だけでなく「タスクを完了する」ことを求められます。ユーザーが「パリ行きの最安航空券を予約して」と依頼した場合、エージェントは検索結果を返すだけでは不十分で、実際に予約を完了しなければなりません。

このとき、WebMCP対応サイトと非対応サイトの差は決定的です。

WebMCP対応サイトでは、エージェントはsearchFlightsツールを呼び出し、構造化された結果を受け取り、bookFlightツールで予約を完了する。1つのワークフローで数秒のうちにタスクが終わります。

非対応サイトでは、エージェントはスクリーンショットを撮り、ビジョンモデルで解析し、出発地フィールドを推測し、テキストを入力し、また撮影し……という「推測の連鎖」を繰り返します。途中でUIが変わればやり直し、あるいは断念して別のサイトへ移ります。

AIエージェントは合理的に行動します。同じタスクを確実・高速・低コストで完了できるサイトを選ぶのは当然です。Visbyの分析によれば、WebMCP非対応のサイトはAI駆動の検索において不利になる傾向が強まると予想されており、特に「買う」「予約する」といったアクション指向の検索でその差は顕著になるでしょう。

Core Web Vitalsへの間接的効果

WebMCPのSEO効果は直接的なランキングシグナルとしてではなく（2026年3月時点で、GoogleはWebMCPを直接的なランキング要因とは発表していません）、間接的なUX改善を通じて現れると考えられます。

Visbyはこの間接効果について次のように分析しています。AIエージェントがWebMCPにより少ないページ遷移でタスクを完了することで、サーバー負荷が軽減され、ユーザー体験が向上する。UXはGoogleのランキング要因として重要な比重を占めるため、これもプラスに働く、と。

具体的にどういうことかを考えてみましょう。従来のスクリーンショット型エージェントは、1つのタスク完了に複数のページ遷移とDOM操作を要しました。これは結果的にサーバーへの不必要なリクエストを生みます。WebMCPでは、1回のツール呼び出しで必要なデータが返るため、ページ遷移が減り、サーバーの負荷が軽減される可能性があります。

また、エージェントがスムーズにタスクを完了できるサイトは、そのサイトを経由した取引の完了率（コンバージョン率）も高くなります。これは「ユーザーにとって価値のあるサイト」というシグナルを間接的に強化します。

先行者優位 — 構造化データの教訓

WebMCPへの対応を「まだ早い」と感じる方もいるかもしれません。しかし、歴史は「早すぎた」ケースよりも「遅すぎた」ケースの方がはるかにコストが高いことを教えています。

第1回で触れたSchema.orgの事例を振り返りましょう。Schema.orgは2011年に発表されましたが、多くの企業が「まだ早い」「効果が不明」として導入を見送りました。一方、早期に導入した企業はGoogleのリッチスニペット表示で年単位の先行者優位を獲得し、クリック率で30%以上の差をつけたケースも報告されています。

WebMCPはその再現になりえます。ThatWareの分析は、まず読み取り専用ツールから始めるべきだと提言しています。価格照会、スペック確認、ポリシー表示、出荷見積もり、在庫確認、FAQなど。これらは安全で、すぐに出荷でき、AIの回答精度を直接的に改善する、と。

レスポンシブデザインの教訓も示唆に富みます。2015年にGoogleがモバイルフレンドリーをランキング要因に追加したとき、対応済みのサイトは構造的なアドバンテージを築き、後追い組はトラフィック減少の中で慌てて対応する羽目になりました。WebMCPの「Agent-Ready」設計は、この「モバイルフレンドリー」の再来と捉えることができます。

実務者向けWebMCP × SEO/GEOアクションプラン

最後に、本記事の内容を実務に落とし込むためのアクションプランを整理します。

今すぐやるべきこと（2026年前半）

1. Schema.orgの棚卸しと強化。NLWebシリーズ（並行連載）で詳しく解説するとおり、Schema.orgの品質はWebMCP時代の基盤です。JSON-LDの実装状況を確認し、エンティティ間の相互接続（Author↔Organization、Product↔Offer等）を充実させてください。

2. llms.txtの設置。まだ設置していないサイトは、低コストの将来投資として導入を検討してください。llms.txt記事で解説した手順で実装できます。

3. Tool Contract設計の検討。第3回のStep 1で示した「ツール棚卸し」を自社サイトで実施し、公開すべきツールの候補と優先順位をリストアップしてください。

Chrome安定版での正式ロールアウトを見据えた準備（2026年後半見込み）

注： 2026年3月時点で、Googleは安定版のリリース時期を公式には発表していません。業界では2026年後半のGoogle I/OまたはGoogle Cloud Nextでの発表が有力と見られていますが、以下はその見通しに基づく準備事項です。

4. Declarative APIによるフォームのWebMCP対応。既存のHTMLフォーム（検索、問い合わせ、予約）にtoolnameとtooldescriptionを追加する。第3回のStep 2の手順に従ってステージング環境で検証してください。

5. tooldescriptionの品質最適化。メタディスクリプションのA/Bテストと同じ感覚で、AIエージェントが正しくツールを選択するかをModel Context Tool Inspectorで検証し、説明文の品質を磨いてください。

6. 監視基盤の構築。ツール呼び出しのログ記録、成功率/失敗率のトラッキング、エージェント経由のコンバージョン計測の仕組みを整備してください。

まとめ — 「読まれる」サイトから「使われる」サイトへ

WebMCPがSEO/GEOにもたらす変化を一言でまとめるなら、「発見可能性」から「実行可能性」への拡張です。

SEOは「見つけてもらう」ことを、GEOは「引用してもらう」ことを目指してきました。WebMCPは、そこに「使ってもらう」という新しい次元を加えます。

Schema.orgが「何であるか」を、llms.txtが「サイトの全体像」を、WebMCPが「何ができるか」を伝える。この3つのレイヤーが揃ったとき、Webサイトは人間にもAIにも最大限の価値を提供できる状態になります。

次回のシリーズ最終回・第5回では、WebMCPのセキュリティ設計と今後のロードマップを取り上げます。permission-firstの設計原則の詳細、ツールディスカバリーの未解決課題、そして2026年後半〜2027年の見通しをもとに、「いつ、どこまで投資すべきか」を経営判断として提示します。

参考情報

• Google Chrome Developers「WebMCP is available for early preview」（2026年2月10日）

• Visby「What is Google WebMCP? AI Agent Web Standard 2026」

• Brainz Digital「WebMCP SEO: How To Optimise Your Website For LLMs」（2026年3月）

• ThatWare「WebMCP: The Future Agent-Ready Standard for LLM SEO」

• Web Marlins「WebMCP Explained: How Google's New Protocol Will Change SEO」（2026年2月）

• AIOSEO.fr「WebMCP : what is this new standard SEO/GEO for visibility in the LLM?」（2026年3月）

• Iceberg Web Design「SEO, GEO, AIO, and WebMCP: What These Buzzwords Mean」（2026年2月）

• Digidop「Structured data: SEO and GEO optimization for AI in 2026」（2026年1月）

• Search Engine Land「Google previews WebMCP, a new protocol for AI agent interactions」（2026年2月11日）

• VentureBeat「Google Chrome ships WebMCP in early preview, turning every website into a structured tool for AI agents」（2026年2月12日）

• Incremys「Microdata for SEO: HTML5 Markup, Validation and Choosing the Right Format」（2026年2月）

この記事は「WebMCP：Webサイトがアクションを話す時代」シリーズの第4回です。

AI技術のビジネス活用やWebサイトのAIエージェント対応について、具体的なご相談はunTypeまでお気軽にお問い合わせください。