WordPressの「Scheduled Actions」画面に、見覚えのない処理や大量の失敗が並び、
マルウェアではないかと不安になっていませんか？
特にWooCommerceを使うサイトでは、意味の分かりにくいhook名、長い引数、同じ処理の繰り返しが表示されます。
ただし、知らない名前や失敗件数だけを理由に一括削除すると、注文、決済、在庫、メールなどの正規処理まで止める危険があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、Action Schedulerの記録を保全し、正規処理と不審処理を分けて安全に止める順序を解説します。
- Action SchedulerとWP-Cronの違い
- 調査前に保存するアクション一覧・引数・ログ
- hook・group・args・statusから登録元を追う方法
- 正規の予約処理を壊さず不審アクションを止める順序
- 削除後に再登録される時の確認場所
結論から言うと、最初に行うのは削除ではなく、対象アクションのhook、group、args、日時、status、ログを保存し、
その処理を登録したプラグインやコードを特定することです。
登録元を止めないままアクションだけ消しても、次のアクセスや定期処理で再び作られます。
証拠保全、正規性の判断、登録元の停止、対象限定のキャンセル、再発確認という順で進めましょう。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
Action Schedulerの不審な処理は名前だけで削除しない
Action Schedulerの一覧に知らない処理があっても、hook名だけで不正と断定しないことが重要です。
この仕組みは、注文処理、定期購入、Webhook、メール、データ同期などをバックグラウンドで実行するため、多くのプラグインが利用しています。
長いhook名や引数は正規プラグインでも使われる
hookは、実行時に呼び出される処理の名前です。
開発者が衝突を避けるため、会社名やプラグイン名を接頭辞にした長い名前を付けることは珍しくありません。
argsには注文ID、商品ID、メール送信対象、同期位置などが保存されることがあります。
英数字が長い、JSONのように見える、同じ形式が多数あるという特徴だけでは、マルウェアの根拠になりません。
failedやpendingが多い時は障害と侵害を分ける
failedが増える原因には、外部APIの停止、PHPエラー、メモリ不足、タイムアウト、決済設定の不備、プラグイン競合があります。pendingの滞留も、アクセス不足やWP-Cron停止、ループバック通信失敗などで起こります。
一方、停止済みプラグイン名を装ったhookが増える、未知の外部送信を伴う、実行直後に不審ファイルや管理者が作られる場合は調査優先度が上がります。
件数だけではなく、実行内容と同時刻の変化を結び付けてください。
- 導入記録のないプラグイン名やランダムなhookが突然増えた
- argsに見覚えのない外部URL、ファイルパス、ユーザーIDが含まれる
- 実行時刻と不審PHP、管理者追加、投稿改ざんの時刻が一致する
- キャンセルしても同じhook・args・groupで短時間に再登録される
- 停止済み・削除済み機能の処理が現在も新規作成され続ける
Action SchedulerとWP-Cronの違いを理解して調査範囲を分ける
Action SchedulerとWP-Cronは連携しますが、同じ一覧を別名で表示しているわけではありません。
Action Schedulerは、将来または可能な限り早くWordPress hookを実行するためのジョブキューで、独自のアクションとログを管理します。
WP-CronはAction Schedulerを起動する経路の一つ
公式説明では、Action SchedulerはWordPress標準のWP-Cronへ登録した処理を使い、通常は毎分キューの実行を試みます。
管理画面リクエストの終了時にもpendingを確認し、必要なら非同期のループバック要求を開始します。
つまり、WP-Cron側にはAction Schedulerを動かす入口が見え、個々の注文メールやWebhookはAction Scheduler側に見える構造です。
WP-Cronイベントだけを消しても個別アクションの記録は残り、逆に個別アクションだけを消しても登録元が再作成することがあります。
専用テーブルとログが正規性を判断する材料になる
現在のAction Schedulerは、一般にactionscheduler_actions、actionscheduler_groups、actionscheduler_claims、actionscheduler_logsなどの専用テーブルを使います。
実際の接頭辞はwp_とは限らないため、稼働サイトのデータベース接頭辞を先に確認してください。
actionsにはhook、status、日時、args、group、claimなどが保存され、logsには作成、開始、完了、失敗の経過が残ります。
不審かどうかは、1行だけではなく、groupとログ、同じhookの正常履歴、登録元コードを合わせて判断します。
Action Schedulerの調査前に一覧・引数・ログを保全する
Action Schedulerの不審処理を止める前に、調査対象と正常な比較対象を保存してください。
キャンセルや削除を先に行うと、作成元、実行失敗の理由、再登録の間隔を追いにくくなります。
Scheduled Actions画面を条件付きで記録する
管理画面の「ツール → Scheduled Actions」、またはWooCommerce導入時の「WooCommerce → ステータス → Scheduled Actions」を開きます。
権限や版によって場所が異なるため、表示されない場合はプラグイン構成と権限を確認します。
まずpending、in-progress、failed、canceled、completeを分け、hook、scheduled date、group、claim ID、action IDを記録します。
検索欄ではhook、args、action ID、claim IDを使い、似たアクションの前後関係も残してください。
- Action ID、hook、group、status、予定日時、作成日時
- argsの原文と、個人情報を伏せた調査用コピー
- 作成・開始・完了・失敗を示すログ全文
- 同じhookの正常例と、最初に異常が出た時刻
- 有効・無効・削除済みを含むプラグインとテーマの一覧
- 同時刻のアクセスログ、PHPエラー、ファイル・ユーザー変更
argsに含まれる機密情報を公開しない
argsには注文番号、メールアドレス、Webhook先、内部パスなどが入る場合があります。
スクリーンショットやログを外部へ共有する時は、値を黒塗りするだけでなく、画像のメタ情報や元ファイルも確認してください。
キュー全体ではなく対象周辺を先に固定する
アクションが何万件もあるサイトで、最初から全件を手作業で読む必要はありません。
異常が始まった時間帯、特定hook、特定group、同じargs形式、連続失敗したclaimを軸に対象を絞ります。
比較用に、その直前まで正常に完了していた同じhookも保存してください。
正常例との差が予定時刻だけなら滞留、argsやgroupが変わっていれば設定変更や別の登録元を疑う、といった切り分けができます。
Action Schedulerのhook・group・args・ログから登録元を追う
Action Schedulerの正規性は、hook名をインターネット検索するだけでなく、サイト内で誰が登録し、誰が実行時のcallbackを提供するかまで確認します。
名前の一致は手掛かりであって、正規ファイルから登録された証明ではありません。
hookとgroupを導入済み機能へ対応付ける
最初にhookの接頭辞とgroupを、現在有効なプラグイン、以前使っていたプラグイン、独自開発、テーマ、mu-pluginsへ対応付けます。
公式配布物のコードや開発元ドキュメントと照合し、同名hookを登録する箇所を確認してください。
argsと実行後の変化を照合する
argsはcallbackへ渡される材料です。
正規の注文処理なら実在する注文や購読と対応するか、同期処理なら正規サービスの設定と一致するかを確認します。
不審な外部URL、公開領域内のPHPパス、存在しないユーザー、同じ長い文字列が含まれる場合は、ログとファイル変更を時系列で照合します。
ただし値の意味を理解しないまま変更すると、シリアライズや処理の依存関係を壊すため、DBセルの直接編集は避けてください。
Action Schedulerのログで作成から失敗までを追う
公式仕様では、アクションの作成、開始、完了、失敗がログへ記録されます。
実行方法がWP-CLIかWP-Cronか、失敗時のエラーが残っているかを確認し、突然の登録なのか、以前から正常に動いていた処理なのかを分けます。
同じ時刻に複数の正規アクションも失敗しているなら、PHPやDB、外部API、サーバー資源など全体障害の可能性があります。
特定hookだけが失敗し、実行後に異常な変更が起きるなら、登録元とcallbackを優先調査します。
Action Schedulerを管理画面とWP-CLIで読み取り確認する
Action Schedulerの調査は、管理画面で概要とログを確認し、件数が多い場合はWP-CLIで条件を絞ると効率的です。
最初は一覧取得と個別取得に限定し、run、cancel、delete、cleanなど状態を変える操作は行いません。
WP-CLIでpendingとfailedを別々に取得する
SSHとWP-CLIを安全に使える環境では、WordPressルートで次のように候補を確認します。
利用できるサブコマンドやオプションはAction Schedulerの版で異なるため、先にhelpも確認してください。
wp action-scheduler --help
wp action-scheduler action list --status=pending --format=table
wp action-scheduler action list --status=failed --format=table
wp action-scheduler action get <ACTION_ID> --format=json<ACTION_ID>は確認対象のIDへ置き換えます。
出力に個人情報や外部送信先が含まれる場合があるため、ターミナル履歴、共有ログ、チケットへの貼り付けにも注意してください。
件数とstatusの偏りを確認する
pendingだけが増えているなら、実行経路、ループバック、WP-Cron、サーバー負荷を確認します。
failedだけが急増した場合は、最初の失敗時刻とエラー、直前の更新、外部APIの状態を確認してください。
in-progressが長時間残る場合は、claimが解放されていない、PHP処理が停止した、重いcallbackがある可能性があります。
見かけ上のstatusを直すためにDBを直接更新せず、処理中かどうかと公式の復旧方法を確認します。
- pending: 予定日時を過ぎた滞留、実行経路、同じgroupの件数
- in-progress: 開始時刻、claim、PHPプロセス、実行時間
- failed: 最初のエラー、直前の更新、同じhookの正常履歴
- canceled: 誰が何の理由で止めたか、登録元が再作成するか
- complete: 実行後の正常結果と、異常変更が発生していないか
大量キューをforce実行しない
滞留を早く解消しようとして、全件を一括実行したり--forceを付けたりすると、決済、メール、外部API、DBへ負荷を集中させる危険があります。
hookやgroupを分けた実行も、処理順の暗黙依存を崩す場合があります。
公式WP-CLI文書も、hook・group単位の実行では、時刻順の依存が保証されなくなるケースへ注意を促しています。
調査中は実行せず、原因と依存関係を確認してから保守時間帯に計画してください。
Action Schedulerの不審アクションを登録元から安全に止める
Action Schedulerの不審アクションを止める時は、対象アクションのキャンセルより先に、再登録するコードや侵入口を止めます。
順序を逆にすると、削除直後に新しいIDで同じ処理が作られ、証拠と作業時間を失います。
正規機能への影響と代替手段を確認する
hookが注文、定期購入、返金、在庫、メール、Webhook、顧客同期に関係する場合、停止による業務影響を先に確認します。
保留中の注文や外部連携があるなら、担当者と復旧時間、再実行方法、顧客案内を決めてください。
不審に見えても正規プラグインが作った処理なら、プラグイン設定の停止、保守モード、開発元手順など、データ整合性を保てる方法を優先します。
登録元コードを隔離してから対象だけをキャンセルする
登録元が不審プラグインなら、いきなり削除せず、正規配布物との比較、設定、依存機能、ログを保存します。
通常プラグインだけでなく、mu-plugins、テーマ、独自スニペット、自動読み込み設定、外部デプロイも確認してください。
登録元を停止・隔離し、再登録されない状態を作った後に、対象IDまたは十分に特定したhookだけをキャンセルします。
別プラグインも使う共通hook、同じgroup内の正常処理、完了済みログまで一括削除してはいけません。
- 対象アクション、ログ、DB、プラグイン構成を保全する
- hookとcallback、登録APIを呼ぶコードを特定する
- 業務影響と正規アクションの依存関係を確認する
- 不審な登録元または侵入口を停止・隔離する
- 対象ID・hookを限定してキャンセルする
- 同じ条件で再登録されないか監視し、主要機能をテストする
DB直接削除と全テーブル初期化を避ける
Action Schedulerのテーブルは、複数プラグインが共有する場合があります。
テーブルを空にする、行を直接削除する、statusだけ書き換える操作は、正規キュー、ログ、外部処理との整合性を壊します。
公式のusage文書でも、アンインストール時は自分のプラグインが作成したアクションだけをキャンセルし、共有テーブル全体を扱わないよう注意されています。
サイト運営者も同じ考え方で、所有者を特定できた対象だけを処理してください。
Action Schedulerが再登録・滞留・失敗する原因を切り分ける
Action Schedulerのアクションを止めた後は、同じhookが再登録されるか、正規キューが流れるか、サイト内部に新しい異常が出ないかを確認します。
再登録そのものは定期処理の正常動作でもあるため、登録元と内容で判断してください。
再登録元を通常プラグイン以外にも広げて探す
プラグインを無効化しても戻る場合は、mu-plugins、テーマのfunctions.php、コードスニペット、drop-in、サーバー側Cron、外部管理ツールを確認します。
正規プラグインを削除しても、残ったローダーや別の侵害コードが同名hookを作る可能性があります。
滞留はWP-Cron・ループバック・資源不足を確認する
pendingが予定時刻を過ぎて増える場合は、WP-Cron無効化、低アクセス、Basic認証、WAF、DNS、SSL、ループバック失敗、PHPメモリや実行時間を確認します。
キューの内容が正規でも、起動経路が止まれば処理は進みません。
failedが多い場合は、最初のエラーを基点にします。
後続の失敗は同じ原因の連鎖かもしれないため、最新エラーだけでなく、最初に正常から異常へ変わったログを探してください。
復旧後は正常な基準と変更記録を残す
復旧後は、主要hook、group、通常件数、実行間隔、完了時間、エラー0件の状態を基準として保存します。
プラグイン更新で新しいhookが増えた場合は、更新日と変更理由を記録すると次回の誤判定を減らせます。
同時にWordPress本体・テーマ・プラグインを正規版へそろえ、不審管理者、Application Passwords、ファイル、データベース、アクセスログも確認します。
予約処理だけ直しても、侵入口やバックドアが残れば別の方法で再発します。
Action Schedulerの不審処理に関するよくある質問
Action Schedulerの不審処理を安全に確認・停止するまとめ
Action Schedulerに見覚えのない処理や大量の失敗があっても、名前と件数だけで削除しないでください。
まずhook、group、args、status、日時、claim、ログを保全し、同じhookの正常例と登録元コードを照合します。
Action SchedulerはWP-Cronを起動経路の一つとして使いますが、個々のアクションとログを独自に管理します。
WP-Cronの記事だけでは分からない専用画面、専用テーブル、アクションログを確認することが重要です。
- 停止前の一覧・args・ログ・DB・構成を保存した
- 正規プラグインのhookと不審な登録元を分けた
- 業務影響とアクション間の依存関係を確認した
- 登録元を止めてから対象だけをキャンセルした
- 同じ条件で再登録されないか監視した
- 注文・決済・メール・同期・サイト全体を動作確認した
不審な予約処理の実行後に、管理者追加、ファイル改ざん、外部送信、検索スパムなどが起きている場合は、Action Schedulerだけの問題ではありません。
現在の状態を保全し、WordPress全体とサーバーを対象にした復旧調査へ切り替えてください。
Action Schedulerの不審処理を自分で判断できない時は
不審な予約アクションが再登録される、実行元が見つからない、注文や決済への影響が怖い場合は、
クイックレスキューが証拠保全から登録元の特定、マルウェア駆除、復旧後確認まで対応します。
- 見覚えのないhookやargsが大量に登録されている
- キャンセルしても同じアクションが何度も戻る
- failedの原因が障害かマルウェアか判断できない
- WooCommerceの注文・決済を止めずに調査したい
- WordPress全体に不審ファイルや不正管理者がないか確認したい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
