メディアサイトのLLMO実測｜7サイト運用で見えたAI引用の条件

結論から言うと、メディアサイトのLLMO対策で効くのは「AI向けの特別な書き方」ではなく、一次情報の量、記事構造の明快さ、情報の鮮度という、地味な3条件をサイト全体で維持することです。私たちUravationは自社で7つのメディアサイト、合計2,400本以上の記事を実際に運用しながら、AIの回答に自社記事がどう扱われるかを定点観測してきました。この記事は、その運用の中で確認できた傾向と、公式に確認できる事実を切り分けて、メディア運営者が今日から点検できる形に整理したものです。

先に注意点を書いておきます。AI検索の引用は運営側がコントロールできるものではなく、「この施策をやれば引用される」という保証はどこにも存在しません。本記事で扱う「引用の条件」は、公式ドキュメントで確認できる土台条件と、自社運用で繰り返し観測された傾向（仮説）の2階建てです。どちらに属する話かは本文中で毎回明示します。

対象読者は、オウンドメディア・比較メディア・専門メディアを運営する編集責任者、SEO担当者、そしてAI検索時代にメディア投資を続けるべきか判断したい経営者です。LLMO対策の全体像はLLMOとは？AI検索時代に企業サイトが確認すべきことで扱っているので、本記事はメディアサイト特有の論点に絞ります。

メディアサイトのLLMOの定義

メディアサイトのLLMOとは、ChatGPT、Gemini、Perplexity、GoogleのAIによる概要・AIモードなどのAI検索が回答を生成する際に、自社メディアの記事が情報源として正確に理解され、引用候補として扱われる余地を高めるための情報設計です。具体的には、記事単位では一次情報（独自データ・実体験・検証結果）の明示と引用しやすい構造化を、サイト単位では著者情報・運営者情報・専門領域の一貫性と更新の継続を整えます。引用を保証する施策ではなく、AIと読者の両方が「誰が・何を根拠に・いつ書いたか」を確認できる状態を作る取り組みです。

企業サイトのLLMOが「自社がAIに正しく説明されること」を目的とするのに対し、メディアサイトのLLMOは「自社記事がAIの回答の材料として参照されること」を目的とします。守るべき対象が会社情報ではなく記事群そのものである点が、設計上の最大の違いです。

前提の開示：この記事の「実測」とは何か

「実測」という言葉を使う以上、何をどう測ったかを先に開示します。

• 運用対象は自社で企画・執筆・更新まで行っている7つのメディアサイト、記事総数は2,400本以上です。ジャンルはAI活用、補助金、キャリア、地域情報など複数領域にまたがります。
• 観測方法は、AI検索（GeminiのGrounding機能を使った自社計測ツール、およびChatGPT・Perplexityでの手動確認）に対して自社関連クエリ・記事関連クエリを定期的に投げ、回答内で自社ドメインが情報源として扱われるかを記録する定点観測です。この計測の考え方はLLMOの効果測定で詳しく解説しています。
• 本記事では、具体的な引用率・順位・トラフィックの数値は公開しません。AI検索の回答はクエリ・時期・利用者の文脈で変動が大きく、特定時点の数値を一般論として提示するとかえって誤解を生むためです。数値の代わりに「複数サイト・複数時点で繰り返し観測された傾向」だけを、仮説と明示した上で扱います。

つまり本記事の主張の強さは「公式ドキュメントで確認できる事実 ＞ 自社運用で繰り返し観測された傾向（仮説） ＞ 一度きりの観測」の順であり、2番目と3番目を事実のように書くことはしません。

公式に確認できる土台：AI検索はメディア記事をどう扱うか

まず、運営者の観測に依存しない、公式に確認できる範囲を押さえます。

Googleの公式ドキュメントでは、AIによる概要やAIモードに表示されるための特別な追加要件はなく、Google検索にインデックスされスニペット表示の対象になれることが土台とされています。「AIによる概要やAIモードのための特別な最適化は不要」と明記されており、AI専用のマークアップやファイルも要求されていません。同時に、AIモードでは関連する複数のサブトピックへ検索を並行実行する「クエリファンアウト」という手法で、複数の情報源を参照して回答が組み立てられることが説明されています。

これはメディアサイトにとって重要な示唆です。1本の総合的な長文記事だけでなく、サブトピックごとに明確な答えを持つ記事群が、ファンアウトされた個別の検索でそれぞれ拾われる可能性があるということです。トピックを網羅する記事群と内部リンクの設計についてはLLMOにおける内部リンク設計で扱っています。

ChatGPT検索については、OpenAIが検索結果へのサイト表示に使うOAI-SearchBot、モデル学習用のGPTBot、ユーザー操作起点のChatGPT-Userを公開しており、それぞれrobots.txtで個別に制御できます。Perplexityも検索用のPerplexityBotと、ユーザーの質問に答えるためにページへアクセスするPerplexity-Userを分けて公開しています。メディア運営者としては、少なくとも検索系クローラー（OAI-SearchBot、PerplexityBot）が記事ページにアクセスできる状態かをまず確認します。学習利用を避けたい場合はGPTBotだけを制御する、という切り分けが可能です。

もう1つ、メディア運営者が必ず知っておくべき公式情報がGoogleのスパムポリシーです。「大量生成されたコンテンツの不正使用（scaled content abuse）」は、検索ランキング操作を主目的に、ユーザーへの価値を付加せず大量のページを生成する行為と定義されています。重要なのは、AIツールの使用自体が禁止されているのではなく、「価値を付加しない大量生成」が問題とされている点です。AIを使って記事を量産するメディアは、この境界線の内側に留まる設計が前提になります。

実測から見えた仮説：引用された記事に共通していた3条件

ここからは自社7サイトの定点観測で繰り返し確認された傾向です。因果関係を証明したものではなく、あくまで運用上の仮説として読んでください。

条件1：一次情報（自分で確かめた内容）が本文にあること

AIの回答内で自社記事が情報源として扱われたケースを振り返ると、「実際にやってみた結果」「自社で運用して確認した手順」「独自に整理した比較・分類」を含む記事が目立ちました。逆に、他サイトの情報を言い換えただけの解説記事は、同じキーワードで上位表示されていても、AI回答の情報源としては確認しにくい傾向がありました。

これはGoogleが公式に示すE-E-A-Tの方向性とも整合します。Googleの「有用で信頼性の高いコンテンツ」ガイダンスでは、実際に商品やサービスを使用した経験に基づく特別な知識（Experience）や、誰が・どのように・なぜ作ったか（who/how/why）の明示が重視されています。クエリファンアウトで複数情報源が参照されるとき、どこにでも書いてある一般論は他の情報源と交換可能ですが、そのサイトにしかない検証結果や運用記録は交換が利きません。「交換の利かない情報を持つ記事が残りやすい」というのが、私たちの運用仮説の核です。

条件2：結論と定義が切り出せる構造であること

観測の中で情報源として扱われた記事は、記事のどこかに「その一段落だけ抜き出しても意味が通る」定義文・結論文・判断文を持っていることが多いという傾向がありました。本記事の冒頭に定義ブロックを置いているのはこのためです。

構造面で私たちが7サイト共通で実装しているのは次の3点です。

• 記事冒頭の1〜3段落で、検索意図への答えを完結させる
• 「〇〇とは」に答える定義文を、前後の文脈に依存しない独立した段落として書く
• 表・チェックリストの各行を、単語の羅列ではなく引用可能な完結文で書く

構造化データ（FAQやArticleのマークアップ）も整えていますが、Googleの公式見解ではAI機能のための特別なマークアップは不要とされているため、構造化データを「AI引用の必須条件」と考えるのは過大評価です。構造化データの位置づけは構造化データとAI検索の関係で整理しています。

条件3：更新が止まっていないこと（鮮度）

同一記事の観測を時系列で見ると、公開から時間が経ち内容の更新が止まった記事は、AI回答の情報源として確認できる頻度が下がっていく傾向がありました。特にAI関連のように変化が速い領域では、古い仕様・古い料金・古いツール名が本文に残っている記事は、読者にとってもAIにとっても信頼を毀損する要素になります。

私たちの運用では、新規記事の追加だけでなく、既存記事の事実確認と更新を定常業務に組み込んでいます。どの記事から更新すべきかの優先順位付けはAI検索時代のコンテンツ更新で解説しています。

なお、この3条件は独立ではなく掛け算で効く、というのが運用実感です。一次情報があっても構造が悪ければ切り出されにくく、構造が良くても情報が古ければ参照されにくい。どれか1つに全振りするより、3つを一定水準で維持するほうが観測結果は安定していました。

判断表：記事タイプ別のAI検索での扱われ方と投資判断

メディアの限られたリソースをどの記事タイプに配分するかの判断表です。「AI検索での扱われやすさ」は自社観測に基づく仮説評価であり、保証ではありません。

メディアサイトLLMOの実装チェックリスト

7サイト運用で実際に使っている点検項目を、記事単位とサイト単位に分けて示します。

記事単位のチェックリスト

• 冒頭1〜3段落で検索意図への答えが完結している
• 前後の文脈なしで意味が通る定義文・結論文がある
• 「自分で確かめた内容」（検証結果・運用記録・独自整理）が本文に含まれている
• 一般論と自社の見解・仮説が書き分けられている
• 数値・固有名詞・仕様は一次情報源で確認済みで、確認日が管理されている
• 表・リストの各行が引用可能な完結文になっている
• 公開日と最終更新日が表示され、更新時は本文が実際に直っている
• 同一テーマの関連記事へ本文中から内部リンクしている

サイト単位のチェックリスト

• 著者情報ページがあり、記事の署名から専門性・経歴を確認できる
• 運営者情報ページで、誰が何の目的で運営しているメディアかを明示している
• メディアの専門領域が明確で、無関係なジャンルの記事を混ぜていない
• robots.txtで検索系AIクローラー（OAI-SearchBot、PerplexityBot等）の扱いを意図どおりに設定している
• 古い記事の更新・統合・削除の運用ルールがある
• AI回答での自社ドメインの扱われ方を定点観測する手段がある

robots.txtの具体的な設定はrobots.txtのAIクローラー設定で、自社がAIにどう説明されているかの確認手順はAI検索でブランド名を調べた時に確認すべき回答パターンで解説しています。

失敗例：7サイト運用で実際に踏んだ落とし穴

成功パターンよりも失敗のほうが再現性高く学べるので、自社で実際に経験した失敗を4つ共有します。

失敗例1：量産期の記事が資産にならなかった

立ち上げ初期、記事本数を優先して、既存上位記事の再構成に近い記事を量産した時期がありました。これらの記事は検索流入こそ一定量ありましたが、AI回答の情報源として確認できたことはほとんどなく、後から一次情報を足す改修コストが新規執筆と大差ない水準になりました。教訓は「本数目標が品質基準に優先すると、後で全部作り直しになる」です。現在は1本ごとに「この記事にしかない情報は何か」を企画段階で言語化しています。

失敗例2：更新日だけ変えて本文を直さなかった

一時期、更新日の表示だけを新しくして本文の事実確認を省略する運用が混ざったことがあります。結果として、古いツール仕様が本文に残ったまま「最新」を名乗る記事が生まれ、読者からの指摘で発覚しました。鮮度は表示上の日付ではなく本文の中身の問題です。以降、更新時は「何を確認し、何を直したか」を記録する運用に変えました。

失敗例3：AIクローラーをまとめて遮断していた

セキュリティ設定の見直し時に、学習用クローラーと検索用クローラーを区別せず、AI系のUser-Agentを一括で遮断していたサイトがありました。学習利用を避けたいという意図自体は正当ですが、検索用のOAI-SearchBotやPerplexityBotまで遮断すると、AI検索の情報源候補から自ら降りることになります。意図（学習拒否か、検索露出も拒否か）を先に決めてから、クローラー別に設定する必要があります。

失敗例4：定点観測を始めるのが遅れた

観測を始める前の期間については、施策と結果の対応関係を後から検証する手段がありません。「あの改修が効いたのか」を語れないのは、社内説得の場面で大きなハンデになりました。AI回答での扱われ方の観測は、施策を始める前から記録しておくことを推奨します。AI検索経由の流入計測はGA4でのAI検索流入の計測で手順を解説しています。

メディア運営者が今期やるべきことの優先順位

短期の日数プランではなく、状態目標で書きます。

1. 観測の開始：主要テーマのクエリ群でAI回答での自社の扱われ方を記録し始める。施策より先に観測です。
2. ピラー記事の定義ブロック整備：各テーマの中核記事に、切り出し可能な定義文・結論文を入れる。
3. 一次情報記事の企画ラインを常設化：「自分で確かめた内容」を含む記事を、量産記事とは別の企画枠として維持する。
4. 既存記事の更新・統合・削除ルールの明文化：更新は本文の事実確認を伴うこと、価値を足せない記事は統合・削除の対象とすることを決める。
5. 著者・運営者情報の点検：署名から専門性が確認できる状態にする。

よくある質問

記事数が多いほどAIに引用されやすくなりますか？

記事数そのものが引用を増やすという根拠は、公式情報にも自社観測にもありません。むしろ価値を付加しない量産はGoogleのスパムポリシー（scaled content abuse）の境界リスクを高めます。自社観測では、本数よりも「交換の利かない一次情報を持つ記事の比率」のほうが、AI回答での扱われ方の傾向と対応しているように見えます（仮説）。

AIに記事を読ませないよう遮断すべきですか、開放すべきですか？

意図によります。モデル学習に使われたくないだけなら、学習用クローラー（GPTBot等）のみを遮断し、検索用クローラー（OAI-SearchBot、PerplexityBot等）は許可する設定が可能です。検索露出も含めて拒否するなら一括遮断ですが、その場合AI検索の情報源候補からは外れます。メディアとして流入や認知を得たいなら、検索用クローラーは許可するのが基本方針になります。

llms.txtを設置すればメディア記事は引用されやすくなりますか？

llms.txtは提案段階の仕様であり、主要AI検索サービスが引用判断に使うことを公式に確約した仕組みではありません。設置コストは低いので試す価値はありますが、効果は仮説として扱うべきです。詳細はllms.txtとはで解説しています。

AIが記事を要約してしまうなら、メディア運営はもう割に合わないのでは？

ゼロクリックの増加はメディアにとって実在するリスクで、楽観できる話ではありません。ただし自社運用の実感では、AI回答で完結する一般論記事と、AI回答の先で読まれる一次情報記事の間で、価値の差が開いています。「AIが要約できる情報」の生産をやめ、「AIが要約しても出典として残る情報」に投資を寄せるのが、現時点で私たちが取っている方針です。

まとめ：メディアサイトのLLMOは「編集方針の問題」である

メディアサイトのLLMOは、技術施策の皮をかぶった編集方針の問題です。公式に確認できる土台（インデックス可能であること、検索用クローラーへの許可、基本的なSEO品質）を満たした先で差がつくのは、一次情報・構造・鮮度という編集の意思決定でした。少なくとも自社7サイト・2,400本以上の運用の中で、小手先のAI向けテクニックが継続的な差を生んだ観測はありません。

自社メディアが現時点でAIにどう扱われているかを把握できていない場合は、まず観測から始めてください。自分で確認する手順はLLMO診断チェックリストにまとめています。観測結果の解釈や、記事群のどこから直すべきかの優先順位付けに外部の目が必要な場合は、AI検索診断で相談を受け付けています。