sister pillar の関係性を schema で第一級表現する — brief 拡張案

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

bateson-engine pillar の brief に tech_spoke_slugs フィールドがある。そこに 2026-05-bateson-business-strategy という slug が混在している。これは business 版 sister pillar への参照だ。spoke ではない。だが schema は両者を同じフィールドで表現している。

この混在は暫定解として始まった。sister pillar 戦略に転換した直後、「とりあえず spoke フィールドに入れておく」という判断が取られた。bateson-engine.yaml では business_spoke_slugs フィールドに 2026-05-bateson-business-strategy が記述されている。だが暫定解は概念の混乱を schema に固着させる。sister_pillar_slug フィールドを別途追加することで、schema レベルで sister pillar と spoke の概念を分離できる。schema が概念を第一級表現することで、graph 生成・link 分析・skill の cross-link 設計が整合する。

現状の問題 — spoke と sister pillar の概念混在

tech_spoke_slugs に sister pillar slug を混在させている現状

spoke と sister pillar は別の概念だ。

spoke は pillar の特定テーマを深掘りした記事だ。2026-05-bateson-engine pillar の spoke は「multi-tenant 化の実装手順」「Phase B への移行判断」のような、pillar の下位概念を展開する記事になる。spoke は pillar に帰属する。

sister pillar は同一トピックの逆 cluster pillar だ。2026-05-bateson-engine（tech cluster）の sister は 2026-05-bateson-business-strategy（business cluster）だ。2 本は対等な関係であり、一方が他方の下位概念ではない。sister pillar は pillar に帰属しない。

tech_spoke_slugs に sister pillar slug を混在させると、schema を読む人間・機械・skill のいずれもが「これは spoke か sister か」を判断できない。フィールド名から意味が読めないデータは、参照するたびに文脈推定が必要になる。

混在によって生じる graph 分析・skill 動作への影響

blog-ops/config/pillar-relations.json は pillar ↔ sister-pillar / spoke の graph 構造を SSOT として持つ。現在の実装では sisterPillars と spokes は別々のフィールドで表現されており、graph としては分離している。

だが brief YAML の tech_spoke_slugs に sister が混在した状態だと、brief から graph を生成する処理（または brief を参照する skill）が「この slug は spoke か sister か」を判断する追加ロジックを必要とする。

blog-graph skill が brief YAML を静的解析するとき、tech_spoke_slugs の中から spoke だけを抽出し、sister pillar を除外するロジックが必要になる。これは schema の責務をコードに押し付けている状態だ。schema が概念を正しく分離していれば、コードは単純に参照するだけでよい。

schema で概念を区別しないことのコスト

コストは 3 種類に分かれる。

理解コスト: 新しいメンバーが brief YAML を見たとき、tech_spoke_slugs に pillar の slug が入っている理由が schema から読めない。ドキュメントやコンテキストを参照しなければ意味を理解できない。

実装コスト: skill / script が tech_spoke_slugs を参照するとき、中に sister pillar slug が混在していないかを判定するロジックが必要になる。判定ロジックは「is_pillar フィールドを読んで判断する」のような間接的な方法になる。

将来コスト: sister pillar ペアが増えるほど混在が拡大する。現在は bateson ペアだが、mcluhan ペアも mcluhan-engine と mcluhan-business-strategy という sister 関係を持つ。同じ暫定解を繰り返すと、tech_spoke_slugs が「spoke + sister の混在フィールド」として定着する。

拡張案 — sister_pillar_slug フィールドの追加

sister_pillar_slug の定義: 同一トピックの逆 cluster pillar への参照

拡張案として sister_pillar_slug フィールドを brief YAML に追加する。定義は次の通りだ。

sister_pillar_slug: "2026-05-bateson-business-strategy"
# 同一トピックに対して逆 cluster で書かれた sister pillar の slug。
# tech cluster pillar は business sister を、business cluster pillar は tech sister を参照する。
# pillar 記事のみに適用。spoke 記事には設定しない。

フィールドは単一値（string）で、対称関係を表す。2026-05-bateson-engine が sister_pillar_slug: 2026-05-bateson-business-strategy を持ち、2026-05-bateson-business-strategy が sister_pillar_slug: 2026-05-bateson-engine を持つ。

tech_spoke_slugs / business_spoke_slugs との役割分離

拡張後の役割分離は次の通りだ。

フィールド	対象	関係の種類
`tech_spoke_slugs`	tech 詳細を深掘りする spoke	pillar → 下位 spoke（帰属関係）
`business_spoke_slugs`	business 観点を深掘りする spoke	pillar → 下位 spoke（帰属関係）
`sister_pillar_slug`	同一トピックの逆 cluster pillar	pillar ↔ pillar（対等関係）

分離することで、tech_spoke_slugs は「この pillar の下で動く tech spoke」だけを持つ。graph 生成スクリプトは sister_pillar_slug と tech_spoke_slugs を別のエッジとして処理できる。

追加するフィールドの YAML スキーマ設計

.schema.md への追加記述案:

# sister_pillar_slug（オプション。pillar 記事のみ）
sister_pillar_slug: string  
# 同一トピックの逆 cluster pillar の slug。mcluhan / bateson のような
# business+tech 2 pillar 並走の場合に両方から互いを参照して設定する。
# spoke 記事では使用しない（spoke-pillar 関係は pillarSlug フィールドで表現する）。
# 値は相互に対称であること（A が B を持てば B も A を持つ）。

schema 拡張の影響範囲と移行コスト

既存 brief YAML の migration

現在 tech_spoke_slugs または business_spoke_slugs に sister pillar slug を混在させている brief YAML の件数は 14 件だ。

migration の作業は各 brief YAML で次の 2 ステップだ。

tech_spoke_slugs（または business_spoke_slugs）から sister pillar slug を削除する
sister_pillar_slug: {slug} を追記する

逆側の sister pillar brief にも同じ変更を加えて対称性を保つ。pillar-relations.json は既に sisterPillars フィールドで正しく表現しているため、変更不要だ。

graph 生成スクリプト / link graph への影響

blog-graph skill が brief YAML を解析して link graph を生成するとき、sister_pillar_slug フィールドを新しいエッジタイプとして追加する必要がある。

変更点:

tech_spoke_slugs → spoke エッジ（direction: pillar → spoke）
sister_pillar_slug → sister エッジ（direction: 双方向）

spoke エッジは一方向（pillar から spoke へ）。sister エッジは双方向で同等だ。この区別は graph 可視化とリンク分析の両方で意味を持つ。spoke とのリンク数と、sister との参照数は異なるメトリクスとして集計すべきだ。

blog-gate G ルールへの追加が必要なチェック

schema に sister_pillar_slug を追加した後、blog-gate に追加するチェックの候補がある。

候補 G14: sister_pillar_slug が指す slug が実際に存在するか（存在しない slug への参照は WARN で検出）

候補 G15: sister_pillar_slug の対称性チェック（A が B を持つが B が A を持たない場合を WARN で検出）

G14/G15 は fail ではなく WARN レベルが適切だ。新規 sister pillar を計画段階で brief に記述した段階では相手の brief がまだ存在しない場合があるためだ。

まとめ — schema が概念を第一級表現する意義

pillar 設計の思想を schema に焼き込む価値

sister pillar 戦略は「1 トピック = 1 pillar」の前提を壊す設計判断だ。この判断を運用するには、schema がその概念を正しく表現していることが必要だ。

schema が概念を第一級表現するとは、「この値は何のための参照か」が schema を読むだけで分かることだ。sister_pillar_slug というフィールド名を見れば、それが sister pillar への参照であることは自明だ。tech_spoke_slugs の中から sister を探す必要はない。

設計の思想を schema に焼き込む価値は「コードとドキュメントの外側に、概念の地図を持つこと」だ。新しいメンバーが brief YAML を見て、pillar 設計の構造を読み取れる状態が理想だ。

将来の sister pillar 増加に備えた schema の拡張性

現在運用中の sister pillar ペアは 7 ペアだ。

sister pillar 戦略が成立するトピックの条件（tech と business の両側に固有 narrative を持つ）を満たすトピックが増えるほど、ペア数は増える。sister_pillar_slug フィールドが schema に存在することで、新しいペアを追加するときの作業は「両方の brief に 1 行追加する」だけになる。

フィールドが存在しない状態では、新しいペアが来るたびに「どこに書くか」という判断コストが発生する。schema が先行してフィールドを定義しておくことで、運用の判断コストを排除できる。

sister pillar 戦略は bateson / mcluhan に限らず、synapse（business org / agent harness）、laplace（medallion finance ROI / data pipeline）、montage（video ops ROI / video pipeline）、ai-agent-design（business integration / harness design）、claude-code-practice（product / design）でも既にペアが組まれている。2026-05 時点で pillar-relations.json に登録されている sister pillar ペアは 7 ペアだ。

sister_pillar_slug フィールドの brief schema への正式追加は、次の新規 pillar pair を brief から起こすタイミングで実施する想定だ。既存 7 ペアは pillar-relations.json 側で sisterPillars として既に表現されているため retro 的な backfill 優先度は低く、brief 生成の DAG に組み込むときに schema 拡張と同時にやる方が手戻りが少ない。

優先度は高い。sister pillar 戦略は今後の pillar 増加に伴って WARN がないと「片側だけ書いた」状態を検知できなくなるためだ。schema 拡張（sister_pillar_slug フィールド追加）と同じ PR で G14 / G15 を導入するのが自然な順序になる。

なお G15 で対称性を担保するのは tech ↔ business の sister pillar ペアであり、日本語記事 ↔ 英語記事の対称性は別の gate（既存の sitemap-audit / blog-translate 経路）が担当する。ただし海外展開を前提に置くなら、JA/EN の対称性も WARN として gate 化する価値はあり、これは別 issue として切り出して扱う。

→ sister pillar の prose 密度設計については pillar 設計の 3 層（構造 / 語彙 / prose 密度）を、spoke と pillar の cross-link 設計の全体像については bateson の経営判断と Phase 戦略を参照してほしい。