Engineering ai-driven-dev 12 min read

audience.primary を絞ると sister pillar / spoke 設計が明確になる

pillar の audience.primary を 1 つに絞ると、対象外の persona は sister pillar や spoke の設計空白として可視化される。絞ることが cluster 全体の記事構造を自然に導出する仕組みを解説。

公開 2026-05-25 森本拓見

pillar の audience を「絞る」と聞くと、多くの設計者は「届く読者が減る」と反応する。しかし実際は逆だ。audience.primary を 1 つに絞ると、そこに収まらない persona たちが cluster の設計空白として可視化され、sister pillar と spoke の役割が自然に導出される。「絞る = 捨てる」ではなく、「絞る = 全体設計の起点になる」という転換がここにある。

この記事では、mcluhan エンジン（コンテキスト圧縮エンジン）の pillar 設計を事例に、audience.primary の絞り込みが cluster 全体の記事構造をどう導出するかを解説する。対象は pillar と spoke の構造設計を担当するコンテンツアーキテクトとシニアエンジニアだ。

→ cluster と persona の 2 軸設計の前提については cluster と persona の関係 — 外向き・内向き軸の設計 を参照してほしい。

audience.primary を 1 つに絞る設計判断

primary / secondary の役割と書き方

brief YAML の audience フィールドは 2 段構造になっている:

audience:
  primary: "senior-engineer"    # narrative の主軸
  secondary:
    - "architect"               # cross-link で誘導する対象
narrative_weight:
  primary: 75
  secondary: 25

primary は本文の narrative 重心を決める唯一の persona だ。narrative_weight.primary: 75 は、本文の 75% が senior-engineer の視点で語られることを意味する。残りの 25% は secondary persona の関心事（architect が気にするトレードオフ等）を短く扱う。

重要なのは、primary が 1 つに限定されていることだ。2 つ以上の persona を primary に並べることは、audience-tracks.json の schema で禁止されている。

G11 は audience.primary の存在チェック（欠落 → fail）を担うが、「primary が複数定義されている」ケースのチェックは G11 に含まれない（scripts/blog-gate.ts は /^\s{1,4}primary:\s*\S/m の存在チェックのみ）。複数定義の防止は brief 生成時のプロンプト規約（SKILL.md 側）で担保している。

1 つに絞ったとき何が決まるか

audience.primary: "senior-engineer" に絞った瞬間、以下が確定する:

  • H2 の順序: 実装ディテール → 落とし穴 → 設計の核、という順でシニアエンジニアの関心順に並べる
  • 例示の粒度: コードスニペットやコマンド例を省略せず展開する。「なぜそのコマンドを使うか」は補足不要
  • 専門用語の閾値: grep -rn, yaml.safe_load(), narrative_weight といった用語を解説なしで使える
  • 比喩の種類: OSS のライブラリやシステム設計の文脈で例える

同じ記事で audience.primary: "architect" に変えた場合、H2 の順序は設計判断の why → トレードオフ → 実装例、専門用語は引き続き技術語彙だが比喩はシステム全体の整合性や将来の拡張性に寄る。

対象外 persona が sister pillar / spoke の空白を可視化する

tech pillar で primary = architect にすると business persona 向け記事が空白になる

tech cluster の pillar で audience.primary: "architect" に絞ると、business cluster の persona（executive / marketing-head / pm-product 等）向けのコンテンツが空白になる。この空白は問題ではなく、設計シグナルだ。

空白が可視化されることで、2 つの設計選択肢が明確になる:

  1. business cluster persona 向けのsister pillar を別途設計する（同一トピックを異なる audience で書き直す）
  2. business persona 向けのコンテンツを、tech pillar の本文末尾に圧縮してまとめ、business 向け pillar への cross-link を置く

選択肢 1 は、トピックの重要度が高く両 persona への訴求が必要な場合に使う。mcluhan エンジンのケースでは、tech 版の 2026-05-mcluhan-engine（audience.primary: senior-engineer）に対して、business 版の 2026-05-mcluhan-business-strategy（audience.primary: marketing-head / executive）を sister pillar として設計した。

retrofit 結果は blog-ops/retros/2026-05-18-persona-taxonomy-drives-narrative.md に記録されている。reset-timeline: executive、mcluhan: senior-engineer、bateson tech: senior-engineer、bateson business: business-owner。retrofit 前後の prose 品質の変化については具体的な記述箇所の記録はない。

mcluhan pillar で audience.primary を senior-engineer に絞った経緯は、2026-05-18 のセッション中にユーザーから「dual audience のつもりが tech に倒れている」と指摘されたことだ（blog-ops/retros/2026-05-18-persona-taxonomy-drives-narrative.md trigger フィールド）。具体的なセクションや段落の記録はない。

空白を埋める sister pillar の設計根拠

sister pillar を設計する根拠は空白の「大きさ」だ。以下の基準で判断する:

  • 空白の persona 数が 3 以上: 別 cluster で pillar を立てる価値がある（例: business cluster の 6 persona のうち 3 つが未カバー）
  • 空白の persona の KPI が主 KPI と異なる: 同一記事で両 KPI を追うと効果が薄くなる（例: lead-gen と採用ブランドを 1 記事で追う）
  • 空白 persona が主要なトラフィック源: SEO の検索意図が分岐している場合、記事を分けた方が keyword 競合を避けられる

mcluhan エンジンの場合、tech cluster（senior-engineer）と business cluster（marketing-head）で検索意図が大きく異なっていた。tech 側は「パイプライン設計」「persona SSOT」、business 側は「owned media 改善」「コンテンツ品質」がキーワードだった。これは sister pillar を別途設計する根拠として十分だった。

2026-05-mcluhan-business-strategy の sister pillar 戦略は 2026-05-18 のセッションで decision が下りた。blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md に記録されており、bateson の sister pillar（business-strategy）は同日 commit 57e22ed 等で新規作成された。mcluhan-business-strategy の brief 作成タイミングは git log で確認できる。

secondary persona を捨てるのではなく、cross-link で誘導するのが基本パターンだ。tech pillar の本文末尾に以下のような誘導を置く:

business 観点での mcluhan エンジン活用については [owned media 戦略として mcluhan を使う](/magazine/2026-05-mcluhan-business-strategy) を参照してほしい。

この誘導が機能するには、tech pillar の文中に「business 読者が興味を持つポイント」を 1-2 箇所に圧縮して配置する必要がある。たとえば、tech pillar の最終 H2 に「business impact — この設計が KPI にどう影響するか」セクションを短く置き、詳細は business sister pillar へと誘導する。

pillar 本文内でのナチュラルな誘導文例

誘導文は「宣伝」ではなく「補完」として機能させる。以下のパターンが機能する:

  • 問いかけ形: 「この設計の business 意思決定へのインパクトについては〜で詳しく扱う」
  • 前提条件形: 「この spoke は tech cluster の読者を対象としている。business 観点の経緯については〜を先に読むと理解が深まる」
  • 比較形: 「tech 実装の観点は本記事で扱い、ROI や運用コストの観点は〜で扱う」

典型的な pillar が持つ cross_links の数は pillar によって異なる。たとえば 2026-05-mcluhan-engine.yaml では 2 本（2026-05-magazine-reset-timeline と 2026-05-mcluhan-business-strategy）の cross_link が設定されている。関連する spoke や sister pillar の数に応じて 2〜5 本程度が目安となる。

実装: brief schema と pillar-relations.json

spoke の brief では parentPillarSlug と cross_links が関係構造を宣言する:

parentPillarSlug: 2026-05-mcluhan-engine    # この spoke の親 pillar
cross_links:
  - "2026-05-mcluhan-business-strategy"     # sister pillar への cross-link
  - "2026-05-cluster-persona-outer-inner-axis"  # 同 cluster 内の関連 spoke

parentPillarSlug は spoke が属する pillar を宣言し、pillar の H2 に「この spoke へのエントリポイント」を設計する根拠になる。cross_links は cluster 越境のリンク（tech → business、business → tech）を宣言し、link graph の生成基盤になる。

pillar-relations.json で cluster 全体の空白を一覧できる

blog-ops/config/pillar-relations.json は cluster の全体構造を俯瞰するための SSOT だ。どの pillar がどの sister pillar を持ち、どの spoke がぶら下がっているかを一覧できる:

{
  "topicClusters": {
    "mcluhan-owned-media": {
      "pillar": "2026-05-mcluhan-business-strategy",
      "sisterPillars": ["2026-05-mcluhan-engine"],
      "spokes": []
    }
  }
}

spokes: [] が空のままのエントリは「まだ設計されていない spoke の空白」を可視化する。audience.primary を絞った結果、どの persona 向けのコンテンツが不足しているかを一目で確認できる。

blog-tech-write スキルは、spoke の追加参照（F）として pillar-relations.json を Read し、同 topicCluster の全関係を確認してから cross-link の網羅性を担保する。

まとめ — 絞ることが全体設計の起点になる

audience.primary を 1 つに絞ることは、対象外の persona を「見えないもの」にすることではない。それは対象外の persona を「設計すべき空白」として可視化し、sister pillar と spoke の役割を明確化する行為だ。

絞ることで決まることをまとめる:

  1. primary persona への narrative 重心（H2 順序・語彙・例示粒度）が確定する
  2. secondary persona 向けの cross-link 先（sister pillar・spoke）の設計根拠が可視化される
  3. pillar-relations.json の空白（未設計の spoke）が一覧できるようになる

pillar が「誰でも読める」記事から「特定の読者が何かを持ち帰れる」記事へと変わるのは、この絞り込みを起点にした設計の連鎖があってこそだ。

→ audience.primary 欠落を pipeline で構造的に防ぐ gate 設計については 機械的 gate で persona 欠落を fail にする設計 を参照してほしい。

SHARE X でシェア B! はてブ

NEXT READS

  1. Business 2026-05-26 12 min read

    事業ポートフォリオ設計 — AIネイティブ組織土台の上で受託とプロダクトをどう選ぶか

    受託 vs プロダクト化の二項対立を超え、AIネイティブな組織土台を先に作り、その上で事業ポートフォリオを設計する判断軸を整理。bateson Booking Engine を土台上の事業選択の一例として、並走を機能させる組織設計と判断チェックリストを解説する。

  2. Engineering 2026-05-26 13 min read

    bateson を single-tenant 実装で multi-tenant 化を妨げない Phase 設計

    Phase A の single-tenant 実装が Phase B 以降の multi-tenant 化を阻まないための 3 規約。tenantId 全引数化・adapter DI・cancelToken hash で破壊的変更なしに SaaS 化を準備。

  3. Business 2026-05-25 19 min read

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

    pillar の primary keyword を cluster の軸とし、spoke の secondary keywords に段階的に降ろす cluster SEO 設計。AI 量産環境での keyword マップ保守と一貫性担保の仕組みを解説。