本記事に登場する
HUMAN_INPUTマーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例:<!-- HUMAN_INPUT: 数値を記入 -->）。
business cluster pillar に「この段落の主語が engineering 用語になっていないか」と指示を出すだけでは足りない。intent の伝達で prose の密度は保てない。次の執筆セッションで再び tech prose が滑り込む。prose 密度は「意図を伝える」ではなく「生成を制約する」構造的アプローチで保つ。
2 つの制約が効く。コード片の全面禁止と、段落の主部への経営判断用語配置だ。どちらも「business らしく書いてほしい」という曖昧な指示ではなく、prose 生成に直接バリアを張る仕組みだ。bateson business pillar（2026-05-bateson-business-strategy）はコード片を一切貼らずにこの 2 制約を適用して 12,996 字を書いた。
制約 1: コード片の全面禁止
コード片が business prose を破壊するメカニズム
コード片が本文に現れると、読者の認知が「business の文脈」から「tech の実装コンテキスト」に強制的に切り替わる。
変数名（tenantId）、型名（ICalendarAdapter）、関数呼び出し（adapter.getSlots()）——これらが段落に出てきた瞬間、business 読者は「自分に向けた文章ではない」と判断する。エンジニアが書いたコードを見ている、という体験に切り替わる。
この切り替えは 1 行で起きる。段落の 9 割が business prose であっても、コード片が 1 箇所あれば prose 密度が壊れる。「小さな混入だから許容範囲」は存在しない。
コード片の問題は見た目の問題ではなく、読者の認知負荷の問題だ。エンジニアはコード片を自然に読み飛ばすが、business 読者は「これは何か」「自分には関係ないか」を判断するコストを払う。コード片が多いほど business 読者のコストが積み上がり、最終的に離脱する。
must_avoid に「コード片を本文中に貼る」を追加する実装
brief YAML の must_avoid フィールドへの追記は 1 行で済む。
must_avoid:
- "コード片を本文中に貼る（変数名・型名・関数名・パターン名を英字で本文に出現させることを含む）"
- "engineering 用語を段落の主部・主語に置く"1 行目が形式的な制約だ。「コード片」の定義を「英字の変数名・型名」まで拡張することで、コードブロック（``` で囲まれたもの）以外のインライン技術用語も制約対象になる。
2 行目が prose 密度の制約だ（後述する制約 2 と重なる）。
must_avoid に記述することで、blog-tech-write skill が本文を生成するとき、この制約が SKILL.md の契約として機能する。「コード片」の禁止を explicit に書いておくことで、曖昧な「business らしく」という指示より精度の高い制約になる。
tech 詳細を sister pillar / spoke に委ねる cross-link 設計
コード片を禁止すると、「engineering の具体性がなくなって説得力が落ちる」という懸念が出る。これは sister pillar / spoke への cross-link で対処する。
business pillar: コード片なし。経営判断・Phase 戦略・ROI を中心に書く
→ "engineering 実装の詳細は [tech pillar] を参照してほしい" という cross-link
tech pillar: コード片あり。実装の詳細を具体的に示す
spoke: 特定テーマの実装を deep dive するbusiness 読者は business pillar を読んで「設計判断の意味」を理解する。tech 詳細が知りたい読者は cross-link をたどって tech pillar に移動する。2 本を連動させることで、business pillar がコード片なしでも具体性を失わない設計になる。
bateson business pillar の lead 冒頭 1 文がこの設計を実装している。「engineering 実装の詳細は [Booking Engine を自作する設計戦略] を参照してほしい」と明示し、本文ではコードを一切扱わない宣言をしている。
制約 2: 経営判断用語の主部化
経営判断用語の主部化とは何か（具体例と対比例）
「経営判断用語の主部化」は、段落の主語または主題句を経営判断に関わる用語（ROI・Phase 戦略・選択肢・受注 funnel・中期投資・商用化等）に固定するという散文技法だ。
before（engineering 用語が主部）: 「Adapter pattern は外部カレンダー実装を差し替え可能にする抽象レイヤーだ。ICalendarAdapter インタフェースで統一し、Google と Outlook の adapter を差し替えられる設計にする。」
after（経営判断用語が主部）: 「外部ベンダーの切替え自由度は、商用展開先の顧客要件に対応する余地を作る。カレンダーシステムの選択肢を自社に固定しない設計が、将来の顧客多様性に対応する基盤になる。」
同じ「calendar の abstraction」について書いているが、前者は「Adapter pattern が何をするか」を主部に置き、後者は「切替え自由度が何を可能にするか」を主部に置く。
before（ROI の言い方が抽象的）: 「この設計は Phase B への移行を容易にする。multi-tenant 化のリファクタコストを下げる効果がある。」
after（経営判断の主体を明示）: 「Phase B の投資判断は、Phase A でどの設計規律を守ったかにのみ依存する。Phase A でテナント分離の置き場所を確保しておくことが、Phase B への移行判断から実行開始までを短縮する。」
前者は「設計がコストを下げる」という passive な描写。後者は「Phase B の投資判断」という経営アクションを主部に置き、それが何に依存するかを述べる。
engineering 用語が段落の主部に滑り込む典型パターン
3 つの典型パターンがある。
パターン 1: 設計概念名が主語になる 「DI コンテナは依存関係の注入を管理する」「adapter は実装を差し替え可能にする」——これらは engineering 概念が主語だ。business prose では「DI コンテナ」「adapter」という単語を段落の主部に置かない。
パターン 2: 実装の手順説明が段落を占める 「まず interface を定義する。次に実装クラスを作る。最後に DI で差し込む」——これは手順の説明だ。business prose は「何が可能になるか」を語り、「どうやって実装するか」は語らない。
パターン 3: tech 用語の説明が business 文脈に先行する 「テナント分離とは複数顧客のデータを論理的に分けることだ」——用語定義が先行する。business 読者は用語定義より「その設計が経営的に何を意味するか」を先に知りたい。
段落ごとの主部チェックリストの作り方
実践的なチェックは段落の最初の文の主語を書き出すことだ。
- 段落の最初の文を書いた後、主語（主部）を括弧で囲む
- 括弧内の語が engineering 用語なら → 書き直しが必要
- 括弧内の語が business 語彙（ROI・投資・選択肢・段階・経営判断・競争優位・顧客等）なら → そのまま続ける
段落単位でこのチェックを行うことで、prose 密度の維持が機械的な確認作業になる。「良い prose かどうか」という主観判断より、「主部は何か」という事実確認で判定できる。
2 つの制約を brief の must_avoid に組み込む
must_avoid フィールドへの具体的な記述例
brief YAML の must_avoid に組み込む記述例:
must_avoid:
- "コード片を本文中に貼る（変数名・型名・関数名・抽象クラス名・パターン名を英字で本文に出現させることを含む）"
- "engineering 用語を段落の主部・主語に置く（Adapter / DI / interface 等が文頭の主語になることを含む）"
- "tech 詳細を本文で説明する（tech 詳細は sister pillar または spoke への cross-link で委ねる）"
- "実装手順の説明（まず〜、次に〜の形式で手順を追う記述）"4 行で prose 密度の制約を網羅できる。1 行目がコード片禁止（制約 1）、2〜4 行目が経営判断用語の主部化に関連する制約（制約 2 の別表現）だ。
blog-review skill がチェックできるルール粒度の設計
must_avoid の記述を blog-review の判定基準として機能させるには、具体性が必要だ。「business らしく書く」では review の判定軸にならない。
review がチェックできる粒度の例:
- 「英字の単語（変数名・型名相当）が段落内にあるか」→ 機械的に検出可能
- 「各 H2 の最初の段落の主語が engineering 用語か」→ LLM での判定が可能
- 「tech の手順説明（まず〜、次に〜）があるか」→ パターンマッチで検出可能
「より良い prose か」という aesthetics の判断は review には向かない。must_avoid に記述した具体的な制約違反を機械的に検出することが review の責務だ。
brief 段階で制約を明示することで AI 執筆時に prose 密度が保たれる理由
制約を must_avoid に書いておくと、blog-tech-write が本文を生成するとき、constraint として読んで従う。「コード片を本文中に貼るな」という制約は、技術系の話題を書くとき自然に出てくる tech prose を抑制する明示的な指示になる。
「business らしく書いてほしい」では AI は「全体のトーンを business に」と解釈し、段落ごとの主部チェックまでは行わない。「変数名・型名を英字で段落に出現させるな」は具体的な出力制約として機能し、prose 密度が段落単位で保たれる確率が上がる。
まとめ — prose 密度は意図でなく制約で保つ
prose 密度は執筆者の意図より構造的制約で決まる
business prose を書くことへの意識が高くても、tech の話題を business 向けに書くとき engineering 用語が自然に出てくる impulse は止めにくい。意図より馴染みのある語彙が先に出る。
制約はその impulse を止める構造だ。コード片禁止は「貼りたいが貼れない」状況を作る。主部チェックは「書いた後に確認できる」基準を与える。どちらも「意識する」より「確認できる」に向けた設計だ。
2 制約の組み合わせで business cluster pillar の品質がどう変わったか
bateson business pillar は 2 制約を適用した。コード片なし、経営判断用語（受託資産・商用化・Phase 戦略・受注 funnel）を段落の主部に置く。結果として、「engineering 用語が主部を占めない」状態の維持自体には大きな苦労はなかった。執筆段階で困難に直面した記憶はなく、むしろ brief の must_avoid に事前にコード片禁止が入っていたことで impulse が発生する前に抑制されていた、という構造が機能した。
一方で副作用として、HUMAN_INPUT という社内マーカー語を本文中で当たり前のように使ってしまい、初めて記事を読む人には何を指しているのか分かりにくい箇所が残った（これは別記事の冒頭で注釈を入れる方針で補正している）。
最終的に business 読者向けの記事として品質が保たれていると判断した根拠は、八雲が business 読者に伝えたい方針（受託資産・商用化・Phase 戦略・受注 funnel という経営判断の語彙で意思決定を語る）を本文がそのまま反映していた点にある。語彙制約が方針を歪めず、方針を「書きやすい形」に翻訳できていた。
「制約があると書きにくい」という感覚は正しい。制約は書きやすさを下げる代わりに、prose 密度を保つ構造を作る。制約のコストは執筆者が払い、business 読者が読みやすさとして受け取る。
この 2 制約は既に部分的に組み込まれている。2026-05 時点で実装した business cluster pillar の brief には must_avoid に「コード片を本文中に貼る」が個別に書かれており、blog-tech-write skill は brief の must_avoid を読んで執筆段階に反映する。残っているのは brief を新規に作る側、blog-plan skill のテンプレートに「business cluster の場合はこの 2 制約を default で must_avoid に入れる」というロジックを組み込む工程だ。これが入れば business cluster pillar の brief 生成は人手の追記なしで 2 制約が走る。
書きたい衝動を強く感じた箇所は記録としては残っていない。git log を確認しても「コード片を削除した」「engineering 用語を主部から外した」という修正履歴はなく、bateson business pillar の本文は最初の draft 段階から sister tech pillar への cross-link で実装詳細を委譲する構造で書かれていた。「書いた後に困難に直面した」のではなく、brief の must_avoid に「コード片禁止」が事前に入っていたことで、執筆 LLM 自身がコード片を提案しない状態が作られていた結果だと見ている。
→ prose 密度の診断方法（3 層の枠組み）については pillar 設計の 3 層（構造 / 語彙 / prose 密度） を、sister pillar の schema 設計については sister pillar を schema で第一級表現する を参照してほしい。