SEOカニバリをAIでチェックする方法｜競合URLの発見と解消手順

SEOのカニバリ（自サイト内の記事同士が同じ検索意図で競合している疑い）をAIでチェックするときは、Search Consoleのquery-page（検索語句とページの対応）実績から候補ペアを機械的に作り、各記事の主キーワード・H1・扱う範囲をまとめた台帳と突き合わせてAIに意図を分類させます。AIが出せるのは競合「候補」までです。統合するか差別化するかの最終判断は、クリック数、被リンク、収益、更新性、実際の本文を見て人が決めてください。

同じqueryで自サイトの複数URLが表示されること自体は、異常ではありません。この記事では、正常な複数表示と本当のカニバリを分ける判定シグナル、AIに分類させるプロンプト、そしてkeep（維持）・merge（統合）・differentiate（差別化）・retire（廃止）という4つの処置の選び方までを一続きで解説します。

情報確認日：2026年7月28日（日本時間）

結論：同一queryだけで判断せず、意図・順位の動き・記事設計を突き合わせる

この記事の結論

同じqueryに複数URLが出るだけでは競合と断定しない
判定はquery重複、表示URLの入れ替わり、クリック配分、実際の記事設計を複数期間で見て行う
主キーワード・H1・扱う範囲／扱わない範囲を書いた台帳が、AI分類の精度を決める
AIには分類と根拠queryだけを出させ、処置の提案までさせない
処置はkeep・merge・differentiate・retireの4択から、人がデータで選ぶ
統合と301は戻しにくいため、条件を確認せずに実行しない

カニバリと正常な複数URL表示を分ける

同じqueryだけでは競合と断定しない

1つのqueryで自サイトの2本以上の記事が表示回数を得ている状態は、ごく普通に発生します。読者の目的が枝分かれするqueryでは、Googleが複数の候補を出し分けているだけということも多いためです。この段階で「重複しているから片方を消す」と決めると、独立して価値のあるページを失います。

ここで計測上の注意点が1つあります。Search Consoleヘルプは平均掲載順位を「検索結果におけるサイトの最上位の平均掲載順位」と説明しています。つまり同じqueryで2本のURLが表示されていても、プロパティ全体で見た平均掲載順位には上位側の数字しか現れません。ページ単位に分解しないと、2本目の存在そのものが見えないということです。

カニバリが疑われるときは、順位の数字だけでなく次のような現象が見られます。ただし、どれも単独では証拠になりません。queryの細かな違い、データ量の少なさ、季節性、検索結果全体の変化でも起こるため、同じ条件の複数期間と記事内容を合わせて確認します。

同じqueryで表示されるURLが週ごとに入れ替わり、どちらも順位が安定しない
同じqueryのクリックが2本に分かれ、主要URLが定まらない
そのqueryに最も適した記事ではないURLが表示され、CTR（クリック率）が下がる
改善したい記事に手を入れても、別の記事が表示されてしまい効果が読めない

逆に、片方が主要URLとして安定し、もう一方が別の意図でも固有の成果を得ているなら、複数表示を直す必要はありません。少数の表示しかないURLも、データ不足だけで無害とは断定せず、次の判定表で保留を含めて判断します。

検索意図・順位交代・CTRを見る

競合候補を「同一検索意図」「近接意図」「別意図」の3つに切り分けるための判定matrix（判定表）です。1つのシグナルだけで決めず、複数行が同じ列を指しているかで判断します。

判定シグナル	同一検索意図（真の競合）	近接意図（調整が必要）	別意図（正常な複数表示）
主要queryの重なり	表示回数やクリックを得るqueryの構成がよく似る	一部が一致し、周辺語が異なる	固有の主要queryが明確に分かれる
表示URLの動き	同じqueryで表示URLが週単位に入れ替わる	主従は決まるが、時折入れ替わる	queryごとに表示URLが固定
掲載順位の傾向	どちらも中位のまま伸びない	一方が上位、一方が下位で安定	それぞれの主要queryで上位
クリックの配分	同一queryのクリックが2本に分散	主URLに集中し、副URLは少量	別々のqueryで独立に獲得
CTRの動き	表示回数の割にどちらも低い	主URLのみ標準的	いずれも意図に見合う水準
台帳の主キーワード	実質的に同じ語	上位概念と下位概念の関係	明確に異なる
H1と扱う範囲	言い換えの範囲で重複	一部だけ重なる	重ならない
読者の次の行動	どちらを読んでも同じ	読み進める順序がある	そもそも目的が違う

この表に万能な点数や件数の基準はありません。十分な表示回数があるqueryで複数のシグナルが継続し、本文を読んでも同じ課題・同じ次の行動を扱っていると確認できたときに、初めて統合や廃止を検討します。データが少ない、またはシグナルが割れる組は「保留」とし、書き分けか追加観測を先に行います。

query-pageデータと記事台帳を準備する

Search Consoleの期間とfilterを揃える

Search Consoleのパフォーマンスレポートは、クエリ、ページ、国、デバイス、検索での見え方、日付という6つのディメンションでデータをグループ化できます。指標はクリック数、表示回数、CTR、平均掲載順位の4つです。カニバリ調査で必要なのは、queryとpageの対応が取れた行なので、条件を固定してから書き出します。

検索タイプを「ウェブ」に固定する（画像や動画が混ざると比較できません）
十分な表示回数を得られる固定長の期間を選び、以後の再計測でも同じ長さと曜日構成を使う
国とデバイスを絞る場合は、比較する全URLで同じ条件にする
少数URLを画面で調べる場合は「URL が次と一致」フィルタをかけ、クエリタブでそのページのqueryを取得する
次に対象queryを完全一致で絞り、ページタブで表示されているURLを確認する
この往復で得た query, page, clicks, impressions, ctr, position の組をCSVにまとめる

画面上の往復は少数の候補を確認する方法です。サイト全体を継続的に調べる場合は、Search Console APIまたは一括データエクスポートでqueryとpageを同時に扱える表を作り、条件を保存してください。部分一致のURLフィルタは似たパスまで混ぜるため、個別URLの検証には完全一致を使います。

ヘルプによれば、ページのディメンションを選ぶとテーブルのデータはプロパティ単位ではなくページ単位で集計されますが、グラフのデータは選んだディメンションに関わらず常にプロパティ単位で集計されます。テーブルの数字とグラフの合計が一致しないのはこのためで、集計単位の違いを取り違えると誤った結論に進みます。

フィルタは「+ フィルタを追加」から追加するほか、テーブルの行をクリックしても適用されます。検索タイプと日付のフィルタは削除できません。文字列の一致は大文字と小文字を区別しませんが、スペースを含めてそれ以外は正確に一致する必要があります。複数の記事群をまとめて見たい場合は正規表現フィルタが使え、構文はRE2、既定の挙動は部分一致です。大文字と小文字を区別したいときは式の先頭に (?-i) を付けます。

期間や値の比較も可能ですが、比較できるのは1つのグルーピングディメンション内の2つの値で、同時に保持できる比較は1つだけです。新しい比較フィルタを追加すると既存の比較は置き換わります。カニバリ調査では「解消前と解消後」のように、比較軸を1本に絞って使ってください。

取得できるデータは全量ではありません。ヘルプでは、ユーザーのプライバシー保護のために一部のqueryが匿名化クエリとして省かれること、そしてクエリフィルタを適用しない限り匿名化クエリもグラフの合計には含まれることが説明されています。画面には最大1,000行などの制約もあり、内部的な制限によりテーブルに出ないqueryがあります。一括データエクスポートは画面より多くの行を分析できますが、匿名化クエリはエクスポートにも含まれません。「表に出ていない＝存在しない」と読まないことが重要です。

主キーワード・H1・記事の役割を対応付ける

実績データだけをAIに渡すと、単語の見た目が似ているというだけで競合と判定されがちです。精度を大きく左右するのは、記事側の設計情報をまとめた台帳です。スプレッドシートでもMarkdownの表でも構いませんが、次の列を持たせます。

url,h1,primary_kw,secondary_kw,covers,not_covers,role,indexable,canonical,updated
/blog/csv-import-basics/,CSVインポートの基本,CSV インポート,csv 取り込み 方法,形式の決め方と最小手順,文字コードのエラー対処,basic,true,self,2026-05-12
/blog/csv-encoding-error/,CSVの文字化けを直す,CSV 文字化け,csv utf-8 shift_jis,文字コードの判定と再保存,インポート全体の流れ,howto,true,self,2026-06-30
/blog/csv-import-tools/,CSVインポートツール比較,CSV インポート ツール,csv 一括登録 ツール,選定基準と比較軸,各ツールの詳細な操作手順,comparison,true,self,2026-07-02

not_covers（扱わない範囲）は記事同士の意図した境界を表すために有効です。ただし、台帳に「扱わない」と書くだけで書き分けが成立するわけではありません。実際のタイトル、冒頭、見出し、本文、内部リンクがその境界に沿っているかを候補ごとに確認します。indexable と canonical も記録し、同一内容のパラメータURLなど、記事企画ではなく正規化で扱うべき技術的な重複を分けます。

roleには basic、howto、comparison、troubleshooting のように、サイト内で統一した役割名を入れます。roleが同じで primary_kw も近い2本は、同一意図である可能性が高い組み合わせです。台帳は記事を新規公開するときに1行追加する運用にしておくと、調査のたびに作り直す必要がなくなります。キーワードの割り当てそのものの決め方は「AIキーワード調査」で解説しています。

AIで競合候補を分類する

同一意図・近接意図・別意図へ分ける

最初にスプレッドシートやSQLで、同じqueryに2つ以上のURLがある行を抽出し、URLペア、重複query、重複数、表示回数を計算します。この集計はAIに任せず、元データから再現できる処理にします。その候補表と記事台帳をAIに渡し、注目すべき組の意図を分類させます。分類の定義は先に固定しておきます。

same_intent（同一検索意図）：主要queryの構成がよく似ており、台帳と本文でも primary_kw と covers が実質同じ。統合か廃止の検討対象。
near_intent（近接意図）：一部のqueryが重なるが、台帳上は上位概念と下位概念の関係にある。書き分けで解決できることが多い。
different_intent（別意図）：queryの重なりが少なく、covers が明確に異なる。原則として手を入れない。

根拠queryとURLを必ず出力させる

次のプロンプトはそのままコピーして使えます。3つのデータの貼り付け位置だけ差し替えてください。

あなたはSEOの分析担当です。以下の3つのデータを突き合わせ、
同じ検索語句で競合している可能性のあるURLの組を分類してください。

【データA】query-page実績（期間・検索タイプ・国・デバイスを固定）
query,page,clicks,impressions,ctr,position
（ここに貼り付け）

【データB】元データから機械的に作った候補ペア
url_a,url_b,overlap_queries,overlap_query_count
（ここに貼り付け）

【データC】記事台帳
url,h1,primary_kw,secondary_kw,covers,not_covers,role,indexable,canonical,updated
（ここに貼り付け）

【分類ルール】
- データBにあるURLペアだけを対象にする
- 各組を same_intent / near_intent / different_intent に分類する
  - same_intent: 主要queryの構成がよく似ており、primary_kwとcoversも実質同じ
  - near_intent: 一部のqueryが重なるが、台帳上は上位概念と下位概念の関係
  - different_intent: queryの重なりが少なく、coversが明確に異なる
- データBにないURLペアを追加しない
- データCのnot_coversは意図した設計として参照するが、
  実際の本文確認なしに境界が守られていると断定しない
- データAに存在しないqueryを推測で補わない
- 統合・削除・リダイレクトなどの処置は提案しない。分類と根拠までにとどめる

【出力】次の列を持つ表を、confidenceの高い順に並べて出力する
url_a, url_b, classification, overlap_queries, overlap_query_count,
evidence, confidence(high/mid/low), needs_human_check

- overlap_queriesにはデータAに実在するqueryだけを最大5件書く
- evidenceには「どのqueryで、どちらのURLが、どの順位帯だったか」を一文で書く
- 判断材料が足りない組はconfidence=lowとし、
  needs_human_checkに不足している情報を書く

根拠queryとURLを必ず出させるのは、検算のためです。出力後は全行について、URLペアと overlap_queries が候補表および実績CSVに存在するかを機械的に照合します。一部だけの目視確認で、統合や削除の判断に進んではいけません。存在しないqueryが混じっていたら、その出力は実行判断に使わず、入力とプロンプトからやり直します。

また、処置の提案を禁止しているのは、AIが「統合してください」と書くと、それが結論のように読めてしまうためです。分類は候補出しであり、統合するかどうかは次章のデータを見てからでないと決められません。外部のAIサービスへデータを渡す場合は、公開済みURLと公開されている見出しなど、外に出しても問題のない情報だけに絞ります。

URLごとの処置を決める

維持・統合・差別化・廃止を選ぶ

分類がsame_intentやnear_intentだった組について、4つの処置から1つを選びます。

処置	選ぶ条件	実施手順	確認項目
keep（維持）	別意図。それぞれ固有のqueryでクリックを得ており、順位も安定している	台帳に「意図的な併存」と記録し、H1とリード文の差が読者に伝わるかだけ点検する	次回調査でqueryの重なりが増えていないか
merge（統合）	同一意図。内容の大半が重複し、片方を残しても失う情報がない	旧URL固有の情報を残す側へ統合 → 内容が同等の新URLへ恒久リダイレクト → canonical・内部リンク・hreflang・サイトマップを最終URLへ揃える	重要な外部リンクの更新依頼が必要か／リダイレクトが1段で最終URLへ到達するか
differentiate（差別化）	近接意図。どちらにも固有のqueryと需要があり、統合すると記事が長くなりすぎる	読者の課題と到達点を分け、本文の担当範囲を再設計したうえで、H1・見出し・冒頭・内部リンクを揃える	改稿後にqueryの重なりが減り、各URLが自分の主queryで上がったか
retire（検索対象から外す／廃止）	固有の価値や成果がなく、今後も検索流入を担わせない。統合先の有無と、ユーザー向けにページを残す必要は別に判断する	明確に対応する移転先があれば恒久リダイレクト。代替がなく削除するなら404または410。ユーザー向けには残し検索結果だけから外すならnoindex	無関係なURLへ転送していないか／noindexページをrobots.txtでブロックしていないか／リンクとサイトマップを更新したか

迷ったときはdifferentiateを先に試します。統合と廃止は元に戻しにくい一方、書き分けは記事を残したまま検証できるためです。

traffic・link・収益・更新性を確認する

mergeを選んだあと、どちらを残すかは次の4点で決めます。片方だけを見て決めないでください。

traffic（流入）：判断に足る表示回数がある直近期間と、季節性を比較できる前年同時期などのクリック数
link（被リンク）：外部から参照されているURLとリンク先の文脈。重要な参照元は可能なら最終URLへ更新を依頼する
収益：申込や資料請求などの成果が発生している導線が乗っているか
更新性：今後も情報を更新し続ける予定があるURLか

この4点が割れることは珍しくありません。流入は少なくても、外部参照やコンバージョンで価値があるURLを残し、内容だけをもう一方から移す判断もあり得ます。AIの分類結果に「どちらを残すべきか」を書かせていないのは、この4点と本文の固有価値が入力からは見えないためです。

統合の向きを決めたら、正規URLの扱いを確認します。Google検索セントラルは、リダイレクトを「リダイレクト先が正規URLになるべきという強いシグナル」、rel="canonical" を「指定したURLが正規URLになるべきという強いシグナル」、サイトマップへの掲載を「弱いシグナル」と説明しています。これらは組み合わせると効果が高まる一方、いずれも指示ではなくシグナルであり、正規URLの指定自体が必須というわけでもありません。重複または非常に似たページで正規URLを明示する利点として、個々のURLに対して持っているシグナル（そのURLへのリンクなど）を1つの優先URLに統合できること、重複ページのクロールに時間を使わずに済むことが挙げられています。

解消後の影響を追跡する

redirect・canonical・内部リンクを点検する

リダイレクトの種類は結果が変わります。公式ドキュメントでは、301や308などの恒久リダイレクトは検索結果に新しいリダイレクト先を表示するのに対し、302や307などの一時リダイレクトは検索結果に元のページを表示し、リダイレクト先が正規URLになるシグナルとしては使われないと説明されています。統合を反映させたいのに一時リダイレクトを設定すると、意図した結果になりません。恒久リダイレクトは、後で元に戻さないと確信できるときに使います。

実装方法にも優先順位があります。サーバー側のリダイレクトが最も信頼性が高く、meta refresh は0秒なら恒久、0秒より長い遅延があると一時として扱われます。JavaScriptによるリダイレクトは、サーバー側や meta refresh が使えない場合の最終手段と案内されています。

retireでnoindexを使う場合の注意点も公式に明記されています。noindexルールは <meta name="robots" content="noindex"> か、HTTPヘッダーの X-Robots-Tag で指定します。ただしルールが有効に働くには、そのページがrobots.txtでブロックされていないことが必要です。ブロックされているとクローラーがnoindexルール自体を見られないため、ページが検索結果に表示され続ける可能性があります。「まとめてrobots.txtで塞ぐ」という対応が逆効果になるのはこのためです。

ページを削除する場合、明確に対応する移転先がなければ404または410を返します。関連性の低いトップページや一覧へまとめてリダイレクトすると、soft 404として扱われる可能性があります。noindexは「ページを残したまま検索結果から外す」方法であり、削除やURL統合の代用ではありません。また、サイト内の正規URLを選ばせる目的でnoindexを使うことも推奨されていません。

最後に内部リンクを点検します。統合前のURLを指したままの内部リンクが残ると、読者はリダイレクトを経由することになり、リダイレクトが多段になっている場合は取り違えも起きます。旧URLを参照している箇所を洗い出して最終URLへ張り替え、台帳の該当行も更新してください。リンク側の監査手順は「AI内部リンク分析」にまとめています。

query-page対応の安定を再計測する

処置の効果は、順位が上がったかどうかではなく、queryとURLの対応が安定したかで判断します。再計測は準備段階とまったく同じ条件（検索タイプ、期間の長さ、国、デバイス）で行い、比較機能で処置前後の同じ長さの期間を並べます。

統合したqueryで、表示されるURLが1本に収束したか
そのqueryのクリック数が、処置前の2本の合計を下回っていないか
差別化した組で、重なっていたqueryの数が減ったか
それぞれのURLが、台帳の primary_kw で表示されるようになったか
意図せず表示回数を失ったqueryがないか

再クロールとインデックスの更新には時間がかかるため、処置直後の短いデータで結論を出さないでください。固定の最低日数はなく、Search Consoleで変更後のURL処理を確認し、判断に足る表示回数が溜まってから、同じ長さ・同じ曜日構成・近い季節条件の期間を比較します。前後比較だけでは検索需要や検索結果の変化と切り分けられないため、未変更の近い記事群も参考にします。判定が付かない場合は、変更点を1つに絞ってもう1期間観測します。AI検索側での見え方も含めた全体像は「AI検索時代のSEO」を参照してください。

よくある失敗

平均掲載順位だけで判断する

プロパティ全体の平均掲載順位は自サイトの最上位URLの数字です。2本目が下位で表示されていても数字には現れないため、「順位は問題ないからカニバリはない」という結論になりがちです。必ずページ単位に分解して確認します。

AIの分類をそのまま実行に移す

AIは表の見た目の類似から same_intent を出すことがあります。根拠queryを実績データで検算せず、被リンクや収益も見ないまま統合すると、成果の出ていたURLを消してしまいます。分類は着手順を決めるための候補で、実行の許可ではありません。

統合したのに内部リンクと台帳を更新しない

リダイレクトを設定して満足すると、旧URLを指す内部リンクと、旧URLの行が残った台帳が次回調査のノイズになります。処置の完了条件に「内部リンクの張り替え」と「台帳の更新」を含めてください。

よくある質問

同じqueryで2つのURLが出たら必ず直すべきですか？

いいえ。queryの重複だけでは異常と断定できません。十分なデータがある複数期間でシグナルが続き、本文を読んでも同じ課題と到達点を扱っていると確認できたときに処置を検討します。それぞれが固有のqueryで成果を出しているなら、意図的な併存として記録します。

AIに記事本文を全部読ませたほうが精度は上がりますか？

候補抽出には台帳が効きますが、台帳は設計上の宣言にすぎません。AIで候補を絞ったあと、処置を決める全ペアについて実際のタイトル、冒頭、見出し、本文、内部リンクを確認してください。

Search Consoleだけですべてのカニバリを見つけられますか？

できません。プライバシー保護のために匿名化されるqueryがあり、画面の行数や内部的な制限によってテーブルに出ないqueryもあります。一括データエクスポートは画面より多くの行を扱えますが、匿名化queryまで得られるわけではありません。

noindexにすればカニバリは解消しますか？

そのページを検索結果から外すことはできますが、内容と被リンクは活かされません。統合する価値のある内容が残っているならmergeを先に検討します。またnoindexは、対象ページがrobots.txtでブロックされているとクローラーがルールを読めず、機能しない点にも注意してください。

まとめ

カニバリのチェックは、同じqueryに複数URLが出ているかを探す作業ではなく、query-pageの実績と記事の設計情報を突き合わせて、意図が重なっている組だけを絞り込む作業です。判定matrixで同一意図・近接意図・別意図に分け、keep・merge・differentiate・retireの4択から処置を選びます。

AIが担うのは、2つの表を突き合わせて候補を並べる部分だけです。根拠queryとURLを必ず出力させて検算し、どちらを残すかは流入・被リンク・収益・更新性という、AIからは見えない情報で人が決めてください。処置後は同じ条件で再計測し、順位ではなくqueryとURLの対応が安定したかで効果を判定します。