2026年8月スパムアップデート開始！Google検索への影響と対策を解説
Googleが2026年8月18日、8月のスパムアップデートの展開を開始した。全言語・全地域が対象で、完了までに数日かかる見込みだ。Search Status Dashboardにランキングへ影響を与えるインシデントとして記録されている。
これは2026年に入って3回目のスパムアップデートとなる。3月の更新は過去最速の19時間30分で完了し、6月の更新は生成AI検索への操作対策もスパムポリシーの対象に含める方針が示された直後に行われた。
検索順位に動きが出た場合、スパムポリシー違反がないか確認することが重要になる。復旧には数ヶ月かかることもあるため、早期の対応が求められる。
8月スパムアップデートの概要
今回のアップデートは太平洋時間8月18日午前9時27分に開始された。日本時間では8月19日午前1時27分となる。Search Status Dashboardには開始時刻の約1分後、午前9時28分にリリースノートが掲載された。
適用範囲は全世界・全言語だ。Googleは完了までに数日かかる可能性があると案内している。この種のアップデートは、展開中に順位の変動が大きくなることがある。短期間のデータだけで判断せず、数日単位で傾向を見る必要がある。
公開時点では、Search Status Dashboardの注記に加えて公式ブログ記事は投稿されていない。スパムアップデートの概要ページも2025年12月から変更されていない。今回は新しいスパムポリシーの種類は追加されていない。既存のポリシーがそのまま判断基準になる。
このデモは8月スパムアップデートの展開フローを示している。各ステップの色分けは進行段階を表しており、青が開始、緑が適用範囲、橙が展開期間、紫が完了通知を意味する。
2026年のスパムアップデート史
2026年はスパムアップデートが立て続けに実施されている。8月の更新は3回目だ。過去2回の傾向を把握しておくと、今回の展開期間や影響範囲を推測しやすくなる。
3月の更新は過去最速で完了
3月のスパムアップデートは19時間30分で完了した。これはSearch Status Dashboardの記録上、確認済みの展開としては最速だった。展開期間が短いほど、順位変動も短期間に集中しやすい。
6月の更新は生成AI検索の操作対策も対象に
6月のスパムアップデートは2日と1時間かけて完了した。その前月の5月15日には、GoogleのスパムポリシーがAI OverviewsやAI Modeなど、生成AI検索の結果を操作しようとする試みにも適用されるという方針が明確化されている。6月の更新がこの種の操作を具体的に狙ったものかどうかは、Googleから公式な説明はない。
8月の更新についても、生成AI検索の操作を特に標的にしているかどうかは明らかにされていない。ただし、スパムポリシーは検索結果全般に適用されるため、生成AI検索への操作も対象範囲に含まれると考えるのが自然だ。
このデモは2026年に実施された3回のスパムアップデートを比較したものだ。青が3月、緑が6月、橙が8月を表す。完了までの時間が回を追うごとに長くなる傾向が見える。
サイト運営者が取るべき行動
スパムアップデートの展開中は、検索順位が一時的に変動することがある。1日だけのデータで判断せず、Search Consoleのデータを数日分確認するのが基本だ。特に8月18日以降の動きに注目する必要がある。
Search Consoleで順位変動を確認する
順位の変動を確認するには、Search Consoleのパフォーマンスレポートが最も信頼できる。表示回数・クリック数・平均掲載順位を日別で確認し、8月18日以降に急激な変化が出ていないかを見る。
もし変動が見つかったら、それがスパムアップデートの影響なのか、他の要因によるものなのかを切り分ける必要がある。季節要因や自サイトの変更、競合サイトの動きなども同時に確認することだ。
このデモはSearch Consoleを使った確認手順を示している。青から紫への色分けは、各ステップの進行順を表す。
スパムポリシーの見直しが復旧の最短経路
順位が大きく下がった場合、Googleのスパムポリシーに違反していないかを見直す必要がある。主なポリシーには、クローキング、隠しテキスト、リンクスパム、キーワードの乱用、ユーザー生成スパムなどがある。自サイトが該当する可能性がないか、コンテンツとリンクの両面から確認する。
Googleの公式ドキュメントによると、スパムポリシー違反からの復旧には数ヶ月かかることがある。自動化されたシステムが、サイトがルールに従うようになったことを認識するまでに時間が必要なためだ。違反を修正しても、すぐに順位が戻るわけではないことを理解しておく必要がある。
このデモはGoogleのスパムポリシーで代表的な違反の種類を示している。赤い左線が注意を促す配色だ。
今後の展開と監視ポイント
Googleはアップデートの展開が完了すると、Search Status Dashboardに完了記録を掲載する。3月は19時間30分、6月は2日と1時間で完了しており、今回も同様に記録される見込みだ。
サイト運営者としては、完了通知が出るまでの間、Search Consoleのデータを注視するのが現実的な対応になる。特に8月18日以降の表示回数と平均掲載順位の推移を数日分まとめて確認し、変動の傾向を掴むことだ。
Search Engine JournalはGoogleが完了を確認次第、続報を伝えるとしている。今回のアップデートで新たなスパムポリシーが追加されたり、特定のスパム手法が集中的に取り締まられたりした場合は、その情報も出てくるだろう。
この記事のポイント
- 8月スパムアップデートは2026年8月18日に開始、全言語・全地域が対象
- 今年3回目のスパムアップデートで、新ポリシーの追加はなし
- 完了までに数日かかる見込みで、完了後にSearch Status Dashboardで通知される
- 順位変動があればSearch Consoleで8月18日以降のデータを確認する
- スパムポリシー違反からの復旧には数ヶ月かかることがある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google広告が検索キャンペーンの言語ターゲティング設定を廃止。9月下旬から順次適用
Google広告が2026年9月下旬から、検索キャンペーンとP-MAX（パフォーマンスマックス）の検索枠におけるキャンペーンレベルの言語ターゲティング設定を廃止する。広告文とランディングページの言語が配信判断の主な基準となり、GoogleのAIによる言語理解がより大きな役割を担う。
この変更により、多言語キャンペーンの運用方法が変わる。既存キャンペーンの再構築は不要だが、規制業界の広告主には配信実績の文書化という未解決の課題が残る。
本記事では、言語ターゲティング廃止の具体的な内容、Googleの判定ロジック、広告主が取るべき対応を解説する。
言語ターゲティングで何が変わるのか
現行の仕組みと変更後
現在のGoogle広告では、キャンペーン設定で広告主が1つ以上の言語を選択する仕組みだ。同時にGoogleは検索クエリ、ユーザー設定、その他のAI由来のシグナルを基に、ユーザーが理解する言語を独自に判定している。この2つの条件が重なったときにだけ検索広告が配信される。
9月下旬以降、キャンペーンレベルの言語設定が検索キャンペーンから削除される。代わりにGoogleは広告クリエイティブとランディングページの言語、およびユーザーの理解言語に関する既存のAI判断を組み合わせて配信を決定する。
この変更により、キャンペーン設定で言語を指定する手間がなくなる。広告文とランディングページの言語がそのまま配信基準として機能するようになるのだ。
P-MAXへの影響範囲
P-MAX（パフォーマンスマックス）では、この変更の影響を受けるのは検索枠のみ。検索以外のチャネルではキャンペーンレベルの言語設定が引き続き使用される。つまりP-MAX全体が変わるわけではなく、Google検索に表示される部分だけが対象になる。
複数言語ユーザーへの広告配信ロジック
変更後の大きなポイントは、複数言語を理解するユーザーへの配信方法だ。英語とスペイン語の両方を理解するユーザーには、どちらの言語の広告も配信される可能性がある。GoogleのAIが広告グループ単位で優先順位付けを行い、検索に対して最適な言語を選ぶ。
検索クエリに明確な言語がある場合は、その言語の広告とランディングページが優先される。たとえばスペイン語で検索したユーザーには、スペイン語の広告が優先的に表示される仕組みだ。
Googleはクエリの言語だけでなく、ユーザー設定や過去の行動など複数のシグナルを組み合わせて最適な言語を選ぶ。複数言語を理解するユーザーに対しては、AIが広告グループ単位でより適切な言語を優先する仕組みだ。
ブランド検索における言語判断
ブランド検索では状況が少し複雑になる。ブランド名が複数言語で同一であることが多く、クエリ自体から言語を判断する手がかりが少ないからだ。たとえば「Nike」というブランド名は英語でもスペイン語でも同じ表記になる。
このような場合、Googleはクエリ以外の言語シグナルに依存し、ユーザーの優先言語を重視する。日常的に英語とスペイン語の両方で検索するユーザーには、どちらの言語の広告も配信対象になり得る。
Googleはこの変更が、キャンペーン設定による意図しないトラフィック制限を減らすとも説明している。たとえば英語でターゲティングしたキャンペーンにスペイン語の広告文やランディングページが含まれる場合、従来はキャンペーン設定がブロック役を果たしていた。今後はGoogleの言語理解に委ねられ、関連トラフィックを取りこぼしにくくなる見込みだ。
広告主が懸念する規制対応とAI生成クリエイティブ
規制業界の配信実績の文書化
発表前に行われたバーチャルラウンドテーブルでは、広告主からいくつかの質問が寄せられた。特に規制対象業界の広告主は、コンプライアンスに関する懸念を示した。
保険業界の広告主を例にとると、英語話者とスペイン語話者の両方に広告が公平に届いていることを文書で示さなければならない場合がある。Googleは両言語で広告を提供していれば、両方のグループにリーチする意図があると判断されると説明した。
ただし、ラウンドテーブルで出た質問は意図の話だけにとどまらなかった。キャンペーン設定ではなくGoogleの自動判定が言語ごとの配信を決めるようになった場合、広告主がどのように配信実績を証明するかという点は未解決のままだ。Googleは言語別の配信状況やパフォーマンスの差を確認できる追加のレポート機能を発表していない。
AI Maxと自動生成クリエイティブ
P-MAXと自動生成クリエイティブに関しても質問があった。ケベック州をターゲットにしたAI Maxキャンペーンで、AIがフランス語のクリエイティブを生成した場合、英語で検索するユーザーにそのフランス語広告が表示される可能性はあるのか。Googleは「可能性がある」と回答した。
クリエイティブの生成が先に行われ、その後Googleが利用可能な広告とランディングページをユーザーが理解できるかをチェックする。クエリの言語と広告の言語が一致していなくても、ユーザーが理解できると判断されれば配信される仕組みだ。
検索クエリの言語と広告の言語は必ずしも一致する必要がない。Googleがユーザーの理解言語を判断し、優先順位付けシステムが最適なクリエイティブを選ぶためだ。
広告主が取るべき具体的な対応
既存キャンペーン構造の扱い
大多数の広告主にとって、この変更は大きな影響を及ぼさない。Googleも既存キャンペーンの再構築は不要だと明言している。言語別にキャンペーンを分けている場合も、そのままの構造を維持してよい。言語設定が検索からなくなったからといって、キャンペーンを統合する必要はない。
注意が必要なのは、言語ターゲティングを本来の目的以外に使っていたケースだ。旅行、国際展開、規制対象などの業界では、言語設定がオーディエンスの絞り込みやコンプライアンス要件に影響していることがある。
Google広告APIを利用する広告主は、検索キャンペーンの作成・更新時に言語条件を送信するのをやめることが推奨されている。既存の言語条件は残っても構わないが、検索ターゲティングには影響しなくなる。
適用後に監視すべき指標
具体的には、広告文とランディングページが意図した言語で書かれているか確認するべきだ。特に多言語キャンペーンやAI生成アセットを利用する場合は注意が必要。Googleが広告文とランディングページの言語を基準にするため、これらの言語が正確に設定されていないと配信に影響する。
変更が適用された後は、検索語句や地理的トラフィックの変化、流入ユーザーの言語属性などを確認し、パフォーマンスを監視する。国際展開や多言語運用を行う広告主は、特にこれらの指標に注意を払う必要がある。
パフォーマンスと流入ユーザーの構成がおおむね安定していれば、Googleの主張どおり言語設定が実質的に重複していたと言える。一方、言語設定を追加のオーディエンス制御層として使っていたケースでは、適用後の変化を見極めるのに時間がかかるかもしれない。
この記事のポイント
- Google広告が検索キャンペーンとP-MAXの検索枠からキャンペーンレベルの言語ターゲティング設定を廃止する
- 変更は2026年9月下旬から順次適用され、広告文とランディングページの言語が配信判断の主な基準になる
- 既存キャンペーンの再構築は不要で、言語別に分けている場合もそのまま維持できる
- 規制業界では配信実績の文書化について未解決の課題が残る
- P-MAXでは検索以外のチャネルでキャンペーンレベルの言語設定が引き続き使われる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WPForms Liteにバックドア疑惑、セットアップウィザードが管理者権限を外部に渡す仕組み
WordPressプラグイン「WPForms Lite」にバックドアが仕込まれているという疑惑が、2026年8月にX（旧Twitter）上で提起された。発端はSEOプラグイン「The SEO Framework」の開発者Sybre Waaijer氏の投稿だ。同氏はWPForms Liteのバージョン2.0.0に含まれるセットアップウィザードが、1時間有効の管理者トークンを外部に渡し、ユーザーのサイトにプラグインをインストールできる状態を作り出していると指摘した。
Search Engine Journalの著者Roger Montti氏が実際にWPForms Liteをインストールしてテストしたところ、セットアップウィザードがユーザーを外部サイトに誘導し、気づかぬうちに追加プラグインのインストールを強制するという実態が明らかになった。この記事では疑惑の内容、テスト結果、そしてこれが本当にバックドアと呼べるのかを検証する。
WPForms Liteにバックドア疑惑、発端はThe SEO Framework開発者の投稿
2026年8月、Sybre Waaijer氏がX上でWPForms Liteにバックドアが仕込まれていると投稿した。WPForms LiteはAwesome Motive社が開発する無料のフォーム作成プラグインで、500万以上のサイトにインストールされている。Waaijer氏は、バージョン2.0.0で追加されたセットアップウィザードが、管理者権限を持つ1時間有効のトークンを発行し、Awesome Motiveのサーバーに渡す仕組みになっていると指摘した。
問題となったコードは「wpforms-lite/src/SetupWizard/Bridge.php」というファイルに含まれているという。セットアップウィザードを起動すると、ユーザーのブラウザはWPFormsの外部サイトにリダイレクトされ、そこで管理者トークンが発行される。このトークンを使ってAwesome Motive側は、ユーザーに代わってプラグインのインストールや有効化、さらにはフォームの送信データを自社サーバーに送る設定の有効化まで可能になるとされる。
この概念図はWaaijer氏の主張を簡略化したものだ。ユーザーがセットアップを進めると、知らないうちに自サイトの管理者権限が外部に渡り、プラグインが追加される流れになる。
インストール可能なプラグインの一覧
Waaijer氏の投稿によると、この仕組みでインストール可能なプラグインは以下の13種類だ。驚くべきことに、競合するコンタクトフォームプラグインであるContact Form 7やNinja Forms、Pirate Formsも含まれており、同氏はこれを「おそらくバグ」と指摘している。
- WP Mail SMTP
- WPConsent
- Uncanny Automator
- AIOSEO（All In One SEO）
- Universally
- Duplicator
- Reviews Feed
- OptinMonster
- MonsterInsights
- ActiveLayer
- Contact Form 7（競合プラグイン、バグの可能性）
- Ninja Forms（競合プラグイン、バグの可能性）
- Pirate Forms（競合プラグイン、バグの可能性）
また、WPFormsのアドオンやPro版を自社サーバーから直接プルすることも可能で、これらのサーバーはWordPress.orgのモデレーションを受けないため、悪意あるコードをプッシュするリスクもあるとWaaijer氏は警告している。
コミュニティからの反論とWaaijer氏の立場
Waaijer氏の投稿に対して、WordPressコミュニティからは「Awesome Motiveは10年にわたり信頼されてきたプラグイン開発者であり、公に非難するのは不公平だ」という意見が上がった。ユーザー@BuildInBitsは「これは非公開で議論すべき内容であり、公開で非難するのは行き過ぎだ」と投稿している。
しかしWaaijer氏は、Awesome Motiveが自らの競合であると明かした。同氏が開発するThe SEO Frameworkは、Awesome Motiveが提供するAll In One SEO（AIOSEO）と直接競合するSEOプラグインだ。Waaijer氏は「彼らは意図的に管理者権限の第二チャネルを構築し、オープンソースに見せかけている。WPBeginnerは10年以上にわたり、チュートリアルの最終着地点が常に自社スタックに誘導するファネルだった」と批判している。
本当にバックドアなのか、異論も
一方で、Waaijer氏の「バックドア」という表現に対しては異論も出ている。Xユーザー@marckranatは「これは従来の意味でのバックドアではない。ベンダーが自発的にアクセスを開始する経路はなく、認証バイパスも隠しリスナーも存在しない。ログインした管理者がウィザードを起動する必要がある」と指摘した。
米国立標準技術研究所（NIST）の定義によれば、バックドアとは「コンピューターシステムにアクセスするための文書化されていない手段」であり、セキュリティリスクになり得るものだ。しかしWPForms Liteのケースでは、管理者が自らセットアップウィザードを起動しなければ外部からの操作は始まらない。つまり、外部から一方的に侵入される経路が存在するわけではないという視点も成り立つ。
この比較からわかるように、WPForms Liteの仕組みは厳密な意味でのバックドアとは異なる。しかし管理者が認識しないまま外部に権限を渡す点は、透明性の観点で問題があると指摘されている。
Search Engine Journal著者が実際にテスト、セットアップウィザードの実態
Search Engine JournalのRoger Montti氏は、この疑惑を検証するためWPForms Liteを実際にインストールした。Montti氏はすでに別のサイトで同プラグインを使用していたが、テスト用のサイトに新規インストールしたところ、セットアップウィザードが表示されたという。
注目すべきは、セットアップウィザードの最初の画面がすでにWPFormsの外部サイト（wpformsapi.com）に切り替わっていた点だ。Montti氏は「自分のサイトにいると思っていたが、すでに別のサイトに移動していた」と述べている。URLバーを注意深く見ていなければ、気づかないレベルの遷移だったという。
Montti氏が実際に体験したセットアップの流れは上図のとおりだ。同氏は「Install and Continue」をクリックしてしまったが、これが自サイト内の操作だと信じていたと振り返っている。
2つのプラグインが強制インストール、オプトアウト不可
セットアップウィザードの途中には「Select Your Features」という画面が表示され、「AI Form Generation」と「Privacy Compliance」のチェックボックスが最初からオンになっており、外せない状態だった。さらに画面下部には、無料の「WPConsent」プラグインがインストールされる旨の通知があり、これも拒否できなかった。
結果として、Montti氏のテストサイトにはWP Mail SMTP、WPConsent、そしてWPForms Liteの3つのプラグインがインストールされた。同氏はその後プラグインをアンインストールし、同じワークフローを再現しようとしたが、2回目以降は発生しなかったという。
バックドア疑惑の本質とWordPressサイト運営者が取るべき対応
WPForms Liteのセットアップウィザードが外部サイトに誘導し、管理者トークンを発行して他プラグインをインストールする仕組みは、Montti氏のテストでも確認された。これは「密かに不正アクセスを可能にする」典型的なバックドアとは異なるが、管理者が認識しないままサイトの変更を許す点で、透明性に問題がある。
NISTの定義に照らせば「文書化されていない手段」には該当し得る。しかし実際にはセットアップウィザードの一部として動作し、管理者がトリガーを引く必要があるため、「バックドア」という表現は強すぎるという見方もある。とはいえ、ユーザーが外部サイトに移動したことに気づかないまま、プラグインが追加される体験は、セキュリティ意識の高いサイト運営者にとって懸念材料だ。
この問題の核心は「バックドアかどうか」の定義論争よりも、プラグインのセットアッププロセスにおける透明性の欠如にある。500万以上のサイトに影響を与え得る仕様だけに、開発者側の説明責任が問われている。
この記事のポイント
- WPForms Lite 2.0.0のセットアップウィザードが、外部サイトで管理者トークンを発行し、ユーザーに無断でプラグインをインストールできる状態を作る
- Search Engine Journalのテストで、WP Mail SMTPとWPConsentが強制インストールされ、AI機能もオプトアウト不可だった
- 「バックドア」という表現には異論もあるが、管理者が気づかないまま外部サイトに誘導される点は透明性に問題がある
- サイト運営者はプラグインインストール時のURL確認と、定期的なプラグイン一覧のチェックを習慣化すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPTが商業クエリの26%に広告表示、関連性に課題も浮上
ChatGPTが商業目的のクエリの約4回に1回の割合で広告を表示していることが、SEOツール企業SE Rankingの調査で明らかになった。表示頻度はGoogleのAIモードに迫る水準だが、広告の関連性や広告主の可視性に課題が残る。
今回の調査は20分野にわたる5万件以上の商業クエリを分析したもので、会話型AI上での広告配信の実態が初めて大規模に可視化された。AI検索時代の新たな広告チャネルとして注目されるChatGPT Adsだが、その仕組みにはGoogle検索とは異なる独自の難しさがある。
商業クエリの約26%で広告が出現、Google AIモードに肉薄
SE Rankingの調査によると、ChatGPTは商業クエリの25.94%でスポンサードプレースメント（広告）を表示した。これは同社が以前調査したGoogle AIモードの29.45%にかなり近い数字だ。AIチャットボットの広告表示率が、従来型検索エンジンのAIモードと肩を並べつつある状況が浮かび上がった。
表示スタイルはシンプル、1クエリに単一広告
広告の表示スタイルは現在のところ非常にクリーンだ。調査で観測されたすべての広告は、生成された回答の下部に表示され、他の広告主と並んで競合することはなかった。1つの回答に対して常に1つのスポンサーオファーのみが表示される。
Googleの検索結果画面とは異なり、ユーザー体験を大きく阻害しない形で広告が統合されている点は注目に値する。ただし、このシンプルさは広告枠の稀少性を意味しており、将来的に入札競争が激化した際にどう変化するかは未知数だ。
広告の関連性に課題、約14%が的外れな表示
ChatGPT Adsの大きな課題として浮上したのが、広告の関連性だ。SE Rankingのセマンティック分析によると、表示された広告の約14.35%が、ユーザーのプロンプトと実質的な関連性を持たなかった。これは7件に1件の割合で、的外れな広告が表示されている計算になる。
カテゴリによるばらつきが顕著
ミスマッチの発生率はカテゴリによって大きく異なる。ペット分野ではわずか2.6%だったのに対し、人間関係やニュース・政治分野では半数以上が無関係な広告だった。特定のトピックでは、会話の文脈を正しく解釈して適切な広告を選ぶことが依然として難しいことがわかる。
実際のミスマッチ例
調査で観測された例では、デートアプリに関するプロンプトに衣料品小売店の広告が表示されたり、新聞の購読を尋ねるクエリに電力会社の広告が出たりといったケースがあった。ユーザーの意図と広告の内容が明らかにずれている。
このようなミスマッチは、広告主にとって広告費の無駄遣いになるだけでなく、ユーザーのAI体験の質を下げる要因にもなる。ChatGPTが広告プラットフォームとして成熟するためには、文脈理解の精度向上が不可欠だ。
従来のキーワードターゲティングとは根本的に異なる仕組み
ミスマッチが起きる背景には、ChatGPT Ads特有のターゲティング方式がある。広告主はキーワードリストではなく、自然言語で書かれた「コンテキストヒント」を提供する。これは「自社の広告を表示したい会話の文脈」を説明するテキストで、厳密なマッチングルールではなく、AIによるゆるやかなマッチングのガイドとして使われる。
加えて、広告主は現在のところ、実際にどのクエリや会話が自社の広告表示をトリガーしたのかを確認できない。これでは不適切なプレースメントが起きても原因を特定しづらく、改善のためのフィードバックループを回すのが難しい。
広告出稿とAI回答でのブランド露出はほぼ無関係
調査の中で特に注目すべき知見は、ChatGPT上で広告を出稿しても、それが生成AIの回答本文にブランドとして登場する確率はほとんど上がらないという点だ。
広告が表示されたクエリのうち、同じブランドが回答の情報源として引用されたケースはわずか3.63%だった。さらに、広告のURLがそのまま引用に現れたのは0.09%にすぎない。ブランド名の言及も4.44%にとどまる。
つまり、ChatGPTに広告費を投下しても、AIが生成するオーガニックな情報として認識される可能性は極めて低い。有料プレースメントとオーガニックなAI可視性は、今のところ完全に分離していると考えてよい。
YMYL分野で目立つ広告表示、Google AIモードとの違い
ChatGPT Adsは、健康やニュースといったYMYL（Your Money or Your Life）分野で、Google AIモードに比べて顕著に多くの広告を表示している。
調査によると、ヘルスケア関連のプロンプトでは28.69%で広告が表示されたのに対し、Google AIモードではわずか2.64%だった。ニュース・政治カテゴリでも同様に、ChatGPTが28.76%、AIモードは6.8%と大きな開きがある。
この差は、ChatGPTの広告セーフガードが緩いことを必ずしも意味しない。むしろ、2つのAIプラットフォームが広告表示に対して異なるポリシーやマッチングモデルを採用している証拠と見るべきだ。広告主は、AI検索チャネルごとにまったく異なる配信傾向があることを前提に戦略を立てる必要がある。
広告主が今おさえておくべきポイントと今後の展望
ChatGPT Adsは急速に成長する有料メディアチャネルだが、Google検索広告と同じ感覚で運用すると期待はずれに終わる可能性が高い。会話型AI上の広告は、キーワードではなくコンテキストに依存するため、精度の高いコンテキストヒントの設計と継続的な実験が欠かせない。
また、どのような会話で広告が表示されたかというレポートの不足は、最適化の足かせとなる。OpenAIが今後、広告主向けにより詳細な分析ダッシュボードを提供するかどうかが、チャネルとしての成熟度を左右するだろう。
さらに、AI検索の世界では、有料広告とオーガニックなブランド認知が直接リンクしない構造が鮮明になった。SEOにおけるブランド構築や被リンク獲得といった従来手法は、AIが回答を生成する時代にも強みを発揮する。広告だけでAI上の可視性を買おうとする発想は現実的ではない。
この記事のポイント
- ChatGPTは商業クエリの約26%で広告を表示し、Google AIモードと同等の水準に達している
- 広告の約14%がクエリと無関係で、会話ターゲティングの精度に課題が残る
- 広告出稿しても、ブランドがAI回答内で情報源として引用される確率は3%程度と低い
- 健康やニュース分野では、ChatGPTの広告表示率がGoogle AIモードより顕著に高い
- 会話型AI広告の最適化には、精密なコンテキストヒント設計と、広告表示ログの透明性が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GoogleのAI責任者ジェフ・ディーン氏が退任、新会社を設立。AI研究の巨人の軌跡とSEOの今後
GoogleのアルファベットCEO、サンダー・ピチャイ氏が2026年8月5日、大規模な組織改編と重要人物の退任を発表した。今回のニュースの核心は、27年にわたりGoogleの検索基盤と現代のAI技術を支えてきたチーフサイエンティスト、ジェフ・ディーン氏が退任し、新会社を設立することだ。
彼の退任は、単なる一社の人事異動ではない。TensorFlowの共同発明、知識蒸留の概念、MapReduceといった、今日の検索エンジンと生成AIの土台そのものを築いた人物の離脱である。この記事では、今回の発表内容、ディーン氏の技術的遺産、そしてこの出来事がSEO業界に投げかける長期的な影響を読み解く。
Google DeepMind新体制とデミス・ハサビス氏の役割拡大
今回の発表で、GoogleのAI研究開発におけるリーダーシップ体制が一新された。Google DeepMindの共同創業者でありCEOであるデミス・ハサビス氏が、新たにアルファベット社全体のチーフサイエンティスト、そしてGoogle DeepMindの会長に就任する。彼はDeepMindの顔としての役割を維持しつつ、Googleが持つ他のAI関連部門に対しても影響力を拡大することになる。
とりわけ注目すべきは、医薬品開発を行うアイソモルフィック・ラボ（Isomorphic Labs）への関与だ。この部門はAIを駆使して新たなバイオ医薬品や治療薬を発見することを目的としており、既にイーライリリーやノバルティス、ジョンソン・エンド・ジョンソンといった製薬大手と提携している。数兆円規模の巨大市場である医薬品産業において、GoogleがAIを中核に据えた事業展開を本格化させる意思が明確に示された形だ。
また、DeepMindのCTOを務めてきたコライ・カブクチュオール氏は、Google DeepMindのシニアバイスプレジデントに昇格し、実務的な日々のリーダーシップを担う。彼の管掌範囲には、Geminiモデルとアプリケーションの開発チーム、そして最先端のフロンティアモデルが含まれる。ピチャイCEOは声明の中で「彼は13年間DeepMindに在籍し、深層学習チームを立ち上げ、WaveNetやDQNといったブレークスルーを主導してきた」と評しており、まさに技術面での最高責任者としてGoogleのAI開発を牽引する役割を負う。
この一連の体制変更は、GoogleがAI研究の成果を検索やクラウドだけでなく、より実体経済に近い分野へと応用する段階に入ったことを示唆している。
ジェフ・ディーン氏の退任とその考古学的な功績
SEOやサイト運営者の間ではあまり知られていないかもしれないが、ジェフ・ディーン氏の名前は現代のインターネットの風景を語る上で欠かせない存在だ。彼はGoogleの初期検索インフラから、ニューラルネットワークによる現代AIの時代に至るまで、最も重要な技術的転換点の数々を牽引してきた。ピチャイCEOが「現代AI時代の創造に貢献した」と述べるのも当然のことである。
彼の退任が「巨大な損失」と形容される理由は、その業績リストを見れば一目瞭然だ。以下に、ディーン氏が関わった主要な研究論文と、その歴史的意義をまとめる。
MapReduce（2004年）
大規模クラスター上でのシンプルなデータ処理手法を提示したこの論文は、後のApache Hadoopの開発に強い影響を与え、ビッグデータ産業そのものの創出を可能にした。検索エンジンが扱う膨大なウェブデータの分散処理は、この着想なくしては実現しなかったと言っても過言ではない。
Bigtable（2006年）
構造化データを数千台のサーバーに分散して保存し、ペタバイト級にスケールさせる方法を示した。これは、超巨大規模でのウェブインデックス作成に直接的な影響を与え、Google検索の根幹技術のひとつとなった。
Large Scale Distributed Deep NetworksとDistBelief（2012年）
この論文は、数十億のパラメータを持つモデルのトレーニング手法を提示した。ここで紹介された分散学習フレームワーク「DistBelief」は、TensorFlowの直接の前身にあたる。スケーラブルな深層学習という、現在の巨大AIモデル時代の扉を開けたものだ。
知識蒸留（Distilling the Knowledge in a Neural Network、2015年）
大小さまざまなAIモデルを扱う企業や研究者にとって、知識蒸留は今や常識とも言える重要な技術である。これは、大規模で高性能な「教師モデル」の振る舞いを、より小さく高速な「生徒モデル」に学習させる手法を指す。簡単に言えば、ベテラン職人の技術を新人に凝縮して継承するイメージだ。ディーン氏は、この概念の主要な発明者の一人である。
この技術は、OpenAIやAnthropicのトップモデルを模倣するために中国企業が使用したと非難されたり、AIによる検索結果をリバースエンジニアリングする際に使われたりと、模倣や分析の文脈でも頻繁に話題に上る。AIの民主化と技術流出という、現代的な課題の根源にも関わる発明なのだ。
TensorFlow（2016年）
そして、おそらく最も広く知られているのが、機械学習ライブラリ「TensorFlow」の共同発明である。TensorFlowは、今日のAIを形作ることを可能にした柔軟なインフラ層だ。開発者が機械学習モデルを構築し、トレーニングするためのツールキットであり、現在の生成AIブームの縁の下の力持ちとも言える。TensorFlowの存在なくして、ChatGPTに代表される大規模言語モデルの急速な発展はありえなかった。
今回の退任がSEOとサイト運営に与える長期的な影響
SEOコミュニティの多くは、ジェフ・ディーンという個人名に馴染みが薄いかもしれない。しかし、彼の存在はこれまでの検索エンジンの進化、つまりSEOそのもののゲームルールを決定づけてきた。ここでは、彼の退任がもたらすであろう、より深い地殻変動を考察する。
GoogleのAI研究開発の方向性変化
最高技術責任者の退任と後任者の就任は、組織としての研究開発の優先順位や文化に変化をもたらすことが一般的だ。ディーン氏の代わりに実務のトップに立つコライ・カブクチュオール氏は、Geminのような大規模言語モデルと、その先のフロンティアモデルに直接責任を持つ。この体制が続く限り、Googleの研究開発リソースは「より賢く、より大きなAI」を追求する方向性が加速するだろう。
AIによる検索品質とアルゴリズム進化の加速
同時に、ディーン氏が積み上げてきた分散処理と大規模学習の基盤は、既にGoogle検索の血肉となっている。Googleが「AIによる検索体験」をどこまで推し進めるのか。AI Overviewsのような機能の進化は、後任者たちの手腕にかかっている。ディーン氏の退任は、ある種の完成を迎えた基盤技術の上で、応用レイヤーの競争がいよいよ本格化する合図とも読み取れる。
AIスタートアップ「Discovery Loop」とGoogleの特別な関係
サンダー・ピチャイ氏は、ディーン氏とGoogleのシニアフェローであるサンジェイ・ゲマワット氏が、機械学習や科学、工学における発見を加速させる独立した公益法人（Public Benefit Corporation）を設立すると述べた。この新会社「Discovery Loop」はGoogleからの独立組織だが、Google自身が出資者かつクラウドパートナーとなり、研究フレームワークでも協業するという。つまり、まったくの別会社というわけではなく、Googleのエコシステムと強固に結びついた「外部の頭脳」として機能する可能性が高い。両社の研究成果が間接的にGoogle検索に還流する未来も十分に考えられる。
この記事のポイント
- Googleのチーフサイエンティスト、ジェフ・ディーン氏が27年のキャリアに幕を下ろし、AI研究の新会社「Discovery Loop」を設立。
- ディーン氏はMapReduce、Bigtable、TensorFlow、知識蒸留など、現代の検索とAIの基盤技術を数多く発明。事実上の「検索エンジンの父」の一人。
- 後任のハサビス氏はDeepMind会長兼アルファベット全体のチーフサイエンティストとなり、医薬品開発などAIの応用領域を拡大する方針。
- この人事は、GoogleのAI研究が「基盤づくり」から「応用と収益化」へとフェーズを移行させるシンボリックな出来事。
- SEO実務者にとっては、AI Overviewsの高度化など、検索体験のさらなる変貌を前提とした長期的視点でのサイト運営がこれまで以上に求められる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
cats.txtが暴いたGEOの証拠水準。AIクロールは機能の証明にならない
AI検索時代におけるSEOの延長線上にあるGEO（生成AIエンジン最適化）。その効果を裏付ける「証拠」として、しばしば4つの観測があげられる。AIボットがファイルをクロールした、Googleがインデックスした、LLMがその内容を出力した、ChatGPTが有効性を認めた。しかし、これらの観測は本当に「有効性の証明」と言えるのか。
Search Engine JournalのMark Williams-Cook氏が公開した風刺的な検証が、この疑問に痛烈な答えを出している。同氏は架空の規格「cats.txt」を考案し、上記4つの証拠すべてをクリアすることを実証した。つまり、ウェブ上に置かれたどんなテキストファイルにも同様の現象は起こり得るのであり、それらは機能を保証するものではないというわけだ。
GEO業界でまかり通る「4つの証拠」とその問題点
以下、それぞれを詳しく見ていこう。
1. AIボットがクロールしている
クローラーの役割は、Web上にあるファイルを片端から取得することだ。そのため、cats.txtのような冗談まじりのファイルにも、PerplexityBotやGPTBot、ClaudeBotがアクセスしてくる。サーバーログにボットの痕跡があったからといって、そのファイルが「特別に利用されている」証拠にはならない。配達員が門を通るのと、家の中のゴミ箱の中身が役立っているというのは別の話である。
2. Googleにインデックスされた
Googleはテキストファイルをきわめて積極的にインデックスする。cats.txtもGoogle検索結果に現れ、Search Consoleで「インデックス登録されました」と表示された。しかしそれは、URLが存在し、何かしらの文字が書かれているという事実を確認しただけだ。信ぴょう性や有用性とは無関係である。
3. LLMがファイルの内容を出力した
検索拡張生成（RAG）は、LLMが検索結果を参照して回答を生成する仕組みだ。cats.txtが検索上位に登場すると、AIはその猫情報を何の疑いもなく引用する。これはファイルが特別な「プロトコル」として機能しているのではなく、単に1つのWebページとして扱われた結果に過ぎない。
4. ChatGPTが有効性を認めた
ChatGPTに「cats.txtは役立ちますか」と尋ねると、公開直後は「検索エンジンやLLM駆動システムでのランク向上に寄与する可能性があります」という回答が返ってきた。これはネット上に「有効だ」と書かれたテキストが多かったからであり、AI自身が何かを判断したわけではない。興味深いことに、このファイルが風刺であると知れ渡った後は、同じChatGPTが「これは冗談です」と答えるようになった。AIの意見は、周囲の言説の平均値にすぎないのである。
「収束問題」が引き起こす根拠の循環
この「収束問題」こそが、4つの証拠の背後にある根本的なメカニズムだ。LLMは与えられたネット上の言説の平均的な意見を出力するに過ぎない。cats.txtが「効果的だ」と答えたのも、公開当初に肯定的な書き込みが一定数集まったからである。もし皆が「これはデタラメだ」と書いていれば、AIもそう答えたはずだ。
このように、AI自身の意見を「お墨付き」と捉えるのは危険である。流動的な世の中の雰囲気に左右される出力を、数値や因果関係の証拠と混同してはいけない。
真のSEO・GEO最適化が目指すべきもの
cats.txtの実験が示したのは、あるGEO施策の効果を主張するために使われる「証拠」があまりにも脆弱だという事実だ。AIボットのクロール、インデックス、LLMの出力、ChatGPTの賛同。これらはどれも、「施策が機能していること」の証明にはならない。
問題は、こうした根拠不十分な手法に時間と予算を費やすことにある。確かな価値が実証されている基本的なSEO改善（コンテンツ品質、サイト速度、ユーザー体験の向上）こそが、長期的にAI検索からのトラフィックを伸ばす土台となる。最適化とは、検証可能な小さな改善を積み重ね、競合よりもわずかに優位に立つことだ。まだ誰も検証していない「次のGEOの秘策」を追いかけることではない。
この記事のポイント
- AI検索最適化の「証拠」とされる4つの観測（クロール、インデックス、LLM出力、ChatGPT賛同）は、どのテキストファイルにも起こる現象であり、施策の有効性を担保しない
- 2026年8月に公開されたcats.txtは、この4つの証拠すべてをクリアし、根拠の脆弱性を浮き彫りにした
- LLMの自己評価はネット上の意見の平均を返しているに過ぎず、エコーチェンバー効果によって「有効」と誤認されやすい
- 限られたリソースは、検証済みの基本SEO改善に集中させるべきであり、エビデンスの弱い新手法に振り回されてはならない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1の管理画面テーブル変更、一部プラグインに影響の可能性
WordPress 7.1が2026年8月19日にリリース予定だ。このバージョンでは管理画面のアクセシビリティを大幅に改善する変更が含まれる。具体的には、投稿一覧などの管理用テーブルでHTMLのセマンティクスが修正される。この修正自体は好ましい進化だが、一部のプラグインやテーマで管理画面の動作に影響が出る可能性がある。特に、管理用のテーブル構造を前提にCSSやJavaScriptでカスタマイズしている場合は注意が必要だ。
変更の規模はそれほど大きくないが、プラグイン開発者だけでなく、サイト運営者も事前に互換性を確認しておくことで、アップデート後のトラブルを回避できる。この記事では、変更の具体的な内容と、利用者・開発者それぞれが取るべき対策を簡潔にまとめる。
管理画面テーブルのHTML構造が変わる
WordPress 7.1では、投稿・固定ページ・カスタム投稿タイプなどを一覧表示する管理画面のテーブル（リストテーブル）のHTMLマークアップが一部変更される。修正の対象は、主に各行の左端にあるチェックボックス列と、投稿タイトル列だ。変更点を整理すると以下のようになる。
- チェックボックス列が
<th>（行ヘッダー）から<td>（通常のセル）に変更される - 投稿タイトル列が
<td>から<th scope="row">（行ヘッダー）に変更される - 投稿タイトルの行ヘッダーには、投稿名を含む
aria-label属性が追加される - レスポンシブ表示時の折りたたみセルがFlexboxレイアウトに更新される
この変更によって、スクリーンリーダーを利用するユーザーは、各行で「どの投稿を操作しているのか」を正確に認識できるようになる。従来は、チェックボックス列が行ヘッダーだったために「すべて選択」といった無意味なラベルが読み上げられることが多く、特に投稿がロックされている場合などは混乱の原因になっていた。
変更前と変更後のコード比較
具体的にHTMLがどのように変更されるのか、簡単な例を示す。まずは現行バージョンの構造だ。
<tr>
<th scope="row" class="check-column">
<input type="checkbox" name="post[]" value="123">
</th>
<td class="title column-title column-primary page-title">
<a class="row-title" href="...">Hello world!</a>
</td>
<td class="author column-author">admin</td>
</tr>これがWordPress 7.1では以下のように変わる。
<tr>
<td class="check-column">
<input type="checkbox" name="post[]" value="123">
</td>
<th scope="row" class="title column-title column-primary page-title" aria-label="Hello world!">
<a class="row-title" href="...">Hello world!</a>
</th>
<td class="author column-author">admin</td>
</tr>チェックボックスのセルが <th> から <td> になり、代わりにタイトル列が <th scope="row"> として行の見出しの役割を担う。これにより、支援技術は「Hello world!」という投稿タイトルを行の識別子として扱えるようになる。
この変更は、サイトのフロントエンド（公開側）には一切影響しない。問題が発生するのはあくまで管理画面の投稿一覧テーブルをカスタマイズしている場合に限られる。
11年越しのバグ修正がもたらすアクセシビリティ向上
WordPressのコア開発チケット「#32892」は、この問題を報告してから実に11年が経過していた。修正が長期化した背景には、管理画面のテーブルマークアップが広範囲に影響するため、影響範囲の調査とテストに時間を要したことがある。
従来の構造では、スクリーンリーダーが各行を読み上げる際に、チェックボックスに関連付けられたラベル（多くの場合「すべて選択」）を読み上げてしまい、ユーザーはどの投稿の行にいるのか理解しづらかった。特に投稿が他ユーザーによってロックされている時に表示される鍵アイコンには、読み上げ用のラベルがなく、スクリーンリーダーは「すべて選択」と繰り返すだけだった。今回の変更により、行の主たる識別子である投稿タイトルが適切に読み上げられるようになり、管理画面の操作性が大きく改善される。
サイト運営者が今すぐすべきこと
影響を受けるのは、管理画面の投稿一覧に対して何らかの情報や操作を追加しているプラグインのみだ。具体的には、CSSやJavaScriptで特定の <th> や <td> をターゲットにしてカスタマイズしているプラグインが対象となる。多くのサイトでは問題は起きないが、念のため以下の手順で確認することをおすすめする。
プラグインの互換性情報を確認
WordPress 7.1の公開後、利用中のプラグインが互換性テストをパスしているかどうかをまずチェックしよう。方法は簡単で、「プラグイン名 changelog」や「プラグイン名 WordPress 7.1」で検索すれば、開発元の公式ブログやチェンジログが見つかる。プラグインが「7.1対応済み」と明記されていれば、先にプラグインを最新版に更新してからWordPress本体のアップデートを行うと安全だ。
互換性が未確認の場合は、本番環境に直接アップデートを適用せず、ステージングサイト（テスト環境）で事前に動作確認を行うことが望ましい。特に管理画面に大きく依存したワークフローを構築しているサイトでは、ステージングでのテストは必須に近いと考えていい。
主要SEOプラグインへの影響はほぼなし
多くのサイトで利用されているYoast SEO、Rank Math、All in One SEO（AIO SEO）の3つのSEOプラグインには、管理画面の投稿一覧に独自のカラムを追加する機能が含まれている。こうしたプラグインこそ影響を受けやすいように見えるが、Search Engine Journalの記事によると、公開されているコードを確認した限りでは、今回変更される <th> と <td> の構造に依存したセレクタは見つからなかったという。したがって、これらのプラグインがWordPress 7.1で即座に動作しなくなる可能性は極めて低い。
ただし、これは公式の保証ではない。各プラグインの公式ブログやチェンジログで、7.1対応についてアナウンスがないか確認しておくに越したことはない。
万が一問題が出た場合の対処
仮にプラグインが管理画面の投稿一覧で表示崩れや機能停止を起こしたとしても、フロントエンドの表示やSEO評価に直接影響が出ることはまずない。管理画面の一部の機能が不安定になる程度と考えてよい。その場合は、問題のプラグインを一時的に無効化するか、開発元の対応を待つことになる。落ち着いてステージング環境で原因を特定し、本番への影響を最小限に抑える対応を取ろう。
プラグイン開発者とカスタム実装者に向けて
WordPress向けのプラグインや管理画面のカスタマイズを行っている開発者は、今回の変更を事前に把握し、影響を受けるセレクタを修正する必要がある。特にノーコードツールやAIによるコーディング（いわゆるVibe Coding）で生成されたコードをそのまま利用している場合、セレクタの記述が <th> や <td> に依存している可能性が高いため、注意が必要だ。
修正すべきセレクタの典型例
問題となるのは、以下のようなCSSやJavaScriptのセレクタだ。
#the-list tr th.check-columnのような、チェックボックスの<th>を前提としたCSSルールdocument.querySelectorAll('tbody td.title')のように、タイトル列を<td>として取得するJavaScript- カスタムカラムを追加する際に、
<td>の直後に<td>を挿入するロジック
開発者は、セレクタをタグ名ではなくクラス名（.check-column や .title）に基づいたものに書き換えることで、新旧両方のマークアップに対応できる。WordPress 7.1への移行期間中は、<th> と <td> の両方にマッチするようなセレクタを用意するか、バージョン分岐処理を入れるのが安全だ。変更自体は単純なため、対応に膨大な工数がかかることはないだろう。
tr th.check-column で背景色を変更<td> になるためスタイルが当たらなくなるtr .check-column で背景色を変更なお、公式の発表では、テーマのフロントエンド側マークアップには一切手が加えられていないことが明言されている。管理画面のカスタマイズだけをメンテナンスすればよく、影響範囲は極めて限定的だ。
この記事のポイント
- WordPress 7.1ではアクセシビリティ向上のため、管理画面の投稿一覧テーブルのHTML構造が変更される
- チェックボックス列が
<th>から<td>に、タイトル列が<td>から<th scope="row">に変わる - フロントエンドへの影響はなく、管理画面のカスタマイズに依存する一部プラグインのみ注意が必要
- 主要SEOプラグイン（Yoast、Rank Math、AIO SEO）は現時点で影響が確認されておらず、互換性情報の確認を推奨
- 開発者はタグ名ではなくクラス名ベースのセレクタに修正することで新旧両対応が可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0.3が緊急リリース。深刻なXSS脆弱性など12件を修正、早急な更新を
WordPressのセキュリティアップデート「7.0.3」が2026年8月6日に公開された。このリリースでは12件の脆弱性が修正され、特に認証前の反射型クロスサイトスクリプティング（XSS）が深刻度8.9と評価されている。
当該のXSS脆弱性は、攻撃者が細工したサイトを経由してログイン画面にアクセスさせることで、リモートコード実行（RCE）に発展する可能性がある。全バージョンのWordPressに影響し、過去のブランチにまでパッチがバックポートされた点からも、緊急性の高さが伺える。
本記事では、修正された脆弱性の詳細と、ユーザーがすぐに実践できる対策をまとめた。
今回修正された12件の脆弱性の概要
WordPress 7.0.3では、以下の12件の脆弱性が修正された。公式発表では深刻度などの情報が最小限に留められているが、いずれも実運用に影響を与え得るものだ。
- 投稿日付ブロックでのContributor+保存型XSS
- 投稿コンテンツブロックでのContributor+保存型XSS
- 最新コメントブロックにおける情報開示（パスワード保護された投稿のコメントが露出）
- メールアドレス確認フローのバイパス
- Author+による安全なCSS属性フィルターのバイパスを介したCSSインジェクション
- 絵文字設定要素を介したContributor+保存型XSS
- マルチサイトネットワークでの権限昇格（ユーザー登録が有効な場合、新規サイト作成が可能）
- URL検証におけるSSRF（サーバーサイドリクエストフォージェリ）により、リンクローカル範囲へのリクエストが可能
- ログイン画面における認証前の反射型XSS（PHPコード実行の可能性あり）
- コメントフィードでのノート開示
- 投稿スラッグの列挙
- 多数のユーザーが存在するサイトでのクイック編集におけるContributor+保存型XSS
特に注意が必要な3つの深刻な脆弱性
修正された12件のうち、以下の3つは危険度が突出して高い。中でもログイン画面のXSSは、リモートコード実行に繋がる恐れがあり、深刻度は10点満点中8.9と評価された。
パスワード: ********
パスワード: ********
上のデモは、ログインエラーメッセージにスクリプトが紛れ込むケースを簡略化したものだ。修正前は悪意のあるコードがそのまま実行されてしまうが、修正後は出力が適切にエスケープされ、安全なテキストとして表示される。
ログイン画面の反射型XSS（深刻度8.9）
この脆弱性は、認証前（Pre-auth）の反射型XSSに分類される。攻撃者は特別に細工した悪意のあるWebサイトを用意し、標的ユーザーをそこへ誘導する。ユーザーがそのサイトを経由してWordPressのログイン画面にアクセスすると、不正なスクリプトが実行される可能性がある。
公式のGitHubセキュリティリポジトリによると、この脆弱性を悪用するとリモートコード実行（RCE）にまで発展する恐れがあるという。ただし、攻撃を成立させるにはソーシャルエンジニアリングが必須であり、標的ユーザーが意図的にアクションを起こす必要がある点が緩和要因となっている。
セキュリティ企業Patchstackのオリバー・シルド氏はSearch Engine Journalの取材に対し、「ソーシャルエンジニアリングが必要なため、ハッカーがこのXSSを積極的に悪用する可能性は低いと考えている」とコメントしている。同社では開示時点で緩和ルールを顧客に提供済みだ。
SSRF（サーバーサイドリクエストフォージェリ）による内部情報露出
SSRFとは、サーバーが内部ネットワークに対して不正なリクエストを送信させられる脆弱性だ。今回の事例では、リンクローカルIP範囲（サーバー内のプライベート通信で使われるアドレス）へのリクエストが可能になる。
これにより、本来外部からアクセスできない内部の機密情報が漏洩するリスクがある。公式発表では詳細が明かされていないが、仮想ホスト環境やクラウドインスタンスのメタデータサービスなどが標的になる可能性がある。
マルチサイト環境での権限昇格（新規サイト作成）
ユーザー登録が有効なマルチサイトネットワークにおいて、権限を持たないユーザーが新たなサイトを作成できる脆弱性だ。大学や企業のポータルサイトのような大規模マルチサイト環境では、悪意のあるサイト作成によってブランド毀損やフィッシングサイトの設置などに悪用される恐れがある。
単一サイトの運営者には影響しないが、WPMU（WordPress Multisite）を利用している管理者は直ちにアップデートを適用する必要がある。
XSSの危険性を正しく理解する
今回のリリースで最も注意を集めている脆弱性が反射型XSSだ。クロスサイトスクリプティングは、古くから存在する攻撃手法でありながら、依然として多くのWebアプリケーションで発見される。
OWASP（Open Worldwide Application Security Project）は、XSSを「悪意のあるスクリプトが、信頼された正規のWebサイトに注入される攻撃」と定義する。攻撃者は、ユーザーの入力を適切に検証・エンコードせずに出力することで、任意のスクリプトを実行させる。
実行されたスクリプトは、Cookieやセッショントークンといった機密情報にアクセスできるため、アカウントの乗っ取りや個人情報の窃取に直結する。WordPressのログイン画面でこの攻撃が成立すれば、サイト全体の管理者権限を奪取されるリスクもゼロではない。
WordPressユーザーが取るべき具体的な対策
自動更新が有効か確認する
WordPress 7.0.3はセキュリティリリースのため、自動更新がデフォルトで有効になっている環境では速やかに適用される。管理画面の「ダッシュボード」→「更新」から、現在のバージョンを確認しておこう。
手動更新が必要な場合の手順
何らかの理由で自動更新が失敗した場合は、手動での更新を推奨する。FTP/SFTPでWordPressファイルを上書きする方法が一般的だが、事前にデータベースとファイルの完全バックアップを取得しておくことが鉄則だ。
マルチサイト運営者は特に注意を
ユーザー登録を許可しているマルチサイトネットワークでは、権限昇格の脆弱性が悪用される前に即座に更新する必要がある。また、新規サイト作成の監査ログを確認し、不審なサイトが作成されていないかも点検すべきだ。
この記事のポイント
- WordPress 7.0.3では12件の脆弱性が修正され、ログイン画面の反射型XSSは深刻度8.9
- SSRFやマルチサイト権限昇格も深刻で、特にマルチサイト運営者は早急な対応が必要
- 攻撃にはソーシャルエンジニアリングが必要だが、RCEに繋がる可能性があるため軽視できない
- 自動更新の確認と、全バージョンへのパッチ適用を今すぐ実施すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GoogleサーチコンソールにAI検索レポート登場。見るべきポイントと活用術
Google は 2026 年 6 月 3 日、Search Console に生成 AI 専用のパフォーマンスレポートを追加した。AI Overviews（AI 概要）や AI Mode（AI モード）といった検索体験の一部として、自社サイトの URL がどの程度表示されたかを切り分けて確認できるようになっている。
これまで「AI 検索に自社のコンテンツが出ているのかどうか」は、通常の検索パフォーマンスの数字に埋もれてわからなかった。今回の分離によって、どのページが生成 AI の回答元として使われているのかを確認できるようになったが、あくまで「表示回数」ベースのデータであり、クリックや引用のされ方までは把握できない点に注意が必要だ。
この記事では、新レポートで何が読み取れるのか、従来の検索表示回数とどう違うのか、そして実際にサイト改善に役立てるための診断フローを解説する。
AI検索レポート、ついに独立
生成AI専用レポートの概要
この新しい Search レポートは、AI Overviews と AI Mode からの表示回数のみを集計する。Discover 向けの生成 AI 機能は別レポートとして提供されている。また、Labs の実験的機能は対象外だ。
レポートでは、URL 単位、国別、デバイス別、日付別に表示回数をセグメントできる。ただし現時点では、以下の指標は含まれていない。
- 検索クエリ
- クリック、クリック率（CTR）
- 平均掲載順位
- 引用の位置（回答内でリンクがどの順序で表示されたか）
- 回答の基となった文章の特定
- コンバージョンや収益データ
Google は「今後、追加指標の要望をサイト運営者とともに検討する」と述べており、機能拡張の可能性はある。また、AI Overviews や AI Mode にコンテンツを含めるかどうかを制御する新しい設定も Search Console でテスト中だ。デフォルトは「含める」で、オプトアウトすると従来の検索結果には影響なく、生成 AI の回答からも自社コンテンツが除外される。
まずは「どの部分が使われているか」を把握するために
現時点のレポートが答えられるのは「サイトのどのページが生成 AI の表示に使われているのか、どのくらいの頻度か」という問いだ。それ以上の詳細は得られないが、この可視化だけでもこれまでにない手がかりになる。
AI表示回数は従来の表示回数とは異なる
表示回数の数え方の基本
Google の定義では、AI 表示回数とは「生成 AI の機能内でユーザーにリンクが表示された回数」を指す。集計方法はレベルによって異なり、グラフのプロパティ全体では、1 つの回答内に同じサイトの異なる URL が複数出ても 1 回とカウントされることがある。一方、ページテーブルでは各 URL が個別に 1 回ずつ計上されるケースもある。
つまり、ページレベルの表示回数を足し上げた合計が、必ずしもプロパティ合計と一致しない。これは集計単位の違いによるもので、数値に矛盾があるわけではない。
従来の検索との違いと混同禁止
従来の検索結果での表示回数は、検索結果リスト内の 1 つの掲載としてユーザーが認識しやすい。一方、AI Overviews や AI Mode の表示は、合成された回答文の一部として現れる。リンクが目立つ場合もあれば、折りたたまれた引用リストの中に埋もれている場合、フォローアップの質問の後に出現する場合もある。
また、AI Overviews ではリンクがスクロールされるか展開されるまで表示回数としてカウントされない。AI Mode ではフォローアップの質問が新しいクエリとして扱われ、後続の回答で表示されたリンクが追加の表示回数を生む。
これらの違いから、生成 AI の表示回数と通常の検索表示回数を合算して「総検索可視性」のように扱うのは全くの誤りだ。CTR のブレンド計算も同様に意味をなさない。レポート画面で数字が並んでいても、それらは性質の異なる指標であることを肝に銘じたい。
このレポートで診断できること
このレポートの真価は、表示回数の総数ではなく、どのページが生成 AI 検索で使われているかを通常の検索パフォーマンスと比較できる点にある。
これは概念図だが、レポートの表示回数を通常の Search Console の検索パフォーマンスと並べて分類すると、上記の4パターンに整理できる。それぞれ次のような特徴がある。
高オーガニック表示・低AI表示のページ
通常検索ではよく見られていても、生成 AI の回答にはあまり使われないページだ。必ずしも問題とは限らない。クエリ自体が AI 応答を引き起こさないケースもある。しかし、次のような点を確認すると原因が見えてくる。
- 具体的な質問に直接答えているか
- 見出し構造が整理されているか
- 重要な情報がテキストとして HTML 上に露出しているか（タブや画像、JavaScript に隠れていないか）
- AI 応答が発生しやすいクエリにマッチする内容か
通常のランキングで上位に上がる能力があっても、合成に使えるクリーンな回答を提供できなければ、AI 表示にはつながりにくい。
低オーガニック表示・高AI表示のページ
こちらの方が注目に値する。通常の検索では目立たずとも、生成 AI で高い頻度で表示されるページがある。定義や統計、比較、説明が明快なコンテンツがこれにあたる。
こうしたページを分析すると、以下の共通点が見えてくることが多い。
- セクションの冒頭付近で直接的な回答を提示している
- 見出しの階層が明確で情報が取り出しやすい
- 独自の調査や一次情報を含んでいる
- 有益な表やリストがある
- トピックの範囲が絞られており、曖昧な表現が少ない
1 つの成功パターンを見つけたからといって、それを再生産すればうまくいくとは限らないが、サイト内で「Google が使いやすい」と判定している構造や表現のヒントになる。
ページ改修の効果を追う
コンテンツを大幅に修正した後に、AI 表示回数がどう変化するかをウォッチするのにも有用だ。たとえば以下のような改修が効果を持つ可能性がある。
- 明確な要約や定義を冒頭に追加
- 古い情報を更新し、鮮度を高める
- 重複したページを統合
- 見出しを書き直して情報の抽出を助ける
- 画像や動画に頼っていた重要情報を HTML テキストに移す
- 独自の証拠や専門家のコメントを加える
ただし、1 つの見出しを変えた翌週に数字が上がったからといって「AI 検索のアルゴリズムを解明した」と騒ぐのは禁物だ。需要や競合、AI 機能の出現頻度そのものが変動する。持続的な増加が確認できて初めて意味のあるシグナルとなる。
データを分析する実践ワークフロー
エクスポートと分類、従来データとの比較
分析は次の 6 ステップを踏むと整理しやすい。
- AI 表示回数の上位ページをエクスポート
意味のある期間を選ぶ。リリース直後の数日で判断しない。 - 同じ URL・期間で通常の検索パフォーマンスをエクスポート
通常の検索表示回数、クリック、CTR、平均順位、可能なら上位クエリを加える。比較することで、AI と通常検索で差があるページを特定できる。 - ページを属性で分類
ページタイプ、トピック、検索意図、テンプレート、著者、公開日、最終改訂日、ファネルステージなどを付与。URL と表示回数を並べただけでは分析にならない。 - 外れ値を調査
AI 表示回数が極端に高いページや低いページを探す。テンプレートやトピック、著者によってなぜ差が生まれるのかを実際に HTML 構造や本文を見て確認する。この段階で初めて手を動かす必要がある。 - アナリティクスのデータを別に確認
AI 経由のトラフィックやコンバージョンが特定できれば、表示回数がどの程度実際の訪問につながっているかを評価する。ただし Search Console と Analytics では計測方法が異なるため、数字のズレに一喜一憂しない。 - 日次の変動ではなくトレンドを追う
新しいデータは暫定的な数値の可能性もある。週次や月次で傾向を見るほうが建設的だ。1 日で上がった下がったに右往左往しない。
経営ダッシュボードに載せるべきではない指標
「AI」とラベルされた大きな数字が現れると、ダッシュボードの一番上に大きく表示したくなるものだ。しかし、生成 AI の表示回数はあくまで特定の状況でのリンク出現を示しており、ビジネス成果に直結するとは限らない。
以下のような報告は避けるべきだ。
- 生成 AI 表示回数と通常検索表示回数を合算した「総視認性」
- 両者をブレンドしたクリック率
- 自社の AI 表示回数だけを元にした「AI シェア」
- 表示回数に紐づけたコンバージョンの推測
- 1 つの最適化施策が効いたかのように見せるための表示回数の増加報告
- ページレベルの合計をプロパティ全体の露出と誤認させる表示
代わりに、ダッシュボードに盛り込むべきは「生成 AI 表示回数の推移」「表示回数がついたページ数」「表示されているトピック・ページタイプ」「AI 可視ページと通常検索パフォーマンスとの関係」「期間中に実施した改修」「AI 経由の識別可能なトラフィックやコンバージョン（分けて報告）」「追加調査が必要な仮説」といった項目だ。
この記事のポイント
- Search Console の新レポートで、AI Overviews と AI Mode の表示回数が通常検索と分離された
- 表示回数はクリックや引用位置の情報を含まず、あくまで「リンクが表示された」という指標である
- 従来の検索表示回数とは性質が異なり、合算やブレンド分析は誤解を招くため厳禁
- 通常検索との比較で、コンテンツの抽出しやすさや構造の課題を発見できる
- 分析の際は長期的なトレンドとページ属性の分類が不可欠で、数字の上下だけで施策の成否を判断しない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce Social Loginに深刻度9.8の脆弱性。管理者アカウント乗っ取りの危険
WooCommerce Social Loginプラグインに、未認証の攻撃者が任意のユーザーアカウントにログインできる重大な脆弱性が報告された。CVSSスコアは9.8と最高クラスの深刻度であり、管理者権限の奪取も可能になる。バージョン2.8.7以下を利用しているすべてのサイトが対象だ。
この脆弱性はAppleログイン処理に存在し、攻撃者は特別な権限を必要としない。正規のユーザーのメールアドレスさえ知っていれば、管理者を含む任意のアカウントに不正ログインできる。2026年8月1日に公開されたCVE-2026-8457として識別されており、即時対応が求められる。
深刻度9.8の認証バイパス脆弱性と影響範囲
Wordfenceのセキュリティ研究者によって発見されたこの脆弱性は、WooCommerce Social LoginのAppleサインイン機能に潜んでいた。ユーザーがAppleアカウントでログインする際、プラグインはAppleから返されるIDトークンの正当性を検証していなかった。このため攻撃者は、なりすましたいユーザーのメールアドレスを含む偽のトークンを作成し、認証をすり抜けられる。
被害を受けるのはWooCommerce Social Loginのバージョン2.8.7以下の全インストールだ。プラグインを有効化しているサイトであれば、特別な設定ミスがなくても攻撃が成立する。攻撃者はユーザー名やパスワードを一切知る必要がなく、標的のメールアドレスさえ分かれば管理者権限でログイン可能になる。
一般的なWordPressの脆弱性では、攻撃者が何らかの権限をあらかじめ持っていたり、管理者がリンクをクリックするなどの操作が必要になることが多い。しかし今回は、攻撃者が標的サイトにリクエストを送るだけで管理者アカウントにログインできてしまう。いわゆる「認証なしの管理者乗っ取り」に分類され、CVSS 9.8という評価はその直接的な危険性を反映している。
なぜこれほど危険なのか
認証バイパスにより管理者権限を取得した攻撃者は、WooCommerceサイトの全データを自由に操作できる。具体的には、顧客情報や注文データの窃取、不正な管理者アカウントの追加、プラグインやテーマの改ざんによるマルウェア注入、支払い情報への介入などが考えられる。さらに、サイトのSEO評価を意図的に下げるスパムリンクの埋め込みや、Googleからのインデックス削除といった攻撃も容易に行われてしまう。
WooCommerceを利用するECサイトでは、顧客の個人情報や購入履歴が保存されている。こうしたデータが流出した場合、個人情報保護法やGDPRなどの規制違反に発展する可能性もある。サイトの信用失墜だけでなく、法的なリスクや多額の損害賠償にまでつながりかねない。
WooCommerceのコア機能や他の決済プラグインでは、こうした認証処理に対する検証が厳格に行われている。しかし、Social LoginプラグインのAppleログイン部分だけが例外的に署名検証を欠いていた。そのため、攻撃の標的として非常に狙われやすい。
Appleログイン処理の具体的な問題点
Appleサインインでは、ユーザーが認証を完了すると、AppleのサーバーからIDトークンと呼ばれるデータがサイト側に送られる。このトークンにはユーザーのメールアドレスなどの情報が含まれ、改ざんを防ぐためにAppleの秘密鍵で電子署名が付与されている。プラグインは本来、Appleが公開している鍵を使ってこの署名を検証し、トークンが本物であることを確認しなければならない。
ところが、WooCommerce Social Loginはこの署名検証のステップを実装しておらず、受け取ったメールアドレスをそのまま信頼してログイン処理に使っていた。結果として、攻撃者が偽のIDトークンを作り、その中に標的ユーザーのメールアドレスを入れて送信するだけで、そのユーザーとして認証が通ってしまう状態になっていた。
Wordfenceの調査によると、管理者ロールかどうかのチェックも行われていなかった。攻撃者が管理者のメールアドレスを指定すれば、管理画面へのフルアクセスが即座に与えられる。これはIDトークンに含まれる「email」フィールドを、ログインにそのまま使う実装ミスに起因している。
つまり、IDトークンの署名確認という重要な防御ラインがまるごと欠落していたわけだ。この種の不備は、OpenID ConnectやOAuth 2.0を利用するソーシャルログイン実装では絶対にあってはならないものであり、Wordfenceの報告では「未認証の攻撃者が、偽造したid_tokenのペイロードに対象ユーザーの電子メールアドレスを含めて送信するだけで、管理者を含む任意のアカウントでログインできる」と指摘されている。
影響を受けるバージョンと今すぐ取るべき対策
この脆弱性の影響を受けるのは、WooCommerce Social Loginバージョン2.8.7以下のすべてのリリースだ。8月1日の公開後、プラグイン開発元はすぐに修正版2.8.8をリリースしている。Wordfenceは、該当バージョンを使用しているユーザーに対して、2.8.8またはそれ以降のバージョンへの即時アップデートを強く推奨している。
アップデートを適用しないまま放置すると、攻撃者に管理者権限を奪取された後に、バックドアを仕込まれたり、サイトの完全な乗っ取りが発生する可能性が高い。特にWooCommerceサイトでは決済情報や顧客データが絡むため、被害が拡大する前に一刻も早く更新を済ませてほしい。
- WordPress管理画面から「プラグイン」→「インストール済みプラグイン」を開く
- 「WooCommerce Social Login」を探し、利用可能なアップデートがあれば「今すぐ更新」をクリック
- バージョンが2.8.8以上になっていることを確認する
- 万が一、プラグインをすぐに更新できない事情がある場合は、一時的にプラグインを無効化する
また、サイトの管理者アカウントに不正なログインがなかったかどうか、アクセスログやユーザー一覧を至急確認してほしい。身に覚えのない管理者アカウントが追加されている場合は、すでに攻撃を受けている可能性がある。その場合は、プラグインの更新だけでなく、全ユーザーのパスワードリセットや、サイト全体のマルウェアスキャンも併せて実施する必要がある。
この記事のポイント
- WooCommerce Social Login 2.8.7以下にCVSS 9.8の認証バイパス脆弱性が存在する
- AppleログインのIDトークン署名検証が行われておらず、攻撃者が任意のユーザーになりすませる
- 管理者アカウントも標的になるため、ECサイトの全データが危険にさらされる
- 修正版2.8.8への即時アップデートが必須
- すでに攻撃を受けた可能性がある場合は、ユーザー一覧の確認とサイト全体のセキュリティチェックを推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験