WordPressをMarkdown形式で使いたい(5)｜ドラフト記事の日付が勝手に変わる

こんにちは、パレイド技術部です。

前回まで、WordPress とローカルで編集した Markdown 形式のファイルとの同期について試用を進めてきました。

実際にWordPress REST API を使って記事の双方向同期ツールを運用していたところ、ドラフト記事の date フィールドが更新のたびに現在日時に書き換わるという問題に遭遇しました。ゴミ箱に入れた記事でも同様です。

本記事ではこの挙動の原因、影響、対策をまとめます。

本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

何が起きたか
原因：WordPress の「浮動日付（floating date）」
実際に起きた影響
対策
まとめ

何が起きたか

ローカルの Markdown ファイルと WordPress を post_id で紐付けて同期するツールを運用しています。ファイル名には date_publish を含めており、2026-01-24_2227_series-todo-management-15.md のような形式です。

ところがある日、同じ記事のファイル名が 2026-02-09_2227_series-todo-management-15.md に変わっていました。date_publish が 01-24 から 02-09 に変わっている。手動で日付を変更した覚えはありません。

調査すると、WordPress REST API から返される date フィールドの値が、元の公開予定日ではなく最終更新日時に置き換わっていました。

原因：WordPress の「浮動日付（floating date）」

WordPress はドラフト記事の日付を特殊な方法で管理しています。

内部の仕組み

ドラフト記事を作成すると、post_date にはローカル時刻が入るが、post_date_gmt は 0000-00-00 00:00:00 に設定される
この 0000-00-00 は「浮動日付（floating date）」と呼ばれるマーカー
WordPress は post_date_gmt が 0000-00-00 の記事を更新する際、post_date を現在日時に自動的に上書きする

REST API での影響

REST API の date フィールドは post_date から生成されます。つまり：

ドラフト記事を REST API 経由で更新する
WordPress が post_date_gmt = 0000-00-00 を検出
post_date を現在日時に書き換える
次回 API で取得すると date が変わっている

ゴミ箱（trash）に入れた記事でも同様の挙動が起きます。

公式のバグトラッキング

この問題は WordPress の開発チームにも認識されており、複数の Trac チケットで議論されています。

#39953: REST API: Do not update date when preparing post if date is known to be “floating” — 浮動日付のドラフトで日付を更新しないようにする提案
#38883: Shim post_date_gmt for drafts / empty dates in the REST API — ドラフトの空の date_gmt を REST API でどう扱うか
WP-API Issue: post_date changes on update — REST API 経由で更新すると日付が変わる問題の報告

2026年3月時点でも根本的な修正は入っておらず、REST API を使う開発者が個別に対処する必要があります。

実際に起きた影響

この問題により、同期ツールで以下の事故が発生しました。

ファイル名の不整合

ドラフト記事を REST API 経由で更新 → date が現在日時に変わる → ダウンロード時にファイル名が変わる → git 上で旧ファイル名が削除(D)、新ファイル名が未追跡(??)に見える。

# git status
 D blog/articles/2026-01-24_2227_series-todo-management-15.md
?? blog/articles/2026-03-24_2227_series-todo-management-15.md

ゴミ箱記事のダウンロード

ゴミ箱に入れた記事の date も書き換わるため、異常な日付のファイルが生成されました。2024-05-20 のような過去の日付が付いた記事が突然ダウンロードされ、混乱を招きました。

対策

1. アップロード時にdateを明示的に送る

REST API で記事を更新する際、frontmatter の date_publish を date フィールドとして明示的に送信します。これにより WordPress が浮動日付を検出して現在日時に書き換える挙動を防げます。

data = {
    "title": title,
    "content": content,
    "status": "draft",
}
if date_publish:
    data["date"] = date_publish  # 明示的に送る

2. ダウンロード時にローカルの日付を優先する

WP からダウンロードする際、date_gmt が 0000-00-00 のドラフト記事は date を信頼しません。ローカルに既存の date_publish があればそちらを優先します。

wp_date_gmt = post.get("date_gmt", "")
is_floating = wp_date_gmt.startswith("0000") or not wp_date_gmt

if local_date_publish:
    date_str = local_date_publish  # ローカル優先
elif is_floating and status in ("draft", "trash"):
    date_str = ""  # 信頼できない日付は使わない
else:
    date_str = wp_date_str

3. sync 前に WP のスナップショットを保存する

sync の前に WordPress の全記事を zip にバックアップしておくことで、日付の書き換えやリビジョン汚染があっても確実に復元できます。

blog/articles/_backups/
  20260209T001500_wp_snapshot.zip

WordPress のリビジョン機能も復旧に使えますが、sync ツールが壊れた内容をアップロードするとリビジョン自体が汚染されるため、ローカルの zip バックアップの方が確実です。

まとめ

WordPress REST API のドラフト記事における浮動日付は、2026年時点でも未修正の既知の問題です。REST API を使った同期ツールを運用する場合は、以下を徹底する必要があります。

date フィールドを必ず明示的に送信する
ダウンロード時に WP の date を盲信しない
sync 前にバックアップを取る

WordPress の内部的には「ドラフトの日付は公開時に確定するもの」という設計思想があり、それ自体は合理的です。しかし REST API で外部ツールと連携する場合、この暗黙の挙動がサイレントなデータ破壊を引き起こします。API を設計する際は、「暗黙の書き換え」を避け、呼び出し側が明示的に制御できるインターフェースにすべきだという教訓でもあります。