こんにちは。イシイ（@tomohiko_ishii）です。

先日、Xで「MCPでSEOが死ぬ」という趣旨のポストを見かけたのですが、発生源が見つけられませんでした。ひとまず、今回は生成AIに壁打ちをしてもらいながら、Model Context Protocol（MCP）を整理してみました。

ウェブマーケっぽいひとたちの周りで語られるMCPは、SEOやAIO / LLMOの話とかなり混ざっている印象です。ですが、調べていくと、この2つはそもそも扱っているものが違うことが理解できました。

MCPは「調べる」技術ではなく、「動かす」技術です。SEOやAIO / LLMOと対立する関係ではなく、順序の関係にあります。AIがまず調べて、それから何かを実行する。その「実行する」の部分を担うのがMCPです。

自分が見る限りでは、Web担当者が今やるべきことは、MCPそのものではありません。「MCPが来るから自社サイトやSEOは要らなくなる」という話にもならない、というのがこの記事の内容です。

1. MCPとは何か

AIに「使わせるツール」を渡すための共通規格です。

MCPは、AIと社内の業務システムや外部サービスをつなぐための、オープンな共通規格です。Anthropicが2024年11月に公開し、今はLinux Foundation傘下の団体で開発が続けられています。

AIは文章を書くのは得意ですが、そのままでは自社の在庫を確認したり、予約を入れたりはできません。MCPは、AIに「使わせるツール」を定義して渡すための仕組みです。

ツールに必要な要素は、4つです。「名前」「何ができるかの説明」「渡す情報」「実際の処理」。この4つがそろっていれば、AIは「このツールをこう使えばいいんだ」と判断できるようになります。

このツールはプログラムによってではなく、AIの判断で呼び出されます。「何ができるかの説明」が、そのまま実装の一部のように機能します。書かれている説明が曖昧だと、AIは変なタイミングで使ってしまったり、逆に使うべき場面で使わなかったりします。「文章の書き方がシステムの挙動を決める」というのは、面白いですね。

検索が「調べる」ための仕組みだとすれば、MCPは「動かす」ための仕組みです。この違いが、この記事全体を通じて効いてきます。

次は、直近で話題になったMCPの大きな改訂について見てみます。

2. 2026年7月28日のアップデートで何が変わったか

ローンチ以来最大の改訂ですが、Web担当者が今やることは基本ありません。

既存の接続をそのまま使っているだけなら、急いで何かする必要はないようです。開発キット側が、古い仕様との互換性を保ってくれているためです。

そのうえで、何が変わったのかですが、今回の内容に関係が深いものは2点です。

  1. つなぎっぱなしをやめました（ステートレス化）。 今までは接続を確立して維持する必要がありました。新しい仕様では、1回のリクエストに必要な情報がすべて含まれています。どのサーバーが受け取っても処理できるので、混んできたら台数を増やすだけで済みます。普通のウェブサイトと同じ増やし方です。
  2. 大量アクセスされる前提の設計になりました（ヘッダーによるルーティング）。 何度も同じ問い合わせが来ることを見込んで、一度取得した情報を使い回せる仕組みや、負荷を分散させる仕組みが組み込まれています。企業が普段使っているサーバー設備を、そのまま流用できる形です。

これらが検索部分につながっていきます。
1回の会話でツールを1〜2回呼ぶだけなら、ここまでの作り込みは必要なく、たくさんのAIが高頻度でアクセスしてくる未来を見て設計されている、とも読めます。ローカルからネットワークの流れですね。

次は、WebMCPについて整理します。名前は似ていますが、まったく別の場所で動いているものです。

3. WebMCPとは

Webページ自身が、AIに向かって「うちではこれができますよ」とツールを差し出す仕組みです。

概要

WebMCPは、W3Cで標準化を目指して議論されているドラフト仕様です。2025年8月にMicrosoft Edgeチームが提案し、Googleが共同で仕様を策定。2026年2月10日にChromeが早期プレビューを公開しました。

これまでAIにWebサイトを操作させようとすると、AIが画面を見て「このボタンはたぶんこういう意味だろう」と推測しながらクリックする必要がありました。WebMCPは、ページ側で「ホテル検索」「予約」といった機能に名前をつけて、あらかじめ宣言しておく仕組みです。AIは推測せず、宣言された機能をそのまま呼び出せます。

ポイントは、既存のフォームに属性をいくつか足すだけでも登録できることです。単純な用途なら制作会社に大きな発注をかけるような規模の話ではありません。

安全機構もあります。フォームに属性を足す方式では、AIが機能を呼び出してもブラウザが項目を埋めて送信ボタンにフォーカスを当てるところで止まり、人が内容を確認してから送る設計です。ただしサイト側が toolautosubmit 属性を付ければ自動送信も可能で、JavaScriptで登録した機能はそのまま実行されます。「人を挟む」のはあくまで既定値で、最終的な判断はサイト側の実装に委ねられています。

現状（2026年8月時点）

Chromeがオリジントライアルを実施中。Edgeは仕様の共同提案者で、Edgeチームも続報を予告していますが、正式な対応表明・出荷はまだ確認されていません。Firefox、Safariは態度を明らかにしていません。

一方、この機能を呼びに来るAIのほうは、Gemini in Chrome（Chromeに組み込まれたAI機能）が対応を表明しているという段階です。

標準としての土台は揃ったのに、使う相手（AI側）がまだいない状態です。供給側であるブラウザは進んでいるのに、需要側であるAIが追いついていません。

似た名前の2つが出てきたので、次はこの2つを並べて整理してみます。

4. MCPとWebMCPの違い

名前は似ていますが、置き換え関係ではありません。動く場所が違います。

MCP WebMCP
動く場所 サーバー側 ブラウザで開いているページの中
つなぐ手続き 人が事前に承認して接続 不要（訪問すれば見える）
対象のAI AI全般 ブラウザ内蔵のAI中心
有効な期間 接続している間ずっと そのタブを開いている間だけ

体感で一番効くのは、「タブの生存期間＝ツールの生存期間」という違いです。WebMCPで差し出されたツールは、そのタブを閉じた瞬間に見えなくなります。

もうひとつ、誤解されやすい点があります。ブラウザでChatGPTやClaudeのチャット画面を開いていても、隣のタブのWebMCPのツールは自動では見えません。チャット画面もウェブページで、他のタブの中身を読む手段を持たないからです。

ツールを受け取れるのはブラウザ本体のAIか、専用の拡張機能を入れた場合に限られます（実際、開いているタブのツールを集めてデスクトップのAIに渡す拡張機能はすでに存在します）。「WebMCPに対応すれば、すべてのAIから見えるようになる」わけではなく、橋渡し役が要る、というのが正確なところです。

ここまでで、MCPとWebMCPがそれぞれなんなのか整理できました。

次は、MCPの見つけられ方の話です。

5. MCPには、検索エンジンのような発見の仕組みがない

MCPには、検索エンジンのクロールにあたる「勝手に見つけてもらう仕組み」がありません。

検索エンジンには、クロールという仕組みがあります。ウェブサイトは見つけてもらえさえすれば、順位が10位でも、検索されるたびにクリックの可能性が生まれます。

MCPにはこれがありません。自分で用意して、人に選んで繋いでもらう。ユーザーが実際に繋ぐのはせいぜい数個から十数個で、そこに入れなければ露出はゼロです。

公式のMCPレジストリのようなカタログは存在します。AIが候補を探して提案する実装も出てきました。ただ、実際に繋ぐかどうかを決めるのは人です。AIから見えているのは、基本的に「すでに人が繋いだもの」だけになります。

MCPは、検索を迂回する近道ではなく、今時点では検索よりもさらに狭い関門をもうひとつ別に作るものだと考えたほうが正確です。

補足：ECの「発見」はデータソースの世界

商品を見つけてもらう段階で実際に使われているのは、「フィード／データソース」と呼ばれる、自社側からデータを送る仕組みです。GoogleもOpenAIも、商品データについては企業側から送るデータソースが主な経路になっています。ただしOpenAIの直接フィード連携は現時点では申請・オンボーディング制で、対応地域も段階的に拡大されています。

ここで大事な違いがあります。自社のデータベースは、自社の商品だけの世界です。一方、プラットフォーム側のインデックスは、他社の同じ商品と横並びになる棚のようなものですね。

MCPと検索エンジンの構造の違いが分かったところで、次はよくある混同を解いていきます。AIO / LLMOとMCPは、実は別の話です。

6. AIO / LLMOとMCPは、別の話

生成AIの検索が使うのは「取得」の技術で、MCPは「実行」の技術です。

生成AIの検索はMCPを見には来ない

生成AIによる検索の中核は、クエリファンアウトと呼ばれる仕組みです。1つの質問を複数の検索に分解し、並列に投げて結果を統合するというものです。分解される数は8〜12個程度とされています（Googleが公式に示した数字ではなく、外部の分析による目安です）。

問い合わせが向かう先は、MCPではなく検索のインデックス、商品のインデックス、Webページそのものです。

MCPのツールが選ばれにくい理由は3つあります。

  1. 副作用がある
    「予約する」を並列で12件同時に実行するわけにはいきません。
  2. 重い
    インデックス照会は一瞬ですが、外部システムを呼ぶツールは動作が遅く、同時に叩くと相手側が落ちてしまいます。
  3. 繋がれていない
    事前に人が繋いだ相手しか呼べません。

ファンアウトは「取得」の技術、MCPは「実行」の技術です。このことからも、Web担当者が投資すべきは、ウェブサイトの手入れと、ECであればフィード／データソースの品質であって、MCPではないと考えていて、やることは従来のSEOの延長線上です。これまでのSEO施策を続けるだけで十分で、着手しやすく発注もしやすい技術タスクを答えの位置に置かないようにするのが良いと思います。

MCPと生成AIの検索が別物だと分かったところで、次はMCPがどこまで広がっているのか、現在地の話をします。

7. MCPが普及するための条件

今MCPが機能しているのは、「使う人」と「繋ぐと決める人」が同じで、その人が技術に近い領域だけです。

いま実際に活用されているのは、大きく3つの領域です。決済やEC基盤のような開発者向けのサービス、プログラミングを補助する道具、そしてAIサービス自身が持っている情報のインフラ。どれも、使っているのはエンジニアです。

共通点はひとつだけ。自分で使う人が、自分の判断で繋いでいることです。

裏を返せば、ここが壁になります。壁は2つあります。

ひとつは、繋げる相手が限られていること。

主要なサービスなら、一覧から選んでボタンを押すだけで繋がります。ただし一覧に載っていないものは、途端に難易度が上がる。接続先のアドレスを用意し、ログイン連携を設定し、相手が安全かどうかを自分で確かめる——「繋ぐ」というより「システム連携を一本作って点検する」に近い作業です。エンジニアなら日常業務の範囲ですが、そうでない人には荷が重い。手軽に繋げるのは、AIサービス側が最初から用意してくれた相手だけです。

もうひとつは、会社では自分の判断で繋げないこと。

ChatGPTでもClaudeでも、法人向けプランでは「どのサービスと繋いでよいか」を情報システム部門などの管理者が決める仕組みになっています。データを書き換える操作は最初はオフで、管理者が個別に許可しないと使えません。情報漏洩を防ぐには当然の設計ですが、結果として、今MCPが機能している条件——使いたい人が自分で繋ぐ——が成立しなくなります。

ただし、サービス提供側の対応が遅れているわけではありません。Asana、Box、Canva、monday.com、Slack、Salesforceといった、エンジニアでなくても毎日使うサービスが対応を始めています。ツールはすでに並び始めていて、詰まっているのは繋ぐところ、という状況です。

では、何が起きれば広がるのか。3つ考えられます。

  1. AIが自分でカタログを見に行くようになること
    MCPにも、どんなサービスが繋げるかをまとめた登録簿はすでにあります。ただ、それを自動で見に行くAI側の仕組みがまだ乏しく、事実上は人が探して選んでいます。加えて「その登録簿に載っているサービスは安全だと誰が保証するのか」という問題も未解決です。
  2. そもそも繋ぐ作業が要らなくなること
    これがWebMCPの目指している方向です。ただし3章で見た通り、代わりに「タブを開いている間だけ」「橋渡し役が要る」という条件がつきます。繋ぐ手間と引き換えに、見える範囲がぐっと狭まる取引になっています。
  3. AIサービス側が、主要サービスを最初から組み込んでしまうこと
    ChatGPTでは主要なサービスが一覧から1クリックで繋がる一方、その一覧に載っていないサービスは、有料プラン限定の開発者向け機能で接続先を手入力しなければなりません。実現性は高いのですが、裏を返せば各カテゴリで1〜2社が選ばれ、そこに入れなければ存在しないのと同じという未来がそのまま見えています。

ここまでの整理を踏まえて、業種によって、MCPとどう向き合うべきかを見ていきます。

8. 業種別：どう向き合うか

判断はAIに「調べてほしい」のか、「動かしてほしい」のかで決まる。

調べてほしいだけなら、やることはMCPではなくウェブサイトの手入れです。ECであれば、それに加えてフィードの整備が必要になります。

動かしてほしいのであれば、そこで初めてMCPの話になります。ただしその場合も「どうやってそのツールを見つけてもらうか」という問いへの答えが必要です。

5カテゴリ早見表

カテゴリ AIにしてほしいこと 知ってもらう経路 やること
中小BtoBなど 調べる 検索・AIの引用 ウェブサイトの手入れ
ローカルビジネス 調べる 検索・地図（GBP） ウェブサイトの手入れ＋GBPの更新
EC 調べる 検索・商品フィード ウェブサイトの手入れ＋フィード整備
SaaS 動かす 既存顧客への告知 MCPを自作して告知
予約・独自システム 動かす 経路がない まず社内向けにMCPを自作

日本のクライアント構成では、上の2カテゴリが多数派です。つまり、大半の会社にはMCPの話をする必要がありません。

中小BtoBなど

MCP：関係ありません

部品メーカーや士業、制作会社、専門メディアなど、実店舗も商品フィードも持たない層です。AIに呼ばせる機能もなければ、送るべき商品データもありません。

やることは、ウェブサイトの手入れがほぼすべてです。独自の視点、情報の鮮度と内部構造、指名検索の獲得。5つの中で一番シンプルですが、AI専用の施策を売り込まれやすい層でもあります。

ローカルビジネス（飲食・美容室・クリニック・実店舗小売など）

MCP：関係ありません

プラットフォームに乗ることが前提の領域です。AIが参照するのは、自社サイトよりもGoogleビジネスプロフィールや地図の情報になります。

やることは3つ。プロフィールを正確に保つこと、予約や在庫をデジタル化すること、原本の情報を1箇所に決めることです。最大のリスクは新技術への未対応ではなく、臨時休業の入力を忘れることです。なおGoogleも公式に「プロフィールを最新に保て」とは書いていますが、「整備すればAI露出が増える」とは書いていません。

EC

MCP：将来的には関係しますが、急ぎません

発見の担い手はフィード、実行の担い手はMCP、という役割分担です。ただし実行部分の実用性は、まだ証明されていません。

やることは、商品データの品質と属性の充填、そして原本を1箇所に集約すること。避けたいのは、AIの中で購入まで完結する前提での投資と、海外向け規格への慌てた申請です。

SaaS

MCP：関係します

自社サービスの機能を、AIエージェントから操作できるようにする話です。ユーザーが自分のAIに指示すれば、管理画面を開かなくてもデータの取得や更新ができます。

やることは、MCPサーバーを自作して既存顧客に告知することです。5カテゴリで唯一、発見の見通しが立ちます。ただし測るべきは接続数ではなく呼ばれた回数で、「繋がれたが使われない」は普通に起きます。

予約・独自システム

MCP：作れますが、見つけてもらう経路がありません

発見の担い手が空白です。作るコストよりも、見つけてもらえる見通しが立たないことが問題になります。

やることは、まず社内向けに作って運用してみることです。発見の問題が起きないぶん投資対効果が確実で、外部公開は業界のプラットフォーム側の対応が進んでからで十分です。

業種別の整理が終わったところで、次は少し視点を変えて、検索という行動そのものがどう変わりつつあるのかを見ていきます。

9. 検索行動はどう変わりうるか

発見はAIに移りつつありますが、実行はまだです。

すでに起きたこと：ChatGPTのチャット内決済は約半年で方針転換した

OpenAIがチャット内で購入まで完結できる「Instant Checkout」を出したのが2025年9月。Walmartが約20万商品で参加したのが11月です。そして2026年3月24日、OpenAIは方針を転換しました。「初期バージョンのInstant Checkoutは我々が目指す水準の柔軟性を提供できなかった。マーチャントが自前のチェックアウトを使えるようにし、我々は商品発見に注力する」というのが公式の説明です。

Walmart社のDaniel Danker氏が2026年3月18日のWIRED記事で語ったところによると、ChatGPT内で完結した購入のコンバージョンは、同じ客をwalmart.comへ遷移させた場合の3分の1程度だったそうです。一方でChatGPT経由の新規顧客率は、検索エンジン経由と比べて約2倍だったとも報じられています。

発見は機能していて、決済が機能しなかった、ということになります。

その後、Walmartは自社のAIエージェント「Sparky」をChatGPT内に埋め込む方式に切り替えました。ログインもカートも決済もWalmartの環境で行い、ChatGPTは発見の場に徹する形です。Instant Checkoutの時より改善したと報じられています。「AIで発見し、自社サイトで買う」というパターンです。

OpenAIがチャット内決済から手を引いて発見に集中する一方、Googleは逆にAIの中での決済を推進中です。小売側も分かれていて、Gapのようにチャット内決済に踏み込む企業もあります。Shopifyのようなプラットフォームは、チャット内で販売しつつ決済は自社サイトに保てる形を用意し、事業者側が選ばなくていいようにしようとしています。

AIからの流入は「量」ではなく「質」が変わる

AIからの流入は量はまだ小さく、業種にもよりますが、多くのサイトで全流入の数%以下にとどまります。ただし質は高く、全訪問のわずか0.5%だったAI経由の流入が、サインアップ全体の12%を生んだという事例もあります。AI経由で来る人は、比較検討をチャットの中で終えた状態で着地する、という特徴があります。

10. これからのウェブサイトの役割

サイトの役割は置き換わるのではなく、仕事が一つ増えます。

AIが普及しても、ウェブサイトには集客の仕事が残り続けます。また、AI経由で流入した「もう決めてきた人」の着地先という役割が増えることになるでしょう。そこで求められるのは、説得ではなく整合です。チャットの中で見えていた価格や在庫、仕様と、実際のサイトの内容がズレていると、そこで離脱されてしまいます。

  1. AIに渡すデータと、サイトに載っている情報を一致させる
    価格、在庫、営業時間、仕様。原本をどこに置くかを決めて、そこから流すこと。ズレていると「チャットで見た内容と違う」という理由で離脱されます。
  2. ウェブサイトの手入れ
    独自の視点、情報の鮮度、明確な構造。従来のSEOの延長線上です。
  3. まっとうなHTMLを書く
    意味のある名前、適切なラベル、必須項目の明示。これらはWebMCPの下地にもなりますが、対応しなくてもアクセシビリティの改善として無駄になりません。
  4. AI経由の流入と成果を、分離して測れる状態を作る
    全体平均に混ぜず、専用のベースラインを持つこと。きれいには分けられませんが、見えている分だけでも別枠にしておけば判断を誤りません。

まとめ

今回は、MCPについて整理してみました。

MCPは「実行」のはなしで、AIO / LLMOは「取得」のはなしです。両者は対立ではなく、調べる、それから動かす、という順序の関係にあります。並べて「どちらを選ぶか」と考えると、判断を誤ってしまいます。

MCPを主語にして危機感を語るのは、今の時点ではあまりおすすめしません。やることはこれまでと変わらず、ただ、その手入れされた情報の届く先が一つ増えたという話だなと思いました。

この記事に関するご意見やご感想は、ぜひXなどで教えてください。

最後までお読みいただき、ありがとうございました。