Claude Code でブログ運用を半自動化した記録|執筆から WordPress 公開までを1セッションで回す仕組み【2026年版】

AI活用ノウハウ
※本記事はアフィリエイト広告(PR)を含む可能性があります。

「ブログを書くより、ブログを書く仕組みを作る方が面白い」——そう思って Claude Code でブログ運用の自動化を組み始めて約1ヶ月、ようやく 1記事=1セッションで公開まで到達できる状態 ができたので、その実装記録を公開します。本記事では、戦略ドキュメント・サブエージェント・整形スクリプト・WordPress REST API を組み合わせた具体的なスタックと、それで運用した直近の納品実績、ハマった失敗談、現時点の限界までを率直に書きました。同じことを真似したい人のためのスタータ手順も付けています。

この記事の結論(3行)

  • Claude Code に「戦略ドキュメント」「ディレクター agent」「エディター agent」「整形スクリプト」「WP投稿スクリプト」を組み合わせると、1記事の執筆〜WP公開を約1時間で回せる
  • 人間が見るのは 戦略・最終プレビュー・赤入れ だけ。本文の整形や納品の機械作業は全部スクリプト化
  • 万能ではない。一次情報・実体験・編集方針は人間が握り続ける前提のスタック

Before / After — 何が変わったか

導入前と現在で、1記事を WordPress に納品するまでにかかる作業を比較してみます。

工程 Before(手作業中心) After(Claude Code+自動化)
構成検討 60分(白紙から) 5〜10分(戦略書ベースで自動提案)
本文執筆 120〜180分 15〜30分(ドラフト生成+赤入れ)
SEO・コンプラ確認 30分(主観) 5分(ディレクター agentが指摘)
余白・装飾整形 20分(手動) 数秒(スクリプト)
アイキャッチ作成 30〜60分 3〜5分(画像生成API)
WP投稿(タグ・カテゴリ含む) 15分 数秒(REST APIスクリプト)
合計 約4〜6時間 約45〜60分

体感としては 4〜6倍速。ただし「速くなった」というより、機械作業の時間がなくなって、編集判断や事実確認に集中できる 構造に変わったのが大きな違いです。

スタック全体像

使っている部品を上から並べると次の構成です。

┌─────────────────────────────────────────┐
│ projects/blog/                          │
│  ├─ strategy.md       戦略書(SEO/構成/KPI) │
│  ├─ learnings.md      過去の校正フィードバック │
│  ├─ articles/         記事ごとのフォルダ        │
│  ├─ scripts/                                    │
│  │   ├─ inject_spacing.py   余白挿入          │
│  │   └─ sync_image_urls.py  画像URL同期     │
│  └─ template/                                   │
│                                                  │
│ .claude/                                          │
│  ├─ agents/                                      │
│  │   ├─ blog-director.md   校正担当 agent   │
│  │   └─ blog-editor.md     編集担当 agent   │
│  └─ skills/                                       │
│      ├─ wp-post/           WordPress 投稿     │
│      └─ image-gen/         アイキャッチ生成    │
└─────────────────────────────────────────┘

これを Claude Code の1セッションから呼び出します。以下、コンポーネントごとに役割を分解します。

1. 戦略書(strategy.md)— サイトの設計図

サイトの軸・KPI・記事ラインナップ・骨子テンプレ・SEO ルール・余白ルールまでを1つのMarkdownにまとめています。Claude Code のメモリ機能で常にコンテキストに乗るため、「次に書くべき記事は?」と聞くだけで戦略に沿った提案が返ってくる 状態です。これがないと、AIに振っても「無難な記事」しか出てきません。

2. learnings.md — 過去フィードバックの蓄積

校正で指摘されたNG表現(「必ず」「絶対」などの断定・全称表現)を蓄積するファイル。次の記事を書くときにディレクター agent がここを参照するので、同じ失敗を繰り返さない仕組みになります。

3. blog-director(校正 agent)

strategy.md と learnings.md を読み込み、ドラフトを4軸(骨子・SEO・内部リンク・CTA/コンプラ)で校正する サブエージェント。「リード文200字超」「断定表現混入」「内部リンク未設置」「FAQ不足」などを指摘して返してくれます。

4. blog-editor(編集 agent)

記事マークダウンを受け取って、director と最大2ラウンド校正をやり取りしながら本文をリライトし、最終的に wp-post 経由で WordPress に納品する 編集サブエージェント。指示は「この記事を公開ステータスで仕上げて」だけで足ります。

5. inject_spacing.py — 機械的な余白整形

WordPress テーマの既定行間だとセクションが詰まって読みづらい問題への対策として、H2 直前に 56px、H3 直前に 24px のスペーサー div を 機械的に注入 するスクリプト。冪等性を担保しているので二重実行で増えません。

6. wp-post — WordPress REST API ラッパー

記事ファイル(Markdown or HTML)とメタ情報(タイトル・スラッグ・カテゴリ・タグ・アイキャッチ)を渡すと、REST API で 新規投稿・更新・公開ステータス変更 までを1コマンドで完結。アイキャッチもローカル画像パスを渡せば自動でメディアにアップロードしてくれます。

7. image-gen — アイキャッチ自動生成

OpenAI の画像生成 API(gpt-image-1)をラップしたスクリプトで、プロンプトを渡すだけでブランドスタイルに沿ったアイキャッチを生成。「mitsuketa スタイル」というプリセットを当てているので、複数記事間でビジュアルが統一されます。

実際のフロー(MiriCanvas記事を例に)

直近で公開した MiriCanvas のレビュー記事 を例に、1セッションで何が起きたかを書き出します。

  1. ASP案件のPR文を Claude Code に貼り付け(必須要件、リンク、リスティングNGなどを抽出させる)
  2. 戦略書と照らし合わせて記事タイプ・骨子を決定(今回は Type C How-to+一部 Type A レビュー要素)
  3. 本文ドラフトをHTMLで生成(リード→結論→1stCTA→各H2→FAQ→2ndCTA→まとめ)
  4. blog-editor サブエージェントに引き渡し(校正・余白注入・WP投稿まで丸投げ)
  5. image-gen でアイキャッチ生成(プロンプトはこのスキル内で1行で渡せる)
  6. wp-post で featured image を後付け+publish

このうち人間(なお)が判断したのは「記事タイプの選定」「結論3行のメッセージ」「CTAの文言」「アイキャッチのプロンプト方向性」の4つだけ。それ以外はすべて AI agent とスクリプトが回しています。

失敗談:本文が全部消えた事件

正直に書きますが、構築途中で一度 公開済み記事の本文が空っぽになる事故 がありました。原因は wp-post スクリプトの実装ミスで、「--post-id でアイキャッチだけ更新しようとしたら、空文字の content で本文を上書きしてしまう」という挙動になっていたためです。Claude Code のような非対話環境では sys.stdin.isatty() が False になり、空のstdinを読み込んで本文として送ってしまっていました。

発覚した経緯は「ブラウザで開いたらPR表記しか出ていない」というシンプルなもの。すぐに次の手順で復旧しました。

  1. WP REST API で実際の content を確認 → 空であることを確定
  2. ローカルに残っていた最終版 HTML を --content-file で再投稿
  3. 同時に post.py 自体を修正(content引数が無く stdin も空なら content フィールドを payload に含めない、というガードを追加)
  4. ついでに先頭メタコメント(<!-- meta: ... -->)を送信前に剥がす関数を追加し、表示上のノイズも除去

教訓:自動化スクリプトは「メタ操作だけ」のケースで本体データを破壊しないように、引数の組み合わせで「触らない」を実装する。一度やられると本当に焦ります。

このスタックの現時点の限界

万能ではないので、ハマる場面も正直に書いておきます。

  • 一次情報は人間が握る必要がある:実際の受講・契約・運用体験はAIには代替できない。「触ってない記事」を書こうとすると即座に薄くなる
  • 事実関係の最終チェックは人間必須:固有名詞・料金・スペックは公式情報を直接確認しないと事故る
  • 構造化データ(FAQPage 等の JSON-LD)は REST API で送れない:WordPress の unfiltered_html 権限の壁で 403。管理画面 or Yoast 等のSEOプラグイン経由が必要
  • ディレクター agent も完璧ではない:learnings.md に蓄積しないと同じ指摘を毎回受ける
  • アイキャッチの再現性が完璧ではない:同じプロンプトでも生成結果に揺らぎがある。複数枚出してベストを選ぶ運用
  • 記事数を増やすほどコストが線形で増える:OpenAIのAPI代+Claudeの利用料。1記事数百円〜千円規模で、量産すると意外と効く

真似したい人のためのスタータ手順

0から組むなら、最小構成で次の順序が最短です。

  1. WordPress を立てる(レンタルサーバー+独自ドメイン+Cocoon等のテーマ)
  2. WP REST API のアプリケーションパスワードを発行(管理画面→ユーザー→アプリケーションパスワード)
  3. wp-post 相当のスクリプトを作る(requestsとBasic認証だけで動く、100行以内)
  4. 記事の骨子テンプレ(strategy.md相当)を1ファイル書く(SEO・余白・CTA設置場所のルール)
  5. Claude Code で「このテンプレに沿ってドラフト書いて」と振る
  6. 1記事を手動で校正して納品 → 指摘点を learnings.md に蓄積
  7. 3記事溜まったらディレクター agent を作る(校正の型化)
  8. 5記事溜まったらエディター agent を作る(納品の型化)
  9. 10記事溜まったら画像生成・余白注入をスクリプト化

順序を守るのが大事で、いきなり全部組もうとすると「動くけど自分の運用に合わない仕組み」ができあがります。記事を書きながら必要になったところから順に自動化するのが結果的に早いです。

応用:自分以外のブログでも回せるか

結論から言うと、同じ仕組みは他のブログ運営者にも適用しやすい構成 です。実際、なお側ではこのスタックを AI業務自動化の受託案件 のショーケースとしても使っています。違いは:

  • strategy.md と learnings.md を クライアントごとに分ける
  • WP接続情報を 環境変数で切り替え る
  • 校正基準は クライアントのトンマナ に書き換える

これだけで他社のWordPress運用にも適用可能になります。AIに任せる範囲・人間が握る範囲を最初に切り分けるのが運用設計の肝です。

まとめ:書く時間を「考える時間」に変える

ブログ運営における AI 活用は「執筆を肩代わりさせる」のではなく、「機械作業を全部AI/スクリプトに渡して、人間は判断・体験・編集に集中する」 という構造変更だと感じています。書く速度が4〜6倍になったというより、書いていて疲れる工程がほぼ消えました。

このスタックで実際に納品した直近の記事は以下です。アーキテクチャの参考に開いてみてください。

「自分でも組みたい」「もしくは丸ごと依頼したい」というご相談があれば、X や問い合わせフォームから声をかけてください。実装記録は今後もこのブログにアップしていきます。

※本記事は2026年5月時点の構成をもとに執筆しています。各コンポーネントは継続的に改修中で、現状の仕様と異なる場合があります。

タイトルとURLをコピーしました