ChatGPTなどに自社ページが出ないとき、構造化データやFAQを増やせば解決するとは限りません。ページを取得できない、質問に答える内容が足りない、情報が古い、別の資料が使われたなど、確かめる場所が違います。
公開資料で確認できるのは、主に取得の設定やコンテンツの要件です。各製品が回答の候補をどう順位付けし、どのページを引用するかの全条件は公開されていません。この記事では、取得できる状態、根拠を確認できる本文、表示・引用の観測、訪問後の成果を分けて整えます。引用を保証する手順ではありません。
30秒で要点
- Google Search、ChatGPT、Perplexity、Claudeの公開仕様を分けて確認します。検索向けBotと学習向けBotも同じ役割ではありません。
- 取得を許可しても、索引登録、回答への引用、流入は保証されません。
- 定義、対象、条件、根拠、著者の責任を本文で明確にし、構造化データは見えている内容と合わせます。
- 日付だけ更新せず、変更箇所と確認範囲を残します。引用率と参照流入・成果は別の分母で測ります。
LLMOは、生成AIを使う検索・回答環境で、自社の情報がどう見つかり、扱われるかを改善・観測する取り組みです。SEOの取得・索引・内容品質の土台と重なる部分があります。基礎はLLMOの入門、製品による違いはAI検索の仕組みで確認できます。
最初に、四つの段階を混ぜない
表が収まらない場合は、横にスクロールできます
| 段階 | 確認する材料 | ここからは言えないこと |
|---|---|---|
| 取得 | HTTP応答、robots.txt、アクセス制御、サーバーログ | 取得を許可したので必ず読まれた |
| 内容 | 可視本文、出典、対象範囲、著者、日付、構造化データの一致 | 正しい形式なので優先的に引用される |
| 表示・引用 | 対象製品、質問、回答日時、表示URL、引用箇所 | 引用された人数や訪問者数 |
| 訪問・成果 | 参照元、セッション、問い合わせ等のイベント定義 | AI回答を見た全員の行動や、施策の因果効果 |
この順序は、担当者が原因を切り分けるための提案です。製品の内部アルゴリズムを再現したものではありません。
1. 製品ごとの取得設定を確認する
2026年10月7日に確認した公開資料では、次のように役割が分かれています。Bot名が似ていても、検索、学習、利用者の依頼による取得を一括で扱わないでください。
表が収まらない場合は、横にスクロールできます
| 対象 | 公開資料で確認できる取得の役割 | 適用範囲・留保 |
|---|---|---|
| Google SearchのAI機能 | Googlebotの取得設定が関係する。対象ページは索引登録され、スニペット表示の対象である必要がある | Google Searchの説明。Gemini Appsの仕様まで同じとは扱わない |
| ChatGPTの検索 | OAI-SearchBotが検索向け、GPTBotが学習向け。設定は独立している | ChatGPT-Userは利用者の操作による取得で、robots.txtが適用されない場合がある |
| Perplexity | PerplexityBotは検索向けで、基盤モデルの学習向けではない | Perplexity-Userは利用者の要求による取得で、通常robots.txtを無視すると公開資料に記載されている |
| Claude | Claude-SearchBot、ClaudeBot、Claude-Userを検索・学習・利用者による取得として区別する | Anthropicはこれらのrobots.txt尊重を説明。他社の利用者向け取得と同じ動作とは限らない |
根拠はGoogle SearchのAI機能、OpenAIのBot一覧、Perplexityのクローラー説明、Anthropicの取得方針です。各ページは公開された取得方針の根拠であり、引用順位の説明ではありません。
robots.txtは、目的を決めてから書く
次は、公開サイトの通常ページは取得を許し、GooglebotとOAI-SearchBotにも同じ方針を示し、GPTBotには全体の取得を許可しないという架空サイトの設定例です。/internal/は取得させたくない公開パスの例で、機密情報を置く場所ではありません。
User-agent: *
Disallow: /internal/
User-agent: Googlebot
Disallow: /internal/
User-agent: OAI-SearchBot
Disallow: /internal/
User-agent: GPTBot
Disallow: /*のグループを特定Botのグループに足し合わせません。そのため、特定グループにも必要なパス制限を書いています。他社Botの実装をGoogleの仕様だけで保証することはできないので、対象事業者の資料と取得ログも確認します。
robots.txtはアクセス認証ではありません。非公開情報はログインやアクセス権限で守り、URLを知っていれば読める状態をrobots.txtだけで保護しないでください。WAFやCDNでBotを許可するときも、User-agent文字列だけを信用せず、事業者が公開するIP情報等と照合します。拒否や認証を回避して取得できるようにする話ではありません。
2. 質問に答える本文と、確認できる根拠を用意する
読み手が必要とするのは、用語を短く定義するだけでなく、「自分の場合にも当てはまるか」を判断する材料です。見出し、箇条書き、表はその整理に使えますが、FAQ形式だから引用されるという保証にはなりません。
次のMarkdownは、架空の説明記事の本文例です。公開時には、定義と適用範囲、根拠へのリンクが人にも読める形で表示される必要があります。
# AI検索向けページの点検例
AI検索向けページの点検では、取得設定と本文の根拠を別々に確認します。
## 対象と限界
この例は公開記事を対象にします。取得許可は引用を保証しません。
## 確認した根拠
Google Searchは、AI機能用の特別なschema.org構造化データは不要と説明しています。
[Googleの説明](https://developers.google.com/search/docs/appearance/ai-features)
他社製品の内部選定条件まで、この資料からは判断できません。数値や効果には、その数値の出所、対象、期間、分母、測定方法を添えます。過去の市場予測を現在の実測値として扱わず、独自の提案と、資料で確認できる事実を分けてください。出典リンクがあっても、リンク先がその主張を支持しているかは本文を読んで確かめる必要があります。
著者情報は、肩書を盛るための欄ではない
著者や編集者が誰で、何を確認し、誰が訂正を受け付けるかを示します。個人の資格や経験は確認できる範囲だけにし、組織の記事を架空の専門家が書いたように見せないでください。次も架空サイトの表示例です。
## 作成と確認の責任
作成：例示編集室（架空の組織）
確認範囲：掲載した公開仕様と、このページの実装例
未確認：各製品の非公開の引用順位、実際の掲載効果
訂正窓口：このサイトの問い合わせページ実案件の事例を載せる場合は、公開できる根拠と許諾の範囲を確認します。経験年数や導入社数の数字を足すだけで、記事の主張が確かになるわけではありません。
3. 構造化データを可視本文と一致させる
GoogleはAI機能に特別なschema.org構造化データは不要と説明しています。また、構造化データの一般方針は、正しく実装してもリッチリザルト表示が保証されないと明記しています。形式が正しいことと、掲載・引用されることを分けましょう。
Articleの公開仕様は、見出し、著者、公開日、更新日などの情報を説明しています。次は、上の架空記事と対応するJSON-LDのデータ部分です。実装時はページへ適切に挿入し、本文の著者と日付も同じ内容にします。この例のドメインや組織を実サイトへそのまま転載しないでください。{
"@context": "https://schema.org",
"@type": "Article",
"headline": "AI検索向けページの点検例",
"author": {
"@type": "Organization",
"name": "例示編集室",
"url": "https://example.com/about"
},
"datePublished": "2026-10-01T09:00:00+09:00",
"dateModified": "2026-10-04T09:00:00+09:00",
"mainEntityOfPage": "https://example.com/ai-search-check"
}ページに存在しない著者、実績、評価、FAQを構造化データにだけ足しても、内容の信頼性は増しません。ページに合う型と値を選び、JSONの構文確認、可視本文との照合、対象検索サービスの検証手段を順に使います。構文検査で合格しても、実際の索引登録や引用は別に観測する必要があります。
4. 更新日には、何を確かめたかを結び付ける
更新日は内容の再確認を追えるようにするための情報です。日付だけを新しくして、読んでいない仕様まで確認済みに見せないでください。次は上のJSON-LDと対応する架空記事の表示例です。
公開日：2026年10月1日
更新日：2026年10月4日
更新内容：公開Botの役割を確認し、robots.txtの説明を修正。
確認範囲：リンク先の公開資料と掲載例。実際の引用順位や掲載効果は未検証。製品名、Botの役割、利用条件など変更されやすい箇所は、担当者と再確認するきっかけも決めます。「毎月必ず全資料を読み直す」ことが難しければ、公式変更の告知、取得エラー、問い合わせ、引用内容の誤りを再点検のきっかけにできます。これは運用の提案であり、更新頻度による順位向上の実証ではありません。
5. 小さく検証し、引用と成果を別々に記録する
最初は代表的な公開ページを一つ選びます。次の順序なら、何を直し、どこまで確かめたかを残せます。
- 対象製品と質問を決め、公開URL、取得設定、HTTP応答、主要本文を点検する。
- 内容の対象、条件、出典、責任者、更新理由を確認する。
- 可視本文と構造化データ、リンク先、日付の一致を確かめる。
- 表示・引用を観測するときは、製品、検索機能の使用、質問、日時、回答、引用URLを保存する。
- アクセス解析では参照流入と成果の定義・分母を別に記録し、断定できない部分を残す。
たとえば固定した10問を2回ずつ観測し、20回答中5回答で対象ページへの引用リンクがあったなら、この仮想観測内の引用率は25%です。利用者全体の25%に表示された意味ではなく、流入が5件あった意味でもありません。モデル、製品、日時、回答の揺れや観測対象の選び方に依存します。
施策前後で差があっても、その間の製品変更、質問の構成、競合資料の変化が関わり得ます。取得・引用・参照流入・成果はそれぞれの観測手段と分母を使い、LLMOの効果測定に沿って比較条件を固定してください。
AIに選ばれることを約束する設定はありません。まずは、人が内容を検証できるページを作り、公開仕様で確認できる取得条件を整え、実際に起きたことを段階ごとに記録する。それが、改善箇所を見つけるための最小の取り組みです。