記事の点検表を毎日作るたびに全件を取得すると、前回と同じ記事が大量に並びます。WordPress REST APIには、更新日時を条件に記事を絞るmodified_afterがあります。前回の取得範囲を控えておけば、更新された記事を点検候補として集められます。
ただし、差分取得の結果はその期間に起きた変更をすべて記録した履歴ではありません。記事の削除や、公開記事が非公開になったことは、公開記事の取得だけでは見つけられない場合があります。定期的な全件照合も残す設計が必要です。
公開日時と更新日時を分ける
afterは公開日時、modified_afterは更新日時の絞り込みに使います。以前公開した記事の本文が今日直された場合、今日公開した記事だけを取る条件では、その更新を見落とします。
GET /wp-json/wp/v2/posts?modified_after=2026-11-01T00:00:00Z&orderby=modified&order=asc&per_page=100&_fields=id,modified_gmt,title,link
この日時は説明用の区切りです。ZはUTCを示します。実際には、保存した取得範囲とサイト側の応答日時を照合し、扱う時刻をそろえます。modified_gmtはGMTの更新日時なので、比較する処理ではUTCとして扱います。応答の日時文字列に時差が付いていないからといって、PCの現地時刻で解釈しないようにします。
重ねて取得したIDを照合する
取得の境界ぴったりから再開すると、時刻の精度や取得中の更新を考える必要があります。少し前の期間から重ねて取得し、投稿IDと更新日時で既に処理したものを分ける方法があります。重ねる期間の長さは運用に合わせて決めます。
次は架空の取得結果を比べるだけのPythonです。保存済みの日時より新しい行を返し、同じIDが入力に複数あれば新しいものを選びます。
from datetime import datetime, timezone
def utc_time(value):
return datetime.strptime(value, "%Y-%m-%dT%H:%M:%S").replace(
tzinfo=timezone.utc
)
def updated_rows(rows, saved_times):
newest = {}
for row in rows:
ident = row["id"]
stamp = utc_time(row["modified_gmt"])
previous = newest.get(ident)
if previous is None or stamp > utc_time(previous["modified_gmt"]):
newest[ident] = row
result = []
for ident, row in newest.items():
saved = saved_times.get(ident)
if saved is None or utc_time(row["modified_gmt"]) > utc_time(saved):
result.append(row)
return sorted(result, key=lambda r: (r["modified_gmt"], r["id"]))
saved_times = {42: "2026-11-01T00:00:00"}
rows = [
{"id": 42, "modified_gmt": "2026-11-01T00:00:00"},
{"id": 42, "modified_gmt": "2026-11-01T01:00:00"},
{"id": 43, "modified_gmt": "2026-11-01T00:30:00"},
]
print([row["id"] for row in updated_rows(rows, saved_times)])
結果は[43, 42]です。記事42の同じ日時の行は新しい変更として数えず、1時の更新を残します。これは日時を比べる最小例で、同一秒の別変更を完全に区別するものではありません。必要な精度に応じて、取得した本文のハッシュなども記録します。
途中失敗で再開点を進めない
総ページ数を確認し、全ページの保存と照合が終わるまでは、前回の取得完了点を置き換えません。途中で失敗したのに「今回の現在時刻」を保存すると、その間の記事が次回の対象から漏れる可能性があります。
更新日時順でも、取得中の編集によってページの中身は変わり得ます。重複IDを照合し、取り直した期間と取得完了の記録を残してください。厳密に変更を取りこぼせない業務では、一定間隔の一覧の突合や、サイト側で変更を記録する仕組みも検討します。
公開APIの既定の対象は公開記事です。下書きや予約も管理するなら、権限を持つ認証と対象状態を明示します。ここで示したコードは架空の日時の比較だけで、実サイトの全更新を収集できたという検証結果ではありません。
関連する記事
WordPress REST APIで既存記事を更新する方法｜上書き事故を防ぐ
公式資料
Posts – REST API Handbook | Developer.WordPress.org
Global Parameters – REST API Handbook | Developer.WordPress.org
