Claude Code でブログ記事を一括生成する意味
ブログ記事を月に何十本と出す現場で、手が止まる場所はいつも同じです。ネタは決まっている。1本ずつ書けば書ける。ところが並列に3本、5本と走らせようとした瞬間に、指示の出し直し、ファイル名の付け直し、トーンの揺れ、CMS への反映漏れが積み重なります。
Claude Code は、この段取りの部分を担うために設計されています。ファイルの読み書き、シェルの実行、外部ツールへの接続、複数の作業を並列で回すためのサブエージェント、事前と事後の自動検査。ブログ記事の生成そのものは Claude が担い、量産のための骨組みだけを Claude Code が引き受ける構図になります。
一括生成の対象は、pSEO 記事、製品リリースの周知記事、社内のナレッジ記事、SNS の元原稿、いずれでも構いません。共通するのは「型がある」「本数がまとまる」「後段の反映まで必要」の3点です。この3点が揃うと、Claude Code の設計と噛み合います。
事前準備｜ネタ表・型・出力先の3点
一括生成を回す前に、材料を3つ用意します。順番はこの通りです。
一つめはネタ表です。CSV か Markdown で構いません。1行に1記事、必要な列は「タイトル案」「主対象キーワード」「想定読者」「参照する一次情報の URL」「文字数目安」「公開先」の6つに絞ります。これ以上増やすと、Claude 側の判断がぶれます。
二つめは型です。書き出し、h2 の並び、締めの型、避けたい言い回し。この4つを .claude/skills/blog-writing/SKILL.md に書き出します。CLAUDE.md にまとめて置くのではなく Skill として切り出す理由は、公式ドキュメントの説明にある通り「Skill の本文は使うときにだけ読み込まれる」ため、参照資料が長くても普段のセッションが重くならないからです。
三つめは出力先の設計です。案件フォルダ直下に posts/、その中に slug ごとのサブフォルダ、原稿・下書き・確認済みの3段階のファイルを置く形が回しやすいです。命名規則も先に決めておきます。
Skills でブログの型を Claude Code に覚えさせる
Skill は、繰り返し使う手順を Claude が呼び出せる形に束ねる仕組みです。フォルダ一つに SKILL.md を置き、そこに手順を書きます。.claude/skills/blog-writing/ に置くと、Claude はそのフォルダを認識し、必要な場面で自分で呼び出します。/blog-writing と打って明示的に呼び出すことも可能です。
ブログの一括生成で有効な Skill の切り方は、次の4つに分けることです。
一つは記事本体の Skill（blog-writing）。書き出しの3文の型、h2 の並び、締めの段落、内部リンクの入れ方をまとめます。二つは校正の Skill（blog-copyedit）。表記揺れ、禁止語、一文の長さ、句読点の使い方の規約をまとめます。三つは SEO の Skill（blog-seo）。title の作り方、description の字数、hub-spoke 内部リンクの設計をまとめます。四つは CMS 書き出しの Skill（blog-publish）。CMS 側のフィールドと本文の対応、公開日と canonical の埋め方をまとめます。
一つの大きな Skill にまとめないのが要点です。Claude は必要な Skill を場面ごとに読み込むため、目的別に切っておくと、下書きの段階では blog-writing だけが読み込まれ、書き出しの段階では blog-publish だけが読み込まれます。1セッションのコンテキスト使用が節約でき、指示の反映精度が上がります。
サブエージェントで複数記事を並列に走らせる
サブエージェントは、Claude Code の中に独立したコンテキストを持った作業単位を作る仕組みです。公式ドキュメントの定義では「特定の種類のタスクを扱う、独立したコンテキストを持つ Claude Code の専門アシスタント」とされています。定義は .claude/agents/ に Markdown ファイルとして置き、YAML frontmatter に name・description・tools・model・preload する skills などを書きます。
ブログ記事の一括生成では、この構造がそのまま量産の骨格になります。1記事＝1サブエージェントを立ち上げ、複数記事を同時に走らせる。メインのセッションはネタ表を配って回し、各サブエージェントは自分の担当記事だけを最後まで書きます。書き終えたら、要約と成果物のパスをメインに返して終了します。
サブエージェントは背景実行に対応しており、公式の記述では「フォークモードが有効な場合、サブエージェントは既定で背景で動く」とされています。背景で走らせておけば、こちらは別の記事の校正や、次のネタ表の準備に手を動かせます。書き終わったサブエージェントから順に、確認して差し戻すか、次の工程に渡すかを決める運用になります。
なお背景実行では、書き込み系ツールを含む一部のツールが使える一方、権限確認を要求する UI 系のツールは使えません。ブログ本文の作成と保存には支障がないため、実務ではそのまま使えます。
Hooks で書き出し前後の検査を自動化
Hooks は、Claude Code の動作の特定のタイミングで、シェルコマンド・HTTP リクエスト・別の Claude 呼び出しを差し込む仕組みです。公式ドキュメントの説明では「Claude Code のライフサイクルの特定の時点で自動的に実行される、利用者が定義したシェルコマンド・HTTP エンドポイント・LLM プロンプト」とされています。
ブログの一括生成では、次の3つの Hook が特に効きます。
PreToolUse は、Claude が Write や Edit を叩く直前に走ります。ここで、書き出そうとしているファイル名が命名規則に沿っているか、対象フォルダが posts/ 配下か、既存の記事を上書きしていないか、といった検査をシェルスクリプトで通します。規則違反があれば、hookSpecificOutput の permissionDecision を deny にして書き出しを止めます。
PostToolUse は、書き出しが済んだ直後に走ります。ここで、文字数のカウント、禁止語の grep、h2 の数、内部リンクの本数、meta 情報の有無を検査します。fail した項目はログに残し、次のセッションでの直しの起点にします。
Stop は、Claude が返答を返して1ターンを閉じる直前に走ります。1本の記事の生成が終わったタイミングで、記事一覧の JSON を更新する、Slack に完了通知を投げる、といった後片付けを差し込みます。
Hook の設定ファイルは、プロジェクト単位なら .claude/settings.json、個人設定なら ~/.claude/settings.json に書きます。チーム全体で回す場合は、前者を Git 管理に入れ、hooks/ ディレクトリごと共有します。
MCP で CMS と一次情報と素材フォルダをつなぐ
Model Context Protocol（MCP）は、AI ツールと外部のツールを接続するための、Anthropic 主導の共通規格です。Claude Code は MCP クライアントとして動くため、対応するサーバーを登録するだけで、外部ツールに直接手が伸びます。
ブログの一括生成で、実務で最初に入れておきたい接続は3つです。
一つは Google Drive や Notion の接続です。企画書、既存記事、社内のスタイルガイド、公式素材。これらを Drive や Notion に置いておき、Claude Code から直接読み込みます。人が下書きに貼り直す手間がなくなります。
二つは CMS の接続です。WordPress、Ghost、Notion（公開機能を使う場合）、GitHub 上の静的サイト。いずれも MCP サーバーが揃っています。書き上がった記事を Claude Code から直接下書きとして投稿し、公開の判断だけを人に残します。
三つは Slack や Gmail の接続です。書き出し完了の通知、レビュー依頼、公開後のシェア原稿の下書き。運用の周辺の連絡を、記事生成の流れの中でそのまま片付けます。
MCP サーバーは1本ずつ入れます。組む順は Drive → CMS → Slack。素材の入り口、成果物の出口、運用の連絡の順で塞いでいくと、途中で詰まっても影響範囲が小さく済みます。
実装の最小構成｜30本のネタ表から下書きを回す
ここまでの Skills・サブエージェント・Hooks・MCP を組み合わせた、最小構成を示します。
準備は次の3つです。posts/topics.csv にネタ表を30行入れる。.claude/skills/ に blog-writing・blog-copyedit・blog-seo・blog-publish の4つを置く。.claude/agents/blog-writer.md にサブエージェント定義を置き、preload する skills に blog-writing と blog-seo を指定する。
実行はメインセッションで1行の指示から始めます。「posts/topics.csv の30本を、blog-writer サブエージェントに1本ずつ割り当てて、下書きを posts/<slug>/draft.md に書き出して。」この一行で、Claude はネタ表を読み、30のサブエージェントを立ち上げ、背景で並列に下書きを進めます。
書き出しの直前で PreToolUse が命名規則を検査し、書き出しの直後で PostToolUse が文字数と禁止語を検査します。fail の記事はメインセッションのログに戻り、こちらが確認して blog-writer に差し戻します。
30本すべてが draft の状態になったら、次は校正のフェーズです。同じ枠組みで、blog-copyeditor サブエージェントを立ち上げ、posts/<slug>/draft.md を読み、posts/<slug>/edited.md を書き出します。ここでも Hooks が検査を通します。
最後の公開フェーズは blog-publisher サブエージェントに任せます。edited.md を読み、MCP 経由で CMS に下書き投稿を作り、投稿の URL を posts/<slug>/publish.md に書き戻します。人は CMS 側で最終確認と公開の判断だけをおこないます。
この構成で、30本の下書きが1晩で揃う状態が作れます。速さの効用よりも、指示の再現性が上がることの効用のほうが大きくなります。担当者が変わっても、同じネタ表と同じ Skill から、同じ品質の下書きが上がってきます。
品質を保つための3つの検査工程
一括生成は、速く回るからこそ、品質の検査を強めに入れる必要があります。3つの層で入れます。
一つめは Hooks による機械的な検査です。文字数、禁止語、h2 の数、命名規則、内部リンクの本数。数値と grep で判定できるものは、この層で機械的に落とします。人の目に上がる前で止められると、後段の直しが浅くなります。
二つめは校正サブエージェントによる文体の検査です。表記揺れ、翻訳調、断言の強さ、句読点の位置。数値では判定しづらい要素を、独立したサブエージェントに読ませます。書いた本人（blog-writer）と検査する主体（blog-copyeditor）を分けるのが要点です。同じサブエージェントに検査させると、書いた本人の癖を「良し」と判断してしまいます。
三つめは人の目視です。公開前にこちらが読むのは、この層です。前の2層で機械と文体の検査が済んでいるため、人の目視は「主張の筋が通っているか」「一次情報の使い方に無理がないか」に集中できます。目視が1本あたり5分に収まるようになれば、月に何十本の運用が現実の稼働時間で回せます。
詰まったときの切り分け
30本の一括生成を回していると、必ずどこかで詰まります。切り分けの順番を決めておくと、対応が早くなります。
最初に見るのは PostToolUse のログです。fail の記事とその理由が、ここに集まります。禁止語なら Skill 側の禁止語リストを見直す、文字数なら Skill 側の目安を調整する、命名規則なら PreToolUse 側の検査条件を見直す。原因の層ごとに戻る場所が違います。
次に見るのはサブエージェントの完了時の要約です。書き終えた各サブエージェントは、要約と成果物のパスをメインに返して終了します。要約に「参考にした一次情報が見つからなかった」「トーンの指示が矛盾していた」のような報告があれば、そのままネタ表と Skill を直します。
最後に、それでも同じ場所で詰まる場合は、Skill の粒度を疑います。1つの Skill に手順を詰め込みすぎると、Claude が全体を読み込んだ結果、途中の指示が背景に埋もれます。手順の塊ごとに Skill を割り直すと、精度が戻ります。
Claude Code の Hooks・Skills・サブエージェント・MCP の4つを組み合わせると、ブログ記事の一括生成は「Claude が書く」だけではなく「量産の骨組みごと自動化する」ところまで踏み込めます。手が動く量を減らすのではなく、判断だけを人に残す設計として使う道具です。
同じ考え方は、素材の一括生成にもそのまま横展開できます。詳細は Claude Code をクリエイティブに使う実装ガイド を起点に、ブランドコンテンツの一括生成ワークフロー、画像の一括生成の workflow、映像スクリプトの一括生成の workflow、Artifacts でニュースレターを組む workflow を合わせて確認してみてください。
FAQ
Q1. Claude Code でブログ記事を一括生成するとき、無料でどこまでできますか。
A. Claude Code の CLI 自体は無料で導入できますが、実際の生成は Anthropic の API 課金または Claude の有料プランに紐づきます。従量課金と定額のどちらが向くかは、月あたりの本数と1記事の想定字数で決まります。少ない本数から始めて、月ごとに使用量を見て切り替える運用が安全です。
Q2. サブエージェントを何本まで同時に走らせられますか。
A. 公式ドキュメントには本数の上限は明示されていません。実務では、書き出しの並列度を上げるよりも、書き出し前後の検査を強めに入れることのほうが、詰まりの発生を抑えられます。まず5本から始めて、Hooks のログを見ながら段階的に上げていく形が安定します。
Q3. WordPress や Notion への反映は、どこまで自動化できますか。
A. 対応する MCP サーバーを入れれば、下書きの作成と本文の反映までは自動化できます。公開のボタンを押す判断は人に残すのが実務的です。一括で公開までしてしまうと、後段の直しが記事一覧に露出した状態で走ることになり、影響が広がります。
Q4. Claude Code と、通常の Claude の Web 画面での作業とは何が違いますか。
A. Claude 単体は1回の対話が単位ですが、Claude Code はローカルのファイル・シェル・外部ツールにまで手が伸び、複数の作業を並列で回す仕組みまで内蔵している点が違います。1本の記事を書くだけなら Web 画面で十分ですが、月に何十本を型で回すなら Claude Code の設計が噛み合います。
Q5. Skills とサブエージェントの使い分けの目安は。
A. Skills は「型」を Claude に持たせる仕組み、サブエージェントは「作業単位」を切り出す仕組みです。ブログの見出しの規約は Skill に、1記事ぶんの生成は1サブエージェントに、というのが基本の切り分けです。両者は組み合わせて使うことが前提で、どちらか片方だけで済ませようとすると、指示が Skill 側に膨らむか、サブエージェント側の指示に型が埋もれます。