AIキーワードクラスタリング：検索クエリを記事・シリーズ・内部リンクに整理する

Astro、Docker、Cloudflareに関する300行のqueryを含むkeywords.csvがあるとします。AIは42個のclusterに仮分類しましたが、人が確認するとcluster #1にastro seoとastro vs next.js for seoが一緒に入っていました。前者は手順を探す意図、後者は比較する意図です。一つの記事で両方を満たすのは難しいでしょう。

キーワードクラスタリングで起きやすい失敗はここにあります。AIは意味が近く検索意図が異なる語をまとめることがあり、複数の類似記事が同じ需要を奪い合うcontent cannibalizationのリスクを高めます。また、「キーワードのグループ」が並んでいるだけでは、新規記事にするのか、既存記事を更新するのか、FAQや内部リンクにするのかを判断できません。

以下では、GSC query、企画カード、既存記事を一つの表にまとめ、正規化と重複排除を行い、AIの仮分類後に人が確認します。最後に各clusterを新規記事、既存記事の更新、FAQ、内部リンク、discardへ割り当てます。対象は入力データ、重複排除、分類方法の比較、AI prompt、cluster map、アクション判断、内部リンク設計です。

1. キーワードクラスタリングの入力データをそろえる

入力は「AIが考えた語句」ではありません。自サイトのquery/pageデータ、企画カード、既存記事の一覧です。この3種類を組み合わせると、書く価値がある語、既存記事が受け止められる語、コミュニティで実際に使われる質問を区別できます。

入力データは次のように整理します。

データソース	フィールド	取得方法	注意点
GSC query/pageデータ	query, page, clicks, impressions, CTR, position	Search Console UI / Search Analytics API	APIのrowLimitはデフォルト1,000、1回の上限25,000。内部制限があるため全行は保証されず、top rowsが返る
企画カード	タイトル, 検索意図, 出典（Reddit/GitHub/競合）, 根拠	企画調査Agentの出力	出典の品質を人が確認する
既存記事	記事タイトル, URL, シリーズ, 公開日, 流入, ランクインquery	サイトDB / CMS	対応する既存記事とシリーズを記録する
quickWins指標	低CTR・高impressionのquery, 既存記事の更新候補	GSC quickWins分析	既存記事を更新する判断に使う

手順：

1. GSCのquery/pageデータを出力します。Performance reportのデフォルトは直近3か月ですが、タスクに合わせて期間を変更できます。
2. 企画調査Agentが出力した企画カードを統合します。
3. 既存記事、シリーズ、流入状況を一覧にします。
4. 低CTR・高impressionのqueryと既存記事の更新候補にquickWinsフラグを付けます。
5. query、検索意図の仮判定、出典、既存記事との一致、quickWinsフラグを含む統合表を出力します。

2. クラスタリング前にキーワードを正規化する

統合表には重複、類似表現、表記揺れが大量に含まれます。処理せずにAIへ渡すと、同じ検索意図を別の語として扱い、複数のclusterに分ける可能性があります。

重複排除のチェックリスト：

• 完全一致：astro seoとastro seo → 1行だけ残す
• 表記・設定の違い：docker host.docker.internal、docker host-gateway、docker 127.0.0.1 → 同じ意図の候補として記録し、人が確認する
• 同義語：cloudflare pricing、cloudflare 料金、cloudflare cost → 同じ意図として記録する
• 語形の違い：astro blogとastro blogs → 同じ意図として記録する

正規化ルール：

• 用語を統一：nextjs → next.js、cloudflare workers → Cloudflare Workers
• 大文字・小文字を統一：Astroとastro → astro
• 句読点を統一：astro, seoとastro seo → astro seo

検索意図の仮ラベル：

• 情報収集：how to, what is, guide, tutorial
• ナビゲーション：ブランド名、製品名、特定のURL
• 比較：vs, compare, alternative
• 購入：pricing, cost, buy, download

手順：

1. 統合表から完全一致の重複を削除します。
2. 表記揺れと同義語を見つけ、同じ意図の候補として記録します。
3. 用語、大文字・小文字、句読点を正規化します。
4. 各queryに情報収集、ナビゲーション、比較、購入の仮ラベルを付けます。
5. query、normalized_query、intent_tag、source、old_post_matchを含む正規化表を出力します。

3. 3種類のクラスタリング方法を比較する

方法を選ぶときは、コスト、精度、リスクのバランスを取ります。主な3種類は、それぞれ適した運用段階が異なります。

方法	コスト	精度	適した場面	リスク
SERP-based	高い。多数のSERP照会が必要で、bot対策に触れる可能性もある	高い。実際の検索結果を使い、ページを統合するかの判断を補助できる	公開済み記事、ページの重なり判定、SERP API予算がある運用	高コスト。SERP変動で安定性が下がる
Semantic	低い。embedding APIだけで実行できる	中程度。実際の検索意図を見落とし、異なる意図をまとめることがある	初期のトピックマップ、限られた予算、素早い仮分類	意味が近く意図が異なる語を誤ってまとめる可能性がある
Hybrid	中程度。意味ベースの仮分類 + SERP/GSC検証 + 人のレビュー	高い。コストと精度を両立しやすい	GSCデータとレビュー時間がある継続的なコンテンツ運用	人のレビュー工数が必要

推奨フロー：

• 小規模チーム / 初期：Semanticの仮分類 + GSC/page検証 + リスクの高いclusterを人が確認
• 中〜大規模チーム / 公開済み記事が多いサイト：意味ベースの分類、SERP/GSC検証、人のレビューを組み合わせたHybrid
• 十分な予算 + ページ統合の判断：SERP-based + 人のレビュー

私が使っているのはHybridです。まず意味の近さで仮分類し、GSC pageデータで既存記事が受け止めているqueryを確認し、最後に人が検索意図の衝突を解決します。

4. AIの出力形式を決めてクラスタリングする

正規化したキーワードをAIへ渡すときは、出力フィールドと検索意図の条件を明記します。次のpromptを使えます。

AI promptの例：

あなたはSEOコンテンツプランナーです。以下の正規化済みキーワードを検索意図ごとにclusterへ分類し、各clusterについて次を出力してください。
1. primary_intent（主な検索意図）
2. canonical_page（統合先のページ種別：new article / old post refresh / FAQ / discard）
3. suggested_action（推奨アクション）
4. internal_link_targets（リンクすべき既存記事またはシリーズ）
5. risk_notes（cannibalizationの可能性、人のレビューが必要か）

キーワード：
- astro seo
- astro vs next js for seo
- cloudflare pricing
- docker host.docker.internal
- docker host-gateway
...

JSON配列で出力してください。各clusterは次の形式にします。
{
  "cluster_id": 1,
  "keywords": ["astro seo", ...],
  "primary_intent": "情報収集 - チュートリアル",
  "canonical_page": "new article",
  "suggested_action": "Astro SEOチュートリアルを新規作成",
  "internal_link_targets": ["astro-guideシリーズ", "cloudflare-binduiシリーズ"],
  "risk_notes": "人のレビューが必要：astro vs next js for seoは比較意図なので統合しない"
}

cluster mapの例：

cluster_id	keywords	primary_intent	canonical_page	suggested_action	internal_link_targets	risk_notes
1	astro seo, astro blog seo	情報収集 - チュートリアル	new article	Astro SEOチュートリアルを新規作成	astro-guideシリーズ, cloudflare-binduiシリーズ	なし
2	astro vs next js for seo	比較	new article	AstroとNext.jsのSEO比較記事を新規作成	astro-guideシリーズ, nextjs-blog-series	なし
3	cloudflare pricing, cloudflare cost, cloudflare 料金	購入	old post refresh	既存のCloudflare料金記事を更新	cloudflare-binduiシリーズ	既存記事/cloudflare-pricingを更新する
4	docker host.docker.internal, docker host-gateway, docker 127.0.0.1	情報収集 - 設定	FAQ	Dockerシリーズの記事にFAQを追加	docker-practiceシリーズ	同じ意図の表記違いとしてFAQへ統合

人によるレビュー項目：

• 検索意図の混在：同じclusterにチュートリアルと比較のqueryがある → 分割する
• 既存記事との衝突：「新規記事」に割り当てられたclusterに関連する既存記事がある → 既存記事の更新またはFAQへ変更する
• 分けすぎ：一つの検索意図が複数のclusterに分かれている → 統合する
• まとめすぎ：異なる検索意図が同じclusterに入っている → 分割する

手順：

1. 正規化表をClaude、ChatGPT、社内モデルなどのAIクラスタリング処理へ渡します。
2. 上のpromptで仮分類します。
3. cluster mapを出力します。
4. 検索意図の衝突、既存記事との一致、分けすぎ、まとめすぎを人が確認します。
5. cluster mapを修正し、リスクの高いclusterに印を付けます。

5. 各クラスターを一つのコンテンツアクションへ割り当てる

クラスタリングの完了条件は「キーワードのグループ」ではなく、実行できるアクションです。私は次の判断表を使います。

判断軸	新規記事	ピラーページ	既存記事の更新	FAQ	内部リンク改善	discard
query数	多い（5+）	多い（5+）	少ない（1〜3）	少ない（1〜3）	少ない（1〜3）	1件
検索意図の差	大きい	大きい	小さい	小さい	小さい	小さい
対応する既存記事	なし	なし	あり	あり	あり	あり
競合の強さ	高い	高い	中程度	中程度	低い	低い
サイトテーマとの適合	高い	高い	高い	中程度	中程度	低い
独自価値を追加できる余地	大きい	大きい	小さい	小さい	小さい	なし
例	astro seoチュートリアル	astroシリーズ	cloudflare pricing	docker host.docker.internal	関連記事間のリンク	ブランド名の表記違い

アクションの定義：

• 新規記事：cluster内の同じ検索意図を一つのページで扱います。
• ピラーページ：シリーズのhubを作り、cluster内の他の記事へリンクします。
• 既存記事の更新：新しいqueryを扱えるように既存ページを拡張します。
• FAQ：既存記事に焦点を絞った回答を追加します。
• 内部リンク改善：canonicalページを指す文脈的なリンクを追加します。
• Discard：コンテンツを作らず、価値が低い、または対象読者の範囲外として記録します。

手順：

1. 各clusterを判断軸に沿って評価します。
2. 評価結果をアクションへ割り当てます。
3. cluster_id → suggested_actionの形式でアクション一覧を出力します。
4. 新規記事とピラーページなど、リスクの高いアクションを人が確認します。

表のquery数は判断材料の例であり、固定のしきい値ではありません。最終アクションは検索意図、既存記事、独自価値、保守コストを合わせて判断します。

6. 内部リンクをclusterのナビゲーションとして設計する

cluster間の関係は、単なる「関連記事」ではなく、実行可能な内部リンクへ変換します。次の形式で計画できます。

内部リンク設計の原則：

• pillar/clusterの双方向リンク：pillarから全clusterページへリンクし、各clusterページからpillarへ戻します。
• 具体的なアンカーテキスト：「こちら」ではなく、リンク先の検索意図が分かる表現を使います。
• canonical URLをリンク先にする：重複・類似ページを避け、優先したいcanonicalページへリンクします。
• 孤立記事を避ける：各記事に少なくとも一つの文脈的な被リンクを計画し、サイト構造と読者経路に応じて入口を追加します。
• cluster mapのinternal_link_targets：リンクすべき既存記事またはシリーズを記録します。

内部リンク一覧：

cluster_id	pillar_page	cluster_pages	internal_link_targets	アンカーテキスト案
1	Astro SEO完全ガイド	astro seoチュートリアル, astro blog seo	astro-guideシリーズ, cloudflare-binduiシリーズ	「AstroのSEO最適化」「Cloudflareのパフォーマンス最適化」
2	-	astro vs next.js for seo	astro-guideシリーズ, nextjs-blog-series	「AstroとNext.jsの比較」
3	-	cloudflare pricing	cloudflare-binduiシリーズ	「Cloudflareの料金解説」

手順：

1. pillarページとclusterページを特定します。
2. 双方向のリンク構造を設計します。
3. 各リンクに具体的なアンカーテキストを決めます。
4. 孤立記事がないか確認します。
5. 内部リンク一覧をコンテンツタスク表へ出力します。

Googleは現在、redirectとrel="canonical"を強いcanonicalシグナル、sitemapへの掲載を弱いシグナルとして扱っています。複数のシグナルは組み合わせられますが、最終的なcanonicalはGoogleが選びます。内部リンクはcanonicalとして優先したいURLへ一貫して向けます。

7. クラスタリングをページ量産にしない品質基準を設ける

キーワードクラスタリングを一括ページ生成器にすると、people-firstの原則から外れやすくなります。

リスク境界：

• キーワードの表記違いごとにページを作らない。同じ検索意図のqueryは一つのページまたはcanonicalのリンク先へ統合します。
• 独自価値の判断を必須にする。各clusterを読者の課題、サイトの主題、既存記事にない追加価値へ結び付けます。
• 同じ意図のqueryをcanonicalへまとめる。重複または非常に似たページでは、redirect、rel="canonical"、sitemapで希望を示せますが、シグナルの強さは異なり、Googleの採用を保証しません。
• search engine-firstのコンテンツを避ける。主目的はランキング操作ではなく、読者の課題を解決することです。
• cannibalizationのリスクを下げる。ほぼ同じキーワード向けに多数のページを公開すると、複数URLが同じ検索意図を奪い合う可能性があります。
• リスクの高いclusterを記録する。cluster mapのrisk_notesで人のレビューを必須にします。

品質上の禁止事項：

• 対応する既存記事がある場合は、類似ページを増やす前に記事更新またはFAQを優先します。
• クラスタリングの出力には、サイトテーマとの適合と独自価値の判断を必ず含めます。
• 内部リンクは重複・類似ページではなく、canonical記事へ向けます。

8. astro seo、cloudflare pricing、dockerの例で確認する

3つの場面に当てはめると、フローが分かりやすくなります。

例1：astro seoとastro vs next.js for seo（検索意図が異なるため分割）

• 元のquery：astro seo, astro vs next.js for seo, astro blog seo
• 正規化：astro seo, astro vs next js for seo, astro blog seo
• AIの仮分類：cluster_id=1, keywords=[astro seo, astro vs next js for seo, astro blog seo]
• 人のレビュー：astro seoはチュートリアル、astro vs next js for seoは比較なので分割します。
• 最終cluster map：
  • cluster_id=1: [astro seo, astro blog seo] → Astro SEOチュートリアルを新規作成
  • cluster_id=2: [astro vs next js for seo] → AstroとNext.jsのSEO比較記事を新規作成

例2：cloudflare pricing（既存記事を更新）

• 元のquery：cloudflare pricing, cloudflare cost, cloudflare 料金
• 正規化：cloudflare pricing, cloudflare pricing, cloudflare pricing
• AIの仮分類：cluster_id=3, keywords=[cloudflare pricing, cloudflare pricing, cloudflare pricing]
• 既存記事との一致：/cloudflare-pricingがある
• 最終cluster map：
  • cluster_id=3: [cloudflare pricing, cloudflare cost, cloudflare 料金] → /cloudflare-pricingを更新

例3：docker host.docker.internal（関連する技術queryを正規化）

• 元のquery：docker host.docker.internal, docker host-gateway, docker 127.0.0.1
• 正規化：同じ設定意図の候補グループとして記録します。
• AIの仮分類：cluster_id=4, keywords=[docker host.docker.internal, docker host-gateway, docker 127.0.0.1]
• 既存記事との一致：Dockerシリーズがある
• 最終cluster map：
  • cluster_id=4: [docker host.docker.internal, docker host-gateway, docker 127.0.0.1] → 人が検索意図を確認したうえで、Dockerシリーズの記事へFAQまたは節として追加

9. コンテンツマップを次の工程へ渡す

クラスタリングが終わったら、cluster mapをコンテンツタスク表へ移し、フィールド、スコア、状態遷移、公開計画を設計します。シリーズの次の記事「コンテンツタスク表の設計：フィールド、スコア、状態、公開計画」で扱います。

cluster mapから執筆可能な構成を作る方法は、「AIによる構成生成：cluster mapから執筆可能なアウトラインへ」で説明します。リンクの一括挿入は、後続の「内部リンク自動化：関連記事リンクの一括生成と注意点」で掘り下げます。

既存記事の更新には、「GSC既存記事更新戦略：quickWinsからコンテンツ更新へ」という別のガイドがあります。

公開済みの関連記事：

• Pillar-Clusterモデルで技術ブログの四半期コンテンツを計画する
• GA/GSC週次運用SOP：データからアクションへ
• コンテンツ機会を見つけるGSC上級テクニック