AI活用

AIでWordPressの下書きを作る|入稿・権限・二重投稿の確認手順

AI原稿をWordPressの下書きへ入れる手順を、権限・投稿ID・画像・表示で確認。公開拒否と失効のローカル実測、二重投稿を避ける照合も紹介します。

この記事の目次
  1. まず、試験用の原稿を下書きへ一件入れる
  2. 下書きの指定と、公開できない権限を分ける
  3. 401・403・404は、応答と操作をセットで読む
  4. Gmailは、記事に使える材料だけを渡す
  5. 画像・アイキャッチ・分類は、登録したIDで結び付ける
  6. 表示の成功と、ブロックの再編集を分ける
  7. 新規作成と更新を、投稿IDで分ける
  8. 確認した版だけを、公開判断へ渡す
  9. 下書き用アカウントの確認票
  10. 次に知りたいこと

AI原稿の自動入稿は、一件の下書きを作り、表示と権限を確かめるところから始めます。原稿の作成、下書きの登録、公開の判断を分けると、誤った内容や二重投稿が公開へ進むのを防ぐ条件を確認できます。

まず、試験用の原稿を下書きへ一件入れる

タイトル、本文、抜粋、原稿IDを固定し、WordPress REST APIの投稿作成へ送ります。投稿状態はAIの回答から受け取らず、登録するコード側でdraftへ固定します。最初は個人情報のない短い原稿を使い、本番へ送る前に許可された検証環境で試してください。

{
  "title": "下書き入稿の確認",
  "content": "<h2>確認する順番</h2><p>まず保存先を確認します。</p>",
  "excerpt": "試験用の原稿です。",
  "status": "draft"
}

作成先はPOST /wp-json/wp/v2/postsです。応答の投稿IDとstatusを保存し、管理画面で同じIDの下書きを開きます。通信が成功した表示だけでなく、登録された本文と状態を確認してください。

スポンサーリンク

下書きの指定と、公開できない権限を分ける

draftを送る設定は、送信内容の制御です。AI用アカウントが公開できないことは、WordPressの権限で別に確認します。Application Passwordも、発行したユーザーの権限を引き継ぐため、管理者のキーを使えば下書き専用にはなりません。

WordPressの標準権限では、Author(投稿者)は自分の記事を公開できます。Contributor(寄稿者)は公開権限を持ちませんが、標準では画像アップロードもできません。画像の登録が必要なら、必要な操作だけを許可する構成を管理者が用意し、成功と拒否の両方を試します。

確認する操作 望む結果 今回のローカル実測
下書き作成 作成でき、draftで保存される 201・draftを確認
publishへ変更 拒否される 限定権限のアカウントで403
他人の記事の変更 拒否される 検証用の別作者の記事で403
画像とaltの登録 必要な場合だけ成功する upload_filesを持つ限定権限で201/200
キー失効後の更新 認証が拒否される 失効させたキーで401

実測は2026年10月10日のDevsローカル環境で、合成原稿と確認用の小画像を使ったHTTP REST試験です。外部AIの文章品質、本番の独自権限、長期運用を保証する結果ではありません。検証用アカウントは試験後に削除しています。

401・403・404は、応答と操作をセットで読む

応答 確認すること
401 認証情報、失効、認証ヘッダーがWordPressまで届くか
403 そのユーザーの操作権限、対象の作者、WAF等の応答元
404 サイトのURL、REST経路、投稿ID、対象の状態

番号だけで原因を一つに決めず、WordPressのエラーcode、送った操作、対象IDを残します。別の保護機能が返すHTMLを、WordPress RESTのJSONと混同しないようにしてください。

Gmailは、記事に使える材料だけを渡す

メール本文を、そのまま公開原稿にしません。利用できる内容を選び、宛先、署名、個人情報、社外へ出せない情報を除き、記事の目的に沿った原稿へ整えます。メールのMessage IDは材料の識別、原稿IDは作る記事の識別として分けます。

同じメールを別の記事へ使う場合もあるため、Message IDだけを投稿の一意キーにしないでください。添付画像は、保存できたこととは別に、掲載してよい画像か、必要な内容だけが写っているかを確認します。

画像・アイキャッチ・分類は、登録したIDで結び付ける

画像はメディア登録の応答IDを保存し、altを画像の役割に合わせて設定します。アイキャッチを使う場合は投稿のfeatured_mediaへメディアIDを渡します。本文内の画像とアイキャッチは別の指定なので、両方を確認してください。

カテゴリとタグも、対象サイトの既存項目とIDの対応を先に作ります。表示名が同じ別項目や、別サイトのIDを流用しないようにします。新しい分類を作る判断は、入稿の自動処理へ任せず編集方針として決めます。

表示の成功と、ブロックの再編集を分ける

通常のHTMLをRESTへ送って表示できても、見出しや表が個別のブロックとして編集できるとは限りません。ブロック形式を使う場合も、見出し、表、画像、テーマ固有の部品を同じ原稿で確認します。

崩れた場合は、AIの原稿、変換後のHTML、WordPressに保存された本文、実際の表示を並べます。どの段階で変わったかを確かめてから直してください。方式の比較は入稿と残る手作業の比較票へ分担します。

新規作成と更新を、投稿IDで分ける

新しい記事は作成の応答IDを保存し、既存の記事は保存済みIDの更新へ送ります。原稿ID、版、送信した内容のhash、投稿ID、登録結果を対応させると、別の記事を更新する取り違えを調べやすくなります。

「同じslugがないか検索してから作成」だけでは、同時送信の競合を防げません。保存直後に通信が切れた場合も、作成できなかったと決めてPOSTを繰り返さず、登録先の結果を照合します。結果を確定できなければ確認待ちにし、むやみに再送しない設計にします。

WordPress標準の投稿作成APIが、独自の冪等キーで必ず一回だけ処理する契約を持つとは想定しません。受信側のキーと保存の設計は同時送信・通信断・再起動の検査で確認できます。

確認した版だけを、公開判断へ渡す

公開を担当する人へ、投稿ID、原稿の版、表示で確認した点、未確認の項目を渡します。確認後に本文が変わったら、古い承認で新しい版を公開しないよう、版を照合します。誰が公開を承認したかは、実際の判断を記録してください。

下書き用アカウントの確認票

入力内容は送信されません。残したい記録はCSVで保存してください。

条件を入力すると、ここに結果が出ます。

確認票では「下書き作成」「公開拒否」「他人の記事変更拒否」「画像」「表示」「失効」を別行で残せます。一件の試験が通ったら、対象のテーマや権限が変わったときに何を再確認するかも記録します。公開前の内容確認は原稿の公開前チェックリストへ進めます。

スポンサーリンク