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 Taxが配送先住所を無視する原因と修正手順
WooCommerceの自動税計算（WooCommerce Tax）が配送先住所を無視して店舗住所の税率を適用し続ける場合、設定のキャッシュか配送先住所の認識不良が原因だ。税計算の基準を再確認し、プラグインのトランジェントデータを手動で削除すれば、多くのケースで正しい税率に戻る。
配送先住所ではなく店舗住所の税率が使われる原因
WooCommerce Tax（旧称 WooCommerce Shipping & Tax）は、有効化すると TaxJar の自動税率データベースを参照して税額を算出する。管理画面の「WooCommerce > 設定 > 税」で「顧客の配送先住所に基づいて計算する」を選択しているにもかかわらず店舗住所の税率が使われるのは、次のいずれかが起きていると考えられる。
- 税計算の基準設定が実際には店舗住所のまま保存されていない、または別のフィルターで上書きされている
- プラグインが内部に保持するトランジェントキャッシュが古い設定を返し、配送先住所を無視している
- チェックアウト時に配送先住所が正しくシステムに渡っていない（テーマや他のプラグインによる競合）
- WooCommerce Tax が店舗の税ネクサス（課税拠点）を元にした「オリジンベース課税」のルールを配送先住所より優先してしまっている
特に最後の点は、米国のように州ごとにオリジンベース／デスティネーションベースの課税方式が異なる地域で混乱しやすい。日本国内のオンラインショップでは基本的に配送先住所の税率（消費税10％または軽減税率8％）が使われるべきだが、WooCommerce Tax が海外の課税ロジックを引きずっている場合もあり、実際に「店舗住所を変えると税率が変わってしまう」といった現象が報告されている。
配送先住所「大阪市 530-0001」（税率8.25%のはず）
↓
適用される税率 → 店舗住所「東京都 100-0001」の税率10%
配送先住所「大阪市 530-0001」
↓
適用される税率 → 配送先住所の8.25%
このデモのように、配送先住所を正しく入力していても、店舗住所の税率だけが繰り返し使われるのが典型的な症状だ。
税計算の基準が本当に配送先住所になっているか再確認する
まず根本的な設定ミスがないか、管理画面をチェックする。
設定画面上は正しく見えていても、内部的に値がロックされている場合がある。STEP 3 のように一度無効化して再保存することで、WooCommerce Tax の内部キャッシュをリセットできる。
トランジェントキャッシュを手動で削除する
WooCommerce Tax は API から取得した税率データを WordPress のトランジェント（一時キャッシュ）に保存している。このキャッシュが古いままだと、配送先住所が変わっても最初に引いた店舗住所のレートを返し続けることがある。
データベースを直接操作せずにキャッシュをクリアする方法
- WooCommerce > ステータス > ツール に移動する
- 「WooCommerce トランジェントをクリア」を実行する
- さらに「顧客セッションをクリア」も実施する
- 必要に応じて、WooCommerce Tax プラグインを無効化してから削除し、再度インストールして有効化する
再インストール時には、プラグインが新しい API キーを取得し、税設定が初期化される。その後、必ず「WooCommerce > 設定 > 税」で「配送先住所に基づいて計算する」を再設定する。
配送先住所の受け渡しをデバッグモードで検証する
テーマや他のプラグインの影響で、チェックアウト画面から正しい配送先住所が WooCommerce Tax に渡っていない可能性もある。WooCommerce のデバッグモードを有効にして、税計算の内部ログを確認する。
define('WP_DEBUG', true); を追加WooCommerce > ステータス > ログ に、woocommerce-tax や taxjar のログファイルが生成される。配送先住所ではなく店舗住所が送信されているようであれば、テーマの functions.php やカスタムコードが住所情報を改変していないか精査する。
応急的に店舗住所を「配送先住所」と同じ扱いにするフィルター
どうしても自動税計算が配送先住所を認識せず、緊急で正しい税率を適用しなければならない場合、WordPress のフィルターフックを使って一時的に配送先住所を強制的に税計算に使わせることもできる。
add_filter( 'woocommerce_tax_based_on', function( $base ) {
if ( is_checkout() || is_cart() ) {
return 'shipping';
}
return $base;
});このコードを子テーマの functions.php に追加すれば、カート・チェックアウト画面では常に配送先住所ベースの計算が強制される。ただし、根本原因の解決にはならないため、あくまで応急策として利用する。
よくある質問
WooCommerce Tax を再インストールしても直らないのはなぜか
再インストールだけでは、データベースに残ったトランジェントや設定値が削除されないことがある。プラグインを削除した後に「WooCommerce > ステータス > ツール」からトランジェントを完全クリアし、その上で再インストールする必要がある。
配送先住所が正しく入力されているのに税率が変わらないのはどうしてか
WooCommerce Tax は TaxJar API に配送先の ZIP コードと国・州の情報を送り、税率を取得する。このとき、ZIP コードが実在しないか API が認識できない場合、フォールバックとして店舗住所の税率を返す仕様がある。テストする住所が実在するか、郵便番号のフォーマットが正しいかを再確認する。
WooCommerce Tax を使わずに日本国内の税率を正確に計算するにはどうすればよいか
日本国内のオンラインショップで消費税のみを扱うなら、自動税率プラグインを無効化し、WooCommerce 標準の税率設定で「標準税率（10％）」と「軽減税率（8％）」を手動で登録する方が安定する。配送先住所の県や市町村による税率差分が不要なケースが大半のため、あえて自動計算を導入する必要はない。
テスト注文を何度も行っても税額が変わらない場合の最終確認事項は
テスト注文時には、必ずブラウザのシークレットウィンドウを使い、サイトのキャッシュやセッションの影響を排除する。また、カートの計算がセッション情報に依存するため、住所を変えるたびにカートを空にしてから再度商品を追加する。
特定の州や地域でオリジンベース課税のせいで税率が店舗住所になることはあるのか
米国の一部の州では、店舗所在地と配送先の両方が同じ州内にある場合、店舗所在地の税率を適用するオリジンベース課税が採用されている。しかし、WooCommerce Tax は州ごとの課税方式を自動で判別するわけではなく、設定上のトラブルでこの現象が起こることがある。日本のショップでは関係ないが、海外向けに販売する場合は注意が必要だ。
この記事のポイント
- 自動税計算が配送先住所を無視するのは、設定キャッシュか住所の受け渡し不良が主な原因
- 「WooCommerce > 設定 > 税」の計算基準を再確認し、無効化→再有効化で内部リセットを試す
- トランジェントキャッシュを手動クリアし、必要ならプラグインの再インストールを行う
- デバッグログで TaxJar API へのリクエスト内容を検証する
- 日本国内のみのショップなら自動税率をやめ、標準税率を手動設定する方が安定する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Stripe for WooCommerce決済不備を修正、影響バージョンと更新手順
WooCommerce公式開発ブログが7月14日、決済プラグイン「Stripe for WooCommerce」の重要な修正パッチをリリースした。一部の環境でAdaptive Pricing（適応型価格設定）が有効になっている場合、決済処理中にカートの合計金額と実際の請求額が一致しない可能性があるという決済検証の不具合が確認されたためだ。
影響を受けるのはバージョン10.6.0から10.8.3。修正バージョンは10.6.2、10.7.1、10.8.4の三系統で提供されている。自動更新が可能なサイトではすでに適用が進んでいるが、手動更新が必要なケースも残っており、運営者はすぐにバージョン確認を進める必要がある。
なぜ今すぐ更新が必要なのか
今回の不具合は、ストアの売上管理や顧客との信頼に直結する重大な問題だ。Adaptive PricingはStripeが提供する機能で、海外顧客向けに現地通貨での価格表示や決済をサポートする。しかし特定条件下で、WooCommerce側で計算された注文金額と、Stripe側で実際に処理される決済金額に差が生じることが判明した。
Adaptive Pricingの簡易的な役割
Adaptive Pricingとは、簡単に言えば「海外ユーザーが自分の通貨で価格を見て、そのまま支払える仕組み」だ。例えば米ドル建ての商品を、日本の顧客が日本円換算でチェックアウトできる。通貨換算レートの自動反映や、支払い手段の最適化も行われるため、越境ECでは非常に便利な機能である。しかしこの換算処理が絡む分、プラグイン内部の金額バリデーションが正しく行われないと、過少請求や過大請求が起こり得る。
具体的に何が問題だったのか
WooCommerce開発ブログのアドバイザリーによると、バリデーションロジックの一部がAdaptive Pricingの有効時に期待どおり動作しないケースが確認された。詳細な技術情報は修正が行き渡るまでは公開されないが、「WooCommerceの注文合計とStripeの処理金額が一致しない」という症状が報告されている。Adaptive Pricingが有効なストアでは、特に10.8.x系で広範に影響が出る可能性があるため、注意が必要だ。
上図は問題の概念を示したイメージである。注文合計と実際の請求額がずれてしまうと、ストア側は過不足金の調整や顧客への説明に追われ、信頼を損ねるリスクがある。このため公式からも即時更新が強く推奨されている。
影響を受ける条件を3点でチェック
すべてのストアが影響を受けるわけではない。以下の3つの条件がすべて重なった場合にのみ、今回の不具合が発生し得る。
バージョン系統ごとの影響度の違い
10.8.x系では、Adaptive Pricingが接続先アカウントに対して幅広く有効化されていたため、最も広範囲に影響が出る。10.7.x系では新規マーチャント向けにAdaptive Pricingが有効にされており、比較的新しく設定したストアがリスクにさらされる。10.6.x系は手動でAdaptive Pricingを有効にした場合に限られる。いずれにせよ、該当するならば速やかな対応が必要だ。
修正バージョンへのアップデート手順
修正パッチは10.6.2、10.7.1、10.8.4として提供されている。以下の対応表に沿って、自分のストアのバージョンを確認し、該当する修正バージョンへ更新しよう。
管理画面からの手動更新方法
自動更新が走っていない、あるいは手動で確認したい場合は、以下の手順でアップデートを実施できる。
- WordPress管理画面の「ダッシュボード」→「更新」へ移動する
- 「Stripe for WooCommerce」または「WooCommerce Stripe Payment Gateway」の更新が表示されたら選択する
- 「今すぐ更新」ボタンをクリックし、完了を待つ
- プラグイン一覧でバージョンが10.6.2、10.7.1、10.8.4のいずれかであることを確認する
すぐに更新できない事情がある場合は、応急処置としてAdaptive Pricingを一時的に無効化することで、不具合の発生を回避できる。ただしこれはあくまで短期的な緩和策であり、根本対応は修正バージョンへのアップデートとなる。無効化後もできるだけ早く更新を済ませることが望ましい。
開発者・代理店・ホスティング事業者が取るべき対応
クライアントのWooCommerceサイトを管理・保守している開発者や代理店、あるいはWooCommerce向けホスティングを提供している事業者は、以下の確認を即座に実施することが推奨される。
- 管理下にある全サイトでStripe for WooCommerceのバージョンを直接確認する
- 特にAdaptive Pricingが有効なサイトを優先して修正バージョンへの更新を完了させる
- クライアントへこのアドバイザリーの内容を共有し、状況を説明する
- 更新がすぐに行えない場合は、Adaptive Pricingを一時無効化し、後日必ず更新するスケジュールを組む
- 影響を受けたストアでは、更新後に過去の注文で金額不一致がないか確認する
WooCommerce公式ブログのアドバイザリーでも強調されているが、「マーチャント向けの通知が届くのを待たずに、直接バージョンを確認する」ことが最も安全な対応だ。影響サイトの放置は、金銭的なトラブルだけでなく、顧客からのクレームや返金処理の増加につながる。特に繁忙期や越境ECを積極的に行っているストアでは、早期対応が欠かせない。
発見の経緯と今後の教訓
この問題は、HackerOneを通じてセキュリティ研究者のe0x1337氏から責任ある報告が行われたことで発覚した。WooCommerceチームは直ちに修正パッチを準備し、WordPress.orgプラグインチームと連携して自動更新の展開も進めている。
ストア運営者が学ぶべきこと
今回の事例は、決済プラグインの更新管理の重要性を改めて示している。Adaptive Pricingのような高度な機能はビジネス拡大に貢献する一方で、内部ロジックが複雑化する分、不具合が紛れ込む余地も生まれる。以下のポイントを日常的に意識することで、類似リスクを減らせる。
- WooCommerceおよび関連プラグインの自動更新を可能な限り有効にしておく
- 週次など定期的に管理画面の「更新」セクションをチェックする習慣をつける
- 決済系プラグインの変更履歴（Changelog）やセキュリティアドバイザリーをウォッチする
- テスト環境（ステージング）で決済フローを定期的に動作確認する
- 不審な金額の注文や顧客からの問い合わせがあった場合、プラグインのバージョンと設定を真っ先に疑う
WooCommerceコミュニティの迅速な対応により、今回の不具合は大事に至る前に修正パッチが提供された。しかし、プラグインを更新しなければリスクは残る。自分のストアが該当するかどうかを今一度確認し、必要なアクションを取ることが、安全なオンラインビジネスの継続につながる。
この記事のポイント
- Stripe for WooCommerce 10.6.0〜10.8.3でAdaptive Pricing有効時に決済金額不一致の不具合
- 修正バージョンは10.6.2、10.7.1、10.8.4。即時更新が強く推奨される
- 自動更新が走っていない場合は管理画面の「更新」から手動でアップデート
- 開発者や代理店はクライアントサイトのバージョン確認と優先更新が必要
- 影響を防ぐ一時策としてAdaptive Pricingの無効化も可能だが、根本解決には更新が不可欠
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceで北アイルランド向けVAT税率だけ20%に設定する方法
{ “title”: “WooCommerceで北アイルランド向けVAT税率だけ20%に設定する方法”, “meta_description”: “WooCommerceで英国は税率0%、北アイルランドだけ税率20%に設定するには、国「UK」と州コード「Northern Ireland」を組み合わせる。設定手順とテスト方法まで解説。”, “tags”: [“WooCommerce”, “税率設定”, “VAT”, “北アイルランド”, “EC運営”, “Brexit”], “slug”: “woocommerce-northern-ireland-tax-rate”, “image_prompt”: “WooCommerceのロゴ（紫の丸みを帯びたマーク）を3Dで目立つように大きく配置する。上部には、ダークなEU地図の上に北アイルランドだけがハイライトされ、20%のプレートが浮かぶリアルな構図。下部には英国本土と北アイルランドが色分けされたVAT設定画面のUIを配置。構図は上下分割スタイルとし、主要な視覚要素を画面の上部と下部に配置して、その間を自然で大気感のあるトランジションでつなぐ。画面を横切る水平の帯やストライプは描かない。画像の右下の領域には文字・ロゴ・重要な被写体を置かず、背景や余白にする。アスペクト比16:9。UI画面・ダッシュボード・コードエディタ・管理画面が写る場合、その中の文字はすべて英語にする。ノートPCやモニターが写る場合は極細ベゼルの現代的なデザインにする。カレンダー・画面・書類・タイムラインに年号の数字を表示しない。”, “featured_text”: “北アイルランドだけ\n税率20%にしたい？” }
WooCommerceで英国本土と北アイルランドに異なるVAT税率を設定するには、税率設定画面で国として「United Kingdom (UK)」を選び、州コードに「Northern Ireland」を指定して、英国全体の税率と北アイルランドのみの税率をそれぞれ登録する。
WooCommerceの税率設定で英国と北アイルランドを区別できない原因
WooCommerceは国単位で税率をマッチさせるが、標準状態では英国全体が「GB」という国コードでまとめられている。そのため、英国本土向けの税率と北アイルランド向けの税率を単一の国設定で区別できないように見える。しかし実際には、州コード（State Code）を使って地域を細分化できる仕組みが備わっている。英国本土と北アイルランドはVAT制度上、EUと英国内で異なる扱いを受けるため、州レベルでの切り分けが不可欠だ。
WooCommerceで英国本土と北アイルランドの税率を別々に設定する手順
WooCommerceの管理画面から、税率の新規追加・編集を行う。まずは英国全体に対する税率0%を設定し、その後に北アイルランドだけを対象とした税率20%を追加する。この順序で設定する必要は必ずしもないが、後のテストが楽になる。
このデモは英国全体（州コードなし）と北アイルランド（州コードあり）の2つの税率エントリを示している。実際の設定画面でも同じ構造で登録する。
英国全体の税率0%を設定する
WooCommerceの管理メニューから「WooCommerce」→「設定」→「税率」タブを開く。「税率を追加」ボタンを押し、以下のように入力する。
- 国コード: ドロップダウンから「United Kingdom (UK)」を選ぶ
- 州コード: 何も入力せず空欄のままにする
- 税率: 0%（英国本土向けVATは0%のため）
- 税率名: 例「UK VAT 0%」など分かりやすい名前
- 税率の優先度: 0（デフォルトで問題ない）
「変更を保存」をクリックする。これで英国本土向けの注文には0%が適用される。
北アイルランド向けの税率20%を設定する
同じ税率一覧画面で再び「税率を追加」を押す。今度は州コードを指定して北アイルランドだけに20%が適用されるエントリを作る。
- 国コード: 「United Kingdom (UK)」を選ぶ
- 州コード: ドロップダウンまたは手入力で「Northern Ireland」を指定する。入力欄に文字を打つと候補が表示される
- 税率: 20%（標準VAT）
- 税率名: 例「Northern Ireland VAT 20%」
- 税率の優先度: 0
「変更を保存」をクリックする。WooCommerceは注文時に配送先住所の国と州を照合し、より具体的な州コード指定のある税率エントリを優先して適用する。これで北アイルランド宛ての注文には20%が、それ以外の英国本土宛てには0%が自動で適用される。
設定後は必ずテスト購入で税率を確認する
本番運用する前に、かならずテストモードまたはステージング環境で実際の購入フローを試してほしい。配送先住所を英国本土（例: London）と北アイルランド（例: Belfast）の2パターンで入力し、カートやチェックアウト画面に表示される税額が想定どおりになっているか確認する。
もし北アイルランド住所でも税率が0%のままだった場合は、税率エントリの州コードが正しく「Northern Ireland」になっているか、また住所欄に入力した州名が税率設定のものと一致しているかをチェックする。WooCommerceは住所の州名と税率テーブルの州コードを厳密に突き合わせるため、スペルミスや表記ゆれがあるとマッチしない。
よくある質問
英国全体の税率エントリと北アイルランドの税率エントリの優先度は同じでよいのか
問題ない。どちらも優先度が同じ場合、WooCommerceはより具体的な条件を持つエントリ（州コード指定あり）を自動的に優先する。本土用（州指定なし）より北アイルランド用（州指定あり）のほうが具体的なため、優先度の値にかかわらず正しく適用される。
州コードに「Northern Ireland」が表示されない場合はどうするか
WooCommerceの州コードリストはデフォルトで主要な州を含んでいるが、何らかの理由で表示されない場合は手入力も可能だ。入力欄に直接「Northern Ireland」とタイプして保存すれば機能する。もしどうしてもリストに出ないなら、WooCommerceの一般設定で販売地域を「すべての国に出荷する」などに一時変更してから再確認する。
欧州連合（EU）のVAT設定と衝突しないか
WooCommerceの税率設定は国単位・州単位で独立しているため、EU加盟国向けの税率エントリとは別に管理できる。英国（GB）向けのエントリは、EUの税率設定テーブルとは独立して動作するので衝突しない。ただしEU全域向けの税率設定をまとめて有効にしている場合は、英国向けエントリが優先されるよう、税率の優先度や対象地域を整理しておくと安心だ。
北アイルランド宛ての配送時にだけ異なる税率を表示したいが可能か
可能だ。本記事で解説した州コード指定の方法を使えば、北アイルランド向けの注文だけ異なる税率（例: 20%）を表示し、英国本土向けには別の税率（例: 0%）を表示できる。条件は住所の州名が税率エントリの州コードと一致することだけだ。
WooCommerce以外のプラグインでもこの方法は使えるか
この解説はWooCommerceの税率設定機能を前提としている。ECプラグインによっては州コードを使った税率の細分化に対応していない場合もあるため、利用しているプラグインのドキュメントを確認する必要がある。WooCommerceを推奨する趣旨ではないが、同様の要件を満たすには国と州を組み合わせた柔軟な税率設定ができるプラグインを選ぶことがポイントになる。
この記事のポイント
- WooCommerceでは国コード「GB」と州コード「Northern Ireland」で税率を分けられる
- 州コード指定のある税率エントリは、指定のないエントリより優先される
- 英国全体に税率0%、北アイルランドに税率20%をそれぞれ追加する
- 設定後はテスト購入で英国本土と北アイルランド両方の税額を確認する
- 州コードは手入力でも有効、表示されない場合は直接タイプする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce 11.0でget_queried_object()がショップページでもWP_Postを返す改善
WooCommerce 11.0より、ショップページで get_queried_object() を呼び出した際の戻り値の型が WP_Post_Type から WP_Post に統一される。これまでショップページだけが例外的に商品の投稿タイプオブジェクトを返していたが、今回の変更でWordPress標準の挙動と一貫性が保たれることになる。
この修正は、WooCommerceが内部的に管理するクエリの取り扱いをWordPressコアに合わせるもので、テーマやプラグインの開発者が「ショップページかどうか」を意識せずに get_queried_object() を扱えるようにする狙いがある。フロントページにショップページを設定している場合も同様の挙動となる。
WooCommerce 11.0のショップページ改善
get_queried_object() は現在のWordPressクエリに対応するオブジェクトを取得する標準関数だ。通常の固定ページや投稿ページでは WP_Post オブジェクトを返すが、これまでのWooCommerceではショップページに限り WP_Post_Type オブジェクト、つまり商品（product）の投稿タイプ情報を返していた。この不一致が開発者にとって混乱の元となっていた。
WooCommerce Developer Blogの説明によれば、ショップページで get_queried_object() を呼び出して「商品アーカイブであること」を判定するコードを書いていた場合、この変更の影響を受ける可能性がある。逆に言えば、今回の修正で is_shop() のような条件分岐タグと get_queried_object() の戻り値の関係が整理され、より直感的なコードが書けるようになる。
この変更の背景には、WordPressの「投稿ページ」設定と同様にショップページでも WP_Post を返すべき、という設計上の判断がある。WooCommerce 11.0ではこの長年の不一致が解消され、より予測しやすいAPIへと改善された。
影響を受けるコードの判断方法
自作のテーマやプラグインでショップページのクエリオブジェクトを参照している場合、以下のいずれかの関数やプロパティを使用していないか確認する必要がある。
get_queried_object()を呼び出しているget_queried_object_id()を呼び出している$query->queried_objectに直接アクセスしている$query->queried_object_idに直接アクセスしている
これらのコードがショップページ上で実行され、戻り値として WP_Post_Type オブジェクトを期待しているなら、WooCommerce 11.0へのアップデート後に動作が変わる可能性が高い。とくに、queried_object->labels->name などのプロパティに依存している場合は要注意だ。
Before / After コードの比較
具体的なコードの違いを見てみよう。以下はショップページでの get_queried_object() の戻り値の変化を示している。
// WooCommerce 10.x まで Shopページのみ例外
get_queried_object(); // → WP_Post_Type
get_post_type_object( 'product' ); // → WP_Post_Type
// その他の固定ページ
get_queried_object(); // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type// WooCommerce 11.0 以降 Shopページも含めて統一
get_queried_object(); // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Typeこの変更の影響を受けないケース
次のような状況では、WooCommerce 11.0の変更による影響はなく、既存のコードはそのまま動作する。
- 単一の商品ページ（
single-product）では引き続き商品のWP_Postオブジェクトが返る - 商品カテゴリやタグ、ブランド、属性などのタクソノミーページでは
WP_Termオブジェクトが返る - その他の投稿タイプアーカイブや個別ページはもともと変更の対象外
is_shop()やis_archive()、is_post_type_archive( 'product' )といった条件分岐関数の挙動は従来どおり変わらない
開発者が取るべき具体的な対応
もし既存のコードがショップページで get_queried_object() の戻り値を WP_Post_Type として扱っている場合、WooCommerce 11.0へのアップデートに備えて改修が必要だ。修正の基本方針は「オブジェクトの型をチェックしてからプロパティにアクセスする」ことにある。
商品の投稿タイプ情報を取得する推奨方法
商品の WP_Post_Type オブジェクトが必要な場合は、get_post_type_object() を使うのが安全で推奨される方法だ。この関数はWooCommerceのバージョンに関係なく常に正しいオブジェクトを返す。
$product_post_type = get_post_type_object( 'product' );
if ( $product_post_type instanceof WP_Post_Type ) {
// 商品のWP_Post_Typeオブジェクトは
// get_post_type_object() から引き続き取得できる
$singular_name = $product_post_type->labels->singular_name;
}ショップページのWP_Post情報を扱うコード例
ショップページ自体の情報（ページタイトルやスラッグなど）を取得したい場合は、WooCommerce 11.0以降は get_queried_object() から直接 WP_Post としてアクセスできるようになる。以下はその典型的な使用例だ。
$shop_page = get_queried_object();
if ( $shop_page instanceof WP_Post ) {
// WooCommerce 11.0以降、ショップページでも
// WP_Postとして扱える
$shop_title = $shop_page->post_title;
$shop_slug = $shop_page->post_name;
}get_queried_object() / $query->queried_object を使っている箇所を特定するWP_Post_Type として使っているか確認する（ instanceof や型チェックをしていない場合）get_post_type_object( 'product' ) で商品の投稿タイプ情報を個別に取得し、既存コードを書き換える重要なのは、get_queried_object() の戻り値に依存した条件分岐を書く前に、必ず instanceof でオブジェクトの型をチェックする習慣をつけることだ。これにより、WooCommerceの将来のアップデートや他のプラグインとの競合にも強いコードになる。
この記事のポイント
- WooCommerce 11.0ではショップページの
get_queried_object()がWP_Postを返すように統一される - 商品の投稿タイプ情報が欲しい場合は
get_post_type_object( 'product' )を使用する is_shop()などの条件分岐関数の挙動は変わらないため、ページ判定ロジックの修正は不要- 影響を受けるコードは、おもにショップページでクエリオブジェクトのプロパティに直接アクセスしている箇所
- アップデート前に
instanceofによる型チェックを追加し、テスト環境で検証するのが安全な移行手順
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Hostingerが写真から即決済リンクを生成するAIツール発表、EC販売チャネルの分散化が加速
リトアニア発のホスティング企業Hostingerが、商品写真をアップロードするだけで決済リンクを生成するEC向けAIツール「Quick Links」を発表した。従来のECの常識を覆し、自社サイトを持たない販売手法を一段と推し進めるものだ。
この機能により、販売者はSNS投稿やメッセージ、メールで直接決済リンクを共有できる。見逃せないのは、単なるチェックアウト機能の追加ではなく、ECプラットフォームが「ストアの先」へと進出する方向性を明確に打ち出した点にある。
ここではQuick Linksの仕組みにとどまらず、ウェブサイトを介さないEC販売の潮流、Shopifyなど他のプラットフォームの動き、そして小規模事業者がこれから取るべき販売チャネル戦略について分析していく。
HostingerのQuick Links機能の詳細
AIが商品写真から販売ページを自動生成
Quick Linksの使い方は極めてシンプルだ。販売者が商品の写真を1枚アップロードすると、HostingerのAIが商品説明、詳細スペック、推奨価格を含む商品ページを自動で作成する。そのページには決済機能が組み込まれており、生成されたリンクをSNSやチャットで共有すれば、購入者がそのまま支払いを完了できる。
従来のECでは、まずプラットフォームを選び、ストアを構築し、商品を登録し、決済手段を設定し、集客するという手順が必要だった。Quick Linksは、この流れを「写真1枚で販売開始」まで圧縮する。ECの専門知識がない個人や小規模事業者にとって、参入障壁が極めて低くなる仕組みだ。
ウェブサイト不要のEC販売は目新しいか
しかし、この「サイト不要」というコンセプト自体は完全な新機軸ではない。決済リンク（Payment Links）やリンクインバイオツール、ダイレクトメッセージを使った販売は以前から存在している。StripeやSquare、PayPal、Shopify Starter、TikTok Shop、Instagram、Facebook Marketplace、WhatsAppなど、すでに多くの企業が従来型ストアの外側で取引を完結させる手段を提供してきた。
決定的な違いは、AIによる「写真から商品ページを自動生成する」工程が加わったことだ。これにより、販売者は商品情報を手入力する手間さえも省ける。Hostingerは単なる決済手段の提供ではなく、「AIが販売を組み立てる」という次元へ踏み込んだ。
社会的文脈とHostingerのポジショニング
HostingerのウェブサイトビルダーおよびEC責任者であるAuksė Žirgulė氏は、次のように述べている。「コマースは単純なストアからエコシステムへと移行している。人々は多様なチャネルで商品を発見し、AIエージェントが選択や比較、購入を支援することが増えている。小規模販売者にとって、この変化は大きな機会だが、顧客と同じスピードで事業を動かせる場合に限られる」
この発言の核心は「次にどのチャネルが重要になるかを予測しなくてよい」というホスティング事業者の新たな役割提示にある。販売者はチャネル開拓に頭を悩ませる必要はなく、まず商品を素早く世に出すことが優先される。チャネル戦略の複雑さをプラットフォーム側が吸収する、という宣言ともとれる。
ECプラットフォームが直面する販売チャネルの分散化
上図のように、従来はストア構築から集客、決済まで一気通貫で自前管理するのが常識だった。Quick Linksはこの流れを「商品情報をAIが生成して即座に販売リンク化」するモデルへと変える。販売者は来店を待つ必要がなく、自ら顧客のいる場所へリンクを届けにいける。
ECソフトウェアの従来モデルが揺らぐ理由
ECソフトウェアは長年、「ストアを作り、商品を並べ、トラフィックを集め、訪問者を購入に転換する」という単純明快なモデルに依存してきた。このモデルは今でも通用するが、その確実性は低下している。
- 検索エンジンは質問に直接回答するようになり、ユーザーが商品ページに到達するまでにAIが情報を要約してしまう。
- SNSプラットフォームはユーザーをフィードやアプリ内に留め、外部リンクへの遷移を抑制する傾向を強めている。
- マーケットプレイスは需要を一手に集め、販売ルールをコントロールする。
- 生成AIが商品の比較や選定を、販売者のサイトを訪れる前に行う可能性が高まっている。
Googleが構想する「ユニバーサルカート」は、検索結果やYouTube、Gmail、AI体験上でカートを形成し、販売者のサイト外で購入が完結する世界を示唆している。販売者は在庫やフルフィルメント、カスタマーサービスを引き続き担うが、購買ジャーニーの起点やカートの支配権は手放すことになるかもしれない。
Hostingerの方向性が示すプラットフォーム間競争
この不確実性の高まりこそ、Hostingerのポジショニングの背景だ。同社は単にもっと速く決済リンクを作る機能を提供しているのではない。ECプラットフォームは販売者に対して「今日はSNS投稿で、明日はマーケットプレイスで、来月はAIエージェント経由で」販売できるように支援しなければならない、というメッセージを発している。
Shopifyも同様の方向にかじを切っている。ソーシャルコマース向けツールやPOS（販売時点情報管理）の強化、Shop Payの拡張、マーケットプレイス統合、AIによる商品発見支援などを通じて、販売者がより多くの販売機会を掴めるようにしている。Hostingerの発表は、その小規模販売者版だ。ECプラットフォームの役割が「ストアのホスティング」から「販売成功のための機会創出」へと変わりつつある。
販売者にとっての実務的な意味
「最初の販売」はサイト外で起こる
オンライン販売者にとって、HostingerのQuick Linksが投げかける最大の含意はこれだ。「最初の販売は、自社サイトの外で起こる時代になった」のである。潜在顧客が最初に商品を目にする場所は、SNSのタイムラインかもしれないし、友人のメッセージかもしれないし、AIアシスタントのレコメンドかもしれない。
しかし、だからといって自社サイトの重要性が消えるわけではない。信頼構築、検索プレゼンスの維持、コンテンツマーケティング、利用規約の提示、メールアドレス収集、カスタマーサービス、リピート購入促進といった要素は、依然として自社サイトが最も適した場所だ。ブランドや商品を丁寧に説明し、顧客との長期的な関係を築く場としての役割は揺るがない。
小規模事業者がまず着手すべきこと
小規模事業者がQuick Linksのようなツールを活用する際、最初に取り組むべきは「販売チャネルの即時展開」だ。商品写真さえあれば、今日からSNS上で直接販売を始められる。特設ページのデザインや決済設定に数日を費やす必要はない。
そのうえで、徐々に自社ECサイトを構築し、ブランド体験の深化やリピーター獲得の仕組みを整えていくという二段構えの戦略が現実的になる。これまでは「まずストアを作り、その後で集客」という順序だったが、これからは「まず販売を始め、その後でストアを育てる」という順序も合理的な選択肢になる。
ECの未来像：ストアとトランザクションの分離
これまでのECは、ストアとトランザクション（取引）が一体化していることが前提だった。商品を買うには、販売者のストアにアクセスし、そのストアのカートを使い、そのストアの決済フローを経由する。この一体型モデルが、技術の進化とともに解体されつつある。
決済リンク、SNSショップ、マーケットプレイス、AIエージェントは、いずれも「販売者のサイトを経由しないトランザクション」を可能にする。ストアはブランドの本拠地として残り続けるが、販売そのものは多様な「セリングサーフェス（販売面）」に分散していく。
このトレンドは国内のEC事業者にも無関係ではない。BASEやSTORESのような国内プラットフォームも、SNS連携やリンク販売機能を強化している。WooCommerceで構築されたECサイトであっても、決済リンクを積極的に外部チャネルで活用する発想が求められるようになるだろう。
プラットフォーム選定の新しい基準
販売者やWeb制作者がECプラットフォームを選ぶ際、これまでは「ストア構築のしやすさ」「デザインの自由度」「決済手段の豊富さ」が主な評価ポイントだった。しかし今後は、「外部チャネルとの連携性」や「AIによる販売支援機能」が選定基準の上位に食い込んでくる可能性が高い。
特にWooCommerceユーザーは、WordPress上でのコンテンツマーケティングとの親和性を強みとしつつも、SNSやメッセージアプリでのダイレクト販売をどう取り込むかが課題になる。プラグインや拡張機能で決済リンクを発行し、AIによる商品情報の自動最適化を組み合わせるといった対策が現実的だ。
この記事のポイント
- HostingerのQuick Linksは、商品写真1枚からAIが商品ページと決済リンクを自動生成する。ストア構築の手間を完全に省くアプローチだ。
- ウェブサイト不要のEC販売自体は新しい概念ではないが、AIによる自動生成が加わったことで、販売開始のスピードが飛躍的に向上する。
- ECプラットフォームは、販売者のストア外での販売を支援する方向へシフトしている。Shopifyも同様の多チャネル戦略を推進中だ。
- 小規模事業者は「最初の販売をサイト外で行い、その後で自社サイトを育てる」という二段構えの戦略を検討する価値がある。
- WooCommerceなど既存のEC環境でも、決済リンクやAIによる販売支援を積極的に取り入れることが、今後の競争力を左右する。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
カートが0円だとWooCommerceの注文が完了しない時の直し方
なぜカート合計が0円だとチェックアウトが完了しないのか
WooCommerce の最低購入金額制御プラグイン（たとえば Minimum Purchase Amount Control など）は、指定した金額未満の注文を受け付けないように設計されている。このプラグインは通常、カートの合計金額が設定した最低金額を下回るとチェックアウトをブロックする。しかし「無料商品を許可する」「クーポンで0円になる場合を許可する」といった例外ルールを設定していても、内部的にはチェックアウト処理の最終段階で金額を再評価し、ブロックをかけてしまうケースがある。
このとき画面上では「注文する」ボタンを押せてしまい、一見すると購入が完了したように見える。ところが実際には注文データが正しく確定されず、商品がカートに取り残される。リダイレクト先の注文確認ページ（サンキューページ）にも遷移しない。プラグインを停止すると問題が消えることから、プラグインのゼロ円ブロック機能が直接の原因だ。
フィルターフックでゼロ円チェックアウトを許可する手順
このプラグインには、ゼロ円の注文を許可するための専用フィルターフック ct_mpac_allow_zero_total が用意されている。このフックを有効にすれば、無料商品やクーポンで合計が0円になったカートでも問題なくチェックアウトが完了するようになる。
以下の手順では、子テーマの functions.php に数行のコードを追加する。子テーマを使っていない場合は、Code Snippets プラグインなどを利用しても同じ結果が得られる。
functions.php を開く（外観 → テーマファイルエディター）追加するコードは次のとおりだ。
add_filter( 'ct_mpac_allow_zero_total', '__return_true' );この1行で、プラグインがゼロ円の注文を許可するようになる。__return_true は WordPress の組み込み関数で、単純に true を返す。フィルターにこれを渡すことで「常に許可する」という挙動に切り替わる仕組みだ。
Code Snippets プラグインを使う場合は、新規スニペットを追加し、上記のコードを貼り付けて「サイト全体で実行」に設定すればよい。
コード追加後も改善しない場合の確認ポイント
フィルター名がプラグインのバージョンと合っているか確認する
プラグインのバージョンアップによってフィルター名が変更されている可能性がある。プラグインの公式ドキュメントやソースコード内で apply_filters を検索し、最新のフック名を確認するのが確実だ。特にプラグイン名が似ている別の最低購入金額プラグインに乗り換えた場合は、フック名がまったく異なるため注意が必要になる。
キャッシュ系プラグインやサーバーキャッシュの影響を疑う
functions.php を更新したのに改善しない場合、WordPress のキャッシュプラグインやサーバーレベルのキャッシュ（OPcache など）が原因で変更が反映されていないことがある。キャッシュをすべてクリアし、さらにブラウザのシークレットモードで動作をテストしてみる。OPcache が効いているレンタルサーバーでは、ファイル更新から数分間は古いコードが動き続けるケースもある。
決済ゲートウェイ側のゼロ円制限を調べる
ごくまれに、WooCommerce の決済ゲートウェイ自体が0円のトランザクションを許可していない場合がある。プラグインの問題が解消されたあともチェックアウトが進まないときは、Stripe や PayPal などのゲートウェイ設定で「0円の注文を許可する」オプションが存在しないか確認する。テスト用に代金引換や銀行振込など、実決済を伴わないゲートウェイに切り替えて試すのも有効な切り分け方法だ。
よくある質問
このフィルターはどのプラグインに対応しているのか
ct_mpac_allow_zero_total は、主に「Minimum Purchase Amount Control for WooCommerce」系のプラグインで使われるフックだ。プラグインの作者が異なるとフック名も変わるため、必ず利用中のプラグインのドキュメントを参照してほしい。
フィルターを追加する以外の解決策はあるか
プラグインの設定画面で「無料商品を許可」「クーポン適用後の0円を許可」といったチェックボックスが用意されていれば、そちらを有効にするだけで直ることもある。設定が存在しない場合や、設定を入れても効かないときにフィルターを使うのが確実な方法だ。
ゼロ円の注文を許可するとセキュリティ上のリスクはあるか
意図した無料商品や割引クーポン以外で0円になるカートが発生しないよう、クーポンの利用条件や商品価格の設定を適切に管理していれば大きなリスクにはならない。ただし、テストや不正利用対策として、定期的に0円注文のログを確認する運用は推奨する。
子テーマを使わずにコードを追加する方法はあるか
Code Snippets プラグインや WPCode プラグインを利用すれば、テーマファイルを直接編集せずにフィルターフックを安全に追加できる。テーマのアップデートでコードが消える心配もなく、管理画面からオンオフを切り替えられるため、まずはこちらを試すのが安心だ。
この記事のポイント
- WooCommerce の最低購入金額プラグインが0円の注文をブロックし、チェックアウトが完了しない
- フィルターフック
ct_mpac_allow_zero_totalをfunctions.phpに追加すればゼロ円注文を許可できる - Code Snippets プラグインを使えば子テーマの編集なしで安全にコードを追加可能
- 改善しない場合はキャッシュのクリアや決済ゲートウェイの0円制限も確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce 11.0で配送クラスが非公開タクソノミーに変更
WooCommerce 11.0が2026年7月28日にリリースされる。このアップデートでは、商品の送料計算に使われる「product_shipping_class」タクソノミーが非公開に変更される。これまで明示的に設定されていなかった公開フラグが、WordPress のデフォルトで true 扱いとなっていた状態が解消され、内部データとしての扱いが明確になる。
多くの店舗や拡張機能では特別な対応は不要だが、配送クラスを公開タクソノミーとして利用していたコードは見直しが必要だ。この変更の背景と、開発者が確認すべきポイントを整理する。
WooCommerce 11.0で配送クラスのタクソノミーが非公開になる
配送クラス（product_shipping_class）は、商品を送料計算のグループに割り当てるための仕組みだ。たとえば「大型商品」「冷蔵商品」といったクラスを作り、各商品に紐づけることで、配送方法ごとに異なる送料を設定できる。
これまでの動き（Before）
WooCommerce 11.0 より前のバージョンでは、配送クラスをタクソノミーとして登録する際に public 引数が指定されていなかった。WordPress のタクソノミー登録関数は public が省略されるとデフォルトで true を適用する。そのため、配送クラスは「公開タクソノミー」として扱われ、is_taxonomy_viewable() が true を返していた。
この状態では、サイトマップ生成、タクソノミーアーカイブの処理、パブリックタクソノミーを列挙するクエリなどに配送クラスが意図せず含まれることがあった。
変更後の動作（After）
WooCommerce 11.0 からは、タクソノミー登録時に 'public' => false が明示的に設定される。これにより is_taxonomy_viewable( 'product_shipping_class' ) は false を返すようになり、WordPress の各種 API で配送クラスが非公開タクソノミーとして扱われる。
この変更はデータそのものを削除するものではない。すでに登録された配送クラスのタームや商品との紐づけ、送料ルールはそのまま維持される。
なぜこの変更が必要だったのか
配送クラスは本来、商品カテゴリーやタグのように顧客に見せるためのカタログ用タクソノミーではない。あくまでも送料計算のための内部データである。ところが公開タクソノミーとして振る舞うことで、サイトマップに配送クラスのアーカイブ URL が含まれたり、SEO ツールが意図しないページを認識したりといった副作用が生じていた。
一部のストアでは、この挙動を避けるために手動で除外設定を行なっていた。WooCommerce コアの修正により、根本的な原因を取り除き、特に設定をしなくても配送クラスが公開面に漏れ出さないようになる。
また、WordPress の public フラグが false になると、publicly_queryable も自動的に false を継承する。つまり、URL で配送クラスの一覧ページに直接アクセスすることもできなくなる。こうした一貫した内部データとしての扱いが、開発者にとっても予測しやすい動作につながる。
影響を受けるコードのチェックポイント
WooCommerce Developer Blog の案内に沿って、以下のようなコードを含むテーマやプラグインは変更後の動作を確認する必要がある。
is_taxonomy_viewable( 'product_shipping_class' )が true を返すことを前提にしている- 配送クラスのアーカイブページへのリンクをフロントエンドに生成している
- サイトマップや SEO、ナビゲーションの生成時に
product_shipping_classを public タクソノミーとして含めている get_taxonomies()などで公開タクソノミー一覧を取得し、その中に配送クラスが含まれることを期待している- タクソノミーの公開ステータスをもとに REST API や GraphQL のスキーマ、検索、フィルタリングをカスタマイズしている
- 送料計算以外の汎用的な商品グルーピングに配送クラスを流用している
ごく単純に、配送クラスを送料計算だけに使っている場合は影響を受けない。商品編集画面で配送クラスを設定したり、フックで送料を分岐させたりするコードはそのまま動作する。
開発者が取るべき具体的な対応
基本は何もしなくてよい
配送クラスを送料計算のみに使っているのであれば、コードの修正は不要だ。WooCommerce のコア変更がそのまま適用され、配送クラスは内部タクソノミーとして適切に管理される。
どうしても公開が必要な場合のフィルターフック
特定のサイトや拡張機能で、あえて配送クラスを公開タクソノミーとして扱い続けたいケースもあるだろう。たとえば、配送クラスのアーカイブページをカスタムデザインで用意している場合などだ。
そのような場合は、WooCommerce が用意している register_product_shipping_class_taxonomy_args フィルターを使って、登録時の引数を上書きできる。
add_filter(
'register_product_shipping_class_taxonomy_args',
function ( $args ) {
$args['public'] = true;
$args['publicly_queryable'] = true;
return $args;
}
);ただし、この方法はあくまで例外的な対応である。WooCommerce Developer Blog も述べているように、公開タクソノミーとして再利用するのではなく、本来の目的に合ったカスタムタクソノミーを新たに用意するほうが長期的に健全だ。
長期的にはカスタムタクソノミーへの移行を
商品を顧客向けにグルーピングしたい場合は、商品カテゴリー、商品タグ、商品属性、あるいは専用のカスタムタクソノミーを利用すべきだ。配送クラスはあくまで内部の送料計算用と割り切り、公開用の分類とは役割を分けることで、サイト構造が整理され、SEO の観点からも無駄なアーカイブページが生まれなくなる。
この変更はデータ移行を伴わない「公開状態の切り替え」であり、既存の設定には一切手が加えられない。しかし、今回のバージョンアップをきっかけに、配送クラスを公開タクソノミーとして使っていたコードがあれば、設計を見直す良い機会になるだろう。
この記事のポイント
- WooCommerce 11.0 で配送クラスのタクソノミーが非公開になり、サイトマップやアーカイブに現れなくなる
- 送料計算だけに使っているストアや拡張機能は特別な対応不要
is_taxonomy_viewable()や公開タクソノミーの一覧に依存しているコードは見直しが必要- どうしても公開が必要な場合はフィルターフックで復活できるが、長期的にはカスタムタクソノミーの利用を推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Mollie決済プラグインでPHP警告「Undefined array key」が出たときの対処法
Mollie Payments for WooCommerce で「PHP Warning: Undefined array key “identifier”」という警告が出ても、決済フローや Apple Pay の動作に支障はない。この警告は PHP 側の配列キー未定義による軽微な通知であり、プラグイン開発元が修正を予定している。緊急の対応が必要でなければ、エラーログへの出力を抑える設定で一時的に回避できる。
なぜ「Undefined array key “identifier”」警告が発生するのか
この警告は、PHP 8.0 以降で強化された型と配列アクセスの安全性チェックによって表面化したものだ。Mollie プラグインの Apple Pay 関連クラス内で、変数やリクエストデータに「identifier」というキーが存在しない状態で配列アクセスを行っているために出力される。
PHP 8.0 以降の配列アクセスへの影響
PHP 7.x までは、配列内に存在しないキーを参照しても通知（Notice）または軽微な警告（Warning）で済む場面が多かった。しかし PHP 8.0 からは「Undefined array key」が Warning に格上げされている。テーマやプラグインが最新の PHP に完全対応していないと、こうした警告が表面化しやすい。
Mollie プラグインの該当コードが生む状況
警告の発生箇所は ResponsesToApple.php の 89 行目と ApplePayDataObjectHttp.php の 193 行目付近だ。Apple Pay のトークン処理やデータオブジェクトの動的生成時に、送信されてくるパラメータが一部欠落している場合や、プロパティが未定義のままアクセスされている場合に警告が記録される。
もう一つの「Creation of dynamic property」は PHP 8.2 で導入された非推奨通知で、クラスに明示的に宣言されていないプロパティへ動的に値を代入している場合に発生する。いずれも決済処理の本筋を妨げるエラーではなく、サーバーのエラーログに記録されるだけの通知レベルだ。
エラーログを確認して影響度を判断する
警告の発生頻度や実際の影響を把握するには、まずサーバーのエラーログを確認する。多くの国内レンタルサーバーでは管理画面のログビューアから確認できるほか、FTP で /wp-content/ 内の debug.log を直接ダウンロードしてもよい。
エラーログの保存場所と見方
WordPress のデバッグモードを有効にしている場合、wp-config.php に定義された WP_DEBUG_LOG の設定に従い、エラーログが出力される。デフォルトでは /wp-content/debug.log に保存される。
ログを開くと日付とともにエラーレベルが記録されている。「PHP Warning」と「PHP Deprecated」の行を探し、該当のプラグイン名とファイルパスが含まれているかを確認する。もし1時間に数千回単位で記録されているようであれば、ログファイルが肥大化してディスク容量を圧迫する可能性があるため対応が必要だ。
警告の発生頻度を調べる簡単なコマンド
SSH 接続が可能なサーバーであれば、grep コマンドで頻度を数えられる。以下のように実行すると「identifier」を含む警告の出現回数がわかる。
grep -c "Undefined array key \"identifier\"" /home/user/domains/example.com/public_html/wp-content/debug.log数十件程度であれば運用上の支障は少ないが、数百件以上ある場合は早めの抑制を検討する。
PHP 警告を一時的に非表示にする方法
根本的な修正がプラグイン側で提供されるまでの間、エラーログへの出力を抑える設定で運用上のノイズを減らせる。複数の段階的な手法があるので、サイトの状況に合わせて選択する。
エラーレポートレベルを変更する
wp-config.php に以下の定数を追加すると、Warning と Deprecated をログから除外できる。この設定は本番環境で推奨される標準的なエラー抑制の手法だ。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'error_reporting', E_ALL & ~E_WARNING & ~E_DEPRECATED );WP_DEBUG_DISPLAY を false にすることで画面表示を防ぎ、error_reporting のビット演算で Warning と Deprecated だけを除外する。Fatal error など重大なエラーは引き続き記録されるため、サイトの異常を見逃すリスクは低い。
Mollie プラグイン固有のフックで抑制する
よりピンポイントに対処するなら、Mollie が提供するフィルターフックを利用する方法もある。ただし、これはプラグインのバージョンによって動作が異なるため、公式ドキュメントを参照のうえ実装する必要がある。
多くの場合、前述のエラーレポート設定で十分に警告は抑制できる。プラグイン更新後に設定を元に戻すことを忘れずに、スケジュールに組み込んでおく。
wp-config.php を開くWP_DEBUG_DISPLAY を false に設定するerror_reporting を設定して Warning と Deprecated を除外プラグインのアップデートを待つときの注意点
Mollie の開発チームはこの警告を認識しており、将来のバージョンで修正が行われる見込みだ。プラグインの更新を待つ間は、以下の点に注意してサイトを運用する。
自動アップデートを有効にしておく
WordPress の管理画面で Mollie Payments for WooCommerce の自動アップデートをオンにしておくと、修正版がリリースされた際に即座に適用される。更新を手動で行う場合は、Mollie の changelog を定期的にチェックし、「identifier」や「dynamic property」に関する修正が含まれているかを確認する。
ログのローテーションを設定する
警告が高頻度で出ていると debug.log が急速に肥大化する。サーバーのログローテーション機能や、WordPress 用のログ管理プラグインを導入して、一定期間で古いログを圧縮・削除する仕組みを整えておく。これによりディスク容量の圧迫を防げる。
よくある質問
この警告が出ていても決済は正常に動くのか
多くの場合、クレジットカードや Apple Pay の決済処理に影響はない。PHP Warning や Deprecated は実行を停止させるエラーではなく、処理は継続される。実際に決済が通っているかは、テスト購入を行って確認するのが確実だ。
他の決済プラグインでも同じ警告は出るのか
PHP 8.0 以降に完全対応していないプラグインであれば、同様の「Undefined array key」警告が発生する可能性がある。Stripe や PayPal の公式プラグインでも、過去に似たような警告が報告され修正されている。プラグインが最新かどうかを常に確認することが重要だ。
プラグインを自分で修正してもよいのか
PHP の知識があるなら、該当行に isset() によるキー存在チェックを追加すれば警告は消える。ただし、プラグインのアップデートで修正が上書きされるため、修正を維持するには継続的な管理が必要だ。本番環境では推奨しない。
PHP のバージョンを下げれば解決するか
PHP 7.4 に戻せばこの警告は出なくなるが、PHP 7.4 はすでにセキュリティサポートが終了している。サイト全体の安全性を損なうため、PHP のダウングレードは避けるべきだ。サーバー環境は常にサポート対象の PHP バージョンを維持する。
「Creation of dynamic property」も同じ対処でよいのか
同じエラーレポートレベルの設定で抑制できる。こちらも PHP 8.2 以降の非推奨通知であり、機能停止を伴わない。根本対応はプラグイン側でプロパティ宣言を追加する必要があるため、開発元のアップデートを待つ形になる。
この記事のポイント
- 「Undefined array key」警告は決済機能に影響しない軽微な通知
- PHP 8.0 以降の配列アクセス厳格化によって表面化している
- エラーレポートレベルの変更で一時的にログ出力を抑制できる
- プラグインの自動アップデートを有効にして修正版の適用に備える
- PHP バージョンのダウングレードはセキュリティリスクがあるため避ける
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce決済が「処理中」で止まりサンクスページに遷移しない場合の対処法
WooCommerceでRazorpay決済を利用しているサイトで、支払い自体は成功しているのにチェックアウト画面が「処理中です。しばらくお待ちください」と表示されたまま止まり、注文完了ページへ遷移しない問題は、RazorpayのJavaScript SDKが正常に読み込まれていないか、他のプラグインとの競合によってフォーム送信処理が破損している場合に起こる。
特にサンドボックスモードでは正常に動作するのに本番環境でのみ発生する場合、APIキーの設定ミスや決済スクリプトのパス解決エラーが根本原因である可能性が高い。ブラウザの開発者コンソールを開くと GET .../build/undefined 403 や document.razorpayform.submit is not a function といったエラーが記録されているはずだ。以下では原因の特定から具体的な修正手順までを順に解説する。
ブラウザコンソールでエラーの全体像を把握する
まず最初に行うべきは、問題が起きているページで開発者ツールを開き、コンソールタブとネットワークタブに出力されているエラーを確認することだ。Razorpayの処理フローはほぼすべてフロントエンドのJavaScriptで制御されているため、バックエンドのログだけでは見えない問題がここに集中して現れる。
Chromeの場合、決済画面で F12 を押してDevToolsを開き、以下の手順で記録を取る。
記録した中で特に注目すべきは以下の2種類のエラーだ。
GET https://checkout-static-next.razorpay.com/build/undefined 403というリクエストが発生している場合、Razorpay SDKのビルドパスが正しく解決されていない。末尾が/undefinedになっているのが最大の手がかりだ。Uncaught TypeError: document.razorpayform.submit is not a functionは、決済フォームの送信メソッドが何らかの理由で失われていることを示す。他のJavaScriptによって上書きされているか、Razorpayのスクリプト自体が最後まで読み込まれていない可能性が高い。
GET …/build/undefined 403 エラーが示す根本原因
Razorpayのチェックアウトスクリプトは、プラグインが動的に生成するパスに基づいて checkout-static-next.razorpay.com/build/【バージョン番号】 というURLから読み込まれる。このバージョン番号が何らかの理由で空になると /build/undefined という不正なURLが生成され、当然ながら403 Forbiddenで拒否される。
この現象は主に次の3つの状況で起こる。
本番用APIキーが未設定または誤ったキーが入力されている
Razorpayプラグインの設定画面（WooCommerce → 設定 → 決済 → Razorpay）を開き「本番用キーID」と「本番用キーシークレット」の両方が 本番環境用の正しい値 になっているか確認する。サンドボックス用のキーが誤って本番フィールドに入力されていると、スクリプトパスの生成に失敗する。キーはRazorpayダッシュボードの「Settings → API Keys」から再発行できる。
プラグインのバージョンが古いか不完全に更新されている
公式の「Razorpay for WooCommerce」プラグインが最新版かどうかを確認する。過去のバージョンには、特定の条件下でSDKバージョン文字列が空になる不具合が報告されている。wp-adminのプラグイン一覧で更新があれば適用し、問題が継続する場合は一度プラグインを完全に削除してから再インストールする。削除前に必ずAPIキーをメモしておくこと。
マルチカレンシープラグインがRazorpayの設定を上書きしている
WooCommerce Currency Switcher（FOXやAeliaなど）を使用している場合、通貨切り替えの過程でRazorpayの決済スクリプトに渡すパラメータが改変されることがある。特にジオベースで通貨を自動切り替えしている環境では、チェックアウトページ読み込み時に想定外の通貨コードがRazorpayに渡され、SDKの初期化に失敗するケースが確認されている。
通貨スイッチャー側の設定で、チェックアウトページと決済完了ページを通貨切り替えの対象外にするルールを追加しても改善しない場合、以下の方法で問題の所在を明確にできる。
undefined になり、スクリプトパスが /build/undefined に/build/v3.45.0 など正常にdocument.razorpayform.submit is not a function を解消する
このTypeErrorは、決済フォームを送信するタイミングで razorpayform オブジェクトの submit メソッドが存在しないことを意味する。原因は主に2つに絞られる。
JavaScriptの最適化や結合によるメソッド破損
LiteSpeed CacheやAutoptimizeなどのキャッシュ・最適化プラグインがJavaScriptを結合（Combine）したり、圧縮（Minify）したり、遅延読み込み（Defer）したりする設定が有効だと、Razorpayのフォームオブジェクトが初期化される前に他のスクリプトが実行され、document.razorpayform が不完全な状態になる。
JavaScriptの最適化機能をすべてオフにしても改善しない場合でも、LiteSpeed Cacheにはページ単位の最適化設定や「ゲストモード」など追加の最適化機能が存在する。プラグインを完全に無効化してテストした上で、それでも直らなければキャッシュ以外の競合を疑う。
サンクスページカスタマイズプラグインによるリダイレクト干渉
「WooCommerce Thank You Page」のような注文完了ページをカスタマイズするプラグインは、通常のリダイレクトフックを上書きする。Razorpayが決済完了後に実行する razorpayform.submit() が、この上書きされたフローと衝突し、メソッド呼び出し自体が失敗するケースがある。
サンクスページプラグインを無効化してテストした結果、問題が解消するのであれば、そのプラグインが原因だ。Razorpayとの互換性をプラグイン開発者に確認するか、よりシンプルなフックベースのカスタマイズ（テーマのfunctions.phpで制御）に切り替える。
プラグインの競合を段階的に切り分ける手順
エラーのパターンから明らかな原因を特定できない場合は、標準的なトラブルシューティングの手順で競合を絞り込む。本番サイトで作業する前に、必ずステージング環境を用意するか、メンテナンスモードを有効にしてから行う。
STEP 4では、まず通貨スイッチャーとキャッシュ系プラグインを最初に有効化してテストする。この2つが最も競合を起こしやすい。次にPixelYourSiteなどの外部スクリプトを注入するプラグインをテストし、最後にサンクスページプラグインを検証する。
RazorpayのWebhook設定も再確認する
フロントエンドのJavaScriptエラーに加えて、バックエンドのWebhookが正しく設定されていないと、決済完了後に注文ステータスが更新されない。Razorpayダッシュボードの「Settings → Webhooks」で以下を確認する。
- Webhook URLが
https://あなたのサイトURL/wc-api/razorpay_webhook/になっている。 - イベントに
payment.authorizedとrefund.createdが最低限含まれている。 - WebhookシークレットがWooCommerce側のRazorpay設定に入力した値と完全に一致している。
- 重複したWebhook登録がない（過去のテストで作成した古いWebhookが残っていると競合する）。
よくある質問
サンドボックスでは正常なのに本番だけで止まるのはなぜですか？
本番用のAPIキー設定ミスか、本番環境専用のプラグイン（セキュリティや最適化）がRazorpayのスクリプトに干渉している可能性が高い。サンドボックスと本番で異なるキーを使っていることを再確認し、本番環境にのみ有効なプラグインを一時停止して切り分ける。
Razorpay以外の決済ゲートウェイでも同じ現象は起こりますか？
StripeやPayPalなど他の決済プラグインでも、JavaScriptの競合やリダイレクトフックの干渉によって同様の「処理中」ループが発生することがある。原因の切り分け手順はほぼ共通しているため、本記事のSTEPを他のゲートウェイにも応用できる。
コンソールにエラーが出ていないのに処理が止まる場合は？
PHPのメモリ不足や実行時間制限が原因で、決済完了後のサーバーサイド処理が途中で止まっている可能性がある。WooCommerceのステータスレポートでPHPのメモリ制限が256MB以上、最大実行時間が300秒以上あるか確認する。サーバーのエラーログも併せて調査する。
Razorpayプラグインを最新にしても直らない場合は？
プラグインの公式GitHubリポジトリで同様のIssueが報告されていないか確認する。解決策としてパッチが提供されていることもある。また、Razorpayのカスタマーサポートに本番環境のドメインとエラーの詳細を伝えて調査を依頼する方法も有効だ。APIキーの発行元アカウントに制限がかかっていないかも合わせて確認してもらえる。
PixelYourSiteを無効化せずに共存させる方法はありますか？
PixelYourSiteの設定で「チェックアウトページでのスクリプト実行を遅延させる」オプションをオフにするか、カスタムコードでRazorpayのスクリプトがPixelYourSiteより先に読み込まれるよう wp_enqueue_scripts の優先度を調整する。functions.phpに以下のようなコードを追加する方法もある。
add_action('wp_enqueue_scripts', function() {
if (is_checkout()) {
wp_dequeue_script('pys');
wp_enqueue_script('pys', 'path/to/pys.js', array('razorpay'), null, true);
}
}, 100);このコードはあくまで概念を示すもので、実際のハンドル名やパスはプラグインのソースを確認して書き換える必要がある。
この記事のポイント
- ブラウザコンソールで
/build/undefined403エラーやrazorpayform.submitTypeErrorを確認する - 本番用APIキーが正しく入力されているか、Razorpayダッシュボードで再確認する
- 通貨スイッチャーがチェックアウトページで干渉していないか検証する
- JavaScript最適化プラグインを完全無効化し、サンクスページカスタマイズプラグインを停止してテストする
- 全プラグイン無効化と標準テーマ切り替えで競合を段階的に切り分ける
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている