WordPress REST APIでブログ自動投稿を組む実装ガイド。Application Password認証で最初にハマる場所と対処法

結論:認証は「発行」ではなく「疎通確認」を最初にやる

WordPressのブログ自動投稿を内製で組みたいという相談が増えている。AIで記事本文を作れるようになった分、「作った記事をWordPressへ流し込むところ」がボトルネックになっているからだ。

やり方自体はシンプルだ。WordPressのREST API(`/wp-json/wp/v2/posts`)にHTTPのPOSTを投げるだけで、投稿・カテゴリ・タグ・アイキャッチ画像の設定まで自動化できる。認証にはWordPress標準の「アプリケーションパスワード(Application Password)」を使う。ユーザー名とアプリケーションパスワードをBase64化し、`Authorization: Basic ~` ヘッダーに乗せて叩けばよい。

ただし実務でこの仕組みを組むとき、最初にやるべきことは「アプリケーションパスワードを発行して、すぐ投稿APIを叩く」ことではない。先に**疎通確認専用のチェック(ヘルスチェック)を1本作り、認証だけを単独で検証する**ことだ。

理由は単純で、自動投稿がうまくいかないとき、原因は次の3種類のどれかに分かれるが、いきなり投稿APIを叩くとこの3つが混ざって切り分けに時間がかかるからだ。

1. WordPress側の権限・設定の問題(ユーザー権限、プラグインの制限)

2. サーバー側の問題(Authorizationヘッダーがそもそも WordPress まで届いていない)

3. 実装側の問題(投稿ペイロードの形式、カテゴリ・タグID、画像アップロードの処理)

先に1と2だけを切り出して確認できる仕組みを作っておけば、3の実装作業に集中できる。これが結論であり、以下は実際にこの順番で構築した際の記録と、判断基準の具体化だ。

実例:自社ブログの自動投稿基盤を構築した際の記録

自社(graciauto)のブログ運用でも、この自動投稿の仕組みを2026年5月から実際に構築・運用している。Claude Codeで作業ログやセッション内容からSEO記事を組み立て、WordPressへ流し込むパイプラインだ。構築時に実際に起きたことを時系列ではなく「何が起きうるか」という観点で整理する。

まず、WordPress側の公開REST API(投稿一覧取得・カテゴリ取得・タグ取得)は最初から正常に動いていた。ここまではAPIキーも認証も不要なので当然といえば当然だが、「読み取り系のAPIが動く=書き込み系の認証も通る」わけではない、という点が最初の落とし穴になる。

実際、投稿系のAPIを認証付きで叩いた際に返ってきたのは次の2種類のエラーだった。

`401 rest_not_logged_in`(現在ログインしていません)
`401 rest_cannot_create`(このユーザーとして投稿を編集する権限がありません)

これらのエラーメッセージは紛らわしい。「ログインしていません」と表示されるが、実際にはアプリケーションパスワード自体は正しく発行されており、WordPress側の `authentication.application-passwords` 機能も有効になっていた。つまりエラーメッセージが指している原因と、実際の原因が一致しないケースがある、というのが実務上の学びだ。

この状態から切り分けを進めた結果、疑うべきポイントは大きく2つに絞られることが分かった。

1つ目は、サーバー環境によってはPHPまで `Authorization` ヘッダーがそもそも渡っていないケースがあるということ。CGI/FastCGIで動くApache系のレンタルサーバーでは、`.htaccess` に以下の設定を追加しないと、Basic認証用のヘッダーがWordPressに届かない場合がある。

“`apache

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

“`

うまくいかない場合の候補として、以下のRewriteRuleも合わせて検討する価値がある。

“`apache

RewriteEngine On

RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

“`

2つ目は、アプリケーションパスワードの再発行時に生じるヒューマンエラーだ。パスワードのコピー時にスペースの有無で表記が変わって見えることや、対象ユーザーの権限が「投稿者」未満(購読者など)になっていて、そもそも投稿作成権限がないケースがある。この場合はエラーメッセージが認証エラーのように見えても、実際は権限不足が原因になる。

最終的にこの案件では、ユーザー権限を「管理者」で再確認したうえで新しいアプリケーションパスワードを発行し直し、疎通が取れる状態まで持っていった。重要なのは、「エラーメッセージだけで原因を決め打ちしない」「サーバー側・WordPress側・実装側を分けて1つずつ確認する」という進め方そのものだ。

手順:実装する際の判断基準

これから同じ仕組みを組む人向けに、実装の手順と、各ステップでの判断基準を整理する。

ステップ1: 投稿権限のあるユーザーでアプリケーションパスワードを発行する

WordPress管理画面のユーザー編集画面から、対象ユーザーの権限が「投稿者」「編集者」「管理者」のいずれかであることを確認したうえで、アプリケーションパスワードを発行する。運用の都合上は管理者ユーザーで発行しておくと、カテゴリ・タグ・アイキャッチ画像アップロードまで一通りの操作を1つの認証情報でまかなえる。

ステップ2: 投稿APIを叩く前に、疎通確認だけを行う

`/wp-json/wp/v2/users/me?context=edit` に対して、ユーザー名とアプリケーションパスワードをBase64化した `Authorization: Basic ~` ヘッダーを付けてGETする。ここで200が返り、ユーザー名と権限(roles)が取得できれば認証は成立している。401が返る場合は、次のチェックリストへ進む。

ステップ3: 401が返った場合のチェックリスト

対象ユーザーの権限が投稿可能な権限になっているか
セキュリティ系プラグイン(ログイン制限・REST API制限系)がREST APIやアプリケーションパスワード認証をブロックしていないか
サーバーが `Authorization` ヘッダーをWordPressまで渡しているか(上記の `.htaccess` 設定で解決するケースがある)
アプリケーションパスワードを再発行し、コピー時の空白・改行が混入していないか

この4点を1つずつ潰していけば、多くの場合は解決する。逆にここを飛ばして投稿APIの実装(タイトル・本文・カテゴリ・アイキャッチ画像アップロードのロジック)を先に組んでしまうと、401が返ったときに「どの工程が原因か」の切り分けに時間がかかる。

ステップ4: 投稿ペイロードを組み立てる

疎通確認が取れたら、投稿API(`/wp-json/wp/v2/posts`)にPOSTするペイロードを組み立てる。最低限必要なのは以下の項目だ。

`title`(タイトル)
`content`(本文。MarkdownからHTMLへの変換が必要)
`status`(`draft` か `publish`)
`slug`(URLスラッグ)
`categories` / `tags`(あらかじめIDを設定ファイルで固定管理しておく)
`featured_media`(アイキャッチ画像のメディアID。先に画像をメディアライブラリへアップロードしてIDを取得する)

カテゴリ・タグはWordPress側のIDが変わらない前提で、設定ファイル側に固定値として持たせておくと運用がぶれない。名前で毎回検索する実装にすると、表記ゆれで意図しないカテゴリが付く事故につながる。

ステップ5: アイキャッチ画像は生成方式にも判断基準がある

自動投稿の仕組みを作ると、アイキャッチ画像も自動生成したくなる。ここで起こりやすいのが、画像生成AIに文字入りの完成画像までまるごと作らせる方式にすると、背景・文字・ロゴのバランスが記事ごとにばらつき、ブランドとしての統一感が崩れるという問題だ。

これを避けるための判断基準は、「背景」「文字・タイトル」「ロゴ」の生成工程を分けることだ。あらかじめ用意した高品質な写真素材を背景に使い、その上にタイトルとロゴをテンプレートで合成する方式にすると、記事が増えても見た目の統一感を保てる。実装上は、素材フォルダの参照パスをユーザー環境非依存にしておく(ホームディレクトリ基準にする、環境変数で上書きできるようにする)ことで、複数の端末で同じ仕組みを使い回せるようにしておくと運用が安定する。

ステップ6: 本番投稿の前に必ずdraftで確認する

status を `publish` に固定してテストするのではなく、まずは `draft` で投稿し、WordPress管理画面で表示崩れ・カテゴリ・タグ・アイキャッチを目視確認してから、`publish` に切り替える運用にする。自動化の最終ゴールが予約投稿・即時公開だとしても、導入初期はdraft運用を経由したほうが事故を防げる。

まとめ

WordPress REST APIでブログ自動投稿を組む際の急所は、実装そのものよりも「認証の疎通確認を独立して検証できる状態を先に作ること」にある。エラーメッセージが指している原因(ログインしていない、権限がない)と、実際の原因(サーバーがヘッダーを渡していない、パスワード再発行時のヒューマンエラー)がずれるケースがあるため、WordPress側・サーバー側・実装側を分けて1つずつ確認する進め方が結果的に一番早い。

疎通確認さえ取れれば、投稿ペイロードの組み立てやアイキャッチ画像の自動化は通常の実装作業として進められる。逆に言えば、自動投稿の内製化を検討している店舗・企業の担当者は、まず自社のWordPress環境でこの疎通確認(ユーザー情報取得APIの200/401)だけを先に試してみることをおすすめする。ここが通れば、あとの自動化は着実に積み上げられる。