本記事に登場する
HUMAN_INPUTマーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例:<!-- HUMAN_INPUT: 数値を記入 -->）。
pillar を business cluster として設計した。H2 見出しを business 訳し、narrative_weight.primary を 75 に設定し、lead に「経営判断」と書いた。それでも本文の段落では engineering 用語が主部を占め続けた。構造と語彙では audience 分離を偽装できるが、prose 密度で実態が出る。
bateson pillar がその実例だ。bateson の場合、Booking Engine というトピックは engineering で語ることに最も意味があるため、business framing の prose を維持しにくかった。adapter / tenantId / DI（依存性注入）が段落の主部に現れ、tech 版（tech cluster として書いたほうが自然）の prose が business cluster の設計意図と乖離していた（blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md 根本原因セクション）。 最終的な解決策は「cluster を変える（tech 版として再分類し、business 版を新規執筆する）」だったが、その判断に至る前に 3 層の診断があれば早期に分岐できた。
3 層の定義と診断方法
層 1: 構造（H2 順序・narrative_weight・brief schema での設計意図）
構造は pillar の骨格だ。H2 の順序、各 H2 のタイトル、narrative_weight フィールドの設定、brief schema の cluster 設定——これらは設計意図を表す。
business cluster pillar の構造は「経営判断 → 投資判断 → 実装方針 → まとめ」のような順序になる。tech cluster pillar は「設計の問い → アーキテクチャの選択 → 実装パターン → 適用基準」のような順序になる。
構造で business 訴求を意図した pillar の診断は简単だ。H2 が「なぜ自前で作るのか」「受託 vs プロダクトの選択」「Phase 戦略」のように business framing になっているか確認する。構造が business を向いていれば、層 1 は通過している。
構造は最も操作しやすい層だ。H2 を書き直すだけで変えられる。だが構造だけで pillar の品質は決まらない。
層 2: 語彙（H2 タイトル・lead 文字列で business / tech 用語を使うか）
語彙は構造の表面に現れる単語の選択だ。H2 タイトルと lead 段落で使われている用語が business 語彙か tech 語彙かを確認する。
business 語彙の例: 「受託資産」「商用化」「Phase 戦略」「受注 funnel」「中期 ROI」「経営判断」 tech 語彙の例: 「adapter pattern」「tenantId」「DI」「multi-tenant」「リポジトリ」「API 抽象化」
語彙の診断は H2 タイトルと lead の最初の 3 段落を見ればほぼ判定できる。business cluster を意図した pillar でも、H2 内の冒頭段落に tech 語彙が散らばっていれば、語彙レベルでの分離が不完全だ。
語彙は構造より変えにくいが、まだ表面的な操作が可能だ。H2 タイトルを「Adapter Pattern の設計」から「外部ベンダーの切替え自由度」に書き換えれば、語彙は変わる。しかし段落の本体が変わらなければ、層 3 で破綻する。
層 3: prose 密度（各 H2 内の段落で audience 向けの用語が主部にあるか）
prose 密度は最も変えにくい層であり、実態が最も正直に出る層だ。
診断の方法は単純で厳しい。各 H2 内の段落を 1 つずつ見て、段落の主語・主部が何か を確認する。
- 「Adapter pattern は外部依存を抽象化する」→ 主部は「Adapter pattern」= tech 語彙
- 「外部ベンダーの切替え自由度は、商用展開先の顧客要件に対応する余地を作る」→ 主部は「外部ベンダーの切替え自由度」= business 語彙
business cluster pillar を意図した記事で、段落の主部が tech 語彙に連続して来る場合、その段落群は prose 密度で破綻している。
prose 密度の診断チェックリストは 5 項目で構成できる。各項目は「この段落の主部は何か」を問うチェックになる。
3 層の相互関係: 上位層は下位層を偽装できるが破綻は prose 密度で出る
構造（層 1）は語彙（層 2）を偽装できる。H2 の順序を business 向けにすれば、語彙を tech のままにしておいても「business cluster っぽく見える」。
語彙（層 2）は prose 密度（層 3）を偽装できる。H2 タイトルを business 訳しても、段落の主部が engineering 用語であれば実態は tech prose だ。
だが prose 密度は偽装できない。段落の主部が何かは本文を読めばわかる。層 1 と層 2 が business を向いていても、層 3 で tech prose が続けば business 読者は離脱する。3 層の中で最も正直な指標が prose 密度だ。
prose 密度で破綻するパターン — 偽装の実態
H2 タイトルを business 訳しても段落の主語が engineering 用語になる例
同じ概念を business framing と tech prose の 2 通りで書いた例を比較する。
tech prose（主部が engineering 用語）: 「Adapter pattern は外部カレンダー実装を差し替え可能にする抽象レイヤーだ。Google Calendar adapter と Outlook adapter を ICalendarAdapter interface で統一することで、実装の切り替えが DI コンテナの差し替えで済む。」
business prose（主部が business 語彙）: 「外部ベンダーの切替え自由度は、商用展開先の顧客要件に対応する余地を作る。あるテナントは Google Workspace で動き、別のテナントは Microsoft 365 に固定している——この多様性に対応できない実装は、商用化の選択肢を最初から閉じている。」
同じ「calendar の abstraction」という概念を扱っているが、主部がまったく異なる。tech prose は「pattern が何をするか」を中心に据える。business prose は「この設計が経営的に何を保証するか」を中心に据える。
bateson pillar で発生した実際の破綻パターン
bateson-engine pillar は最初 business cluster として執筆された。H2 を「なぜ予約ツールを自前で作るか」「受託 vs プロダクト」「Phase 戦略」と設定した。語彙レベルでは business framing を意図していた。
しかし retro に記録された通り、実際の段落では「adapter / tenantId / DI」が主部を占めた。設計の詳細を説明する impulse が prose に現れ続けた。engineering 用語が具体的で豊かなため、business prose より書きやすく、ディテールが豊富に出てくる——これが破綻のメカニズムだ。
最終的に user 指摘で「tech 寄り pillar として残し、business 版を新規執筆する」sister pillar 戦略に転換した。bateson-business-strategy.md として業務に書き直した business 版は、コード片なしで 12,996 字を達成した。
prose 密度の自己診断チェックリスト
prose 密度の自己診断は段落ごとに行う。以下の問いに “yes” が続くなら prose 密度は保たれている。
- この段落の主部（主語または主題句）は business 語彙か
- engineering の実装詳細を説明していないか（「どう動くか」ではなく「何を可能にするか」になっているか）
- コード片・変数名・型名・パターン名が段落内に現れていないか
- business 読者が「次の判断」をイメージできる具体性があるか
- 対義語として tech prose を書いたとき、今の段落と明確に異なるか
5 問すべてに “yes” なら、その段落の prose 密度は business cluster として維持されている。1 問でも “no” があれば、その段落は business prose として機能していない可能性が高い。
破綻の修正選択肢 — 再分類 vs 書き直し
cluster を変える（prose の実態に schema を合わせる）のコスト
cluster を tech に変える場合のコストは schema の修正に留まる。brief YAML の cluster フィールドと物理パス（src/content/magazine/tech/ 配下）の変更、pillar-relations.json の更新——これらはファイル数でいえば 5 件程度で完了する。実際の bateson cluster 再分類では bateson-engine.yaml / bateson-engine.md / bateson-business-strategy.yaml（新規）/ bateson-business-strategy.md（新規）/ _state.json の 5 ファイルが変更された（commits: 57e22ed / d854ddf / 0baaf6d、blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md 変更したファイル セクション参照）。
本文は変えない。prose が既に tech 向けに書かれているなら、cluster を tech に合わせることで「設計意図と実態の整合」が取れる。
本文を書き直す（schema の意図に prose を合わせる）のコスト
本文を business prose に書き直すコストは再分類より大きい。pillar 1 本が 5,000〜15,000 字規模の場合、段落ごとの主部を全て business 語彙に置き換える作業は機械的に自動化しにくい。
さらに書き直し後も prose 密度を維持するには、執筆プロセスに制約（後述）を組み込む必要がある。書き直しで一時的に business prose を実現しても、次の追記セッションで tech prose が滑り込む構造的リスクが残る。
sister pillar 戦略（2 cluster 並走）が合理的になる条件
「cluster を変える」でも「本文を書き直す」でもなく、「2 本立てる」が合理的になる条件がある。
条件 1: トピック自体が tech と business の両側に固有の narrative を持つ場合。bateson の場合、engineering 実装（adapter / DI / tenantId）と経営判断（Phase 戦略 / 商用化 / 受注 funnel）は別の narrative arc を持つ。どちらも削れない。
条件 2: tech spoke と business spoke が異なる cluster に向けて固有のキーワード群を持つ場合。sister pillar を立てることで、cluster SEO（pillar primary を spoke secondary に降ろす設計）が 2 方向に広がる。
sister pillar 戦略のコストは本文を 2 本書くことだ。だが再分類ゼロ + 書き直しゼロで 2 つの cluster をカバーできる場合、トータルコストは「1 本を書き直す」より低くなる。bateson の事例では tech 版を再分類してそのまま残し、business 版を新規執筆した。
まとめ — 3 層診断を設計フェーズに組み込む
brief 生成時に 3 層の整合を確認するチェックリスト
pillar の brief を生成する段階で、次の 3 問を確認する。
- 構造: H2 の順序は想定 cluster の audience に向いているか（business なら経営判断 → 投資判断の順）
- 語彙: H2 タイトルと lead に書く予定の用語は business / tech のどちらに属するか
- prose 密度の見込み: このトピックで business prose の段落を書き続けることは現実的か（コード片なしで 5,000 字書けるか）
問 3 で “no” の見込みが立つなら、brief 生成段階で sister pillar 戦略を検討する。本文を書いてから判断するより、設計フェーズで判断した方がコスト効率は高い。
prose 密度チェックを review gate に追加する提案
blog-review skill への追加として、prose 密度の簡易チェックを組み込む提案がある。
判定条件は単純に「business cluster pillar で engineering 用語（変数名・型名・コード片）が段落の主部に現れているか」だ。機械的な判定は難しいが、blog-review の SKILL.md に「business cluster pillar は段落の主部が business 語彙であることを確認する」という判定軸を追加することで、review の判断基準に明示できる。
3 層診断を pillar 執筆に組み込んだのは bateson pillar の cluster 再分類が最初で、現時点ではここから引き出した枠組みを retro として記録している段階だ（blog-ops/retros/2026-05-18-two-cluster-sister-pillar.md）。bateson 以外の pillar で同等の prose 密度破綻を観測した記録はまだないが、これは他の pillar が事前に business / tech のどちらかに寄せて設計されていたためで、診断が必要になるほど破綻していなかったからだと考えている。今後の pillar 設計では brief 生成段階で「問 3: コード片なしで本文密度を保てるか」を組み込む方向で検討している。
→ prose 密度を保つ具体的な制約設計については pillar prose 密度を保つ 2 制約 を、sister pillar の schema 拡張については sister pillar を schema で第一級表現する を参照してほしい。