WordPressのAction Schedulerに不審な処理がある時の確認・停止手順

WordPressの「Scheduled Actions」画面に、見覚えのない処理や大量の失敗が並び、
マルウェアではないかと不安になっていませんか？

特にWooCommerceを使うサイトでは、意味の分かりにくいhook名、長い引数、同じ処理の繰り返しが表示されます。
ただし、知らない名前や失敗件数だけを理由に一括削除すると、注文、決済、在庫、メールなどの正規処理まで止める危険があります。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、Action Schedulerの記録を保全し、正規処理と不審処理を分けて安全に止める順序を解説します。

結論から言うと、最初に行うのは削除ではなく、対象アクションのhook、group、args、日時、status、ログを保存し、
その処理を登録したプラグインやコードを特定することです。

登録元を止めないままアクションだけ消しても、次のアクセスや定期処理で再び作られます。
証拠保全、正規性の判断、登録元の停止、対象限定のキャンセル、再発確認という順で進めましょう。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計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が増える、未知の外部送信を伴う、実行直後に不審ファイルや管理者が作られる場合は調査優先度が上がります。
件数だけではなく、実行内容と同時刻の変化を結び付けてください。

クイックレスキュー

WordPressの不審なPHPファイルは放置していい？危険度と削除判断の考え方

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イベントだけを消しても個別アクションの記録は残り、逆に個別アクションだけを消しても登録元が再作成することがあります。

クイックレスキュー

WordPressのWP-Cronに不審な処理がある時の確認と安全な削除手順

専用テーブルとログが正規性を判断する材料になる

現在のAction Schedulerは、一般にactionscheduler_actions、actionscheduler_groups、actionscheduler_claims、actionscheduler_logsなどの専用テーブルを使います。
実際の接頭辞はwp_とは限らないため、稼働サイトのデータベース接頭辞を先に確認してください。

actionsにはhook、status、日時、args、group、claimなどが保存され、logsには作成、開始、完了、失敗の経過が残ります。
不審かどうかは、1行だけではなく、groupとログ、同じhookの正常履歴、登録元コードを合わせて判断します。

テーブル名や列構成は導入版・移行状態で差が出ます。推測したSQLをいきなり更新に使わず、管理画面かWP-CLIの読み取り確認を先にしてください。

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を使い、似たアクションの前後関係も残してください。

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を登録する箇所を確認してください。

クイックレスキュー

WordPressに見覚えのないプラグインが増えた時の確認と安全な削除手順

argsと実行後の変化を照合する

argsはcallbackへ渡される材料です。
正規の注文処理なら実在する注文や購読と対応するか、同期処理なら正規サービスの設定と一致するかを確認します。

不審な外部URL、公開領域内のPHPパス、存在しないユーザー、同じ長い文字列が含まれる場合は、ログとファイル変更を時系列で照合します。
ただし値の意味を理解しないまま変更すると、シリアライズや処理の依存関係を壊すため、DBセルの直接編集は避けてください。

Action Schedulerのログで作成から失敗までを追う

公式仕様では、アクションの作成、開始、完了、失敗がログへ記録されます。
実行方法がWP-CLIかWP-Cronか、失敗時のエラーが残っているかを確認し、突然の登録なのか、以前から正常に動いていた処理なのかを分けます。

同じ時刻に複数の正規アクションも失敗しているなら、PHPやDB、外部API、サーバー資源など全体障害の可能性があります。
特定hookだけが失敗し、実行後に異常な変更が起きるなら、登録元とcallbackを優先調査します。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順

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を直接更新せず、処理中かどうかと公式の復旧方法を確認します。

大量キューをforce実行しない

滞留を早く解消しようとして、全件を一括実行したり--forceを付けたりすると、決済、メール、外部API、DBへ負荷を集中させる危険があります。
hookやgroupを分けた実行も、処理順の暗黙依存を崩す場合があります。

公式WP-CLI文書も、hook・group単位の実行では、時刻順の依存が保証されなくなるケースへ注意を促しています。
調査中は実行せず、原因と依存関係を確認してから保守時間帯に計画してください。

Action Schedulerの不審アクションを登録元から安全に止める

Action Schedulerの不審アクションを止める時は、対象アクションのキャンセルより先に、再登録するコードや侵入口を止めます。
順序を逆にすると、削除直後に新しいIDで同じ処理が作られ、証拠と作業時間を失います。

正規機能への影響と代替手段を確認する

hookが注文、定期購入、返金、在庫、メール、Webhook、顧客同期に関係する場合、停止による業務影響を先に確認します。
保留中の注文や外部連携があるなら、担当者と復旧時間、再実行方法、顧客案内を決めてください。

不審に見えても正規プラグインが作った処理なら、プラグイン設定の停止、保守モード、開発元手順など、データ整合性を保てる方法を優先します。

登録元コードを隔離してから対象だけをキャンセルする

登録元が不審プラグインなら、いきなり削除せず、正規配布物との比較、設定、依存機能、ログを保存します。
通常プラグインだけでなく、mu-plugins、テーマ、独自スニペット、自動読み込み設定、外部デプロイも確認してください。

クイックレスキュー

WordPressのmu-pluginsに不審なファイルがある時の確認と安全な削除手順

登録元を停止・隔離し、再登録されない状態を作った後に、対象IDまたは十分に特定したhookだけをキャンセルします。
別プラグインも使う共通hook、同じgroup内の正常処理、完了済みログまで一括削除してはいけません。

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、ファイル、データベース、アクセスログも確認します。
予約処理だけ直しても、侵入口やバックドアが残れば別の方法で再発します。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント

わたしの実務では、不審アクションを消した時刻より、最初に登録された時刻と再登録された条件を追う方が、原因コードへ早く到達できます。

Action Schedulerの不審処理に関するよくある質問

Action Schedulerがあるだけでマルウェア感染ですか？

いいえ。Action SchedulerはWooCommerceをはじめ、多くの正規プラグインが使うバックグラウンド処理の仕組みです。hook、group、args、ログ、登録元コード、実行後の変化を確認し、複数の根拠で判断してください。

failedのアクションは全部削除してよいですか？

一括削除は避けてください。決済や注文処理の失敗が含まれる可能性があります。最初のエラーと業務影響を確認し、原因を直してから、開発元の手順に沿って再実行・キャンセル・整理を選びます。

Action Schedulerのテーブルを空にすれば直りますか？

おすすめできません。複数プラグインの正規キューとログを失い、注文や外部連携の整合性を壊すおそれがあります。バックアップを取り、登録元と対象を特定して、公式API・管理画面・対応するWP-CLI操作を使います。

キャンセルしても同じアクションが戻るのは感染ですか？

必ずしも感染ではありません。定期処理を維持する正規機能が再登録する場合があります。戻る時刻、hook、args、group、作成元コードを照合し、正規の再登録条件と一致しない場合は侵害調査へ進んでください。

Action Schedulerの不審処理を安全に確認・停止するまとめ

Action Schedulerに見覚えのない処理や大量の失敗があっても、名前と件数だけで削除しないでください。
まずhook、group、args、status、日時、claim、ログを保全し、同じhookの正常例と登録元コードを照合します。

Action SchedulerはWP-Cronを起動経路の一つとして使いますが、個々のアクションとログを独自に管理します。
WP-Cronの記事だけでは分からない専用画面、専用テーブル、アクションログを確認することが重要です。

不審な予約処理の実行後に、管理者追加、ファイル改ざん、外部送信、検索スパムなどが起きている場合は、Action Schedulerだけの問題ではありません。
現在の状態を保全し、WordPress全体とサーバーを対象にした復旧調査へ切り替えてください。

Action Schedulerの不審処理を自分で判断できない時は

不審な予約アクションが再登録される、実行元が見つからない、注文や決済への影響が怖い場合は、
クイックレスキューが証拠保全から登録元の特定、マルウェア駆除、復旧後確認まで対応します。

不審なアクションを一括削除する前に、現在の一覧とログを保全してご相談ください。初期費用・調査費用0円で状況を確認します。