LLMOのやり方7手順｜AI検索に引用される記事の作り方【2026】

結論から言うと、LLMO（AI検索に引用されるための最適化）のやり方は、「AIクローラーを通す」「答えを冒頭に置く」「AIが要約で代替できない固有情報を1つ入れる」「出典と更新日を機械可読にする」の4点に集約されます。特別なマークアップや裏技はありません。Google は公式ドキュメントで「AI Overviews や AI モードに表示されるための追加要件も、特別な最適化も必要ありません」「新しい機械可読ファイルや AI 用テキストファイル、マークアップを作る必要はなく、追加すべき特別な schema.org 構造化データもありません」と明言しています（Google 検索セントラル）。

この記事では、その前提のうえで「AI に引用される側に回るために、実際に何をどの順番で実装するか」を7手順で書きます。あわせて、Mihata が mihata.jp 自身に実装している構成と、GA4 で計測している実測値（90日でAIアシスタント経由は全体の約1.3%）も公開します。LLMO は憶測が多い領域なので、「公式に確認できること」と「まだ仮説であること」を記事内で区別しました。

なお、すでに AI Overviews によって流入が落ちてしまった場合の立て直し方は、AI Overviewsでアクセスが減ったときの検索流入を守る対策で守りの視点からまとめています。本記事は逆に「引用される側の作り方」＝攻め手に絞ります。

LLMOとは何か（そしてSEOと何が違わないのか）

LLMO（Large Language Model Optimization）は、ChatGPT・Google の AI Overviews / AI モード・Copilot・Perplexity といった生成AIの回答の中で、自社サイトが引用・言及されることを狙う取り組みの総称です。GEO（Generative Engine Optimization）とほぼ同義で使われます。

実務上の違いはゴールの置き方だけです。従来のSEOのゴールが「検索結果でクリックされること」だったのに対し、LLMO のゴールは「AIの回答の中に、自社名とリンクが根拠として残ること」になります。順位ではなく引用（citation）が成果物です。

一方で、手段は驚くほど従来のSEOと重なります。AI検索の回答は、原則としてクロール・インデックスされたWebページを根拠（グラウンディング）にして生成されるためです。したがって「インデックスされていない」「クローラーを弾いている」「中身が他所と同じ」ページは、そもそも引用の候補に入りません。LLMO を「SEOとは別の新種の施策」と考えると、たいてい費用対効果を外します。

やり方①：AIクローラーを通す（ここだけは通常のSEOと別軸）

LLMO で唯一、通常のSEO設定と独立しているのが robots.txt のAIクローラー制御です。「AI学習を避けたい」という理由で一括ブロックしていると、AI検索の回答からも消えます。各社の公式ドキュメントを読むと、用途ごとにボットが分かれていることが分かります。

OpenAI は公式ドキュメントで「OAI-SearchBot をオプトアウトしたサイトは ChatGPT の検索回答に表示されない（ナビゲーションリンクとしては出うる）」「各設定は互いに独立している」「robots.txt の更新が反映されるまで約24時間かかることがある」と説明しています（OpenAI Docs）。Anthropic も ClaudeBot / Claude-User / Claude-SearchBot を用途別に分け、robots.txt で個別に制御できると案内しています（Anthropic ヘルプセンター）。Google の Google-Extended についても、同社は「Google-Extended は Google 検索へのサイトの掲載に影響せず、Google 検索のランキング シグナルとしても使用されない」と明記しています（Google 検索セントラル）。

実務の判断軸はシンプルです。「学習には使われたくないが、AI検索経由の来訪はほしい」なら、学習用ボット（GPTBot・ClaudeBot・Google-Extended）だけを拒否し、検索用ボット（OAI-SearchBot・Claude-SearchBot）は通す。この切り分けをせず一律 Disallow にしているサイトは、現場で今もよく見ます。まず自社の robots.txt を開いて確認するのが、LLMO の最初の一歩です。

やり方②：冒頭に「答え」を置き、一問一答の粒度で書く

生成AIはページ全体を丸ごと引用しません。質問に対応する段落単位で抜き出します。したがって、記事の構造は「1見出し＝1つの問い」「1段落＝1つの主張」に揃えるほど拾われやすくなります。

具体的には次の3点です。第一に、リード直後にメインの問いへの結論を2〜4文で置く。第二に、H2・H3を「〜とは」「〜のやり方」「〜はいくらか」のように読者の質問文へ寄せる。第三に、前の段落を読まないと意味が通らない書き方（「これについては」「前述のとおり」の多用）を避ける。切り出されても独立して成立する段落は、そのまま引用の単位になります。

記事末尾のFAQも同じ理屈で有効です。FAQは Google のリッチリザルト表示が2023年に一般サイト向けには終了していますが、「質問文と短い答え」というAIにとって最も扱いやすい形式であることに変わりはありません。可視のFAQとして読者にも役立つ形で置くのが現実的です。

やり方③：AIが要約で代替できない固有情報を、1記事に1つ入れる

どこにでも書いてある一般論は、AIにとって「あなたのページを引用する理由」になりません。逆に、自社しか持っていない数値・比較・手順は、AIが自力で生成できないため引用元として指名されます。

入れるべき固有情報の候補は、実測値（自社の計測データ・検証結果）、自作の比較表や判断基準、実務での失敗パターン、価格や納期の具体レンジ、自社プロダクトの画面などです。この記事でいえば、後述する Mihata 自身の GA4 実測値がそれにあたります。

学術研究でも同じ方向の結果が出ています。GEO（Generative Engine Optimization）の研究（KDD 2024採択、GEO-bench による評価）は、引用・統計・出典の追加といった編集で生成エンジン内の可視性が最大40%向上したと報告しています。ただし同論文は「手法の効果はドメインによって異なり、領域ごとの最適化が必要」とも明記しています（arXiv:2311.09735）。「統計を足せば必ず40%増える」という読み方は誤りです。

やり方④：数値には必ず出典リンクを、本文中に添える

AIが引用しやすい最小単位は「数値＋出典」のペアです。数値だけを書いて出典がないと、AI側でも真偽を確かめられないため採用されにくく、逆に人間の読者からの信頼も得られません。

実務のルールとしては、（1）一次情報（公式ドキュメント・公的統計・原論文）を優先する、（2）出典は記事末尾にまとめるだけでなく本文の該当箇所にリンクする、（3）調査対象・期間・母数を添える、の3つで十分です。AIが生成した下書きをそのまま出すと数値の出所が空になりがちなので、AI記事のファクトチェックの手順とセットで運用してください。

やり方⑤：構造化データは「特別なもの」ではなく「本文と一致するもの」を入れる

ここは誤解が多いところです。前述のとおり Google は「AI検索のために追加すべき特別な schema.org 構造化データはない」と明言しています。一方で同社は、構造化データを「可視コンテンツの曖昧さを解消する」ために使うとも説明しており、構造化データの内容がページ上の見える情報と一致していることを求めています。

つまり LLMO における構造化データの役割は、加点アイテムではなく「誤解防止」です。実装するなら Article（著者・公開日・更新日）、BreadcrumbList（サイト内の位置）、Organization（発信主体）、FAQPage（本文のFAQと一致するもの）といった基本形で足ります。本文に無い内容をFAQ構造化データに書くのはガイドライン違反なので、本文とマークアップは必ず同一ソースから生成する設計にしておくのが安全です。

やり方⑥：更新日と鮮度を、機械が読める形で伝える

AI検索は「いつの情報か」を強く見ます。Microsoft は Bing Webmaster Blog で「サイトマップの lastmod は、Bing が再クロール・再インデックスするURLの優先度を決める重要なシグナルであり続ける」「Bing のようなAI搭載検索エンジンでは、鮮度シグナルが、更新が検索結果やAI生成の回答へ反映される速さに直接影響する」と述べ、IndexNow による即時通知との併用を推奨しています（Bing Webmaster Blog）。

ここで実務的な落とし穴があります。CMSの「最終更新日時」は、内部リンクの追加やタグ付けのような中身を変えていない機械的な更新でも動いてしまうことです。それを更新日として出すと、鮮度シグナルの信頼性が落ちます。Mihata では「本文を実際に書き換えたときだけ進む日付」を別フィールドで持ち、表示上の更新日と構造化データの dateModified の両方を必ずその同一フィールドから出しています。

やり方⑦：エンティティ（社名・サービス名）の表記を1つに固定する

AIは文章を実体（エンティティ）に紐づけて理解します。社名やサービス名の表記が揺れていると、同一の主体として扱われず、言及が分散します。表記ゆれの典型は、英字と日本語の併用、法人格の有無、旧サービス名の残存、担当者名義の不統一です。

対策は地味です。（1）社名・サービス名の正式表記を1つに決める、（2）サイト内の全ページ・全記事・SNS・登記情報・Google ビジネス プロフィールで同じ表記に揃える、（3）会社概要ページを1枚の正典にして、各所からそこへリンクする。Mihata の場合は「Mihata」という表記を唯一の正としており、記事本文でも表記を混在させない運用にしています。

Mihataが自社サイトで実装していることと、90日の実測値

一般論だけだと机上の話になるので、mihata.jp 自身の構成と数字を出します。

実装（すべてこのサイトで稼働中）

• FAQは単一ソース：記事本文に書いたFAQブロックから、可視のアコーディオン表示と FAQPage の構造化データを同時生成する。本文とマークアップがずれる余地を構造的に消している
• Article / BreadcrumbList / Organization の構造化データを全コラム記事に出力
• 更新日は「本文を書き換えたときだけ進む専用フィールド」から出力し、表示と dateModified を一致させる
• 出典は記事内リンク＋末尾の出典一覧の二段構えで明示
• llms.txt を設置（サービス一覧と無料ツールの要約）。ただし後述のとおり、これは効果が実証された施策ではない

GA4実測：AIアシスタント経由は全体の約1.3%（2026年5月8日〜8月5日）

直近90日の mihata.jp のセッションは合計37,136。うち生成AIサービスを参照元とするセッションは471で、全体の約1.3%でした。内訳は ChatGPT系（openai / chatgpt.com）が300、Copilot が109、Gemini が34、Perplexity が25、NotebookLM が3です。同期間の Google 検索経由は24,322なので、桁が2つ違います。

ここから読み取れることは3つあります。第一に、2026年時点の中小規模サイトにとって、AI検索経由の流入は「検索の代替」ではなくまだ数%の追加チャネルだということ。「LLMOをやればSEOが不要になる」は現時点では誇張です。第二に、質は悪くありません。同期間のエンゲージメント率は chatgpt.com 経由が45.8%（平均セッション時間312秒）で、google 経由の43.2%（同330秒）と大差ない水準でした（母数が小さいため参考値）。第三に、AI経由の着地ページは比較・一覧・具体的な製品名を含む記事に偏りました（上位は「AIプレゼン資料作成ツール」「iPhoneの常時表示時計」「ChatGPT・Claude・Geminiの比較」の各記事）。抽象的な入門記事ではなく、具体名と比較軸を持つ記事が引用されやすい傾向が、自社データでも確認できています。

実証されていること／まだ仮説なこと（ここを混ぜない）

LLMO は情報の鮮度が高く、断定的な言説が先行しやすい領域です。発注や社内提案の判断材料として、確度で仕分けておきます。

提案書や見積書で「LLMO対策」と書かれていたら、この表の左列のどれを指しているのかを必ず確認してください。実体が「robots.txt の見直しと記事構成の改善」であれば妥当ですが、独自ファイルの設置だけで高額な場合は、根拠を尋ねる価値があります。

効果の測り方：GSCの生成AIレポートとGA4の参照元

LLMO は「やったつもり」になりやすいので、測定手段を先に用意します。2026年時点で使える公式の計測手段は2つです。

1つ目は Search Console の生成AIパフォーマンスレポートです。Google は2026年6月にこのレポートを発表し、AI Overviews と AI モードにおける表示回数を確認できるようにしました。ヘルプによれば、これは通常のパフォーマンスレポート（Web検索）に含まれるデータの内数で、一部のサイト所有者への段階的な提供から始まっています（Search Console ヘルプ）。自社アカウントにまだ出ていなくても異常ではありません。

2つ目は GA4 の参照元です。chatgpt.com / openai.com / perplexity.ai / copilot.microsoft.com / gemini.google.com などをまとめて1つのセグメント（またはチャネルグループ）として定義し、月次でセッション数とエンゲージメントを見ます。前述のとおり最初は全体の数%以下から始まるので、絶対数ではなく「前月比」と「どの記事が引用されているか」を見るのが実用的です。指標設計そのものはAIブログの効果測定と分析の手順と同じ枠組みで運用できます。

やってはいけないこと

• AI向けだけに別のコンテンツを出し分ける：ユーザーとクローラーに異なる内容を見せる行為は、Google のスパムポリシー上のクローキングに該当します
• 量産だけのAI記事でページ数を増やす：独自の価値がない大量生成は「スケールされたコンテンツの不正使用」として対策対象です。作り方はAIライティングでSEO記事を書く方法を参照してください
• 出典のない数値を書く：AIにも人にも採用されず、誤情報を広げるリスクだけが残ります
• 学習用ボットのブロックと検索用ボットのブロックを混同する：意図せず AI検索から消えます
• AI特有の紋切り型の言い回しを残したまま公開する：不自然な文章は独自性を感じさせにくく、引用元として選ばれにくくなります。直し方はAIの文章を人間らしく書く方法｜AI感が出る7つの症状と直し方にまとめています

まとめ：LLMOは「引用される形に整える」作業

やることを1行に圧縮すると、「AI検索用クローラーを通したうえで、答えを冒頭に置き、自社しか出せない数値と出典を、更新日と一緒に機械可読な形で置く」です。裏技はなく、公式ドキュメントを読むほど「良い記事を、AIが切り出しやすい構造で出す」という当たり前に収束します。

そして2026年時点では、AI経由の流入はまだ全体の数%です。既存の検索流入を守りながら（守りの手順はAI Overviewsでアクセスが減ったときの対策にまとめています）、引用される資産を積み増していく、という二正面の運用が現実解になります。

ここまでの7手順は、社内で回せるならそれが一番です。ただ「記事を書き続ける人手がない」「構造化データや更新日の設計まで手が回らない」という声も多くいただきます。Mihata では、この記事で書いた構造（結論先出し・出典明記・FAQ・構造化データ・更新日運用）をそのまま組み込んだ記事を継続的に作るサービスも行っています。記事の途中で恐縮ですが、よろしければ下のご案内も合わせてご覧いただけたら嬉しいです。ご相談だけでも歓迎です。