Product Feed PROでブランド・変動商品・商品カテゴリが出力されない時の直し方
Product Feed PRO for WooCommerceでブランド・変動商品・Google商品カテゴリがXMLに出力されない場合、まず確認すべきはフィールドマッピングの重複定義とキャッシュの遅延だ。症状が3つ同時に出ていても原因はそれぞれ別で、マッピング設定と条件設定を正しく組み替えれば大半は解決する。
ブランドがXMLに間欠的に出力される原因
同じブランドを割り当てた商品の一部にだけ<g:brand>が出力されない場合、最も多いのが「ブランドの取得ソースが複数存在している」ケースだ。WooCommerceの商品編集画面ではブランドが正しく見えていても、フィードプラグインは別のソースを参照して空の値を受け取ることがある。
Product Feed PROにはブランドを取得するための選択肢が複数用意されている。商品ブランド（product_brand）タクソノミー、商品属性（pa_brand）、YITH Brandプラグイン用の「Brand」、WooCommerce Brandsプラグイン用の「Product brand」などが代表だ。これらが混在していると、商品Aはタクソノミーから値を取得し、商品Bは未設定の商品属性を参照して空振りする、という動きになる。
特に複数のプラグインを併用していたり、過去にブランド管理の方法を変更したサイトで起きやすい。商品一覧のCSV書き出しでブランド列を確認すると、同じブランド名でも保存されている場所が商品によって異なるのがわかる。
商品B Dr Coffee → タクソノミーに設定済み → 属性は未設定 → 出力なし
商品B Dr Coffee → タクソノミーから取得 → 出力あり
このデモは、ブランドの取得ソースを属性にしたままタクソノミーのみ設定した商品で出力が欠落する状況を示している。対処は連載の後半でまとめて説明する。
商品ごとにブランドの保存場所を確認する
WooCommerceの商品一覧からCSVを書き出し、ブランドのタクソノミー列と属性列の両方を確認する。片方だけに値が入っている商品があれば、その商品群で出力が欠落しているはずだ。同じブランド名を保ったまま、フィードが参照するソースにデータを揃える必要がある。
フィードプラグインのフィールドマッピングを再定義する
フィードのフィールドマッピング画面で、<g:brand>フィールドの「取得ソース」を確認する。プルダウンに複数のブランド候補が並んでいたら、実際に価値が入っているタクソノミー（product_brand）を選択し直し、フィードを再生成する。
変動商品がフィードから完全に欠落する原因
変動商品（バリエーションを持つ商品）がXMLに一切出力されない場合、最初に確認するのは「デフォルトのバリエーション」の設定だ。WooCommerceの変動商品では「デフォルトのバリエーションを選択」プルダウンが「デフォルトを選択」のままになっていると、親商品がフィードの出力対象から外れることがある。
フィードプラグインの設定で「商品のバリエーションを含める」を有効にしても、親商品のバリエーション自体が正しく構築されていないと出力はできない。各バリエーションに価格・在庫状況・画像が設定されているか、親商品がカタログに表示される設定になっているかも重要なチェックポイントだ。
プルダウン「デフォルトを選択」のまま → フィード生成スキップ
バリエーション3点も非出力
プルダウンで1件選択 → フィードに親商品とバリエーションが出力
価格と在庫のある3バリエーションも表示
このデモは、デフォルトのバリエーション未選択で変動商品が出力から漏れる典型的なパターンを表している。ほかに価格未入力や在庫切れでも同様の欠落が起こる。
バリエーションの設定を一括で点検する
変動商品の編集画面で、各バリエーションに通常価格またはセール価格が登録されているか、在庫ステータスが「在庫あり」または「予約可能」になっているかを確認する。バリエーションが「非公開」や「カタログに表示しない」になっていないかも見る。
親商品の「商品データ」メタボックスでは、プルダウンで「デフォルトのバリエーション」を必ず1つ選ぶ。この操作が済んでいない変動商品は、フィードプラグイン側の設定に関係なく出力対象外になるケースが多い。
フィード設定の「商品のバリエーションを含める」を再確認する
Product Feed PROのフィード編集画面で、変動商品に関するオプションが有効か確認する。「商品のバリエーションを含める」と「親商品も含める」の両方が目に入るが、どちらか一方だけ有効になっていると期待した出力にならない。特に親商品を表示するには、その商品自体がカタログに表示される設定である必要がある。
Google商品カテゴリが出力されない原因
Google商品カテゴリ（<g:google_product_category>）がXMLに出ない場合、原因はほぼ「カテゴリマッピングの条件不一致」か「フィールドマッピングの取得ソースにgoogle_categoryが設定されていない」のどちらかだ。カテゴリマッピング画面でWooCommerceカテゴリとGoogleカテゴリを紐づけただけでは、フィードに反映されない。
カテゴリマッピングの画面では、左側にWooCommerceの商品カテゴリ、右側にGoogleの商品カテゴリを割り当てる。この割り当てが「すべてのカテゴリ」ではなく、一部のカテゴリだけに適用される条件で作られていると、対象外のカテゴリに属する商品からはカテゴリが出力されない。
→ 他のカテゴリ（ドリップ用品など）は
<g:google_product_category>が空のまま→ すべての商品に
<g:google_product_category>が出力このデモは、カテゴリマッピングの条件漏れで一部商品のGoogleカテゴリが空になる状況を示している。カテゴリマッピング画面は商品数が多いほど設定漏れが起きやすいので、全カテゴリを対象にするのが基本だ。
フィールドマッピングでgoogle_categoryが設定されているか確認する
フィードのフィールドマッピング画面で、Google側の<g:google_product_category>フィールドに対して、取得ソースが「google_category」になっていることを確認する。このソースは、カテゴリマッピング画面で定義した対照表を参照する専用の値だ。
誤って商品カテゴリそのものを割り当てていると、Googleが求める形式（例: Home & Garden > Kitchen & Dining > Coffee Makers）ではなく、WooCommerceのカテゴリ名だけが出力される。Google Merchant Center側でエラーまたは警告になるため、ソース設定は丁寧に見直す必要がある。
カテゴリマッピングを全カテゴリに適用する
カテゴリマッピング画面で、WooCommerceの各カテゴリに対応するGoogleカテゴリをすべて埋める。カテゴリが多い場合は「未マッピングのカテゴリ」フィルタを使うと、設定漏れのカテゴリだけを洗い出せる。親カテゴリを割り当てたら、子カテゴリが自動的に引き継がれるかどうかも確認する。
3つの問題をまとめて修正する手順
3つの問題が同時に起きている場合は、それぞれを個別に直すよりも、フィードの基本設定を順番に整える方が早い。次の手順でフィールドマッピング、変動商品設定、カテゴリマッピングを見直す。
このデモは、3つの症状をまとめて修正する際の優先順位を表している。ブランドの取得ソースを先に統一すると、変動商品とGoogleカテゴリの修正結果をXMLで正確に確認できる。
フィード再生成とキャッシュの扱い
設定を変更したあとは、フィードプラグインの「再生成」または「今すぐ更新」ボタンを実行する。WooCommerceやサーバー側のキャッシュが効いていると、更新前のXMLが表示され続けることがある。キャッシュプラグインを使っている場合は、フィードを再生成する前にキャッシュを削除すると確実だ。
生成されたXMLをブラウザで開き、<g:brand>、<g:google_product_category>、変動商品のIDやタイトルが表示されているかをCtrl+F（MacではCommand+F）で検索する。変動商品は親商品とバリエーションが別々の<item>要素として出力されるため、商品IDではなく商品名の一部で検索すると見つけやすい。
よくある質問
ブランドの出力が安定しないのはキャッシュが原因か？
キャッシュだけが原因になる場合は少ない。ブランドタクソノミーと商品属性の両方に同名のブランドが存在し、フィードのマッピングが不安定なソースを参照していることが多い。キャッシュを削除しても再発するなら、取得ソースの統一が先だ。
変動商品だけがXMLから消えるのはなぜか？
変動商品は親商品と各バリエーションが個別の商品として扱われるため、単純商品より出力条件が厳しい。デフォルトのバリエーション未選択、価格未入力、在庫切れ、または「商品のバリエーションを含める」設定のミスが典型的な原因になる。
Google商品カテゴリの出力形式が正しいか確認する方法は？
出力されたXML内の<g:google_product_category>の値を確認し、Google Merchant Centerが求める形式（不等号で区切られた英語の数字付きカテゴリパス）になっているかを見る。WooCommerceのカテゴリ名だけが入っている場合は、フィールドマッピングの取得ソースが誤っている。
設定を変えてもフィードが更新されない場合は？
フィードの再生成ボタンを押したあと、ブラウザでXMLを開いたときに古い内容が表示されることがある。キャッシュプラグインの削除、サーバー側のキャッシュ（OPcacheやVarnish）のクリア、またはクエリパラメータを付けて開く（例: feed.xml?nocache=1）と最新の出力を確認できる。
ブランドが空の商品はどうやって特定するか？
WooCommerceの商品一覧でフィルタ機能を使い、ブランドタクソノミーが空の商品を絞り込む。もし全商品にブランドが付いているのにXMLには一部しか出ていないなら、取得ソースの不一致を疑う。CSV書き出しでブランド列とブランド属性列を並べて比較すると特定しやすい。
この記事のポイント
- ブランドは取得ソースの統一が最優先
- 変動商品はデフォルトバリエーションの選択が必須
- Google商品カテゴリは全カテゴリのマッピングが必要
- 設定変更後はキャッシュを削除して再生成する
- XMLを検索して各フィールドの出力を検証する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
カートページで数量を変更すると違う数になる時の対処法
WooCommerceのカートページで数量を1から2に変更したのに3が表示される不具合は、テーマまたはプラグインの古いJavaScriptが原因で数量更新のイベントが二重に処理されるケースが多い。まずテーマとWordPress本体・WooCommerceを更新し、それでも直らなければプラグインの競合を切り分けるのが最短の解決手順だ。
なぜカートページの数量変更で数がずれるのか
カートページで数量を変更すると、WooCommerceはAjax通信でサーバーに更新を送り、その結果を画面に反映する。このときブラウザ側のJavaScriptが「変更前の数量」と「変更後の数量」を正しく引き算して表示する仕組みになっている。
ところがテーマやプラグインが古いjQueryや独自のAjax処理を持っていると、同じクリックや入力イベントに対して数量加算の処理が2回走ることがある。たとえば「1を2に変更」が「1を3に変更」として解釈され、画面に3が表示される。
特に数量に小数を許可するプラグイン（WooCommerce Decimal Productなど）が有効な場合、数量フィールドの値の扱いが標準と変わるため、テーマ側のJavaScriptとの相性問題が表面化しやすい。プラグインを無効化すると正常になることから、原因がプラグイン単体でなく「プラグインとテーマの組み合わせ」にあると判断できる。
テーマとWordPressを最新版に更新する手順
この不具合は、テーマ・WordPress・WooCommerceのいずれかが古いことで、最近のブラウザやプラグインとの間でJavaScriptの仕様差が生じるために起きることがある。まずは更新作業から始める。
更新後はシークレットウィンドウや別ブラウザでテストする。通常のブラウザに古いCookieやキャッシュが残っていると、修正後も古いJavaScriptが動いてしまうためだ。
JavaScriptの競合を切り分ける手順
更新しても症状が変わらない場合、特定のプラグインやテーマのJavaScriptがWooCommerceの数量更新イベントと競合している。原因を特定するには「無効化テスト」が確実だ。
プラグインを1つずつ無効化して原因を特定する
まずプラグイン一覧から、数量に関係するプラグイン（小数プラグイン・カスタム数量プラグイン・Ajaxカートプラグインなど）を候補として絞り込む。それぞれ無効化してカートページを再読み込みし、数量が正しく更新されるか確認する。
もし特定のプラグインを無効化したときだけ正常になるなら、そのプラグインが原因だ。プラグインの更新版が出ていないか確認し、出ていなければ代替プラグインへの乗り換えを検討する。
ブラウザのコンソールでJavaScriptエラーを確認する
ブラウザのデベロッパーツール（ChromeではF12キー）を開き、「Console」タブを確認する。カートページで数量を変更したときに赤いエラーが表示される場合、エラーのファイル名から競合元を特定できる。
エラーメッセージが「jQuery is not defined」や「$ is not a function」なら、テーマのJavaScriptがjQueryを正しく読み込んでいない。wp_enqueue_script の順序や依存関係の問題なので、テーマ制作者に修正を依頼するか、子テーマ側で読み込みを調整する。
「cart-fragments」や「wc-cart-fragments」に関するエラーなら、WooCommerceのAjaxカート更新機能が別のプラグインと衝突している。該当プラグインを特定して無効化すれば症状は収まる。
キャッシュとCookieの影響を排除する
修正後も古い表示が続く場合は、サーバー側のキャッシュとブラウザ側のCookieが原因で古いJavaScriptが読み込まれている可能性がある。キャッシュプラグイン（WP Super Cache、W3 Total Cache、LiteSpeed Cacheなど）のキャッシュを全削除し、ブラウザのCookieとキャッシュも消去してから再テストする。
また、CDN（Cloudflareなど）を利用している場合は、CDN側のキャッシュもクリアする。CDNが古いJavaScriptファイルを配信し続けると、サーバー上では更新済みでもブラウザには古いコードが届く。
よくある質問
数量が正しく更新されるか確認する方法は？
カートページで数量を複数回変更し、そのたびにカート内の小計と合計が正しく再計算されるかを確認する。加えて管理画面の「WooCommerce→ステータス→ログ」にJavaScript関連のエラーが記録されていないか確認するとよい。
テーマを更新しても大丈夫？
更新前にバックアップを取っていれば問題ない。カスタマイズをテーマ本体に直接書いている場合は、更新で消える可能性があるので、子テーマや独自プラグインに移してから更新するのが安全だ。
小数プラグインを使い続けながら直す方法は？
プラグイン自体に更新版がない場合は、テーマ側のJavaScriptを修正して競合を回避する必要がある。具体的にはカートページの数量更新をWooCommerce標準のAjax処理に任せるよう、テーマのcustom.jsやmain.jsから数量関連のコードを除去する。
テストサイトを作るべき？
本番サイトに影響を与えずに原因を切り分けたい場合は、ステージング環境（多くのレンタルサーバーに標準搭載）か、ローカル環境（LocalやXAMPPなど）で同じテーマとプラグインを再現するのが有効だ。テストサイトで症状が再現できれば、切り分け作業を安全に進められる。
PHPのバージョンは関係ある？
PHPのバージョンが極端に古い（7.4未満など）場合、WooCommerceの最新版が正しく動作しないことがある。サーバー管理画面でPHP 8.0以上に更新できるか確認するのも有効な切り分けのひとつだ。
この記事のポイント
- カートの数量が「1→2」で「3」になるのはJavaScriptの二重処理が主因
- テーマ・WordPress・WooCommerceの更新で解決するケースが多い
- 直らない場合はプラグインを1つずつ無効化して競合元を特定する
- ブラウザとサーバーのキャッシュ・Cookie削除を忘れない
- 小数プラグインを使うならテーマ側のJavaScript競合を重点確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce 11.2のライフサイクルフック変更。保存と並び替えでSQL最大45%削減
WooCommerce 11.1と11.2で、商品保存と商品並び替えの内部処理が大きく変わった。商品保存時のSQLクエリ数は最大45%削減され、並び替えアルゴリズムは大規模カタログ向けに再設計された。
プラグインやカスタムコードで商品データを操作している場合、レガシーフックの移行が必要になる。本記事では変更の全体像、技術的な詳細、そして移行の具体的な手順を解説する。
WooCommerce 11.1と11.2の変更点を俯瞰する
2つの変更はいずれも、後方互換性を優先しつつ、大規模な商品カタログでパフォーマンスを改善することを目的としている。
大規模カタログ向けのパフォーマンス改善
WooCommerceチームは、商品数が数千・数万を超えるストアで発生する管理画面の遅延やデータベース負荷を問題視していた。特に商品保存と並び替えは、カタログ全体に影響が及ぶ処理であり、これまでの実装ではカタログが大きくなるほど処理時間が線形に悪化する構造だった。
今回の変更は、商品データストアが不要な書き込みを行わないようにし、並び替えでは全カタログの再インデックスを避ける設計へと置き換えるものだ。これにより、大規模ストアの管理画面レスポンスが大幅に改善される見込みである。
後方互換性の優先とレガシーフックの扱い
重要なのは、非推奨になったフックを使い続けた場合、自動的に旧アルゴリズムへフォールバックする点だ。互換性は保たれるが、その分パフォーマンス改善の恩恵は受けられない。
プラグイン開発者にとっては、古いフックへの依存を解消し、新しいフックへ移行するかどうかの判断が必要になる。次のセクションから、各変更の詳細を見ていく。
商品保存処理の最適化でSQL数を45%削減
商品保存時の動作が変わり、値に変更がない場合はAPI呼び出しをスキップする。この最適化により、保存1回あたりのSQLクエリ数が最大45%削減される。
no-op書き込みの削減がもたらす効果
今回の最適化は、wp_set_object_terms() と delete_post_meta() というWordPressの関数に着目したものだ。これらの関数は、データが変わっていない場合でも呼び出されるとキャッシュを無効化する動作をしていた。いわば「変更がないのに掃除をする」ような無駄が毎回発生していた。
WooCommerce 11.1以降では、保存前の値と保存後の値を比較し、同じ値であればこれらのAPIを呼び出さない。この小さな変更が、商品保存を頻繁に行う大規模ストアでは大きなDB負荷の削減につながる。
フック発火頻度の変化による副作用
ただし注意点がある。set_object_terms フックは、これまで商品保存のたびに発火していた。最適化後は、値が変わった場合のみ発火するようになる。このフックに依存して何らかの処理を実行しているカスタムコードがある場合、想定よりも発火回数が減る可能性がある。
具体的には、商品タイプが変わっていなくても毎回の保存で処理を行うことを前提としたコールバックは、移行が必要だ。次のセクションで確認手順を詳しく解説する。
商品並び替えアルゴリズムの刷新とフック移行
並び替えに関わるフックは2つが非推奨になり、2つの新しいフックが追加された。非推奨フックを使うと旧アルゴリズムにフォールバックする。
旧アルゴリズムから新アルゴリズムへ
従来の商品並び替えは、管理画面の「商品 → すべての商品 → 並び替え」で操作するたびに、カタログ全体を再インデックスしていた。商品数が1万件を超えると、この処理は数十秒かかることもあり、実用に耐えないケースがあった。
新しいアルゴリズムは、大規模カタログを前提に設計されている。再インデックスを高速化し、範囲ベースの並び替えを採用することで、変更された範囲だけを効率的に処理する。これにより、大規模ストアでも並び替え操作が快適になる。
非推奨フックと新フックの対応表
以下の表が、今回変更されたフックの全体像だ。非推奨になったフックを今も使っている場合、対応する新しいフックへの移行を検討する必要がある。
woocommerce_after_single_product_orderingは非推奨。カタログ再インデックス中に商品ごとに発火していたwoocommerce_after_product_orderingは非推奨。並び替え完了後に一度だけ発火していたclean_post_cacheは変更なし。レガシーと高速パスの両方で影響を受けた商品ごとに発火するwoocommerce_product_ordering_process_reindexed_productsは新設。フルカタログ再インデックス後に発火するwoocommerce_product_ordering_process_moved_productsは新設。商品が再配置された後に発火する
元の動作を再現するには、clean_post_cache、wp_ajax_woocommerce_product_ordering、woocommerce_product_ordering_process_reindexed_products、woocommerce_product_ordering_process_moved_products をプリミティブとして組み合わせる方法が公式に案内されている。
既存サイトが受ける影響と確認手順
公式ブログでは、AIツールを使ってカスタムコードを確認する方法が提示されている。上の手順で、フックへの依存を洗い出せる。
カスタムコードの確認方法
まず、アクティブなプラグイン、MUプラグイン、テーマの functions.php を対象に、add_action('set_object_terms', ...) というコールバックを検索する。該当があれば、そのコールバックが「商品タイプが変わっていなくても毎回発火すること」を前提にしていないかを確認する。
もし前提にしていた場合、そのコールバックは woocommerce_update_product や save_post_product など、より適切なフックへ移動する必要がある。
移行が必要なケースと不要なケース
移行が必要なのは、set_object_terms フックが毎回発火することを前提にしたコードが存在する場合だ。逆に、商品タイプの変更やカテゴリの変更など、実際に値が変わる場合のみ処理を行いたいというコードは、そのままでも問題ない。
並び替え関連では、woocommerce_after_single_product_ordering と woocommerce_after_product_ordering を使っているコードは、新しいフックへの移行を検討する。非推奨フックを使い続けても動作はするが、旧アルゴリズムにフォールバックするため、パフォーマンス改善の効果を得られない。
この記事のポイント
- 商品保存処理は、値が変わらない場合はAPI呼び出しをスキップしてSQL数を最大45%削減する
- 商品並び替えは、全カタログ再インデックスから範囲ベースの新アルゴリズムへ刷新された
set_object_termsフックの発火頻度が変わるため、毎回発火を前提としたコードは移行が必要- 並び替えの旧フック2つは非推奨になり、新フック2つが追加された
- 非推奨フックを使い続けると旧アルゴリズムにフォールバックし、高速化の恩恵を受けられない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.1で注文撤回機能が登場、14日以内の自己対応を実現
WooCommerce 11.1に注文撤回（Order Withdrawal）機能が追加された。EU域内の消費者が持つ14日間の契約撤回権に対応するための仕組みで、顧客が店舗にメールや電話で問い合わせることなく、注文から14日以内であれば自分で撤回リクエストを送信できるようになる。
この機能は既定では無効化されている。すべてのストアに必要な機能ではないため、事業者が設定画面から明示的に有効化する方式だ。顧客向けのリクエストフォーム、自動確認メール、店舗側の通知まで一連のフローが組み込まれている。
本記事では注文撤回機能の概要、有効化の手順、顧客と店舗それぞれの画面で何が起きるのかを解説する。EU向けに販売するストア運営者は特に確認しておきたい内容だ。
注文撤回機能とは何か
注文撤回機能は、EUの消費者保護規則で定められた「注文撤回権」に対応するための機能だ。EU域内の消費者は、商品やサービスを注文した日から14日以内であれば、理由を説明せずに契約を撤回する権利を持つ。従来はこの手続きをメールや電話で行う必要があり、店舗側も個別に対応する必要があった。
EUの14日間撤回権とは
14日間の撤回権はEU消費者権利指令に基づく制度で、オンライン購入を含む通信販売に適用される。消費者は商品を受け取った日から14日以内に撤回を申し出ることができ、事業者は返金に応じる義務を負う。この規則はEU域内の消費者との取引に適用されるため、日本からEU向けに販売するストアも対象になりうる。
重要なのは、注文撤回機能は法的手続きの自動化ツールであって、コンプライアンスを保証するものではないという点だ。WooCommerce Developer Blogの記事でも、事業の内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
従来の対応との違い
従来のフローでは、顧客がメールや電話で撤回の意思を伝え、店舗担当者が手動で注文を確認し、返金処理を行っていた。この方式には対応漏れや記録不足のリスクが伴う。注文撤回機能は、顧客が自己対応フォームからリクエストを送信し、システムが自動で記録と通知を行う。
このデモで示した違いは大きい。顧客からの撤回リクエストがシステムに記録され、確認メールが自動送信されることで、店舗と顧客の双方に証跡が残る。対応の属人化を防ぎ、処理の一貫性を保てる。
有効化の手順
注文撤回機能は既定では無効化されている。EU向け販売を行っていないストアでは不要な機能のため、必要な事業者だけが有効化する設計だ。設定はWooCommerceの管理画面から数ステップで完了する。
設定画面での操作
WooCommerceの設定画面を開き、詳細設定タブから機能セクションに移動する。そこに注文撤回のオプションが表示されるので、有効化して変更を保存するだけだ。設定完了後、顧客向けのリクエストフォームが /my-account/withdraw-order というURLで公開される。
エンドポイントのカスタマイズ
リクエストフォームのURLは変更できる。詳細設定のページ設定セクションでエンドポイントを編集すれば、自社の導線に合わせたURLに調整できる。標準のURLは /my-account/withdraw-order だ。
もう1つの重要な特徴として、このページはログイン状態に関わらず動作する。ゲスト購入した顧客でもフォームにアクセスしてリクエストを送信できる。EUの撤回権はゲスト購入者にも適用されるため、この設計は実務上欠かせない。
顧客から見た注文撤回フロー
顧客が注文撤回ページにアクセスすると、短いリクエストフォームが表示される。必要な情報を入力し、送信前に内容を確認する画面を経てから送信する。送信後は確認画面が表示され、入力した内容を含む確認メールが自動的に届く。
この4ステップのフローは、顧客が自分の操作だけで撤回リクエストを完了できることを示している。確認メールには顧客が入力した内容が含まれるため、顧客はリクエストの記録を残せる。店舗側への電話やメールが不要になり、双方の手間を削減する。
確認メールが自動送信される点は法的にも意味がある。撤回権の行使を顧客が証明できる記録が残るため、後日のトラブルを防ぐ効果が期待できる。
店舗運営者から見た通知と管理
顧客がリクエストを送信すると、店舗運営者には2つの経路で通知が届く。1つは撤回リクエストを知らせるメール通知、もう1つはWooCommerceホーム画面のインボックス通知だ。この二重の仕組みにより、リクエストの見落としを防ぐ。
リクエスト内容に含まれる注文番号と請求先メールアドレスが既存の注文と一致する場合、リクエストは自動的にその注文に紐付けられ、注文メモが追加される。これにより、店舗担当者は注文詳細画面からリクエストの存在を確認できる。
一致する注文が見つからない場合でも、リクエスト自体は受け付けられ、顧客には確認メールが送信される。通知には手動確認が必要であることを示すフラグが付けられ、注文へのリンクはスキップされる。この設計により、注文番号の入力ミスやゲスト購入の注文でも、リクエストが拒否されることはない。
重要な点として、撤回リクエストの送信は注文ステータスを変更しない。注文が自動的にキャンセルされたり、返金が実行されたりすることもない。リクエストはあくまで「撤回の申し出」であり、その後の対応（返金の承認、商品返送の依頼、追加情報の確認など）は店舗側の判断に委ねられる。
導入前に確認すべき注意点
注文撤回機能は店舗運営の効率化に寄与するが、いくつかの注意点がある。まず、この機能がEUの法的要件への準拠を保証するわけではないという点を理解しておく必要がある。WooCommerce Developer Blogの記事でも、事業内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
リクエスト処理のワークフロー設計
撤回リクエストが届いた後の対応フローは、店舗自身で設計する必要がある。返金を承認するのか、商品の返送を求めるのか、追加情報を確認するのか。これらの判断基準を事前に決めておかないと、リクエストが届いてから担当者が迷うことになる。
特に、注文ステータスが自動変更されない点は運用上のポイントだ。リクエストが届いても注文は「処理中」などの状態のまま残るため、店舗側で明示的に注文をキャンセルする処理が必要になる。この部分を社内で共有しておかないと、注文が放置されるリスクがある。
ゲスト購入への対応
ログインしていない顧客でもリクエストを送信できる設計は、ゲスト購入が多いストアにとって重要な特徴だ。ただし、ゲスト購入の注文は注文番号とメールアドレスの照合が手動になる可能性がある。手動確認フラグが付いたリクエストを担当者が見逃さないよう、通知の確認ルールを決めておく必要がある。
実務的には、EU向け販売を行うストアにとって注文撤回機能は顧客対応の手間を大幅に減らす可能性がある。メールや電話での個別対応から、システム化されたリクエスト処理へ移行することで、対応の一貫性と記録の完全性が向上する。一方で、リクエスト受信後のワークフローが未整備のままでは、かえって対応が遅れるリスクもある。
注文撤回機能は、WooCommerce 11.1の新機能としてEU対応ストアに実用的な選択肢を提供する。導入を検討する場合は、機能の有効化だけでなく、社内の対応フローまで含めて計画することをおすすめする。
この記事のポイント
- WooCommerce 11.1に注文撤回機能が追加され、顧客が自己対応で撤回リクエストを送信できる
- EUの14日間撤回権に対応する仕組みで、既定では無効化されている
- 顧客はフォーム入力から確認メール受信まで自動フローで完了できる
- 店舗にはメールとインボックスの二重通知が届き、注文への自動リンクも行われる
- 注文ステータスは自動変更されないため、受信後のワークフロー設計が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooPaymentsでカード追加ページが真っ白になる原因と解消手順
WooCommerceでWooPaymentsを使っているサイトで、購入時のカード保存は正常に動くのにマイアカウントのカード追加ページだけが真っ白になる場合、多くはJavaScriptエラーかプラグインによるテンプレート競合が原因だ。開発者ツールでエラーの実体を特定し、プラグインとテーマの切り分けを順に行うと短時間で解消できる。
なぜカード追加ページだけが真っ白になるのか
WooPaymentsのカード入力フォームは、チェックアウト画面でもマイアカウント内でもJavaScriptで動的に描画される。特にカード追加ページでは、WooPaymentsが提供するStripe Elementsという入力部品を読み込んでフォームを生成する仕組みだ。
このとき、他のプラグインが読み込むスクリプトと衝突したり、テーマがマイアカウントのテンプレートを上書きしてフォームの置き場所が消えたりすると、ページが真っ白に見える。PHPの致命的エラーが起きている場合も同様の症状になる。
保存済みカードの一覧表示は正常なのにカード追加だけが空になるのは、表示に異なる読み込み経路が使われるためだ。一覧はすでにデータベースへ保存された情報をPHPだけで描画できるが、カード追加フォームはJavaScriptの実行が必須になる。だからこそ、スクリプトエラーが症状としてそのページだけに出やすい。
また、WooPaymentsのアップデート時にファイルの一部が欠けた場合もフォームが表示されない。エラーがどこにも出ないまま空白だけになるケースでは、プラグイン本体の再インストールも選択肢に入る。
ブラウザの開発者ツールでエラーを特定する手順
まず最初に、ブラウザの開発者ツールを使って実際に何が止まっているのかを確認する。エラーが特定できれば、その後の切り分けが大幅に短くなる。
このデモは、エラー特定までの基本フローを示している。コンソールとネットワークの両方を確認すると原因ファイルが見つかりやすい。
コンソールでJavaScriptエラーを確認する
カード追加ページを開いた状態でF12キーを押し、「コンソール」タブを開く。赤い文字で表示されるエラーが1件以上あれば、その内容を控えておく。英語表示の場合は「Uncaught TypeError」や「Failed to load resource」のような記述が手がかりになる。
エラーの右側に表示されるファイル名も重要だ。どのプラグインのスクリプトが失敗しているかが分かれば、無効化の対象を特定できる。たとえば `woocommerce.js` や `stripe.js` が読み込めていなければ、キャッシュやプラグイン本体の問題を疑う。
ネットワークタブで読み込み失敗を確認する
同じく開発者ツールの「ネットワーク」タブを開き、ページを再読み込みする。ステータスが「404」や「500」になっているファイルがないかを確認する。404はファイルが存在しない、500はサーバー処理の失敗を意味する。
とくにカードフォームの描画に必要なJavaScriptファイルが404になっていると、ページが白いまま何も表示されない。この場合はWooPaymentsのファイルが不完全な可能性が高い。
プラグインとテーマの競合を切り分ける手順
開発者ツールで原因が特定できない場合は、定番の切り分け作業を順に行う。目的は、どのプラグインまたはテーマがカード追加ページの表示を妨げているかを絞り込むことだ。
切り分け前
全プラグインが有効のまま「カード追加」を開くと
ページが真っ白でフォームが表示されない
どのプラグインが影響しているか不明
切り分け後
WooCommerceとWooPaymentsだけを有効にすると
カード入力フォームが正常に表示される
原因プラグインをひとつずつ有効化して特定できる
このデモは、プラグイン競合の切り分け前後で何が変わるかを示している。競合元を特定しなければ恒久的な解決にはならない。
全プラグインを無効化してWooCommerce系だけ有効化する
管理画面の「プラグイン」へ移動し、(WooCommerceとWooPayments以外の)すべてのプラグインを無効化する。この状態でカード追加ページを開いてフォームが表示されるか確認する。
フォームが表示された場合は、無効化したプラグインをひとつずつ有効化して、どのプラグインを有効にした時点で再発するかを確認する。マイアカウントの表示をカスタマイズするプラグインや、管理画面用のスクリプトを全ページに読み込むプラグインが原因になりやすい。
この作業で一時的にサイト機能が変わるため、アクセスの少ない時間帯に行うか、ステージング環境があればそちらで再現させる。WooCommerceとWooPaymentsは必ず有効のままにして検証する。
標準テーマに切り替えてテーマの影響を除外する
プラグインをすべて無効化しても症状が続く場合は、テーマが原因の可能性がある。管理画面の「外観」→「テーマ」で、Twenty Twenty-FourなどのWordPress標準テーマへ一時的に切り替える。
標準テーマでカード追加フォームが表示されるなら、元のテーマがマイアカウントのテンプレートを上書きしていることになる。テーマに含まれる `woocommerce` フォルダの `myaccount` 関連ファイルが、カード追加ページの表示を妨げているケースが多い。
テーマを切り替えるとウィジェットやカスタマイズ設定が変わることがあるため、検証後は必ず元のテーマへ戻す。できればステージング環境での検証を推奨する。
WooPaymentsの設定とパーマリンクを再確認する
切り分けを行っても原因が見つからない場合、WooCommerceの設定とパーマリンクを再確認する。設定が正しくても保存し直すだけで直るケースがある。
カード追加エンドポイントの設定を保存し直す
管理画面の「WooCommerce」→「設定」→「詳細設定」タブを開き、「アカウントエンドポイント」欄を確認する。カード追加の項目が正しく入力されていることを確認し、入力内容そのものに変更がなくても一度「変更を保存」を押す。
パーマリンクの内部マップがずれていると、ページ自体は存在してもWooCommerceがエンドポイントを認識できないことがある。保存し直すだけでマップが再構築されるため、手軽に試せる。
保存済みカード決済の設定を確認する
「WooCommerce」→「設定」→「決済」タブでWooPaymentsを開き、「カード決済」が有効であることと「保存済みカードによる支払いを有効にする」にチェックが入っていることを確認する。購入時のカード保存は正常でも、この設定が外れるとマイアカウントからの追加だけが動作しないことがある。
パーマリンクを更新してエンドポイントを再マップする
管理画面の「設定」→「パーマリンク」へ移動し、設定を変更せずそのまま「変更を保存」を押す。これでリライトルールが再生成され、マイアカウントの各エンドポイントが正しく認識されるようになる。
パーマリンク更新後は必ずキャッシュプラグインのキャッシュを全削除する。キャッシュが残っていると、古い状態のページが配信されて症状が続いているように見える。
再発を防ぐための更新前チェックとログ確認
根本解決できたら、次回のアップデートで同じ問題が起きないように更新前チェックの習慣をつけておく。WooPaymentsは更新頻度が高いプラグインのため、更新後に特定のページだけが壊れるリスクは常にある。
WooCommerceのログでPHPエラーを確認する
管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開き、直近のエラーログに「fatal-errors」のようなファイルがないかを確認する。PHPの致命的エラーが記録されていれば、その内容から原因ファイルを特定できる。
ログが存在しない場合は、WooPaymentsの「ログ」タブから決済関連の動作記録を確認する。カード追加フォームの読み込みに失敗した形跡がないかを探る。
WooPaymentsのファイルを再アップロードする
アップデート時にファイルの一部が欠けた疑いがある場合は、管理画面からプラグインを削除して再インストールする。その際、決済データはサーバー側に保存されているため、プラグインの削除で売上情報や顧客情報が消えることはない。
FTP接続でWooPaymentsのフォルダだけを最新版のファイルで上書きする方法もある。管理画面に入れる状態なら「プラグイン」→「プラグインの新規追加」からWooPaymentsを検索して入れ直す方が確実だ。
マイアカウント系ページをキャッシュ対象から除外する
キャッシュプラグインの設定で、マイアカウント関連のURLをキャッシュ対象から除外しておく。具体的には `/my-account/` で始まるパスを除外リストへ追加する。これにより、カードフォームや認証情報が古いキャッシュで表示される問題を防げる。
よくある質問
カード追加ページだけが真っ白になるのはなぜ？
そのページだけテンプレートやJavaScriptが干渉されている可能性が高い。WooPaymentsのカード入力フォームはJavaScriptで描画されるため、他のプラグインのスクリプトが衝突するとフォームが生成されず真っ白に見える。
開発者ツールにエラーが表示されない場合は？
コンソールにエラーが出ない場合、PHPの処理途中で止まっている可能性を疑う。wp-config.phpでデバッグを有効にしてエラーを可視化するか、WooCommerceのログを確認する。あわせてテーマのマイアカウント用テンプレートが正しいかも調べる。
WooPaymentsのバージョンを一つ前へ戻すと直る？
互換性が問題の場合は直ることがある。バージョン固定のダウングレードは応急処置として有効だが、セキュリティ更新を含む場合は推奨しない。まず競合の特定を優先し、どうしても手がかりがない場合に実施する。
キャッシュプラグインが原因になることはある？
ある。特にマイアカウント系のページをキャッシュしてしまう設定だと、カードフォームの読み込みだけが古い状態で配信されることがある。キャッシュ対象からマイアカウントを除外する設定も併せて確認する。
マイアカウントの表示をカスタマイズするプラグインは原因になりやすい？
なりやすい。カード追加ページのテンプレートやフックを書き換えるタイプのプラグインは、WooPaymentsのフォーム表示に直接影響する。無効化して症状が消えるかどうかを最初の切り分けで確認する。
この記事のポイント
- 開発者ツールのコンソールでJavaScriptエラーを特定する
- 全プラグインを無効化してWooCommerce系だけ有効化して切り分ける
- 標準テーマに切り替えてテーマ競合を除外する
- パーマリンクとエンドポイント設定を保存し直す
- WooPaymentsを再インストールしてファイルの健全性を回復する
- マイアカウント系ページをキャッシュ対象から除外する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceで小数数量の購入が通らない時の原因と対処法
WooCommerceのチェックアウトで小数数量（1.5kgや0.8mなど）を指定すると、line_itemsパラメータが無効というエラーが表示され、注文が完了できなくなる。原因はWooCommerceのデフォルト仕様でカート内の数量が整数として扱われるため。数量単位を変えて整数にするか、小数数量対応のプラグインを導入すれば解決できる。
なぜWooCommerceで小数数量を購入できないのか
WooCommerceの商品数量フィールドは、標準状態では1、2、3といった整数しか受け付けない。ところが、計量販売や布地・配線材など小数単位で売りたい商品は多く、小数を入力できるよう改造したサイトも存在する。
問題が表面化するのは、チェックアウトブロックを使っている場合だ。このブロックはStore APIと呼ばれるREST APIを通じて注文データをサーバーに送る。Store APIは送られてきた注文明細（line_items）を検証する際に、数量を整数としてチェックする。ここで小数が混ざっていると「line_itemsパラメータが無効」というエラーを返す。
従来のクラシックチェックアウト（ショートコード方式）では別の仕組みで注文を送るため、同条件でもエラーが出ないことがある。つまり「カートには小数で入るのに、チェックアウトブロックだけ失敗する」という症状になりやすい。
このデモは、小数数量がAPI検証で拒否される流れと、単位を変換して整数にした場合の成功フローを示している。エラーの根本原因はフロント側の表示ではなく、APIが受け取る数量の形式にある。
数量単位を変えて整数だけで販売する手順
もっとも手軽で確実な方法は、商品の販売単位そのものを細かくして、顧客が常に整数で数量を入力できるようにする方法だ。たとえば1.5kgの商品を売るなら、販売単位を「kg」から「100g」に変更し、顧客には15と入力してもらう。
食品・重量商品の場合
コーヒー豆や精肉、チーズなど重量で売る商品では、単位をグラムに切り替えるだけで解決できる。商品名に「100gあたり」と明記し、価格も100g単位で設定する。1.5kg買いたい顧客は数量欄に15と入力すればよい。
布地・ロープ・配線材の場合
メーター単位で切売りする商品は、センチメートル単位に変換するのが有効だ。1.5mは150cmとして、数量欄には150と入力してもらう。商品タイトルに「1cm単位で販売」と明記すれば混乱も防げる。
在庫管理とSKUの見直し
単位を変えたら在庫数とSKUも新しい単位に合わせて更新する必要がある。1kgの在庫は1000gとして記録し、SKUも単位が分かる番号に変更しておくと後の運用が楽になる。既存の注文データには影響しないので、商品単価と在庫だけを慎重に更新する。
小数数量対応のプラグインで解決する方法
どうしても小数数量を維持したい場合は、小数数量に対応したプラグインを導入する方法がある。WooCommerce公式のエクステンションストアには、数量の刻み幅を小数で設定できる拡張が複数配布されている。
プラグインを選ぶ際の確認ポイントは、次の3点だ。まず、チェックアウトブロック（Store API）に対応していること。フロント側の数量入力だけを変更しても、API検証で拒否されれば同じエラーが再発する。次に、在庫管理でも小数を扱えること。最後に、WooCommerceの最新バージョンで動作確認されていること。
導入後は、商品編集画面に小数ステップの設定欄が追加される。数量の刻み幅を0.1に設定し、最小数量も小数で指定する。設定を保存したら、必ずテスト注文で小数数量が通るか確認する。カートに入れる段階とチェックアウト実行の両方でエラーが出ないことを確かめる。
開発者向けカスタムコードで数量の小数を許可する方法
自作テーマやカスタムプラグインで対応する場合は、数量入力フィールドの引数をフィルターで変更する。以下のコードは、テーマのfunctions.phpやCode Snippetsプラグインに追加する想定だ。
add_filter( 'woocommerce_quantity_input_args', 'allow_decimal_quantity', 10, 2 );
function allow_decimal_quantity( $args, $product ) {
$args['step'] = '0.1';
$args['min_value'] = '0.1';
return $args;
}ただし、このコードだけではフロント側の入力欄が小数に対応するだけで、Store APIの検証までは通過しないことがある。チェックアウトブロックを使う場合は、API側のスキーマを拡張する追加のフィルターが必要になる。Store APIのline_itemsで数量の型を変更するには、より深い層への対応が求められる。
実務では、Store API対応を自前で実装するより、小数数量対応をうたうプラグインを利用する方がリスクが小さい。APIスキーマの変更はアップデートで挙動が変わる可能性があり、受注データの整合性にも関わるためだ。
小数数量が必要な商品の販売方法を再設計する
エラーの対処と並行して、そもそも小数数量を使わずに済む販売設計を検討するのも有効だ。商品の性質によっては、属性（バリエーション）を使う方がシンプルで顧客にも分かりやすい。
よく買われるサイズをバリエーションで用意する
布地やケーブルなら「50cm」「1m」「1.5m」「2m」のように、よく注文されるサイズをあらかじめバリエーションとして登録する。顧客は数量1を選ぶだけで済み、小数入力は不要になる。在庫管理も単位が明確になるため、発注ミスも減らせる。
計量販売プラグインの活用
重量や長さに応じて価格を自動計算する計量販売向けの拡張を使う手もある。顧客が重さや長さを入力すると、対応する価格が自動で表示される仕組みだ。この方式なら小数数量を直接カートに入れる必要がなく、エラーの発生を回避できる。
よくある質問
小数数量を使うと必ずこのエラーになりますか
いいえ。従来のクラシックチェックアウト（ショートコード方式）では、フロント側で小数を許可していれば通ることがある。エラーが起きやすいのはチェックアウトブロックを使っており、Store API経由で注文を送信する構成だ。
商品ごとに小数数量を許可できますか
できる。小数数量対応プラグインの多くは商品単位で設定を持っており、小数を許可する商品と整数のみの商品を混在させられる。カスタムコードでも商品IDやカテゴリを条件にフィルターを適用できる。
数量単位をgに変更すると在庫管理はどうなりますか
在庫数も新しい単位に合わせて記録し直す必要がある。1kgの在庫は1000gとして登録し、SKUも単位が分かる体系に変更するのが望ましい。既存の注文履歴には影響しないため、商品単価と在庫数を慎重に更新すればよい。
すでに小数数量で登録した商品がある場合はどうすればよいですか
商品データを確認し、数量の刻み幅や単位設定を見直す。複数商品を一括で変更するなら、WooCommerce標準の商品CSVエクスポート・インポート機能を使うと効率的だ。変更後はテスト注文で必ず動作を確認する。
チェックアウトブロックだけでエラーになるのはなぜですか
チェックアウトブロックはStore APIというREST API経由で注文データをサーバーに送信する。このAPIがline_itemsを検証する際、数量を整数としてチェックするため、小数が混ざると検証エラーになる。クラシックチェックアウトは別の送信方式のため、同じ条件でも通ることがある。
この記事のポイント
- 小数数量の購入エラーはStore APIのline_items検証が原因
- もっとも手軽な対処は数量単位を変えて整数で販売すること
- 小数数量を維持したい場合は対応プラグインの導入が有効
- チェックアウトブロック対応の有無を確認してからプラグインを選ぶ
- カスタムコードはフロント側だけでは不十分でAPI側の対応も必要
- 属性や計量販売方式への再設計も検討価値がある
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce 11.1ベータ版が公開！EU注文撤回と返金APIの全容
WooCommerce 11.1のベータ版が公開された。今回のリリースではEU顧客向けの注文撤回フロー、REST APIの新しい返金計算エンドポイント、バリエーション商品のパフォーマンス改善が柱となる。正式版は2026年9月1日にリリース予定だ。
この記事では開発者向けブログの情報を基に、主要な変更点と実務への影響を解説する。ストア運営者とエクステンション開発者の双方が押さえておくべきポイントをまとめた。
WooCommerce 11.1の全体像
WooCommerce 11.1には大きく4つの改善領域がある。EU消費者保護に対応する注文撤回機能、返金計算を自動化するREST APIエンドポイント、商品CSVのインポートとエクスポートのバグ修正、そしてバリエーション商品の表示速度向上のためのパフォーマンス修正だ。
これらに加え、エクステンション開発者向けの互換性修正も複数含まれる。ブロック登録のスキップによる管理画面の負荷軽減、エディタアセットの統合実験など、開発者向けの変更も見逃せない。なお、この段階ではあくまでベータ版であり、フィードバックが募集されている。
この図はWooCommerce 11.1の4つの柱を示している。それぞれの詳細を順に見ていこう。
EU顧客向けの注文撤回フローが登場
WooCommerce 11.1では、EU消費者保護指令に基づく注文撤回権（right of withdrawal）に対応する機能が追加された。顧客はマイアカウントの専用ページから注文撤回を申請できる。EU圏では消費者が契約後一定期間内に理由なく注文を取り消せる権利が法律で定められている。この機能はその権利をストア運営者がスムーズに扱うための仕組みだ。
顧客が注文撤回を申請すると、ストア運営者にメール通知と管理画面のインボックス通知が届く。加盟店はその通知を確認して返金手続きを進める流れだ。申請時に認証は不要で、顧客は管理画面のワードプレスログインを必要としない。これはEUの消費者保護の原則に沿った設計である。
注文撤回の申請から返金までの流れはこの3ステップで完結する。ストア運営者は通知を確認してから対応すればよいため、顧客とのやり取りを記録しやすい。
この機能はデフォルトでは無効化されている。利用するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、注文撤回機能を有効化する必要がある。EU圏向けにストアを運営している場合は導入を検討したい。
REST APIの返金エンドポイントが強化された
返金処理を外部システムから操作する開発者にとって大きな変更が入った。WooCommerce REST APIの返金フローが更新され、サーバー側で返金額を自動計算できるようになった。従来は返金額を手動で計算してリクエストに含める必要があったが、その手間を省ける。
既存の返金エンドポイントに compute_totals フィールドが追加された。このフィールドに true を指定すると、WooCommerceサーバーが商品代金、送料、税を自動的に計算して返金額を確定する。計算ミスによる返金誤りを防げるのが利点だ。
POST /wc/v3/orders/123/refunds
{
"compute_totals": true
}この例では注文番号123に対して返金リクエストを送信している。ボディに compute_totals を指定するだけで、あとはWooCommerceが注文の明細を基に返金額を算出する。手動で計算する必要がなくなった。
さらに新しいプレビューエンドポイントも追加された。POST /wc/v3/orders/123/refunds/preview を使うと、実際に返金を実行せずに計算結果だけを確認できる。返金額を事前に検証したいケースや、顧客に返金額を提示する前に確認したいケースで重宝する。
POST /wc/v3/orders/123/refunds/previewこのプレビューエンドポイントは、返金処理を自動化するシステムを構築する際にデバッグと金額確認を容易にする。実際に返金を実行せずに結果を確認できるため、開発環境でのテストにも適している。
compute_totals を true にするだけでサーバーが自動計算この比較が示すように、返金処理の負担が大きく軽減された。外部システムから返金を自動化する際の堅牢性も向上している。
Store APIのチェックアウト金額チェック
Store APIにも改善が入った。チェックアウトエンドポイントに expected_total というオプションフィールドが追加された。このフィールドには顧客が画面上で確認した合計金額を整数で指定する。サーバー側で計算した金額と一致しない場合、リクエストは失敗し、新しい 409 エラーレスポンスが返される。
このエラーレスポンスのコードは woocommerce_rest_checkout_total_mismatch で、金額の不一致が発生したことをシステムが判別できる。顧客が画面で見た金額と実際に請求される金額が食い違う事故を未然に防ぐための仕組みだ。
この仕組みはチェックアウトの金額改ざんや画面表示の不整合を検出するために有効だ。決済処理を独自に実装している場合は特に注目したい。
バリエーション商品のパフォーマンス改善
バリエーション商品を多数抱えるストアでは、商品編集画面や店舗フロントの表示が遅くなる問題があった。WooCommerce 11.1ではこの問題に対処する複数のパフォーマンス修正が含まれている。主な改善は、バリエーションと属性の読み込み時に発生するN+1クエリの削減だ。
N+1クエリとは、1つの親データを取得した後、子データを1件ずつ追加で取得してしまう非効率なデータベースアクセスのことだ。たとえば100件のバリエーションがあると、101回のクエリが実行される。修正後は必要なデータをまとめて取得するため、クエリ回数が大幅に減る。
加えて価格キャッシュの処理も改善された。変動価格商品の価格計算ではキャッシュを活用してクエリを削減している。管理画面とフロントエンドの両方で、商品数の多いストアほど体感できる差が生まれるはずだ。
ブロック登録の条件付きスキップ
WooCommerce 11.1では、ブロックタイプとパターンの登録処理が見直された。従来はほぼすべてのリクエストでブロックが登録されていたが、新しい BlockRegistrationContext ガードを導入し、cron、AJAX、REST APIリクエストでは登録をスキップするようになった。
フロントエンド、管理画面、エディタの動作は従来通り維持される。つまり、実際にブロックを描画または編集する場面でのみ登録が走り、不要な場面では処理を省く。これにより管理画面のバックエンド処理が軽くなる。
1つ例外がある。商品やバリエーションの説明文にWooCommerceブロックが含まれている場合、woocommerce_short_description フィルターを通じて必要に応じてブロックタイプが登録される。商品REST API、Store API、バリエーションAJAXエンドポイント、商品ウェブフックでも説明文が正しく描画される。
エクステンション開発者への影響もある。すべてのリクエストでブロック登録が走ることを前提にした実装は修正が必要になる。新しい woocommerce_should_register_blocks フィルターで、スキップされたコンテキストでもブロックを登録するようにオプトインできる。
メールエディタの更新
ブロックベースのメールエディタにも機能追加があった。core/embed ブロックが、クリック可能なサムネイルを描画するプロバイダーで挿入できるようになった。対象はYouTube、Vimeo、VideoPress、TikTok、Dailymotion、そしてWordPressの埋め込みだ。WordPressの埋め込みはリッチなリンクカードとして表示される。
オーディオプロバイダーは対象外だ。また、未対応のプロバイダーからの埋め込みは貼り付けることはできるが、エディタが警告を表示し、配信時にはリンクとして送信される。メールに動画サムネイルを入れたい場合は、対応プロバイダーのURLを使うとよい。
パーソナライゼーションタグのコールバックにも改善が入った。タグが送信先のコンテンツタイプを受け取れるようになり、HTML、プレーンテキスト、href 属性のそれぞれに適切にエスケープできるようになった。新しいパラメータはオプションで、デフォルトはHTMLだ。自動エスケープは新しく登録されたテキスト型タグにのみ適用される。
実験的機能のプレビュー
WooCommerce 11.1には2つの実験的機能が含まれている。1つは統合ブロックエディタアセットだ。ブロックごとに個別のスクリプトとスタイルを読み込む代わりに、共有のJavaScriptとCSSバンドルに置き換える仕組みである。
テストによると、エディタのアセット数が91.7%削減され、ネットワーク転送サイズが48.3%減少、スタイルバンドルは62.3%小さくなった。フロントエンドのアセットには変更がない。デフォルトでは無効で、WooCommerceの設定画面から「詳細 → 機能 → 実験的機能」と進んで有効化できる。
この実験的機能が正式採用されれば、ブロックエディタの読み込み速度が大きく改善される。開発段階の指標ではあるが、かなり有望な結果だ。
もう1つの実験的機能は商品ギャラリービデオの内部ストレージだ。商品ギャラリーに動画を追加する第一歩として、動画データを保存する内部構造がフラグの後ろに実装された。設定画面から「商品ギャラリービデオ（ベータ）」を有効化すると使える。
開発者向けの互換性注意事項
WooCommerce 11.1では開発者が把握しておくべき互換性修正が複数含まれている。is_rest_api_request() 関数は、これまで /wp-json/ のパーマリンクパスのみでRESTリクエストを検出していた。今回の修正で、空でない rest_route クエリパラメータもRESTリクエストとして扱うようになった。クエリ形式のRESTルートを使う実装では挙動が変わる可能性がある。
ProductGalleryUtils::get_product_gallery_image_count()は非推奨となり、get_product_gallery_media_count()に置き換えられた。旧メソッドは非推奨通知を出すシムとして復元されている- 数量ステッパーのDOM順序が視覚的な順序と一致するように修正された。旧DOM順序に依存するCSSを書いているテーマは再テストが必要だ
WC_Order_Item_Product::set_product()はvariation_idをリセットするようになった。部分的なREST注文更新ではproduct_idが変わらない場合、variation_idが保持されるsearch_products()はORグループの結合を括弧で囲むようになった。これにより include、exclude、status、type の条件が全グループに適用される。結果セットが変わる- 新しい
GET /wc-analytics/activity-panel/countsエンドポイントが3つの従来エンドポイントを統合し、管理画面のページ読み込みあたり6回のリクエストを1回に削減する - アナリティクスページの出力からリクエスト由来のプロパティが除去された。キャッシュされたページが別の訪問者のリクエストデータを漏洩する事故を防ぐ
@woocommerce/entitiesはwindow.wc.wcEntitiesで内部ユーティリティを公開しなくなった。これらはもともと公開APIではない- 通貨記号の出力がMOP（P から MOP$）とZMW（ZK から K）で変更された。既存の記号オーバーライドフィルターは引き続き動作する
この記事のポイント
- WooCommerce 11.1ベータ版は2026年9月1日に正式リリース予定
- EU顧客向けの注文撤回フローが追加され、デフォルトでは無効
- REST APIに返金自動計算とプレビューエンドポイントが登場
- Store APIの
expected_totalによりチェックアウト時の金額不一致を検出 - バリエーション商品のN+1クエリ削減で管理画面とフロントの表示が高速化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方
ECサイトでWooCommerceのクラシックカートとクラシックチェックアウトにApple PayやGoogle Payのボタンが表示されない場合、原因の多くはStripeが提供するホスト型決済方法設定がショートコード版ページのJavaScript初期化と衝突していることにある。商品ページやブロックカートでは正常でも、ショートコード版だけ動かないという状況では、決済ゲートウェイの初期化スクリプトが正しく読み込まれていない可能性が高い。
なぜクラシックカートだけApple PayとGoogle Payが表示されないのか
WooCommerceのStripeゲートウェイは、ページの種類に応じて決済ボタンを表示するためのJavaScriptを別々のタイミングで初期化する。ブロックカートとブロックチェックアウトは新しいGutenbergブロックとしてレンダリングされるため、StripeのExpress Checkoutボタンを配置する専用のコンテナが自動で用意される。
一方、クラシックカートとクラシックチェックアウトはショートコード（[woocommerce_cart]と[woocommerce_checkout]）でページに埋め込まれる。この方式では、テーマのJavaScriptやjQueryの読み込み順によってStripeの初期化スクリプトが正しく実行されず、ボタンが表示されないことがある。特にカスタムテーマやテーマビルダーを使っている場合は競合が起きやすい。
もう一つの有力な原因が、WooCommerceのログに出力されている「Stripe-hosted payment method configuration（ホスト型決済方法設定）」への切り替えエラーだ。Stripeがホストする決済方法設定に切り替わると、従来のローカル設定で動いていたExpress Checkoutボタンの初期化ロジックと整合しなくなることがある。これはStripeアカウント側の設定変更によって発生する。
つまり、症状がショートコード版ページに限定されるのは、決済ゲートウェイ自体の設定ミスではなく、ページのレンダリング方式とStripeスクリプトの初期化タイミングのずれが主因であるケースがほとんどだ。
JavaScriptコンソールでエラーを確認する手順
真っ先に調べるべきは、クラシックカートとクラシックチェックアウトのページでJavaScriptエラーが出ているかどうかだ。ブラウザのデベロッパーツールを使えば、原因となるスクリプトを特定できる。
Chromeの場合、クラシックカートのページを開いた状態で「F12」キーを押し、「Console」タブを確認する。赤いエラーメッセージが表示されていれば、その内容を記録する。特にwc_stripe_upe_paramsやwp.escapeHtmlに関連するエラーはStripeゲートウェイの初期化失敗を示す代表的なものだ。
FirefoxやEdgeでも同様に、開発者ツールのコンソールから確認できる。スマートフォンで確認する場合は、パソコンのブラウザでデベロッパーツールを開き、デバイスエミュレーションモードにして同じページを読み込むとよい。
Stripeのホスト型決済方法設定を無効化する
WooCommerceのログにホスト型決済方法設定への切り替えエラーが出ている場合、Stripeダッシュボード側の設定を変更するか、プラグイン側でホスト型設定を手動設定に戻す必要がある。
このデモはStripe設定の確認から修正までの手順の流れを示したものだ。実際の管理画面の項目名はWooCommerce Stripeプラグインのバージョンによって若干異なる。
Stripeダッシュボードでは、ホスト型決済方法設定が有効になっていると、決済方法の組み合わせがStripeサーバー側で管理される。これがWooCommerce側のExpress Checkoutボタン初期化と競合し、クラシック版ページでのみボタンが出ない状態を引き起こすことがある。WooCommerce側のStripe設定画面で「決済方法を手動で管理」するオプションを選択し、Apple PayとGoogle Payを明示的に有効化すると改善するケースが多い。
プラグインの再設定だけでは直らない場合は、Stripeアカウントの接続を一度解除して再接続するのも有効だ。WooCommerceの「決済」タブからStripeを選び、「接続を解除」を押した後、再度Stripeアカウントで接続する。この操作でプラグインがStripeサーバーから最新の設定を取得し直し、ホスト型決済方法設定とのずれが解消されることがある。
クラシックカートのショートコードとページ設定を再確認する
クラシックカートとチェックアウトのページに正しいショートコードが貼られているかも併せて確認する。カートページには[woocommerce_cart]、チェックアウトページには[woocommerce_checkout]が必須だ。
WooCommerceの「設定」→「詳細設定」タブにある「カートページ」と「チェックアウトページ」の指定が、実際にショートコードを貼ったページと一致しているか確認する。別のページを指定したままだと、表示されている地図ページとStripeの初期化対象ページがずれて、ボタンが出ないことがある。
ページビルダー（ElementorやBeaver Builderなど）でカートページを作成している場合は、ショートコードウィジェットを配置しているか確認する。ページビルダーのテキストブロックにショートコードを直接入力していると、WooCommerceのテンプレートフックが正しく読み込まれず、StripeのExpress Checkoutボタン用のフックが実行されないことがある。
キャッシュとCDNを削除して再テストする
設定変更後もボタンが表示されない場合は、サーバー側のキャッシュとCDNのキャッシュが古いスクリプトを配信し続けている可能性がある。WooCommerce専用のキャッシュプラグインを使っている場合は、そのキャッシュを全削除する。CDN（コンテンツデリバリネットワーク / 配信網）を利用している場合は、CDNのダッシュボードからキャッシュをパージする。
その後、シークレットウィンドウ（プライベートブラウジング）でクラシックカートのページを開いて確認する。通常のブラウザに残っているクッキーやサービスワーカーが古いスクリプトを参照していることがあるため、シークレットウィンドウで確認するとキャッシュの影響を排除できる。
それでも直らない場合、一時的にすべてのプラグインを無効化して標準テーマに切り替え、WooCommerceとStripeゲートウェイだけを有効化した状態でテストする。この最小構成でボタンが表示されれば、別のプラグインかテーマが原因だ。影響しているプラグインを一つずつ有効化して切り分けていく。
よくある質問
商品ページではボタンが出るのにクラシックカートでは出ないのはなぜか
商品ページとクラシックカートではExpress Checkoutボタンを初期化するJavaScriptのフックが異なる。商品ページはWooCommerce標準のフックで動くが、カートとチェックアウトはページテンプレートの構造に依存するため、テーマやプラグインの競合で初期化が妨げられることがある。
ブロックカートに切り替えれば解決するのか
ブロックカートとブロックチェックアウトはGutenbergブロックとしてレンダリングされるため、Stripeゲートウェイが専用コンテナを確実に配置でき、ボタンが正常に表示される。どうしてもクラシック版を使い続ける必要がなければ、ブロック版への移行は有効な回避策になる。
Stripeアカウントの再接続だけでは直らない場合はどうするか
再接続で直らない場合は、WooCommerceのStripe設定画面でExpress Checkoutボタンの表示オプションを一度すべてオフにして保存し、再度オンにして保存する。これでプラグインの設定値がリフレッシュされ、クラシックページ用のフックが再登録されることがある。
ログに出るホスト型決済方法設定のエラーは無視してよいか
無視しないほうがよい。ホスト型決済方法設定への切り替えエラーは、Stripe側の設定とWooCommerceプラグインの設定が同期していない状態を示している。この状態を放置すると、クラシックページでのボタン非表示だけでなく、支払い処理自体に影響が出る可能性がある。Stripeダッシュボードで決済方法設定を確認し、手動設定に切り替えることを推奨する。
スマートフォンでもボタンが表示されないのは同じ原因か
基本的には同じ原因だ。ただしスマートフォンではApple PayとGoogle Payの表示条件が端末の対応状況にも左右される。iPhoneならSafari、AndroidならChromeで、ウォレットにカードが登録されていないとボタン自体が表示されない。パソコンで表示されることを前提に原因を切り分けるほうが正確だ。
この記事のポイント
- クラシックカートとチェックアウトだけボタンが出ないのはStripeスクリプトの初期化タイミングのずれが主因
- デベロッパーツールのコンソールでJavaScriptエラーを確認する
- Stripeダッシュボードのホスト型決済方法設定を手動設定に切り替える
- ショートコードの貼付位置とWooCommerceの設定ページ指定が一致しているか確認する
- キャッシュとCDNを削除し、シークレットウィンドウで再テストする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceのバリエーション商品だけ検索にヒットしない時の原因と直し方
WooCommerceで複数のバリエーションを持つ商品のうち特定のバリエーションだけサイト内検索に表示されない場合、Algoliaなどの検索インデックスに「非公開扱い」「価格未設定」「在庫切れの非表示」などの条件が記録されたままになっている可能性が高い。まず商品編集画面で該当バリエーションの有効状態とカタログ表示の設定を確認し、再保存してインデックスを更新する。
なぜ特定のバリエーションだけ検索にヒットしないのか
WooCommerceはバリエーションを親商品とは別の商品データとして管理する。検索用のインデックスを作る仕組みでは、親商品に加えて各バリエーションが別レコードとして登録されることが基本になる。その際、各バリエーションの公開条件や商品データに不備があると、そのバリエーションだけインデックスから除外される。
たとえば一部のバリエーションは検索に出るのに特定の型番だけ出ないという症状は、インデックス全体の問題ではなく、該当バリエーションの扱いに原因が集中している場合が多い。親商品の更新では直らず、バリエーション単位の設定を見直す必要がある。
WooCommerceでバリエーションの公開設定を確認する手順
バリエーションが検索に引っかからない場合、まず商品編集画面から該当バリエーションを開き、公開状態とデータの入力を確認する。単純商品であれば「更新」ボタンを押すだけで直る症状でも、バリエーション商品は個別の設定がそのまま残ることがある。
このデモでは、検索に出ないバリエーションを確認する流れを示している。ここからは各ステップの詳細を見ていく。
「有効」チェックボックスがオフになっていないか
バリエーション編集画面の上部には「有効」のチェックボックスがある。ここがオフになっていると、そのバリエーションはカタログや検索から除外される。特定のバリエーションだけ検索に出ない場合、最初に確認したい項目だ。
チェックが外れている場合はチェックを入れて保存する。複数のバリエーションで同じ問題が起きているなら、一覧画面の絞り込み表示を活用し、無効化されたバリエーションだけを確認するのが早い。
価格と在庫が正しく入力されているか
バリエーションに価格が入力されていない場合、WooCommerceはそのバリエーションを非表示にする。また在庫切れでかつ「在庫切れ商品をカタログから隠す」設定が有効だと、検索インデックスからも外れる。価格と在庫はバリエーションごとに独立して管理されるため、親商品が正常でも特定のバリエーションだけ欠けていることがある。
親商品の「カタログ表示」設定が検索対象になっているか
親商品の編集画面には「カタログ表示」の設定がある。ここが「ショップと検索結果」または「検索結果のみ」になっていないと、その商品のバリエーション全体が検索に出なくなる。ただし一部のバリエーションはヒットするというケースでは、親商品の設定は原因になりにくい。それでも親商品が「非表示」になっていないか併せて確認しておく。
Algoliaにバリエーションが同期されない場合の対処
WooCommerceとAlgoliaを連携しているサイトでは、商品データの変更がAlgolia側に正しく同期されないと、特定のバリエーションだけ検索結果から漏れることがある。管理画面からインデックス設定と同期キューを確認する。
変動商品のインデックス設定を確認する
AlgoliaのWooCommerce連携プラグインには、バリエーションをインデックスに含めるかどうかの設定がある。ここが無効だと親商品だけが検索対象になり、バリエーションの型番検索が機能しない。設定を開き、バリエーションが検索可能になっているか確認する。
該当バリエーションを無効化して再度有効化する
検索に出ないバリエーションの「有効」チェックを一度外して保存し、その後に再びチェックを入れて保存する方法が有効なことがある。これによりWooCommerce側の更新イベントが発火し、Algoliaへの同期処理が再実行される。単純商品の「更新」で直るのと同じ理屈だが、バリエーションは親商品の更新だけではイベントが伝わらない場合がある。
インデックスキューをリセットして再構築する
Algolia連携プラグイン側でキューに滞留しているタスクがあると、一部の商品だけ同期されない。プラグインの設定画面からインデックスを再構築するか、キューをクリアしてから商品を再保存する。再構築には数分かかることがあるため、完了後に検索結果を確認する。
再保存しても直らない時に確認するデータ不整合
設定面で問題がないのにインデックスされない場合は、バリエーションデータそのものに不整合が起きている可能性がある。データベース上のpost_statusやSKUの重複を確認する。
重複するSKUや空の価格が原因になっていないか
SKUが別の商品と重複していると、検索プラグイン側でレコードの上書きや取り込みスキップが発生することがある。また親商品で価格を設定せずバリエーション側だけ価格を入れる運用では、空の値が検索条件から除外される場合もある。SKUの重複は管理画面の商品一覧からCSV書き出しなどで確認できる。
バリエーションの投稿状態が下書きになっていないか
WooCommerceのバリエーションは内部的に「product_variation」という投稿タイプで保存される。何らかの操作で投稿状態が下書きのままになっていると、検索インデックスに登録されない。通常は管理画面から確認できないため、WP CLIやデータベースの直接確認が必要になる。WP CLIが使える環境なら次のコマンドで該当バリエーションの状態を調べられる。
wp post list --post_type=product_variation --post_status=draft検索インデックスを更新したあとに確認する動作
設定とデータを修正したら、実際にサイトの検索窓から該当するバリエーションを検索して表示されるか確認する。検索結果に出るかだけでなく、リンク先のURLが正しく該当バリエーションに飛ぶかも見る。
フロントエンドで検索して該当バリエーションが出るか
型番やSKUを検索語にして、対象のバリエーションがヒットするか確かめる。キャッシュが残っていると更新前の結果が表示されることがあるため、ブラウザのシークレットウィンドウを使うか、サイト側のキャッシュを削除してから検索する。
検索結果のURLが正しいバリエーションに飛ぶか
バリエーション検索では、インデックスから返されるURLにバリエーション識別子が含まれていないと、親商品のページに飛んで該当するオプションが初期表示されない。検索結果をクリックして商品ページを開き、狙った型番が選択された状態で表示されるか確認する。URLに属性のクエリパラメータが付いているかを目視で確かめるのが確実だ。
よくある質問
バリエーション検索はWooCommerce標準機能でも使えるのか
WooCommerce標準の商品検索は親商品を対象にすることが多く、バリエーション単位の型番検索には対応が弱い。Algoliaなどの専用検索プラグインを入れることで、バリエーションごとのインデックスが可能になる。
Algoliaの再インデックスにかかる時間はどのくらいか
商品数が多いほど時間がかかる。数百件程度なら数分で完了するが、数千件を超える場合は10分以上かかることもある。完了後に何度か検索して結果が安定するのを確認する。
特定のバリエーションだけ在庫切れになるたびに検索から消えるのはなぜか
WooCommerceの設定で「在庫切れ商品をカタログから隠す」が有効になっていると、在庫がゼロになったバリエーションは検索インデックスから除外される。在庫切れでも検索に表示したい場合は、この設定を無効にするか、検索プラグイン側で在庫切れの扱いを調整する。
親商品を更新してもバリエーションが同期されないのはなぜか
Algolia連携プラグインによっては、親商品の更新イベントがバリエーションの個別更新まで伝わらないことがある。該当バリエーションを直接開いて保存するか、無効化と有効化の操作を行うことで同期が再開される。
バリエーションの一括修正はできるのか
商品一覧のCSV書き出しと取り込みを使うと、複数のバリエーションに対してSKUや価格、在庫を一括で修正できる。ただしインデックスへの同期までは自動で走らないことがあるため、取り込み後に再インデックスを実行する。
この記事のポイント
- 特定のバリエーションだけ検索に出ない原因は、公開状態や価格、在庫といったバリエーション単位の設定に集中している
- 商品編集画面で該当バリエーションを開き、「有効」チェックと価格、在庫を確認する
- 親商品の更新だけでなく、該当バリエーションを一度無効化して再度有効化すると同期が再開されることがある
- Algolia連携プラグインではインデックス設定と同期キュー、再構築の状態を確認する
- それでも直らない場合はSKU重複やpost_statusの不整合を調べる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Gmailが政治メールに専用レーンを新設。EC事業者が学ぶべき送信者検証と苦情率0.3%の意味
Gmailが政治メール向けにスパムフィルタを迂回できる新プログラムを発表した。2026年9月8日から、資格を満たす政治団体はGmailのVerified Sender Programに参加できる。この動きは政治メールだけでなく、EC事業者のメールマーケティングにも重要な示唆を与える。
プログラムの核心は、送信者検証と苦情率0.3%という2つの条件だ。検証済みの送信者は標準のスパムフィルタを回避できる一方、受信者からのスパム報告が一定を超えると資格を失う。本記事ではこの仕組みをECメール運用にどう活かすかを解説する。
Gmailが政治メールに専用レーンを新設
Gmailは2026年9月8日から、政治団体向けの新制度「Verified Sender Program」を開始する。この制度に参加した政治団体は、ポリシーに準拠したメールを個人のGmailアカウントに送る際、通常のスパムフィルタを経由せずに受信トレイへ届けられる。
対象となるのは、連邦選挙委員会や州・地方の選挙管理当局に登録された候補者、政党、政治活動委員会などだ。参加にはCampaign Verifyを通じた本人確認と経歴チェックが必要になる。キャンペーンドメインごとに検証できるメールアドレスは1つだけに限られる。
この制度は、Gmailが政治メールの扱いをめぐって長年続いてきた論争への回答でもある。2022年には共和党全国委員会がGoogleを提訴した。Googleは以前にも政治メールを一部のスパムフィルタから除外する試験運用を行っていたが、2023年初めに終了している。
送信者検証と苦情率0.3%の仕組み
新プログラムの参加条件は、送信者検証と苦情率の2つに集約される。送信者検証とは、メールの送信元が本人であることを技術的・制度的に確認する仕組みだ。政治団体はCampaign Verifyによる本人確認と経歴チェックを受け、セキュリティ要件とコンプライアンス要件も満たす必要がある。
もう1つの条件が苦情率0.3%未満だ。これは受信者が「スパム」と報告した割合を指す。14日間の平均が0.3%を超えると、プログラムのポリシー違反となる。つまり、検証済みの送信者であっても、受信者からのネガティブな反応が続けば優先レーンを失う。
この図は、送信者検証がメールの初期処理を変える一方で、受信者のフィードバックが依然として重要な役割を果たすことを示している。
EC事業者が学ぶべき3つのポイント
政治メール向けの制度だが、EC事業者にとっても学びは大きい。特にWooCommerceで注文確認メールやプロモーションメールを送る事業者は、この仕組みを自社の運用に置き換えて考えたい。
1つ目は送信者検証の重要性だ。Gmailが優先レーンの条件に検証を求めたのは、なりすましやフィッシングを防ぐためだ。EC事業者もSPF、DKIM、DMARCといった送信ドメイン認証を設定し、メールの正当性を示す必要がある。これらはメールの「身分証明書」のようなもので、設定していないと正規のメールでもスパム扱いされやすくなる。
2つ目は苦情率の監視だ。0.3%という閾値は政治メール向けだが、ECメールでも苦情率が高いと到達率が下がる。目安として0.3%は非常に厳しい数字だが、日々のモニタリングとリスト管理が欠かせない。購読解除の導線を明確にし、関与の低い宛先への配信を控えるだけでも改善できる。
3つ目は受信者フィードバックを運用に活かすことだ。Gmailのプログラムでは、検証済みでも受信者がスパム報告すれば通常のフィルタに戻る。EC事業者も同じで、開封率やクリック率だけでなく、スパム報告率や購読解除率を追う必要がある。
この3ステップを回すことで、Gmailのようなプラットフォームの変更にも強いメール基盤を作れる。
この記事のポイント
- Gmailは9月8日から政治メール向けにスパムフィルタ迂回の新制度を開始する
- 参加条件は送信者検証と苦情率0.3%未満の2つ
- 検証済みでも受信者のスパム報告が続けば優先レーンを失う
- EC事業者はSPF、DKIM、DMARCと苦情率監視をセットで運用したい
- WooCommerceのメールも送信者検証とフィードバック管理が到達率を左右する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験