タグアーカイブ Google

2026年8月スパムアップデート開始!Google検索への影響と対策を解説

2026年8月スパムアップデート開始!Google検索への影響と対策を解説

Googleが2026年8月18日、8月のスパムアップデートの展開を開始した。全言語・全地域が対象で、完了までに数日かかる見込みだ。Search Status Dashboardにランキングへ影響を与えるインシデントとして記録されている。

これは2026年に入って3回目のスパムアップデートとなる。3月の更新は過去最速の19時間30分で完了し、6月の更新は生成AI検索への操作対策もスパムポリシーの対象に含める方針が示された直後に行われた。

検索順位に動きが出た場合、スパムポリシー違反がないか確認することが重要になる。復旧には数ヶ月かかることもあるため、早期の対応が求められる。

8月スパムアップデートの概要

8月スパムアップデートの概要

今回のアップデートは太平洋時間8月18日午前9時27分に開始された。日本時間では8月19日午前1時27分となる。Search Status Dashboardには開始時刻の約1分後、午前9時28分にリリースノートが掲載された。

適用範囲は全世界・全言語だ。Googleは完了までに数日かかる可能性があると案内している。この種のアップデートは、展開中に順位の変動が大きくなることがある。短期間のデータだけで判断せず、数日単位で傾向を見る必要がある。

公開時点では、Search Status Dashboardの注記に加えて公式ブログ記事は投稿されていない。スパムアップデートの概要ページも2025年12月から変更されていない。今回は新しいスパムポリシーの種類は追加されていない。既存のポリシーがそのまま判断基準になる。

STEP 1 8月18日 9:27 AM PDT に展開開始
STEP 2 全言語・全地域に適用される
STEP 3 数日かけて展開が完了する見込み
STEP 4 完了後にSearch Status Dashboardで通知される

このデモは8月スパムアップデートの展開フローを示している。各ステップの色分けは進行段階を表しており、青が開始、緑が適用範囲、橙が展開期間、紫が完了通知を意味する。

2026年のスパムアップデート史

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月スパムアップデート
完了までの時間 19時間30分
過去最速の完了記録。短期間に順位変動が集中した。
2026年6月スパムアップデート
完了までの時間 2日と1時間
5月の生成AI検索操作対策の方針明確化の直後に実施された。
2026年8月スパムアップデート
完了までの時間 数日かけて展開中
新ポリシーの追加はなし。既存ポリシーが判断基準。

このデモは2026年に実施された3回のスパムアップデートを比較したものだ。青が3月、緑が6月、橙が8月を表す。完了までの時間が回を追うごとに長くなる傾向が見える。

サイト運営者が取るべき行動

サイト運営者が取るべき行動

スパムアップデートの展開中は、検索順位が一時的に変動することがある。1日だけのデータで判断せず、Search Consoleのデータを数日分確認するのが基本だ。特に8月18日以降の動きに注目する必要がある。

Search Consoleで順位変動を確認する

順位の変動を確認するには、Search Consoleのパフォーマンスレポートが最も信頼できる。表示回数・クリック数・平均掲載順位を日別で確認し、8月18日以降に急激な変化が出ていないかを見る。

もし変動が見つかったら、それがスパムアップデートの影響なのか、他の要因によるものなのかを切り分ける必要がある。季節要因や自サイトの変更、競合サイトの動きなども同時に確認することだ。

STEP 1 Search Consoleにログインする
STEP 2 パフォーマンスレポートを開く
STEP 3 8月18日以降のデータを日別で確認する
STEP 4 急激な変動があればスパムポリシー違反を確認する

このデモは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日以降のデータを確認する
  • スパムポリシー違反からの復旧には数ヶ月かかることがある
GoogleのAI責任者ジェフ・ディーン氏が退任、新会社を設立。AI研究の巨人の軌跡とSEOの今後

GoogleのAI責任者ジェフ・ディーン氏が退任、新会社を設立。AI研究の巨人の軌跡とSEOの今後

GoogleのアルファベットCEO、サンダー・ピチャイ氏が2026年8月5日、大規模な組織改編と重要人物の退任を発表した。今回のニュースの核心は、27年にわたりGoogleの検索基盤と現代のAI技術を支えてきたチーフサイエンティスト、ジェフ・ディーン氏が退任し、新会社を設立することだ。

彼の退任は、単なる一社の人事異動ではない。TensorFlowの共同発明、知識蒸留の概念、MapReduceといった、今日の検索エンジンと生成AIの土台そのものを築いた人物の離脱である。この記事では、今回の発表内容、ディーン氏の技術的遺産、そしてこの出来事がSEO業界に投げかける長期的な影響を読み解く。

Google DeepMind新体制とデミス・ハサビス氏の役割拡大

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研究の成果を検索やクラウドだけでなく、より実体経済に近い分野へと応用する段階に入ったことを示唆している。

変更前の体制(2025年)
ジェフ・ディーン Googleチーフサイエンティスト
デミス・ハサビス Google DeepMind CEO
コライ・カブクチュオール DeepMind CTO / チーフAIアーキテクト
変更後の体制(2026年8月発表)
新会社 ジェフ・ディーンとサンジェイ・ゲマワットがDiscovery Loopを設立
デミス・ハサビス Alphabet チーフサイエンティスト / DeepMind会長に就任
コライ・カブクチュオール DeepMind SVPに昇格、日々の業務を統括
前体制の重要人物  今回の退任者と動向  拡大する役割  現場統括

ジェフ・ディーン氏の退任とその考古学的な功績

ジェフ・ディーン氏の退任とその考古学的な功績

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に代表される大規模言語モデルの急速な発展はありえなかった。

2004年 MapReduceがビッグデータ分散処理の基盤を創出
2006年 Bigtableが超大規模ウェブインデックスを可能に
2012年 DistBeliefが深層学習の大規模化への道を拓く
2015年 知識蒸留により、軽量AIモデルへの技術継承が現実に
2016年 TensorFlowが現代のAI開発を支える共通基盤に
分散処理  インデックス  大規模学習  軽量化  AI民主化

今回の退任がSEOとサイト運営に与える長期的な影響

今回の退任が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社内 研究者が閉じた環境で研究
※成果はすべてGoogle社内に蓄積され、製品化の方向性は会社の戦略と直結する。
新しいハイブリッド研究エコシステム
Discovery Loop社 独立した公益法人として基礎研究を推進
Google 出資者・クラウドパートナーとして協業。成果はエコシステム全体で共有
※基礎研究の成果が、よりオープンに、かつGoogleの製品へ還元される経路が生まれる。
旧モデル  新モデル  独立組織  既存組織

この記事のポイント

  • Googleのチーフサイエンティスト、ジェフ・ディーン氏が27年のキャリアに幕を下ろし、AI研究の新会社「Discovery Loop」を設立。
  • ディーン氏はMapReduce、Bigtable、TensorFlow、知識蒸留など、現代の検索とAIの基盤技術を数多く発明。事実上の「検索エンジンの父」の一人。
  • 後任のハサビス氏はDeepMind会長兼アルファベット全体のチーフサイエンティストとなり、医薬品開発などAIの応用領域を拡大する方針。
  • この人事は、GoogleのAI研究が「基盤づくり」から「応用と収益化」へとフェーズを移行させるシンボリックな出来事。
  • SEO実務者にとっては、AI Overviewsの高度化など、検索体験のさらなる変貌を前提とした長期的視点でのサイト運営がこれまで以上に求められる。
GoogleサーチコンソールにAI検索レポート登場。見るべきポイントと活用術

GoogleサーチコンソールにAI検索レポート登場。見るべきポイントと活用術

Google は 2026 年 6 月 3 日、Search Console に生成 AI 専用のパフォーマンスレポートを追加した。AI Overviews(AI 概要)や AI Mode(AI モード)といった検索体験の一部として、自社サイトの URL がどの程度表示されたかを切り分けて確認できるようになっている。

これまで「AI 検索に自社のコンテンツが出ているのかどうか」は、通常の検索パフォーマンスの数字に埋もれてわからなかった。今回の分離によって、どのページが生成 AI の回答元として使われているのかを確認できるようになったが、あくまで「表示回数」ベースのデータであり、クリックや引用のされ方までは把握できない点に注意が必要だ。

この記事では、新レポートで何が読み取れるのか、従来の検索表示回数とどう違うのか、そして実際にサイト改善に役立てるための診断フローを解説する。

AI検索レポート、ついに独立

AI検索レポート、ついに独立

生成AI専用レポートの概要

この新しい Search レポートは、AI Overviews と AI Mode からの表示回数のみを集計する。Discover 向けの生成 AI 機能は別レポートとして提供されている。また、Labs の実験的機能は対象外だ。

レポートでは、URL 単位、国別、デバイス別、日付別に表示回数をセグメントできる。ただし現時点では、以下の指標は含まれていない。

  • 検索クエリ
  • クリック、クリック率(CTR)
  • 平均掲載順位
  • 引用の位置(回答内でリンクがどの順序で表示されたか)
  • 回答の基となった文章の特定
  • コンバージョンや収益データ

Google は「今後、追加指標の要望をサイト運営者とともに検討する」と述べており、機能拡張の可能性はある。また、AI Overviews や AI Mode にコンテンツを含めるかどうかを制御する新しい設定も Search Console でテスト中だ。デフォルトは「含める」で、オプトアウトすると従来の検索結果には影響なく、生成 AI の回答からも自社コンテンツが除外される。

まずは「どの部分が使われているか」を把握するために

現時点のレポートが答えられるのは「サイトのどのページが生成 AI の表示に使われているのか、どのくらいの頻度か」という問いだ。それ以上の詳細は得られないが、この可視化だけでもこれまでにない手がかりになる。

AI表示回数は従来の表示回数とは異なる

AI表示回数は従来の表示回数とは異なる

表示回数の数え方の基本

Google の定義では、AI 表示回数とは「生成 AI の機能内でユーザーにリンクが表示された回数」を指す。集計方法はレベルによって異なり、グラフのプロパティ全体では、1 つの回答内に同じサイトの異なる URL が複数出ても 1 回とカウントされることがある。一方、ページテーブルでは各 URL が個別に 1 回ずつ計上されるケースもある。

つまり、ページレベルの表示回数を足し上げた合計が、必ずしもプロパティ合計と一致しない。これは集計単位の違いによるもので、数値に矛盾があるわけではない。

従来の検索との違いと混同禁止

従来の検索結果での表示回数は、検索結果リスト内の 1 つの掲載としてユーザーが認識しやすい。一方、AI Overviews や AI Mode の表示は、合成された回答文の一部として現れる。リンクが目立つ場合もあれば、折りたたまれた引用リストの中に埋もれている場合、フォローアップの質問の後に出現する場合もある。

また、AI Overviews ではリンクがスクロールされるか展開されるまで表示回数としてカウントされない。AI Mode ではフォローアップの質問が新しいクエリとして扱われ、後続の回答で表示されたリンクが追加の表示回数を生む。

これらの違いから、生成 AI の表示回数と通常の検索表示回数を合算して「総検索可視性」のように扱うのは全くの誤りだ。CTR のブレンド計算も同様に意味をなさない。レポート画面で数字が並んでいても、それらは性質の異なる指標であることを肝に銘じたい。

このレポートで診断できること

このレポートで診断できること

このレポートの真価は、表示回数の総数ではなく、どのページが生成 AI 検索で使われているかを通常の検索パフォーマンスと比較できる点にある。

AI 表示回数と通常検索表示の4象限
高オーガニック表示・低AI表示
通常検索では上位だが、生成AIにはあまり使われないページ。情報が回答として抽出しにくい可能性
低オーガニック表示・高AI表示
通常検索では控えめだが、AIには頻出。有用な定義や統計など、抽出しやすいコンテンツが多い
高オーガニック表示・高AI表示
いずれも良好。ページの質が高く、合成にも向く可能性。強みのトピックとして要分析
低オーガニック表示・低AI表示
検索上もAI上も見えていない。コンテンツの根本的な見直し候補
■ 高(上) ■ 低(下) ■ 問題あり ■ 好材料

これは概念図だが、レポートの表示回数を通常の Search Console の検索パフォーマンスと並べて分類すると、上記の4パターンに整理できる。それぞれ次のような特徴がある。

高オーガニック表示・低AI表示のページ

通常検索ではよく見られていても、生成 AI の回答にはあまり使われないページだ。必ずしも問題とは限らない。クエリ自体が AI 応答を引き起こさないケースもある。しかし、次のような点を確認すると原因が見えてくる。

  • 具体的な質問に直接答えているか
  • 見出し構造が整理されているか
  • 重要な情報がテキストとして HTML 上に露出しているか(タブや画像、JavaScript に隠れていないか)
  • AI 応答が発生しやすいクエリにマッチする内容か

通常のランキングで上位に上がる能力があっても、合成に使えるクリーンな回答を提供できなければ、AI 表示にはつながりにくい。

低オーガニック表示・高AI表示のページ

こちらの方が注目に値する。通常の検索では目立たずとも、生成 AI で高い頻度で表示されるページがある。定義や統計、比較、説明が明快なコンテンツがこれにあたる。

こうしたページを分析すると、以下の共通点が見えてくることが多い。

  • セクションの冒頭付近で直接的な回答を提示している
  • 見出しの階層が明確で情報が取り出しやすい
  • 独自の調査や一次情報を含んでいる
  • 有益な表やリストがある
  • トピックの範囲が絞られており、曖昧な表現が少ない

1 つの成功パターンを見つけたからといって、それを再生産すればうまくいくとは限らないが、サイト内で「Google が使いやすい」と判定している構造や表現のヒントになる。

ページ改修の効果を追う

コンテンツを大幅に修正した後に、AI 表示回数がどう変化するかをウォッチするのにも有用だ。たとえば以下のような改修が効果を持つ可能性がある。

  • 明確な要約や定義を冒頭に追加
  • 古い情報を更新し、鮮度を高める
  • 重複したページを統合
  • 見出しを書き直して情報の抽出を助ける
  • 画像や動画に頼っていた重要情報を HTML テキストに移す
  • 独自の証拠や専門家のコメントを加える

ただし、1 つの見出しを変えた翌週に数字が上がったからといって「AI 検索のアルゴリズムを解明した」と騒ぐのは禁物だ。需要や競合、AI 機能の出現頻度そのものが変動する。持続的な増加が確認できて初めて意味のあるシグナルとなる。

データを分析する実践ワークフロー

データを分析する実践ワークフロー

エクスポートと分類、従来データとの比較

分析は次の 6 ステップを踏むと整理しやすい。

  1. AI 表示回数の上位ページをエクスポート
    意味のある期間を選ぶ。リリース直後の数日で判断しない。
  2. 同じ URL・期間で通常の検索パフォーマンスをエクスポート
    通常の検索表示回数、クリック、CTR、平均順位、可能なら上位クエリを加える。比較することで、AI と通常検索で差があるページを特定できる。
  3. ページを属性で分類
    ページタイプ、トピック、検索意図、テンプレート、著者、公開日、最終改訂日、ファネルステージなどを付与。URL と表示回数を並べただけでは分析にならない。
  4. 外れ値を調査
    AI 表示回数が極端に高いページや低いページを探す。テンプレートやトピック、著者によってなぜ差が生まれるのかを実際に HTML 構造や本文を見て確認する。この段階で初めて手を動かす必要がある。
  5. アナリティクスのデータを別に確認
    AI 経由のトラフィックやコンバージョンが特定できれば、表示回数がどの程度実際の訪問につながっているかを評価する。ただし Search Console と Analytics では計測方法が異なるため、数字のズレに一喜一憂しない。
  6. 日次の変動ではなくトレンドを追う
    新しいデータは暫定的な数値の可能性もある。週次や月次で傾向を見るほうが建設的だ。1 日で上がった下がったに右往左往しない。

経営ダッシュボードに載せるべきではない指標

経営ダッシュボードに載せるべきではない指標

「AI」とラベルされた大きな数字が現れると、ダッシュボードの一番上に大きく表示したくなるものだ。しかし、生成 AI の表示回数はあくまで特定の状況でのリンク出現を示しており、ビジネス成果に直結するとは限らない。

以下のような報告は避けるべきだ。

  • 生成 AI 表示回数と通常検索表示回数を合算した「総視認性」
  • 両者をブレンドしたクリック率
  • 自社の AI 表示回数だけを元にした「AI シェア」
  • 表示回数に紐づけたコンバージョンの推測
  • 1 つの最適化施策が効いたかのように見せるための表示回数の増加報告
  • ページレベルの合計をプロパティ全体の露出と誤認させる表示

代わりに、ダッシュボードに盛り込むべきは「生成 AI 表示回数の推移」「表示回数がついたページ数」「表示されているトピック・ページタイプ」「AI 可視ページと通常検索パフォーマンスとの関係」「期間中に実施した改修」「AI 経由の識別可能なトラフィックやコンバージョン(分けて報告)」「追加調査が必要な仮説」といった項目だ。

この記事のポイント

  • Search Console の新レポートで、AI Overviews と AI Mode の表示回数が通常検索と分離された
  • 表示回数はクリックや引用位置の情報を含まず、あくまで「リンクが表示された」という指標である
  • 従来の検索表示回数とは性質が異なり、合算やブレンド分析は誤解を招くため厳禁
  • 通常検索との比較で、コンテンツの抽出しやすさや構造の課題を発見できる
  • 分析の際は長期的なトレンドとページ属性の分類が不可欠で、数字の上下だけで施策の成否を判断しない
クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法

クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法

Googleがクロールインフラストラクチャの公式ドキュメントを更新し、「クロールバジェットの最適化」に関する新たなガイドラインを公開した。ECサイト運営者にとって、この変更は商品ページのインデックス速度に直結する。クロールされなければ検索結果に表示されないからだ。

今回の更新で注目すべきは、新サイトに割り当てられる「保守的なクロールバジェット」の考え方と、304ステータスコードに関する注意喚起だ。特に304の扱いは、安易に導入すると検索順位に影響を与える可能性がある。

この記事では、Googleの新ガイドラインの要点と、ECサイトが実践すべきクロールバジェット最適化の手法を解説する。

クロールバジェットとは何か

クロールバジェットとは何か

クロールバジェットとは、Googlebotが一定期間内に特定のサイトをクロールするURLの総量を指す。インターネット上のURL数は膨大であり、Googleは各サイトに割り当てるクロール量を最適化する必要がある。この割り当てが「バジェット(予算)」と呼ばれる理由だ。

サイト構造が整理されておらず、無駄なURLが多いサイトは、クロールに時間がかかり、結果としてインデックスされるページ数が少なくなる。ECサイトの場合、商品ページがインデックスされなければ、検索経由の流入機会を失うことになる。

クロールバジェットが無駄に使われるサイト
Googlebot 重複ページ ソフト404 無駄なパラメータURL
※クロールの大半が無駄なURLに消費され、重要な商品ページまで到達できない
Googlebotが無駄なURLを巡回
クロールバジェットが最適化されたサイト
Googlebot 新着商品ページ 更新されたカテゴリ ブログ記事
※無駄なURLが除外され、重要なページだけがクロールされる
重要なページを効率的に巡回

クロールバジェットを意識したサイト設計は、検索エンジンに「このサイトは効率的にクロールできる」と認識させる第一歩だ。以下、Googleの新ガイドラインに沿った具体的な施策を見ていく。

新サイトには保守的なクロールバジェットが割り当てられる

新サイトには保守的なクロールバジェットが割り当てられる

Googleの更新されたドキュメントで明確にされたのが、新規サイトに対するクロールバジェットの初期値だ。新サイトには「保守的な」バジェットが割り当てられ、サーバーに過負荷をかけずに重要なコンテンツをカバーできるよう設計されている。

段階的なコンテンツ公開が鍵

新サイトを立ち上げる際は、一度に大量のページを公開するよりも、徐々にページ数を増やす方がGooglebotの信頼を得やすい。たとえば、100商品を1日で公開するより、1日3商品ずつ約1ヶ月かけて公開する方が、クロールバジェットの観点からは有効だ。

STEP 1 新サイト公開(少数の重要ページのみ)
Googlebotがサーバー負荷を確認しながら巡回開始
STEP 2 1日数商品ずつ追加公開
XMLサイトマップを更新し、Googleに変更を通知
STEP 3 定期的な更新を継続
Googlebotの巡回頻度が徐々に増加
STEP 4 クロールバジェットの拡大
信頼が確立され、より多くのページが巡回対象に

この段階的アプローチにより、Googlebotはサイトの更新パターンを学習し、クロールバジェットを徐々に拡大していく。XMLサイトマップの自動更新と組み合わせることで、さらに効果が高まる。

表示速度の改善がバジェットを増やす

サイトの読み込み速度が速いほど、Googlebotは効率的にクロールできる。これは以前から知られていた事実だが、今回のガイドラインでも改めて強調された。表示速度の改善は、ユーザー体験の向上だけでなく、クロールバジェットの増加にも直結する。

Googleが提供するPageSpeed InsightsやLighthouseを使って定期的にパフォーマンスを測定し、改善を続けることが重要だ。ECサイトでは、画像の最適化や不要なスクリプトの削減が特に効果的だ。

人気ページはクロール頻度が高まる

外部リンクや内部リンクを多く集めているページは、Googlebotの巡回頻度が高くなる。ECサイトの場合、トップページや主要カテゴリページ、よく参照される商品ページが該当する。内部リンク構造を最適化し、重要なページへリンクを集中させることで、クロール頻度を向上させられる。

クロール効率を下げる要因とその対策

クロール効率を下げる要因とその対策

クロールバジェットを浪費する要因はいくつかある。以下に主要なものと対策を示す。

robots.txtで不要ページをブロック

プライベートログインページ、ショッピングカート、動的に生成されるページなど、インデックス不要なページはrobots.txtのdisallowディレクティブでブロックする。これにより、Googlebotが本当に重要なページだけを巡回するよう誘導できる。

重複コンテンツの削除と統合

同じ内容のページが複数存在すると、クロールバジェットが分散される。商品バリエーション(色違い、サイズ違い)でURLが分かれている場合は、canonicalタグで正規URLを指定するか、統合を検討する。

ソフト404とリダイレクトチェーンを回避

削除されたページが200ステータスコードを返す「ソフト404」は、Googlebotが無駄なクロールを続ける原因となる。存在しないページは404または410レスポンスを返すように設定する。また、1つのページに対して複数のリダイレクトが発生する「リダイレクトチェーン」も、クロール効率を低下させるため避けるべきだ。

Search Consoleのクロール統計を活用

Google Search Consoleの「設定」→「クロール統計」レポートでは、Googlebotのクロール頻度や発生した問題を確認できる。このレポートを定期的にチェックし、クロールバジェットの消費状況を把握することが、最適化の出発点となる。

304ステータスコードの注意点

304ステータスコードの注意点

今回のガイドライン更新で追加されたのが、304(Not Modified)ステータスコードに関する推奨だ。Googleは「前回のクロールからページが変更されていない場合、304コードを返すことでGoogleにキャッシュ版の再利用を促し、サーバー帯域とリソースを節約できる」としている。

しかし、この推奨には注意が必要だ。Practical Ecommerceの記事では、Jill Kocher氏が次のような見解を示している。304コードを重要なページに使用すると、検索結果での表示順位やインデックスステータスに影響を与える可能性がある。同氏は、期限切れ商品やポリシーページなど、重要性の低いページに限定して使用することを推奨している。

304コードを重要な商品ページに使った場合のリスク
Googlebot 304 Not Modified
※キャッシュが再利用され、実際のコンテンツ更新が検出されないおそれ
⚠ 表示順位の低下やインデックスステータスへの悪影響の可能性
リスクあり(重要ページには非推奨)
304コードの安全な使用例
期限切れ商品 プライバシーポリシー
※検索順位に影響しないページに限定して使用
✅ サーバーリソースの節約に貢献
安全に使用可能

ECサイト運営者としては、この304コードの推奨を鵜呑みにせず、自社のSEO戦略に照らして慎重に判断する必要がある。売上に直結する商品ページやカテゴリページには適用せず、重要度の低い固定ページに限定するのが賢明だ。

この記事のポイント

  • 新サイトのクロールバジェットは「保守的」に設定されるため、段階的なコンテンツ公開が有効
  • 表示速度の改善と定期的な更新が、クロールバジェット拡大の鍵
  • robots.txtの活用、重複コンテンツの統合、ソフト404の排除で無駄なクロールを削減
  • Search Consoleのクロール統計レポートで状況を定期的にモニタリング
  • 304ステータスコードは重要ページには使用せず、影響の少ないページに限定する
AI時代のブランド監査、ローカルビジネスに必要なSEO戦略とは

AI時代のブランド監査、ローカルビジネスに必要なSEO戦略とは

AIがビジネスの評判を決める時代に入った。検索窓に質問を打ち込むユーザーは、もはやリンクのリストをクリックしない。AIが瞬時に要約した「答え」だけを見て、店を選び、サービスを予約する。この変化はローカルビジネスの集客構造を根底から揺るがしている。

GatherUpが2025年秋に集計したデータによると、消費者の55%がGoogleやBingのAI要約を参照し、48%がChatGPTに地域ビジネスについて質問した経験を持つ。さらに31%は複数回質問している。問題は、AIが提示する「おすすめ」が、必ずしも最高評価の店舗ではないことだ。

実際の検索で起きた象徴的な事例がある。バージニア州ノーフォークで「SUVが入る非接触洗車機」をGoogleに尋ねたユーザーに対し、AIは評価3.3の店舗を提示した。検索クエリとのマッチ度が、星評価より優先されたのである。この事実は、AI時代のローカルSEO戦略が星集めだけでは成立しないことを示している。

AIは地域ビジネスをどう探すようになったか

AIは地域ビジネスをどう探すようになったか

従来のローカル検索は「近くのラーメン」という短いキーワードが主流だった。ユーザーはMapPackやオーガニック検索結果から複数店舗を見比べた。AI検索ではこの流れが完全に変わる。ユーザーは「子供連れでも入れて、駐車場があって、あっさり系の醤油ラーメンが人気の店」のように、自然言語で条件をすべて盛り込んだ質問を一度に投げる。

質問型クエリが標準になった

この変化を端的に表すのが洗車場の事例だ。検索クエリは「no-touch car wash for my SUV in Norfolk, VA」。車種、洗車方式、場所、すべてが1文に含まれている。Googleは保有する3億件の施設データと5億人のレビュー投稿者情報を即座に処理し、1件の店舗を返した。

注目すべきは、この店舗の評価が3.3だった点である。GatherUpのアニー・ジャクソン氏(収益オペレーション&成長担当ディレクター)はSearch Engine Journalの記事で「Googleは私の質問に答えましたが、このビジネスは3.3つ星なのです。星評価よりクエリの文脈が優先されたのです」と指摘している。

従来の検索行動(Before)
ユーザー 「近くの洗車場」
複数店舗のリストから選ぶ
各店舗のサイトを訪問して情報収集
AI検索の行動(After)
ユーザー 「SUV対応の非接触洗車 ノーフォーク」
AIが1件に絞り込み即座に回答
車高制限や営業時間も本文中で提示
従来はユーザーの訪問と比較が必要  AIは処理を丸ごと代行する
※AI検索では1回の質問で店舗決定まで完結する

検索の文脈には時間帯やユーザーの属性も含まれる。Search Engine Journalの記事でジェイソン・ワーサム氏(レビューディフェンス運営担当VP)が警告しているように、LLMが「ユーザーはSUVを持っている」「大型犬を飼っている」といった情報を学習すると、以降の検索では毎回その文脈が適用される。ユーザーが再び条件を入力しなくても、AIは過去の対話を覚えている。

AIはレビューをどう読んでいるのか

AIはレビューをどう読んでいるのか

多くのマーケティング担当者が誤解している点がある。GoogleビジネスプロフィールやYelpに投稿されたレビューは、AIが直接読み取れるわけではない。これらの主要ディレクトリは、LLMクローラーがビジネスプロフィール上のレビューをスクレイピングするのをブロックしている。

レビューがAIに渡る経路

ワーサム氏はこのメカニズムを明確に説明している。「ChatGPTやClaudeなどのLLMツールは、GoogleやYelpといった主要ディレクトリ上のレビューデータをクロールできません。実際、AIが特定のレビューを引用しないのはこのためです」。

しかし同じレビューでも、一度Web上に再掲載されると状況が一変する。レビューを自社サイトのウィジェットで公開したり、SNSに投稿したりした瞬間、その情報はLLMのクロール対象になる。ワーサム氏の言葉を借りれば「その時点でLLMツールの餌食になる」のだ。

レビューがAIに届かないケース
顧客Googleビジネスプロフィール
⚠ クローラーブロックによりAIは読み取れない
レビューがAIに届くケース
顧客Googleビジネスプロフィール自社サイト
✅ ウィジェットやSNS経由でAIがクロール可能に
ディレクトリ上だけではAIに届かない  Web上への再掲載でAIの情報源になる
※「人気の店」を尋ねるユーザーにはクロール可能なレビューが回答を左右する

この仕組みは、AI検索でどのクエリに勝てるかを決定的に左右する。ユーザーが「人気の」「高評価の」ビジネスを尋ねたとき、LLMはアクセス可能なレビューテキストを検索する。ディレクトリ内に閉じ込められたレビューは、回答に一切貢献しない。

そのため実務上の優先順位は明確だ。レビューを自社サイトやSNSで定期的に再発信し、AIが参照できる形でWeb上に存在させることが、AI時代のローカルSEOでは必須になる。ディレクトリ任せでは不十分だとワーサム氏も強調している。

星評価はAI検索で通用しなくなる

星評価はAI検索で通用しなくなる

これまでのローカルSEOは星の数を増やすことが目標だった。しかしAI検索において、平均星評価の重要度は急速に低下している。Search Engine Journalが報じた監査事例では、AIが平均星評価を引用したケースはゼロだった。代わりに参照されたのはすべて、具体的なレビュー本文の内容である。

AIが重視するのは「鮮度」と「量」

消費者データも同じ傾向を示す。45%のユーザーが星評価よりレビューの新しさを優先し、60%が評価点だけのレビューより詳細な文章レビューを信頼する。さらに70%が、購入後72時間以内のレビュー依頼を好むというデータもある。

ワーサム氏はこの変化を明確に言語化している。「星5の30件より、星3.9で1,000件の店に行く。古い高評価より、現在も続く安定したレビューの流れの方が価値が高い」。Googleのデフォルト表示が「最も関連性の高い」レビューであっても、ユーザーの多くはわざわざ「新しい順」に並べ替える。それは最新のレビューが、自分がこれから受ける体験を最も正確に予測するからだ。

星評価偏重型の戦略(Before)
店舗A 星4.8(30件)
レビューのほとんどが2年前
⚠ AIの回答にはほぼ登場しない
レビュー鮮度と量重視の戦略(After)
店舗B 星3.9(1,000件)
毎週10件以上の新着レビューあり
✅ AIの情報源として優先的に参照される
平均星の高さだけでは不十分  安定したレビュー流入がAIの信頼を獲得する
※ユーザーはGoogleの表示順を「新しい順」に切り替える傾向がある

対策は3つの柱に整理できる。構築(リスティングの一貫性とレビュー量の確保)、管理(72時間以内の返信とモニタリング)、防御(ポリシー違反レビューの削除依頼とレビューの埋没対策)。この3つを同時に回すことで、AIが参照する情報の質と量をコントロールできる。

AIの回答が毎回違う理由

AIの回答が毎回違う理由

LLMが生成する回答は確率的な出力だ。同じ質問をしても、デバイスやアカウント、時間帯によって結果が変わる。SparkToroの調査では、異なるユーザーが同じ質問をLLMに投げたところ、結果の順序が一度も同じにならなかった。

スロットマシンのような仕組み

ジャクソン氏はこの性質を「AIへの質問はスロットマシンのようなものだ」と表現している。毎回似たデータが返ってくるが、その都度少しずつ異なる。この特性を理解しないまま「AI検索で1位」を目標にするのは無意味だ。

AI検索における正しいKPIは順位ではない。評価すべきは引用総数、つまりAIの回答に自社情報がどれだけ使われているかである。ブランドが特定の端末で回答から完全に除外されることもあれば、次の検索ではトップに立つこともある。重要なのは、どの検索でも「存在する」ことだ。

旧来の評価指標(Before)
検索順位のトラッキング
⚠ AI検索では意味をなさない
AI時代の評価指標(After)
AI回答内での引用総数・情報源の幅
✅ 複数回の検索でブランドが出現するかを測る
順位はLLMの確率的出力に依存する  引用総数がAI存在感の実態を示す
※異なるデバイスや時間帯で結果が変わる前提の測定が必要

監査の際には必ずシークレットモードやテンポラリーチャットを使用する。保存されたコンテキストが結果を歪めるからだ。さらに定期的な再実行が不可欠で、月次での定点観測によって、AI上のブランド認知が実際に改善しているかを評価する。

緊急ブランド監査 4つのプロンプト

緊急ブランド監査 4つのプロンプト

GatherUpのセッションでは、多店舗ブランドが今すぐ実行できる4段階の監査プロンプトが紹介された。目的は、ChatGPTやGoogleのAI Overviews、Ask Mapsが自社について何を答えているかを可視化することだ。

自社把握から店舗別診断まで

監査はブランド名の単純な質問から始まり、徐々に深掘りしていく。最終段階では店舗ごとにAIがどう説明しているかをチェックする。Search Engine Journalの記事に掲載された監査ハンドアウトには、この4段階の具体的なプロンプト例が含まれている。

注目すべきは、Googleが今月更新したAI最適化ガイドの変更点だ。Search Engine Journalの記事でワーサム氏が指摘しているように、GoogleはAI生成の低品質コンテンツを検出し、ペナルティを科し始めている。汎用的なAIブログ投稿やFAQスクレイピングは、もはや無視されるだけでなくマイナス評価の対象になる。

監査前の状態(Before)
施策なし
AIが何を答えているか不明
低品質なAI要約が独り歩きする
監査後の状態(After)
4段階監査を定期実行
月次でAI回答の変化を追跡
自社サイトやSNSのレビュー公開で情報ソースを確保
現状把握なしでは改善できない  定期監査と対策でAI回答をコントロールする
※GoogleはAI生成の低品質コンテンツへのペナルティを開始している

この記事のポイント

  • AI検索では星評価よりクエリとのマッチ度とレビューテキストが優先される
  • LLMはGoogleやYelp上のレビューを直接クロールできず、自社サイトやSNSへの再掲載がAIの情報源になる
  • 星評価よりレビューの鮮度と量がAIの回答を左右する。評価が3.9でも1,000件ある店舗が星5の30件より強い
  • AIの回答は確率的で毎回変わるため、順位ではなく引用総数で評価する
  • 4段階の監査プロンプトを月次実行し、AIが自社をどう説明しているかを把握することがブランド防衛の第一歩
Googleがrobots.txtを無視する理由とSEOへの悪影響を解説

Googleがrobots.txtを無視する理由とSEOへの悪影響を解説

GoogleのJohn Mueller氏が、robots.txtに関する見落としがちな設定ミスについて回答した。このミスは、SEOやサイトのインデックス目標に悪影響を及ぼす可能性があり、特に検索ボックススパムへの対策を複雑化させる。なぜrobots.txtが正しく機能しないのか、その根本原因と具体的な解決策を解説する。

「無視されるrobots.txt」が生まれる仕組み

「無視されるrobots.txt」が生まれる仕組み

robots.txtは、検索エンジンのクローラーに対して「どのページをクロールしてよいか」を指示するためのファイルだ。しかし、設定の書き方を誤ると、その指示が完全に無視され、意図しないページがGoogleにインデックスされる事態を引き起こす。

誤ったrobots.txt設定(Before)
User-agent: Googlebot
Disallow: /search

User-agent: *
Disallow: /private
Disallow: /admin
※Googlebotは「User-agent: Googlebot」のセクションだけを見るため、/privateや/adminの禁止指示が適用されず、クロールされる可能性がある
正しいrobots.txt設定(After)
User-agent: googlebot
Disallow: /search
Disallow: /private
Disallow: /admin
User-agent: *
Disallow: /
※Googlebot用のセクションにすべての必要なルールを記述するか、共通ルールをコピーすることで、すべての指示が正しく反映される

User-agent別ルールと優先順位の落とし穴

問題の核心は、robots.txtの「より具体的なルールが優先される」という仕様にある。一般的なクローラー向けの User-agent: * セクションと、Googlebot専用の User-agent: googlebot セクションが同じファイル内に存在する場合、Googlebotは自身に直接関係するセクションのみを参照する。

Search Engine Journalの記事によると、あるShopifyサイトでは検索ボックススパム対策として Disallow: /searchUser-agent: * 内に記述していたが、別途 User-agent: Googlebot セクションが存在したため、この禁止指示がGooglebotに無視されていた。結果として、スパムによって生成されたURLがGoogleのインデックスに残り続けることになった。

これはrobots.txtの設計に起因する合理的な動作だ。特定のクローラーにだけピンポイントで指示を出し、それ以外のクローラーには別のルールを適用できる柔軟性を持たせるための仕組みである。しかし、この「柔軟性」が、設定の分断と見落としを生み出す。

設定ミスが引き起こすインデックス問題
スパマー 検索クエリ送信 スパムURL生成 Googlebot robots.txt無視でインデックス
スパマーの攻撃経路
クローラーの動作
発生した問題

robots.txtが制御するのは「クロール」であって「インデックス」ではない

もう一つの重要な前提として、robots.txtはページのクロールを制御するものであり、インデックスを直接制御するものではない。robots.txtでブロックしたページでも、何らかの理由でGoogleがそのURLを知り得た場合、コンテンツをクロールせずにインデックスすることがある。この仕様は、robots.txtだけに依存したインデックス制御が根本的に不完全であることを示している。

robots.txtとnoindexの正しい使い分け

robots.txtとnoindexの正しい使い分け

インデックスそのものを確実に防ぎたい場合、robots.txtよりも meta robots タグによる noindex 指定の方がはるかに効果的だ。robots.txtはドアの前に立つ警備員のようなもので、部屋の中のものを「知らない」ままでいられるが、部屋の存在自体を消し去ることはできない。noindex は、その部屋に「公開禁止」の札を貼るようなもので、検索エンジンに直接「これを検索結果に表示しないでほしい」と伝える。

誤った対策 robots.txtによるブロック
User-agent: *
Disallow: /search
robots.txtだけでは、クロールはブロックできてもインデックスは防げない。外部リンクなどからURLが発見されると、検索結果に表示されるリスクがある。
正しい対策 noindexタグの設置
<meta name=”robots” content=”noindex”>
このタグがページの<head>内にあれば、Googleはそのページをクロールしても検索結果から除外する。より確実なインデックス制御が可能。

noindexを確実に適用するための注意点

noindex を適用する際、robots.txtでそのページをクロール禁止にしてしまうと、Googlebotはそもそもそのページを読みに行けず、noindex タグを発見できない。結果として、いつまでもインデックスから削除されないという、本末転倒な事態を招く。クロールを許可した上で、noindex を指示することではじめて、意図したインデックス制御が機能する。

ShopifyとWordPressにおける具体的な対策

ShopifyとWordPressにおける具体的な対策

検索ボックススパムは、どのようなCMSでも発生しうる問題だが、幸いShopifyとWordPressの両方には、比較的簡単に実装できる緩和策が用意されている。

Shopifyでの検索ページnoindex設定

Shopifyでは、テーマの theme.liquid ファイルを編集することで、すべての検索結果ページに自動で noindex タグを追加できる。これにより、スパムクエリによって生成された無意味なページが検索結果に表示されることを防ぐ。

{% if template contains 'search' %}
  <meta name="robots" content="noindex">
{% endif %}

このコードをテーマの <head> セクションに追記するだけで、すべての検索ページへのnoindex適用が完了する。robots.txtによる制御と異なり、検索結果ページのURLを確実にインデックスから除外できるため、より根本的なスパム対策となる。

WordPressでの検索スパム対策

WordPress環境では、主要なSEOプラグインを導入するだけで検索結果ページへの noindex がデフォルトで有効になる。Yoast SEO、Rank Math、All In One SEO Packといったプラグインは、インストールしたその日から検索スパムに対する基本的な防御壁として機能する。

さらに、Diviをはじめとする一部のテーマやページビルダーは、スパムワードを含む検索クエリに対して、結果を表示する代わりに「該当する結果がありませんでした」というメッセージを返す仕組みを備えている。これにより、スパムURLそのものが生成されにくくなるという副次的な効果も期待できる。

robots.txtの正しい知識がサイトを守る

robots.txtの正しい知識がサイトを守る

robots.txtは強力なツールだが、その仕様を正しく理解していないと、かえってサイトの健全性を損なう原因になりうる。特に、User-agent別のルールの優先順位や、クロール制御とインデックス制御の違いといった基礎知識は、サイト運営者にとって必須のリテラシーと言える。

この記事のポイント

  • robots.txtでUser-agent: Googlebotの専用セクションがあると、一般的なUser-agent: *のルールはGooglebotに無視される。
  • robots.txtはクロールの制御であり、確実なインデックス除外にはmeta robotsタグのnoindex指定が必要。
  • 検索ボックススパム対策には、robots.txtよりnoindexの方が根本的な解決策となる。
  • ShopifyやWordPress(SEOプラグイン利用)では、テンプレートや設定を少し修正するだけで検索スパムを効果的に緩和できる。
Google LSAがGoogle広告に統合、2026年8月から段階移行へ

Google LSAがGoogle広告に統合、2026年8月から段階移行へ

GoogleがLSA(Local Services Ads / ローカルサービス広告)の管理画面をGoogle広告に統合する。2026年8月から一部の米国広告主を対象に移行が始まり、2027年にかけて段階的に拡大される予定だ。

移行後はGoogle広告内でキャンペーン管理やリード対応が完結する。ただし入札方式やレポートの扱いが変わるため、事前の準備が欠かせない。本記事では移行のスケジュールや変更点、広告主が取るべき対応を3つのポイントに絞って解説する。

LSAのGoogle広告統合で何が変わるのか

LSAのGoogle広告統合で何が変わるのか

LSA(ローカルサービス広告)は、もともとGoogle検索やマップの上部に表示される問い合わせ獲得型の広告だ。ユーザーが「近くの電気工事業者」などと検索すると、電話やメッセージでのリード獲得を主目的とした事業者一覧が表示される仕組みである。

今回の統合により、LSAはGoogle広告の管理画面から操作する形へと一本化される。従来のLSA専用ダッシュボードは廃止され、キャンペーンの作成からリード対応までをGoogle広告内で処理できるようになる。

移行スケジュールは2026年8月から段階的に

Googleが公開したスケジュールによると、最初の移行対象は米国の一部広告主であり、ペットケアやホームサービス、ウェルネス、教育関連の業種が含まれる。2026年8月にこの第1陣の移行が始まり、同年後半に米国内の対象が拡大される見込みだ。

米国以外のアカウントや残りの業種については2027年に対応が進む。アカウント管理者には移行の14日前と7日前に通知が届き、移行完了時にも確認の連絡があるため、突然ダッシュボードが使えなくなる事態は避けられる。

現在のLSA管理フロー(変更前)
LSAダッシュボード キャンペーン設定
GBP管理画面 ビジネス情報の更新
LSA受信箱 リード対応
※複数の管理画面にまたがるため情報の更新漏れが生じやすい
Google広告統合後(変更後)
Google広告 キャンペーン設定とビジネス情報の一元管理
Google広告 Lead Manager リード対応
※1つのインターフェースで管理業務が完結する
変更前の分散管理  統合後の一元管理

管理フローの一元化によって作業負荷は減る一方で、従来のLSA専用画面に慣れた事業者や代理店には操作変更への対応が求められる。

新しいLSAキャンペーンの仕組み

新しいLSAキャンペーンの仕組み

統合後のLSAは、Google広告のP-MAX(Performance Max)キャンペーンとして配信される。ただし名称こそP-MAXだが、配信面や課金方式は従来のLSAと変わらない点に注意が必要だ。

配信面と課金方式は変更なし

LSAは今後もキーワードの入札なしで、Google検索とマップにのみ表示される。クリック課金ではなく、電話、メッセージ、予約といった有効リードに対して料金が発生する仕組みも維持される。P-MAXと聞くとディスプレイ広告や動画広告まで配信対象が広がるイメージがあるが、LSAの場合はあくまで検索とマップに限定される形だ。

Google広告内で完結するキャンペーン管理

広告主はGoogle広告の管理画面でLSAキャンペーンの設定、リードの確認、返信をすべて行えるようになる。従来のLSA専用ダッシュボードは移行後に利用できなくなるため、操作に不慣れな場合は早めにGoogle広告の画面構成を確認しておくとスムーズだ。

キャンペーン管理で変わる5つのポイント

キャンペーン管理で変わる5つのポイント

統合に伴い、予算の考え方や入札、レポートの扱いが一部変更される。Search Engine Journalの記事で挙げられた主な変更点を整理する。

現在のLSA設定(Before)
予算は週単位で管理
手動入札でリード単価の上限を設定できる
サービスカテゴリ別に目標CPAを設定可能
LSAダッシュボードとGBPで情報を別管理
過去レポートはLSAダッシュボードからアクセス
Google広告移行後(After)
予算は日単位で管理
手動入札は廃止
全カテゴリをまとめたキャンペーン単位の目標CPA1つ
GBPの情報が自動同期
過去レポートは移行後アクセス不可になるため事前保存が必要
移行前  移行後

予算は週単位から日単位へ

従来のLSAは週平均の予算で運用されていたが、移行後はGoogle広告の他のキャンペーンと同様に日額予算での管理に変わる。1日あたりの支出上限が設定されるため、週単位のざっくりした予算配分からより細かい調整が必要になる。

手動入札が廃止され目標CPAがキャンペーン単位に

これまで一部の広告主は「リード1件あたりの上限単価」を手動で設定できたが、この機能は使えなくなる。代わりに、Googleが算出するキャンペーン単位の目標CPA(リード獲得単価の目標値)が適用される。

サービスカテゴリごとに異なる目標CPAを設定することもできなくなる。たとえば配管工事と空調工事の両方を1つのキャンペーンで広告している事業者の場合、双方のリードコスト差にかかわらず1つの目標CPAに統一される。この点は業種によって影響が大きいため、キャンペーン分割の要否を検討する必要がある。

ビジネス情報はGBPと自動同期

事業者名や住所、営業時間といった基本情報はGBP(Google Business Profile / グーグルビジネスプロフィール)から自動で同期される。これまではLSAとGBPで別々に情報を更新する手間があったが、統合により片方だけ変更するリスクは減る。ただし、大幅な名前や住所の変更を行うと24〜48時間の確認プロセスが入り、キャンペーンが一時停止する可能性がある。

レポートとリード管理の拠点が切り替わる

過去のパフォーマンスレポートはGoogle広告に引き継がれない。リードの履歴は移行されるものの、レポートデータへのアクセスは移行完了と同時に失われる。年度比較や顧客報告に必要なデータは事前にダウンロードしておくことが必須だ。リード対応についても、Google広告内のLead Manager(リード管理画面)に切り替わる。

広告主が移行前後に取るべき対策

広告主が移行前後に取るべき対策

移行をスムーズに進めるために、広告主や代理店が今から着手できる準備を整理する。移行の通知を受け取ってから慌てないよう、以下の2点を押さえておきたい。

履歴レポートのダウンロードを最優先に

最も重要なのは、LSAダッシュボードに保存されている過去のパフォーマンスデータをエクスポートすることだ。移行後はレポート画面自体がなくなるため、後から取り出すことはできない。

複数アカウントを管理する代理店は、通知を受け取る前にバックアップ作業を始めておくと安全だ。前年比較レポートを作る予定のある事業者も、今のうちに必要な期間のデータを保存しておくことを推奨する。

移行後の設定を丁寧に確認する

Googleがキャンペーン設定を自動で移行するが、広告主自身で以下の項目を再確認すべきである。

  • 日額予算が事業計画と合っているか
  • キャンペーン単位の目標CPAが過去のリード単価と大きく乖離していないか
  • サービスカテゴリや配信地域が正しく設定されているか
  • 広告スケジュールが想定通りか
  • リード転送先の電話番号や写真、訴求文に誤りがないか

事業者名や住所に大きな変更があると、前述の通り審査が入りキャンペーンが止まる可能性がある。配信再開までに数日かかるケースもあるため、移行直後の大口変更は避けたほうが無難だ。

Googleは移行後すぐに広告が表示される場合もあるとしているが、パフォーマンスが安定するまで最大2週間をみておく必要がある。

統合がもたらす影響と今後の見通し

統合がもたらす影響と今後の見通し

今回の統合の最大の焦点は、カテゴリ別の目標CPAが廃止される点にある。リード単価の大きく異なる複数サービスを1つのキャンペーンで運用してきた事業者は、キャンペーンを分割するか、まとめたまま自動入札に任せるかの判断を迫られる。

分割すれば入札のコントロールは細かくなるが、各キャンペーンのコンバージョンデータが少なくなり、Googleの自動最適化が働きにくくなる面もある。リード数の多い事業者は分割、まだボリュームの少ない事業者は統合したまま様子を見るという選択肢が現実的だ。

初期移行グループの状況を見ながら、Googleは追加のガイダンスを出すとみられる。とくに日本国内の広告主が対象となるのは2027年以降と見込まれるため、まずは米国の事例を参考にしつつ、自社のLSAデータを整理しておくのが賢明だろう。

この記事のポイント

  • LSAの管理画面が2026年8月からGoogle広告に統合される
  • 配信面とリード課金の仕組みは変わらないが、予算管理や入札方式が変更される
  • カテゴリ別目標CPAの廃止が事業者に与える影響は大きく、キャンペーン分割の要否を検討する必要がある
  • 過去レポートは移行前に必ずダウンロードしておくこと
  • 日本国内の移行は2027年以降の見込みだが、今からデータ整理を始めておくとよい
Google、匿名化検索データを競合と共有へ EUのDMA決定の全容

Google、匿名化検索データを競合と共有へ EUのDMA決定の全容

EUの欧州委員会が2026年7月16日、Googleに対して2つの拘束力のある決定を下した。検索データを匿名化した上で競合他社と共有すること、そしてAndroidの一部機能を競合AIアシスタントに開放することだ。いずれもデジタル市場法(DMA)に基づく措置である。

この決定の影響は検索エンジンにとどまらない。AIチャットボットも対象に含まれており、検索とAIが融合しつつある現在の状況において、今後の競争環境を左右する転換点となる可能性が高い。

DMAに基づく2つの決定の全体像

DMAに基づく2つの決定の全体像

今回の決定は、欧州委員会が2026年4月に公開協議を経て暫定的な見解を示していたものを最終化した形だ。2つの柱で構成されている。

  • 検索データの共有義務。Googleの検索結果に関するクエリ、クリック、閲覧、ランキング位置の匿名化データを、公正かつ非差別的な条件で競合に提供すること
  • AndroidのAI相互運用性の確保。競合AIアシスタントが音声起動やアプリ内操作を実行できるよう、OSレベルの機能を開放すること

違反時の罰金を伴う独占禁止法の案件とは異なり、DMAに基づく今回の措置は構造的な是正を目的とする。欧州委員会は、Googleの現在のデータ共有の取り組みは不十分だと明確に指摘している。

従来のGoogleのデータ共有(Before)
Google検索 データを独占的に保持
競合検索エンジン 独自にデータ収集
※Googleのランキング信号やアルゴリズム自体にはアクセス不可。競合は自前でデータを集める必要があった
DMA決定後のデータ共有(After)
Google検索 匿名化データを提供 データセット
競合検索エンジン データを取得し独自ランキングを構築
※クエリ・クリック・閲覧・結果位置データを含む。ランキングアルゴリズム自体は共有対象外
Before  After  Google側  競合側

この図で示した通り、データ共有の枠組みが整うことで、競合検索エンジンやAIチャットボットはGoogleが長年かけて蓄積してきた規模の検索インタラクションデータを活用できるようになる。

検索データ共有の具体的な仕組みと対象範囲

検索データ共有の具体的な仕組みと対象範囲

共有されるデータの内容

共有対象となるのは、Google検索の無料・有料を問わずすべての検索結果から生成される匿名化データである。具体的には以下の情報が含まれる。

  • 検索クエリ(ユーザーが入力した検索語句)
  • メタデータ(使用言語、デバイスの種類)
  • 表示されたURL一覧
  • ユーザーのクリックや閲覧といったインタラクション情報
  • 検索結果内での表示位置(ランキング)

一方で、Googleのランキングアルゴリズムそのものは共有対象外だ。また個人を特定できる情報(アカウント詳細、検索履歴、タイムスタンプ、極端に稀または長大なクエリ)は除外される。

利用資格と審査プロセス

このデータを利用できるのは誰でもない。欧州委員会が定めた要件を満たす必要がある。

  • EU圏内で月間5万人以上のユーザーを持つこと
  • 2年以上の事業運営実績があること。新規参入企業の場合は投資実績による代替審査を受けること
  • セキュリティ審査と独立監査を通過すること

これらの条件をクリアした事業者のみが、Googleとライセンス契約を結びデータの提供を受けることができる。データ価格は市場レートではなくコスト回収ベースで算定される。

STEP 1 月間EUユーザー5万人以上+事業実績2年(または投資審査)
STEP 2 セキュリティ審査と独立監査の通過
STEP 3 Googleとのライセンス契約(コスト回収ベースの価格設定)
STEP 4 匿名化検索データの提供開始

AIチャットボットについても、DMA上でオンライン検索エンジンと見なされるものは利用資格がある。ただしデータの用途は、自社の検索・ランキングシステムの改善に限定され、汎用AIモデルの学習やGoogleの検索結果の複製には使用できない。

AI検索時代におけるデータの重要性

AI検索時代におけるデータの重要性

この決定が単なる検索エンジン間の競争を超えた意味を持つのは、AIチャットボットが回答を生成する仕組みと深く関わるからだ。

グラウンディングと検索データ

AIチャットボットが正確な回答を返すためには「グラウンディング(事実確認のための根拠付け)」と呼ばれるプロセスが欠かせない。最新のWebデータを参照し、回答の確からしさを検証する仕組みだ。

Googleは自社のAIに対して「FastSearch」というシステムでグラウンディングを行っている。これはGoogle自身の検索ランキング信号に依存する仕組みであり、当然ながら競合には提供されていなかった。

今回の決定で共有される匿名化データ(クエリ、クリック、閲覧、結果位置)は、競合各社が独自の情報検索・ランキングシステムを構築するための材料となる。グラウンディングもこの用途の一つとして認められている。

従来のAI検索の課題(Before)
競合AI 独自収集データのみ 限定的な根拠
Google AI FastSearchで大量データ活用 強力な根拠
※競合AIは回答精度の基盤となる検索データで大きな差をつけられていた
DMA決定後のAI検索(After)
競合AI 匿名化データで学習 強化された根拠
Google AI 引き続きFastSearch活用
※競合AIも大規模な検索インタラクションデータを活用できるように。ただしアルゴリズム自体は各家が開発
Before  After  競合AI  Google AI

検索トラフィックへの影響は限定的か

短期的に見れば、Webサイト運営者が感じるトラフィックへの影響は限定的だろう。SE Rankingのデータによると、2026年1月時点で全AIプラットフォームを合わせた紹介トラフィックは、世界のインターネットトラフィック全体の約0.24%に過ぎない。

データへのアクセスが改善されれば競合エンジンやチャットボットの開発が進む可能性はあるが、それだけでユーザーの検索行動が一気に変わるわけではない。重要なのは、このデータを実際に製品開発に活かせるかどうかだ。

AndroidのAIアシスタント開放

AndroidのAIアシスタント開放

2つ目の決定はAndroidに関するものだ。GoogleはOSレベルの機能を競合AIアシスタントに開放する義務を負う。

  • ユーザーが「Hey Google」のような音声コマンドで競合アシスタントを起動できるようにすること
  • 競合アシスタントがアプリ内で動作し、タクシーの予約や返信文の作成といった操作を実行できるようにすること

Google自身のGeminiアシスタントはすでにこのレベルのアクセス権を持っている。今回の決定はこの非対称性を是正するものだ。

主な機能の実装期限は次期メジャーリリースのAndroid 18、遅くとも2027年8月1日までとされている。複数のアシスタントが異なるウェイクワードで同時応答できる機能にはさらに1年の猶予が与えられ、2028年8月1日が期限となる。

Googleの反応とプライバシーをめぐる議論

Googleの反応とプライバシーをめぐる議論

Googleは両方の決定に反対の立場をとっている。Alphabetのグローバル問題担当プレジデントであるKent Walker氏は公式ブログで、「数百万人の欧州市民にとって不可欠なプライバシーとセキュリティの防御線を損なうリスクがある」と表明した。

同氏はまた、GoogleがDMAの目的に沿った解決策を繰り返し提案してきたことも強調している。検索データの共有については、適切な匿名化やユーザーの知識・同意なしに、欧州の検索データが見知らぬ企業に開示されることへの懸念を示した。

これに対し欧州委員会は、匿名化のプロセスが多層的な技術処理と契約上の保護措置で構成されており、内部および外部のプライバシー専門家の関与のもとで開発されていると説明する。Googleはデータ共有前にサイバーセキュリティやデータ保護の基準に基づいて申請者を審査できる。独立したテストで保護措置が不十分と判明した場合は、措置の見直しも可能だ。

匿名化データの保護レイヤー
技術的保護
多層的な匿名化処理(内部・外部のプライバシー専門家が関与)。個人特定情報・検索履歴・タイムスタンプ・稀なクエリは除外
契約的保護
ライセンス契約による利用制限。汎用AIモデルの学習やGoogle結果の複製を禁止
審査と監視
Googleはセキュリティ・データ保護基準で申請者を事前審査。独立テストで不十分と判明すれば措置の再評価も可能

今後の展開とスケジュール

今後の展開とスケジュール

2026年後半は、Googleがデータセットの整備と提供条件の策定に費やす期間となる。価格提案の期限は遅くとも2027年1月だ。各事業者はライセンス契約と価格合意を経て、それぞれのスケジュールでデータ提供を受けることになる。

Android側の主な変更は2027年8月1日、複数アシスタントの同時音声起動は2028年8月1日が期限だ。欧州委員会はこれらの措置を2年ごとに見直し、匿名化が不十分と判断されれば再検討を行うとしている。

この決定が実際に検索エンジンやAIチャットボットの多様化を促すかどうかは、資格審査を通過する事業者の顔ぶれと、提供されたデータをどれだけ製品開発に活かせるかにかかっている。すぐに目に見える変化はないが、中長期的には検索とAIの競争環境を変える可能性を秘めた決定と言えるだろう。

この記事のポイント

  • EU欧州委員会がDMAに基づき、Googleに匿名化検索データの共有とAndroidのAIアシスタント開放を義務付ける決定を下した
  • 共有対象はクエリ・クリック・閲覧・結果位置のデータで、ランキングアルゴリズム自体は対象外。AIチャットボットも利用資格あり
  • Googleはプライバシーとセキュリティへの懸念を表明しているが、欧州委員会は多層的な匿名化と審査プロセスで対応
  • 短期的な影響は限定的だが、中長期的には検索とAIの競争環境に変化をもたらす可能性がある
Google NotebookLMがGemini Notebookに改称、AIスクレイピング対策の緊急対応

Google NotebookLMがGemini Notebookに改称、AIスクレイピング対策の緊急対応

Googleが研究支援ツールNotebookLMをGemini Notebookに改称した。実体は同じだが、このタイミングでユーザーエージェントの表記が「Google-NotebookLM」から「Google-GeminiNotebook」に変更される。旧ユーザーエージェントは2026年8月をもって廃止されるため、サイト運営者は数週間のうちにスクレイピング対策の見直しを迫られている。

今回の変更は単なる名称の刷新にとどまらず、AIによる自動コンテンツ収集と再利用のリスクを改めて浮き彫りにする。本記事では、Gemini Notebookのスクレイピング機能の実態、robots.txtを無視するユーザートリガー型フェッチャーの仕組み、そして具体的なブロック手法を簡潔にまとめる。

NotebookLMがGemini Notebookに改称、機能は変わらず

NotebookLMがGemini Notebookに改称、機能は変わらず

名前変更の背景と影響

2026年7月18日、Googleはユーザートリガー型フェッチャーのドキュメントを更新し、NotebookLMをGemini Notebookに置き換えた。ブランド統合の一環であり、既存のNotebookLMユーザーにとって使い勝手に違いは生じない。

しかし、サイト運営者にとって重大なのは、旧ユーザーエージェント「Google-NotebookLM」が2026年8月で無効になる点だ。ファイアウォールや.htaccessにこの文字列を直書きしている場合、猶予期間内に新しいユーザーエージェントへ切り替えなければ、ブロックが機能しなくなる。

Gemini Notebookの主な機能

Gemini Notebookは、ユーザーが提供した文書やURLを「グランドトゥルース(信頼できる基盤情報)」として扱い、AIが調査や学習を支援するマルチモーダルツールだ。YouTubeの動画や音声ファイルを取り込んで分析することも、逆にアップロードされた資料を音声ポッドキャストや動画解説に変換することもできる。

この「資料をもとに新しいコンテンツを自動生成する」という特徴が、後述するスクレイピング問題の根本にある。生成された音声や動画がオンラインで公開されれば、元の記事と直接競合する可能性があるからだ。

Gemini Notebookが引き起こすスクレイピング問題

Gemini Notebookが引き起こすスクレイピング問題

Discover Sourcesによる自動スクレイピング

Gemini Notebookの「Discover Sources」機能は、ユーザーが設定したクエリやテーマに沿って最大10件のオンライン記事を自動で収集し、AI要約を生成する。問題は、サイト所有者の許可を一切取らずにクローリングが行われ、参照元へのリンクも一切発生しない点だ。

従来の検索エンジンであれば、クローラーが収集した情報は検索結果としてユーザーをサイトへ誘導する。しかしGemini Notebookの要約はクローズドな環境で完結し、トラフィックの恩恵は元サイトに還元されない。SEOの観点からは、コンテンツが無断で「搾取」される構造といえる。

音声・動画コンテンツの自動生成と競合

さらに、アップロードした資料からポッドキャストや動画解説を生成できる点も看過できない。仮に自社サイトの記事が材料に使われ、第三者が公開すれば、同一テーマでオリジナルと競合する二次コンテンツが無数に生まれる危険がある。

Googleのドキュメント上、これらは「ユーザー調査のための機能」と位置づけられているが、実質的には許可なきスクレイピングとリパーパス(再利用)を自動化する仕組みにほかならない。コンテンツを資産とするウェブサイト運営者にとって、対策は急務だ。

緊急対応すべきブロック手法

緊急対応すべきブロック手法

ユーザートリガー型フェッチャーとは

Gemini Notebookのクローラーは「ユーザートリガー型フェッチャー」に分類される。これは、ユーザーが明示的に指示(URL貼り付けやDiscover Sourcesの実行)をトリガーとして起動するため、robots.txtの指示に従わない。robots.txtはあくまで紳士協定であり、一般的なクローラーは自発的に従うが、ユーザートリガー型には適用されないのだ。

ただし、robots.txtが効かないからといって手立てがないわけではない。サーバー側でHTTPリクエストのユーザーエージェント文字列を検査し、該当するアクセスを拒否することは可能である。

.htaccessによる具体的なブロック例

多くのレンタルサーバーで使えるApache環境であれば、.htaccessに以下のルールを追記するだけでGemini Notebookのアクセスを遮断できる。

RewriteEngine On

# Gemini Notebookのユーザーエージェントをブロック
RewriteCond %{HTTP_USER_AGENT} Google-GeminiNotebook [NC]
RewriteRule ^ - [F,L]

この設定により、該当のユーザーエージェントを含むすべてのリクエストに対して「403 Forbidden」が返される。Nginxを利用している場合は、if ($http_user_agent ~* "Google-GeminiNotebook") { return 403; } のような記述で同様の制御が可能だ。

重要なのは、新旧両方のユーザーエージェントをカバーするか、あるいは直ちに新UAのみに移行することである。2026年8月以降、旧UAはGoogle側で廃止されるが、それまでにサイト側のルールを更新しておかなければ、一時的にブロックがすり抜けるリスクが生じる。

旧ユーザーエージェントの猶予期間と注意点

旧ユーザーエージェントの猶予期間と注意点

Googleはドキュメント内で、旧ユーザーエージェント「Google-NotebookLM」を2026年8月までサポートすると明記している。ハードコードしているサイト運営者は、この期間内に新しい文字列へ切り替える必要がある。

従来のユーザーエージェント(Before)
Google-NotebookLM
2026年8月に完全廃止
変更後のユーザーエージェント(After)
Google-GeminiNotebook
即座にブロックルールへ反映が必要
サイト運営者は、既存のブロックルールに新UAを追加するか、新旧両方に対応する形で設定を更新する必要がある。

なお、合わせて「Project Mariner」に関する記述がドキュメントから完全に削除された。同プロジェクトは2026年5月に終了しており、混乱を避ける意味でも、ユーザーエージェント周辺の情報は最新版を参照すべきである。

この記事のポイント

  • NotebookLMはGemini Notebookに改称され、ユーザーエージェントが変更された
  • Discover Sources機能が許可なく記事を収集し、AI要約や音声コンテンツを生成する
  • ユーザートリガー型フェッチャーはrobots.txtを無視するが、ファイアウォールや.htaccessでブロック可能
  • 旧UA「Google-NotebookLM」は2026年8月に廃止、既存のルールを直ちに更新する必要がある
Google AI OverviewsにTop Stories表示、米国モバイルで本格展開

Google AI OverviewsにTop Stories表示、米国モバイルで本格展開

Google AI Overviewsにニュース表示機能が本格実装、Top Storiesが米国モバイルで展開開始

Google AI Overviewsにニュース表示機能が本格実装、Top Storiesが米国モバイルで展開開始

Googleが2026年7月中旬、検索結果のAI Overviews内にニュースとTop Storiesを表示する機能の本格展開を開始した。米国モバイルユーザー向けに完全展開されており、今後対象地域が拡大される見込みだ。

この機能は2026年5月にGoogleが発表した「AI Overviewsにおける新鮮な視点、最新情報、目立つリンク」構想の一環として導入された。発展中のトピックに関する質問に対し、タイムリーな記事をより目立つ形で表示するキャッセル形式を採用する。

Googleの広報担当者はこの展開が米国モバイル向けに完全にライブであることを確認している。AI OverviewsとAI Modeといった検索機能からサイトへのトラフィックが増加する可能性を示す重要なアップデートといえる。

AI OverviewsのTop Stories表示とは、何が変わるのか

AI OverviewsのTop Stories表示とは、何が変わるのか

これまでAI Overviewsは主にGoogleが収集した知識グラフや静的コンテンツから回答を生成していた。そこにニュースや最新情報のカルーセルが統合されたことで、リアルタイム性の高い情報がAI生成回答と並列で表示されるようになった。

表示の仕組み、カルーセル形式でニュースを可視化

AI Overviewsのセクション内に、水平スクロール可能なカルーセルとしてニュース記事が表示される。各項目にはニュースメディア名、見出し、アイキャッチ画像が含まれ、ユーザーは回答文に加えてリアルタイムの情報をワンタップで確認できる。

このカルーセルは「Preferred Sources」と呼ばれる、Googleが信頼性を評価したソースを優先的に表示する仕組みと連動する。ニュースメディアにとっては、検索結果ページ内での露出機会を大幅に拡大するチャンスとなる。

従来のAI Overviews(Before)
AIが生成した回答文を静的表示
情報源リンクは下部に小さく配置
ニュースのリアルタイム更新なし
※ユーザーはニュースを知るには別途検索が必要
Top Stories搭載のAI Overviews(After)
AI回答に加えてニュースカルーセルを表示
タイムリーな記事を水平スクロールで閲覧可能
Preferred Sourcesを優先表示
※ユーザーはAI回答と最新情報を同一画面で取得可能

Preferred Sourcesの影響力がさらに拡大

Googleは2026年5月の発表時に、Preferred Sourcesをニュースカルーセルでも優先表示すると明言していた。今回の本格展開により、Googleに信頼できる情報源として認識されるメディアは、AI Overviews経由のトラフィックをより多く獲得できる環境が整った。

この仕組みは単なるアルゴリズム評価だけでなく、メディア側のE-E-A-T(経験、専門性、権威性、信頼性)をより重視する検索エコシステムへの移行を加速させる。検索結果の質を担保しつつ、タイムリーなニュースを適切に届けるための設計といえる。

AI Overviews経由のクリック、メディアへのトラフィック増加が期待される

AI Overviews経由のクリック、メディアへのトラフィック増加が期待される

Googleは2026年7月、AI検索機能がウェブサイトに毎週数十億回のクリックを送っていると発表した。AI OverviewsやAI Modeを含むこれらの機能は、従来の検索結果とは異なる経路でユーザーをオンラインコンテンツに誘導する役割を果たす。

AI検索とトラフィックの関係、新しい導線設計

AI Overviews内のニュースカルーセルは、従来の検索結果よりも目立つ位置に配置される。テキスト回答の直下または横に表示されるため、スクロールなしでニュース記事にアクセスできる。これは単なるクリック率向上にとどまらず、発展中のニューストピックにおける情報鮮度と発信者評価を結びつける設計だ。

STEP 1 ユーザーが発展中のニューストピックについて検索
STEP 2 AI Overviewsが概要回答を生成し、Top Storiesカルーセルを表示
STEP 3 ユーザーがカルーセル内の記事をタップし、メディアサイトへ遷移
STEP 4 メディアサイトがAI Overviews経由のトラフィックを獲得

AI Modeとの統合がもたらす波及効果

AI ModeはGoogleが提供するAI専用の検索モードで、会話形式の対話と情報探索を組み合わせた機能だ。Top Stories表示はAI OverviewsだけでなくAI Mode内でも有効であり、ユーザーが対話的にニュースを掘り下げる際にもメディアの記事が提示される。

これにより、キーワード検索だけに依存しない多層的な導線が形成される。ユーザーが自然言語で質問を重ねるたびに新たなニュースが表示される可能性があり、メディアにとってはAI検索最適化が新たなSEO領域として重要性を増す。

ニュースメディアのSEO戦略、AI Overviews対応が急務に

ニュースメディアのSEO戦略、AI Overviews対応が急務に

AI OverviewsにTop Storiesが統合されたことで、メディアのSEO戦略は新たな段階に入った。従来のテキスト検索向け最適化に加え、AI Overviews内で優先表示されるための対策を講じる必要性が高まっている。

Preferred Sourcesとしての評価を高める施策

Googleが示すPreferred Sourcesの評価基準は完全には公開されていないが、一般的にE-E-A-Tが重視されることは明白だ。メディアは記事の正確性、著者の専門性、サイト全体の信頼性を継続的に向上させる必要がある。

  • 著者情報の充実 執筆者の経歴、専門分野、過去の実績を明確に提示する
  • 事実確認のプロセス可視化 情報源の明示、訂正ポリシーの公開、編集基準の提示
  • 構造化データの適切な実装 NewsArticle、Article、Authorなどのスキーマを正確にマークアップする
  • サイト全体のページ速度とモバイル対応 コアウェブバイタルの基準を満たし、ユーザー体験を最適化する

AI可視性を高めるコンテンツ戦略

AI Overviewsで表示されるためには、GoogleのAIが質問の意図を理解し、回答の情報源として適切と判断するコンテンツ設計が求められる。具体的には、明確な見出し構造、簡潔な要約文、信頼性の高い統計データの提示が有効だ。

非推奨のコンテンツ設計
曖昧なタイトル、引用のみの記事、専門性の低い執筆者、構造化データ未実装
推奨のコンテンツ設計
具体的事実を含む明確な見出し、一次情報の提示、著者の専門性明示、構造化データ完全実装

今後の展開と検索エコシステムへの影響

現時点では米国モバイルユーザー向けに限定されているが、Googleは今後デスクトップや他地域への拡大を示唆している。AI Overviewsの機能拡張は段階的に行われるため、日本のメディア関係者も早期の準備が重要だ。

Googleの継続的なAI検索改善とメディアの対応

Search Engine Landの記事によれば、GoogleはAI検索機能からオープンウェブへのクリックを改善する方針を継続している。Top Stories表示はその一環であり、検索とメディアの関係を再構築する取り組みと位置づけられる。

メディア企業はAI Overviewsでの表示を単なるトラフィック獲得手段としてだけでなく、コンテンツの質と信頼性を問われる新たな評価指標として捉えるべきだ。AI検索時代のSEOは、キーワード密度や被リンク数から、情報の正確性と権威性の証明へと重心を移している。

この記事のポイント

  • Google AI OverviewsにTop Stories表示機能が米国モバイル向けに本格実装された
  • ニュースカルーセルはPreferred Sourcesを優先表示し、メディアのAI可視性を高める
  • AI検索機能はサイトに週数十億回のクリックを送り、新たなトラフィック導線を形成
  • メディアのSEO戦略はE-E-A-T強化と構造化データ実装によるAI Overviews対応が急務
  • AI Overviews展開は他地域やデスクトップにも拡大予定で、早期の対策準備が重要