記事100本超のSEO担当者向け｜意味検索（pgvector）で類似記事を自動検出し統合・共存を判定する3層診断

結論：言葉が違っても意味が近い記事は自動検出でき、統合するかは「意味近接3層診断」で切り分けます

「SEO対策」と「検索エンジン最適化」は同じ意味ですが、キーワード一致の検索では別記事として扱われます。ATKが使うpgvectorの意味検索は、記事の内容そのものを数値化して比較するため、表現が違っても近い記事を自動で見つけます。ただし、検出された組み合わせをすべて統合するのは誤りです。

この記事では、検出の仕組みに加えて、統合・差別化・共存を切り分ける判定表（意味近接3層診断）と、工数・売上がどの経路で動くかの試算式まで示します。意味検索は「重複を見つける道具」であり、「統合を決める道具」ではありません。

この記事は誰向けか：記事が100本を超え、カニバリ確認が手作業のまま止まっている運用者です

次のような立場・規模の方が読むと、そのまま自社の運用に当てはめられます。

• BtoB SaaS事業会社のインハウスSEO担当者（1〜3名体制）：記事本数が100〜500本に達し、月に10本前後の新規とリライトを回している。過去記事の一覧は持っているが、どれとどれが競合しているかは記憶と勘に頼っている。
• EC事業会社のオウンドメディア責任者：商品カテゴリごとに「選び方」「比較」「おすすめ」記事が積み上がり、似た構成の記事が量産されている。担当ライターが複数いるため、同じ検索意図の記事が別々に発注されている。
• コンテンツ制作会社のディレクター：複数クライアントのサイトを横断で見ており、1サイトあたりに割ける確認時間が限られている。納品後に「既存記事と被っている」と指摘されるのが最大のリスク。

共通するのは、記事本数の伸びに対して確認工数が線形に増え、手作業が限界に達している状態です。逆に、記事が数十本以下でチーム全員が全記事の中身を覚えている段階では、意味検索の導入効果は限定的です。

よくある失敗：表現の違う類似記事を見逃し、同じキーワードで両方の順位が下がる

実務で起きやすい見落としを、状況ごとに整理します。いずれも「一般論としての重複」ではなく、判断のどこで間違えたかが分かる形で書いています。

• 言い換えタイトルで重複チェックをすり抜けるパターン：記事本数が100本を超えた段階で、キーワード一覧のフィルタ機能だけで重複確認をしている。「転職エージェント 選び方」と「人材紹介会社 比較 就活」は文字列が一致しないため別テーマとして通過し、公開後に同一クエリで両方が中位に張り付き、どちらも上位に上がらなくなる。
• スコアが高いという理由だけで統合してしまうパターン：類似度が高い組み合わせを機械的に統合し、片方をリダイレクトした結果、比較検討段階の読者向けだった記事が消え、指名系クエリの受け皿が無くなる。意味は近くても購買フェーズが違う記事は、統合ではなく書き分けが正解になる。
• ライター発注時に重複が生まれるパターン：月次のキーワード計画を作る時点で既存記事との照合をしていないため、外注に出した記事が納品されてから重複に気づく。原稿料と編集工数が丸ごと戻らないコストになる。
• 内部リンクを「関連しそうな記事」で貼ってしまうパターン：担当者の記憶を頼りにリンクを貼るため、リンク先が偏る。新しく増えた記事にはリンクが集まらず、古い記事だけが内部リンクを独占する構造になる。
• 統合後に効果検証をしないパターン：統合・リダイレクトを実施したが、対象クエリの順位とクリックを記録していないため、統合が正解だったのか判断できない。次の統合判断も勘のままになる。

失敗の多くは「検出漏れ」ではなく「検出後の判断基準が無いこと」から起きます。

意味検索（pgvector）は何をしているのか：記事の意味を座標に変換して距離を測っています

pgvectorはPostgreSQL上で動作する拡張機能で、テキストを「ベクトル」と呼ばれる数値の配列に変換し、その距離から意味の近さを測ります。イメージとしては、記事の意味を地図上の座標に置き換え、近い場所にある記事を探す仕組みです。

そのため「転職 エージェント 選び方」と「就職活動 人材紹介会社 比較」のように使っている単語が違っても、座標が近ければ意味的に似た記事として検出されます。キーワード一致では見逃す言い換え・類義語の重複を、意味レベルで拾えるのが従来手法との違いです。

比較表：キーワード一致と意味検索（pgvector）はどこが違うのか

観点	キーワード一致	pgvector意味検索
検索の基準	同じ言葉が含まれているか	意味・文脈が近いか
類義語・言い換え	別の記事と判断される	近い記事として検出できる
カニバリ検出の精度	表現が違うと見逃しやすい	表現が異なっても検出できる
内部リンク提案	設定したキーワードに依存する	本文の文脈をもとに候補を提示
運用の手間	命名ルール・タグ整備を人が維持する	公開・下書き時に自動でベクトル生成
苦手なこと	言い換え・表記ゆれ	読者層や購買フェーズの違いの判定

意味検索は「同じ話題か」を判定できますが、「同じ読者に向けた記事か」までは判定できません。この穴を埋めるのが次の3層診断です。

意味近接3層診断：検出結果を統合・差別化・共存に振り分ける判断軸

本記事では、意味検索の結果を実務の意思決定に落とすための枠組みを「意味近接3層診断」と呼びます。第1層で機械が拾い、第2層と第3層で人が判断する、という役割分担が前提です。

3層それぞれで何を見るか

層	見るもの	判断の問い	担当
第1層：意味近接	記事同士のベクトル類似スコア	本文の主題そのものが重なっているか	システム（自動）
第2層：検索意図	想定クエリ、実際に流入しているクエリの重なり	読者の同じ疑問に答えているか	SEO担当者
第3層：読者フェーズ	読者層・購買フェーズ（認知／比較検討／指名）	同じ人が同じタイミングで読むか	編集・マーケ責任者

類似スコアの高低をどこで区切るかは、サイトの記事量やジャンルによって変わります。閾値は絶対値で決め打ちせず、自社の記事群でスコア順に並べたうえで、上位から目視で確認して「実務上まとめるべき組み合わせ」がどこまで続くかで調整します。そのため本表では高・中・低の相対表現で扱います。

判定マトリクス：3層の組み合わせで打ち手が決まります

第1層 意味近接	第2層 検索意図	第3層 読者フェーズ	判定	取るべきアクション
高	一致	同じ	統合	強い方に本文を集約し、弱い方を301リダイレクト。旧URLへの内部リンクも張り替える
高	一致	異なる	差別化	「入門向け」「比較検討向け」にタイトル・見出し・CTAを書き分け、相互に内部リンクを張る
高	不一致	—	共存	タイトルと見出しの重複語を整理し、被リンク・内部リンクの向き先を分ける
中	一致	同じ	保留（監視）	対象クエリの順位とクリックを一定期間記録し、両方が伸び悩むなら統合へ移す
中	不一致	—	内部リンク候補	関連記事・本文中リンクとして接続し、回遊導線に使う
低	—	—	対応不要	そのまま運用。クラスタ設計の対象外とする

統合を実行する前のチェックリスト

確認項目	確認方法	当てはまらない場合の扱い
両記事が同じクエリで実際に競合しているか	検索パフォーマンスで対象クエリの掲載URLを確認	競合していないなら共存（統合しない）
片方に外部リンク・被リンクが集中していないか	被リンクの本数と参照元を確認	集中している方を残す側にする
コンバージョン導線が片方にしか無いか	各記事の問い合わせ・資料DL導線を確認	導線がある方を残し、無い方を吸収する
読者フェーズが本当に同じか	導入文・想定読者の記述を読み比べる	異なるなら統合ではなく書き分け
統合後の効果測定の準備があるか	統合前の順位・クリックを記録したか	未記録なら、記録してから実行する

3層すべてが「統合」を指したときだけ、URLを消す判断をします。

自社の状況と照らす3つの場面

• 「選び方」記事と「おすすめ比較」記事が並存している状態なら：第1層は高、第2層も一致しやすい一方、第3層で認知段階と比較検討段階に分かれることが多く、判定は「差別化」に落ち着きます。片方を消すと比較検討クエリの受け皿が消えます。
• 担当者が入れ替わり、同じテーマの記事が別の言い回しで再作成されているパターンでは：第1層が高く、第2層・第3層とも重なるため「統合」に該当します。新しい方に集約し、古い方をリダイレクトするのが基本形です。
• 用語解説記事と導入手順記事が近いスコアで出るパターンでは：第2層で検索意図が「知りたい」と「やりたい」に割れるため「共存＋内部リンク」が妥当です。この組み合わせを統合すると、記事が長くなるだけで両方の検索意図に中途半端になります。

ATKでは意味検索がどう動くか：公開のたびに自動でベクトルが更新されます

• ベクトル生成：記事の下書き・公開のタイミングで、本文の意味を表すベクトルを自動生成して保存します。担当者の操作は不要です。
• 類似度スコアの算出：既存の全記事と対象記事のベクトルを比較し、意味の近さをスコアとして出します（3層診断の第1層に相当）。
• カニバリ候補の通知：スコアが一定以上の組み合わせを候補として提示します。ここから第2層・第3層の人の判断に進みます。
• 内部リンク候補の提案：意味的に近い記事をリンク先候補として提示します。記憶に頼らないため、新しい記事にもリンクが行き渡りやすくなります。
• 関連記事の自動選択：記事末尾の関連記事をスコアに基づいて選びます。

自動化されるのは検出と候補提示までで、統合・削除の実行は人の判断を通す設計です。

売上と工数はどの経路で動くか：2本の式に自社の数字を入れて計算します

効果は「削減できる工数×人件費単価」と「カニバリ解消後のクリック集中→問い合わせ→受注」の2経路で発生します。以下の数値はすべて仮置きです。自社の数字を入れて再計算してください。

経路1：類似チェックにかけている工数の削減

月間削減額 ＝ 1本あたりの類似記事チェック時間（　　時間） × 月間の新規・リライト本数（　　本） × 担当者の時間単価（　　円）

仮に1本あたり0.5時間、月20本、時間単価4,000円と置くと、0.5 × 20 × 4,000 ＝ 80,000円／月、年換算で96万円になります。この3つの数字は自社の実測値に置き換えてください（実測が無い場合は、直近1か月のチェック作業を記録することから始めます）。

経路2：カニバリ解消によるクリック集中から受注まで

月間売上増 ＝ 統合後に1本へ集中する対象クエリの月間クリック増分（　　クリック） × 記事からの問い合わせ率（　　％） × 商談化・成約率（　　％） × 平均受注単価（　　円）

仮に月300クリック増、問い合わせ率1.0％、成約率20％、平均受注単価300,000円と置くと、300 × 0.01 × 0.2 × 300,000 ＝ 180,000円／月です。クリック増分は「統合対象クエリで2URLに分散していたクリック数」を統合前に記録しておくと、後から検証できる形で置けます。

投資回収期間の見方

回収期間（か月） ＝ 導入・運用コスト（　　円） ÷ （経路1の月間削減額 ＋ 経路2の月間売上増）

経路2は順位変動に左右されるため、稟議では経路1（工数削減）だけで回収できるかを先に確認し、経路2は上振れ要因として扱うのが安全です。ここに書いた数値はすべて計算方法を示すための仮の値であり、実績値ではありません。

他機能とどうつながるか：検出の次に必要な設計を補います

意味検索は入口であり、その後の整理・設計と組み合わせて初めて成果につながります。

統合・差別化・リダイレクトの判断手順を細かく詰めるときはカニバリ検出の活用ガイド、リンクの張り替えを含む全体設計は内部リンク最適化ガイドが対応します。近い記事をクラスタとして束ね直す場合はピラーページ戦略とトピッククラスターの構築を、統合作業の実行順とスケジュール化はリライトSprintの運用フローを参照してください。回遊が増えた後のコンバージョン導線の見直しはCRO Copilotの活用、統合後の原稿品質の確認はカクンダーZの品質評価で行えます。

運用時の注意点：スコアだけで意思決定をしないことが前提です

• 類似スコアは参考値です：スコアが高くても、読者層や購買フェーズが異なれば共存できます。第2層・第3層を必ず通してください。
• 本文の厚みが精度を左右します：タイトルや見出しだけでなく、本文の情報量が少ない記事はベクトルが安定しにくく、スコアがぶれることがあります。
• 通知は「問題の発生」ではなく「整理の機会」です：件数が多い場合は、流入のあるクエリに関わる組み合わせから順に処理します。
• 内部リンク提案は候補として扱います：文脈に合うかを確認したうえで反映すると、読者にとって自然な導線になります。
• 導入すれば自動で順位が上がるものではありません：検出精度は記事データの質と量に依存し、成果は統合・書き分けの実行品質で決まります。

よくある質問

Q. pgvectorの意味検索を使うのに、特別な設定は必要ですか？

ATKの環境内で自動的に動作するため、利用者側での個別設定は不要です。記事を下書き・公開するたびに、バックグラウンドでベクトルの生成と比較が行われます。

Q. キーワードがまったく違う記事でも検出できますか？

検出できます。使われている単語が違っても、内容と文脈が意味的に近ければ類似記事として提示されます。これがキーワード一致との最大の違いです。

Q. 類似度スコアが何％以上ならカニバリと判断すべきですか？

絶対的な基準値はありません。自社の記事をスコア順に並べ、上位から目視で確認して「実務上まとめるべき」と感じる組み合わせがどこまで続くかを見て、社内の閾値として決めるのが現実的です。決めた後も記事本数が増えたら見直します。

Q. カニバリと判定された記事は統合すればよいですか？

統合・差別化・共存の3択です。本記事の意味近接3層診断で、検索意図と読者フェーズまで一致した組み合わせのみ統合します。判断の詳細はカニバリ検出ガイドで整理しています。

Q. 検索コンソールでの順位確認と意味検索は何が違いますか？

検索コンソール側は「すでに起きている競合」を結果から確認する手段で、意味検索は「公開前・公開直後に起こりうる重複」を先に洗い出す手段です。役割が違うため、3層診断では第1層に意味検索、第2層の裏取りに実測クエリを使います。

Q. 記事数が少ないうちから使う意味はありますか？

全記事の内容をチームが把握できている規模では、効果は限定的です。本数が増えて確認が記憶頼りになってきた時点、あるいは執筆担当が複数人になった時点が導入の目安になります。

まとめ：3層診断の結果で1つでも当てはまるなら、統合作業を始める前にご相談ください

意味検索は重複を見つけるところまでを自動化し、統合するか書き分けるかの判断は3層診断で人が決める——これが本記事の結論です。

ここまでのチェックリストと判定マトリクスを自社に当てはめて、（1）第1層で意味近接が高い組み合わせが手作業で捌ききれない件数残っている、（2）第2層・第3層の判断が担当者ごとにぶれて統合可否が決まらない、（3）過去に類似記事を統合してクリックを落とした経験がある——このうち1つでも当てはまる場合は、統合やリダイレクトを実行する前に一度整理することをおすすめします。

ご相談では、意味近接3層診断を自社の記事構成にどう当てはめるか、統合・差別化・共存の切り分け手順、経路1・経路2の式に自社数値を入れた試算の作り方を一緒に確認します。事前に用意いただくとスムーズなのは、記事一覧（URL・タイトル・主要キーワード）、直近の順位とクリックの推移、月間の制作・リライト本数、担当者の時間単価の4点です。

ATKへのご相談はこちら