cluster SEO 実装 — pillar primary を spoke secondary に降ろす設計

本記事に登場する HUMAN_INPUT マーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例: ）。

owned media に pillar と spoke を複数本運用し始めたとき、SEO の焦点が変わる。記事単体の検索最適化から、記事群の keyword 関係の保守へ。これが「cluster SEO」の発想転換だ。

pillar の primary keyword を cluster の中心軸に据え、spoke の secondary keywords へ段階的に降ろすことで、記事群が keyword の階層構造を形成する。個々の記事が keyword を競い合う（内部カニバリゼーション）のではなく、それぞれが担当する keyword 層で役割分担する設計だ。

八雲のコンテンツパイプラインでは、@seo-director（SEO 戦略を担うアドバイザエージェント）が cluster 単位でこの keyword マップを保守している。この記事では、pillar primary keyword を spoke secondary に降ろす cluster SEO の設計と、new-article-spoke.json パイプラインでの実装を解説する。

→ SEO 戦略レイヤーを pipeline に組み込む advisor agent の接続設計については pipeline 戦略レイヤー設計を参照してほしい。

記事単位の最適化から cluster 単位の keyword 関係保守へ

以前、記事の SEO は記事ごとに独立して考えていた。spoke ごとに担当者が keyword を設定し、「この記事は何の検索でヒットさせたいか」を個別に判断する。この方法では、同一 cluster の記事間で keyword が重複し、Google から見ると「同じ検索意図に複数の記事が競合している」状態になる。

内部カニバリゼーションが起きると、cluster 全体の SEO 力が分散する。同じ keyword で 3 本の記事が競合すれば、それぞれの記事が薄い評価しか得られない。1 本の記事が高い評価を得られた方が cluster としての集客力は高い。

cluster SEO はこの問題を設計で解決する。pillar が cluster の keyword 軸を担い、spoke は pillar の secondary keywords を primary として受け取ることで、cluster 全体が keyword の階層構造になる。

cluster SEO の概念 — keyword 階層の設計

pillar の primary keyword が cluster の keyword 軸になる理由

pillar は cluster の「入口」だ。読者がトピックに関心を持ったとき最初に着地する記事であり、内部リンクの hub として機能する。この位置づけから、pillar の primary keyword は「このトピックで最も検索ボリュームが高く、かつ cluster を代表する検索フレーズ」を選ぶ。

mcluhan cluster（owned media pipeline の設計をテーマとするクラスター）の場合:

pillar primary keyword: content cluster persona（tech cluster 側）、owned media AI 運用（business cluster 側）
この keyword は cluster 全体の keyword 軸になる

spoke はこの軸の下位概念を担う。pillar primary keyword を spoke の secondary keywords に含めることで、spoke は「pillar の延長線上にある詳細記事」として keyword 関係を宣言する。

spoke の secondary keywords に pillar の primary を含める設計

spoke の brief YAML では、親 pillar の primary keyword を secondary_keywords の 1 つとして必ず含める:

# spoke の brief YAML（例）
slug: 2026-05-cluster-persona-outer-inner-axis
seo:
  primary_keyword: "pillar narrative 設計 audience"   # spoke の独自 keyword
  secondary_keywords:
    - "content cluster persona"   # ← 親 pillar の primary keyword を継承
    - "コンテンツ SSOT persona taxonomy"

この設計には 2 つの効果がある。1 つは、Google が spoke を「pillar の関連記事」として認識しやすくなること。内部リンク構造と keyword 関係の両方が pillar との結びつきを示すため、cluster としての評価が高まる。もう 1 つは、spoke が pillar の keyword を奪わないこと。spoke は pillar の primary keyword を「secondary（サポート）」として持つだけで、primary としては独自の narrower keyword を持つ。

内部カニバリゼーション防止の観点

cluster SEO の設計で最も注意が必要なのは、同一 cluster 内の記事が同じ primary keyword を持つことだ。

@seo-director は新規 spoke の keyword 設計時に、既存 pillar と spoke の primary_keyword を確認し、被りがないかをチェックする。具体的には:

新規 spoke の candidate primary_keyword が、既存記事の primary_keyword と完全一致しないか
候補 keyword の検索意図が既存記事と同一でないか（「AI pipeline 設計」と「AI パイプライン設計」は実質同じ）

SEO 戦略なしで書いていた期間に何が起きていたかは、現状の frontmatter を機械的に突合すれば見える。primaryKeyword の 完全一致重複 は 50 記事中 0 件だが、語幹レベルでの近接 は多数発生していた。例えば mcluhan-engine 配下の spoke では "pre-publish gate ..." を含む keyword を持つ記事が 6 本（pre-publish-gate-proximity / gate-false-positive-balance / allow-list-brand-check / brand-rule-automation / persona-gate-validation / blog-gate-strategic-validation）。"owned media ..." を含む記事は 10 本、"AI エージェント ..." を含む記事は 11 本。primary_keyword レベルでも "pre-publish gate design" と "pre-publish gate false positive" のように語幹が一致するペアが存在する。これは「同一の SERP 競合」ではないが、@seo-director を通さずに書いた spoke が「親 pillar の secondary_keyword をそのまま primary に転用」した結果だ。blog-ops/retros/2026-05-18-seo-missing-from-pipeline.md でも、pillar 3 本（reset-timeline / mcluhan / bateson）の brief から SEO 観点（primary_keyword / 関連キーワード）が完全に抜けていたことが記録されている。

keyword マップの具体的な構造

mcluhan cluster（pillar = 2026-05-mcluhan-engine）の現時点の対応表は以下の通り。pillar の primary は "コンテンツ運用エンジン設計状態機械"、secondary は "AI 記事 pre-publish gate 自動化" / "owned media パイプライン品質チェック" / "コンテンツ SSOT frontmatter 管理" の 3 本。

役割	slug	primary_keyword
pillar (tech)	`2026-05-mcluhan-engine`	コンテンツ運用エンジン設計状態機械
sister-pillar (business)	`2026-05-mcluhan-business-strategy`	AI コンテンツ品質管理 owned media 経営判断
spoke	`2026-05-allow-list-brand-check`	allow-list brand check
spoke	`2026-05-pre-publish-gate-proximity`	pre-publish gate design
spoke	`2026-05-gate-false-positive-balance`	pre-publish gate false positive
spoke	`2026-05-brand-rule-automation`	brand rule automation
spoke	`2026-05-corporate-vocabulary-proximity-detection`	（未設定）
spoke	`2026-05-persona-gate-validation`	（未設定）
spoke	`2026-05-blog-gate-strategic-validation`	（未設定）
spoke	`2026-05-cluster-seo-keyword-map`	（未設定）
spoke	`2026-05-cluster-persona-outer-inner-axis`	（未設定）
spoke	`2026-05-audience-primary-pillar-spoke-clarity`	（未設定）

観察できることが 2 つある。1 つは「pillar の secondary AI 記事 pre-publish gate 自動化 が複数 spoke の primary pre-publish gate design / pre-publish gate false positive に降りる」設計が部分的に成立していること。もう 1 つは「12 spoke のうち 6 本で primary_keyword が未設定」という現状だ。後者は @seo-director を pipeline phase 0 に組み込む前に書かれた spoke 群で、リライト時に後付けで埋める方針になっている。

SSOT としての brief YAML seo セクションの設計

keyword マップは、各 brief YAML の seo セクションが SSOT（Single Source of Truth）として機能する設計だ。Excel や頭の中に分散したキーワードリストを持たない。

各 spoke の brief には:

seo:
  primary_keyword: "{この spoke 独自の keyword}"
  secondary_keywords:
    - "{親 pillar の primary keyword}"
    - "{関連 keyword}"
  longtail_clusters:
    - "{spoke が答える具体的な検索クエリ}"

@seo-director はこの構造を cluster 単位で俯瞰し、keyword の重複・競合・空白を管理する。新規 spoke を追加するとき、@seo-director は既存の brief seo セクションを全件確認してから keyword を提案する。

seo-director による keyword マップの保守責務

seo-director が担う cluster 単位の keyword マップ管理

@seo-director の責務は「単発記事の keyword 設定」ではなく「cluster の keyword 関係保守」だ。

具体的には:

新規 pillar 追加時: cluster の keyword 軸を設計し、cluster 内の既存記事との keyword 関係を整理する
新規 spoke 追加時: 親 pillar の secondary_keywords から primary candidate を選定し、既存 spoke との重複を確認する
既存 spoke のリライト時: keyword の現在の検索意図と traffic データを参照し、primary keyword の変更が必要かを判断する

この 3 つのタイミングで @seo-director を呼ぶことで、cluster の keyword 構造が一貫性を保ちながら成長できる。

@seo-director keyword <slug> モードを呼び出すと、@seo-director は以下の手順で seo セクション素案を生成して返す:

blog-ops/articles/ 配下の既存 brief YAML を全件収集し、使用中の primary_keyword を確認（カニバリ回避）
blog-ops/config/audience-tracks.json で記事トラックの読者・価値提供を確認
primary_keyword / secondary_keywords / longtail_clusters / search_intent / serp_title_finalized / serp_description_finalized / cluster_position を含む seo セクション YAML を生成して main-thread に返す

main-thread はこの素案を blog-ops/output/rewrite/{slug}/00_seo.yaml に書き出し、確認後に brief YAML に組み込む。

現状の overlap check は 決定論的なスクリプトではなく @seo-director 側の LLM 判断として実装している。scripts/blog-gate.ts の G1〜G14 には keyword overlap を見るチェックは存在せず（SEO 関連は G11 の「pillar 記事の brief に seo セクション欠落」だけ）、blog-ops/config/pipelines/new-article-spoke.json の phase 0 で @seo-director を呼んで「クラスター内でのカニバリ回避と意図の棲み分けを確認する」と指示する設計だ。.claude/agents/seo-director.md の手順 1 にも「blog-ops/articles/ 配下の既存 brief YAML を Glob で収集し、使用中の primary_keyword を確認（カニバリ回避）」と書いてあるが、これは LLM agent への自然言語指示であり、決定論ゲートではない。将来は blog-gate.ts 側に「primary_keyword 完全一致」「語幹一致 cluster 内 N 件以上」を機械検出する G ルール（仮に G15）を追加する余地がある。

新規 spoke 追加時の keyword アサイン手順

新規 spoke 追加の際、@seo-director は以下の手順で keyword を提案する:

親 pillar の brief から seo.secondary_keywords を取得する
既存 spoke の seo.primary_keyword リストと照合し、未使用の secondary keyword を特定する
未使用の secondary keyword の中から、この spoke のトピックと最も整合するものを primary candidate として提案する
longtail_clusters はトピックの具体的な検索クエリ（「How to…」「〜する方法」形式）で 3-5 本提案する

pipeline phase 0 として seo-director を組み込む起動ルート

new-article-spoke.json では phase 0 で @seo-director を起動する:

{
  "phase": 0,
  "step": "seo",
  "kind": "agent",
  "runner": "@seo-director",
  "model": "sonnet",
  "trigger": "pipeline 開始時。main-thread が @seo-director を呼んで素案を受け取る",
  "depends_on": [],
  "description": "spoke の SEO 設計。親 pillar の secondary_keywords から spoke の primary_keyword を選定する設計を推奨。クラスター内でのカニバリ回避と意図の棲み分けを確認する",
  "input": {
    "slug": "{slug}",
    "parent_pillar_slug": "{parent_pillar_slug}",
    "parent_pillar_brief": "blog-ops/articles/{parent_pillar_slug}.yaml",
    "audience_tracks": "blog-ops/config/audience-tracks.json",
    "existing_articles": "src/content/magazine/**/*.md"
  }
}

phase 0 の input.parent_pillar_brief が親 pillar の brief を input として受け取る設計になっている。@seo-director はこの input から seo.secondary_keywords を取得し、cluster 内の既存 spoke との重複を避けながら新規 spoke の primary keyword を提案する。pillar の secondary keywords を参照することで、pillar で「深掘りしていない領域」を特定し、その空白を埋める spoke を設計できる。

new-article-spoke.json での cluster SEO 実装

spoke パイプラインの phase 0 で pillar の seo セクションを参照する設計

new-article-spoke.json の phase 0 は、親 pillar の brief（blog-ops/articles/{parent_pillar_slug}.yaml）を input として受け取る。@seo-director はこの input から seo.secondary_keywords を取得し、cluster 内の既存 spoke との重複を避けながら新規 spoke の primary keyword を提案する。pillar の secondary keywords を参照することで、pillar で「深掘りしていない領域」を特定し、その空白を埋める spoke を設計できる。

phase 0 の output は blog-ops/output/rewrite/{slug}/00_seo.yaml に書き出され、phase 1（blog-plan）が brief YAML に seo セクションとして組み込む。この依存関係（depends_on: ["seo"]）により、seo セクションのない spoke は phase 1 以降に進めない設計になっている。

まとめ — 記事単位から cluster 単位の SEO へ

owned media の SEO は「記事を書いてから keyword を当てはめる」のではなく、「cluster の keyword 構造を設計してから記事を書く」順序で進める必要がある。

cluster SEO で整備する設計要素をまとめる:

pillar primary keyword = cluster の keyword 軸: pillar は cluster を代表する検索フレーズを primary に持ち、この keyword が cluster のセマンティック中心になる
spoke secondary に pillar primary を継承: spoke は pillar の keyword との関係を secondary として宣言し、cluster の keyword 階層構造を形成する
@seo-director が cluster 単位で保守: 新規記事追加のたびに cluster 全体の keyword マップを確認し、重複・競合を防ぐ
brief YAML が keyword マップの SSOT: Excel や頭の中ではなく、各 brief の seo セクションが keyword 関係の唯一の情報源になる

AI 量産環境では、記事の生成速度が上がる分、keyword の競合リスクも高まる。pipeline の入口（phase 0）で @seo-director を呼んで keyword を設計してから執筆に入る構造を持つことが、cluster の SEO 力を維持する前提条件だ。

→ 全体的なコンテンツ戦略として mcluhan エンジンを活用する業務設計の観点については owned media を mcluhan エンジンで改善するを参照してほしい。

→ cluster SEO の設計判断が必要になった経緯——AI 量産で 48 本一括投下したあとに発覚した内部リンク死滅と keyword 競合の実態——は AI 量産ブログを約 1 週間で全撤退した話を参照してほしい。

→ cluster SEO で keyword と並ぶもう一つの SSOT である persona を機械チェックする設計については機械的 gate で persona 欠落を fail にする設計を参照してほしい。