WooCommerce 11.0が公開、ゲスト注文の連携と大規模ストア向けパフォーマンス改善
WooCommerce 11.0が2026年8月4日にリリースされた。このバージョンは551件のプルリクエストを含む、近年最大規模のアップデートのひとつだ。バックログの整理とコアの基盤強化に重点が置かれ、ゲスト購入者が過去の注文を自分のアカウントに紐づけられる機能や、アナリティクスの信頼性向上、大規模ストア向けのパフォーマンスチューニングが行われている。
本記事では、運用者と開発者の両方にとって重要な変更点を中心に、WooCommerce 11.0の中身を解説する。カタログが数千点を超える店舗でも体感できる速度改善や、新しいゲスト注文管理の仕組みを詳しく見ていこう。
大規模ストアで効くパフォーマンス最適化
WooCommerce 11.0のパフォーマンス改善は、商品点数が多く、過去の注文データが膨大な店舗ほど効果を発揮する。内部クエリの最適化を中心に、Store APIの改良や注文処理中の在庫ステータス管理がより軽量になった。
内部クエリの見直しとStore APIの改善
大規模ストアでは、商品一覧や注文履歴を表示するたびにデータベースへ重いクエリが走り、管理画面やフロントエンドのレスポンスが悪化しがちだ。今回のアップデートでは、こうしたクエリに不要なJOINやサブクエリが含まれていないかを洗い出し、インデックスを活用したシンプルな構造に書き換える修正が多数含まれている。
Store APIも改良された。Headless構成やカスタムストアフロントでWooCommerceを利用している場合、商品データの取得やカート操作がより高速になる。具体的には、APIの内部で使用するキャッシュ戦略とデータ構造が見直され、同じデータを重複して取得する無駄が省かれた。
在庫管理まわりの処理が軽量化
注文が入るたびに在庫数を更新し、ステータスを変更するフローもチューニングされている。特に、バックエンドで複雑な在庫チェックを繰り返していた処理が一本化され、注文から在庫確保までの一連の流れがスリムになった。商品バリエーションが多い店舗では、これによる管理画面の操作感向上が期待できる。
上記のように、規模が大きくなるほど効果が明確になる。クエリ最適化は累積的なため、今後のWooCommerceバージョンでも継続して改善が加えられる見込みだ。
ゲスト購入とアカウントの連携がスムーズに
WooCommerce 11.0では、購入後のアカウント作成フローがさらに強化された。これまではゲストとして注文した後にアカウントを作っても、過去の注文は引き継がれなかった。今回のアップデートで、ゲスト購入者が自分の過去注文を見つけ、メール認証を通じてアカウントに紐づけられるようになっている。
メール認証による過去注文の引き継ぎ
具体的な流れはこうだ。ゲスト購入者が新たにアカウントを作成すると、WooCommerceはそのメールアドレスに関連する過去のゲスト注文を検索し、一覧を提示する。ユーザーは「自分の注文」として承認するかどうかを選択でき、承認されるとアカウントの注文履歴に統合される。この仕組みにより、リピート購入への心理的なハードルが下がり、顧客ロイヤルティの向上にもつながる。
この機能は、WooCommerce 9.5で導入された購入後アカウント作成の自然な拡張だ。単に「購入後にアカウントを作れる」だけでなく、「過去の購入履歴もまとめて管理できる」ようになる点が、顧客体験として大きな進化といえる。
アナリティクス報告の信頼性が向上
WooCommerce 11.0では、売上分析や注文レポートの精度が高められた。イベントトラッキングの確実性が増し、返金データが売上APIの数値に正しく反映されるようになった。また、過去データのインポートに失敗した場合、再試行できる機能が追加され、管理画面からエラー状況を確認しやすくなっている。
返金が売上レポートに正しく反映
これまでのアナリティクスでは、返金処理が行われても売上APIの数値が更新されないケースがあった。11.0では、返金も含めた正味売上が計算されるため、ダッシュボードの数字と実際の会計がずれる問題が解消される。
失敗時のリトライ機能でデータ欠損を防止
大量の履歴データを一括でインポートする際、サーバーの制限などで処理が途切れることがある。今回のアップデートで、インポートに失敗したジョブの一覧が表示され、管理者が手動でリトライできるようになった。大規模なデータ移行やバックアップからの復元作業が、より安全で扱いやすくなっている。
開発者向けアップデートと基盤整理
WooCommerce 11.0には、開発者向けの変更も数多く含まれている。Abandoned Cartメールやブロックベースのメール編集、新しい設定UIといった試験的機能が追加されたほか、Product Editor Betaの完全廃止、内部依存ライブラリであるAction Schedulerが4.0.0へ更新されている。
Action Scheduler 4.0.0への移行
Action Schedulerとは、WordPressのWP-Cronに代わる形で定期的なジョブや遅延タスクを実行するライブラリで、WooCommerceの購読や自動メールなど多くの機能を支えている。今回、依存バージョンが4.0.0に引き上げられ、ジョブの登録と実行の仕組みが改善された。具体的には、処理の重複防止やエラーハンドリングが強化され、長期間のタスクでも安定して動くようになっている。
試験的機能と廃止スケジュール
Abandoned Cartメールは、カゴ落ちしたユーザーに自動でリマインダーを送る機能だが、これまではサードパーティのプラグインに頼る必要があった。今回、コアに試験的実装が加わり、将来的な標準機能化への布石となっている。ブロックベースのメール編集や新しい設定UIも、まだ試験的ではあるが、より直感的な管理画面を目指す方向性を示している。
一方、Product Editor Betaは今回のバージョンで完全に廃止された。すでに新しい商品編集エディタが安定版へ移行しており、以前のベータ版に依存していたカスタムコードがある場合は、早めの移行が推奨される。
この記事のポイント
- WooCommerce 11.0は551件のPRを含む大規模アップデートで、基盤整理とパフォーマンス改善が中心
- ゲスト購入者が過去の注文をメール認証でアカウントに紐づけられるようになり、リピート率向上に寄与
- 大規模ストア向けにクエリ最適化とStore API改良が行われ、管理画面とフロントエンドのレスポンスが向上
- 返金データが売上APIに正しく反映され、アナリティクスの信頼性が高まった
- 開発者向けにはAction Scheduler 4.0.0への移行や試験的機能の追加、Product Editor Betaの廃止が行われた
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce HPOSが48時間で100万件以上のアクションスケジューラ完了ジョブを生成した原因と対処法
WooCommerceサイトでデータベースサイズが突然急増し、wp_actionscheduler_actionsテーブルに数百万件もの完了済みジョブが蓄積している場合、HPOSデータ同期バッチプロセスが無限ループを起こしている可能性が極めて高い。ここでは症状の見分け方から原因の特定、停止、クリーンアップまで、具体的な手順をまとめる。
HPOS関連のデータベース肥大化が疑われる症状
以下のような兆候が複数同時に現れたら、Action Schedulerの暴走を疑ってよい。
- データベース容量が短時間で急激に増加する（数GB単位）
- PHPエラーログのファイルサイズが異常に大きくなる
- データベースのロックエラーやデッドロックが頻発する
- 管理画面やフロントエンドで「INSERT command denied」などのエラーが出る
- サーバーのバックグラウンドプロセスがほぼ常時稼働し続ける
- 注文件数が数百件なのにAction Schedulerテーブルだけが肥大化している
これらの症状は、単体では他の原因もあり得るが、データベース内の完了ジョブが異常に増えている点が最大の特徴だ。
Action Schedulerが暴走していないか確認する方法
まずはデータベースを直接調べ、どのジョブが何件蓄積しているかを確かめる。WP-CLIが使えるならコマンドラインから、そうでなければphpMyAdminやAdminerで以下のクエリを実行する。
完了ジョブの数とフック名を調べる
データベースに直接問い合わせる場合、以下のSQLで完了状態のジョブをフック名別に集計できる。
SELECT hook, COUNT(*) AS cnt
FROM wp_actionscheduler_actions
WHERE status = 'complete'
GROUP BY hook
ORDER BY cnt DESC
LIMIT 10;ここで wc_run_batch_process の件数が数十万〜数百万件と突出していれば、疑いは濃厚だ。
引数（args）から発行元を特定する
次に、そのフックの引数を見る。例えば以下のクエリで先頭の数件を取得する。
SELECT action_id, args, scheduled_date_gmt
FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process'
AND status = 'complete'
ORDER BY action_id DESC
LIMIT 5;引数フィールドにはシリアライズされたデータが入っている。その中に Automattic\WooCommerce\Internal\DataStores\Orders\DataSynchronizer という文字列が含まれていれば、HPOSのデータ同期機構がバッチを発行している証拠だ。
注文件数との比較で異常を確信する
管理画面のWooCommerce → 注文で表示される注文の総数は、データベースの wp_posts（またはHPOS有効時は wp_wc_orders）で確認できる。注文が600件しかないのに、同期バッチの完了ジョブが100万件もあるなら、明らかにループが発生している。
動作中のループをリアルタイムで観察する
WP-CLIが利用可能なら、以下のコマンドでペンディング状態のジョブを監視する。
wp action-scheduler list --hook=wc_run_batch_process --status=pending定期的に実行すると、常に1件だけ存在し、それが完了するとすぐに新たなペンディングが生まれるパターンが観測できるはずだ。これはキューが滞留しているのではなく、バッチ自身が次をスケジュールし続ける無限ループであることを示す。
なぜHPOS DataSynchronizerが無限ループを起こすのか
HPOS（High-Performance Order Storage）を有効にすると、WooCommerceは注文データを従来の wp_posts テーブルから専用テーブルへ移行する。この移行やデータの同期を担うのが DataSynchronizer であり、バックグラウンドでバッチ処理を走らせる。
通常は同期が完了すればバッチは停止するが、何らかの設定不整合やエラーにより「同期が完了したと見なされず、次のバッチが即座に予約される」状態に陥ることがある。具体的には、各バッチが「保留中 → 完了 → 次バッチ予約」というサイクルを際限なく繰り返す。注文数が少なくても、このループによってAction Schedulerのテーブルだけが急激に肥大化し、データベース全体を圧迫する。
このループが起きているかどうかは、データベースを直接見るまで気づきにくい。キャッシュやRedis、WP Rocketなどを最初に疑いがちだが、真因はAction Schedulerの中にある。
データベースの安静化とクリーンアップの手順
原因がHPOSの同期バッチループと判明したら、ループを止め、完了ジョブを削除し、再発を防ぐ。以下の手順を順に実行する。
同期状態のリセット
まず、現在のHPOS同期状況を確認する。WP-CLIで次のコマンドを実行する。
wp wc hpos sync statusここで「status: in-progress」や「pending」が表示される場合、同期が完了しておらず、バッチが動き続けている可能性がある。強制的にリセットし、不要な同期を停止するには以下を実行する。
wp wc hpos sync resetリセット後、再度ステータスを確認し「idle」や「complete」になっていれば、新たなバッチはスケジュールされなくなる。
完了ジョブの一括削除
100万件単位の完了ジョブを削除するには、Action Schedulerが提供するWP-CLIコマンドを使うのが安全で高速だ。以下のコマンドで、完了状態のジョブをすべて削除できる。
wp action-scheduler clean --status=complete特定のフックのみを削除したい場合は、プレーンなSQLで一度に削除してもよいが、必ず事前にデータベース全体のバックアップを取ること。
DELETE FROM wp_actionscheduler_actions
WHERE hook = 'wc_run_batch_process' AND status = 'complete';さらに、関連するログテーブル（wp_actionscheduler_logs）の不要レコードも合わせて削除すると、ディスク容量を大きく回復できる。ただし、こちらは慎重に扱う必要があるため、まずは完了ジョブの削除だけでも効果は大きい。
テーブル最適化で容量を解放
大量のレコードを削除した後は、データベースが断片化し、実際の容量が解放されないことがある。phpMyAdminなどから該当テーブルに対して「最適化（OPTIMIZE TABLE）」を実行するか、以下のSQLを流す。
OPTIMIZE TABLE wp_actionscheduler_actions;
OPTIMIZE TABLE wp_actionscheduler_logs;これにより、削除した領域がOSに返却され、データベース全体のサイズが縮小する。
再発防止とHPOS設定の見直し
ループが再発しないように、WooCommerceのHPOS設定を確認する。管理画面の WooCommerce → 設定 → 詳細設定 → 機能 から「High-performance order storage（高性能注文ストレージ）」が有効になっているか、そして「互換モードを有効にする」や「データ同期を有効にする」オプションがどのようになっているかをチェックする。
既に全注文がHPOSテーブルに完全移行済みで、互換モードが不要なら、これらの同期オプションを無効化することで、バックグラウンドのバッチ処理そのものを止められる。ただし、テーマやプラグインが古い注文データ参照方法を使っている場合は注意が必要だ。
また、WP-CLIのcronを定期的に監視し、Action Schedulerのジョブ数が異常増加していないかをチェックする仕組みをサーバー監視に組み込むと早期発見につながる。
よくある質問
HPOSが有効かどうかはどこで確認できるか
管理画面の「WooCommerce → 設定 → 詳細設定 → 機能」に移動し、「注文データストレージ」の項目で「High-performance order storage」が選択されていれば有効だ。WP-CLIでは wp wc hpos status で確認できる。
完了ジョブを削除してもサイト動作に影響はないか
Action Schedulerの完了ジョブは過去の処理履歴であり、削除しても現在予約されているジョブや進行中の処理には影響しない。ただし、監査やデバッグ目的で残したい場合は、削除前にバックアップを取ることを強く推奨する。
WP-CLIが使えないレンタルサーバーではどうすればよいか
phpMyAdminなどのデータベース管理ツールから直接SQLで削除できる。プラグイン「WP Crontrol」などを利用すれば、Action Schedulerの一覧を管理画面で確認し、フックごとに手動で削除することも可能だが、件数が多い場合はSQLのほうが現実的だ。
同期をリセットしてもループが再発するのはなぜか
根本原因が解消されていないと再発する。たとえば、同期オプションが有効なまま残っていたり、カスタムコードがバッチをトリガーし続けているケースがある。同期の完全停止を試み、プラグインの干渉も疑いながら一つずつ切り分ける必要がある。
この記事のポイント
- データベースの急激な肥大化とAction Schedulerの完了ジョブ数に注目する
- フック名「wc_run_batch_process」と引数からHPOSの同期バッチループを特定する
- WP-CLIで同期状態をリセットし、完了ジョブを一括削除してテーブルを最適化する
- HPOSの同期設定を見直し、不要なバッチ処理を完全に止めて再発を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Action Scheduler 4.0.0の変更点、WooCommerceのテーブル肥大化を抑制
WooCommerceの裏側で動くAction Schedulerは、多くのデータベースの中でも特に負荷の高いテーブルを持つ。高トラフィックのストアでは、完了した処理を削除する仕組みが追いつかず、失敗したアクションは一切消えないまま蓄積し続けることが問題になっていた。4.0.0はその根本に手を入れたメジャーアップデートだ。失敗アクションの保持期間をデフォルトで3か月に制限し、クリーンアップを専用のデイリージョブとして分離した。これにより、アクションとログのテーブルサイズが際限なく肥大化する状態を防げる。
本バージョンは7月28日リリース予定のWooCommerce 11.0にバンドルされ、すでにWordPress.orgで単独でも入手可能だ。互換性を壊す変更が複数含まれているため、拡張機能を開発している人や大規模ストアを運用している人は、4.0.0での動作検証を早めに始める必要がある。
4.0.0が狙う根本的なテーブル肥大化の抑制
Action SchedulerはWordPress管理画面での注文処理やメール送信など、WooCommerceの非同期ジョブを支えるコアライブラリだ。これまでは小さなバグフィックスが中心で、3.9.x台を刻んでいた。しかし今回、互換性を壊す複数の変更をまとめて投入するため、バージョン番号が4.0.0にジャンプした。WordPress形式のバージョン付けでは3.9.3の次は3.10ではなく4.0だから、意図的な動きといえる。
失敗アクション 無期限で保持
クリーンアップ キュー処理のついでに小分け
専用ジョブ 毎日3時に一括処理
バッチサイズ 最低250件、最大まで連続
このデモが示すように、クリーンアップの仕組みが根本から見直された。特に失敗アクションが自動削除の対象になった点と、削除処理が専用ジョブとして分離された点が、テーブル肥大化を抑える大きな柱だ。
互換性の壁を越えるメジャーバージョンアップ
4.0.0ではWordPress 6.8以上の動作要件が課せられ、WordPress 7.0との互換性も明示された。これは今後のWooCommerceエコシステムにとって、基盤環境を一段上げる布石でもある。また、後述するユニークアクションの判定変更は、同じフックでも引数が異なれば別物として生成されるようになり、既存コードの重複防止ロジックに影響を与える可能性がある。
失敗アクションの保持期間を3か月に制限
これまでAction Schedulerは、完了とキャンセルのアクションだけを削除していた。失敗ステータスのアクションは、自らフィルターで追加しない限り永久に残り続けた。多忙なストアではこれが原因でアクションテーブルとログテーブルが無制限に成長し、自力で回復できない状況に陥っていた。4.0.0では、失敗アクションが発生から3か月を超えると自動的に削除される専用のクリーンアップパスがデフォルトで有効化された。
3か月という期間は、典型的な四半期会計サイクルに合わせつつ、障害調査のための十分な猶予を残す設計だ。より厳格なデータ保持ポリシーを持つストアでは、action_scheduler_retention_period_for_failedフィルターで秒単位の期間を変更できる。あるいはaction_scheduler_enable_failed_action_cleanupに__return_falseを渡せば、4.0.0以前と同じく無期限保持に戻せる。
注目すべき点は、既にaction_scheduler_default_cleaner_statusesフィルターで失敗ステータスを追加していた場合、そちらの設定が優先されることだ。その場合は、4.0.0の新しい失敗専用パスではなく、既存のクリーンアップサイクルに統合されるため、動作が変わることはない。
クリーンアップを専用のデイリージョブに分離
旧バージョンでは、古いアクションの削除はキューの各バッチ処理にインラインで埋め込まれ、一度に少量しか処理されなかった。そのため、処理量の多いストアではクリーンアップが追いつかず、テーブルが大きくなる一方だった。4.0.0では、クリーンアップを独立したタスクとし、サイト時刻で毎日午前3時に一度だけ実行する方式に変更された。
この方式により、削除処理が通常のキュー処理のパフォーマンスに影響を与えなくなり、大規模テーブルでも遅延なく追いつけるようになった。バッチサイズはaction_scheduler_cleanup_batch_sizeフィルターで変更可能で、デフォルトの250件より少なくも多くもできる。もし従来のインライン方式に戻したい場合は、カスタムキュークリーナーを実装すれば自動的にそちらが使われるが、ほとんどのサイトではその必要はないだろう。
ユニークアクションの判定に引数が加わった
as_enqueue_async_action()やスケジュール系関数の$uniqueパラメータは、同じアクションが重複して生成されるのを防ぐためのものだ。従来はフック名とグループだけを比較していたため、引数が異なる2つのアクションでも同一とみなされ、後のほうが黙って破棄される挙動だった。これが4.0.0では、引数の内容まで含めて同一性を判定するように変更された。
この変更は互換性を壊すため、特に注意が必要だ。旧来のフックとグループだけの重複防止に依存していたコードでは、これまでよりも多くのアクションが生成されるようになる。意図しない大量のジョブがキューに積まれないよう、$uniqueを使っている箇所は必ず見直してほしい。
WooCommerceサイトへの実務的な影響と移行のポイント
4.0.0はWooCommerce 11.0のバンドルに先立って単独テストが可能だ。大規模ストアや独自の拡張機能でAction Schedulerを利用している開発者は、以下の3点を中心にステージング環境で動作検証を行うことを推奨する。
- 失敗アクションの保持ポリシー
3か月のデフォルトが自社のデータ保持要件に合致するか確認し、必要ならフィルターで調整する。 - ユニークアクションの重複防止ロジック
$unique=trueを使用している全箇所を洗い出し、引数が異なるアクションが正しく生成されるかテストする。 - クリーンアップの実行タイミング
デイリージョブへの移行により、削除がバッチ処理から外れたことで、期待していたリアルタイム性が失われていないか確認する。必要に応じてカスタムクリーナーを実装する。
開発元のWooCommerceチームはGitHubでフィードバックを募集しており、予期しない動作があれば早期に報告するよう呼びかけている。WooCommerce 11.0の正式リリースまで1か月あまり。致命的なトラブルを回避するために、今のうちに4.0.0との互換性テストを済ませておくことが賢明だ。
この記事のポイント
- Action Scheduler 4.0.0はテーブル肥大化を防ぐため、クリーンアップの仕組みを根本から見直したメジャーアップデート
- 失敗アクションがデフォルトで3か月後に自動削除されるようになり、保持期間のカスタマイズも可能
- クリーンアップが専用のデイリージョブとして実行され、キュー処理のパフォーマンスに影響しなくなった
- ユニークアクションの重複チェックに引数が含まれるようになり、既存の重複防止ロジックへの影響に注意が必要
- WooCommerce 11.0へのバンドル前に単体テストを行い、互換性の問題を早期に発見することが重要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験