公開していたはずのWordPressの記事が、ある日突然、まとめて下書きに戻っていたり、完全に削除されていたりする現象が発生しました。
ゴミ箱にも入っていない。誰かが編集した形跡も見当たらない。それなのに、複数の記事がほぼ同じ時刻に変更されている。
「これはまずい……」
最初は不正アクセスやデータベースの不具合を疑いました。アクセスログを一行ずつ確認し、WordPressの内部処理やプラグインの動作も追ってみたところ、原因はもっと身近なところにありました。
原因として考えられたのは、PublishPress Futureという期限管理プラグイン、WP-Cron、そしてAction Schedulerの組み合わせです。
今回は実際に発生したトラブルをもとに、なぜWordPressの投稿が一斉に下書き・完全削除されたのか、その仕組みと確認方法、再発防止策を解説します。同じような現象に悩んでいる方の参考になれば幸いです。
関連記事：WordPressのトップページ、front-page.phpとindex.phpの違いと使い分け
まず確認したいチェックリスト
WordPressの投稿が勝手に下書きになったり、削除されたりした場合は、すぐにプラグインを削除したり設定を変更したりする前に、まず状況を確認しましょう。
焦って設定を変えてしまうと、あとから原因を追いにくくなることがあります。特に、アクセスログやScheduled Actionsの履歴は、原因を切り分けるための重要な手がかりになります。
- 変更された投稿が複数あるか
- 複数の投稿がほぼ同じ時刻に変更されていないか
- 投稿のリビジョンが増えているか
- ゴミ箱に移動された投稿が残っているか
- PublishPress Futureのワークフローが有効になっていないか
- Automatically create actionsが有効になっていないか
- Scheduled Actionsに過去の予約処理が残っていないか
- サーバーログに
wp-cron.phpへのアクセスが記録されているか admin-ajax.php?action=as_async_request_queue_runnerのリクエストが記録されているか- ベーシック認証やアクセス制限によってWP-Cronが止まっていなかったか
特に、複数の投稿が同じタイミングで変更されている場合は、手動操作よりも自動処理を疑った方が自然です。PublishPress FutureやAction Schedulerに残っていた予約処理が、WP-Cronの再開時にまとめて実行された可能性があります。
複数投稿が同時刻に変更された理由
今回まず注目したのは、変更された投稿の更新時刻がほぼ同じだったことです。
人が管理画面で一つずつ操作した場合、たとえ急いで作業したとしても、投稿ごとの変更時刻は数秒から数十秒単位でずれることが多いです。しかし今回は、まるでスイッチを押したかのように、複数の記事が一斉に変更されていました。
さらに、通常の編集であれば増えるはずのリビジョンも見当たりませんでした。
この時点で、「誰かが管理画面で編集した」というよりも、WordPress内部の自動処理が動いた可能性が高いと考えました。
サーバーのアクセスログを確認すると、同じ時間帯にwp-cron.phpへのPOSTと、admin-ajax.phpへのリクエストが記録されていました。
POST /wp-cron.php
POST /wp-admin/admin-ajax.php?action=as_async_request_queue_runnerこの組み合わせは、WordPressのスケジュール処理や、Action Schedulerによる非同期処理が実行されたときに見られるパターンです。
つまり、今回の投稿変更は、人の手動操作ではなく、WordPress側の自動処理によって実行された可能性が高いということになります。
不正アクセスや手動操作との見分け方
投稿が勝手に下書きになったり削除されたりすると、まず不正アクセスを疑いたくなります。もちろん、不正ログインや管理者権限の悪用を完全に否定することはできません。
ただし、今回のように複数の投稿がほぼ同時刻に変更され、リビジョンも増えていない場合は、手動操作よりも自動処理を疑った方が自然です。
| 確認項目 | 手動操作の可能性 | 自動処理の可能性 |
|---|---|---|
| 変更時刻 | 投稿ごとに少しずつズレやすい | 複数投稿が同時刻に変わりやすい |
| リビジョン | 増えることが多い | 増えない場合がある |
| アクセスログ | 管理画面の編集画面アクセスが残りやすい | wp-cron.phpやadmin-ajax.phpが目立つ |
| 対象投稿 | 一部の記事に限られることが多い | 条件に合う投稿がまとめて処理されることがある |
もちろん、管理者アカウントのログイン履歴やセキュリティプラグインのログも確認した方が安心です。ただ、同じ時刻に大量の記事が変更されている場合は、まずプラグインの予約処理やWP-Cronを確認してみる価値があります。
WP-CronとAction Schedulerの仕組み
WordPressには、WP-Cronという仕組みがあります。
名前に「Cron」と付いていますが、サーバーの本来のcronとは少し違います。WP-Cronは、サイトへのアクセスをきっかけに動作するWordPress独自の疑似的なスケジューラーです。
たとえば、予約投稿、プラグインの定期処理、メール送信、期限付きのアクションなどが、この仕組みによって動くことがあります。
ただし、WP-Cronには特徴があります。
- サイトへのアクセスがきっかけで実行される
- アクセスが少ないサイトでは処理が遅れることがある
- ベーシック認証やアクセス制限の影響を受ける場合がある
- 止まっていた処理が、再開時にまとめて実行されることがある
さらに、多くのプラグインはAction Schedulerという仕組みを使って、バックグラウンド処理を管理しています。
Action Schedulerは、簡単に言えば「あとで実行する処理をキューとして保存しておく仕組み」です。将来のタイミングで実行するアクションを登録し、WP-Cronなどをきっかけに処理します。
期限付きのアクションはこのキューに登録され、WP-Cronが動いたタイミングで実行されます。もし何らかの理由でWP-Cronが止まっていれば、処理は実行されずに溜まり続けます。
そして再びWP-Cronが動いた瞬間、溜まっていたジョブがまとめて処理されることがあります。
今回の現象は、まさにこの動きと一致していました。
PublishPress Futureが影響した可能性
今回の構築サイトでは、WordPressプラグイン「PublishPress Future」を入れていました。
PublishPress Futureは、投稿の公開後に自動でステータスを変更したり、カテゴリを更新したり、非公開化・削除・ゴミ箱移動などをスケジュールできる便利なプラグインです。
期間限定のお知らせ、キャンペーン記事、求人情報、イベント情報などではとても役立ちます。公開後に手作業で下書きに戻したり、カテゴリを外したりする必要がなくなるからです。
ただし、便利な反面、設定を誤ると影響範囲が大きくなります。
特に注意したいのが、ワークフローや自動アクションの設定です。
たとえば「公開から1週間後にDraftへ変更」というルールがあれば、その条件を満たした投稿は自動で下書きになります。個別に期限を設定していないつもりでも、投稿タイプ全体やワークフロー側でルールが適用されていれば、複数の投稿が対象になる可能性があります。
今回、個別に期限を設定していない投稿まで対象になったのは、この仕組みによるものだと考えられました。
つまり、知らないうちに全投稿へ自動ルールが登録されていた可能性がある、ということです。
PublishPress FutureとScheduled Actionsの確認方法
PublishPress Futureを使っている場合は、現在の設定だけでなく、過去に登録された予約処理が残っていないかも確認しておきましょう。
ここが非常に重要です。
設定画面で自動処理をOFFにしていても、すでに作成済みのアクションが残っている場合、後から実行される可能性があります。
PublishPress Futureで確認する項目
まず、PublishPress Future側の設定を確認します。
- WordPress管理画面にログインする
- PublishPress Futureの設定画面を開く
- 投稿タイプごとの期限設定を確認する
- Automatically create actionsが有効になっていないか確認する
- ワークフロー設定で、全投稿に自動適用されるルールがないか確認する
- 期限到来時の動作が「Draft」「Trash」「Delete」になっていないか確認する
特に注意したいのは、全投稿に対して自動的に期限アクションを作成する設定です。
意図せず有効になっていると、公開済みの記事に対して下書き化や削除の処理が登録される可能性があります。
また、期限到来時のアクションが「Delete」や「Trash」になっている場合は要注意です。誤作動や設定ミスがあったときの影響が大きくなります。
Scheduled Actionsで確認する項目
次に、Action Scheduler側に過去の予約処理が残っていないか確認します。
WooCommerceや一部のプラグインを使用している環境では、管理画面内にScheduled Actionsの一覧が表示されることがあります。環境によって表示場所は異なりますが、ツールメニューやステータス関連の画面から確認できる場合があります。
確認したいのは、次のような項目です。
- ステータスが「Pending」または「Failed」になっている処理がないか
- 投稿ステータスを変更するようなアクションが残っていないか
- 同じ時刻に大量のアクションが登録されていないか
- PublishPress Futureに関連するアクション名がないか
- 過去の日付のまま未実行になっている処理がないか
もし不審なアクションが残っている場合は、すぐに削除する前に、スクリーンショットやメモを残しておくのがおすすめです。
あとから原因を調べるときに、「どの処理が、いつ、どの投稿に対して実行されたのか」を確認しやすくなります。
Automatically create actionsがOFFでも起きた理由
今回ややこしかったのが、投稿タイプ設定でAutomatically create actionsをOFFにしていても、すでに登録されているスケジュールは消えないという点です。
この設定は、あくまで「今後作成する投稿に自動で期限を付けるかどうか」を制御するものです。
つまり、過去に登録されたアクションや、すでにキューに入っている予約処理まで自動的に削除してくれるわけではありません。
たとえば、以前の設定で何らかの期限アクションが作成されていた場合、その後にAutomatically create actionsをOFFにしても、登録済みのアクションが残っていれば、条件が揃ったタイミングで実行される可能性があります。
ここは見落としやすいポイントです。
「今はOFFにしているから大丈夫」と思っていても、過去に作られた処理が残っている場合があります。今回も、以前に設定されたルールが有効なまま残り、WP-Cronが再開したタイミングで一気に実行された可能性が高いと考えられます。
ベーシック認証とCron停止の関係
今回もう一つ大きな要素だったのが、ベーシック認証をサイトに適用していた点です。
制作中のサイトや公開前のテスト環境では、ベーシック認証をかけることがあります。外部から見られないようにするためには便利ですが、環境によってはWordPress自身の通信にも影響することがあります。
WordPressでは、自分自身のサイトにアクセスする「ループバックリクエスト」が使われることがあります。予約投稿やスケジュールイベント、プラグインの自動処理などに関係する重要な仕組みです。
しかし、ベーシック認証によってこのループバックリクエストが正常に通らない場合、WP-Cronがうまく動かないことがあります。
その結果、期限処理がキューに溜まり続けることがあります。
そして、ベーシック認証を解除した瞬間、WP-Cronが再び動き、溜まっていた処理がまとめて実行される。
今回のログ上の時刻と挙動は、この流れとかなり一致していました。
もちろん、すべての環境で必ず同じことが起きるわけではありません。ただ、ベーシック認証中に予約投稿やプラグインの自動処理が動かない場合は、WP-Cronやループバックリクエストへの影響を疑った方がよいです。
アクセスログで確認したいポイント
サーバーのアクセスログを確認できる場合は、投稿が変更された時刻の前後で、次のようなリクエストがないか見てみましょう。
POST /wp-cron.php
POST /wp-admin/admin-ajax.php?action=as_async_request_queue_runnerwp-cron.phpはWordPressのスケジュール処理に関係するファイルです。
admin-ajax.php?action=as_async_request_queue_runnerは、Action Schedulerの非同期処理に関係するリクエストとして記録されることがあります。
これらが投稿変更時刻と近いタイミングで記録されている場合、人の手動操作ではなく、自動処理によって投稿ステータスが変わった可能性があります。
ログを見るときは、次の点も合わせて確認すると切り分けしやすくなります。
- 投稿が変更された時刻とログの時刻が近いか
- 同じ時間帯に複数回
wp-cron.phpが実行されていないか - 管理画面の投稿編集ページへのアクセスが残っているか
- 不審なIPアドレスからログイン試行がないか
- セキュリティプラグインのログに異常がないか
自動処理の可能性が高いとはいえ、不正アクセスの確認もあわせて行っておくと安心です。
安全に期限機能を使うための設定
期限機能自体はとても便利です。
キャンペーン終了後に記事を非公開にしたい場合や、期間限定情報を自動で整理したい場合には、PublishPress Futureのようなプラグインは役に立ちます。
ただし、全投稿に自動ルールを適用する設定は慎重に扱う必要があります。
一般的なWordPressの運用であれば、次のような使い方が安全です。
- 全投稿に自動適用されるワークフローは使わない、または慎重に設定する
- 投稿タイプのAutomatically create actionsは必要がない限りOFFにする
- 必要な投稿だけ手動で期限を設定する
- 期限到来時の動作はDeleteよりもPrivateやカテゴリ変更を検討する
- 設定変更後はScheduled Actionsに残っている処理を確認する
期限到来時のアクションも、DraftやDeleteではなく、Privateを選ぶと影響を抑えられる場合があります。
特にSEOを重視するサイトでは、誤って下書きや削除になるリスクは避けたいところです。公開URLが突然404になったり、インデックスから外れたりすると、検索流入にも影響する可能性があります。
| 期限到来時の動作 | リスク | おすすめ度 |
|---|---|---|
| Delete / 完全削除 | 復旧が難しく、SEO面の影響も大きい | 低い |
| Trash / ゴミ箱 | 復旧はできるが、公開URLは表示されなくなる | 低〜中 |
| Draft / 下書き | 管理画面から戻せるが、公開URLは一時的に消える | 中 |
| Private / 非公開 | 公開状態は変わるが、完全削除より安全 | 比較的高い |
| カテゴリ変更 | 公開状態を維持したまま整理できる場合がある | 高い |
「期限が来たら削除する」という設定は一見便利ですが、実運用ではかなりリスクがあります。どうしても使う場合は、対象投稿を限定し、バックアップ体制も整えておいた方がよいです。
再発防止のために見直したいポイント
今回のようなトラブルを防ぐためには、定期的にScheduled Actionsを確認し、不要なワークフローが残っていないかチェックすることが大切。特に、次のようなタイミングでは確認しておくと安心です。
- サイト公開前にベーシック認証を解除するとき
- PublishPress Futureの設定を変更したとき
- プラグインを有効化・無効化したとき
- WordPressやプラグインを大きく更新したとき
- 予約投稿や期限付き投稿を大量に扱ったあと
また、WP-Cronが正常に動作しているかも確認しておきたいポイントです。
サイトへのアクセスが少ない場合や、ベーシック認証・アクセス制限を使っている場合は、WP-Cronが期待通りに動かないことがあります。必要であれば、サーバー側のcronでwp-cron.phpを定期実行する方法も検討できます。
ただし、サーバーcronを設定する場合は、二重実行や設定ミスにも注意が必要です。サーバー環境によって適切な設定方法は異なるため、レンタルサーバーのマニュアルや管理画面の仕様を確認しながら進めるのがおすすめです。
よくある質問
WordPressの投稿が勝手に下書きになるのは不正アクセスですか？
不正アクセスの可能性もゼロではありません。ただし、複数の投稿が同じ時刻に変更され、リビジョンが増えていない場合は、プラグインやWP-Cronによる自動処理を疑った方が自然です。アクセスログ、ログイン履歴、Scheduled Actionsを確認して判断しましょう。
PublishPress Futureを無効化すれば解決しますか？
今後の処理を止めるという意味では有効な場合があります。ただし、過去に登録された予約処理が残っている可能性もあるため、プラグインを無効化するだけで安心とは言い切れません。Scheduled Actionsに残っている処理も確認した方が安全です。
Automatically create actionsをOFFにしたのに投稿が下書きになるのはなぜですか？
Automatically create actionsは、今後作成する投稿への自動アクションを制御する設定です。すでに登録済みの予約処理やワークフローが残っている場合、それらが後から実行される可能性があります。
ベーシック認証をかけているとWP-Cronに影響しますか？
環境によっては影響することがあります。WordPress自身が自分のサイトへアクセスするループバックリクエストが認証で止まると、WP-Cronや予約投稿、プラグインの自動処理が正常に動かない場合があります。
完全削除された投稿は復元できますか？
バックアップがあれば復元できる可能性があります。ゴミ箱にも残っていない場合は、WordPress管理画面だけでは戻せないこともあるため、サーバーバックアップ、データベースバックアップ、プラグインのバックアップ機能を確認しましょう。
参考情報
まとめ
今回の投稿一斉下書き・完全削除問題は、不正アクセスでも単純なシステム障害でもなく、PublishPress Futureのワークフロー、WP-Cron、Action Schedulerの挙動が重なった結果だと考えられました。
Automatically create actionsをOFFにしていても、過去に登録されたルールや予約処理が残っていれば、それらが後から実行される可能性があります。
さらに、ベーシック認証によってWP-Cronやループバックリクエストが止まっていた場合、解除後に溜まっていた期限処理が一気に実行されることもあります。
便利な自動化機能ほど、その仕組みを理解して使うことが大切です。特に、次の3点は必ず確認しておきたいところ。
- PublishPress Futureのワークフローや自動アクションが意図せず有効になっていないか
- Scheduled Actionsに過去の予約処理が残っていないか
- WP-Cronやループバックリクエストが正常に動作しているか
設定を見直し、ワークフローを整理し、必要な投稿だけに期限を設定する。これだけでも、同じトラブルを防げる可能性はかなり高くなります。
WordPressの自動化は便利ですが、裏側で何が動いているのかを知らないと、思わぬタイミングで大きな影響が出ることがあります。
今回の経験が、WordPress運用の安心材料になれば幸いです。
