Engineering ai-driven-dev 14 min read

cluster と persona の分離 — 外向き・内向き軸の設計

cluster は配信先・KPI の外向き軸、persona は narrative・専門用語閾値の内向き軸。2 軸を SSOT で分離して pipeline に通す設計を、mcluhan エンジンの実装から解説する。

公開 2026-05-25 森本拓見

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

pillar と spoke の構造を設計するとき、「どの読者に向けて書くか」という問いに 2 つの軸が重なっている。配信先や KPI を決める外向きの軸と、本文の語り口や専門用語の閾値を決める内向きの軸だ。この 2 軸を混同したまま執筆に流れると、pillar の prose が「誰に向けて書かれているのか」が曖昧な中庸値に収束する。どちらの読者にも刺さらない、平均化された文章ができあがる。

この記事では、外向きの軸を cluster、内向きの軸を persona として SSOT（Single Source of Truth）で分離し、pipeline に通す設計を解説する。対象は blog-ops/config/audience-tracks.json と scripts/blog-gate.ts の G11 を使ってこの分離を実装したコンテンツパイプライン設計者だ。

→ mcluhan エンジン（コンテキスト圧縮エンジン）を中心とした owned media pipeline の全体像は mcluhan エンジン設計原則 を参照してほしい。

cluster は外向きの軸 — 配信先・KPI・SEO を決める

business cluster と tech cluster の責務定義

cluster の責務は、記事が「どこで誰に届くか」を決めることだ。blog-ops/config/audience-tracks.json では、business cluster と tech cluster の 2 軸を定義している。

business cluster は primary_kpi: "lead-gen / 問い合わせ CV" を持ち、primary_audience を「経営層・事業責任者・PM」と定義する。tech cluster は primary_kpi: "ブランド浸透 / エンジニア採用 / 開発組織信頼性" を持ち、primary_audience を「AI ドリブン開発のエンジニア・アーキテクト」と定義する。

この 2 つは KPI が根本的に異なる。business cluster は問い合わせ CV を目指すため、リード段落から executive summary と key takeaway 3 点を提示し、意思決定者が 30 秒で価値判断できる構成をとる。tech cluster はブランド浸透とエンジニア採用を目指すため、課題 → パターン → 設計の核 → 落とし穴という構成で技術的な深みを担保する。

cluster が決めること

cluster は以下の 3 つを決める:

primary keyword 設計: business cluster の記事は経営者が検索するフレーズ（例: 「AI 業務改善 事例」「コンテンツ運用 自動化」）を primary keyword に設定する。tech cluster は技術者が検索するフレーズ（例: 「content cluster persona 設計」「pillar spoke pipeline」）を選ぶ。

配信 time slot: src/config/publish-policy.ts に 5 つのタイムスロット（09:00 / 11:00 / 14:00 / 16:00 / 18:00 JST）が定義されている（2026-05-21 5d8e531）。business cluster の記事は 18:00 スロットに移動するコミット（305044d：6 本の business cluster 記事を 09:00 → 18:00 へ移動）が存在する。

cross-link 先: business cluster の記事は同 cluster 内の business spoke や sister pillar（tech cluster 側）への cross-link を持つ。これにより、tech に興味を持った business 読者が tech pillar に流れる経路を確保する。

persona は内向きの軸 — narrative・H2 重み・専門用語閾値を決める

persona が決めること

persona の責務は、本文の「語り口」を決めることだ。同じ cluster（例: tech cluster）でも、audience.primary に senior-engineer を設定するか architect を設定するかで、文章の質感は変わる。

audience-tracks.json の tech cluster には 6 つの persona が定義されている: junior-engineer, senior-engineer, tech-lead, architect, solo-developer, data-engineer。business cluster には: executive, business-owner, cto, marketing-head, pm-product, sales-head。

business cluster と tech cluster のそれぞれに 6 つの persona が定義されており、合計 12 の persona が audience-tracks.json で管理されている。

persona は以下を決める:

H2 の順序と重み: senior-engineer persona では実装ディテールを前半に置き、business impact を末尾に圧縮する。architect persona では「なぜその設計を選んだか」のトレードオフを前半に置く。

例示の解像度: junior-engineer persona では、パターン名の定義からコードスニペットまでを丁寧に展開する。tech-lead persona では、チーム規模への適用可否や運用コストを前提として議論を進める。

専門用語の閾値: senior-engineer persona は grep -rn "chr(65" のようなコマンドを説明なしで使える。marketing-head persona はその代わりに「文字コードの計算式」のような業務語彙で補足が必要になる。

persona を 2 つ以上設定してしまうと、文章が平均化する。audience.primary: "senior-engineer" と audience.primary: "architect" を同時に想定した pillar は、実装ディテールを語りつつトレードオフも丁寧に説明しようとして、どちらにも中途半端な文章になる。

解決策は、audience.primary を 1 つに絞り、audience.secondary に指定した persona 向けの記事を sister pillar や spoke として設計することだ。pillar の本文末尾に「設計判断の観点は [architect 向けの別記事] を参照してください」と anchor link を置けば、secondary persona の読者を自然に誘導できる。

→ この設計の具体的な実装については audience.primary を絞ることで sister pillar / spoke 設計が明確化する で詳しく解説している。

SSOT で 2 軸を分離する実装

audience-tracks.json の clusters × personas 設計

blog-ops/config/audience-tracks.json は cluster を最上位のキーとし、各 cluster の下に persona のリストを持つ設計になっている。

{
  "clusters": {
    "business": {
      "personas": ["executive", "business-owner", "cto", "marketing-head", ...],
      "narrative_style": "結論先出し、数字・経営判断を前半に...",
      "default_writer_skill": "blog-case-write"
    },
    "tech": {
      "personas": ["junior-engineer", "senior-engineer", "tech-lead", "architect", ...],
      "narrative_style": "課題 → パターン → 設計の核 → 落とし穴 → まとめ",
      "default_writer_skill": "blog-tech-write"
    }
  }
}

cluster は narrative_style と default_writer_skill を持つ。これが「外向きの設計」だ。個々の persona は blog-ops/articles/{slug}.yaml の brief で audience.primary として指定される。これが「内向きの設計」だ。

brief YAML の audience.primary / cluster フィールドが担う役割

brief YAML では 2 軸が別フィールドとして分離されている:

cluster: tech          # 外向き: どの cluster で配信するか
audience:
  primary: "senior-engineer"    # 内向き: 誰に向けて書くか
  secondary:
    - "architect"
narrative_weight:
  primary: 75          # primary persona の narrative 重心割合
  secondary: 25

cluster: tech は配信先・KPI・writer_skill の選択を決定する。audience.primary: "senior-engineer" は本文のトーン・語彙・H2 の重みを決定する。2 軸が同一フィールドに混在していないため、pipeline の各ステップが自分の責務に応じた軸だけを参照できる。

この設計の効果は bateson pillar の改修で実感できた。SSOT 導入前は brief の target_audience.role に「経営者と CTO の両方」と freeform で書いていたため、本文では engineering 制約（tenantId・adapter pattern）と経営判断（受託 vs 商用化）が混在し、business 読者にも tech 読者にも刺さらない中庸化した prose になっていた。clusters × personas に SSOT を分けてからは、同じトピックを business cluster（audience.primary: business-owner、コード片廃除、経営判断用語を主部）と tech cluster（audience.primary: senior-engineer、design pattern を正面）の 2 つの pillar に分割し、それぞれの prose が一貫した語彙で書けるようになった。2 軸の分離は、執筆段階の語彙選択そのものを構造で決めている。

pipeline への組み込みと gate

blog-gate G11: audience.primary 欠落を fail にする設計

2 軸の分離は SSOT だけでは担保できない。「書くのを忘れた」という人間のうっかりを防ぐには、機械的な gate が必要だ。

scripts/blog-gate.ts には G1〜G13 の 13 個の必須チェックが定義されており、G11 は is_pillar: true の brief で audience.primary が欠落している場合に pipeline を fail させる。freeform text の target_audience.role フィールドは機械検証できなかったが、audience-tracks.json に定義された taxonomy の有効値との照合（例: senior-engineer は valid、エンジニア一般 は invalid）が可能になったことで、欠落だけでなく無効値も検出できる。

G11 が機能することで、pillar は「persona なしで先に進めない」構造になる。persona が決まらなければ brief の audit でも fail になり、執筆フェーズに入れない。

2 軸が揃って初めて narrative arc が駆動する

cluster と persona の 2 軸が揃うことで、pipeline の各ステップが一貫した判断基準を持てる。

  • blog-tech-write は cluster=tech と audience.primary=architect を読んで、設計判断と why を前面に出した narrative を生成する
  • blog-review は G11 に加えて narrative_weight の整合性（primary persona への narrative 重心が 75% 以上確保されているか）を検証する
  • blog-gate は 2 軸の欠落・無効値を fail にし、pipeline が素通りするのを防ぐ

persona を決めずに執筆に流れた場合、prose は「senior-engineer にも architect にも通用するように」書かれた中庸なテキストになる。どちらの persona も「自分向けではない」と感じる。2 軸の分離は、この中庸化を設計段階で防ぐための構造的解決策だ。

→ persona 欠落を機械的に検出する gate 設計の詳細は 機械的 gate で persona 欠落を fail にする設計 を参照してほしい。

まとめ — cluster と persona を分離する理由

cluster と persona を混同すると何が起きるか。cluster（外向き）で本文のトーンを決めようとすると、business cluster = ビジネス語彙、tech cluster = コード重視という粗い振り分けになる。persona（内向き）で配信 KPI を設定しようとすると、senior-engineer = エンジニア採用、architect = ブランド浸透という意味不明な対応になる。

2 軸を分離して SSOT に落とすことで:

  1. cluster が外向きの設計（配信先・KPI・keyword 戦略）を担当する
  2. persona が内向きの設計（narrative arc・H2 重み・専門用語閾値）を担当する
  3. pipeline は両方の軸を参照して、特定の読者に刺さる本文を生成・検証する

この分離は、pillar が「誰にでも読める」中庸な記事から、「特定の読者に強く刺さる」記事へと進化するための設計上の前提条件だ。

audience.primary を retrofit した既存 pillar は 4 本だ。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）。

cluster × persona の設計が完成したら、次は sister pillar と spoke の役割分担をどう設計するかだ。audience.primary を 1 つに絞ったとき、残った persona が cluster 全体のどこに収まるかが可視化される。その設計については audience.primary を絞ることで sister pillar / spoke 設計が明確化する で解説している。

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 マップ保守と一貫性担保の仕組みを解説。