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