Category Archive EC制作

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

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での照合に対応した
  • チェックアウトブロックに日付入力欄を追加できる
  • 注文撤回メールの管理画面設定が可能になった
  • パフォーマンス改善とセキュリティ更新を含むためバックアップしてアップデートを
ChatGPT広告に画像フォーマット登場。EC事業者が知るべきBotクリック問題と計測拡張

ChatGPT広告に画像フォーマット登場。EC事業者が知るべきBotクリック問題と計測拡張

OpenAIはChatGPTの広告に画像を使った視覚フォーマットを追加する。画像生成中に表示される新しい広告枠で、広告主は商品やサービス体験を画像で伝えられるようになる。

ChatGPTの週間利用者数は12億人に達している。広告の露出規模は巨大だ。一方でTrafficGuardの調査によれば、ChatGPT広告のクリックはGoogle広告と比べてデータセンターやプロキシ経由が3.6倍多い。

本記事では新しい広告フォーマットの仕組み、Botクリックの実態、計測機能の拡張を整理する。ECサイトを運営する事業者が広告予算を無駄にしないためのポイントもあわせて解説する。

ChatGPT広告に視覚フォーマットが追加

ChatGPT広告に視覚フォーマットが追加

OpenAIの発表によると、新しい視覚広告は画像生成のタイミングで表示される。広告主は商品そのもの、使用シーン、サービスに関連する体験などを画像で表現できる。この広告は生成される画像とは別の領域に表示され、ChatGPTの回答内容には影響を与えない設計だ。

米国では今月下旬から一部の広告主を対象にテストが始まる。従来のChatGPT広告は広告主名、ロゴ、商品リンクを並べるだけのシンプルなスポンサー表示だった。今回の変更で、広告クリエイティブの表現力が一段階上がることになる。

従来のChatGPT広告(Before)
広告主名 + ロゴ + 商品リンク
テキスト中心のシンプルなスポンサー表示だけだった。
↓
新しい視覚広告(After)
商品画像 + 使用シーン + 体験イメージ
画像で商品の価値を直接伝えられる。

このデモでは従来のテキスト中心の広告と、画像を活用した新しい広告の違いを示した。視覚フォーマットは商品を直感的に伝えられる点が最大の変化だ。

週間12億人が閲覧する広告枠がECにもたらす意味

週間12億人が閲覧する広告枠がECにもたらす意味

ChatGPTの週間利用者数は12億人に達している。この規模のユーザーベースに商品画像を直接見せられる広告枠は、EC事業者にとって新しい集客チャネルになり得る。特に検索意図が明確な会話の中で商品を提示できる点が、従来のディスプレイ広告とは異なる。

ただし、新しい在庫が増えても基本的な疑問は残る。誰が本当にクリックしているのか、という点だ。広告の見た目が派手になるほど、実際の成果が見えにくくなるリスクもある。

商品を画像で見せられる価値

ECの集客では商品画像が購買判断に直結する。ChatGPTの視覚広告は、会話の文脈に合わせて商品画像を提示できるため、いわゆる「ついで買い」や「比較検討」の入り口になりやすい。従来のテキストリンクよりクリック率向上が期待できるフォーマットだ。

とはいえ、広告の露出が増えるほどBotによる不正クリックの影響も拡大する。次章でその実態を確認する。

BotクリックはGoogle広告の3.6倍。無効トラフィックの実態

BotクリックはGoogle広告の3.6倍。無効トラフィックの実態

広告検証を行うTrafficGuardは、47社の広告主から得たChatGPT広告の3週間分のトラフィックを分析した。無効クリック率はキャンペーンごとに0.1%から34%まで大きくばらついた。ほぼクリーンなキャンペーンがある一方で、コンバージョンの見込みがないトラフィックに料金を支払っていたケースも確認された。

調査では、比較的少数のBotがクリックの多くを生み出していた。あるホスティング事業者の15台のサーバーが、5社の広告主の広告を3週間で318回クリックしていた。さらに4つのホスティング・プロキシネットワークが47社中25社に到達し、分析で特定された無効クリックの半数を生み出していた。

ChatGPT広告のクリックはデータセンターやプロキシネットワーク経由がGoogle広告の3.6倍、実在し得ない端末設定からのアクセスは10倍だった。自動化されたトラフィックはまだ初期段階のChatGPT広告にすでに到達している。

Botクリック発生率の比較
ChatGPT広告 データセンター・プロキシ経由が 3.6倍
Google広告 同じ指標の基準値 1.0倍
47社のキャンペーンで無効クリック率は 0.1〜34% と大きなばらつき
実在し得ない端末設定からのアクセスは 10倍
■ ChatGPT広告 ■ Google広告 ■ 無効クリック率の範囲 ■ 不正端末由来

このデモではBotクリックの発生率をChatGPT広告とGoogle広告で比較した。ChatGPT広告はGoogle広告よりはるかに高い割合でBot経由のクリックが発生している。

自動化されたトラフィックへの見解

TrafficGuardの共同創業者兼CEOであるMathew Ratty氏は声明で、ChatGPT広告はまだ初期段階であるにもかかわらず自動化トラフィックはすでに到達していると述べた。同氏によれば、それは組織的で、持続的で、毎日クリックを続けているという。

EC事業者がChatGPT広告へ予算を投じる場合、Bot対策は無視できない要素だ。配信設定で除外すべきネットワークを絞り込み、無効クリックの発生率を定期的に確認する運用が求められる。

計測機能も拡張。HightouchやLiveRampと連携

計測機能も拡張。HightouchやLiveRampと連携

OpenAIは広告効果を測定する仕組みも拡張する。Hightouch、Tealium、LiveRampとの連携により、広告主はコンバージョンデータをChatGPT広告へ送信できるようになる。これにより、ChatGPT広告経由で実際に商品が購入されたかどうかを追跡しやすくなる。

EC事業者にとっては、広告クリック後の購入までの導線を数値で把握できる点が重要だ。ただし、Botクリックが混ざると成果数値が歪むため、無効クリックの除外とセットで運用する必要がある。

コンバージョンデータの連携フロー
ECサイト 購入データを計測 → Hightouch 連携ツール → ChatGPT広告 効果測定に反映
ECサイト 会員データを連携 → Tealium → LiveRamp で顧客照合
■ データ発生元 ■ 計測連携ツール ■ 広告プラットフォーム

このデモではECサイトからChatGPT広告へのコンバージョンデータの流れを示した。3つの連携ツールを使うことで、購入データを広告効果測定に反映できる。

EC事業者が取るべき対応

ChatGPTの視覚広告は新しい集客チャネルとして注目に値する。特に商品画像を自然な会話の流れで提示できる点は、従来の検索広告やSNS広告にはない強みだ。一方で、Botクリック率の高さは予算を毀損する要因になる。

まずは少額のテスト配信から始め、無効クリック率とコンバージョンの推移を確認するのが現実的だ。計測ツールとの連携を設定し、購入に至ったトラフィックの割合を継続的に追うことを推奨する。

この記事のポイント

  • ChatGPT広告に画像を使った視覚フォーマットが追加された
  • 新フォーマットは画像生成中に表示され、ChatGPTの回答には影響しない
  • ChatGPTの週間利用者数は12億人に達する
  • TrafficGuardの調査で無効クリック率は0.1〜34%と大きくばらついた
  • BotクリックはGoogle広告の3.6倍、データセンター経由が多い
  • Hightouch、Tealium、LiveRampと連携しコンバージョン計測を拡張
AI検索の7つの神話をデータで検証。サイト運営者が知るべき真実

AI検索の7つの神話をデータで検証。サイト運営者が知るべき真実

AI検索の台頭をめぐって「Googleは死んだ」「SEOは終わった」といった過激な主張が飛び交っている。しかし、実際のデータを確認すると、その多くが誤解や誇張であることが分かる。

本記事では、AI検索とSEOに関する7つの神話を取り上げ、調査データを基にそれぞれを検証する。サイト運営者やEC担当者が、感情的な主張に振り回されずに戦略を立てるための指針となるはずだ。

AI検索と従来型検索をめぐる3つの神話

AI検索と従来型検索をめぐる3つの神話
広まっている神話
ChatGPTやPerplexityの利用が増えるたびに、Googleなど従来型検索の需要は縮小している
↓
データが示す現実
AI検索も従来型検索も、四半期ごとにほぼ同じペースで成長している
■ 神話 ■ データに基づく結論

上の図は「AI対従来型検索」という二項対立ではなく、両者が共存して成長していることを示している。

AI検索は従来型検索を殺していない

「AI検索がGoogleを駆逐する」という主張は、感情には訴えるがデータと一致しない。State of Search Q2 2026レポートによると、AI検索と従来型検索は四半期ごとにほぼ同じ成長率で推移している。

つまり、AIプラットフォームは検索需要を奪っているのではなく、既存の検索需要の上に新たな層を追加している形だ。ただし、検索需要全体が伸びる一方で、Googleが自社画面内で回答を完結させる傾向が強まった結果、外部サイトへのクリック数は減少している。

同じ調査では、Google傘下以外のデスクトップ検索結果へのクリックが2025年4月以来の最低水準にあることも示された。検索意欲は伸びているが、Googleからオープンウェブへの送客は減っている構図だ。

ゼロクリック環境でもオーガニック流入は伸ばせる

「2026年にオーガニック流入を伸ばすのは不可能」という主張も誤りだ。AI OverviewやAI Modeの影響が強い分野では苦戦するものの、地元密着型の中小企業では2026年7月に過去最高のオーガニッククリック数を記録した事例が報告されている。

重要なのは、ゼロクリック圧力が全業界に均等にかかるわけではないという認識だ。ブログ記事とサービスページの両方で、ブランドに依存しない施策のみで成果を出した例もある。業界やビジネスモデルによって影響度は大きく異なる。

AI生成コンテンツでも上位表示は可能

「GoogleやLLMはAI生成コンテンツを検出して抑制する」という神話も根強い。しかし、2025年3月から9月にかけてAIで生成し軽い人間レビューのみを経て公開した4本の記事が、現在も上位表示とパフォーマンスを維持している事例がある。

Googleが低品質で独自性のないAI出力を評価しないのは事実だ。ただし検索エンジンが判断しているのは「AIが書いたか」ではなく「付加価値があるか」という観点である。良いアイデア、専門知識、独自データ、明確な視点から生まれたコンテンツなら、AIを執筆に使っても通常の記事と同じ扱いを受ける。

テクニカルSEOの神話を検証する

テクニカルSEOの神話を検証する
神話 4の主張
llms.txtを設置すれば、AI検索での表示頻度が上がる
↓
データが示す現実
Googleは公式に「llms.txtを使用しない」と明言。効果測定でも有意な変化なし

llms.txtは「AIが読むためのサイトマップ」として注目されたが、現時点ではインフラ整備の域を出ない。

llms.txtに過度な期待は禁物

llms.txtとは、AIクローラーがサイト内容を理解するためのテキストファイルである。AI検索での可視性を高める目的で導入するサイトが増えたが、この方法には明確な効果が確認されていない。

まず、Googleは公式ドキュメントで「AI検索の検出にllms.txtを使用しない」と明確に述べている。さらに、10サイトを対象にllms.txt導入前後の90日間を追跡した調査では、AIクロール頻度にもAI経由のトラフィックにも測定可能な変化が見られなかった。変化があったサイトも、他のSEO施策によるものだった。

結論としては、llms.txtは「戦略」ではなく「インフラ」である。設置して損はないが、それだけでAI可視性が改善するわけではない。

LLMはJavaScriptをレンダリングできない

「最新のAIクローラーはブラウザと同じようにJavaScriptを実行できる」という主張も事実と異なる。Profoundの調査によると、新興AI検索プロバイダーの多くはJavaScriptレンダリング機能を持たず、クライアントサイドレンダリングのコンテンツを読み取れない。

サーバーサイドレンダリング(SSR)がAI可視性の観点で重要なのはこのためだ。Headless CMSやJavaScriptに依存したサイトを運営している場合、AI検索にコンテンツを認識してもらえないリスクがある。

やっかいなのは、LLM自身がこの弱点を認めないことだ。実際にChatGPTにJavaScriptで隠された記事の要約を依頼したところ、「問題なく読める」と答えた後に、実は別の記事から内容を引用していたと認めた事例が報告されている。AIが「読める」と言っても、その言葉を鵜呑みにするのは危険だ。

AI流入の計測とSEOチームの価値

AI流入の計測とSEOチームの価値
AI経由の流入が計測から漏れる仕組み
AIチャット ブランド名を言及 → ユーザー 数時間から数日後にサイトを訪問 → 解析ツール 「直接流入」として記録
↓
計測上の問題
AI経由の訪問の約97%がUTMパラメータを持たず、直接流入や自然検索として計上される
■ AIチャット ■ ユーザー ■ 解析ツール

AIがブランドに言及してから訪問が発生するまでに時間差があるため、成果がAI由来と認識されにくい。

AI経由の流入は97%が計測されていない

AIがサイトに送るトラフィックは「誤差レベル」と思われがちだが、実際には大幅に過小評価されている。AIのブランド言及効果を調査した研究では、AIアシスタントがブランドを言及した後、そのユーザーは今後7日間に予測ベースラインの1.5倍から2.5倍の頻度でブランドサイトを訪問することが分かった。

注目すべきは計測の難しさだ。2026年5月のChatGPTアップデートで引用件数が増えた後でさえ、AI経由の訪問のうち追跡可能な参照パラメータを保持していたのは約2.5%のみだった。つまり約97%の訪問が直接流入や自然検索として記録され、AIが起点だった痕跡を残していない。

さらに訪問のタイミングも影響する。AI言及から1時間以内に訪問したのは20.5%、24時間以内でも42%にとどまり、初回訪問の多くは翌日以降に発生する。この時間差が、AI起点の流入を人間が認識しにくい理由だ。

SEO人材をAIで置き換えるのは時期尚早

「AIが監査も記事構成も技術修正もできるから、SEO担当者は不要になる」という主張も短絡的だ。NP Digitalの調査では、AIは人間より多くのエラーを検出できたが、重要度の高いエラーを見落とし、優先順位付けも不得手であることが示された。

AIは規模の面で優れており、大量の軽微なエラーを高速で検出する。しかし、キーワード調査や検索意図の判断といった大局的な意思決定は苦手だ。Altテキストの修正やメタディスクリプションの改善といった軽微な項目を「最優先」と誤って推奨することもある。

さらにAIは、存在しない修正方法を提案したり、既に存在するページを推奨したり、明らかに悪いアイデアに自信満々で同意したりする。AIはSEOの道具箱において強力なツールだが、人間の判断を完全に代替するには至っていない。

この記事のポイント

  • AI検索と従来型検索は同じペースで成長しており、共存関係にある
  • ゼロクリック圧力は業界によって異なり、適切なSEO戦略で成果は出せる
  • llms.txtはインフラであり、設置だけでAI可視性が向上するわけではない
  • AI経由の流入の約97%が計測されず、実際の効果は過小評価されている
  • SEOチームをAIで置き換えるのは時期尚早で、人間の判断力は依然として重要
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の現在の推奨だ
AI検索時代のGEO対策、ChatGPTやPerplexityに引用されるための技術SEOとコンテンツ戦略

AI検索時代のGEO対策、ChatGPTやPerplexityに引用されるための技術SEOとコンテンツ戦略

AI検索エンジンが情報取得の主流になりつつある。ChatGPT、Perplexity、Geminiなどの生成系エンジンは、質問に対する答えを直接生成する。従来の検索結果一覧からリンクをクリックする流れが変わり始めた。

この変化に対応するには、キーワード中心のSEOから生成エンジン最適化(GEO)への転換が必要だ。GEOとは、AIが回答を生成する際に自社コンテンツを一次情報源として引用してもらうための施策群である。従来SEOがブルーリンクのクリック獲得を目指すのに対し、GEOはAIの回答内で引用されることを目指す。

本記事ではAIクローラーへの技術対応と、AIに引用されやすいコンテンツ戦略の両面から具体的な施策を解説する。ECサイト運営者とWeb制作担当者に向けた内容だ。

GEOの基本を理解する

GEOの基本を理解する

生成エンジン最適化(GEO)は、AI検索エンジンが回答を合成する際に、自社サイトのコンテンツを情報源として検出・理解・引用されることを目的とする。従来SEOが「検索結果のクリック数」を評価指標にするのに対して、GEOは「AI回答内での引用率」を重視する。

従来のSEO(Before)
キーワードをページに詰め込み、検索結果のブルーリンクでクリックを獲得する。
対策例 → タイトルタグ最適化、メタディスクリプション、被リンク獲得
↓
GEO(After)
AIが回答を生成する際に、一次情報源として引用されるコンテンツを作る。
対策例 → 構造化データ、独自データ発信、直接回答フォーマット

従来SEOからGEOへの考え方の転換をBeforeとAfterで対比した。

AI検索エンジンがサイトを選ぶ仕組み

AI検索エンジンは検索拡張生成(RAG)という仕組みで回答を作る。RAGとは、事前学習済みの大規模言語モデル(LLM)にリアルタイムのWeb情報を取り込ませ、最新の情報を含む回答を生成する技術だ。AIは質問を受けると、関連するWebページを取得し、その内容を引用しながら回答を合成する。

つまりAI検索で自社サイトが引用されるには、AIが「このページは信頼でき、回答に使える」と判断できる状態にしておく必要がある。そのために技術SEOとコンテンツ戦略の両面から対策を進める。

AIクローラー対応の技術SEO

AIクローラー対応の技術SEO

AIプラットフォームは専用のクローラーとRAGパイプラインを使ってWebコンテンツを取り込む。技術チームは、独自データを保護しながらコンテンツへのアクセスを確保する必要がある。

STEP 1 Webページのコンテンツが公開される
↓
STEP 2 AIクローラーがアクセスして内容を取得
↓
STEP 3 RAGチャンキングで情報を適切な単位に分割
↓
STEP 4 ベクトルデータベースに埋め込みとして保存
↓
STEP 5 回答生成時に該当箇所が引用される

AI検索の裏側では、このようにクローリングから引用までの5段階の処理が走る。

robots.txtでボットを区別する

AI関連のクローラーは用途別に分かれている。学習用クローラー(GPTBotなど)とリアルタイム検索用クローラー(ChatGPT-User、PerplexityBotなど)を区別し、robots.txtで個別にアクセス制御する。学習用ボットをブロックすれば独自データを保護でき、検索用ボットを許可すればAI回答への情報提供を継続できる。

ECサイトの場合、商品の仕様データや価格情報は検索用ボットに公開しつつ、学習用ボットのアクセスを制限する運用が現実的だ。

構造化データでAIに文脈を渡す

Schema.orgの語彙を使った構造化データの実装範囲を広げることが重要だ。Organization、Product、HowTo、TechArticle、FAQPageなどのタイプを適切に付与すると、LLMのパーサーがエンティティ間の関係性を明示的に理解できるようになる。

ECサイトであれば商品ページにProductスキーマを付与し、価格、在庫状況、レビュー評価を機械可読な形式で伝える。AI検索エンジンが「この商品はいくらか」という質問に答える際、構造化データが整っているページが優先的に引用される。

RAGチャンキングを意識したHTML設計

RAGパイプラインはWebページを小さな単位(チャンク)に分割し、ベクトルデータベースに格納する。この分割処理を意識して、ページ構造を論理的なHTML階層で設計することが有効だ。<h2>や<h3>の見出しを適切に使い、各段落を独立して理解できる簡潔な長さに保つ。

見出しが明確で段落が短いと、RAGの分割処理が正確になり、回答生成時に該当箇所だけをクリーンに抽出・引用できる。長い段落に複数の話題を詰め込むと、チャンクの境界が曖昧になり引用精度が下がる。

表示速度とインデックス性の確保

AI検索エンジンはライブ検索の際、高速かつ安定したページ取得を優先する。モバイル対応を徹底し、サーバー応答時間(SRT)を短く保つことが重要だ。取得がタイムアウトすると、そのページは回答生成の候補から除外される。

SRTとはサーバーがリクエストに応答するまでの時間である。画像最適化、キャッシュ活用、CDN導入などでSRTを短縮しておくと、AIクローラーによるリアルタイム取得の成功率が上がる。

生成AIに引用されるコンテンツの作り方

生成AIに引用されるコンテンツの作り方

AI検索エンジンはハルシネーション(誤情報生成)のリスクを減らすため、権威性の高い情報源を優先的に参照する。コンテンツ戦略は「検証可能な情報密度」を軸に再設計する必要がある。

従来のコンテンツ構成(Before)
結論を後半に置き、導入文を長く書く形式。AIが要約しにくい。
導入3段落 → 背景説明 → 事例 → 最後に結論
↓
直接回答フォーマット(After)
冒頭に要約と結論を置く形式。AIが即座に抽出して引用できる。
要約表 → 結論 → 詳細説明 → 補足データ

AIが回答に使いやすいコンテンツ構成への変更点を示した。

エンティティベースの権威性構築

エンティティとは、人物、組織、商品、概念など明確に定義できる対象のことだ。自社ブランドの中核となるエンティティを中心に、関連する業界用語やトピックを密度高くまとめたトピッククラスターを作る。

具体的には、主語と述語が明確で断定を含む文章を心がける。「当社の商品Aは業界最高水準の耐久性を持つ」のような曖昧な表現ではなく、「商品Aは10万回の開閉テストに合格した」と具体的な事実を書く。このような文章はAIが抽出しやすく、引用時の信頼性も高い。

独自データとオリジナルリサーチの発信

AIモデルは集約された二次情報よりも、独自の統計、調査結果、オリジナルレポートを優先的に参照する。自社で実施したアンケート結果、商品の性能テストデータ、業界動向の独自分析などを公開することで、一次情報源としての地位を確立できる。

ECサイト運営者であれば、自社商品の比較テスト結果、顧客満足度調査、購入データから見える傾向などを記事化すると効果的だ。競合が真似できない独自データは、AI検索で安定的に引用される資産になる。

直接回答抽出フォーマットの採用

技術記事や教育コンテンツでは、ページの冒頭に要約表、箇条書きのポイント、明確な定義を配置する。検索意図の高い質問には、背景説明の前に直接回答する構成が有効だ。

たとえば「商品Aの防水性能はどの程度か」という質問を想定したページでは、冒頭に「IPX7等級で水深1メートルに30分間耐える」と明記し、その後に試験方法や比較データを展開する。この構成ならAIが回答をそのまま引用できる。

マルチモーダル検索への対応

AI検索エンジンは音声や画像を使った検索にも対応し始めている。マルチモーダル検索とは、テキスト以外の入力手段を含む検索のことだ。画像検索AIが商品を認識して回答するケースが増える。

商品画像や図表には説明的なalt属性を付与し、構造化されたキャプションを添える。画像の内容をAIが理解できるようにすることが、将来のマルチモーダル検索での可視性につながる。

AI検索を味方につける運用の転換点

AI検索を味方につける運用の転換点

従来のオーガニック検索トラフィックは、AIが直接回答を返すようになるにつれて集約化が進む可能性がある。ただし、技術インフラを最適化し、高密度な一次情報を公開し続ければ、ブランドはAI検索の裏側で推奨される情報源としての地位を維持できる。

重要なのは、目先のクリック数ではなく「AIに引用される確率」を評価指標に加えることだ。AI検索時代のブランド可視性は、回答の出典として選ばれる頻度で測られる。ECサイト運営者は、商品情報の構造化と独自データの発信を組み合わせ、この変化に対応すべきである。

SEO担当者と技術チームが協力し、クローラー管理からコンテンツフォーマットまでを一貫して整備すること。これがAI検索時代に競争優位を保つための実践的なアプローチだ。

この記事のポイント

  • AI検索時代には従来のキーワード中心SEOからGEO(生成エンジン最適化)への転換が必要
  • robots.txtで学習用ボットと検索用ボットを区別し、独自データを保護しつつ引用機会を確保する
  • 構造化データの拡充とRAGチャンキングを意識したHTML階層設計が技術SEOの柱になる
  • 独自データとオリジナルリサーチの発信がAIからの一次情報源としての地位を確立する
  • 冒頭に要約と結論を置く直接回答フォーマットがAIによる引用率を高める
AI検索がECを変える。検索クエリは6語から24語へ拡大

AI検索がECを変える。検索クエリは6語から24語へ拡大

AI検索エンジンの台頭により、ECサイトの商品発見の仕組みが根本から変わりはじめている。消費者は短いキーワードの組み合わせではなく、文脈や使用シーンを盛り込んだ長い自然言語で商品を探すようになった。

従来の検索エンジンでの平均クエリは約6語だった。一方、大規模言語モデル(LLM、人間のように自然な文章を理解・生成できるAIモデル)を活用したAI検索では、平均約24語にまで拡大している。この4倍の変化は、商品カタログとプロダクトページの設計思想そのものの見直しを迫るものだ。

この記事では、AI検索がECサイトに与える具体的な影響、対応策、そしてマーケティング担当者が見直すべき思考法について解説する。WooCommerceをはじめとするECプラットフォームを運営する事業者にとって、今後12ヶ月の優先課題が見えてくるはずだ。

AI検索が変える検索クエリの姿

AI検索が変える検索クエリの姿

消費者が検索窓に入力する言葉が劇的に変化している。かつては「防水 ランニング シューズ 軽量」のような短いキーワードの羅列が一般的だった。いまは「雨の日でも滑りにくくて、通勤でも使える軽いランニングシューズを探しています。週末は10キロ走るのでクッション性も欲しいです」といった会話調の質問に変わっている。

6語から24語へ、検索行動の変化

MarTechのポッドキャスト「Conversations with MarTech」に出演したOpiversalのCEO、Lucas Tieleman氏は、この変化を具体的な数字で示している。従来のGoogle検索での平均クエリは約6語だった。ところがLLMを活用した検索では平均約24語に拡大している。ユーザーは検索エンジンに「単語を投げる」のではなく「相談する」姿勢に変わったのだ。

会話的クエリが商品発見に与える意味

検索クエリが会話的になるということは、商品が文脈で選ばれる時代の到来を意味する。「軽いランニングシューズ」という単語だけでは用途が見えなかった。しかし「通勤で使える」「週末に10キロ走る」といった文脈が加わることで、同じ商品が異なる理由で選ばれる可能性が生まれる。Tieleman氏は「同じ商品でも、人によって異なる意味を持ちうる」と述べている。この多義性が、これからのECサイトの設計を難しくする一方で、差別化の余地も広げている。

従来の検索クエリ(Before)
「防水 ランニング シューズ 軽量」
平均6語前後。商品名と属性の単語を並べるだけの短いクエリ。
↓
AI検索時代のクエリ(After)
「雨の日でも滑りにくくて、通勤でも使える軽いランニングシューズを探しています。週末は10キロ走るのでクッション性も欲しいです。予算は1万5千円まで」
平均24語前後。会話調で文脈、使用シーン、予算まで含まれる。

検索クエリが短いキーワードから会話的な長文へ変化したことを示している。ECサイト側もこの変化に対応した情報設計が必要になる。

旧来の商品カタログが抱える限界

旧来の商品カタログが抱える限界

多くのECサイトの商品ページは、青いリンクとキーワード検索の時代に作られたものだ。商品名、価格、カテゴリ、簡単な説明文という最小限の属性を並べた静的ページが中心だった。この設計は、消費者が「単語を入力して結果の一覧から選ぶ」という行動パターンを前提にしている。文脈や使用シーンを含む24語のクエリに対して、こうした静的ページは十分な回答を提供できない。

ボットトラフィックの急増が見せる新しい現実

Tieleman氏が指摘するのは、AIエージェントによるボットトラフィックの急増だ。自律型AIエージェントが実際に購入を行う段階にはまだ至っていない。しかし、ユーザーの質問に答えるためにECサイトを巡回するLLMのトラフィックは爆発的に増えている。マーケティング担当者は、インプレッション(表示回数)とセールスの関係を従来とは異なる視点で捉え直す必要がある。表示回数が増えても、それが人間の目に触れているとは限らないからだ。

従来の商品データ(Before)
商品名 ランニングシューズ A
価格 12,800円
カテゴリ スポーツ
属性情報が少なく、検索エンジンにもAIにも商品の特徴が伝わりにくい。
↓
AI対応の商品データ(After)
防水性能 IPX4対応、雨天時も滑りにくい設計
使用シーン 通勤、週末の10kmランニング
クッション性 高反発ミッドソール、かかと部衝撃吸収
重量 片足230g(26.5cm時)
FAQ 幅広の足型に対応していますか? → 2E相当のゆったり設計です
会話的な属性情報とFAQを追加。AIが文脈に応じて商品を推奨しやすくなる。

文脈的な属性情報とFAQを加えることで、AIが商品を理解しやすくなることを示している。

ECサイトがAI検索に対応するための3つの施策

ECサイトがAI検索に対応するための3つの施策

AI検索時代において、ECサイトが取るべき具体的な対策は3つに集約できる。構造化データの整備、動的なランディングページ生成、そしてFAQの戦略的拡充だ。どれも特別なツールなしで今日から着手できる。

構造化データと会話的属性情報の整備

商品フィードの重要性はかつてないほど高まっている。構造化データとは、商品名や価格、属性などが機械に読み取りやすい形式で整理されたデータのこと。検索エンジンとAIプラットフォームに商品の存在を知らせるためには、高度に構造化されたデータを継続的に供給する必要がある。商品名と価格だけでは不十分だ。使用シーン、解決できる課題、関連するFAQなど、会話的な属性情報を追加することで、AIが商品を文脈に応じて提案しやすくなる。

WooCommerce運営者であれば、商品データの拡張は比較的容易だ。商品説明欄を充実させるだけでなく、カスタム属性やカテゴリタクソノミーを使って使用シーンや解決課題を明示的に登録できる。属性情報は商品のタイプごとに設計し、サイト全体で一貫した命名規則を保つことが重要だ。

動的なランディングページ生成

AIがコンテンツ制作の限界費用を大幅に下げたことで、EC事業者は変動するソーシャルトレンドや自然言語のクエリに合わせてカスタムランディングページを大量に生成できるようになった。Tieleman氏は「ウェブサイトは生きた有機体である」と表現している。固定された商品ページだけでなく、検索文脈に応じたランディングページを動的に用意することが、これからのECサイトには求められる。

FAQの戦略的拡充

FAQセクションは、AI検索対策の隠れた有力手段だ。商品に関する具体的な疑問と回答を構造化して掲載することで、AIエージェントが商品のユースケースを理解しやすくなる。「このシューズは幅広の足型に対応していますか」といった具体的な質問と回答は、まさに24語クエリの世界で求められている情報だ。FAQはユーザーが実際に抱く疑問を想定して作成し、商品データの一部として機械に読み取らせる意識が重要になる。

STEP 1 ユーザーがAIに自然言語で相談
「雨の日に通勤で使えるランニングシューズを探している」
↓
STEP 2 AIエージェントがECサイトを巡回
商品フィード、構造化データ、FAQを機械的に読み取る
↓
STEP 3 文脈に合う商品を抽出して提案
防水、通勤、クッション性など複数の条件を照合して候補を提示

AIエージェントが商品データを巡回し、文脈に合う商品を提案する流れを示している。各ステップで構造化データが正しく読み取れるかが成否を左右する。

エージェント型購買の現実とマーケティングの再考

エージェント型購買の現実とマーケティングの再考

Tieleman氏との対話から浮かび上がるのは、AIエージェントが本当に「購入」を行うのはまだ先だという現実だ。現在はあくまで調査・比較の段階で、ボットが商品情報を収集しているにすぎない。しかし、この段階で商品データがAIに正しく理解されているかどうかが、将来の購入決定に直結する。準備を怠れば、AI検索の世界で商品が存在しないのと同じ扱いを受けるリスクがある。

単一の正解に執着することの無意味さ

Tieleman氏は「マーケティング業界が信じている最大の嘘」として、単一の正解を探し求めることへの執着を挙げている。現実には、現代のテクノロジーを使えば複数の施策を並行して検証し、効率的に失敗しながら最適解に近づくことができる。同氏の「いまのテクノロジーを使えば、もっと効率的に間違えることができる」という指摘は、マーケティングの思考法を変える視点だ。A/Bテストを繰り返すことへの心理的障壁を下げ、失敗をデータとして蓄積する姿勢が求められる。

商品を文脈で選ばせる設計へ

「AppleはUXとデザインの重要性を示す好例だ。Amazonはそうではないことを示している」というTieleman氏の発言は、ECサイト設計の2つの方向性を端的に表している。徹底したUXで差別化するのか、価格と品揃えで勝負するのか。AI検索時代には、どちらの戦略を選ぶにせよ、商品データが文脈を伝えられるかどうかが成否を分ける。デザインの優劣ではなく、データの伝達力が新しい競争軸になるのだ。

この記事のポイント

  • 検索クエリは平均6語から24語に拡大し、会話調の質問へと変化している
  • 従来の静的カタログは、文脈を含む長いクエリに十分応えられない
  • AIエージェントによるボットトラフィックが急増し、商品データの構造化が必須になっている
  • 構造化データ、会話的属性情報、FAQの拡充がAI検索対策の3本柱となる
  • 単一の正解を求める思考を捨て、複数の施策を効率的に検証する体制が有効
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日に公開されたセキュリティ更新で、データベース更新は不要
  • 商品バリエーションギャラリーの無限再帰を修正し、独自テーマ利用時の白画面リスクを解消
  • メール経由の商品レビューにおける入力検証を強化し、不正データの投稿リスクを低減
  • 独自テーマやカスタムコードを運用中のサイトは、ステージング環境での事前確認を推奨
Googleが商品カルーセルを欧州で削除、EC事業者の有機的流入が激減

Googleが商品カルーセルを欧州で削除、EC事業者の有機的流入が激減

Googleが2026年9月、欧州経済領域(EEA)で商品カルーセルの表示をほぼ全廃した。EC事業者がGoogle検索からオーガニックで顧客を獲得する主要経路が突然消えた形だ。

オランダの分析プラットフォームProductriseの計測では、EEA圏内の商品カルーセル表示回数は90〜100%減少している。英国や米国では変化がない。この変更は欧州のEC事業者だけに影響する。

デジタル市場法(DMA)への対応が理由で、Googleは29年の歴史で最大の検索品質低下と述べる。この記事では、変更の実態、EC事業者への影響、そして取るべき具体的な対策を解説する。

商品カルーセル消失の実態

商品カルーセル消失の実態

商品カルーセルとは何か

商品カルーセルとは、Google検索で商品名を入力した際に検索結果の上部に表示される横並びの商品一覧だ。商品画像、商品名、価格、ショップ名が一目で確認でき、ユーザーは検索結果から直接商品ページへ遷移できる。EC事業者にとっては、Google Merchant Centerに商品情報を登録するだけでオーガニック流入を得られる重要な表示だった。

従来の検索結果(Before)
「ワイヤレスイヤホン」で検索した場合
商品A 9,800円 商品B 7,500円 商品C 12,000円 商品D 5,480円
※商品カルーセルが検索結果の上部に表示され、ワンクリックで商品ページへ遷移できた
↓
新しい検索結果(After)
同じキーワードで検索した場合
ショップ名A ショップ名B 価格比較サイトC アグリゲーターD
※ショップとアグリゲーターのリストのみ表示され、商品情報は直接表示されない

このデモは検索結果の表示変化を示している。商品カルーセルが消え、ショップリストに置き換わった。

90〜100%という減少幅

Productriseは数千件の検索クエリを毎日追跡している。同社の計測によると、ドイツ、フランス、オランダ、ベルギー、スウェーデンの5カ国で商品カルーセルの表示回数が90〜100%減少した。Productrise創設者のHugo Huijer氏は「わずか数日で90〜100%の減少が見られる。一方、英国、米国、オーストラリアなどEEA圏外では変化がない」とEcommerce News Europeに語っている。

EEAはEU加盟27カ国にノルウェー、アイスランド、リヒテンシュタインを加えた30カ国で構成される。対象となるのはこの30カ国に限られ、日本を含むEEA圏外の検索結果では従来通り商品カルーセルが表示される。

DMA(デジタル市場法)遵守が理由

DMA(デジタル市場法)遵守が理由

DMAの概要とGoogleの判断

DMA(Digital Markets Act / デジタル市場法)は、巨大プラットフォーム企業による市場支配を規制するEU法だ。2022年に成立し、Google、Apple、Meta、Amazon、Microsoftのような「ゲートキーパー」と指定された企業に対し、自社サービスを競合より有利に扱うことを禁じている。

Googleは、商品カルーセルがDMAの「自己優遇の禁止」条項に抵触する可能性があると判断した。商品カルーセルはGoogle Shoppingという自社サービスへの誘導を促進する機能であり、競合する価格比較サイトやアグリゲーターを不利にする。この判断に基づき、EEA圏内では商品カルーセルを削除し、代わりにショップ名とアグリゲーターのリストを表示する方式に切り替えた。

Shoppingタブの消滅

ドイツの業界プラットフォームSEO SüdwestのKristian Kunz氏によると、GoogleのタブナビゲーションからShoppingタブも削除された。「その他」メニューにも表示されず、残っているのはGoogle Shopping Ads(有料広告)のみだ。Googleは今回の変更について「29年の歴史で最大の検索品質低下」と述べている。これは同社の主張であり、DMA対応がいかに抜本的な変更であるかを示す言葉だ。

ここで重要なのは、変更の対象が「オーガニック表示」に限定されている点だ。Google Shopping Adsは有料広告であり、DMAの規制対象外としてEEA圏内でも引き続き表示される。Googleにとって広告収入は維持される構造となっている。

EC事業者への影響を読み解く

EC事業者への影響を読み解く

中小事業者と大手の明暗

この変更の影響は事業規模によって異なる。中小規模のEC事業者は、オーガニック検索からの商品ページへの直接流入が大幅に減る。商品カルーセルは商品名、価格、画像を直接検索結果に表示していたため、ユーザーがクリックする前に商品情報を確認し、そのまま商品ページに遷移できた。この経路が絶たれたことで、商品個別ページへの流入は激減する。

従来の流入経路(Before)
検索 → 商品カルーセル → 商品ページ(直接流入)
※ワンクリックで商品ページに到達できた
↓
現在の流入経路(After)
検索 → ショップリスト → 価格比較サイト → 商品ページ(間接流入)
※中間業者を経由し、クリック数が増える

このデモは流入経路の変化を示している。直接流入から間接流入へと質が変わった。

一方、大手小売業者にはプラスに働く面もある。ブランド認知度が高い大手は、ユーザーが直接サイト名やブランド名を検索する「ブランド検索」からの流入が増える可能性がある。Hugo Huijer氏も「多くの企業が戦略の基盤としてきた機能が消えた」と指摘しつつ、この変化を「オーガニック可視性の根本的な転換」と表現している。

Google Merchant Centerの価値低下

Google Merchant Centerへの商品登録の価値も大きく下がった。従来は登録した商品情報が商品カルーセルやGoogle Shoppingタブに表示されていたが、これらのオーガニック表示が消えた今、Merchant Centerへの登録は商品広告(Google Shopping Ads)を出稿する場合を除き、オーガニック流入を生まない。Kunz氏は「SEO for productsも、少なくともGoogle Shoppingに直接関係する施策に関しては重要性が低下した」と述べている。

EEA圏内のEC事業者が取るべき対策

EEA圏内のEC事業者が取るべき対策

カテゴリーページのSEO強化が最優先

Productriseは、商品カルーセルの代替としてカテゴリーページがオーガニック検索で重要性を増すと予測している。カテゴリーページとは、「ランニングシューズ」「ワイヤレスイヤホン」のような商品群をまとめたページだ。商品個別ページではなく、カテゴリーページが検索結果の上位に表示される可能性が高まる。カテゴリーページのタイトル、メタディスクリプション、コンテンツ、内部リンクを最適化する必要がある。

WooCommerceを使っているECサイトの場合、カテゴリーページの構造は比較的最適化しやすい。WooCommerceの商品カテゴリーはアーカイブページとして自動生成されるため、カテゴリーの説明文、タイトル、メタ情報を設定するだけで基本的なSEO対策ができる。さらに商品カテゴリーごとに固有のコンテンツを追加することで、検索エンジンからの評価を高められる。例えば「ランニングシューズ 選び方」のような購買ガイド記事をカテゴリーページに組み込むと効果的だ。

ショッピング広告と価格比較サイトの活用

オーガニック表示が消えたことで、有料広告の価値が相対的に高まった。Google Shopping AdsはEEA圏内でも引き続き表示されるため、予算に余裕がある事業者はショッピング広告への投資を増やすことを検討すべきだ。広告費は増えるが、商品カルーセルが消えたことで競合の有機的な露出も減少しており、広告のクリック率や費用対効果が改善する可能性がある。

同時に、価格比較サイトやアグリゲーターへの掲載を強化することも有効だ。Googleが表示するショップリストには、価格比較サイトやアグリゲーターが並ぶ。これらのサイトに商品を掲載することで、間接的にGoogle検索からの流入を確保できる。手数料は発生するが、オーガニック流入が激減した現状では、顧客獲得コストとして捉える必要がある。

STEP 1 カテゴリーページのSEO強化
↓
STEP 2 Google Shopping Ads の活用
↓
STEP 3 価格比較サイトへの掲載
↓
STEP 4 ブランド検索の強化

このデモはEC事業者が取るべき対策を4つのステップで示している。優先順位の高い順に並んでいる。

ブランド検索の強化と分散戦略

四つ目に、ブランド検索の強化がある。ユーザーが「ショップ名+商品名」で検索した際に、自社サイトが確実に上位表示されるようにする。Googleが商品カルーセルを削除しても、ブランド検索には影響がないためだ。ブランドの認知度を高めるためのコンテンツマーケティング、SNS活用、メールマーケティングにも投資すべきだ。特定のプラットフォームに依存しすぎない「分散戦略」が、今回のような突然の仕様変更への備えとなる。

この記事のポイント

  • GoogleがEEA圏内で商品カルーセルを削除、表示回数は90〜100%減少した
  • DMA(デジタル市場法)対応のためで、Shoppingタブも消滅した
  • カテゴリーページのSEO強化が今後の最重要課題となる
  • Google Shopping Adsと価格比較サイトへの掲載が代替流入手段として浮上する
  • 中小EC事業者は直接流入の減少で打撃を受け、大手はブランド検索で恩恵を受ける可能性がある
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事業者は動的価格設定プラグインの利用時に説明表示を追加する必要がある
  • データの出所と利用目的を追跡できるデータガバナンスが今後の課題になる