Claude Code で週次コンテンツブリーフを全自動化した — CLAUDE.md・Supabase・Slack MCP連携の実装記録

この記事は、コンテンツ企画から記事公開までを Claude Code の routine で自動化したシステムの実装ログです。そして、この記事自体がそのシステムによって書かれています——content-executor routine が 2026-06-18 02:00 JST に起動し、Supabase から本日分のブリーフ（#19）を取得して執筆しています。

きれいに成功した話ではありません。Supabase MCP の権限エラーで止まり、SQL スキーマのミスで executor がクラッシュし、1 週間かけてデバッグした実録です。

結論

Claude Code で「コンテンツを任せる設計」を組む場合、効いたのは次の 3 層でした。

1. weekly-content-planner routine — GSC・GA4 データから記事候補を分析し、content_briefs テーブルに priority 順でブリーフを INSERT する
2. Supabase MCP + content_briefs テーブル — ブリーフのキュー管理（status: planned → in_progress → published）
3. content-executor routine — 毎日 02:00 JST に起動し、priority=1 のブリーフを取り出して記事を執筆・commit・push する

この 3 層を CLAUDE.md で記述しておくことで、Claude Code は「次に何を書くべきか」を毎回人間に聞かずに判断できます。

この記事の前提（自分の状況・スタック・実験条件）

• 運用期間: 2026-06-07 コンセプトピボット後に実装開始、現在計測中
• スタック: Next.js + Supabase（Postgres）+ Claude Code + Slack MCP
• 実行環境: Claude Code on the Web（remote execution、火〜土 02:00 JST に scheduled routine で自動起動）
• GSC データ: claude code 関連クエリで 35 impressions（2026-06 計測）。需要確認の根拠として使用
• コスト前提: Claude Code Max サブスク（月定額）内で運用。API 従量課金なし

読者のよくある詰まり（「それ俺だ」を作る）

Claude Code を使って記事を書こうとすると、たいてい次のどこかで止まります。

1. 「今日何を書く？」が毎回の意思決定コスト — AI にプロンプトを書く前に、テーマ選びで力尽きる
2. 連続性がない — 昨日書いたこと・GSC で伸びているキーワード・読者の反応を AI が知らない
3. 「ネタがある → 書く」がクリエイター罠 — 在庫があるから書く、は quality を落とす
4. 1 回書いたら終わり — 既存記事のリライトや SEO 改善が積み残しになる

どれも「AI が賢くない」問題ではなく、「何を書くかの設計」が欠けている問題です。ブリーフキュー + executor routine で、これを構造で解決しました。

実際に組んだ設計

① weekly-content-planner routine

週次で起動する routine です。やることは 3 つ。

• Search Console / GA4 の最新 CSV を読み込み、伸びているクエリ・ランク B-C 記事を特定する
• 既存 content_briefs の planned 件数を確認し、4 件を下回ったら新規ブリーフを補充する
• 各ブリーフに priority・brief_type（new / rewrite）・source_type・rationale・data_evidence を付けて Supabase に INSERT する

-- weekly-content-planner が生成するブリーフの例
INSERT INTO content_briefs (
  brief_type, priority, title_proposal, slug_target,
  rationale, data_evidence, source_type, status
) VALUES (
  'new', 4,
  'Claude Code で週次コンテンツブリーフを全自動化した',
  'claude-code-weekly-content-planner-routine-2026',
  '新コンセプトの最典型記事。このroutine自体を題材に実装ログを書ける。GSCでclaude code系35表示あり。',
  '{"gsc_claude_code_related_queries": 35}',
  'conversion_funnel', 'planned'
);

ポイントは rationale と data_evidence に根拠を必ず書くことです。executor が記事を書くとき、この 2 フィールドが「なぜこの記事を書くか」の一次情報になります。根拠のないブリーフは executor に拾わせない設計にしました。

② content_briefs テーブル（Supabase）

ブリーフのキューとして機能します。カラム構成は次のとおりです。

CREATE TABLE content_briefs (
  id           SERIAL PRIMARY KEY,
  brief_type   TEXT NOT NULL,         -- 'new' | 'rewrite'
  priority     INTEGER NOT NULL,       -- 低い数字が高優先度
  title_proposal TEXT,
  slug_target  TEXT,
  rationale    TEXT,
  data_evidence JSONB,
  source_type  TEXT,
  status       TEXT DEFAULT 'planned', -- planned | in_progress | published
  created_at   TIMESTAMPTZ DEFAULT NOW(),
  updated_at   TIMESTAMPTZ DEFAULT NOW()
);

executor は毎日 status = 'planned' ORDER BY priority ASC LIMIT 1 で 1 件だけ取り出します。1 日 1 本の制約は CLAUDE.md に書いてあり、executor は違反できません。

③ content-executor routine（CLAUDE.md 設計）

本体の設計を CLAUDE.md に書くことで、Claude Code はこの routine を毎回自律実行できます。

## content-executor
- 実行タイミング: 火-土 02:00 JST
- Step 1: content_briefs から planned を 1 件取得
- Step 2: status を in_progress に更新
- Step 3: brief に従って MDX 記事を執筆（1500-3000字）
- Step 4: 誇張 grep + lint-article-claims で品質チェック
- Step 5: git commit & push
- Step 6: Slack #dev-crew-logs に完了通知
- 禁止: 1日2本以上書かない / rationale を無視して書かない / 数字を捏造しない

CLAUDE.md にルールを書くことで、executor は「ついでにもう1本」「rationale を無視して書きたいテーマに変える」ができなくなります。

実際に起きた失敗（数字・エラー・判断）

失敗 1: Supabase MCP の project_id を間違えた

最初の executor 実行で、Supabase MCP ツールに渡す project_id を本番とステージングで混在させてしまいました。ブリーフが本番テーブルに入り、executor はステージングテーブルを読んで「0 件」と判定して停止。Slack にも「ブリーフなし」通知が飛んで、翌日まで原因に気づきませんでした。

対処: CLAUDE.md に project_id: amtwwscvhwkfdrqimgqm (KOBO本番) と環境名を明記。コメントアウトでなく「これを使え」と直接書く。

失敗 2: lint-article-claims スクリプトが存在しない記事で止まる

executor の Step 4 で node scripts/lint-article-claims.mjs を実行するように設計していましたが、スクリプトが missing のときに executor がそのまま止まりました。git push まで進まず、Slack 通知もなく、朝起きたら「何もなかった」状態。

対処: executor の CLAUDE.md に「スクリプトが存在しない場合は skip して続行する」を明記。エラーをキャッチして push まで完走させる。

失敗 3: ExperienceBox の中に捏造数値を入れそうになった

executor（Claude Code）が ExperienceBox に「登録者数 200 人」「月間 PV 12,000」のような数字を生成しようとしました。これは dev_journal に存在しない数字で、誇張 grep に引っかかります。

対処: CLAUDE.md に 体験捏造禁止: dev_journal 由来でない数字・実体験は使わない を追記。実測値がない場合は「計測中」と書く。

判断基準（読者が当てはめられる形）

ブリーフキューを組む価値があるのは次の場合です:

• 記事を月 4 本以上継続して出したい（それ以下ならアドホック執筆で十分）
• 「今日何を書く？」の意思決定が記事執筆の最大ボトルネックになっている
• GSC / GA4 のデータを判断に使いたいが、毎回 CSV を見るのが面倒
• リライト候補（ランク B-C 記事）が常に 10 件以上積み残されている

逆に、アドホック執筆を続けるべき場合:

• 記事テーマが実体験に依存しており、週次で計画できない
• まだ GSC / GA4 のデータが少なく（週 10 セッション未満）、データドリブンな判断ができない

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

1. Supabase に content_briefs テーブルを作る（上の DDL をそのままコピー）
2. 1 本分の記事ブリーフを手動で INSERT し、executor が読み取れるか確認する
3. CLAUDE.md に executor の制約（1日1本・捏造禁止・エラー時の挙動）を 5 行書く

全部いっぺんに動かそうとしない。まず「ブリーフ 1 件 → 記事 1 本」が手動で再現できてから、自動化する。

で、どう稼ぐ？

コンテンツブリーフを自動化しても、それ自体は収益を生みません。稼ぎに繋がる設計は次の 2 つです。

1. 記事を継続的に出し続けることで GSC の impressions が蓄積し、検索流入が安定する（今の 35 impressions → 350+ を目指して計測中）
2. 実装ログを公開することで「設計の当事者性」が生まれ、有料テンプレ・ニュースレターへの信頼導線ができる

現時点では「稼いでいる」は言えません。「稼げる設計を組んで、計測しながら改善している」が正直なステータスです。

---

---