AI検索対策の効果、測れていますか
LLMO/GEOを言及率で可視化する実務の全手順

構造化データを入れた。E-E-A-Tを意識して著者情報を整えた。一問一答形式の見出しに書き換えた。llms.txt も設置した——。

AI検索対策（LLMO / GEO / AEO）として、ここまでやったとします。ではひとつ、質問させてください。

それで、効果はあったのでしょうか。

やり方を説明した記事はもう十分にあります。しかし「やった結果をどう測るか」を具体的に書いたものは、探してもほとんど見つかりません。従来のSEOには検索順位という共通のものさしがありましたが、AI検索にはそれがない。だから施策が施策のまま終わり、事業者の方にも「たぶん効いています」としか言えない——そんな状態が広がっています。

私はもともと金融機関のシステム基盤を担当し、「測れないものは管理できない」という考え方を前提に仕事をしてきました。その視点で、自社ブランドのAI検索での露出を毎月計測するなかで固めてきた測定の型を、この記事で公開します。

なぜ「順位」ではなく「言及率」を測るのか

まず前提の整理です。従来のSEOで測っていた検索順位は、AI検索ではそのまま使えません。理由は3つあります。

1. 出力が毎回違う
同じ質問を同じエンジンに2回投げても、返ってくる文章は違います。順位のような一意の値が、そもそも存在しません。

2. 「1位」という概念がない
AIの回答に自社が登場するか・しないか。登場するとしたら、どういう文脈で触れられるか。これは順序の問題ではなく、「含まれるか否か」と「その質」の問題です。

3. 質問文が無限にある
「AI検索対策 会社」というキーワードに順位をつける、という発想が成立しません。ユーザーは自然な文章で尋ねるので、キーワードではなく「質問のパターン」を代表させる必要があります。

したがって、測定対象はこうなります。

順位計測がキーワード単位の「点」の測定だったのに対し、これはサンプリング調査です。だからこそ「どういうサンプルを取るか」——つまりプロンプト設計——が、測定の質そのものを決めます。ここが最初の山場です。

観測プロンプトは「3階層」で設計する

思いついた質問を適当に並べても、意味のあるデータにはなりません。私は次の3階層でプロンプトセットを組んでいます。

Tier 1: 指名系──「正しく説明されているか」を測る

ブランド名を直接含む質問です。

• 株式会社◯◯とはどんな会社ですか？
• ◯◯のサービス内容と料金体系を教えてください。
• ◯◯はどんな技術に強い会社ですか？

これは露出を測る質問ではありません。すでに名前を知っている人がAIに尋ねたとき、正しい情報が返ってくるかを測ります。

軽視されがちですが、私は優先度が最も高いと考えています。ここが崩れていると、他のすべてが無意味になるからです。実際に測ってみると、事業内容が古いまま説明される、サービス名が微妙に違う、同名の別会社と混同されている——といったことが普通に起きます。指名検索してくれた見込み客に誤った情報が届いている状態は、露出がゼロであることよりも深刻です。

そして、ここは直せます。自社サイトの記述を整えれば、改善が数字として観測できる。最も費用対効果の高い領域です。

Tier 2: 発見系──「そもそも見つかるか」を測る

ブランド名を一切含まない、カテゴリや課題ベースの質問です。

• ◯◯県で△△に強い制作会社を教えてください。
• □□で困っているのですが、どこに相談すればいいですか？
• △△を外注する場合の相場と、依頼先の選び方を教えてください。

LLMOの本丸はここです。そして同時に、最も改善が難しく、最も動きにくい指標でもあります。

重要なのは、この階層に期待値を持ちすぎないことです。中小規模の事業者が、全国区の広い質問で言及される確率は、当初きわめて低いのが現実です。だからこそ、地域・業種・課題で条件を絞った質問を必ず混ぜます。「Webサイト制作会社」ではなく「◯◯市で△△向けのWebサイト制作」。数字が動く粒度でなければ、指標として機能しません。

Tier 3: 差別化訴求系──「選ばれる文脈で出るか」を測る

自社の強みを条件として含めた質問です。

• △△に対応できる制作会社を、条件つきで探しています。
• □□と◯◯を両方頼める会社はありますか？
• 小規模事業者でも導入しやすい△△のサービスを教えてください。

Tier 2 が「知られているか」を測るなら、Tier 3 は「比較検討のテーブルに乗るか」を測ります。実務上、いちばん受注に近いのはこの階層です。しかもTier 2より数字が動きやすい。ニッチな条件ほど、AIが挙げる候補の総数が少なくなるためです。

配分と本数の目安

私は8本から始めました。内訳は Tier 1 が2本、Tier 2 が3本、Tier 3 が3本です。

本数を絞る理由は、運用の持続性にあります（この作業は思っているより何倍も重い、という話は後半でします）。ただし、各Tierを最低2本にするのは譲れません。1本だと言及率が0%か100%しか取らず、傾向として読めなくなるからです。

そして、プロンプトは固定します。途中で文言を変えると、時系列の比較が壊れます。追加は可・変更は不可。これは運用ルールとして明文化しておくべきです。

記録するのは「言及の有無」だけでは足りない

プロンプトを投げたら、最低限これらを記録します。

• 実行日時 / エンジン名 / プロンプトID
• 言及されたか（0 or 1）
• 文脈（推奨として挙がったのか、単なる列挙の一部か、否定的な文脈か）
• 回答からの引用（該当箇所の原文）
• 自社サイトが出典としてリンクされたか

見落とされがちなのが、最後の2つです。

引用原文を残しておくと、あとから「AIはうちの何を根拠に説明しているのか」が分かります。これが改善の最大のヒントになります。自社サイトの特定ページの文言がそのまま出てくることもあれば、まったく別のディレクトリサイトの古い情報を引いていることもあります。後者だと分かれば、打つ手は「自社サイトの改善」ではなく「その外部情報の訂正」に変わります。打ち手の方向そのものが変わるので、ここを記録するかどうかは決定的です。

出典リンクの有無も、言及の有無とは別の軸で追う価値があります。名前だけ挙がるのと、リンクつきで挙がるのとでは、実際の流入への寄与がまったく違うからです。

ここからが本題：これを複数エンジンでやると何が起きるか

設計の話は以上です。ここまでは、正直それほど難しくありません。

問題は運用です。「では主要エンジン全部で毎月測りましょう」となった瞬間に、この作業は破綻します。ここから先は、実際にやってみた人が必ずぶつかる現実の話です。

自動化できるエンジン、できないエンジン

エンジンごとに、プログラムからの取得可否は大きく異なります。おおまかに3つに分かれます。

この表で決定的なのが、2行目です。

Google AI Overviews には公式APIが存在しません。

もっとも多くの人に見られているAI回答が、もっとも機械的に取得できない。しかもこれは一時的な状況ではありません。Googleが検索結果そのものの機械的な取得を規約で禁じている以上、構造的にそうなっています。つまりAI検索の計測は、どれだけ自動化を進めても、最後に必ず手作業が残ります。

「APIがある」も額面通りではない

さらに厄介なのは、公式APIがあるエンジンでも、それが計測に使えるとは限らない点です。

APIで叩いているのは、多くの場合、Webサービスとして提供されているものと同一の挙動ではありません。Web版はユーザーの文脈や独自の検索パイプラインを通した結果を返しますが、APIは素のモデル、あるいは別系統の検索機能を通した結果を返します。同じ質問を投げても、返ってくるものが違うのです。

計測の目的が「実際にユーザーが目にする回答に自社が出るか」である以上、APIの結果でWeb版を代用すると、測っているものがずれてしまいます。ここは自動化の便利さと、測定の妥当性のトレードオフです。私は妥当性を取りました。

スクレイピングという誘惑

「では、ブラウザを自動操作すればいいのでは」と、誰もが一度は考えます。実際、技術的には可能です。

私はやめました。理由は単純で、各AIサービスの利用規約に抵触するリスクが高いからです。多くのサービスが、自動化されたアクセスやスクレイピングを明示的に禁じています。事業者の方に提供するサービスのインフラを、規約違反の上に建てるのは、事業リスクとして割に合いません。アカウント停止で計測が止まるだけでなく、それを商材にしていた場合には責任問題にもなります。

結果として、私が採った構成はこうです。

• アプリ内に複数のWebViewを持ち、各エンジンを並べて表示する
• プロンプトの投入と回答の読み取りは、人間が手動で行う
• 記録・集計・レポート生成だけをアプリが担当する

自動化したのは「面倒な部分」ではなく、「機械にやらせても問題のない部分」だけ、ということです。

無料枠という地味な壁

もうひとつ、実運用ではじめて効いてくるのが、利用回数の上限です。

主要な対話型AIの無料プランには、日次や週次で利用回数の制限があります。プロンプト8本 × 複数エンジンを1日でこなそうとすると、途中で上限に当たって作業が中断されます。翌日に持ち越すと、今度は「同じ日に測っていないデータ」が混ざります。

対処は2択です。有料プランを契約するか、測定を複数日に分割することを前提に運用設計するか。前者はエンジンの数だけ月額費用が積み上がり、後者はデータの厳密性が落ちます。どちらにせよ、「全エンジン網羅」は無料では成立しない、という結論になります。

現実的な月次運用の設計

以上を踏まえた、私の現在の運用ルールです。ここはそのまま真似していただける部分です。

頻度は月1回にする。週次は運用が持ちません。またAI側の学習・インデックス更新のサイクルを考えると、週次で測っても差分がノイズに埋もれます。

測定日はまとめる。同一の対象について、全エンジン・全プロンプトを可能な限り同じ日に消化します。エンジン間の比較を成立させるためです。

Tier別に集計する。全体の言及率を1つの数字で出すと、意味が薄れます。「指名系90%・発見系0%」と「全部まとめて30%」とでは、打つべき手がまったく違うからです。

分母を必ず併記する。Tier 1 が2本しかないのに「50%」とだけ書くと、実態は「2本中1本」なのに過剰な精度に見えます。サンプル数の少ない指標は、率と分母をセットで出します。

報告時は階層名を言い換える。Tier 1 / 2 / 3 のままでは伝わりません。「指名認知」「新規発見」「強み訴求」のように、ビジネス上の意味が分かる言葉に変換します。

よくある質問

まとめ

• AI検索の効果測定は、順位ではなく言及率のサンプリング調査。プロンプト設計が測定の質を決める
• プロンプトは指名系 / 発見系 / 差別化訴求系の3階層で組み、各階層最低2本、合計8本程度から始める。一度決めたら文言は変えない
• 記録は言及の有無だけでなく、文脈・引用原文・出典リンクの有無まで。打ち手の方向がここで決まる
• Google AI Overviews に公式APIはなく、完全自動化は構造的に不可能。APIがあるエンジンもWeb版と挙動が異なるため、計測の妥当性を優先するなら手動が残る
• スクレイピングは規約リスクが高く、事業の土台にはできない
• 無料枠の上限があるため、全エンジン網羅には有料プラン契約か複数日運用のどちらかが必要

「AI検索対策をやった」で終わらせず、数字で語れるようにするための最小構成は、ここまでです。プロンプトを8本決めて、スプレッドシートに記録欄を作れば、今日から始められます。

正直にお伝えすると、この作業は思っている3倍は重いです。1社あたり8プロンプト × 10エンジンで80回、それを毎月。回答を読んで文脈を判定し、引用を切り出し、記録する——。私はこれをきちんと回すために、専用ツールを自作することになりました。

自社のAI検索での見え方が気になる方へ

「自社サイトがAI検索でどう見えているか気になるが、この運用を自前で回すのは現実的でない」——そうお感じの方に向けて、Penbit Lab では月次のAI言及率レポートをサービスとして提供しています。

まずは指名系の質問で、自社がAIにどう説明されているかだけでも、一度確認してみてください。誤った情報が出ているケースは、本当に珍しくありません。そして指名系は、最も直しやすい領域でもあります。

あわせて、Webサイトの土台そのものに関心のある方は、こちらの記事もご覧ください。

• WordPressのセキュリティが不安な方へ｜乗っ取り被害が繰り返される本当の理由と根本対策
• WordPressの表示速度が遅い本当の理由と、根本的な改善策
• CDNとは何か｜サイトが「速く・落ちにくく・安全」になる仕組み
• LAMP構成とJamstack、中小企業のサイトはどちらを選ぶべきか