WordPress下書き一括作成｜件数と重複の安全確認

WordPressの下書きを一括作成する前は、送信前の一覧、1件の試験、保存結果の照合、再実行の条件をそろえます。下書き指定だけで大量に送ると、途中停止や保存内容の違いを追いにくくなります。

本文CSVから確認用の計画を作るPythonコードと、WordPress REST APIへ進む前後の安全確認を紹介します。コードはWindows 11とPython 3.12で架空の原稿に対して実行しています。WordPressへの作成・更新・削除は行っていません。

WordPress下書き一括作成｜最初に決める対象

同じ一括処理でも、新しい下書きの作成と既存記事の更新は影響が違います。まず今回の操作と対象サイトを固定します。

• 作成と更新の区別
• 対象件数と停止条件

新規下書きと既存記事更新の区別

新しい投稿はPOST /wp-json/wp/v2/postsで作成し、既存投稿への更新はID付きのURLを使います。公式仕様ではstatusにdraftを指定できます。既存記事を下書きへ戻す操作は、新規作成とは別に扱います。

公開済みの記事をレビューしたいだけなら、元記事をdraftへ変えて確認する流れにはしません。新規に作る一覧と変更するIDが混ざらないようにします。この記事の確認コードは新規下書き用の計画だけを作ります。

件数上限と一時停止の基準

CSVに入っているすべてを無制限に送るのではなく、対象件数を先に数えます。試験は一件、その後は確認できる小さな単位に分けます。一回何件までとするかは、サイトと確認担当の負荷に合わせて決めます。

• 送り先のサイトURLと投稿の種類が正しい
• 作成予定件数と原稿の一覧が一致している
• 状態はdraftで、公開や予約の指定がない
• 不一致、認証失敗、上限超過、タイムアウトで止まる
• 保存結果を読む担当者と再開を決める人がいる

下書きでも、プラグインや外部連携が保存をきっかけに動く場合があります。検証用サイトでの確認を先に行い、本番で副作用の有無を探さないようにします。

WordPress下書き一括作成｜原稿と重複の点検

送信に進む前に、入力の識別子と本文ファイルを対応させます。投稿タイトルだけでは同名の記事を区別できません。

• 原稿の識別子
• 本文と設定の確認

source_id・slug・本文の対応

原稿ごとに変わらないsource_idを付け、slugと本文ファイルの場所を記録します。タイトルを修正しても識別子が変わらなければ、前回処理した原稿かを確認できます。

slugが重複したとき、WordPress側で期待と異なるslugになることがあります。送信前の一覧と、保存後に返ったID・slugを必ず対応させます。slugだけに二重作成の防止を任せないようにします。

本文と下書き指定の確認

タイトルと本文が空でないか、別の記事の本文を参照していないかを点検します。ファイルのハッシュ値を残すと、送信時と照合時に本文が変わっていないかを比較できます。ただし、ハッシュは内容の正しさを確認するものではありません。

カテゴリ、タグ、著者、画像も必要なら明示して一覧で確認します。本文にAI出力を使う場合は、事実やリンクの校正を終えてから計画へ入れます。未確認の本文を下書きだからと大量保存しないようにします。

認証にはHTTPSと利用できるアプリケーションパスワードなど、公式資料が案内する方法を選びます。通常のログイン用パスワードをコードやCSVへ書き込まないようにします。

WordPress下書き一括作成｜送信しない計画コード

下のコードはローカルの入力を点検してplan.jsonを作るだけです。APIキーも通信ライブラリも使いません。

• 入力ファイル
• 計画作成のコード

二件の架空原稿とCSV

新しい作業フォルダーにarticlesフォルダーを作り、a.htmlとb.htmlを保存します。まずは次の架空の短い本文を使います。

articles/a.html
<p>架空の記事Aの本文です。</p>

articles/b.html
<p>架空の記事Bの本文です。</p>

同じ作業フォルダーへdrafts.csvをUTF-8で保存します。content_fileはarticles内から見たファイル名です。

source_id,title,slug,content_file
A001,確認用の記事A,example-draft-a,a.html
A002,確認用の記事B,example-draft-b,b.html

重複と空本文を止める処理

次をdraft_plan.pyとして保存し、python draft_plan.pyを実行します。全行の確認が終わるまで計画を保存しないため、不正な行があれば出力前に止まります。

import csv
import hashlib
import json
import re
from pathlib import Path

base = Path("articles").resolve()
seen_keys, seen_slugs, plan = set(), set(), []
with open("drafts.csv", encoding="utf-8-sig", newline="") as f:
    for line, row in enumerate(csv.DictReader(f), 2):
        key, slug = row["source_id"].strip(), row["slug"].strip()
        title = row["title"].strip()
        if not key or key in seen_keys:
            raise ValueError(f"source_idの欠損または重複: {line}行目")
        if not re.fullmatch(r"[a-z0-9]+(?:-[a-z0-9]+)*", slug) or slug in seen_slugs:
            raise ValueError(f"slugの形式または重複: {line}行目")
        if not title:
            raise ValueError(f"タイトルがありません: {line}行目")
        path = (base / row["content_file"]).resolve()
        if not path.is_relative_to(base):
            raise ValueError("本文ファイルの場所を確認してください")
        content = path.read_text(encoding="utf-8")
        if not content.strip():
            raise ValueError(f"本文が空です: {line}行目")
        seen_keys.add(key)
        seen_slugs.add(slug)
        plan.append({
            "source_id": key,
            "sha256": hashlib.sha256(content.encode("utf-8")).hexdigest(),
            "payload": {"title": title, "slug": slug, "content": content, "status": "draft"}
        })
if not plan:
    raise ValueError("対象が0件です")
with Path("plan.json").open("x", encoding="utf-8") as f:
    json.dump(plan, f, ensure_ascii=False, indent=2)
print(f"確認用の計画: {len(plan)}件 / status=draft / 送信なし")

確認用の計画: 2件 / status=draft / 送信なし

plan.jsonのpayloadには、タイトル、slug、本文、status=draftが入ります。date、公開状態、既存の投稿IDは入れていません。これは新規下書きの確認用計画であり、送信許可やWordPress側の保存成功を示すものではありません。

WordPress下書き一括作成｜一件試験と保存結果

WordPressへ接続する段階では、作成要求と保存された内容を照合します。この工程は実際のサイトへ書き込むため、確認用計画とは分けます。

• 作成直後の読戻し
• 画面での表示確認

ID・slug・statusの読戻し

作成応答のIDを記録し、同じIDを取得して状態を確認します。statusがdraftで、slugやタイトルが計画どおりかを照合します。本文は編集用の値と表示用の値で形式が違うため、何を比較するかも決めておきます。

下書きの読み取りには認証と権限が必要です。投稿一覧の既定は公開記事なので、認証なしの一覧に見当たらないことを下書きが存在しない証拠にしないようにします。statusとcontextを公式仕様で確認します。

ブロックと記事設定のプレビュー

保存できても、ブロックHTML、内部リンク、コード、画像が意図どおり表示されるとは限りません。プレビューで本文の表示と設定を確認し、カテゴリや著者も点検します。

一件で保存形式の違いが見つかったら、残りを送る前に入力と変換処理を直します。試験結果と停止理由を残すと、別の担当者が途中から再開する場合も判断しやすくなります。

WordPress下書き一括作成｜二重作成を防ぐ再開手順

途中で止まった場合は、保存済み・未送信・結果不明を区別します。結果不明を未送信に混ぜると再送時に重複します。

• 実行ログの記録
• 結果不明の照合

原稿と作成IDを結ぶ実行ログ

source_id、本文ハッシュ、送信時刻、作成ID、確認したstatusを一件ずつ記録します。認証情報や本文全文はログへ出さず、控えの場所を参照できる形にします。

再開前に入力が変わっていれば、前回の計画をそのまま使わず差分を確認します。内容が変わった既存下書きへ上書きするか、新規に作るかは別の判断です。作成済みを自動で更新する流れを混ぜないようにします。

タイムアウト後の保存有無の確認

応答が返らなくても、サーバー側では作成が終わっている可能性があります。すぐ同じPOSTを送らず、認証した一覧や管理画面、取得できたIDから作成された可能性のある投稿を確認します。

候補が一つに絞れても内容が合わない場合、候補が複数見つかる場合、保存の有無が分からない場合は、その原稿の処理を止めます。結果不明のまま再送しないことが、小さな一括処理でも重要です。

重複が見つかっても自動削除はしません。対象IDと内容を並べて確認し、片付ける操作は別に決めます。plan.jsonだけではWordPress側の二重作成は防げない点を覚えておきます。

WordPress下書き一括作成｜よくある質問

下書き指定と確認用計画の限界、タイムアウト後の対応を確認します。

draftを指定すれば確認せず大量に送ってよいですか？

下書きでも保存や外部連携の影響があります。一件試験と読戻しを行い、小さな単位で件数と内容を照合します。

plan.jsonを作ったらWordPressにも保存されていますか？

保存されていません。このコードは通信しません。ローカル計画とAPIの保存結果は別であり、接続後には実際のIDと内容を確認します。

タイムアウトした原稿は再送してよいですか？

まず保存有無を確認します。作成済みか分からない場合は結果不明のまま止める扱いにし、同じPOSTを繰り返さないようにします。

まとめ｜下書き一括作成は計画と照合を先に

一括処理は失敗したあとにどこから再開できるかまで決めておきます。

まずは架空の二件で計画ファイルを作り、重複した識別子を入れると止まることを確認してみてください。送信前の一覧が固まってから、検証用サイトの一件試験へ進みます。

続けて作業する場合は、次の記事も参考になります。

• WordPress REST APIの全体像
• PythonでWordPress下書きを作る方法
• GASでWordPress下書きを作る方法

参考資料
Posts | WordPress REST API Handbook
Authentication | WordPress REST API Handbook