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>&1WP-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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressのパフォーマンス低下は「アクセス減少時」に起こる？共有サーバーの落とし穴と対策
WordPressサイトのパフォーマンス対策といえば、多くの場合はアクセス急増（スパイク）への備えを連想する。キャンペーンの開始や新製品の発表時にサーバーがダウンしないよう、リソースの増強やキャッシュの強化を行うのが一般的だ。
しかし、実は「アクセスが減少していく時期」にこそ、サイトの健全性を損なう大きなリスクが潜んでいる。キャンペーンが終わり、トラフィックが平時に戻る過程で、共有サーバー環境では予期せぬパフォーマンスの劣化が発生することがあるのだ。
なぜアクセスが減っているのに、サイトの動作が重くなるのか。その裏側には、多くのホスティングサービスが採用している「リソースの割り当てロジック」と、WordPress特有のバックグラウンド処理の仕組みが深く関わっている。
共有サーバーの不都合な真実：アクセスが減ると「後回し」にされる理由
多くの安価なレンタルサーバー（共有サーバー）では、1台の物理的なサーバー内に数百から数千のウェブサイトを収容している。ここで問題となるのが「オーバーセリング（過剰販売）」という手法だ。
オーバーセリングとは、物理的なサーバーの総リソース（CPUやメモリ）よりも多くの容量を、顧客に割り当てて販売することを指す。これは銀行の仕組みに似ている。すべての預金者が一度に現金を全額引き出そうとしない限り、銀行は預かっている以上の資金を運用できる。サーバーも同様に、すべてのサイトが同時にフル稼働しないことを前提に運用されている。
リソースの動的割り当てという名の「選別」
共有サーバー環境では、限られたリソースを効率よく分配するために「動的リソース割り当て」が行われる。これは、アクセスが多い「活発なサイト」に優先的にリソースを振り向け、アクセスが少ない「静かなサイト」への割り当てを削る仕組みだ。
つまり、あなたのサイトのアクセスが減少すると、サーバー側は「このサイトには今はリソースを割く必要がない」と判断する。その結果、余ったリソースは他の高トラフィックなサイトへと奪われてしまう。パフォーマンスがインフラの質ではなく、トラフィック量に依存してしまうという逆転現象が起きるのだ。
スロットリングによる制限の正体
リソースの制限は「スロットリング（Throttling）」と呼ばれる手法で実行される。これには主に3つの形態がある。
- CPU制限：計算処理能力に上限を設ける
- RAM（メモリ）割り当て：一度に扱えるデータ量を制限する
- I/O制限：ディスクへの読み書き速度を抑える
アクセスが多いときはリソースを消費し尽くすことで制限に触れるが、アクセスが少ないときは「最初からパイが小さく設定される」ため、わずかなバックグラウンド処理でも制限に引っかかるようになる。
スロットリングが招く「サイレント障害」：WP-Cronの遅延とデータベースの肥大化
フロントエンドの表示速度が落ちる以上に深刻なのが、WordPressのバックグラウンド処理への影響だ。WordPressには「WP-Cron（ダブルピー・クロン）」という、予約投稿やプラグインの更新チェック、データベースの最適化などを自動で行う仕組みが備わっている。
WP-Cronは、誰かがサイトにアクセスしたタイミングで実行される。アクセスが減少すると、そもそも実行される機会が減る。さらにリソースを制限された環境では、ようやく実行のチャンスが巡ってきても、CPUやメモリの不足によって処理が途中で失敗したり、実行が大幅に遅れたりする事態を招く。
蓄積される技術的負債
バックグラウンド処理の失敗は、目に見えないところでサイトの健康状態を悪化させる。例えば、以下のような問題が蓄積していく。
- データベース最適化の失敗：不要なデータ（リビジョンや一時データ）が削除されず、クエリの実行速度が徐々に低下する
- キャッシュのクリーンアップ遅延：古いキャッシュが残り続け、ディスク容量を圧迫する
- セキュリティスキャンの未完了：脆弱性の発見が遅れ、リスクが高まる
これらの問題は、アクセスが回復したときに自動的に解消されるわけではない。むしろ、肥大化したデータベースが足かせとなり、次のアクセス増の際にサーバーが耐えきれなくなる原因を作る。
共有環境と独立環境の視覚的イメージ
共有サーバーでのリソース奪い合いと、独立した環境の違いを視覚的に理解するためのデモを作成した。左側は他サイトの影響を受ける共有環境、右側は常に一定のリソースが確保された環境をイメージしている。
(アクセス減少時)
(アクセス減少時)
このデモは、共有環境では自分のサイト（青）が他サイト（赤）に圧迫されるのに対し、コンテナ型では常に一定の枠が保証される概念を示している。
独自の分析：トラフィックの「凪」がサイトの健康寿命を削るメカニズム
ここで独自の分析を加えたい。アクセス減少時のパフォーマンス低下は、単なる一時的な速度低下ではなく、サイトの「健康寿命」を削る慢性疾患のようなものだ。筆者はこれを「メンテナンス・デット（保守の負債）」の蓄積と呼んでいる。
自動車に例えるなら、レース（アクセス急増）のときだけオイル交換をし、街乗り（アクセス減少）のときは整備を一切受けられない状態に近い。整備不良のまま放置された車は、次に高速道路に乗った瞬間に故障する。WordPressサイトも同様で、平時のメンテナンスが滞ることで、サイトの構造自体が脆弱になっていくのだ。
SEOへの悪影響という負のループ
さらに深刻なのは、Googleの「CWV（Core Web Vitals / コアウェブバイタル）」への影響だ。アクセスが少ない時期にスロットリングによってページ読み込みが遅くなると、検索エンジンはそのサイトの評価を下げる可能性がある。
「アクセスが減る」→「リソースを削られる」→「表示が遅くなる」→「SEO評価が落ちる」→「さらにアクセスが減る」という負のスパイラルに陥る危険性がある。このループは、一度入り込むと抜け出すのが非常に困難だ。
コンテナ技術が実現する「トラフィックに左右されない」安定性
こうした共有サーバーの構造的な問題を解決するのが、Linuxコンテナ技術を活用したホスティングだ。Kinstaなどのモダンなホスティングサービスが採用しているこの方式では、各ウェブサイトが完全に独立した「コンテナ」内で動作する。
コンテナ型の最大の特徴は、他のサイトとリソースを共有しない点にある。あなたのサイトに割り当てられたCPUやメモリは、たとえアクセスがゼロになっても、他のサイトに転用されることはない。常にあなたのサイト専用の待機リソースとして確保され続ける。
キャッシュ機能もトラフィックに依存しない
また、多層構造のキャッシュシステムも安定性に寄与する。エッジキャッシュやサーバーレベルのキャッシュは、トラフィックの増減に関わらず一貫して動作する。Cloudflareなどのグローバルネットワークを利用したエッジキャッシュなら、オリジンサーバーにリクエストが届く前に応答できるため、アクセス減少時でも高速なレスポンスを維持できる。
静的アセット（画像やCSS）を配信するCDN（Content Delivery Network）も同様だ。これらはサーバーの負荷状況とは無関係に、世界中の拠点から最適な速度で配信される。
運用コストを最適化する：なぜ安定期こそ高品質なホスティングが必要なのか
「アクセスが少ない時期は、安いサーバーにダウングレードしてコストを抑えたい」と考えるのは自然な心理だ。しかし、WordPressサイトの複雑さはトラフィック量に比例して減るわけではない。
プラグインの動作、セキュリティスキャン、管理画面でのコンテンツ編集、ステージング環境でのテスト。これらすべての作業には、安定したインフラが必要だ。特にサイトを管理するエンジニアやディレクターにとって、管理画面のレスポンスがトラフィック減少時に悪化することは、作業効率を著しく低下させる要因となる。
長期的なビジネス成長を支えるインフラ選び
予測可能なインフラは、ビジネスの計画を容易にする。メンテナンス作業がスケジュール通りに完了し、WP-Cronが確実に実行され、管理画面が常にサクサク動く。この「当たり前」の環境を維持することが、長期的なサイト運営における最大のコスト削減につながる。
トラフィックの波に合わせてサーバーを右往左往させる管理コストや、劣化したパフォーマンスの調査に費やす時間を考えれば、最初からリソースが保証された環境を選ぶメリットは大きい。ホスティングは単なる「場所貸し」ではなく、サイトの健康を守る「維持装置」として捉えるべきだ。
この記事のポイント
- 共有サーバーでは「オーバーセリング」により、アクセスが少ないサイトのリソースが他へ転用されるリスクがある
- リソース制限（スロットリング）は、WP-Cronなどのバックグラウンド処理を停止させ、技術的負債を蓄積させる
- データベースの最適化不足やSEO評価の低下は、アクセス減少期に進行する「サイレント障害」である
- コンテナ型ホスティングなら、トラフィックの増減に関わらず専用リソースが確保され、安定した運用が可能になる
- 管理画面のレスポンスやメンテナンスの確実性を維持するためには、安定期こそ高品質なインフラが重要だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験