WooCommerceでCPU使用率が100%になった時の原因と対処法

WooCommerceでCPU使用率が100%になった時の原因と対処法

WooCommerceでCPU使用率が100%に張り付く場合、プラグイン競合ではなくAction Schedulerのタスク滞留とWP-Cronの実行負荷が主な原因だ。タスクの件数とアクセスログを確認すれば、負荷の発生源を特定できる。

WooCommerceのCPU使用率が100%になる3つの原因

WooCommerceを標準テーマで運用し、有効プラグインがWooCommerceだけでもCPU使用率が100%に達することがある。この局面でプラグイン同士の競合を疑うのは的が外れている。次に挙げる3つの要素を優先して調べる必要がある。

Action Schedulerのタスクが蓄積して再試行を繰り返す

Action SchedulerはWooCommerceがバックグラウンド処理を管理する仕組みで、商品の定期更新や決済後のメール送信などをキューに積んで実行する。失敗したタスクは自動的に再試行されるため、根本原因が解決しないまま失敗と再試行がループするとCPU負荷が際限なく上がる。

WP-Cronがページを読み込むたびに起動する

WordPress標準のWP-Cronは、実際のサーバーcronとは異なり、ページが開かれるたびに起動する仕組みだ。アクセスが一定数あると、同じタスクが何度も起動してPHPの実行が重なり、結果的にCPUを使い切ってしまう。

ボットやAPIリクエストが継続的に飛んでくる

検索エンジンのクローラーや悪質なボットがフロントエンドを巡回すると、動的なWooCommerceページは通常のブログ記事より重い処理が走る。管理画面へのajax通信やwc-ajax経由のリクエストも、回数が増えるとCPU使用率を押し上げる。

原因切り分けの流れを4つのステップで示す。各手順の詳細は次項以降で詳しく解説する。

スケジュール済みアクションでタスク滞留を確認する

最初に確認するのはWooCommerce内部のタスクキューだ。管理画面の「WooCommerce」メニューから「ステータス」を開き、「スケジュール済みアクション」タブを選択する。ここにAction Schedulerが管理する全タスクの実行状況が表示される。

件数から異常を判断する

画面には「完了」「保留中」「期限超過（Past-due）」「失敗」「キャンセル済み」などのタブがあり、それぞれの件数が表示される。正常に動いている店舗なら「完了」以外の数は少ない。保留中が数百件、失敗が数十件を超えている場合は、タスクが処理されずに溜まっている状態だ。

失敗するタスクの共通点を調べる

「失敗」タブを開き、どのフック名のタスクが何度も失敗しているかを確認する。同じフック名で多数の失敗が並んでいるなら、その処理が起因で再試行がループしている可能性が高い。タスクをクリックするとエラーログが表示されるため、根本原因を特定する手がかりになる。

システムレポートで環境全体を確認する

「WooCommerce → ステータス → システムレポート」には、WooCommerceとWordPressのバージョン、PHPのメモリ上限、サーバー環境などの情報がまとまっている。PHPのメモリ上限が低すぎる場合やWooCommerceが古いバージョンのままの場合もCPU負荷の原因になるため、レポートの値を確認して必要な更新を検討する。

アクセスログから負荷の発生源となるURLを特定する

タスク滞留が見つからない場合、次に負荷の高いリクエストをログから探す。サーバーのアクセスログを確認できるか、レンタルサーバーの管理画面から生ログをダウンロードする。CPU使用率が高かった時間帯のログを抽出し、PHPが実行されるURLの出現頻度を数える。

頻出するURLのパターン

特にCPUを消費しやすいURLには明確な傾向がある。

• admin-ajax.php への大量のPOSTリクエスト
• /?wc-ajax=checkout などのカート・決済系リクエスト
• /wp-json/wc-analytics/ 配下への連続アクセス
• wp-cron.php への直接アクセス
• フロントエンドの商品ページやカテゴリページへのボット巡回

admin-ajax.php のログに action= パラメータが記録されていれば、その値でどの機能が呼ばれているかが分かる。たとえば action=heartbeat なら管理画面の自動更新機能、action=woocommerce_xxx なら注文処理やカート処理が走っている。

Query Monitorプラグインで計測する

開発環境やステージング環境なら、Query Monitorプラグインを有効にして実際に重いページを開いてみる。各ページで実行されたPHPプロセス、データベースクエリ、フックの実行時間が表示されるため、どの処理が負荷を生んでいるかが可視化される。本番環境では一時的に有効化して計測後すぐ無効化する。

WP-Cronをサーバーcronに切り替えて負荷を分散する

WP-Cronがページ読み込みのたびに起動する仕組みを止めるには、wp-config.phpにDISABLE_WP_CRONを定義して、サーバー側のスケジューラから1分間隔で実行する構成に切り替える。これにより、ページアクセスと関係なくcronが1回だけ実行される。

wp-config.phpに1行追加する

wp-config.phpの編集はFTPやサーバーのファイルマネージャから行う。次の行を追加する。

define( 'DISABLE_WP_CRON', true );

この1行を追加すると、WordPressがページ読み込みのたびにWP-Cronを起動しなくなる。まだサーバーcronを設定していない段階では、スケジュール投稿や定期タスクが動かなくなるため、追加後すぐに次の設定を行う。

サーバー側のcronを設定する

サーバーのcron設定で、1分おきにWordPressの予定タスクを実行するよう登録する。WP-CLIが使える環境なら、次のコマンドを登録する。

*/1 * * * * cd /home/user/public_html && wp cron event run --due-now > /dev/null 2>&1

WP-CLIが使えない場合は、直接wp-cron.phpを実行する方法もある。

*/1 * * * * php /home/user/public_html/wp-cron.php > /dev/null 2>&1

パスは環境によって異なるため、WordPressのインストールディレクトリに合わせて変更する。サーバーcronに切り替えると、アクセスが集中する時間帯でもページ読み込みと独立してタスクが処理されるため、CPU使用率が安定しやすくなる。

ボットアクセスを制限して外部からの負荷を減らす

クローラーやボットがフロントエンドを大量に巡回してCPUを圧迫している場合、CDNのレート制限や悪質なボットへの遮断が必要になる。まずアクセスログで同一IPからのリクエスト頻度を確認し、明らかに異常なパターンを特定する。

管理画面の分析APIへのアクセスを確認する

/wp-json/wc-analytics/ 配下への大量アクセスは、外部ツールやボットが原因のことが多い。管理画面上の分析にしか使わないなら、特定のIP以外からのアクセスをサーバー側で制限する設定を検討する。

CDNやWAFでレート制限をかける

CloudflareなどのCDNやWAF（Webアプリケーションファイアウォール）を利用している場合、フロントエンドへのリクエスト頻度に上限を設けられる。同一IPからの短時間での大量アクセスを自動的にブロックする設定を有効にすると、ボットによるCPU消費を大幅に削減できる。

よくある質問

CPU使用率100%の原因がWooCommerceなのかどうやって確かめる？

有効プラグインをWooCommerce以外すべて無効化して標準テーマに切り替える。それでも負荷が続けばWooCommerce内部の処理が原因と絞れる。さらに管理画面の「スケジュール済みアクション」を開き、失敗タスクの有無を確認する。

Action Schedulerの失敗タスクはどうやって削除する？

スケジュール済みアクション画面で失敗タスクを選択し、一括操作から「削除」を選ぶ。削除前に、同じフック名が繰り返し失敗していないか確認する。根本原因を直さないまま削除しても、再び失敗タスクが積み上がる。

wp-cron.phpへの直接アクセスを止めるには？

wp-config.phpに define( 'DISABLE_WP_CRON', true ); を追加する。これでページ読み込み時のWP-Cron起動が止まり、サーバーcronに切り替えて定期的に実行する。両方の設定をセットで行うことが重要だ。

管理画面が重くてスケジュール済みアクションを開けない場合は？

サーバー側からデータベースを直接調査する。PhpMyAdminなどで wp_actionscheduler_actions テーブル（プレフィックスは環境による）を開き、ステータス列が失敗や保留中の行数をカウントする。原因になるタスクが分かれば、関連する処理を安全な方法で停止する。

対策してもCPU使用率が下がらない場合は？

Action Schedulerの整理とWP-Cronの切り替え、ボット遮断をすべて実施した上で、それでもCPUが100%に達するならサーバーのスペック不足が考えられる。トラフィック量と同時接続数を確認し、必要ならプランを上げるか、より処理能力の高い環境を検討する。

この記事のポイント

• Action Schedulerのタスク滞留を最初に疑う
• WP-Cronのページ読み込み起動を止めてサーバーcronへ切り替える
• アクセスログでadmin-ajax.phpやwc-ajaxの頻度を調べる
• 失敗タスクの根本原因を修正しないと再発する
• ボット対策とレート制限で外部からの負荷を減らす

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている