AI検索の計測を
5層に分ける

— 01

レイヤー1｜Googleの生成AI機能での表示とクリック

このレイヤーで確認できるのは、Google検索内での露出とクリックです。Googleは、AI OverviewsやAI Modeといった生成AI機能に表示されたサイトについて、検索結果ページの他の部分と同じく検索トラフィック全体に含めて扱い、検索パフォーマンスレポートの「ウェブ」検索タイプで報告すると説明しています。

裏を返せば、AI機能経由の表示・クリックだけを分離する専用のレポートは案内されていません。「AI Overviewsからのクリック数」を独立した数値として取り出そうとする設計は、この時点で成立しません。画面や提供範囲は変更される可能性があるため、確認日を記録して運用します。

確認する指標: 表示回数、クリック、クリック率、表示されたページ、対象期間、通常検索との重複や差分。

このレイヤーでは分からないこと: 回答文のどの記述へ使われたか、他のAIサービスで引用されたか、クリックしなかった利用者が問い合わせに至ったか、表示の増加が特定施策の結果であるか。

AI Overviewsそのものの仕組みと備え方はAI Overviews対策ガイドで扱っています。

— 03

レイヤー3｜AIサービスからのサイト流入

このレイヤーが対象にするのは、サイトへ遷移した利用者だけです。GA4などで、ChatGPT・Perplexity・Geminiなどの参照元からの訪問を確認します。

チャネル定義には前提があります。GA4はChatGPTなどのAIアシスタントを独立したチャネルとして分類しますが、GoogleのAI OverviewsやAI Mode経由の来訪はGoogle検索の一部として扱われるため、ここには現れません。当社のダッシュボードでは、チャネル名に頼らず、参照元（GA4のsessionSource）の完全一致リストで集計しています。判別できない新しいAIサービスは集計から漏れる設計で、AI流入を水増ししない側へ倒しています。

加えて、アプリ内ブラウザ、リダイレクト、プライバシー制御により参照元が欠落することがあります。日次の確定値ベースでは数時間から1〜2日遅れて観測される、いわば遅行指標です。

確認する指標: セッション数、ランディングページ、滞在とスクロール、主要CTAの到達、問い合わせ開始、問い合わせ完了、新規と再訪の別。

AI経由の流入が少なくても、AI回答で会社名を知り、後から指名検索する利用者がいます。流入だけで価値を判断しないことが重要です。自社GA4での実測値はAI検索からの流入は実際どれくらい？で公開しています。

— 05

レイヤー5｜問い合わせ・商談・受注

最終的に事業へつながったかを確認するレイヤーです。ここで見るのは、問い合わせ件数、有効商談数、相談内容、受注、契約金額、初回接点として申告された経路、読まれたページ、問い合わせまでの日数です。

計測を実装する際は、フォームのイベント名を先に決めます。netsujo.jpでは、入力開始をform_start、送信試行をform_submit、サーバーが正常受領した送信をgenerate_lead、送信失敗をform_submit_errorとして記録しています。GA4の拡張計測が自動で拾うform_submitは信頼性が低いため、成功率の分母には自前で発火させたイベントを使います。

この段階では、AI検索経由と断定できない案件も含まれます。UTMや参照元が残る場合は記録し、本人申告とアクセスログを照合します。問い合わせまでの計測設計はSEO・AIO施策を問い合わせにつなげる計測方法で扱っています。

— 07

引用を判定してスナップショットで追う

判定がもっとも素直に書けるのは、レスポンスに出典URLの配列を返すエンジンです。ここではPerplexityのSonar APIを例に、最小ロジックを擬似コードで示します。

def query_engine(query, api_key):
    # 出典配列を返す検索付きAI（例: Perplexity Sonar）に messages を投げ、
    # 回答 + citations を受け取る
    resp = post("https://api.perplexity.ai/chat/completions", {
        "model": "sonar",
        "messages": [{"role": "user", "content": query}],
    }, auth=api_key)
    return resp

def check_brand_mention(citations, brand_hosts):
    # citations URL の hostname を parse し、完全一致 or サブドメイン一致で判定する。
    # 単純な部分文字列一致（host in url）は netsujo.jp.evil.com のような
    # 偽装ホストを誤検出するため避ける。
    for url in citations or []:        # citations は null/空がありうる
        host = urlparse(url).hostname or ""
        for brand in brand_hosts:      # 例: ["netsujo.jp"]
            if host == brand or host.endswith("." + brand):
                return True
    return False

出典配列はnullや空配列で返ることがある点、そして単純な部分文字列一致は誤検出する点に注意が必要です。URLをparseしてホスト名で判定します。判定対象は、構造化された出典配列にドメインが含まれるかを見る出典リストの判定と、回答本文中にブランド名やドメインが言及されているかを見る本文テキストの判定の2つに分けると安定します。前者は誤検出が少なく、後者は出典リンクが貼られずに名前だけ出るケースを拾えます。

エンジンによって出典の取り方は異なります。ChatGPTは、UI上の回答を測るならログインを伴うブラウザ自動化、API上のweb search応答を測るなら公式APIの引用アノテーション、というように測定対象で配線が変わります。GeminiはGrounding with Google Searchが出典アノテーションを返すためAPIでの構造化取得が可能です。AI OverviewsはGoogle公式のAPIがなく、第三者のSERP取得サービスでの近似になります（再現性や各社の利用規約に注意が必要です）。

なお当社が公開している観測は、OpenAIのWeb検索を使った1系統です。Perplexity Sonar向けのアダプタは実装済みですが、公開している観測では無効にしています。エンジン横断の完全自動計測には至っておらず、段階的に広げる前提で運用しています。

1回の計測結果は、クエリ単位のスナップショットとして保存します。レスポンス全文ではなく、抽出済みの引用情報だけを残す点が肝心です（保存量とプライバシーの両面から）。1クエリ分の保存形式はおおよそ次の形です。

{
  "snapshot_date": "2026-06-02",
  "engine": "perplexity",
  "query": "京都 Web3 開発会社",
  "brand_hosts": ["netsujo.jp"],
  "citations": ["https://...", "https://..."],
  "brand_mentioned": true,
  "citation_count": 5
}

これを日付・エンジン・クエリごとに蓄積し、週次で前回スナップショットと突き合わせて、citation shareの前週比、新たに引用されたクエリ、引用が消えたクエリ、比較対象とのシェア差の変化を出します。実行間隔はエンジンごとのレート制限に合わせて調整します。

— 09

1つの「AI可視性スコア」へまとめない

経営向けのサマリーとして指数を使う場合でも、元の指標を残す必要があります。レイヤーは同じ方向へ動くとは限らないためです。

外部AIでの引用率が上がっても、サイト流入が増えない場合があります。Google内の表示が増えても、問い合わせページが分かりにくければ商談にはつながりません。逆に、AIで引用されなくても、指名検索や既存顧客からの紹介が増える場合があります。総合値は状況を一目で見るための補助です。改善の判断は、レイヤー別の指標で行います。

スコア化そのものの限界（反復回数・信頼区間の扱い）はAI可視性の測り方で掘り下げています。

— 11

測れない範囲を先に明記する

AI検索の計測で、完全な把握はできません。運用判断を誤らないために、測れない範囲を先に書きます。

• AI回答を読んで終わった利用者

• 参照元が消えたアクセス

• 同じ回答内で引用されなかった参照

• AIサービス内部の候補生成

• 回答が変化した原因

• 複数接点を経た問い合わせの正確な帰属

観測の側にも限界があります。同じクエリでも回答は実行ごとに揺れるため、1回のfalseで「引用されていない」と断定はできません。出典配列を返すエンジンと、出典の取得自体が近似になるエンジンでは計測精度が揃わないため、エンジン横断のシェアを単純合算すると判断がぶれます。クエリ集合が小さいとシェアは数クエリの増減で大きく振れ、30クエリなら1件動くだけで3ポイントを超えて変動します。出典の返し方やパラメータは各社の都合で変わるため、判定ロジックは定期的な追従が前提です。

そのため、「この施策で引用率が何ポイント上がった」という因果の断定は避けています。計測が示せるのは、固定した条件下での相対的な推移と、改善すべきクエリの所在までです。測れない部分を隠して精密なスコアに見せるより、観測範囲を明示した方が意思決定に使えます。

よくあるご質問

関連記事