Claude Code で速報記事を自動生成 — Generator-Verifier で煽りを防ぐ

朝起きたら、AI 業界の速報記事が masatoman.net に公開されていてほしい。手動で書くと数時間かかる。LLM に任せると煽り記事が量産される。この間で詰んでいた。

結論: Anthropic Multi-agent パターンの「Generator-Verifier」を採用して、Claude Code Skill の night-writer に「速報モード Phase 3-0」を組み込んだ。AI 業界の急上昇 OSS / 公式発表 / バイラル投稿を検出して、Claude Code が実環境で動作確認してから記事化する仕組みだ。

この記事では、なぜ LLM 単独で速報記事を量産すると失敗するのか、Generator-Verifier パターンで何が変わるのか、night-writer Phase 3-0 の実装内容と動作確認結果まで全部書いた。

この記事でわかること:

• なぜ AI 業界で「翌朝速報」が個人開発者に効くのか
• LLM に速報を書かせるとなぜ煽り記事になるのか
• Anthropic Multi-agent パターン「Generator-Verifier」の本質
• night-writer Phase 3-0 のアーキテクチャ（trend_collector + Phase 3-0 判定 + 実環境検証）
• 90 日ルールに緩和した実データ検証（GitHub Trending の現実）
• 誇張禁止語 grep + 5 章テンプレ構造で煽りをカットする方法

---

なぜ AI 業界で「翌朝速報」が効くのか

2026-04-17、HeyGen が Hyperframes をオープンソース化して、24 時間で GitHub ⭐ 10,000 を超えた。HTML を書くと動画になるという、AI エージェント向けの動画生成フレームワークだ。

X では「これはマジかよ」というポストで埋まった。インフルエンサーが note の有料記事を 2 日後に出して、3 日後にはもう「Hyperframes」というキーワードでの SEO 上位は埋まった。

個人開発者として悔しいのは、情報自体は GitHub Trending と X 公式アカウントを見ていれば即気づける点だ。気づいた翌朝には、リポジトリを clone して動かして、自分の所感を含めた解説記事を出せれば、SEO で先取りできる。

ただ問題は、これを毎週やる労力だ。手動で書くと 1 本 4-6 時間。週 2 本でも週末が消える。

自動化したい。LLM に任せたい。でも LLM に速報を書かせると、別の問題が出る。

---

LLM に速報を書かせるとなぜ煽り記事になるのか

試しに Claude に「Hyperframes について速報記事を書いて」と頼んでみる。出てくるのは、こういう文体だ:

2026 年 4 月 16 日、動画編集の世界で、静かに、でも確実に、地殻変動が起きました。これを知らないまま半年過ごすと、あなたのコンテンツは「動きのある発信者」にどんどん置いていかれます。

「地殻変動」「ゲームチェンジ」「半年遅れたら置いていかれる」「祭り状態」。インフルエンサー定型句が並ぶ。LLM の学習データに、こういう文体の記事が大量にあるからだ。

これは masatoman.net では使えない。理由は 3 つ:

1. 誇張禁止ルール（memory feedback_no_exaggeration.md）— 未達成のベネフィットを訴求に使わない方針
2. 読者層と合わない — 本業エンジニア向けには「何が動いて、何が動かないか」の事実が欲しい
3. 数字捏造リスク — LLM は「外注で 5〜10 万円かかっていた」のような相場感数字を平気で生成する

つまり LLM 単独では速報記事の質が担保できない。じゃあどうすればいいか。

---

解決策: Anthropic Multi-agent パターン「Generator-Verifier」

Anthropic Engineering Blog の Multi-agent coordination patterns 記事に、この問題への明確な答えがある。Generator-Verifier パターンだ。

仕組みはシンプルだ。1 つの agent が出力（Generator）し、別の agent が実環境で検証する（Verifier）。Verifier が失敗を返せば、Generator は再生成する。これを上限回数（通常 2-3 回）まで繰り返す。

速報記事に置き換えると:

• Generator: 候補のセットアップコマンドを抽出して、一時ディレクトリで実行する agent
• Verifier: 実行ログを見て「実際に動いたか / どこで詰まったか」を確認する agent
• 失敗 → 速報化キャンセル → 通常記事フローへフォールバック
• 成功 → 実行ログを記事の第 2 章にそのまま組み込む

ここで重要なのは、「動いたかどうか」が記事化のゲートになっている点だ。LLM が「これは凄い」と書く前に、実環境で動かす。動かないなら速報にしない。

これで煽りが消える。記事の主役が「実際に動かしたログ」になるからだ。「2 分でセットアップできた」「初回 build で 3 エラー出た」「最終的に MP4 が出力された」みたいな、自分の手で確認した事実だけで記事が組み立つ。

---

night-writer Phase 3-0 のアーキテクチャ

masatoman.net の記事自動化は、Claude Code Skill の night-writer が担当している（毎晩 02:00 JST 実行）。これに Phase 3-0 速報モード判定 を新設した。

全体の流れ:

sns-automation/trend_collector.ts (毎日 GitHub Actions で実行)
  ├─ ProductHunt RSS
  ├─ GitHub Trending RSS
  ├─ X API (claudeai, AnthropicAI のタイムライン + JP Claude 検索)
  └─ Anthropic Blog (sitemap)
       ↓
  Supabase trend_items テーブル (5 ソース集約)
       ↓
night-writer (Claude Code routine, 毎晩 02:00 JST)
  ├─ Phase 3-0: 速報モード判定 (新設)  ← この記事の本題
  └─ Phase 3:   通常記事生成 (既存)

trend_collector.ts 自体は前から動いていた。問題は「集めたデータが night-writer に流れていない」ことだった。Phase 3-0 を挟んで、ここを繋いだ。

発火条件（Tier S/A/B）

直近 24 時間に追加された trend_items から、以下の優先度で候補を選ぶ:

• Tier S: source = 'anthropic_blog' の新着 — Claude/Anthropic 公式新機能が最優先
• Tier A: claude_x_en で votes >= 5000 AND published_at > 48h前 — X 公式アカウントのバイラル
• Tier A: github_trending で stargazers_count >= 5000 AND (created_at > 90日前 OR pushed_at > 7日前 + リリース語句) — Hyperframes 級の急上昇 OSS
• Tier B: producthunt_rss で AI/開発者ツール関連キーワード — PH 上位入り

複数候補が出ても 最高優先度の 1 件のみ を速報化する。1 日 1 本厳守。残りは翌日の trend_items に残るので翌日判定。

90 日ルールへの緩和（実データ検証）

最初は「created_at > 30日前 の新作 OSS のみ」というルールにした。これが現実に合わなかった。

GitHub Trending の RSS（mshibanami.github.io/GitHubTrendingRSS/weekly/all.xml）は 既存の人気リポが定期的に再浮上する 仕組みになっている。つまり 30 日以内に作られた新作 OSS だけを拾うと、候補がほぼゼロになる。

実データで確認した結果が下のテーブルだ:

2026-04-26 のトレンド候補 14 件 (github_trending) を GitHub API で補完した結果:

repo                                       stars      age    Tier
forrestchang/andrej-karpathy-skills        89,469    89 d   ✅ A
Alishahryar1/free-claude-code              12,460    87 d   ✅ A
multica-ai/multica                         21,291   102 d   ❌ (90日超)
openai/openai-agents-python                25,258   411 d   ❌ (古い)
deepseek-ai/DeepGEMM                        7,061   437 d   ❌ (古い)
...

30 日ルールだと 0 件。90 日 + pushed_at 7 日 + リリース語句に緩和して、ようやく 2 件取れた。

「真の新作」だけを狙うのは GitHub Trending の構造上難しいので、「比較的新しい + 最近メジャー更新がある」を許容する設計にした。

5 章テンプレ構造（誇張排除）

速報記事の本文構造は固定する:

# {タイトル: 事実 + 一行解釈}

## 第 1 章 何が起きたか — 事実だけ
（いつ / 誰が / 何を出したか、⭐ 数や votes 数は trend_items から実値のみ）

## 第 2 章 触ってみた — 実環境ログ
（実際に走らせたコマンド、出たエラー、所要時間（実測秒数）、出力の実物）

## 第 3 章 個人開発者目線で何が変わるか
（いままで何が必要だった → これで何が要らなくなる、ROI 試算）

## 第 4 章 試したい人向けセットアップ
（自分のログをそのまま手順化、前提環境、詰まった点）

## 第 5 章 で、どう稼ぐ？
（masatoman.net 既存記事との関連、Lab Free 登録 CTA）

第 2 章に実コマンド + 実ログを入れることが、煽り防止の最強の武器になる。LLM が "革命" と書く余地がない。

誇張禁止語 grep（push 前必須）

それでも LLM は時々煽りを混ぜてくる。最後の防御線として、push 前に grep でチェックする:

grep -E "(業界が変わる|ゲームチェンジ|革命|今が一番早い|置いていかれる|祭り状態|神アップデート)" \
  content/articles/breaking-*.mdx
# ヒットしたら commit せず修正

これは memory feedback_night_writer_fabrication.md で過去 5 記事で発見した偽装数字問題への対応の延長線上にある。

---

動作確認: 89,469 ⭐ のリポジトリが Tier-A 候補に取れた

仕組みを実装した直後、当日のデータで動作確認した。2026-04-26 の Phase 3-0 SQL クエリを実行:

スケジュールも調整した。trend_collector は既存で JST 12:00 に走っていたが、night-writer (02:00 JST) には前日の 14 時間前のデータしか届かない。鮮度を上げるため、night-writer 直前 1 時間（JST 01:00 = UTC 16:00 前日）にも cron を追加した:

# sns-automation/.github/workflows/trend-collector.yml
on:
  schedule:
    # JST 01:00 (UTC 16:00 前日) - night-writer 直前、速報モード Phase 3-0 用
    - cron: "0 16 * * *"
    # JST 12:00 (UTC 03:00) - 既存（Researcher 実行用）
    - cron: "0 3 * * *"

これで明日 02:00 JST の night-writer は、1 時間前に集めたばかりのトレンドデータを使って判定できる。

---

ハマったポイント（実体験）

1. trend_items テーブルが正本ではない Supabase プロジェクトに

memory には「trend_items は project amtwwscvhwkfdrqimgqm」と書かれていた。これを信じて該当プロジェクトの table list を確認したら、そんなテーブルはなかった。

慌てて作成した後で、別の memory（.claude/rules/sns-automation.md）を読んだら「正本は dnamzzarzmnkeqlaehch」と書いてあった。後者のプロジェクトに既に 431 行ある trend_items が存在していた。最初に作ってしまったテーブルは drop した。

教訓: memory は書かれた時点のスナップショット。複数プロジェクトを扱うときは、複数の memory ファイルを横断的に確認しないと、間違ったプロジェクトに migration を適用しかねない（memory feedback_verify_before_acting_on_memory.md の実例が増えた）。

2. scheduled-tasks ディレクトリが git 管理外だった

scheduled-tasks/night-writer/SKILL.md と scheduled-tasks/_shared/breaking-news-mode.md を更新したが、git status で確認したら not a git repository だった。

ローカルファイルとしてしか保存できない。Claude Code routine の設定としては問題ないが、バックアップは別途必要。今回は memory として project_breaking_news_mode_implemented.md に主要な仕様を記録して対応した。

3. 並行セッションの未コミット変更

sns-automation には他の Claude Code セッションの未コミット変更が 7 ファイル分残っていた。git add .github/workflows/trend-collector.yml で個別ファイルだけを stage して push した。memory feedback_git_add_parallel_sessions.md の通り、git add -A は事故の元。

---

で、どう稼ぐ？ — 速報記事は L1 集客の最強チャネルになる

masatoman.net の SEO 戦略は「ロングテール KW を 100 本積む」が基本だ。「Cursor 料金 個人 2026」のような複合 KW を狙って、月 30,000 PV を目指す。

ただ、ロングテール記事は伸びるまで 3-6 ヶ月かかる。Google の評価が固まるまでの時間だ。速報記事はこの待ち時間をスキップできる。「Hyperframes 触ってみた」が公開 24 時間以内に書かれていれば、検索結果上位に瞬時に乗る。

ロングテール記事と速報記事は補完関係にある:

• ロングテール記事: 安定した月次流入、決済率高い、L1→L2→有料記事への導線がしっかり
• 速報記事: 単発の急増流入、決済率は低いが著者ブランド構築に効く、関連有料記事への trickle-down 効果

速報記事を毎週 1-2 本出すと、masatoman.net のドメイン評価が「AI 系の最新動向にコミットしているメディア」として固まる。これがロングテール記事の評価底上げに効く。

そしてもう 1 つ、速報記事は自分の引き出しを増やす効果が大きい。Generator-Verifier で実環境セットアップを必須にしているので、毎週新しい技術を 1-2 個触る習慣ができる。これが個人開発の引き出しになる。今回の Hyperframes も、知らなかったら recipe-ai の動画化パイプラインを思いつかなかった。

「で、どう稼ぐ？」の答えは、直接の決済より、引き出しを増やして次のプロダクトに繋げることだ。

---

まとめ

• AI 業界の翌朝速報は個人開発の SEO 先取りに効くが、LLM 単独で書かせると煽り記事が量産される
• 解決は Anthropic Multi-agent パターン「Generator-Verifier」— 別 agent が実環境で検証するゲートを挟む
• night-writer Phase 3-0 として実装、データソースは trend_collector（ProductHunt + GitHub Trending + X 公式 + Anthropic Blog）
• Tier S/A/B の発火条件、GitHub Trending は 90 日ルール（30 日では候補ゼロ）に緩和
• 5 章テンプレ構造（事実 / 触ってみた / 何が変わる / セットアップ / で、どう稼ぐ？）で煽りを排除
• 誇張禁止語 grep で push 前に最終チェック
• 動作確認 1 日目で Karpathy Claude Code Skills（⭐ 89,469）が Tier-A 候補として取れた

「LLM に何でも書かせる」のではなく、「LLM に書かせていいゲートを設計する」。これが個人開発で agent を本番運用するときの 1 つの実践だ。