WordPress に記事を自動投稿する構成を、実際に組んで運用したうえでの記録です。REST API とアプリケーションパスワードの組み合わせ、アイキャッチとカテゴリ・タグの扱い、そして初期投入で wp-cli に切り替えた理由までをまとめます。
結論:投稿の口は REST API、認証はアプリケーションパスワード
WordPress の記事投稿を自動化する場合、投稿先は /wp-json/wp/v2/posts です。ここに POST すれば記事が作れます。管理画面をブラウザで操作する必要はありません。
問題は認証です。認証にはアプリケーションパスワードを使い、管理画面のログインパスワードは使いません。自動化スクリプトの中に管理画面のログインパスワードを置くのは、そもそも用途が違います。アプリケーションパスワードは用途ごとに発行して、要らなくなったらその一本だけ止められる、という前提の仕組みです。
スクリプトに書くのはアプリケーションパスワードです。ログインパスワードを埋め込む構成にしないでください。
アプリケーションパスワードの発行
wp-cli が使える環境なら、コマンド一発で発行できます。
wp user application-password create ユーザー名 用途名 --porcelain
--porcelain を付けると発行された値だけが返るので、そのまま変数に受けて設定ファイルへ流し込めます。用途名を分けておけば、後から「どのスクリプト用の鍵か」が分かります。
アイキャッチ画像は「先にアップロード」する
ここは最初につまずきやすいところです。記事の POST に画像そのものを混ぜて投げることはできません。画像は先に /wp-json/wp/v2/media へアップロードし、返ってきた media_id を記事側に渡す、という二段構えになります。
/wp-json/wp/v2/mediaに画像をアップロードする- レスポンスから media_id を取り出す
/wp-json/wp/v2/postsへの投稿時に、その media_id を渡す
つまり自動投稿スクリプトは、必ず2回以上 API を叩く構造になります。1リクエストで完結する想定で組むと、途中で作り直しになります。
カテゴリとタグは「名前」では渡せない
記事の投稿時に、カテゴリやタグを文字列で指定することはできません。渡すのは ID です。ですから、自動投稿の前に必ず次のどちらかが必要になります。
- 既存のカテゴリ・タグの ID を事前に取得しておく
- 存在しない場合は先に作成して、その ID を取得する
運用してみて分かったのは、この「無ければ作る」の分岐を最初から入れておかないと、記事は投稿できているのにカテゴリだけ付いていない、という中途半端な状態が生まれることです。
カテゴリ・タグはID を渡す仕様です。名前で渡す前提で組むと、記事本体だけが投稿されて分類が抜け落ちます。
初期投入は wp-cli のほうが早い
すでに手元に記事の HTML がまとまってある、という状態からの初期投入なら、REST API より wp-cli のほうが速いです。
wp post create ファイル名.html --post_title=...
これで投稿できます。既存記事をまとめて入れる最初の一回は wp-cli、そこから先の継続的な自動投稿は REST API、という使い分けが実務的でした。
| 用途 | 向いている方法 |
|---|---|
| 手元の HTML をまとめて初期投入 | wp-cli の wp post create |
| 継続的な自動投稿 | REST API /wp-json/wp/v2/posts |
初期投入を REST API で全部やろうとせず、wp-cli に寄せたことで立ち上げが早く終わりました。API 側は「これから増える記事」だけを担当させています。
ハマったところ
日本語タイトルのパーマリンクが異常に長くなる
パーマリンク設定を「記事名」にしていると、日本語タイトルがそのままスラッグになり、URL エンコードされて非常に長い URL になります。自動投稿でタイトルを機械的に入れていると、これが全記事に発生します。
対策は、英語のスラッグを別途設定することです。自動投稿の側で、タイトルとは別にスラッグを持たせる設計にしておく必要があります。ここは後から一括で直すと手間になるので、最初から組み込んでおいたほうが良い部分です。
タイトルだけ渡してスラッグを指定しなかった結果、日本語がエンコードされた長大な URL の記事ができました。スラッグは自動投稿の必須項目として扱うべきでした。
.htaccess が無くて固定ページが 404 になる
もうひとつは、環境構築側の話です。wp core install の直後に .htaccess が作られないことがあります。この状態だと、固定ページが 404 になります。
原因が分かるまでは「投稿は成功しているのにページが見えない」という状態に見えるので、API 側を疑ってしまいがちでした。実際には .htaccess を手で作れば直ります。自動投稿の不具合ではありませんでした。
この構成で何ができて、何ができないか
- REST API で記事本文を投稿する
- アイキャッチ画像をアップロードして記事に紐付ける
- カテゴリ・タグを ID で指定する(無ければ作成する)
- wp-cli で既存 HTML をまとめて初期投入する
- 1回のリクエストで画像ごと投稿する
- カテゴリ・タグを名前のまま渡す
- タイトルだけ渡して、まともな URL のスラッグを期待する
なお、長期運用でどこが壊れやすいのか、どのくらいの頻度でトラブルが起きるのかについては、まだ十分なデータがありません。現時点で確実に言えるのは、上に書いた「詰まった箇所」とその回避方法までです。
- 投稿先は
/wp-json/wp/v2/posts、認証はアプリケーションパスワード。ログインパスワードは使わない - 発行は
wp user application-password create ユーザー名 用途名 --porcelainが早い - アイキャッチは
/wp-json/wp/v2/mediaに先にアップし、media_id を記事に渡す二段構え - カテゴリ・タグは ID 渡し。無ければ作成してから ID を取得する
- 初期投入は
wp post create ファイル名.html --post_title=...のほうが速い - パーマリンクが記事名だと日本語がエンコードされて長くなるので、英語スラッグを別途指定する
wp core install直後に.htaccessが無いと固定ページが 404 になる。手で作れば直る


