LLMO 総合ガイド ― AI 検索に引用される技術を、30ヶ月分の計測から組み立てる
ある日、私は自分の AI エージェントのログを眺めていて、ちょっとした違和感に気づきました。
エージェントが情報を取りに行く先が、Google ではなかったのです。Brave Search でした。ChatGPT は Bing を、Perplexity は自前のインデックスを叩いていました。私が 12 年かけて最適化してきた検索エンジンと、私の AI が実際に見ている検索エンジンが、まったく別の建物だったわけです。
SEO の家を綺麗に飾りつけている間に、AI は隣の家に住み着いていました。
LLMO ―― Large Language Model Optimization は、SEO の延長ではなく、SEO の隣に並んで立つ、もうひとつの別の領域です。本ガイドは、私がこの 30 ヶ月間に書き溜めた検証記事を、8 つの章に整理した地図です。各章は深掘り記事へのリンクで構成されています。90 秒で見出しだけ追うこともできますし、半日かけて全リンクを巡ることもできます。
1. なぜ LLMO は「AI 向け SEO」ではないのか
LLMO は「ChatGPT 用 SEO」ではありません。問題そのものが別物です。
SEO が前提にしているのは、25 年の研鑽を積んだ、辛抱強い司書(Googlebot)です。LLMO が前提にしているのは、急ぎ足の一般教養人 ―― RAG パイプラインがあなたのページを引っ張り上げ、3 段落だけ拾い読みし、たった 1 トークン分の文脈で「引用するか、言い換えるか、無視するか」を決める LLM です。
この導線には扉が 3 つあります。SEO のアドバイスは最初の扉までしかカバーしていません。3 つの扉を整理したのが LLMO の 3 つの経路 ― SEO が壊れた日 です。Google で 1 位を取っていても AI に存在を認知されない、という現象は、この 3 扉モデルで素直に説明できます。経路が違うのですから、計測指標も施策も別物になります。
2. AI クローラーが本当に読んでいるもの
私が最も多く目撃した「お金のかかる勘違い」は、React で SPA を組んでクライアントレンダリングのまま公開し、AI ボットも JavaScript を実行してくれるはず、と信じ込んでいるケースです。
実行してくれません。30 日かけて 5 種類の AI クローラーをサーバーログから抽出し、それぞれが何を取得しているかを観察した結果は 5 つの AI クローラーが 30 日間にサーバーログに残したもの にまとめてあります。useEffect の後にしか存在しないコンテンツは、引用判断をする側のボットにとっては、存在しないコンテンツです。
「来てくれる」ボットは、来てくれるなりにそれぞれ別のルールで動きます。robots.txt を 30 日観察した robots.txt の AI クローラー指定 ― 30 日見たら 3 つしか守っていなかった は、Disallow を書けば従ってもらえる、という前提がどこまで通用するかの実測です。
そして、ボットが「ノックするかどうか」自体を決める入り口の役割を担いつつあるのが llms.txt です。最小実装の組み方は LLMO 最小実装 ― llms.txt と JSON-LD を 30 分でリリースする に、公開されている 30 ファイルを監査して見えてきたアンチパターンは llms.txt を 30 ファイル監査して見つけた 5 つのアンチパターン にまとめました。パターンはすでに形成されつつあります。歳の取り方が綺麗なものと、すぐ風化しそうなものが、もう見え始めています。
3. JSON-LD は、今のところ一番安く効くレバー
構造化データは、私が試した LLMO 施策の中で、投資回収が最速だった手段です。
JSON-LD 11 種類のうち、AI に引用されたのは 3 種類だけだった では、Article / Person / Book / FAQPage / BreadcrumbList など 11 種類を実装し、その後 1 四半期かけて引用に現れたかどうかを追跡しました。3 種類が「効く」を体現し、残りはほぼ礼儀正しい背景ノイズでした。
ただし、構造化データは「ページのランクを押し上げる」ためのものではなく、「ページの中の特定の段落を、AI 回答の中に持ち上げる」ためのものです。この区別は抽象論に聞こえますが、私が Passage Rank Beats Page Rank ― AI 引用は段落単位で動く で計測したとおり、構造化された 1 段落のほうが、最強の被リンクより重く働くケースが珍しくありません。
なぜ被リンクの効きが弱まるのか、という点は JSON-LD 11 種類が LLM の理解にどう作用したか で別角度から検討しました。「リンクの数」から「文脈の中で名前が呼ばれる回数」へ ―― 通貨そのものが入れ替わりつつある、というのが私の暫定的な結論です。
4. コンテンツ設計 ― 3 つの原則だけが生き残った
「AI 向けに書く方法」というアドバイスは、抽象的すぎて使えないか、具体的すぎて転用できないかのどちらかに偏りがちです。30 ヶ月の試行錯誤を経て、私の手元には 3 つだけが残りました。
先に答えを出す。 Microsoft が提唱した LLM 向けコンテンツ設計の 3 原則を、自サイトで実装してみた結果が LLM 向けコンテンツ設計 ― Microsoft の 3 原則を自サイトで試した です。答えを冒頭 120 字以内に置くだけで、引用率の地形が変わりました。
段落単位で完結させる。 LLM はあなたの記事を読んでいません。リトリーバが拾った「チャンク」だけを読んでいます。だから各 H2 は、前後の H2 から切り離されても単独で意味が通る必要があります。これは設計の問題であって、執筆の問題ではありません。
鮮度を保つ。 AI 検索は鮮度を、SEO よりはるかに強く重み付けします。私が観測した citation half-life は、多くの編集者が計画している投稿頻度よりかなり短かったです。具体的な数字は、次章の計測方法の中で扱います。
5. 計測 ―― まだ標準が存在しない領域での KPI 設計
計測できないものは改善できない、というのは正しいのですが、AI 引用計測はまだアナログ計器の時代にいます。だから私は方法論ごと公開しながら進めています。代案は「肩をすくめる」だけだからです。
私が日常的に追っている 3 つの計測手法を LLMO 計測 ― 3 つの方法と、それぞれの限界 に整理しました。Playwright を CI に組み込んで、AI クローラーから見える HTML を継続的に監視する仕組みは Playwright で AI 引用テストを CI に組み込む に書いた構成で動いています。
サードパーティ製の citation tracker を契約する前に、ぜひ 7 つの AI 引用トラッカーが、同じサイトに対して 7 つの違う数字を返した を読んでください。同一サイトに対して桁が違う結果が出ました。先に内製の小さなログを持つほうが、結果的に判断速度が上がります。
著者エンティティそのものも、立派な計測対象です。著者エンティティと AI 引用 ― 個人名を「ノード」として認識させる で扱った観点を、自サイトに適用した監査が 著者エンティティ自己監査 ― 自分のサイトで何が抜けているか です。著者がエンティティとして認識されているか否かは、思っているより早く citation 数に効いてきます。
6. AI エンジンごとに挙動が違う、という当たり前の話
AI 検索を「ひとつのカテゴリ」として扱うのは、私が初期に犯した最も大きな戦術的ミスです。Perplexity、ChatGPT Search、Gemini、Web 接続した Claude、Brave の LLM Context API は、それぞれ別のプラットフォームとして扱う必要があります。
5 つのエンジンが私のブログをどう引用したか、その差を見たのが 5 つの AI エンジンが私のブログを引用したのは、31 本中 3 本だけだった です。引用された記事に共通する形があり、その形は再現します。
Google の AI Overviews だけを切り出して観察したのが AI Overviews に出る 4 つの条件 ― 30 日見たら、効いたのは 1 つだけ です。4 つの仮説のうち、再現性があったのは 1 つだけでした。残り 3 つは、たまたま結果が伴った別要因に乗っていた、というのが私の見立てです。
ローカルビジネス領域は、これから一番大きく動く市場だと考えています。ローカルビジネスの LLMO ― llms.txt より先に GBP は、店舗業の方向けに優先順位を整理した記事です。llms.txt は二の矢で構いません。一の矢は Google Business Profile です。
GraphRAG 系の話も、AI 検索の挙動と密接に絡みます。GraphRAG 2026 ― RDF か Property Graph か、3 つの問いで決める は技術選定の話ですが、引用される側のサイトとして「どちらが採用されると自分が拾われやすいか」を考える材料にもなります。
7. ケーススタディ ― 数字で語れる事例だけを選んだ
LLMO で一番難しいのは「結果を見せる」ことです。多くのケーススタディは雰囲気で書かれていて、再現性を確かめる材料になりません。私は、自分で再現できる事例だけを記事化するようにしています。
TRM が引用率 83.37% に達した ― LLMO Pillars を個人ブログで検証する は、引用率の上限を測った記事です。83.37% という数字は、間違っていたら恥ずかしいだけの大きさですが、間違っていなかった場合は再現を試す価値がある大きさでもあります。
8. ここから先、どこを読むか
読者の置かれている状況によって、最短の経路が変わります。
- まだ何も実装していない方 ―― 第 2 章 → 第 3 章 → 第 4 章 の順で読むことをお勧めします。私がもう一度ゼロから始めるなら、この順番で実装します。
- 実装はしたが数字が動かない方 ―― 第 5 章を飛ばし読みしてください。動かない理由のほとんどは、計測の組み方にあります。施策のせいではありません。
- 多言語展開を考えている方 ―― 当ガイドでは多言語の事例は英語版に詳しいので、合わせて /blog/llmo もご覧ください。英語圏の天井は思っているより低く、非英語圏の床は多くのサイトが思っているより高いです。
長尺で全体像を押さえたい方には、以下の 2 冊を用意しています。
- LLMO 実践ガイド ―― 6 ヶ月分の監査を 200 ページに圧縮した、本格版です。
- LLMO クイックスタート ―― 1 つのチームが 1 週末で実装できる範囲に絞った、90 分版です。
店舗業・ローカルビジネス向けの実務書として、AI 時代の店長のための MEO × LLMO も併せてご参照ください。
本ピラーは、新しい検証記事が出るたびに加筆します。リンク先の個別記事は加筆しませんので、内容が古く感じたら、各記事のタイムスタンプを確認してください。地図は書き換えますが、領土のほうも、まだ動いています。
この記事は役に立ちましたか？