LLMO対策とは？AI検索に向けてサイト側でできること・できないこと

LLMOとSEOの関係を整理し、狙う質問を決める

LLMO対策を始める前に、従来のSEOと重なる部分と、追加で確認する部分を分けておくと作業を整理しやすくなります。GoogleはAI 機能とウェブサイトのページで、AI による概要やAI モードに表示されるための追加の要件はなく、特別な最適化も必要ないと説明しています。出典のリンクとして表示される条件も通常の検索と同じで、ページがインデックスに登録され、検索でスニペットを表示でき、検索の技術要件を満たしていることです。

SEOとLLMO対策の共通点と違い

「従来のSEO」の列が整っていないサイトでは、右の列だけを工夫しても効果は限られます。インデックスされていないページや本文を読み取れないページは、検索でもAIの回答でも材料になりにくいからです。

顧客の言葉で質問を書き出す

次に、どの質問に対して自社のページを読んでほしいかを決めます。キーワードの一覧ではなく、営業の会話、問い合わせ、導入時の説明で実際に出てくる質問を、文章のまま集めます。AIへの質問は、条件や状況を含んだ長い文章になることがあるので、その形のまま書き出しておくと、後の効果測定にもそのまま使えます。

予約システムの例なら、次のような質問が考えられます。

• 振替レッスンを生徒が自分で予約できるシステムはある？
• 兄弟で通う場合、月謝の支払いをまとめられる？
• 講師ごとに空き時間を設定し、Googleカレンダーと同期できる？
• 生徒20人ほどの教室だと、月額費用はどのくらい？

質問ごとに「答えるページ」を一つ決め、ページ同士の目的が重ならないようにします。答えるページがない質問は、新しいページや既存ページの節を追加する候補です。最初は10〜20個ほどの質問から始め、後で説明する観察でも同じ一覧を使います。

AIクローラーとrobots.txtを点検する

AIの回答が公開ページを使う経路は一つではありません。GoogleのAI機能は通常の検索インデックスを使います。OpenAI、Anthropic、Perplexityは、検索や回答の出典に使うもの、モデルの学習に使うもの、ユーザーの操作をきっかけにページを取得するものなど、用途ごとに別の名前（ユーザーエージェント）のクローラーを公開しています。どの名前に何を許可するかは、robots.txtで決められます。

主なAIサービスのクローラー

表は各社の公式文書（2026年10月1日に確認）に基づきます。名前や役割は変わることがあるため、設定の前にOpenAI、Anthropic、Perplexity、Googleの最新の説明を確認してください。

学習と検索での表示は分けて決められる

OpenAIは、OAI-SearchBotとGPTBotの設定はそれぞれ独立していると説明しています。たとえば「モデルの学習には使わせないが、ChatGPTの検索には表示されたい」という場合は、GPTBotを拒否し、OAI-SearchBotを許可できます。反対にOAI-SearchBotを拒否したサイトは、ChatGPTの検索回答には表示されず、ナビゲーション用のリンクとして表示される可能性が残るだけになります。

Googleの場合、Google-ExtendedはGoogle検索への登録やランキングに影響しないとされています。ただしGoogle-Extendedが管理するのは学習だけではなく、Geminiアプリなどでのグラウンディング（回答を作るときにGoogleの検索インデックスの内容をモデルに渡すこと）への利用も含みます。拒否するとこうしたグラウンディングへの利用も制限される点を踏まえて判断してください。AI による概要に表示される条件は通常の検索と同じなので、表示する情報を制限したいときは、検索と同じnosnippet、data-nosnippet、max-snippet、noindexを使います。

robots.txtの書き方と見落としやすい点

# 方針の一例：学習用は拒否し、検索・回答の出典用は許可する
User-agent: GPTBot
User-agent: ClaudeBot
Disallow: /

User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Disallow: /members/

User-agent: *
Disallow: /members/

Sitemap: https://example.com/sitemap.xml

これは方針の一例で、どの組み合わせがよいかは事業や考え方によって異なります。設定するときは次の点に注意してください。

• 名前を指定したグループは*のルールを引き継ぎません。robots.txtの標準であるRFC 9309では、クローラーは自分の名前に一致するグループに従い、一致するグループがないときにだけ*のグループに従います。上の例で、出典用のグループにも/members/の拒否を書いているのはこのためです。
• robots.txtはアクセス制御ではありません。RFC 9309も、これらのルールはアクセスの認可ではないと明記しています。OpenAIはユーザーの操作による取得にはrobots.txtが適用されない場合があるとし、Perplexityもユーザーが依頼した取得は一般にrobots.txtのルールに従わないと説明しています（Anthropicは、自社のボットはrobots.txtの指示に従うとしています）。扱いはサービスごとに異なるため、公開したくない情報はログインなどの認証で守ります。
• 反映には時間がかかります。OpenAIは検索結果への反映に24時間ほど、Perplexityは最大24時間かかることがあるとしています。RFC 9309も、robots.txtを取得できない場合を除き、キャッシュしたものを24時間を超えて使うべきではないとしています。
• robots.txt以外の設定も確認します。CDNやWAFのボット対策で特定のクローラーを拒否していると、robots.txtで許可していても取得できません。サーバーやCDNのログで、各クローラーへの実際の応答コードを確かめましょう。

重要な内容は最初のHTMLに含める

GoogleはJavaScript SEO の基本で、ボットによってはJavaScriptを実行できないものもあるため、サーバー側でのレンダリングも有効な方法だと説明しています。料金、対応機能、FAQの答えなど、質問への回答に必要な文章は、JavaScriptを実行する前のHTMLに含めておくと、取得する側の仕組みに左右されにくくなります。ブラウザの「ページのソースを表示」やcurlで取得したHTMLに本文が含まれているかを確認しましょう。

robots.txtとインデックスの基本はrobots.txtのガイドとテクニカルSEOのガイドでも説明しています。

企業・製品の情報を揃え、構造化データとllms.txtの役割を見極める

Googleは、生成AI機能がブログ、動画、フォーラムでの議論など、ウェブ上で製品やサービスについて語られている内容を表示することがあると説明しています。AIの回答は、自社サイトだけでなく、ニュース記事、比較サイト、取引先のページなど複数の情報源をもとに作られることがあります。そのため、会社や製品が「何者か」を示す情報（エンティティ情報と呼ばれることがあります）は、どこで読まれても同じ内容になっていることが大切です。

表記と基本情報を揃える

• 名称：正式な社名、サービス名、略称、英語表記、カタカナ表記の関係を会社概要で説明します。「Example予約（読み：エグザンプルよやく、旧称：○○）」のように旧名称も書いておくと、古い記事とのつながりが分かります。
• 何をしている会社か：事業内容、対象とする顧客、提供地域を一文で言える形にし、トップページ、会社概要、フッター、SNSのプロフィールで同じ説明を使います。
• 連絡先と所在地：住所、電話番号、問い合わせ先を各所で揃え、移転や変更があれば外部のプロフィールも更新します。
• 人の情報：記事の著者や運営責任者を明記します。Googleの有用で信頼性の高いコンテンツのガイドも、著者が誰かを明確にすることはE-E-A-Tの考え方に沿うと説明しています。

構造化データは「見えている情報」を機械向けに書く

構造化データは、ページの内容をschema.orgの語彙で機械が読める形に書いたものです。Googleは構造化データの形式としてJSON-LDを推奨し、組織（Organization）の情報はトップページか、会社概要のように組織を説明する1ページに置くよう勧めています。必須のプロパティはなく、name、alternateName、url、logo、sameAsなど、当てはまるものを追加します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社エグザンプル予約",
  "alternateName": ["Example予約", "Example Yoyaku"],
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "sameAs": ["https://social.example.net/example-yoyaku"]
}
</script>

sameAsには、SNSの公式アカウントなど、同じ組織であることを示す外部ページのURLを入れます。schema.orgの定義でも、対象が何者かを明確に示す参照ページのURLとされています。

注意したいのは、構造化データに書くのは画面に表示されている情報に限るという点です。Googleは、ユーザーに表示されない情報については、正確であっても構造化データを追加しないよう求めています。また生成AI機能向けのガイドでは、生成AI検索に構造化データは必須ではなく、追加すべき特別なschema.orgのマークアップもないとしたうえで、リッチリザルトの対象になるために役立つことから、SEO全体の取り組みの一部として使い続けるよう勧めています。構造化データは「AI専用の近道」ではなく、見えている情報を正確に補う手段と考えるのが現実的です。

llms.txtは任意の提案として扱う

llms.txtは、サイトのルートなどに置くMarkdown形式のファイルで、エージェントやツールがサイトを使うための案内（サイト名、概要、主要なページへのリンク）をまとめるという提案です。Jeremy Howard氏が2024年9月に公開し、2026年8月に「v2」へ更新されましたが、IETFやW3Cの標準ではなく、非公式の提案という位置づけです。必須とされているのは、サイト名やプロジェクト名を書くH1見出しだけです。robots.txtとは目的が異なり、クローラーのアクセスを許可したり拒否したりする役割はありません。

効果については、公式の説明を確認しておきましょう。

• Googleは生成AI機能向けのガイドで、Google検索（生成AI機能を含む）に表示されるために機械可読ファイルやAI向けのテキストファイルを新たに作る必要はないとし、こうしたファイルはGoogle検索での可視性や順位に良くも悪くも影響しないと説明しています。
• OpenAI、Anthropic、Perplexityのクローラーの説明が扱っているのはrobots.txtで、サイトのllms.txtを回答や出典に使うという記述はありません（2026年10月1日時点）。
• ChromeのLighthouseには、ドメインのルートにllms.txtがあるかを調べる試験的な監査があります。調べるのは存在だけで、ファイルがない（404）場合は「該当なし」として扱われます。
• OpenAI、Anthropic、Gemini API、Perplexity、Cloudflareはllms.txtを公開していますが、確認できたものはいずれも開発者向けドキュメントのものでした（2026年10月1日に確認）。

まとめると、llms.txtはAPIのドキュメントのように、開発者が使うツールやエージェントに読ませたい資料があるサイトでは検討する価値があります。一般の企業サイトでは、Google検索については害も益もないとされ、AIの回答での表示につながるという公式の根拠は今のところ見当たりません。優先するのは、robots.txt、読み取れる本文、正確な情報のほうです。llms.txtの書き方と最小構成の例は、llms.txtの解説ガイドで詳しく紹介しています。

回答の材料になる本文を書く：結論、条件、具体例

Googleは生成AI機能向けのガイドで、AIのためにコンテンツを細かく分割する必要はなく、生成AI検索のためだけに特別な書き方をする必要もないとしています。勧めているのは、誰でも書ける一般論にとどまらず、専門知識や経験にもとづく独自の価値があり、読者にとって役立つ内容を作ることです。つまりLLMO対策の文章術は、人が読んで分かりやすい文章とほとんど同じです。そのうえで、日本語のページで見直したい点を挙げます。

見直したい5つの点

1. 見出しの直後に結論を書く。「できます／できません」「料金は月額○円から」のように最初の1〜2文で質問に答え、その後に条件と理由を続けます。
2. 主語と固有名詞を省かない。日本語は主語を省きやすい言語です。「本サービスは」「当社では」だけでは、段落だけを読んだときに何の話か分かりません。製品名を適度に繰り返し、段落単位でも意味が通じるようにします。見出しから途中の節に飛んで読む人にも役立ちます。
3. 数値、条件、例外を具体的に書く。「柔軟に対応」「お気軽にご相談ください」だけでは答えの材料になりません。対応範囲、上限、期限、料金の条件を書き、変わりやすい情報には確認日を添えます。
4. 表と手順はHTMLで書く。比較表や手順を画像だけで載せると、テキストとして読み取りにくくなります。表や番号付きのリストで書き、図には説明の文章を添えます。
5. 自社にしかない情報を入れる。実際の設定手順、画面の説明、自社で確かめた条件など、一般論ではない内容が、ほかのページとの違いになります。

書き換えの例

架空の予約システムで、振替レッスンの説明を書き換えると次のようになります。

書き換え後の文は、誰が、何を、どの条件でできるのかが一文で分かります。これは架空の例で、数値は説明のためのものです。

質問の種類ごとに書く内容を決める

「向いていないケース」まで書くのは勇気がいりますが、条件がはっきりしたページは、質問した人にとって判断しやすい材料になります。FAQは、実際に受けた質問をそのままの言葉で見出しにし、答えをページ上に表示します。

情報の正確さを保つ：出典、更新日、サイト外の記述

AIの回答で自社が誤って説明されていると気づいたとき、最初に確認したいのは自社サイトの中です。古い料金表、終了したキャンペーンのページ、以前のPDF資料が残っていて、現在のページと食い違っていないでしょうか。

サイト内の情報を整理する

• 料金、仕様、対応機能など変わりやすい情報は、基準となるページを一つ決め、ほかのページからはそこへリンクします。
• 古くなったページは更新するか、内容を引き継いだページへリダイレクトします。残す場合は、いつ時点の情報かを冒頭に明記します。
• 事実、例、意見を書き分けます。仮の例は「例」と明記し、測定した結果には、何をどの条件で測ったかを添えます。
• 比較や引用では元の資料へ直接リンクし、確認した日付を書きます。

Googleはユーザーを第一に考えたコンテンツのガイドで、検索エンジンのランキングを操作するためではなく、ユーザーの役に立つことを第一に作られたコンテンツを重視すると説明しています。正確で、根拠をたどれる情報は、人にとってもAIの回答にとっても同じように土台になります。

サイト外の記述も確認する

Googleは生成AI機能向けのガイドで、ウェブ上で見せかけの「言及」を集めることは、一見役立ちそうでも実際にはそれほど役に立たないとしています。自作自演の紹介記事やレビューを増やすより、取引先の紹介ページ、業界団体の会員情報、過去に掲載された記事などに古い情報や誤りがないかを確認し、必要に応じて訂正を依頼するほうが現実的です。

確認の範囲は、社名で検索して上位に出るページと、AIの回答で出典として示されたページから始めると絞り込めます。どのページに何を依頼したかを記録しておくと、次の節で説明する観察の結果と照らし合わせられます。

LLMO対策の効果測定：引用は約束できないので、観察を仕組みにする

LLMO対策では、従来のSEOのように一つの「順位」を追うことは難しくなります。同じ質問でも、サービス、モード、日時、ログインの有無、地域によって回答が変わることがあるからです。そこで、いくつかの記録を組み合わせて傾向を見ます。

1. 質問セットで定点観測する

最初に書き出した質問を、毎月など決まった間隔で同じサービスに尋ね、結果を記録します。1回の回答だけで判断せず、同じ質問を何度か試して傾向を見ます。

誤った説明が見つかったら、前の節の手順で、元になっていそうなページを探して直します。

2. 検索サービスのレポートを使う

• Google Search Console：Googleは、AI機能に表示されたサイトのトラフィックは検索パフォーマンスレポートの「ウェブ」検索タイプに含まれると説明しています。加えて生成 AI パフォーマンス レポートでは、AI による概要とAI モードでサイトへのリンクが表示された回数（インプレッション数）を確認できます。ヘルプページは2026年8月31日に全サイト向けにリリースされたとする一方、段階的に提供しているため利用できないプロパティもあると説明しています。生成AI機能での表示回数が少ないサイトでは、レポートを利用できません。
• Bing Webmaster Tools：2026年2月に公開プレビューとして始まったAI Performanceレポートでは、Microsoft CopilotやBingのAIによる要約などで自社のページが出典として示された回数、引用されたページ、AIが内容を取得するときに使った語句（grounding queries）を確認できます。

3. AIサービスからの訪問を分けて見る

アクセス解析では、参照元にAIサービスのドメインが記録された訪問を一つのグループにまとめ、その後の行動（資料請求、問い合わせ、購入）を見ます。どのドメインが記録されるかはサービスや利用環境によって変わるので、実際のレポートに出てきた参照元から一覧を作り、定期的に見直します。アプリからの訪問などは参照元が残らず、「(direct)」として記録されることもあります。

結果を読むときの注意

3つの記録は、それぞれ別のことを示します。質問セットは回答での見え方、検索サービスのレポートは表示や引用の量、訪問データはその後の行動です。サイトを変更した日と、AIサービス側の大きな変更を一緒に記録し、同じ質問、同じ長さの期間で比べましょう。数週間の変化だけで成否を判断せず、数か月単位で傾向を見るのが現実的です。

点検の順番と、SitelemetryのAI可視性チェックの範囲

今日から始める点検リスト

1. 顧客の質問を10〜20個書き出し、それぞれに答えるページを決める。
2. robots.txtで、AIクローラーごとの方針（検索・出典用と学習用）を決め、CDNやWAFの設定と食い違いがないか確認する。
3. 料金、主要な説明、FAQの答えが、JavaScriptを実行する前のHTMLに含まれているか確認する。
4. 社名と製品名の表記、会社概要、外部のプロフィールを揃え、Organizationの構造化データを表示内容と一致させる。
5. 各ページの冒頭に結論を置き、条件と具体例を書く。
6. 変わりやすい情報に確認日を入れ、古いページを整理する。
7. 質問セット、Search Console、Bing Webmaster Tools、訪問データを月に一度記録する。

SitelemetryのAI可視性チェックが確認すること

SitelemetryのAI可視性の監査は、このリストのうち技術的な準備状況を確認するものです。1回の監査で公開ページを最大5ページ（Starter）、15ページ（Professional）、30ページ（Enterprise）までクロールして静的なHTMLを読み取り、クロール、インデックスの可否、構造化データ、本文、出典の信頼性、計測に関するシグナルから準備状況のスコアを出します。主な確認内容は次のとおりです。

• robots.txtで、GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBot、Google-Extendedなど16種のAI関連クローラーを名前で指定したグループが、サイト全体（Disallow: /）をブロックしていないか。一部のパスだけの拒否やUser-agent: *のルールは、AIクローラーの問題としては扱いません。対象は16種の名前に限られ、Claude-SearchBotのように含まれない名前もあるため、robots.txt全体はご自身でも確認してください。
• JSON-LD形式の構造化データの有無と種類、JSONの書式エラー。MicrodataやRDFaは読み取らず、schema.orgの語彙が正しいかやリッチリザルトの対象になるかは検証しません。
• /llms.txtが空でないテキストファイルとして返り、リンクの案内らしい内容を含むか。仕様に沿った検証や、ファイル内のリンクの確認はしません。
• 想定される質問とページ本文の語句の重なりから、回答に必要な内容がページにあるかを簡易的に見積もります。この見積もりのために質問をAIサービスへ送ることはありません。

このチェックはChatGPT、Claude、Perplexity、Googleに問い合わせず、AIの回答での言及や引用を追跡しません。JavaScriptを実行してページを表示することもないため、前の節で紹介した質問セットでの観察や、Search Console、Bing Webmaster Toolsのレポートと組み合わせて使ってください。

AI可視性を含む6つの監査領域（セキュリティ、テクニカルSEO、AI可視性、アクセシビリティ、パフォーマンス、連携）は、週次の定期監査が付いた月額49ドルのStarterプランから利用できます。Freeプランはセキュリティチェックのみです。登録不要の無料の公開準備スナップショットは、DNS、TLS、セキュリティヘッダーなどの公開情報を読む8項目のパッシブなチェックで、AI可視性は含みません。詳しくは料金ページをご覧ください。