カニバリゼーションが1日140件から561件に
6月下旬から8月中旬にかけて、同じ日にamicited.comの2つ以上のURLがランクインしたクエリ数が、約140件からピークの561件にまで増加しました。最悪の時期には、カニバリズされたクエリがサイトの全ランキングクエリの11.6%を占めていました。
そこで、Claude CodeをサイトのHugoリポジトリに接続し、AmICited SEO MCPサーバーと連携させて、キーワードカニバリゼーションを発見し、各ケースへの対応を判断し、サイトが配信する全16言語にわたって修正を適用するよう指示しました。
以下がその手法を最初から最後まで解説した内容です：使用したプロンプト、エージェントが実際に呼び出して実行した内容、そして私が依頼していなかったのに浮上した3つの発見についてです。まだ本番適用はしていないため、これは結果報告ではなく手法のウォークスルーとしてご覧ください。28日後の再チェックは後日実施予定です。
キーワードカニバリゼーションとは、同一サイト内の複数のページが同じ検索クエリを競合することで、Googleが表示するページを切り替え続け、一つの強いページほどのランキングを得られなくなる現象です。これは自サイトのURL間の内部競合であり、Claude Codeが真価を発揮するSEO業務の一つです。データはSearch Consoleにあり、修正対象はリポジトリにあり、エージェントが両方を同時に扱えるからです（AIコンテンツカニバリゼーション — AI生成の回答が本来ページが得るはずのクリックを奪う現象 — とは混同しないでください）。詳細な解説については、キーワードカニバリゼーション問題の特定と修正方法について別途まとめています。
セットアップ
- リポジトリ： 私のHugoサイトのリポジトリ。500以上の英語ブログ記事があり、それぞれが他の15言語に翻訳されています。
- データ： AmICited MCPサーバー。Google Search ConsoleベースのSEOレポート（カニバリゼーションを含む）をClaude Codeが直接呼び出せるツールとして公開します。
- エージェント： 自動モードで動作するClaude Code (Opus 5.5)。新しいブランチ
seo/cannibalization-oct-2026上で実行され、差分を確認するまでは何もコミットされません。
MCPサーバーへの接続は一度限りのOAuth手順です。/mcp を実行し、サーバーを選択し、ブラウザでワークスペースを承認するだけで、以降はClaude Codeから呼び出せるようになります。
最初に知っておくべきこと：私のAmICitedワークスペースには複数のドメインが含まれています。作成したすべてのプロンプトでamicited.comを明示的に指定し、最初のプロンプトではClaude CodeにどのドメインIDを選択したか教えるように指示しました。このステップを省略すると、エージェントが正しく推測するのに任せることになります。
ステップ1：カニバリゼーションを発見し、ノイズを除外
AmICited MCPサーバーを使用して、amicited.comドメインのみのキーワードカニバリゼーションレポートを取得してください（ワークスペースには複数のドメインがあります。amicited.comのものを選び、使用したドメイン／プロジェクトIDを教えてください）。Google Search Consoleのデータ、過去90日間を使用してください。最初に呼び出すMCPツールをリストアップしてください。ノイズを除外：検索オペレーター（site:、inurl:）、純粋なブランド／ナビゲーションクエリ（「amicited」、「am i cited」）、およびインプレッション数50未満のクエリ。実際のカニバリゼーションクラスターの上位15件を表形式で表示してください […] ファイルは編集しないでください。
ノイズフィルターが必要な理由は、生のレポートの実態にあります。私のダッシュボードの「最悪の競合」リストのトップは、site:www.amicited.com（417 URL）、site:amicited.com（277 URL）、ブランド名だけのクエリamicited（193 URL）でした。これはカニバリゼーションではありません。私自身（そしておそらくチームも）がサイトを直接検索しているだけです。これをカニバリゼーションクラスターとしてカウントするツールは、間違ったものをカウントしています。
実行した内容は順に以下の通りです：
list_domains— ワークスペース内のドメインからamicited.comを検索（使用したドメインIDを報告）。search_tools— カニバリゼーションツールがデフォルトのツールリストに含まれていなかったため、説明文で検索。describe_tool— 2回実行し、カニバリゼーションクエリ用の2つのツールの入力スキーマを確認してから呼び出し。- クラスターリストツール — 1回実行：90日間のウィンドウにおける10,000以上のカニバリズされたクエリの中から、重要度順で上位200件を取得。
- クエリ別詳細ツール — 15回実行（クラスターごとに1回）、競合するURLとその日次の順位を取得。1つのレスポンスが大きすぎてインライン表示できなかったため、出力をディスクに保存し、
jqで要約。
その後フィルタリングを実行しました。上位200件のうち約30件がsite:クエリでした。さらに自律的に2つのフィルターを追加し、その旨を報告しました：数千インプレッションでクリックゼロの長いプロンプト状のクエリ（AIトラッキングツールのプロンプトをそのままコピーしたように見えるもの）、およびボットトラフィックと思われるコード風のクエリです。
出力の中で最も有用だった行は表そのものではなく、以下の一文でした：
これらのほとんどは実際のトラフィック分割ではありません。上位15クラスターのうち9つでは、1つのURLが97%以上のインプレッションを獲得し、残りはわずかです。
上位15件の「カニバリゼーション」クラスターのうち9件は、実質的に1つのページがすべての仕事をしており、別のURLが数日間表示されただけでした。単に重要度順に並べただけのレポートではそれがわかりません。URLごとの分割を読むことで初めてわかるのです。
ステップ2：修正の前に診断する
表の中でインプレッションがページ間で実際に分割されているクラスター（1つのURLが97%以上のものを除く）について、competing pagesをcontent/内で開き、それぞれを分類してください：CONSOLIDATE、DIFFERENTIATE、FIX-TECHNICAL、LEAVE。優位ページはクリック数、次に順位、そしてそのページへの内部リンク数で選んでください。このHugoサイトが現在どのようにリダイレクトを処理しているか確認してください。まだ何も編集しないでください。各行に1行の理由を添えた判断表を出力してください。
このステップではMCP呼び出しは一切行いませんでした。約20のシェルコマンドでした：競合するMarkdownファイルの読み取り、各ページへの内部リンク数のカウント、テーマのテンプレートの読み取り、実際のサイトに対するcurlの実行による、リポジトリ上だけでなく本番環境で実際にリダイレクトとhreflangタグが何を返しているかの確認。
15クラスターのうち、マージが必要だったのは1件、ターゲット変更が必要だったのは1件、技術的修正が必要だったのは2件で、残りは何も必要ありませんでした。この比率こそが、私がエージェントに「これがカニバリゼーションレポートです」からいきなり「これが削除したページです」へと飛躍させてはいけないと考える主な理由です。
依頼していない3つの発見
1. 301リダイレクトルールが2ヶ月前から静かに機能しなくなっていました。 私のサイトには、Amplifyが提供する実際の301ルールを生成するスクリプトがあります。Claude Codeは出力ファイルが存在しないことに気づき、gitの履歴を遡って、5週間前に21,000以上のファイルに影響する「コンテンツ更新」コミット内で削除されていたことを発見しました。大量同期の巻き添え被害であり、誰かが意図的に決断したものではありませんでした。実際のサイトで確認したところ、どのルールも有効になっていませんでした（移動したURLが、リダイレクトがあるべき場所で404を返していました）。それ以来、サイト上のすべての「リダイレクト」は実際にはHugoのエイリアス（metaリフレッシュ付きの200ステータスページ）であり、本当の301ではありませんでした。
2. それは理論上の話だけではありませんでした。 7月に移動したページの古いURLが、Search Consoleに独自に表示され続けていました。移動から2ヶ月半後も188インプレッションを獲得し、増え続けていました。Googleが依然としてインデックスし続けるmetaリフレッシュのスタブページ——これこそ、壊れたエイリアス設定が実際に引き起こす現象です。
3. 自身の誤りを自分で修正しました。 ステップ1では、あるページペアをhreflangの問題の可能性としてフラグ付けしていました。翻訳版が英語のオリジナルをランキングで上回っていたためです。ステップ2では、実際のHTMLを取得し、hreflangタグがGoogleが要求するように絶対URLで相互参照されていることを確認し、最初に言ったことを修正したと報告しました。この判断はFIXからLEAVEに変わりました。レポートに疑問が提示されないまま放置される自信満々の誤った回答をもらうより、はるかに良い結果です。
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
ステップ3：16言語で修正を適用
承認します。このブランチで判断表を適用してください。コミットはしないでください。1) CONSOLIDATE […] 事実を作り出したりemダッシュを追加したりせずに、そのページが存在するすべての言語で劣位ページを削除し、各言語対応の優位ページのaliasesに古いURLを追加し、content/全体で劣位ページへの内部リンクをすべて張り替えてください。2) DIFFERENTIATE […] 全言語で、優位ページへのコンテキストリンクを1つ追加してください。3) FIX-TECHNICAL: git履歴を確認して、static/_redirectsの削除が意図的だったかどうかを調べてください。偶発的なものだった場合は再生成してください […] 意図的だった場合は復元せず、その旨を教えてください。
マージの前に事実確認が行われました。廃止されるページには優位ページにはないセクション（競合ツールの紹介、製品ランキング機能、無料トライアルのまとめ）がありました。これらを引き継ぐ前に、Claude Codeは各ベンダーの実際のサイトを取得し、情報がまだ正確かどうかを確認しました。
記載されていたツールの1つは数週間前に買収され、新規登録が終了していたことが判明しました。そのため、その情報は現在の事実としてそのままコピーされるのではなく、修正として反映されました。また、廃止ページの別のツールに関する価格主張が優位ページで既に確認済みの数値と矛盾していたため、確認済みの数値が保持され、古い情報はマージに含まれませんでした。
FIX-TECHNICALのケースでは、リダイレクト削除が意図的だったかどうかを確認してから何かに手を付けました。偶発的であることを確認し（削除を含む一括コミットはリダイレクトとは無関係の数千のファイルに影響していた）、ルールを再生成し、マージの影響を受けるページと古いアドレスでまだインプレッションが表示され続けている移動済みURLに対して実際の301を追加しました。CONSOLIDATEとDIFFERENTIATEについては、影響を受けるページが存在するすべての言語で同じ変更を繰り返し（英語だけでなく）、その後フルプロダクションビルドを実行して何も壊れていないことを確認しました。
次のステップ
新しいコンテンツを公開した後も、仕事は終わりではありません。それは始まりに過ぎません。どのURLが互いに静かに競合しているのか、どのURLをマージする必要があるのか、どのURLが単に技術的修正を必要としているのかを正確に把握することが、コンテンツが自分自身と戦わないようにするための鍵です。今回のパスの内容はまだ本番適用されていません。28日後の再チェックで、カニバリズされたクエリ数が実際に減少するかどうかを確認する予定です。
あなたのドメインでこのようなカニバリゼーションレポートを確認したい場合は、お問い合わせ の上、詳しくご説明します。
