WordPress REST APIで記事を自動化する方法｜取得・下書き・更新・公開の安全設計

WordPress REST APIは、管理画面を開かずに投稿・固定ページ・メディア・カテゴリなどをHTTP経由で扱うための標準APIです。AI専用機能ではなく、n8n、独自スクリプト、社内ツール、モバイルアプリなどからWordPressを操作する共通の入口として使えます。

僕は複数サイトで、投稿一覧の取得、draft作成、既存投稿の更新、publishまでをREST API経由で確認してきました。実際に運用して分かったのは、API自体より「どの投稿を、どのフィールドだけ、どの条件で変更するか」を先に決める方が重要だということです。

まず覚えるのは /wp-json/wp/v2/posts と「読む・作る・変える」の3操作

WordPressのPosts endpointでは、投稿ごとにid、slug、status、date、modified、linkなどのフィールドを扱えます。外部システム側は「記事名」ではなくidを保持しておくと、タイトル変更後も同じ投稿を追跡できます。slugはURL整合性の検査に使い、IDとslugの両方が期待値と一致しない場合は停止する設計が安全です。

投稿を読む・作る・更新する

最初はGETだけで「WordPressの現在地」を取る

最初の自動化で書き込み権限は不要です。公開済み、draft、更新日時、featured image、カテゴリなどを取得し、手元の台帳と一致するかを確認するだけでも管理画面を巡回する回数を減らせます。大量の記事を扱うときはページネーションを考慮し、必要なフィールドだけを取得して処理量を抑えます。

ここで重要なのは、取得結果をそのまま「正しい」と決めつけないことです。たとえばWordPress上に古いdraftやテスト投稿が残っていることがあります。取得結果から公開候補を決めるのではなく、許可したpost IDやslugのリストと照合する方が、TBOS TESTのようなテスト用draftを誤って扱う事故を防げます。

新規記事は公開ではなくdraftから始める

新規投稿のPOSTでは、title、content、statusなどを送れます。自動化の初期段階はstatus=draftに固定し、WordPress管理画面で表示・表・リンク・画像・SEO設定を確認してから公開する流れが向きます。本文生成の品質が高くても、Cocoon側の装飾や表の横幅までAPIレスポンスだけで完全には確認できません。

draft作成時には、外部システム側で一意な処理IDを持ち、同じジョブが再実行されても新しい記事を作らない工夫も必要です。WordPressの標準投稿APIに「あなたの業務上の重複防止キー」が自動で付くわけではないため、slug照合や独自meta、外部DBのjob IDなどで二重作成を防ぎます。

既存記事の更新は「post ID固定＋変更フィールドのホワイトリスト」

既存記事を更新するときは、取得したIDを指定し、変更してよいフィールドだけ送ります。本文だけ直す処理でslugやstatusまで毎回送る必要はありません。送信項目が増えるほど、意図していない差分を作る可能性も増えます。

僕なら更新前にtitle、content、excerpt、slug、status、taxonomy、SEO meta、featured imageの現在値をsnapshotへ保存します。そのうえで「更新前→更新後」の差分を記録し、QAに失敗したらsnapshotへ戻します。API更新を使うメリットは、速さだけでなく、この差分と復旧処理を標準化しやすいことです。

認証はApplication Passwordを連携ごとに分離する

外部から認証が必要なREST APIへアクセスする場合、WordPressはApplication Passwordを利用できます。通常のログインパスワードを自動化ツールへ保存する必要がなく、連携ごとに発行・失効できます。使い方と安全管理は123で詳しく解説します。

401・403・400系を全部「再試行」にしない

「失敗したら3回再試行」は通信障害には有効でも、認証ミスやデータ不整合には逆効果です。更新リクエストがタイムアウトした場合は、再送前に対象投稿を再取得し、すでに変更が反映されていないか確認します。これをしないと、画像アップロードや新規作成のような操作で重複が起きます。

メディア・カテゴリ・タグは本文と別の失敗点になる

記事を「完成状態」で作る場合、本文以外にfeatured image、ALT、カテゴリ、タグ、SEO metaがあります。画像アップロードが成功してもfeatured image設定に失敗する、カテゴリ名が存在しない、SEOプラグイン/テーマのmeta keyが違う、といったズレが起こります。1回の巨大な処理にせず、各工程の成功結果を検証して次へ進みます。

特にSEO metaはWordPress標準のフィールドではなく、テーマやSEOプラグイン側の保存方法に依存する場合があります。TameshiTechのようにCocoon固有のmetaを扱うなら、実サイトで使っているkeyを固定し、更新後にget_post_meta相当で値を読み直して一致を検証する必要があります。

REST API運用で最低限残したいログ

• 対象サイトとpost ID/slug
• 実行時刻とジョブID
• 変更前後のフィールド差分
• HTTP statusとWordPressのerror code/message
• 作成したattachment ID
• QA結果と公開可否
• rollbackを実行したか、その結果

ログにApplication PasswordやAPI keyなどの秘密情報を出さないことも重要です。トラブル時に欲しいのは「どのcredentialそのものか」ではなく、どの連携名・どのユーザー・どの操作経路で実行したかを追跡できる識別情報です。

n8nを使う場合もREST APIの安全設計は同じ

n8nならHTTP RequestやWordPress連携ノードで処理を組みやすくなりますが、WordPress側の権限や重複防止が自動で解決するわけではありません。n8nの便利さは処理をつなぐところにあり、post ID照合、draft固定、公開ゲート、失敗通知は別途設計します。

再試行を安全にするには、workflow側でjob ID、対象post ID、想定slug、変更fieldをmanifestとして残します。同じjobがtimeout後にもう一度走ったときは、再送前に現在の投稿状態を読み直し、既に同じ変更が反映されていれば新しいPOSTを送らず終了します。HTTP requestの再送回数だけを設定するより、処理全体をidempotentに近づける方が二重投稿を防ぎやすくなります。

コードを書きたくない人はn8nから始めても構いません。逆に複数サイトで同じQAやrollbackを厳密に再現したい場合は、共通ロジックを独自APIや管理基盤へ寄せた方が管理しやすいケースがあります。どちらを選んでも、WordPressへ書く直前の安全条件は共通です。

公式情報・参考資料

仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。

• https://developer.wordpress.org/rest-api/
• https://developer.wordpress.org/rest-api/reference/posts/
• https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/

あわせて読みたい

• Application Passwordの安全な使い方
• AI・API自動化のセキュリティ
• WordPressをAIで自動化する方法
• n8nでWordPressを自動化する方法