始まりは予約投稿でした。予約投稿していた記事が、朝9時半になっても公開されませんでした。前日に自分でやった作業が原因だったんですが、当日の朝まで気づけないタイプのミスだったので、記録として残しておきます。
公開順を入れ替えたくなった
発端は動画でした。きっかけは、同じテーマのYouTube動画を先に公開することになったことでした。動画から記事に誘導したいのに、記事の方が後に出る予定になっていたので、記事2本の公開日を入れ替えることにしました。
WP-CLIで日付を変更するのは簡単で、こんな感じのコマンドを2本分打っただけです。
wp post update 180 --post_date="2026-08-14 09:30:00"油断していました。実行結果も成功と出たし、管理画面の投稿一覧を見ても日付はちゃんと入れ替わっていました。この時点では完全に終わったつもりでいました。
翌朝、片方だけ公開されていなかった
様子がおかしいと分かりました。翌日、公開されているか確認したら、日付を前倒しした方の記事が「予約投稿」のまま残っていました。時刻はとっくに過ぎているのに、ステータスが変わっていません。
疑ったのはcronでした。最初はWP-Cronが動いていないのかと思いました。共有サーバーだとアクセスが少ない時間帯にcronが回らないことはあるので、ありそうな話ではあります。でも同じ日の他の予約投稿はちゃんと公開されていたので、その線は消えました。
原因は、日付が2つあったこと
投稿のフィールドを直接確認してみて、ようやく分かりました。
wp post get 180 --fields=post_status,post_date,post_date_gmt原因は日付の二重管理でした。WordPressの投稿には日時のフィールドが2つあります。サイトの表示に使われるpost_date(日本時間)と、内部処理に使われるpost_date_gmt(UTC)です。
そしてwp post update --post_dateで更新できるのはpost_dateだけでした。post_date_gmtは変更前の古い日付のまま残っていたんです。
仕組みはこうでした。予約投稿を公開するWP-Cronの処理は、表示用のpost_dateではなくpost_date_gmtを見て「もう公開時刻を過ぎたか」を判定しています。つまり、管理画面上は8月14日に見えているのに、内部的には「まだ8月15日になっていないから公開しない」と判断され続けていた、というわけです。
もう1本の方が、実はもっと危なかった
ここで気づいたのが、日付を後ろにずらした方の記事です。
こちらは表示上は先の日付に変わっているのに、post_date_gmtには元の日付、つまりすでに過ぎてしまった時刻が入ったままでした。
放置すれば事故でした。これは「公開されない」より厄介です。次にWP-Cronが回ったタイミングで「とっくに公開時刻を過ぎている」と判定されて、意図しないタイミングで公開されてもおかしくない状態だったからです。たまたま実害は出ませんでしたが、気づかず放置していたらどこかで勝手に出ていたと思います。
片方は公開されず、もう片方はいつ公開されてもおかしくない。ひとつの操作ミスで、正反対の壊れ方が同時に起きていました。
対処と、それ以降の書き方
対処はあっさりでした。直し方自体は単純で、両方のフィールドを揃えて指定し直すだけです。GMTは日本時間から9時間引いた値になります。
wp post update 180 --post_date="2026-08-14 09:30:00" --post_date_gmt="2026-08-14 00:30:00"運用ルールを変えました。それ以降、予約投稿の日時をいじるときは必ず両方を指定するようにしました。新規に予約投稿を作るときも同じで、wp_insert_post()に渡す配列にはpost_dateとpost_date_gmtを両方書いています。
あわせて、変更した後は必ず両方の値を読み出して、ちゃんと9時間差になっているかを目視で確認する手順も足しました。コマンドが成功と返してくることと、意図通りになっていることは別問題なので、ここは省かないようにしています。
まとめて確認しておくと安心
不安は他にも広がりました。一度この状態になると「他の記事は大丈夫だろうか」と不安になったので、予約投稿を全部まとめて確認できるようにしておきました。予約中の投稿の両方の日付を並べて出すだけです。
wp post list --post_status=future --fields=ID,post_title,post_date,post_date_gmtチェックはひと目で済みます。これで9時間差になっていない行がないかを眺めれば、ズレている投稿がひと目で見つかります。予約投稿をまとめて操作した後は、これを一度通すようにしています。
まとめ
怖いのはここでした。今回のミスは、実行時にはエラーも警告も出ませんでした。コマンドは成功して、管理画面の見た目も期待通りで、失敗していると気づく手がかりが翌朝までひとつもなかったのが厄介なところです。
「表示用の値」と「処理用の値」が別々に持たれている作りは、WordPressに限らずわりとよくあります。片方だけ更新して満足していないか、というのは今後も気をつけたいところだなと思いました。
この記事が参考になったら、応援クリックをお願いします
