2026年10月8日に、GoogleのAI機能ガイド、Search Consoleの生成AIレポート、Googleの構造化データ方針、OpenAIのクローラ説明を再読しました。準備を、対象の問いとページ、本文の正確さと条件、クロール・indexの確認、可視本文と構造化データの一致、製品別の観測へ分けます。特別なschemaやAI専用ファイル、bot許可だけで掲載・引用・成果が決まるとは扱いません。
LLMOの準備を始めようとして、構造化データ、FAQ、記事更新などの候補が並び、何から直すか迷うことがあります。最初に決めたいのは施策名ではなく、どの利用者の問いに、どのページで答え、何を確かめて次へ進むかです。
LLMOは、AIが情報を探して回答する場面で、自社の情報が適切に扱われるよう整える取り組みを指して使われます。ただし製品共通の合格基準や引用保証はありません。この記事では、対象ページ、取得条件、内容、根拠、測定という五つの準備に分けて、限られた時間の使い道を決めます。
30秒で要点
- まず対象となる問いとページを選ぶ。FAQのマークアップ追加を、全サイト共通の最優先にはしない。
- 取得・掲載の資格、実際の表示や引用、サイトへの流入、その後の成果を分ける。
- Google検索とOpenAIのクローラーは、公開された役割・制御をそれぞれ確認する。許可は掲載保証ではない。
- 変更前の状態、担当、見直し条件を残す。実装期間や成果が出る月数を一律に決めない。
まず五つの準備を見渡す
SEOは検索で見つけてもらい、利用者に役立つ内容と技術条件を整える取り組みです。Googleの現行の生成AI検索向けガイドは、通常のSEOの基本が引き続き関係すると説明しています。AI向けの別サイトを増やす前に、共通の問題から確認します。
表が収まらない場合は、横にスクロールできます
| 準備 | 残すもの | 次へ進めるかを判断する問い |
|---|---|---|
| 1. 対象を決める | 利用者の問いと対象ページ | 誰の何の判断に必要な情報か |
| 2. 取得・包含条件を確認する | 製品別の設定と確認結果 | 読ませたい範囲と公開の方針が合っているか |
| 3. 内容と構造を整える | 本文・見出し・必要なマークアップ | 条件や答えが本文から理解できるか |
| 4. 根拠と更新を管理する | 出典・対象・著者・確認日 | 主張をどこまで確かめたか追えるか |
| 5. 測って見直す | 分母つきの観測と次の判断 | 何が変わり、何はまだ不明か |
以下の製品仕様は2026年10月4日に公式本文を確認した範囲です。画面や対応範囲が変わるため、実際に設定する時点でもリンク先を再確認します。用語の全体像が必要ならLLMOの基礎も参照できます。
準備1：対象の問いとページを絞る
「AIに引用されたい」だけでは、どの内容を改善するか決まりません。購入前の比較、使い方の確認、費用の理解など、利用者が判断したいことを一つ選びます。その答えになるページを決め、一覧ページから詳細へたどれるかを確認します。
たとえばサービスサイトなら、次の三つを候補にできます。これは優先順位を考える仮想例です。
表が収まらない場合は、横にスクロールできます
| 候補 | 読者の問い | 現状の問題と優先判断 |
|---|---|---|
| 料金ページ | 何が料金に含まれるか | 必須条件が欠けていれば先に補う |
| 比較ページ | どの条件なら合わないか | 違いと適用しない条件を明らかにする |
| 用語の解説 | その言葉は何を意味するか | 既に答えが十分なら、緊急性の高いページを先にする |
サイト内の全ページへ同じFAQを加えるより、読者の判断に欠けている情報を見つけます。対象ページごとに「問い」「現状」「変える箇所」「確認担当」を一行で書ければ、作業の目的が具体的になります。
準備2：製品別に、取得と包含の条件を確認する
ページを公開していること、クローラーが取得できること、検索に登録されること、回答で紹介されることは別です。アクセス制限、robots.txt、検索向けの指定、サーバーや配信基盤の応答を、対象製品の仕様に合わせて確認します。
Google検索の生成AI機能
現行ガイドは、ページがインデックスに登録され、スニペット表示の対象になることに加え、Search ConsoleのSearch generative AIへの包含条件を案内しています。要件を満たしても、取得・登録・掲載は保証されません。
包含制御の公式ヘルプでは、包含、除外、親プロパティからの継承を区別しています。親の設定を継承している場合もあるため、対象のサイト・範囲に対して何が適用されているかを確認します。この制御は、一般検索全体からの除外や、モデル学習の制御と同じではありません。設定を変える前に、サイトの公開方針と変更権限を確認します。表示を増やしたい担当者の判断だけで、公開を制限している情報まで開放する必要はありません。
OpenAIの検索と学習
OpenAIの公式クローラー資料は、検索用のOAI-SearchBotと、学習に使われ得る内容を取得するGPTBotを分けています。設定は独立して管理できます。ChatGPT-Userはユーザーの操作に応じたアクセスで、自動検索クロールの制御と同一ではありません。この違いを無視して「AI向けBotを全部許可する」と決めないようにします。どの用途の取得を許可したいかを先に決めます。検索用の取得を許可しても、回答の引用や順位、訪問は保証されません。
技術担当へ依頼する際は、対象URL、対象製品、公開方針、取得時の応答、設定の確認日をセットで渡します。自分でページを表示できたことを、全クローラーの取得成功の証拠にはしません。
準備3：本文を整え、必要な構造化データを選ぶ
見出しは読者の問いと対応させ、定義には条件と具体例を添えます。比較なら同じ軸の表にし、根拠と留保を離しすぎないようにします。短い断片へ一律に分割するのではなく、そのページで判断できるだけの説明を残します。
Googleの現行ガイドは、生成AI検索のための特殊なschema.orgマークアップや専用ファイルを必須にしていません。llms.txtもGoogle検索では使用しないと説明しています。他の用途で使う場合は、その利用先と保守する理由を別に決めます。
構造化データを、本文の代わりにしない
構造化データは、ページ内容を機械へ明示する標準形式です。Googleの導入資料を参照し、可視本文と同じ情報を記述します。掲載機能の対象と、一般的な語彙として記述できることを分けます。
表が収まらない場合は、横にスクロールできます
| 記述の候補 | 対象の考え方 | 先に確認すること |
|---|---|---|
| Organization | 組織を説明するページの情報 | 組織名や連絡先が実際の表示と一致するか |
| Article / BlogPosting | 記事の著者や日付など | 原稿の責任者と公開・実更新の情報を示せるか |
| Service | サービスを説明する語彙 | Googleの専用表示機能を当然に伴うと解釈していないか |
| FAQPage | 質問と回答を記述する語彙 | 利用先と目的があるか。質問・回答が本文にあるか |
実装するなら、ページの種類と現行の対応機能を確認し、必要な項目だけをJSON-LDなどで記述します。構文と本文の一致を検査し、Googleの対応する検索装飾機能はRich Results Testでも確認します。対象外の語彙を同ツールが報告しないことと、記述全体が無効であることは同義ではありません。エラーがなくても検索表示やAIの引用が約束されるわけではありません。
FAQ本文と、GoogleのFAQ表示機能を分ける
Googleの更新記録では、FAQ rich resultは2026年5月7日から検索結果に表示されず、6月15日にその文書が削除されています。そのため「FAQ構造化データは効果が測りやすいので、必ず最初に追加する」という順序にはしません。読者が実際に迷う質問へ答えるFAQ本文には、理解を助ける用途があります。一方、その有用性と、Googleの特定の検索装飾機能や他社AIの扱いは別です。既存のFAQマークアップも、別の利用先や保守上の理由を確認して判断します。
準備4：根拠と更新を、主張へ結び付ける
著者名や日付を置くだけで、内容の正しさが証明されるわけではありません。「誰が」「何を」「どの条件で」確認したかを主張の近くに残します。経験談は対象や条件を明記し、資料の要約と自社の実績を混同しません。
表が収まらない場合は、横にスクロールできます
| 原稿の点検箇所 | 残す情報 | 避けたい書き方 |
|---|---|---|
| 数値 | 出典、対象、期間、単位、分母 | 条件の違う改善率だけを並べる |
| 製品仕様 | 公式URL、確認日、利用条件 | 古い仕様を「最新」と呼ぶ |
| 事例 | 実際に確認できた範囲と結果 | 仮想例を顧客実績として書く |
| 更新 | 変更した内容と再確認すべき条件 | 日付だけを新しくして鮮度を装う |
著者情報、引用元、更新日、経験に基づく具体的な説明は、読者が信頼性を判断する材料になります。それらをそろえたことを、全AI共通の引用順位を上げる公式や、E-E-A-Tの認証取得とは扱いません。独自の情報を足す際も、根拠のない独自性より、読者の疑問に答えられる具体性を優先します。
準備5：観測できることを分け、見直し条件を決める
引用、表示、流入、成果は同じものを数えていません。どの製品の、どの範囲のデータかを残します。取得できない項目は、0と不明を区別します。
Googleの専用レポートを読む
Generative AI performance reportの公式ヘルプは、AI OverviewsとAI Modeの表示回数を扱います。ページ別とサイト単位などで集計が異なるため、表の合計とグラフの合計が常に一致するとは限りません。表示回数を、クリック数や読み終えた人数とは呼びません。ヘルプには全世界への展開の注記と、レポートが見えない理由の説明が併存します。実際の利用可否を確認し、データ不足や対象設定を調べます。また、画面で未取得などを表す「~」「-」がエクスポートでは0になる注意があります。書き出した0だけを見て、実際の表示が皆無だったと判断しないようにします。
自前の観測と、サイト成果を混ぜない
計算方法を示す仮想例として、条件を固定した30回答中6回答に自サイトの引用URLがあれば、観測回答内の割合は6/30＝20%です。質問、製品、言語、検索設定、日時を残します。この30回答は市場の利用者を無作為に抽出した標本ではありません。
別に、AI参照元と識別できた50セッションのうち4セッションで問い合わせが起きたなら、セッション単位の発生割合は4/50＝8%です。同一セッションの重複送信は別の成果セッションとして数えません。
この50セッションを先ほどの6引用で割って、引用からの流入率にはできません。同じ回答を見た人の移動を追跡したデータではないためです。広告、季節、他の更新なども変化に関係し得るので、前後の増減だけで施策の因果効果としません。より細かな製品差と分母はLLMOの測定ガイドで確認できます。
一つのページから、作業の採否を決める
最小の検証では、対象ページを一つ選び、五つの準備について現在の状態を記録します。次に、読者の判断に必要で、根拠を確かめられる変更を一つ選びます。
- 問い、対象URL、現在の本文、取得・包含の確認結果を保存する。
- 修正内容、担当、投入する時間の上限、見直す日を決める。
- 本文・リンク・必要なマークアップの一致を確認し、意図した修正かを読む。
- 同じ定義で観測し、未取得・不足・変動も残して次の作業を決める。
たとえば、料金の適用条件を明示する修正は、引用データが少なくても読者の理解に必要な作業として判断できます。引用を増やすための追加施策とは、目的と評価を分けます。技術的な取得障害が見つかったら、それを解決する担当へ戻します。
工数はページ数、CMS、修正範囲、確認体制で変わります。成果の観測に必要な期間もデータ量や製品の変化に依存し、「実装は何週間、成果は何か月」と一律に約束できません。観測を延ばす負担が大きい場合は、調査範囲を絞る、保留する、読者のための内容修正へ戻す判断もできます。
五つの準備は、全部にチェックを付けて終えるためのものではありません。何が不足し、次に誰が何を確認するかを決める道具です。内容の設計はLLMOコンテンツ戦略、取得とページ記述の具体例はAIに選ばれるWebサイトの条件へつなげられます。