「7月28日のMCP更新でAIの自律SEOが現実になった」は本当か
「7月28日のMCP更新でAIの自律SEOが現実になった」は本当か
X(Twitter)で、「7月28日のMCPの更新を含む一連のアップデートで、AIが検索データを監視して課題発見、サイト修正、効果検証、再改善まで自律的に回し続けることが現実になってきた」という趣旨の投稿を見かけた。 サイトを運営する身としては聞き流せない話だが、投稿だけでは「7月28日のMCPの更新」が何を指すのか分からない。 そこで一次情報を確認した。
先に確認結果をまとめる。
- 「7月28日のMCP更新」は実在する。MCP仕様の新リビジョン「2026-07-28」がこの日に安定版として公開され、Anthropicも同日にClaude製品群への導入を発表した
- ただし中身はエージェント基盤の土台工事であり、SEOに固有の機能の発表ではない
- 検索データの監視から再改善までのループは、部品を組み合わせれば今日でも構築できる。ただしGoogle Search Consoleの公式MCPサーバーは存在せず、Googleが提供するのは読み取りAPIまでで、実態は「自律」よりも「半自動」に近い
- 同種のループの実践報告は7月28日より前からXにある。「この更新で現実になった」は投稿者の解釈であり、元Google検索品質チームの専門家からは「飛躍しすぎ」という反論も出ている
言説の出どころ
調べていくと、発端のポストを特定できた。 8月1日の@hassii_adのポストである。 7月31日の「SEO業界大変化が起こりそう」という投稿を引用し、AIが検索データを監視して課題発見、サイト修正、効果検証、再改善まで自律的に回し続けることが現実になった、という解釈を示したものである。 取得時点の表示回数は約8.7万だった。 投稿者は、一連のアップデートでそのための部品が揃ったとして、今夏でSEO事業から撤退するとまで表明している。
これに対して8月4日、元Google検索品質チームの長山一石氏が「MCPの新specでSEO死亡!みたいなポストが拡散されてるけど飛躍しすぎ」と反論した。 SEOは死なず、サイト外の評価に比重が移るだけだという実務家の整理も出ており、反応は二分されている。
もう1つ、言説の位置づけを考えるうえで見逃せない事実がある。 Google AnalyticsとSearch ConsoleをClaude Codeにつないで毎日自動で改善を回しているという実践報告が、7月6日や7月17日の時点で既にXへ投稿されていたことである。 つまり監視から改善までのループ自体は、7月28日の更新を待たずに回っていた。 では7月28日に何が変わったのか。 更新の中身を見る。
7月28日に更新されたのは何か
MCP(Model Context Protocol) は、AIエージェントを外部のデータやツールへ接続するための標準規格である。 2026年7月28日、この仕様の新リビジョン「2026-07-28」が安定版として公開された。
公式のchangelogによると、改訂の柱は2つある。
1つ目はプロトコルのステートレス化である。
従来のinitializeハンドシェイクとセッションIDを廃止し、単純なリクエストとレスポンスのやりとりに移行した。
これでMCPサーバーをサーバーレスやエッジ環境へ置けるようになり、多数のエージェントが常時接続する運用を支えやすくなった。
2つ目はTasksの公式エクステンション昇格である。
実験扱いだった長時間実行タスクの仕組みが io.modelcontextprotocol/tasks として標準化された。
エージェントが時間のかかる処理をポーリングで追跡し、完了まで見届けるための規格で、AWSが仕様策定に加わった。
ほかに、会話内でコネクタがUIを描画するMCP Appsの標準化、OAuth認可まわりの変更などが入っている。
同じ日、AnthropicがBringing MCP 2026-07-28 to Claudeを発表し、この仕様をClaude製品群へ導入すると告知した。 発表には、Claudeのディレクトリに登録されたMCPサーバーが950超、MCP SDKのダウンロードが月間4億超という数字も出てくる。
つまり7月28日に起きたのは、AIが外部データへ常時接続して長時間働き続けるための「配管の標準化」である。 SEOに固有の機能は何も発表されていない。
同じ週に重なったGoogle側の動き
では、なぜこの話がSEOの文脈で語られたのか。 関連する出来事がこの前後の1週間に集中しており、これが背景にあると私は推測している。
まず7月24日、AnthropicがClaude Opus 5をリリースし、長時間の自律実行に耐えるモデルの側も更新された。
翌週の7月29日には、Google側の出来事が2つ重なった。
1つは、Google Search Consoleの「Platform properties」の全世界展開である。 Instagram、TikTok、X、YouTube上のコンテンツがGoogle検索とDiscoverでどう見られているかを把握できる新しいプロパティ種別で、検索データの計測対象が自サイトの外まで広がった。 ただし、この機能のAPIやMCPでの提供は発表されていない。
もう1つは、Google Analytics公式MCPサーバーのv0.7.0リリースである。 中身は依存関係の更新が主だが、READMEに「Claude Codeでのセットアップ」の節が追加された。 GoogleがAIエージェントからの利用経路を公式ドキュメントで案内し始めたという意味で、小さいが象徴的な変更である。
エージェント基盤の大改訂と、検索データ側の話題が同じ週に固まって流れた。 「MCPの更新でAIによる検索データの監視が現実になった」という言説は、この重なりから生まれたと見るのが自然だと思う。
Search ConsoleのMCP対応の実情
いちばん誤解されやすいのがここである。
Googleは2026年4月のCloud Next '26で、BigQueryやCloud Run、Workspaceなど50超のGoogle管理MCPサーバーを発表している。 Search Consoleはそのリストに含まれていない。 Google Analyticsに公式MCPサーバーがあるため「Search Consoleにもあるはず」という誤解が広がっている、と指摘する検証記事が7月17日に出ており、私が確認した8月4日時点でも反証は見つからなかった。
実在するのは、Search Console APIを包んだコミュニティ製MCPサーバー群である。 AIにSearch Consoleのデータを読ませること自体は今日でもできるが、それはGoogleが公式に開いた経路ではなく、非公式ラッパー経由になる。 公式のGoogle Analytics MCPサーバーも、読み取り専用のExperimental(実験的)扱いである。
SEOツールベンダーはGoogleより先行している。 AhrefsとSemrushは公式のリモートMCPサーバーを提供済みで、DataForSEOもMCPに対応している。 ただしいずれも7月末の新発表ではなく、それ以前から動いているものである。
監視から再改善まで、各段の現在地
冒頭の言説を段ごとに分解して、2026年8月4日時点で使える部品と限界を整理する。
| 段 | 使える部品 | 現在地 |
|---|---|---|
| 監視(検索データの取得) | Google Analytics公式MCP、Search Console API+非公式MCP、Ahrefs/Semrush/DataForSEOの公式MCP | 読み取りの部品は揃っている |
| 課題発見 | エージェントによるデータ分析 | 技術的には可能。抽出の質は指示の設計次第 |
| サイト修正 | コーディングエージェントがリポジトリを編集してデプロイ | 技術的には可能。無審査の自動修正は事故のもと |
| 効果検証 | 監視と同じ読み取り経路の再実行 | 順位への反映に数週間かかり、アルゴリズム更新の影響と切り分けにくい |
| 常駐(回し続ける) | スケジュール実行機能、MCPのTasksエクステンション | 部品は揃い、7月28日の改訂で土台が固まった |
表のとおり、Googleが提供しているのは監視の読み取りまでである。 課題発見の質、修正の妥当性、効果の因果判断は依然としてエージェント側、最終的には人間の仕事として残る。 特に効果検証は、施策の結果が順位に出るまで数週間かかるうえ、同時期のアルゴリズム更新の影響と切り分けにくい。
ループを回し続けるためのスケジュール実行そのものも、7月28日の新機能ではない。 Claude Codeのスケジュール実行(Routines)は2026年4月に、cron指定で動くManaged Agentsは同年6月にベータとして出ている。
「自律的に回し続ける」の今日の実態は、スケジュール実行される半自動ループに要所の人間レビューを挟んだものと理解するのが正確だと思う。
このサイトのSEO運用にどう取り込むか
このサイト(eurekapu.com)は1,000本超の記事を静的生成で配信しており、記事の作成から修正、デプロイまでをClaude Codeで回している。 ループの後半、修正から配信までは既に手元にある。 足りないのは入口、つまり検索データの取り込みである。
現実的な設計はこうなる。
- Search Console APIから検索アナリティクス(クエリ、表示回数、CTR、掲載順位)を週次で取得する
- 表示回数が多いのにCTRが低いページと、順位が下落したページをエージェントに抽出させ、タイトルやdescription、内部リンク、本文追記の改善案を出させる
- 改善案を人間がレビューし、通ったものだけを修正としてコミット、デプロイする
- 数週間後に同じデータを取得し、差分を見る
全段を無人化しないのは、修正の無審査自動化が事故のもとだからであり、効果の因果が弱いまま再改善を自動で積むと、根拠のない書き換えが記事に蓄積していくからでもある。
追記(同日): この4ステップのうち、データ取得と分析のスクリプトは記事の公開後に実装した。 残っているのはSearch Console APIの初回認証だけである。
冒頭の言説に戻る。 「現実になってきた」は方向として正しい。 ただしそれは、7月28日に何かが解禁されたからではない。 実践のループは改訂前から回っていた。 読み取りのMCPサーバー、コーディングエージェント、スケジュール実行という部品がこの1年で順に揃い、7月28日の仕様改訂がその土台を固めた、というのが確認できた実態である。
参考リンク
- 発端のポスト (@hassii_ad, 2026-08-01)
- 長山一石氏の反論ポスト (2026-08-04)
- Publickey: MCP 2026-07-28 改訂の解説
- gihyo.jp: MCP仕様 2026-07-28 の解説
- GIGAZINE: MCP 2026-07-28 リリース報道
- MCP仕様 2026-07-28 changelog
- MCP公式ブログ: 2026-07-28リリース告知
- Anthropic: Bringing MCP 2026-07-28 to Claude
- Google Search Central Blog: Platform properties
- Google Analytics公式MCPサーバー (GitHub)
- Google Cloud: Google管理MCPサーバーの一般提供
- Search Consoleの公式MCPは存在しないことの検証記事 (usecarly.com)
- コミュニティ製Search Console MCPサーバーの例 (mcp-gsc)
- Ahrefs: MCPサーバー解説
- Semrush MCP ドキュメント