書き終えた原稿を、WordPressの下書きに自動で置く。この最後の一歩を裏で動かしているのが、REST APIと変換スクリプトの組み合わせです。第3章では司令塔CLAUDE.mdとサブエージェント分業の設計思想を掘り下げました。ここから先は、その分業のもとで動く個々の仕組みを1つずつ開けていきます。第一弾は、記事を実際にWordPressへ届ける部分。REST APIとは何か、MarkdownがどうHTMLに変換されるか、カテゴリ・タグ・関連記事はどう自動で決まるか、そして投稿処理でどんな事故が起きるかを、体験ベースで書きます。
そもそもWordPressに"外から"記事を入れる仕組み——REST APIとは
普段WordPressで記事を書くときは、管理画面にログインして本文を書き、公開ボタンを押します。この手動フローはこれで問題ないのですが、「AIが書いた原稿を1コマンドで自動投稿する」を実現するには、管理画面を通さず、外部のプログラムから直接記事を送り込む仕組みが必要になります。
その窓口が REST API です。API（Application Programming Interface）とは、「外部のプログラムから機能を呼び出すための入口」のこと。RESTはその入口の作法の一つで、「URLに『何を』『どうする』を素直に対応させる」というスタイルを指します。乱暴に言えば、REST APIは"郵便窓口"のようなものです。手紙（HTTPリクエスト）を持って窓口（URL）に行き、「これを掲示板に貼ってください」（記事を投稿してください）と頼む。窓口はきちんと本人確認をして、要件どおりに掲示板へ貼ってくれる。
WordPressにはこの窓口が標準で備わっていて、「新しい記事を作る」「既存記事を更新する」「カテゴリの一覧を取得する」といったやり取りをすべてURL経由で行えます。ブログ自動化スクリプトは、この窓口を叩くことで、管理画面を一切開かずに下書きを作れる。「AIが書いた原稿がWordPressに勝手に置かれている」は魔法ではなく、この窓口があるおかげで成立している話です。
もう一つ大事なのは「本人確認」の部分。REST APIをただ開放してしまうと、誰でも投稿できてしまうので危険です。そこで第1章で発行したアプリケーションパスワードが効いてきます。あれは、REST API専用の「窓口の鍵」。パスワードを持っている＝正当な利用者、として認証を通してもらえます。この鍵は .env に置いておき、スクリプトからは環境変数として読み出す形にしています（鍵そのものをスクリプトに書き込まないのは、後から流出しないための基本ルールです）。
余談ですが、REST APIが使えるかどうかはサーバー側の設定にも依存します。私はエックスサーバー
を使っていて、REST APIは標準で有効・WAF（Webアプリケーションファイアウォール）の調整も管理画面から数クリックで済みました。「REST APIが動かない」で詰まらないためには、この選定はけっこう効いてきます。
MarkdownをWordPressの形に翻訳する——変換の役割
書き手（AI）はMarkdownで原稿を作ります。Markdownは、#や*といった記号でシンプルに書ける記法。人間にもAIにも読み書きしやすいので、下書きの段階はずっとMarkdownで扱っています。
一方、WordPressの本文はHTMLで持っています。つまり、Markdownで書いた原稿は、投稿する前に HTMLへ変換（パース） しないといけません。「パース」というのは、テキストを読み解いて別の形式に組み替える処理のこと。## タイトル と書いた行を <h2>タイトル</h2> に置き換える、といった対応づけを大量にやります。
トリヴィペディアでは、この変換を md2html.py という小さなスクリプトが担っています。ここは"変換"だけをやっているわけではなく、いくつかの下ごしらえも兼ねているのがポイントです。具体的には次のようなことを、変換のついでに済ませています。
- 大きな見出しの間に、広告タグを自動的に差し込む（記事の途中に自然に広告が入る位置を計算）
- 表（テーブル）を スマホで横スクロールできるラッパーで自動的にくるむ
- 公開済み記事の中から、タイトル類似度や本文リンクをもとに 関連記事を選び、記事末尾に自動挿入する
- 一覧記事のときは、SEOに効く 構造化データ（JSON-LD）を自動で埋め込む
つまり、変換スクリプトは「MarkdownをHTMLに直訳する翻訳者」だけではなく、「WordPressに置く前の最終仕上げをする内職係」でもあります。書き手であるAIには、「テーブルのスマホ対応どうする？」「広告どこに入れる？」といったことを一切考えさせずに、本文の中身だけに集中してもらえる。書く仕事とレイアウトの下ごしらえを分けるのが、変換工程の役割です。
ちなみに、この下ごしらえのルールもすべてCLAUDE.mdに書いてあります。「テーブルは4列以内が基本」「広告タグは手で書かず変換スクリプトに任せる」など。書き手側と変換側が同じルールブックを見ていて、責任範囲だけが違う——ここでも司令塔＋分業の設計が効いています。
カテゴリ・タグ・関連記事はどう自動で決まるか
投稿するときに欠かせないのが、カテゴリとタグの設定です。ここは自動化と手動運用の線引きが分かれるところなので、少し丁寧に書きます。
カテゴリは、記事のタイトルと本文に含まれるキーワードを見て自動判定する仕組みにしています。「気象・雲・雨・風」といった単語が2つ以上出てくれば "科学＞気象" に、「語源・漢字・日本語」が2つ以上あれば "言語" に、といった単純な多数決です。判定に迷ったら「トリビア」に落とす、というフォールバックも入れています。
ここで大事なのは、カテゴリは既存のものだけを使い、勝手に新しいカテゴリを作らせない、というルールを絶対に守らせていることです。理由はシンプルで、カテゴリを気軽に増やすと、サイト全体の設計がぐちゃぐちゃになるから。カテゴリはブログの本棚の見出しのようなもので、増やすほど読者は「どこに何があるか」が分からなくなる。カテゴリの追加は自分で判断する運営マター、と割り切っています。
タグは逆に、存在しない場合は自動作成OKにしています。タグはカテゴリと違って、記事同士を横串でつなぐキーワード程度の役割。増えすぎても検索性が落ちにくく、必要なら後でまとめれば済むので、自動作成でも実害が少ない。
関連記事は、公開済み記事の中からスコアリング方式で最大3件を選び、記事末尾に自動挿入しています。加点方式は、本文で明示的にリンクを張った記事は最優先、タイトルのテーマ語が似ているものは類似度スコアで加点、同じカテゴリなら少しボーナス、という設計です。本文で言及した記事が必ず関連記事にも出る——ここは読者の回遊性に直結する部分なので、この設計にたどり着いてから内部リンクの効きが目に見えて良くなりました。
投稿の"事故"から学んだこと
投稿処理には、投稿処理ならではの落とし穴があります。実装しながら遭遇したものを、いくつか紹介します。
一つは「二重投稿」。ファクトチェックで修正点を見つけたとき、修正版をもう一度 wp-post.sh に流してしまうと、同じ内容の下書きが2件できあがる。REST APIは「同じスラッグでも別記事として受け付ける」ので、投げれば投げただけ増えます。投稿は最終版で1回だけ、修正が要るなら新規投稿ではなく "更新" のリクエスト（PATCH）を投げ直す、というルールに切り替えたら止まりました。
もう一つは「スラッグの末尾に自動で -2 が付く」現象。WordPressはスラッグが既存記事と衝突していると、勝手に symbol-names-list-2 のような末尾番号を追加してくれます。優しい機能ですが、これが出たときは「同じスラッグの記事が二重に作られている」というサインでもある。投稿後に返ってきたスラッグを毎回確認して、-2 が付いていたら処理を止めるように運用しています。
もう一つは、REST APIの「投稿成功レスポンス」を素直に信じてはいけないケース。APIが 200 OK を返してきても、本番の記事本文を後から取り出してみると、狙った変更が入っていない、ということが実際にありました。理由はいくつか考えられますが、大事なのは 投稿の成否と、内容の反映は別物として扱う という運用姿勢です。だから投稿後は、必ず本番の記事本文をAPIで取り直し、狙った変更が入っているかgrepで確認するまで「完了」とは言わない。
こう並べてみると、どれも「APIが返す OK を鵜呑みにしないこと」が共通の教訓です。序章から言い続けている 公開ボタンだけは自分の指で押す という姿勢は、この投稿処理の実装の中でも同じ形で貫かれています。API任せの部分こそ、最後に人が実データを見に行く。この連載の背骨は、ここでも変わりません。
まとめ
書き終えた原稿がWordPressの下書きになるまでには、REST APIという窓口を叩き、MarkdownをHTMLに変換し、カテゴリ・タグ・関連記事を組み立てるという、いくつもの小さな仕事が挟まっています。ぱっと見は「1コマンドで下書きが増える」だけですが、その内側では、外部と繋がる窓口の作法、変換の下ごしらえ、投稿処理特有の落とし穴への対策が積み上がっています。
次章（第5章）では、記事に添える画像を自動で取ってくる仕組みを掘り下げます。無料画像APIをどう選び、著作権フリーの写真をどうやって記事のテーマに合わせて選ぶか——地味ですが、記事の"顔つき"を左右する大事な工程です。
なお、この章で触れた wp-post.sh や md2html.py の実ファイル・REST APIのエンドポイントや叩き方・カテゴリ判定の具体的な条件表・関連記事のスコア設計については、シリーズがひととおり出そろったところで、まとめて別途公開する予定です。動く形で手元に置きたい方は、その段になったらまた見に来てください。
この記事で使っているツール
レンタルサーバーはWordPress REST APIが標準で使え、WAFの調整も管理画面から簡単にできるエックスサーバーを使っています。
