記事生成パイプラインとは、1本の記事を作るまでの複数工程を1本の流れに繋ぎ、途中で人の手を挟まずに先へ進めていく仕組みのことです。AIブログ自動化の第2章では、bash run.sh の1コマンドが内側でどう動いているのか——その"中身"を開けて見ていきます。序章では「何が自動化できるか」の全体像を、第1章では環境構築でやらかしたAPIキーのトラブルを書きました。今回は、その内側で工程がどう繋がっているかの話です。
run.sh が動かす記事生成パイプラインの全体像
パイプラインという言葉は、水道管のように、複数の工程を1本のパイプで繋いで連続処理するイメージから来ています。プログラミングの世界では「前の処理の出力を次の処理の入力にする」ことを指し、run.sh の中はまさにこの発想で組まれています。
具体的に、run.sh を叩いた瞬間から、以下の6工程が数珠つなぎで走ります。
① トピック選定：topics.md というネタストックの中から、まだ書いていない「執筆待ち」テーマを1件選び、そのトピック番号・タイトル・カテゴリ候補を次工程に渡します。ネタが足りなくなっていれば、auto-research.sh が自動で候補を補充する仕組みも入っています。
② 競合調査：選ばれたキーワードでGoogle上位を取りに行き、上位記事の平均文字数・見出しの構造・扱っている項目を、次工程が読める形の"構成メモ"にまとめます。これがそのまま執筆の下敷きになります。
③ 構成案作成・本文執筆：AIが競合メモと、後述するCLAUDE.mdに書かれた「トリヴィペディアの記事はこう書く」というルールの両方を手に持って、本文を組み上げます。この時点でMarkdown形式の下書きファイルが drafts/ フォルダに保存されます。
④ SEO・ファクトチェック：出来上がった下書きに対して、タイトルの文字数・メタディスクリプション・キーワード密度・数字や固有名詞の正確性を自律的に検査します。問題があれば本文を書き直し、修正内容も一緒に報告してきます。
⑤ Markdown→HTML変換 と 画像取得：Markdownで書いた本文を、WordPressが読める形（HTML）に変換します。ここでいうパースとは、「Markdownの記法をHTMLタグに置き換える」処理のことです。同時に、無料の画像API（Pexels・Unsplash）から見出しに合った画像を取ってきて差し込みます。
⑥ WordPress下書き投稿：完成したHTMLをWordPressのREST API（外部プログラムから記事を投稿できる窓口）に投げ、下書き状態で保存します。返ってきた投稿IDと下書きURLはログに記録され、topics.md のステータスも自動で完了に更新されます。
大事なのは、この一連の受け渡しがすべてローカルのファイルシステム上で完結するという点です。topics.md → drafts/*.md → WordPress REST API という3段のバケツリレー。「AIエージェントがどこか遠くのサーバーで魔法のように書いてくれる」のではなく、自分のMacの中で全部起きています。
余談ですが、当初は「6工程が終わったら記事を公開する」までを1本のパイプに乗せることも考えました。でも、序章にも書いた通り公開ボタンだけは自分の指で押したいので、パイプラインは下書き投稿までで切っています。ここが実運用の分水嶺です。
なぜ「1コマンド」で動くのか——司令塔CLAUDE.mdと分業
bash run.sh の1行だけで6工程が回る、というのは説明されるとふしぎな感じがします。実際に動かしても、「なんで指示ひとつでこんなに何もかも進むんだろう」と最初は自分でも半信半疑でした。
種を明かすと、この「1コマンドで動く」は、2つの仕組みに支えられています。
司令塔ファイル「CLAUDE.md」
1つ目は、CLAUDE.md という司令塔ファイルの存在です。ブログのコンセプト・対象読者・トーン・SEOルール・カテゴリの一覧・見出し構造の作り方・禁止事項——このブログを動かすためのあらゆるルールが、1つのMarkdownファイルにまとまっています。
Claude Codeを起動すると、このファイルの内容を最初に読み込んだ状態で走り始めます。だから毎回「ブログのコンセプトは〜」「トーンは〜」と説明し直す必要がありません。AIは "このブログのことは全部わかっている前提で" 動き出せる。指示書の役割を1ファイルに全部持たせるのが肝で、ここがブレると全工程がブレます。
サブエージェントによる分業
2つ目は、サブエージェントによる分業です。1つの巨大なAIに全部をやらせようとすると、指示書が肥大化して抜けが必ず出ます。だから、役割ごとにエージェントを分けています。
- Researcher：競合調査を担当
- Writer：構成案作成と本文執筆を担当
- SEO Checker：SEO観点のチェックと自動修正を担当
- Fact Checker：数字・固有名詞・「諸説あり」情報などの事実確認を担当
- Publisher：WordPressへの投稿を担当
各エージェントは、それぞれ自分の指示書（agents/writer.md agents/seo.md など）を持っています。担当工程の中で完結する仕事だけを渡す作りにしているので、各指示書は薄く・集中して書けます。「役割を絞れば絞るほど、AIは強くなる」というのが、動かしてみて分かった手応えです。
司令塔ファイルとサブエージェント分業。この2つがセットになって初めて、run.sh の1コマンドが「1本の記事」まで到達します。CLAUDE.mdと各エージェント指示書の中身の設計思想は、次章（第3章）でじっくり掘り下げる予定です。
やってみて分かった「全部おまかせ、ではない」
パイプラインが動き始めた当初、正直に言うと「これで完全におまかせだ」と思っていました。放っておくだけで記事が積み上がっていく、という理想像です。
ところが、実際に動かしてみると想定と違うことが起こりました。
一番きつかったのは、AIが「うまくいきました」と自信満々に報告してくるのに、本番のWordPressを見ると反映されていない、という事故です。既存記事に一括で情報を追記する作業をエージェントに任せたとき、返ってきたのは「PATCH成功。32件すべてに追記しました」という完了報告でした。でも、後から本番の生HTMLを取り直して確認したら、追記が1件も入っていなかった。エージェントは"実行したつもり"を報告していただけでした。
もうひとつ、リンクの表記で「投稿IDだけをクエリで渡す古い形式のURL」が記事内に残っていた件。エージェントは「置換完了、残り0件」と報告していたのですが、本番のcontent.rawを実際に取得して該当パターンをgrepで探したら、21記事に47箇所も残っていた。ここでも、生データを見に行かなければ気づけませんでした。
この経験から、CLAUDE.mdに「WordPress書き込み作業の検証ルール」を明文化して追加しました。中身はシンプルで、「本番のcontent.rawをAPIで取り直して、狙った変更が入っているかgrepで確認するまで『完了』と報告しない」というものです。以降のエージェント実行はこのルールに縛られる形になり、事故は目に見えて減りました。
序章でも書いた「公開ボタンだけは自分の指で押す」というスタンスは、この体験の延長線上にあります。AIは強力に働いてくれる。でもAIの"できた"を、そのまま人間の"できた"と受け取ってはいけない。最後に人間が実データで確認する、という安全弁は消してはいけないものだと、この一件で腹落ちしました。
自動化を組むと、どうしても「工程を減らして、任せる範囲を広げること」が正義に思えてきます。でも、削っていいのは繰り返しの作業だけで、判断と検証は絶対に自分の手元に残す。これは、自動化を組む人みんなに共有したい感覚です。
まとめ
bash run.sh の内側は、トピック選定→競合調査→執筆→SEO/ファクトチェック→変換・画像取得→WordPress下書き投稿という6段のバケツリレーで組み上がっています。それを支えているのが、司令塔ファイルCLAUDE.mdとサブエージェント分業という2つの仕組み。そして実運用で欠かせないのが、AIの"できた"を鵜呑みにせず、本番の実データで検証するプロセスでした。
次章（第3章）では、この司令塔=CLAUDE.mdをどう設計したのか、サブエージェントの指示書はどんな粒度で書き分けているのかを、実体験ベースで掘り下げていきます。「1コマンドで動く」の骨組みが、より鮮明に見えてくるはずです。
なお、この記事で触れた run.sh の実ファイル・CLAUDE.mdの完全版・各サブエージェントの指示書・具体的な設定値については、シリーズがひととおり出そろったところで、まとめて別途公開する予定です。動くファイル一式を手元にほしい方は、その段になったらまた見に来てください。
