技術チームのための AI 検索における可視性の測定フレームワーク

359 件の回答で Beetroot の AI 検索結果での可視性を測定したとき、同じ製品がサーフェスとプロンプト次第で 0、9、13、100 パーセントになり、8 個のプロンプトのうち 1 つがブランド名なしのメンションをすべて担っていました。あの記事は、1 回の測定を正しく行うための話です。この記事はその次の話です。誰かが 1 か月後にパネルをもう一度回し、2 つの数字を並べたときに何が起きるのか。

主張は狭く、多くのダッシュボードにとっては居心地の悪いものだと思います。AI 検索の可視性について報告される変化のほとんどは、測定の仕方が生んだ見かけ上のものです。プロンプトのパネルが変わったか、サンプルが小さすぎて差が見えなかったか、背後のモデルが変わったのに誰も記録していなかったか、です。パネルのバージョン、サンプル数、モデルの記録なしで出される可視性の数字は、誰にも検証できません。それを出したチーム自身にもです。

以下は、この測定を定期的なプログラムとして回すための設計です。対象は、パイプラインを作り、トレンドラインについて説明を求められる人たち、つまり収集を担うエンジニアリングと、定義と統計を担う分析チームです。メンション、引用、回答への採用の定義と、1 日で回せるワークフローは対になる記事にあります。ここでは、時間を追って追跡することで要件が増える箇所でだけ、それらを再び取り上げます。フレームワークの対象は 4 つ、クエリ、メンション、引用、競合で、その下にすべてに共通するサンプリングのルールがあります。限界は終盤で扱います。こうして作られたレポートを渡されたら、真っ先に読むべきなのはそこです。

なぜ SEO のダッシュボードを流用できないのか

観測の単位が変わったからです。検索結果ページもパーソナライズや位置情報によって変わりますが、クエリごとに 1 日 1 回確認すれば測定として十分通用する程度には安定していて、順位トラッカーは順位を保存できます。アシスタントの回答は毎回新しく生成されます。言い回しも、挙げられるブランドの一覧も、引用される出典も、同じプロンプトを続けて実行するたびに変わりえます。アシスタントが先に Web を検索する場合は、検索のステップ自体がばらつきを加えます。

だから、順位は率になります。1 回の確認は多数の実行になります。「3 位です」は「20 回中 7 回現れ、95% 区間はおよそ 18 から 57 パーセント」になります。誰もスライドに載せたくない数字ですが、2 回目の実行を経ても通用するのはこの形だけです。

もう 1 つの違いはクリックです。SEO のレポートにもセッションを伴わないインプレッションはありますが、成果の大半は最終的にアナリティクスに届きます。アシスタントの回答のかなりの部分は、ユーザーが満足してそのまま去ることで終わります。パブリッシャーについて品質のパラドックスで追ったのが、この力学です。測定にとっては、送られてこないかもしれないトラフィックを待つのではなく、回答そのものを観測する必要がある、ということです。

実際には何回実行すればよいのか

直感よりも多くです。そして重要なのは、変化を検出できるかどうかという問いで、これは区間を 1 つ得るより難しい問題です。ここでの区間はすべて、二項比率の Wilson スコア区間です。50 パーセント前後の単一の率なら、10 回でおよそ 24 から 76 パーセント、30 回で 33 から 67、100 回で 40 から 60 になります。

しかしレポートは 2 つの期間を比べます。2 つの率の差は、どちらの率よりもノイズが大きくなります。有意水準 5 パーセントの両側検定、検出力 80 パーセントで、ベースラインが 50 パーセント前後の場合、確実に検出できる最小の変化はおよそ次のとおりです。

これらの数字は実行が互いに独立していることを前提にしていますが、実行は完全には独立していません。同じ日の同じプロンプトの実行は、検索インデックス、キャッシュ、その週のモデルの状態を共有しています。すべてのプロンプトとすべての実行を 1 つの大きな二項分布にまとめると、区間は精密に見えて、実際には狭すぎるものになります。役に立つ習慣が 3 つあります。期間内で実行を複数の日に分散させること。パネル全体の不確実性を計算するときはプロンプトを単位として扱うこと（実行ではなくプロンプトをリサンプリングするブートストラップが簡単な方法です）。そして期間どうしを、同じプロンプトについての対応のあるデータとして比較することです。

対になる記事のパネルを見ると、これがどれほど早く効いてくるかがわかります。Web 検索ありのサーフェスでの Beetroot のメンション率は、ブランド名なしの回答 80 件中 7 件、約 9 パーセントでした。このベースライン付近では、期間あたり 80 回の実行で確実に検出できるのは、どちらの方向でもおよそ 13 ポイントの変化です。翌月に 18 パーセントへ倍増しても、おそらく有意にはなりません。4 パーセントに半減しても同じです。単発のスナップショットには情報がありました。同じ規模で前月比を取れば、測っているのはほとんどノイズです。

次に、設計を固める前に予算の計算をします。プロンプト 100 個、各 20 回、サーフェス 3 つのパネルでは、正確さの採点を始める前の時点で、期間あたり 6,000 件の回答を集めることになります。この規模ならパネル全体で数ポイントの変動は見えますが、10 ポイントの動きを検出できるだけの実行回数を持つプロンプトは 1 つもありません。このトレードオフこそが本当の設計判断です。プロンプトを減らして実行回数を増やすか、サーフェスを減らすか、プロンプトごとの数字は診断用にとどめると割り切るか。最初のレポートの前に、「X より小さい変化は、このサンプルサイズではノイズ」という形で答えを書き残してください。

罠がもう 1 つあります。100 個のプロンプトを 5 パーセントの水準で検定すると、偶然だけで毎期間およそ 5 個が「有意な」動きを示し、スライドに載るのはまさにその 5 個です。プロンプトごとの動きは、調べるべきものを見つけるためのもので、報告するためのものではありません。

レイヤー 1：どのクエリを測定すべきか

意図ごとに層別した、固定されバージョン管理されたプロンプトのパネルです。各プロンプトには、それがどう作られたかを記録しておきます。パネルはこの先のすべての指標の分母なので、フレームワークの中で最も影響の大きい選択であり、最も偏りやすい選択でもあります。

3 つの層を作り、別々に報告します。

• ブランド名なしの発見プロンプト。 実際のクエリ（Search Console、キーワードツール）から始め、元のクエリを、そこから作ったアシスタント向けの形の隣に残しておきます。書き直しは意図を簡単に変えてしまいます。「best open source clipboard manager for Windows」と「a free clipboard manager that keeps images」は別の要求で、後者はオープンソースという条件を黙って落としています。派生させたプロンプトにはすべて合成であることを示すラベルを付け、変換の内容を保存してください。
• 比較プロンプト。 「Alternatives to X」「X vs Y for a team of 20」。競合の間でバランスを取り、大半のプロンプトで自社ブランドが名指しの基準点にならないようにします。
• エンティティプロンプト。 「What is [product]?」「Who makes [product]?」。質問の中でブランド名を挙げているので、メンションはほぼ確実です。測っているのは説明が正しいかどうかで、推薦されるかどうかではありません。発見のスコアに混ぜてはいけません。

パネルはコードのように扱います。ID、バージョン、測定期間ごとの凍結です。プロンプトを追加したり外したりしたらバージョンを上げ、バージョンをまたいだ数字は、両方のパネルで数字を出し直してから比較します。誰かがブランド名を含むプロンプトを 5 個足したせいで上がったスコアは、勝利とまったく同じに見えます。構成の効果は、ブランド名を含むプロンプトがなくても起きます。対になる記事の実行では、AI 機能についての 1 つのプロンプトが、2 つの検索サーフェスにわたる Beetroot のブランド名なしのメンション 17 件のうち 17 件を生みました。同じようなプロンプトをもう 1 つ足していれば、世の中では何も変わっていないのに、見出しの率はほぼ 2 倍になっていたはずです。

レイヤー 2：何をメンションとして数えるのか

生成された回答のテキストの中で、自社のエンティティが名前を挙げられていることです。検出には、監査と検証ができるマッチャーを使います。生の回答は名前を略し、綴りを間違え、名前を出さずに「Rust で書かれたもの」と説明し、あるいは競合の機能に自社の名前を付けます。

回答ごとに記録するもの:

• メンション有無（mentioned）：完全一致、既知の別名、レビュー済みのあいまい一致のいずれかで名前が挙がっているか。パネルの隣に置いた、バージョン管理された別名辞書を使います。
• スタンス（stance）：中立的なメンション、推薦、明示的な否定のどれか。「X is an option, but most users prefer Y」はメンションであり、負けです。
• 順位（position）：回答がリストの場合、その中での順番。
• 正確さ（accuracy）：回答が自社について言っていることが正しいか。日付入りのファクトシート（ライセンス、プラットフォーム、価格モデル、主要機能）に照らして採点し、「不確か」も結果として認めます。オープンソースのツールをプロプライエタリと呼ぶ回答は実害のあるリスクですが、素朴なダッシュボードはそれを勝ちとして数えます。

マッチャーは、人手でラベル付けしたサンプルに照らして検証してください。そのサンプルには、マッチャーが自社のメンションなしと判定した回答も含めます。検出されたメンションだけをレビューしても、見逃しは決して見つからないからです。モデルに採点させるなら、人手のラベルとの一致度を測り、採点者と採点基準をバージョン管理します。

対になる記事の実行では、マッチャーが乗り越えなければならない 2 つの失敗パターンがどちらも見つかりました。Beetroot を「similar indie apps」のひとまとめの一行に押し込んだ回答（正規表現はこれを完全なメンションとして採点します）と、Web アクセスのないモデルが自信満々に間違ったライセンスを答え、無関係なリポジトリにリンクした回答です。時間がたつと、マッチャーと採点者もバージョン管理される入力になります。どちらかを変えたら、トレンドラインが意味を持つ前に、古い回答を採点し直さなければなりません。

中心となる指標はメンション率です。あるプロンプトの完了した実行のうち、自社をメンションした割合です。パネル全体への集計は、実行をまとめるのではなく、プロンプトに固定の重みを付けて行います（等しい重みが妥当なデフォルトです）。そうしないと、今月タイムアウトが多かったサーフェスが、気づかないうちにスコアの重みを変えてしまいます。

レイヤー 3：何を引用として数えるのか

回答に付いた、自社の URL へのリンクまたは出典の表示です。メンションとは別の対象で、両者はどちらの方向にもずれることがあります。

メンションされても引用されないことがあり、引用されてもメンションされないことがあります。後者は、自社の比較ページやドキュメントが、別の製品を推薦する回答の出典として使われるケースです。前者は読み込みすぎたくなるパターンです。引用のないメンションはモデルの学習データから来ているかもしれませんが、インターフェースが表示しなかった第三者のページを検索で取得した結果かもしれません。検索で取得した出典と表示された引用は同じ集合ではなく、OpenAI 自身の Web 検索のドキュメントもこの 2 つを区別しています。このパターンは診断ではなく、検証すべき仮説として扱ってください。

引用率は、配管の影響を最も受けやすい指標でもあります。対になる記事の実行では、構造化されたアノテーションに加えてインラインの Markdown リンクも数えると、同じ回答で率が 2.5 倍動きました。あるサーフェスの引用は、収集スクリプトにまったく届いていませんでした。トレンドラインにとっては、パースのルールにもほかのすべてと同じくバージョンがあり、パーサーが黙って変わることと本当の変化は見分けがつかない、ということです。

引用された URL はすべて、生の形と正規化した形（リダイレクトを解決し、トラッキングパラメーターを除去したもの）、バージョン管理された所有者リストに基づく所有者の区分（自社、競合、第三者）、そして引用がインラインか別の出典パネルかを記録します。可能なら構造化された API レスポンスか、レンダリングされた証拠を残してください。URL を平たく並べたリストでは、引用がどの主張に付いていたかが失われます。この記録から次を出します。

• 引用率：自社の URL を少なくとも 1 つ引用した、完了した実行の割合。
• 引用されたページ：自社のどの URL が引用されているか。このフレームワークの中で、チームが変更できるページに直接対応する唯一の部分です。
• 第三者の引用シェア：観測された引用のうち、自社や追跡している競合ではなく、レビューサイト、フォーラム、ディレクトリを指すものの割合。表示されている出典が誰なのかはわかりますが、それぞれがテキストにどれだけ寄与したかはわかりません。

サーバーログは独立した視点を加えます。その際、2 種類のボットを分けておく必要があります。検索クローラー（OAI-SearchBot、PerplexityBot、Claude-SearchBot）は、あとで使うためにページをインデックスします。ユーザー起点のフェッチャー（ChatGPT-User、Perplexity-User、Claude-User）は、誰かがその場で何かを尋ねたからページを取得します。後者のほうが実際の利用の証拠に近いですが、どちらも引用の証明にはなりません。Google の AI による概要と AI モードは Google の通常のインデックスを使うので、ログにはそれらに固有のものは何も現れません。ユーザーエージェント文字列を信じる前に、公開されている IP 範囲か逆引き DNS でクローラーの身元を確認してください。

レイヤー 4：競合をどう公平に測定するのか

同じパネル、同じ実行、同じマッチャーで、自社の率を単独で見るのではなくシェア・オブ・ボイスを使います。自社のメンション率はそれだけでも情報になりますが、カテゴリーのリーダーが 35 パーセントのときと 90 パーセントのときでは、読み方がまったく変わります。

シェア・オブ・ボイスは登場の有無で定義します。回答ごとに、追跡している各ブランドは、何回名前が挙がっても、現れていれば 1 回と数えます。あるプロンプトのシェア・オブ・ボイスは、自社の登場数を、追跡しているすべてのブランドの登場数の合計で割ったものです。追跡しているブランドが 1 つも現れない場合、値はゼロではなく未定義です。そうした回答は 2 つの別々のバケットで報告します。ブランドを 1 つも挙げない回答と、追跡していないブランドだけを挙げる回答です。2 つ目のバケットが大きくなっているなら、追跡する競合のセットが古くなっている兆候です。

カテゴリー全体の合計を出す前に、意図ごとに計算します。対になる記事の実行では、ほとんどのプロンプトを Ditto と CopyQ が占めていましたが、AI 機能のプロンプトでは、あるサーフェスが 10 件すべての回答で Microsoft の PowerToys Advanced Paste を挙げ、Beetroot は毎回 2 番手で、Ditto も CopyQ も 1 度も現れませんでした。カテゴリー全体のシェアは、2 つの異なる競争状況を平均して、どこにも存在しない 1 つの状況にしてしまいます。引用もここに含まれます。比較プロンプトでは、回答が選択肢の枠組みを示すときに誰のページが引用されているかを追跡する価値があります。

競合のセットはパネルと一緒に固定します。期間の途中で強い競合を追加すると、全員のシェアが下がり、下落のように見えます。

実行レコードには何を入れるのか

失敗したものも含めて、すべての実行です。対になる記事には、1 回の測定に最低限必要なレコードを載せました。定期的なプログラムにはそれ以上が必要です。トレンドは、モデル、収集スクリプト、定義の変更を経ても意味を保たなければならないからです。スキーマは、自分で設定したものと観測したものを分けます。ほとんどのコンシューマー向けサーフェスでは、モデルを指定することも、検索を強制することもできないからです。

# set by the collector
run_id, panel_version, prompt_id, surface, requested_mode,
country, language, account_state, fresh_conversation, timestamp
 
# observed in the response
status (completed | refused | timeout | parse_error | no_ai_feature),
retry_of, model_reported, search_triggered, issued_queries[],
answer_text, citations[] (raw_url, normalized_url, placement)
 
# applied later, re-runnable
matcher_version, grader_version, ownership_list_version

status は分母を正直に保つためのものです。タイムアウトは、メンションのない回答ではありません。Google の場合、「このクエリでは AI による概要が表示されなかった」はそれ自体が 1 つの結果です。可視性は、対象となるすべてのクエリ全体と、その機能が表示された場合に限った条件付きの両方で報告してください。すべての指標の隣に完了率を載せます。

model_reported は空であることが多いフィールドです。API はモデル ID を公開しますが、コンシューマー向け製品はたいてい公開せず、ベンダーは製品名を変えないままモデルを入れ替えます。そうしたサーフェスでは、モデルの変更はリリースノートか、多数のプロンプトで同時に起きる急な変化から推測するしかありません。記録できるものは記録し、残りは不明と明記し、既知のベンダーのリリースをすべて時系列に注記してください。エージェントのパイプラインについても、モデルは、じっとしていない依存先ですで同じことを論じました。何に対して測っていたかをログに残していなければ、ベンダー側のドリフトと自分たちの変更を切り分けることはできません。

API の結果とコンシューマー向けインターフェースは別々のサーフェスで、互いの代わりにはなりません。系列は分けておいてください。コンシューマー向けインターフェースからブラウザー自動化で収集するなら、先にその製品の利用規約を読んでください。コンシューマー向けアプリへの自動アクセスは規約違反になりえますし、アカウントを危険にさらします。

これらの数字からわからないことは何か

この方法で作るレポートには、以下を必ず本文に入れてください。脚注に書いた限界は、誰にも読まれない限界です。

回答の母集団ではありません。 パネルは設計されたサンプルです。実際のユーザーは自分なりの言い方で質問し、会話の履歴やメモリーを持ち、パーソナライズされた結果を見ています。パネルが測るのは管理された条件です。だからこそ時間をまたいで比較でき、だからこそトラフィックの推定にはなりません。実行回数を増やせばサンプリングのノイズは減りますが、偏ったパネルには何の効果もありません。

ベンダーのツールも測定です。 商用トラッカーはそれぞれ違います。自分でプロンプトを定義できるものもあれば、独自のプロンプトデータベースについて報告し、各プラットフォームの利用状況で調整した検索ボリュームでプロンプトに重みを付けてリーチを推定するものもあります。どのツールか、どのモードか、どの手法のバージョンかを記録し、その系列には明確なラベルを付けてください。同じ名前の指標であっても、その数字は自分たちの数字と置き換えがききません。

リファラルは観測値であって、インパクトではありません。 ChatGPT search はリファラルのリンクに utm_source=chatgpt.com を付けます（OpenAI publisher FAQ）。リファラーを渡すアシスタントもあります。Search Console にはこの夏から独立した生成 AI のパフォーマンスレポートがありますが、AI による概要と AI モードのインプレッションをまとめて扱っていて、クリックは今も通常の Web の合計に入ります。これらは「観測された帰属可能なセッション」と呼んでください。ビジネスへの効果の下限でもなければ、メンションのコンバージョン率でもありません。

トレンドは原因ではありません。 安定したパネルは、可視性が動いたことを示します。構造化データのマークアップや新しい比較ページがそれを動かしたことは示しません。特定の変更を検証するには、専用の設計が必要です。施策を適用したページまたはプロンプトのセット、比較可能な施策なしのセット、そして事前に固定した観測期間です。

エンジニアリングチームと分析チームのための実装チェックリスト

各項目の説明は本文にあります。このリストは、最初の数字がチームの外に出る前に何が存在していなければならないか、そして誰がそれを担当するかをまとめたものです。

エンジニアリング

• プロンプトのパネル、別名辞書、所有者リスト、ファクトシートをバージョン管理し、それぞれにバージョン ID を付けます。
• サーフェスごとに収集スクリプトを 1 つ（API があれば API、ブラウザー自動化は規約が許す場合のみ）。すべてのプロンプトを期間ごとに N 回、複数の日に分散させて、固定した地域とアカウント状態から実行します。
• 失敗も含めたすべての試行について、完全な実行レコード、生の回答テキスト、構造化された引用を残します。
• 検索クローラーとユーザー起点のフェッチャーを URL 別に集計するログのパース（身元確認付き）。
• 再処理：マッチャー、採点者、所有者リストのどれを変えても、保存した生の回答に対して再実行できること。

分析

• パネルは 3 つの層（発見、比較、エンティティ）で構成し、派生プロンプトはそれぞれ元のクエリにひも付け、期間ごとに凍結します。
• サンプルサイズは、検出できる変化の表と収集の予算から選び、そこから導かれるノイズのしきい値を書き残します。
• マッチャーと採点者を、ネガティブを含む人手のラベルで検証します。
• 指標は層ごと、サーフェスごとに報告します。メンション率、スタンス、正確さ、引用率、引用されたページ、第三者の引用シェア、シェア・オブ・ボイスで、それぞれに完了率、実行回数、区間を付けます。
• 時系列には、パネルのバージョン、既知のモデルリリース、自社サイトのリリースを注記します。
• リファラルのデータには「観測された帰属可能なセッション」とラベルを付け、成果指標としては決して扱いません。

共通

• すべての指標を平易な言葉で定義した 1 ページ。数字に異議が出たとき、守るべきはそのページです。
• 四半期ごとのパネルレビュー。もう誰も尋ねなくなったプロンプトを外し、新しい需要を加え、バージョンを上げ、比較を出し直します。

この記事の位置づけ

フレームワークは手法であって、発見ではありません。単一パネルでの測定は最初のデータポイントです。発見は、このようなフレームワークを十分に長く回して、「AI の回答に載る」ための定番の推奨のうちどれが通用するかを確かめ、通用したものを適切な介入デザインで検証することから生まれます。このサイトの独自データに基づく研究は research セクションにまとめていて、それぞれ結果の隣に手法と出典を示しています。可視性の数字が満たすべき基準も同じです。どう作られたのかを誰も検証できないなら、それはグラフ付きの意見にすぎません。