タグアーカイブ WooCommerce

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で受け付けている
FTCが個人別価格表示に透明性要求。WooCommerce事業者の備え

FTCが個人別価格表示に透明性要求。WooCommerce事業者の備え

米FTC(連邦取引委員会)がパーソナライズドプライシング、つまり顧客データに基づいて個人ごとに価格を変える手法に対する執行方針を提案した。2026年8月19日付の提案で、この手法そのものを禁止するものではない。価格がどのように決まったのかを消費者に明確に伝える透明性を求める内容だ。

ECサイトを運営する事業者、特にWooCommerceを使う中小企業にとって、今後の価格戦略とデータ活用の見直しにつながる重要な動きである。パブリックコメントは2026年9月25日まで受け付けている。

FTCがパーソナライズドプライシングの透明性を要求

FTCがパーソナライズドプライシングの透明性を要求

パーソナライズドプライシング(個人別価格設定)とは、顧客の購買履歴や行動データを使って、同じ商品でも顧客ごとに異なる価格を提示する手法だ。FTCはこの手法を禁止する権限はないとしつつ、FTC法第5条(不公正または欺瞞的な行為の禁止)を根拠に透明性の確保を図る。

FTCが事業者に求めている内容は大きく3つある。

  • 価格がパーソナライズされたものであることの明示
  • なぜその価格になったのかの理由
  • どのようなデータを使ったのかの説明

提案された執行方針の内容

FTCが示した方針では、価格がパーソナライズされたことを消費者に知らせる免責事項の表示が必要になる。たとえば「この価格はあなたの購買履歴に基づいてパーソナライズされています」といった説明を商品ページに追加することが想定される。

従来の価格表示(Before)
¥12,800
送料無料
価格がどのように決まったかの説明なし
↓
FTCが求める透明性のある価格表示(After)
¥12,800
送料無料
この価格はあなたの過去の購入履歴に基づいてパーソナライズされています

このデモは、価格表示に透明性の説明を追加する変化を示している。FTCの方針は、価格そのものの変更ではなく、消費者への説明責任を問うものだ。

マーケターへの影響

ここ数年、マーケターはサードパーティCookieの衰退を受けて、ファーストパーティデータ(自社で直接収集した顧客データ)を集めるよう奨励されてきた。そのデータ活用が「体験のパーソナライズ」から「価格のパーソナライズ」にまで拡大しているケースがある。FTCの提案は、この流れに透明性という歯止めをかけるものだ。

たとえば、ある小売業者が顧客の過去の購買履歴を分析し、この顧客は高くても買う傾向があると判断して、同じ商品を他の顧客より高い価格で提示するケースを考えてみる。FTCの提案では、この場合「価格が過去の購入履歴に基づいてパーソナライズされている」という説明が必須になる。

パーソナライズドプライシングとダイナミックプライシングの違い

パーソナライズドプライシングとダイナミックプライシングの違い

FTCはパーソナライズドプライシングとダイナミックプライシングを明確に区別している。この区別は重要だ。ダイナミックプライシング(変動価格設定)は需要と供給に応じて価格を変動させる手法で、航空券やホテルの宿泊料金、配車アプリのサーチャージが代表例だ。繁忙期や悪天候時に価格が上がるのは、個人のデータではなく市場全体の需給に基づく。

一方、パーソナライズドプライシングは個人のデータに基づく。過去の購買履歴から「この顧客は高くても買う傾向がある」と判断して、同じ商品を他の顧客より高い価格で提示するようなケースだ。

ダイナミックプライシング
需要と供給に基づいて価格が変動する
航空券 ホテル 配車アプリ
個人データは使わない。市場全体の需給で決まる
パーソナライズドプライシング
個人のデータに基づいて価格が変動する
購買履歴 閲覧行動 会員情報
同じ商品でも顧客ごとに異なる価格を提示する
■ ダイナミックプライシング ■ パーソナライズドプライシング

この比較図は、2つの価格設定手法の根本的な違いを示している。FTCが問題視するのは後者のパーソナライズドプライシングである。

FTCが監視対象として挙げた具体例

FTCが挙げた具体例はかなり踏み込んでいる。外出が難しい消費者への食品販売、複数の子供のために牛乳を買う消費者、葬儀や緊急の用事で移動する消費者、医療緊急時の交通手段を必要とする消費者、犯罪被害に遭った直後に防犯カメラを探す消費者、店舗や駐車場にいながら小売サイトを閲覧する消費者などが挙げられた。これらは消費者が弱い立場にある状況で、パーソナライズドプライシングが使われることを特に問題視している。

この具体例から読み取れるのは、FTCが「事業者はデータをたくさん集めているが、すべてを理解しているわけではない」というメッセージをマーケターに送っている点だ。

WooCommerce事業者への実務的影響

WooCommerce事業者への実務的影響

日本のEC事業者にとって、FTCの方針は直接の規制対象ではない。ただし、海外向けに販売するWooCommerceサイトや、グローバルに展開する企業は注意が必要だ。また、日本でも個人情報保護法や景品表示法の観点から、同様の透明性が求められる可能性がある。

動的価格設定プラグインの注意点

WooCommerceでパーソナライズドプライシングを実装する場合、動的価格設定プラグインを使うことが多い。これらのプラグインは、顧客のログイン情報や過去の注文履歴、カートの中身などに基づいて価格を変更できる。今回のFTC方針を踏まえると、こうした機能を使う際に「価格がパーソナライズされていること」を明示する仕組みを追加する必要が出てくる。

STEP 1 顧客データの収集(購入履歴・会員情報・閲覧行動)
↓
STEP 2 価格計算エンジンが個人別の価格を算出
↓
STEP 3 商品ページに価格を表示
↓
STEP 4 FTC対応として透明性の説明を追加

このフローは、WooCommerceでパーソナライズドプライシングを導入する際の基本的な流れを示している。STEP 4の透明性の説明が、FTC方針への対応に該当する。

データガバナンスの課題

FTC方針への対応で最も難しいのが、データの出所と利用目的の管理だ。顧客データはCDP(カスタマーデータプラットフォーム)、ロイヤルティプログラム、パーソナライゼーションエンジン、AIエージェントなど複数のシステムに分散している。どのデータを価格設定に使ったのかを追跡できる状態にしておく必要がある。

MarTechの記事で、In-Store MarketplaceのPaul Brenner氏は「データの許可利用範囲と禁止範囲の線引きが難しく、多くの加盟店がシステムと透明性を備えていない」と指摘している。この課題は、FTCの執行方針が現実になった場合、EC事業者にとって大きなハードルになる。

今すぐできる3つの対策

今すぐできる3つの対策

FTCの方針はまだ提案段階だが、今から準備しておくことで、執行が始まった際の混乱を避けられる。具体的には次の3つだ。

1つ目は、価格表示に説明を追加すること。パーソナライズドプライシングを使っている場合、その旨を商品ページやカート画面に明記する。使っていない場合でも、価格がどのように決まるのかを説明しておくと、消費者の信頼につながる。

2つ目は、データ利用の同意取得を見直すこと。他社から取得したデータを価格設定に使う場合、消費者がその用途に同意しているかを確認する必要がある。単に「同意があるはず」と仮定するだけでは不十分だ。

3つ目は、データの利用目的を文書化すること。価格設定にどのデータを、どのように使っているのかを社内で整理し、必要に応じて開示できる状態にしておく。これがデータガバナンスの第一歩になる。

この記事のポイント

  • FTCはパーソナライズドプライシングそのものを禁止せず、透明性の確保を求めている
  • パーソナライズドプライシングは個人データに基づく価格設定で、ダイナミックプライシングとは異なる
  • WooCommerce事業者は動的価格設定プラグインの利用時に説明表示を追加する必要がある
  • データの出所と利用目的を追跡できるデータガバナンスが今後の課題になる
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以上へのテストを推奨
TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開

TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開

TikTok ShopがEU加盟8カ国と英国の間で越境販売を開始する。出品者は自国の外にいる消費者へ直接商品を届けられるようになる。9月21日のパイロット運用を経て、10月19日に本格展開へ移行する流れだ。

越境ECの選択肢が増えることで、中小規模の事業者にも新たな販路が開ける。英国市場では30万以上の小規模事業者がTikTok Shopを利用している。EU側の出品者にとって英国市場へのアクセスは魅力的な拡張機会になるだろう。

本記事では越境販売の仕組み、販売条件、EC事業者への影響を解説する。特にWooCommerceで自社ECを運営する事業者にとっての意味合いも掘り下げる。

TikTok Shopの越境販売、全体像

TikTok Shopの越境販売、全体像
EU8カ国から英国へ
EU8カ国の出品者 商品を出品 → TikTok Shop 越境販売を仲介 → 英国の購入者
↓
英国からEU12カ国へ
英国の出品者 商品を出品 → TikTok Shop 越境販売を仲介 → EU12カ国の購入者

このデモでは双方向の越境販売フローを示した。9月21日と10月19日の2段階展開がポイントである。EU側と英国側で販売条件が異なる点は後述する。

TikTok Shopは欧州での展開を急速に進めている。6月中旬にはオーストリア、ベルギー、オランダ、ポーランドに進出した。同時に「Sell Across Europe」プログラムを始動し、欧州12カ国をカバーする汎欧州市場へと進化している。今回の越境販売は、この汎欧州市場を英国へ拡張する動きの一環だ。

EU8カ国から英国への販売

対象となるのはベルギー、ドイツ、フランス、アイルランド、イタリア、オランダ、ポーランド、スペインの8カ国だ。まず9月21日に選ばれたEU出品者向けパイロットが始まる。その後10月19日に本格展開に移る。英国ではTikTok Shopが約5年間運営されており、30万以上の小規模事業者が利用する成熟市場だ。

英国からEU12カ国への販売

一方、英国の出品者は欧州大陸の12カ国に販売できるようになる。対象国はSell Across Europeネットワークに参加している国々だ。対象かどうかは、出品者の現在のアカウント状態とパフォーマンスをリアルタイムで評価して決まる。

EC事業者が知るべき販売条件

EC事業者が知るべき販売条件

越境販売に参加するには、いくつかの条件を満たす必要がある。特に英国向け販売では配送方式が重要になる。

Ship by Seller方式の詳細

英国向け販売で使える配送オプションは「Ship by Seller」のみである。これは出品者が自ら配送業者を選び、配送料を支払い、配送トラブルが起きた場合も顧客対応を行う方式だ。TikTok Shop公式の説明でも「配送業者を選び、配送料を支払い、配送がうまくいかなかった場合の顧客対応も行う」とされている。日本で言えば、マーケットプレイスではなく自社発送に近い形態である。フルフィルメントをTikTok側が代行するわけではないため、越境配送の手配とコスト管理は出品者自身の責任になる。

STEP 1 出品者が配送業者を選択
↓
STEP 2 配送料を出品者が負担
↓
STEP 3 トラブル発生時の顧客対応も出品者が担当

この3ステップがShip by Seller方式の全体像だ。配送業者の選択から顧客対応まで、出品者側に責任が集中する。越境販売では関税や返品対応も加わるため、国内発送以上に準備が求められる。

販売対象になるための要件

越境販売の対象になるには、次の要件を満たす必要がある。対象EU市場でTikTok Shopにすでにアクティブであること、アカウントが良好な状態であること、最近の販売実績があること、大きな未払い残高がないこと。英国からEUへの販売では、リアルタイムのアカウント評価が対象判断に使われる。

対象になるための主な要件
要件 1 対象EU市場でTikTok Shopにすでにアクティブ
要件 2 アカウントが良好な状態
要件 3 最近の販売実績がある
要件 4 大きな未払い残高がない
■ 要件1 ■ 要件2 ■ 要件3 ■ 要件4

4つの要件を色分けして示した。英国からEUへの販売は、これらに加えてリアルタイムのパフォーマンス評価が使われる。出品者側は日頃からアカウント状態を良好に保つことが前提になる。

越境ECとしてのTikTok Shopの戦略的意味

越境ECとしてのTikTok Shopの戦略的意味

TikTok Shopの越境販売は、欧州市場を一つの商圏として統合する動きだ。従来のECモールは国ごとにアカウントや出品設定が必要だったが、Sell Across Europeと英国への拡張により、一つのアカウントで複数国にリーチできるようになる。特に英国市場は購買力が高く、EU側の事業者にとって有望な販売先である。越境ECの障壁だった言語や通貨、配送の問題をTikTokがどこまで解決できるかが、今後の成長を左右する。

本サイトの見方として、TikTok Shopの越境販売はソーシャルコマースの越境展開という新しい段階に入ったことを示す。InstagramやFacebookと異なり、TikTokのショート動画とECが一体になった体験が、国境を越えた購入を後押しする可能性がある。一方で、Ship by Seller方式による出品者負担の配送は、越境ならではの関税や返品対応の複雑さを考慮すると、小規模事業者にとっては高いハードルになり得る。ここが普及の鍵になるだろう。

WooCommerce事業者への示唆

WooCommerce事業者への示唆

WooCommerceで自社ECを運営する事業者にとって、TikTok Shopの越境販売は販路拡大の新たな選択肢になる。自社ECサイトを持ちながら、TikTok Shopをフロントエンドの集客チャネルとして使う形だ。商品データの同期や注文管理の連携ができれば、在庫管理を一元化しながら越境販売を試せる。現時点では公式なプラグインによる深い統合は限定的だが、今後のAPI公開や連携強化に注目したい。まずは自社の商品が越境販売に適しているか、配送コストと販売価格のバランスを見極めることを推奨する。

EC制作の現場から見ると、越境販売への対応はテーマやカートの複数通貨対応、配送業者との連携、関税計算など、技術的な準備が増える。TikTok Shopのようなプラットフォームを活用すれば、これらの複雑さを一部肩代わりできる。WooCommerce事業者は「自社ECで深く最適化する」か「プラットフォームで手早く展開する」かの使い分けが重要になる。

この記事のポイント

  • TikTok ShopがEU8カ国と英国の間で越境販売を開始する
  • 9月21日にパイロット、10月19日に本格展開へ移行する
  • 英国向け販売はShip by Seller方式のみで、出品者が配送の全責任を負う
  • 販売対象にはEU市場でのアクティブな実績と良好なアカウント状態が求められる
  • WooCommerce事業者は自社ECとの併用で越境販売の機会を探れる
Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策

Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策

Googleの広告テック事業をめぐる独占訴訟で、米連邦地裁は事業分割を命じず、行動制限という形で決着をつけた。裁判所はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築いたと認定したものの、AdXの売却は求めなかった。

この判決は、EC事業者が日々利用しているプログラム広告のインフラに直接関わる。広告費の流れやオークションの透明性が変わる可能性があり、広告運用の見直しが必要になる場面も出てくる。

本記事では、判決の内容を整理し、EC事業者やWooCommerceサイト運営者が知っておくべき影響と対策を解説する。

判決の概要と独占認定のポイント

判決の概要と独占認定のポイント

司法省は2023年、Googleが広告テック事業で複数の市場を支配し、競争を抑圧しているとして提訴した。2025年4月、ブリンケマ判事はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築き、両製品を不当に抱き合わせたと認定した。一方、アドバタイザー向けツールでの独占は認定されなかった。

この区別は重要だ。Googleは広告主とパブリッシャーの間に位置し、パブリッシャー側の在庫管理と、その在庫を広告需要と結びつけるオークションの両方を運用している。つまり、売り手と市場の両方を支配している状態だ。

分割要求が退けられた理由

司法省はGoogleに対し、広告エクスチェンジ「AdX」の売却を要求した。しかしブリンケマ判事は、分割は困難で混乱を招く可能性が高いと判断した。判事は救済措置の審理で、誰がエクスチェンジを買うのか、買った後にどう運営するのかと疑問を呈し、違法行為を止める方が現実的な救済になると述べたという。

判決の完全な内容はまだ一部が封印されており、詳細は明らかになっていない。公開された命令では、提案された行動制限のほとんどが修正付きで受け入れられたとされている。

広告オークションのルールはどう変わるのか

広告オークションのルールはどう変わるのか

裁判所は以前、Googleが「ファーストルック」と「ラストルック」という慣行を使ってAdXを有利にしていたと認定した。ファーストルックは、Googleがパブリッシャーの在庫に最初にアクセスできる仕組みだ。ラストルックは、競合の入札情報を見てから自社の入札額を決められる仕組みだった。

今回の救済措置では、これらの優位性が制限される。パブリッシャーは価格設定の自由度を高め、競合するパブリッシャー向け広告サーバーにはGoogleのAdX入札情報がリアルタイムで提供される見込みだ。

従来の広告オークション(Before)
Google AdX がパブリッシャーの在庫に最初にアクセス(ファーストルック)
Google AdX が競合の入札情報を見てから入札額を決定(ラストルック)
パブリッシャー は需要元ごとに最低価格を設定できず
↓
判決後の広告オークション(After)
Google AdX のファーストルックとラストルックが制限される
競合広告サーバー にもAdXの入札情報がリアルタイムで提供される
パブリッシャー は需要元ごとに最低価格を設定可能になる

この変更により、競合する広告テック企業が在庫獲得で公平な条件で競争できるようになる。広告主にとっては、オークションのダイナミクスやサプライパス、価格設定、パブリッシャーに届く広告費の割合が徐々に変わる可能性がある。

EC事業者が知っておくべき広告費の透明性

EC事業者が知っておくべき広告費の透明性

この判決は、広告費の流れを可視化する重要性を高めている。特にEC事業者は、Googleショッピング広告やディスプレイ広告を通じて商品を宣伝する。広告費がどの経路を通り、どれだけパブリッシャーに届くのかを理解することが、投資対効果の改善につながる。

Googleは依然として広告テックの主要インフラを所有している。行動制限は一部の優位性を取り除くが、パブリッシャーと広告主はGoogleが独占を維持してきたシステムの中で運用を続けることになる。

STEP 1 広告主(EC事業者)が広告予算を設定する
↓
STEP 2 広告エクスチェンジ(Google AdXなど)がオークションを実施
↓
STEP 3 パブリッシャー(ブログ・ニュースサイト)に広告が表示される
■ 広告主(EC事業者) ■ Google所有の広告テック ■ パブリッシャー

上図の通り、Googleはパブリッシャー向け広告サーバーとエクスチェンジの両方を所有している。このため、広告主が支払った金額の一部が中間レイヤーで差し引かれ、パブリッシャーに届くまでに目減りしやすい構造だ。判決後のルール変更がこの構造をどこまで変えられるかが焦点になる。

今後の広告運用にどう備えるか

今後の広告運用にどう備えるか

短期的には大きな変化はない

マーケターは来週からプログラム広告キャンペーンが劇的に変わるとは考えない方がよい。オープンウェブ広告の成長はすでに鈍化しており、YouTubeやInstagram、Amazonなどへの支出シフトが進んでいる。Appleのプライバシー変更によるモバイルトラッキング制限もこの流れを加速させた。

それでも、判決はサプライパスの透明性をより重要にする。マーケターは自社の広告費がどのエクスチェンジや中間業者を経由しているか、各広告費のうちどれだけがパブリッシャーに届いているか、Googleのスタック以外の選択肢が現実的になってきたかを注視する必要がある。

サプライパスの見直しと代替手段の検討

EC事業者にとって具体的な対策は、広告配信のログやレポートを定期的に確認し、中間マージンが過大な経路を特定することだ。Googleの広告テック以外にも、競合するエクスチェンジやパブリッシャー向けサーバーが存在する。判決後の環境変化を見極めつつ、複数の選択肢をテストすることが推奨される。

MarTechの記事では、行動制限は「実験」にすぎず、競合がこの機会を利用してGoogleから大きなシェアを奪えなければ独占は続くと指摘している。つまり、他の事業者がGoogleの支配に対抗できるかどうかが、今後の市場の行方を左右する。

この記事のポイント

  • Googleは広告テック独占で違法認定されたが、AdXの売却は命じられず、行動制限のみが課された
  • ファーストルックとラストルックの制限により、競合広告テックが公平に競争できる可能性が出てきた
  • EC事業者は広告費のサプライパスを可視化し、中間マージンの過大な経路を特定することが重要
  • 短期的に広告運用が激変することはないが、代替手段のテストと環境変化の注視が推奨される
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顧客向け注文撤回フォームが追加された(デフォルトでは無効)
  • 商品ギャラリーの動画対応はベータ機能としてデフォルト無効で提供される
  • 仮想商品のみの注文では管理画面に配送先住所が表示されなくなった
Rank MathでWooCommerceモジュールが開けない時の原因と対処法

Rank MathでWooCommerceモジュールが開けない時の原因と対処法

Rank MathのWooCommerceモジュールがグレーアウトして切り替えられない場合、原因はプラグインのデータベースマイグレーションが完了していないことにある。管理画面に表示されるデータベースバージョンが初期値の1のままなら、まずキャッシュの全削除とメモリ上限の確認を行い、その上で不要オプションを削除して再マイグレーションを発生させる。

なぜWooCommerceモジュールだけがロックされるのか

なぜWooCommerceモジュールだけがロックされるのか

Rank Mathは各機能をモジュール単位で管理している。WooCommerceモジュールもその一つで、商品の構造化データや詳細設定をまとめて扱う。ところがこのモジュールは、プラグインのデータベーススキーマが特定のバージョン以上になった時だけ有効化できる仕組みだ。

管理画面のステータス情報で「database_version」がいつまでも初期値の1のままだと、WooCommerceモジュールを含む一部の機能が「未導入」と判断されたままになる。トグルにマウスを重ねると「Please activate WooCommerce to use this module」という趣旨のツールチップが表示されるが、WooCommerce本体が有効化されていてもこのエラーは出る。

つまり、WooCommerceの有効・無効が問題なのではなく、Rank Math側のデータベース情報が古いまま更新されていないことが本質のトラブルだ。

database_versionが1のまま進まない主な原因

database_versionが1のまま進まない主な原因

Rank Mathのインストール時やセットアップウィザード実行時、プラグイン内部でデータベーステーブルの作成とデータ移行が走る。この処理が最後まで到達しないと、バージョン情報が初期値の1から更新されない。具体的な原因は大きく三つに分けられる。

キャッシュプラグインが古いオプションを保持している

WP Super Cacheに代表されるキャッシュプラグインは、ページ表示を高速化するために一時データを保持する。まれにデータベースのオプション情報まで古い状態のまま配信することがあり、これが原因でRank Mathのバージョン情報が更新されないケースがある。

PHPメモリ上限が低くマイグレーションが途中で止まる

WooCommerceサイトは通常のWordPressサイトより管理画面のメモリ消費が大きい。Elementorや高機能テーマも動いている場合、PHPのメモリ上限を超えてRank Mathのデータベース処理が途中で終了してしまうことがある。具体的にはwp-config.phpで定義されたWP_MEMORY_LIMITが40M程度だと、重い環境では不足しやすい。

rank_math_db_versionオプションが破損している

WordPressのオプションテーブル(wp_options)には、Rank Mathが利用する複数のオプションが保存されている。このうち「rank_math_db_version」という値が破損したり、不正な状態で固定されたりすると、セットアップウィザードを再実行しても値が更新されない。

モジュールロックを解除する具体的な手順

モジュールロックを解除する具体的な手順

以下の手順は、データベースバージョンが初期値から更新されない場合に有効だ。順に実行することで、Rank Mathのマイグレーションが正常に走り、WooCommerceモジュールのロックが外れる。

STEP 1 キャッシュプラグインを停止し全キャッシュを削除する
↓
STEP 2 wp-config.phpでWP_MEMORY_LIMITを128M以上へ引き上げる
↓
STEP 3 rank_math_db_versionオプションをデータベースから削除する
↓
STEP 4 Rank Mathのセットアップウィザードを再度実行してWooCommerceモジュールを確認する
■ STEP 1  ■ STEP 2  ■ STEP 3  ■ STEP 4

このデモは、Rank Mathのデータベースバージョンを固定している原因を取り除き、マイグレーションを再実行させる流れを示している。

キャッシュを完全に無害化する

管理画面のプラグインページでWP Super Cacheを一時的に無効化する。次に「設定」→「WP Super Cache」からキャッシュの削除を実行し、サーバー上のwp-contentディレクトリにあるcacheディレクトリ内のファイルも手動で削除しておく。

共有サーバーで管理画面から操作できない場合は、FTPソフトでwp-content/cacheに入り、中身を空にする。キャッシュを消した後は、ブラウザのキャッシュも混ざらないようシークレットウィンドウで確認すると確実だ。

WP_MEMORY_LIMITを引き上げる

FTPまたはサーバーのファイルマネージャーでwp-config.phpを開き、WP_MEMORY_LIMITの定義を探す。設定されていなければ「/* That’s all, stop editing! */」の直前に以下の行を追加する。

define( 'WP_MEMORY_LIMIT', '128M' );

すでに40Mなど低い値が指定されている場合は、128Mまたは256Mに書き換える。変更後にWordPress管理画面の「ツール」→「サイトヘルス」からPHPのメモリ上限が更新されているか確認できる。

rank_math_db_versionオプションを直接削除する

サーバーのphpMyAdminにアクセスし、該当サイトのデータベースを選択する。wp_optionsテーブルを開き、option_nameが「rank_math_db_version」の行を探して削除する。

SQLを直接実行できる環境なら、次のようにしても同じ結果になる。

DELETE FROM wp_options WHERE option_name = 'rank_math_db_version';

テーブルの接頭辞がwp_以外の場合は、実際の接頭辞に置き換える。削除後、Rank Mathの管理画面を開くとマイグレーションが自動的に再実行され、正常ならデータベースバージョンが初期値より大きい値に更新される。

rank_math_modulesオプションも削除する

rank_math_db_versionを削除してもWooCommerceモジュールがロックされたままの場合、rank_math_modulesというオプションも同様に削除する。この値には有効化済みモジュールのリストが保存されており、破損しているとモジュールの出し分けが正常に機能しない。

DELETE FROM wp_options WHERE option_name IN ('rank_math_db_version', 'rank_math_modules');

この二つを削除した後、Rank Mathのセットアップウィザードを「詳細モード」で最後まで実行する。WooCommerceモジュールのトグルが青くなり、切り替え可能になっていれば成功だ。

それでも直らない場合の最終確認

それでも直らない場合の最終確認

データベースユーザーにテーブル作成権限があるか

Rank Mathのマイグレーションは、専用のテーブル(rank_math_analytics_objectsなど)を作成してデータを保存する。データベースユーザーに「CREATE TABLE」権限がないと、処理が裏側で失敗し続ける。レンタルサーバーの管理画面からデータベースユーザーの権限を確認し、不足していれば付与する。

重いプラグインを停止してからもう一度

ElementorやSlider Revolutionなど、管理画面の動作を重くするプラグインがマイグレーションを妨げている可能性がある。Health Check & Troubleshootingプラグインのトラブルシューティングモードを使い、Rank MathとWooCommerceだけを有効化した状態で手順をもう一度試す。

Rank Mathのデータベースツールでテーブルを作り直す

Rank Mathの管理画面から「ステータスとツール」→「データベースツール」を開く。「テーブルを作り直す」や「データベースを修復」といったボタンが用意されているので、順に実行してテーブルの再作成とデータの再構築を行う。

その後、もう一度セットアップウィザードを完了させ、データベースバージョンの値が更新されるかを確認する。それでも値が1のままなら、プラグインのアップデート待ちか、サーバー環境固有の制約が残っている可能性が高い。

よくある質問

トグルをクリックしても何も反応しないのはなぜ?

WooCommerceモジュールがロックされていると、トグル自体がグレーアウトした状態になる。クリックしても切り替わらず、ツールチップだけが表示される。これは操作ミスではなく、Rank Math内部でモジュールが使えない状態として認識されているためだ。

WooCommerce本体が壊れている可能性はある?

WooCommerceがプラグインページで有効化されており、商品管理やカートなど通常機能が動いているなら本体は正常だ。今回の問題はRank Math側のデータベース情報が古いことが原因なので、WooCommerceを再インストールしても解決しない。

Rank Mathを削除して入れ直しても直らないのはなぜ?

プラグインを削除しても、wp_optionsテーブルに保存されたオプションは残る。再インストール時に古いオプションを読み込んでしまい、同じ状態が再現される。必ずデータベースからrank_math_db_versionを削除してから再インストールする必要がある。

キャッシュプラグインは原因になりうる?

WP Super Cacheなどのキャッシュプラグインはページキャッシュが主体だが、環境によってはデータベースの一時情報も保持することがある。Rank Mathのバージョン情報が更新されない状態が続くなら、キャッシュプラグインを停止して切り分けるのが有効だ。

セットアップウィザードは毎回完了しているのに直らない

ウィザード自体は設定画面を進めるだけで、データベースのマイグレーションは別プロセスで走る。マイグレーションが裏側で失敗していると、ウィザード完了後もdatabase_versionが1のままになる。オプション削除とメモリ上限の引き上げを先に行うことが重要だ。

この記事のポイント

  • WooCommerceモジュールのロックはRank Mathのデータベースバージョンが原因
  • database_versionが1のままならマイグレーションが未完了
  • キャッシュ削除とWP_MEMORY_LIMITの引き上げを先に行う
  • rank_math_db_versionとrank_math_modulesオプションを直接削除して再実行
  • テーブル作成権限の確認と重いプラグインの停止も有効
WooCommerce 11.1でREST APIとStore APIが最大42%高速化。ブロック登録スキップの仕組み

WooCommerce 11.1でREST APIとStore APIが最大42%高速化。ブロック登録スキップの仕組み

WooCommerce 11.1がブロック登録の仕組みを大きく変更する。REST APIとStore APIのリクエストが従来より13〜18ミリ秒、割合で30〜42%速くなる見込みだ。

これまでWooCommerceはほぼすべてのリクエストでブロックタイプとパターンを登録していた。画面にブロックを描画しないAPIリクエストでも同じ準備処理が走り、無駄なコストになっていた。

この記事では変更の背景と仕組み、影響を受ける開発者の条件、具体的な対応方法を解説する。11.1は正式リリース前の段階のため、エクステンションを配布している開発者は事前テストが求められる。

なぜブロック登録をスキップするのか

なぜブロック登録をスキップするのか

ほぼ全リクエストで発生していた無駄な処理

WooCommerceはこれまで、ブロックタイプとパターンをほぼすべてのリクエストで登録していた。商品データを返すだけのREST APIリクエストでも、カート情報を返すStore APIリクエストでも、ブロックを描画しないのに登録処理が実行されていた。

ブロック登録にはファイル読み込みやメタデータ解析が伴う。1リクエストあたりの負荷は小さくても、APIを多用する店舗やヘッドレスコマース構成では応答速度に影響する。WooCommerceチームは「リクエストはブロックを描画または編集できる場合にのみ、ブロック登録のコストを支払うべき」という方針を取った。

従来のリクエスト処理(Before)
全リクエスト ブロック登録を実行 → ブロック登録 → 本来の処理
↓
改善後のリクエスト処理(After)
REST API リクエスト ブロック登録を実行しない → 登録スキップ → 本来の処理

Beforeではすべてのリクエストがブロック登録を経由していた。Afterではブロックを描画しないAPIリクエストが登録処理を飛ばし、その分だけレスポンスが速くなる。

描画しないリクエストに課されるコスト

従来の挙動は、ブロックを編集も描画もしないリクエストまでブロックエディタの準備をさせるものだった。この無駄はアクセス数に比例して増える。とくにモバイルアプリやフロントエンドを別システムで構築し、WooCommerceをAPI経由で使う構成では影響が大きい。

今回の最適化は、APIリクエスト全体に占めるブロック登録のコストが想定以上に大きかったことを示している。13〜18ミリ秒の改善は体感的には小さいが、ピーク時に多数のリクエストを処理する店舗では合計の短縮効果が積み上がる。

11.0から11.1へ段階的に進めた変更

11.0から11.1へ段階的に進めた変更

11.0で導入したパターンの遅延読み込み

第一段階はWooCommerce 11.0で実装された。パターンがファイルパスで登録され、エディタから要求されたときだけ内容が読み込まれるようになった。WordPressコアと同じ挙動だ。ブロックを登録するリクエストごとに5〜8ミリ秒の節約が確認されている。

11.1のBlockRegistrationContextガード

11.1では新しいBlockRegistrationContextガードが追加された。このガードがリクエストを判定し、ブロックを描画しない場面ではブロックタイプとパターンの登録をまとめてスキップする。

商品説明を守るオンデマンド登録の例外

1つだけ例外がある。商品説明やバリエーション説明にWooCommerceブロックが含まれる場合、woocommerce_short_descriptionフィルター経由で必要なときにブロックタイプが登録される。これにより商品REST API、Store API、バリエーションAJAXエンドポイント、商品のWebhookでも説明が正しく描画される。

STEP 1 11.0でパターンの遅延読み込みを導入
↓
STEP 2 11.1でブロック登録をスキップするガードを追加
↓
STEP 3 Store APIとREST APIが13〜18ミリ秒、30〜42%高速化

2段階の変更により、パターン読み込みとブロック登録という2つの重い処理がAPIリクエストから外れた。完成した最適化の効果が30〜42%という数字に表れている。

対象リクエストと安全性の設計

対象リクエストと安全性の設計

スキップ対象と従来どおりのリクエスト

スキップされるのはブロックを描画しないリクエストのみだ。フロントエンド、管理画面、ブロックエディタ、サイトエディタのリクエストは従来どおりブロックを登録する。

見落としがあっても表示は壊れない

ガードは自身が認識したコンテキストだけをスキップする。認識できない場面では登録を継続するため、分類に漏れがあったとしても描画の後退にはつながらない。性能が少し落ちるだけで済む設計だ。

登録をスキップするリクエスト
REST API、Store APIなどブロックを描画・編集しない場面
従来どおり登録するリクエスト
フロントエンド、管理画面、ブロックエディタ、サイトエディタ
認識できないコンテキスト
登録を継続するため、表示が壊れることはない

この設計は保守性の面でも合理的だ。未知のリクエストに対して安全側に倒すため、WooCommerceの内部判断が変わっても既存サイトの表示が突然崩れるリスクを抑えられる。

開発者が確認すべき影響範囲

開発者が確認すべき影響範囲

影響を受けるエクステンションの条件

この変更はWooCommerce 11.1.0から適用される。スキップされるリクエスト中にWooCommerceブロックを描画するエクステンション、またはWooCommerceのブロックタイプ、パターン、ブロックごとのアセット登録に依存するエクステンションが影響を受ける。

スキップされた場面では、WooCommerceブロックは生のブロックマークアップか、動的出力のない静的なHTMLとして返る。テンプレートに直接ブロックを組み込んでいるエクステンションは、表示内容が変わらないか確認が必要だ。

コードで確認する方法

影響の有無はコードで確認できる。以下のコードはWooCommerce 11.1以降のスキップ対象リクエストでfalseを返す。

// WooCommerce 11.1以降、スキップされた場面では false を返す。
WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' );

商品説明と自前ブロックは影響なし

商品説明とバリエーション説明はオンデマンドで処理されるため対応は不要だ。register_block_type()で自前登録しているブロックも影響を受けない。今回の変更はWooCommerce自身が行う登録だけが対象になる。

実務では「自前でブロックを登録しているか」「WooCommerceのブロック登録に依存しているか」の切り分けが重要になる。前者は今回の変更を意識する必要がなく、後者だけが対応を検討すればよい。

開発者が取るべき対応と正しいブロック作成

開発者が取るべき対応と正しいブロック作成

woocommerce_should_register_blocksフィルターで復帰

影響を受けるエクステンションは、新しいwoocommerce_should_register_blocksフィルターを使い、実際にブロックを描画するリクエストのときだけtrueを返す。

add_filter(
    'woocommerce_should_register_blocks',
    function ( $should_register ) {
        return my_context_renders_blocks() ? true : $should_register;
    }
);

フィルターはプラグイン読み込み時に実行され、メインクエリが解析される前の段階で呼ばれる。そのため条件には$_SERVERや$_GETなど、この初期段階で利用できる情報だけを使うことになる。

復帰させる範囲を絞りすぎるとブロックが見つからず表示が変わることがある。逆に広げすぎると今回の性能改善が失われる。描画が実際に発生するリクエストを正確に判定する条件を書くのが開発者の作業になる。

内部クラスAbstractBlockを避ける

WooCommerceはブロックをAbstractBlockという内部クラスの上に構築しないよう推奨している。内部クラスを継承すると、WooCommerceが下すすべての登録判断、今回のスキップも含めて引き継ぐことになる。

登録の最適化が進むにつれ、内部クラスのライフサイクルは今後も変わり続ける。依存すると将来のアップデートで予期しない挙動になる可能性が高い。

標準のWordPress Block APIを使う

サポートされる方法は標準のWordPress Block APIだ。ブロックをblock.jsonに定義し、init時にregister_block_type()で登録する。カートやチェックアウトの内部ブロックには@woocommerce/extend-cart-checkout-blockテンプレートがある。

WooCommerceの公式ドキュメントにあるスキャフォールディングとサンプルストアデータ、@wordpress/create-blockも出発点として適している。標準APIに沿って作れば、今後の最適化に追随しやすい。

正式リリース前の段階で、WooCommerceはエクステンション開発者に11.1へのテストを呼びかけている。とくに商品データやカート情報をAPIで扱う拡張を配布している場合は、早めの動作確認が安全だ。

この記事のポイント

  • WooCommerce 11.1はブロックを描画しないリクエストでブロック登録をスキップする
  • Store APIとREST APIは13〜18ミリ秒、割合で30〜42%高速化する
  • 商品説明や自前登録ブロックは影響を受けず対応不要
  • 影響を受ける場合のみ woocommerce_should_register_blocks フィルターで復帰させる
  • 内部クラスAbstractBlockではなく標準のWordPress Block APIでブロックを作る
Product Feed PROでブランド・変動商品・商品カテゴリが出力されない時の直し方

Product Feed PROでブランド・変動商品・商品カテゴリが出力されない時の直し方

Product Feed PRO for WooCommerceでブランド・変動商品・Google商品カテゴリがXMLに出力されない場合、まず確認すべきはフィールドマッピングの重複定義とキャッシュの遅延だ。症状が3つ同時に出ていても原因はそれぞれ別で、マッピング設定と条件設定を正しく組み替えれば大半は解決する。

ブランドがXMLに間欠的に出力される原因

ブランドがXMLに間欠的に出力される原因

同じブランドを割り当てた商品の一部にだけ<g:brand>が出力されない場合、最も多いのが「ブランドの取得ソースが複数存在している」ケースだ。WooCommerceの商品編集画面ではブランドが正しく見えていても、フィードプラグインは別のソースを参照して空の値を受け取ることがある。

Product Feed PROにはブランドを取得するための選択肢が複数用意されている。商品ブランド(product_brand)タクソノミー、商品属性(pa_brand)、YITH Brandプラグイン用の「Brand」、WooCommerce Brandsプラグイン用の「Product brand」などが代表だ。これらが混在していると、商品Aはタクソノミーから値を取得し、商品Bは未設定の商品属性を参照して空振りする、という動きになる。

特に複数のプラグインを併用していたり、過去にブランド管理の方法を変更したサイトで起きやすい。商品一覧のCSV書き出しでブランド列を確認すると、同じブランド名でも保存されている場所が商品によって異なるのがわかる。

Before フィールドマッピングが「ブランド(属性)」を参照
商品A Dr Coffee → タクソノミーに設定済み → 実は属性も選択済み → 出力OK
商品B Dr Coffee → タクソノミーに設定済み → 属性は未設定 → 出力なし
↓
After マッピングを「商品ブランド(product_brand)」に統一
商品A Dr Coffee → タクソノミーから取得 → 出力あり
商品B Dr Coffee → タクソノミーから取得 → 出力あり
■ ブランドの出力がない状態 ■ 修正後

このデモは、ブランドの取得ソースを属性にしたままタクソノミーのみ設定した商品で出力が欠落する状況を示している。対処は連載の後半でまとめて説明する。

商品ごとにブランドの保存場所を確認する

WooCommerceの商品一覧からCSVを書き出し、ブランドのタクソノミー列と属性列の両方を確認する。片方だけに値が入っている商品があれば、その商品群で出力が欠落しているはずだ。同じブランド名を保ったまま、フィードが参照するソースにデータを揃える必要がある。

フィードプラグインのフィールドマッピングを再定義する

フィードのフィールドマッピング画面で、<g:brand>フィールドの「取得ソース」を確認する。プルダウンに複数のブランド候補が並んでいたら、実際に価値が入っているタクソノミー(product_brand)を選択し直し、フィードを再生成する。

変動商品がフィードから完全に欠落する原因

変動商品がフィードから完全に欠落する原因

変動商品(バリエーションを持つ商品)がXMLに一切出力されない場合、最初に確認するのは「デフォルトのバリエーション」の設定だ。WooCommerceの変動商品では「デフォルトのバリエーションを選択」プルダウンが「デフォルトを選択」のままになっていると、親商品がフィードの出力対象から外れることがある。

フィードプラグインの設定で「商品のバリエーションを含める」を有効にしても、親商品のバリエーション自体が正しく構築されていないと出力はできない。各バリエーションに価格・在庫状況・画像が設定されているか、親商品がカタログに表示される設定になっているかも重要なチェックポイントだ。

Before デフォルトのバリエーションが未選択
Dr Coffee M10(変動商品)
プルダウン「デフォルトを選択」のまま → フィード生成スキップ
バリエーション3点も非出力
↓
After デフォルトのバリエーションを明示的に選択
Dr Coffee M10(変動商品)
プルダウンで1件選択 → フィードに親商品とバリエーションが出力
価格と在庫のある3バリエーションも表示
■ フィード欠落の状態 ■ 修正後

このデモは、デフォルトのバリエーション未選択で変動商品が出力から漏れる典型的なパターンを表している。ほかに価格未入力や在庫切れでも同様の欠落が起こる。

バリエーションの設定を一括で点検する

変動商品の編集画面で、各バリエーションに通常価格またはセール価格が登録されているか、在庫ステータスが「在庫あり」または「予約可能」になっているかを確認する。バリエーションが「非公開」や「カタログに表示しない」になっていないかも見る。

親商品の「商品データ」メタボックスでは、プルダウンで「デフォルトのバリエーション」を必ず1つ選ぶ。この操作が済んでいない変動商品は、フィードプラグイン側の設定に関係なく出力対象外になるケースが多い。

フィード設定の「商品のバリエーションを含める」を再確認する

Product Feed PROのフィード編集画面で、変動商品に関するオプションが有効か確認する。「商品のバリエーションを含める」と「親商品も含める」の両方が目に入るが、どちらか一方だけ有効になっていると期待した出力にならない。特に親商品を表示するには、その商品自体がカタログに表示される設定である必要がある。

Google商品カテゴリが出力されない原因

Google商品カテゴリが出力されない原因

Google商品カテゴリ(<g:google_product_category>)がXMLに出ない場合、原因はほぼ「カテゴリマッピングの条件不一致」か「フィールドマッピングの取得ソースにgoogle_categoryが設定されていない」のどちらかだ。カテゴリマッピング画面でWooCommerceカテゴリとGoogleカテゴリを紐づけただけでは、フィードに反映されない。

カテゴリマッピングの画面では、左側にWooCommerceの商品カテゴリ、右側にGoogleの商品カテゴリを割り当てる。この割り当てが「すべてのカテゴリ」ではなく、一部のカテゴリだけに適用される条件で作られていると、対象外のカテゴリに属する商品からはカテゴリが出力されない。

Before カテゴリマッピングに条件絞り込みが残っている
WooCommerceカテゴリ「コーヒーマシン」だけにGoogleカテゴリを割り当て
→ 他のカテゴリ(ドリップ用品など)は<g:google_product_category>が空のまま
↓
After 全カテゴリを割り当て直し、条件を解除
全WooCommerceカテゴリに対応するGoogleカテゴリをマッピング
→ すべての商品に<g:google_product_category>が出力
■ カテゴリ未出力 ■ 修正後

このデモは、カテゴリマッピングの条件漏れで一部商品のGoogleカテゴリが空になる状況を示している。カテゴリマッピング画面は商品数が多いほど設定漏れが起きやすいので、全カテゴリを対象にするのが基本だ。

フィールドマッピングでgoogle_categoryが設定されているか確認する

フィードのフィールドマッピング画面で、Google側の<g:google_product_category>フィールドに対して、取得ソースが「google_category」になっていることを確認する。このソースは、カテゴリマッピング画面で定義した対照表を参照する専用の値だ。

誤って商品カテゴリそのものを割り当てていると、Googleが求める形式(例: Home & Garden > Kitchen & Dining > Coffee Makers)ではなく、WooCommerceのカテゴリ名だけが出力される。Google Merchant Center側でエラーまたは警告になるため、ソース設定は丁寧に見直す必要がある。

カテゴリマッピングを全カテゴリに適用する

カテゴリマッピング画面で、WooCommerceの各カテゴリに対応するGoogleカテゴリをすべて埋める。カテゴリが多い場合は「未マッピングのカテゴリ」フィルタを使うと、設定漏れのカテゴリだけを洗い出せる。親カテゴリを割り当てたら、子カテゴリが自動的に引き継がれるかどうかも確認する。

3つの問題をまとめて修正する手順

3つの問題をまとめて修正する手順

3つの問題が同時に起きている場合は、それぞれを個別に直すよりも、フィードの基本設定を順番に整える方が早い。次の手順でフィールドマッピング、変動商品設定、カテゴリマッピングを見直す。

STEP 1 ブランドの取得ソースを「商品ブランド(product_brand)」に統一する
↓
STEP 2 変動商品のデフォルトバリエーションを1つ選択する
↓
STEP 3 Google商品カテゴリを全カテゴリに割り当てる
↓
STEP 4 フィードを再生成し、XMLで各フィールドの出力を検証する

このデモは、3つの症状をまとめて修正する際の優先順位を表している。ブランドの取得ソースを先に統一すると、変動商品とGoogleカテゴリの修正結果をXMLで正確に確認できる。

フィード再生成とキャッシュの扱い

設定を変更したあとは、フィードプラグインの「再生成」または「今すぐ更新」ボタンを実行する。WooCommerceやサーバー側のキャッシュが効いていると、更新前のXMLが表示され続けることがある。キャッシュプラグインを使っている場合は、フィードを再生成する前にキャッシュを削除すると確実だ。

生成されたXMLをブラウザで開き、<g:brand>、<g:google_product_category>、変動商品のIDやタイトルが表示されているかをCtrl+F(MacではCommand+F)で検索する。変動商品は親商品とバリエーションが別々の<item>要素として出力されるため、商品IDではなく商品名の一部で検索すると見つけやすい。

よくある質問

ブランドの出力が安定しないのはキャッシュが原因か?

キャッシュだけが原因になる場合は少ない。ブランドタクソノミーと商品属性の両方に同名のブランドが存在し、フィードのマッピングが不安定なソースを参照していることが多い。キャッシュを削除しても再発するなら、取得ソースの統一が先だ。

変動商品だけがXMLから消えるのはなぜか?

変動商品は親商品と各バリエーションが個別の商品として扱われるため、単純商品より出力条件が厳しい。デフォルトのバリエーション未選択、価格未入力、在庫切れ、または「商品のバリエーションを含める」設定のミスが典型的な原因になる。

Google商品カテゴリの出力形式が正しいか確認する方法は?

出力されたXML内の<g:google_product_category>の値を確認し、Google Merchant Centerが求める形式(不等号で区切られた英語の数字付きカテゴリパス)になっているかを見る。WooCommerceのカテゴリ名だけが入っている場合は、フィールドマッピングの取得ソースが誤っている。

設定を変えてもフィードが更新されない場合は?

フィードの再生成ボタンを押したあと、ブラウザでXMLを開いたときに古い内容が表示されることがある。キャッシュプラグインの削除、サーバー側のキャッシュ(OPcacheやVarnish)のクリア、またはクエリパラメータを付けて開く(例: feed.xml?nocache=1)と最新の出力を確認できる。

ブランドが空の商品はどうやって特定するか?

WooCommerceの商品一覧でフィルタ機能を使い、ブランドタクソノミーが空の商品を絞り込む。もし全商品にブランドが付いているのにXMLには一部しか出ていないなら、取得ソースの不一致を疑う。CSV書き出しでブランド列とブランド属性列を並べて比較すると特定しやすい。

この記事のポイント

  • ブランドは取得ソースの統一が最優先
  • 変動商品はデフォルトバリエーションの選択が必須
  • Google商品カテゴリは全カテゴリのマッピングが必要
  • 設定変更後はキャッシュを削除して再生成する
  • XMLを検索して各フィールドの出力を検証する