LLMO対策の効果、どうやって測っていますか——観測プロンプトの3階層設計と、10エンジン計測の現実

LLMO（LLM Optimization）の方法論は周知だ。構造化データ、E-E-A-T、llms.txt の配置——やることは明確だ。だが次の質問には誰も答えない。「で、効果あったんですか？」。SEO なら共通言語として「順位計測ツール」があったが、AI 検索にはそれがない。だから施策は施策のまま、クライアントには「たぶん効いてます」としか言えない。その空白を埋めるため、実際の計測方法を 3 階層のプロンプト設計で提案したのがこの記事だ。

従来の「順位」を AI 検索に適用できない理由は 3 つある。出力が毎回違う、「1 位」という概念がない、質問文が無限にある———だから測定対象は「言及率」になる。代表的な質問を複数エンジンに投げて、自社が言及されたかを記録する。その推移を追う。これはサンプリング調査だから、「どういうサンプルを取るか」が計測の質そのものを決める。

プロンプト設計は 3 階層だ。Tier 1 は「指名系」——ブランド名を含む質問で、正確性を測る。ここが最優先だ。誤情報が届いている状態は露出ゼロより深刻だからだ。Tier 2 は「発見系」——ブランド名なしのカテゴリ・課題ベース質問で、本当に見つかるか測る。LLMO の本丸だが改善は難しく指標も動かない。だから地域や業種で条件を絞らないと意味がない。Tier 3 は「差別化訴求系」——自社の強みを条件に含める。ここが受注に最も近く、数字が動きやすい。配分は Tier 1、2、3 をそれぞれ最低 2 本ずつ、計 8 本程度から始めるのが現実的だ。

ここからが現実だ。この計測を複数エンジンで毎月やろうとすると、システムは破綻する。Google AI Overviews に公式 API がない。Web 版と API 版で結果が異なる。スクレイピングも規約違反のリスクが高い。無料枠の利用回数制限もある。完全な自動化は不可能で、採った構成は「マルチ WebView で各エンジンを並べて、プロンプト投入と回答読み取りは人間が手動、記録と集計だけを機械化」という至って非効率なものだ。ただし、計測の信頼性を取るなら、ここが正解だ。理想と現実のギャップは大きいが、この「実装不可能な部分がある」という事実そのものが、LLMO 戦略の立案に必須の情報なのだ。