「WordPressの予約投稿を一括変更したいのに、日付を入れる場所が見当たらない」 「明日からの予約を、全部まとめて1日後ろにずらしたいだけなのに」 「1本ずつ開いて直すしかないのか？ 20本あるんだけど」
3つ目に心当たりがある人は、この記事で終わります。
先に結論を書きます。WordPressの予約投稿は、まとめて「下書きに戻す」ことはできるのに、まとめて「日時を変える」ことは標準機能ではできません。一括編集の画面に、日付の欄そのものが用意されていないからです。1本ずつなら変えられます。つまり本数ぶん、同じ操作を繰り返すしかない、というのが標準機能の答えです。
筆者はこのブログを 毎日12:00に1本ずつ公開していました（この記事を書いた2026年9月上旬の時点。公開済みは 107本。その後は隔日に切り替えています）。予約が数本先まで並んでいる状態が常にあり、その並びごと後ろにずらしたい日が月に何度か来ます。理由は記事の出来ではありません。画像が間に合わない日があるからです。
筆者は40代の会社員（非エンジニア）です。プログラムは書けません。この記事では、WordPressの予約投稿を一括変更する現実的なやり方と、途中で1度やらかした「予約したはずの記事が、その場で公開されてしまった」という失敗を、筆者の環境で何を送って何が起きたかまで切り分けて、専門用語を噛み砕いて説明します。
※ 本記事は Claude Code（筆者が使用中のAIアシスタント）が筆者の実体験を元に執筆しています。
この記事はこんな方向け
- 予約投稿の日時をまとめてずらしたい人
- 一括編集を開いて、日付欄が無くて固まった人
- 予約が急に公開されてしまったことがある人
- 毎日更新をしていて、1日ぶん後ろに倒したい人
🎬 この記事に登場するキャラ
- 社長 — 筆者本人（40代・副業で複数の事業を運営）
- 策 — Claude Code（参謀AI・冷静な軍師）
- 凛 — Claude.ai（秘書AI・ちょいドS姉御）
- Claude — 純AIキャラ（実測値・仕様を淡々と提示するロボット）
社長：「予約してある記事を、全部1日ずつ後ろにずらしたいんだよ。記事を全部選んで、一括編集を開いた。……日付を入れる欄が無い。」
凛：「無いのよ。カテゴリーもタグも作者も変えられるのに、日付だけ無いの。」
社長：「なんで日付だけ無いんだ？」
策：「まとめて同じ日時を入れられてしまうと、選んだ記事が全部同じ瞬間に公開されるからです。事故のほうが大きいので、最初から欄が置かれていない、と考えるのが自然です。」
Claude：「補足します。1本ずつなら、投稿一覧のクイック編集で日時を変えられます。変えられないのではなく、まとめて変えられないだけです。」
社長：「……20本あるんだよ。」
📌 目次（クリックでジャンプ）
1. 【問題提起】WordPressの予約投稿を一括変更で動かせない本当の理由
1-1. 一括編集の画面には、日付の欄そのものが無い
投稿一覧で記事にチェックを入れて「一括操作 → 編集 → 適用」と進むと、まとめて変更できる項目が並びます。ここで変えられるのは、だいたい次のものです。
- カテゴリー（追加）
- タグ（追加）
- 作成者
- コメントの可否
- ステータス（公開／下書き／レビュー待ちなど）
- 先頭固定にするかどうか
この中に「日時」がありません。 探しても出てこないのは、あなたの画面がおかしいからではなく、機能として置かれていないからです。
ここが少しややこしいのは、ステータスは一括で変えられることです。予約投稿を全部選んで「下書き」に落とすのは一括でできます。ところが、下書きに落とした瞬間に予約していた日時の情報が扱いづらくなるので、「一旦全部下書きにして、あとで予約し直す」は解決策になりません。戻すときに結局1本ずつ日付を入れることになるからです。
1-2. 1本ずつなら変えられる。だから「本数ぶん繰り返す」が標準機能の答え
投稿一覧で記事名にマウスを乗せると出てくる「クイック編集」を開くと、そこには日時の欄があります。年・月・日・時・分をその場で直して更新すれば、予約日時は変わります。
つまり標準機能でできることを整理すると、こうなります。
- ✅ 1本の予約日時を変える → できる（クイック編集）
- ✅ 複数の予約をまとめて下書きに落とす → できる（一括編集）
- ❌ 複数の予約日時をまとめて変える → できない
- ❌ 「全部まとめて1日後ろ」のような相対的なずらし方 → できない
4つ目が地味に効いてきます。仮に日付欄があったとしても、それは「全部同じ日時にする」機能であって、「それぞれの日付を保ったまま1日ずつ後ろに動かす」ではありません。毎日更新の並びを崩さずに倒したい人が本当に欲しいのは後者のほうです。
社長：「同じ日時にするんじゃなくて、順番を保ったまま全部1日ずらしたいんだ。」
凛：「それは標準機能の発想に無いのよ。予約は”1本ずつ置くもの”という前提で作られてるから。」
策：「なので考え方を切り替えます。画面で直すのをやめて、今入っている日付を読み取って、1日足して、書き戻すという手順にします。人がやるのは”1日足す”と決めることだけです。」
2. 【AI導入で変わった】「1本ずつ直す」から「全部読んで、足して、書き戻す」へ
2-1. 予約をずらしたくなるのは、記事の出来が悪いときではない
先に、なぜこの作業が必要になるのかを書いておきます。筆者の場合、理由はいつも同じです。記事は書けているのに、画像が間に合わない。
このブログは1記事につきアイキャッチ1枚と本文中の図解3枚、合計4枚の画像を使っています。画像を作れる枚数には1日あたりの上限があり、記事を毎日1本公開するペースと、画像を1記事ぶん作れるペースがほぼ同じです。余白がありません。1日どこかで作れない日が出ると、翌日の公開に画像が間に合わなくなります。
このとき取れる手は2つです。
- 画像なしで公開する
- 予約を全部1日後ろにずらして、作る時間を1日買う
1つ目は選びたくありませんでした。だから2つ目をやることになり、その結果として「予約をまとめてずらす」という作業が定期的に発生するようになった、という順番です。
2-2. やることは「読む・足す・書き戻す」の3つだけ
AIに任せてから変わったのは、作業の速さよりも手順の形でした。画面を1本ずつ開く発想をやめて、こういう流れにしています。
- いま予約されている記事を、日付つきで全部読み出す
- それぞれの日付に 1日足す
- 1本ずつ、新しい日付を書き戻す
見ての通り、人間が判断しているのは 2 の「1日足す」だけです。1 と 3 は同じ操作の繰り返しなので、そこを任せています。20本あっても手順は変わりません。
社長：「読んで、足して、書き戻す。言われれば当たり前なんだけど、画面を見てるとその発想にならないんだよな。」
Claude：「画面は”1本を直す道具”なので、そう見えます。まとめて動かすときは、画面ではなく一覧を相手にすると考え方が切り替わります。」
凛：「で、その書き戻すところで1回やらかしたのよね。」
社長：「……はい。」
3. 【具体例】予約日時をまとめて動かして分かった3つのこと
3-1. ケース1：日付を片方だけ送ったら、その記事はその場で公開された（筆者の環境で起きたこと）
これが今回いちばん伝えたい失敗です。ただし先に断っておきます。これは「筆者の環境で、この送り方をしたらこうなった」という記録で、「WordPressは片方だけ送ると必ず即公開になる」という仕様の話ではありません。理由はこの節の後半に書きます。
WordPressは、1本の記事について日付を2つ持っています。外から書き戻すときの項目名も添えておきます。
| 名前（項目名） | 中身 | 例（日本時間12:00） |
|---|---|---|
表示用の日付（date） |
自分のサイトの時間帯での日時 | 2026-09-10 12:00 |
世界標準の日付（date_gmt） |
時差を戻した日時（日本は9時間前） | 2026-09-10 03:00 |
人が画面で操作しているときは、2つ目は自動で計算されます。ところが、一覧を相手にして書き戻すやり方をすると、この2つ目を自分で渡す場面が出てきます。
筆者の環境で起きたこと（記録）
- 発生日：2026年5月2日
- 使ったもの：Claude Code（筆者が使っているAIアシスタント）から、WordPressの外部窓口（REST API＝プログラムから記事を読み書きする仕組み）に直接書き戻し
- 送った項目：表示用の日付（
date）だけ。世界標準の日付（date_gmt）と、状態（status）は送っていない - 起きたこと：予約済みだった記事1本が、送った直後に公開された
- 残っていない記録：そのとき送った日付の値そのものと、送信した時刻。当時は失敗の記録を取る習慣がなく、ここが残っていません
「片方だけ＝必ず即公開」とは言えない理由
あとから WordPress 本体の仕様（外部窓口が、送られてきた記事データを保存する前に整える処理）を確認したところ、表示用の日付だけを送った場合、世界標準の日付はサイトの時間帯設定から自動で計算されるつくりになっていました。つまり本体が仕様どおりに動いていれば、片方だけ送っても予約日時は正しく揃うはずです。参考：WordPress開発者向けリファレンス（英語）
では筆者の環境では何が起きたのか。当時の記録が無いので断定はできませんが、候補は2つに絞れます。
- 送った日付が、サーバーから見てすでに過去だった（いちばん怪しい）。WordPressには「予約状態なのに公開日時が過去なら、その場で公開に切り替える」という仕様があります。たとえば日本時間から9時間引いた値を、うっかり表示用の欄に入れて送ると、サーバーはそれを日本時間として読むので、その日の午前3時＝すでに過ぎた時刻になります。これは仕様どおりの動きで、片方だけ送ったこと自体が原因ではありません
- 送った中身に、別の抜けや形式の違いがあった。当時はAIに指示して書き戻していて、日付の形式や状態の指定が意図どおりだったかを、送ったあとに確認していません
対策は、原因がどちらでも効く形にしました。表示用と世界標準の日付を2つとも送る、状態も「予約のまま」と明示して送る、送った直後に読み直して確認する。この3点にしてから、同じ失敗は起きていません。
3-2. ケース2：「予約のままにする」という指定を省くと、下書きに落ちる
もうひとつ、日付と一緒に渡すべきものがあります。その記事を予約状態のままにする、という指定です。
これを省くと、日付は正しく入っているのに状態だけが下書きに落ちる、ということが起きます。下書きは公開されません。「日付は合っているのに、その日が来ても記事が出ない」という一番気づきにくい壊れ方をします。
日付が壊れると即座に公開されるので気づけます。ところが状態が壊れると、公開されなかったことに当日まで気づけません。こちらのほうが実は怖い、というのが正直な感想です。
3-3. ケース3：全部ずらすと、「次の空き枠」も全部ずれる
3つ目は、事故ではなく設計の話です。
予約を全部1日後ろにずらすと、当然ながら最後の予約の日付も1日後ろに動きます。毎日更新をしていると、次に書いた記事を入れる場所は「最後の予約の翌日」になります。つまり、ずらした瞬間に次の記事の置き場所も1日ずれます。
これを忘れていると、ずらしたあとに新しい記事を古い感覚で予約してしまい、同じ日に2本入るか、1日空くかのどちらかが起きます。ずらしたら、必ず一覧をもう一度開いて、最後の予約日を目で確認する。これだけで防げます。
社長：「日付が飛ぶより、出なかったことに気づかないほうが怖いな。」
策：「そうです。壊れたときに大きな音がするかどうかで、危険度は変わります。即公開は音が大きいので必ず気づけます。下書き落ちは無音です。」
凛：「だから作業のあとに一覧を開くの。開いて数えれば、無音の壊れ方も見えるでしょ。」
Claude：「実運用の数字です。このブログは公開済み107本、予約は常に数本ぶん先まで並んでいます。ずらす対象が数本でも20本でも、確認は一覧を1回開くだけで済みます。」
4. 【じゃあどうやる？】予約投稿を壊さずにまとめてずらす5ステップ
ここからは実際の手順です。5本以下なら、素直にクイック編集で1本ずつ直すのがいちばん早いです。以下は10本を超えてきたときの話だと思ってください。
Step 0（前提）：Claude Code と WordPress をつないでおく
この手順は、Claude Code（筆者が使っているAIアシスタント）から WordPress の外部窓口（REST API）に読み書きできる状態が前提です。つなぎ方は WordPress 側で「アプリケーションパスワード」を1つ発行するだけで、手順はClaude CodeでWordPressに記事を自動投稿する方法の2章にまとめてあります。つないだあとに403というエラーで弾かれる場合はWordPress REST APIが403になる原因を見てください。
Step 1：まず一覧を開いて、いま何本あるかを数える
投稿一覧の「予約済み」で絞り込みます。ここで本数と、いちばん後ろの予約日をメモします。作業後に同じ場所を見て突き合わせるので、この2つは必ず控えます。
筆者は投稿一覧の画面ではなく、Claude Code に次のように頼んで一覧を出しています。
予約済み（status が future）の記事を、
記事ID・予約日時（date と date_gmt）・状態の
一覧にして。古い順で。裏側で動いているのは、WordPressの外部窓口に「予約済みの記事を日付つきで一覧にして」と頼む1行です。
GET /wp-json/wp/v2/posts
?status=future&per_page=100
&orderby=date&order=asc
&_fields=id,title,date,date_gmt,status実物の記録を1つ載せます。2026年9月14日の、筆者のブログの予約一覧（変更前）です。
| ID | date（日本時間） | date_gmt |
|---|---|---|
| 3011 | 2026-09-15 12:00 | 2026-09-15 03:00 |
| 3019 | 2026-09-17 12:00 | 2026-09-17 03:00 |
| 3031 | 2026-09-19 12:00 | 2026-09-19 03:00 |
| 3038 | 2026-09-21 12:00 | 2026-09-21 03:00 |
本数は4本、いちばん後ろは9月21日、状態は4本とも「予約済み（future）」。この3つを控えます。
Step 2：何日ずらすかを、先に1つだけ決める
「とりあえず動かしてから考える」をやると必ず散らかります。1日なのか3日なのかを先に決めてください。決めるのはここだけです。あとの工程に判断は出てきません。
Step 3：日付は必ず2つセットで書き戻す
前章のとおりです。表示用の日付と世界標準の日付（日本時間から9時間引いたもの）を、必ず一緒に渡します。片方だけ送った筆者は、3-1の事故になりました。
Claude Code への頼み方は、こうです。
さっきの一覧の記事を、古い順に1本ずつ、
date と date_gmt を両方 +1日 して書き戻して。
status は future のまま明示して送って。
送ったら1本ごとに、返ってきた
date / date_gmt / status を表示して。裏側で1本ごとに送っている中身は、この3項目だけです（記事ID 3011 を9月16日にずらす例）。
POST /wp-json/wp/v2/posts/3011
{
"status": "future",
"date": "2026-09-16T12:00:00",
"date_gmt": "2026-09-16T03:00:00"
}世界標準の日付は、表示用から9時間引くだけです（日本の場合）。この値を表示用の欄に入れ間違えると、3-1の候補1の事故になります。
そして 「予約のままにする」という状態の指定も一緒に渡すこと。日付と状態はセットです。片方だけ正しくても意味がありません。
Step 4：古い日付から順に処理する
前から順、つまり公開が近いものから動かします。後ろから動かす理由がないうえ、途中で止まったときに「どこまで進んだか」が分かりやすくなります。
途中で止まったときも慌てないでください。日付を前に動かしているわけではないので、処理済みのものが先に公開されてしまうことはありません。落ち着いてもう一度、未処理のぶんだけ流せば済みます。
Step 5：終わったら一覧を開いて、本数と最終日を突き合わせる
ここを飛ばさないでください。 Step 1で控えた本数と同じか、いちばん後ろの予約日がちょうど動かしたぶんだけ後ろになっているか。この2つを見ます。
- 本数が減っていたら → どれかが公開されたか、下書きに落ちた
- 最終日がずれていなかったら → 書き戻しが1本も効いていない
数えるだけで、無音の失敗まで拾えます。
確認は、Step 1と同じ一覧をもう一度出して、1本ずつ突き合わせます。頼み方はこれだけです。
さっき動かした記事を1本ずつ読み直して、
status が future のままか、
date と date_gmt が両方 +1日 になっているかを
表にして。Step 1の実物を1日ずらした場合、変更後はこう並ぶのが正解です（送る前に手元で計算した表。実際に動かすときは、返ってきた値がこの表と一致するかを見ます）。
| ID | date（日本時間） | date_gmt |
|---|---|---|
| 3011 | 2026-09-16 12:00 | 2026-09-16 03:00 |
| 3019 | 2026-09-18 12:00 | 2026-09-18 03:00 |
| 3031 | 2026-09-20 12:00 | 2026-09-20 03:00 |
| 3038 | 2026-09-22 12:00 | 2026-09-22 03:00 |
date_gmt が動いていない、status が future 以外になっている、本数が減っている。どれか1つでもあれば、その記事だけやり直します。
社長：「日付は2つセット。状態も一緒。終わったら数える。それだけだな。」
凛：「それだけよ。難しいのは手順じゃなくて、終わったあとに確認をサボらないこと。あなたが前にやらかしたのも、そこでしょ。」
策：「はい。あのときは書き戻した直後にブラウザで確認していれば、公開されたことにその場で気づけました。確認は作業の一部です。」
Claude：「補足すると、この5工程のうち人が判断するのは Step 2 の”何日ずらすか”だけです。残りは全部、同じ操作の繰り返しです。」
5. よくある質問（FAQ）
Q. プラグインを入れれば、予約日時を一括変更できますか？ A. 投稿一覧の表示を増やしたり、カレンダー形式で編集できるようにするプラグインはあります。ただし「それぞれの日付を保ったまま全部1日ずらす」という相対的な動かし方は、標準の一括編集にもプラグインにも期待しにくい部分です。まずは本数を数えて、10本以下ならクイック編集という判断で足ります。
Q. 一括編集で全部「下書き」にしてから予約し直すのはダメですか？ A. 動きますが、戻すときに結局1本ずつ日付を入れることになるので楽になりません。しかも下書きに落ちている間は、うっかり忘れると公開されないままになります。おすすめしません。
Q. 予約した記事が、予約日を過ぎても公開されません。 A. まず状態が「予約済み」のままか確認してください。下書きに落ちていると、日付が来ても出ません。状態が正しいのに出ない場合は、サイトの時間帯の設定（日本時間になっているか）を見ます。
Q. 逆に、予約日より前に公開されてしまいました。 A. この記事の 3-1 のケースです。まず疑うのは、送った日付がサーバーから見て過去になっていなかったか（時間帯の取り違え）。WordPressは予約状態でも、公開日時が過去ならその場で公開します。次に、日付を2つとも送ったか、状態を「予約（future）」と明示したかを確認してください。
Q. ずらした結果、同じ日に2本入ってしまいました。 A. 3-3 のケースです。ずらすと最後の予約日も動くので、次に入れる場所も動きます。一覧を開いて最後の予約日を見てから、次の記事の日付を決めてください。
6. まとめ｜予約は「置くもの」ではなく「並びとして持つもの」
社長：「日付が2つあるなんて、1年やってて知らなかったよ。しかも俺の事故、仕様のせいじゃなくて俺の送り方だった可能性が高いのか。」
凛：「知らないまま画面で操作してる限りは、知らなくても困らないの。まとめて動かそうとした瞬間に初めて出てくるのよ、その2つ目は。原因を仕様のせいにしないで、送った中身を残す。それが今回の教訓でしょ。」
策：「まとめて付ける・まとめて下書きにする。この2つは標準機能で通ります。通らないのは”まとめて日時を変える“だけです。そこだけ考え方を変えれば、あとは繰り返しの作業になります。」
Claude：「執筆時点の実測では、公開済み107本を毎日12:00に1本ずつという並びで運用していました。ずらす作業そのものより、ずらしたあとに一覧を1回開くことのほうが効いています。」
この記事で伝えたかったことは3つです。
- 予約投稿は一括で「下書きにする」ことはできるが、一括で「日時を変える」ことは標準機能ではできない。一括編集の画面に日付欄そのものが無い
- 日付は2つある。表示用と世界標準の2つを、状態と一緒に必ずセットで書き戻す。筆者は片方だけ送って即公開になったが、本体の仕様上「片方だけ＝必ず即公開」ではない。原因は送った日付が過去扱いになった可能性が高い
- 状態の指定を省くと下書きに落ちて、当日になっても出ない。日付の事故は音が大きいが、状態の事故は無音
予約をずらしても、記事が良くなるわけでも順位が上がるわけでもありません。それでもこの作業を覚えてよかったと思うのは、「今日は間に合わないから1日買う」という選択肢を持てるようになったからです。間に合わない日は必ず来ます。そのときに慌てて中身の薄い記事を出すより、並びごと1日後ろに倒すほうがずっとましでした。
次に読むべき記事
- Claude Codeで副業を始める完全ガイド — この記事の前提になっている、AIに繰り返し作業を任せる考え方の総まとめ
- WordPressのスラッグを一括変更する方法 — 公開済みの記事を触ると何が起きるかを、URL側で確かめた話
- WordPressのカテゴリを一括変更する方法 — 同じ「まとめて直す」でも、外せない事情がある側の話
- Claude CodeでWordPressに記事を自動投稿する方法 — 予約まで含めて1年運用してわかったこと
- WordPress REST APIが403になる原因 — 書き戻しそのものが弾かれるときの話
※ 本記事は Claude Code（筆者が使用中のAIアシスタント）自身が、筆者の実体験を元に執筆しています。 ※ 本記事にはアフィリエイトリンクが含まれます。
