LLMOの本質とは？AI検索で自社を正しく伝えるための情報の整え方

LLMOは、大規模言語モデル最適化の略です。英語ではLarge Language Model Optimizationと呼びます。

扱う範囲は実務の改善です。AI検索やAIの回答で、自社の情報がどう扱われるかを整えます。

モデルの追加学習とは違います。内部の仕組みを調整する技術論とも区別します。

私は、その目的を顧客が自社を正しく選べる状態を整えることに置きます。

何を頼めて、誰に向くのか。条件や相談先はどこか。AIの回答と自社ページで、この事実が食い違わない状態を目指します。

例えば経営者向けの研修です。それが開発講座としてAIに紹介されたらどうでしょう。

リンクがあっても期待はずれます。名前が出ることと、合う人に正しく伝わることは別です。

似た言葉もあります。AIでの露出を扱うGEO、回答を意識したAEO、検索全体のSEOです。

Googleは、自社の生成AI検索も検索体験の最適化であり、従来のSEOの基本が引き続き土台になると説明しています。出典：Googleの生成AI検索向け最適化ガイド

呼び名が増えても、仕事を別々に増やす必要はありません。経営者がやるべき基本は同じです。

サービス名をそろえる。条件をはっきり書く。根拠にたどれるようにする。これまでのサイト改善と同じ基礎から始められます。

ただし、すべてのAIを通じた1つの「AI順位」があるようには考えません。

どのツールの、どんな質問への回答か。条件を外すと、順位を比べる意味がなくなります。

では、どこから直せばよいのでしょうか。

見直す対象を4つに分けます。実務を進めるための見取り図です。AIの内部処理がこの順番で進むわけではありません。

ここでいう理解は、AIの頭の中を測ることではありません。

確かめるのは回答の正確さです。対象者や費用、条件を、公開ページと突き合わせます。

引用と推薦は別です。

料金比較で引用されても、おすすめとは限りません。対象外だと説明するために引用されることもあります。

引用の先には、生身の人の判断があります。

回答に出ても、条件が合わなければ申し込まれません。引用と推薦、成約は自動ではつながりません。見かけの数字だけに惑わされないようにしたいところです。

冒頭の例なら、問い合わせ先と対象者を先に確認します。記事を増やすのが先ではありません。

何が食い違っているかを整理します。それだけで、1つのページでも直す場所が見えてきます。

引用されやすい文章の形式に整えれば、AIに選ばれる。そう考えたくなります。

社名が出るだけなら、AIが事前に持っている知識で語られることもあります。でも、自社ページが出典として引用される話は別です。

検索型の回答では、参照候補に入らなければ文章の書き方を工夫しても届きません。顧客の疑問に答えるページが、まず検索で拾われる状態にあるかを確かめます。

Googleが説明するquery fan-outは、1つの質問から関連する複数の検索へ広げて情報を集める方法です。例えば研修探しなら、内容だけでなく対象者や実施条件まで調べるイメージです。この例は分かりやすさのための説明であり、実際に発行される検索語そのものではありません。出典：Google「AI features and your website」

研究の結果も、実験の前提によって意味が変わります。何を検索の候補に入れた環境なのかが重要です。

KDD 2024のGEO論文は、文章の提示方法を変えて生成回答内での可視性を評価しました。売上や問い合わせの改善を示した研究ではありません。検索順位への影響も評価の対象外で、結果をそのまま現在の全サービスへ広げることはできません。出典：GEO論文

KDD 2026のSAGEO Arenaは、検索、候補の並べ直し、回答生成までを含めて検証する環境を用意しました。既存の手法が取得段階で不利になる場合があることや、構造化された情報が役立つ結果を示しています。ただし、商用検索の非公開シグナルまで再現した環境ではありません。出典：SAGEO Arena論文

2026年10月10日の「What Drives AI Citations?」も、取得と言及・引用の違いを調べています。米国市場についての英語の質問を用いた2市場の調査です。質問に合うページと引用の関連や、取得の重要性を報告しています。査読状況を確認できないプレプリントです。APIでの再実行と一般画面の差、取得できなかったページがあるなどの限界があります。出典：What Drives AI Citations?

FAQを消せば引用が増える、という単純な話ではありません。市場も質問も違います。自社に持ち込むなら、まずは仮説として扱います。

また、取得されたページと引用されたページの差を分析した研究もあります。2025年のLMArenaログを分析した結果であり、当時の観測を現在のモデルの引用割合にそのまま読み替えることはできません。出典：Attribution Crisis論文

持ち帰りたいのは、引用の見た目だけで判断しないことです。

疑問に答える情報があるか。そのページへたどり着けるか。回答に出ない原因を書き方だけに求めず、まず検索で取得されているかを調べます。

専用ファイルや特別なタグが必要に見えるかもしれません。でも、何のために足すのか。まず目的を整理します。

Googleの最適化ガイドでは、Google検索においてllms.txtなどの専用ファイルや特別な構造化データを必要とせず、検索での特別な優遇材料にしないと説明しています。この説明の対象はGoogle検索です。他社AIの活用や社内文書の案内用途まで無意味だと広げるものではありません。出典：Googleの生成AI検索向け最適化ガイド

llms.txtの提案は、AIエージェントへサイトの概要や詳細文書へのリンクを渡すための仕組みです。例えば開発用の文書へ案内する用途には実用的な意味があります。ただし、文書へ到達しやすくする設計と、検索順位や問い合わせが増える証拠は別です。出典：llms.txt提案原本

構造化データも同様です。ページにある商品や組織の情報を機械が扱いやすい形で記述するものですが、本文と一致していることが基本です。Googleも、画面に見える内容との一致を基本条件に挙げています。出典：GoogleのAI検索向け基本事項

見えない場所に高評価を足してはいけません。確認できない実績を入れても、本来の事実を壊すだけです。

実在する内容をそのまま正確に伝える。必要なのはそれだけです。

FAQも、顧客が判断に迷う疑問に答えるために置きます。

条件が分からないなら、条件をはっきり書きます。似た質問で数を増やすより、判断を止めている1点を解消するほうが役に立ちます。

Googleの人を第一に考えたコンテンツ指針でも、独自の情報や正確さ、ページの目的を果たす内容を確認するよう促しています。日付だけを変えて新しく見せることも自己点検の対象です。出典：Googleのコンテンツ品質指針

追加する前に、まずは「これで顧客のどの疑問が解けるか」を確かめます。答えが出ないなら、追加作業に追われる前に、本文の説明不足を見直します。

検索で読ませることと、モデルの学習を許可することは別です。

AI検索に出たいからといって、すべてのアクセスを一括で許可する設定変更は避けます。

OpenAIは、検索用のOAI-SearchBotと、基盤モデル学習用のGPTBotを個別に設定できると説明しています。ChatGPT-Userは利用者の操作に伴う取得であり、検索参加を管理する代わりにはなりません。出典：OpenAIのクローラー説明

PerplexityBotは検索結果でサイトを表示・リンクするためのもので、基盤モデルの学習用ではないとされています。アクセスを調べる際は、robots.txtだけでなく、WAFの設定や公式IP範囲の確認も必要です。クローラーが到達できることと、掲載が保証されることは別です。出典：Perplexityのボット説明

Googleでは、Googlebotによる取得、検索対象への登録や抜粋表示、生成AI機能への参加、そして学習への利用制御が区別されています。Search Consoleの生成AI参加設定（include・exclude・inherit）は学習制御とは別で、学習の制御にはGoogle-Extendedを使います。出典：Search generative AI control

サイト管理担当者と一緒に、現在の設定と目的を確かめます。

検索に出したいページはどれか。守る情報はどれか。拒否されているアクセスログがあるか。設定の名前だけで決めず、対象のページと記録を見て判断します。

この記事では、そのまま貼れる全文許可の設定は載せていません。既存の保護まで外してしまう変更は、サービスページの改善という範囲を超えてしまうからです。

顧客の個人情報や社内の記録、守秘義務のある資料を公開する必要はありません。

出せない事例の代わりに架空の実績を作るのではなく、公開できる範囲と出せない範囲をはっきり分けます。

対策の結果を何で見ますか？ 名前が出た回数だけでは、冒頭に挙げた古い問い合わせ先には気づけません。

自社の名前が出たか、自サイトへの引用リンクがあるか、どんな用途で勧められたか。そして事実の正確さ、訪問、問い合わせを別々に記録します。

1つのスコアにまとめる前に、何を観測できたかが分かる状態を作ります。

Googleは、2026年にSearch Consoleの生成AIパフォーマンス報告を発表し、2026年8月31日に全世界への展開を完了しています。AI OverviewsやAI Modeでの表示を、ページや国などから確認できます。十分な表示実績がないサイトでは報告自体が出ない場合もあります。現在も生成AIの数値を分けて見られない、という話は当てはまりません。出典：Googleの生成AIパフォーマンス報告・発表資料

BingのAI Performanceは、CopilotやBingのAI要約、一部の提携先での引用を表示します。取得に使われた語の一部も確認できます。ただし、引用回数は順位や売上を表す指標ではありません。出典：Bing AI Performance

追加機能のTopics Portfolioは、話題ごとの広がりを見るベータ機能です。十分なデータがあるサイト向けで、分類に誤りがあり得ることや、数値が概数であることも説明されています。出典：Bing Topics Portfolio

これら個別のツールの数値を合算して、全AIにおける自社のシェアとは呼びません。対象のサービスも、数える定義も違うためです。

同じ顧客の質問を、同じ条件で残す

手元でAIの回答を比べるなら、まず質問を固定します。

例えば「初めてAI研修を受ける経営者に向く内容は何か」「費用には何が含まれるか」。これらは仮の例です。実際の顧客からよく受ける相談に合わせて選びます。

残すのは質問文だけではありません。

使ったツールとモデル、検索のオン・オフ、日時、場所、新規の会話かどうかを添えて、複数回の回答を保存します。Webの画面とAPIの結果も混ぜずに分けます。

集計は、同じ条件で取得できた回答のうち「何回名前が出たか」「何回引用されたか」を数えます。対象者や費用の正確さも、元のページと突き合わせます。

エラーなどで取得できなかった回答は「未取得」です。言及がなかった回答として数えてはいけません。

Search Consoleの仕様として、管理画面上で利用できない指標が書き出し時にゼロになる場合もあります。書き出した数字だけを見ず、画面の表示と取得条件の記録も手元に残しておきます。出典：Generative AI performance report

変更前後に回答の差が出ても、同じ時期にモデルや検索側が更新されていれば、自社ページの修正だけが原因とは断定できません。比較の結果と、原因についての解釈を分けます。

回答を見て知った人が、後から社名で検索して訪れることも考えられます。

ただ、その経路を確かめられないなら、AIの成果だと決めつけません。分からないところを残しておくことも、次の判断を誤らないために大切です。

調べる項目が増えましたが、最初からサイト全体を直そうとしなくて大丈夫です。私が勧めたい着手方法は、重要な既存サービスページを1つ選ぶことです。

仮の研修会社で考えます。変更前の見出しが「経営を変えるAI研修」だけだったとすれば、大まかな方向性は伝わっても、自分に合うか判断できません。

これは実施結果ではなく、ページを見直すための仮の設計です。値段や導入社数は作りません。未確認の欄があれば、未取得として社内の担当者へ確認します。

看板のキャッチコピーだけでは、店の実際の味や自分に合う一皿までは分かりません。サービスページも同様に、良さを伝える言葉に加えて、選ぶための具体的な条件が必要です。

AIには、読み取りから修正案までを任せる

まずはAIに公開ページを読ませ、根拠となるURLと場所を挙げてもらいます。

次に、同じサービスについて別ページと矛盾がないかを確かめます。料金だけでなく、サービス名や対象者、問い合わせ先まで突き合わせます。

そのうえで、変更前の本文と修正案を並べます。事実に基づいた訂正なのか、書き方の提案なのか、追加確認が必要なのかが見えると、判断もしやすくなります。

公開、設定変更、削除、送信は、人が承認してから行います。内容を確認していないまま、AIにサイト全体を書き換えさせる必要はありません。

直す前の本文と、AIの回答記録は手元に残します。公開した後は窓口が動いているかを確かめ、同じ質問で回答を比べます。

ページが正確になったこと、引用が増えたこと、問い合わせが増えたこと。それぞれ別の結果として受け取ります。

新しい記事を増やす前に、今ある情報の食い違いをなくす。まず取り組みたい最初の一手はこの作業です。

顧客が迷ってしまう1ページを、安心して選べる1ページへ整えるところから始められます。

まずは既存のサービスページ1つで、対象や条件、根拠を整え、自社の事実を正しく伝えるための見直しから始められます。