MCPの大型更新はなぜSEO業界に衝撃なのか。AIが検索データから改善まで回す仕組み

2026年8月2日更新日: 2026年8月2日AIコラム

先日、AIと外部サービスをつなぐ共通規格「MCP」の大型アップデートについて、「ClaudeのMCPがステートレス化。2026年7月28日の大規模更新で何が変わる？」という記事を書きました。

そのとき筆者が注目したのは、MCPサーバーを混雑に強くし、大規模に運用しやすくする「ステートレス化」でした。普段Claudeを使うだけなら、今すぐ設定を変える必要はない。そう結論づけています。

ところが数日後、Xで「SEO業界の仕事や単価を変えるほどの出来事」「大企業はすでに動いている」という趣旨の投稿を見かけました。正直に言うと、投稿を読んだ直後も、なぜMCPの通信方式が変わるとSEO業界に衝撃が走るのか、うまくつながりませんでした。

公式資料と、すでに公開されているGoogle Analytics・Search Console・WordPress・GitHubの仕組みを並べ直すと、ようやく全体像が見えてきました。

今回のMCP更新でSEO機能が追加されたわけではありません。大きいのは、検索データの取得、課題の発見、サイトの修正、効果測定をAIが繰り返すための「配管」が、実験用から本番運用向けへ一段進んだことです。

Xの投稿が指していた「SEOの大変化」とは

きっかけになったのは、次の2つの投稿です。

1つ目の投稿は、MCP更新を取り上げた記事を示しながら、SEO業界に大きな変化が起きる可能性と、一部の企業がすでに動いているという見方を紹介しています。

2つ目の投稿は、変化をもう少し具体的に説明しています。AIが検索データを監視し、課題を見つけ、サイトを修正し、結果を測り、さらに改善する。この一連の流れを自律的に回すための部品がそろった、という見立てです。

ここで分けて考えたいのは、MCPの仕様変更は確認できる事実ですが、「SEOの仕事が小さくなる」「業務単価が崩れる」といった部分は、そこから導かれた予測だということです。影響を過小評価する必要はありませんが、未来予測まで確定事項として読むと話が大きくなりすぎます。

SEOの改善ループを構成する部品は、すでに存在する

従来のSEO業務を単純化すると、次のような循環になります。

計測 → 課題発見 → 改善案の作成 → サイト修正 → 再計測 → 次の改善

これまでも各工程を自動化するツールはありました。MCPが変えるのは、別々だった道具を、AIが同じ会話やワークフローから呼び出しやすくする点です。

工程	使える仕組みの例	AIが担えること
計測	Google Analytics MCP、Search Console API	アクセス数、検索クリック、表示回数、CTR、平均掲載順位などを取得する
課題発見	ClaudeやCodexなどのAIエージェント	前期間と比較し、落ちた記事や改善候補を抽出する
修正	WordPress MCP Adapter、GitHub MCP Server	記事の下書き、コード変更、修正案のPull Requestなどを作る
確認	MCPの承認フロー、レビュー、権限管理	公開前に人へ確認を求め、許可された操作だけを実行する
再計測	外部スケジューラー、MCP Tasks、分析ツール	一定期間後に同じ指標を取得し、変更前後を比較する

Google Analyticsには、Google Analytics Data APIをAIから使うための実験的なMCPサーバーが公開されています。筆者も以前、Google Analytics MCPでアクセス解析をAIに頼む方法を記事にしました。これは上の表でいう「計測」の部品です。

Google Search Consoleにも公式APIがあり、検索クエリやページごとのクリック数・表示回数・CTR・平均掲載順位を取得できます。Search Console用の接続部分を用意すれば、「表示回数は多いのにCTRが低いページ」などをAIが探せます。

修正側では、WordPress公式のMCP Adapterが、WordPressの機能をMCPの道具として公開する仕組みを提供しています。Gitで管理しているサイトなら、GitHub MCP Serverを通じてコードを調べたり、変更案を作ったりする方法もあります。

つまり、データを読む道具と、サイトを書き換える道具は別々に登場していました。中央にいるAIエージェントが両方を使えば、改善の輪を閉じられます。

7月28日のMCP更新が重要だった3つの理由

では、なぜ以前から存在する部品が、2026年7月28日の更新で急に注目されたのでしょうか。

1. ステートレス化で、多人数向けに動かしやすくなった

MCP 2026-07-28では、通信ごとに必要な情報を含める「ステートレス」が中核になりました。どのサーバーが依頼を受けても処理しやすいため、通常のWebサービスのように台数を増やし、負荷を分散できます。

1人のパソコンで動く試作品と、複数部署・複数サイトで毎日動く仕組みでは、必要な安定性が違います。今回の変更は、SEOの新技術というより、AIエージェントを会社の業務へ組み込みやすくする基盤整備です。

2. 認証・ルーティング・キャッシュが本番運用向けになった

新仕様では、通信の行き先を振り分けるためのHTTPヘッダー、道具一覧のキャッシュ、認証の強化なども盛り込まれました。企業が気にする「誰が、どの道具を、どの権限で使ったか」を管理しやすい方向へ進んでいます。

SEOの自動化で怖いのは、AIの分析が外れることだけではありません。権限を持ちすぎたAIが、大量の記事やサイト全体のテンプレートを一度に変えてしまうことです。接続が標準化され、認証や承認を設計しやすくなることは、実運用にとって重要です。

3. 長い処理と途中確認を扱いやすくなった

新仕様では、時間のかかる処理を扱うTasksが正式な拡張になり、処理の途中で利用者へ確認を求める仕組みもステートレスな通信に合わせて見直されました。

ただし、MCP Tasksは「毎週月曜日にSEOを実行する予約機能」ではありません。定期実行には別のスケジューラーやワークフロー管理が必要です。MCPは、長い作業や途中承認をAIと外部サービスの間で受け渡しやすくする役割を担います。

「AIが自走学習する」は、モデルの再学習とは限らない

Xの投稿には「自走学習」という表現も出てきます。この言葉は、AIモデル自体がSEOの結果を学習し、内部の重みを書き換えるようにも聞こえます。

実際に組みやすくなったのは、もっと実務的な自律改善ループです。AIが前回の仮説・変更内容・結果を記録し、次回の判断材料として読み直します。モデルそのものを再学習させなくても、履歴を参照しながら次の行動を変えられます。

例えば、次のような流れです。

Search Consoleから、表示回数が多くCTRが低い記事を探す
AIが検索意図と本文を確認し、タイトル変更の仮説を作る
WordPressには公開せず、変更を下書きとして保存する
人が内容とブランド表現を確認して公開する
一定期間後に同じ指標を測り、維持・修正・元に戻すを判断する
結果と判断理由を記録し、次の記事選びに使う

これは十分に強力ですが、「AIが勝手に賢くなり、検索順位を上げ続ける装置」ではありません。良い目標、正しいデータ、変更履歴、安全な権限がそろって初めて機能します。

SEOの仕事は、どこまで置き換わるのか

影響を受けやすいのは、手順が決まっていて、結果を数値で確認しやすい作業です。

定例レポートの作成
アクセスや検索流入が落ちたページの抽出
タイトル・メタディスクリプションの改善候補作り
内部リンク切れや構造上の問題の洗い出し
修正案の下書きやPull Request作成
変更前後の数値比較と報告

これらを人が管理画面から拾い、表計算へ移し、報告書へ整える時間は減っていくはずです。作業時間を積み上げて決めていた料金には、下落圧力がかかる可能性があります。X投稿が「効率化ではなく、業務内容と単価の変化」と表現した理由はここにあります。

一方で、SEOの仕事全体がなくなるとまでは言えません。価値が移るのは、次のような判断です。

売上・問い合わせ・読者満足のどれを目的にするか決める
数字の変化から、検証できる仮説を作る
検索意図だけでなく、ブランドや専門性を守る
アルゴリズム更新、季節性、競合の動きと自社変更を切り分ける
AIに任せる範囲と、人が承認する範囲を設計する

「データを集めて直す人」より、「何を良い結果とするか決め、AIの行動を評価できる人」の価値が高くなる。現時点では、その見方のほうが現実的です。

まだ完全自動運転にしないほうがよい理由

検索データには遅れと欠落がある

Search Consoleの新しいデータには、収集・処理中の不完全な値が含まれることがあります。また、APIが返すのは条件に合うすべてのデータとは限らず、上位の行が中心です。見えている数字だけを完全な事実としてAIに渡すと、判断を誤る可能性があります。

変更と結果の因果関係を証明しにくい

タイトルを変えた翌週にクリックが増えても、変更だけが理由とは限りません。ニュース、季節、競合サイト、Googleの更新なども同時に動きます。AIが多くのページを一度に直すほど、何が効いたのか分からなくなります。

測りやすい数字だけを追いかけやすい

CTRを目標にすると、AIはクリックされやすい強い表現へ寄せるかもしれません。しかし、記事内容と合わないタイトルでクリックを集めれば、読者の信頼を失います。順位やPVが上がっても、問い合わせや売上が下がることもあります。

大量修正はスパムと事故の両方につながる

Googleは、生成AIを調査や独自コンテンツの構成に使うこと自体は有用としつつ、利用者への価値を加えず大量のページを生成する行為は、スパムポリシーに違反する可能性があると案内しています。

WordPress公式のMCP Adapter解説も、本番では専用ユーザーと最小権限を使い、インターネットへ公開する機能は読み取り専用から始め、操作を記録するよう勧めています。技術的に自動公開できることと、自動公開すべきことは別です。

個人サイトなら、まず「読み取り専用の半自動」から試す

筆者がAIじてんで試すなら、最初からサイトを自動修正させません。まずはGoogle Analytics MCPなどを読み取り専用でつなぎ、次のように頼みます。

直近28日と、その前の28日を比較し、アクセスが大きく落ちた記事を5件挙げてください。データで確認できる事実と推測を分け、まだ記事は変更しないでください。

Search Consoleのデータも扱えるようにしたら、クリック数・表示回数・CTR・平均掲載順位を加えます。そのうえで、候補のうち少数の記事だけを人が選び、AIには「仮説」「変更案」「判定に使う指標」「再確認する日」をセットで作らせます。

実際の変更も、最初は公開ではなくWordPressの下書きかGitHubのPull Requestまで。人が差分を読み、1つの仮説につき変更を絞り、元へ戻せる記録を残します。これなら、AIの速度を借りながら、サイト全体を実験台にせずに済みます。

前回の記事で見落としていたのは「二次的な影響」だった

前回の記事で「普段Claudeを使う人が、今日すぐ設定を変えるニュースではない」と書いたことは、今も間違いではないと思っています。利用者の画面に突然SEO自動化ボタンが現れたわけではありません。

見落としていたのは、その先です。MCPサーバーを安定して増やせること、企業の認証やルーティングに載せやすいこと、長い仕事や途中承認を扱いやすいこと。これらは単体では地味でも、すでにある分析・編集の道具と組み合わさると、継続的な改善業務をAIへ渡す土台になります。

MCP 2026-07-28は、SEOを自動化した更新ではありません。しかし、「人が各ツールの間を移動して回していた仕事」を、AIエージェントが一つの流れとして扱う現実味を大きくした更新です。SEO業界が反応した理由は、機能の派手さではなく、仕事の工程が丸ごとつながり始めたことにあります。

参考情報

2026年8月2日時点の情報です。MCP対応状況、各サーバーの機能、Googleの仕様やガイダンスは更新される可能性があります。