LLMO計測の始め方｜サンプリング設計とKPI 6項目を実装ガイド付きで解説

LLMO計測の始め方｜サンプリング設計とKPI 6項目を実装ガイド付きで解説

この記事の結論: LLMOを計測するにはクエリ設計→サンプリング→KPI集計という3段階の構造が必要で、引用率・言及率など6KPIを月次レポートに落とし込むことで改善PDCAが回せる。

最終更新日: 2026-05-09

はじめに

AI検索が普及する中、「自社サイトがChatGPTやPerplexityに引用されているか」を定量的に把握したいSEO担当者が増えている。しかしLLMO計測は従来のGSCレポートとは設計思想が異なるため、何をどの頻度で計測すればよいか迷うケースが多い。

本記事では、計測フローを6ステップで体系化したうえで、サンプリング設計の数学的根拠と6つのKPIの計算式・目安値を実装ガイド付きで解説する。ツールの比較はllmo-measurement-tools、KPI設計の総論はkpi-measurementに譲り、本記事は「実際に手を動かして計測を始める手順」にフォーカスする。

LLMOの全体像を把握してから読みたい場合はllmo-complete-guideを先に参照してほしい。

---

LLMO計測の全体フロー（6ステップ）

ステップ1｜クエリ設計

計測の精度はクエリリストの品質で決まる。自社サービスに関連するキーワードを「情報収集系」「比較検討系」「課題解決系」の3カテゴリに分類し、各カテゴリから代表クエリを5〜15本選ぶ。ロングテールキーワードは引用率が高い傾向があるため優先的に含める。

落とし穴は「自社名+製品名」だけで完結させることだ。競合が引用されているが自社が引用されていないクエリを発見するには、業界課題を問う汎用クエリが必要になる。

ステップ2｜サンプリング設計

同一クエリを1回だけ投げて結果を記録する方法では、LLMの確率的な出力揺らぎを吸収できない。1クエリあたり複数回サンプリングする設計が必要で、詳細は次のセクションで解説する。

落とし穴は計測タイミングの固定だ。同じ時刻帯に計測すると特定モデルのキャッシュ状態を拾い続けるリスクがある。曜日と時間帯を分散させることを推奨する。

ステップ3｜記録

APIまたはブラウザ操作でクエリを投げ、レスポンスの全文・引用URL・ソース表示順をスプレッドシートまたはDBに保存する。最低限記録すべきフィールドは「クエリ文字列 / 計測日時 / AIエンジン名 / 引用URL / ブランド言及有無 / ソース順位」の6項目だ。

後から集計クエリを変更できるよう、生ログは必ず保持する。加工済みサマリーだけ残すと再集計が不可能になる。

ステップ4｜KPI集計

記録した生ログから6KPIを算出する。計算式は後述のセクションで定義する。週次でトレンドを確認し、月次でステークホルダー向けレポートを生成する粒度が現実的だ。

ステップ5｜改善

KPIの低下が見られたクエリについて原因を分類する。引用率低下ならファクト密度の高い記事構造への改修、言及率低下ならブランドメンション施策が有効なことが多い。構造化データの追加やllms.txtの整備も改善候補に含める。

ステップ6｜再計測

改善施行から2〜4週間後に同一クエリセットで再計測し、KPIの変化を確認する。変化が誤差範囲内か統計的に有意かを判断するために、次セクションのサンプリング設計が重要になる。

---

サンプリング設計｜最低サンプル数の決め方

なぜ複数サンプルが必要か

大規模言語モデルは同一プロンプトに対して確率的に異なる出力を返す。引用率のような比率指標を推定する場合、真の引用率 p を許容誤差 e の範囲で95%信頼区間に収めるには以下の簡易式を使う。

n ≥ (1.96)² × p(1-p) / e²

引用率が50%（最も分散が大きい想定）・許容誤差±15%の条件では n ≈ 43 となる。許容誤差±20%では n ≈ 24 だ。これを踏まえると以下の目安が導出される。

• 最低10サンプル: 許容誤差±30%前後。傾向把握には使えるが精度は低い
• 推奨30サンプル: 許容誤差±18%前後。月次レポートの判断根拠として許容範囲
• 高精度50サンプル: 許容誤差±14%前後。経営報告や外部公表に耐えるレベル

KPI種別別の推奨サンプル数と頻度

予算・工数が限られる初期フェーズは、最重要クエリ5〜10本に絞り推奨30サンプルを確保する方が、全クエリ最低10サンプルより信頼性が高い。

---

KPI 6項目｜各指標の式と良い値

(1) 引用率（Citation Rate）

何を測るか: 計測クエリのうち、自社URLがAI回答のソースとして引用された割合。
計算式: 引用された回数 ÷ 総サンプル数 × 100 [%]
良い値の目安: 業界平均は不明だが、自社計測の中で月次トレンドが右肩上がりであることを基準とする。競合比較で自社が上位なら良好と判断してよい。
悪い時の対策: 対象クエリに対応するページのファクト密度・見出し構造・構造化データ（JSON-LD）を見直す。

(2) 言及率（Brand Mention Rate）

何を測るか: 引用URLとしては登場しないが、ブランド名・製品名が回答本文中に言及された割合。引用なし言及はLLMO固有の指標でGSCには存在しない。
計算式: ブランド言及ありの回数 ÷ 総サンプル数 × 100 [%]
良い値の目安: 引用率より言及率が常に高くなるのが正常な状態。言及率が引用率を下回る場合、ブランド認知よりURLソース評価が高い特殊なクエリが多い可能性がある。
悪い時の対策: Wikipediaや主要メディアへのブランドメンション獲得施策、AEO視点のQ&Aコンテンツ強化を検討する。

(3) ソース順位（Source Rank）

何を測るか: 引用されたとき、ソースリストの何番目に表示されるかの平均値。Perplexityなど可視化されるエンジンで特に重要。
計算式: 引用された全サンプルのソース順位の平均値
良い値の目安: 平均3位以内を目標とする。1位獲得率も補助指標として記録する。
悪い時の対策: 上位引用されているページのコンテンツ構造・E-E-A-T要素を分析し、自社ページに移植する。

(4) クエリカバレッジ（Query Coverage）

何を測るか: 計測クエリリスト全体のうち、少なくとも1回引用されたクエリの割合。引用率が「1クエリ内の頻度」を見るのに対し、こちらは「何種類のクエリをカバーできているか」を見る。
計算式: 1回以上引用が確認されたユニーククエリ数 ÷ 計測クエリ総数 × 100 [%]
良い値の目安: 50%以上を初期目標とし、中期的に70%以上を目指す。
悪い時の対策: カバレッジゼロのクエリを抽出し、対応コンテンツが存在するか確認する。ないなら新規作成、あるなら構造・ファクト密度の改修が先決だ。

(5) 競合比率（Competitor Share）

何を測るか: 同一クエリで引用されるドメインのうち、自社ドメインが占める割合（競合ドメインとの相対比較）。
計算式: 自社引用回数 ÷ (自社引用回数 + 監視対象競合の引用回数合計) × 100 [%]
良い値の目安: 競合数によるが、競合2〜3社を監視対象とした場合に自社シェア33%以上を基準とする。
悪い時の対策: 引用率の高い競合ページを分析し、ピラー・クラスターモデルやトピカルオーソリティの観点でコンテンツ網羅性を比較する。

(6) 改善応答率（Improvement Response Rate）

何を測るか: コンテンツ改修・構造化データ追加などの施策を打った後に、対象クエリの引用率が改善した割合。施策効果を定量化するための後行指標。
計算式: 施策後に引用率が上昇したクエリ数 ÷ 施策対象クエリ数 × 100 [%]
良い値の目安: 50%以上なら施策の方向性が正しいと判断できる。30%以下の場合は仮説の見直しが必要だ。
悪い時の対策: 施策内容と引用率変化のログを突き合わせ、有効なパターンと無効なパターンを分類する。

---

社内で月次レポートを作る最短手順

スプレッドシートテンプレの構成

手動計測の初期フェーズは、以下4タブ構成のスプレッドシートで十分運用できる。

1. クエリマスタ: slug / クエリ文字列 / カテゴリ / 重要度（高中低） / 担当URL
2. 生ログ: 計測日時 / クエリslug / エンジン名 / 引用URL / 言及有無 / ソース順位
3. KPIサマリー: クエリslugごとに6KPIを週次集計した時系列テーブル
4. 月次ダッシュボード: KPIサマリーからPIVOTで生成した可視化シート

週次と月次の粒度の使い分け

週次確認は引用率と言及率のトレンドだけを見る。急落があれば即座に原因調査に入る。全KPIを週次で追うと工数が膨らみ継続できなくなるため、モニタリング対象は2指標に絞る。

月次レポートでは6KPI全てをステークホルダーに報告する。前月比・前四半期比の2軸で変化を示し、施策との因果関係を記述する。クエリカバレッジと競合比率はトレンドより絶対値の水準が重要なため、業界ベンチマークへの言及を添えると説得力が増す。

自動化のロードマップ

---

有料ツールに切り替えるサイン

手動運用から有料ツール導入を検討するタイミングは以下の通りだ。

• サンプル数が追えなくなった: 推奨30サンプル×クエリ30本以上を手動で維持するのが困難になった
• 競合監視が必要になった: 競合比率を正確に計測するには複数ドメインの同時モニタリングが必要で、手動では対応が難しい
• 経営報告の精度要求が上がった: 統計的有意性の検定や信頼区間の提示を求められ始めた
• エンジンが複数になった: ChatGPT・Perplexity・Geminiの3エンジンを同時計測するとサンプル数が3倍になり工数が急増する
• リアルタイムアラートが必要になった: 引用率の急落を即日検知して対応したい要件が生まれた

profoundなどの専用ツールはこれらのニーズに対応しているが、導入前に手動計測で計測設計を確立しておくと、ツール移行後のKPI定義が安定する。

---

よくある質問

Q. 計測するAIエンジンはどれを優先すべきですか?
A. 自社のターゲット読者が最も使っているエンジンを優先する。BtoBならPerplexityとChatGPT、BtoCならChatGPTとGeminiから始めるケースが多い。最初は1エンジンに絞り、計測フローを確立してから拡張する方が挫折しにくい。

Q. 同じクエリを30回投げると費用がかさみますか?
A. API経由の場合、GPT-4o miniクラスなら1クエリ30回で数円〜数十円程度だ。ブラウザ手動操作で無料枠を使う方法もあるが、再現性が下がる。初期はコスト・精度のバランスで10〜20サンプルから始めてよい。

Q. 引用率が上がらないのに言及率が高い状態はどう解釈すればよいですか?
A. ブランドとしては認識されているが、URLをソースとして提示する根拠をAIが持てていない状態と解釈できる。ファクト密度の高いコンテンツ構造の強化と構造化データ整備が先決だ。

Q. KPIの「良い値」に業界標準はありますか?
A. 2026年時点でLLMO計測の業界標準ベンチマークは存在しない。自社の時系列トレンドと競合比率による相対評価が現実的な判断基準となる。

Q. llms.txtを整備すると引用率は上がりますか?
A. llms.txtはクローラーにコンテンツ構造を伝える効果があるが、引用率への直接的な影響は限定的という報告が多い。ただしコンテンツの発見性向上には寄与するため、llms-txt-guideを参考に整備しておくことを推奨する。

---

関連用語

• LLMO — LLM最適化の基本概念
• AEO — AI Engineの回答最適化手法
• ブランドメンション — 言及率KPIに直結する概念
• クエリ — 計測設計の出発点
• RAG — AIがソースを引用する仕組みの背景
• ハルシネーション — 計測精度を下げるAI出力の誤り

---

関連記事

• LLMO完全ガイド — LLMOの全体像と戦略設計
• LLMOとSEOの違いを徹底解説 — 従来SEOとの計測観点の差異
• LLMO計測ツール比較 — 有料・無料ツールの機能比較
• KPI設計の総論 — KPI設計の上流フレームワーク
• AI検索最適化ガイド — LLMO施策の実践まとめ
• ピラー・クラスターモデル — コンテンツ網羅性を高める構造設計