WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する

WordPress で投稿したはずの記事が、意図せず予約投稿になり、さらに予約投稿に失敗することがあります。特に Docker や Kubernetes 上で WordPress を動かしている場合、原因は WordPress だけではなく、PHP、コンテナ、データベース、ノード側の時刻設定に分散していることがあります。

この記事では、WordPress の投稿時刻が 9 時間ずれて予約投稿扱いになる場合に、どこを確認すべきかを整理します。日本時間と UTC の差が 9 時間であるため、単なる表示の問題ではなく、タイムゾーンの扱いがどこかで混ざっている可能性があります。

9 時間ずれる場合はタイムゾーンを疑う

日本時間 Asia/Tokyo は UTC より 9 時間進んでいます。そのため、WordPress の投稿時刻が 9 時間ずれて未来時刻として扱われる場合、どこかの層で UTC と JST の扱いがずれている可能性があります。

WordPress はアプリケーションとしてタイムゾーン設定を持ちます。一方で、PHP は PHP のタイムゾーン、コンテナは OS レベルの時刻設定、MariaDB はデータベース側の時刻設定を持ちます。Kubernetes の場合は、さらに Pod が動いているノード側の時刻同期も関係します。

まず WordPress のタイムゾーンを確認する

最初に見るべきなのは WordPress のサイト設定です。管理画面の 設定 から 一般 を開き、タイムゾーンが 東京 または Asia/Tokyo 相当になっているか確認します。

WP-CLI が使える環境であれば、次のように確認できます。空文字や UTC のままになっている場合は、WordPress 側の設定から直します。

wp option get timezone_string
wp option get gmt_offset

設定する場合は、管理画面から変更するのが分かりやすいです。WP-CLI で行うなら、次のように timezone_string を設定します。

wp option update timezone_string Asia/Tokyo

PHP のタイムゾーンを確認する

WordPress は PHP で動いているため、PHP 側の時刻設定も確認します。コンテナ内で次のコマンドを実行すると、PHP が認識しているタイムゾーンと現在時刻を確認できます。

php -r 'echo date_default_timezone_get(), PHP_EOL; echo date("c"), PHP_EOL;'

WordPress 側のタイムゾーンが正しくても、PHP やコンテナ側の設定が期待と異なると、ログや一部処理の見え方が混乱します。特に障害調査では、WordPress の表示時刻、PHP の実行時刻、コンテナログの時刻を同じ前提で見られるようにしておくことが重要です。

Docker コンテナの時刻を確認する

Docker コンテナでは、ホスト OS とコンテナ内のタイムゾーン設定が分かれます。現在時刻、タイムゾーンファイル、環境変数を確認します。

date
readlink /etc/localtime || ls -l /etc/localtime
printenv TZ

アプリケーションコンテナでは、必ずしも OS のタイムゾーンを JST にする必要はありません。サーバー運用として UTC に統一する考え方もあります。ただし、WordPress の投稿時刻や予約投稿の問題を切り分けるときは、どの層が UTC で、どの層が JST なのかを明示的に把握する必要があります。

Kubernetes では Pod とノードの両方を見る

Kubernetes 上の WordPress では、Pod の中だけを見ても不十分な場合があります。Pod はノード上で動いているため、ノード側の時刻同期が崩れていると、アプリケーション全体に影響します。

まず WordPress Pod の中で時刻を確認します。名前空間や Pod 名は環境に合わせて変更します。

kubectl -n wordpress get pod
kubectl -n wordpress exec -it wordpress-xxxxxxxxxx-xxxxx -- date

次に、ノード側で timedatectl や chronyc tracking を確認します。ノードの時刻同期が不安定な状態で、WordPress の予約投稿だけを疑うと切り分けを誤ります。

timedatectl
chronyc tracking

MariaDB の時刻も確認する

WordPress は投稿データをデータベースに保存します。投稿日時にはローカル時刻と GMT 相当の値が関係するため、データベース側の時刻設定も確認しておくと切り分けが楽になります。

SELECT NOW(), UTC_TIMESTAMP(), @@global.time_zone, @@session.time_zone;

データベースの時刻設定を無理に JST にする必要があるとは限りません。重要なのは、WordPress、PHP、DB、ログのそれぞれがどの時刻基準で動いているかを理解し、投稿時刻のずれがどこで発生しているかを切り分けることです。

予約投稿の失敗は WP-Cron も関係する

9 時間ずれて未来時刻として扱われると、記事は予約投稿になります。そして予約投稿は、WordPress の WP-Cron によって公開処理が実行されます。つまり、時刻ずれに加えて WP-Cron が正常に動いていない場合、予約投稿失敗として見えることがあります。

アクセスが少ないサイトや、外部から WordPress へのアクセスが制限されている環境では、WP-Cron の実行タイミングが安定しないことがあります。Kubernetes で運用するなら、通常のアクセス任せではなく、CronJob などで明示的に WP-Cron を実行する構成も検討できます。

wp cron event list
wp cron event run --due-now

切り分けの順序

この問題は、いきなりコンテナイメージや Kubernetes の設定を疑うより、層ごとに順番に確認した方が早いです。

• WordPress のタイムゾーンが Asia/Tokyo になっているか確認する
• 投稿日時がローカル時刻と GMT のどちらでずれているか確認する
• PHP が認識しているタイムゾーンを確認する
• コンテナ内の date とログ時刻を確認する
• MariaDB の NOW() と UTC_TIMESTAMP() を確認する
• Kubernetes ノードの時刻同期を確認する
• 予約投稿失敗がある場合は WP-Cron の実行状態を確認する

まとめ

WordPress の投稿時刻が 9 時間ずれて予約投稿になる場合、原因を WordPress だけに閉じて考えると見落としが起きます。9 時間という差は JST と UTC の差そのものなので、WordPress、PHP、コンテナ、MariaDB、Kubernetes ノードのどこで時刻基準が混ざっているかを確認する必要があります。

サーバー管理としては、すべてを JST にそろえることよりも、どの層がどの時刻基準で動いているかを明確にすることが重要です。その上で、WordPress の表示と予約投稿に必要な設定を整え、WP-Cron の実行経路まで確認すると、予約投稿失敗の切り分けがしやすくなります。

関連記事

• タイムゾーンの仕組みを理解する
• Ubuntu 22.04 タイムゾーン設定
• Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
• WordPress が wordpress.org に接続できない原因と切り分け方
• WordPress で Google Analytics 4 を導入する理由 – アクセス解析を運用改善に使う

Related posts:

CentOS 8 Docker インストール – Docker CE の導入 CentOS 8 で WordPress を構築した記録 – 現在は Ubuntu / Kubernetes 構成へ読み替える WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える WordPress が wordpress.org に接続できない原因と切り分け方 Kubernetes に Docker / Podman のような stop/start がない理由 コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける WordPress のショートコード運用を見直す – 経過日数表示を例に本文と機能を分離する WordPress の「返答が正しい JSON レスポンスではありません」を切り分ける WordPress のメール送信が遅い原因 – sendmail、Postfix、名前解決を切り分ける WordPress ブロックエディタを使う理由 – 記事構造と再利用性を高める WordPress のスパムコメント対策 – コメント欄を開くリスクと運用設計 WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針