機械的 gate で persona 欠落を fail にする設計

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

コンテンツパイプラインを運用していると、「persona を決めてから書く」という手順を踏んだつもりなのに、気づいたら persona が空欄のまま記事が進んでいた、という経験をする。人間の注意力は有限だ。忙しい日の brief 確認で、audience フィールドへの記入が抜けることは構造的に起きる。

その問題を「気をつける」で解決しようとするのは誤りだ。機械的な gate で構造的に防ぐ。blog-gate G11 は、pillar の audience.primary が欠落しているときに pipeline を fail させる設計だ。persona を決めない限り、記事は先に進めない構造を作ることで、「後から直す手戻り」を設計段階で吸収する。

→ この gate が守る audience.primary 設計の全体像は mcluhan エンジン設計原則を参照してほしい。

persona 欠落がなぜ繰り返されるか

freeform text の audience フィールドは検証不可能だった

2026-05-18 の設計変更前、brief YAML の audience フィールドは target_audience.role という freeform text フィールドだった。そこには「経営者・PM・CTO・事業責任者」のように、複数 persona を一行に bundles して書くことができた。

機械は「経営者・PM・CTO・事業責任者」が有効な persona 指定かどうかを判定できない。gate は「フィールドが空かどうか」しかチェックできなかった。つまり、freeform text に何かが書いてあれば、gate は通過してしまった。

実際には、「経営者・PM・CTO・事業責任者」というフィールドは persona を定義していない。narrative arc・H2 重み・専門用語閾値が何も決まらない状態で「audience あり」扱いになっていた。

人間の注意力に依存した品質チェックの限界

freeform text 時代の品質チェックは、実質的にレビュワーの注意力に依存していた。

brief 作成者が audience フィールドを書く（freeform text）
レビュワーが「本当に 1 persona に絞れているか」を確認する
確認が不十分なまま執筆フェーズに進む

この手順で失敗するのは、「確認が不十分」なときではなく、「確認が行われなかった」ときだ。締め切り前の忙しいセッションで、brief の audience フィールドを深く確認する余裕はない。戦略的な欠落は、cosmetic な品質チェック（文字数・誤字）の影に隠れて見過ごされる。

直近の事例は 2026-05-18 の mcluhan pillar で発生した。「dual audience のつもりが tech に倒れている」状態が公開前レビューで発覚し、その日のうちに audience フィールドを freeform text から clusters.{business|tech}.personas の SSOT taxonomy に格上げする設計判断に至った。発覚から SSOT 反映まではおよそ半日で、taxonomy 化を経なければ pillar 再執筆級の手戻りが発生していた可能性が高い。

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

G11 の判定ロジック

scripts/blog-gate.ts の G11 は以下の条件で fail を返す:

G11: pillar audience.primary 欠落検出
  条件: brief.is_pillar === true && brief.audience.primary が undefined または空
  結果: fail（pipeline 停止）
  理由: pillar は cluster 全体の narrative 重心を持つ。persona なしで執筆した pillar は中庸化する

G11 が fail を返すと、pipeline の write フェーズ（blog-tech-write または blog-case-write）に進めない。audience.primary に値を設定し、gate を再通過するまで先に進めない構造だ。

spoke（is_pillar=false）の場合、G11 は必須チェックではなく警告（WARN）として扱う。spoke は pillar の narrative arc を引き継ぐため、pillar の audience 設計が確立していれば spoke の audience 欠落リスクは相対的に低い。

scripts/blog-gate.ts には G1〜G13 の 13 個の必須チェックが定義されており、G11 はその中の 1 つだ。cosmetic チェック（G1: HUMAN_INPUT 残存、G2: 内部リンクの誤り、G3: タグ SSOT 照合）と戦略チェック（G11: pillar の audience/cluster/seo セクション欠落）が同一フレームワーク上で管理されている。

SSOT taxonomy との照合は skill / agent 層が担う分業構造

「freeform text が入っていれば G11 が fail を返す」ことが理想だが、現状の G11 は presence チェックまで、taxonomy 照合は @seo-director と執筆 skill が audience-tracks.json を読んで担当する分業になっている。

blog-ops/config/audience-tracks.json には valid な persona 名が列挙されている。@seo-director は brief 作成時にこのファイルを参照し、audience.primary に taxonomy 外の freeform text（例: "経営者・PM"）を書かないよう執筆 skill に渡す。

これにより:

audience.primary: "senior-engineer" → pass（taxonomy に定義済み、G11 も presence チェックを通る）
audience.primary: "エンジニア一般" → skill / agent 層で検出して書き直しを促す（G11 は値の妥当性まで見ない）
audience.primary: "" → G11 が fail（空文字はそもそも presence なし扱い）

「空欄」は機械が止めるが、「埋まっているが taxonomy 外」は agent 層で止める——この 2 段構えにすることで、G11 自体の実装を最小に保ちつつ taxonomy のメンテナンスは SSOT 1 ファイル（audience-tracks.json）に集約できる。将来 G11 を taxonomy-aware に拡張する余地はあるが、まずは「フィールドが書かれているか」のレイヤーを安定させる優先順位を取っている。

実装は scripts/blog-gate.ts:597-725 にある。parseBriefForG11() が brief YAML をテキストレベル（正規表現）で parse して ^is_pillar:\s*true\s*$ の有無を判定し、is_pillar: true でなければ checkG11_PillarSeoSection() の line 688 で early-return して spoke の brief を G11 のスコープから外す。pillar として判定された場合のみ、cluster:\s*(business|tech) の有無、audience: ブロック内の primary: フィールドの有無、narrative_weight.primary + secondary の合計、seo: セクション内の 4 必須フィールド（primary_keyword / secondary_keywords / longtail_clusters / search_intent）の有無を順番にチェックする。注意点は、現状の G11 は フィールドが書かれているかを見る presence チェックで、audience.primary の値が blog-ops/config/audience-tracks.json の taxonomy に含まれるかという valid-value 照合までは入っていない点だ。taxonomy 照合は @seo-director および執筆 skill 側が audience-tracks.json を読み込んで担当する分業構造で、G11 はその前段の「欠落そのもの」を機械で止める層に絞っている。

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

gate が止める範囲と止めない範囲

機械が止めるもの vs 人間が判断するもの

G11 が止めるのは「構造的な欠落・無効値」だ。以下の 2 種類に分類できる:

使い分けは scripts/blog-gate.ts:691-723 の checkG11_PillarSeoSection() で確認できる。

fail（pipeline 停止）: cluster フィールド欠落 / audience.primary フィールド欠落 / seo: セクションの必須 4 フィールド（primary_keyword / secondary_keywords / longtail_clusters / search_intent）のいずれか欠落
warn（警告のみ）: narrative_weight.primary + secondary の合計が 100 でない（執筆中の調整途中で 100 に揃わない局面を許容するため fail にしない）
skip（チェック対象外）: draft 状態の記事（line 672 の if (isDraft) return）/ is_pillar: false の brief（line 688 の if (!isPillar) return）

pillar と spoke の扱いの違いは「G11 が spoke を skip する」という形で実装されている。spoke に同種の制約をかけたい場合は別の G ルールとして追加する設計で、G11 自体は pillar 専用に絞っている。

機械が止めるもの	人間が判断するもの
`audience.primary` の欠落	`audience.primary` の妥当性（「senior-engineer が本当に適切か」）
taxonomy 外の persona 名	persona の選択理由（「なぜ architect ではなく senior-engineer か」）
`cluster` フィールドの欠落	cluster の適切性（「business と tech どちらが正しいか」）

G11 は「設定されているかどうか」を検出する。「設定された値が正しいかどうか」は人間が判断する。この境界線は重要だ。機械に「architect と senior-engineer のどちらが適切か」を判断させようとすると、gate は複雑になりすぎる。機械に委ねるのは「有/無」と「valid/invalid」の 2 点だけだ。

戦略的欠落を gate で検出する原則

cosmetic チェック（文字数超過・誤字・NG ワード）と戦略的チェック（audience.primary 欠落・seo セクション欠落）を同じ gate フレームワークで扱えることは、品質保証の設計として重要だ。

従来の pre-publish gate は cosmetic に偏っていた。「タイトルが 30 字以内か」「NG ワードが含まれていないか」は重要だが、「この記事が誰向けに書かれているか決まっているか」という戦略的な問いを gate に組み込むことで、pipeline が「品質の守り手」として機能する範囲が広がった。

導入後の効果と副作用

2026-05-18 に G11 を導入した時点では、すでに pillar 3 本（reset-timeline / mcluhan / bateson）の brief は SEO セクション・audience.primary 付きで書き直し済みだったため、本番運用で G11 が新規 brief に対して初めて fail を返す機会はまだ訪れていない。ただし test fixture（cluster / audience.primary / seo セクション欠落版の brief）に対しては想定通り fail を返すことを確認済みで、次に新規 pillar を書くタイミングで「埋め忘れて fail に当たる」エピソードが発生する見込みだ。その段階で「persona 設計を意識するきっかけになったか」という効果計測を retro に残す予定にしている。

gate が厳しすぎる場合の調整ポイント

G11 は pillar（is_pillar: true）のみを対象とし、spoke は WARN 扱いにしている。この設計は「厳しすぎる gate が生産性を下げる」問題への対処でもある。

すべての記事に G11 の必須チェックを課すと、実験的な spoke や draft 段階の記事で gate が頻繁に fail し、パイプラインが詰まる。pillar は cluster 全体の narrative 重心を決めるため、persona の明示が特に重要だ。spoke は pillar の narrative arc を引き継ぐため、pillar さえ決まっていれば相対的に寛容な運用ができる。

この「pillar = 必須、spoke = 推奨」の二段階設計は、gate の厳格さと運用の柔軟性を両立させる。

まとめ — 戦略的欠落を機械が止める設計

persona を決めないまま執筆に流れる事故は、人間の注意力を鍛えても防げない。設計で防ぐ必要がある。

blog-gate G11 がとったアプローチは 3 つだ:

freeform text から taxonomy への移行: audience-tracks.json で valid な persona 名を定義し、機械検証可能にした
欠落と無効値を同列に fail に: 「何か書いてあればよい」から「valid な値が設定されているか」へ検証精度を上げた
pillar のみ必須、spoke は推奨: 戦略的重要度に応じて gate の厳格さを使い分け、運用コストとのバランスを取った

「戦略的欠落を gate で防ぐ」という設計原則は、audience だけでなく SEO セクションの欠落検出（pillar の seo フィールド欠落を fail にする設計）にも応用できる。gate は cosmetic な品質番人から、戦略的設計の番人へと責務を拡大できる。

→ この gate が保護するコンテンツ設計全体の構造については cluster と persona の関係 — 外向き・内向き軸の設計を参照してほしい。