タグアーカイブ BFCM

WooCommerceクーポン自動適用、209行のコードで約1万3000行を削減

WooCommerceクーポン自動適用、209行のコードで約1万3000行を削減

WooCommerce.comは、BFCM(ブラックフライデー・サイバーマンデー)2025に向けてクーポン自動適用の仕組みを内製化し、それまで使っていたサードパーティ製プラグインを廃止した。削除したコードは実に約12,888行、新たに書いたコードはわずか209行である。WooCommerceコアのクーポン機能をそのまま活かし、再発明を避けることで、大幅なコード削減と安定性の向上を両立させた。

WooCommerce Developer Blogの記事で、開発者のRonny Shani氏がこのプロジェクトの全貌を公開した。BFCM本番では数万人規模の顧客に利用され、クーポン起因のバグはゼロだったという。返品率の低減や顧客単価の上昇といった副次効果も確認されており、少ないコードがもたらすビジネスインパクトを示す好例だ。

従来のサードパーティ製プラグイン
プラグイン 段階的割引ロジックを独自実装
プラグイン 使用制限・有効期限などを自前で再実装
プラグイン 通貨対応も独自処理
12,888行 削除対象となったコード量
内製化された自動適用プラグイン
小プラグイン 「自動適用」チェックボックスのみ追加
WooCommerceコア is_valid()で既存の検証ロジックを活用
WooCommerceコア 複数通貨対応も標準機能で動作
209行 新たに書いたコード量
削除(サードパーティ)  追加(内製化)  自動発動の指示役  検証・実行を担うWooCommerce本体

このデモでは、従来の肥大化したアプローチと内製化後のシンプルな構造を対比している。「何でも自前でやろうとする」と「コアの力を借りて指示役に徹する」の差がコード量に直結している点を視覚化した。以下、具体的な実装と成果を見ていく。

少数のコードでクーポンを自動適用する仕組み

この内製プラグインの考え方は極めて明快だ。WooCommerceがもともと持っているクーポンの検証機能(WC_Couponクラスによる使用回数制限・商品制限・有効期限チェックなど)を一切再実装せず、「いつ」「どのクーポンを」「どう適用するか」という判断部分だけを追加する。WooCommerce Developer Blogの著者Ronny Shani氏は「再発明はしない」という原則を掲げ、徹底的にコアに委ねた設計を選んだ。

このアプローチは、WordPressやWooCommerceのエコシステム全般に当てはまる教訓でもある。機能拡張が必要なとき、つい「全部入り」のプラグインを導入したり、独自のロジックを上から書いたりしがちだが、コアがすでに提供している仕組みの上に薄い層を重ねるだけで要件を満たせるケースは少なくない。コードが少なければバグの入り込む余地も減り、保守負荷も下がる。

チェックボックスひとつで制御する設計

管理画面のクーポン編集画面には「Apply coupon automatically(クーポンを自動適用する)」というチェックボックスが追加される。ここにチェックを入れると、該当クーポンの投稿メタ _auto_applyyes が保存される。判定ロジックはこのメタ値を見るだけであり、新たなデータベーステーブルや複雑な設定画面は一切作っていない。

カートが再計算されるタイミングで、プラグインは _auto_apply = yes のクーポン一覧を取得する。この一覧は12時間キャッシュされるため、WooCommerce.comのような高トラフィックサイトでもパフォーマンス上の問題は起きない。取得後は各クーポンに対して WC_Coupon::is_valid() を呼び出し、条件を満たしていれば静かに適用、満たさなくなったら静かに削除する。顧客に余計な通知を見せることもない。

再帰防止とWooCommerce.com固有の対応

実装上の唯一の「厄介なポイント」として、Shani氏は再入(re-entrancy)ガードを挙げている。クーポンを適用する処理自体が woocommerce_after_calculate_totals フックを再度発火させるため、何も対策しないと無限ループに陥る。これを防ぐために static $running フラグを導入し、処理中は再実行をブロックしている。このデバッグは、Shani氏の言葉を借りれば「なかなか楽しめた」類の不具合だったようだ。

また、WooCommerce.comの要件として、BFCMクーポンがサブスクリプション更新や特定の決済フローに適用されないようにする制御も追加されている。こうしたドメイン固有の制約はGitHub上のプルリクエストには含まれていないが、各自のストアで同様の仕組みを実装する際の参考になる。

STEP 1 カート再計算イベント発生
買い物客が商品を追加・数量変更を行うと woocommerce_after_calculate_totals が発火する
STEP 2 自動適用クーポンの取得
_auto_apply = yes のクーポンコード一覧をキャッシュから取得(12時間キャッシュ)
STEP 3 各有効性チェック
WC_Coupon::is_valid() で使用制限・有効期限・商品制限をまとめて検証。コアが処理するため再実装不要
STEP 4 自動適用または自動削除
有効なら適用・無効なら削除。いずれも顧客に通知なし。static $running フラグで再帰を防止
トリガー  取得  検証  適用・削除

上図の流れがカート再計算のたびに実行される。重要なのは、STEP 3の検証部分が完全にWooCommerceコア任せであることだ。プラグイン開発者は「どのクーポンが自動適用対象か」というメタ管理と、「適用・削除のタイミング制御」の2点だけをコード化すればよい。

BFCM 2025本番でのパフォーマンス

BFCM 2025本番でのパフォーマンス

このプラグインが初めて本格稼働したのはBFCM 2025(2025年11月19日〜12月2日)だった。結果は上々で、数万件の完了注文、数万人のユニーク顧客が3段階の割引(20%・30%・40%)を利用し、クーポン起因のバグやシステム停止は一度も発生しなかった。

WooCommerceコアのクーポン機能に乗ったことで、複数通貨対応も標準機能のまま問題なく動作した。多くのマルチカレンシーストアにとって、これは見逃せない恩恵だ。独自実装では通貨ごとの計算ロジックを自前で保守しなければならないが、コア任せならその負荷から解放される。

返品率低下と顧客単価上昇という副産物

数字にもはっきりとした改善が表れた。同記事の報告によれば、返品率は13.1%から7.8%へと約5.3ポイント低下し、顧客あたりの純現金収入は前年比25%増加した。クーポン適用の仕組みそのものが返品率に直接作用したとは考えにくいが、安定した割引適用がスムーズな購買体験につながり、結果的にポジティブな指標改善を後押しした可能性が高い。

SQLでクーポン効果を可視化する方法

同様の分析を自社ストアで行いたい場合、記事では以下のようなSQLクエリが紹介されている。クーポンコードごとに利用注文数とユニーク顧客数を集計するもので、プロモーションの効果測定に使える。

SELECT
    oi.order_item_name                  AS coupon_code,
    COUNT(DISTINCT oi.order_id)         AS orders_with_coupon,
    COUNT(DISTINCT o.customer_id)       AS unique_customers
FROM wp_woocommerce_order_items oi
JOIN wp_wc_orders o ON oi.order_id = o.id
WHERE oi.order_item_type = 'coupon'
  AND oi.order_item_name IN ('sale-20%', 'sale-30%', 'sale-40%')
  AND o.date_created_gmt BETWEEN '2025-11-19 14:00:00' AND '2025-12-02 23:59:59'
  AND o.status IN ('wc-completed', 'wc-processing')
GROUP BY oi.order_item_name
ORDER BY orders_with_coupon DESC;

クーポン名と日付範囲を自社のキャンペーンに合わせて変更すれば、同じ集計が簡単に得られる。データベースへの直接クエリになるため、実行前には必ずバックアップを取得しておきたい。

WooCommerceコアへのフィードバックと今後の展開

WooCommerceコアへのフィードバックと今後の展開

Shani氏はこの仕組みをWooCommerceのコアに取り込むためのプルリクエストをGitHub上で公開している。WooCommerce.com固有の制約は外されているが、_auto_applyメタによる自動適用のコア機能は「WooCommerceがネイティブでサポートすべき」と判断され、将来のリリースに含まれる見込みだ。

現時点でも、このプルリクエストを参考に自前のミニプラグインを構築することは十分可能である。コード量が少ないため、中級者以上のPHP開発者であれば半日もかからずに実装できるだろう。

今後に残る課題

完璧ではない部分もある。ひとつはクーポンのHPOS(High-Performance Order Storage)移行対応だ。_auto_applyメタは現在 wp_postmeta テーブルに保存されているが、注文データがHPOSに移行するタイミングでクエリの見直しが必要になる。Shani氏もこの点を「再検討が必要」として明記している。

もうひとつは、ブロックカート上でクーポン削除ボタンを非表示にするJavaScriptの実装だ。特定のブロックCSSクラス名に依存しているため、WooCommerceのバージョンアップでクラス名が変わると動作しなくなる可能性がある。本格的に汎用化するなら、より堅牢なセレクタ戦略が求められる。

また、BFCM用のクーポン名がハードコードされている点も、汎用プラグインとして配布するには改善の余地がある。現状はフィルターフックで上書きできる設計にはなっているが、管理画面から設定できるようにするほうがより実用的だろう。

「コードを書かない」判断がもたらす安定性

「コードを書かない」判断がもたらす安定性

この事例が示しているのは、技術的な巧みさよりも「何を書かないか」の判断の重要さである。WooCommerceのクーポンシステムは、利用制限、有効期限、商品カテゴリ制限、使用回数制限、複数通貨対応など、すでに十分すぎるほどの検証ロジックを備えている。それらを再実装するかわりに「適用するタイミング」だけをコード化したことで、バグの総量は劇的に減り、保守コストも最小化された。

実際の数字もこの判断の正しさを裏付けている。12,888行を削除して209行に置き換え、BFCM本番でバグゼロ。返品率は13.1%から7.8%に低下し、顧客単価は25%向上した。コードを減らすことはリスクを減らすことであり、それがそのままビジネス指標の改善に直結した好例といえる。

やりがちなアプローチ(Bad)
プラグイン 割引計算 プラグイン 有効期限チェック プラグイン 通貨換算
すべて自前で実装するためコードが膨張し、バグの温床になる
コア活用アプローチ(Good)
小プラグイン 自動適用フラグ管理 WooCommerce is_valid()で全検証
209行で完結。検証ロジックの再実装は一切なし
肥大化・自前実装  スリム・コア活用  制御役  エンジン役(コア)

この対比はWooCommerceに限らず、あらゆるシステム開発に通じる原則だ。既存の仕組みを活かし、本当に必要な差分だけをコード化する。その結果が「12,888行削除して209行追加」という数字であり、BFCM本番でのバグゼロ運用という実績である。

この記事のポイント

  • WooCommerce.comはBFCM 2025に向けてクーポン自動適用を内製化し、12,888行のサードパーティコードを209行のミニプラグインで置き換えた
  • コアの WC_Coupon::is_valid() を活用し、検証ロジックの再実装を徹底的に避ける設計が功を奏した
  • BFCM本番では数万件の注文を処理し、クーポン起因のバグはゼロ。返品率は5.3ポイント低下、顧客単価は25%向上した
  • 将来のWooCommerceコアリリースで _auto_apply メタによる自動適用がネイティブサポートされる見込み。現時点でもGitHub上のPRを参考に自前実装が可能
  • 既存の仕組みを活かして「書かない」判断を積み重ねることが、コード品質とビジネス指標の両方を引き上げる好例