Claude Code に記事生成を任せたら CI が全停止した — 直すべきは SKILL.md でなく検証ゲートだった

結論：LLM に「こう書いてね」とお願いしても、いつか必ず field は欠ける

3行サマリー（効率厨の自戒）：

• AI に記事の量産を任せていたら、ある朝 Qiita / Zenn の publish CI が全部赤くなった。frontmatter の必須 field が欠けて、CLI が全記事の publish ごと止めていた
• 「テンプレが悪い」とローカルの SKILL.md を何度直しても直らない。実際に記事を吐いていたのはローカルじゃなく、クラウドで回っているルーチンの方だった（置物を撫でていた）
• 教訓は一個。指示文（お願い）で品質を守るな。生成の出口に決定論的な門番（検証ゲート）を立てて、通らなきゃ push しない

これは誰の話か（前提）

俺のスタックは、Claude Code 系のルーチンが記事の下書きと各媒体向けの frontmatter を生成 → GitHub Actions が qiita-cli / Zenn の CLI で publish、という記事自動投稿パイプライン。要は「AI に書かせて、CI で勝手に公開する」やつを自分で組んで回している。同じことを組んでいる/組みたい個人開発者向けの、わりとガチな事故報告です。

ブログ運用を AI に任せる全体像（共有ボード・CLAUDE.md のルール・定期実行・機械チェックのどれを足すか）は別記事に書いた。この記事はそのうちの「機械チェック」を、実際に全停止して学んだ1点だけ深掘りする。

① イラッと：ある朝、CI が全部赤

朝イチの CI ブリーフを見たら、Qiita も Zenn も publish が連続で失敗していた。しかも新しい記事だけが落ちるんじゃなく、CLI が「1本でも frontmatter が不正なら全部止める」挙動で、既存の投稿済み記事まで巻き添えで publish が止まる。自動化したはずが、気づかないうちに全停止していた、という効率厨が一番こわいやつ。

② 仮説（誤）：ローカルの SKILL.md を直せば直る

最初の犯人読みは「生成テンプレが悪い」。ローカルにある記事生成スキルの SKILL.md（frontmatter テンプレが書いてあるファイル）をカチャカチャ直す。直らん。もう一回直す。直らん。ぐぬぬ。

③ 試した結果：生成元はローカルじゃなくクラウドだった

ここで効率厨の典型ミスを踏んでいたと気づく。動いている場所を勘違いして、関係ないファイルを延々いじっていた。

実際に各媒体向けの frontmatter を生成しているのは、停止中のローカル SKILL.md ではなく、クラウドで稼働しているルーチン（content-executor）側。ローカルのファイルは正しいテンプレを持ってはいるが、もう実行経路に乗っていない。ただの置物。authoritative（本物の設定）は /schedule 側のクラウドにあった。撫でても無反応だったのはそういうこと。

④ 真因：LLM に frontmatter を「お願い」していたこと

場所が分かっても、根っこはもっと手前にあった。LLM に「この通りに frontmatter を書いてね」とテキストで指示していたこと自体が地雷だった。LLM は大体は守る。でもたまに updated_at や id みたいな必須 field を静かに落とす。そして qiita-cli は欠けた1本に対して --all モードで全 publish を止める。確率は低くても、母数（記事数）が増えれば必ず踏む。

実はこれ、5月にも同じ型でやらかしている。そのときは約10日・14回連続で CI が失敗し、50本以上の記事の publish が止まっていた（その後 id: null → '' の修正と validate-frontmatter の自動修正化で復旧した）。今回6月にまた同じ型で再発した時点で、「これは運じゃなく構造の問題」と確定した。学習しろよ俺。

⑤ 再現手順：指示文をやめて「決定論的ゲート」を出口に立てる

再発を止めた対策はシンプルで、誰でも真似できる。要は**「お願い」を信用するのをやめて、機械的に止める門番を生成の出口に置く**だけ。

1. push 前に決定論的検証を挟む：validate-frontmatter.sh（必須 field が1つでも欠けていたら exit 1）を生成直後・push 前に走らせ、通らなければ push しない。LLM の出力品質に依存せず、機械が弾く
2. 恒久修正は「実行経路に乗っている場所」に入れる：ローカルの置物 SKILL.md ではなく、実際に生成しているクラウドルーチンの生成ステップにテンプレ＋検証を埋め込む。直す前に「authoritative はどこか」を必ず確認する
3. 巻き添えを防ぐ：投稿済みの記事は ignorePublish: true 相当にして、新規1本の不正で既存全部が道連れにならないようにする

ポイントは「LLM をちゃんとさせる」方向に頑張らないこと。LLM は確率的に間違える前提で、出口に確定的な関所を置く。これが LLM 自動化の信頼性設計の芯だと思っている。

今日やること（3つ以内）

• 自分の LLM 自動化パイプラインで「LLM の出力をそのまま外部 CLI / API に渡している箇所」を1つ挙げる。そこが地雷
• その出口に、必須項目が欠けたら exit 1 で止まる検証スクリプトを1本噛ませる（push / 投稿の前に）
• 「自分がいじっているファイルは、本当に実行経路に乗っているか？」を確認する（ローカルの置物を撫でていないか）

次に読む

LLM に運用を任せる設計の話を、効率厨の実験ログとしてこの先も書いていきます。「AI と仕組みで、事業も体も暮らしも攻略する」実録と再現テンプレは、登録するとすぐ届く特典（ブログ解析を Claude Code に丸投げする8ステップ手順）と一緒にメルマガで配っています。下から登録できます。