blog-gate を戦略ゲートに拡張する — 欠落検出を cosmetic から G ルールへ

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

blog-gate が検出してきたのは、表記ゆれと禁則語だ。「DX」「革命的」「弊社」——cosmetic な失敗を機械が止める。だが pillar の seo セクションが丸ごと欠けたまま公開スケジュールに入る事故は、cosmetic gate をくぐり抜けた。発覚したのは pillar #3 bateson の brief 確認段階だったが、先行する 2 本（reset-timeline / mcluhan）は既に schedule 済だった。

構造的な欠落は cosmetic gate では止められない。止めるには、gate のルール対象を cosmetic から戦略レイヤーまで拡張する必要がある。G ルールに「pillar の seo セクション 4 必須フィールド欠落で fail」を追加することで、設計の失敗を本文執筆前に構造的に防げる。

cosmetic ゲートと戦略ゲートの違い

G1〜G10 が対象にする cosmetic レベルの失敗例

現在の blog-gate.ts は G1〜G13 のチェックを実装している。

代表的な cosmetic チェックを挙げる。

G1: HUMAN_INPUT マーカー残存（未解決の人力入力が本文に残っていないか）
G2: 内部リンクに /blog/ パスが残存（廃止パスの混入検出）
G3: タグが tags.ts の SSOT に存在しない
G10: Yakumo 自身を 会社 / 企業 と記述している

これらはいずれも「書き方の問題」だ。本文の中で禁止パターンを検出して止める。重要なチェックだが、gate の対象は本文・フォーム・タグのような表面的な属性に限定されている。

戦略レイヤー欠落が cosmetic ゲートでは検出できない理由

seo セクションの欠落は本文の中には現れない。brief YAML の特定フィールドが存在するかどうか、という構造の問題だ。cosmetic gate が本文を走査しても、YAML の seo: キーが存在しないことは検出できない。

audience.primary の未設定も同様だ。「誰に向けて書くか」が決まっていない状態で pillar が存在しても、gate はパスしてしまう。

これが cosmetic ゲートと戦略ゲートの本質的な違いだ。cosmetic gate は「書き方の失敗」を止める。戦略 gate は「設計の失敗」を止める。

どの欠落が最も被害が大きいか

seo セクション欠落 vs 禁則語混入の被害を比較する。

禁則語（「DX」「弊社」等）が 1 件混入した記事は、公開後に編集すれば済む。読者体験の劣化は限定的で、一般論として修正コストは低い。

seo セクション欠落で pillar を公開した場合の被害は構造的だ。primary keyword が設定されていないため、下流 skill（blog-tech-write / blog-review / blog-meta）が seo セクションを読みに行くことができない。本文の H2 配置にキーワードが反映されず、meta title/description も最適化されない状態で公開される。さらに cluster SEO（pillar の primary keyword を spoke の secondary に降ろすデザイン）も機能しない。

pillar 3 本の seo セクション欠落が実際に起きた。3 本が欠落状態で公開スケジュールに入った。bateson は brief 段階で対応できたが、他 2 本は description のみの retrofit で schedule 直前リスクを残した。

戦略欠落を G ルールで検出するパターン

G11: pillar の seo セクション 4 必須フィールド欠落で fail

G11 の実装概念は次の通りだ。

is_pillar === true の brief YAML に対して:
  seo.primary_keyword が存在しない → fail
  seo.secondary_keywords が空配列 → fail
  seo.search_intent が存在しない → fail
  seo.serp_title_finalized が存在しない → fail

scripts/blog-gate.ts の parseBriefForG11 関数が brief YAML を読み込み、isPillar: true の場合に seo セクションの必須 4 フィールドを検証する。1 件でも欠落していれば Failure を積み、exit 1 で処理を停止する。

重要なのは検出のタイミングだ。G11 は pillar の brief YAML を対象にする。本文ファイル（.md）が存在しない段階でも動作するため、本文執筆前に設計の欠落を止められる。

G12: is_pillar=true の audience.primary が未設定で fail

G12 相当（現在の実装では G11 の延長として扱われている）の検出対象は audience.primary の未設定だ。

pillar は特定の audience に向けた主軸コンテンツであり、audience.primary が未設定の状態は「誰に向けた pillar か設計が完了していない」ことを意味する。この状態で本文執筆に進むと、narrative arc の設計が audience を想定せず始まってしまう。

blog-tech-write skill は brief の audience.primary を参照して語彙レベルと説明深度を調整する契約を持つ。hub に値がなければ、下流 skill の出力品質が保証されない。

ルール追加の実装パターン

scripts/blog-gate.ts への追記は次の構造に従う。

checkG11_PillarSeoSection 関数内の parseBriefForG11 が返すオブジェクトに、新たに検証したいフィールドの存在チェックを追加する
欠落フィールドを missingFields 配列に積む
missingFields.length > 0 のとき Failure を生成して failures 配列に push する
failures が 1 件以上あれば exit 1 で処理を止める（この流れは既存の G1〜G10 と同一）

新しい必須フィールドが brief YAML スキーマに追加されるたびに、parseBriefForG11 に 1 行追加するだけで gate の検出対象が広がる。この設計は「ルールを増やすコスト」を最小化している。

gate 拡張の設計判断 — どこまで機械で止めるか

false positive のコスト

false positive（正常な記事を誤って fall させる）のコストは見えにくい。ルールを厳しくするほど、正常に設計された記事が gate で止まる頻度が上がる。執筆者は「なぜ止まったか」を調べるコストを払い、場合によっては gate 自体への信頼を失う。

false positive の代表例は「必須」として定義したフィールドが実は省略可能なケースだ。たとえば spoke 記事に pillar と同じ seo セクション必須ルールを適用すると、spoke の brief が常に fail する。G11 が is_pillar === true の場合のみに限定している理由はここにある。

false negative のコスト

false negative（戦略欠落が gate を通過する）のコストは見えやすい。公開後に問題が発覚し、事後修正のコストが発生する。

seo セクション欠落の場合、公開後の修正は description の retrofit に留まる。title / H2 の修正は既存 URL の変更を伴う場合があり、公開後は選択肢が減る。

つまり false negative は「取り返しのつかなさ」が高い。

バランスの判断基準

設計時に決まっているべき情報は機械ゲートの対象にする、というのがバランスの判断基準だ。

seo.primary_keyword は pillar の brief を書く段階で決まっている。audience.primary も brief 生成時に設定する情報だ。これらは「書き忘れ」が発生しやすく、かつ設計時点で存在すべき情報だ。機械ゲートに適している。

一方、本文の「論旨の一貫性」や「H2 間の narrative arc の整合」は機械ゲートで検出しにくい。これらは blog-review skill が担う人間判断の領域だ。機械ゲートに含めても false positive が増えるだけで、検出精度が出ない。

「機械が stop できる失敗は機械に止めさせる。機械が判断できない領域は人間が判断する」——この分業がゲート設計の指針になる。

まとめ — 機械が止める範囲を広げる意義

人手レビューが本当に判断すべき領域への集中

機械ゲートが cosmetic チェックだけを担う場合、blog-review の人手判断は「禁則語があるか」から「narrative arc は一貫しているか」まで、広い範囲を並行して見ることになる。

戦略欠落を G ルールに含めると、人手レビューが集中できる領域が変わる。機械が止めた「seo セクション欠落」は人間が見なくてよい。人間の判断リソースは「audience に本当に届いているか」「pillar の narrative arc に説得力があるか」という機械では評価しにくい観点に集中できる。

gate 拡張のコストと繰り返し事故防止のトレードオフ

scripts/blog-gate.ts にルールを 1 行追加するコストは小さい。一方、pillar 3 本の seo 欠落を後追い retrofit するコストは、brief 段階で防ぐコストより確実に大きい。

gate 拡張のコスト対効果は非線形だ。実装コストは 1 回だが、防ぎ続けるコストは 0 に近い。事故が繰り返されるほど対効果が上がる。

「機械検出の対象を cosmetic から戦略レイヤーの欠落まで広げる」という方針は、コスト計算が終わったあとの結論ではなく、設計の出発点として持つべき前提だ。

→ pipeline の戦略レイヤー設計の全体像は AI エージェントハーネスの設計原則を、brief YAML を hub にする設計の詳細は brief YAML を skill 間 hub にする設計を参照してほしい。

→ 機械が止められなかった失敗が実際にどう発覚し、なぜ gate 拡張が必要になったかの経緯は AI 量産ブログを約 1 週間で全撤退した話を参照してほしい。

→ G ルール拡張で避けて通れない false positive / false negative のチューニング設計については Pre-publish gate 設計 — false positive と false negative の両立を参照してほしい。