grüumがShopifyとMagentoを評価しWooCommerceを選んだ理由
イギリス発のスキンケアブランド「grüum（グルーム）」は、月間8万件の注文を1人のフルタイム開発者で処理する。2023年、彼らは成長に伴い「WooCommerceでこのまま進むべきか」を再検討した。Shopify PlusとMagento（Adobe Commerce）を4か月かけて評価した結果、grüumはWooCommerceに残る決断を下した。
その背景には、複雑な商品構成を維持するための柔軟性、サブスクリプション収益に比例する手数料の回避、そして顧客データの完全な所有権があった。本記事では、月間8万件規模のEC事業者が下したプラットフォーム選定の判断基準を具体的に解説する。
grüumのビジネスモデルと商品構成の複雑さ
grüumは2016年、英国とオランダで活動する4人の同僚によって設立された。当初は男性向けスキンケアとシェービング製品を中心に約10商品でスタートしたが、現在では年齢や性別を問わず使えるスキンケア、ヘアケア、ボディケア、シェービング製品を展開する。売れ筋はシャンプーバーで、累計数百万個を販売している。
製造は英ストックポートの自社工場で一貫して行い、化粧品科学者も社内に抱える。段ボール包装の徹底、水を使わない製剤、天然成分の使用など、サステナビリティを製品開発の中心に据えている点が特徴だ。
300SKUを支える特殊なバンドル構造
grüumは約300SKUの商品を扱い、単品購入、定期購入（サブスクリプション）、そして独自の組み合わせが可能なバンドル販売を提供している。共同創業者のBethanie Sleigh氏は「私たちは製品の設定方法に多くの独自の仕組みを持っている」と語る。彼らの商品バンドルは「内容物、価格設定、在庫管理」を1つの設定単位として扱う必要がある。
具体的には、顧客は石鹸セットを購入した上で別の製品を追加したり、個別の製品を定期購入に切り替えて割引を受けたりできる。このような複雑な商品構成は、標準的なECプラットフォームの枠組みでは再現が難しい。
オープンソースであるWooCommerceは、条件付きロジックを必要とするバンドル機能があれば、拡張機能を導入するか開発者が独自に作成できる。ほとんどのEC事業者には不要な機能でも、特殊なカタログ構造を持つブランドにとっては事業形態を変えずに販売を継続できることを意味する。
Shopify Plusがgrüumのビジネスに合わなかった理由
grüumが最初に評価したShopify Plusは、ホスティングやセキュリティをプラットフォーム側で管理するSaaS型ECの代表格だ。しかし、grüumの複雑な商品構成を前にして、Shopify Plusではビジネス側をプラットフォームに合わせる必要があった。
プラットフォームに事業を合わせるのか、事業にプラットフォームを合わせるのか
共同創業者のSimon Leonard氏は「Shopify Plusに移行するなら、私たちのビジネスをプラットフォームに合わせて変えなければならなかった」と振り返る。WooCommerce Blogの記事によれば、grüumのバンドル構造（内容物、価格設定、在庫管理を1つの設定単位として扱う）はShopify Plusではネイティブにサポートされていなかった。
この制約は、EC事業者にとって重要な分岐点を浮き彫りにする。プラットフォームのデフォルト機能から外れた運用をしている場合、SaaS型では「ビジネスを変える」か「高額なカスタム開発に投資する」かの二択になりがちだ。WooCommerceはオープンソースであるため、プラットフォームを事業に合わせて拡張できる。Leonard氏は「私たちはWooCommerceを自分たちのビジネスに合わせて機能させることができる。原則を変える必要はない」と結論づけた。
サブスクリプション収益に比例する手数料の重み
grüumにとってサブスクリプション（定期購入）は重要な収益源だ。全収益の10%を占め、平均継続期間は30か月に達する。この定着率の高さゆえに、サブスクリプションのインフラコストは事業の収益性を大きく左右する。
Shopifyはサブスクリプション収益に対して売上の一定割合を手数料として課金する。Leonard氏が試算したところ、サブスクリプション経由で100万ポンド（約1.9億円）から1,000万ポンド（約19億円）の売上がある場合、年間10万ポンド（約1,900万円）規模の手数料が発生する計算になる。
一方、WooCommerce Subscriptionsは定額制の年間ライセンス料で提供される。grüumの規模では、Shopifyの従量課金モデルと比較して大幅なコスト削減につながる。これは「成長すればするほど手数料が増える」モデルと「成長しても固定費で済む」モデルの構造的な違いだ。
この料金体系の違いは、月間8万件の注文を処理するEC事業者にとって年間数百万円規模のコスト差を生む。WooCommerce Blogの記事でも、Leonard氏が「サブスクリプションで100万ポンドや1,000万ポンドの売上があると、すぐに年間10万ポンドの出費になる」と試算したことが紹介されている。
Magento（Adobe Commerce）の運用負荷とコスト構造
grüumが次に評価したMagento（現在のAdobe Commerce）は、エンタープライズ向けの高度なカスタマイズ性を持つオープンソースプラットフォームだ。Shopify Plusとは異なり、Magentoは拡張性の面ではgrüumの要件を満たす可能性があった。
専任の技術チームが不可欠な運用現実
しかし、Magentoの運用には相応の技術リソースが必要になる。サーバー管理、パフォーマンスチューニング、セキュリティパッチ適用、バージョンアップ対応などを継続的に行うには専任の技術スタッフが欠かせない。Leonard氏は「ウェブサイトを運営するために20人のチームを雇うつもりはなかった」と語っている。
grüumの開発チームはフルタイム1人とパートタイムのQAテスター1人という最小構成で運営されている。Magentoの運用に必要なリソースは、この体制では経済的に成立しなかった。拡張性の高さと引き換えに、運用負荷とインフラコストが大きく跳ね上がる点が決定的なマイナス要因となった。
これは中規模EC事業者にとって重要な示唆だ。機能の豊富さや拡張性だけでプラットフォームを選ぶと、運用フェーズで想定外のコストが発生する。自社の技術リソースと運用体制を正確に見積もった上で判断する必要がある。
この比較から見えるのは、ECプラットフォーム選定において「機能の多さ」よりも「自社の運用体制に合うか」が重要だということだ。grüumはMagentoの拡張性を評価しつつも、1人体制で回せる軽量な運用を優先した。
1人の開発者で月間8万件を処理できる運用設計
grüumのWebサイトは、フルタイム開発者1人とパートタイムのQAテスター1人で運用されている。小規模なコンテンツチームが商品登録、ページ作成、日々のコンテンツ更新を担当し、開発者の手を借りることはほとんどない。
非エンジニアが自律的に運営できるツール選定
コンテンツチームはページ作成にGutenberg（WordPressのブロックエディタ）、ナビゲーション管理にMax Mega Menu、SEO対策にYoast SEOを使用している。商品リスティング、プロモーション、季節ごとの更新はすべて開発者の介在なしで完了する。
この分業が成立するのは、WordPressエコシステムに成熟したノーコードツールが豊富に存在するからだ。grüumの開発者は、ルーチン作業ではなく顧客体験の改善や新機能の開発に集中できる。WooCommerce Blogの記事によれば、CTOの試算では「以前なら1年かかっていたタスクがWooCommerceなら1か月で完了する」という。開発速度の差はそのままコスト削減と市場投入の迅速化につながる。
決済基盤としてのWooPayments
決済についても、grüumはWooCommerceネイティブのWooPaymentsを選択した。外部の決済サービスを別途契約するのではなく、WooCommerceに統合された決済基盤を使うことで管理の一元化と手数料の最適化を図っている。プラットフォームと決済が分離していると、売上データの突合や手数料計算が複雑化するが、統合されていれば管理負荷が大幅に下がる。
この構成図からわかるように、grüumの運営は「開発者がルーチン作業から解放されている」点が最大の強みだ。コンテンツチームが自律的に動けるツールを選び、開発者は成長のための改善に専念する。この分業設計が1人体制での月間8万件処理を可能にしている。
データ所有権がもたらす事業の独立性
grüumがWooCommerceに残る決断をした理由の最後の1つが、データ所有権だ。SaaS型ECプラットフォームでは、顧客データや購買履歴はプラットフォーム側のデータベースに保存され、事業者が自由にアクセスできるとは限らない。移行時にはデータのエクスポートに制限があったり、追加費用が発生したりするケースもある。
30か月の顧客関係を自社で保有する意味
grüumのサブスクリプション顧客の平均継続期間は30か月だ。この間に蓄積された購買履歴、好み、購買パターンは、マーケティング戦略の基盤となる重要な資産である。Leonard氏はWooCommerce Blogの記事で「データは私たちのものだ。他のサブスクリプションプラットフォームとは大きく異なる。顧客をサードパーティに渡すのではなく、自分たちで管理できる」と述べている。
オープンソースのWooCommerceでは、データベースは事業者のサーバー上に存在する。仮に将来プラットフォームを移行する場合でも、データを完全な形でエクスポートできる。これはSaaS型プラットフォームにはない構造的な優位性だ。特にサブスクリプションモデルで長期的な顧客関係を構築しているEC事業者にとって、データアクセスの制限は重大な事業リスクになる。
データ所有権の問題は、短期的なコスト比較では見落とされがちだ。しかし、サブスクリプション事業のように顧客との長期関係が収益の柱となるビジネスモデルでは、データの可搬性とアクセス権が戦略的な価値を持つ。grüumの判断は、この点を明確に意識したものと言える。
この記事のポイント
- grüumは月間8万件の注文を1人の開発者で処理する中規模EC事業者であり、Shopify PlusとMagentoを評価した結果WooCommerceに残る決断を下した
- 複雑な商品バンドル（内容物、価格設定、在庫管理の一元設定）はShopify Plusではネイティブにサポートされず、ビジネス側をプラットフォームに合わせる必要があった
- サブスクリプション収益に対する従量課金（Shopify）と定額制（WooCommerce）の差は、年商1,000万ポンド規模で年間約10万ポンドのコスト差を生む
- Magentoは拡張性は高いが、運用に専任の技術チームが必要で、grüumの1人体制では経済的に成立しなかった
- オープンソースのWooCommerceはデータベースを事業者が完全に所有でき、顧客データの可搬性とアクセス権がSaaS型よりも優位
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 10.8でOrder更新APIが非Order IDを弾く仕様に。サブスク型データの消失を防止
WooCommerce 10.8が2026年5月19日にリリース予定で、そのなかでREST APIの注文更新エンドポイントに重要な変更が入る。具体的には、/wc/v3/orders/{id} および /wc/v2 相当のルートが、注文ID以外のIDを指定された場合にHTTP 400エラーを返すようになる。
一見すると小さな修正に思えるが、この変更の背景には「サブスクリプションなどの注文以外のデータが、注文更新APIを通じて誤って通常注文に変換され、種別固有のデータが消失する」という深刻な問題がある。WooCommerceのサブスクリプション機能を使っている事業者や、カスタム連携を組んでいる開発者にとっては見逃せない変更だ。
注文更新APIの型検証が強化された背景
従来、WooCommerceのREST API v2およびv3における注文更新エンドポイントは、指定されたIDが本当に注文（shop_order）レコードに属するかをチェックしていなかった。Developer WooCommerce Blogの記事によると、このエンドポイントはサブスクリプション（shop_subscription）など、注文以外のレコードのIDを受け付け、保存時にそれらを通常の注文へとサイレントに変換していたという。
この挙動が引き起こす最大の問題は、サブスクリプション固有のデータ（定期購読の周期、支払いスケジュール、関連する親注文とのひも付けなど）が完全に失われることだ。データが失われているにもかかわらず、APIはHTTP 200で成功を返すため、開発者もサイト運営者も異常に気づきにくい。この問題は GitHub Issue #63936 で報告された。
実はこの「エンドポイントが受け付けるIDの型を事前に検証する」仕組み自体は、v1エンドポイントには当初から存在していた。v2とv3で欠落していた検証が、10.8でようやく追加される形になる。後方互換性を多少犠牲にしても、データの整合性を守ることを優先した判断といえる。
影響を受けるのはどのようなケースか
Developer WooCommerce Blogの記事では、影響を受ける開発者の条件が明示されている。/wc/v2/orders/{id} または /wc/v3/orders/{id} に対して、shop_order レコード以外のIDを指定した更新リクエストを送信しているコードやインテグレーションが該当する。
具体的なシナリオとしては、以下のようなケースが考えられる。
- サブスクリプションの更新処理を誤って注文エンドポイントで行っている
- カスタムプラグインが注文IDとサブスクリプションIDを区別せずに同一の処理関数に渡している
- 外部のCRMや基幹システムとの連携で、IDの種別チェックを怠っている
- バッチ処理やデータ移行スクリプトが注文以外のレコードもまとめて注文APIに送っている
10.8にアップグレードした後、これらのリクエストは以下のようなエラーレスポンスを受け取ることになる。
{
"code": "woocommerce_rest_shop_order_invalid_id",
"message": "ID is invalid.",
"data": {
"status": 400
}
}エラーコード woocommerce_rest_shop_order_invalid_id は、今後ログ監視のキーワードとして覚えておくとよい。このエラーが出ている場合は、注文更新APIに誤ったIDが渡されていることを示す。
過去に影響を受けたデータの取り扱い
ここで重要なのは、過去にすでに変換されてしまったデータは元に戻らないという点だ。10.8より前のバージョンで、非 shop_order のIDに対して注文更新APIが200を返したケースでは、そのレコードはすでに通常注文へと変換されており、種別固有のデータは削除されている。
この変更の根本にあるPull Request（#64050）は、型検証の追加というよりも「これ以上のデータ破壊を防ぐ安全装置の設置」と捉えるのが正確だ。10.8は事後対応ではなく、予防措置としてのアップデートである。
開発者が取るべき具体的な対応
サブスクリプション更新処理の移行
WooCommerce Subscriptionsプラグインを使用している場合、サブスクリプションの更新には注文エンドポイントではなく、サブスクリプション専用のRESTエンドポイントを使う必要がある。具体的には /wc/v3/subscriptions/{id} だ。
Developer WooCommerce Blogの記事でも、この移行が最初に推奨されている。コードレベルの修正は単純で、API呼び出しのパスを /orders/ から /subscriptions/ に変更するだけだが、同時にリクエストボディの構造もサブスクリプション用のフォーマットに合わせる必要がある点に注意が必要だ。注文APIとサブスクリプションAPIでは受け付けるパラメータが異なる。
APIログの監査
アップグレード前に、これまでのAPIリクエストログを精査しておくことを強く推奨する。特に以下のシグネチャに注目してほしい。
/wc/v2/orders/または/wc/v3/orders/へのPATCH/PUTリクエスト- レスポンスが200だが、対象IDが注文以外のレコード（サブスクリプション、返品、クーポンなど）
- サードパーティプラグインや外部サービスからの自動連携リクエスト
影響を受けたレコードが見つかった場合、バックアップからの復元が必要になるケースもある。特にサブスクリプション型のビジネスモデル（定期購入、メンバーシップ、SaaS課金など）を運用している事業者は、この監査を優先タスクとして扱うべきだ。
エラーハンドリングの追加
10.8以降、woocommerce_rest_shop_order_invalid_id エラーが新たに発生し得ることを踏まえ、APIクライアント側のエラーハンドリングにもこのケースを追加しておく必要がある。HTTP 400が返ってきた場合に、単に「リクエスト失敗」としてログに残すだけでなく、IDの種別が誤っていないかをチェックするフローを組み込むとよい。
// ID の種別を確認し、適切なエンドポイントに振り分ける
if ( isSubscription( id ) ) {
patch( `/wc/v3/subscriptions/${id}`, body );
}
}
この変更の本質的な意味
今回の変更は、単なる「バグ修正」ではなく、WooCommerceのREST APIがデータの型安全性を重視する方向へ舵を切ったことを示すシグナルだ。従来は「多少のデータ不整合には目をつぶり、とにかく動かす」というPHP／WordPressエコシステムの寛容な文化が反映されていたが、ECプラットフォームとしての成熟に伴い、データの一貫性を厳格に守る姿勢へとシフトしている。
実際、GitHub上での議論を見ると、この問題が最初に報告されたのはv1エンドポイントがすでに型検証を持っていたにもかかわらず、v2/v3でそれが欠落していたことへの疑問からだった。APIバージョン間での挙動の不一致が長年放置されていたこと自体が、WooCommerceのREST APIの設計上の技術的負債だったといえる。
EC事業者にとっての実務的な教訓は明確だ。サブスクリプション、予約、会員権など、WooCommerceのカスタム注文タイプを利用している場合は、それぞれのデータ種別に対応する専用エンドポイントの使用を徹底すること。複数の注文タイプを横断するような汎用的なAPIクライアントを自作している場合は、今回の変更を機にアーキテクチャの見直しを検討する価値がある。
この記事のポイント
- WooCommerce 10.8で注文更新APIが非注文IDをHTTP 400で拒否するようになる
- これまではサブスクリプションなどのデータが誤って通常注文に変換され、固有情報が消失していた
- サブスクリプション更新は
/wc/v3/subscriptions/{id}専用エンドポイントへ移行が必要 - 過去に変換されたレコードはバックアップからの復元以外に手段がないため、APIログの監査が急務
- 正式リリースは2026年5月19日を予定、事前対応の猶予は短い
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce Subscriptions Health Checkリリース、定期購入の健全性をチェック
WooCommerce Subscriptionsプラグインに、サブスクリプションの支払い状態を可視化する「Subscriptions Health Check」ツールが追加された。WooCommerce Developer Blogの2026年4月30日の記事で発表されている。
このツールは、本来は自動更新されるべき定期購入が手動更新のまま止まっていないか、あるいは次回支払日が欠落していないかを店舗管理者がすぐに把握できるようにするものだ。WooCommerce 3.0以降のサブスクリプションストアであれば、過去のバグの影響有無にかかわらず利用できる。
リリースの直接のきっかけは、定期購入が意図せず手動更新に切り替わる可能性がある4件のバグが公に報告されたことだ。しかし開発チームは、原因がバグに限らず、決済ゲートウェイの変更やインポート時の設定など、同じような「自動更新されない」状態はさまざまな要因で起こり得ると判断。特定のバグ被害者を探すのではなく、潜在的に問題を抱えるサブスクリプションを幅広くリストアップする仕組みを選んだ。
サブスクリプション健全性チェックツールの登場背景
サブスクリプション型ビジネスでは、決済の自動継続が収益の柱になる。そのため、意図せず手動更新に設定されたまま放置されると、気づかないうちに売上を失うリスクがある。開発チームはもともとこうした健全性チェック機能をロードマップに載せていたが、公のバグ報告を受けて開発を前倒しした。
報告されたバグは、WooCommerceの高性能オーダーストレージ（HPOS）環境で、定期購入の作成時に_requires_manual_renewalフラグが誤ってtrueのままになるというものだ。調査の過程で、キャッシュの不整合やデータ同期の欠落といった根本原因がいくつか特定された。しかしチームは、これらが修正済みであっても「自動更新されない定期購入」という状態は他の経路でも発生し得ると考えた。
たとえば、店舗管理者が手動更新設定に切り替えた、決済トークンが削除された、他社のカートシステムからインポートした際に手動扱いになった、カスタムコードやサードパーティ連携がフラグを書き換えた、といったケースだ。これらをすべて機械的に区別するのは難しい。そこで最終的には、自動更新が可能な支払い方法を持ちながら手動更新になっているサブスクリプションをすべて可視化し、その判断をマーチャントに委ねる設計が採用された。
4つのバグが与えた影響の実態
WooCommerce開発者ブログの記事では、公表された4件のバグすべてがすでに修正済みであることが明かされている。しかし、修正当時はこれらのバグが「定期購入をサイレントに手動更新へ切り替える」というマーチャント目線での影響まで認識されていなかった。
バグの組み合わせが実際に問題を引き起こしていたのは、HPOSを有効にしたストアで、かつ特定のバージョンのWooCommerce Subscriptionsを動かしていた期間に限られる。バグ1（期限切れHPOSキャッシュ）は2024年3月に修正済み。バグ2（HPOSバックフィルメソッド欠落）は2023年中に解消。バグ3（再取得による不整合）は2024年5月に修正された。独立して「手動更新化」を引き起こすわけではなく、バグ1とバグ3が同時に存在する環境で、購入手続き時にフラグが誤設定されるという経路だった。
影響を受けた可能性が最も高いのは、2023年10月から2024年3月の間にHPOSを有効化し、かつWooCommerce Subscriptions 6.1.0未満を利用していたストアだ。2024年5月以降にサブスクリプションを開始したストアは、今回のバグの影響を受けていない。ただし、開発チームはこのツールをバグの有無にかかわらず定期購入全体の監視に役立ててほしいとしている。
ツールの使い方と主要機能
Health Checkツールは、WordPress管理画面の「WooCommerce」→「ステータス」→「サブスクリプション」タブに設置されている。ステータスページには、最終スキャン日時と、手動スキャンの実行ボタンが表示される。
「今すぐ実行」ボタンでオンデマンドのスキャンが可能だ。スキャンはバッチ処理で行われ、サーバーやデータベースに過負荷がかからないようスロットリングが組み込まれている。定期的な自動スキャンも、WooCommerce設定で有効にすれば夜間に実行され、結果が保存される。保存された結果はページを開くたびに即座に表示されるため、毎回重いクエリを待つ必要はない。
3つのタブで状態を整理
ツールを開くと、「すべて」「自動更新をサポート」「更新漏れ」の3つのタブが表示される。
「すべて」タブでは、ストア内の全サブスクリプションが一覧できる。特定の条件で絞り込みたい場合の全体像把握に使う。
「自動更新をサポート」タブは、今回のツールの中核となる部分だ。次の条件をすべて満たすサブスクリプションが表示される。ステータスが「有効」「保留中」「キャンセル保留」のいずれかである、_requires_manual_renewalフラグがtrueである、支払い方法が自動更新をサポートしている、かつ顧客がそのゲートウェイに有効な支払いトークンを保存している。つまり、自動更新できるのに手動扱いになっているサブスクリプションが浮かび上がる。
「更新漏れ」タブには、次回支払日が空欄のまま更新が止まっているものや、過去の支払日から24時間以上経過しても対応する更新注文が生成されていないサブスクリプションが表示される。これらはスケジュールされたアクションの不具合やサーバー移行時の問題など、さまざまな原因で発生し得る。
表示される項目とフィルター
各行には、サブスクリプションID、作成日、顧客名、請求サイクル、ステータス、請求モード（手動/自動）、自動更新の設定（顧客がMy Accountでオプトアウトしたかどうか）、支払い方法、次回支払日、最新の更新注文ステータス、直近の成功支払日が表示される。他社システムから手動更新としてインポートされたものは「インポート（手動）」と明示され、フィルターで除外されるのではなく、タグ付けされる。
フィルターとして、ステータス別、請求モード別、更新注文ステータス別、自動更新オプトアウトの有無別、IDやメールアドレスによる検索が用意されている。列のソートも可能で、デフォルトでは新しいサブスクリプションが先頭に来る。
このツールは、あえて自動修復を行わない設計になっている。たとえば、手動更新に切り替わっているサブスクリプションを自動で「自動更新」に戻したり、店舗全体で「自動支払いを無効化」しているストアのサブスクリプションを非表示にしたりはしない。すべての判断は店舗の文脈を知るマーチャントに委ねられている。
バグの詳細とマーチャントへの影響
公表された4件のバグのうち、定期購入の手動更新化に直接つながったのはバグ1とバグ3の組み合わせだ。バグ2はスケジュールメタデータの不整合を引き起こしたもので、更新日に更新処理そのものが発火しないという別の症状となる。バグ4はゲートウェイ変更時の復旧ギャップで、単体では不具合を生み出さない。
バグ1とバグ3の組み合わせで何が起きたか
HPOS環境で注文が作成されると、バグ1によって定期購入の日付更新後にキャッシュがクリアされず、バグ3の再取得処理がキャッシュ経由で古い状態を読み取ってしまう。その結果、メモリ上でクリアしたはずの_requires_manual_renewalフラグが、保存時に古い値（true）のままデータベースに書き込まれるというものだ。
このフラグが誤ってtrueになると、最初の更新日に定期購入は「保留中」になり、保留中の更新注文が作成され、顧客に「手動で支払いを」というメールが送られる。このメールはデフォルトで有効になっていることが多く、開発チームのオプトインデータによれば約91.8%のストアで送信されていたという。つまり、ほとんどのケースで顧客には支払いを促す通知が届いており、完全にサイレントで見逃される状態ではなかった。
ただし、顧客がそのメールに気づかずに放置すると、更新が止まったままになる。マーチャントにも通知が行かないケースがあったため、結果として気づかないうちに収益機会を失う可能性があった。今回のHealth Checkツールは、まさにこの「更新されていない状態」を検出するためにある。
バグ2の異なる影響
バグ2はスケジュール関連のメタデータがHPOS互換モードで同期されない問題で、更新日時がずれたり、更新イベントが発火しなかったりした。影響範囲は2023年8月から12月にデータ移行が行われた一部のストアに限られる。このケースでは更新注文自体が生成されず、通知の記録すら残らないため、「更新漏れ」タブで初めて表面化する。
今後の展開とマーチャントへの推奨事項
今回のHealth Checkツールは、あくまで「第1弾」と位置づけられている。WooCommerce開発チームは、すでに次のバージョンでツール画面から直接サブスクリプションを修正できる機能の開発に着手している。たとえば、一括で自動更新に戻す、手動更新であることを明示的に確定させるといった操作が、ツール上で完結するようになる見込みだ。
また、今回の一連のバグ対応を受けて、チェンジログの書き方も改善された。今後は、バグ修正がマーチャントの収益や顧客体験に影響を与える可能性がある場合、その内容をチェンジログに明記し、必要に応じて影響を受けるストアに直接連絡する方針だ。これは単なるコミュニケーションギャップの解消ではなく、エコシステム全体での透明性を高める取り組みといえる。
ストア管理者が今すぐやるべきこと
まず、WooCommerce Subscriptionsを最新バージョン（8.6.1以降）にアップデートする。そのうえでHealth Checkツールを実行し、「自動更新をサポート」タブと「更新漏れ」タブの内容を確認してほしい。特に、HPOSを有効にしていて、かつ2024年3月以前からサブスクリプション販売を行っているストアは重点的なチェックが推奨される。
もし手動更新にすべきでないサブスクリプションが見つかった場合は、手動で編集して自動更新に戻すか、WooCommerceサポートに問い合わせてサポートを受けることができる。開発チームは今回のツール公開に合わせてサポート体制を強化しており、結果の解釈に迷った場合でも相談しやすくなっている。
この記事のポイント
- WooCommerce Subscriptionsに定期購入の健全性を可視化するHealth Checkツールが追加された
- 自動更新可能なのに手動更新設定になっているサブスクリプションや、更新日が欠落しているものを一覧できる
- 過去のバグ（HPOS環境でのキャッシュ不整合など）の影響を受けていなくても、すべてのストアで活用できる汎用機能
- ツールは自動修復せず、判断はすべてマーチャントに委ねられる。次のバージョンで一括操作機能が追加予定
- バグの影響が最も疑われるのは2023年10月〜2024年3月にHPOSを有効にしていたストア。2024年5月以降のストアは今回のバグの直接影響なし
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験