タグアーカイブ ECサイト

WooCommerce 11.2が登場、商品CSVのUPC照合と決済日付入力を追加

WooCommerce 11.2が2026年10月8日にリリースされた。今回のアップデートでは商品CSVインポートの照合方法が拡張され、サプライヤーから届いたUPCだけの価格表をそのまま取り込めるようになった。ほかにもチェックアウトでの日付入力、注文撤回メールの設定、カタログ画面のパフォーマンス改善が含まれる。

ECサイトを運営する担当者にとって、日々の商品管理と受注業務に直結する変更が中心だ。特に商品コードを使った一括更新は、数千点規模の在庫を扱う店舗で作業時間を大きく短縮できる。本記事ではWooCommerce 11.2の主要な変更点と、アップデート前に確認しておきたい注意事項をまとめる。

WooCommerce 11.2の主な変更点

WooCommerce 11.2の主な変更点

WooCommerce 11.2はWordPressのECプラグインとして広く利用されているWooCommerceのマイナーアップデートだ。公式ブログでは変更点を6つの項目に分けて紹介している。いずれも店舗運営の効率化に寄与する内容で、商品管理から顧客体験の改善まで幅広い。

WooCommerce 11.2の変更点マップ
商品管理 CSVインポートがUPC・GTINなどで照合できる
チェックアウト 注文時に日付入力欄を追加できる
メール設定 注文撤回メールを管理画面で設定できる
パフォーマンス カタログ画面とレポート集計が高速化
ブロック機能 商品フィルターがスティッキー表示に対応
注意点 一部メールのCC・BCC配信が停止される

上記のほか、セキュリティ改善とデータベース更新も含まれる。更新前にバックアップを取得しておくことが推奨される。

商品CSVインポートがUPC・GTINなどのコードに対応

商品CSVインポートがUPC・GTINなどのコードに対応

商品コードとは

UPC(Universal Product Code)は主に米国で使われるバーコード規格で、商品パッケージに印刷された12桁の数字を指す。GTIN(Global Trade Item Number)は国際標準の商品識別コード、EAN(European Article Number)は欧州で広く使われるバーコード、ISBNは書籍の識別コードだ。いずれも商品を一意に特定するための番号で、サプライヤーから届く価格表にはこれらのコードだけが記載されていることが多い。

インポート時の照合の流れ

WooCommerceの商品CSVインポート機能では、これまで各行を商品IDまたはSKUで照合して既存商品を更新していた。11.2では照合の優先順位が拡張され、ID、SKU、GTIN、UPC、EAN、ISBNの順に一致する商品を探す。サプライヤーからUPCだけの価格表を受け取った場合でも、そのままCSVファイルとしてアップロードできるようになった。

CSVインポートの照合順序
STEP 1 商品IDで照合
↓
STEP 2 SKUで照合
↓
STEP 3 GTIN・UPC・EAN・ISBNで照合
照合は上から順に行われ、最初に一致したコードが使われる

利用するにはインポート画面で「既存の商品を更新」を有効にする必要がある。同一商品にSKUとUPCの両方が登録されている場合はSKUが優先される仕組みだ。

チェックアウトで日付入力を追加できる

チェックアウトで日付入力を追加できる

日付フィールドの用途

チェックアウトブロックを使用している店舗では、注文手続き中に顧客へ日付を尋ねられるようになった。配達希望日や誕生日など、商品の性質に合わせて自由に用途を決められる。顧客はスマートフォンやブラウザ標準の日付ピッカーを使って日付を選択する。店舗側は選択できる日付の範囲も制限できる。

設定方法

この日付フィールドを追加するには、チェックアウトブロックの設定にショートコードスニペットを追加する。テーマのfunctions.phpやコード管理プラグインに数行のコードを貼り付けるだけで有効化できる。コードの詳細は公式のリリースノートに記載されている。

チェックアウト画面の変化
従来のチェックアウト(Before)
お名前
入力欄
配送先住所
入力欄
↓
改善後のチェックアウト(After)
お名前
入力欄
配送先住所
入力欄
配達希望日
日付を選択

この例では配達希望日を追加しているが、誕生日や引き取り希望日など、店舗の運用に合わせて自由にラベルを変更できる。

注文撤回メールを管理可能に

注文撤回メールを管理可能に

EU圏の顧客に販売している店舗向けの変更も入った。注文撤回(キャンセル要求)が発生したときに送信される2種類のメールを、管理画面から設定できるようになった。1つは顧客が受け取る確認メール、もう1つは店舗側に届く通知メールだ。

WooCommerceの設定画面にある「メール」セクションで、それぞれのメールに独自のメッセージを追加できる。プレビューで内容を確認し、通知を受け取る担当者を選び、必要なければメール自体を無効化することも可能だ。これまではコードでしか変更できなかった設定が、管理画面だけで完結するようになった。

パフォーマンス改善とブロックの新スタイル

パフォーマンス改善とブロックの新スタイル

カタログと管理画面の高速化

商品数が5点でも5万点でも、カタログ画面で商品を自由に並べ替えられるようになった。可変商品(サイズや色などのバリエーションを持つ商品)を含む店舗では、商品ページの読み込みとチェックアウト処理が高速化している。レポート集計ではデータベースへのクエリ数が減り、顧客数が増えてもメモリ使用量が増加しにくくなった。

レポート集計のパフォーマンス
従来(Before)
データベースクエリ数が多い
顧客数に比例してメモリ使用量が増加
↓
WooCommerce 11.2(After)
クエリ数を削減
メモリ使用量が顧客数に依存しない

大量の顧客データを持つ店舗ほど、この改善による管理画面の体感速度は大きく変わる。レポート表示が遅くて開くのを待っていた店舗は、更新後に改善を実感しやすい。

商品フィルターブロックのスティッキー表示

商品フィルターブロックにスティッキー(追従)表示のオプションが追加された。長いカテゴリーページを顧客が下へスクロールしても、フィルター条件が画面上部に表示され続ける。絞り込みのたびにページ先頭まで戻る手間がなくなる。

ほかにも数量セレクター(カート内のものを含む)は枠線、影、色、角丸を設定できる。商品画像には枠線、フィルターチップにはフォントと余白のコントロールと角丸が追加された。これらのスタイルは外観 > エディター > スタイル > ブロックの画面で店舗全体に一括設定するか、ブロック単位で個別に調整する。

アップデート前に知っておくべき注意点

アップデート前に知っておくべき注意点

既存メール設定への影響

パスワードリセット、新規アカウント作成、メール確認の各メールについて、自分自身をCCまたはBCCでコピー受信していた場合、その配信が停止される。これらのメールにはログインリンクが含まれるため、本人以外には送られないようにするセキュリティ上の変更だ。

ダウンロードリンクと権限の変更

標準のダウンロードリンクは従来どおり動作する。ただし、まれにカスタム登録やインポートで不正なデータを持つリンクは動作しなくなる可能性がある。顧客から報告があれば、注文画面からリンクを再発行すればよい。

ショップマネージャー(店舗運営者)が、フォーラム権限や会員権限など特定の追加権限を持つユーザーを編集できなくなる。そのようなユーザーの編集はWordPress管理者が行うことになる。

アップデート手順の注意

WooCommerce 11.2にはセキュリティ改善とデータベース更新が含まれるため、運営中のすべての店舗でアップデートを適用することが推奨される。データベース更新が走るので、事前のバックアップが必須だ。

この記事のポイント

  • WooCommerce 11.2は2026年10月8日にリリースされた
  • 商品CSVインポートがUPC・GTIN・EAN・ISBNでの照合に対応した
  • チェックアウトブロックに日付入力欄を追加できる
  • 注文撤回メールの管理画面設定が可能になった
  • パフォーマンス改善とセキュリティ更新を含むためバックアップしてアップデートを
WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能

WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能

WooCommerce 11.6が2027年2月にリリース予定で、このバージョンからPHP 8.1以上が必須要件になる。PHP 7.4または8.0で動かしているストアは、それまでに移行準備を進める必要がある。

移行期間を確保するため、WooCommerce 11.3では管理画面に警告通知が追加される。通知は現在のPHPバージョンとホスティング事業者への相談を促す内容で、閉じることもできる。11.5までは従来のPHP環境でも更新を継続できる仕組みだ。

WooCommerceが公開した利用統計によれば、追跡対象ストアの約7%がPHP 7.4、約2%がPHP 8.0で稼働している。この記事では移行の背景、通知の内容、具体的な手順、影響範囲を整理する。

PHP 8.1必須化の背景にある3つの理由

PHP 8.1必須化の背景にある3つの理由

セキュリティサポートの終了

PHP 7.4と8.0は、PHP公式のセキュリティサポートがすでに終了している。サポートが切れたバージョンでサイトを運営し続けると、新しい脆弱性が発見されても修正パッチが提供されない。WooCommerce側でパッチを出しても、PHPランタイム自体のリスクは残る。

依存関係の更新とコードパスの削減

PHP 7.4と8.0に対応し続けるには、古い依存パッケージを固定し、バージョンごとの分岐コードを維持する必要がある。PHP 8.1を最低ラインにすることで、開発者とエクステンション製作者は新しいPHP機能を使え、テスト対象の環境も減らせる。WooCommerceはすでにPHP 8以上での動作を長年サポートしてきた実績がある。

今回の変更は、最低ラインを引き上げて将来のリリースの土台を作るものだ。コミュニティからのフィードバックを受けて、対象リリースをWooCommerce 11.6に設定した。繁忙期の後に十分なテストとアップグレードの時間を確保できるよう配慮されている。

従来の最低要件(Before)
PHP 7.4 PHP 8.0
セキュリティサポートが終了したバージョンでも動作。ただし新たな脆弱性が発見されてもパッチが提供されない。
↓
WooCommerce 11.6の最低要件(After)
PHP 8.1以上 推奨はPHP 8.3以上
新しいPHP機能を利用でき、依存パッケージの更新も進めやすくなる。テスト対象の環境も削減できる。
※ PHP 8.1で最低要件を満たすが、WooCommerceの現在の推奨はPHP 8.3以上

デモで示したように、最低要件の引き上げは単なる制限強化ではなく、開発基盤を健全化するための措置だ。PHP 8.1以降には型システムの改善やJITコンパイラの成熟など、パフォーマンスと保守性の面で有利な機能が揃っている。

WooCommerce 11.3で表示される警告通知

WooCommerce 11.3で表示される警告通知

WooCommerce 11.3から追加される通知は、PHP 7.4または8.0で稼働するストアの管理画面にのみ表示される。現在のPHPバージョンを表示し、ホスティング事業者にアップグレードを相談するよう案内する。通知は閉じられる仕組みで、11.3の利用自体は従来のPHPでも継続できる。

通知の役割はあくまで予告だ。実際に最低要件が変わるのはWooCommerce 11.6がリリースされたタイミングになる。それまでは通常どおり11.3、11.4、11.5へと更新を続けられる。

WooCommerce 11.3 管理画面の警告通知イメージ
⚠️ PHPバージョンの更新が必要です
このストアはPHP 7.4で動作しています。WooCommerce 11.6からPHP 8.1以上が必須になります。ホスティング事業者にPHP 8.3以上へのアップグレードを相談してください。
閉じる ※ 閉じてもストアの動作には影響しない
■ 通知はPHP 7.4または8.0の環境のみに表示 ■ 11.5までは従来のPHPでも更新可能

通知を閉じた後でPHPバージョンを確認したい場合は、管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認すればよい。ホスティング環境が更新済みなら、WooCommerceの推奨はPHP 8.3以上だ。

通知を確認した後の移行手順

通知を確認した後の移行手順

通知が表示されたストアは、以下の手順でPHPアップグレードを進める。焦らず、ステージング検証を挟むのが安全だ。

PHPバージョンの確認

管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認する。PHP 7.4または8.0が表示された場合は、移行の対象になる。WooCommerceのPHPアップデートガイドも参考になる。

ステージング環境での検証

バックアップを取得し、ステージング環境でPHP 8.3以上に切り替える。決済と支払い方法、配送計算、税計算、注文管理、スケジュールジョブ、テーマ、拡張機能、カスタムコードを一通り検証する。互換性の問題があれば、本番を変更する前に解決する。

本番環境の切り替えと確認

ステージングで問題がなければ本番を切り替え、再度「WooCommerce」→「ステータス」と重要フローを確認する。その後、WooCommerce 11.6への更新が可能になる。

STEP 1 WooCommerceのステータス画面でPHPバージョンを確認
↓
STEP 2 バックアップを取得し、ステージング環境でPHP 8.3以上に切り替え
↓
STEP 3 決済・配送・税計算・注文管理・拡張機能を一通り検証
↓
STEP 4 本番環境を切り替え、重要フローを再確認してからWooCommerce 11.6へ更新
■ 青=確認 ■ 緑=準備 ■ 橙=検証 ■ 紫=切り替え

ステージング検証は省略しがちだが、決済や配送計算の不具合は売上に直結する。特に拡張機能やカスタムコードを多用するストアでは、本番前に必ず検証したい。

アップグレードが間に合わない場合の選択肢

アップグレードが間に合わない場合の選択肢

WooCommerce 11.5はPHP 7.4と8.0に対応する最後のリリースになる予定だ。ホスティングや拡張機能の制約で移行が遅れる場合は、11.5に留まって作業を進められる。WordPressはPHP要件を満たさないプラグインの更新を通常ブロックするため、11.6への更新はサーバー側のPHPバージョンが8.1以上になるまで制限される。

11.5に留まるのは一時的な選択肢だ。WooCommerceのセキュリティパッチサポートポリシーでは、CVSS 9以上の重大な脆弱性の修正は、直近21メジャーリリースシリーズにバックポートされる。しかしそれ以外の修正は最新版にしか提供されない。加えてPHP 7.4と8.0自体のセキュリティサポートも終了しているため、WooCommerceのパッチだけではランタイムのリスクを解消できない。

WooCommerceバージョンとPHP要件の対応
11.3〜11.5 PHP 7.4 / 8.0 でも利用可能(通知は表示される)
11.5まで PHP 7.4 / 8.0 で更新できる最後のリリース
11.6以降 PHP 8.1以上が必須。PHP 7.4 / 8.0では更新できない
⚠️ 11.5に留まる場合の注意点
CVSS 9以上の重大な脆弱性のみ直近21メジャーリリースにバックポートされる。それ以外の修正は最新版のみ。PHP 7.4 / 8.0自体のセキュリティサポートも終了しているため、リスクは残る。
■ 青=移行期間 ■ 橙=最終ライン ■ 赤=必須要件

移行が遅れる理由として、特定の拡張機能がPHP 8.1以上に対応していないケースがある。その場合は拡張機能開発者に互換性の状況を確認し、代替手段を検討するのが現実的な対応だ。

ストアと拡張機能への影響範囲

ストアと拡張機能への影響範囲

利用統計から見る影響

WooCommerceが公開した統計によると、追跡対象ストアの約7%がPHP 7.4、約2%がPHP 8.0で稼働している。直近1年間にWooCommerceを更新したストアに限ると合計約6%で、この数値は継続的に減少している。実際に要件が変わる2027年2月にはさらに低くなると見られる。使用状況の追跡はオプトイン方式のため、この数値はサンプルであり全ストアの正確なカウントではない。

拡張機能マーケットの静的解析

WooCommerceは全拡張機能マーケットプレイスを対象にPHP 8.1互換性の静的解析を実施した。購入可能な1,357個の拡張機能のうち、0.22%に潜在的な問題が見つかり、開発者と手動で確認中だ。ただしこのスクリーニングはすべての拡張機能、テーマ、カスタム統合の動作を保証するものではない。各ストアは自分の環境でテストする必要がある。

拡張機能開発者と制作会社向けには、WooCommerce 11.6が使うPHP 8.1と推奨PHPバージョンの両方でテストするよう案内がある。互換性の問題を見つけた場合は、PHPとWooCommerceのバージョン、影響する拡張機能、再現手順をGitHubのイシューかコメントで共有することが推奨されている。

拡張機能マーケットのPHP 8.1互換性スキャン結果
99.78% 問題なし 0.22% 要確認
1,357個の拡張機能を静的解析。問題が見つかったものは開発者と手動で確認中。ただしスクリーニングは動作保証ではない。
ストアのPHPバージョン分布(追跡対象サンプル)
PHP 8以上 約91% PHP 7.4 約7% PHP 8.0 約2%
直近1年間に更新したストアでは合計約6%で継続的に減少。実際の要件変更時にはさらに低くなる見込み。
■ 緑=安全 ■ 青=PHP 8以上 ■ 橙=要移行 ■ 赤=要確認・要移行

影響範囲は限定的だが、該当するストアにとっては計画的な移行が欠かせない。PHPアップグレードは早めに着手し、繁忙期に入る前に完了しておくのが安全だ。

この記事のポイント

  • WooCommerce 11.6からPHP 8.1以上が必須になり、11.3で警告通知が追加される
  • PHP 7.4と8.0は公式セキュリティサポートが終了しており、移行は不可避だ
  • 11.5までは従来のPHP環境で更新可能だが、あくまで一時的な選択肢だ
  • 移行前にはバックアップとステージング検証を必ず実施する
  • PHP 8.3以上への更新がWooCommerceの現在の推奨だ
WooCommerce 11.1.2リリース!商品ギャラリーの無限再帰とメールレビュー検証を修正

WooCommerce 11.1.2リリース!商品ギャラリーの無限再帰とメールレビュー検証を修正

WooCommerce 11.1.2が2026年9月22日にリリースされた。商品バリエーションギャラリーで発生する無限再帰の修正と、メール経由の商品レビューにおける入力検証の強化が含まれるドットリリースだ。

今回の更新はセキュリティ更新に該当する。データベースの更新は不要で、適用のハードルは低い。ECサイト運営者は早めのアップデートを検討したい。

WooCommerce 11.1.2のリリース概要

WooCommerce 11.1.2のリリース概要

WooCommerceのドットリリースとは、メジャーバージョンやマイナーバージョンの間に挟まれる小規模な修正更新のことだ。新機能の追加はなく、既知の不具合修正とセキュリティ強化に絞られる。

今回の11.1.2は、2026年9月22日に公開された。公式のリリースノートによると、セキュリティ更新に該当し、データベース更新は不要とされている。つまり、プラグインの更新ボタンを押すだけで適用が完了する。

修正内容は2つに絞られている。1つ目は商品バリエーションギャラリーにおける無限再帰の防止、2つ目はメールベースの商品レビューにおける検証の厳格化だ。どちらもECサイトの安定稼働に直結する内容である。

商品バリエーションギャラリーの無限再帰を修正

商品バリエーションギャラリーの無限再帰を修正

1つ目の修正は、テーマがテンプレートファイル内で get_available_variations 関数を呼び出した際に無限再帰が発生する問題への対処だ。GitHubのプルリクエスト番号68939で修正されている。

無限再帰とは何か

無限再帰とは、関数が終了条件なしに自分自身を呼び出し続ける状態を指す。プログラミングの世界では「スタックオーバーフロー」と呼ばれるエラーにつながる。たとえるなら、合わせ鏡の間に立ったときに像が無限に反射して見えるのに似ている。どこかで止める仕組みがなければ、コンピュータのリソースを使い果たしてしまう。

WooCommerceの商品バリエーションギャラリーでは、テーマが独自に get_available_variations を呼び出すケースが問題になった。テーマのテンプレートファイルにこの関数の呼び出しが含まれていると、内部のフックが再帰的に呼び出されてスタックが溢れ、商品ページ全体が白画面になったり応答しなくなったりする。

修正の内容と影響範囲

修正後は、テーマが get_available_variations をテンプレートファイルで呼び出しても、再帰的な呼び出しが防止される。バリエーションごとの画像ギャラリーが正常に表示され、商品ページが通常どおり動作するようになる。

影響を受けるのは、バリエーション商品を持つECサイトで、なおかつテーマがこの関数を直接呼び出している場合に限られる。標準のWooCommerceテーマや多くの人気テーマでは問題は発生しない。しかし、独自にカスタマイズしたテーマを使っている場合は注意が必要だ。

修正前(Before)
⚠ ページが応答しない
テーマが get_available_variations をテンプレート内で呼び出すと、内部フックが再帰的に実行されてスタックが溢れる。商品ページ全体が白画面になり、購入フローが停止する。
↓
修正後(After)
✅ ギャラリーが正常に表示
再帰的な呼び出しが防止され、バリエーション画像の一覧が正しく表示される。商品ページが通常どおり動作し、購入フローに支障が出ない。
■ 赤枠は修正前の問題状態 ■ 緑枠は修正後の正常状態を示す

上図のとおり、修正前は get_available_variations の再帰呼び出しにより商品ページ全体が停止する可能性があった。修正後はこの再帰が防止され、ギャラリーが正しく表示される。独自テーマを運用している場合は、この修正の適用前にステージング環境で動作確認することを推奨する。

メールレビューの検証を強化

メールレビューの検証を強化

2つ目の修正は、メール経由で投稿される商品レビューの入力検証を厳格化するものだ。GitHubのプルリクエスト番号68961で対応された。セキュリティ更新とされる理由はこの修正にある。

メールベースのレビュー機能とは

WooCommerceには、購入者からのレビューをメールで受け付ける仕組みがある。顧客が注文後に届くメール内のリンクからレビューを投稿できる機能だ。ECサイトにとってレビューは信頼構築の要であり、この導線はコンバージョン率にも影響する。

問題は、このメール経由の投稿経路において入力値の検証が十分でなかった点だ。悪意のある第三者が不正なデータを送信する余地があり、セキュリティリスクになり得た。今回の修正では、この検証処理が厳格化されている。

検証強化がもたらす効果

検証の厳格化により、不正な入力や改ざんされたデータがレビューとして投稿されるリスクが低減される。レビューの信頼性が保たれ、ECサイトの評判管理にも好影響を与える。

店舗運営者の目線では、この変更によってレビュー投稿のフローに大きな変化はない。顧客が正規のメールリンクからアクセスする限り、従来どおりの手順でレビューを投稿できる。内部のバリデーションが強化されただけなので、ユーザビリティへの影響はない。

STEP 1 顧客が注文後のメールからレビューフォームを開く
↓
STEP 2 WooCommerceがレビューデータを受信
↓
STEP 3 入力値の検証を実行(今回強化された箇所)
↓
STEP 4 検証を通過したレビューが公開される
■ オレンジ色のSTEP 3が今回の修正で強化された検証処理を指す

上図のとおり、メール経由のレビュー投稿は4段階で処理される。今回の修正はSTEP 3の検証処理に焦点を当てており、不正なデータの流入を防ぐ役割を担う。顧客側の操作フローに変更はない。

ECサイト運営者が取るべき対応

ECサイト運営者が取るべき対応

この更新はセキュリティ更新のため、基本的には即時適用が望ましい。ただし、独自テーマやカスタムコードを使っているサイトでは、事前の動作確認を怠らないことが重要だ。

更新前の準備

更新の前に、サイト全体のバックアップを取得する。WooCommerceを運用するECサイトでは、商品データ、注文履歴、顧客情報が失われると事業に直結する。更新作業の前には必ずデータベースとファイルの両方をバックアップしておく。

また、ステージング環境が利用できるのであれば、本番環境に適用する前に更新後の動作を確認する。特にバリエーション商品を持つ場合は、商品ページでギャラリーが正しく表示されるかをチェックしたい。

更新手順の目安

WooCommerceの更新はWordPressの管理画面から行える。プラグイン一覧からWooCommerceを選択し、更新を実行するだけだ。データベース更新が不要なため、更新後のマイグレーション処理も発生しない。

更新後は、商品ページ、カート、チェックアウト、レビュー投稿の各フローが正常に動作するかを確認する。特にメールレビュー機能を有効にしている場合は、テスト用のレビューを1件投稿して検証すると安心だ。

この記事のポイント

  • WooCommerce 11.1.2は2026年9月22日に公開されたセキュリティ更新で、データベース更新は不要
  • 商品バリエーションギャラリーの無限再帰を修正し、独自テーマ利用時の白画面リスクを解消
  • メール経由の商品レビューにおける入力検証を強化し、不正データの投稿リスクを低減
  • 独自テーマやカスタムコードを運用中のサイトは、ステージング環境での事前確認を推奨
WooCommerce公式ブロックテーマPurpleがベータテスト開始。テスト方法と注目機能

WooCommerce公式ブロックテーマPurpleがベータテスト開始。テスト方法と注目機能

WooCommerce初の公式ブロックテーマ「Purple」がベータテストを開始した。GitHubからダウンロードできる状態で、正式版はWordPressテーマディレクトリとWooCommerceマーケットプレイスで配布される予定だ。

PurpleはECサイト向けに作られたスターターテーマで、テンプレート一式、10種類のカラーパレット、10種類のフォント組み合わせ、EC向けパターンライブラリを備える。ブロックテーマのため、従来のクラシックテーマより軽量で柔軟なカスタマイズが可能だ。

この記事ではPurpleの特徴、WooCommerceコアに加わったブロック改善、テスト手順を解説する。ストア運営者や制作会社がベータテストに参加する際の参考にしてほしい。

Purpleテーマとは何か

Purpleテーマとは何か

PurpleはWooCommerceチームが開発したオープンソースのスターターテーマだ。ブロック対応のWooCommerceページ用テンプレートをほぼ網羅しており、WooCommerceとWordPressコアブロックのカスタムスタイルも含む。ストアを立ち上げる事業者が、モダンで高速な土台として使える設計になっている。

ブロックテーマとは、WordPressのブロックエディタだけでサイトの見た目やレイアウトを編集できるテーマ形式のことだ。従来のテーマはPHPテンプレートとCSSが中心だったが、ブロックテーマはブロックの組み合わせでページを構成する。エディタ上で完結するため、コードを書かずにデザインを変更できるのが特徴だ。

Purpleには商品グリッド、フィルター、コレクション、CTA、商品詳細ページなどを含むEC特化のパターンライブラリも同梱されている。パターンとは、あらかじめ組み立てられたブロックのセットで、ワンクリックでページに挿入できる部品のことだ。

Purpleテーマに含まれる主な要素
テンプレートブロック対応のWooCommerceページ用テンプレート一式
カラーパレット10種類の配色プリセット
フォント10種類のフォント組み合わせ
パターン商品グリッド、フィルター、コレクション、CTA、商品詳細ページなど

このデモはPurpleテーマの中核となる4つの要素を示している。開発者や制作会社はこれらのテンプレートとスタイルを拡張し、独自のストアデザインの出発点として使える。

Storefrontとの違い

WooCommerceの従来の代表テーマであるStorefrontと比較すると、Purpleの違いが分かりやすい。Storefrontはクラシックテーマで、商品ヒーローデザイン、カスタムホームページ、商品ギャラリー、ミニカート、高度なヘッダーやフッターを実現するには拡張機能が必要だった。

一方、ブロックテーマではWooCommerceのブロックライブラリとブロックエディタだけで、これらのカスタマイズを実現できる。拡張機能に依存せず、テーマとコア機能だけでストアを構築できるのがPurpleの大きな利点だ。

WooCommerceコアに加わったブロック改善

WooCommerceコアに加わったブロック改善

Purpleプロジェクトの価値はテーマそのものだけではない。開発の過程で、WooCommerceコアに多数のブロック改善が加わった。この改善はPurpleに限らず、影響を受けるブロックやAPIを使うすべてのブロックテーマで利用できる。

バージョン11.0の基盤整備

WooCommerce 11.0では、ブロックテーマを軽量かつ一貫性のあるものにするための基盤が整えられた。まず、パターンコンテンツの読み込みが必要になった時だけ行われるようになった。これにより、パターンを必要としないリクエストでの無駄な処理が減る。

商品画像まわりも改善された。Product Imageブロックはより大きなサムネイルを使い、トリミングされた画像でも正しいアスペクト比を保持する。商品カタログの見た目がテーマ設定と調和しやすくなった。

そのほか、Product CollectionブロックがQuery Loopの内側にネストされた際に正しいコンテキストを保持するようになり、複合テンプレートやパターン内で商品ブロックが正しく描画されるようになった。Breadcrumbsブロックはtheme.jsonによるスタイリングに対応し、Product Filtersブロックはフィルタードロワーを無効化するオプションを追加した。カートテーブルのヘッダーにはARIAロールが付与され、支援技術でのアクセシビリティも向上している。

バージョン11.1のレスポンシブ対応

WordPress 7.1がブロックエディタにレスポンシブデザインコントロールを導入したことを受け、WooCommerce 11.1では主要なブロックがこのコントロールに対応した。Product Priceはタイポグラフィ、色、パディング、マージンのレスポンシブスタイリングに対応し、Product Reviewsも画面幅ごとのスタイルを反映できるようになった。

Product Detailsはパディング、マージン、背景、ボーダーをブロックとグローバルスタイルの両方から設定できる。Product Galleryはカスタムアスペクト比に対応し、大きな画像エリアとサムネイルレールの同期も改善された。

パフォーマンス面では、ブロック登録の改善が大きい。ブロックを描画できないリクエストではブロックとパターンの登録をスキップする仕組みが入り、公開された測定値ではStore APIとRESTリクエストが30〜42%高速化した。統合ブロックエディタアセットの実験的サポートも導入され、サイト編集中のネットワーク転送サイズは48.3%削減された。

従来のブロック登録(Before)
すべてのリクエストでブロックとパターンを登録
不要な処理が発生
↓
WooCommerce 11.1の改善後(After)
ブロックを描画できないリクエストでは登録をスキップ
Store APIとRESTリクエストが30〜42%高速化

このデモはブロック登録の最適化前後の違いを示している。不要な登録処理を省くことで、APIリクエストの応答時間が大幅に短縮された。

バージョン11.2の注目機能

WooCommerce 11.2は現在開発中だが、テーマ作業の成果が最も目に見える形で現れているバージョンだ。Product Filtersブロックはレスポンシブオーバーレイとスティッキー配置のコントロールを獲得した。インライン表示のままにするか、モバイルやタブレットでオーバーレイに切り替えるか、全画面幅でオーバーレイを使うかを選べる。WordPress 7.1の設定可能なレスポンシブブレークポイントにも対応する。

Product Quantityブロックはテキスト色、背景色、ボーダー半径、ボーダー、シャドウをブロックスタイルから設定できるようになった。グループ商品の数量コントロールも同じスタイリングモデルを使う。Product Imageブロックはテーマ定義のボーダーに対応し、商品グリッドやコレクションパターンにストアのビジュアルシステムを反映しやすくなった。

Chipsブロックもテーマ化が進んだ。商品フィルターや「カートに追加+オプション」で使われるChipsブロックにタイポグラフィとボーダー半径のコントロールが追加され、ストア全体と一貫したスタイルを適用できる。パターンのインサーターカテゴリ名は「WooCommerce」から「Shop」に変更され、パターンを探しやすくなった。

Purpleのテスト方法

Purpleのテスト方法

Purpleはベータ版のため、必ずステージング環境またはローカルサイトでテストしてほしい。本番環境でのテストは推奨されない。最新のWordPressとWooCommerceを使うことで、前述のレスポンシブコントロールを実際に試せる。

Purpleテーマのテスト手順
STEP 1ステージング環境またはローカルサイトを準備する
↓
STEP 2最新のWordPressとWooCommerceをインストールする
↓
STEP 3GitHubからPurpleをダウンロードしてテーマとしてインストールする
↓
STEP 4テーマを有効化して外観→エディタを開く
↓
STEP 5各テンプレートとブロックをテストする

この手順でテーマをインストールした後、フロントページ、ショップまたは商品カタログ、商品詳細、カート、チェックアウト、マイアカウント、検索の各テンプレートを確認する。特にProduct Filtersブロックはデスクトップ、タブレット、モバイルの3つの画面幅でテストし、インラインモードとオーバーレイモードの両方を試す。

商品ブロックについては、Product Price、Product Details、Product Reviews、Product Gallery、Product Quantity、Catalog Sorting、Mini-Cartを、シンプル商品、バリエーション商品、グループ商品の3種類でテストする。通常使っている拡張機能や子テーマのカスタマイズを追加して、エディタとフロントエンドの両方で再テストするのが望ましい。なお、GitHubから直接ダウンロードした場合、自動更新は受けられない。

フィードバックの送り方

フィードバックの送り方

問題を発見した場合や提案がある場合は、GitHubのWoo Themesリポジトリでissueを開く。その際、WordPress、WooCommerce、PHP、Purpleの各バージョン、テストしていたテンプレートまたはブロック、問題の再現手順を含める。視覚的な問題ならスクリーンショットや録画も添付する。

フィードバックはデフォルトのWooCommerceストアフロントの改善と、すべてのブロックテーマで利用できるブロックとテンプレートの改善に直結する。ベータテストへの参加は、WooCommerceのブロックエコシステム全体を育てる貢献になる。

この記事のポイント

  • PurpleはWooCommerce初の公式ブロックテーマで、ベータテストが始まった
  • テンプレート一式、10種類のカラーパレットとフォント組み合わせ、EC向けパターンライブラリを備える
  • WooCommerce 11.0から11.2にかけて、ブロック改善とパフォーマンス最適化がコアに加わった
  • テストはステージング環境またはローカルサイトで行い、各ブロックとテンプレートを確認する
  • フィードバックはGitHubのissueで受け付けている
WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5(2027年1月目標)から、最低動作環境がPHP 8.1以上になる提案が発表された。この変更が採用されると、PHP 7.4とPHP 8.0のサポートは将来のバージョンで終了する。

WooCommerceの利用データでは、PHP 7.4が追跡対象ストアの約7%、PHP 8.0が約2%を占めている。比較的新しいWooCommerceバージョンに限ると合計約6%まで下がり、減少傾向が続いている。

ストア運営者や拡張機能開発者は、移行の影響を早めに把握して準備を進める必要がある。本記事では提案の内容、影響範囲、推奨される対応をまとめた。

WooCommerce 11.5からPHP 8.1以上が最低要件に

WooCommerce 11.5からPHP 8.1以上が最低要件に
従来のWooCommerce(Before)
PHP 7.4 または PHP 8.0 で動作
WooCommerce 11.4 以前の最低要件
↓
WooCommerce 11.5以降(After)
PHP 8.1 以上が最低要件
PHP 7.4 と 8.0 のサポート終了

上の図のように、WooCommerce 11.5を境に最低PHPバージョンが引き上げられる。PHP 7.4と8.0を使うストアは、設定変更なしでは新しいバージョンへ更新できなくなる。

PHPサポート終了の現状

PHP 7.4は2022年11月に、PHP 8.0は2023年11月に公式サポートが終了している。以降はセキュリティ修正が提供されていないため、脆弱性が見つかっても修正されない状態が続く。

WooCommerceの内部データによると、追跡対象ストア全体ではPHP 7.4が約7%、PHP 8.0が約2%を占める。一方、直近1年以内にリリースされた比較的新しいWooCommerceバージョンでは合計約6%まで縮小している。

提案の具体的内容

WooCommerceエンジニアリングチームは、WooCommerce 11.5のリリースを目標に最低要件をPHP 8.1以上へ引き上げることを提案している。採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。

この変更により、WooCommerce 11.5以降はPHP 7.4と8.0向けの互換コードを削除できる。コードベースの保守性が高まり、開発スピードの向上につながると見込まれている。

PHPバージョン引き上げのメリット

PHPバージョン引き上げのメリット
最新構文 union types
match式
名前付き引数
セキュリティ EOL回避
安全な依存パッケージ
開発効率 CIテスト高速化
互換性コード削減
性能向上 PHP 8系の
ランタイム改善
■ 最新構文 ■ セキュリティ ■ 開発効率 ■ 性能向上

PHP 8.1以上への引き上げで得られる主な利点は4つ。最新構文の活用、セキュリティ向上、開発効率の改善、そしてランタイム性能の向上だ。

最新PHP機能の活用

PHP 8.1以上では、union types(複数の型を許容する宣言)、attributes(メタデータを付与する仕組み)、null-safe operator(null判定を簡潔に書く演算子)、match式、名前付き引数などが使えるようになる。WooCommerce本体だけでなくサードパーティ製の拡張機能も、これらの機能を前提に開発できる。

union typesとは、関数の引数や戻り値に「intまたはstring」のように複数の型を指定できる記法だ。これがあると、無理な型変換や冗長な分岐を減らせる。コードが読みやすくなり、バグの発生も抑えられる。

セキュリティとパフォーマンスの向上

サポート終了済みのPHPを使い続けると、既知の脆弱性が修正されないまま残る。PHP 8.1以上へ移行することで、セキュリティ修正が提供される安心な環境に切り替えられる。

さらに、WooCommerceと拡張機能が新しいPHP専用の安全な依存パッケージを採用できるようになる。旧バージョン向けの互換レイヤーを削除でき、継続的インテグレーション(CI)でテストするPHPバージョンも減るため、テストやリリースの速度も上がる。

PHP 8系へのアップグレード自体にも性能向上の効果がある。PHPランタイムの改善により、WooCommerceストアの表示速度や処理能力が底上げされる。これはコード変更なしで得られる利点だ。

PHP 7.4・8.0を使うストアへの影響

PHP 7.4・8.0を使うストアへの影響
PHP 7.4・8.0 のストア(Before)
WooCommerce 11.5 の更新が提供されない
既存バージョンのドットリリースのみ継続
↓
PHP 8.1 以上へ移行後(After)
WooCommerce 11.5 以降を更新可能
PHPアップグレード後に更新

PHP 7.4や8.0を使っていても、WooCommerceが自動でPHPを更新したり、ストアを停止させたりすることはない。ただし、WooCommerce 11.5以降への更新だけはブロックされる。

自動更新の停止と移行手順

提案が採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。WordPressの標準機能により、要件を満たさないストアにはWooCommerce 11.5の更新が表示されなくなる。

PHP 7.4または8.0を使うストアは、現在のWooCommerceバージョンをそのまま使い続けることになる。同じブランチのドットリリース(例 11.4.x)は引き続き提供される。新しいメジャーバージョンへ移るには、先にPHPを8.1以上へアップグレードする必要がある。

前例となったWooCommerce 8.2

今回の進め方は過去のWooCommerceのPHP要件変更と同様のアプローチを取っている。WooCommerce 8.2では最低要件をPHP 7.4以上へ引き上げ、事前通知と移行ガイダンスが提供された。

当時も、要件を満たさないストアは自動更新されず、既存バージョンの更新のみ継続する方式だった。今回のPHP 8.1引き上げでも同じ流れが想定されている。

WordPressと拡張機能開発者への影響

WordPressと拡張機能開発者への影響

WordPressのPHP要件との違い

WordPress本体は現在、PHP 7.4以上で動作し、PHP 8.3以上を推奨している。しかしWooCommerceは、WordPressより高いPHP要件を維持してきた経緯がある。

WooCommerceは決済処理や在庫管理、注文ワークフローなどを持つ複雑なECアプリケーションだ。独自の依存関係や性能要件があるため、最低PHPバージョンをWordPressと完全に一致させる必要はないとされている。

拡張機能開発者への推奨事項

WooCommerce向けの拡張機能を開発している場合、すでに新しいPHPバージョンでテストしていることが理想だ。今回の変更により、WooCommerce 11.5以降だけを対象にする拡張機能はPHP 8.1以上の機能を使えるようになる。

一方、古いWooCommerceバージョンを引き続きサポートする拡張機能は、互換レイヤーや別コードパスを維持する必要が出てくる。PHPバージョンが上がっても、すべての拡張機能やテーマ、カスタムスニペットがそのまま動く保証はない。

本番環境へ適用する前に、ステージングサイトでPHP 8.1以上への移行テストを行うことが重要だ。特に独自カスタマイズや古い拡張機能を使っている場合、互換性の問題が顕在化しやすい。

意見募集と今後のスケジュール

意見募集と今後のスケジュール

フィードバックの募集ポイント

WooCommerceエンジニアリングチームは、ストア運営者、代理店、ホスティングプロバイダー、拡張機能開発者などから幅広く意見を求めている。主な質問は以下の通りだ。

  • PHP 7.4や8.0から移行できない理由はあるか
  • 該当PHPバージョンを必要とする拡張機能やテーマは存在するか
  • WooCommerce 11.5(2027年1月目標)で準備期間は十分か
  • ホスティングプロバイダーはWooCommerceストアのPHP利用状況について追加データを持っているか
  • 対応が望まれる移行ガイダンスは何か

互換性の問題を報告する場合は、PHPバージョン、WooCommerceバージョン、影響を受ける拡張機能、エラーメッセージを添えることが推奨されている。

決定までのタイムライン

WooCommerceチームはフィードバックと利用データを確認した上で、対象リリースと最低PHPバージョンを最終決定する。決定後は事前告知を行い、開発者が新しい要件でテストできるよう準備期間を設ける方針だ。

現時点ではまだ提案段階であり、正式な決定ではない。ただし利用データの減少傾向やEOLの状況を踏まえると、PHP 8.1以上への引き上げは現実的な選択肢として有力だ。

この記事のポイント

  • WooCommerce 11.5(2027年1月目標)からPHP 8.1以上が最低要件になる提案が発表された
  • PHP 7.4と8.0はサポート終了済みで、利用は全体の約6〜9%まで縮小している
  • PHP 7.4・8.0のストアは自動更新されず、移行後にWooCommerce 11.5へ更新できる
  • 最新PHP機能の活用、セキュリティ向上、開発効率の改善が主な目的だ
  • 拡張機能開発者はステージング環境でPHP 8.1以上へのテストを推奨
WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのコードベースで長年使われてきた「マジックストリング」が、人知れず問題を引き起こしていた。注文ステータス、商品タイプ、在庫状態、税金モード。これらの重要な値が、コード中で生の文字列として比較されていたのだ。タイプミス一つでバグになり、プレフィックスの有無で混乱し、コード検索でノイズが大量に混ざる。開発者にとって頭の痛い状況だった。

WooCommerceはこの問題に対処するため、Automattic\WooCommerce\Enumsという名前空間にエナムクラス群を導入した。注文ステータスや商品タイプを表す名前付き定数をパブリックAPIとして公開し、拡張機能開発者に採用を促している。本記事では、この変更の背景、利用可能なクラス、実際の導入方法を整理する。

マジックストリングがもたらす4つの問題

マジックストリングがもたらす4つの問題

WooCommerceは歴史が長い。そのため、注文ステータスや商品タイプといった重要な値が、PHPの近代的な慣習が生まれる前から存在している。コードベースの各所で、次のような生の文字列比較が行われてきた。

if ( 'completed' === $order->get_status() ) {
    // タイプミスがないことを祈るしかない
}

この書き方は一見シンプルに見えるが、WooCommerceのような大規模なコードベースでは深刻な代償を伴う。Developer WooCommerce Blogの記事では、その問題を4つの観点から説明している。

沈黙のエラー

文字列リテラルの最大のリスクは、タイプミスが静かに潜むことだ。'complete'と書くべきところを'completed'と書いても、リンターもオートローダーもテストもエラーを検出しない場合がある。コードは実行時に黙って失敗し、デバッグに時間を奪われる。

プレフィックスの有無による混乱

WordPressのデータベースでは、注文ステータスにwc-というプレフィックスが付く。データベースにはwc-completedとして保存されるが、WooCommerceの多くのAPIはプレフィックスなしのcompletedを期待する。この違いは、開発者が実際にコードを動かして初めて気づく類の落とし穴だ。

検索の非効率さとドキュメントの分散

エージェントやコード検索で'simple'という文字列を探すと、商品タイプのロジックを探しているのに無関係な箇所が大量にヒットする。一方、ProductType::SIMPLEのように名前付き定数で検索すれば、該当箇所を正確に絞り込める。さらに、on-holdのようなステータスの定義は、宣言箇所のdocblockにドキュメントとして残せるようになる。

マジックストリングの問題点(Before)
タイプミス検出困難 → 実行時まで気づけない
プレフィックス混乱 → wc-completed と completed の区別が曖昧
検索ノイズ → simple で検索すると無関係な箇所が大量ヒット
ドキュメント分散 → 値の意味がコード中に散在
↓
エナムクラス導入後(After)
名前付き定数 → タイプミスをコンパイル時に検出
意図の明確化 → OrderStatus::COMPLETED と OrderInternalStatus::COMPLETED を区別
検索精度向上 → ProductType::SIMPLE で該当箇所を正確に絞り込み
ドキュメント統合 → docblockに意味を記載

この比較で示したように、エナムクラスは文字列リテラルが抱える問題を構造的に解決する。特に、プレフィックス有無の違いを別々のクラスに分けることで、意図を明確に伝えられる点が重要だ。

ネイティブPHPエナムを採用しなかった理由

ネイティブPHPエナムを採用しなかった理由

PHPにはバージョン8.1からネイティブのエナム型が導入されている。しかしWooCommerceはこの選択肢を取らなかった。主に2つの理由がある。

PHP 7.4のサポート

WooCommerceの最低サポートPHPバージョンは7.4だ。このバージョンにはネイティブエナムが存在しない。PHP 8.1を前提にすると、多くのユーザーを切り捨てることになる。クラス定数として文字列を定義する方式なら、PHP 7.4でも問題なく動作する。

文字列互換性という設計判断

もう一つの理由はアーキテクチャ上の判断だ。注文ステータスや商品タイプの値は、すでに数百万のデータベースにプレーンな文字列として保存されている。数千の拡張機能もその形式を前提にしている。ネイティブPHPエナムを使うと値がオブジェクトに変換され、既存のコードが壊れる可能性がある。

文字列定数を使う方式なら、OrderStatus::COMPLETEDは従来の'completed'と同じ文字列を生成する。開発者はより明確な名前を使いつつ、WooCommerceの動作を変えない。既存コードが動き続け、拡張機能は準備ができた時点で新しい定数に移行できる。

final class OrderStatus {
    /**
     * 注文が完了した状態
     */
    public const COMPLETED = 'completed';
    // ...
}

このコードが示すように、エナムクラスはfinalで宣言され、public constとして定数を公開する。docblockで各定数の意味をドキュメント化できるのが利点だ。クラスを継承させないことで、APIの一貫性を保つ。

利用可能なエナムクラス

利用可能なエナムクラス

現在WooCommerceのsrc/Enumsディレクトリには、4つのカテゴリにまたがるエナムクラスが用意されている。各クラスの一覧を確認しよう。

注文と商品のエナム

  • OrderStatus(プレフィックスなしの値。例としてcompleted)
  • OrderInternalStatus(データベースに保存されるwc-プレフィックス付きの値)
  • OrderItemType(注文アイテムのタイプ)
  • ProductType(商品タイプ。例としてsimple)
  • ProductStatus(商品ステータス)
  • ProductStockStatus(在庫状態)
  • ProductTaxStatus(税金状態)
  • CatalogVisibility(カタログの表示設定)

支払いと設定値のエナム

  • PaymentGatewayFeature(ゲートウェイがsupports配列で宣言する文字列)
  • WeightUnit(重量単位)
  • DimensionUnit(寸法単位)
  • CurrencyPosition(通貨位置)
  • TaxBasedOn(課税基準)
  • TaxDisplayMode(税表示モード)
  • DefaultCustomerAddress(デフォルト顧客住所)
  • StockDisplayFormat(在庫表示形式)
  • CatalogSortOrder(カタログ並び順)

各クラスの完全な一覧は、WooCommerceのGitHubリポジトリにあるsrc/EnumsディレクトリとREADMEで確認できる。このディレクトリが権威ある情報源として公開されている。

注文関連 OrderStatus / OrderInternalStatus / OrderItemType
商品関連 ProductType / ProductStatus / ProductStockStatus 他
支払い関連 PaymentGatewayFeature
設定値関連 WeightUnit / DimensionUnit / CurrencyPosition 他

以上の4カテゴリが、現在WooCommerceで利用可能なエナムクラスの全体像だ。注文関連と商品関連が特に充実している。

拡張機能での採用方法

拡張機能での採用方法

エナムクラスは公的に発見可能なAPIとして設計されており、publicの可視性、docblock、開発者向けドキュメントを備えている。拡張機能開発者は安心して利用できる。

基本的な使い方

使い方はシンプルだ。use文で必要なクラスをインポートし、定数を参照する。例えば注文ステータスをチェックする場合、次のように書ける。

use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;

if ( OrderStatus::COMPLETED === $order->get_status() ) {
    // 注文が完了した場合の処理
}

$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );

採用前に確認すべき2つのポイント

エナムクラスを拡張機能に導入する前に、確認しておくべきことが2つある。

1. 最小サポートWooCommerceバージョン。エナムクラスは段階的に追加されてきた。OrderStatusはWooCommerce 9.5で導入され、商品関連クラスは9.7〜9.8頃、設定値クラスは10.xシリーズで追加された。古いバージョンもサポートする場合は、文字列リテラルを使い続けるか、class_exists()でガードする必要がある。

2. WooCommerceが期待する文字列。OrderStatus::COMPLETEDはcompletedを返すが、OrderInternalStatus::COMPLETEDはwc-completedを返す。ほとんどのWooCommerce関数はプレフィックスなしの形式を取るが、データベースレベルやpost_statusコンテキストではプレフィックス付きを使う必要がある。どちらの形式を使うべきかを意識するのが重要だ。

商品検索と注文検索の公式ドキュメントには、文字列リテラルとエナムクラスの両方の形式が併記されている。移行時の参考になる。

プレフィックスなし(API用)
OrderStatus::COMPLETED → completed を返す
使用場面 → wc_get_orders() などの API
↓
プレフィックスあり(DB用)
OrderInternalStatus::COMPLETED → wc-completed を返す
使用場面 → post_status やデータベース操作

このデモで示したように、2つの定数は同じ注文完了状態を表すが、使用するコンテキストが異なる。混同すると期待通りに動作しない。

今後の展開

今後の展開

Developer WooCommerce Blogの記事によれば、コアに新しい語彙(文字列値の集合)を追加する場合、エナムクラスをデフォルトで付ける方針が示されている。WooCommerceコアにはまだ名前の付いていない文字列値が多数残っており、コミュニティからの貢献も歓迎している。

この変更は拡張機能開発者にとって歓迎すべき動きだ。タイプミスのリスクが減り、コードの意図が読みやすくなり、IDEの補完機能も効きやすくなる。長期的にはWooCommerceエコシステム全体のコード品質向上につながる。

一方で、移行には段階的な対応が必要だ。既存の拡張機能は古いWooCommerceバージョンとの互換性を維持しながら、徐々にエナムクラスへ移行していくことになる。一括で全置換するのではなく、新規コードから採用していくのが現実的なアプローチだろう。

この記事のポイント

  • WooCommerceがマジックストリング(生の文字列リテラル)をエナムクラスに置き換える動きを進めている
  • エナムクラスはタイプミス防止、プレフィックス区別、検索精度向上、ドキュメント統合の4つの利点を持つ
  • ネイティブPHPエナムではなく文字列定数クラスを採用した理由は、PHP 7.4互換性と既存データベースの文字列互換性
  • 注文・商品・支払い・設定値の4カテゴリにエナムクラスが用意されている
  • 採用時は最小サポートWooCommerceバージョンと、プレフィックス有無のどちらの定数を使うかを確認する
WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0が2026年9月1日にリリースされた。今回のアップデートでは商品バリエーション画像ギャラリーが標準機能となり、専用プラグインが不要になった。Store APIとREST APIの応答速度も最大42%改善している。

今回のリリースは後方互換性を保っており、データベース更新を伴う。561件のプルリクエストがマージされ、77人のコントリビューターが参加した。WooCommerceを運用しているECサイトでは更新前に変更点を把握しておきたい。

この記事ではWooCommerce 11.1.0の主要な変更点を、店舗運営者向けと開発者向けに分けて解説する。更新作業の前に確認すべき注意点もまとめた。

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0では店舗運営者に直接影響する機能追加と、開発者向けの内部改善が同時に行われた。本番サイトへの適用前には公式の更新ガイドとチェンジログを確認することが推奨されている。

店舗運営者に影響する変更は3つある。1つ目は商品バリエーション画像ギャラリーの標準搭載、2つ目はEU顧客向け注文撤回フォームの追加、3つ目は仮想商品の管理画面表示の改善だ。これに加えて商品ギャラリーへの動画対応がベータ機能として導入された。

開発者向けにはブロックエディタアセットの統合、ブロック登録処理の最適化、注文アイテム削除ロジックの修正などが含まれる。特にStore APIとREST APIの応答速度は30%から42%改善しており、ヘッドレス構成や外部連携を運用している場合に効果が大きい。

WooCommerce 11.1.0の変更分類
店舗運営者向け バリエーション画像ギャラリーの標準化
店舗運営者向け EU顧客向け注文撤回フォームの追加
パフォーマンス Store APIとREST APIを最大42%高速化
ベータ機能 商品ギャラリーへの動画対応
■ 店舗運営者向け ■ パフォーマンス改善 ■ ベータ機能

上記デモはWooCommerce 11.1.0の変更点を影響範囲ごとに分類したものだ。青と緑が店舗運営者向け、オレンジがパフォーマンス改善、紫が実験的ベータ機能に該当する。

商品バリエーション画像ギャラリーが標準機能に

商品バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0で、商品バリエーションごとに複数の画像を持たせる「バリエーション画像ギャラリー」が全ストアで標準機能として有効化された。これまでこの機能は「WooCommerce Additional Variation Images」という別プラグインで提供されていたが、今回のリリースをもって公式の専用プラグインは提供終了となる。

バリエーション画像ギャラリーとは、商品のサイズやカラーといったバリエーションごとに、複数の商品写真や画像を登録できる仕組みだ。たとえばサイズ違いのTシャツ商品で、MサイズにはMサイズの着用写真を複数枚登録し、LサイズにはLサイズの写真を複数枚登録できる。購入希望者が自分に合ったサイズの写真だけを確認できるため、購入決定の精度が上がる。

今回の標準化では設定画面の実験的機能フラグが削除された。データベース更新(11.1.0-1)により、過去に実験的フラグをオフにしていたストアでも自動的に有効化される。個別に切り替える必要はなく、WooCommerceを11.1.0に更新すれば全ストアで利用できる。

11.1.0以前(Before)
追加プラグイン 必須 → プラグイン終了予定
バリエーション画像ギャラリーを利用するには専用プラグインの導入が必要だった。設定も個別のプラグイン管理画面から行う必要がある。
↓
11.1.0以降(After)
WooCommerce標準機能 追加費用なし → 全ストアで自動有効化
WooCommerce 11.1.0に更新するだけで全ストアで利用できる。実験的フラグは削除され、データベース更新で自動的に有効化される。

専用プラグインが不要になり、バリエーション画像ギャラリーはWooCommerceの標準仕様となった。既存の専用プラグインユーザーも移行作業なしでそのまま利用できる。

Store APIとREST APIのパフォーマンス改善

Store APIとREST APIのパフォーマンス改善

WooCommerce 11.1.0ではStore APIとREST APIの応答速度が大幅に改善された。ブロックタイプとパターンの登録処理が、ブロックを描画できないリクエストではスキップされるようになったことが主な要因だ。

Store APIとは、WooCommerceの商品データや注文データを外部から利用するためのAPIだ。ヘッドレス構成でフロントエンドとWooCommerceを接続する場合や、モバイルアプリから商品情報を取得する場合に使われる。REST APIも同様に外部連携の窓口となる。

今回の変更により、ブロックタイプ(block types)とパターン(patterns)の登録が、ブロックを描画・編集できないリクエストでは実行されなくなった。これまではAPIリクエストでも無駄にブロック関連の処理が走っていたため、応答時間が長くなっていた。変更後はStore APIとRESTリクエストの速度が30%から42%向上した。

11.1.0以前のAPIリクエスト(Before)
APIリクエスト → ブロック登録処理 → 無駄に実行
ブロックを描画できないAPIリクエストでも、ブロックタイプとパターンの登録処理が実行されていた。これが応答時間を長くする要因になっていた。
↓
11.1.0以降のAPIリクエスト(After)
APIリクエスト → ブロック登録をスキップ → 30〜42%高速化
ブロックを描画・編集できないリクエストでは登録処理がスキップされる。Store APIとREST APIの応答速度が最大42%改善した。

このデモはAPIリクエスト時の処理フロー変化を示している。ブロック登録の最適化は店内回遊の速度向上ではなく、外部連携やヘッドレス構成での応答性能に直接効く変更だ。

EU顧客向け注文撤回フォームの追加

EU顧客向け注文撤回フォームの追加

WooCommerce 11.1.0ではEU圏の規制に準拠するための「注文撤回フォーム」が追加された。デフォルトでは無効になっており、EUガイドラインへの準拠が必要なストアが手動で有効化する形だ。

注文撤回とはEUの消費者保護規則に基づく権利で、消費者が商品を受け取ってから一定期間内に購入をキャンセルできる仕組みだ。ストア側はこの権利に応じた返金・返品プロセスを用意する必要がある。今回追加されたフォームは、その撤回申請を顧客自身がオンラインで提出するための画面をマイアカウントページに作成する。

撤回申請が提出されるとシステムに記録され、ストア運営者にはメール通知と管理画面のダッシュボード通知が送られる。ただし実際の注文撤回処理と返金作業は手動で行う必要がある。各ストアのポリシーや商品特性によって処理手順が異なるためだ。

STEP 1 顧客がマイアカウントページで注文撤回フォームを開く
↓
STEP 2 顧客が注文撤回リクエストをオンラインで提出
↓
STEP 3 システムに記録され運営者へメールとダッシュボードで通知
↓
STEP 4 運営者が返金・返品処理を手動で実行

注文撤回フォームはデフォルト無効のため、通常の国内向けストアでは追加設定は不要だ。EU向け販売を行うストアはWooCommerceの設定画面から有効化できる。

商品ギャラリーの動画対応と仮想商品の表示改善

商品ギャラリーの動画対応と仮想商品の表示改善

WooCommerce 11.1.0では商品ギャラリーへの動画対応がベータ機能として追加された。クラシックテーマとブロックテーマの両方の商品ギャラリーで動画を表示できる。

初期リリースではローカルにアップロードした動画のみが対応する。外部ホスティングの動画URL(YouTubeやVimeoなど)は現時点ではサポートされていない。実験的機能のため、今後のリリースで仕様が変更される可能性がある。

この機能はデフォルトでは無効になっている。有効化するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、「商品ギャラリー動画」をオンにする必要がある。商品の見せ方を動画で強化したいストアはテスト環境での検証を推奨する。

仮想商品の管理画面表示が整理された

発送処理が不要な仮想商品のみの注文では、管理画面の注文サマリーに配送先住所が表示されないようになった。これまでStore APIのチェックアウト処理が互換性維持のために請求先住所から配送先住所を生成していたため、仮想商品のみの注文でも意味のない住所が表示されていた。

この変更により、仮想商品のみの注文画面がすっきりと整理される。実際の住所データが削除されるわけではなく、表示されなくなるだけだ。物理商品を含む注文や、配送情報が未確定の注文では従来どおり住所が表示される。

開発者向けの変更点

開発者向けの変更点

WooCommerce 11.1.0には複数の開発者向け変更が含まれる。ブロックエディタアセットの統合、注文アイテム削除ロジックの修正、WooCommerce Adminの安定済みフィーチャーフラグ廃止などだ。

統合ブロックエディタアセット(実験的)

実験的な新機能として、ブロックエディタ向けのJavaScriptとCSSファイルが統合された。これまでWooCommerceのブロックはそれぞれ個別のスクリプトとスタイルを読み込んでいたが、共有バンドルにまとめることでエディタ画面でのリクエスト数と総サイズが削減される。

デフォルトでは無効になっており、11.1.0では影響が出ない。有効化した場合もフロントエンド側のアセットは変更されず、既存のブロックハンドルは従来どおり動作する。管理画面の編集速度を改善したいストアは検討の余地がある。

注文アイテム削除ロジックの修正

WooCommerceの注文アイテム削除処理に含まれていた潜在的なバグが修正された。更新前は、拡張プラグインが注文保存前に差し込んだ置換用アイテムが、削除処理によって誤って消される可能性があった。

具体的にはWC_Abstract_Orderクラスのremove_order_itemsメソッドが、削除要求時に存在していたアイテムIDを記録するようになった。これにより拡張プラグインが追加したアイテムが誤って削除されるのを防ぐ。9割以上の拡張プラグインではコード変更は不要だが、カスタム注文データストアを実装している場合はget_item_idsとdelete_items_by_idsの実装を確認する必要がある。

安定済みフィーチャーフラグの廃止

WooCommerce Adminの安定機能として採用済みのフィーチャーフラグの一部が、設定パイプラインを介さず直接読み込まれるようになった。機能自体は削除されておらず、互換性維持のための互換レイヤーも残されている。

互換レイヤーはFeatures::is_enabled()とwindow.wcAdminFeaturesに対して従来の値を返し続けるが、非推奨警告を出力するようになった。自作の拡張プラグインでフィーチャーフラグに依存している場合は、互換レイヤーが撤去される前に対応を進めておきたい。

この記事のポイント

  • バリエーション画像ギャラリーがWooCommerce標準機能として全ストアで有効化された
  • 専用プラグイン「WooCommerce Additional Variation Images」は提供終了となる
  • Store APIとREST APIの応答速度が最大42%向上した
  • EU顧客向け注文撤回フォームが追加された(デフォルトでは無効)
  • 商品ギャラリーの動画対応はベータ機能としてデフォルト無効で提供される
  • 仮想商品のみの注文では管理画面に配送先住所が表示されなくなった
WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方

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チェックアウトでVAT任意欄が空だと無効エラーになる不具合の修正方法

WooCommerceチェックアウトでVAT任意欄が空だと無効エラーになる不具合の修正方法

WooCommerce のチェックアウトで VAT 番号のフィールドが任意設定なのに、空のまま進むと「VAT が無効」と表示されて注文が完了しない場合は、使用している VAT 関連プラグインのアップデートに不具合が混入している。最新バージョンへ更新すれば多くのケースで直り、どうしても更新が難しいなら前のバージョンに戻すことでチェックアウトを復旧できる。

なぜ VAT 任意項目が空でエラーになるのか

なぜ VAT 任意項目が空でエラーになるのか

WooCommerce の標準機能に VAT 番号のバリデーション(入力値の検証)は含まれていない。チェックアウト画面に VAT フィールドを追加し、「無効な VAT」「VAT が無効」といったエラーチェックを行っているのは、EU VAT Number 系の拡張プラグインだ。こうしたプラグインでは管理画面から VAT フィールドを必須にするか、任意にするかを切り替えられるが、特定のバージョン(報告では 4.7.6)で、空欄を「無効な VAT」と誤判定する不具合が発生した。設定上は任意でも、チェックアウト処理時に空の値を無効と見なしてエラーを返すため、購入完了まで進めなくなる。

この現象はプラグイン開発者側の不具合であり、サイト側の設定ミスではない。同様の症状が出た場合、まずはプラグインが最新の安定版かどうかを確認するのが最も確実な対処になる。

プラグインの最新バージョンに更新する

プラグインの最新バージョンに更新する
STEP 1 サイト全体のバックアップを取得する
↓
STEP 2 プラグイン一覧で対象プラグインの更新通知を確認する
↓
STEP 3 更新を実行し、変更を反映させる
↓
STEP 4 キャッシュをクリアし、チェックアウトが正常に動作するかテストする

上の手順デモは、不具合が修正されたバージョンへ更新する際の流れを示している。実際の管理画面では、VAT 関連プラグインの名前(例 EU VAT Number for WooCommerce 等)を特定し、更新可能なバージョンが表示されていれば「今すぐ更新」をクリックするだけだ。

本件のフォーラム報告例では、バージョン 4.7.6 で問題が発生し、4.7.8 で修正された。同様のケースでは、開発元が既に不具合を認識して修正版をリリースしていることが多い。更新後も症状が続く場合は、プラグインの設定画面で VAT フィールドの「必須」オプションが誤ってオンになっていないか再確認する。

更新できない場合の緊急回避策

更新できない場合の緊急回避策

何らかの理由ですぐにプラグインを最新版にできない場合、一時的にチェックアウトの支障を取り除く方法として、プラグインを前の安定バージョンに戻す方法がある。プラグインの提供ページから過去のバージョンをダウンロードし、手動で上書きアップロードすれば、VAT フィールドが空でもエラーにならなかった状態に戻せる。

Before 不具合発生中
VAT 任意なのに空欄で「VAT が無効」とエラー表示
↓
After 前バージョンに戻す
VAT 空欄のままチェックアウトが正常に完了する
■ エラー状態 ■ 復旧後

プラグインファイルを手動で置き換える際は、必ず FTP やサーバーのファイルマネージャーでアクセスするか、WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP ファイルでインストールする。作業前に必ずバックアップを取っておく。

もうひとつの緊急手段として、チェックアウト画面から VAT フィールドを一時的に非表示にする方法もある。子テーマの functions.php にフィルターを追加してフィールドを除去すれば、バリデーション自体が行われなくなる。ただしこれは購入者から VAT 番号を取得できなくなるため、後日プラグインが修正されたら元に戻す必要がある。

根本原因を特定して再発を防ぐ

根本原因を特定して再発を防ぐ

プラグインの自動更新を有効にしていると、気づかないうちに不具合を含むバージョンが適用されてしまうことがある。VAT のような決済に直結するフィールドでトラブルが起きると、数時間の売上損失につながる可能性が高い。そのため、VAT 系プラグインや決済関連プラグインについては、本番環境へ適用する前にステージング環境で動作確認を行うか、少なくとも更新直後に手動でチェックアウトを通すテストを習慣化する。

また、プラグインの更新履歴(Changelog)に目を通し、「fix」「bug」「checkout」といったキーワードの修正が含まれているかどうかを更新前に確認しておくと、問題の発生にすぐ気づける。

よくある質問

どのプラグインが原因かを特定できない時はどうすればよいか

チェックアウト画面に VAT 関連の項目を追加しているプラグインをすべて疑う。プラグイン一覧で「VAT」「EU」「Tax」などで検索し、該当するプラグインをひとつずつ停止して、チェックアウトの動作を確認する。問題のプラグインが特定できたら、そのプラグインのサポートフォーラムで同様の報告がないか調べる。

VAT フィールドを必須に変更すれば一時的に回避できるのか

フィールドを必須にすると、常に VAT 番号の入力を求められるため、空欄によるエラーは発生しなくなる。しかし日本国内の顧客向けに VAT 不要のサイトでは、必須設定は購入体験を損ねる。商品やターゲットに応じて慎重に判断する必要がある。

コードを一切触らずにエラー表示だけ消す方法はあるか

管理画面の設定から VAT フィールドを無効化するか、チェックアウトのフィールド編集機能を持つプラグインで該当フィールドを削除する。ただし、これらの操作もバックアップを取ってから実行し、注文情報に必要なデータが欠落しないように注意する。

更新後もエラーが解消されない場合の次の手は

まずキャッシュ系プラグインや CDN が古いスクリプトを配信していないか確認する。次に、VAT プラグイン以外のチェックアウト関連プラグインとの競合を疑い、すべてのプラグインを一時停止しながら原因を切り分ける。それでも解決しない場合はプラグイン開発元に直接報告する。

この記事のポイント

  • 任意設定の VAT フィールドが空でエラーになるのはプラグインの不具合
  • 最新バージョンへの更新で修正されるケースが大半
  • 更新できない時は前の安定バージョンに戻すかフィールドを一時非表示にする
  • 決済関連プラグインはステージングテストと更新履歴確認を習慣化する
クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法

クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法

Googleがクロールインフラストラクチャの公式ドキュメントを更新し、「クロールバジェットの最適化」に関する新たなガイドラインを公開した。ECサイト運営者にとって、この変更は商品ページのインデックス速度に直結する。クロールされなければ検索結果に表示されないからだ。

今回の更新で注目すべきは、新サイトに割り当てられる「保守的なクロールバジェット」の考え方と、304ステータスコードに関する注意喚起だ。特に304の扱いは、安易に導入すると検索順位に影響を与える可能性がある。

この記事では、Googleの新ガイドラインの要点と、ECサイトが実践すべきクロールバジェット最適化の手法を解説する。

クロールバジェットとは何か

クロールバジェットとは何か

クロールバジェットとは、Googlebotが一定期間内に特定のサイトをクロールするURLの総量を指す。インターネット上のURL数は膨大であり、Googleは各サイトに割り当てるクロール量を最適化する必要がある。この割り当てが「バジェット(予算)」と呼ばれる理由だ。

サイト構造が整理されておらず、無駄なURLが多いサイトは、クロールに時間がかかり、結果としてインデックスされるページ数が少なくなる。ECサイトの場合、商品ページがインデックスされなければ、検索経由の流入機会を失うことになる。

クロールバジェットが無駄に使われるサイト
Googlebot → 重複ページ → ソフト404 → 無駄なパラメータURL
※クロールの大半が無駄なURLに消費され、重要な商品ページまで到達できない
■ Googlebotが無駄なURLを巡回
↓
クロールバジェットが最適化されたサイト
Googlebot → 新着商品ページ → 更新されたカテゴリ → ブログ記事
※無駄なURLが除外され、重要なページだけがクロールされる
■ 重要なページを効率的に巡回

クロールバジェットを意識したサイト設計は、検索エンジンに「このサイトは効率的にクロールできる」と認識させる第一歩だ。以下、Googleの新ガイドラインに沿った具体的な施策を見ていく。

新サイトには保守的なクロールバジェットが割り当てられる

新サイトには保守的なクロールバジェットが割り当てられる

Googleの更新されたドキュメントで明確にされたのが、新規サイトに対するクロールバジェットの初期値だ。新サイトには「保守的な」バジェットが割り当てられ、サーバーに過負荷をかけずに重要なコンテンツをカバーできるよう設計されている。

段階的なコンテンツ公開が鍵

新サイトを立ち上げる際は、一度に大量のページを公開するよりも、徐々にページ数を増やす方がGooglebotの信頼を得やすい。たとえば、100商品を1日で公開するより、1日3商品ずつ約1ヶ月かけて公開する方が、クロールバジェットの観点からは有効だ。

STEP 1 新サイト公開(少数の重要ページのみ)
Googlebotがサーバー負荷を確認しながら巡回開始
↓
STEP 2 1日数商品ずつ追加公開
XMLサイトマップを更新し、Googleに変更を通知
↓
STEP 3 定期的な更新を継続
Googlebotの巡回頻度が徐々に増加
↓
STEP 4 クロールバジェットの拡大
信頼が確立され、より多くのページが巡回対象に

この段階的アプローチにより、Googlebotはサイトの更新パターンを学習し、クロールバジェットを徐々に拡大していく。XMLサイトマップの自動更新と組み合わせることで、さらに効果が高まる。

表示速度の改善がバジェットを増やす

サイトの読み込み速度が速いほど、Googlebotは効率的にクロールできる。これは以前から知られていた事実だが、今回のガイドラインでも改めて強調された。表示速度の改善は、ユーザー体験の向上だけでなく、クロールバジェットの増加にも直結する。

Googleが提供するPageSpeed InsightsやLighthouseを使って定期的にパフォーマンスを測定し、改善を続けることが重要だ。ECサイトでは、画像の最適化や不要なスクリプトの削減が特に効果的だ。

人気ページはクロール頻度が高まる

外部リンクや内部リンクを多く集めているページは、Googlebotの巡回頻度が高くなる。ECサイトの場合、トップページや主要カテゴリページ、よく参照される商品ページが該当する。内部リンク構造を最適化し、重要なページへリンクを集中させることで、クロール頻度を向上させられる。

クロール効率を下げる要因とその対策

クロール効率を下げる要因とその対策

クロールバジェットを浪費する要因はいくつかある。以下に主要なものと対策を示す。

robots.txtで不要ページをブロック

プライベートログインページ、ショッピングカート、動的に生成されるページなど、インデックス不要なページはrobots.txtのdisallowディレクティブでブロックする。これにより、Googlebotが本当に重要なページだけを巡回するよう誘導できる。

重複コンテンツの削除と統合

同じ内容のページが複数存在すると、クロールバジェットが分散される。商品バリエーション(色違い、サイズ違い)でURLが分かれている場合は、canonicalタグで正規URLを指定するか、統合を検討する。

ソフト404とリダイレクトチェーンを回避

削除されたページが200ステータスコードを返す「ソフト404」は、Googlebotが無駄なクロールを続ける原因となる。存在しないページは404または410レスポンスを返すように設定する。また、1つのページに対して複数のリダイレクトが発生する「リダイレクトチェーン」も、クロール効率を低下させるため避けるべきだ。

Search Consoleのクロール統計を活用

Google Search Consoleの「設定」→「クロール統計」レポートでは、Googlebotのクロール頻度や発生した問題を確認できる。このレポートを定期的にチェックし、クロールバジェットの消費状況を把握することが、最適化の出発点となる。

304ステータスコードの注意点

304ステータスコードの注意点

今回のガイドライン更新で追加されたのが、304(Not Modified)ステータスコードに関する推奨だ。Googleは「前回のクロールからページが変更されていない場合、304コードを返すことでGoogleにキャッシュ版の再利用を促し、サーバー帯域とリソースを節約できる」としている。

しかし、この推奨には注意が必要だ。Practical Ecommerceの記事では、Jill Kocher氏が次のような見解を示している。304コードを重要なページに使用すると、検索結果での表示順位やインデックスステータスに影響を与える可能性がある。同氏は、期限切れ商品やポリシーページなど、重要性の低いページに限定して使用することを推奨している。

304コードを重要な商品ページに使った場合のリスク
Googlebot → 304 Not Modified
※キャッシュが再利用され、実際のコンテンツ更新が検出されないおそれ
⚠ 表示順位の低下やインデックスステータスへの悪影響の可能性
■ リスクあり(重要ページには非推奨)
↓
304コードの安全な使用例
期限切れ商品 や プライバシーポリシー
※検索順位に影響しないページに限定して使用
✅ サーバーリソースの節約に貢献
■ 安全に使用可能

ECサイト運営者としては、この304コードの推奨を鵜呑みにせず、自社のSEO戦略に照らして慎重に判断する必要がある。売上に直結する商品ページやカテゴリページには適用せず、重要度の低い固定ページに限定するのが賢明だ。

この記事のポイント

  • 新サイトのクロールバジェットは「保守的」に設定されるため、段階的なコンテンツ公開が有効
  • 表示速度の改善と定期的な更新が、クロールバジェット拡大の鍵
  • robots.txtの活用、重複コンテンツの統合、ソフト404の排除で無駄なクロールを削減
  • Search Consoleのクロール統計レポートで状況を定期的にモニタリング
  • 304ステータスコードは重要ページには使用せず、影響の少ないページに限定する