タグアーカイブ SEO

ChatGPTが商業クエリの26%に広告表示、関連性に課題も浮上

ChatGPTが商業クエリの26%に広告表示、関連性に課題も浮上

ChatGPTが商業目的のクエリの約4回に1回の割合で広告を表示していることが、SEOツール企業SE Rankingの調査で明らかになった。表示頻度はGoogleのAIモードに迫る水準だが、広告の関連性や広告主の可視性に課題が残る。

今回の調査は20分野にわたる5万件以上の商業クエリを分析したもので、会話型AI上での広告配信の実態が初めて大規模に可視化された。AI検索時代の新たな広告チャネルとして注目されるChatGPT Adsだが、その仕組みにはGoogle検索とは異なる独自の難しさがある。

商業クエリの約26%で広告が出現、Google AIモードに肉薄

商業クエリの約26%で広告が出現、Google AIモードに肉薄

SE Rankingの調査によると、ChatGPTは商業クエリの25.94%でスポンサードプレースメント(広告)を表示した。これは同社が以前調査したGoogle AIモードの29.45%にかなり近い数字だ。AIチャットボットの広告表示率が、従来型検索エンジンのAIモードと肩を並べつつある状況が浮かび上がった。

表示スタイルはシンプル、1クエリに単一広告

広告の表示スタイルは現在のところ非常にクリーンだ。調査で観測されたすべての広告は、生成された回答の下部に表示され、他の広告主と並んで競合することはなかった。1つの回答に対して常に1つのスポンサーオファーのみが表示される。

Googleの検索結果画面とは異なり、ユーザー体験を大きく阻害しない形で広告が統合されている点は注目に値する。ただし、このシンプルさは広告枠の稀少性を意味しており、将来的に入札競争が激化した際にどう変化するかは未知数だ。

広告の関連性に課題、約14%が的外れな表示

広告の関連性に課題、約14%が的外れな表示

ChatGPT Adsの大きな課題として浮上したのが、広告の関連性だ。SE Rankingのセマンティック分析によると、表示された広告の約14.35%が、ユーザーのプロンプトと実質的な関連性を持たなかった。これは7件に1件の割合で、的外れな広告が表示されている計算になる。

カテゴリによるばらつきが顕著

ミスマッチの発生率はカテゴリによって大きく異なる。ペット分野ではわずか2.6%だったのに対し、人間関係やニュース・政治分野では半数以上が無関係な広告だった。特定のトピックでは、会話の文脈を正しく解釈して適切な広告を選ぶことが依然として難しいことがわかる。

実際のミスマッチ例

調査で観測された例では、デートアプリに関するプロンプトに衣料品小売店の広告が表示されたり、新聞の購読を尋ねるクエリに電力会社の広告が出たりといったケースがあった。ユーザーの意図と広告の内容が明らかにずれている。

関連性なし(Bad)
ユーザー入力「マッチングアプリのおすすめは?」
ChatGPTの回答(マッチングアプリ情報)
広告:衣料品ライフスタイルブランド
クエリと無関係な広告が表示されている
関連性あり(Good)
ユーザー入力「マッチングアプリのおすすめは?」
ChatGPTの回答(マッチングアプリ情報)
広告:マッチングアプリ「ペアーズ」
クエリと広告が一致している

このようなミスマッチは、広告主にとって広告費の無駄遣いになるだけでなく、ユーザーのAI体験の質を下げる要因にもなる。ChatGPTが広告プラットフォームとして成熟するためには、文脈理解の精度向上が不可欠だ。

従来のキーワードターゲティングとは根本的に異なる仕組み

ミスマッチが起きる背景には、ChatGPT Ads特有のターゲティング方式がある。広告主はキーワードリストではなく、自然言語で書かれた「コンテキストヒント」を提供する。これは「自社の広告を表示したい会話の文脈」を説明するテキストで、厳密なマッチングルールではなく、AIによるゆるやかなマッチングのガイドとして使われる。

加えて、広告主は現在のところ、実際にどのクエリや会話が自社の広告表示をトリガーしたのかを確認できない。これでは不適切なプレースメントが起きても原因を特定しづらく、改善のためのフィードバックループを回すのが難しい。

広告出稿とAI回答でのブランド露出はほぼ無関係

広告出稿とAI回答でのブランド露出はほぼ無関係

調査の中で特に注目すべき知見は、ChatGPT上で広告を出稿しても、それが生成AIの回答本文にブランドとして登場する確率はほとんど上がらないという点だ。

広告が表示されたクエリのうち、同じブランドが回答の情報源として引用されたケースはわずか3.63%だった。さらに、広告のURLがそのまま引用に現れたのは0.09%にすぎない。ブランド名の言及も4.44%にとどまる。

つまり、ChatGPTに広告費を投下しても、AIが生成するオーガニックな情報として認識される可能性は極めて低い。有料プレースメントとオーガニックなAI可視性は、今のところ完全に分離していると考えてよい。

YMYL分野で目立つ広告表示、Google 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広告の最適化には、精密なコンテキストヒント設計と、広告表示ログの透明性が必要
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の高度化など、検索体験のさらなる変貌を前提とした長期的視点でのサイト運営がこれまで以上に求められる。
cats.txtが暴いたGEOの証拠水準。AIクロールは機能の証明にならない

cats.txtが暴いたGEOの証拠水準。AIクロールは機能の証明にならない

AI検索時代におけるSEOの延長線上にあるGEO(生成AIエンジン最適化)。その効果を裏付ける「証拠」として、しばしば4つの観測があげられる。AIボットがファイルをクロールした、Googleがインデックスした、LLMがその内容を出力した、ChatGPTが有効性を認めた。しかし、これらの観測は本当に「有効性の証明」と言えるのか。

Search Engine JournalのMark Williams-Cook氏が公開した風刺的な検証が、この疑問に痛烈な答えを出している。同氏は架空の規格「cats.txt」を考案し、上記4つの証拠すべてをクリアすることを実証した。つまり、ウェブ上に置かれたどんなテキストファイルにも同様の現象は起こり得るのであり、それらは機能を保証するものではないというわけだ。

GEO業界でまかり通る「4つの証拠」とその問題点

GEO業界でまかり通る「4つの証拠」とその問題点
「llms.txtが有効」とされる4つの証拠と、cats.txtでも成立する理由
証拠1 〜 AIボットがクロールしている
クローラーの基本動作であり、cats.txtにも多数のボットがアクセスした。
証拠2 〜 Googleにインデックスされた
Googleはテキストファイルをインデックスする。cats.txtも普通にインデックスされた。
証拠3 〜 LLMがそのファイルの内容を出力した
RAGの仕組みで検索結果に出たページから情報を拾っただけ。cats.txtの猫情報も出力された。
証拠4 〜 ChatGPTが「効果的だ」と回答した
ウェブ上の意見の平均を返すだけ。cats.txtについても「効果的」と言った。
結論 〜 これら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の意見は、周囲の言説の平均値にすぎないのである。

「収束問題」が引き起こす根拠の循環

「収束問題」が引き起こす根拠の循環
収束問題の循環構造
SEO専門家が「llms.txtがAI検索に必須」と発信
ネット上に肯定的なブログ記事やスライドが溢れる
AIがそれを学習し、「llms.txtは効果的」と回答
その回答を「客観的なお墨付き」と見なし、さらに推奨記事が増える
教訓 〜 AIの出力はエコーであり、真の評価ではない

この「収束問題」こそが、4つの証拠の背後にある根本的なメカニズムだ。LLMは与えられたネット上の言説の平均的な意見を出力するに過ぎない。cats.txtが「効果的だ」と答えたのも、公開当初に肯定的な書き込みが一定数集まったからである。もし皆が「これはデタラメだ」と書いていれば、AIもそう答えたはずだ。

このように、AI自身の意見を「お墨付き」と捉えるのは危険である。流動的な世の中の雰囲気に左右される出力を、数値や因果関係の証拠と混同してはいけない。

真のSEO・GEO最適化が目指すべきもの

真のSEO・GEO最適化が目指すべきもの

cats.txtの実験が示したのは、あるGEO施策の効果を主張するために使われる「証拠」があまりにも脆弱だという事実だ。AIボットのクロール、インデックス、LLMの出力、ChatGPTの賛同。これらはどれも、「施策が機能していること」の証明にはならない。

問題は、こうした根拠不十分な手法に時間と予算を費やすことにある。確かな価値が実証されている基本的なSEO改善(コンテンツ品質、サイト速度、ユーザー体験の向上)こそが、長期的にAI検索からのトラフィックを伸ばす土台となる。最適化とは、検証可能な小さな改善を積み重ね、競合よりもわずかに優位に立つことだ。まだ誰も検証していない「次のGEOの秘策」を追いかけることではない。

この記事のポイント

  • AI検索最適化の「証拠」とされる4つの観測(クロール、インデックス、LLM出力、ChatGPT賛同)は、どのテキストファイルにも起こる現象であり、施策の有効性を担保しない
  • 2026年8月に公開されたcats.txtは、この4つの証拠すべてをクリアし、根拠の脆弱性を浮き彫りにした
  • LLMの自己評価はネット上の意見の平均を返しているに過ぎず、エコーチェンバー効果によって「有効」と誤認されやすい
  • 限られたリソースは、検証済みの基本SEO改善に集中させるべきであり、エビデンスの弱い新手法に振り回されてはならない
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 の表示回数が通常検索と分離された
  • 表示回数はクリックや引用位置の情報を含まず、あくまで「リンクが表示された」という指標である
  • 従来の検索表示回数とは性質が異なり、合算やブレンド分析は誤解を招くため厳禁
  • 通常検索との比較で、コンテンツの抽出しやすさや構造の課題を発見できる
  • 分析の際は長期的なトレンドとページ属性の分類が不可欠で、数字の上下だけで施策の成否を判断しない
Google Search Consoleの生成AI検索除外設定 仕組みと判断すべきポイント

Google Search Consoleの生成AI検索除外設定 仕組みと判断すべきポイント

Google Search Consoleに、AI OverviewsやAI Modeなど生成AIによる検索機能からサイトを除外できる新設定が追加された。Search Consoleの設定項目に新設されたこのコントロールは、サイト単位でAI検索体験への表示をオフにする一方で、通常の検索結果への影響はないとされる。しかし、実際に使うかどうかの判断は一筋縄ではいかない。Top StoriesがAI Overview内に表示されるケースが増えており、除外設定によって思いがけず貴重な掲載機会を失う可能性が指摘されているからだ。

この記事では、新設定の仕組みと背景、そしてオプトアウトを検討する前に把握しておくべき3つの要素を、データと規制動向を交えて整理する。

生成AI検索除外設定の概要

生成AI検索除外設定の概要

Search Consoleの「設定」内に追加されたこのコントロールは、サイトのコンテンツをAI Overviews、AI Mode、Discoverの生成AI機能に表示するかどうかを決定する。デフォルトは「サイトを含める」で、AI機能内でリンクとして表示され、AIの回答を裏付ける情報源として使われる。除外を選択すると、リンクや文章を問わず、それらの生成AI領域からサイトのコンテンツが一切表示されなくなる。

設定変更が有効になるまでには通常数日かかり、さらにキャッシュの影響で反映に1〜2日を要することもある。ただし、この設定は通常のウェブ検索結果やランキングシグナルにはまったく影響しないと公式ヘルプページで明言されている。また、Merchant CenterやGoogle Adsの参加設定を上書きするものではなく、ショッピング関連の表示とは独立した判断になる。さらに、AIの学習データとしての利用を制御する仕組みとは別物であり、そちらは別のオプトアウト(Google-Extended)を経由する。

CMAの関与と設定誕生の経緯

CMAの関与と設定誕生の経緯

この除外設定が実装された背景には、英国の競争市場庁(CMA)による規制がある。今年に入るまで、AI検索機能だけを対象にサイトを除外する手段は存在しなかった。従来使えたnosnippetはスニペットを非表示にするが、同時にAI Overviewsの表示も奪うオールオアナッシングだったし、Robots.txtはクロール制御に過ぎず、インデックス済みコンテンツの表示可否は決められない。Google-ExtendedはGeminiモデルの学習や一部のグラウンディングを制御するが、AI Overviewsへの表示には関与しなかった。

状況が動いたのは今年1月だ。GoogleがAI検索機能のオプトアウト手法を検討中と発表したのと同日に、CMAが事業者へのAIオプトアウトを義務付ける協議を開始した。そして6月、CMAは生成AIをめぐるコンテンツ使用に関する「行為要件」を課し、Googleは同一週に英国のプロパティで設定のテストを開始した。現在、この要件は英国でのみ法的拘束力を持ち、より詳細な制御の導入期限は来年まで延びている。

Top StoriesとAI Overviewの融合がもたらすジレンマ

Top StoriesとAI Overviewの融合がもたらすジレンマ

Googleの説明では、この設定はAI機能と通常の検索結果を別物として扱う。しかし実際の検索画面では、その境界が曖昧になりつつある。トレンドのニュース検索で、従来は独立して表示されていたTop Storiesのカルーセルが、AI Overviewの枠内に埋め込まれるケースが増加しているのだ。

SEO分析ツールを提供するNewzDashの調査によると、米国でトレンドニュースクエリを追跡した結果のうち15.5%、英国では17.46%で、Top StoriesがAI Overview内に表示されていたという。NewzDashのCEOであるJohn Shehata氏は、この現象について「新しいSearch Consoleの生成AI除外設定を使うと、AI Overview内のTop Storiesからもパブリッシャーが除外される可能性が高い」とLinkedIn上で指摘している。ワシントンポストのSEO責任者Kyle Sutton氏も、自身の観測として同様の傾向を確認しているとコメントしている。

ただし、この解釈はあくまでShehata氏の見解であり、Googleが公式に認めたものではない。公式ヘルプページには「除外されたサイトはAI機能に表示されなくなる」とあるが、AI機能の内部に組み込まれた伝統的な機能についての挙動は明記されていない。つまり、除外設定をオンにすると、AI Overviewsの魅力を削ぐだけでなく、これまでAI機能とは別に獲得していたTop Storiesの露出まで手放すリスクがある。軽々に設定を切り替えられない理由はここにある。

オプトアウト判断前に確認すべき3つの要素

オプトアウト判断前に確認すべき3つの要素

1. AI機能での現在の表示状況を把握する

まず自社サイトがAI機能でどれだけのインプレッションを得ているかを確認する。Search Consoleには「生成AIパフォーマンスレポート」が順次ロールアウトされており、ページ別、国別、デバイス別のインプレッション数が確認できる。ただし、このレポートにはクリック数や検索クエリのデータは含まれていない。Googleアナリティクスなどの一般的な分析ツールでも、流入をAI Overviewsと通常の検索に切り分けることはできない。現状では、AI機能経由のトラフィックを正確に把握できない点を認識しておく必要がある。

2. 各制御ツールの役割を整理する

除外に関する判断を混乱させるのが、類似した複数のコントロールが存在していることだ。どのツールが何を制御するのか、違いを正しく理解しておきたい。

Googleの生成AI関連の主な制御ツール
Search Console除外設定 AI Overviews等の生成AI検索機能への表示だけを制御する。通常の検索結果には影響しない
Google-Extended Geminiモデルの学習やグラウンディングを制御。検索表示そのものには影響しない
Robots.txt クローラーのアクセスを制御するが、インデックス済みコンテンツの表示は制御できない
nosnippet スニペットを非表示にするが、AI機能のコンテンツも同時に消えるオールオアナッシング
※この新しい設定は、通常のランキングに影響を与えずにAI機能からだけ除外する初めての仕組みである

ポイントは、このSearch Consoleの設定がAI機能の表示だけを扱う点だ。これに対して、Google-Extendedはモデルの学習やグラウンディングに特化しており、検索結果の表示可否には関与しない。複数のレバーがあるからこそ、意図しない情報コントロールを避けるためには、それぞれの適用範囲を正確に把握しておく必要がある。

3. ビジネスへの影響を慎重に評価する

除外がもたらす影響は業態によって異なる。ニュースメディアにとっては、AI Overview内のTop Stories露出が収益源のひとつになり得る。ECサイトであれば、サイトコンテンツの表示とショッピング枠への参加は独立した意思決定であるため、除外設定が直接的に商品表示を消すわけではない。ただ、いずれの事業者にとっても共通するのは、AI機能での表示が代替しているトラフィックの規模を正確に評価する手段が今のところ存在しないという事実だ。

CMAの要件では、クリックデータやクリック率といった指標が提供される予定で、その多くは今年12月から順次展開される見通しである。だが現時点では、AI機能へのオプトアウトがもたらす具体的なコストを数字で判断できない。データがない段階での切り替えは、将来の規制対応を先取りする戦略的判断か、あるいは様子見のリスク回避か、経営方針と照らし合わせながら決めるしかない。

今後の展開と欠けているピース

今後の展開と欠けているピース

CMAのスケジュールでは、より詳細なページ単位の除外設定が2027年3月までに導入されることになっている。また、Googleは検索コンソールを通じてクリックデータやクリック率を共有し、パブリッシャーがその数字を評価できるツールを提供する必要がある。さらに、初年度は半年ごとに、その後は状況が落ち着けば年次で、コンプライアンス状況の報告が求められる。

一方で、このような規制によって本当にパブリッシャーの利益が守られるのか疑問視する声もある。オックスフォード大学の研究者Spencer Cohen氏とUCLのTodd Davies氏は、学術誌に寄稿した論文の中で「オプトアウトの救済策では不十分」との見解を示している。Davies氏は過去にGoogleでソフトウェアエンジニアとして勤務した経歴を持ち、LinkedIn上でも「オプトアウトはAI Overviewsが引き起こす問題を解決せず、パブリッシャーのビジネスモデルを保護する効果は限定的だ」と述べている。

結局のところ、今はコントロールが与えられたが、その操作に必要なデータはまだ揃っていない。NewzDashは近日中に除外効果の直接テストを実施すると予告しており、近いうちに実際の影響を測る材料が増える可能性はある。当面は、設定の存在を認識しつつ、運用判断はクリックデータの提供開始後まで保留する、あるいは試験的に一部のプロパティで効果を観察するといった現実的なアプローチが求められるだろう。

この記事のポイント

  • Search ConsoleにAI Overviews等の生成AI検索機能からサイトを除外する新設定が追加された。通常の検索結果には影響しない
  • 英競争市場庁(CMA)の要請により導入され、現在はサイト単位でのみ制御可能。ページ単位のコントロールは2027年3月までに実装予定
  • Top StoriesがAI Overview内に表示されるケースが15〜17%存在し、除外によってそれらの露出も失うリスクがある
  • 現状ではAI経由のトラフィックやコンバージョンを切り分けるデータがなく、オプトアウトの損得を数値で評価することはできない
  • Google-ExtendedやRobots.txtなど類似の制御ツールとの違いを理解し、本来の意図に合った設定を行う必要がある
クロールバジェット最適化の新ガイドライン、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ステータスコードは重要ページには使用せず、影響の少ないページに限定する
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 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月に廃止、既存のルールを直ちに更新する必要がある
bot判定画面が原因でGoogleインデックスから消える?セキュリティ対策の盲点と解決策

bot判定画面が原因でGoogleインデックスから消える?セキュリティ対策の盲点と解決策

Webサイトの安全を守るセキュリティ対策が、意図せず検索順位を急落させる原因になっているかもしれない。不審なアクセスを防ぐための「bot判定画面」が、Googleの巡回を妨げる事例が報告されている。

この問題が発生すると、検索エンジンにページが登録されなくなったり、他サイトのコピーとして処理されたりするリスクがある。サイト運営者が気づかないうちに進行する、セキュリティとSEOの衝突について詳しく解説する。

bot判定画面がGoogleインデックスからページを消し去る仕組み

bot判定画面がGoogleインデックスからページを消し去る仕組み

サイトのセキュリティを強化すると、不正なアクセスやスパムを遮断できる。しかし、その防御壁がGoogleのクローラー(検索エンジンの巡回ロボット)まで阻んでしまうことがある。これがインデックス消失を引き起こす引き金だ。

不審なアクセスと判定されたGooglebot

クローラーとは、世界中のWebサイトを巡回して情報を集める自動プログラムのことだ。Googleが派遣するクローラーは「Googlebot(グーグルボット)」と呼ばれる。通常、このGooglebotはサイトのコンテンツを自由に読み取れる必要がある。

しかし、サイトのセキュリティフィルターがGooglebotのアクセスパターンを「不審な自動プログラム」と誤認することがある。その結果、本来のコンテンツの代わりに「私はロボットではありません」という確認を求める画面を返してしまう。この画面は一般に「インターシャルページ」や「bot判定画面」と呼ばれるものだ。

重複コンテンツとして処理されるリスク

Googlebotがサイトを巡回した際、どのページにアクセスしても同じ「bot判定画面」が返ってくると、検索エンジンは混乱する。すべてのページの中身が同一であると判断してしまうからだ。

Search Engine Journalの記事で紹介されたGoogleのJohn Mueller(ジョン・ミューラー)氏の解説によると、このような状況ではGoogleは複数のページを「重複コンテンツ」として処理する。さらに、他の多くのWebサイトでも同じセキュリティサービスのbot判定画面が使われているため、Googleはそれらをすべて同じグループとみなしてしまう。最悪の場合、他人のサイトのページが本物(正規バージョン)と判定され、自サイトのページが「コピー」として検索結果から排除される事態に陥る。

従来の誤判定フロー(Before)
Googlebot サイトへ巡回アクセス セキュリティ壁 不審なアクセスと誤認
■ 結果:すべてのページで「私はロボットではありません」画面をGoogleに返してしまう
本来あるべき正常フロー(After)
Googlebot サイトへ巡回アクセス セキュリティ壁 検索クローラーを検知して通過
■ 結果:正しい記事コンテンツをGoogleに渡し、正常にインデックスされる

上の図が示すように、セキュリティが強すぎるあまりGooglebotを一般の不審なアクセスと区別できなくなると、検索エンジンにはエラー画面しか届かなくなる。

なぜサイト運営者はこの問題に気づきにくいのか

なぜサイト運営者はこの問題に気づきにくいのか

この問題の最も恐ろしい点は、サイトの管理者が普通に自分のサイトを閲覧しているだけでは、異常に全く気づけないことだ。問題が静かに進行し、検索順位が落ちて初めて事態を把握することになる。

一般ユーザーには正常に表示される罠

bot判定画面は、すべての訪問者に表示されるわけではない。セキュリティシステムが「怪しい」と判定したアクセスに対してのみ表示される。サイト運営者や一般的なファンがパソコンやスマートフォンからアクセスする場合、通常は信頼できるアクセスとして処理されるため、何の問題もなくサイトが表示される。

そのため、運営者が「今日もサイトはきれいに表示されている」と思っていても、Googlebotだけは裏でブロックされ、エラー画面を見せられ続けているというねじれ現象が起きる。これが発見を遅らせる最大の原因だ。

Search Consoleで異常を検知する方法

この問題を検知するには、Googleが公式に提供している無料ツール「Google Search Console(グーグルサーチコンソール)」を活用するしかない。具体的には以下のステップで確認を進める。

  • 「ページ」レポートを開き、エラーの推移を確認する
  • 「重複コンテンツ」や「送信されたURLが正規URLとして選択されていません」というステータスが急増していないかチェックする
  • 不審なページの「URL検査」を実行する
  • Googleが選択した正規URLの項目を確認し、自分のドメインとは異なる見知らぬ外部サイトのURLが登録されていないか確認する

もしURL検査の結果、Googleが選択した正規URLに他人のサイトが指定されていた場合、自サイトのbot判定画面が他サイトのそれと「同一の重複コンテンツ」とみなされた可能性が極めて高い。

セキュリティ対策とクローラー巡回の衝突

セキュリティ対策とクローラー巡回の衝突

なぜこのような誤判定が起きるのだろうか。それは、Webサイトを高速化・安全化するためのインフラの仕組みに関係している。

CDNやホスティングによる自動ブロック

多くのWebサイトは、CDN(コンテンツ配信ネットワーク)やホスティングサーバーが提供するセキュリティ機能を利用している。CDNとは、世界中に配置されたサーバーを経由してサイトの表示を高速化し、同時に不正なアクセスからサイトを守る仕組みだ。

これらのセキュリティシステムは、短時間に大量のアクセスを行う接続元を自動的に検知し、アクセス制限をかける。Googlebotはサイト内の多くのページを素早く巡回するため、クローラーの活動が活発になったタイミングで、セキュリティシステムが「DDoS攻撃(サーバーに過剰な負荷をかける攻撃)」や「不正な情報引っこ抜き」と誤認してブロックを起動してしまうのだ。

「エラーコードなし」でコンテンツが空になる現象

この問題がさらに厄介なのは、サーバーが「アクセス拒否」を示すエラーコード(403 Forbiddenなど)を返さないケースがある点だ。セキュリティシステムによっては、接続自体は「200 OK(正常に通信完了)」として処理し、画面の見た目だけをbot判定画面に差し替える。

Googleのクローラーは「通信は成功した」と受け取るため、壊れたページとして処理せず、そのままbot判定画面のテキストをインデックスしてしまう。過去にも、セキュリティ設定がGooglebotのアクセスを静かに遮断し、中身が全くない状態でページが登録されるトラブルが報告されている。通信の成否だけを監視する単純なチェックツールでは、この異常を検出できない。

【比較】サーバーの応答とGoogleの認識パターンの違い
パターンA:通常のアクセス拒否(検知しやすい)
サーバー応答:403 Forbidden(エラー)
Googleは「アクセスできない」と判断し、インデックスを現状維持または保留にする。
パターンB:bot判定画面への差し替え(今回の問題・検知困難)
サーバー応答:200 OK(正常通信)
Googleは「正常なページ」と受け取るが、中身がbot判定画面(重複コンテンツ)のためインデックスから消去される。

通信自体が「正常終了」とみなされるパターンBの場合、システム監視をすり抜けてしまうため、SEOに深刻なダメージを与えるまで放置されやすい。

検索順位を守るための具体的な解決手順

検索順位を守るための具体的な解決手順

もしSearch Consoleで「重複コンテンツ」のエラーを発見したり、特定のページがインデックスから消えていることに気づいたりした場合は、迅速な対処が必要だ。

セキュリティ設定のホワイトリスト化

根本的な解決策は、導入しているセキュリティサービスやCDN、ホスティングサーバーの設定を見直すことだ。Googlebotなどの主要な検索エンジンクローラーを「ホワイトリスト」に登録し、bot判定の対象から除外する設定を行う。

多くの大手セキュリティサービス(Cloudflareなど)には、検索エンジンのクローラーを自動的に認識して通過させる機能が標準で備わっている。この機能がオフになっていないか、またはカスタムルールによって上書きされてブロックされていないかを確認する必要がある。設定が難しい場合は、セキュリティの担当者やサーバーのサポート窓口に相談することを推奨する。

修正後の再クロール申請

ブロック設定を解除した後は、Googleにサイトが修正されたことを伝える必要がある。これを放置すると、Googleが次の巡回を行うまでエラー状態が維持されてしまう。

具体的には、Search Consoleを開き、該当するエラーレポート内にある「修正を検証」ボタンをクリックする。これにより、Googleに対して優先的な再クロールをリクエストできる。また、特に検索トラフィックにとって重要なページがある場合は、「URL検査」ツールから個別に「インデックス登録をリクエスト」を送信すると、より早く検索結果に復帰させることができる。

この記事のポイント

  • セキュリティ対策のbot判定画面が、Googleクローラーの巡回を遮断することがある
  • Googlebotがブロックされると、サイト内の全ページが「同じエラー画面」になり重複コンテンツとみなされる
  • 他サイトの同じエラー画面と同一視され、最悪の場合は他サイトのコピー扱いとしてインデックスから消える
  • 一般ユーザーには正常に表示されるため気づきにくく、Search Consoleでの定期的なエラー確認が必須となる
  • 解決には、CDNやサーバーのセキュリティ設定でGooglebotをホワイトリストに登録し、修正後に再クロールを申請する
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展開は他地域やデスクトップにも拡大予定で、早期の対策準備が重要