タグアーカイブ SEO

Googleがインデックス不要のランキングを理論実証。検索結果ページは見えなくなる

Googleがインデックス不要のランキングを理論実証。検索結果ページは見えなくなる

Googleの研究チームが、インデックスなしで文書をランキングできる計算手法を理論的に証明した。検索結果ページは「見るもの」から「モデルが内部で処理するステップ」に変わる可能性がある。

この研究は2026年1月に発表されたAutoRegressive Ranking(ARR、自己回帰ランキング)という手法に関する論文が基盤になる。Googleは2021年から同じ方向の研究を積み重ねてきた。

実務者にとって重要なのは、ビームサーチと呼ばれる生成プロセスが可視性の境界線になることだ。ランキング上位の限られた件数に入れない限り、そもそも生成されないため「圏外」と「生成されず」の区別すらできなくなる。

Googleが2021年から進めてきた研究の集大成

Googleが2021年から進めてきた研究の集大成

この論文は突然出てきたものではない。2021年にGoogleの研究者4人が発表した「Rethinking Search(検索の再考)」では、検索システムは参照リストを提示するのではなく、引用可能なコーパスから直接回答すべきだと主張していた。これは研究提案であり製品ロードマップではないとの但し書きが付いていた。

2022年にはほぼ同じ研究グループがDifferentiable Search Index(微分可能検索インデックス、DSI)を発表した。1つのTransformerモデルがクエリを文書識別子に直接マッピングできることを示した。コーパス全体がモデルのパラメータにエンコードされる。これが新しいランキング手法の原型だ。

2026年1月の論文はその理論を埋める。デュアルエンコーダの埋め込み次元は文書数に比例して拡大する必要があるのに対し、固定の隠れ次元を持つ自己回帰モデルは任意の数をランキングできることを証明した。さらにSToICaLという学習ロスを導入し、モデルが上位1件だけでなくリスト全体を意識して学習するようにした。提案、プロトタイプ、証明という流れで、5年間の研究が1つの方向に収束している。

従来の2段階パイプライン(Before)
デュアルエンコーダ 高速に文書を検索 → クロスエンコーダ 精度高く再ランキング → 検索結果ページ
↓
新しい単一生成モデル(After)
1つの生成モデル クエリを直接理解 → docIDを生成 ランキングを内部処理で実行
※検索結果ページは内部ステップになり、ユーザーには答えだけが提示される

従来の検索は「検索してから並べ替える」2段階だったが、新しい手法では1つのモデルが文書識別子を生成しながらランキングまで完了する。この違いはアーキテクチャの変更ではなく、検索という概念の再定義に近い。

文書はコードになり、コードがランクされる

文書はコードになり、コードがランクされる

このアーキテクチャでは文書はURLではない。docID(文書識別子)という短いトークン列として扱われる。モデルは単語を生成するのと同じ仕組みで、文書識別子を1つずつ生成していく。

ショッピング実験では、各商品の識別子を商品タイトルの埋め込みベクトルから3つの数字に圧縮して作った。識別子自体が意味を持ち、似た商品は似た数字の並びを共有する。モデルは最も確からしい識別子から順にビームサーチで生成していく。調べるのではなく、アドレスを生成する。検索ルックアップが存在しない点が本質的な違いだ。

文書からdocIDへの変換
文書タイトル 埋め込みベクトルに変換 → 3つの数字に圧縮
↓
docID(例 3, 7, 12) 類似の文書はIDも近くなる
■ 文書データ ■ 生成される識別子

ショッピング実験では、商品タイトルの埋め込みベクトルを3つの数字に圧縮して識別子を作った。似た商品は似た識別子を持つため、ランキングが意味を持つ。

識別性が最適化目標になる

ページが埋め込み空間で隣接するページと区別できない場合、安定した識別子を持てない。2つの重複に近い商品ページは隣接する順位を争うのではなく、同じアドレスを争うことになる。そして片方は完全に負ける。

ランキング関数はトレーニングセットそのものになる。SToICaLはクエリ、文書識別子、真のランクの3つ組で学習する。クリックログ、評価者の判断、エンゲージメント信号など、グレード付きリストを生成したものがアルゴリズムになる。リバースエンジニアリングすべきランキング要素の層は存在しなくなる。

鮮度がトレーニング問題に変わる

従来のインデックスでは新しいページはクロールして挿入するだけでよかった。パラメトリック生成インデックスでは学習する必要がある。Googleの後続研究DSI++では、新しい文書を継続的にインデックスすると既存文書の記憶が大幅に失われることが分かっている。

ニュースパブリッシャーにとって「インデックスされた」と「ランカーに認識された」は別のイベントになる。ARR実験では候補をプロンプト内に置くことで回避している。実際の展開も古典的検索が生成ランカーに候補を供給するハイブリッドから始まる可能性が高い。純粋な生成インデックスは長期的な方向性だ。

ビームサーチが可視性の境界線になる

ビームサーチが可視性の境界線になる

ビームサーチは生成モデルが1つの答えではなく短いリストを生成する仕組みだ。各生成ステップで確率の高い部分列を一定数(ビーム幅)だけ保持し、他は捨てる。ビーム幅が10なら最終リストは10件を超えない。

ポイントは11位が「悪い結果」ではなく「存在しない」ことだ。従来のデュアルエンコーダなら最近傍インデックスで上位1000件をほぼ無料で取得できた。スコアリングが安価だからリストは副産物だった。しかしビーム幅10の生成モデルでは11位はそもそも生成されない。

ビームサーチの仕組み(ビーム幅=3の例)
生成ステップ1
候補A 候補B 候補C 上位3件を保持
↓
生成ステップ2
候補A-1 候補A-2 候補B-1 他の候補は破棄
↓
最終結果
1位 2位 3位 11位以下はそもそも生成されない
※ビーム幅を超える結果は「圏外」ではなく「存在しない」。これが可視性の境界線になる。
■ 初期候補 ■ 中間候補 ■ 最終結果

ビームサーチでは各ステップで一定数(ビーム幅)の候補だけが生き残る。ビーム幅が10なら結果は10件止まりで、11位は計算すらされない。

ランクトラッキングの意味が消える

ページ2は設計上の決定ではなく、存在しないものになる。ビーム幅以下のランクトラッキングは何も測定しない。可視性は2値化する。「生成されたセットに入っているか、入っていないか」だ。

外部からは「ランキングが悪い」と「生成されなかった」を区別できない。どちらも見た目は同じだからだ。実務者の問いは「何位か」から「生成セットに入っているか、どのクエリ形状で、どれだけ一貫して」に変わる。これが可視性計測プラットフォームが答えるべき問いになる。

論文には皮肉な点がある。実際の貢献は1位以下の改善だ。WordNetでの実験では、ランク認識型トレーニングが2位から5位の再現率を50%台から90%台半ばまで押し上げた。2位から5位の並び順が改善される瞬間に、検索結果画面には表示されない領域が広がっていく。

広告と収益モデルへの影響

広告と収益モデルへの影響

Alphabetの2026年第2四半期のGoogle検索およびその他収益は632億7000万ドル、前年比17%増だった。広告オークションは別システムであり、この論文は直接触れない。収益に関係するのはコスト面だ。

2段階パイプラインが存在するのは、クロスエンコーダをコーパス全体に実行するのが高すぎるからだ。自己回帰ランキングは最近傍インデックスを不要にし、全文書を個別にスコアリングしない。生成結果の構造的なコスト削減になる。

コストはGoogleがAI回答をデフォルト体験としてどこまで押し広げるかの静かな制約だった。十分なコスト削減が実現すれば、広告在庫が存在する10個の青いリンクを維持する構造的な理由が弱くなる。広告が消えるのではなく、広告を載せる面が変わる。広告も一緒に移動するのだ。

広告システムの変容は始まっている

Search Engine Journalの著者Duane Forrester氏は2025年8月に「Cohorts, Clusters, and the Coming AI Ad System(コホート、クラスタ、到来するAI広告システム)」という記事を公開し、Intent Vector Bidding(意図ベクトル入札)という概念を提唱した。広告主のコンテンツがユーザープロンプトの意味とどれだけ近いかで掲載が決まり、広告自体もクエリ時に広告主の資産から組み立てられるという仕組みだ。

9か月後のGoogle Marketing Liveで、GoogleはAI検索向けの広告フォーマットを発表した。ユーザー固有のクエリに即座に合わせ、質問の具体的な言い回しからクリエイティブを生成する。キャンペーンを実行し資産を供給する点は従来通りだが、クリエイティブの半分は実現した。

ARR論文はそのメカニズムを完成させる。Google Researchのトークンオークション論文は、広告主がトークンごとに生成される広告テキストに影響を与えるために入札するオークションを設計した。自己回帰ランキングは有機的な文書識別子をトークンごとに生成する。同じ生成プロセスが答え、有機ソース、スポンサード掲載を同時に生成できる可能性がある。

実務者が今着手すべき3つの対策

実務者が今着手すべき3つの対策

研究論文を基盤にプログラム全体を再構築する必要はない。この段階では3つの小さな動きが釣り合いの取れた対応になる。

STEP 1 識別性を測定可能な特性として扱う
意味で区別できないページを監査する。生成インデックス下では重複ページは1つのアドレスを争うことになる
↓
STEP 2 測定をポジションから含有に移す
ビームが境界線になる日までにベースラインの履歴を蓄積しておく
↓
STEP 3 有料戦略を新しい広告システムの視点で見直す
クリエイティブ生成の半分はすでに実装済み。広告の作り方そのものが変わる

この3つの対策は即座に実行可能で、研究の進展を待たずとも価値がある。識別性の監査と可視性測定の移行は、現在の検索環境でも有効な施策だ。

この記事のポイント

  • Googleがインデックスなしで文書をランキングできる計算手法を理論的に証明した
  • 文書はdocIDというコードになり、モデルが生成するアドレスに変わる
  • ビームサーチが可視性の境界線になり、上位10件以外は存在しない扱いになる
  • ランクトラッキングより生成セットへの含有率測定が重要になる
  • 広告システムはトークン単位の入札と生成型クリエイティブへ進化する
AI検索の7つの神話をデータで検証。サイト運営者が知るべき真実

AI検索の7つの神話をデータで検証。サイト運営者が知るべき真実

AI検索の台頭をめぐって「Googleは死んだ」「SEOは終わった」といった過激な主張が飛び交っている。しかし、実際のデータを確認すると、その多くが誤解や誇張であることが分かる。

本記事では、AI検索とSEOに関する7つの神話を取り上げ、調査データを基にそれぞれを検証する。サイト運営者やEC担当者が、感情的な主張に振り回されずに戦略を立てるための指針となるはずだ。

AI検索と従来型検索をめぐる3つの神話

AI検索と従来型検索をめぐる3つの神話
広まっている神話
ChatGPTやPerplexityの利用が増えるたびに、Googleなど従来型検索の需要は縮小している
↓
データが示す現実
AI検索も従来型検索も、四半期ごとにほぼ同じペースで成長している
■ 神話 ■ データに基づく結論

上の図は「AI対従来型検索」という二項対立ではなく、両者が共存して成長していることを示している。

AI検索は従来型検索を殺していない

「AI検索がGoogleを駆逐する」という主張は、感情には訴えるがデータと一致しない。State of Search Q2 2026レポートによると、AI検索と従来型検索は四半期ごとにほぼ同じ成長率で推移している。

つまり、AIプラットフォームは検索需要を奪っているのではなく、既存の検索需要の上に新たな層を追加している形だ。ただし、検索需要全体が伸びる一方で、Googleが自社画面内で回答を完結させる傾向が強まった結果、外部サイトへのクリック数は減少している。

同じ調査では、Google傘下以外のデスクトップ検索結果へのクリックが2025年4月以来の最低水準にあることも示された。検索意欲は伸びているが、Googleからオープンウェブへの送客は減っている構図だ。

ゼロクリック環境でもオーガニック流入は伸ばせる

「2026年にオーガニック流入を伸ばすのは不可能」という主張も誤りだ。AI OverviewやAI Modeの影響が強い分野では苦戦するものの、地元密着型の中小企業では2026年7月に過去最高のオーガニッククリック数を記録した事例が報告されている。

重要なのは、ゼロクリック圧力が全業界に均等にかかるわけではないという認識だ。ブログ記事とサービスページの両方で、ブランドに依存しない施策のみで成果を出した例もある。業界やビジネスモデルによって影響度は大きく異なる。

AI生成コンテンツでも上位表示は可能

「GoogleやLLMはAI生成コンテンツを検出して抑制する」という神話も根強い。しかし、2025年3月から9月にかけてAIで生成し軽い人間レビューのみを経て公開した4本の記事が、現在も上位表示とパフォーマンスを維持している事例がある。

Googleが低品質で独自性のないAI出力を評価しないのは事実だ。ただし検索エンジンが判断しているのは「AIが書いたか」ではなく「付加価値があるか」という観点である。良いアイデア、専門知識、独自データ、明確な視点から生まれたコンテンツなら、AIを執筆に使っても通常の記事と同じ扱いを受ける。

テクニカルSEOの神話を検証する

テクニカルSEOの神話を検証する
神話 4の主張
llms.txtを設置すれば、AI検索での表示頻度が上がる
↓
データが示す現実
Googleは公式に「llms.txtを使用しない」と明言。効果測定でも有意な変化なし

llms.txtは「AIが読むためのサイトマップ」として注目されたが、現時点ではインフラ整備の域を出ない。

llms.txtに過度な期待は禁物

llms.txtとは、AIクローラーがサイト内容を理解するためのテキストファイルである。AI検索での可視性を高める目的で導入するサイトが増えたが、この方法には明確な効果が確認されていない。

まず、Googleは公式ドキュメントで「AI検索の検出にllms.txtを使用しない」と明確に述べている。さらに、10サイトを対象にllms.txt導入前後の90日間を追跡した調査では、AIクロール頻度にもAI経由のトラフィックにも測定可能な変化が見られなかった。変化があったサイトも、他のSEO施策によるものだった。

結論としては、llms.txtは「戦略」ではなく「インフラ」である。設置して損はないが、それだけでAI可視性が改善するわけではない。

LLMはJavaScriptをレンダリングできない

「最新のAIクローラーはブラウザと同じようにJavaScriptを実行できる」という主張も事実と異なる。Profoundの調査によると、新興AI検索プロバイダーの多くはJavaScriptレンダリング機能を持たず、クライアントサイドレンダリングのコンテンツを読み取れない。

サーバーサイドレンダリング(SSR)がAI可視性の観点で重要なのはこのためだ。Headless CMSやJavaScriptに依存したサイトを運営している場合、AI検索にコンテンツを認識してもらえないリスクがある。

やっかいなのは、LLM自身がこの弱点を認めないことだ。実際にChatGPTにJavaScriptで隠された記事の要約を依頼したところ、「問題なく読める」と答えた後に、実は別の記事から内容を引用していたと認めた事例が報告されている。AIが「読める」と言っても、その言葉を鵜呑みにするのは危険だ。

AI流入の計測とSEOチームの価値

AI流入の計測とSEOチームの価値
AI経由の流入が計測から漏れる仕組み
AIチャット ブランド名を言及 → ユーザー 数時間から数日後にサイトを訪問 → 解析ツール 「直接流入」として記録
↓
計測上の問題
AI経由の訪問の約97%がUTMパラメータを持たず、直接流入や自然検索として計上される
■ AIチャット ■ ユーザー ■ 解析ツール

AIがブランドに言及してから訪問が発生するまでに時間差があるため、成果がAI由来と認識されにくい。

AI経由の流入は97%が計測されていない

AIがサイトに送るトラフィックは「誤差レベル」と思われがちだが、実際には大幅に過小評価されている。AIのブランド言及効果を調査した研究では、AIアシスタントがブランドを言及した後、そのユーザーは今後7日間に予測ベースラインの1.5倍から2.5倍の頻度でブランドサイトを訪問することが分かった。

注目すべきは計測の難しさだ。2026年5月のChatGPTアップデートで引用件数が増えた後でさえ、AI経由の訪問のうち追跡可能な参照パラメータを保持していたのは約2.5%のみだった。つまり約97%の訪問が直接流入や自然検索として記録され、AIが起点だった痕跡を残していない。

さらに訪問のタイミングも影響する。AI言及から1時間以内に訪問したのは20.5%、24時間以内でも42%にとどまり、初回訪問の多くは翌日以降に発生する。この時間差が、AI起点の流入を人間が認識しにくい理由だ。

SEO人材をAIで置き換えるのは時期尚早

「AIが監査も記事構成も技術修正もできるから、SEO担当者は不要になる」という主張も短絡的だ。NP Digitalの調査では、AIは人間より多くのエラーを検出できたが、重要度の高いエラーを見落とし、優先順位付けも不得手であることが示された。

AIは規模の面で優れており、大量の軽微なエラーを高速で検出する。しかし、キーワード調査や検索意図の判断といった大局的な意思決定は苦手だ。Altテキストの修正やメタディスクリプションの改善といった軽微な項目を「最優先」と誤って推奨することもある。

さらにAIは、存在しない修正方法を提案したり、既に存在するページを推奨したり、明らかに悪いアイデアに自信満々で同意したりする。AIはSEOの道具箱において強力なツールだが、人間の判断を完全に代替するには至っていない。

この記事のポイント

  • AI検索と従来型検索は同じペースで成長しており、共存関係にある
  • ゼロクリック圧力は業界によって異なり、適切なSEO戦略で成果は出せる
  • llms.txtはインフラであり、設置だけでAI可視性が向上するわけではない
  • AI経由の流入の約97%が計測されず、実際の効果は過小評価されている
  • SEOチームをAIで置き換えるのは時期尚早で、人間の判断力は依然として重要
AI検索時代のGEO対策、ChatGPTやPerplexityに引用されるための技術SEOとコンテンツ戦略

AI検索時代のGEO対策、ChatGPTやPerplexityに引用されるための技術SEOとコンテンツ戦略

AI検索エンジンが情報取得の主流になりつつある。ChatGPT、Perplexity、Geminiなどの生成系エンジンは、質問に対する答えを直接生成する。従来の検索結果一覧からリンクをクリックする流れが変わり始めた。

この変化に対応するには、キーワード中心のSEOから生成エンジン最適化(GEO)への転換が必要だ。GEOとは、AIが回答を生成する際に自社コンテンツを一次情報源として引用してもらうための施策群である。従来SEOがブルーリンクのクリック獲得を目指すのに対し、GEOはAIの回答内で引用されることを目指す。

本記事ではAIクローラーへの技術対応と、AIに引用されやすいコンテンツ戦略の両面から具体的な施策を解説する。ECサイト運営者とWeb制作担当者に向けた内容だ。

GEOの基本を理解する

GEOの基本を理解する

生成エンジン最適化(GEO)は、AI検索エンジンが回答を合成する際に、自社サイトのコンテンツを情報源として検出・理解・引用されることを目的とする。従来SEOが「検索結果のクリック数」を評価指標にするのに対して、GEOは「AI回答内での引用率」を重視する。

従来のSEO(Before)
キーワードをページに詰め込み、検索結果のブルーリンクでクリックを獲得する。
対策例 → タイトルタグ最適化、メタディスクリプション、被リンク獲得
↓
GEO(After)
AIが回答を生成する際に、一次情報源として引用されるコンテンツを作る。
対策例 → 構造化データ、独自データ発信、直接回答フォーマット

従来SEOからGEOへの考え方の転換をBeforeとAfterで対比した。

AI検索エンジンがサイトを選ぶ仕組み

AI検索エンジンは検索拡張生成(RAG)という仕組みで回答を作る。RAGとは、事前学習済みの大規模言語モデル(LLM)にリアルタイムのWeb情報を取り込ませ、最新の情報を含む回答を生成する技術だ。AIは質問を受けると、関連するWebページを取得し、その内容を引用しながら回答を合成する。

つまりAI検索で自社サイトが引用されるには、AIが「このページは信頼でき、回答に使える」と判断できる状態にしておく必要がある。そのために技術SEOとコンテンツ戦略の両面から対策を進める。

AIクローラー対応の技術SEO

AIクローラー対応の技術SEO

AIプラットフォームは専用のクローラーとRAGパイプラインを使ってWebコンテンツを取り込む。技術チームは、独自データを保護しながらコンテンツへのアクセスを確保する必要がある。

STEP 1 Webページのコンテンツが公開される
↓
STEP 2 AIクローラーがアクセスして内容を取得
↓
STEP 3 RAGチャンキングで情報を適切な単位に分割
↓
STEP 4 ベクトルデータベースに埋め込みとして保存
↓
STEP 5 回答生成時に該当箇所が引用される

AI検索の裏側では、このようにクローリングから引用までの5段階の処理が走る。

robots.txtでボットを区別する

AI関連のクローラーは用途別に分かれている。学習用クローラー(GPTBotなど)とリアルタイム検索用クローラー(ChatGPT-User、PerplexityBotなど)を区別し、robots.txtで個別にアクセス制御する。学習用ボットをブロックすれば独自データを保護でき、検索用ボットを許可すればAI回答への情報提供を継続できる。

ECサイトの場合、商品の仕様データや価格情報は検索用ボットに公開しつつ、学習用ボットのアクセスを制限する運用が現実的だ。

構造化データでAIに文脈を渡す

Schema.orgの語彙を使った構造化データの実装範囲を広げることが重要だ。Organization、Product、HowTo、TechArticle、FAQPageなどのタイプを適切に付与すると、LLMのパーサーがエンティティ間の関係性を明示的に理解できるようになる。

ECサイトであれば商品ページにProductスキーマを付与し、価格、在庫状況、レビュー評価を機械可読な形式で伝える。AI検索エンジンが「この商品はいくらか」という質問に答える際、構造化データが整っているページが優先的に引用される。

RAGチャンキングを意識したHTML設計

RAGパイプラインはWebページを小さな単位(チャンク)に分割し、ベクトルデータベースに格納する。この分割処理を意識して、ページ構造を論理的なHTML階層で設計することが有効だ。<h2>や<h3>の見出しを適切に使い、各段落を独立して理解できる簡潔な長さに保つ。

見出しが明確で段落が短いと、RAGの分割処理が正確になり、回答生成時に該当箇所だけをクリーンに抽出・引用できる。長い段落に複数の話題を詰め込むと、チャンクの境界が曖昧になり引用精度が下がる。

表示速度とインデックス性の確保

AI検索エンジンはライブ検索の際、高速かつ安定したページ取得を優先する。モバイル対応を徹底し、サーバー応答時間(SRT)を短く保つことが重要だ。取得がタイムアウトすると、そのページは回答生成の候補から除外される。

SRTとはサーバーがリクエストに応答するまでの時間である。画像最適化、キャッシュ活用、CDN導入などでSRTを短縮しておくと、AIクローラーによるリアルタイム取得の成功率が上がる。

生成AIに引用されるコンテンツの作り方

生成AIに引用されるコンテンツの作り方

AI検索エンジンはハルシネーション(誤情報生成)のリスクを減らすため、権威性の高い情報源を優先的に参照する。コンテンツ戦略は「検証可能な情報密度」を軸に再設計する必要がある。

従来のコンテンツ構成(Before)
結論を後半に置き、導入文を長く書く形式。AIが要約しにくい。
導入3段落 → 背景説明 → 事例 → 最後に結論
↓
直接回答フォーマット(After)
冒頭に要約と結論を置く形式。AIが即座に抽出して引用できる。
要約表 → 結論 → 詳細説明 → 補足データ

AIが回答に使いやすいコンテンツ構成への変更点を示した。

エンティティベースの権威性構築

エンティティとは、人物、組織、商品、概念など明確に定義できる対象のことだ。自社ブランドの中核となるエンティティを中心に、関連する業界用語やトピックを密度高くまとめたトピッククラスターを作る。

具体的には、主語と述語が明確で断定を含む文章を心がける。「当社の商品Aは業界最高水準の耐久性を持つ」のような曖昧な表現ではなく、「商品Aは10万回の開閉テストに合格した」と具体的な事実を書く。このような文章はAIが抽出しやすく、引用時の信頼性も高い。

独自データとオリジナルリサーチの発信

AIモデルは集約された二次情報よりも、独自の統計、調査結果、オリジナルレポートを優先的に参照する。自社で実施したアンケート結果、商品の性能テストデータ、業界動向の独自分析などを公開することで、一次情報源としての地位を確立できる。

ECサイト運営者であれば、自社商品の比較テスト結果、顧客満足度調査、購入データから見える傾向などを記事化すると効果的だ。競合が真似できない独自データは、AI検索で安定的に引用される資産になる。

直接回答抽出フォーマットの採用

技術記事や教育コンテンツでは、ページの冒頭に要約表、箇条書きのポイント、明確な定義を配置する。検索意図の高い質問には、背景説明の前に直接回答する構成が有効だ。

たとえば「商品Aの防水性能はどの程度か」という質問を想定したページでは、冒頭に「IPX7等級で水深1メートルに30分間耐える」と明記し、その後に試験方法や比較データを展開する。この構成ならAIが回答をそのまま引用できる。

マルチモーダル検索への対応

AI検索エンジンは音声や画像を使った検索にも対応し始めている。マルチモーダル検索とは、テキスト以外の入力手段を含む検索のことだ。画像検索AIが商品を認識して回答するケースが増える。

商品画像や図表には説明的なalt属性を付与し、構造化されたキャプションを添える。画像の内容をAIが理解できるようにすることが、将来のマルチモーダル検索での可視性につながる。

AI検索を味方につける運用の転換点

AI検索を味方につける運用の転換点

従来のオーガニック検索トラフィックは、AIが直接回答を返すようになるにつれて集約化が進む可能性がある。ただし、技術インフラを最適化し、高密度な一次情報を公開し続ければ、ブランドはAI検索の裏側で推奨される情報源としての地位を維持できる。

重要なのは、目先のクリック数ではなく「AIに引用される確率」を評価指標に加えることだ。AI検索時代のブランド可視性は、回答の出典として選ばれる頻度で測られる。ECサイト運営者は、商品情報の構造化と独自データの発信を組み合わせ、この変化に対応すべきである。

SEO担当者と技術チームが協力し、クローラー管理からコンテンツフォーマットまでを一貫して整備すること。これがAI検索時代に競争優位を保つための実践的なアプローチだ。

この記事のポイント

  • AI検索時代には従来のキーワード中心SEOからGEO(生成エンジン最適化)への転換が必要
  • robots.txtで学習用ボットと検索用ボットを区別し、独自データを保護しつつ引用機会を確保する
  • 構造化データの拡充とRAGチャンキングを意識したHTML階層設計が技術SEOの柱になる
  • 独自データとオリジナルリサーチの発信がAIからの一次情報源としての地位を確立する
  • 冒頭に要約と結論を置く直接回答フォーマットがAIによる引用率を高める
Cloudflareがrobots.txtを自動生成するBot Preference Syncの仕組みと検証

Cloudflareがrobots.txtを自動生成するBot Preference Syncの仕組みと検証

Cloudflareが2026年8月21日、サイトのrobots.txtを自動生成する新機能「Bot Preference Sync」を発表した。Search、Agent、Trainingの3つのカテゴリ設定から、Cloudflareがrobots.txtの該当部分を自動的に書き換える仕組みだ。robots.txtとエッジ強制設定の矛盾を解消すると期待される。

この機能は無料プランから利用でき、新規顧客にはデフォルトでオンになる予定だ。一方でカテゴリ単位の設定には粗さがあり、個別クローラー単位のビジネス判断を表現できないという課題もある。本記事では機能の仕組みと限界、サイト運営者が取るべき対応を検証する。

robots.txtとエッジ強制の矛盾が生んだ新機能

robots.txtとエッジ強制の矛盾が生んだ新機能

Webサイトのクローラーポリシーは2つの場所で管理される。1つはrobots.txtファイル、もう1つはWAFやCDNのエッジ側で動作するブロック設定だ。robots.txtはテキストファイルであり、クローラーへのリクエスト(お願い)を記述する。エッジ強制設定はダッシュボードで操作し、実際にHTTPリクエストを拒否する。

この2つは別々の場所で管理されるため、時間とともに矛盾が生じやすい。robots.txtは一度作成すると放置されがちで、エッジ設定は後から変更されることが多い。No Hacksの記事は、運営者自身のサイトでこの問題が発生していた例を報告している。robots.txtではBytespiderを許可する記述が数ヶ月間残っており、意図しないクローラーを歓迎する状態だったという。

CloudflareのBot Preference Syncは、この矛盾を自動的に解消する。ダッシュボードで設定したAIボットポリシーをrobots.txtに反映し、エッジ強制設定との乖離を防ぐ。Cloudflareがrobots.txtを書くという行為は、サイト運営者の代わりにポリシーを文書化することでもある。

Bot Preference Syncの仕組みと3つのカテゴリ設定

Bot Preference Syncの仕組みと3つのカテゴリ設定

Bot Preference Syncは、セキュリティ設定の「AIボットポリシー」で設定した内容をrobots.txtに変換する。設定項目はSearch(検索)、Agent(エージェント)、Training(トレーニング)の3カテゴリだ。各カテゴリには「全ページでブロック」「広告表示ページのみブロック」「許可」の選択肢がある。

生成されたrobots.txtには、Cloudflare Bot Preference Syncの開始マーカーと終了マーカーが付与される。既存のrobots.txtコンテンツはその下に保持される。つまりCloudflareが書き込むのはマーカーの間の部分だけで、サイト運営者が手動で書いた部分は残る仕組みだ。

STEP 1 CloudflareダッシュボードでAIボットポリシーを設定する
Search、Agent、Trainingの3カテゴリから選択する
↓
STEP 2 Cloudflareがrobots.txtの該当部分を自動生成する
既存のコンテンツはマーカーの下に保持される
↓
STEP 3 robots.txtとエッジ強制設定が同期される
矛盾した設定が解消される

Bot Preference Syncは設定をrobots.txtへ反映する一連の流れを自動化する。

Cloudflareの発表によると、この機能は無料プランから利用可能で、新規顧客にはデフォルトでオンになる。ただし2026年9月13日時点では、Bot Preference Syncの公式Changelogへの記載がなく、Cloudflareのボットドキュメントにも言及がない。また一部のサイトではrobots.txtに生成ブロックがまだ現れていない。本記事は発表内容に基づく検証となる。

カテゴリ単位の設定では表現できない個別ポリシー

カテゴリ単位の設定では表現できない個別ポリシー

Bot Preference Syncの3カテゴリ設定は、サイト運営者のビジネス判断を必ずしも表現できない。No Hacksの記事の運営者は、OpenAIのGPTBot、Anthropicのクローラー、PerplexityBotを許可し、Bytespiderとmeta-externalagentをブロックしている。この判断は企業ごとの見返りに基づく。前者は自社ページをアシスタントの回答に表示してくれるが、後者は何も返さない、という理由だ。

このポリシーを3カテゴリ設定で表現しようとすると、矛盾が生じる。Trainingをブロックに設定すれば、許可したいGPTBotまでブロックされる。Trainingを許可に設定すれば、ブロックしたいBytespiderまで許可される。個別クローラー単位のビジネス上の決定は、カテゴリ単位の設定では表現できない。

カテゴリ単位の設定では個別ポリシーを表現できない
TrainingをDisallowにした場合
許可したい GPTBot → ブロックされる
許可したい Anthropic → ブロックされる
ブロックしたい Bytespider → ブロックされる
ブロックしたい meta-externalagent → ブロックされる
↓
TrainingをAllowにした場合
許可したい GPTBot → 許可される
許可したい Anthropic → 許可される
ブロックしたい Bytespider → 許可される
ブロックしたい meta-externalagent → 許可される
■ 許可したいクローラー ■ ブロックしたいクローラー

個別クローラー単位のポリシーは3カテゴリ設定では表現できない。許可したいクローラーの扱いが、設定次第で逆転してしまう。

Cloudflareは、より細かい制御が必要な場合の対応策として、同期機能をオフにして手動でrobots.txtを管理することを挙げている。これはBot Preference Syncが万人向けではなく、カテゴリ単位の粗さを受け入れられるサイトに向けた機能だということを示している。

独自の見解として、日本のサイト運営者にもこの課題は当てはまる。コンテンツをAIトレーニングに提供する見返りを個別に評価している企業は、3カテゴリの設定では対応できない。Bot Preference Syncはあくまで「全許可」か「全拒否」に近いポリシーを持つサイト向けの省力化ツールと捉えるべきだ。

Cloudflareが公開した4つの開示条件とブロッキング

Cloudflareが公開した4つの開示条件とブロッキング

TrainingをDisallowに設定すると、robots.txtにno-training行が書き込まれる。同時に、Cloudflareが「不透明」と判断したAIクローラーがブロックされる。Cloudflareはこのブロックを回避するために、クローラーが満たすべき4つの条件を公開している。

Cloudflareが公開した4つの開示条件
条件1 robots.txtのno-training設定を尊重する
条件2 AIサマリーからオプトアウトする方法を提供する
条件3 トレーニング対象ページのURLレベルの可視性と検索結果の指標を提供する
条件4 トレーニング拒否が従来の検索結果に影響しないことを公に示す

4つの条件を満たさないクローラーは不透明とみなされ、TrainingをDisallowに設定したサイトではブロック対象となる。

条件2と条件4はGoogleを記述している。条件4についてGoogleはすでに満たしている。Googleのクローラードキュメントは、Google-ExtendedがGeminiモデルのトレーニングを制御し、検索結果への掲載やランキングシグナルには影響しないと明記している。これは条件4が求める公開声明に該当する。

一方で条件2はGoogleが答えを持っていない。条件2はAIサマリーからオプトアウトする方法を求めている。GoogleのAI機能のドキュメントによると、AI概要から除外するにはnosnippet、data-nosnippet、max-snippet、noindexのいずれかを使うことになる。しかし、これらはすべて通常の検索表示にも影響する。AI概要だけから外れて通常の検索スニペットは残す、という設定は存在しない。

Microsoftは2023年9月に条件2への回答を示している。NOARCHIVEタグを付けたコンテンツはBing Chatの回答に含まれないが、検索結果には引き続き表示される。検索インデックスから除外せず、チャットの回答からだけ除外できる仕組みだ。Cloudflareは2026年7月の記事で、BingBotとGooglebotを混合用途クローラーとしてこの条件の対象に挙げている。

CloudflareがAI企業への開示要求を明文化した点は評価できる。ただし、その条件を書いたのも執行するのもCloudflareという単一ベンダーだ。条件を読まずにダッシュボードのトグルをクリックしたサイト運営者も多い。パブリッシャーがAI企業に求めてきた説明責任は、いまやCloudflareにも向けられている。

新規顧客にデフォルト適用される意味とリスク

新規顧客にデフォルト適用される意味とリスク

2026年9月15日から、Cloudflareは新規ドメインのデフォルト設定を変更する。広告を表示するページではTrainingとAgentがブロックされ、Searchは許可される。オンボーディング時に「広告付きページで収益化している」を選択すると、TrainingがDisallowに自動設定される。

これはビジネスモデルに関する質問であり、その回答がrobots.txt上のAIトレーニングに関する公開ポジションになる。広告収益に依存するサイトは、AIトレーニングを拒否する立場を自動的に表明することになる。サイト運営者がこの設定を認識していなければ、意図しないポジションが公開され続ける。

リスクが大きいのは、robots.txtを二度と開かず、自分の代わりに書かれたポジションを読まないサイトだ。Cloudflareはすでにアナリティクススクリプトを無料プランのサイトにデフォルトで書き込んでいる。同じオンデフォルトのパターンがrobots.txtにも及ぶ。サイト運営者が設定を確認しなければ、AIトレーニングに関する自社の立場を外部ベンダーに委ねることになる。

SEO担当者の観点では、このデフォルト変更を黙認してはいけない。自社サイトがAIトレーニングを拒否しているのか許可しているのかは、AI時代の検索戦略を左右する。デフォルト設定のまま放置するのではなく、自社のビジネスモデルに合わせて意図的に選択することが重要だ。

robots.txtが守れる範囲と守れない範囲

robots.txtが守れる範囲と守れない範囲

robots.txtのルールは、停止することを選ぶクローラーを停止させるだけだ。ルールを無視するクローラーには何も影響しない。No Hacksの記事は、同サイトのログで最大のAIクローラーが認証情報を探していたと報告している。非営利研究アーカイブの名前を使い、/.envやSSHキーを要求するクローラーがいたという。テキストファイルのルールはそのようなクローラーを不便にさせることすらできない。

それでもBot Preference Syncは有用だ。インターネットの誠実な側、つまりルールを守るクローラーに対しては機能する。エッジでの強制が実際の防御であり、robots.txtは意図の文書化として、後から紛争になった時に意味を持つ。リクエストが到着した瞬間の防御にはならないが、自社のポリシーを明確に残しておく価値はある。

最終的には、robots.txtとCloudflareのAIボットポリシーを突き合わせて確認する作業が欠かせない。Bot Preference Syncが自サイトに到達したら、書かれた内容を必ず確認すること。読んでいないポリシーファイルは、他人が自分の代わりに表明した立場になる。

この記事のポイント

  • CloudflareのBot Preference Syncはrobots.txtとエッジ強制設定の矛盾を解消する自動化機能である
  • Search、Agent、Trainingの3カテゴリ設定では個別クローラー単位のビジネス判断を表現できない
  • Cloudflareは4つの開示条件を公開し、不透明なクローラーをブロック対象にした
  • 新規顧客にはデフォルトでオンになり、広告収益化サイトではTrainingがブロックされる
  • robots.txtは誠実なクローラーにしか効かないため、エッジ強制が依然として重要である
GoogleのAIコンテンツ支払い、CloudflareとMicrosoftが示す3つの設計思想

GoogleのAIコンテンツ支払い、CloudflareとMicrosoftが示す3つの設計思想

Google、Cloudflare、Microsoftの3社がAIによるコンテンツ利用への対価支払いモデルをそれぞれ試験している。支払いの発生条件、価格設定の主導権、運営者に返るレポートの中身は3社で大きく異なる。

Googleは「重要な貢献」と判定した場合のみ支払う招待制パイロットだ。Cloudflareはクロール1回ごとに課金する独自モデルを持つ。Microsoftはライセンス型マーケットプレイスを2月に発表した。

この違いが、サイト運営者がAIにコンテンツを提供する際の収益性とリスクを左右する。本記事では3モデルの設計思想とSEOへの影響を整理する。

3社のAIコンテンツ支払いモデルの全容

3社のAIコンテンツ支払いモデルの全容

Google、Cloudflare、Microsoftは2026年に入り、AIがウェブサイトのコンテンツを利用する際の対価支払いモデルをそれぞれ提示した。3社のアプローチは課金の単位、価格設定の主導権、レポートの粒度で根本から異なる。

Google AI貢献パイロット
招待制のみ参加可能。「重要な貢献」とGoogleが判定した場合に支払い。Search Consoleで月次収益を確認できるが、計算式は非公開。
Cloudflare Pay Per Crawl / Pay Per Use
クロール1回ごとの成功取得に課金。価格はサイト運営者が設定(最低0.001ドル)。残高はダッシュボードに表示されない。
Microsoft Publisher Content Marketplace
プレミアムコンテンツのライセンス提供型。利用条件はパブリッシャーが定義するが、価格決定者は公開情報では不明。
■ Google(青) ■ Cloudflare(橙) ■ Microsoft(紫)

3社のモデルは支払い方式とコントロール権限のバランスで大きく異なる。

Googleは「貢献度」判定、Cloudflareは「取得単位」課金

Googleのパイロットプログラムは、Gemini、AI Overviews、AI Modeのいずれかで、サイトのコンテンツがAI生成応答に「重要な貢献をした」と判断された場合に支払いが発生する。回答生成後のリンク表示や確認だけでは条件を満たさない。Googleは6月18日の公式投稿で、AI回答の根拠となる情報を提供するウェブサイト向けの新モデルを試験する方針を示した。

一方、CloudflareのPay Per Crawlは2025年から非公開ベータとして提供されてきた。クローラーがコンテンツを正常に取得するたびに課金が発生する仕組みで、サイト運営者はクロール1回あたりの価格を設定できる。最低価格は0.001ドルだ。価格に同意したクローラーには正常応答コードでページが返る。

Microsoftはライセンス型マーケットプレイス

Microsoftは2月3日にPublisher Content Marketplaceを発表した。Copilotの回答を支えるためのプレミアムコンテンツのライセンスを提供する仕組みで、パブリッシャーは提供価値に基づいて支払いを受ける。利用条件とライセンス条件はパブリッシャーが定義し、利用ベースのレポートも提供される。Copilotが最初の需要パートナーとなり、Yahooも導入を進めている。

関連する動きとして、Ceramic.aiは自社の検索結果にサイトのコンテンツが表示された際に参加サイトへ支払うモデルを採用している。You.comは特定のプレミアムコンテンツをオンデマンドで利用した時点で支払う仕組みだ。

支払いトリガーを決めるのは誰か

支払いトリガーを決めるのは誰か

各モデルは支払い発生のイベント定義が異なる。ここが運営者の収益予測を難しくする根本原因だ。Googleは「重要な貢献」という質的基準、Cloudflareは「取得成功」という機械的基準、Microsoftは「提供価値」という経済的基準を採用している。

Google 判定型(ブラックボックス)
「重要な貢献」をGoogleが独自判定。基準は公開されない。
Gemini → AI Overviews → AI Mode での貢献を判定
↓
Cloudflare 機械判定型(事前確定)
正常応答を返した時点で課金イベントが発生。判定はコードベースで透明。
クローラー 価格承諾 → 取得成功 → 課金確定

判定者が誰かによって、収益予測の立てやすさが変わる。

Googleの「重要な貢献」はブラックボックス

Digidayの報道によれば、Googleのパイロットでは支払いがコンテンツの使用量ではなく価値に基づくとされている。Googleが自社で「意味のある貢献だったか」を判断する仕組みで、プログラムに詳しい企業幹部はDigidayの取材に対し「かなりブラックボックスだ」と述べている。Googleは判定基準を公表していない。

サイト運営者から見れば、この構造は収益の予測可能性を著しく下げる。何が支払いにつながるかの明確な基準が分からない状態で、コンテンツ戦略の投資判断を下すのは難しい。

Cloudflareは機械的なイベント、Microsoftは定義自体が不明

Pay Per Crawlのイベントは機械的だ。価格に同意したクローラーへの正常応答が課金の条件と明確に定義されている。ただしCloudflareの7月1日の投稿は、クロール回数が価値の粗い指標であると自認している。1回だけクロールされたページが何千もの回答に引用されることもあれば、何度もクロールされながら一度も使われないページもある。

Microsoftは支払い単位を公開していない。提供価値に基づくと説明するが、具体的な計算式や契約上の定義は明らかにされていない。価格設定もパブリッシャーとの共同設計の対象とされるが、誰が最終決定するかは公開情報では分からない。

サイト運営者がコントロールできる範囲

サイト運営者がコントロールできる範囲

3社のモデルはサイト運営者がどのような条件を設定できるかも異なる。価格を自分で決められるのか、参加の是非だけなのか、利用条件まで定義できるのか。この差は収益性と交渉力に直結する。

Googleは参加の是非のみ、条件交渉の余地なし

Googleのパイロットは招待制だ。参加者はSearch Consoleからいつでもオプトアウトできるが、参加するかどうか以外の条件交渉の余地は公開情報から見えてこない。Digidayによれば、ある企業幹部は提示された金額が低すぎてオプトインしなかったと述べ、Googleとの交渉は継続中だという。

この点は小規模なサイト運営者ほど不利になる。招待を受けるか、提示された条件で飲むか。その二択しか選べない状況では、交渉力のある大手メディアと中小サイトの間に収益格差が生まれやすい。

Cloudflareは価格を運営者が設定、Microsoftは利用条件を定義

Pay Per Crawlでは、サイト運営者がドメインごとの価格を設定できる。パス単位で価格を変える動的プライシングにも対応し、クローラーごとに課金、許可、ブロックを選べる。Pay Per Useでは、サイト運営者はパートナーのプログラムに参加する形で、パートナーによって支払い条件が変わる。

Microsoftのマーケットプレイスは加入が任意で、パブリッシャーはコンテンツの所有権と編集の独立性を保持する。ただし、ライセンス条件と利用条件の具体的な内容は公開されていない。価格決定者も不明のままだ。

レポートで見える情報と見えない情報

レポートで見える情報と見えない情報

収益化の判断には、どれだけの情報が返ってくるかが重要だ。3社のレポート粒度と透明性にも明確な差がある。

Googleの月次収益表示と計算式の非公開

Googleの参加者はSearch ConsoleのAI貢献パネルで月次収益額と履歴を確認できる。しかしDigidayは、支払い計算の詳細は提供されないと報じている。Googleは一部のパートナーと週次会議も行っている。パブリッシャー連合SpurのDavid Buttle氏は、第一歩として「パブリッシャーが自分のコンテンツが回答に影響したことを知る権利がある」という前例を作ることだと述べた。

月次収益という数字は見えるが、その数字がどう算出されたかは見えない。この非対称性は、運営者が支払い額の妥当性を検証できないことを意味する。

Cloudflareの残高非表示とCeramicの詳細レポート

Pay Per Crawlでは、課金イベント発生時に記録が残る。ダッシュボードにはどのクローラーがアクセスしたか、課金が何回発生したかが表示される。ただし獲得残高はダッシュボードに表示されず、Cloudflareチームへの問い合わせが必要だ。

Pay Per Useでは、Ceramicプログラムに参加するサイトが、コンテンツが表示された検索クエリ、該当ページ、スニペット、検索結果内の平均順位まで含むレポートを受け取れる。こちらの方が実務的には使える情報が多い設計だ。

Microsoftの利用ベースレポートは中身が非公開

Microsoftは「コンテンツがどのように評価され、どこでさらに価値を提供できるか」を確認できる利用ベースのレポートを約束している。ただし、レポートに含まれる具体的な項目は公開されていない。参加者がレポート内容について説明した記録も見つからない。

Googlebotへの従量課金が招くSEOリスク

Googlebotへの従量課金が招くSEOリスク

CloudflareのPay Per Crawlは、ディレクトリに登録されたあらゆるクローラーに従量課金を設定できる。Googlebotも対象だ。ここにSEO上の大きな落とし穴がある。

STEP 1 サイトがGooglebotに支払い要求コード(402)を返す
↓
STEP 2 402はエラー系コード(4xx)に分類される
↓
STEP 3 Googleは4xxを返すURLのコンテンツを使用しない
↓
STEP 4 インデックスから削除され検索順位が低下するリスク

CloudflareのBlock設定をGooglebotに適用すると、検索インデックスからの削除リスクが連鎖的に発生する。

Googleのクローラードキュメントによれば、4xxステータスコードを返すURLのコンテンツは使用されない。402 Payment Requiredも4xxに該当するため、Googlebotに課金を設定して402を返すと、時間の経過とともに検索インデックスから削除される可能性がある。

Cloudflareが9月15日に公開した新設定はこの状況を変えるものではない。Disallow AI Training設定はrobots.txtに学習拒否の意思を公開し、GoogleとAppleはこれを尊重しつつ検索クローリングは続ける。一方、BlockオプションはGooglebotを含むクローラーを完全に停止する。

つまり、Googlebotに対して「学習は拒否したいが検索クロールは許可したい」場合は、BlockではなくDisallow AI Trainingを選ぶ必要がある。Cloudflareの報告では、検索ボットをブロックしているサイトは1%未満、何らかの学習ブロックを使っているサイトは17%に上る。

また、Googleは数週間以内にGoogle-Extendedに関連するURL単位の透明性ツールを提供する予定だとCloudflareは伝えている。これはパイロットの貢献レポートとは別のものだ。

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

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

3社のモデルは完成形ではなく、すべて試験段階にある。運営者が今できるのは、自社のコンテンツの性質とリスク許容度に合わせて選択肢を評価することだ。

Cloudflare設定の見直しが最優先

すでにCloudflareを利用しているサイトは、現在の設定状態を確認すべきだ。従来の設定が移行されている可能性があり、Googlebotに対して意図しないBlockがかかっていないかを確認する必要がある。学習拒否と検索継続を両立するには、Training controlをDisallow AI Trainingに設定する。Blockにしてしまうと検索クロールも停止する。

この設定の分岐は、サイト運営者にとって「収益化のチャンス」と「検索順位のリスク」を同時に含む。学習を拒否するか、検索クロールを維持するか、あるいは課金対象としてGooglebotに支払いを求めるか。それぞれの選択肢の帰結を理解した上で決める必要がある。

契約前に確認すべき情報

Googleのパイロット招待を受けた場合、オプトイン前に「重要な貢献」の定義、計算方法、Search Consoleの生成AIコントロールとの関連性についてGoogleに確認するべきだ。Microsoftのマーケットプレイスを検討する場合は、誰が価格を決定するのか、レポートに何が含まれるのかを契約前に明確にする必要がある。公開情報だけではこれらの質問に答えられない。

3社のモデルは「支払いの透明性」に対するアプローチが根本から異なる。Googleは判定をブラックボックスにすることで柔軟性を確保し、Cloudflareは機械的なイベントで透明性を確保し、Microsoftはパブリッシャーに条件定義を委ねる。いずれもまだ実験段階であり、最終的な設計が現在の形のまま展開されるとは限らない。

特に重要なのは、Cloudflareが自ら「クロール回数は価値の粗い指標」と認めた点だ。同じコンテンツでも1回のクロールで何千回も引用される場合と、何度もクロールされながら全く利用されない場合がある。この非対称性は、現在のすべての支払いモデルが「価値の正確な測定」にまだ到達していないことを示している。

サイト運営者は、今後のレポート精度の向上と透明性ツールの展開を注視しつつ、自社のコンテンツがAI応答にどう使われているかを定期的に確認する姿勢が求められる。

この記事のポイント

  • Googleは招待制で「重要な貢献」と判定した場合のみ支払う。判定基準は非公開
  • Cloudflareはクロール取得単位の課金とパートナー主導の利用課金の2軸で展開
  • Microsoftはライセンス型で利用条件はパブリッシャーが定義するが価格決定者は不明
  • Googlebotを含むクローラーにBlock設定を適用するとSEOリスクが連鎖する
  • 3社とも試験段階で、価値測定の正確性が今後の焦点となる
Cloudflare新設定が公開。Disallow AI TrainingでGooglebotを残してAI学習だけを拒否

Cloudflare新設定が公開。Disallow AI TrainingでGooglebotを残してAI学習だけを拒否

Cloudflareが9月15日から新しいクローラー制御設定「Disallow AI Training」の提供を開始した。AI学習に使われるクローラーを拒否しつつ、Googlebotなどの検索クロールは維持できる設定だ。

従来はAI学習をブロックするとGooglebot、Applebot、Bingbotまで停止する仕様だった。新設定ではこの3つのクローラーが検索目的のクロールを継続できる。

検索流入を維持しながら生成AIへの無断利用を防ぎたいサイト運営者にとって、判断軸が明確になる変更だ。SEOを担当する立場からは設定の仕組みと影響範囲を把握しておく必要がある。

9月15日に何が変わったのか

9月15日に何が変わったのか

Cloudflareはクローラー制御を3つの設定に再編した。検索クローラーを制御するSearch、AIエージェントを制御するAgent、AI学習を制御するTrainingだ。今回の目玉となるDisallow AI TrainingはTrainingに属する新設の選択肢である。

重要なのは、7月時点の告知からの方針転換だ。当初はAI学習を拒否するサイトはGooglebot、Applebot、Bingbotもブロックされると説明されていた。3つのクローラーが検索と学習の両方に使われるため、切り分けができないという理由だった。

転換のカギは「Accountable(説明責任)」という新しい認定だ。検索と学習を兼ねるクローラーのうち、学習拒否の仕組みを整えた事業者のクローラーだけが検索クロールを許される。この枠組みにより、検索と学習の分離が可能になった。

3つの設定項目の新しい役割

Disallow AI Trainingを選ぶと、Accountable認定を受けたクローラーは検索目的に限ってクロールを継続する。学習用のクロールは拒否される。一方、Blockを選ぶとGooglebot、Applebot、Bingbotを含むすべてのクローラーが完全に停止する。検索クロールも止まる点に注意が必要だ。

検索との両立を狙うならDisallow AI Training、完全遮断を望むならBlockという使い分けになる。誤ってBlockを選ぶと検索エンジンからの評価に影響するため、設定変更時は現状を確認してから操作したい。

既存ユーザーの設定は自動移行される

Cloudflareの公式ブログによると、既存ユーザーの多くは何も変更する必要がない。旧設定で「Block」または「Block on pages with ads」を選択していたサイトは、自動的にDisallow AI Trainingへ移行される。旧Block AI Botsトグルを使っていたサイトは、SearchがAllow、TrainingがDisallow AI Training、AgentがBlock on pages with adsに振り分けられる。

なお、旧機能のBlock AI BotsとManaged Robots.txtは廃止予定だ。混在利用型クローラーをサイトから完全に締め出したい場合は、新設のBlockを明示的に選ぶ必要がある。広告で収益化する新規ドメインには、Disallow AI TrainingがTrainingの初期設定として適用される。

7月時点の計画(Before)
AI学習をブロック
Googlebot、Applebot、Bingbotがすべてブロック対象
検索クロールまで止まってしまう
↓
9月15日からの新設定(After)
Disallow AI Training
Googlebot、Applebot、Bingbotは検索クロールを継続
AI学習クローラーだけを拒否する

このデモは旧計画と新設定の挙動の違いを示している。7月時点では検索クロールの継続が困難とされていたが、Accountable認定の導入により分離が実現した。

Accountableクローラーの4つの要件

Accountableクローラーの4つの要件

AccountableはCloudflareが2026年7月からクローラー運営事業者との協議を経て設けた認定だ。検索と学習を兼ねるクローラーが検索目的でクロールを継続するには、この認定を取得している必要がある。

4つの要件の具体的内容

認定には4つの要件がある。robots.txt経由でAI学習を拒否できる仕組み、AIサマリーからの除外手段、どのページが学習に使われたかの可視性と検索表示の指標開示、学習拒否が検索結果に影響しないことの保証だ。

Cloudflareの公式ブログによると、Apple、Google、Microsoftがこれらの要件を満たしている。提供済みの機能に加え、残りの項目についても期限付きのコミットメントを出しているという。Amazon、Anthropic、Meta、OpenAIもAccountableとしてリストに載っている。これらは検索クローラーと学習クローラーを別々に運用しているため、学習クローラーはDisallow AI Trainingで引き続きブロックされる。

Accountable認定の4つの要件
要件 1 robots.txt経由でAI学習を拒否できる仕組みを持つ
要件 2 AIサマリーからの除外手段を提供する
要件 3 学習に使われたページの可視性と検索表示の指標を開示する
要件 4 学習拒否が従来の検索結果に影響しないことを保証する
Apple、Google、Microsoftがこの4要件を満たしている

このチェックリストはクローラー運営事業者が開示した内容を基にしている。サイト運営者側で個別に審査する必要はなく、Cloudflareが認定状況を管理する。

Google・Apple・Bingで動作はどう違うのか

Google・Apple・Bingで動作はどう違うのか

Disallow AI Trainingは各プラットフォームごとに異なる仕組みで実装される。robots.txtのトークンにマッピングされる点は共通だが、Bingは対応が遅れている。

GoogleのGoogle-Extended

Googleではrobots.txtのDisallowルールでGoogle-Extendedを拒否する形式になる。Google-ExtendedはGeminiモデルの学習からコンテンツを除外するためのトークンだ。Googleのクローラードキュメントによると、Google-Extendedを拒否しても検索結果への掲載や順位には影響しない。

注意したいのは、AI OverviewsやAI Mode、Discoverの生成AI機能への表示はSearch Consoleで別途制御する点だ。Googleのヘルプページでは、この設定はAI学習には影響しないと明記されている。検索表示と学習拒否は完全に別ルートで管理される。

AppleとBingの対応状況

AppleではApplebot-ExtendedのDisallowルールで対応する。Appleのドキュメントによると、Applebot-Extendedはページをクロールせず、検索順位にも考慮されない。Siriや検索のAI回答からコンテンツを除外するにはnosnippetメタタグが必要だ。

Bingはまだrobots.txtのno-trainingプリファレンスに対応していない。Microsoft側の実装待ちで、Cloudflareの公式ブログでは2027年初頭のサポートを目標としている。現状の学習拒否手段はNOARCHIVEメタタグだ。Bingのドキュメントによると、NOARCHIVEを付けたコンテンツはMicrosoftの生成AIモデルの学習に使われず、ChatやCopilotにもリンクされない。

Disallow AI Trainingの実装方法の比較
Google(Google-Extended)
robots.txtのDisallowルールで対応。検索順位には影響しない。AI Overviewsへの表示はSearch Consoleで別途制御する
Apple(Applebot-Extended)
robots.txtのDisallowルールで対応。Siriや検索のAI回答から除外するにはnosnippetメタタグが必要
Bing(未対応)
robots.txtのno-trainingプリファレンスは未対応。現状はNOARCHIVEメタタグで拒否する。サポートは2027年初頭予定
■ Google対応済み ■ Apple対応済み ■ Bing対応待ち

3つのプラットフォームで対応状況が異なるため、アクセス解析で各検索エンジンからの流入比率を確認しておくとよい。Bingの比率が高いサイトでは、NOARCHIVEメタタグの併用も検討したい。

SEO担当者が意識すべき実務ポイント

SEO担当者が意識すべき実務ポイント

この変更はサイト運営者の判断を迫る場面を増やす。検索流入を守るのか、AI学習への露出を完全に断つのか。目的に応じて設定を使い分ける必要がある。

BlockとDisallow AI Trainingの使い分け

Blockを選ぶとGooglebot、Applebot、Bingbotの検索クロールまで停止する。検索からの流入が重要なサイトでは現実的ではない選択肢だ。Disallow AI Trainingを選べば、検索クロールを維持したまま学習だけを拒否できる。

サイト運営者は「AI学習への露出を許容できるか」を最初に決めるべきだ。許容できるならBlockでもDisallow AI Trainingでも大きな差はない。許容できないならDisallow AI Trainingを選び、BingのNOARCHIVEを併用する形が現実的だ。

AIサマリーへの影響は別設定

Disallow AI TrainingはAI OverviewsやAI Modeへの表示を制御しない。GoogleではSearch Consoleの設定が担当領域だ。AI学習を拒否しても、生成AIの回答に自社コンテンツが要約として表示される可能性は残る。

逆に、AI学習を許可していてもSearch Console側でAIサマリーへの表示を制御できる。学習拒否とサマリー表示は独立した2つの軸として考えると分かりやすい。両方の設定を確認して、自社の方針に合わせて調整したい。

Cloudflareの今後の目標は、AIサマリーに含まれるコンテンツ量を単一の設定で制御できる仕組みだ。現状は事業者ごとに個別調整が必要だが、2027年初頭には一元管理が可能になる見込みという。

今後のロードマップ

今後のロードマップ

Cloudflareの公式ブログによると、Googleは今後数週間でGoogle-ExtendedのURLレベルの透明性ツールを展開する予定だ。どのページが学習対象になったのかをサイト運営者が確認できるようになる。Appleも同様のツールを来年提供する予定である。

Microsoftのrobots.txt no-trainingプリファレンス対応は2027年初頭が目標だ。これが実装されれば、BingでもCloudflare経由で学習拒否を指示できるようになる。NOARCHIVEメタタグの代替として機能する見込みだ。

AIサマリーの制御についてもCloudflareは単一設定での一元管理を目指している。事業者ごとの調整を不要にし、Cloudflareの設定だけでコンテンツの露出量を制御できる仕組みだ。2027年初頭の提供が目標とされている。

この記事のポイント

  • Disallow AI TrainingはGooglebotなどの検索クロールを維持したままAI学習だけを拒否する新設定
  • Blockを選ぶと検索クロールも含めて完全に停止するため使い分けが重要
  • Accountable認定はApple、Google、Microsoftが取得済みで検索クロールの継続が保証される
  • Bingはrobots.txt対応が2027年初頭まで待つ必要があり、当面はNOARCHIVEメタタグで拒否する
  • AI Overviewsへの表示制御はSearch Consoleで別途行う。学習拒否とは独立した設定だ
ByTheWeb AIレビュー!無料GEOプラグインでAI検索に引用されるサイトを目指す

ByTheWeb AIレビュー!無料GEOプラグインでAI検索に引用されるサイトを目指す

ChatGPTやGeminiなどAI検索の利用が広がる中、従来型SEOだけでは不十分な局面が増えてきた。GEO(Generative Engine Optimization / 生成AI向け最適化)と呼ばれる、生成AIにサイトを理解させるための最適化が必要になっている。検索エンジン向けにメタディスクリプションやXMLサイトマップを整えても、AIが回答を組み立てる際に情報源として引用されるとは限らない。

WP Mayorの2026年9月2日付レビューをもとに、ByTheWebの料金体系、主要機能、実務での使い方、プライバシー面を整理した。

AI検索対策を低コストで始めたい中小企業や個人ブロガーが、この無料ツールをどこまで使えるかを判断するための内容だ。

ByTheWeb AIの全体像

ByTheWeb AIの全体像

ByTheWebは2つのWordPressプラグインに分かれている。無料のByTheWeb GEOがAI可読性スコアの算出、スキーマ生成、llms.txt出力、robots.txt管理という土台部分を担う。ここでllms.txtは、大規模言語モデル向けにサイト情報を整理したテキストファイルだ。任意のByTheWeb AIはクレジット制のアシスタントとして、不足するフィールドの自動補完やメタ情報の生成をクラウド処理で行う。

ByTheWebの2つのプラグイン構成
土台 WordPressサイト
記事、固定ページ、商品ページなどが格納される
↓
無料・必須ではない ByTheWeb GEO
AI可読性スコア、各種スキーマ、llms.txt、robots.txt、メタ情報の手動管理を担当
↓
任意・クレジット制 ByTheWeb AI
不足フィールドの自動生成、メタ情報最適化、FAQスキーマ生成をクラウド処理で実行
スコア改善 → llms.txt出力 → AI検索での引用されやすさ向上
■ WordPressサイト ■ GEO(無料) ■ AI(クレジット制)

重要なのは、どちらのプラグインも必須ではない点だ。ByTheWeb GEOはアカウントなしで手動機能をすべて使える。ByTheWeb AIは無料のAPIキーを接続して初めて生成機能が動く。この分離設計により、クレジット消費を伴うAI機能だけを後から追加できる。

料金とクレジットの仕組み

料金とクレジットの仕組み

ByTheWeb GEOの基本機能は無料だ。ダッシュボード、スキーマ、llms.txt、サイトマップ、robots.txt、手動フィールドはアカウント登録なしで利用できる。費用が発生するのはByTheWeb AIを接続した場合に限られる。新規アカウントには30日間有効の5,000クレジットが付与される。

試用期間後の有料プランは4段階ある。いずれも1プランで対応するドメインは1つで、未使用クレジットは翌月に繰り越されない。

  • Starter AIは月額10.95米ドルで5,000クレジットを利用できる
  • Creator AIは月額19.95米ドルで10,000クレジットを利用できる
  • Growth AIは月額29.95米ドルで20,000クレジットを利用できる
  • Pro AIは月額39.95米ドルで30,000クレジットを利用できる

クレジットの消費量はAIアクションごとに異なる。1回の操作で50クレジットで済む場合もあれば、450クレジットを消費する場合もある。利用頻度が高い場合は、月に何回のAIアクションを実行するかを事前に見積もるとよい。

プラグインとは別に、ByTheWebは無料のAI可視性およびSEOサイトスキャナーも提供している。URLを入力すると、OpenAI、Google Gemini、Perplexity、Claudeがそのビジネスをどう理解しているかを、実際のWeb検索結果と引用元付きで確認できる。接続と検証を済ませるとレポート全体が閲覧可能になり、見つかった課題をWordPressツールで修正できる。

主要機能の解説

主要機能の解説

AI向けフィールドとllms.txt

ByTheWeb GEOの中心となるのが、Short AnswerとAI Summaryという2つのAI向けフィールドだ。Short Answerは質問への直接的な一文回答であり、AI Summaryは重要事実を箇条書きにしたスキャンしやすい要約である。どちらもサイトが自動生成するllms.txtファイルに反映される。必要に応じてllms-full.txtとしてMarkdown形式の完全版も出力できる。

FAQビルダーは手動で書いた質問をJSON-LD形式のFAQスキーマへ変換する。ここでスキーマとは、ページ内容を検索エンジンやAIが機械的に理解できるよう構造化するマークアップの一種だ。JSON-LDはその構造化データを記述するフォーマットである。ショートコードまたはElementorウィジェットで訪問者にも表示できる。

そのほか、Article、Organization、Person、Local Business、Service、BreadcrumbListの各スキーマと、sameAsおよびContactPointフィールドが構造化データの側面を補う。sameAsは自社の公式プロフィールを紐付けるためのフィールドだ。

従来のSEO機能と既存プラグインとの共存

AI向け機能に加えて、ByTheWeb GEOは従来型のSEOレイヤーも備える。タイトルとメタディスクリプションの文字数インジケーター、最適化チェック、スマート変数を使った動的テンプレートの作成が可能だ。WP Mayorのレビューでは、主要なSEOプラグインにある基本機能はおおむねこちらでも揃っていると指摘されている。

ByTheWeb GEOはYoast SEOやRank Mathと併用できる。機能が重複するフィールドは重複を避けて調整される一方で、GEOスコアとスキーマ機能はそのまま有効になる。既存のSEOワークフローにByTheWebを追加しやすい設計だ。

実務での使い方とGEOスコア改善

実務での使い方とGEOスコア改善

初期設定とスキャン

ByTheWeb GEOをインストールして有効化すると、WordPress管理画面に専用メニューが追加され、バックグラウンドで初回サイトスキャンが実行される。最初にGEO設定とSEO設定の画面で、ビジネス名や所在地などの基本情報を登録するとよい。両方のプラグインを有効にした場合、Needs Attention(要対応)テーブルからページごとのGEOスコアを確認できる。スコアが低いページが上に並ぶため、改善対象を見つけやすい。

スコア改善の流れとAIアシスト

Short Answer、AI Summary、FAQを手動で追加すると、そのページのGEOスコアは上がる。これらの情報はページソースのメタタグやFAQスキーマとして出力され、llms.txtにも反映される。ByTheWeb AIを接続している場合は、不足フィールドの横にあるボタンを押すだけで自動生成できる。生成前にはページ内容、任意のトピック指定、クレジット消費量が表示される。

生成結果の編集が必要かどうかは、元のページにどれだけ情報があるかに左右される。このツールはゼロからリサーチするのではなく、ページ上の情報を素材にするためだ。既存コンテンツが充実していれば、そのまま使える精度の出力が得られやすい。

AI検索で引用されるまでの変化
従来のSEO対策のみ(Before)
タイトル最適化 メタディスクリプション XMLサイトマップ
AIはこれらの情報を直接の回答根拠として優先しない
↓
GEO対策を追加(After)
AI Summary Short Answer FAQスキーマ llms.txt
AIが回答を組み立てる際の引用元として認識されやすくなる
■ 従来型SEO要素 ■ AI向けフィールド ■ スキーマ ■ テキスト出力

このデモは、AI検索に引用される状態への変化を概念として示したものだ。実際の改善はプラグインが算出するスコアに沿って進める。スコアが上がると、ChatGPTやGeminiが回答の根拠としてサイトを使う可能性が高まる仕組みだ。

プライバシー、サポート、総合評価

プライバシー、サポート、総合評価

クラウド処理とプライバシー

ByTheWeb AIでコンテンツ生成を実行すると、該当ページの内容とドメイン情報がByTheWebのクラウドサービスを経由する。WP Mayorのレビューでは、厳格なデータ処理要件を持つサイトはプライバシーポリシーを確認し、必要に応じて運営チームへ問い合わせるべきだと触れられている。手動機能だけを使う場合はクラウド処理が発生しない。

サポート体制

サポートはWebサイト上のチケットシステムで受け付ける。WordPressプラグインのダッシュボードから簡単にアクセスできる。ナレッジベースには基本機能と一部の応用ケースがまとめられており、多くは短い動画ガイド付きだ。WP Mayorのレビューでは、動画だけでなくテキストによる詳しい説明が増えるとさらに良いという指摘もある。

導入に向くサイトタイプ

WP Mayorのレビューでは、ブロガー、複数サイトを監査するエージェンシー、構造化データを追加したいローカルビジネスにとって最も価値があると評価されている。一方、同レビューは成熟したSEOスタックを導入済みの場合やAI引用の保証を求める場合、複数ある判断材料の1つとして扱うのが現実的だとしている。確立されたリーダーというより、形成途中のカテゴリに登場した有望な初期段階の製品という位置づけだ。

この記事のポイント

  • ByTheWeb GEOは無料でAI可読性スコア、llms.txt、スキーマ、従来SEOを管理する
  • ByTheWeb AIは任意のクレジット制アシスタントで、不足フィールドを自動生成する
  • 新規アカウントには30日間有効の5,000クレジットが付与される
  • Yoast SEOやRank Mathと併用でき、GEOスコアとスキーマは有効なまま残る
  • AI生成を実行するとページ内容がクラウドを経由するため、プライバシー確認が必要だ
Googleサーチコンソールの生成AIレポートが全世界展開。見方とオプトアウトの注意点

Googleサーチコンソールの生成AIレポートが全世界展開。見方とオプトアウトの注意点

Googleサーチコンソールの生成AIレポートが、2026年8月31日付で全世界のサイトに展開された。AI OverviewsやAI Modeなど生成AI機能での表示回数を、ページ別・国別・日付別に確認できる。

一方で、クリックデータはまだ提供されていない。表示はされても実際のサイト訪問につながったかは分からない。この記事ではレポートの見方、オプトアウト設定の仕組み、SEO担当者が取るべき対応を整理する。

生成AIレポートの全体像

生成AIレポートの全体像

2026年6月から段階的に展開が始まった生成AIレポートは、8月31日付の公式注記で全世界のサイトに行き渡った。Search Consoleにログインすると、検索レポートとDiscoverレポートのそれぞれで生成AI関連のデータを確認できる。

レポートが対象とするのは、AI Overviews、AI Mode、Discoverの生成AI機能だ。AI Overviewsは検索結果の上部に生成AIが回答の要約を表示する機能を指す。AI Modeは対話形式で検索を続けられる専用モードだ。DiscoverはGoogleアプリのフィードで、ここにも生成AIによるコンテンツ表示が含まれる。

従来の検索フロー(Before)
ユーザー キーワード検索 → 検索結果ページ サイトをクリック → サイト訪問
※クリックが発生し、実際のトラフィックにつながる
↓
生成AI検索のフロー(After)
ユーザー 自然言語で質問 → AI Overviews 等 回答を表示 → サイトはインプレッションのみ
※表示はされるが、クリックされるとは限らない

従来の検索ではクリックが発生してサイト訪問につながっていた。生成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つの表示面
AI Overviews 検索結果の上部に表示される生成AIの回答要約
AI Mode 対話形式で検索を続けられる生成AI専用モード
Discover 生成AI Discoverフィード内に表示される生成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検索では、ユーザーが回答だけで満足してサイトを訪れないケースが増えると指摘されている。

レポートで見えるデータ
■ ページ別の表示回数
■ 国別の表示回数
■ 日付別の表示回数
■ デバイス別の内訳(検索レポートのみ)
↓
レポートで見えないデータ
■ クリック数とクリック率
■ 表示からサイト訪問につながった割合
■ 生成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月までにページ単位のコントロールを要求しており、今後の仕様変更に注意が必要
AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

SEOで上位を獲得しているブランドの一部が、AIチャットの回答にはほとんど登場しない。検索エンジン向けの最適化だけでは、生成AI時代のブランド視認性を確保できないことが明らかになってきた。

Fractlの調査では、GPT-4o、Gemini 2.5 Flash、Claude Sonnet 4.6の3つのモデルに96種の業界別プロンプトを投げ、4,320件の回答と8,500件超のブランド言及を分析した。SEO指標とAI回答での言及頻度を突き合わせ、その乖離を数値化している。

この記事では、AI検索から消えつつあるブランドの特徴、逆にAIで過剰に登場するブランドの共通点、そしてブランド戦略に必要な対応を解説する。

AI回答に潜む「デフォルトブランド」の存在

調査対象の全業界に共通して、プロンプトの言い回しを変えても繰り返し登場する「デフォルトブランド」が存在した。ただし、その顔ぶれは検索エンジンの上位表示とは必ずしも一致しない。ドメイン評価が高く、大量のキーワードで上位表示されているブランドが、AI回答では自社カテゴリにすら登場しないケースが目立つ。

逆に、従来のSEO指標では目立たないブランドが、AI回答では頻繁に推奨される事例も多かった。注目すべきは、デフォルトブランドの顔ぶれが業界ごとに大きく異なる点だ。

旅行カテゴリではBooking.com(285回)、Airbnb(227回)、Expedia(215回)の3ブランドが、カテゴリ全体の言及量の約20%を占めた。3社で推奨の5分の1を握る集中度だ。保険カテゴリではLemonade(213回)がState Farm(172回)を上回り、Root Insurance(165回)がProgressive(114回)を超えた。デジタルネイティブの保険会社が先に挙げられ、従来の大手は代替案として扱われている。

ライフスタイルカテゴリでは、Patagonia、Allbirds、Eileen Fisher、Everlaneといったサステナビリティ系D2Cブランドが、SephoraやSamsung、Whirlpoolを上回った。Fractlの記事では、この傾向は第三者コンテンツで語られるブランドストーリーがAIの訓練データに強く反映された結果だと指摘している。

従来のSEO検索(Before)
大手保険ブランド Google検索1位
ドメイン評価 80以上、月間訪問数 数百万
キーワード 数十万件で上位表示
↓
AIチャット回答(After)
デジタル保険ブランド AI回答で先に登場
大手保険ブランドは言及なし、または代替案としてのみ
■ 従来のSEO上位 ■ AI回答で優先 ■ 言及なし

このデモが示す通り、検索エンジンでの強さとAI回答でのプレゼンスは一致しない。AI回答内の競争集合は、検索結果ページよりはるかに小さい。自社カテゴリでAIが想起する上位5〜10ブランドに入れなければ、Googleで上位表示できていても、AIが生成する検討リストには載らない。

伝統的なSEO権威性とAIリコールの乖離

伝統的なSEO権威性とAIリコールの乖離

Fractlの分析によれば、データセット全体の9割超のブランドでは、従来の検索権威性とAI視認性がほぼ連動していた。つまり、SEOの基本原則が無効になったわけではない。ただし、データの端に位置するブランド群にこそ戦略の変化が見える。

全体の約5%、471ブランドが「AI過少露出」だった。ドメイン評価が高く、オーガニック流入も多く、大量のキーワードで上位表示しているにもかかわらず、AIモデルからはほとんど参照されなかった。SEO指標上は市場リーダーに見えるのに、LLMからの言及では「誰も書いたことがない企業」のように映る。

一方、全体の約4%、377ブランドが「AIオーバーパフォーマー」だった。控えめなSEO指標に比べて、AIモデルからの参照が大幅に多かった。さらに9%は、第三者コンテンツでの言及頻度とAI視認性が一致した。

ここから見える最大の示唆は、自社が発信するコンテンツよりも、外部サイトが繰り返し語ってきた内容の方がAIの回答に強く影響するという点だ。まとめ記事、専門家リスト、比較レビューに登場する頻度が高いブランドほど、AIモデルの訓練データに取り込まれやすい。

カテゴリ誤分類で消える大手ブランド

カテゴリ誤分類で消える大手ブランド

AI過少露出のブランドには、従来の指標ではカテゴリの勝者とみなされてきた大手が並ぶ。ドメイン評価80以上、月間訪問数数百万、数十万のキーワードで上位表示しているブランドが、自社カテゴリのプロンプトで一切言及されない。

この問題の根底にあるのが、カテゴリ分類のズレだ。MicrosoftとSpotifyはFinTechのプロンプトで言及されなかった。両社とも伝統的な視認性は巨大だが、AIモデルはFinTechカテゴリに分類していない。Microsoftは生産性ソフトやクラウドの文脈では頻繁に引用される。FinTechの回答セットには含まれないだけだ。

同様の構図は保険、小売、ヘルスケアでも見られた。Aetna、Cigna、Humana、Liberty Mutualはドメイン評価80以上でも、AI回答ではLemonadeやRootに置き換えられた。Sephora、Samsung、Whirlpoolも、ライフスタイルのプロンプトではPatagoniaやAllbirdsに劣位した。

言及されない理由は、AIがブランドを知らないからではない。検索者が使うカテゴリと異なる引き出しに、そのブランドがしまわれているからだ。コンテンツ量を増やすだけでは解決しない。AIモデルがブランドを正しいカテゴリに結び付けるための外部シグナルが必要になる。

ブランド分類のズレが示すもの
Microsoft 検索側の見立て → 生産性ソフト
Microsoft FinTechプロンプトでは → 言及なし
Spotify FinTechプロンプトで → 言及なし
■ ブランド ■ AIが認識するカテゴリ ■ カテゴリ不一致

AIモデルがブランドをどのカテゴリに分類しているかを把握し、ズレがあれば修正する方が先だ。カテゴリの結び付きを強化するには、アナリスト記事、業界メディア、比較ページ、パートナーページ、カスタマーストーリー、レビューサイトでの露出が有効になる。

AIで際立つオーバーパフォーマーの戦略

AIオーバーパフォーマー377ブランドの動きは、マーケターにとって他山の石になる。小さいSEOプロフィールでも、AIの回答に繰り返し登場するブランドは、共通してAIモデルの訓練データに使われた第三者コンテンツに複数回登場している。

データセット最大のオーバーパフォーマーはMonday.comだ。AI視認性スコアは0.71を記録した。オーガニック訪問数は約100万、上位キーワードは5万以上。すでに大きなSEO基盤を持ちながら、SaaSプレイヤーの平均を大きく上回る頻度でAIに参照されている。

保険カテゴリではRoot Insuranceが突出した。大手保険会社の規模に遠く及ばないにもかかわらず、AI参照数ではすべての従来型保険会社を上回った。オーバーパフォーマーの上位15ブランドのうち6つは教育分野で、Stanford、MIT、Khan Academy、LinkedIn Learning、IBM Data Science、Google Career Certificatesが並ぶ。AIモデルは商用的なプラットフォームではなく、信頼性の高さで教育ブランドを参照している。

共通項は「良いSEO」ではなく、他者のコンテンツにカテゴリレベルで登場していることだ。製品まとめ記事、エキスパートリスト、比較記事に取り上げられる頻度が、AI視認性を押し上げる。AI視認性の向上は、デジタルPRやカテゴリ権威性の構築に近づいている。

モデル間で異なるAI視認性の実態

モデル間で異なるAI視認性の実態

調査対象のうち、3モデルすべてに参照されたブランドは11%、900ブランドにとどまった。2モデルに登場したのは12%。残りの77%は、1つのモデルにしか登場しなかった。これはAI視認性の測定に深刻な課題を突き付ける。

ChatGPTで勝てるブランドがGeminiでは消える。Claudeで登場してもChatGPTからは出てこない。1つのモデルの回答を制しても、別のモデルではほとんど登録されない。AI視認性の「総合スコア」だけで改善を判断すると、実態を見誤る原因になる。

3モデルすべてに参照されたブランド(11%)
900ブランドが該当
2モデルに参照されたブランド(12%)
データセットの約12%が該当
1モデルだけに参照されたブランド(77%)
大多数がここに集中
■ 全モデルで一致 ■ 2モデルで一致 ■ 1モデルのみ

モデルごとの「指紋」も異なる。ClaudeはSaaSと保険に偏り、Notion、Linear、Lemonadeが他モデルより頻繁に登場した。Geminiは旅行とヘルスケアに偏り、Booking.com、Teladoc、Livongoの言及が多かった。ChatGPTは3モデルの中で最も合意型で、他モデルとの重複が最も多い。

NotionはClaudeからの引用がGeminiの17倍に達し、Whoopは約4倍だった。State FarmはChatGPTに言及のほぼ半分を依存し、Geminiからは約4分の1しか得られなかった。総合スコアが同じでも、どこで差が出ているかを確認しないと対策は打てない。

ブランド戦略に必要な5つの視点

Fractlの記事は、この調査から導ける5つの教訓を提示している。実行しやすい順に並べると、次の通りだ。

1. 検索権威性とAIリコールを分けて測る

ドメイン評価、オーガニック流入、キーワード順位は引き続き重要だ。ただし、それだけでは全体像を捉えられない。Googleでの順位とAI回答での登場を別々に追跡し、乖離を探す。そのズレにこそ戦略のヒントがある。

2. 第三者による検証を増やす

自社サイトのコンテンツだけではAI回答への登場を保証できない。まとめ記事、ベストリスト、比較記事、専門家レビュー、アナリストページ、ポッドキャスト、YouTubeの文字起こし、コミュニティの議論など、外部コンテンツでの言及を積み重ねることが、AI視認性の実用的なレバーになる。

3. モデルごとに個別測定する

3モデルすべてに参照されたブランドは11%に過ぎない。「AI視認性」を1つの指標として扱うのは誤解を招く。ChatGPT、Gemini、Claudeを分けて計測し、プロンプトをカテゴリ別、購買意図別、比較セット別に分解する。どのモデルで、どの文脈で、どの競合と共に登場するかを追跡する。

4. カテゴリ分類の修正を優先する

ブランド全体の認知度が高くても、狙うカテゴリでのリコールが弱いなら、問題は分類にある可能性が高い。AIモデルはブランドを知っているが、重要なクエリの回答セットに含めるべき存在だとは考えていない。メディア報道、比較コンテンツ、パートナー参照、カスタマーストーリー、受賞歴、レビュー、第三者ページなどを通じて、ブランドとカテゴリの結び付きを繰り返し強化する必要がある。

5. デフォルト回答の枠が固まる前に動く

ウェルネス、ライフスタイル、ヘルステックの一部では、デフォルト回答の座がまだ空白だ。一方、旅行、主要SaaS、FinTechの一部では、AIが返す顔ぶれがすでに固定化しつつある。カテゴリとの結び付きを早期に築いたブランドほど、AIの回答に残りやすい。後発が割り込む余地は徐々に狭まる。

この記事のポイント

  • SEO上位でもAI回答に登場しないブランドが全体の約5%存在する
  • AI回答での競争集合は検索結果ページよりはるかに小さい
  • 第三者コンテンツでの言及頻度がAI視認性を左右する
  • 3モデルすべてに参照されるブランドは11%に過ぎない
  • カテゴリ誤分類の修正がAI視認性改善の近道になる
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広告の最適化には、精密なコンテキストヒント設計と、広告表示ログの透明性が必要