FTCが個人別価格表示に透明性要求。WooCommerce事業者の備え
米FTC（連邦取引委員会）がパーソナライズドプライシング、つまり顧客データに基づいて個人ごとに価格を変える手法に対する執行方針を提案した。2026年8月19日付の提案で、この手法そのものを禁止するものではない。価格がどのように決まったのかを消費者に明確に伝える透明性を求める内容だ。
ECサイトを運営する事業者、特にWooCommerceを使う中小企業にとって、今後の価格戦略とデータ活用の見直しにつながる重要な動きである。パブリックコメントは2026年9月25日まで受け付けている。
FTCがパーソナライズドプライシングの透明性を要求
パーソナライズドプライシング（個人別価格設定）とは、顧客の購買履歴や行動データを使って、同じ商品でも顧客ごとに異なる価格を提示する手法だ。FTCはこの手法を禁止する権限はないとしつつ、FTC法第5条（不公正または欺瞞的な行為の禁止）を根拠に透明性の確保を図る。
FTCが事業者に求めている内容は大きく3つある。
- 価格がパーソナライズされたものであることの明示
- なぜその価格になったのかの理由
- どのようなデータを使ったのかの説明
提案された執行方針の内容
FTCが示した方針では、価格がパーソナライズされたことを消費者に知らせる免責事項の表示が必要になる。たとえば「この価格はあなたの購買履歴に基づいてパーソナライズされています」といった説明を商品ページに追加することが想定される。
このデモは、価格表示に透明性の説明を追加する変化を示している。FTCの方針は、価格そのものの変更ではなく、消費者への説明責任を問うものだ。
マーケターへの影響
ここ数年、マーケターはサードパーティCookieの衰退を受けて、ファーストパーティデータ（自社で直接収集した顧客データ）を集めるよう奨励されてきた。そのデータ活用が「体験のパーソナライズ」から「価格のパーソナライズ」にまで拡大しているケースがある。FTCの提案は、この流れに透明性という歯止めをかけるものだ。
たとえば、ある小売業者が顧客の過去の購買履歴を分析し、この顧客は高くても買う傾向があると判断して、同じ商品を他の顧客より高い価格で提示するケースを考えてみる。FTCの提案では、この場合「価格が過去の購入履歴に基づいてパーソナライズされている」という説明が必須になる。
パーソナライズドプライシングとダイナミックプライシングの違い
FTCはパーソナライズドプライシングとダイナミックプライシングを明確に区別している。この区別は重要だ。ダイナミックプライシング（変動価格設定）は需要と供給に応じて価格を変動させる手法で、航空券やホテルの宿泊料金、配車アプリのサーチャージが代表例だ。繁忙期や悪天候時に価格が上がるのは、個人のデータではなく市場全体の需給に基づく。
一方、パーソナライズドプライシングは個人のデータに基づく。過去の購買履歴から「この顧客は高くても買う傾向がある」と判断して、同じ商品を他の顧客より高い価格で提示するようなケースだ。
この比較図は、2つの価格設定手法の根本的な違いを示している。FTCが問題視するのは後者のパーソナライズドプライシングである。
FTCが監視対象として挙げた具体例
FTCが挙げた具体例はかなり踏み込んでいる。外出が難しい消費者への食品販売、複数の子供のために牛乳を買う消費者、葬儀や緊急の用事で移動する消費者、医療緊急時の交通手段を必要とする消費者、犯罪被害に遭った直後に防犯カメラを探す消費者、店舗や駐車場にいながら小売サイトを閲覧する消費者などが挙げられた。これらは消費者が弱い立場にある状況で、パーソナライズドプライシングが使われることを特に問題視している。
この具体例から読み取れるのは、FTCが「事業者はデータをたくさん集めているが、すべてを理解しているわけではない」というメッセージをマーケターに送っている点だ。
WooCommerce事業者への実務的影響
日本のEC事業者にとって、FTCの方針は直接の規制対象ではない。ただし、海外向けに販売するWooCommerceサイトや、グローバルに展開する企業は注意が必要だ。また、日本でも個人情報保護法や景品表示法の観点から、同様の透明性が求められる可能性がある。
動的価格設定プラグインの注意点
WooCommerceでパーソナライズドプライシングを実装する場合、動的価格設定プラグインを使うことが多い。これらのプラグインは、顧客のログイン情報や過去の注文履歴、カートの中身などに基づいて価格を変更できる。今回のFTC方針を踏まえると、こうした機能を使う際に「価格がパーソナライズされていること」を明示する仕組みを追加する必要が出てくる。
このフローは、WooCommerceでパーソナライズドプライシングを導入する際の基本的な流れを示している。STEP 4の透明性の説明が、FTC方針への対応に該当する。
データガバナンスの課題
FTC方針への対応で最も難しいのが、データの出所と利用目的の管理だ。顧客データはCDP（カスタマーデータプラットフォーム）、ロイヤルティプログラム、パーソナライゼーションエンジン、AIエージェントなど複数のシステムに分散している。どのデータを価格設定に使ったのかを追跡できる状態にしておく必要がある。
MarTechの記事で、In-Store MarketplaceのPaul Brenner氏は「データの許可利用範囲と禁止範囲の線引きが難しく、多くの加盟店がシステムと透明性を備えていない」と指摘している。この課題は、FTCの執行方針が現実になった場合、EC事業者にとって大きなハードルになる。
今すぐできる3つの対策
FTCの方針はまだ提案段階だが、今から準備しておくことで、執行が始まった際の混乱を避けられる。具体的には次の3つだ。
1つ目は、価格表示に説明を追加すること。パーソナライズドプライシングを使っている場合、その旨を商品ページやカート画面に明記する。使っていない場合でも、価格がどのように決まるのかを説明しておくと、消費者の信頼につながる。
2つ目は、データ利用の同意取得を見直すこと。他社から取得したデータを価格設定に使う場合、消費者がその用途に同意しているかを確認する必要がある。単に「同意があるはず」と仮定するだけでは不十分だ。
3つ目は、データの利用目的を文書化すること。価格設定にどのデータを、どのように使っているのかを社内で整理し、必要に応じて開示できる状態にしておく。これがデータガバナンスの第一歩になる。
この記事のポイント
- FTCはパーソナライズドプライシングそのものを禁止せず、透明性の確保を求めている
- パーソナライズドプライシングは個人データに基づく価格設定で、ダイナミックプライシングとは異なる
- WooCommerce事業者は動的価格設定プラグインの利用時に説明表示を追加する必要がある
- データの出所と利用目的を追跡できるデータガバナンスが今後の課題になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Salesforce Winter ’27、マーケターが押さえるべき10の変更点
SalesforceのWinter ’27リリースにおける主要アップデートが公開された。マーケティング担当者に影響が大きい変更点は10項目あり、Agentforceによるキャンペーン自動化からボット調整済みクリック率まで幅広い。本記事では、ECやB2Bのマーケティング運用に関わる担当者向けに、各アップデートの実務的な意味を整理する。
Winter ’27は2026年8月下旬にプレビューサンドボックスへ展開され、本番環境へのリリースは9月4日、10月2日、10月9日の週末に段階的に行われる。Salesforceによると、全機能の一般提供は10月12日を予定している。組織が利用するインスタンスや製品によって更新日は異なるため、自社のリリーススケジュールを確認しておきたい。
Agentforceがキャンペーン運用を自動化する
Winter ’27で最も注目されるのは、Agentforce関連の新機能だ。マーケティング担当者の日々の業務を自動化するエージェントが複数追加された。特に影響が大きいのが、キャンペーン作成とリード育成を担う2つのエージェントである。
キャンペーン作成エージェントの実務インパクト
Salesforceは戦略立案からコンテンツ作成までを自動化するキャンペーン作成エージェントと、大量のリード獲得・育成に特化したエージェントを投入した。これまで単一の戦略をメール、SMS、ランディングページなど複数チャネルに展開する作業は、ツール間を行き来する煩雑なオペレーションになりがちだった。エージェントが一連の作業を引き受けることで、担当者は承認と戦略判断に集中できる。
このデモはキャンペーン運用の変化を概念的に示したものだ。実際のAgentforceはメールやSMS、ランディングページ向けのコンテンツを自動生成し、人間の承認を経て配信する。営業部門とマーケティング部門の往復が減ることで、キャンペーン立ち上げのスピードが大きく変わる。
メールに返信できる双方向エージェント
もう一つの注目機能は、マーケティングメールへの返信にAgentforceがリアルタイムで応答する「双方向メール」だ。従来のマーケティングメールは一方的な配信が基本で、見込み客が返信しても未対応のまま放置されることがあった。新機能ではエージェントが自動応答し、必要に応じてオムニチャネル受信箱を通じて人間の担当者へ引き継ぐ。購買意欲が高いタイミングで会話を始められる点が重要だ。
データ基盤と配信品質を強化する変更点
マーケティング成果の土台となるのが、データの正確さと配信の到達性だ。Winter ’27ではこの領域に複数の改善が入った。
メール到達性をリアルタイムで監視
Marketing Cloud NextとAccount Engagementのユーザー向けに、配信ボトルネックをリアルタイムで検出し、即座に解消するツールが追加された。これまで配信問題はキャンペーン終了後に発覚することが多く、ドメイン評価を傷つけてから対策するケースが少なくなかった。新機能は配信前に問題を検知し、対策を促す。
配信到達性はすべてのキャンペーン投資の前提になる。メールが届かない状態でクリエイティブやセグメントを改善しても成果には結びつかない。今回の変更で、配信インフラの健全性を維持しやすくなった。
重複プロフィールを減らすID解決ルールの拡張
データ品質の面では、ID解決ルールが拡張された。あいまいな名前表記を正規化し、メールアドレスや電話番号、住所を組み合わせて同一人物を判定するデフォルトのマッチングルールが追加されている。重複プロフィールはオーディエンス数を歪め、同じ相手に重複メッセージを送るコストを生む。プロフィール統合の精度が上がることで、セグメント設計やAIモデルの学習データが健全になる。
マーケティング運用をAIで効率化する
Winter ’27では、日常的な管理業務を自然言語で操作できる仕組みも拡充された。マーケティングオペレーション担当者の負荷を下げる変更だ。
MCPサーバーに40個の新ツール
Marketing Cloud EngagementのMCP（Model Context Protocol）サーバーに40個のツールが追加された。AIアシスタントがオートメーションの管理、コンテンツフォルダの整理、レコード操作などを実行できるようになる。これまではプラットフォーム管理やクエリ作成に専門知識が必要で、熟練スタッフの工数を毎週のように消費していた。自然言語で指示できる範囲が広がることで、経験豊富な人材はアーキテクチャ設計や戦略立案に集中できる。
このフローはMCPツールを活用した運用の一例である。実際にはMarketing Cloud Engagementの管理画面からAIアシスタントに指示を出し、裏側でMCPサーバーが対応するツールを呼び出す形になる。
コンテンツの再利用とパーソナライズ
チャネル横断コンテンツの管理も改善された。スクリプトベースのパーソナライズ、再利用可能な動的コンテンツブロック、一元管理できるブランドセンターが追加される。メール、SMS、ランディングページごとに似たメッセージ資産を作り直す運用は、コンテンツ負債とブランド不統一を生みやすい。一元化された資産を使えば、キャンペーン立ち上げが速くなり、すべての顧客接点でパーソナライズを一貫して適用できる。
レポートとプライバシー管理の精緻化
マーケティング成果を正しく測るための変更も入った。ボットによるクリックの除外と、トラッキングの細かい制御が主なポイントだ。
ボット調整済みクリック率
B2B Analytics for Marketersに加えて、クリック率レポートに自動ボットフィルタリングが導入された。セキュリティスキャナーなどの自動アクセスがクリック数を水増しすると、実際の見込み客がどのキャンペーンに反応したか分からなくなる。ボットを除外したクリーンなレポートにより、予算配分や最適化の判断を実際のオーディエンスデータに基づいて行える。
開封・クリック追跡の細かい制御
ビジネスユニット単位で、開封、リンククリック、高度な指標のトラッキングを個別にオン・オフできるようになった。地域ごとのコンプライアンス要件や社内のリスク許容度に合わせて、データ収集の範囲を調整しやすくなる。法務・コンプライアンス部門との連携がスムーズになり、顧客との長期的な信頼構築にもつながる。
このデモは設定の自由度を示す概念図である。実際には管理画面のトグルで各指標のトラッキングを個別に切り替える。
その他の管理機能アップデート
上記10項目以外にも、管理面のアップデートが複数含まれている。組織の構成によっては影響が大きいものもあるため、簡単に触れておく。
- 電話番号を非表示にしているユーザー向けのWhatsAppメッセージングサポート
- 複数アカウントのMarketing Cloudを単一のData Cloudインスタンスに接続するWhatsApp向け機能
- ユニークなクーポンコードと事前設定済みの小売ジャーニートリガー
- Journey Builderの判定スプリットに関する診断ログ
- 一括削除とコンテンツ整理ワークスペースの強化
- セキュリティダッシュボード、クライアントシークレット管理、フィッシング耐性認証
- プライバシー監査向けのデータ拡張アクセスログ
- Automation Studioにおける大文字小文字を区別しないファイル名トークン
Winter ’27にはセキュリティ関連のアップグレードも含まれている。管理チームは自社の設定に影響がないか、リリースノートの確認を推奨する。
この記事のポイント
- Agentforceがキャンペーン作成からメール返信までを自動化し、担当者は戦略に集中できる
- 配信到達性のリアルタイム監視とID解決ルールの拡張で、マーケティングの基盤が強化された
- MCPサーバーのツール追加により、自然言語での管理業務が拡大した
- ボット調整済みクリック率と細かいトラッキング制御で、レポート精度とプライバシー対応が両立する
- Winter ’27の一般提供は2026年10月12日を予定しており、組織ごとのリリース日程を確認する必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開
TikTok ShopがEU加盟8カ国と英国の間で越境販売を開始する。出品者は自国の外にいる消費者へ直接商品を届けられるようになる。9月21日のパイロット運用を経て、10月19日に本格展開へ移行する流れだ。
越境ECの選択肢が増えることで、中小規模の事業者にも新たな販路が開ける。英国市場では30万以上の小規模事業者がTikTok Shopを利用している。EU側の出品者にとって英国市場へのアクセスは魅力的な拡張機会になるだろう。
本記事では越境販売の仕組み、販売条件、EC事業者への影響を解説する。特にWooCommerceで自社ECを運営する事業者にとっての意味合いも掘り下げる。
TikTok Shopの越境販売、全体像
このデモでは双方向の越境販売フローを示した。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事業者が知るべき販売条件
越境販売に参加するには、いくつかの条件を満たす必要がある。特に英国向け販売では配送方式が重要になる。
Ship by Seller方式の詳細
英国向け販売で使える配送オプションは「Ship by Seller」のみである。これは出品者が自ら配送業者を選び、配送料を支払い、配送トラブルが起きた場合も顧客対応を行う方式だ。TikTok Shop公式の説明でも「配送業者を選び、配送料を支払い、配送がうまくいかなかった場合の顧客対応も行う」とされている。日本で言えば、マーケットプレイスではなく自社発送に近い形態である。フルフィルメントをTikTok側が代行するわけではないため、越境配送の手配とコスト管理は出品者自身の責任になる。
この3ステップがShip by Seller方式の全体像だ。配送業者の選択から顧客対応まで、出品者側に責任が集中する。越境販売では関税や返品対応も加わるため、国内発送以上に準備が求められる。
販売対象になるための要件
越境販売の対象になるには、次の要件を満たす必要がある。対象EU市場でTikTok Shopにすでにアクティブであること、アカウントが良好な状態であること、最近の販売実績があること、大きな未払い残高がないこと。英国からEUへの販売では、リアルタイムのアカウント評価が対象判断に使われる。
4つの要件を色分けして示した。英国からEUへの販売は、これらに加えてリアルタイムのパフォーマンス評価が使われる。出品者側は日頃からアカウント状態を良好に保つことが前提になる。
越境ECとしてのTikTok Shopの戦略的意味
TikTok Shopの越境販売は、欧州市場を一つの商圏として統合する動きだ。従来のECモールは国ごとにアカウントや出品設定が必要だったが、Sell Across Europeと英国への拡張により、一つのアカウントで複数国にリーチできるようになる。特に英国市場は購買力が高く、EU側の事業者にとって有望な販売先である。越境ECの障壁だった言語や通貨、配送の問題をTikTokがどこまで解決できるかが、今後の成長を左右する。
本サイトの見方として、TikTok Shopの越境販売はソーシャルコマースの越境展開という新しい段階に入ったことを示す。InstagramやFacebookと異なり、TikTokのショート動画とECが一体になった体験が、国境を越えた購入を後押しする可能性がある。一方で、Ship by Seller方式による出品者負担の配送は、越境ならではの関税や返品対応の複雑さを考慮すると、小規模事業者にとっては高いハードルになり得る。ここが普及の鍵になるだろう。
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との併用で越境販売の機会を探れる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策
Googleの広告テック事業をめぐる独占訴訟で、米連邦地裁は事業分割を命じず、行動制限という形で決着をつけた。裁判所はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築いたと認定したものの、AdXの売却は求めなかった。
この判決は、EC事業者が日々利用しているプログラム広告のインフラに直接関わる。広告費の流れやオークションの透明性が変わる可能性があり、広告運用の見直しが必要になる場面も出てくる。
本記事では、判決の内容を整理し、EC事業者やWooCommerceサイト運営者が知っておくべき影響と対策を解説する。
判決の概要と独占認定のポイント
司法省は2023年、Googleが広告テック事業で複数の市場を支配し、競争を抑圧しているとして提訴した。2025年4月、ブリンケマ判事はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築き、両製品を不当に抱き合わせたと認定した。一方、アドバタイザー向けツールでの独占は認定されなかった。
この区別は重要だ。Googleは広告主とパブリッシャーの間に位置し、パブリッシャー側の在庫管理と、その在庫を広告需要と結びつけるオークションの両方を運用している。つまり、売り手と市場の両方を支配している状態だ。
分割要求が退けられた理由
司法省はGoogleに対し、広告エクスチェンジ「AdX」の売却を要求した。しかしブリンケマ判事は、分割は困難で混乱を招く可能性が高いと判断した。判事は救済措置の審理で、誰がエクスチェンジを買うのか、買った後にどう運営するのかと疑問を呈し、違法行為を止める方が現実的な救済になると述べたという。
判決の完全な内容はまだ一部が封印されており、詳細は明らかになっていない。公開された命令では、提案された行動制限のほとんどが修正付きで受け入れられたとされている。
広告オークションのルールはどう変わるのか
裁判所は以前、Googleが「ファーストルック」と「ラストルック」という慣行を使ってAdXを有利にしていたと認定した。ファーストルックは、Googleがパブリッシャーの在庫に最初にアクセスできる仕組みだ。ラストルックは、競合の入札情報を見てから自社の入札額を決められる仕組みだった。
今回の救済措置では、これらの優位性が制限される。パブリッシャーは価格設定の自由度を高め、競合するパブリッシャー向け広告サーバーにはGoogleのAdX入札情報がリアルタイムで提供される見込みだ。
この変更により、競合する広告テック企業が在庫獲得で公平な条件で競争できるようになる。広告主にとっては、オークションのダイナミクスやサプライパス、価格設定、パブリッシャーに届く広告費の割合が徐々に変わる可能性がある。
EC事業者が知っておくべき広告費の透明性
この判決は、広告費の流れを可視化する重要性を高めている。特にEC事業者は、Googleショッピング広告やディスプレイ広告を通じて商品を宣伝する。広告費がどの経路を通り、どれだけパブリッシャーに届くのかを理解することが、投資対効果の改善につながる。
Googleは依然として広告テックの主要インフラを所有している。行動制限は一部の優位性を取り除くが、パブリッシャーと広告主はGoogleが独占を維持してきたシステムの中で運用を続けることになる。
上図の通り、Googleはパブリッシャー向け広告サーバーとエクスチェンジの両方を所有している。このため、広告主が支払った金額の一部が中間レイヤーで差し引かれ、パブリッシャーに届くまでに目減りしやすい構造だ。判決後のルール変更がこの構造をどこまで変えられるかが焦点になる。
今後の広告運用にどう備えるか
短期的には大きな変化はない
マーケターは来週からプログラム広告キャンペーンが劇的に変わるとは考えない方がよい。オープンウェブ広告の成長はすでに鈍化しており、YouTubeやInstagram、Amazonなどへの支出シフトが進んでいる。Appleのプライバシー変更によるモバイルトラッキング制限もこの流れを加速させた。
それでも、判決はサプライパスの透明性をより重要にする。マーケターは自社の広告費がどのエクスチェンジや中間業者を経由しているか、各広告費のうちどれだけがパブリッシャーに届いているか、Googleのスタック以外の選択肢が現実的になってきたかを注視する必要がある。
サプライパスの見直しと代替手段の検討
EC事業者にとって具体的な対策は、広告配信のログやレポートを定期的に確認し、中間マージンが過大な経路を特定することだ。Googleの広告テック以外にも、競合するエクスチェンジやパブリッシャー向けサーバーが存在する。判決後の環境変化を見極めつつ、複数の選択肢をテストすることが推奨される。
MarTechの記事では、行動制限は「実験」にすぎず、競合がこの機会を利用してGoogleから大きなシェアを奪えなければ独占は続くと指摘している。つまり、他の事業者がGoogleの支配に対抗できるかどうかが、今後の市場の行方を左右する。
この記事のポイント
- Googleは広告テック独占で違法認定されたが、AdXの売却は命じられず、行動制限のみが課された
- ファーストルックとラストルックの制限により、競合広告テックが公平に競争できる可能性が出てきた
- EC事業者は広告費のサプライパスを可視化し、中間マージンの過大な経路を特定することが重要
- 短期的に広告運用が激変することはないが、代替手段のテストと環境変化の注視が推奨される
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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ではブロックを描画しないAPIリクエストが登録処理を飛ばし、その分だけレスポンスが速くなる。
描画しないリクエストに課されるコスト
従来の挙動は、ブロックを編集も描画もしないリクエストまでブロックエディタの準備をさせるものだった。この無駄はアクセス数に比例して増える。とくにモバイルアプリやフロントエンドを別システムで構築し、WooCommerceをAPI経由で使う構成では影響が大きい。
今回の最適化は、APIリクエスト全体に占めるブロック登録のコストが想定以上に大きかったことを示している。13〜18ミリ秒の改善は体感的には小さいが、ピーク時に多数のリクエストを処理する店舗では合計の短縮効果が積み上がる。
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でも説明が正しく描画される。
2段階の変更により、パターン読み込みとブロック登録という2つの重い処理がAPIリクエストから外れた。完成した最適化の効果が30〜42%という数字に表れている。
対象リクエストと安全性の設計
スキップ対象と従来どおりのリクエスト
スキップされるのはブロックを描画しないリクエストのみだ。フロントエンド、管理画面、ブロックエディタ、サイトエディタのリクエストは従来どおりブロックを登録する。
見落としがあっても表示は壊れない
ガードは自身が認識したコンテキストだけをスキップする。認識できない場面では登録を継続するため、分類に漏れがあったとしても描画の後退にはつながらない。性能が少し落ちるだけで済む設計だ。
この設計は保守性の面でも合理的だ。未知のリクエストに対して安全側に倒すため、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でブロックを作る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.1で注文撤回機能が登場、14日以内の自己対応を実現
WooCommerce 11.1に注文撤回（Order Withdrawal）機能が追加された。EU域内の消費者が持つ14日間の契約撤回権に対応するための仕組みで、顧客が店舗にメールや電話で問い合わせることなく、注文から14日以内であれば自分で撤回リクエストを送信できるようになる。
この機能は既定では無効化されている。すべてのストアに必要な機能ではないため、事業者が設定画面から明示的に有効化する方式だ。顧客向けのリクエストフォーム、自動確認メール、店舗側の通知まで一連のフローが組み込まれている。
本記事では注文撤回機能の概要、有効化の手順、顧客と店舗それぞれの画面で何が起きるのかを解説する。EU向けに販売するストア運営者は特に確認しておきたい内容だ。
注文撤回機能とは何か
注文撤回機能は、EUの消費者保護規則で定められた「注文撤回権」に対応するための機能だ。EU域内の消費者は、商品やサービスを注文した日から14日以内であれば、理由を説明せずに契約を撤回する権利を持つ。従来はこの手続きをメールや電話で行う必要があり、店舗側も個別に対応する必要があった。
EUの14日間撤回権とは
14日間の撤回権はEU消費者権利指令に基づく制度で、オンライン購入を含む通信販売に適用される。消費者は商品を受け取った日から14日以内に撤回を申し出ることができ、事業者は返金に応じる義務を負う。この規則はEU域内の消費者との取引に適用されるため、日本からEU向けに販売するストアも対象になりうる。
重要なのは、注文撤回機能は法的手続きの自動化ツールであって、コンプライアンスを保証するものではないという点だ。WooCommerce Developer Blogの記事でも、事業の内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
従来の対応との違い
従来のフローでは、顧客がメールや電話で撤回の意思を伝え、店舗担当者が手動で注文を確認し、返金処理を行っていた。この方式には対応漏れや記録不足のリスクが伴う。注文撤回機能は、顧客が自己対応フォームからリクエストを送信し、システムが自動で記録と通知を行う。
このデモで示した違いは大きい。顧客からの撤回リクエストがシステムに記録され、確認メールが自動送信されることで、店舗と顧客の双方に証跡が残る。対応の属人化を防ぎ、処理の一貫性を保てる。
有効化の手順
注文撤回機能は既定では無効化されている。EU向け販売を行っていないストアでは不要な機能のため、必要な事業者だけが有効化する設計だ。設定はWooCommerceの管理画面から数ステップで完了する。
設定画面での操作
WooCommerceの設定画面を開き、詳細設定タブから機能セクションに移動する。そこに注文撤回のオプションが表示されるので、有効化して変更を保存するだけだ。設定完了後、顧客向けのリクエストフォームが /my-account/withdraw-order というURLで公開される。
エンドポイントのカスタマイズ
リクエストフォームのURLは変更できる。詳細設定のページ設定セクションでエンドポイントを編集すれば、自社の導線に合わせたURLに調整できる。標準のURLは /my-account/withdraw-order だ。
もう1つの重要な特徴として、このページはログイン状態に関わらず動作する。ゲスト購入した顧客でもフォームにアクセスしてリクエストを送信できる。EUの撤回権はゲスト購入者にも適用されるため、この設計は実務上欠かせない。
顧客から見た注文撤回フロー
顧客が注文撤回ページにアクセスすると、短いリクエストフォームが表示される。必要な情報を入力し、送信前に内容を確認する画面を経てから送信する。送信後は確認画面が表示され、入力した内容を含む確認メールが自動的に届く。
この4ステップのフローは、顧客が自分の操作だけで撤回リクエストを完了できることを示している。確認メールには顧客が入力した内容が含まれるため、顧客はリクエストの記録を残せる。店舗側への電話やメールが不要になり、双方の手間を削減する。
確認メールが自動送信される点は法的にも意味がある。撤回権の行使を顧客が証明できる記録が残るため、後日のトラブルを防ぐ効果が期待できる。
店舗運営者から見た通知と管理
顧客がリクエストを送信すると、店舗運営者には2つの経路で通知が届く。1つは撤回リクエストを知らせるメール通知、もう1つはWooCommerceホーム画面のインボックス通知だ。この二重の仕組みにより、リクエストの見落としを防ぐ。
リクエスト内容に含まれる注文番号と請求先メールアドレスが既存の注文と一致する場合、リクエストは自動的にその注文に紐付けられ、注文メモが追加される。これにより、店舗担当者は注文詳細画面からリクエストの存在を確認できる。
一致する注文が見つからない場合でも、リクエスト自体は受け付けられ、顧客には確認メールが送信される。通知には手動確認が必要であることを示すフラグが付けられ、注文へのリンクはスキップされる。この設計により、注文番号の入力ミスやゲスト購入の注文でも、リクエストが拒否されることはない。
重要な点として、撤回リクエストの送信は注文ステータスを変更しない。注文が自動的にキャンセルされたり、返金が実行されたりすることもない。リクエストはあくまで「撤回の申し出」であり、その後の対応（返金の承認、商品返送の依頼、追加情報の確認など）は店舗側の判断に委ねられる。
導入前に確認すべき注意点
注文撤回機能は店舗運営の効率化に寄与するが、いくつかの注意点がある。まず、この機能がEUの法的要件への準拠を保証するわけではないという点を理解しておく必要がある。WooCommerce Developer Blogの記事でも、事業内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
リクエスト処理のワークフロー設計
撤回リクエストが届いた後の対応フローは、店舗自身で設計する必要がある。返金を承認するのか、商品の返送を求めるのか、追加情報を確認するのか。これらの判断基準を事前に決めておかないと、リクエストが届いてから担当者が迷うことになる。
特に、注文ステータスが自動変更されない点は運用上のポイントだ。リクエストが届いても注文は「処理中」などの状態のまま残るため、店舗側で明示的に注文をキャンセルする処理が必要になる。この部分を社内で共有しておかないと、注文が放置されるリスクがある。
ゲスト購入への対応
ログインしていない顧客でもリクエストを送信できる設計は、ゲスト購入が多いストアにとって重要な特徴だ。ただし、ゲスト購入の注文は注文番号とメールアドレスの照合が手動になる可能性がある。手動確認フラグが付いたリクエストを担当者が見逃さないよう、通知の確認ルールを決めておく必要がある。
実務的には、EU向け販売を行うストアにとって注文撤回機能は顧客対応の手間を大幅に減らす可能性がある。メールや電話での個別対応から、システム化されたリクエスト処理へ移行することで、対応の一貫性と記録の完全性が向上する。一方で、リクエスト受信後のワークフローが未整備のままでは、かえって対応が遅れるリスクもある。
注文撤回機能は、WooCommerce 11.1の新機能としてEU対応ストアに実用的な選択肢を提供する。導入を検討する場合は、機能の有効化だけでなく、社内の対応フローまで含めて計画することをおすすめする。
この記事のポイント
- WooCommerce 11.1に注文撤回機能が追加され、顧客が自己対応で撤回リクエストを送信できる
- EUの14日間撤回権に対応する仕組みで、既定では無効化されている
- 顧客はフォーム入力から確認メール受信まで自動フローで完了できる
- 店舗にはメールとインボックスの二重通知が届き、注文への自動リンクも行われる
- 注文ステータスは自動変更されないため、受信後のワークフロー設計が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.1ベータ版が公開！EU注文撤回と返金APIの全容
WooCommerce 11.1のベータ版が公開された。今回のリリースではEU顧客向けの注文撤回フロー、REST APIの新しい返金計算エンドポイント、バリエーション商品のパフォーマンス改善が柱となる。正式版は2026年9月1日にリリース予定だ。
この記事では開発者向けブログの情報を基に、主要な変更点と実務への影響を解説する。ストア運営者とエクステンション開発者の双方が押さえておくべきポイントをまとめた。
WooCommerce 11.1の全体像
WooCommerce 11.1には大きく4つの改善領域がある。EU消費者保護に対応する注文撤回機能、返金計算を自動化するREST APIエンドポイント、商品CSVのインポートとエクスポートのバグ修正、そしてバリエーション商品の表示速度向上のためのパフォーマンス修正だ。
これらに加え、エクステンション開発者向けの互換性修正も複数含まれる。ブロック登録のスキップによる管理画面の負荷軽減、エディタアセットの統合実験など、開発者向けの変更も見逃せない。なお、この段階ではあくまでベータ版であり、フィードバックが募集されている。
この図はWooCommerce 11.1の4つの柱を示している。それぞれの詳細を順に見ていこう。
EU顧客向けの注文撤回フローが登場
WooCommerce 11.1では、EU消費者保護指令に基づく注文撤回権（right of withdrawal）に対応する機能が追加された。顧客はマイアカウントの専用ページから注文撤回を申請できる。EU圏では消費者が契約後一定期間内に理由なく注文を取り消せる権利が法律で定められている。この機能はその権利をストア運営者がスムーズに扱うための仕組みだ。
顧客が注文撤回を申請すると、ストア運営者にメール通知と管理画面のインボックス通知が届く。加盟店はその通知を確認して返金手続きを進める流れだ。申請時に認証は不要で、顧客は管理画面のワードプレスログインを必要としない。これはEUの消費者保護の原則に沿った設計である。
注文撤回の申請から返金までの流れはこの3ステップで完結する。ストア運営者は通知を確認してから対応すればよいため、顧客とのやり取りを記録しやすい。
この機能はデフォルトでは無効化されている。利用するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、注文撤回機能を有効化する必要がある。EU圏向けにストアを運営している場合は導入を検討したい。
REST APIの返金エンドポイントが強化された
返金処理を外部システムから操作する開発者にとって大きな変更が入った。WooCommerce REST APIの返金フローが更新され、サーバー側で返金額を自動計算できるようになった。従来は返金額を手動で計算してリクエストに含める必要があったが、その手間を省ける。
既存の返金エンドポイントに compute_totals フィールドが追加された。このフィールドに true を指定すると、WooCommerceサーバーが商品代金、送料、税を自動的に計算して返金額を確定する。計算ミスによる返金誤りを防げるのが利点だ。
POST /wc/v3/orders/123/refunds
{
"compute_totals": true
}この例では注文番号123に対して返金リクエストを送信している。ボディに compute_totals を指定するだけで、あとはWooCommerceが注文の明細を基に返金額を算出する。手動で計算する必要がなくなった。
さらに新しいプレビューエンドポイントも追加された。POST /wc/v3/orders/123/refunds/preview を使うと、実際に返金を実行せずに計算結果だけを確認できる。返金額を事前に検証したいケースや、顧客に返金額を提示する前に確認したいケースで重宝する。
POST /wc/v3/orders/123/refunds/previewこのプレビューエンドポイントは、返金処理を自動化するシステムを構築する際にデバッグと金額確認を容易にする。実際に返金を実行せずに結果を確認できるため、開発環境でのテストにも適している。
compute_totals を true にするだけでサーバーが自動計算この比較が示すように、返金処理の負担が大きく軽減された。外部システムから返金を自動化する際の堅牢性も向上している。
Store APIのチェックアウト金額チェック
Store APIにも改善が入った。チェックアウトエンドポイントに expected_total というオプションフィールドが追加された。このフィールドには顧客が画面上で確認した合計金額を整数で指定する。サーバー側で計算した金額と一致しない場合、リクエストは失敗し、新しい 409 エラーレスポンスが返される。
このエラーレスポンスのコードは woocommerce_rest_checkout_total_mismatch で、金額の不一致が発生したことをシステムが判別できる。顧客が画面で見た金額と実際に請求される金額が食い違う事故を未然に防ぐための仕組みだ。
この仕組みはチェックアウトの金額改ざんや画面表示の不整合を検出するために有効だ。決済処理を独自に実装している場合は特に注目したい。
バリエーション商品のパフォーマンス改善
バリエーション商品を多数抱えるストアでは、商品編集画面や店舗フロントの表示が遅くなる問題があった。WooCommerce 11.1ではこの問題に対処する複数のパフォーマンス修正が含まれている。主な改善は、バリエーションと属性の読み込み時に発生するN+1クエリの削減だ。
N+1クエリとは、1つの親データを取得した後、子データを1件ずつ追加で取得してしまう非効率なデータベースアクセスのことだ。たとえば100件のバリエーションがあると、101回のクエリが実行される。修正後は必要なデータをまとめて取得するため、クエリ回数が大幅に減る。
加えて価格キャッシュの処理も改善された。変動価格商品の価格計算ではキャッシュを活用してクエリを削減している。管理画面とフロントエンドの両方で、商品数の多いストアほど体感できる差が生まれるはずだ。
ブロック登録の条件付きスキップ
WooCommerce 11.1では、ブロックタイプとパターンの登録処理が見直された。従来はほぼすべてのリクエストでブロックが登録されていたが、新しい BlockRegistrationContext ガードを導入し、cron、AJAX、REST APIリクエストでは登録をスキップするようになった。
フロントエンド、管理画面、エディタの動作は従来通り維持される。つまり、実際にブロックを描画または編集する場面でのみ登録が走り、不要な場面では処理を省く。これにより管理画面のバックエンド処理が軽くなる。
1つ例外がある。商品やバリエーションの説明文にWooCommerceブロックが含まれている場合、woocommerce_short_description フィルターを通じて必要に応じてブロックタイプが登録される。商品REST API、Store API、バリエーションAJAXエンドポイント、商品ウェブフックでも説明文が正しく描画される。
エクステンション開発者への影響もある。すべてのリクエストでブロック登録が走ることを前提にした実装は修正が必要になる。新しい woocommerce_should_register_blocks フィルターで、スキップされたコンテキストでもブロックを登録するようにオプトインできる。
メールエディタの更新
ブロックベースのメールエディタにも機能追加があった。core/embed ブロックが、クリック可能なサムネイルを描画するプロバイダーで挿入できるようになった。対象はYouTube、Vimeo、VideoPress、TikTok、Dailymotion、そしてWordPressの埋め込みだ。WordPressの埋め込みはリッチなリンクカードとして表示される。
オーディオプロバイダーは対象外だ。また、未対応のプロバイダーからの埋め込みは貼り付けることはできるが、エディタが警告を表示し、配信時にはリンクとして送信される。メールに動画サムネイルを入れたい場合は、対応プロバイダーのURLを使うとよい。
パーソナライゼーションタグのコールバックにも改善が入った。タグが送信先のコンテンツタイプを受け取れるようになり、HTML、プレーンテキスト、href 属性のそれぞれに適切にエスケープできるようになった。新しいパラメータはオプションで、デフォルトはHTMLだ。自動エスケープは新しく登録されたテキスト型タグにのみ適用される。
実験的機能のプレビュー
WooCommerce 11.1には2つの実験的機能が含まれている。1つは統合ブロックエディタアセットだ。ブロックごとに個別のスクリプトとスタイルを読み込む代わりに、共有のJavaScriptとCSSバンドルに置き換える仕組みである。
テストによると、エディタのアセット数が91.7%削減され、ネットワーク転送サイズが48.3%減少、スタイルバンドルは62.3%小さくなった。フロントエンドのアセットには変更がない。デフォルトでは無効で、WooCommerceの設定画面から「詳細 → 機能 → 実験的機能」と進んで有効化できる。
この実験的機能が正式採用されれば、ブロックエディタの読み込み速度が大きく改善される。開発段階の指標ではあるが、かなり有望な結果だ。
もう1つの実験的機能は商品ギャラリービデオの内部ストレージだ。商品ギャラリーに動画を追加する第一歩として、動画データを保存する内部構造がフラグの後ろに実装された。設定画面から「商品ギャラリービデオ（ベータ）」を有効化すると使える。
開発者向けの互換性注意事項
WooCommerce 11.1では開発者が把握しておくべき互換性修正が複数含まれている。is_rest_api_request() 関数は、これまで /wp-json/ のパーマリンクパスのみでRESTリクエストを検出していた。今回の修正で、空でない rest_route クエリパラメータもRESTリクエストとして扱うようになった。クエリ形式のRESTルートを使う実装では挙動が変わる可能性がある。
ProductGalleryUtils::get_product_gallery_image_count()は非推奨となり、get_product_gallery_media_count()に置き換えられた。旧メソッドは非推奨通知を出すシムとして復元されている- 数量ステッパーのDOM順序が視覚的な順序と一致するように修正された。旧DOM順序に依存するCSSを書いているテーマは再テストが必要だ
WC_Order_Item_Product::set_product()はvariation_idをリセットするようになった。部分的なREST注文更新ではproduct_idが変わらない場合、variation_idが保持されるsearch_products()はORグループの結合を括弧で囲むようになった。これにより include、exclude、status、type の条件が全グループに適用される。結果セットが変わる- 新しい
GET /wc-analytics/activity-panel/countsエンドポイントが3つの従来エンドポイントを統合し、管理画面のページ読み込みあたり6回のリクエストを1回に削減する - アナリティクスページの出力からリクエスト由来のプロパティが除去された。キャッシュされたページが別の訪問者のリクエストデータを漏洩する事故を防ぐ
@woocommerce/entitiesはwindow.wc.wcEntitiesで内部ユーティリティを公開しなくなった。これらはもともと公開APIではない- 通貨記号の出力がMOP（P から MOP$）とZMW（ZK から K）で変更された。既存の記号オーバーライドフィルターは引き続き動作する
この記事のポイント
- WooCommerce 11.1ベータ版は2026年9月1日に正式リリース予定
- EU顧客向けの注文撤回フローが追加され、デフォルトでは無効
- REST APIに返金自動計算とプレビューエンドポイントが登場
- Store APIの
expected_totalによりチェックアウト時の金額不一致を検出 - バリエーション商品のN+1クエリ削減で管理画面とフロントの表示が高速化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Gmailが政治メールに専用レーンを新設。EC事業者が学ぶべき送信者検証と苦情率0.3%の意味
Gmailが政治メール向けにスパムフィルタを迂回できる新プログラムを発表した。2026年9月8日から、資格を満たす政治団体はGmailのVerified Sender Programに参加できる。この動きは政治メールだけでなく、EC事業者のメールマーケティングにも重要な示唆を与える。
プログラムの核心は、送信者検証と苦情率0.3%という2つの条件だ。検証済みの送信者は標準のスパムフィルタを回避できる一方、受信者からのスパム報告が一定を超えると資格を失う。本記事ではこの仕組みをECメール運用にどう活かすかを解説する。
Gmailが政治メールに専用レーンを新設
Gmailは2026年9月8日から、政治団体向けの新制度「Verified Sender Program」を開始する。この制度に参加した政治団体は、ポリシーに準拠したメールを個人のGmailアカウントに送る際、通常のスパムフィルタを経由せずに受信トレイへ届けられる。
対象となるのは、連邦選挙委員会や州・地方の選挙管理当局に登録された候補者、政党、政治活動委員会などだ。参加にはCampaign Verifyを通じた本人確認と経歴チェックが必要になる。キャンペーンドメインごとに検証できるメールアドレスは1つだけに限られる。
この制度は、Gmailが政治メールの扱いをめぐって長年続いてきた論争への回答でもある。2022年には共和党全国委員会がGoogleを提訴した。Googleは以前にも政治メールを一部のスパムフィルタから除外する試験運用を行っていたが、2023年初めに終了している。
送信者検証と苦情率0.3%の仕組み
新プログラムの参加条件は、送信者検証と苦情率の2つに集約される。送信者検証とは、メールの送信元が本人であることを技術的・制度的に確認する仕組みだ。政治団体はCampaign Verifyによる本人確認と経歴チェックを受け、セキュリティ要件とコンプライアンス要件も満たす必要がある。
もう1つの条件が苦情率0.3%未満だ。これは受信者が「スパム」と報告した割合を指す。14日間の平均が0.3%を超えると、プログラムのポリシー違反となる。つまり、検証済みの送信者であっても、受信者からのネガティブな反応が続けば優先レーンを失う。
この図は、送信者検証がメールの初期処理を変える一方で、受信者のフィードバックが依然として重要な役割を果たすことを示している。
EC事業者が学ぶべき3つのポイント
政治メール向けの制度だが、EC事業者にとっても学びは大きい。特にWooCommerceで注文確認メールやプロモーションメールを送る事業者は、この仕組みを自社の運用に置き換えて考えたい。
1つ目は送信者検証の重要性だ。Gmailが優先レーンの条件に検証を求めたのは、なりすましやフィッシングを防ぐためだ。EC事業者もSPF、DKIM、DMARCといった送信ドメイン認証を設定し、メールの正当性を示す必要がある。これらはメールの「身分証明書」のようなもので、設定していないと正規のメールでもスパム扱いされやすくなる。
2つ目は苦情率の監視だ。0.3%という閾値は政治メール向けだが、ECメールでも苦情率が高いと到達率が下がる。目安として0.3%は非常に厳しい数字だが、日々のモニタリングとリスト管理が欠かせない。購読解除の導線を明確にし、関与の低い宛先への配信を控えるだけでも改善できる。
3つ目は受信者フィードバックを運用に活かすことだ。Gmailのプログラムでは、検証済みでも受信者がスパム報告すれば通常のフィルタに戻る。EC事業者も同じで、開封率やクリック率だけでなく、スパム報告率や購読解除率を追う必要がある。
この3ステップを回すことで、Gmailのようなプラットフォームの変更にも強いメール基盤を作れる。
この記事のポイント
- Gmailは9月8日から政治メール向けにスパムフィルタ迂回の新制度を開始する
- 参加条件は送信者検証と苦情率0.3%未満の2つ
- 検証済みでも受信者のスパム報告が続けば優先レーンを失う
- EC事業者はSPF、DKIM、DMARCと苦情率監視をセットで運用したい
- WooCommerceのメールも送信者検証とフィードバック管理が到達率を左右する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差
SEOで上位を獲得しているブランドの一部が、AIチャットの回答にはほとんど登場しない。検索エンジン向けの最適化だけでは、生成AI時代のブランド視認性を確保できないことが明らかになってきた。
Fractlの調査では、GPT-4o、Gemini 2.5 Flash、Claude Sonnet 4.6の3つのモデルに96種の業界別プロンプトを投げ、4,320件の回答と8,500件超のブランド言及を分析した。SEO指標とAI回答での言及頻度を突き合わせ、その乖離を数値化している。
この記事では、AI検索から消えつつあるブランドの特徴、逆にAIで過剰に登場するブランドの共通点、そしてブランド戦略に必要な対応を解説する。
AI回答に潜む「デフォルトブランド」の存在
調査対象の全業界に共通して、プロンプトの言い回しを変えても繰り返し登場する「デフォルトブランド」が存在した。ただし、その顔ぶれは検索エンジンの上位表示とは必ずしも一致しない。ドメイン評価が高く、大量のキーワードで上位表示されているブランドが、AI回答では自社カテゴリにすら登場しないケースが目立つ。
逆に、従来のSEO指標では目立たないブランドが、AI回答では頻繁に推奨される事例も多かった。注目すべきは、デフォルトブランドの顔ぶれが業界ごとに大きく異なる点だ。
旅行カテゴリではBooking.com（285回）、Airbnb（227回）、Expedia（215回）の3ブランドが、カテゴリ全体の言及量の約20%を占めた。3社で推奨の5分の1を握る集中度だ。保険カテゴリではLemonade（213回）がState Farm（172回）を上回り、Root Insurance（165回）がProgressive（114回）を超えた。デジタルネイティブの保険会社が先に挙げられ、従来の大手は代替案として扱われている。
ライフスタイルカテゴリでは、Patagonia、Allbirds、Eileen Fisher、Everlaneといったサステナビリティ系D2Cブランドが、SephoraやSamsung、Whirlpoolを上回った。Fractlの記事では、この傾向は第三者コンテンツで語られるブランドストーリーがAIの訓練データに強く反映された結果だと指摘している。
このデモが示す通り、検索エンジンでの強さとAI回答でのプレゼンスは一致しない。AI回答内の競争集合は、検索結果ページよりはるかに小さい。自社カテゴリでAIが想起する上位5〜10ブランドに入れなければ、Googleで上位表示できていても、AIが生成する検討リストには載らない。
伝統的なSEO権威性とAIリコールの乖離
Fractlの分析によれば、データセット全体の9割超のブランドでは、従来の検索権威性とAI視認性がほぼ連動していた。つまり、SEOの基本原則が無効になったわけではない。ただし、データの端に位置するブランド群にこそ戦略の変化が見える。
全体の約5%、471ブランドが「AI過少露出」だった。ドメイン評価が高く、オーガニック流入も多く、大量のキーワードで上位表示しているにもかかわらず、AIモデルからはほとんど参照されなかった。SEO指標上は市場リーダーに見えるのに、LLMからの言及では「誰も書いたことがない企業」のように映る。
一方、全体の約4%、377ブランドが「AIオーバーパフォーマー」だった。控えめなSEO指標に比べて、AIモデルからの参照が大幅に多かった。さらに9%は、第三者コンテンツでの言及頻度とAI視認性が一致した。
ここから見える最大の示唆は、自社が発信するコンテンツよりも、外部サイトが繰り返し語ってきた内容の方がAIの回答に強く影響するという点だ。まとめ記事、専門家リスト、比較レビューに登場する頻度が高いブランドほど、AIモデルの訓練データに取り込まれやすい。
カテゴリ誤分類で消える大手ブランド
AI過少露出のブランドには、従来の指標ではカテゴリの勝者とみなされてきた大手が並ぶ。ドメイン評価80以上、月間訪問数数百万、数十万のキーワードで上位表示しているブランドが、自社カテゴリのプロンプトで一切言及されない。
この問題の根底にあるのが、カテゴリ分類のズレだ。MicrosoftとSpotifyはFinTechのプロンプトで言及されなかった。両社とも伝統的な視認性は巨大だが、AIモデルはFinTechカテゴリに分類していない。Microsoftは生産性ソフトやクラウドの文脈では頻繁に引用される。FinTechの回答セットには含まれないだけだ。
同様の構図は保険、小売、ヘルスケアでも見られた。Aetna、Cigna、Humana、Liberty Mutualはドメイン評価80以上でも、AI回答ではLemonadeやRootに置き換えられた。Sephora、Samsung、Whirlpoolも、ライフスタイルのプロンプトではPatagoniaやAllbirdsに劣位した。
言及されない理由は、AIがブランドを知らないからではない。検索者が使うカテゴリと異なる引き出しに、そのブランドがしまわれているからだ。コンテンツ量を増やすだけでは解決しない。AIモデルがブランドを正しいカテゴリに結び付けるための外部シグナルが必要になる。
AIモデルがブランドをどのカテゴリに分類しているかを把握し、ズレがあれば修正する方が先だ。カテゴリの結び付きを強化するには、アナリスト記事、業界メディア、比較ページ、パートナーページ、カスタマーストーリー、レビューサイトでの露出が有効になる。
AIで際立つオーバーパフォーマーの戦略
AIオーバーパフォーマー377ブランドの動きは、マーケターにとって他山の石になる。小さいSEOプロフィールでも、AIの回答に繰り返し登場するブランドは、共通してAIモデルの訓練データに使われた第三者コンテンツに複数回登場している。
データセット最大のオーバーパフォーマーはMonday.comだ。AI視認性スコアは0.71を記録した。オーガニック訪問数は約100万、上位キーワードは5万以上。すでに大きなSEO基盤を持ちながら、SaaSプレイヤーの平均を大きく上回る頻度でAIに参照されている。
保険カテゴリではRoot Insuranceが突出した。大手保険会社の規模に遠く及ばないにもかかわらず、AI参照数ではすべての従来型保険会社を上回った。オーバーパフォーマーの上位15ブランドのうち6つは教育分野で、Stanford、MIT、Khan Academy、LinkedIn Learning、IBM Data Science、Google Career Certificatesが並ぶ。AIモデルは商用的なプラットフォームではなく、信頼性の高さで教育ブランドを参照している。
共通項は「良いSEO」ではなく、他者のコンテンツにカテゴリレベルで登場していることだ。製品まとめ記事、エキスパートリスト、比較記事に取り上げられる頻度が、AI視認性を押し上げる。AI視認性の向上は、デジタルPRやカテゴリ権威性の構築に近づいている。
モデル間で異なるAI視認性の実態
調査対象のうち、3モデルすべてに参照されたブランドは11%、900ブランドにとどまった。2モデルに登場したのは12%。残りの77%は、1つのモデルにしか登場しなかった。これはAI視認性の測定に深刻な課題を突き付ける。
ChatGPTで勝てるブランドがGeminiでは消える。Claudeで登場してもChatGPTからは出てこない。1つのモデルの回答を制しても、別のモデルではほとんど登録されない。AI視認性の「総合スコア」だけで改善を判断すると、実態を見誤る原因になる。
モデルごとの「指紋」も異なる。ClaudeはSaaSと保険に偏り、Notion、Linear、Lemonadeが他モデルより頻繁に登場した。Geminiは旅行とヘルスケアに偏り、Booking.com、Teladoc、Livongoの言及が多かった。ChatGPTは3モデルの中で最も合意型で、他モデルとの重複が最も多い。
NotionはClaudeからの引用がGeminiの17倍に達し、Whoopは約4倍だった。State FarmはChatGPTに言及のほぼ半分を依存し、Geminiからは約4分の1しか得られなかった。総合スコアが同じでも、どこで差が出ているかを確認しないと対策は打てない。
ブランド戦略に必要な5つの視点
Fractlの記事は、この調査から導ける5つの教訓を提示している。実行しやすい順に並べると、次の通りだ。
1. 検索権威性とAIリコールを分けて測る
ドメイン評価、オーガニック流入、キーワード順位は引き続き重要だ。ただし、それだけでは全体像を捉えられない。Googleでの順位とAI回答での登場を別々に追跡し、乖離を探す。そのズレにこそ戦略のヒントがある。
2. 第三者による検証を増やす
自社サイトのコンテンツだけではAI回答への登場を保証できない。まとめ記事、ベストリスト、比較記事、専門家レビュー、アナリストページ、ポッドキャスト、YouTubeの文字起こし、コミュニティの議論など、外部コンテンツでの言及を積み重ねることが、AI視認性の実用的なレバーになる。
3. モデルごとに個別測定する
3モデルすべてに参照されたブランドは11%に過ぎない。「AI視認性」を1つの指標として扱うのは誤解を招く。ChatGPT、Gemini、Claudeを分けて計測し、プロンプトをカテゴリ別、購買意図別、比較セット別に分解する。どのモデルで、どの文脈で、どの競合と共に登場するかを追跡する。
4. カテゴリ分類の修正を優先する
ブランド全体の認知度が高くても、狙うカテゴリでのリコールが弱いなら、問題は分類にある可能性が高い。AIモデルはブランドを知っているが、重要なクエリの回答セットに含めるべき存在だとは考えていない。メディア報道、比較コンテンツ、パートナー参照、カスタマーストーリー、受賞歴、レビュー、第三者ページなどを通じて、ブランドとカテゴリの結び付きを繰り返し強化する必要がある。
5. デフォルト回答の枠が固まる前に動く
ウェルネス、ライフスタイル、ヘルステックの一部では、デフォルト回答の座がまだ空白だ。一方、旅行、主要SaaS、FinTechの一部では、AIが返す顔ぶれがすでに固定化しつつある。カテゴリとの結び付きを早期に築いたブランドほど、AIの回答に残りやすい。後発が割り込む余地は徐々に狭まる。
この記事のポイント
- SEO上位でもAI回答に登場しないブランドが全体の約5%存在する
- AI回答での競争集合は検索結果ページよりはるかに小さい
- 第三者コンテンツでの言及頻度がAI視認性を左右する
- 3モデルすべてに参照されるブランドは11%に過ぎない
- カテゴリ誤分類の修正がAI視認性改善の近道になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazonが欧州で一括保管サービスAWDを開始 5カ国で8月20日から
Amazonが欧州で一括保管サービスAWD（Amazon Warehousing & Distribution）を開始する。8月20日からドイツ、フランス、イタリア、スペイン、英国の5カ国で利用可能になる。同サービスはAmazonセラーが大量の在庫を長期保管し、需要に応じてFBAフルフィルメントセンターへ自動補充する仕組みだ。
欧州でAmazonの販売を手がける中小事業者にとって、このサービスは物流面の大きな変化になる。特に繁忙期の在庫管理に悩むセラーには有効な選択肢となり得る。本記事ではAWDの仕組みと利点、そして物流チェーンへの影響を解説する。
AWDとは何か
AWD（Amazon Warehousing & Distribution）は、Amazonセラーが商品を一括でAmazonの配送センターに預け、長期間保管できるサービスだ。保管された在庫は、需要に応じてFBA（Fulfilment by Amazon）フルフィルメントセンターへ自動的に補充される。FBAとは、Amazonが商品の保管、梱包、発送、カスタマーサービスまでを代行する仕組みである。
一括保管と自動補充の仕組み
従来のFBAでは、セラーは商品をフルフィルメントセンターに直接納入する。しかしFBAには保管容量の制限があり、大量の在庫を一度に預けることは難しかった。AWDはAmazonの配送センターで長期の一括保管を行い、FBA側の在庫が減ると自動で補充する。これによりセラーは在庫を手動で移動させる手間から解放される。
AWDは物流の上流に位置する保管拠点の役割を果たし、FBAは注文に応じた出荷を担う。この2つの層をAmazonが一括管理することで、セラーの在庫管理業務が簡素化される。
AWDの料金体系
AWDの料金は、保管料に加えてFBAセンターへの処理費と輸送費が発生する。Amazonはセラー向けの説明で「定額制の長期一括保管」と表現しており、保管コストを予測しやすい設計になっている。ただし処理費と輸送費が別途かかるため、導入前に自社の物流コストと比較する必要がある。
欧州5カ国での提供開始
8月20日からAWDはドイツ、フランス、イタリア、スペイン、英国で利用可能になる。これらは欧州最大のEC市場であり、Amazonが各市場でトップの地位を築いている。欧州のセラーにとって、AWDの開始は物流インフラの選択肢が増えることを意味する。
対象市場とAmazonの地位
欧州のEC市場は国ごとに商慣行や物流網が異なる。しかしAmazonは5カ国すべてで市場リーダーであり、多数の中小セラーが出店している。これらのセラーがAWDをどう活用するかが、今後の普及を左右するだろう。
セラーにとっての3つのメリット
AWDの導入により、セラーは主に3つのメリットを得られる。FBA容量制約からの解放、自動補充による品切れ防止、繁忙期の在庫管理の容易化だ。いずれも売上機会の損失を減らす効果が期待できる。
FBA容量制約からの解放
FBAには保管容量の制限があり、セラーは在庫を増やしたくても受け入れ枠の問題で制約を受けることがあった。AWDを利用すれば、Amazonの配送センターで大量の在庫を長期保管できるため、FBAの容量制約に縛られずに商品を仕入れることが可能になる。
AWDを利用する前と後では、在庫管理の自由度に大きな差が出る。容量制約に縛られずに仕入れができる点は、売れ筋商品の取り扱い数を増やしたいセラーに特に有効だ。
自動補充で品切れを防ぐ
Amazonの説明によると、AWDの自動補充機能は手動での在庫補充作業を不要にし、品切れリスクを低減する。売れ筋商品の在庫が減れば、Amazonが需要を判断してFBAへ補充する。これによりセラーは商品管理から発注業務に時間を割かずに済む。
繁忙期の在庫管理が容易になる
Prime DayやBlack Fridayなどの繁忙期は、短期間で需要が急増する。こうした時期に在庫切れを起こすと、大きな売上機会を失う。AWDなら事前に大量の在庫を保管しておき、需要の高まりに応じて自動でFBAへ補充できる。繁忙期特有の在庫不足を防ぐ手段として、特に中小セラーには実用性が高い。
物流チェーンの支配強化とセラー依存
AWDはセラーの在庫とFBAネットワークの間に、新たな物流の段階を追加する。これは利便性の向上と同時に、Amazonが物流チェーン全体を掌握する動きとも読み取れる。
物流チェーンにAWDが加わることで、商品の保管から出荷までの工程がAmazonの管理下に置かれる。セラーにとっては手間が減る一方、Amazonへの依存度が高まる構造になる。
Amazonの物流支配が強まる
AWDは、Amazonがセラーの在庫保管から配送までを一貫して担う流れを加速させる。Amazonは昨年、欧州でセラー向け手数料を引き下げる施策を実施している。物流サービスを拡充する一方で手数料を調整し、より多くのセラーを自社物流網に取り込む戦略が見える。
セラーの依存度増加
欧州には10万を超えるサードパーティセラーが存在し、Amazonの欧州店舗における売上の大部分はこれらのセラーによって生み出されている。特に中小企業が多い。AWDによって業務が簡素化される一方で、在庫保管から配送までAmazonに委ねる割合が増えれば、プラットフォームへの依存はさらに深まる。Amazonは自社を欧州の中小企業の「味方」と位置づけているが、その関係性は常に緊張をはらんでいる。
米国での展開と今後の可能性
AWDは米国で4年前にサービスを開始しており、すでに一定の実績がある。欧州への展開はその成功を踏まえたものだ。ただし欧州版には現時点で含まれない機能もある。
米国では外部販売チャネルにも供給可能
米国ではAWDに預けた在庫を、Amazonの販売チャネル以外にも供給できるオプションが提供されている。つまりセラーは自社のオンラインストアや他社のECモールへ商品を供給する際にも、Amazonの保管拠点を利用できる。しかし欧州版のローンチ時点では、この外部チャネルへの供給オプションは含まれていない。
欧州の今後の展開は未定
現時点で、AWDが欧州の5カ国以外に展開されるかどうかは明らかになっていない。ただ欧州のEC市場規模を考えると、今後対象国を拡大する可能性は十分にある。外部販売チャネルへの供給機能が欧州でも提供されれば、AWDの価値はさらに高まるだろう。
この記事のポイント
- Amazonが欧州5カ国で一括保管サービスAWDを8月20日から開始する
- AWDは長期の一括保管とFBAへの自動補充が特徴だ
- セラーはFBA容量制約なしで在庫を保管でき、品切れリスクを抑えられる
- 一方でAmazonへの物流依存度が高まる側面もある
- 米国では外部販売チャネルへの供給も可能だが、欧州版では未対応だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験