LLMOツールの引用URLをどう集計する？重複・パラメータ・転送先を整理する方法

LLMOツールで引用元を調べると、同じ記事に見えるURLが複数並ぶことがあります。末尾に計測用の文字列が付いていたり、ページ内の見出しを指す記号があったり、古いURLから新しいURLへ転送されていたりするためです。一方、似たURLでも料金プランや言語が違えば、別の情報を表している場合があります。

集計の基本は、元のURLを保存したうえで、集計用の対応表を別に作ることです。「同じページ」「同じ回答」「同じドメイン」を混同せず、何を一件と数えるかを先に決めます。本記事では、引用URLの一覧を、元の回答まで戻って確認できる分析資料に整える手順を解説します。

引用URLの行数は、そのまま引用された回答数にはならない

一つのAI回答に同じページへのリンクが二つあれば、出力形式によっては二行になります。一つの回答が自社の三ページを挙げれば、URLは三つでも自社が引用された回答は一つです。さらに、データを書き出して結合する途中で同じ記録が二重に含まれることもあります。

そのため、「引用が100件」という報告には数え方が必要です。出典リンクの出現回数なのか、引用された回答数なのか、引用されたページの種類数なのかを併記します。ツールの画面にある指標を独自に再集計するときは、元の指標と異なる定義なら別の名前を付けてください。

目的が記事改善なら、回答とページの組を起点にすると、どの疑問にどのページが採用されたかを確認しやすくなります。外部サイトの広がりを調べるなら、ホスト単位など別の集計も有効です。単位を一つに統一する必要はありませんが、異なる単位を同じグラフの前後で混ぜないようにします。

元データと集計用データを分けて持つ

元データには、回答ID、計測日時、質問文または質問ID、AI、取得状態、引用URLを残します。可能なら回答本文と、回答中の出典位置や出典IDも保存します。これらは「その時の回答に何が示されていたか」を確認する記録です。集計しやすくするために元の値を上書きすると、後で判定を直せなくなります。

集計用データには、同一ページのグループID、確認した転送先、ホスト、判定理由、確認日時、ルールの版を追加します。元URLから集計用ページIDへの対応を保持すれば、グラフから具体的な回答へ戻れます。対象が少ない場合は表計算でも運用できますが、列の役割は最初に決めておきます。

URLに認証情報や個人を識別する値が含まれる場合は、共有用の表を別に作り、必要な箇所を伏せます。分析に使う記録の保管範囲と、社内外へ配布する資料の範囲は分けて考えます。伏せた値を用いて重複判定するなら、その変換によって別のURLを誤ってまとめないかも確認してください。

引用URLを整理する5ステップ

図：元URLは残したまま集計用の対応表を作り、元の回答へ戻れる状態を保ちます。

1. 集計の目的と一件の単位を決める

記事改善、引用の広がり、定点観測などの目的を決め、出典リンク、回答とページの組、回答数、ページ数のどれを集計するか明記します。対象期間とAI、質問群、取得状態の条件も合わせて固定します。

最初の表の見出しは「引用数」ではなく、「自社ページを引用した取得成功回答数」のように具体的にします。全回答が必要な指標を、引用のある行だけから計算しないことも大切です。URL一覧には引用のない回答が含まれないことがあるため、割合を作る際には回答側の母集団と結合する必要があります。

2. 元URLと回答の記録を保存する

書き出したデータをそのまま保存し、回答ID、計測日時、AI、元URLを対応付けます。加工用のコピーを作り、元データの行数とファイルの取得日時、適用した画面のフィルターを記録します。

同じファイルを二度読み込んだ場合の重複を検出できるように、取込元と取込回を残します。出典IDがあれば使い、なければ回答ID、出典位置、元URLなどの組を検討します。URLだけで重複を消すと、別の日や別の回答で同じページが引用された事実まで失われます。

3. 同一ページかを確認して対応表を作る

パラメータ、ページ内の位置指定、転送先、本文の内容を確認し、同一ページと判断できたものに共通のページIDを付けます。判断できないURLは保留にし、元の文字列を残したまま扱います。

すべての疑問符以降を削除するような一括処理は避けます。計測用の値に見えても、ページの表示や選択内容に影響することがあります。対象サイトでの意味を確認し、除去してよいキーの一覧と例外を残します。転送後のURLやcanonicalの指定も判断材料にできますが、それだけを絶対的な同一性の証明にしません。

4. 集計結果を元の回答と照合する

決めた単位で件数を集計し、代表例と例外を元の回答へ戻って照合します。整理前後の行数、ページ数、回答数を並べ、減少が重複除外によるものか、誤った統合や欠落によるものか確認します。

特に複数ページが同じ回答に含まれる例、同じURLが別の回答に含まれる例、計測用パラメータだけが異なる例を確認します。合計が予想どおりでも、一部の欠落と二重計上が相殺されている場合があります。件数と個別の対応を両方見ることで、見かけの一致を避けられます。

5. 判定ルールと保留項目を保存する

同一ページの判定規則、例外、確認日時、ルールの版、保留項目を集計結果と一緒に保存します。規則を変える場合は変更理由と対象を記録し、過去の数字を再計算したかどうかも明示します。

サイト移転などで対応表が変わっても、過去の報告を黙って置き換えないようにします。旧ルールでの結果と新ルールでの結果を比較できる形にしておけば、引用が増減したのか、整理方法が変わったのかを区別できます。担当者の記憶に依存せず、例外の理由を次の人が読めることが運用の到達点です。

パラメータ・大文字小文字・転送をどう扱うか

URLの見た目を整える操作と、同じ内容だと判断する操作は別です。URIの構文を定義するRFC 3986では、ホストなどの扱いと、パス・クエリ・フラグメントの構成が区別されています。ホストを小文字にする考え方を、そのままパス全体の小文字化へ広げないようにします。

例えば、同じ料金ページでも「plan=pro」と「plan=lite」で表示条件が変わるなら、まとめると引用されたプランの違いを失います。一方、「utm_source」のようなキーがアクセス解析の区別だけに使われ、内容が同じだと確認できる場合は、集計用のページIDを共通にする候補になります。キー名だけで決めないことが原則です。

フラグメントと呼ばれる「#」以降の情報は、ページ内の位置などを示します。ページ単位では同じグループにしても、どの節へのリンクだったかを別列に残すとリライト時の参考になります。特殊なWebアプリでは表示との関係が異なる場合もあるため、機械的な削除の前に実際の内容を確認します。

canonicalと転送先は確認材料として使う

Googleの重複URLの正規化に関する説明は、重複ページについて検索側へ優先URLを伝える方法を扱っています。サイトが指定したcanonicalと、実際に検索側で採用されるURLが必ず一致するとは限りません。さらに、その指定をすべてのAIが同じように扱うとも断定できません。

集計ではcanonicalを補助列として保存し、ページの内容、転送、運営上の関係と照合します。異なる商品ページが設定ミスで同じcanonicalを指している場合、指示だけを信じて統合すると分析を壊します。判定根拠を「canonicalが同じ」の一語で終わらせず、内容を確認したかまで残してください。

転送先にも時間の問題があります。今日確認した最終到達先は、過去にAI回答が生成された時点の到達先とは限りません。短縮URLや移転済みページは特に、当時の記録と現在の状態を分けて扱います。「回答時にこのページを見ていた」と逆算せず、「確認日にここへ転送された」と書きます。

架空の6行で集計単位の違いを確認する

次は説明用の架空データです。すべて同じ自社ホスト上にあり、計測用パラメータと節指定は同じガイド本文を指すことを確認済みとします。料金の二つのプランは内容が異なるため分けます。最後の行は、同じ出典IDの記録を二重に取り込んだことが分かった例です。

元の表は6行ですが、取込重複を一つ除くと出典の記録は5件です。URL文字列の種類もこの例では5種類です。「一つの回答で同じページは一件」とする集計では、R1とG、R2とG、R3とP、R3とLの4組になります。ページの種類はG・P・Lの3種類、自社ページが引用された回答はR1・R2・R3の3件です。

ホストはすべて同じなので1種類です。6、5、4、3、1という異なる数字が出ますが、単位を明示すれば矛盾ではありません。反対に、これらをすべて「引用数」と呼ぶと、担当者によって報告が食い違います。表の上部に集計単位を固定し、別の単位は別列に分けて表示します。

この6行だけでは自社引用率を計算できません。引用されなかった回答を含む取得成功回答の総数が不明だからです。元の回答一覧から分母を取得し、同じ期間・質問群・AI・取得状態の条件をそろえます。分子だけ詳しく整理しても、分母が別条件なら意味のある割合にはなりません。

集計後に残す品質確認と例外の一覧

定期報告では、合計だけでなく「未判定URLが何件あるか」「転送先を確認できない記録が何件あるか」も残します。未判定をすべて一つの不明グループにまとめると、ページ数を過小評価することがあります。保留のまま個別に残すか、集計対象から分けて件数を注記するか、目的に応じて決めます。

回答IDがないデータを複数ファイルから結合するときは、質問文と時刻が同じでも本当に同じ試行かを確かめます。丸めた時刻だけを識別子にすると、短時間に実施した別の計測を消す可能性があります。信頼できるIDを復元できない場合は、「回答数」の集計を保留し、確認できる単位だけを報告します。

確認用のサンプルは、件数の多いURLだけでなく例外を含めます。パラメータ付き、別言語、移転、取得不能、複数のcanonical候補など、誤って統合しやすい形を選びます。ルール変更のたびに同じ例を見直せるようにすると、過去に直した誤りを再び持ち込みにくくなります。

引用一覧から分かるのは、取得した回答に示された出典です。そのURLが表示された理由、AIの内部評価、学習への利用状況、参照内容の正確さまで証明するものではありません。引用先の本文を読んで判断する作業と、件数を数える作業を分け、分析結果を強く言い過ぎないようにしてください。

LLMOチェキの引用元分析を改善作業へつなげる

LLMOチェキは、AI回答や出典の分析を通じて改善を支援します。引用元を見つけたら、元の回答、質問、引用ページを結び付け、どの疑問に対応する情報が採用されているかを確認します。本記事の対応表は運用上の整理方法であり、すべての正規化や過去の到達先復元をツールが自動実行するという説明ではありません。

画面の指標と独自集計を比較するときは、LLMOチェキの計測方法と指標定義も確認してください。引用URLを整理する目的は、数字を大きく見せることではなく、元の回答を読み直し、改善すべきページを根拠付きで選べる状態にすることです。集計単位と判定理由が明確なら、次の担当者も同じ材料から判断できます。