WordPress REST APIで下書き投稿を作る方法。最小リクエストと認証の流れを実務向けに整理

WordPress REST APIで下書き投稿を作るなら、まず押さえる点はシンプルです。外部ツールやスクリプトから POST /wp/v2/posts に送信し、status を draft にする。これが基本です。

実務では、記事生成ツールから下書きだけを自動作成したい場面や、社内システムから投稿案をWordPressへ積みたい場面でよく使います。公開まで自動化せず、編集者が最終確認できる形に止められるのが大きな利点です。

• できること: WordPressに下書き投稿を自動作成できる
• よく使う場面: 外部CMS連携、記事生成ツール、社内ワークフロー、自動下書き保存
• 基本の要素: 投稿エンドポイント、認証、JSON本文、status=draft
• 外部アクセスの定番認証: Application Passwords

ここがポイント: 外部プログラムからWordPress REST APIを使う場合、まずは Application Passwords で認証し、/wp-json/wp/v2/posts に title、content、status を送る形から始めるのが安全です。

まず確認したい前提環境

先に前提を整理します。ここが曖昧だと、401 や 403 で止まりやすくなります。

• 対象: WordPress REST APIで「投稿」を作成したいケース
• 想定環境: WordPress 5.6以降
• 認証方法: 外部スクリプトからは Application Passwords を利用
• 送信先: https://あなたのサイト/wp-json/wp/v2/posts
• 送信形式: JSON

WordPress公式ドキュメントでは、投稿作成エンドポイントは POST /wp/v2/posts です。作成時に status として draft を指定できます。つまり、公開記事ではなく下書きのまま保存する動きは、特別な裏技ではなく標準機能です。

また、認証方式は使う場所で分かれます。

外部スクリプトなら Application Passwords が基本

同一サイト内の管理画面やテーマ・プラグインから叩くならCookie認証と X-WP-Nonce が基本ですが、PythonやNode.js、CLIツールのような外部プログラムから呼ぶなら、Application Passwordsを使う方が自然です。

WordPress公式の認証ガイドでも、外部アクセスではApplication Passwordsを使ったBasic Authが案内されています。さらに、旧来のBasic Authenticationプラグインは開発・テスト向けで、本番ではApplication Passwordsが推奨です。

基本リクエストの流れ

全体像は4段階で理解すると迷いにくくなります。

1. Application Passwordを発行する

WordPress 5.6以降では、ユーザーごとにApplication Passwordを発行できます。通常はユーザー編集画面から発行します。

ここで注意したいのは、外部ツールに普段のログインパスワードを渡さないことです。用途ごとにApplication Passwordを分ければ、不要になった資格情報だけを失効できます。

2. 投稿エンドポイントを確認する

投稿作成先は次のURLです。

https://example.com/wp-json/wp/v2/posts

このエンドポイントに POST します。

3. 必要な項目をJSONで送る

最小構成なら、次の3つで動かしやすいです。

• title: 投稿タイトル
• content: 本文
• status: draft

必要に応じて、以下も追加できます。

• slug: URL用の識別子
• excerpt: 抜粋
• categories: カテゴリーID配列
• tags: タグID配列
• featured_media: アイキャッチ画像のメディアID

ここで大事なのは、カテゴリ名やタグ名ではなくIDが必要な項目があることです。実務で自動連携するときは、事前にIDを取得しておく設計にすると詰まりにくくなります。

4. レスポンスで作成結果を確認する

成功すると、作成された投稿のJSONが返ります。id、link、status、slug などが入るので、次の処理に使えます。

たとえば、こんな確認ができます。

• status が draft になっているか
• id を控えて後続の更新処理に渡せるか
• link や slug が期待どおりか

最小のcURL例

まずはcURLで一度成功させると、後でPythonやNode.jsに移すのが楽です。

curl --user "USERNAME:APPLICATION_PASSWORD" \
  -X POST "https://example.com/wp-json/wp/v2/posts" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "REST APIから作った下書き",
    "content": "<p>これはAPI経由で作成した下書きです。</p>",
    "status": "draft"
  }'

この例でやっていることは単純です。

• --user でユーザー名とApplication Passwordを送る
• JSON本文に投稿内容を入れる
• status を draft にして公開を防ぐ

最初の検証では、余計な項目を増やさずこの形で通すのが実務的です。タイトル、本文、状態だけなら、失敗原因を切り分けやすくなります。

Pythonで下書きを作る最小例

業務スクリプトに載せるなら、Pythonの requests でも十分扱えます。

import requests
from requests.auth import HTTPBasicAuth

url = "https://example.com/wp-json/wp/v2/posts"
username = "your-user"
app_password = "xxxx xxxx xxxx xxxx xxxx xxxx"

payload = {
    "title": "Pythonから作る下書き投稿",
    "content": "<p>本文を自動投入します。</p>",
    "status": "draft"
}

response = requests.post(
    url,
    json=payload,
    auth=HTTPBasicAuth(username, app_password),
    timeout=30,
)

print(response.status_code)
print(response.json())

入力例

{
  "title": "Pythonから作る下書き投稿",
  "content": "<p>本文を自動投入します。</p>",
  "status": "draft"
}

返ってくるデータの見方

レスポンスには多くの項目が含まれますが、最初に見るべきなのは次のあたりです。

• id: 投稿の管理用ID
• status: draft になっているか
• slug: 自動生成または指定したスラッグ
• date / modified: 作成・更新時刻
• link: 投稿URL

自動化の次工程で必要になりやすいのは id です。たとえば後から本文差し替え、カテゴリー付与、公開切り替えを行うなら、このIDを保存しておくと処理をつなげやすくなります。

実務で使うときの典型パターン

APIで下書きを作る目的は、単に投稿を増やすことではありません。公開前の確認フローを残したまま入力作業を減らすことにあります。

生成系ツールの出力先にする

AIやテンプレート処理で本文を作る場合、いきなり公開すると事故が起きやすいです。まず下書きで保存すれば、編集者がWordPress上でチェックできます。

向いている場面は次のとおりです。

• 定型記事のドラフト生成
• 商品情報やお知らせ文の初稿投入
• 社内データベースからの定期的な投稿案作成

フォームや社内システムとつなぐ

問い合わせフォームや業務システムの入力内容を、そのまま投稿下書きに変える使い方もあります。

たとえば、現場担当が入力した内容をWordPressへ下書き送信し、広報や運営担当が管理画面で仕上げる流れです。メール転記よりミスが減り、誰がどこまで作業したかも追いやすくなります。

よくある失敗と対処

ここは初心者が詰まりやすい部分です。原因が分かると対処はそれほど難しくありません。

401 Unauthorized になる

主な原因は次のどれかです。

• ユーザー名またはApplication Passwordが違う
• HTTPSでアクセスしていない
• Application Passwordsが無効化されている

WordPress公式のApplication Passwordsガイドでは、既定ではSSL/HTTPS環境で利用できるとされています。まず https:// でアクセスしているかを確認してください。

403 Forbidden になる

認証自体は通っていても、投稿を作る権限がないと失敗します。

確認ポイントは次のとおりです。

• 対象ユーザーに投稿作成権限があるか
• カスタム権限設定や会員系プラグインで制限されていないか
• セキュリティプラグインやWAFがAPI書き込みを止めていないか

rest_cannot_create が返る

これは「そのユーザーでは作成できない」という意味で出ることが多いエラーです。認証情報の問題というより、権限の問題として見る方が早いです。

categories や tags で失敗する

自動連携でよくあるのが、名称をそのまま送ってしまうケースです。投稿エンドポイントでは、カテゴリーやタグはID指定が基本です。

先にカテゴリー・タグを取得し、必要なら別エンドポイントで作成してから投稿へ紐づける流れにすると安定します。

認証情報の安全な扱い

API連携ではここを雑にしない方がいいです。便利でも、運用で崩れると危険です。

• Application Passwordをソースコードへ直書きしない
• 環境変数やシークレット管理に分離する
• 用途ごとに別のApplication Passwordを発行する
• 不要になったらユーザー画面から失効する
• 本番では通常のログインパスワードを使わない

WordPress公式でも、外部アクセスではApplication Passwordsの利用が前提です。古いBasic Authenticationプラグインは、本番用途では避けた方が安全です。

Cookie認証との使い分け

同じREST APIでも、使う場所で最適な認証は変わります。

外部ツールから呼ぶ場合

• Python
• Node.js
• バッチ処理
• CI/CD
• 他システム連携

この場合は Application Passwords が基本です。

WordPress管理画面内で動かす場合

• 管理画面の独自JavaScript
• プラグイン設定画面からのAjax
• ブロックエディタ周辺の拡張

この場合は Cookie認証 + X-WP-Nonce が基本です。

同じAPIでも、認証を混同すると動かない理由が見えにくくなります。外から叩くのか、WordPress内部で叩くのかを最初に分けて考えると整理しやすいです。

代替手段はあるか

下書き作成だけが目的なら、REST API以外にも方法はあります。ただし、それぞれ向き不向きがあります。

REST APIが向くケース

• 外部ツールから投稿を作りたい
• JSONで連携したい
• 将来的に更新、画像アップロード、公開切り替えまで広げたい

XML-RPCやプラグイン連携が向くケース

• 古いシステムとの互換性が必要
• 既存プラグイン前提の運用を変えにくい

ただ、今から新規で組むなら、拡張性と保守性の面でREST APIを優先しやすいです。WordPress公式の案内も、現在のAPI利用はREST API中心です。

最初の実装で押さえたいチェックリスト

最後に、最小構成で動かすための確認項目をまとめます。

• サイトURLが https:// になっている
• WordPressユーザーでApplication Passwordを発行済み
• 送信先が /wp-json/wp/v2/posts になっている
• POST で送っている
• Content-Type: application/json を付けている
• JSON本文に title、content、status: draft がある
• 投稿作成権限のあるユーザーを使っている
• 認証情報をコードに直書きしていない

ここまで通れば、次はカテゴリー付与、アイキャッチ設定、公開切り替え、自動更新へ段階的に広げられます。最初から全部盛りにせず、まず下書き1件を確実に作るところまで切り分けるのが失敗しにくい進め方です。

参照リンク

• WordPress REST API Handbook: Posts
• WordPress REST API Handbook: Authentication
• WordPress REST API Handbook: Application Passwords
• Make WordPress Core: Application Passwords Integration Guide
• WordPress REST API Handbook: Statuses
• WordPress REST API Handbook: Reference