タグアーカイブ WooCommerce

  1. ホーム   /  タグ付きの投稿: "WooCommerce"
2026年8月30日 0

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の記事でも、事業の内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。

従来の対応との違い

従来のフローでは、顧客がメールや電話で撤回の意思を伝え、店舗担当者が手動で注文を確認し、返金処理を行っていた。この方式には対応漏れや記録不足のリスクが伴う。注文撤回機能は、顧客が自己対応フォームからリクエストを送信し、システムが自動で記録と通知を行う。

従来の対応（Before）
顧客がメールや電話で個別に問い合わせる
顧客 メール送信 → 店舗担当者 手動で確認と返金
対応漏れや記録不足のリスクがある
↓
注文撤回機能（After）
顧客が自己対応フォームからリクエストを送信
顧客 フォーム送信 → 自動処理 記録と通知
確認メールが顧客に届き、店舗にも通知される

このデモで示した違いは大きい。顧客からの撤回リクエストがシステムに記録され、確認メールが自動送信されることで、店舗と顧客の双方に証跡が残る。対応の属人化を防ぎ、処理の一貫性を保てる。

有効化の手順

有効化の手順

注文撤回機能は既定では無効化されている。EU向け販売を行っていないストアでは不要な機能のため、必要な事業者だけが有効化する設計だ。設定はWooCommerceの管理画面から数ステップで完了する。

設定画面での操作

WooCommerceの設定画面を開き、詳細設定タブから機能セクションに移動する。そこに注文撤回のオプションが表示されるので、有効化して変更を保存するだけだ。設定完了後、顧客向けのリクエストフォームが /my-account/withdraw-order というURLで公開される。

エンドポイントのカスタマイズ

リクエストフォームのURLは変更できる。詳細設定のページ設定セクションでエンドポイントを編集すれば、自社の導線に合わせたURLに調整できる。標準のURLは /my-account/withdraw-order だ。

もう1つの重要な特徴として、このページはログイン状態に関わらず動作する。ゲスト購入した顧客でもフォームにアクセスしてリクエストを送信できる。EUの撤回権はゲスト購入者にも適用されるため、この設計は実務上欠かせない。

顧客から見た注文撤回フロー

顧客から見た注文撤回フロー

顧客が注文撤回ページにアクセスすると、短いリクエストフォームが表示される。必要な情報を入力し、送信前に内容を確認する画面を経てから送信する。送信後は確認画面が表示され、入力した内容を含む確認メールが自動的に届く。

STEP 1 注文撤回ページにアクセス
ログイン状態でもゲストでも利用できる
↓
STEP 2 リクエストフォームを入力
注文番号と請求先メールアドレスなどを入力する
↓
STEP 3 入力内容を確認
送信前に詳細をレビューする画面が表示される
↓
STEP 4 送信して確認メールを受信
確認画面が表示され、入力内容を含む確認メールが届く

この4ステップのフローは、顧客が自分の操作だけで撤回リクエストを完了できることを示している。確認メールには顧客が入力した内容が含まれるため、顧客はリクエストの記録を残せる。店舗側への電話やメールが不要になり、双方の手間を削減する。

確認メールが自動送信される点は法的にも意味がある。撤回権の行使を顧客が証明できる記録が残るため、後日のトラブルを防ぐ効果が期待できる。

店舗運営者から見た通知と管理

店舗運営者から見た通知と管理

顧客がリクエストを送信すると、店舗運営者には2つの経路で通知が届く。1つは撤回リクエストを知らせるメール通知、もう1つはWooCommerceホーム画面のインボックス通知だ。この二重の仕組みにより、リクエストの見落としを防ぐ。

リクエスト内容に含まれる注文番号と請求先メールアドレスが既存の注文と一致する場合、リクエストは自動的にその注文に紐付けられ、注文メモが追加される。これにより、店舗担当者は注文詳細画面からリクエストの存在を確認できる。

一致する注文が見つからない場合でも、リクエスト自体は受け付けられ、顧客には確認メールが送信される。通知には手動確認が必要であることを示すフラグが付けられ、注文へのリンクはスキップされる。この設計により、注文番号の入力ミスやゲスト購入の注文でも、リクエストが拒否されることはない。

STEP 1 リクエストを受信
メール通知とインボックス通知の両方が届く
↓
STEP 2 注文番号とメールアドレスを照合
既存注文と一致するかシステムが自動判定する
↓
分岐 一致する場合と一致しない場合で処理が変わる
注文が一致 注文に自動リンクされ、注文メモが追加される
注文が不一致 手動確認フラグが付き、注文へのリンクはスキップ

重要な点として、撤回リクエストの送信は注文ステータスを変更しない。注文が自動的にキャンセルされたり、返金が実行されたりすることもない。リクエストはあくまで「撤回の申し出」であり、その後の対応（返金の承認、商品返送の依頼、追加情報の確認など）は店舗側の判断に委ねられる。

導入前に確認すべき注意点

導入前に確認すべき注意点

注文撤回機能は店舗運営の効率化に寄与するが、いくつかの注意点がある。まず、この機能がEUの法的要件への準拠を保証するわけではないという点を理解しておく必要がある。WooCommerce Developer Blogの記事でも、事業内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。

リクエスト処理のワークフロー設計

撤回リクエストが届いた後の対応フローは、店舗自身で設計する必要がある。返金を承認するのか、商品の返送を求めるのか、追加情報を確認するのか。これらの判断基準を事前に決めておかないと、リクエストが届いてから担当者が迷うことになる。

特に、注文ステータスが自動変更されない点は運用上のポイントだ。リクエストが届いても注文は「処理中」などの状態のまま残るため、店舗側で明示的に注文をキャンセルする処理が必要になる。この部分を社内で共有しておかないと、注文が放置されるリスクがある。

ゲスト購入への対応

ログインしていない顧客でもリクエストを送信できる設計は、ゲスト購入が多いストアにとって重要な特徴だ。ただし、ゲスト購入の注文は注文番号とメールアドレスの照合が手動になる可能性がある。手動確認フラグが付いたリクエストを担当者が見逃さないよう、通知の確認ルールを決めておく必要がある。

実務的には、EU向け販売を行うストアにとって注文撤回機能は顧客対応の手間を大幅に減らす可能性がある。メールや電話での個別対応から、システム化されたリクエスト処理へ移行することで、対応の一貫性と記録の完全性が向上する。一方で、リクエスト受信後のワークフローが未整備のままでは、かえって対応が遅れるリスクもある。

注文撤回機能は、WooCommerce 11.1の新機能としてEU対応ストアに実用的な選択肢を提供する。導入を検討する場合は、機能の有効化だけでなく、社内の対応フローまで含めて計画することをおすすめする。

この記事のポイント

  • WooCommerce 11.1に注文撤回機能が追加され、顧客が自己対応で撤回リクエストを送信できる
  • EUの14日間撤回権に対応する仕組みで、既定では無効化されている
  • 顧客はフォーム入力から確認メール受信まで自動フローで完了できる
  • 店舗にはメールとインボックスの二重通知が届き、注文への自動リンクも行われる
  • 注文ステータスは自動変更されないため、受信後のワークフロー設計が必要
海田 洋祐
, , , , ,
EC制作
WooPaymentsでカード追加ページが真っ白になる原因と解消手順
2026年8月30日 0

WooPaymentsでカード追加ページが真っ白になる原因と解消手順

WooCommerceでWooPaymentsを使っているサイトで、購入時のカード保存は正常に動くのにマイアカウントのカード追加ページだけが真っ白になる場合、多くはJavaScriptエラーかプラグインによるテンプレート競合が原因だ。開発者ツールでエラーの実体を特定し、プラグインとテーマの切り分けを順に行うと短時間で解消できる。

なぜカード追加ページだけが真っ白になるのか

なぜカード追加ページだけが真っ白になるのか

WooPaymentsのカード入力フォームは、チェックアウト画面でもマイアカウント内でもJavaScriptで動的に描画される。特にカード追加ページでは、WooPaymentsが提供するStripe Elementsという入力部品を読み込んでフォームを生成する仕組みだ。

このとき、他のプラグインが読み込むスクリプトと衝突したり、テーマがマイアカウントのテンプレートを上書きしてフォームの置き場所が消えたりすると、ページが真っ白に見える。PHPの致命的エラーが起きている場合も同様の症状になる。

保存済みカードの一覧表示は正常なのにカード追加だけが空になるのは、表示に異なる読み込み経路が使われるためだ。一覧はすでにデータベースへ保存された情報をPHPだけで描画できるが、カード追加フォームはJavaScriptの実行が必須になる。だからこそ、スクリプトエラーが症状としてそのページだけに出やすい。

また、WooPaymentsのアップデート時にファイルの一部が欠けた場合もフォームが表示されない。エラーがどこにも出ないまま空白だけになるケースでは、プラグイン本体の再インストールも選択肢に入る。

ブラウザの開発者ツールでエラーを特定する手順

ブラウザの開発者ツールでエラーを特定する手順

まず最初に、ブラウザの開発者ツールを使って実際に何が止まっているのかを確認する。エラーが特定できれば、その後の切り分けが大幅に短くなる。

STEP 1 カード追加ページをブラウザで開く
↓
STEP 2 F12キーを押して開発者ツールを開く
↓
STEP 3 コンソールタブで赤いJavaScriptエラーを確認する
↓
STEP 4 ネットワークタブで読み込み失敗したファイルを探す

このデモは、エラー特定までの基本フローを示している。コンソールとネットワークの両方を確認すると原因ファイルが見つかりやすい。

コンソールで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の設定とパーマリンクを再確認する

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を再インストールしてファイルの健全性を回復する
  • マイアカウント系ページをキャッシュ対象から除外する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerceで小数数量の購入が通らない時の原因と対処法
2026年8月23日 0

WooCommerceで小数数量の購入が通らない時の原因と対処法

WooCommerceのチェックアウトで小数数量（1.5kgや0.8mなど）を指定すると、line_itemsパラメータが無効というエラーが表示され、注文が完了できなくなる。原因はWooCommerceのデフォルト仕様でカート内の数量が整数として扱われるため。数量単位を変えて整数にするか、小数数量対応のプラグインを導入すれば解決できる。

なぜWooCommerceで小数数量を購入できないのか

なぜWooCommerceで小数数量を購入できないのか

WooCommerceの商品数量フィールドは、標準状態では1、2、3といった整数しか受け付けない。ところが、計量販売や布地・配線材など小数単位で売りたい商品は多く、小数を入力できるよう改造したサイトも存在する。

問題が表面化するのは、チェックアウトブロックを使っている場合だ。このブロックはStore APIと呼ばれるREST APIを通じて注文データをサーバーに送る。Store APIは送られてきた注文明細（line_items）を検証する際に、数量を整数としてチェックする。ここで小数が混ざっていると「line_itemsパラメータが無効」というエラーを返す。

従来のクラシックチェックアウト（ショートコード方式）では別の仕組みで注文を送るため、同条件でもエラーが出ないことがある。つまり「カートには小数で入るのに、チェックアウトブロックだけ失敗する」という症状になりやすい。

エラー状態
カートに小数数量（例 1.5）が入る → チェックアウトブロックがStore APIへ送信 → line_itemsパラメータが無効
■ APIスキーマが数量を整数として検証し拒否
↓
修正後
数量を整数に変換（例 1.5kg → 1500g または 15個） → Store APIへ送信 → 検証を通過し注文完了
■ 整数のみで送信されるためエラーが発生しない
■ 小数数量によるエラー　 ■ 整数変換後の成功フロー

このデモは、小数数量が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側の対応も必要
  • 属性や計量販売方式への再設計も検討価値がある
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerce 11.1ベータ版が公開！EU注文撤回と返金APIの全容
2026年8月22日 0

WooCommerce 11.1ベータ版が公開！EU注文撤回と返金APIの全容

WooCommerce 11.1のベータ版が公開された。今回のリリースではEU顧客向けの注文撤回フロー、REST APIの新しい返金計算エンドポイント、バリエーション商品のパフォーマンス改善が柱となる。正式版は2026年9月1日にリリース予定だ。

この記事では開発者向けブログの情報を基に、主要な変更点と実務への影響を解説する。ストア運営者とエクステンション開発者の双方が押さえておくべきポイントをまとめた。

WooCommerce 11.1の全体像

WooCommerce 11.1の全体像

WooCommerce 11.1には大きく4つの改善領域がある。EU消費者保護に対応する注文撤回機能、返金計算を自動化するREST APIエンドポイント、商品CSVのインポートとエクスポートのバグ修正、そしてバリエーション商品の表示速度向上のためのパフォーマンス修正だ。

これらに加え、エクステンション開発者向けの互換性修正も複数含まれる。ブロック登録のスキップによる管理画面の負荷軽減、エディタアセットの統合実験など、開発者向けの変更も見逃せない。なお、この段階ではあくまでベータ版であり、フィードバックが募集されている。

EU対応 注文撤回フローを新規追加
↓
API強化 返金計算エンドポイントと金額チェックを追加
↓
性能改善 バリエーション商品のN+1クエリを削減
↓
開発者支援 ブロック登録のスキップと互換性修正

この図はWooCommerce 11.1の4つの柱を示している。それぞれの詳細を順に見ていこう。

EU顧客向けの注文撤回フローが登場

EU顧客向けの注文撤回フローが登場

WooCommerce 11.1では、EU消費者保護指令に基づく注文撤回権（right of withdrawal）に対応する機能が追加された。顧客はマイアカウントの専用ページから注文撤回を申請できる。EU圏では消費者が契約後一定期間内に理由なく注文を取り消せる権利が法律で定められている。この機能はその権利をストア運営者がスムーズに扱うための仕組みだ。

顧客が注文撤回を申請すると、ストア運営者にメール通知と管理画面のインボックス通知が届く。加盟店はその通知を確認して返金手続きを進める流れだ。申請時に認証は不要で、顧客は管理画面のワードプレスログインを必要としない。これはEUの消費者保護の原則に沿った設計である。

STEP 1 顧客がマイアカウントの専用ページから注文撤回を申請
↓
STEP 2 ストア運営者にメールとインボックス通知が届く
↓
STEP 3 加盟店が注文内容を確認して返金手続きを開始

注文撤回の申請から返金までの流れはこの3ステップで完結する。ストア運営者は通知を確認してから対応すればよいため、顧客とのやり取りを記録しやすい。

この機能はデフォルトでは無効化されている。利用するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、注文撤回機能を有効化する必要がある。EU圏向けにストアを運営している場合は導入を検討したい。

REST APIの返金エンドポイントが強化された

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

このプレビューエンドポイントは、返金処理を自動化するシステムを構築する際にデバッグと金額確認を容易にする。実際に返金を実行せずに結果を確認できるため、開発環境でのテストにも適している。

従来の返金処理（Before）
商品代金、送料、税を個別に計算して返金額を手動で入力
手計算による誤差や入力ミスのリスクがあった
↓
WooCommerce 11.1の返金処理（After）
compute_totals を true にするだけでサーバーが自動計算
プレビューエンドポイントで事前確認も可能

この比較が示すように、返金処理の負担が大きく軽減された。外部システムから返金を自動化する際の堅牢性も向上している。

Store APIのチェックアウト金額チェック

Store APIのチェックアウト金額チェック

Store APIにも改善が入った。チェックアウトエンドポイントに expected_total というオプションフィールドが追加された。このフィールドには顧客が画面上で確認した合計金額を整数で指定する。サーバー側で計算した金額と一致しない場合、リクエストは失敗し、新しい 409 エラーレスポンスが返される。

このエラーレスポンスのコードは woocommerce_rest_checkout_total_mismatch で、金額の不一致が発生したことをシステムが判別できる。顧客が画面で見た金額と実際に請求される金額が食い違う事故を未然に防ぐための仕組みだ。

金額一致（成功）
顧客の画面に表示された合計金額 → サーバー側の計算結果と一致
リクエストは成功して注文が確定する
↓
金額不一致（エラー）
顧客の画面に表示された合計金額 → サーバー側の計算結果と相違
409エラーが返り、注文は確定しない

この仕組みはチェックアウトの金額改ざんや画面表示の不整合を検出するために有効だ。決済処理を独自に実装している場合は特に注目したい。

バリエーション商品のパフォーマンス改善

バリエーション商品のパフォーマンス改善

バリエーション商品を多数抱えるストアでは、商品編集画面や店舗フロントの表示が遅くなる問題があった。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の設定画面から「詳細 → 機能 → 実験的機能」と進んで有効化できる。

有効化前 ブロックごとに個別のJSとCSSを読み込む
アセット数 100% / 転送サイズ 100% / スタイルバンドル 100%
↓
有効化後 共有バンドルに集約
アセット数 8.3% / 転送サイズ 51.7% / スタイルバンドル 37.7%

この実験的機能が正式採用されれば、ブロックエディタの読み込み速度が大きく改善される。開発段階の指標ではあるが、かなり有望な結果だ。

もう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クエリ削減で管理画面とフロントの表示が高速化
海田 洋祐
, , , , ,
EC制作
WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方
2026年8月21日 0

WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方

ECサイトでWooCommerceのクラシックカートとクラシックチェックアウトにApple PayやGoogle Payのボタンが表示されない場合、原因の多くはStripeが提供するホスト型決済方法設定がショートコード版ページのJavaScript初期化と衝突していることにある。商品ページやブロックカートでは正常でも、ショートコード版だけ動かないという状況では、決済ゲートウェイの初期化スクリプトが正しく読み込まれていない可能性が高い。

なぜクラシックカートだけApple PayとGoogle Payが表示されないのか

なぜクラシックカートだけ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コンソールでエラーを確認する手順

真っ先に調べるべきは、クラシックカートとクラシックチェックアウトのページでJavaScriptエラーが出ているかどうかだ。ブラウザのデベロッパーツールを使えば、原因となるスクリプトを特定できる。

Chromeの場合、クラシックカートのページを開いた状態で「F12」キーを押し、「Console」タブを確認する。赤いエラーメッセージが表示されていれば、その内容を記録する。特にwc_stripe_upe_paramsやwp.escapeHtmlに関連するエラーはStripeゲートウェイの初期化失敗を示す代表的なものだ。

FirefoxやEdgeでも同様に、開発者ツールのコンソールから確認できる。スマートフォンで確認する場合は、パソコンのブラウザでデベロッパーツールを開き、デバイスエミュレーションモードにして同じページを読み込むとよい。

Stripeのホスト型決済方法設定を無効化する

Stripeのホスト型決済方法設定を無効化する

WooCommerceのログにホスト型決済方法設定への切り替えエラーが出ている場合、Stripeダッシュボード側の設定を変更するか、プラグイン側でホスト型設定を手動設定に戻す必要がある。

STEP 1 Stripeダッシュボードにログインし「Payment Method Configurations」を開く
↓
STEP 2 作成済みの設定がホスト型になっていないか確認する
↓
STEP 3 WooCommerce管理画面の「Stripe設定」で決済方法を手動設定に切り替える
↓
STEP 4 クラシックカートとチェックアウトでボタンが表示されるか再テストする

このデモは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を削除して再テストする

設定変更後もボタンが表示されない場合は、サーバー側のキャッシュと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を削除し、シークレットウィンドウで再テストする
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WooCommerceのバリエーション商品だけ検索にヒットしない時の原因と直し方
2026年8月21日 0

WooCommerceのバリエーション商品だけ検索にヒットしない時の原因と直し方

WooCommerceで複数のバリエーションを持つ商品のうち特定のバリエーションだけサイト内検索に表示されない場合、Algoliaなどの検索インデックスに「非公開扱い」「価格未設定」「在庫切れの非表示」などの条件が記録されたままになっている可能性が高い。まず商品編集画面で該当バリエーションの有効状態とカタログ表示の設定を確認し、再保存してインデックスを更新する。

なぜ特定のバリエーションだけ検索にヒットしないのか

なぜ特定のバリエーションだけ検索にヒットしないのか

WooCommerceはバリエーションを親商品とは別の商品データとして管理する。検索用のインデックスを作る仕組みでは、親商品に加えて各バリエーションが別レコードとして登録されることが基本になる。その際、各バリエーションの公開条件や商品データに不備があると、そのバリエーションだけインデックスから除外される。

たとえば一部のバリエーションは検索に出るのに特定の型番だけ出ないという症状は、インデックス全体の問題ではなく、該当バリエーションの扱いに原因が集中している場合が多い。親商品の更新では直らず、バリエーション単位の設定を見直す必要がある。

WooCommerceでバリエーションの公開設定を確認する手順

WooCommerceでバリエーションの公開設定を確認する手順

バリエーションが検索に引っかからない場合、まず商品編集画面から該当バリエーションを開き、公開状態とデータの入力を確認する。単純商品であれば「更新」ボタンを押すだけで直る症状でも、バリエーション商品は個別の設定がそのまま残ることがある。

STEP 1 商品編集画面で「バリエーション」タブを開く
↓
STEP 2 該当バリエーションを開き「有効」を確認する
↓
STEP 3 価格、在庫、SKUの入力を確認する
↓
STEP 4 商品を更新して検索インデックスを再構築する
■ 確認ステップ ■ 設定とデータの修正

このデモでは、検索に出ないバリエーションを確認する流れを示している。ここからは各ステップの詳細を見ていく。

「有効」チェックボックスがオフになっていないか

バリエーション編集画面の上部には「有効」のチェックボックスがある。ここがオフになっていると、そのバリエーションはカタログや検索から除外される。特定のバリエーションだけ検索に出ない場合、最初に確認したい項目だ。

チェックが外れている場合はチェックを入れて保存する。複数のバリエーションで同じ問題が起きているなら、一覧画面の絞り込み表示を活用し、無効化されたバリエーションだけを確認するのが早い。

価格と在庫が正しく入力されているか

バリエーションに価格が入力されていない場合、WooCommerceはそのバリエーションを非表示にする。また在庫切れでかつ「在庫切れ商品をカタログから隠す」設定が有効だと、検索インデックスからも外れる。価格と在庫はバリエーションごとに独立して管理されるため、親商品が正常でも特定のバリエーションだけ欠けていることがある。

親商品の「カタログ表示」設定が検索対象になっているか

親商品の編集画面には「カタログ表示」の設定がある。ここが「ショップと検索結果」または「検索結果のみ」になっていないと、その商品のバリエーション全体が検索に出なくなる。ただし一部のバリエーションはヒットするというケースでは、親商品の設定は原因になりにくい。それでも親商品が「非表示」になっていないか併せて確認しておく。

Algoliaにバリエーションが同期されない場合の対処

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の不整合を調べる
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Gmailが政治メールに専用レーンを新設。EC事業者が学ぶべき送信者検証と苦情率0.3%の意味
2026年8月20日 0

Gmailが政治メールに専用レーンを新設。EC事業者が学ぶべき送信者検証と苦情率0.3%の意味

Gmailが政治メール向けにスパムフィルタを迂回できる新プログラムを発表した。2026年9月8日から、資格を満たす政治団体はGmailのVerified Sender Programに参加できる。この動きは政治メールだけでなく、EC事業者のメールマーケティングにも重要な示唆を与える。

プログラムの核心は、送信者検証と苦情率0.3%という2つの条件だ。検証済みの送信者は標準のスパムフィルタを回避できる一方、受信者からのスパム報告が一定を超えると資格を失う。本記事ではこの仕組みをECメール運用にどう活かすかを解説する。

Gmailが政治メールに専用レーンを新設

Gmailが政治メールに専用レーンを新設

Gmailは2026年9月8日から、政治団体向けの新制度「Verified Sender Program」を開始する。この制度に参加した政治団体は、ポリシーに準拠したメールを個人のGmailアカウントに送る際、通常のスパムフィルタを経由せずに受信トレイへ届けられる。

対象となるのは、連邦選挙委員会や州・地方の選挙管理当局に登録された候補者、政党、政治活動委員会などだ。参加にはCampaign Verifyを通じた本人確認と経歴チェックが必要になる。キャンペーンドメインごとに検証できるメールアドレスは1つだけに限られる。

この制度は、Gmailが政治メールの扱いをめぐって長年続いてきた論争への回答でもある。2022年には共和党全国委員会がGoogleを提訴した。Googleは以前にも政治メールを一部のスパムフィルタから除外する試験運用を行っていたが、2023年初めに終了している。

送信者検証と苦情率0.3%の仕組み

送信者検証と苦情率0.3%の仕組み

新プログラムの参加条件は、送信者検証と苦情率の2つに集約される。送信者検証とは、メールの送信元が本人であることを技術的・制度的に確認する仕組みだ。政治団体はCampaign Verifyによる本人確認と経歴チェックを受け、セキュリティ要件とコンプライアンス要件も満たす必要がある。

もう1つの条件が苦情率0.3%未満だ。これは受信者が「スパム」と報告した割合を指す。14日間の平均が0.3%を超えると、プログラムのポリシー違反となる。つまり、検証済みの送信者であっても、受信者からのネガティブな反応が続けば優先レーンを失う。

検証なしの送信者（Before）
未検証ドメイン メール送信 → Gmailスパムフィルタ → スパム行き
※スパムフィルタが通常どおり適用されるため、到達率が下がる可能性がある
↓
検証済みの送信者（After）
検証済みドメイン メール送信 → 優先レーン → 受信トレイへ
※標準のスパムフィルタを迂回するが、受信者がスパム報告すれば通常のフィルタに戻る

この図は、送信者検証がメールの初期処理を変える一方で、受信者のフィードバックが依然として重要な役割を果たすことを示している。

EC事業者が学ぶべき3つのポイント

EC事業者が学ぶべき3つのポイント

政治メール向けの制度だが、EC事業者にとっても学びは大きい。特にWooCommerceで注文確認メールやプロモーションメールを送る事業者は、この仕組みを自社の運用に置き換えて考えたい。

1つ目は送信者検証の重要性だ。Gmailが優先レーンの条件に検証を求めたのは、なりすましやフィッシングを防ぐためだ。EC事業者もSPF、DKIM、DMARCといった送信ドメイン認証を設定し、メールの正当性を示す必要がある。これらはメールの「身分証明書」のようなもので、設定していないと正規のメールでもスパム扱いされやすくなる。

2つ目は苦情率の監視だ。0.3%という閾値は政治メール向けだが、ECメールでも苦情率が高いと到達率が下がる。目安として0.3%は非常に厳しい数字だが、日々のモニタリングとリスト管理が欠かせない。購読解除の導線を明確にし、関与の低い宛先への配信を控えるだけでも改善できる。

3つ目は受信者フィードバックを運用に活かすことだ。Gmailのプログラムでは、検証済みでも受信者がスパム報告すれば通常のフィルタに戻る。EC事業者も同じで、開封率やクリック率だけでなく、スパム報告率や購読解除率を追う必要がある。

STEP 1 送信ドメインを検証する（SPF・DKIM・DMARC）
↓
STEP 2 苦情率を0.3%未満に保つ（14日間の平均）
↓
STEP 3 受信者のフィードバックを監視して改善する

この3ステップを回すことで、Gmailのようなプラットフォームの変更にも強いメール基盤を作れる。

この記事のポイント

  • Gmailは9月8日から政治メール向けにスパムフィルタ迂回の新制度を開始する
  • 参加条件は送信者検証と苦情率0.3%未満の2つ
  • 検証済みでも受信者のスパム報告が続けば優先レーンを失う
  • EC事業者はSPF、DKIM、DMARCと苦情率監視をセットで運用したい
  • WooCommerceのメールも送信者検証とフィードバック管理が到達率を左右する
海田 洋祐
, , , , ,
EC制作
WooCommerceのStripe SEPA決済が後日失敗する時の注文ステータス更新対処
2026年8月19日 0

WooCommerceのStripe SEPA決済が後日失敗する時の注文ステータス更新対処

WooCommerceのStripe決済でSEPAダイレクトデビットを利用する場合、完了ステータスのままだと後日の支払い不成立を注文に反映できない。SEPAは数日後に引き落としが確定する支払い方式なので、注文は保留中で開始し、StripeのWebhook通知でステータスを同期するのが基本だ。

SEPAダイレクトデビットはなぜ後日失敗するのか

SEPAダイレクトデビットはなぜ後日失敗するのか

SEPA（Single Euro Payments Area）のダイレクトデビットは、欧州の銀行口座から代金を引き落とす後日確定型の支払いだ。日本の口座振替に近く、注文時点では「引き落としの依頼」が受理されただけであり、銀行口座から実際に資金が移動したわけではない。

このため注文確定直後はStripeの決済ステータスが「処理中」や「成功」と表示されることがあっても、数日から数週間後に銀行が引き落としを実行した段階で残高不足や口座相違、口座閉鎖、顧客の同意撤回などが判明し、その時点で初めて支払い失敗が確定する。

つまりSEPAでは「注文時に成功していたように見える」状態と「実際の入金が完了した」状態が時間差で分かれる。この時間差が、後から失敗した注文を見つけにくくする根本的な要因だ。

STEP 1 顧客がSEPAダイレクトデビットで注文を確定する
↓
STEP 2 Stripeが決済処理中と表示し、WooCommerceは注文を完了にする
↓
STEP 3 数日から数週間後、銀行の引き落としが実行される
↓
結果 残高不足や口座相違で銀行が拒否し、Stripe上は失敗になる
■ 支払い失敗に切り替わる　 WooCommerce側は完了のまま残ってしまう

この流れで後日失敗が起きても、WooCommerceの注文は完了のまま残るため、店舗側からは売上確定後に消える注文のように見える。

WooCommerceの注文ステータスはなぜ変わらないのか

WooCommerceの注文ステータスはなぜ変わらないのか

一番の原因は、WooCommerceの注文ステータス「完了」が終端状態である点だ。完了になった注文は、標準の状態遷移では処理中や保留中へ戻せない。後からStripeが支払い失敗を通知しても、すでに完了になっている注文を自動で失敗に切り替える動作は発生しない。

StripeプラグインはWebhookイベントを受け取って注文ステータスを更新する。しかしWebhookで支払い失敗を受け取っても、対象の注文が完了の場合、状態遷移がブロックされる。逆に注文が保留中や処理中のままなら、失敗ステータスへ更新できる余地がある。

加えて、Webhookエンドポイントの設定漏れやシークレットキーの不一致があると、Stripeからの通知そのものがWooCommerceに届かない。この状態では支払い失敗だけでなく、成功通知も正しく反映されなくなる。

Before（完了のまま運用）
注文を完了にして発送まで進める
↓
数日後にStripeが支払い失敗を通知する
↓
完了は終端状態のため注文ステータスが変わらない
↓
After（保留中から開始する運用）
注文を保留中にする
↓
Stripeが支払い失敗を通知する
↓
保留中なら注文を失敗ステータスに変更できる
■ 完了のままでは通知を受けても動かない　 ■ 保留中なら後日の失敗を反映しやすい

このように、WooCommerceの注文ステータスは「完了」を途中で覆す前提で設計されていない。SEPAのような後日確定の支払いでは、注文ステータスを保留中に保つのが安全だ。

後日失敗を検知するにはどう設定すればよいか

後日失敗を検知するにはどう設定すればよいか

対策は大きく2つある。1つはStripeとWooCommerceの間でWebhook通知を正しく受け取れる状態にすること、もう1つはSEPA注文の初期ステータスを保留中にして後から失敗に変更できる余地を残すことだ。

STEP 1 StripeダッシュボードでWebhookエンドポイントを追加する
↓
STEP 2 WooCommerceのStripe設定にWebhookシークレットを登録する
↓
STEP 3 SEPA注文の初期ステータスを保留中に変更する
↓
STEP 4 入金確定後にだけ手動で完了へ進める運用にする
■ Stripe側の通知設定　 ■ WooCommerce側の受け取り設定　 ■ 注文の初期ステータス変更

上記の流れを1つずつ設定していけば、後日失敗した注文をWooCommerce側で検知しやすくなる。

Stripe側でWebhookエンドポイントを新規作成する

Stripeのダッシュボードで「開発者」→「Webhooks」を開き、エンドポイントを追加する。エンドポイントURLにはWooCommerceが用意する受信先（通常は example.com/?wc-api=wc_gateway_stripe に相当する自サイトのアドレス）を指定する。イベントには payment_intent.processing、payment_intent.payment_failed、charge.failed を最低限有効にする。

WooCommerce側にWebhookシークレットを登録する

WooCommerceの管理画面で「WooCommerce」→「設定」→「決済」→「Stripe」を開き、詳細設定にあるWebhook Secret欄にStripeから発行された署名シークレットを貼り付ける。これはStripeからの通知が本物であることを検証する鍵で、一致しない場合はイベントが受け付けられない。

SEPA注文の初期ステータスを保留中にする

WooCommerceのStripe決済設定には、支払い方法ごとに注文ステータスを割り当てる項目がある。SEPAダイレクトデビットを「処理中」または「保留中」にしておくと、支払い失敗時の自動更新が効きやすい。完了への変更は入金確定後に行う。

自動で完了にする運用をやめる

注文を一括で完了に変更する自動化プラグインやカスタムコードを使っている場合、SEPA注文には適用しないよう除外する。対象を前払いのカード決済や銀行振込に限定し、後日確定の支払い方法は人による確認を挟む。

再発を防ぐには何を監視すべきか

再発を防ぐには何を監視すべきか

Webhookとステータス設定を整えても、銀行側の事情で通知が遅れたり不達になるケースは残る。店舗側ではStripeダッシュボードの支払い失敗一覧とWooCommerceの注文リストを週次で突き合わせる運用が現実的だ。

  • Stripeダッシュボードの支払い失敗イベントを定期確認する
  • WooCommerceのWebhookログにエラーが出ていないか確認する
  • 保留中のまま長期滞留している注文を抽出する
  • 完了済み注文の中から支払い失敗に切り替わったものを洗い出す

WooCommerceは「WooCommerce」→「システムステータス」→「ログ」にStripeのWebhook受信ログを残す。日付が新しいログに対象注文が見つからないなどのエラーが記録されている場合は、該当する注文の状態を手動で修正する。自動化に頼りきらず、最終確認として人の目を挟むのが安全だ。

よくある質問

SEPAの支払いが失敗した場合、顧客には自動で通知される？

Stripeからは顧客へメール通知が送られるが、WooCommerce側の注文メールはステータス変更を基に動作する。失敗を検知したら店舗側から個別に連絡する運用にしておくと、顧客対応が安定する。

StripeのWebhookが受信されているか確認するには？

WooCommerceのシステムステータスにあるログ一覧でStripe Gatewayのログを開く。日付が新しいログにエラーがなければ受信できている。不安な場合はStripeダッシュボードでテストイベントを送信して確認する。

既に完了にしている注文を後から失敗に変更できるか？

WooCommerceの標準画面では、完了から失敗への直接変更はできない。手動で注文ステータスドロップダウンから変更を試みても反映されないことが多い。必要な場合は対象注文を返金処理するか、カスタムコードでステータスを書き換えることになる。

SEPA以外の後払い決済でも同じ問題は起きる？

後日確定型の支払い方法であれば同様の問題が起きる。具体的には銀行振込や口座振替、一部の後払いサービスなどが該当する。支払い方法ごとに注文ステータスの初期値を確認しておくとよい。

Stripeの公式プラグイン以外でもWebhook設定は必要？

他のStripe連携プラグインでも、Stripeのイベントを受け取る仕組みが備わっている。プラグインの設定画面にWebhook URLやシークレットキーの項目があるかを確認し、なければ手動でエンドポイントを追加する。

この記事のポイント

  • SEPAダイレクトデビットは後日確定するため注文時の成功は最終結果ではない
  • WooCommerceの完了ステータスは終端状態で失敗へ自動変更できない
  • 注文は保留中で開始し入金確定後にのみ完了へ移す
  • StripeのWebhookとWooCommerceのシークレット設定を同期させる
  • StripeダッシュボードとWooCommerceのログを定期的に突き合わせる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法
2026年8月16日 0

WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法

WooCommerceのStripe決済プラグインを自動更新した直後に、設定画面の「決済」タブからStripeが丸ごと消えた場合は、更新時に発生した致命的エラーか、他の決済プラグインとの競合が主な原因だ。まず「ステータス」→「ログ」で fatal-errors の有無を確認し、競合を切り分けた後、キャッシュ削除と設定の再保存で復旧できる。セキュリティパッチ自体がStripe決済を意図的に隠すことはない。

Stripe決済が消える原因は何か

Stripe決済が消える原因は何か

Stripe決済プラグインのアップデート後に、WooCommerceの「設定」→「決済」画面からStripeの項目が消える現象には、いくつかの典型的な原因がある。セキュリティパッチの更新処理そのものがStripeを除外する仕様は存在しないため、まず「更新に伴って別の何かが壊れた」と考えるのが正しい。

最も多いのは、アップデート処理中に発生した致命的エラーだ。プラグイン更新時にPHPのメモリ不足やファイルの不整合が起きると、WooCommerceがプラグインを正常に読み込めなくなり、決済方法の一覧からStripeが消える。管理画面には「このサイトで重大なエラーが発生しました」と表示される場合もあれば、画面に何も表示されず設定一覧だけが欠けるケースもある。

次に多いのがプラグイン競合だ。複数の決済ゲートウェイ系プラグインを導入していると、アップデート後に読み込み順序が変わって競合し、Stripeが一覧から漏れることがある。WooCommerceの決済方法はフィルターを通して一覧に追加されるため、競合相手のプラグインがエラーを出すと後続の読み込みが止まり、Stripeが表示されない。

キャッシュが原因になるケースも見逃せない。アップデート直後にサーバーキャッシュやオブジェクトキャッシュへ古い状態が残っていると、管理画面の一覧にだけ反映されずStripeが消えて見える。ブラウザキャッシュでも同様の現象が起こる。

Before「Stripeが見つからない状態」
WooCommerceの「設定」→「決済」画面を開くと、有効な支払い方法の一覧にStripeが表示されない
↓
After「Stripeが復活した状態」
Stripeが一覧に再び表示され、チェックアウトでクレジットカード決済が利用できる
■ Stripeが消えた状態　■ 復旧後

このデモは、決済タブでStripeが消えた状態から復旧した状態への変化を示している。ここから先の手順を順に実行すれば、原因の特定と復旧まで進められる。

致命エラーログで原因を特定する手順

致命エラーログで原因を特定する手順

最初に確認すべきは、WooCommerceが記録している致命的エラーのログだ。管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開くと、保存されているログの一覧が表示される。この中に fatal-errors で始まる名前のログがあれば、アップデート時になんらかの致命的エラーが発生している。

fatal-errors ログを開くと、エラーが発生した日時、原因となったプラグインやテーマ名、エラーが起きたファイルのパスが確認できる。Stripeプラグインのファイルパスが記録されていれば、そのエラーが原因で一覧から消えた可能性が高い。ログの内容は専門的なPHPの記述が多いが、どのプラグインでエラーが出たかを特定できれば十分だ。

ログに何も出ていない場合は、WP_DEBUG（デバッグモード）を有効にして再現させる方法もある。wp-config.php にデバッグ定数を追記してから決済設定画面をリロードすると、画面にエラー文言が直接表示される。ただし共用サーバーでは本番サイトでデバッグをオンにするとセキュリティ上望ましくないため、確認後は必ず元に戻す。

プラグインの競合を切り分ける

プラグインの競合を切り分ける

致命エラーログが出ていない、または出ていても原因が特定できない場合は、プラグイン競合の切り分けに進む。決済系プラグインを複数導入している環境では、どれか1つがStripeの読み込みを妨げている可能性がある。

切り分けの基本は「一度に全部を無効化しない」ことだ。Stripeを除く他の決済プラグインを1つずつ無効化し、そのつど「設定」→「決済」画面をリロードしてStripeが表示されるか確認する。たとえば「WooCommerce PayPal Payments」や「Amazon Pay」などを無効化するたびに確認を繰り返すと、競合相手を特定できる。

決済プラグインだけでなく、最近更新したプラグインやテーマも疑う。プラグインを全無効化してもStripeが表示されない場合は、テーマを標準テーマの「Twenty Twenty-Four」などに切り替えて同じ画面を確認する。テーマ側のフックが決済一覧を書き換えている例も過去にある。

STEP 1 致命エラーログを確認する
WooCommerceの「ステータス」→「ログ」で fatal-errors の有無を調べる
↓
STEP 2 プラグイン競合を切り分ける
他の決済プラグインを順に無効化して症状が直るか確認する
↓
STEP 3 サイトキャッシュを削除する
サーバーキャッシュとブラウザキャッシュを消して再読み込みする
↓
STEP 4 Stripe設定を再保存する
Stripe設定を開いて保存し直し、API接続が有効か確認する

このデモは、Stripe決済が消えたときに進めるトラブルシューティングの流れを示している。各ステップの詳細は本文の対応する見出しで確認できる。

キャッシュ削除と設定の再保存で復旧させる

キャッシュ削除と設定の再保存で復旧させる

競合の切り分けで原因が特定できた場合も、原因がまだ判明しない場合も、次に試すのはキャッシュの削除とStripe設定の再保存だ。この2つを実行するだけで、実害のない一時的な不整合が解消されてStripeが一覧に復活することが多い。

キャッシュ削除は、レンタルサーバーの管理画面で提供されているサーバーキャッシュ、WooCommerceのシステムが内部で使うオブジェクトキャッシュ、そして自分が閲覧しているブラウザのキャッシュの3つを対象にする。キャッシュ系プラグインを導入している場合は、そのプラグインの管理画面から全キャッシュを削除してから、決済設定画面をリロードする。

Stripe設定の再保存は、WooCommerceの「設定」→「決済」でStripeの項目が表示されていなくても実行できる場合がある。「決済」タブの一覧にStripeが出ていなくても、左メニューに「Stripe」の設定ページが残っていれば、そこを開いて「変更を保存」を押す。これにより設定値が再評価され、一覧に反映される。

設定を保存し直すと、StripeのAPI接続状態も再チェックされる。接続が切れていた場合は「接続」ボタンが表示されるため、そこからStripeアカウントに再接続できる。APIキーが無効になっている、あるいはテストモードと本番モードの切り替えが正しくない場合も、再接続で直るケースがある。

それでも直らない場合の追加チェック

ここまでの手順を実行してもStripeが一覧に表示されない場合は、環境そのものに問題がある可能性が高い。「WooCommerce」→「ステータス」→「システムステータス」を開き、WordPress本体、WooCommerce本体、PHPの各バージョンがStripeプラグインの推奨要件を満たしているか確認する。プラグイン更新後にPHPのバージョン要件が引き上げられ、サーバーのPHPが古いままだと読み込みに失敗することがある。

システムステータスレポートには、有効化している全プラグインの一覧と、WooCommerceが認識している各設定値がまとまっている。この中でStripeプラグインが「有効」になっているか、「非アクティブ」や「エラー」になっていないかを確認する。プラグイン一覧のページでStripeが有効化されていても、WooCommerce側で読み込めていない状態が可視化されることがある。

最終手段として、以前の安定したバージョンへロールバックする方法もある。プラグインの配布ページから過去バージョンのZIPファイルを取得して手動で上書きするか、「WP Rollback」のようなロールバック用プラグインを使って1つ前のバージョンへ戻す。ただしロールバックはセキュリティパッチを巻き戻すことになるため、あくまで復旧のための一時的な手段として扱い、原因を特定した上で最新版へ戻す計画を立てる。

よくある質問

Stripe決済が消えたのは自動更新の不具合か

自動更新自体がStripeを意図的に外すことはない。更新処理の中で発生した致命的エラーや、更新後に顕在化したプラグイン競合が原因であるケースがほとんどだ。ログを確認して切り分けることで特定できる。

セキュリティパッチによってStripeが意図的に隠されることはあるか

通常のセキュリティパッチがStripe決済を隠す仕様は存在しない。もしセキュリティ上の理由で決済方法が制限されるなら、公式リリースノートに明記される。リリースノートに記載がないのに消えた場合は、パッチの直接の影響ではなく別の要因を疑う。

Stripe Linkだけが表示されない場合は何を確認するか

Stripeゲートウェイ自体は表示されているが、Stripe Linkという特定の支払い方法だけが表示されない場合は、Stripe設定ページ内の「支払い方法」セクションでLinkが有効化されているか確認する。また、Stripeのアカウント側でLinkが利用可能な地域・通貨であるかも確認が必要だ。

システムステータスレポートのどこを見れば原因が分かるか

まず「環境」セクションでPHPとWooCommerceのバージョンが要件を満たしているか、次に「有効なプラグイン」でStripeが正常に読み込まれているか、そして「ログ」セクションでエラーが記録されていないかを順に確認する。レポートはサポートに共有する際にもそのまま使える。

プラグインを以前のバージョンに戻してもよいか

復旧を優先するなら一時的なロールバックは有効な手段だ。ただしセキュリティパッチを含む更新を巻き戻すため、原因を特定して修正した後は最新版へ戻すことが前提になる。ロールバック前に必ずサイト全体のバックアップを取る。

この記事のポイント

  • Stripeが決済一覧から消えた主因はupdate時の致命的エラーとプラグイン競合
  • セキュリティパッチ自体がStripeを隠すことはない
  • 最初にWooCommerceの「ステータス」→「ログ」で fatal-errors を確認する
  • 競合切り分け後はキャッシュ削除とStripe設定の再保存で復旧を試す
  • 復旧しない場合はシステムステータスでPHP・WooCommerceの要件を確認する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.