Claude APIで記事生成・品質チェック・WP投稿を自動化する

記事を1本書くのに、調査・執筆・校正・画像作成・WordPress投稿で2〜3時間かかっていた。それをキーワードを入力するだけで全部やってくれる仕組みを作ったら、人間がやるのはレビューと公開ボタンを押すだけになった。

この記事では、Claude APIを中心に組んだ記事生成パイプラインの仕組みと実装のポイントについて解説する。品質チェック→AIリライトのループや、ComfyUIによる記事画像の自動生成まで含めた一気通貫の構成だ。「生成して投稿するだけ」で終わっている既存ツールとは一線を画す、品質保証込みの自動化の話をする。

パイプラインの全体像

システム全体の流れは以下の通りだ。

キーワード入力
  ↓
① 記事生成（Claude API / Opus）
  ↓
② 品質チェック（ルールベース + AI評価）
  ↓
③ AIリライト（指摘一括反映）
  ↓
④ 画像生成（ComfyUI / FLUX schnell）
  ↓
⑤ WordPress投稿（REST API / 下書き）

各ステップは独立したモジュールになっており、途中から再実行できる設計にした。例えば、画像生成サーバーが落ちていたら④をスキップして⑤に進み、後から画像だけ追加するといった柔軟な運用ができる。全ステップを一気通貫で流すバッチモードと、ステップ単体を指定して実行するモードの両方を用意している。

実際に運用してみると、ここで一番大事なのは「②品質チェック→③リライトのループ」だと気づいた。生成した記事をそのまま投稿すると、見出しが少なかったり文字数が足りなかったりして読者体験が落ちる。AIが自分で指摘して自分で直すループを入れることで、投稿品質が大きく安定した。

ステップ別の技術構成

記事生成の核心は「プロンプトの設計」だ。単純に「○○について記事を書いて」と送るだけでは、SEOに強い記事にはならない。

実際に運用しているプロンプトテンプレートでは以下を指定している:

• タイトル（28〜32文字）とdescription（80〜120文字）の形式
• H2見出しを6個以上入れる構成指定
• 冒頭500字以内に導入キーワード・結論先出しを含める
• 末尾500字に「## まとめ」を配置する
• 「例えば」「実際に」などの具体例ワードを1回以上
• アクション動詞（「してください」「手順」「ポイント」等）を5回以上

これをfrontmatterのテンプレートとしてプロンプトに埋め込み、Claude Opusに渡す。Opusを選んでいるのは、構成の整合性と文章品質のバランスが最も安定しているからだ。Sonnetでも十分な品質は出るが、見出し数や段落数の制約をOpusの方が守りやすい傾向がある。

生成されたMarkdownは drafts/ ディレクトリにslug名で保存する。例えばキーワード「Claude Code 導入方法」なら drafts/claude-code-intro.md として出力される。

品質チェックとAIリライトのループ

生成した記事をそのままWordPressに投稿するのは、品質面でリスクがある。そこで「品質チェック→AIリライト」を自動で回すようにした。

ルールベース品質チェック

まず機械的なルールチェックを実行する。チェックする項目は以下だ:

• 文字数: コードブロック除外で3000字以上（目標5000字）
• 見出し数: H2〜H6の合計5個以上
• 段落数: 空行区切りで10個以上
• 導入パターン: 先頭500字に「解説」「について」「紹介」等を含む
• 結論パターン: 末尾500字に「まとめ」「結論」「次のアクション」等を含む
• 具体例: 「例えば」「実際に」「具体例」等が1回以上
• アクション動詞: 「してください」「方法」「ポイント」等が3回以上

3項目以上failするとスコアが40以下（POOR）になり、リライト対象になる。チェック結果はJSON形式で出力され、次のリライトステップに渡される。

AIリライト（指摘一括反映）

品質チェックの指摘をJSONで受け取ったClaude Sonnetが、記事を修正する。実装のポイントは「外科的修正（apply-comment-fix）」と「全体リライト（apply-suggestions）」の2種類を使い分けていることだ。

文字数が少ない、見出しが足りないといった構造的な問題は全体リライトで対処する。一方、「この段落の表現が冗長」「CTAが弱い」といった部分的な改善は外科的修正で対応する。全部を書き直すよりも的確で速く、既存の良い部分を壊さないメリットがある。

リライト後は再度品質チェックを実行する。1回のリライトで全ての問題が解決しないこともあるため、最大3回まで自動でループさせている。

最終レビューとGeminiフォールバックの話

品質チェックを通過した記事に対して、最終レビューとしてAIに「読者視点での評価」をさせている。SEO・構成・読みやすさ・具体性・CTAの5観点でスコアとフィードバックをJSON形式で出力させる。

当初はClaudeに最終レビューをさせていたが、高負荷時に529（過負荷）エラーが頻発して運用が止まることがあった。そこで最終レビューのモデルをGemini 2.0 Flashに切り替えた。

Gemini APIでも同様に503過負荷エラーが起きるため、以下のリトライロジックを実装した:

待ち時間を増やしながら最大3回リトライするロジックをこう実装した:

retry_delays = [5, 15, 30]  # 秒
for delay in retry_delays:
    try:
        response = call_gemini_api(prompt)
        break
    except GeminiOverloadError:
        time.sleep(delay)
else:
    raise RuntimeError("Gemini API: 3回リトライ後も失敗")

5秒、15秒、30秒と待ち時間を増やしながら3回リトライする。これで深夜バッチ処理でも安定して動くようになった。

実際に、単一モデルに依存しないフォールバック設計は本番運用では必須だと感じている。Claude一本で組んでいた時は、モデル切り替え時やAPIの障害で一斉に止まることがあった。

ComfyUIで記事画像を自動生成する

記事画像の生成もパイプラインに組み込んでいる。使っているのはローカルのWindows機で動かしているComfyUI（FLUX schnell）だ。

Wake-on-LANで自動起動

画像生成サーバーは常時起動させておらず、パイプライン実行時にWake-on-LANで自動起動させる。常時起動にすると電力コストがかかるため、使うときだけ起こす設計にした。

# WoL magic packet を送信
send_magic_packet("CC:28:AA:8A:18:2E", ip_address="192.168.1.255")

# 最大60秒待機して接続確認
for _ in range(60):
    if ping_comfyui("http://192.168.1.102:8000"):
        break
    time.sleep(1)

MACアドレスに向けてmagic packetを送り、ComfyUIが応答するまでポーリングする。60秒以内に起動しなければエラーとして処理を続行（画像なしで投稿）する設計にしている。

画像プロンプトの自動生成と画像サイズ

記事のH2見出しからComfyUI向けの英語プロンプトを自動生成する。アイキャッチ画像（1600×900）を3バリエーション、H2ごとにセクション画像（1200×675）を最大5箇所×3バリエーション生成する。合計で最大18枚の画像が一度に生成される。

プロンプトのコツは「具体的な場面を描写する」ことだ。「AI automation concept」のような抽象的な表現より、「A developer at a sleek desk with VS Code open, multiple files being edited simultaneously by AI」のように具体的な場面を英語で書く方が、品質の高い画像が出る。

生成された画像はWordPressにアップロードする際に自動でJPEGに変換され、最初の1枚がアイキャッチ画像として設定される。

WordPress自動投稿の実装

最終ステップのWordPress投稿は、REST APIを使っている。WP-CLI経由のSSH方式も検討したが、レンタルサーバーでのSSH設定が面倒なのとREST APIの方がポータビリティが高いため、こちらを選んだ。

投稿時に自動で行う処理

REST API投稿時に以下を自動で実行している:

• タグ自動生成: 記事の内容をClaudeに読ませてタグ候補を5〜8個生成。既存タグとの照合で重複を避ける
• カテゴリ自動判定: frontmatterのarticleTypeとキーワードからカテゴリを推定
• 内部リンク挿入: 既存の公開済み記事との関連度スコアを計算して、本文中の適切な箇所に内部リンクを挿入
• アイキャッチ設定: ComfyUIで生成した1枚目の画像を自動でアイキャッチに設定
• 下書き保存: デフォルトはdraft状態で保存。人間が確認して公開する「Human in the Loop」の設計

投稿後に返ってくる投稿IDと編集URLを記録しておくことで、後から修正するときに参照できる。

タグ自動生成の実装詳細

タグ生成はシンプルなプロンプトで実装している。記事タイトルと本文冒頭500字をClaude Sonnetに渡し、「この記事に適切なタグを5〜8個JSON配列で返してください」と指示する。出力されたタグをWordPressの既存タグ一覧と照合し、新規タグは作成、既存タグはIDで紐付けする。

実際に運用してみると、タグの粒度が安定する点が意外と便利だ。手動だとついつい細かすぎるタグを作ってしまうが、AIが生成するタグは汎用性の高い適切な粒度になりやすい。

ハマりポイントと対処法

実際に本番稼働させてわかったハマりポイントを3つ紹介する。

① コードブロックを文字数から除外し忘れる

品質チェックの文字数カウントでコードブロックを除外しないと、コードが多い記事が「文字数十分」と誤判定される。読者に伝わる本文の文字数と、コード行数は別物だ。チェック時は ` ` ` で囲まれたブロックを正規表現で除去してから文字数をカウントするようにした。

② APIレート制限で連続実行が詰まる

複数記事をバッチ処理するとき、Claude APIのレート制限（RPM）に当たってしばらく実行が止まることがある。対処法はステップ間に time.sleep(3) を挟むことと、一度に処理する記事数を5〜10本に制限することだ。深夜に流すバッチなら30本程度まで安定して動く。

③ 記事のfrontmatterのパース失敗

Markdownのfrontmatterにコロン（:）を含む値を書くとYAMLパースエラーになる。例えばタイトルに「ChatGPT vs Claude: どちらが良い？」と書くと壊れる。対処法はfrontmatterの文字列値をすべてダブルクォートで囲むことと、パースエラー時のフォールバック処理を入れることだ。

よくある質問

Q: Claude以外のモデルでも動く？

A: 動く。実際にレビューステップではGeminiを使っており、生成ステップもOpenAI GPTに差し替えることは可能だ。モデル部分をインターフェースとして抽象化しておくとモデル切り替えがしやすい。ただし、プロンプトの出力フォーマット（frontmatterのYAMLなど）への忠実さはモデルによって差があるため、最初はClaudeで動かしてから他モデルに移行する方法をおすすめする。

Q: 月間コストはどのくらい？

A: 月50〜100本の記事を生成する場合、Claude APIのコストはおよそ$15〜30程度だ（Opus生成＋Sonnetリライト＋Sonnetタグ生成を合算）。画像生成はローカルのComfyUIなので電気代のみ。WordPress代やサーバー代は別途かかるが、外注で記事を発注するコストと比べると、品質を保ちながら大幅に削減できる。

Q: 生成した記事はGoogleにペナルティを受けない？

A: AI生成コンテンツ自体はGoogleのポリシーに違反しない。Googleが問題視するのは「品質の低いスパムコンテンツ」であり、生成手段（AIか人間か）は評価基準ではないとGoogleは明言している。このパイプラインでは品質チェック・AIリライト・人間によるレビューを経ているため、低品質なまま公開されるリスクは低い。実際に運用しているブログでは、投稿開始から3ヶ月で月間1万PV超の流入が確認でき、主要キーワードで検索1ページ目に表示される記事も複数出てきている。

Q: 画像生成はComfyUIでないとダメ？

A: ダメではない。Stable Diffusion WebUIやMidjourneyのAPIでも代替できる。ただし、ComfyUI（FLUX schnell）はローカルで動かせるため、API費用がかからない点と、画像のサイズ・バリエーション数を自由に指定できる点が気に入っている。クラウドのAPIでよければ、Replicate経由でFLUXを呼び出す方法もある。