AI 検索結果におけるブランドの可視性を測定する方法

9 月 28 日、自分で開発している Windows 用クリップボードマネージャー Beetroot を、4 つの AI サーフェスで 10 個のプロンプトにかけました。どの数字を拾うかによって、その可視性は 0 パーセント（Web アクセスのないモデルすべて）、9 パーセントまたは 13 パーセント（2 つの検索サーフェスでのパネル全体の平均）、あるいは 100 パーセント（Sonar で、AI 機能についての 1 つのプロンプト）になります。4 つとも正しい数字です。AI 検索結果におけるブランドの可視性を測定する方法について最初に理解すべきなのは、この点です。どの数字も「自分たちはどれくらい見えているのか」には答えていません。

可視性の数字が意味を持つのは、それがどのサーフェスから来たのか、どのプロンプトで平均したのか、背後にサンプルがいくつあるのか、何を数えるかをどのルールで決めたのか、がそろっているときだけです。どれかひとつでも欠ければ、見ているのは KPI の格好をした確率変数です。

AI の可視性レポートでは、4 つの用語が同義語のように使われています。可視性（visibility）、メンション（mention）、引用（citation）、回答への採用（answer inclusion）です。以下のデータはこの 4 つを切り離すので、先にそれぞれを定義します。そのあとに、技術チームが実際に回せるワークフローを示します。自分の小さな実行でつかまった間違いも含めてです。

可視性、メンション、引用、回答への採用は、実際には何を意味するのか

3 つは回答ごとに記録する結果で、4 つ目はそこから組み立てる要約です。これらを 1 つの数字にまとめてしまうと、ブランドが名前を挙げられたのか、推薦されたのか、出典として示されたのかを区別できなくなります。

メンション。 生成された回答のテキストにブランド名が現れることです。文字列マッチ（正式名称と、レビュー済みの別名リスト）で、回答ごとに数えます。文脈については何も語りません。「Beetroot and similar indie apps」もメンションですし、「Beetroot は避けるべき」もメンションです。プロンプト自体にブランド名が入っていれば、それに対する回答もすべてメンションになります。

回答への採用。 ブランドが、ユーザーのニーズに対して回答が実際に推薦しているものの一部になっていることです。独立したリスト項目、独立した段落、名指しの推し、といった形です。これは文字列マッチではなく判断であり、たいていは採点者（人間か、監査する前提の別のモデル）が必要です。順位も記録してください。5 件中の 1 位と、末尾の「こちらも一見の価値あり」は別の結果です。

引用。 自分が所有する URL が、出典として回答に付いていることです。アノテーション、脚注、検索を経て組み立てられた回答の中のインラインリンクがこれにあたります。検索を経ずにモデルが記憶から書いたリンクは別のフィールドです（詳しくは後述）。引用はメンションとは独立しています。モデルは出典なしで記憶からブランド名を挙げることもあれば、こちらの比較ページを引用しながら競合を推薦することもあります。

可視性。 全体をまとめた要約です。宣言された回答の集合、つまり固定したサーフェス上で、固定した期間に、固定したプロンプトのパネルを回した回答の中で、ブランドが現れる割合です。これは常にベクトル（メンション率、採用率、引用率、それぞれにサンプル数付き）であって、単一のスコアにはなりません。そして、計算のもとになったパネルなしには存在しません。

この 4 つのさらに上流に 5 つ目の対象があります。ほとんどのツールが隠しているので、あまり測られていません。検索（retrieval）、つまりシステムが回答を書く前に取得したページです。取得されたことと引用されたことは別物で、その差は大きいことがわかりました。

小さなパネル 1 つで何がわかったのか

2026 年 9 月 28 日、1 つの API ゲートウェイ経由で、10 個のプロンプトを 4 つのサーフェスにかけました。8 個はブランド名を含まないプロンプトで、購入を検討している人が実際に聞きそうなものです（「What is the best clipboard manager for Windows?」「What are good alternatives to Ditto clipboard manager?」「Recommend a clipboard manager for Windows that has built-in AI features, like rewriting or translating copied text」）。2 個は製品名を含むエンティティプロンプトです（「Is the Beetroot clipboard manager free and open source? What license does it use?」）。ブランド名なしのプロンプトはサーフェスごとに 10 回ずつ、エンティティプロンプトは 5 回ずつ実行しました。返ってきた回答は 359 件（1 リクエストはレート制限に当たりました）で、実行全体のコストはゲートウェイのクレジットで 3 ドル未満でした。

以下がブランド名なしのプロンプトの結果で、サーフェスごとに 80 件（Sonar は 79 件）です。Web 検索の行には注意点がひとつあります。80 件のうち 9 件では、モデルがそもそも検索しないことを選んだので、「検索が使える」ことと「検索を使った」ことは同じ条件ではありません。

ツールなしの行は、日付を見れば驚くことではありません。Beetroot の公開は 2026 年 2 月です。OpenAI は gpt-5-mini の知識のカットオフを 2024 年 5 月 31 日としていて、ある実行ではモデル自身がそう言いました。そんな製品は「in my training up through mid-2024」（2024 年半ばまでの学習データには）ない、と。モデルの学習データより新しい製品でも、記憶からメンションされることはあります（その仕組みは後のエンティティの節で示します）。ただし、モデルがその製品を実際に知っていることはありえません。この 2 つのモデルでは、Beetroot が現れたのは検索を行うサーフェスだけでした。新しいブランドなら、まずそちらを測るべきだと考えるのはこのためです。

なぜ 1 つのプロンプトが可視性をすべて担っていたのか

すべてのメンションが、製品が本当に差別化されている点に合致した 1 つのプロンプトから来ていたからです。AI 機能についてのプロンプトは、Web 検索ありで 10 件中 7 件、Sonar で 10 件中 10 件のメンションを生みました。ほかの 7 個のブランド名なしプロンプトは、Web 検索ありで 70 件中 0 件、Sonar で 69 件中 0 件でした。

つまり、パネル全体の「9 パーセント」と「13 パーセント」は、データの中にある唯一の構造を隠しています。パネル全体の平均が確率として意味を持つのは、そのパネルの質問の配分のもとでだけで、実際のユーザーがその配分で質問しているという保証はどこにもありません。回答が示しているのは、Beetroot が 20 回中 17 回現れた 1 つの意図と、139 回中 1 度も現れなかった 7 つの意図です。平均はこれらを混ぜ合わせて、どちらのグループの回答にも似ていない数字を作ります。

測定にとっての帰結は 2 つあります。第一に、パネル全体の平均を出す前に、プロンプトごと（または意図のクラスターごと）に報告すること。第二に、パネルの構成そのものが指標だということです。この AI 機能のプロンプトと同じ振る舞いをするプロンプトを 1 つ足せば、見出しの数字はほぼ 2 倍になります。3 つ足せばほぼ 3 倍です。世の中では何も変わっていないのに、です。だからこそ、パネルはコードと同じようにバージョン管理して凍結する必要があります。使っている商用トラッカーにも同じ目を向けてください。そのパネルは、他人が決めた構成です。

競合の側から見ても同じことが言えます。AI 機能のプロンプトでは、Sonar は 10 件すべての回答で Microsoft の PowerToys Advanced Paste を挙げ、Beetroot はそのすべてで 2 番手でした。ほかのすべてのプロンプトを独占している Ditto と CopyQ は、Sonar のこのプロンプトでは 1 度も現れませんでした。カテゴリー全体のシェア・オブ・ボイスで見ればこれは平均に埋もれますが、意図ごとに計算すれば、どの質問を誰が押さえているのかが見えます。

なぜメンションは回答への採用と同じではないのか

文字列マッチは、ブランドが実際には勝ち取っていない回答まで数えてしまうからです。Beetroot をメンションした Web 検索ありの 7 件の回答のうち、6 件は独立した推薦枠を与えていました（順位は 1 位から 4 位まで）。残る 1 件は、ひとまとめの一行に押し込んでいました。「PastePaw (and similar indie apps: Beetroot, Klip, Clipboard Genie, PastePaw)」（PastePaw、および同種のインディーアプリ）。正規表現はこれをメンションとして採点します。読み手はこれを推薦とは呼ばないでしょう。

Sonar は逆のケースでした。10 件中 10 件で採用され、常に名指しの推しとして挙がり、1 位になることは 1 度もありませんでした。言い回しも実行間でほとんど変わりませんでした（「a good alternative」「a strong alternative」「a solid second choice」、いずれも代替候補という位置づけです）。安定した 2 位と不安定な 1 位は別の発見であり、メンション率だけではこの 2 つを区別できません。採用と順位は、メンションとは別に記録してください。

引用率はどれくらいパーサーで決まるのか

同じ回答で率が 2.5 倍動くほどです。3 つの発見があり、どれもモデルそのものではなく、その周辺の仕組みから出てきたものです。

アノテーションとインラインリンク。 Web 検索ありの場合、API は引用を構造化されたアノテーションとして返しますが、一部の回答は出典をテキスト中のプレーンな Markdown リンクとしても含んでいます。アノテーションだけを数えると、メンションのあった 7 件のうち Beetroot の URL を引用していたのは 2 件でした。インラインリンクも数えると 5 件です。同じ回答、同じ日で、パース処理のコード 1 行によって 2.5 倍の差が生まれました。定義を 1 つ選んで書き残し、あとで定義を変えたときに古い回答を採点し直せるよう、生のテキストを保存しておいてください。

パイプラインが黙って捨てる引用。 Sonar の回答には、Beetroot を推薦するたびに [2][6] のような脚注マーカーが付いていましたが、収集スクリプトはそのどれについても出典 URL を記録していませんでした。生のレスポンスを保存していなかったので、あとから同じゲートウェイのルートでもう 1 回リクエストを送り、レスポンス本体をまるごと保存しました。テキストには脚注マーカーがあるのに、レスポンスのどこにも URL は 1 つもありませんでした。Perplexity 自身の API は引用を返しますが、このルートはそれを運んでいませんでした。回答は見るからに引用付きなのに、このサーフェスの引用率は私のデータでは観測できません。収集スクリプトはエラーを 1 つも出さずに指標をまるごと失うことがあります。サーフェスごとに完全な生のレスポンスをいくつか保存し、保存しているつもりのフィールドが本当に入っているか確認してください。

取得されたことは、引用されたことではない。 回答ごとに 1 回として数えると、Web 検索ありの実行はブランド名なしの 80 件の回答で 2,086 の URL を取得し、そのうち 385（アノテーションとインラインリンクの合計）、約 18 パーセントを引用しました。Reddit のスレッドは 80 件のうち 36 件で取得され、12 件で引用されました。つまり「モデルがページを読んだ」ことと「モデルがページを出典として示した」ことは別のイベントです。ある回答では Beetroot 自身のページが取得されていたのに、ブランドはひとまとめの一行に入れられました。別の回答では Beetroot の URL は 1 つも取得されていないのに Beetroot が推薦されていて、それを支えていたのは community.openai.com にある Beetroot についてのフォーラムスレッドでした。引用だけをログに取っていると、どちらのケースも見えません。

もうひとつ罠があります。ツールなしのモデルも URL を出力していました。おおよそ 10 件に 3 件の割合で、しかも一度に複数出すことも多く、取得したものではなく記憶から呼び出したものです。そのうちの 1 つは clipjump.codeplex.com を指していました。Microsoft が何年も前に終了したサービス上のホストです。記憶だけで書かれた回答の中の URL は、リンクについての主張であって引用ではありません。別の列に入れるべきものです。

プロンプトがすでにブランド名を含んでいると何が変わるのか

メンション率は意味を失い（名前はプロンプトに入っています）、問題になるのは、回答が正しいか、間違っているか、回答を控えるか、です。4 つのサーフェスの違いが最もはっきり出たのはここでした。

Beetroot のライセンスを聞くと、2 つの Web サーフェスはどちらも 5 回中 5 回 Apache 2.0 と答え、これは正解でした。開発元を聞くと、どちらも 5 回中 5 回、正しい開発元を挙げました。ツールなしの gpt-5-mini は毎回回答を控えました。ライセンスのプロンプトではどの Beetroot のことかと聞き返し、開発元のプロンプトではその製品を知らないと答えました。正解ではありませんが、より安全な失敗です。ツールなしの Gemini 2.5 Flash は、ライセンスの実行 5 回のうち 4 回で MIT と答え、そのうち 3 回では製品とは無関係なアカウントの GitHub リポジトリにリンクしていました。しかも毎回違うリポジトリです。開発元を聞くと、5 回中 3 回はそんな製品は存在しないと答え、残りの 2 回は間違った開発者を挙げました。

「ブランドがメンションされた」を数えるダッシュボードは、この Gemini の行を完全な可視性として採点します。実際には、間違った出典を添えた自信満々の虚偽であり、ライセンスを確認しようとする購入検討者が読むのはこの回答です。エンティティプロンプトでは、回答が主張していることを短いファクトシート（ライセンス、開発元、価格、プラットフォーム）と照らし合わせて採点し、正解、誤り、回答拒否を 3 つの別々のカウントとして報告してください。「わかりません」と答えるモデルは、間違ったリポジトリを配るモデルよりましな仕事をしています。

この測定を自分で回すにはどうすればよいのか

バージョン管理された入力、生データの保存、再実行できる採点レイヤーを持つ、小さなデータパイプラインとして扱います。技術チームに渡すとしたら、次の形にします。

1. ファクトシートと別名リストを書く。 正式名称、よくある綴り間違い、所有ドメイン（サイト、リポジトリ、ストアの掲載ページ）、そして回答が間違えうる事実を 5 個から 10 個。どちらのファイルもバージョン管理します。

2. 意図ごとにプロンプトのパネルを作る。 実際の需要から作ったブランド名なしのカテゴリープロンプト（検索クエリを質問の形に書き直したもの）、競合の名前を含む比較プロンプト、製品の差別化ポイントごとに少なくとも 1 つのプロンプト、そして別枠のエンティティプロンプト。各プロンプトに意図のタグを付け、エンティティプロンプトは決してメンション率に混ぜないこと。

3. サーフェスを明示的に選ぶ。 最低でも、記憶だけで答えるモデルを 1 つと、検索を行うサーフェスを 1 つ。正確なモデル ID で記録します。API のモデルはコンシューマー向けアプリとは別物です（パーソナライズもチャット履歴もなく、モデルのビルドが違うことも多い）。何を測ったのかを明記してください。

4. 繰り返しサンプリングし、サンプルを時間的に分散させる。 プロンプトごと、サーフェスごとに 10 回が最低ラインです。私のサンプルはすべて 49 分以内に集めたもので、そこまで近接した反復は相関します。上の区間は楽観的なものとして扱い、本番の実行は数日に分散させてください。

5. すべてを生のまま保存する。 回答ごとに 1 レコード。

   text

   run_id, panel_version, prompt_id, intent, surface, model_id, settings,
   timestamp, sample, status, search_fired, answer_text, cited_urls[],
   retrieved_urls[], search_queries[], raw_response

   生のテキストと生のレスポンスは譲れないフィールドです。status と search_fired は、「データなし」を「検索なし」や「リクエスト失敗」と区別するためのものです。このデータを分析している間に、自分の定義が 2 つ変わりました（引用のルールとライセンスのマッチャー）。どちらの変更も採点のやり直しで済み、再実行は要りませんでした。

6. 4 つを別々に採点し、マッチャーを監査する。 メンション（正規表現と別名。ヒットとミスの両方からサンプルを読んで確認します。今回の実行では、AI 機能についての回答のいくつかに出てきた「Ditto」は、クリップボードマネージャーではなく、同じ Ditto という名前の無関係な製品でした）、採用と順位（採点で判断し、モデルが採点するなら一部を手で監査します）、引用（アノテーション、インラインリンク、記憶から呼び出された URL をどう扱うかを書いたルール）、そしてファクトシートに対するエンティティの正確さ。サーフェスが検索結果を公開しているなら、取得から引用への比率も加えます。

7. 意図ごとにベクトルを、区間付きで報告する。 プロンプトまたは意図のクラスターごとに、メンション率、採用率、引用率を、それぞれ n と Wilson 区間付きで出します（どれも回答ごとの yes/no の結果です）。競合のシェアは yes/no の結果ではありません。1 つの回答が複数のブランドを挙げるからです。同じ区間に押し込まず、回答あたりのカウントとして報告してください。パネル全体の平均は最後に、パネルのバージョンを明記して載せます。

8. スケジュールに沿って再実行し、注記を残す。 同じパネル、同じサーフェス、同じ時間帯で。モデルのリリース、パネルのバージョン更新、自分のサイトの変更を時系列上に記録します。数字の上では、モデルの更新とコンテンツの変更は見分けがつかないからです。

ステップ 7 の区間はコード 10 行で書けるので、省く理由にはなりません。

from math import sqrt
 
def wilson(k, n, z=1.96):
    if n == 0:
        raise ValueError("no answers, no estimate")
    p = k / n
    d = 1 + z * z / n
    c = p + z * z / (2 * n)
    m = z * sqrt(p * (1 - p) / n + z * z / (4 * n * n))
    return ((c - m) / d, (c + m) / d)

wilson(0, 80) は 0 から約 4.6 パーセントまでの区間を返します。これが「見えていない」の正直な言い方です。80 件の回答でメンションはゼロ。真の率がおよそ 5 パーセントを超えていたなら、この結果が出ることはまずなかった、ということです。

この規模のパネルでは何がわからないのか

実際のユーザーが何を見ているかはわかりません。実行は API 経由で、コンシューマー向けの ChatGPT、Gemini、Perplexity のアプリではありません。アプリにはパーソナライズ、位置情報、チャット履歴が加わり、モデル自体が違うこともあります。データは 1 日分なので、ドリフトについては何も言えません。対象は 1 つのニッチの 1 つの製品で、しかもその製品は私のものです。だからこそ事実を確認できるのですが、「採用」の採点についてはその点を念頭に置いて読んでください。

一方で、はっきり示しているのは、AI の可視性の数字のどれだけが、ブランドではなく測定上の選択から来ているかです。パネルにどのプロンプトを入れるか、エンティティプロンプトを分けるか、どのサーフェスを数えるか、引用をどうパースするか、ハルシネーションによるメンションを勝ちとして採点するか。どの選択もそれ自体は間違いではありません。間違っているのは、それを明示しないことです。

これは、AI の回答がパブリッシャーのトラフィックに何をもたらしたかを調べたときに見つけたのと同じパターンです。目に見える指標はある方向に動き、それが表しているはずのものは別の方向に動いていました。エージェントのパイプラインについて書いたモデルは止まってくれない依存関係であるという話ともつながります。回答ごとにモデル ID をログに残してください。そうしないと、次のモデルリリースが、コンテンツ戦略の成功や失敗のように見えてしまいます。

パネルは意図的に小さくしています。単一の可視性スコアという考え方を壊すには、これで足りる最小の測定器です。より大規模な調査は、手法と限界を結果と並べて、research にまとめています。