AI編集者開発のリアル(1)　100記事書いて気づいた限界

こんにちは、パレイド思想部です。

ブログ100本書いて気づいた限界：AI編集者（仮）を作る理由
まとめ

ブログ100本書いて気づいた限界：AI編集者（仮）を作る理由

記事を書くこと自体は、楽しいものです。

アイデアを言語化して、コードを動かして、「こういうことだったのか」という発見を文章に落とし込む時間は、快適な知的作業です。しかし記事の本数が50を超えたあたりから、ある種の重力が働き始めました。書くこと「以外」のすべてが、少しずつ重くなっていったのです。

手作業の泥沼

最初の兆候は「同期ズレ」でした。

当サイト「pareido.jp」は WordPress で動いています。記事はローカルの Markdown ファイルで書き、WordPress の投稿として公開するという流れです。最初は手作業で十分でした——記事を書いて、ダッシュボードにペーストして、カテゴリを選んで、公開ボタンを押す。シンプルな工程です。

問題は、WordPress 側で軽く直した修正が、ローカルの Markdown に反映されないことでした。スマホでちょっと誤字を修正する。ダッシュボードでカテゴリを追加する。気づけば「どちらが正」なのかが分からなくなります。記事が増えるほど、この「どこが最新か問題」は雪だるま式に膨らんでいきました。

次はサムネイルでした。

SEO 的にも見た目的にも、記事ごとにサムネイル画像があるほうが圧倒的に良いです。でも Canva を開いて、テンプレートを選んで、タイトルを打ち込んで、エクスポートして、WordPress にアップロードして……1枚あたり5〜10分かかります。100本だと最大1000分。丸2日分の作業時間がサムネイル生成に消える計算です。

そしてアナリティクスです。

「どの記事が読まれているか」は、Google Analytics のダッシュボードを開けば分かります。しかし「どの記事がなぜ読まれているか」「次に何を書くべきか」は、Markdown を編集しているエディタと、WordPressと、Google Analytics と Search Console とを行き来しながら手動で集計しないと見えてきません。月次レポートを作るたびに、スプレッドシートと睨み合いながら30分が溶けていました。

ある日、連載のメモを取りながら、ふと考えました。

この1時間、自分が何をしていたのか?

WordPress にログインして前回の記事 ID を確認（5分）
本文をMarkdownでインポートして調整（20分）
以前の記事を確認して、サムネイルを Canva で作成（8分）
投稿して、スラッグを確認（3分）
カテゴリやタグを手動で更新（2分）
ブラウザでの表示をチェック（5分）
WordPress側で入れた修正を手元のMarkdownに反映（7分）
次回のアウトライン案をメモ（10分）

書くことに使えた時間は正味30分。残りの半分は、書くことを支えるための手作業に消えています。

本当に使いたい時間はどこか

記事が10本のうちは問題ありません。50本になっても、なんとかなります。しかし100本、200本と増えるにつれて、手作業のコストは線形ではなく指数的に増えていきます。なぜなら、過去の記事との整合性チェック・連載の状態管理・サムネイルのバリエーション管理……すべての作業が「記事数 × 作業種別」の積になっていくからです。

本当に使いたい時間は、アイデアを言語化することと設計の判断を記録することです。それ以外のすべては、自動化できるなら自動化したい。

これが「AI編集者」を作り始めた理由です。

ai-editor とは何か

「AI編集者」であるai-editor は、WordPress ブログの執筆・管理・公開を AI で自動化する Python ツール群です。ローカルの Markdown ファイルを「正規ソース（Single Source of Truth）」とし、そこから WordPress への同期・サムネイル生成・アナリティクス取得・次回記事生成まで、ブログ運営の全工程をカバーします。

壁打ちの相手としての将来の期待を込めて、「編集者」と擬人化していますが、まずは決まりきった作業を自動化したい。ある程度、ツールが形になった状態でのディレクトリ構造は下記の通りでした。

tools/
├── lib/              # インフラ層: LLM クライアント、WP API、ロガー
│   └── wp_api/       # WordPress REST API アダプター
└── publish/
    ├── core/         # ドメイン層: 設定、スキーマ定義（他に依存しない）
    ├── gnosis/       # 記事編集ドメイン: parse / write / analyze / edit
    ├── review/       # 品質チェック・RAG レビュー
    ├── services/     # アプリケーション層: 各機能のオーケストレーション
    ├── wp_sync/      # WordPress 双方向同期
    ├── thumbgen/     # サムネイル自動生成
    ├── wp_analytics/ # GA4 / Search Console 連携
    └── cli/          # CLI エントリーポイント（ルーティングのみ）

なぜこの構造にしたのか。

最初からこの構造が決められたわけではなく、普段の記事を考えるプロセスを言語化し、定型化するという段階をバイブコーディングを通じて繰り返した結果です。

記事化は、下記の流れで進みます。

アイディアをバイブコーディングで形にしながらツールを作る
その記憶を元に、箇条書きレベルで記事にしたいアイディアを列挙する
何記事の構成にするか、話の順序はどうするかを考え、連載回数分のMarkdownファイルに分割する
それぞれの記事をVS Code等で編集し、WordPressにアップロードする
WordPress上で装飾やメタデータの編集を行う
WordPress上で行った調整を手元のMarkdownに反映する

最初は、WordPressとの同期部分やサムネイル制作など、ほぼ定型化している部分から自動化を進めました。（サムネイル制作が定型化しているのは良し悪しですが）

徐々に上流の工程を言語化し、トライ＆エラーで今の形に落ち着きました。

誰のためのツールか

ai-editor が恩恵をもたらすのは、PythonやJavaScriptでツールを開発している方です。特に、コードは没頭して楽しく書けるが、日報や記事の作成に疲弊しているという方向き。コードや断片的なメモ、gitへのアクセス履歴から、ドキュメントを生成できます。

現状は100%の自動化には至っていませんが、大幅にドキュメントの労力が減りました。なにより、書くことのベースが自動で整うことで、「自分に記憶をはめ込んでいく」形に作業が変わり、心理的なハードルが大きく下がりました。

ai-editor の全体像（鳥瞰）

連載全8回で、以下を順に解説していきます。

回	テーマ
第1回（本記事）	なぜ作ったか——手作業の限界と設計方針
第2回	Markdown ↔ WordPress 双方向同期の設計
第3回	LLM による記事自動生成パイプライン
第4回	RAG を使った記事品質チェックの実装
第5回	Stable Diffusion によるサムネイル自動生成
第6回	GA4 / Search Console 連携アナリティクス
第7回	CLI・GUI・FastAPI の3インターフェース設計
第8回	連載管理・ペルソナ・シナリオの YAML 構造化