MENU
超高機能SEOツール
SE Ranking
  1. ホーム
  2. seo
  3. WebMCPで自社サイトをAIエージェント対応にしてみた──Search Times運営のアレグロマーケティングによる先行実装事例

WebMCPで自社サイトをAIエージェント対応にしてみた──Search Times運営のアレグロマーケティングによる先行実装事例

seo
Search Times

WebMCPとは何か──AIエージェントが「使える」Webの新標準

WebMCP（Web Model Context Protocol）とは、Webサイトが自分の持つ機能──たとえば「記事検索」「申込フォームの送信」「サービス案内」など──を、ブラウザ内で動くAIエージェントに対して「ツール」として明示的に申告するためのブラウザ標準です。AIに画面の見た目から操作手順を推測させるのではなく、サイト側が「この操作は、この引数で呼んでください」と正確に宣言する点が最大の特徴です。[1]

名前の通り、WebMCPはModel Context Protocol（MCP）のWeb拡張版と位置づけられます。MCPはもともと、AIモデルが外部のデータソースやツールにアクセスする方法を標準化するために設計されたプロトコルで、サーバー側に常駐するアプリケーションをAIから操作する用途で広がってきました。WebMCPはその思想を「ブラウザ上で開かれているライブなWebページ」にまで広げ、AIエージェントがユーザーの代わりにそのページを操作できるようにする仕組みです。

従来の「人間→ブラウザ→Web操作」とい

Google Chrome 149で2026年5月19日にOrigin Trialが開始

WebMCPはGoogle・Microsoft共同でW3C Community Groupにて標準化が進められており、Chrome 149でOrigin Trial（オリジントライアル：特定のサイトが本番環境で実験機能を試せる仕組み）が2026年6月に開始されました。サイト運営者は所定のトークンをページの<head>に出力することで、訪問者のChrome上でWebMCPを有効化できます。現時点で「呼ぶ側」、つまりツールを実際に実行するAIエージェントはChromeに内蔵されたGeminiや開発者向けのInspector拡張が先行しており、ChatGPTなど他のエージェントはまだ非対応というのが正直なところです。

Googleはこの1〜2年、AIモードの段階的な展開や、コマース領域におけるUCP（Universal Commerce Protocol）、Merchant CenterのBusiness Agentなど、「AIとWebの接続レイヤー」を整える発表を立て続けに行ってきました。WebMCPはその流れの中で、特定のユースケース（商取引・広告など）に閉じず、あらゆるWebサイトとAIエージェントを汎用的につなぐ土台として位置づけられる存在です。

つまりWebMCPは、「AIに読まれるWeb」から一歩進んで、「AIに使われるWeb」を実現するための新しい標準だと言えます。本記事では、この WebMCP を弊社（アレグロマーケティング）のコーポレートサイトに実際に実装してみた一次事例を通じて、「何ができるのか」「企業サイトはどう備えるべきか」を順に解説していきます。

なぜ今WebMCPなのか──AIエージェント時代にWebが直面する課題

AI検索やAIエージェントの普及により、Webサイトに求められる役割は急速に変わりつつあります。ユーザーは検索結果を一覧で眺めて自分でクリックするのではなく、AIに「調べておいて」「申し込んでおいて」と頼む流れに移行し始めています。こうした文脈で登場したのが、ブラウザ標準としてのWebMCPです。本章では、なぜ今このような仕組みが必要とされているのか、AIエージェント時代にWebが直面している具体的な課題から整理します。

AIに求められるのは「読む」ことから「動かす」ことへ

これまでのAIのWeb活用は、ページの内容を読み取って要約・回答することが中心でした。しかし、エージェント型のAIに期待される役割はそれだけにとどまりません。具体的には、次のような“アクション”を代行することが求められ始めています。

  • サイト内検索で目的の記事や商品を探す
  • 問い合わせフォームやSEO診断依頼などのフォームに入力して送信する
  • 商品をカートに追加し、購入手続きを進める
  • アカウントにログインして必要なデータを取得する
  • 無料トライアルや資料請求の申込を完了させる

つまり、AIが扱うのは「情報」ではなく「タスク」になりつつあります。Googleが推進するAI Modeや UCP（Universal Commerce Protocol）のような取り組みも、AIがWebを介してそのままコンバージョンまで完結させる世界観を前提にしています。

人間向けに設計された従来のWebの限界

ところが、現在のWebはあくまで人間がブラウザで閲覧することを前提に作られています。AIエージェントが代わりに操作しようとすると、いくつもの壁にぶつかります。

  • 見た目から機能を推測するしかない：「申込はどのボタンか」「検索フォームはどこか」を、AIはDOMやレイアウトから推測する必要があり、誤操作のリスクが高い
  • サイトごとに構造がバラバラ：同じ「お問い合わせ」機能でも、サイトごとにHTML構造もURLも異なるため、汎用的に扱えない
  • APIが整備されていないケースが大半：外部から機械的に操作する手段がそもそも提供されていないサイトが多い
  • ログイン状態やセッションを扱いにくい：会員向けの操作は、サーバー側からはアクセスできない情報に依存する

こうした状況のままAIに操作を任せると、誤った場所をクリックしたり、意図しないフォームを送信してしまったりといった事故が起きかねません。サイト運営者から見ても、「自社サイトがAIにどう使われるか」を制御できないことは、ブランドや顧客体験のリスクになります。

標準化されたインターフェースが必要な理由

そこで求められているのが、サイト側が「自分にはこういう機能があり、こう呼び出せばよい」とAIエージェントに明示的に伝えられる、標準化されたインターフェースです。WebMCPは、まさにこの役割を担うブラウザ標準として設計されています。サイトが自らの機能を“ツール”として申告することで、AIは見た目からの推測ではなく、宣言された仕様に従って正確にアクションを実行できるようになります[1]。

サイト運営側にとってのメリットも明確です。AIに任せたい操作と任せたくない操作を切り分けられ、コンバージョン導線を「会話の中で完結させる」設計が可能になります。これは、AI検索によってクリックがAIに吸収されていく流れに対する、サイト側からの能動的な打ち手とも言えます。AEO（Answer Engine Optimization）の観点でも、「読まれる対象」から「使われる対象」へとサイトの位置づけをアップデートする必要が出てきているのです。

次章では、混同されやすいサーバー型のMCPとWebMCPの違いを整理し、それぞれがどのような場面で役立つのかを明確にしていきます。

サーバー型MCPとWebMCPの違い──「裏側のAPI」か「表のページ」か

WebMCPの話を始めると、ほぼ必ず混同されるのが「サーバー型のMCP」との違いです。名前が同じ「MCP（Model Context Protocol）」を含むため同じものに見えますが、動作する場所も、操作対象も、得意なユースケースも異なります。さらに、Google が AI Mode 周辺で打ち出している UCP（Universal Commerce Protocol）も加わり、3つのプロトコルが並走している状態です。本章では、この違いを整理します。

サーバー型MCP：バックエンドで常時稼働する「裏側のAPI窓口」

もともとの MCP は、Anthropic が2024年に公開したオープン標準で、AI モデルと外部データソース・ツールを安全につなぐためのプロトコルです[2]。一般に「MCPサーバー」と呼ばれる実装は、サーバー側プロセスとして常時稼働し、ファイル・データベース・社内システム・各種SaaSのAPIなどを“ツール”としてAIアシスタント（Claude Desktop、IDE拡張など）に提供します。

つまりサーバー型MCPは、ユーザーが画面で見ているページとは無関係に、裏側のAPIや認証情報を使ってデータを取りに行ったり書き換えたりする仕組みです。弊社が運用側で導入した WordPress 用 MCP サーバー（Automattic 公式プラグイン）も、この方式にあたります。Claude から記事の作成や更新を指示すると、ブラウザを介さずにサーバー上で WordPress の REST API を直接叩いて処理が走ります。

WebMCP：ブラウザ内エージェントが「今見ているページ」を操作する

一方のWebMCPは、ブラウザという土俵の上で動きます。サイト側が JavaScript で document.modelContext の registerTool を使い、自分の機能を“ツール”としてブラウザ内のAIエージェントに申告します[1]。エージェントは、ユーザーが今まさに開いているライブなページの文脈と、ログイン済みのセッション・Cookie をそのまま使って操作を行います。

この違いは実務上とても大きな意味を持ちます。サーバー型MCPはAPIが整備されていることが前提ですが、WebMCPは API を公開していないサービスや、UI 中心で設計されてきた既存サイトにも“AIから操作可能”な道筋を作れます。弊社サイトのように、WordPress に自作プラグインでツール定義 JS を読み込ませるだけで、検索・問い合わせ・申込といった既存機能をそのままエージェントに開放できる点が特長です。

UCPとの関係：コマースに特化した「もう一つの標準」

Google が AI Mode 周辺で進めている UCP（Universal Commerce Protocol）は、AI と商取引（在庫・カート・チェックアウト・決済）をつなぐことに特化した標準です。WebMCP が「Web 全般の操作」を扱う汎用レイヤーであるのに対し、UCP は購買体験という縦軸に深く入り込みます。実装する側から見ると、自社が EC を持つかどうか、AIエージェントに任せたいのが「情報案内・申込」なのか「購買・決済」なのかで、どのプロトコルを優先するかが変わってきます。

3つのプロトコルの違いを一枚で整理

項目サーバー型MCPWebMCPUCP
動作場所サーバー（常時稼働プロセス）ブラウザ内（表示中ページ上）Google のコマース基盤＋加盟事業者
操作対象API・DB・ファイル・社内システム今開いているライブなWebページの機能商品在庫・カート・チェックアウト・決済
認証の使い方サーバー側のトークン／APIキーユーザーのブラウザのログイン状態を活用事業者連携と決済プロバイダ経由
主な呼び出し元Claude Desktop／IDE拡張などブラウザ内蔵AI（Chrome の Gemini など）Google AI Mode／検索面のエージェント
想定ユースケース記事運用の自動化、業務システム連携サイト上での検索・申込・問い合わせ等AIによる商品比較・購入・決済
API未整備のサイトでも使えるか×（API整備が前提）○（既存UIをツール化できる）×（コマース連携の規格に従う必要）
サーバー型MCP・WebMCP・UCP の3つを、動作場所／操作対象／認証／想定呼び出し元／ユースケース／API未整備サイトでの適用可否の6軸で比較した表。読者が自社にどれを優先すべきか判断できるように整理。

整理すると、サーバー型MCPは「裏側のAPIを使った業務自動化」、WebMCPは「表のページ上での顧客接点の自動化」、UCPは「AI経由の購買体験の標準化」と役割が分かれます。3つは競合ではなく補完関係にあり、弊社のように 運用側ではサーバー型MCPで記事運用を半自動化し、公開側ではWebMCPで来訪者向けの操作を提供する という併用が、現実的な構成として有効でした。次章では、その全体像を弊社の実装に沿って具体的に見ていきます。

弊社サイトをAIエージェント対応にしてみた──実装の全体像

ここからは、弊社アレグロマーケティングが2026年6月に自社コーポレートサイト（allegro-inc.com／WordPress 構築）でWebMCPを実装した一次事例の全体像を紹介します。日本のSEO支援会社として「サイトはこれから“AIエージェントに使われる”ことを前提に設計する」という時代に備えるための先行検証です。結論から言うと、弊社の実装は「公開側」と「運用側」の2層構造で組み立てました。それぞれ目的が異なり、混同するとセキュリティ設計を誤りやすいので、まず全体像から整理します。

公開側（ブラウザ内AIエージェント←We

公開側：WebMCPでサイト機能を7つのツールとして申告

1つ目の層は、サイト訪問者のブラウザ内AIエージェントに対して、弊社サイトが持つ機能を「ツール」として明示的に申告する公開側のレイヤーです。WebMCPの命令型API（navigator.modelContext / document.modelContext の registerTool）を使い、ページ読み込み時に7つのツールを登録しています[1]。記事検索やSEO無料診断の申込、お問い合わせ送信など、サイトとして提供したいアクションを「見た目から推測させず、AIに正確に呼ばせる」のが狙いです。具体的なツール内容は次章で詳述します。

運用側：WordPress MCPサーバーをClaudeに接続

2つ目の層は、社内の編集・運用業務をAIアシスタントから半自動化するための運用側レイヤーです。Automattic公式の WordPress MCP サーバープラグインを導入し、AIアシスタント（Claude）から投稿・固定ページ・メディアを操作できるようにしました。こちらは公開側とは逆方向──AIがバックエンドのWordPress管理機能を叩く構図──で、ログイン状態の社内アカウント経由でのみ動作します。詳細な権限設計や運用上の工夫は後の章で扱います。

実装方式：自作プラグイン＋Origin Trialトークン

公開側のWebMCP実装は、弊社で自作したWordPressプラグインから行いました。プラグインの主な役割は次の2つです。

  • ツール定義をまとめたJavaScriptファイルをサイトのフロント側に読み込ませる
  • Chrome 149 の Origin Trial（先行公開試験）で発行されたトークンをページの <head> 内に <meta http-equiv="origin-trial"> として出力し、本番環境でWebMCP APIを有効化する

Origin Trial は、まだ正式仕様化されていないブラウザ機能をオリジン単位で先行的に有効化できる仕組みです[3]。テーマ側を直接いじらずプラグイン化したことで、トークンの更新やツール定義の差し替えが管理画面側で完結し、運用負荷を抑えています。

公開することによるセキュリティリスクの考え方

WebMCPで機能を「公開」するということは、不特定多数のブラウザ内AIエージェントから呼ばれうる状態を作る、ということです。実装にあたっては次の点を事前に整理しました。

  • 公開してよい操作だけをツール化する：記事検索や案内、申込フォーム送信など、本来サイト上で誰でも実行できる範囲に限定。管理系・課金系の操作は登録しない。
  • サーバー側の検証を省略しない：AIから呼ばれた場合でも、申込・送信処理は通常のフォーム同様にバリデーション・スパム対策・reCAPTCHA相当のチェックを通す前提とする。
  • 運用側（WordPress MCP）は公開しない：管理操作層は社内のClaudeからのみ接続し、削除系は許可しないなど権限を絞る。後述のとおりJWT認証で保護する。
  • CDNキャッシュとの相性：Cloudflare 経由で配信しているため、ツール定義JSやトークンを差し替えた際は明示的にキャッシュをパージする運用フローを定めた。

「AIが操作できる」ことと「何でも操作させてよい」ことは別物です。公開側はあくまでサイトが従来から人間に許してきた操作の範囲に閉じ、運用側は認証と権限で完全に閉域化する──この境界設計が、2層構造を採用したいちばんの理由でした。次章では、公開側で実際に登録した7つのツールと、その設計の狙いを具体的に見ていきます。

公開した7つのツールと設計の狙い──「会話からコンバージョン」までの導線

弊社サイトでは、WebMCPの命令型API（navigator.modelContext および document.modelContext の registerTool）を使って、合計7つのツールをブラウザ内AIエージェントに公開しました。ツールとは、サイト側が「私はこういう操作を提供できます」とエージェントに申告する関数のようなもので、名前・説明・入力パラメータを宣言しておくと、エージェントが自然言語の指示から適切なものを選んで呼び出してくれます。

設計の基本方針は明快で、「読み取り系で正確な情報提供」と「申込・遷移系で会話からそのままコンバージョン」という2系統に分けて整理しました。AIに見た目から操作を推測させるのではなく、サイト運営者自身が「ここで何をしてほしいか」を明示する考え方です。

公開した7つのツール一覧

#ツール名用途狙い
1記事検索Search Times内のSEO記事をキーワード検索し、関連記事を返す情報提供
2SE Ranking 概要案内SE Rankingがどんなツールかを要点で説明情報提供
3SE Ranking 機能別案内順位チェック／キーワード調査／競合分析／サイト監査／被リンク／AI検索可視化／レポートを機能別に案内情報提供
4会社・サービス案内アレグロマーケティングの会社概要・支援サービスを返す情報提供
5SE Ranking 無料トライアル導線無料トライアル登録ページへエージェント経由で遷移させるコンバージョン
6SEO無料診断の依頼受付会話の流れから診断依頼フォームの送信までを完結させるコンバージョン
7お問い合わせ送信名前・メール・本文を受け取り、サイトの問い合わせとして送信コンバージョン

読み取り系：AIに「正確な弊社情報」を喋らせる

ツール1〜4は、エージェントが弊社やSE Rankingについて語るときの「ソース・オブ・トゥルース」を提供する役割です。AIが自由にWebをスクレイピングして要約すると、古い情報や誤解が混ざる懸念があります。弊社が公式に申告したツール経由で答えてもらうことで、説明のブレを最小化できます。これはAEO（Answer Engine Optimization）の文脈で言われる「AIに正しく引用される設計」を、ブラウザ内エージェントのレイヤーでも実現しようという発想です。

特に記事検索ツールは、会話の中で「内部リンクの設計について書いた記事ある？」と聞かれたときに、Search Times内の該当記事を返す動きをします。SEOスターターガイド的なまとめ記事から個別トピックまで、会話の文脈に合わせて引っ張れるようにしておくと、AIに「外部サイトに行く前に弊社を経由する理由」を与えられます。

コンバージョン系：会話からそのままCVへ

ツール5〜7は、いわば「会話の終端」を担います。これまでのWebサイトでは、ユーザーがページを読み、CTAボタンを見つけ、フォームに移動し、項目を入力して送信する、という何ステップもの導線が必要でした。WebMCP対応にすると、エージェントとの会話のなかで「SEOの無料診断をお願いしたい」「問い合わせを送ってほしい」と伝えるだけで、エージェントがツールを呼び出し、必要な情報をその場で確認しながら送信まで進められます。

たとえばSE Rankingの無料トライアル導線は、エージェントが「無料で試したい」という意図を検知した瞬間に該当URLへ案内する役割を持ちます。お問い合わせ送信ツールは、入力スキーマ（名前・メール・本文）を宣言してあるため、エージェントが会話から必要項目を抽出し、ユーザー確認を経たうえで送信できます。フォーム画面のUIに依存しない、いわば「会話そのものがUI」になる導線です。

読者の自社サイトに当てはめるヒント

WebMCPの設計をこれから検討する読者には、まず「自社サイトで人間ユーザーが取る代表的なアクション」を3〜7個に棚卸ししすることをおすすめします。弊社のように情報提供系とコンバージョン系を分け、各ツールに「誰が・何のために・どんな入力で呼ぶか」を1行で書き出すと、registerToolの引数（name／description／inputSchema）に素直に落とせます。

  • 情報提供系：会社・サービス・料金・FAQ・記事検索など、AIに正確に喋らせたい内容
  • コンバージョン系：資料請求・問い合わせ・トライアル申込・予約など、会話から完結させたい行動
  • 遷移系：特定ページ（採用・事例・LP）への明示的な案内

ツール数は多ければよいというものではありません。エージェントが選択を迷わないよう、用途が被らない粒度で整理し、descriptionには「いつ呼ぶべきか」をエージェント向けに明確に書くのがコツです。弊社でも7つに絞り込む過程で、似た役割のツールを統合したり、機能別案内のように1ツールで複数トピックを返す設計にまとめ直したりしました。

情報提供系ツールとコンバージョン系ツール

運用側：WordPress MCPサーバーをClaudeに接続して記事運用を半自動化

ここまでは「公開側」、つまり訪問者のブラウザ内AIエージェントに自社サイトの機能をツールとして差し出す WebMCP の話でした。弊社（アレグロマーケティング）の今回の実装にはもう一つの層があります。それが「運用側」、社内の編集作業をAIアシスタントから動かすためのWordPress MCPサーバーです。公開側のWebMCPがエンドユーザー向けの“表の顔”だとすれば、運用側のMCPは編集部向けの“裏の作業台”にあたります。

Automattic公式プラグインをClaudeに接続

運用側で採用したのは、WordPress開発元であるAutomattic公開しているWordPress MCPサーバープラグインです。これをコーポレートサイト（allegro-inc.com）にインストールし、AIアシスタント「Claude」のデスクトップ版から MCP クライアントとして接続しました。MCP は AIモデルと外部ツールのやり取りを標準化するプロトコルで、Claude や対応クライアントなら設定ファイルにエンドポイントを書くだけでツール群を読み込めます。

接続後、Claude側からは「投稿一覧の取得」「下書きの作成」「固定ページの更新」「メディアのアップロード」「タクソノミーの操作」といった操作が、自然言語の指示そのままで呼び出せるようになります。たとえば「Search Times の最新10記事のタイトルとカテゴリを一覧化して」と話しかければ、Claude が裏でMCP経由のAPIを叩き、結果を整形して返してくれる、という流れです。

ClaudeデスクトップアプリからWor

「作成・更新は許可、削除は不許可」──権限の絞り込み

AI から CMS を操作できる、というのは便利な反面、誤操作のリスクも一気に上がります。弊社では運用にあたって、AIに渡す権限を意図的に絞り込みました。具体的には次のような方針です。

  • 許可：投稿・固定ページの作成、下書きの更新、メディアのアップロード、カテゴリやタグの参照
  • 不許可：投稿・固定ページの削除、メディアの削除、ユーザー管理、プラグイン／テーマの操作
  • 運用ルール：AIが作成・更新したコンテンツは必ず人間の編集者がレビューしてから公開ステータスに変更する

権限の制御は、WordPress側で接続用に用意した専用ユーザーのロールと、プラグイン側の機能フラグの両方で二重にかけています。AIが暴走した場合でも、最大でも「下書きが増える」「画像が増える」程度のダメージで収まる設計です。公開済みコンテンツの破壊的な変更や、サイト構造そのものに触る操作は、引き続き人間のみが行えるようにしました。

半自動化で何が変わったか

記事運用フローの中で、AI に任せやすい工程と、人間が判断すべき工程は明確に分かれます。今回の接続で弊社が特に効果を感じているのは、次のような“間の作業”です。

  • 過去記事のメタディスクリプションやタイトルタグの棚卸しし
  • カテゴリ・タグの整理や、関連記事の候補抽出
  • 新規記事の下書き投入（構成案をClaudeに渡し、下書きとしてWordPressに直接保存）
  • 画像のアップロードと alt 属性の一括チェック

従来は管理画面を行き来して数十クリックかかっていた作業が、Claudeとの対話の中で完結します。メタディスクリプションの最適化やタイトルタグの調整といった、地味だがSEO上は無視できない作業をAIと分担できるのは、編集チームにとって大きな変化でした。

公開側 WebMCP との関係

整理すると、弊社サイトには性質の異なる2つの“AI接続口”が同居している状態です。公開側の WebMCP は、訪問者のブラウザに常駐するAIエージェントに対して「サイトでできること」をツールとして差し出す仕組み。運用側のWordPress MCPサーバーは、社内の編集者が使うAIアシスタントに対して「CMSの操作権限」をツールとして差し出す仕組みです。前者はマーケティング寄り、後者はオペレーション寄りの投資ですが、どちらも「サイトをAIから扱える状態にする」という同じ思想の延長線上にあります。

もちろん、運用側もまだ実験段階です。MCPサーバー自体の仕様アップデートも頻繁で、権限設計やログ監査をどこまで作り込むかは継続課題として残っています。それでも、AI時代のCMS運用が「人間が管理画面を操作する」から「人間が方針を決め、AIが実作業を担う」へと移っていく流れは、実際に手を動かすほど強く感じます。次章では、これら公開側・運用側の両方で実際にぶつかった検証上の課題と学びを率直に共有します。

検証結果と、つまずいた・学んだこと

ここでは、弊社（アレグロマーケティング）が allegro-inc.com に WebMCP を実装した結果と、その過程で実際につまずいた点・学んだ点を、誇張せず正直に共有します。同じ実装を検討している企業のWeb担当者の方が、同じ落とし穴を踏まずに済むことを目的とした章です。

検証結果：Chrome 149で7ツールの登録をライブ確認

2026年6月の実装後、Chrome 149上で本番サイト（allegro-inc.com）にアクセスし、navigator.modelContext 配下に登録された7つのツールが正しくAIエージェントから認識されることをライブ環境で確認しました。Chrome 内蔵の Gemini からツール一覧を呼び出すと、記事検索・SEO無料診断依頼・お問い合わせ送信など、こちらが意図したとおりの名前と説明文でツールが列挙されます。[1]

本番有効化に使った Origin Trial（先行公開試験）トークンの有効期限は 2026年11月17日 です。Origin Trial は仕様策定中のブラウザ機能を本番ドメインで一時的に利用するための仕組みで、期限後は更新トークンの再発行か、正式仕様化を待つ必要があります。弊社では期限前にトークンを更新する運用に切り替え、検証を継続する予定です。

つまずいた点と対処法（実装チェックリスト）

実装は「ドキュメント通りに動いて終わり」とはいかず、WordPress＋一般的なセキュリティ・CDN構成ならではの引っかかりがいくつもありました。以下に、つまずいたポイントと弊社で取った対処法をチェックリスト形式で整理します。

  • Wordfence によって Application Password が無効化されていた：運用側の WordPress MCP サーバーから REST API を叩く際、Application Password 認証が通らず接続に失敗。セキュリティプラグイン Wordfence の既定設定で機能自体が無効化されていたためで、JWT（JSON Web Token）認証に切り替えて解消しました。セキュリティ系プラグインを入れている本番サイトでは、まず認証方式の選択肢を確認するのが安全です。
  • Cloudflare のキャッシュで変更が全訪問者に反映されない：ツール定義JSや Origin Trial トークンを <head> に出力するよう変更しても、CDN（Cloudflare）のエッジキャッシュに古いHTMLが残り、訪問者のブラウザでは旧バージョンが配信されることがありました。デプロイのたびに該当URLのキャッシュパージを行う運用に変更し、検証時はキャッシュ無効化のうえで再確認するフローを徹底しています。
  • Origin Trial トークンのドメイン指定ミス：サブドメインを含めるか否か、登録時に選んだ条件と実際の公開URLが一致していないとトークンが効きません。発行前にどのオリジンで使うかを明確にし、Chrome DevTools の Application タブでトークンが有効と認識されているかを必ず確認します。
  • 消費側エージェントが Gemini 先行で限定的：WebMCP は「サイト側がツールを申告する仕様」と「エージェント側がそれを呼ぶ実装」の両輪で成立しますが、現時点で実際にツールを呼べるのは Chrome 内蔵の Gemini と開発者向け Inspector 拡張が中心です。ChatGPT など他のAIエージェントは未対応で、エンドユーザーの利用機会はまだ限定的、という前提で投資判断する必要があります。
  • ツール説明文の粒度がエージェントの理解を左右する：registerTool で渡す説明文が抽象的だと、エージェントが「どのツールを呼ぶべきか」を誤判定しがちでした。たとえば「会社情報を案内する」より「アレグロマーケティングの会社概要・所在地・事業内容を返す」と書いた方が、想定どおりに呼ばれます。仕様上のお作法というより、プロンプト設計に近い感覚です。

学び：実験段階ゆえの「やる価値」

正直に言えば、現時点で WebMCP を実装してすぐ流入や問い合わせが増えるかというと、消費側エージェントが限定的なため大きな数値変化は期待しにくいのが実態です。一方で、ツール定義を書く過程で「自社サイトが提供している価値は結局どのアクションに集約されるのか」を言語化せざるを得ず、これは AEO（Answer Engine Optimization：AI回答最適化）やコンバージョン導線の整理にもそのまま効きます。WebサイトのSEOチェックリストを見直すきっかけにもなりました。

仕様が固まる前に触っておくことで、正式リリース時に他社より一歩早く動ける——その先行優位を取りに行く実験、というのが今回の検証の率直な位置づけです。

WebMCPはSEO/AEOにどう影響するか──「読む対象」から「操作対象」へ

ここまで読み進めてくださった方が一番気になるのは、「結局WebMCPはSEOにどう効くのか」という点だと思います。弊社（アレグロマーケティング）としても、自社サイトに実装してみる前に最も議論したのがこのテーマでした。結論から言えば、現時点でWebMCPはGoogleのランキングアルゴリズムの変更ではありません。検索順位を直接押し上げる施策ではなく、Origin Trial（先行公開試験）の段階にある実験的なブラウザ標準です。ただし、AI検索やAEO（Answer Engine Optimization：AIの回答に取り上げられる最適化）の文脈で見ると、無視できない方向性を示しているのも事実です。

直接のランキング要因ではない、が前提

まず誤解のないように整理しておきます。WebMCPに対応したからといって、Google検索の順位が即座に上がるわけではありません。Googleは「ランキングシステムへの直接影響」については現時点で何も言及しておらず、Chrome 149で始まったOrigin Trialはあくまでブラウザ内AIエージェントが安全にサイトを“操作”するための仕組みです[4]。したがって、現段階で「WebMCPを入れればSEOで有利」と断定するのは誤りです。弊社が実装したのも、順位向上を狙ったわけではなく、その先にある変化に備えるためです。

「読む対象」から「操作対象」への質的変化

では何が変わるのか。最大のポイントは、Webサイトが「読まれるもの」から「使われるもの」へと役割を変えることです。従来のSEOは、検索エンジンのクローラーにテキストを正しく解釈してもらい、ユーザーがクリックして読む流れを最適化する作業でした。一方、AIエージェントが介在する世界では、ユーザーはサイトを直接読まずに、エージェントが代理でフォームを送信したり、検索結果を要約したりします。Google AI Modeの分割ビュー導入のように、検索体験そのものがAIに伴走される設計に変わりつつある今、サイト側も「AIに操作される前提」での設計思想が求められ始めています。

AEOで効いてくる「構造化」と「アクション可能性」

AI検索やAEOの観点で、中長期的に重要性が増しそうな要素は次の3つだと弊社は考えています。

  • 構造化された情報：Schema.orgなどの構造化データに加え、ページの情報構造そのものがAIにとって解釈しやすい状態であること。リッチリザルトと構造化データの整備は、AIエージェントが「このページで何ができるか」を判断する材料にもなります。
  • アクション可能な設計：検索・申込・問い合わせなど、サイトが提供する“機能”が明確に切り出されているか。WebMCPのregisterToolはまさにこの「機能の明示化」を求めています。
  • 意味のあるHTMLとデータ整合性：見た目だけ整っていてマークアップが曖昧なページは、AIにとって扱いづらい対象になります。エージェントが誤操作しないためのセマンティックな実装が、これまで以上に評価されていく可能性があります。

これらは、WebMCPに対応していなくても従来のSEO・テクニカルSEOで「やっておくべき」とされてきた項目と大きく重なります。つまり、AIエージェント時代に向けた準備は、奇をてらった新施策ではなく、基本に忠実な設計の延長線上にあるということです。

「AIエージェントに使われる」前提でサイトを設計する時代へ

Googleは検索・AIによる概要・UCP（Universal Commerce Protocol）・Business Agent、そしてWebMCPと、AI前提のWebに向けた布石を立て続けに打っています。一連の流れが示唆しているのは、サイトが人間の閲覧だけでなく、AIエージェントによる利用も想定した“両対応”の存在になっていく未来です。

もちろんWebMCPはまだ実験段階で、消費側エージェントもChrome内蔵のGemini先行という限定的な状況です。すぐに全サイトが対応する必要はありません。ただ、SEOやAEOの担当者として「いずれ来る変化」に備える意味では、自社サイトが提供している価値を“ツール”として言語化しておく作業は、対応の有無に関わらず有益です。弊社の先行検証から見えてきたのは、WebMCP対応そのものよりも、その過程で自社サイトのコンバージョン導線や情報構造を棚卸ししできたことに、最も大きな実務的価値があったということでした。

今、企業サイトが備えておくべきこと──先行検証から見えた打ち手

WebMCPはまだ実験段階で、消費側のAIエージェントも限定的です。とはいえ「だから様子見でよい」とは言い切れません。WebMCPの設計思想を分解してみると、対応の有無に関わらず、AI検索・AEO（Answer Engine Optimization：AIの回答生成に向けた最適化）時代に効く施策が多く含まれているからです。弊社（アレグロマーケティング）の先行検証から見えた、企業サイトが今から着手できる現実的な打ち手を整理します。

「人間にもAIにも理解しやすいサイト」が共通解になる

WebMCPに対応しようとすると、結局のところ「サイトが提供している機能は何か」「どの導線で何ができるのか」を言語化し、構造として外に出す作業になります。これは検索エンジンのクローラーに対しても、AIによる概要や生成AI検索に対しても、同じ方向の最適化です。意味のあるHTML、明確な見出し階層、構造化データ、コンバージョン導線の明示──いずれも従来のSEOで推奨されてきた事項ですが、AIエージェント時代にはその重要度がさらに上がります。

特に「アクション可能な設計」という観点は、これまでのSEO文脈ではあまり語られてきませんでした。お問い合わせ、申込、検索、資料請求といった機能が、人間のクリックを前提にせず、機械的に呼び出せる形で整理されているか。これはWebMCP対応を見据える上でも、AIエージェントに引用・利用されるサイトを目指す上でも、共通して問われる観点です。[5]

今すぐ着手できるAIエージェント時代のWeb設計チェックリスト

WebMCPの実装そのものに踏み込まなくても、以下の項目はすぐに着手できます。弊社が実装プロセスで「事前にこれが整理されていれば早かった」と感じたポイントでもあります。

  • 提供機能の棚卸しし：サイトで「ユーザーが取れるアクション」を一覧化する（検索、申込、見積依頼、資料請求、問い合わせ、ログインなど）。これがWebMCPのツール定義の原型になります。
  • コンバージョン導線の言語化：各CVについて「何を入力すれば成立するか」「成立後に何が起きるか」を文章で書き出す。AIに説明できないCVは、人間にとっても分かりにくい可能性が高いです。
  • 意味のあるHTMLへの見直し：見出し階層、ボタン要素、フォームのlabel、ランドマークロールなどを、装飾ではなく意味で組み立てる。
  • 構造化データ（schema.org）の整備：Organization、Product、Service、FAQ、Article など、サイトの実態に合う型を選定して実装する。
  • 情報構造の明確化：会社概要、サービス、料金、事例、サポートといった主要カテゴリの粒度と関係性を整理し、サイトマップとパンくずに反映する。
  • 運用面のガバナンス整備：AIに何を許可し、何を禁止するか（作成は可・削除は不可、など）を社内ルール化する。これは弊社がWordPress MCPサーバーをClaudeに接続した際に痛感した点です。
  • セキュリティ・キャッシュ構成の確認：セキュリティプラグインやCDNの設定が、新しい仕様の導入を阻害しないかを事前に棚卸ししする。

「読まれる」から「使われる」への思考転換

WebMCPの本質は、サイトを「読む対象」から「操作対象」へと位置づけ直すところにあります。これまでのSEOは「いかに人間に読まれ、評価されるか」が中心でしたが、これからは「いかにAIエージェントに正しく使われ、目的を果たしてもらうか」という視点が加わります。Googleが推進するAI Mode、UCP、Business Agentといった一連の動きも、同じ方向を向いています。

弊社の先行検証で実感したのは、この移行は「全面刷新」ではなく「これまでやってきたSEOの延長線上にある積み増し」だということです。意味のあるHTML、構造化データ、明確な情報設計、言語化されたCV導線──いずれも従来から推奨されてきた施策の徹底こそが、AIエージェント時代の入り口になります。実験段階だからこそ、今のうちに足元を固めておくことが、競合との差につながると考えています。

よくある質問（FAQ）

Q. WebMCPとMCP（サーバー型）は何が違うのですか？
A. MCPはバックエンドで常時稼働し、APIを介してAIが外部ツールを操作する仕組みです。一方WebMCPはブラウザ内のAIエージェントが、ユーザーが表示中のライブなWebページ上でログイン状態などを活用しながら操作するもので、いわば『裏側のAPI』と『表のページ』の違いといえます。
Q. WebMCPはいつから使えますか？対応ブラウザは？
A. Google Chrome主導で標準化が進められており、Chrome 149からOrigin Trialが2026年6月に開始されました。現時点では実験段階で、消費側のAIエージェントもGeminiが先行している状況です。本番運用というより、先行検証として導入する位置づけが現実的です。
Q. WebMCPに対応するとSEO順位は上がりますか？
A. 現時点でWebMCPはGoogleのランキングアルゴリズムの変更ではなく、対応したからといって直接順位が上がるものではありません。ただし中長期的には、AI検索やAEOの観点で『構造化された情報』と『アクション可能な設計』の重要性が高まると考えられ、結果的にAIに選ばれやすいサイトト作りに繋がります。
Q. WordPressサイトでもWebMCPは実装できますか？
A. 可能です。アレグロマーケティングの事例では、自作プラグインでツール定義用のJavaScriptとOrigin Trialトークンを<head>に出力する方式でWordPressサイトに実装しています。加えて運用側ではAutomattic公式のWordPress MCPサーバープラグインをClaudeに接続し、記事運用の半自動化も実現しています。
Q. WebMCPを公開する際のセキュリティリスクは？
A. WebMCPで公開したツールはAIエージェントから操作可能になるため、削除や決済など影響の大きい操作を無制限に開放するとリスクになります。実装時は読み取り系と申込・遷移系に絞る、運用側のMCPサーバーでは作成・更新は許可しても削除は不許可にするなど、権限を限定した設計が重要です。
Q. WebMCPとUCPはどう違うのですか？
A. UCP（Universal Commerce Protocol）はAIとコマース（購入・決済）をつなぐ商取引特化の標準です。一方WebMCPはフォーム入力や検索、ページ遷移などを含むWeb全体の操作を対象とした、より汎用的な連携プロトコルという位置づけになります。

参考リンク

📌 Search Times を Google の「優先ソース」に追加しませんか？

優先ソースに登録すると、Google 検索や AI による要約で Search Times の最新記事が届きやすくなります。こちらから優先ソースに追加できます（数十秒で完了します）。

seo

SE Rankingの競合＆キーワード調査ツール

この記事を書いた人

野澤 洋介のアバター 野澤 洋介

SEOは考え方はシンプルですが、いざ実践するとなかなか思うようにいきません。
当ブログでは、読者の方に成功も失敗も合わせて情報を共有し、同じような悩みを解決できればという思いで運営しています。
【著書】
「分析が導く　最新SEOプラクティカルガイド」（2022年5月27日発売　技術評論社）
「最強の効果を生みだす 新しいSEOの教科書」（2017年9月20日発売　技術評論社）

>>著者情報の詳細

Search Times ブログ

企業のSEO担当者に役立つ実践的なSEOプラットフォーム活用例とプロ向けハウツー記事をご覧ください。

Search Times
閉じる