MCPの大型更新はなぜSEO業界に衝撃なのか。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業界が反応した理由は、機能の派手さではなく、仕事の工程が丸ごとつながり始めたことにあります。
参考情報
- MCP更新とSEO業界の変化に触れたX投稿
- SEO改善ループの自動化を整理したX投稿
- MCP 2026-07-28仕様の公式解説
- Google Analytics MCP Server（Experimental）
- Search Console API：Search Analytics query
- WordPress MCP Adapterの公式解説
- GitHub MCP ServerのMCP新仕様対応
- 生成AIコンテンツに関するGoogle検索のガイダンス
2026年8月2日時点の情報です。MCP対応状況、各サーバーの機能、Googleの仕様やガイダンスは更新される可能性があります。
