メインコンテンツへスキップ
ブログ一覧に戻る
LLMO(AI検索最適化)

LLMOとは?SEOとの関係・AI検索の取得条件と効果の測り方

2025年12月14日
最終更新: 2026年10月19日
16分で読めます

この記事でわかること

LLMOとは、AIの回答で自社情報が正確に参照されるよう、Webの内容と観測方法を整える取り組みです。SEOとの関係、Google・OpenAIの取得条件、構造化データの役割、Bingの引用指標を公式資料で整理。固定質問の計測例を使い、引用・流入・成果を分け、既存記事の更新と施策の優先順位を判断する方法を解説します。

2026年10月8日に、Google Search CentralのAI features、OpenAI Crawler、W3C robots仕様を再読しました。GoogleのAI機能は通常のSEO基礎、技術要件、本文の可読性、必要に応じた高品質画像を前提にし、特別なAI用ファイルやschemaを追加すれば掲載されるとは説明していません。検索取得、学習・grounding、index/serveの保証は分け、robots.txtを認証やアクセス制御の代わりにしません。

LLMOは、AIの回答で自社の情報が正確に参照されるよう、Web上の情報と、その観測方法を整える取り組みです。 Large Language Model Optimizationの略で使われます。ただし、共通の認定規格や、すべてのAIに効く掲載ルールがあるわけではありません。

「何か特別なタグを追加すれば引用されるのか」「SEOをやめてAI対策へ移るべきか」と考える前に、取得・内容・引用・成果を分けて確認しましょう。このガイドは、Web担当者が自社サイトの着手順を決めるための入口です。製品の仕様に関する説明は、2026年10月4日に確認した公開資料に基づきます。

30秒で要点

  • GoogleのAI OverviewsやAI Modeでは、SEOの基本が引き続き重要です。特別なAI用ファイルや専用の構造化データは必要ないと説明されています。
  • 検索のための取得と、モデルの学習利用は別の論点です。サービスごとにクローラや設定の役割を確認します。
  • 自社名が出ること、URLが引用されること、サイトへ来訪すること、問い合わせにつながることは、それぞれ違う成果です。

この記事で紹介する施策は、掲載を保証する裏技ではありません。読者と検索システムが内容を確認できるようにし、公開後の変化を誤解せず測るための実務です。Google:AI features and your website

どこから読むか — 自分の状況から選ぶ

この記事はLLMOの基礎を扱います。着手順・実装・測定・限界はそれぞれ別の記事にあります。

何から着手するか決めたい。 順番の考え方は着手の順番を判断する考え方、担当者向けの準備は今から始める5つの準備、既存記事の棚卸しは既存記事のLLMO監査ガイド。

SEOと何が違うのか整理したい。 違いの本体はLLMOとSEOの違い、AI検索の仕組みはLLMはどうやって情報を取得・選択するのか、優先順位の統合はSEO/LLMO/CROを統合する優先順位の決め方。

引用される設計をしたい。 情報設計の型はAIが引用したくなる情報設計チェックリスト、取得・内容・引用を分ける話はAIに選ばれるWebサイトの条件、構造の作り方はLLMO実装ガイド、関連検索を前提にした構造はquery fan-outとは?。

効果を測りたい・測れているか不安。 追跡の方法はLLMO効果測定ガイド、どの段階の話かを分けるなら「引用順位」と「発見可能性」を混同しない読み方、レポートの限界は生成AIレポートで分かること・分からないこと、名前が挙がることとの違いは「名前を挙げられる」と「選ばれる」は別。

やり方が合っているか疑っている。 よくある間違いはLLMO失敗パターン、効果の根拠をデータで見るならllms.txtは効果があるのか、Googleが名指しした施策は「やらなくていい」と名指しされた5施策、チェックリスト化の限界はLLMOはチェックリストではない。

載せる/載せないを選びたい。 可視性の選択はAI検索に「載らない」を選べる時代、取得と利用の層の違いはIETF AIPREFが分けた2つの層、ドメイン単位の判断は「優先する情報源」はドメイン単位。

SEO・LLMO・GEOの関係

SEOは、検索エンジンがサイトの内容を見つけ、理解できるようにし、必要な人へ届けるための取り組みです。キーワードを増やすことだけを指すわけではありません。LLMOやGEO(Generative Engine Optimization)は、生成AIの回答での情報の扱われ方に焦点を当てる言葉として使われます。ここでは名称より、対象サービスと観測する結果を明確にします。

表が収まらない場合は、横にスクロールできます

観点従来の検索結果を中心に見る場合AIの回答を含めて見る場合
接点検索結果のタイトル・説明・リンク回答本文の説明、出典リンク、ブランドへの言及
内容の確認ページが意図した検索に対応しているか要約されても条件・対象・結論が正しく伝わるか
技術面取得、インデックス、内部リンク、表示内容サービス別の取得条件に加え、同じ基盤を確認
観測検索表示、クリック、来訪後の行動引用・記述の正確さと、来訪・成果を別々に測る

二つは重なる部分が多く、SEOを捨ててLLMOへ置き換えるという関係ではありません。GoogleはAI機能でも通常の検索の基本を案内しています。一方、Googleの説明だけで、OpenAIや他のサービスの選択基準まで説明できるわけではありません。

AI検索では、質問に対して複数の検索を行い、複数の資料を使う場合があります。GoogleのAI機能の説明にも関連検索を広げる仕組みがありますが、すべての回答が常に同じ経路を通るわけではありません。単独の検索順位と、特定のAI回答への引用を一対一に対応させないことが大切です。

取得から成果までを分けて診断する

サイトが引用されない原因を、文章の書き方だけに求めると遠回りになることがあります。次の図は、調査を進めるための確認順です。各社の内部処理を再現した図ではありません。

取得条件、内容と出典、回答内の引用、来訪後の成果を順に確認し、各段階で分かることを区別する診断図
編集部作図。各社の内部処理ではなく、調査の順序です。末尾の9/30=30%は全30回で回答が得られた架空の固定質問テストで、BingのCitation Shareや全市場のシェアとは異なります。

1. 公開情報が取得できる状態か

対象ページが公開され、意図した内容を返しているかを確認します。誤ったrobots.txt、CDNの遮断、ログイン要求、内部リンクの欠落などがあれば、内容を磨く前に調べます。GoogleのAI機能でサポートリンクの候補になるには、インデックス登録され、検索のスニペット表示の対象であることが条件として説明されています。それでも掲載が保証されるわけではありません。

すべてのページをAIに公開する必要はありません。非公開資料は認証とアクセス権で守り、公開するページの範囲を決めます。robots.txtでのクロール指示はアクセス制御の代わりにはなりません。仕組みの違いはrobots.txtでは情報を非公開にできない理由で解説しています。

2. 取得と学習利用の設定を混同していないか

同じ会社のクローラでも用途が異なります。たとえばOpenAIは次のように区別しています。

表が収まらない場合は、横にスクロールできます

識別名公式資料で説明される用途判断するときの注意
OAI-SearchBotChatGPTの検索機能許可は引用の保証ではない。拒否していてもナビゲーションのリンクとして出る場合がある
GPTBot基盤モデルの学習に使われ得る内容の取得OAI-SearchBotとは独立した設定として扱う
ChatGPT-User利用者の操作をきっかけにしたページ訪問など自動クロールではなく、robots.txtが適用されない場合がある。検索掲載の制御用ではない

検索向けの取得を許可することと、学習向けの取得を許可することは、同じ判断ではありません。設定を変える前に、自社の公開方針と該当サービスの資料を照合してください。OpenAI:Overview of OpenAI Crawlers

Googleについても、SearchのAI機能を扱うGooglebotと、他のAI用途に関わるGoogle-Extendedを同一視しないようにします。検索上の表示を制御したいのか、別の利用を制御したいのかによって、確認する項目が変わります。設定名から効果を推測せず、GoogleのAI機能に関する制御の説明を起点に確認します。

3. 情報の意味と出典が伝わるか

取得できたページに、読者が必要とする答えがあるかを見ます。たとえば「費用は安い」「成果が高い」だけでは、比較する条件が分かりません。対象、期間、含まれる範囲、例外、出典が必要です。

文章は、見出しごとに一つの疑問へ答え、結論の近くに条件と根拠を置くと読みやすくなります。これは編集上の方針です。その形式だけで引用率が上がるという各社共通の規則ではありません。

4. 回答と、その先の成果を確認できるか

回答に会社名が出ても、同名の別会社かもしれません。URLが載っていても、本文にない説明へ出典が付いている場合があります。記述内容と実際の引用先を照合します。

そのうえで、来訪や問い合わせにつながっているかを別に見ます。引用が増えてもクリックが増えるとは限りませんし、クリックが少なくても比較検討の中で正しい情報が伝わる価値はあり得ます。自社が何を改善したいかを先に決めておきましょう。

既存の記事を直すときの具体例

最初から全ページを同じ形式へ変える必要はありません。重要なサービス説明や、古い情報が残る記事から、読者の意思決定に必要な情報を整えます。

表が収まらない場合は、横にスクロールできます

改善する箇所曖昧な状態書き直す方向
定義専門用語だけで説明している何を指し、何を含めないかを示す
主張「大幅に改善する」と断言する何を測ったか、比較条件と限界を示す
数値分母や期間がない対象、単位、集計期間、出典を近くに置く
実例架空の例が導入実績のように見える仮例と明記し、実績なら確認可能な根拠を付ける
著者・更新誰の説明か、いつの仕様か分からない実際の執筆・確認主体と確認日を示す
関連情報類似記事がばらばらに存在する基礎から詳細へ、目的の分かる内部リンクでつなぐ

たとえば、架空のサービス比較を「A社は安く、B社は高機能」とだけ書くと、読み手は比較できません。「月額に何が含まれるか」「同時利用人数」「追加費用」「確認日」をそろえ、確認できなかった項目は未確認として残す方が役立ちます。

価格や機能を表にしたら、条件を画像の中だけへ閉じ込めず、本文でも読めるようにします。図は関係や判断順を説明するために使い、数値の根拠や留保は本文に置きます。FAQも、実際に補足すべき疑問があるときに設ければ十分です。全記事に同じ質問を足すこと自体が目的ではありません。

著者情報や一次資料へのリンクは、誰が何を根拠に説明しているかを確かめる手がかりになります。ただし、「専門家と書けばAIが優先する」といった単純な規則に置き換えないでください。経験談、調査結果、編集部の推奨を区別して説明することが先です。

構造化データで確認すること

Schema.orgの語彙を使ったJSON-LDなどは、ページの種類や著者、日付を明示する方法です。GoogleのArticle資料は、記事に関する情報の理解に役立つと説明しています。しかし、GoogleのAI機能に特別なschemaは必要なく、構造化データを追加しても掲載は保証されません。Google:Article structured data

実装では、コード例を各記事に貼る前に、CMSや共通テンプレートがすでに出力しているかを確認します。同じ記事に別の日付や著者を持つデータを重ねないためです。

表が収まらない場合は、横にスクロールできます

項目照合する内容
headline読者に表示する記事タイトルと意味が一致しているか
author実際の著者を表し、個人ならPerson、組織ならOrganizationとしているか
datePublished実際の初回公開日になっているか
dateModified内容を更新した日を表し、単なる再ビルドで新しくしていないか
image記事を表す画像で、公開URLから取得できるか
URLの対応別記事や旧URLの情報を混ぜていないか

表示内容と出力HTMLを照合し、対象の構造化データを検証したうえで、公開後の取得状態も確認します。構文検査に通ることと、説明内容の正しさ、引用の有無は別の確認です。

なお、GoogleはAI用の新しいテキストファイルも不要と案内しています。llms.txtなどを導入する場合は、対象サービスでの用途や対応を確認して判断し、Googleの掲載必須条件として扱わないようにします。

引用・流入・事業成果を分けて測る

計測表には、少なくとも「どのサービスの、どの期間の、何を数えた値か」を書きます。異なる仕組みの指標を、同じランキングとして足し合わせないことが大切です。

表が収まらない場合は、横にスクロールできます

見たいこと使える観測その観測だけでは分からないこと
Google Searchでの接点Search ConsoleのWeb検索データすべてのAIサービスの引用状況
対応するMicrosoft系サービスでの引用Bing Webmaster ToolsのAI Performance全AI市場のシェア、引用された理由の確定
特定の質問への回答条件をそろえた固定質問の記録実利用者全体の体験や市場の代表値
サイトへの来訪参照元などのアクセス記録記録されない訪問経路、引用全体の回数
来訪後の成果問い合わせや申込などの定義済みイベントその成果が特定の改稿だけで生じたか

GoogleのAI機能のデータは、Search ConsoleのWeb検索の集計に含まれると説明されています。集計値だけから、AI機能による成果をすべて切り出せるとは解釈しないでください。

Bingは2026年2月10日、Copilot・Bing・一部の連携先における引用を扱うAI Performanceの公開プレビューを発表しました。引用件数は、回答内の順位や配置、ページの権威を示す値ではありません。Bing:AI Performanceの発表

同年6月16日の追加機能の発表では、Citation Shareを「同じgrounding queryにおける、全サイトの引用のうち自サイトに帰属する引用の割合」と説明しています。流入シェアや品質点ではなく、前後の変化を観察するための指標です。質問の分類や時期比較などもプレビューとして案内されています。Bing:追加されたAI可視性の指標

固定質問を使う場合の記録例

自社に関係する10個の質問を決め、各3回、計30回の回答を確認する仮例を考えます。サービス、表示されたモデル名、検索機能の状態、言語、実施日時、ログインや会話履歴の条件を記録し、新しい会話から同じ質問を送るなど、条件をそろえます。表示されない内部条件は推測で埋めません。

この仮例で30回すべて回答が得られ、自社URLを出典に含む回答が9件なら、この固定質問群内での観測割合は9÷30=30%です。一つの回答に自社URLが複数あっても、この定義では回答1件として数えます。BingのCitation Shareとは分母が違います。

回答なしやエラーがあった場合は、その件数も記録します。「予定した試行全体」と「回答を取得できた試行」のどちらを分母にしたかを明記し、都合のよい回答だけを残さないでください。検索を使わなかった回答も、検索を使った回答と区別します。

記録するのは有無だけではありません。

  • 自社についての説明は、公開している情報と一致しているか。
  • リンク先は自社の意図したページか。別会社や古いページではないか。
  • 引用先に、回答が述べた内容と条件が実際にあるか。
  • 訂正したい誤解は何か。それはサイト側の曖昧さと結びついているか。

同じ質問を繰り返しても、独立した利用者の無作為な標本にはなりません。この30%を市場シェアと呼んだり、数回の上昇で改稿の効果を確定したりはできません。まずは特定条件で起きる誤引用や欠落を発見する用途に使います。

何から着手するかを決める

優先順位は、AI向けの形式へ変えやすい順より、情報が間違って伝わったときの影響と、現在の問題から決めます。

  1. 公開・取得の問題を直す:重要な公開ページが意図せず遮断されていないか、古いURLへ誘導していないかを確認する。
  2. 重要情報の不一致を直す:サービス内容、対象、料金条件、会社情報、古い仕様や根拠不明の実績を確認する。
  3. 疑問に答えられる内容へ整える:定義、比較条件、手順、出典、適用できない場合を加える。
  4. 観測して次の更新を決める:引用の正確さと来訪後の成果を記録し、残った誤解や不足を直す。

計画を立てる前に、「誰に何を正しく理解してほしいか」「どのページにその答えがあるか」「何が変われば改善と言えるか」の3点を書き出すと、対象を絞れます。すでに取得できるページなら、タグ追加より、古い情報や説明不足を直す方が先になることもあります。

小さな実施計画には、対象URL、修正する主張と根拠、担当者、確認日、観測条件、見直す時期を残します。仕様やサービスが変わったときに、日付だけを更新せず内容を再確認できるようにします。名称や画面だけを追う作業より、重要情報を保守できる体制が必要です。

基本の検索対策を整理したい場合はSEO入門、着手する施策を比較したい場合はAI時代のWeb施策の優先順位、運用の設計には継続的に改善するWeb制作へ進んでください。

よくある質問(FAQ)