2026-07-28 の MCP (Model Context Protocol) の更新で、通常の HTTPS だけで AI エージェントが Web サイトと会話できるようになりました。Web サイトが「読まれる場所」から「AI に応える主体」へ ── その変化の大きさと、いま何が起きるかを図解で見ていきます。
そもそも MCP とは — AI が外と話すための共通規格
MCP (Model Context Protocol) は 2024-11 に発表された、AI が外部ツールやデータと通信するための標準規格です。Claude や ChatGPT といった AI が「自分の中の知識」を超えて、社内システム・SaaS・ローカルファイル・Web サイトといった外の世界にアクセスするための共通の話し方を決めています。
MCP 以前は、AI サービスごとに独自のプラグイン形式があり、同じツールを AI ごとに書き直す必要がありました。「Claude 用の GitHub 連携」と「ChatGPT 用の GitHub 連携」を別々に作り、機能追加のたびに両方をメンテナンスする ── そうした二重開発は、ツールを提供する側にとっても、AI を使う側にとっても大きな摩擦になっていました。
MCP はここに「1 回書けばどの AI からも使える」形を持ち込むことで、この二重開発を解消しています。仕様が公開されてから約 1 年半で、業務システムから個人の開発ツールまで幅広く MCP サーバーとして公開されるようになり、「AI に何を触らせるか」を各サービスが真面目に設計する時代の共通プロトコルになりました。
何が変わったか — 「重いプロトコル」から「HTTPS 一発」へ
2026-07-28 の更新の要点は一言で言うと ステートレス化 です。
Before: これまでの MCP は、AI とサーバー間で常時接続 (WebSocket 相当) を維持する前提でした。セッション管理・接続の再確立・状態同期といった、リアルタイム通信につきものの複雑さがそのまま実装のハードルになっていました。「MCP サーバー = 常駐プロセスを持つ本格インフラ」というイメージが根付いたのも、このあたりに理由があります。動作確認するだけでもプロセスを常駐させる必要があり、気軽に試せる技術ではありませんでした。
After: 更新後は、1 リクエストで完結する ステートレスな HTTPS API としても MCP サーバーを実装できるようになりました。既存の REST API とほぼ同じ粒度で書けて、常時接続の面倒は要りません。curl でも Postman でも、いつもの Web デバッグ道具でそのまま叩けます。
セッション管理・接続維持コストが実装ハードルに
従来の REST と同じ粒度で書ける
これで見えてくる未来 — Web が「読まれる場所」から「応える主体」へ
ステートレス化がもたらす一番大きな変化は、実は技術の話ではありません。Web サイトの役割が「情報が置いてある場所」から「AI に自分の口で応える主体」へと入れ替わる ── そこが本当のインパクトです。
これまで AI が Web の情報を扱おうとすると、経路はどれも「AI 側の道具で吸い上げる」ものでした。スクレイパーを走らせる、RAG の検索インデックスに突っ込む、あるいは Web の外側に別途 API を用意させる。Web サイトそのものは受け身で、そこに「載っている」だけの存在です。電話帳に住所と電話番号が書かれていても、電話帳自身は電話に出ないのと同じ関係でした。
MCP が普通の Web サイトまで降りてくると、この関係がまるごと反転します。AI は Web サイトに直接尋ね、Web サイトは自分の口で答える。 スクレイパーも中間 API も RAG インデックスも要らず、店主が電話を取って空き枠を答えるように、Web が AI と会話し始めるのです。
これは、1990 年代に Web が検索エンジンに載るようになった時と同じ規模の役割変化と言えます。当時、Web は「印刷物のオンライン版」から「検索されて訪問される情報源」に変わりました。そして今、その「訪問される情報源」から「AI に応える主体」へ、もう一段上がろうとしています。これまでのすべての Web サイトが、次は AI からの問い合わせに答える窓口になる ── これはこの 30 年で 2 回目の、Web の使われ方そのものが変わる瞬間です。
具体的には、AI に「近くの美容室を予約して」と頼めば、AI が各店舗のサイトの MCP エンドポイントに直接問い合わせて空き枠を返す。検索エンジンで一覧を眺めて選ぶのではなく、AI が代わりに調べて代わりに動く。検索ではなく AI に頼んで訪問される時代の入口が、いまここで開いたと言えます。Web サイトを持つ側から見れば「検索順位」に加えて「AI から呼ばれやすさ」を意識する時代の始まりです。
普通の Web サイトに、いま何が起きるか — 3 つの実装ポイント
とはいえ、明日いきなり全部の Web サイトが MCP 対応するわけではありません。ステートレス化はあくまで技術的なハードルを下げただけで、コンテンツをどう用意するかは Web サイトの持ち主の設計次第です。実際に「AI に読ませる Web サイト」を作るときに考えるべきことは、大きく 3 つあります。
情報の構造化
AI が読みやすい形で情報を整理する。JSON-LD / OpenGraph / schema.org といった既存の SEO 資産がそのまま MCP の応答にも使えます。検索エンジン向けの構造化データが、AI 向けにも生きる時代です。
公開範囲の線引き
AI に公開する情報と、しない情報を明確に区別する。認証必須の領域や商用データは、MCP 経由でも同じ認証境界の中に置く。「AI からも見える」ことを前提に情報設計を見直す必要があります。
制作時の検討
コンテンツ設計の段階で「AI エージェントが使う可能性」を織り込む。すべてを API 化する必要はなく、Web の情報構造自体を整えることが入口の準備になります。
Web 制作会社にとっては、これまでの「SEO・アクセシビリティ・パフォーマンス」に続く 4 つ目の視点として「AI 対応」が加わる、と考えるとイメージしやすいでしょう。
まとめ — 静かだが、Web の役割が変わる更新
ステートレス化そのものは技術的には派手ではありません。派手な新機能でもなく、AI モデルの精度が上がる話でもありません。それでもこの一手は、Web を「読まれる場所」から「AI に応える主体」へ引き上げる 転換点になりました。役割変化としては、Web に検索エンジンが来た時と同じ規模の話です。
実装ハードルが下がったいま、コンテンツを AI にどう応答させるかを考える姿勢が、Web サイト設計の当たり前の一部になっていきます。次にサイトを作り直すときには、SEO と同じくらい自然に「AI 対応」の話が並ぶ ── そんな未来がすぐそこまで来ています。