TL;DR
- 量産で失敗する原因は、Claude Codeの性能不足ではなく、企画と執筆とレビューを同じ箱に押し込むことです。
- 1本ずつ書くより、3本単位で「テーマ固定 -> 設計 -> 執筆 -> 検証」を回した方が、手戻りが減ります。
- 量産のコツは、書かせることではなく、勝ち筋のある入力と確認手順を先に決めることです。
はじめに
Claude Codeを使えば、記事の初稿はかなり速く作れます。 でも、速いだけだとすぐに破綻します。見出しが毎回ぶれたり、読者が違うのに同じ結論に落ちたり、レビュー時に「結局どこを読めばいいのか」が曖昧になりやすいからです。
この記事では、Claude Codeでブログを量産する ときに必要な実務フローを整理します。単なるプロンプト集ではなく、企画 -> 執筆 -> 検証 を分けて回す方法に絞ります。
この話は、既存の Claude Codeで「高品質」なブログを量産する自動化パイプラインの作り方 と重なる部分があります。けれど、ここではさらに一歩進めて、量産の途中で壊れやすい箇所を実務目線で分解します。あわせて AI記事制作で「品質を落とさない」新・編集フローの設計と必須レビュー体制 や エージェント駆動開発（SDD/Batch）の実践ガイド：承認ゲート付きワークフローの使い方 の考え方も踏まえると、流れがかなり見えやすくなります。
1. Claude Codeの量産が止まる理由
1-1. 同じ依頼文を使い回すと、記事が均質化する
Claude Codeは優秀です。だからこそ、毎回「いい感じに書いて」で済ませると、出力も毎回「いい感じに無難」になります。 その結果、以下のような症状が出ます。
- タイトルだけ違って中身が似る
- 見出しの粒度がそろわない
- 読者の課題が浅くなる
- 最後のCTAだけが場当たり的になる
量産の敵は速度ではなく、再利用するたびに質が薄まることです。
1-2. 企画の詰めが甘いと、レビューが全部やり直しになる
レビューで直すべきなのは、表現の微修正です。ところが、企画段階で読者像や検索意図が曖昧だと、レビュー時に直すのは構成そのものになります。 これはコストが重いです。
なので、先に決めるべきは次の4つです。
- 誰向けの記事か
- 何を解決する記事か
- どの切り口で勝つか
- 何をもって完成とするか
この4点が固まると、Claude Codeには「文章生成」ではなく「設計通りの実装」をやらせやすくなります。
2. 3本単位で回すと、量産が安定する
2-1. 1本ずつではなく、3本で見出しの役割を分ける
3本単位にすると、役割が自然に分かれます。
- 1本目: 入口の悩みを言語化する
- 2本目: 品質やレビューの型を深掘りする
- 3本目: CVや導線の設計に落とす
この分け方にすると、同じテーマでも角度が変わるので、記事同士の重複が起きにくくなります。
たとえば今回のキューでも、AI記事制作で品質を落とさない設計 と SNS流入でCVを取る記事設計 を並べると、前者は制作プロセス、後者は成果導線に寄せられます。そこに本記事のような量産フローを置くと、1本ごとの責務がはっきりします。
2-2. 作業を3段階に分ける
実務では、次の順に進めるのが安定です。
- キーワード候補を1つに絞る
- 読者の課題と検索意図を1文で固定する
- 見出しだけ先に作る
- 本文を生成する
- 内部リンクとCTAを後付けしないで、最初から埋める
ここで大事なのは、本文生成より先に「見出しの役割」を決めることです。役割が決まっていれば、Claude Codeはかなり素直に動きます。
2-3. 検証は文章の良し悪しではなく、再現性を見る
量産フローの検証で見るべきなのは、感想ではありません。
- 何分で初稿が出るか
- 修正が何回必要か
- どの見出しで詰まるか
- どのテーマでリンク設計が崩れるか
つまり、記事を「作品」ではなく「工程の出力」として扱います。ここを切り替えると、改善の回し方が変わります。
pnpm gen
pnpm run eval:articles
pnpm test
この3本を毎回通すだけでも、量産の壊れ方はかなり見えます。
3. そのまま使える量産テンプレ
3-1. 入力は少なく、制約は明確にする
Claude Codeに与える入力は、増やしすぎない方がいいです。
- キーワード候補
- 読者像
- 記事の勝ち筋
- 参考にする既存記事
- 完成条件
逆に、毎回変えるべきでないものもあります。
- 文体
- 見出しの粒度
- まとめの書き方
- 内部リンクの置き方
この固定と可変の分離が、量産の土台です。
3-2. 量産時の確認項目
- タイトルは検索意図に合っているか
- TL;DR で結論が先に出ているか
- H2 が3つ以上あるか
- 兄弟記事や関連記事へのリンクがあるか
- まとめが次の行動を示しているか
このチェックは、同じことを二度と言わないための「スキル定義ファイル」 の考え方とも相性がいいです。毎回の指示を文章で増やすのではなく、再利用できるルールに寄せるのがポイントです。
3-3. 運用ルールのサンプル
1. 企画で勝ち筋を1行にする
2. 見出しを先に確定する
3. 本文生成後は、事実・導線・重複だけを確認する
4. 直しが多い記事は次回の候補から外す
5. 3本終わったら、共通の失敗をメモに残す
このくらいの粒度で十分です。大事なのは、毎回同じ判断をしなくて済むようにすることです。
まとめ
Claude Codeでブログを量産するなら、速さより先に工程を整えた方がうまくいきます。
- 企画と執筆とレビューを分ける
- 3本単位で役割を分ける
- 検証は感想ではなく再現性で見る
まずは1本を速く作るより、3本を同じ基準で作れるかを見てください。そこが安定すると、量産は一気にラクになります。
次に読むなら、AI記事制作で品質を落とさない設計 か SNS流入でCVを取る記事設計 がつながりやすいです。量産の先にある「品質」と「成果」を同時に見たいときに役立ちます。
2026-05 仕様への更新（Subagents / Skills / PlanGate）
2026 年中頃の Claude Code は Hooks / Subagents / Skills の 3 拡張レイヤーを標準提供[公式値]（Claude Code 公式 docs）。本記事の「3 本単位で回す量産フロー」を Subagents で並列化するのが現実解（経験則）。
並列実行時の git 競合と worktree 隔離
複数 conductor を 同一 git ワークスペースで並列起動すると、PR 作成時にブランチ衝突・stash 飛び交いが発生します（経験則）。回避策は .claude/worktrees/<slug>/ 配下に git worktree add で隔離 + 並列度 3-4 まで制限。詳細は AGENT_LEARNINGS の feedback_parallel_exec_git_conflict を参照。
2026-05 標準フロー（経験則）
- 企画:
performance-analystで既存記事の隙間抽出 → queue.csv に投入 - 設計: brief.md を Subagent で並列生成（3-4 並列上限）
- 執筆:
article-conductoragent が D-1〜D-12 を自律実行（worktree 隔離必須） - レビュー:
/article-4p-review（4視点並列）+codex-rescue（独立レビュー） - PR 作成:
gh pr create→ 明示 merge 指示で merge → post-merge-followup - 承認境界: PlanGate v8.6 Hook Enforcement で deterministic な承認ゲート
2026-05-07 セッション実証
本ブログでは 1 セッションで 新規 9 + リライト 18 = 27 記事 + 関連 PR 計 40+ を完走（経験則）。確立したパターン:
- WebSearch fact injection で 27 記事すべて 2026-05 公式値 verified
- gh auth switch を毎 PR 操作直前に実行
- リライトは新規の 50-70% 工数で高品質帯到達
article-fact-injection/official-claim-auditorskill のドッグフーディング成功
詳細な Skill / Subagent 使い分けは Skills対Subagents使い分け5軸、CLAUDE.md / AGENTS.md / Skill / Subagent / Hook の役割分担表は CLAUDE.md 最適化 を参照。
FAQ
Q1. 並列実行で git 衝突を完全に避ける方法は？
worktree 隔離が現実解（経験則）。.claude/worktrees/<slug>/ に git worktree add で各 conductor を独立した作業ディレクトリに固定。並列度は 3-4 まで（subagent rate limit）が経験的閾値。詳細は AGENT_LEARNINGS の feedback_parallel_exec_git_conflict。
Q2. リライトと新規制作で工数はどう変わりますか？
リライトは新規の 50-70% 工数（経験則）。本記事の量産フローでは、新規 1 本 = 1.5-2h、リライト 1 本 = 1-1.5h が現実的目安。リライトは公式値ラベル拡充 + FAQ + JSON-LD 追加 + 関連記事接続が主体で、ゼロから書かない分速い。
Q3. PlanGate v8.6 はどう量産パイプラインに組み込みますか？
承認ゲートを Hook で deterministic 化（PlanGate v8.6 Hook Enforcement 参照）。承認なし merge をブロックするだけでなく、AI 出力の特定パターン（公式値ラベル誤用 / status:draft 残置 / 内部リンク不在）を PreToolUse hook で防げます。
Q4. 27 記事 1 セッションは品質を保てますか？
保てます（経験則）。本ブログの 2026-05-07 セッションでは Score 500/Grade S を 19/19 達成、Codex independent review verdict も REVISE→修正反映で公開可能水準を維持。テンプレ化 + Skill 化 + 4P レビューゲートが効きます。
Q5. claude-code-blog-factory との使い分けは？
本記事 = 量産の運用フロー、claude-code-blog-factory = エージェント統制の総合パイプラインです（経験則）。本記事を読んでから factory に進むと、運用の全体像が立体的に見えます。
References
- Claude Code 公式 docs — 3 拡張レイヤー
- Claude Code Subagents 公式 — 並列タスク
- Claude Code Hooks 公式 — deterministic 制御
- Claude Code Skills 公式 — 再利用ワークフロー
関連記事
- Claude Codeで「高品質」なブログを量産する自動化パイプラインの作り方
- AI記事制作で「品質を落とさない」新・編集フローの設計と必須レビュー体制
- AI記事制作で品質を落とさない設計
- AI編集：体系的な構成と品質管理
- AIエージェント開発の「新常識」SDD：チャット指示をやめて仕様書を書こう
- エージェント駆動開発（SDD/Batch）の実践ガイド：承認ゲート付きワークフローの使い方
- Skills対Subagents使い分け5軸
- Claude Code hooks の実践パターン集
- PlanGate v8.6 Hook Enforcement
- 古い技術記事を AI 検索時代に合わせて更新する運用
