LLMOツールの「検索あり・検索なし」は何が違う？RAG発火率と引用の読み方

LLMOツールの結果を読むときは、Web検索を使う設定、実際に検索した記録、回答に付いた引用URLを分けて確認します。「検索が有効だから必ず自社ページを読んだ」「リンクがないから検索していない」とは限りません。計測条件が違う結果を一つにまとめると、改善の判断を誤ることがあります。

本記事は、計測画面にある検索発火率や言及率を、どのように実務へつなげるかを整理するものです。以下のチェック表や運用例は、担当者が確認漏れを減らすための提案です。特定の質問で必ず検索や引用が起きるという予測ではありません。

検索の設定・実行・引用は別々に記録する

最初に区別したいのは、検索できる状態にしたことと、実際に検索されたことです。さらに検索が行われても、すべての取得先が回答の出典として表示されるとは限りません。利用中のサービスがどの情報を返すかを確認して、観測できる範囲で記録します。

たとえばGoogleのGemini APIでは、Google検索ツールを有効にすると、モデルが必要性を判断して検索する流れが説明されています。検索クエリや引用に関する情報も返されます。ただし、これはそのAPIの説明であり、すべてのAIサービスや一般向け画面が同じ仕組み・表示になるという意味ではありません。Googleの検索グラウンディング解説

この区分を設けると、「検索ありなのに引用がない」という相談を整理できます。設定の問題なのか、取得情報が不足しているのか、単に自社URLが選ばれなかったのかを、一段ずつ確認できるからです。内部の処理が見えない場合は、推測を事実として補わず「確認できない」と残します。

検索なしの回答にも、ブランド名やURLのような文字列が含まれる場合があります。それを見ただけで、その時点のページを取得したと判断しないことが大切です。現在の仕様や料金を確認したいときは、回答に書かれた内容と公式ページを別途照合してください。

RAG発火率を読む前に分母を確かめる

RAGは外部の情報を取り出して回答の材料に使う考え方で、Web検索だけを指す言葉ではありません。一方、LLMOツールの画面ではWeb検索の実行を「RAG発火」と呼ぶことがあります。名称だけで比較せず、そのツールが何を観測しているかを定義から確認します。

記録表には、指標名とともに分子・分母・対象AI・期間を書きます。「検索発火率60%」だけでは、検索が可能な回答のうちの割合か、全回答のうちの割合かが分かりません。検索結果面を対象外にしている集計と、含めた集計を横並びで評価することも避けます。

説明用の仮例として、検索の実行を判定できた回答が20件あり、そのうち12件に検索記録があるなら、判定可能な回答に対する割合は60%です。別に判定不能が5件あった場合は「12/20、判定不能5件」と記載します。この仮例のルールを、利用中のツールの実際の算出式だと決めつけないでください。

検索発火率の上昇だけで、ブランドの評価が上がったとはいえません。質問の内容や実行方式が変わった影響もあり得ます。まず質問群と設定の変更履歴を確認し、その後に回答内容や引用先を読みます。比率を改善目標にする前に、その変化で何を判断するのかを明確にしましょう。

定期計測とオンデマンド計測を直接混ぜない

LLMOチェキの公開されている計測方法では、定期の複数回計測は初回のみ検索付き、2回目以降は検索なしで言及を計測すると説明されています。オンデマンドの10回計測は全回が検索付きです。仕様の基準日は2026年9月7日で、本記事では9月20日に確認しています。LLMOチェキの計測方法

このように実行方式が違う場合、同じ質問でも同じ条件の標本としては扱えません。定期計測の値と、手動で実施した検索付き計測の値が異なっても、直ちに改善や悪化を意味するわけではありません。比較表に実行方式を一列追加するだけで、誤った説明を減らせます。

「昨日の定期計測では出なかったが、今日の手動計測では出た」という結果は、調査のきっかけとして使えます。ただし、施策の前後比較として採用するには条件の整理が必要です。再実行の回数を増やす前に、比較可能な記録かどうかを確認してください。

検索・言及・引用を組み合わせて次の調査先を決める

回答を点検する目的は、良い数字だけを集めることではありません。自社がどの場面で候補になり、読者がどの情報へ導かれるかを理解するためです。検索の状態が確認できる場合は、言及と引用を組み合わせて調査先を選びます。

自社の引用がなくても、信頼できる第三者ページから正しく紹介されている場合があります。逆に公式ページへリンクされていても、回答が条件を取り違えていることがあります。URLの有無を品質の代わりにせず、回答の具体的な説明まで確認するのが実務上の要点です。

検索なしの回答に自社が登場しない場合、短期間のページ更新だけで結果が変わると期待し過ぎないようにします。観測結果からモデル内部の学習状況までは分かりません。現在の公式情報を整える作業と、同じ条件で回答を観察する作業を分けて続けます。

計測条件を点検する5ステップ

図：目的を決める、設定を確認、実行を記録、条件別に比較、修正して再確認の5ステップ。

1. 目的を決める

調べたいことを、日々の言及の変化、最新情報の説明、引用先の確認などから一つ選びます。目的に応じて必要な検索条件と保存項目を決め、比較したい期間と対象の質問を明記してください。

たとえば価格改定後の説明を確認するなら、回答に新しい価格があるかだけでなく、その価格の契約条件と参照先を確認します。一方、一般的な比較質問で候補に挙がるかを追う場合は、質問を固定して長期に観察する設計が必要になります。

2. 設定を確認する

利用中のツールで、対象AI、検索設定、定期・手動の実行方式、繰り返し回数を確認します。公開仕様と実画面で分からない項目は不明として記録し、異なる方式を同じ比較群に入れないでください。

画面に検索の切り替えがなくても、提供側の実行方法が定められていることがあります。設定できる範囲と、提供側に依存する範囲を区別します。変更した場合は変更日を残し、旧条件の結果と新条件の結果が混在する期間に印を付けます。

3. 実行を記録する

質問原文、対象AI、日時、実行方式、取得できた検索記録、回答原文、引用URLを保存します。検索が確認できない場合と、検索しなかったと確認できる場合を分け、記録から判定までたどれるようにしてください。

集計値だけを転記すると、数値が変わった理由を後で調べにくくなります。全件の精査が難しくても、代表的な回答や変化が大きい質問は原文へ戻れるようにします。リンク切れや権限不足で参照できない場合は、その状態も記録に含めます。

4. 条件別に比較する

同じ質問と実行条件の結果をまとめ、言及・引用・検索の状態をそれぞれ比較します。条件が異なるデータは別の欄に置き、分子と分母、判定不能件数を添えて、数値の意味が読み取れる表にしてください。

比較期間の途中でAIや質問を追加した場合、合計値の変化には構成の変化が含まれます。以前からある質問群の変化と、新しく追加した質問群の結果を分けて確認します。同じ質問が増減しただけで、露出の改善と説明しないようにします。

5. 修正して再確認する

回答で不足・誤解が見つかった箇所を公式ページの修正候補にし、修正内容と日時を記録します。再確認では比較に使った条件を維持し、変化が見られても他の要因を点検してから評価してください。

更新直後の一回の回答だけで完了にせず、次の確認日と判断担当者を決めます。引用先が変わったのか、説明だけが変わったのか、依然として確認できないのかを区別します。必要なら対象ページの公開状態や検索での取得状況も別途確認します。

チームで使える計測条件の記録表

記録は細かくし過ぎると続かなくなります。最初は次の項目を一行にまとめ、元の回答へリンクする形で十分です。数値の集計担当者と記事の編集担当者が、同じ回答を見ながら会話できる状態を目指します。

一つの回答に複数の引用がある場合は、どの記述に対応する出典なのかを確認します。対応が表示されないなら、URLの一覧と回答の主張を別々に保存して、根拠の一致は未確認とします。見た目だけで、最初のリンクがすべての主張の根拠だと解釈しないことが重要です。

担当者が交代しても判断を再現できるよう、採用した定義の出典と確認日を添えます。ツール側の仕様が変わったときは表の項目を見直しますが、過去の記録まで新しい定義に見せかけて書き換えず、変更前後の境目を残しておきましょう。

条件の混在で見え方が変わる架空例

料金ページを改修したチームが、前週の定期計測と今週の手動計測を比べたとします。前週は20回中4回で言及、今週は10回中5回で言及されたとすると、割合は20%と50%です。しかし、検索方式も回数も異なるなら、この差をそのままページ改修の成果として報告できません。この数値は説明用の仮例です。

担当者が最初にすることは、好ましい結果だけを再実行して増やすことではなく、前週と今週の記録を二つの条件群へ分けることです。どちらが誤りというわけではありません。それぞれ別の条件で観測した結果として保存し、同じ条件での比較を追加できるかを検討します。追加実行にも費用がある場合は、確認の目的と必要量を先に決めます。

再確認の条件をそろえても、観測した差がページ修正だけで起きたとは限りません。同じ期間に競合の更新やAI側の変更があった可能性もあります。実務の報告では「修正後にこの説明を確認した」と観測事実を述べ、原因の推定は別に記載します。因果関係を検証する設計がない状態で、売上効果やモデル内部の変化まで結び付けないようにします。

もし検索付きの回答だけで新しい条件が説明され、検索なしでは旧条件が残るなら、その違い自体が点検対象になります。公式ページの記載は正しいか、別の公式ページに旧条件が残っていないか、引用された第三者情報はいつのものかを確認します。検索条件ごとに調査の出発点を分けることで、単なる平均値からは見えない問題を整理できます。

レポートへ添える短い説明文の作り方

関係者に結果を共有する際は、「どの質問を、どのAIで、どの方式で、いつ確認したか」を一文で先に示します。その後に、言及の件数、引用の状態、回答で確認した説明を続けます。検索の状態が不明なら、説明文にも不明と書きます。グラフの脚注だけに条件を隠すより、結論の近くに置く方が読み違いを防げます。

たとえば「料金条件の確認を目的に、固定質問を同じ手動方式で観測。対象回答で新料金の説明を確認したが、旧条件が残る回答もあった。次に料金の適用範囲の記述を点検する」といった報告にできます。必要な件数や対象AIを実測値で追記し、今回確認していない条件へ結論を広げないようにします。

報告前の確認として、計画した回数と成功した回数が混ざっていないか、全出典のURL数を自社の引用数として扱っていないか、別の期間の指標を一つの成果として並べていないかを点検します。説明が長くなる場合は、結論を短く保ち、条件表と原文への参照を付けます。読みやすさと検証可能性を両立させるための整理です。

LLMOツール選びでは数値の説明まで確認する

比較検討では、対応AIの数だけでなく、検索条件を説明できるか、原文と引用へ戻れるか、異なる実行方式を区別できるかを確認します。出力したレポートにもその情報が含まれると、社内報告や委託先とのやり取りがスムーズになります。

LLMOツール比較から候補を絞る際は、本記事の記録表を試用時の確認項目として使えます。LLMOチェキについても、公開されている計測方法と実際の画面を照合し、自社が評価したい条件に合うかを確認してください。

Web検索の状態を把握することは、改善の優先順位を考えるための材料です。検索が起きるように質問を不自然に書き換えて数値だけを高めるのではなく、見込み客が実際に知りたい問いを残します。その上で、読者に必要な情報をページ上で明確に示すことが、継続的な改善の土台になります。