Googleサーチコンソールの生成AIレポートが全世界展開。見方とオプトアウトの注意点
Googleサーチコンソールの生成AIレポートが、2026年8月31日付で全世界のサイトに展開された。AI OverviewsやAI Modeなど生成AI機能での表示回数を、ページ別・国別・日付別に確認できる。
一方で、クリックデータはまだ提供されていない。表示はされても実際のサイト訪問につながったかは分からない。この記事ではレポートの見方、オプトアウト設定の仕組み、SEO担当者が取るべき対応を整理する。
生成AIレポートの全体像
2026年6月から段階的に展開が始まった生成AIレポートは、8月31日付の公式注記で全世界のサイトに行き渡った。Search Consoleにログインすると、検索レポートとDiscoverレポートのそれぞれで生成AI関連のデータを確認できる。
レポートが対象とするのは、AI Overviews、AI Mode、Discoverの生成AI機能だ。AI Overviewsは検索結果の上部に生成AIが回答の要約を表示する機能を指す。AI Modeは対話形式で検索を続けられる専用モードだ。DiscoverはGoogleアプリのフィードで、ここにも生成AIによるコンテンツ表示が含まれる。
従来の検索ではクリックが発生してサイト訪問につながっていた。生成AI検索ではサイトが回答の参照元として表示されても、ユーザーがクリックするとは限らない。この違いがレポートの重要性を高めている。
レポートで確認できる指標
レポートには生成AI機能での表示回数、つまりインプレッションが記録される。検索レポートではページ別・国別・日付別に加えて、デバイス別の内訳も確認できる。Discoverレポートでも同様に、ページ・国・日付の切り口でデータを見られる。
たとえば、自社の記事がAI Overviewsの中でどの国で多く表示されているか、日を追って伸びているかを把握できる。特定のページが頻繁に参照されているなら、その分野のコンテンツが生成AIに評価されている可能性を示す。
クリックデータは含まれない
公開時点でレポートにクリックデータは含まれていない。クリック数やクリック率は確認できず、表示が実際のサイト訪問につながったのかは分からない。この制約は、レポートの活用方法を考えるうえで大きなポイントになる。
Googleはアクセスについても、すべてのプロパティに展開が完了したわけではないとヘルプページで説明している。AIインプレッションが十分に蓄積されていないサイトでは、レポート自体が表示されない可能性がある。
オプトアウト設定の仕組み
レポートと同時に提供されているのが「Search generative AI control」というオプトアウト設定だ。Search Consoleの設定画面に配置されており、プロパティ単位で有効にできる。この設定を使うと、AI Overviews、AI Mode、Discover生成AIの3つの表示面からサイトのリンクとコンテンツを除外できる。
オプトアウトしたサイトは、これらの生成AI機能からのトラフィックとインプレッションが一切発生しなくなる。Googleは公式発表で、この設定が通常の検索ランキングのシグナルとして使われることはないと明言している。生成AI機能に表示されないことが、通常の検索順位に影響することはないという意味だ。
レポートはこの3つの表示面を対象にインプレッションを集計する。オプトアウト設定も同じ3面が対象になるため、運用の判断ではこの対応関係を理解しておきたい。
設定の効果と影響範囲
オプトアウトはプロパティ単位で適用される。つまり、サイト全体がまとめて生成AI機能から除外される形だ。ページ単位で一部だけ除外するような細かい制御は、現時点では提供されていない。
除外を有効にすると、生成AI機能からの表示は完全に止まる。生成AI経由の露出をすべて断つことになるため、ブランド認知や間接的な流入を期待している場合は慎重な判断が求められる。
AIトレーニングとは別の設定
このオプトアウトは、生成AIの学習データへの利用を制御する仕組みとは別物だ。Googleの生成AIトレーニングへの利用可否は、Google-Extendedという別の制御で管理される。Search generative AI controlを有効にしても、AIトレーニングへの利用は止まらない。
「生成AI機能への表示」と「AIの学習利用」は異なる設定で管理されている。SEO担当者は、この2つを混同せずに運用方針を決める必要がある。
ここまでの展開経緯
生成AIレポートとオプトアウト設定は、2026年6月3日にGoogleから同時に発表された。当初は英国のウェブサイト運営者の一部を対象にした限定的なテストとして始まっている。
同日、英国の競争・市場庁（Competition and Markets Authority / CMA）は行動要件を発行した。Googleに対し、サイトが通常の検索結果でペナルティを受けることなくAI検索機能からオプトアウトできるようにすることを求めた。
6月の発表と英国限定テスト
6月の時点では、レポートとオプトアウト設定は英国の選ばれたサイト運営者にのみ提供された。規制当局の要求と同時期に動き出した形だ。検索市場における競争環境を意識した展開だったといえる。
7月以降の段階的な拡大
7月になると、英国以外のアカウントでも設定が表示され始めた。その後、8月31日付の注記で全世界のサイトへの展開が完了したとされた。ただし、ヘルプページには展開が進行中であるとの記載が残っており、実際のアクセスにはタイムラグがあるようだ。
なぜ重要なのか
レポートが見えるようになると、オプトアウトを判断する前に生成AI機能での表示状況を確認できる。これまではブラックボックスだったAI検索内での露出が、数字として見えるようになる。
ただし、インプレッションの真の価値はまだ明確ではない。表示回数が多くても、クリックにつながるかどうかは別の問題だ。生成AI検索では、ユーザーが回答だけで満足してサイトを訪れないケースが増えると指摘されている。
レポートで見えるのは表示回数のみ。実際のトラフィック効果を測るにはクリックデータが必要になる。SEO担当者はこの制約を踏まえたうえでデータを読む必要がある。
SEO担当者が取るべき対応
まずはSearch Consoleでレポートの有無を確認する。すでに表示されている場合は、どのページがどの表示面でインプレッションを得ているかを把握できる。AIインプレッションが少ないサイトでは、レポート自体が表示されないこともある。
表示回数が少ない場合や、自社ブランドと合わない文脈で引用されている場合は、オプトアウトを検討する余地がある。ただし、クリックデータがないため、露出を継続した場合の潜在的な影響を過小評価しないことも重要だ。
既存の検索パフォーマンスレポートと併用し、通常検索の推移と生成AI検索の露出を比較しながら総合的に判断する。オプトアウトはプロパティ単位でしか実行できないため、サイト全体への影響を考慮する必要がある。
インプレッションデータの限界
最大の限界は、クリック数が分からない点だ。表示回数が増えても、サイトへの訪問が増えていなければビジネス上の価値は低い。生成AI回答にサイトの情報が引用されても、ユーザーがリンクを押さなければ意味がない。
加えて、引用位置や文脈も確認できない。自社サイトが回答の根拠として適切に扱われているのか、単に名前が出ているだけなのかをレポートから読み取ることはできない。インプレッションの質を評価する材料が不足しているのが現状だ。
今後の展望
CMAは2027年3月までに、ページ単位の生成AI機能コントロールを導入するようタイムラインを設定している。現在のプロパティ単位の設定より細かい制御が求められている。
規制当局はクリックデータの提供も期待している。しかし、8月31日の更新ではクリックレポートへの言及はなかった。クリックデータが追加されれば、レポートの実用性は大きく高まる。
CMAの要求とタイムライン
ページ単位のコントロールは、サイト全体ではなく特定のページだけを生成AI機能から除外できる仕組みを指す。これが実現すれば、オプトアウトの判断がより柔軟になる。生成AI経由の露出を活かしたいページと、除外したいページを分けて運用できるようになる。
クリックデータ提供の行方
クリックデータが追加されるかは、現時点では未定だ。Googleは最初の1年間、コンプライアンス状況を6か月ごとに報告する義務を負っている。規制当局の継続的な監視が、レポートの改善を後押しする可能性は高い。
この記事のポイント
- 生成AIレポートは2026年8月31日付で全世界のサイトに展開された
- 対象はAI Overviews、AI Mode、Discover生成AIの3面で、ページ別・国別・日付別に表示回数を確認できる
- クリックデータはまだ提供されておらず、表示がトラフィックにつながるかは分からない
- オプトアウトはプロパティ単位で、検索ランキングには影響しないとGoogleが明言している
- CMAは2027年3月までにページ単位のコントロールを要求しており、今後の仕様変更に注意が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Rank Mathプラグインが管理者権限を無断取得か。WordPressセキュリティ問題
Rank Mathプラグインに重大なセキュリティ懸念が持ち上がっている。無料アカウントに連携した状態で「ヘルプ＆サポート」セクションを開くと、管理者権限を持つアプリケーションパスワードが無断で生成されるという指摘が、開発者コミュニティからあがった。
指摘したのは、競合するThe SEO Frameworkプラグインの開発者Sybre Waaijer氏だ。Rank Mathは400万以上のサイトで利用される人気プラグインであり、影響範囲は極めて広い。今回はこの問題の仕組みと、サイト運営者が取るべき対処法を整理する。
このデモは、Rank Mathが取っているとされる方式と、WordPress公式が定める方式の違いを図式化したものだ。無承認での生成が問題の核となっている。
Rank Mathプラグインに何が起きているのか
指摘の発端と具体的な動作
2026年8月30日、Search Engine JournalはRank Mathプラグインに関する新たな疑惑を報じた。The SEO Frameworkの開発者Sybre Waaijer氏が、Rank Mathの「ヘルプ＆サポート」セクションを開くだけで管理者権限が外部に渡ると指摘したのだ。
Waaijer氏によれば、Rank Mathは1.0.277へのアップデートでセキュリティ問題を修正した。しかし同じアップデートに、group.one（WP Rocketの所有者でもある企業）がサイトの管理者権限を取得できる機能が含まれていたという。
対象となるファイルは vendor/groupone/wap-client/includes/class-app-password-manager.php だ。無料のrankmath.comアカウントに接続されたサイトで、管理者が「ヘルプ＆サポート」を開くと、プラグインが即座に「WAP – Rank Math Support Agent」という名前のアプリケーションパスワードを生成する。そのパスワードはgroup.oneのサーバーへ送信され、同社のAIエージェントがユーザーに代わってサイトを操作できる状態になる。
許可なき権限委譲という問題
Waaijer氏は「プラグインは最初にユーザーへ確認しない。「利用規約」ボックスは表示されるが、パスワードの生成と送信を止めることはできない。送信はボックスが表示される前に始まっている」と説明している。
つまりユーザーは、何の操作もしないうちに、自分のサイトの管理者権限を第三者へ委譲してしまう。しかも、その事実を知らされることはない。ヘルプ＆サポートを閉じてもパスワードは失効せず、無期限に有効なままだ。
影響範囲と深刻度
Rank Mathは400万以上のサイトで利用されている。管理者権限があれば、プラグインの更新、テーマの変更、投稿の削除、ユーザー情報の閲覧といった、サイト運営の中核的な操作が可能になる。これはSEOプラグインの枠を超えた、サイト全体の安全性に関わる問題だ。
問題の中核にあるアプリケーションパスワードとは
WordPress標準の正当な仕組み
WordPressアプリケーションパスワードは、WordPressコアに含まれる正規の機能である。外部アプリケーションがWordPressサイトへ安全に接続するための仕組みで、ユーザーはいつでも個別に取り消せる。プラグインがこの仕組みを利用すること自体は、公式に認められている。
重要なのは、公式の仕様ではアプリケーションパスワードを発行する前に、必ず承認画面が表示されることだ。ユーザーがプラグインの身元を確認し、接続を許可するか拒否するかを選べる。パスワードがプラグインに渡るのは、ユーザーが承認した後でなければならない。
Rank Mathがガイドラインから外れている点
Rank Mathの動作は、この公式プロセスを完全に飛ばしている。承認画面は表示されず、ユーザーが何かをクリックする前にパスワードが生成され、外部サーバーへ送信される。Waaijer氏が指摘する通り、過去に同氏が「バックドア」と分類したものと構造が似ている。
WordPress.orgのプラグインガイドラインでは、外部サーバーと通信する際にはユーザーの明示的な同意が必要だと定められている。オプトインのチェックボックスや、サービスへの登録を経た同意が求められるのだ。Rank Mathの実装は、この原則に真っ向から反している。
取り消し方法が明示されない
アプリケーションパスワードは本来、ユーザーが確認して取り消せることを前提にしている。しかしRank Mathの場合、「ヘルプ＆サポート」を開いただけでは、パスワードが発行された事実に気づく手がかりがない。プロフィール画面に「WAP – Rank Math Support Agent」という名前で表示されるため、知っていれば探せるが、知らなければ発見は難しい。
ユーザーコミュニティの反応
ソーシャルメディア上の反応は、一貫して否定的だった。一部のユーザーはWordPressコアにSEO機能を統合すべきだと主張し、別のユーザーはRank Mathから別のSEOプラグインへ移行する意思を示した。
フォーラムスレッド削除の疑惑
議論の中で、Rank Mathの公式フォーラムに大きなスレッドが立っていたが、その後削除されたという報告もあった。ユーザーの一人は「数日前にフォーラムで大きなスレッドが立っていたが、今日削除通知が来た。ユーザーフォーラムが大荒れになった後に削除されたようだ」と述べている。
もし事実なら、これはコミュニティの懸念を正面から受け止めていない姿勢と映る。透明性を求める声に対して、静かな対処を選んでいるように見えるからだ。
ユーザーが感じている不信感
「管理者アクセスが無断で？」という短い反応に、多くのユーザーの驚きが凝縮されている。SEOプラグインは検索順位を改善するための道具であって、サイトの制御権を委譲するものではない。誰もがそう考えていたからこそ、今回の発覚は衝撃を持って受け止められた。
Rank Mathの過去の脆弱性と信頼性
脆弱性の履歴
Rank Mathは2024年に7件、2025年に4件、2026年に入って3件の脆弱性が発見されている。直近では、認証されていない状態で保存型クロスサイトスクリプティング（XSS）を実行される脆弱性も報告されていた。
1つのプラグインにこれだけの脆弱性が続くこと自体が、セキュリティ管理の甘さを示す。その上に今回の無断権限取得が加われば、信頼はさらに揺らぐ。
Search Engine Journalの推奨リストから外れている
Search Engine Journalは、自社の推奨WordPressプラグインリストにRank Mathを含めていない。推奨条件の1つが「脆弱性の履歴がないこと」であり、Rank Mathはこの基準を満たせていないためだ。
プラグインの選択では、機能の豊富さだけでなく、セキュリティ面の信頼性を確認することが重要になる。今回の件は、その判断基準を改めて浮き彫りにした。
WordPressサイト運営者が取るべき対処法
まずはパスワードを取り消す
Rank Mathを利用していて、無料アカウントに接続した状態で「ヘルプ＆サポート」を開いたことがあるなら、すぐにアプリケーションパスワードを取り消すべきだ。Waaijer氏が具体的な手順を示している。
- WordPress管理画面の「ユーザー」から「プロフィール」を開く
- 「アプリケーションパスワード」セクションを確認する
- 「WAP -」で始まるパスワードをすべて取り消す
この操作により、Rank Mathのサポートエージェントが保持している管理者権限を無効化できる。手順は数分で済むが、放置すればリスクは残り続ける。
接続解除と設定の見直し
Rank Mathアカウントとの接続を解除することも有効な対策だ。接続していなければ、ヘルプ＆サポートを開いてもパスワードは生成されない。必要になるまで無料アカウントへの接続を切っておくのが無難だ。
また、プラグインの権限設計そのものを見直す機会にしてほしい。管理者以外のユーザーがプラグイン設定を触れるようになっていないか、不要なプラグインが残っていないかを確認する。サイトのセキュリティは、積み重ねた小さな確認で守られる。
他プラグインの移行を検討する
今回の件を受けて、別のSEOプラグインへの移行を検討するユーザーも増えている。The SEO FrameworkやYoast SEOなど、信頼性の高い選択肢は複数ある。重要なのは、移行前に既存の設定やリダイレクト情報をバックアップしておくことだ。
上記のステップを順に実行することで、無断で付与された権限を無効化し、今後のリスクを低減できる。最初のステップが最も緊急性が高い。
この記事のポイント
- Rank Mathはヘルプ＆サポートを開くと管理者権限のアプリケーションパスワードを無断生成すると指摘された
- 承認画面なしでパスワードが外部サーバーへ送信される仕組みはWordPress公式ガイドラインに違反する
- Rank Mathは2024年から2026年にかけて合計14件の脆弱性が報告されている
- 利用者は「ユーザー → プロフィール → アプリケーションパスワード」から「WAP -」をすべて取り消すべき
- アカウント接続の解除と他SEOプラグインへの移行も有効な対策になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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最適化の豊富な経験