AIO

AI引用を計測する

生成エンジンの回答に自社が引用・言及されたかを継続的にトラッキングする仕組みの実装を、netsujo.jpのai-citation-trackerを題材に解説します。

— 02

計測する指標を定義する

被引用を数値で追うために、2つの基本指標を置きます。

• citation presence（被引用の有無）: あるクエリに対する回答のなかに、自社ドメインが出典・本文リンクとして1回でも出現したか。true / falseの二値です。

• citation share（被引用シェア）: 対象クエリ集合のうち、自社が引用されたクエリの割合。たとえば対象25クエリ中8クエリで引用されればシェアは32%です。

加えて、運用で役立つ補助指標として次を取ります。

• citation depth: 回答内で自社が出典として現れた平均的な位置。上位に出るほど影響が大きいという仮説に基づきます。

• competitor delta: 同じクエリ集合に対する自社シェアと、主要競合のシェアの差分。自社が伸びたのか、競合が落ちたのかを切り分けるために使います。

これらは特定のクエリ集合に強く依存します。指標の絶対値そのものより、同じクエリ集合・同じエンジンで時系列の変化を追うことに意味があります。

— 04

クエリを投げて引用を判定する

現状のai-citation-trackerは、PerplexityのSonar APIを中心としたスケルトン実装です。Perplexityはレスポンスにcitations配列（出典URLのリスト）を返すため、被引用判定をもっとも素直に実装できます。最小ロジックは次のような擬似コードになります。

def query_perplexity(query, api_key):
    # Sonar API に 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

citationsはnullや空配列で返ることがある点、そして単純な部分文字列一致は誤検出する点に注意が必要です。URLをparseしてホスト名で判定します。

判定対象は2つに分けて扱うと安定します。

• 出典リストの判定: citationsのような構造化された出典配列にドメインが含まれるか。誤検出が少なく、比較的取りやすい判定です（それでもURL正規化とnull処理は残ります）。

• 本文テキストの判定: 回答本文中にブランド名やドメインが言及されているか。出典リンクは貼られないものの本文で名前だけ出る、というケースを拾えます。こちらは正規表現での表記ゆれ対策が必要です。

ChatGPT・Gemini・AI Overviewsは、出典の取り方がエンジンごとに異なります。ChatGPTは、UI上の回答を測るならログインを伴うブラウザ自動化、API上のweb search応答を測るなら公式APIの引用アノテーション、というように測定対象で配線が変わります。GeminiはGrounding with Google Searchが出典アノテーションを返すためAPIでの構造化取得が可能です。AI OverviewsはGoogle公式APIがなく、SerpAPIのような第三者SERP取得サービスでの近似になります（再現性や各社の利用規約に注意が必要です）。現状の実装はこの横断部分を拡張中で、完全自動の全エンジン計測には至っていません。Perplexityを起点に段階的に広げる前提で運用しています。

— 05

スナップショットを保存して推移を追う

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

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

これを日付・エンジン・クエリごとにreports/ai-citations/配下へ蓄積します。週次で前回スナップショットと突き合わせ、次の差分を出します。

• citation shareの前週比

• 新たに引用されたクエリ（new mentions）

• 引用が消えたクエリ（lost mentions）

• 競合とのシェア差の変化

netsujo.jpではGitHub Actionsのcronで毎週月曜にまとめて回し、差分サマリーをDiscordに流す運用を想定しています。エンジンごとにレート制限が異なるため、実行間隔はそれに合わせて調整します。

— 07

計測の限界を正直に書く

この計測には、無視できない限界があります。運用判断を誤らないために明記します。

• 出力の非決定性: 同じクエリでも、生成エンジンの回答は実行ごとに揺れます。1回のfalseで「引用されていない」と断定はできません。複数回・複数日の傾向で見る必要があります。

• エンジンごとの差: Perplexityのように出典配列を返すエンジンと、出典の取得自体が近似になるエンジンでは、計測精度が揃いません。エンジン横断のシェアを単純合算すると誤解を生みます。

• サンプル数の制約: クエリ集合が小さいと、シェアは数クエリの増減で大きく振れます。30クエリで1件動けば3ポイント超の変動です。

• API仕様の変化: 出典の返し方やパラメータは各社の都合で変わります。判定ロジックは定期的な追従が前提です。

そのため、「この施策で引用率が何ポイント上がった」という因果の断定は避けています。計測が示せるのは、固定した条件下での相対的な推移と、改善すべきクエリの所在までです。

よくあるご質問