Supabase のブリーフキューを起点に Claude Code が記事を書いて Qiita・Zenn・はてなへ配信するパイプラインを実運用しています。CLAUDE.md・adapt-spec ファイル・クラウドルーチンの 3 レイヤー設計と、実際に踏んだ落とし穴を公開します。

構成

環境: masatoman.net（Next.js + Supabase）+ Qiita / Zenn / はてな外部配信
実行主体: content-executor v2.1（クラウドルーチン、火〜土 02:00 JST 自動実行）
記事ソース: Supabase content_briefs テーブルの status='planned' ブリーフ

パイプライン全体図

1. [Supabase: content_briefs]
   status='planned' のブリーフをキューイング
   （title_proposal / slug_target / rationale / data_evidence）

2. [content-executor routine]
   02:00 JST 起動 → ブリーフを 1 件取得（priority ASC）
   → CLAUDE.md の指示に従い MDX 執筆（1500〜3000 字）
   → publish-gate（誇張 grep + lint-article-claims.mjs）
   → masatoman.net リポジトリに push
   → push 検証（git merge-base で main 到達を確認）

3. [外部配信 Step5]
   adapt-spec ファイルを Read → 媒体別 Markdown を生成
   → Qiita / Zenn / はてな / Dev.to / note へ push

4. [SNS 配信]
   疎結合ルーチン x-thread-distributor が記事 URL を X スレッドに投稿

各ステップに「落ちたら公開しない」ゲートが挟まっています。push が main に届いたことを確認してから published にするステップがポイントです（後述の落とし穴 1）。

各レイヤーの役割

CLAUDE.md — 指示書

リポジトリルートに置く CLAUDE.md が content-executor の唯一の仕様書です。次の 4 点を記述します。

ターゲット読者の定義
禁止パターン（「稼げる系」「使ってみた型」等）
標準記事構造（結論 → 前提 → 詰まり → 実際 → 判断軸 → 今日やること）
frontmatter の必須フィールドと値の制約

adapt-spec ファイル — クラウドで Skills の代わりになるもの

当初はローカルの Skills ファイル（~/.claude/skills/）に媒体別ルールを書いていましたが、クラウドルーチンはローカルファイルを参照できません。

解決策は docs/adapt-spec-{媒体}.md というリポジトリ内ファイルです。content-executor は Step5 でこのファイルを Read してから配信用 Markdown を生成します。Qiita / Zenn / はてな / Dev.to / note の仕様はそれぞれ異なるため、ファイルを分けて管理します。

クラウドルーチン — スケジュール実行の本体

Claude Code on the Web のルーチン機能で自動起動します。「Supabase から planned を 1 件取って MDX を書いて push する」手順を自然言語で記述するだけです。

重要な設計判断: 書き手ルーチンは 1 本に絞る。

複数の自動書き手（Cowork aff-crew、night-writer 等）を並走させたところ、push 衝突・同スラッグの重複生成・旧 CTA 混入が頻発しました。2026-06-23 に legacy aff-crew を全部停止し、content-executor 1 本に集約しました。

実際に踏んだ落とし穴

1. ゴーストパブリッシュ

push が成功していないのに Supabase のステータスを published に更新するバグ。git merge-base --is-ancestor で push が main に届いたかを確認するステップを追加して解決。到達しない場合は status='planned' に差し戻します。

2. フォーマット指示違反

CLAUDE.md に「このフォーマットで出力」と書いても LLM は確率的に崩します。Qiita/Zenn の frontmatter 崩れで CI が 10 日間連続失敗した事故から、validate-frontmatter.sh を push 前に必ず通すゲートを追加しました。

3. 書き手の並走

前述の通り。同一リポジトリへの複数ルーチンの書き込みは衝突します。書き手は 1 本に集約してください。

最小構成で始める手順

Supabase に content_briefs テーブルを作る（id, title_proposal, slug_target, rationale, status, priority）
リポジトリルートに CLAUDE.md を置き、ターゲット読者と禁止パターンだけ書く
クラウドルーチンに「ブリーフを 1 件取って MDX を書いて push する」手順を書いてテスト実行する

インフラを全部揃えてから動かすのではなく、最小構成で通してから崩れたところにゲートを足す順番が現実的です。

AI ツールを業務に組み込む設計の実験ログを書いています。 https://masatoman.net