一言で言うと
複数ジャンルのオウンドメディア（ブログ）向けに、記事の執筆 → 画像生成 → 添削＆品質チェック → WordPress への公開 までを、AIエージェントが連携して無人で回すパイプラインです。個人が片手間で運用できる規模を前提に、「量を出す」と「変なものを公開しない」を両立させることを狙って作りました。
なぜ作ったか（背景）
複数のジャンルのブログを個人で並行運用していると、記事を継続的に増やしたい一方で、手作業だと
- 1本ずつ書いていたら時間が足りない
- 既存記事とテーマがかぶって共食い（カニバリゼーション）が起きる
- 急いで量産すると、事実誤認や怪しい情報が混ざる
という壁にぶつかります。最初は「AIに記事を書かせる」だけのシンプルなスクリプトでした。そこから少しずつ、重複を物理的に防ぐ仕組みや、公開前に事実関係をチェックする層を足していって、今の形になっています。最初から完成形を設計したわけではなく、運用しながら穴を埋めていった、というのが正直なところです。
何ができるか（主な機能）
- 記事の自動生成 — キーワードを起点に、構成（見出し）→ 本文 → HTML化までを生成。記事構造は統一フォーマットに固定（本文1万字以上・見出しの文字数バランスなど）して品質のばらつきを抑える
- 画像の自動生成と差し込み — アイキャッチや本文中の画像を生成し、WordPress にアップロードして記事に挿入
- 公開前の添削＆品質ゲート — 仕様チェック（構造・文字数）に加えて、読んで直す編集レビューと出典の実在チェックを通す。合格したものだけ公開、危ういものは「人間に要確認」へ退避
- マルチサイト運用 —
sites/<サイト名>/配下に設定とキーワードとサイト別の編集ブリーフ（読者像・トーン・NG語彙）を置き、ジャンルの違うサイトを混線させずに並行運用 - 重複の自動回避 — 同じキーワードを複数のエージェントが同時に書き始めても、1本に絞り込むロック機構。さらに既存記事との「テーマかぶり」を事前に検出
- キーワード提案 — 検索パフォーマンスの実データ（Google Search Console）から、まだ取れていない需要を拾ってキーワード候補を提案
どう作ったか（技術スタックと工夫）
- 言語 / 基盤: Python、データは SQLite + SQLAlchemy + Alembic（マイグレーション管理）。サーバーやDockerは不要で、ファイルベースで完結
- 連携先: WordPress REST API（下書き入稿・公開・カテゴリ同期）、画像は OpenAI / OpenRouter の Images API
- AIエージェント: Claude Code と Codex を役割分担で併用
- 操作系: GUIは廃止し CLI とスキル（コマンド）群で全操作
パイプラインの形
記事1本は「準備 → 本文 → 画像 → 公開 → 公開後チェック」という段を通ります。
キーワード
│
▼
[Unit1 準備] タイトル・構成・カテゴリを決めてテンプレ固定
│
▼
[Unit2 本文] 下書き → チェック → HTML化（生成の中心）
│
▼
[Unit2.5 編集] 文字化け・表記ゆれ・文体を機械チェック
│
▼
[Unit3 画像] 画像生成 → WordPressへアップロード
│
▼
[Unit4 公開] HTML整形 → WordPress入稿（下書き/公開）
│
▼
[公開後レビュー] 仕様チェック＋編集チェック → 必要なら自動修正工夫した点
- 重複生成を「状態」ではなく「ロック」で防ぐ — 同じキーワードに対する記事は、いずれかの状態で既に存在していれば後続を物理的に止める設計。複数のAIエージェントを並行で走らせても、同じ記事を二重に作ってしまわない
- テーマかぶりの事前検出網を拡張 — 既存のWordPress記事の索引を持っておき、新しい記事が過去記事と食い合わないかを書く前にチェック。この索引網を数百件規模から800件超まで広げて、検出精度を上げた
- 「真実の源」を1つに決める — たとえばキーワードの管理は「TSVファイルに残っている＝未着手／消えている＝書いた」というルールに単純化。状態フラグを増やすほどバグるので、判断の拠り所をできるだけ1箇所に寄せている
- 壊れやすい所にガードを置く — 公開URL（スラッグ）が未確定のプレースホルダのまま公開される事故があり、バリデータで止めるよう強化。失敗の都度ガードを1枚ずつ足していくスタイル
AI（Claude / Codex）の使い方
ここがこのプロジェクトの肝です。最初は「人間が ①記事生成（Claude）→ ②画像生成（Codex）→ ③添削＆公開（Claude）を手動で3回起動する」半自動運用でした。
そこから、Claude Code を“指揮者”役にして、自分は最初のキーワード承認だけを行い、あとは無人で全段を通す構成へ進めました。
- 執筆・添削・公開判断は Claude が記事ごとに並列で担当
- 画像生成は Codex に任せ、Claude が裏でヘッドレス起動して受け渡し
- 品質チェックは別エージェントとして独立させ、「書いた本人がそのまま通す」状態をやめた
特に効いているのが公開前の編集レビューです。機械的な採点で素通しするのではなく、「実際に読んで・出典のURLを開いて裏取りして・直す」ところまでAIにやらせています。これで実運用中に、
- 出典先に書かれていない統計値の捏造を削除
- 引用元に存在しない「嘘の出典」を、裏が取れるページへ貼り替え
- 完結済みの作品を「連載中」と書いた事実誤認の修正
といった、量産にありがちな事故を公開前に止められるようになりました。手動で1本ずつ起動していた頃から、4ジャンル × 3記事/日を無人で公開できるところまで来ています。
詰まったところ・学んだこと
- 順番を間違えると詰まる初期化 — 新サイト追加時に、キーワードを入れる順序を間違えると全件がロック状態になって止まる「ブートストラップ問題」。手順書（README）に強めの注意書きを残して再発を防いだ。自動化は「正しい手順」を文書化しないと自分が一番ハマる
- 別AIを無人で走らせる怖さと安全網 — 画像担当のCodexをライブのWordPressに無人で接続するのは怖い。危険な全権限フラグは使わず、ネットワークだけ許可するサンドボックスを保ったまま、処理対象を「指定したIDだけ」に強く限定。さらに下流の品質ゲートと「人間に要確認」退避で二重に堰き止めている
- 長時間処理は“生きてるのか”が分からなくなる — 画像生成は数時間かかることがあり、接続が一時的に切れて再接続を繰り返すこともある。完了件数だけ見ると停滞と区別がつかないので、「出力ログの行数」「生成済み画像の枚数」の伸びも合わせて生存確認する見張り役（ウォッチドッグ）を設計に組み込んだ
- 散らかりは定期的に掃除しないと効いてくる — ローカルの作業ファイルが知らぬ間に肥大していたので、「WordPress と DB が正本・ローカルは使い捨て」という基準で整理（約1.8GB → 約140MB）。ただし消す前に「使用中でないか」を必ず確認するガードを付ける。自動化システムは作るだけでなく、保守の設計も要る
現在のステータス
運用中です。3日連続で「4ジャンル × 3記事/日」をほぼ全自動で公開できており、品質レビューが実際の事故を毎日のように捕まえています。次は、いまは手動でつないでいる3段（生成 → 画像 → 公開）を 1コマンドで通すオーケストレータ本体の実装と、過去に公開した在庫記事を同じ品質基準で一括監査する運用を進めていく予定です。
お気軽にご相談ください
「AIと組んで、こういう繰り返し作業を半自動／全自動にしたい」というご相談を、個人規模・小さく始める前提で受け付けています。最初から完璧な設計でなくても、運用しながら穴を埋めていけば、ここまでのものは作れます。これからAIでプログラミングを始めてみたい方にも、その実感が少しでも伝われば嬉しいです。
コメント