PHP 8.1以上に変更すると500エラーが起きる時の原因と対処法
WordPressサイトでPHPを8.0から8.1以上に切り替えると500 Internal Server Errorが発生する場合は、サーバー側のエラーログ確認と拡張機能・PHPハンドラの互換性チェックが解決の最短ルートになる。WordPressのdebug.logが空でも、エラーがWordPress起動前に発生している可能性が高い。
PHP 8.1以上への変更で500エラーが起こる原因
500 Internal Server Errorは「サーバー内部で想定外のエラーが起きた」ことを示す汎用的な表示だ。原因はWordPress内のプラグインやテーマとは限らない。PHPのバージョンアップに伴うサーバー側の設定変更、拡張機能の欠落、PHPハンドラの切り替えなど、WordPressが動き出す前の段階でエラーになるケースも多い。
特にPHP 8.0から8.1以上への変更時は、非推奨だった機能の正式な削除や、デフォルト設定の変更が影響する。古いプラグインやテーマのコードがPHP 8.1で動かない場合もあるが、そのケースでは多くの場合WordPressのデバッグログに記録が残る。一方、debug.logに何も出ない500エラーは、サーバーレベルでの問題を疑うべきだ。
サーバーのエラーログを確認する手順
まず確認すべきは、レンタルサーバーのコントロールパネルにある「エラーログ」または「サーバーログ」だ。PHP 8.1でエラーが出ている場合、WordPressのdebug.logではなく、このサーバーログにだけ記録が残っていることがある。
コントロールパネルで該当ログを探す
国内の一般的なレンタルサーバーでは、管理画面の「ログ」や「アクセス解析」の近くにエラーログの項目がある。エラーログにはタイムスタンプとともに、どのPHPハンドラが失敗したのか、どの拡張機能が読み込めなかったのか、メモリ不足が起きたのかといった記録が残る。エラー発生直後の行をコピーしておくと、原因の特定が速い。
上のデモはサーバーのエラーログを確認する一連の流れを示している。ログにPHPの拡張機能名（例「mysqli」や「curl」）が書かれていれば、その拡張機能がPHP 8.1環境で有効になっていない可能性が高い。ハンドラ名（例「php-fpm」や「FastCGI」）の記述があれば、ハンドラの切り替えに失敗しているケースが考えられる。
PHPハンドラと拡張機能の互換性を確かめる
サーバーログにWordPressが起動する前のエラーが記録されている場合、原因はPHPハンドラまたはPHPの拡張機能にある。PHPハンドラとは、サーバーがPHPファイルを実行するための仕組みのことだ。PHP 8.0から8.1に切り替える際、ハンドラの設定が初期化されたり、互換性のない組み合わせになったりすることがある。
最小限のPHPファイルで切り分ける
WordPressとは無関係に、PHP 8.1自体が正常に動くかどうかを確認する方法がある。FTPソフトなどでWordPressと同じディレクトリに、内容が <?php phpinfo(); ?> だけのファイル（例 php-check.php）をアップロードし、ブラウザでアクセスする。
このファイルも500エラーになるなら、WordPressやプラグインの問題ではない。サーバーのPHP設定・ハンドラ・拡張機能そのものに問題がある。逆にこのファイルが正常に表示されるなら、WordPress側のコードに原因があるため、プラグインやテーマの互換性を順に調べる。
この切り分けでサーバー側の問題だと判明したら、レンタルサーバーの管理画面からPHP 8.1に切り替えた直後の設定を確認する。PHPハンドラが「利用不可」になっていたり、必要な拡張機能（mysqli、mbstring、curl、zipなど）が「無効」になっていたりしないかを確かめる。
debug.logが空でも見落とさない5つのチェックポイント
WordPressのdebug.logにエラーが残っていない場合でも、500エラーの原因は必ず存在する。以下の5点を順に確認すると、隠れた原因に行き着きやすい。
1. wp-config.phpのデバッグ設定を再確認する
WP_DEBUG と WP_DEBUG_LOG が両方とも有効になっているかを確認する。WP_DEBUG_DISPLAY が false のままでもログは出力されるが、設定の記述位置が古いテーマのコードより後だと、エラーが発生する時点でログ設定が読み込まれないことがある。wp-config.phpのなるべく先頭近くに記述を移動しておくと確実だ。
2. php.iniや.user.iniの記述を確認する
PHPのバージョンを変更すると、ホームディレクトリ直下の php.ini や .user.ini が別バージョンの設定として適用される場合がある。PHP 8.0向けに書いた設定がPHP 8.1では不正な構文になるケースや、設定した内容がホスティング側の制限と競合するケースがある。
3. 拡張機能の有効状態を一覧で比較する
PHP 8.0で有効だった拡張機能が、PHP 8.1では無効になっていることがある。特に画像処理のGDや、データベース接続のmysqli、マルチバイト文字列のmbstringが無効だと、WordPressは起動すらできない。phpinfo() の結果をPHP 8.0と8.1で並べて比較すると、差分に気づきやすい。
4. .htaccessからPHP関連の記述を一度外す
PHPのバージョンやハンドラを指定する .htaccess の記述が、新しいPHPの設定と競合して500エラーを起こすことがある。WordPressの標準的な記述だけにした .htaccess を新しく作ったうえで、PHP関連のカスタム記述を一時的に外して確認する。
5. サーバー会社の障害情報と設定上限を確認する
そのサーバーがPHP 8.1への切り替えを一時的に制限している場合や、特定のハンドラがメンテナンス中の可能性がある。サーバー会社の障害・メンテナンス情報ページを確認すると、想定外の原因に行き着くこともある。
WooCommerceを使うPHP 8.1移行で気をつける互換性
WooCommerceはPHP 8.1に正式対応している。ただし、導入している拡張プラグインや子テーマの中にはPHP 8.1で動作しない古いコードが残っている場合がある。PHP 8.0から8.1への変更で、関数の呼び出し方が非推奨から削除に変わったものが影響することもある。
切り分けテストは、WooCommerce以外のプラグインをすべて無効化し、標準テーマ（Twenty Twenty-Fourなど）に切り替えた状態でPHP 8.1を適用する手順が確実だ。その後、1つずつプラグインを有効化して、どのプラグインで500エラーが再発するかを突き止める。ただし、この手順でエラーが再発しない場合も、先に述べたサーバーレベルの問題が残っている可能性を忘れてはならない。
よくある質問
500エラーが出たまま管理画面にログインできない場合はどうする？
FTPソフトでwp-content以下のpluginsフォルダ名を一時的に変更すると、全プラグインを無効化できる。同じくテーマフォルダ名を変更すると標準テーマに切り替わる。その後、PHP 8.1でサイトが表示されるかを確認する。
PHP 8.1に切り替える前の注意点は？
事前にサイト全体のバックアップを取る。次に、プラグインとテーマがPHP 8.1に正式対応しているか、各プラグインの公式ページで確認する。対応表記がない場合は、PHP 8.0のままテスト環境で切り替えテストを行うのが安全だ。
サーバーログで「Allowed memory size exhausted」と出る場合は？
PHPのメモリ上限を増やすことで改善する。wp-config.phpの WP_MEMORY_LIMIT を256MBや512MBに設定し、php.iniの memory_limit も確認する。レンタルサーバー側で上限が固定されている場合は、サーバーの仕様を確認する。
debug.logに「Fatal error」と出る場合の読み方は？
エラーが発生したファイル名と行番号が記録されているので、該当するプラグインやテーマを特定できる。プラグイン名が明示されている場合は、そのプラグインを無効化するか、PHP 8.1対応版への更新を確認する。
PHP 8.0に戻せば解決するが、8.1のままにしたい場合は？
PHP 8.0に戻してサイトを復旧させたうえで、8.1で動かない原因を特定する。テスト環境を作り、プラグインやテーマの互換性を1つずつ確認して、修正または代替プラグインを導入してから本番環境を切り替えるのが安全な進め方だ。
この記事のポイント
- PHP 8.1以上での500エラーはサーバーログに原因が記録されていることが多い
- debug.logが空でもWordPress起動前のエラーを疑う
- 最小のPHPファイルでサーバー側とWordPress側を切り分ける
- PHP 8.0で有効だった拡張機能が8.1で無効になっていないか確認する
- WooCommerceは公式対応だが拡張プラグインの互換性は個別に確かめる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
B2BKingのMCP連携でWooCommerce B2BストアをAIが設定。仕組みと接続手順
WooCommerce向けB2B・卸売販売プラグインのB2BKingが、MCP連携機能を実装した。AIアシスタントが自然言語の指示だけで、ストア設定の読み取りから変更までを実行できる。従来は数時間かかっていた設定作業が、数分で完了する可能性がある。
対応するのはClaude、Codex（OpenAIのコーディングエージェント）、Cursor、VS Codeなど、MCP（Model Context Protocol）をサポートするすべてのAIツールだ。コードを書く必要も、設定画面を1つずつ巡回する必要もない。
B2BKingのMCP連携とは何か
B2BKingはWooCommerce向けのB2B・卸売販売プラグインだ。約7年の開発実績を持ち、累計1万5,000以上のWooCommerceストアで稼働している。このB2BKingが、WordPressの標準API群を通じてAIアシスタントから直接設定を変更できる仕組みを実装した。
具体的には、B2BKingがWordPress Abilities APIに主要なストア設定を「能力」として登録する。その能力を公式のWordPress MCP AdapterがMCP経由で外部に公開し、MCPをサポートするAIアシスタントが利用できるようになる。特定のAI製品向けの独自コネクタを作るのではなく、オープンな標準の上に構築されている点が特徴だ。
一度接続すると、英語で普通の文章を入力するだけでストア設定を操作できる。B2B限定ストアとハイブリッドB2B/B2Cの切り替え、ゲストの閲覧制御、顧客グループの作成、卸売価格や最低注文金額の設定、顧客のグループ割り当てなどが対象となる。
指示はAIアシスタントからMCP Adapterへ送られ、B2BKingが登録した能力を通じてWooCommerceに反映される。すべて標準化されたプロトコル上で動作するため、特定のAI製品に依存しない。
AIが設定できる5つの領域
現時点でAIが操作できる範囲は、B2Bストアの構築に必要な主要な決定事項をカバーしている。大きく5つの領域に分類できる。
ストア全体の設定と登録機能
1つ目はストア構成だ。AIがB2BKingの設定全体を読み取り、B2B限定モードとハイブリッドB2B/B2Cモードを切り替えられる。ゲストが見る内容も制御でき、価格の非表示、ショップ全体の非表示、ログイン限定ストア、価格の代わりに見積依頼を表示する設定などに対応する。
2つ目は登録と機能の制御だ。B2B登録フォームの有効化、ロールのドロップダウン表示、アカウント承認フローをオン・オフできる。見積依頼、会話機能、オファー、購入リスト、一括注文フォーム、会社サブアカウントなどの機能も同様に操作できる。
顧客グループと価格ルールの操作
3つ目は顧客グループの管理だ。既存のグループを一覧表示するだけでなく、リセラーやディストリビューターなどの新しいグループを作成できる。グループには与信枠を設定することも可能だ。
4つ目は価格ルールだ。パーセント割引、固定金額割引、固定価格、送料無料、最低注文金額などのルールを、全B2B顧客または特定のグループに対して設定できる。適用範囲もカタログ全体、単一商品、カテゴリ単位で指定できる。
5つ目は顧客の個別管理だ。特定の顧客のB2Bステータス、所属グループ、承認状態を確認し、B2Bグループへの移動やB2Cへの戻しを実行できる。グループを作成した後のルール適用や顧客の移動も、同じ会話の中で続けて指示できる。
手動で設定画面を巡回する作業が、AIアシスタントへの1つの指示文で置き換わる。所要時間は数時間から数分へ短縮される。
WordPress Abilities APIとMCPの技術的仕組み
Abilities APIの役割
WordPress Abilities APIはWordPress 6.9からコアに導入された標準機能だ。プラグインが「自分に何ができるか」をAIに宣言するための共通の方法を提供する。各能力（アビリティ）には、説明文、期待する入力データのスキーマ、権限チェックの3つが含まれる。
これによりAIは、ある操作が何をするのかを事前に理解できる。さらに、ログイン中のユーザーがその操作を実行できるかどうかも、何かが起こる前に検証される。B2BKingは主要なストア設定をこのAbilities APIに登録している。
MCP Adapterの役割
MCP（Model Context Protocol）は、AIアシスタントが外部ツールと会話するためのオープンプロトコルだ。Claude、Codex、Cursor、VS Codeが同じB2BKingの設定を操作できるのは、このMCPが共通の通信基盤になっているからだ。
公式のWordPress MCP Adapterは、Abilities APIに登録された能力をMCP経由で外部に公開する橋渡し役を担う。ライブサイトとローカル開発環境の両方で動作し、WordPressのAIエコシステム全体が成熟するほどB2BKingも自動的に恩恵を受ける構造だ。
注目すべきは、この設計が特定のAI製品へのロックインを避けている点だ。独自のコネクタを開発するのではなく、オープンな標準に乗っているため、MCPをサポートする新しいAIツールが登場すれば、追加の開発なしで利用可能になる。
AIによるストア設定の安全性
AIがストア設定を変更できると聞くと、多くのストア運営者は「制御を失うのでは」と不安に感じる。B2BKingはこの懸念に対して、複数の安全機構を実装している。
実行前のチェック機構
第1に、すべての能力が実行前に接続ユーザーのWordPress権限（ケイパビリティ）をチェックする。権限のないユーザーが接続しても、変更操作は実行できない。
第2に、入力値の検証が行われる。存在しないグループやカテゴリを指定したルール、100%を超える割引率などをAIが指示しても、検証によって拒否される。B2BKingが各ステップを実行時に確認する仕組みだ。
第3に、各能力は読み取り専用か変更を伴うものかがラベル付けされている。AIクライアントは変更実行前にユーザーへ確認を求める設定にできる。第4に、ライセンスキーはAIアシスタントに渡らない設計になっている。
4つの安全機構により、AIがストア設定を誤って変更するリスクを抑えている。特にライセンスキーがAIに渡らない設計は、セキュリティ面で重要なポイントだ。
開発者向けフィルター
開発者向けには2つのフィルターが用意されている。b2bking_mcp_enabledでMCP連携を完全に無効化できる。またb2bking_mcp_write_enabledで読み取り専用に制限することも可能だ。本番ストアでは読み取り専用にしておき、ステージング環境でのみ書き込みを許可するといった運用が現実的だろう。
ClaudeやCodexとB2BKingの接続手順
MCPをサポートするAIアシスタントならどれでも動作するが、ClaudeとCodexが最も始めやすい。接続設定自体もAIに任せられるためだ。コードを書く必要はない。AIはB2BKingに組み込まれた能力を通じてのみ動作する。
AIに接続設定を任せる方法
最も簡単な方法は、ClaudeやCodexに「公式WordPress MCP Adapterを使用してMCP経由でストアに接続したい」と伝えることだ。AIが必要なインストールと設定を判断して進めてくれる。
通常、AIが求めるのはアプリケーションパスワードのみだ。WordPress管理画面の「ユーザー」→「プロフィール」→「アプリケーションパスワード」から作成できる。これだけで接続は完了する。
手動で接続する手順
自分で設定する場合は、以下の手順を踏む。まずWordPress 6.9以降と最新版のB2BKingが必要だ。次にMCP Adapterプラグインをインストールし、アプリケーションパスワードを作成する。最後にAIクライアントのMCP設定に短い設定項目を追加する。
B2BKing側で何かを有効化する必要はない。能力は自動的に登録されるためだ。設定スニペットの全文はB2BKing公式サイトの「AIによるWooCommerce B2Bストア構築ガイド」に掲載されている。
接続後は、以下のような指示文を送るだけで設定作業が始まる。
ストアをハイブリッドB2B/B2Cモードに設定して。ゲストには価格の代わりに見積依頼を表示。Wholesaleグループを与信枠5,000ドルで作成し、全体に15%割引と最低注文300ドルを適用。AIはまず現在のB2BKing設定を読み取り、状況を把握する。その後、ハイブリッドモードへの切り替え、ゲスト見積依頼の設定、Wholesaleグループの作成、15%割引ルールと300ドル最低注文ルールの追加を順番に実行する。各ステップでB2BKingが検証を行い、すべて完了するとAIが変更内容を報告する。
この記事のポイント
- B2BKingがMCP連携に対応し、ClaudeやCodexから自然言語で操作できる
- Abilities APIとMCP AdapterというWordPress標準の仕組みで構築されている
- ストア構成、登録機能、顧客グループ、価格ルール、顧客管理の5領域を設定できる
- 権限チェック、入力検証、読み取り/書き込み区別、ライセンスキー遮断の4重の安全機構を備える
- 7年の実績と1万5,000以上のストアで使われてきた信頼性の上にAI連携が乗っている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.2.1リリース。住所フィールドと郵便番号の不具合を修正
WooCommerce 11.2.1が2026年10月9日にリリースされた。今回のドットリリースは、11.2.0で発生した2件のチェックアウト関連バグを修正する内容だ。
住所フィールドを削除したストアで発生するエラーと、アルゼンチンなど特定の国で郵便番号が拒否される問題が対象になる。セキュリティ更新とデータベース更新は含まれない。
記事を読めば、修正された2つのバグの内容と、アップデート前に確認すべきポイントがわかる。
WooCommerce 11.2.1の概要
WooCommerceはWordPressでECサイトを構築する無料プラグインだ。今回の11.2.1は「ドットリリース」と呼ばれる、バグ修正に限定された小規模な更新になる。新機能の追加はなく、11.2.0で見つかった不具合を修正するためにリリースされた。
修正対象は2件ある。1件目はクラシックチェックアウトで住所フィールドを削除したストアに発生するブロックエラーで、2件目はチェックアウトブロックでアルゼンチンなどの郵便番号が拒否される問題だ。
WooCommerceのチェックアウトには大きく分けて2つの方式がある。1つはショートコードで表示する「クラシックチェックアウト」、もう1つはGutenbergブロックエディタで構築された「チェックアウトブロック」だ。今回の修正は両方を1つずつカバーしている。
このデモは、11.2.1で修正された2つの不具合と、セキュリティ更新やデータベース更新が含まれないことを示している。
クラシックチェックアウトの住所フィールド修正
クラシックチェックアウトは、ショートコード [woocommerce_checkout] で表示される従来型のチェックアウト画面だ。WooCommerceの初期から提供されている方式で、現在も多くのストアで使われている。
住所フィールドとは、請求先住所や配送先住所の入力欄のことだ。多くのストアでは必須項目だが、デジタル商品のみを販売するストアなどでは不要な場合がある。そうしたストアは、woocommerce_billing_fields または woocommerce_default_address_fields というフィルターを使って住所フィールドを削除するカスタマイズを行う。
フィルターとは、WordPressやWooCommerceの動作をサイト独自に変更するための仕組みだ。テーマのfunctions.phpやカスタムプラグインにコードを追加して使う。住所フィールドを削除するカスタマイズは、決して珍しいものではない。
11.2.0では、注文サマリーが更新される際の住所データ送信に問題があった。住所フィールドを削除したストアで、以下のような不具合が発生する可能性があった。
- 「続行するには住所を入力してください」というエラーでチェックアウトがブロックされる
- 税金が正しく計算されない
- 配送方法の選択肢が表示されなくなる
11.2.1では、11.1の動作に戻す修正が入った。注文サマリーのリフレッシュ時に、住所データが正しく送信されるようになる。住所フィールドを削除するカスタマイズを利用しているストアは、このバージョンで問題が解消される。
住所フィールドを削除したストアでは、11.2.0のエラーが11.2.1で解消される。
チェックアウトブロックの郵便番号バリデーション修正
チェックアウトブロックは、ブロックエディタで構築された新しいチェックアウトフローだ。カートブロックやチェックアウトブロックなど、複数のブロックを組み合わせて柔軟にレイアウトを変更できる。
バリデーションとは、入力された値が正しい形式かどうかを検証する仕組みだ。たとえば郵便番号の入力欄に「123」など桁数の少ない値を入力するとエラーになるのは、バリデーションが働いているからだ。今回の問題は、この検証が厳しくなりすぎたことによって発生した。
11.2.0では、アルゼンチンの郵便番号で州文字なしの形式（例 1213）が拒否されるようになった。さらに、エルサルバドル、セントビンセントおよびグレナディーン諸島、イギリス領ヴァージン諸島の郵便番号フォーマットも拒否されていた。
11.2.1では、アルゼンチンの州文字なし郵便番号を再び受け入れ、上記3カ国のフォーマットにも対応する。該当する国への配送を行っているストアは、チェックアウトブロックでエラーが解消される。
11.2.1では、アルゼンチンの州文字なし郵便番号が再び有効になる。
アップデート前の確認ポイント
今回の修正はバグ修正に限定されているため、更新によるリスクは比較的低い。ただし、チェックアウトは売上に直結する機能だ。更新前には以下のポイントを確認しておきたい。
- 住所フィールドを削除するカスタマイズを使っているか
- チェックアウトブロックを利用しており、対象国に配送しているか
- ステージング環境で実際のチェックアウトフローをテストしたか
- 更新前にバックアップを取得しているか
特に住所フィールドを削除するカスタマイズを使っているストアは、11.2.0をスキップして11.2.1に直接更新することをおすすめする。11.2.0に更新してしまった場合は、できるだけ早く11.2.1への更新が望ましい。
この記事のポイント
- WooCommerce 11.2.1は2026年10月9日にリリースされたドットリリース
- クラシックチェックアウトで住所フィールドを削除したストアのエラーを修正
- チェックアウトブロックでアルゼンチンなどの郵便番号バリデーションを修正
- セキュリティ更新とデータベース更新は含まれない
- 住所フィールド削除カスタマイズ利用中のストアは更新推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.2が登場、商品CSVのUPC照合と決済日付入力を追加
WooCommerce 11.2が2026年10月8日にリリースされた。今回のアップデートでは商品CSVインポートの照合方法が拡張され、サプライヤーから届いたUPCだけの価格表をそのまま取り込めるようになった。ほかにもチェックアウトでの日付入力、注文撤回メールの設定、カタログ画面のパフォーマンス改善が含まれる。
ECサイトを運営する担当者にとって、日々の商品管理と受注業務に直結する変更が中心だ。特に商品コードを使った一括更新は、数千点規模の在庫を扱う店舗で作業時間を大きく短縮できる。本記事ではWooCommerce 11.2の主要な変更点と、アップデート前に確認しておきたい注意事項をまとめる。
WooCommerce 11.2の主な変更点
WooCommerce 11.2はWordPressのECプラグインとして広く利用されているWooCommerceのマイナーアップデートだ。公式ブログでは変更点を6つの項目に分けて紹介している。いずれも店舗運営の効率化に寄与する内容で、商品管理から顧客体験の改善まで幅広い。
上記のほか、セキュリティ改善とデータベース更新も含まれる。更新前にバックアップを取得しておくことが推奨される。
商品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ファイルとしてアップロードできるようになった。
利用するにはインポート画面で「既存の商品を更新」を有効にする必要がある。同一商品にSKUとUPCの両方が登録されている場合はSKUが優先される仕組みだ。
チェックアウトで日付入力を追加できる
日付フィールドの用途
チェックアウトブロックを使用している店舗では、注文手続き中に顧客へ日付を尋ねられるようになった。配達希望日や誕生日など、商品の性質に合わせて自由に用途を決められる。顧客はスマートフォンやブラウザ標準の日付ピッカーを使って日付を選択する。店舗側は選択できる日付の範囲も制限できる。
設定方法
この日付フィールドを追加するには、チェックアウトブロックの設定にショートコードスニペットを追加する。テーマのfunctions.phpやコード管理プラグインに数行のコードを貼り付けるだけで有効化できる。コードの詳細は公式のリリースノートに記載されている。
この例では配達希望日を追加しているが、誕生日や引き取り希望日など、店舗の運用に合わせて自由にラベルを変更できる。
注文撤回メールを管理可能に
EU圏の顧客に販売している店舗向けの変更も入った。注文撤回（キャンセル要求）が発生したときに送信される2種類のメールを、管理画面から設定できるようになった。1つは顧客が受け取る確認メール、もう1つは店舗側に届く通知メールだ。
WooCommerceの設定画面にある「メール」セクションで、それぞれのメールに独自のメッセージを追加できる。プレビューで内容を確認し、通知を受け取る担当者を選び、必要なければメール自体を無効化することも可能だ。これまではコードでしか変更できなかった設定が、管理画面だけで完結するようになった。
パフォーマンス改善とブロックの新スタイル
カタログと管理画面の高速化
商品数が5点でも5万点でも、カタログ画面で商品を自由に並べ替えられるようになった。可変商品（サイズや色などのバリエーションを持つ商品）を含む店舗では、商品ページの読み込みとチェックアウト処理が高速化している。レポート集計ではデータベースへのクエリ数が減り、顧客数が増えてもメモリ使用量が増加しにくくなった。
大量の顧客データを持つ店舗ほど、この改善による管理画面の体感速度は大きく変わる。レポート表示が遅くて開くのを待っていた店舗は、更新後に改善を実感しやすい。
商品フィルターブロックのスティッキー表示
商品フィルターブロックにスティッキー（追従）表示のオプションが追加された。長いカテゴリーページを顧客が下へスクロールしても、フィルター条件が画面上部に表示され続ける。絞り込みのたびにページ先頭まで戻る手間がなくなる。
ほかにも数量セレクター（カート内のものを含む）は枠線、影、色、角丸を設定できる。商品画像には枠線、フィルターチップにはフォントと余白のコントロールと角丸が追加された。これらのスタイルは外観 > エディター > スタイル > ブロックの画面で店舗全体に一括設定するか、ブロック単位で個別に調整する。
アップデート前に知っておくべき注意点
既存メール設定への影響
パスワードリセット、新規アカウント作成、メール確認の各メールについて、自分自身をCCまたはBCCでコピー受信していた場合、その配信が停止される。これらのメールにはログインリンクが含まれるため、本人以外には送られないようにするセキュリティ上の変更だ。
ダウンロードリンクと権限の変更
標準のダウンロードリンクは従来どおり動作する。ただし、まれにカスタム登録やインポートで不正なデータを持つリンクは動作しなくなる可能性がある。顧客から報告があれば、注文画面からリンクを再発行すればよい。
ショップマネージャー（店舗運営者）が、フォーラム権限や会員権限など特定の追加権限を持つユーザーを編集できなくなる。そのようなユーザーの編集はWordPress管理者が行うことになる。
アップデート手順の注意
WooCommerce 11.2にはセキュリティ改善とデータベース更新が含まれるため、運営中のすべての店舗でアップデートを適用することが推奨される。データベース更新が走るので、事前のバックアップが必須だ。
この記事のポイント
- WooCommerce 11.2は2026年10月8日にリリースされた
- 商品CSVインポートがUPC・GTIN・EAN・ISBNでの照合に対応した
- チェックアウトブロックに日付入力欄を追加できる
- 注文撤回メールの管理画面設定が可能になった
- パフォーマンス改善とセキュリティ更新を含むためバックアップしてアップデートを
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPT広告に画像フォーマット登場。EC事業者が知るべきBotクリック問題と計測拡張
OpenAIはChatGPTの広告に画像を使った視覚フォーマットを追加する。画像生成中に表示される新しい広告枠で、広告主は商品やサービス体験を画像で伝えられるようになる。
ChatGPTの週間利用者数は12億人に達している。広告の露出規模は巨大だ。一方でTrafficGuardの調査によれば、ChatGPT広告のクリックはGoogle広告と比べてデータセンターやプロキシ経由が3.6倍多い。
本記事では新しい広告フォーマットの仕組み、Botクリックの実態、計測機能の拡張を整理する。ECサイトを運営する事業者が広告予算を無駄にしないためのポイントもあわせて解説する。
ChatGPT広告に視覚フォーマットが追加
OpenAIの発表によると、新しい視覚広告は画像生成のタイミングで表示される。広告主は商品そのもの、使用シーン、サービスに関連する体験などを画像で表現できる。この広告は生成される画像とは別の領域に表示され、ChatGPTの回答内容には影響を与えない設計だ。
米国では今月下旬から一部の広告主を対象にテストが始まる。従来のChatGPT広告は広告主名、ロゴ、商品リンクを並べるだけのシンプルなスポンサー表示だった。今回の変更で、広告クリエイティブの表現力が一段階上がることになる。
このデモでは従来のテキスト中心の広告と、画像を活用した新しい広告の違いを示した。視覚フォーマットは商品を直感的に伝えられる点が最大の変化だ。
週間12億人が閲覧する広告枠がECにもたらす意味
ChatGPTの週間利用者数は12億人に達している。この規模のユーザーベースに商品画像を直接見せられる広告枠は、EC事業者にとって新しい集客チャネルになり得る。特に検索意図が明確な会話の中で商品を提示できる点が、従来のディスプレイ広告とは異なる。
ただし、新しい在庫が増えても基本的な疑問は残る。誰が本当にクリックしているのか、という点だ。広告の見た目が派手になるほど、実際の成果が見えにくくなるリスクもある。
商品を画像で見せられる価値
ECの集客では商品画像が購買判断に直結する。ChatGPTの視覚広告は、会話の文脈に合わせて商品画像を提示できるため、いわゆる「ついで買い」や「比較検討」の入り口になりやすい。従来のテキストリンクよりクリック率向上が期待できるフォーマットだ。
とはいえ、広告の露出が増えるほどBotによる不正クリックの影響も拡大する。次章でその実態を確認する。
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広告とGoogle広告で比較した。ChatGPT広告はGoogle広告よりはるかに高い割合でBot経由のクリックが発生している。
自動化されたトラフィックへの見解
TrafficGuardの共同創業者兼CEOであるMathew Ratty氏は声明で、ChatGPT広告はまだ初期段階であるにもかかわらず自動化トラフィックはすでに到達していると述べた。同氏によれば、それは組織的で、持続的で、毎日クリックを続けているという。
EC事業者がChatGPT広告へ予算を投じる場合、Bot対策は無視できない要素だ。配信設定で除外すべきネットワークを絞り込み、無効クリックの発生率を定期的に確認する運用が求められる。
計測機能も拡張。HightouchやLiveRampと連携
OpenAIは広告効果を測定する仕組みも拡張する。Hightouch、Tealium、LiveRampとの連携により、広告主はコンバージョンデータをChatGPT広告へ送信できるようになる。これにより、ChatGPT広告経由で実際に商品が購入されたかどうかを追跡しやすくなる。
EC事業者にとっては、広告クリック後の購入までの導線を数値で把握できる点が重要だ。ただし、Botクリックが混ざると成果数値が歪むため、無効クリックの除外とセットで運用する必要がある。
このデモではECサイトからChatGPT広告へのコンバージョンデータの流れを示した。3つの連携ツールを使うことで、購入データを広告効果測定に反映できる。
EC事業者が取るべき対応
ChatGPTの視覚広告は新しい集客チャネルとして注目に値する。特に商品画像を自然な会話の流れで提示できる点は、従来の検索広告やSNS広告にはない強みだ。一方で、Botクリック率の高さは予算を毀損する要因になる。
まずは少額のテスト配信から始め、無効クリック率とコンバージョンの推移を確認するのが現実的だ。計測ツールとの連携を設定し、購入に至ったトラフィックの割合を継続的に追うことを推奨する。
この記事のポイント
- ChatGPT広告に画像を使った視覚フォーマットが追加された
- 新フォーマットは画像生成中に表示され、ChatGPTの回答には影響しない
- ChatGPTの週間利用者数は12億人に達する
- TrafficGuardの調査で無効クリック率は0.1〜34%と大きくばらついた
- BotクリックはGoogle広告の3.6倍、データセンター経由が多い
- Hightouch、Tealium、LiveRampと連携しコンバージョン計測を拡張
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce高速化を外注する費用は95,000円、作業の中身を公開
WooCommerce高速化を外注する費用は、一式95,000円（税込）だ。
月額費用はかからず、現状分析からキャッシュ調整、画像最適化、CDN設定までをこの金額でまとめて施工する。
サーバーを乗り換えず、今の環境のまま表示を速くする。
申し込み前の診断は無料で、サイトURLを伝えればどれくらい速くなるかを先に確認できる。
広告費をかけて集めた見込み客が、表示を待つ間に戻るボタンを押している。
その離脱を止めることが、この費用の役割だ。
WooCommerce高速化を外注する費用は一式95,000円（税込）
WooCommerce高速化の外注費用は、一式95,000円（税込）だ。
この金額で、サイトが遅い原因の特定からキャッシュの設計、画像の軽量化、CDNの設定までをまとめて行う。
一月ごとの請求や、作業が増えるたびに追加でかかる費用はない。
施工前の診断も無料で受けられるので、まず予算を確認したいあなたにとって、金額は分かりやすいと思う。
なぜ一式で金額が決まるのか
サイトごとにページ数や商品数、使っているテーマは違う。
だが、私たちの高速化サービスでは料金を一式95,000円（税込）にしている。
見積もりのたびに金額が上下しないので、発注前に予算を確定できる。
無料診断で効果の見通しが立つ
申し込み前の診断は無料だ。
サイトURLを伝えれば、私たちがページの読み込み速度を測り、どこが遅い原因になっているかを調べる。
診断の段階で費用は発生しない。
95,000円に含まれる作業と含まれない作業
95,000円（税込）に含まれる作業は六つある。
最初から一式にしているので、高速化に必要なことを個別に判断して追加を検討する必要はない。
含まれる作業
| 作業 | 内容 |
|---|---|
| 現状分析 | サイトが遅い真の原因を突き止める |
| 独自開発プラグインの実装 | キャッシュを生成し切れを検知して自動で再構築する |
| W3 Total CacheとRedisの調整 | 数百の設定項目をサーバー環境に合わせてフル調整する |
| 画像とアセットの最適化 | 画質を落とさずにWebPへ変換し不要なCSSとJavaScriptを断捨離する |
| CDN設定 | Cloudflare等のCDNを適切に設定し負荷を分散させる |
| 施工前のバックアップ | 万が一の際も復元できる状態で作業する |
含まれない作業
95,000円には、販売促進やマーケティングに関する作業は含まれない。
商品の売り文句を作る、広告運用の設定を変える、SEOのキーワードを調査する、といった作業はこの費用の対象外だ。
高速化に必要な作業だけを行い、それ以外はあなたのチームで進めてほしい。
外注する前に無料診断で分かること
WooCommerce高速化の外注を検討しているなら、まず無料診断を利用してほしい。
診断では、サイトのいまの表示速度を測り、どれくらい速くなる可能性があるかを私たちが確認する。
診断は義務ではない。
見積もりを取る前に「自分のサイトは本当に速くなるのか」を確認できる。
診断の結果を見てから、施工を依頼するかどうかを決めてよい。
診断で伝えること
診断を受けるときは、サイトのURLを伝えるだけでよい。
WooCommerceのサイトであれば、管理画面へのアクセスは最初の診断では不要だ。
私たちはURLを見て、読み込みに時間がかかっている場所を調べる。
診断の結果で分かること
診断では、ページの読み込みを待たせている原因がどこにあるかを特定する。
画像が重いのか、キャッシュの設定が合っていないのか、CDNが効いていないのか。
原因が分かれば、95,000円の施工でどのくらい状況が変わるかの見通しも立つ。
無料の高速化プラグインと外注は、ここが違う
無料の高速化プラグインを入れて失敗した人は少なくない。
画面が真っ白になったり、スマホの表示が崩れてボタンが押せなくなったりする。
そのたびにプラグインを外して、設定を見直す作業が発生する。
私たちの外注は、この無料プラグインの失敗パターンから逆算して設計している。
設定項目が少ない簡易プラグインを使わず、W3 Total Cacheの数百の設定項目をサーバー環境に合わせて調整する。
無料プラグインで起きる失敗
- 画面が真っ白になったり、スマホの表示が崩れてボタンが押せなくなる
- キャッシュの設定を誤り、カゴに入れられない、決済画面に進めないという致命的な不具合が出る
- キャッシュが切れた直後に来た最初のお客様だけが低速表示になり、機会を失う
外注が変えること
外注では、キャッシュをしてよい場所と、いけない場所を最初から見極めて設定する。
カート、決済、マイページはキャッシュから厳密に除外するので、個人情報をキャッシュしない。
トップページや商品一覧など、誰が見ても同じ内容の場所は、ログイン中でもキャッシュを効かせる。
無料プラグインだと更新のたびに低速へ戻る。
私たちの施工では、独自開発プラグインが失われたキャッシュを即座に再生成する。
スコアを出すことをゴールにせず、売上と体感速度をゴールに置いている。
サーバーを乗り換えずに高速化できる理由
WooCommerce高速化というと、サーバーをグレードアップするか、高スペックのレンタルサーバーへ引っ越すことを思い浮かべるかもしれない。
私たちの施工では、サーバーを乗り換えずに今の環境のまま高速化する。
表示速度の遅さは、サーバーの性能だけが原因ではない。
キャッシュの設定、画像の形式、CDNの有無、CSSやJavaScriptの重さが、サーバー本体よりも足を引っ張っていることが多い。
独自開発プラグインの役割
私たちは独自開発プラグインを常駐させる。
記事や商品を更新した瞬間にキャッシュを生成し、切れを検知して自動で再構築する仕組みだ。
キャッシュが切れた直後に来たお客様が低速表示に巻き込まれ、一日に何人も逃げていく機会損失をなくす。
アップデートしても高速化が崩れない
コアファイルを直接書き換えないので、WordPressやプラグインを更新しても高速化の仕組みが維持される。
運用中に気を遣わなくて済む。
商品数が増えたり、将来の機能を追加したりしても、負荷が増えることを前提に設計している。
ログイン中のお得意様にだけ遅いサイトを見せている状態は、キャッシュ設計の見直しで解消できる。
購入済みの顧客が商品選びで快適にページを回れるようになる。
依頼するとどう進むか
私たちのWordPress・WooCommerce高速化サービスは、サーバーを乗り換えずに、今の環境のまま表示速度を上げる。
カートと決済を守るために、キャッシュしてよい場所と、いけない場所を手動で切り分ける。
料金は一式95,000円（税込）だ。
まずはサイトURLを拝見して、どれくらい速くなるかを無料で診断する。
診断の結果を見てから、施工を依頼するかどうかを決めてよい。
待たされて逃げていた客がそのまま買っていき、広告費は増やさないまま売上だけが伸びる。
表示の遅さに悩まされてきた日々が終わり、サイトの運営に集中できるようになる。
WordPress・WooCommerce高速化サービスの無料診断を申し込む
WordPress・WooCommerce 高速化サービス今のサーバーのまま、WooCommerceサイトを高速化して表示待ちによる離脱を止める施工サービスサービスの詳細を見るよくある質問
95,000円以外に追加費用はかかるか
かからない。
料金は一式95,000円（税込）で、現状分析からCDN設定までを含む。
月額費用も発生しない。
販売促進やマーケティングの作業を追加で頼む場合は別途になるが、高速化の施工だけであれば追加費用はない。
サーバーを乗り換えなくても本当に速くなるのか
速くなる。
遅さの原因の多くはサーバーの性能ではなく、キャッシュの設計と画像の最適化にある。
私たちは今のサーバーのまま、キャッシュを生成する仕組みとCDNの設定を変える。
サーバーを替えずに体感速度を上げる。
無料診断は何を伝えれば受けられるか
サイトのURLを伝えるだけでよい。
私たちが読み込み時間を測り、遅い原因がどこにあるかを確認する。
管理画面へのログイン情報は診断の段階では不要だ。
カートや決済が壊れる心配はないか
カート、決済、マイページはキャッシュから厳密に除外する。
トップページや商品一覧など、誰が見ても同じ内容の場所だけをキャッシュする。
個人情報をキャッシュしない設計なので、安全に高速化できる。
施工前にはバックアップも取得する。
WordPressやプラグインを更新したら高速化は崩れるか
崩れない。
コアファイルを直接書き換えずに施工するので、アップデート後も高速化の仕組みが維持される。
独自開発プラグインがキャッシュの切れを検知して自動で再構築する。
この記事のポイント
- WooCommerce高速化を外注する費用は一式95,000円（税込）だ
- 現状分析、独自開発プラグインの実装、W3 Total CacheとRedisの調整、画像最適化、CDN設定、バックアップが含まれる
- 申し込み前の無料診断で、どれくらい速くなるかを確認できる
- サーバーを乗り換えず、今の環境のまま高速化する
- カートと決済を守りながら、ログイン中のお得意様にも高速表示を届ける
WordPress・WooCommerce 高速化サービス今のサーバーのまま、WooCommerceサイトを高速化して表示待ちによる離脱を止める施工サービスサービスの詳細を見る・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce Dual APIが専用プラグインに移行、コアから削除へ
WooCommerce 11.2で、実験的なDual APIエンジンがコアから削除され、専用プラグインとして提供される。10.9から11.1まで利用できた検証用の商品・クーポンAPIも廃止されるため、使っていた開発者は対応が必要だ。
Dual APIとはPHPクラスからGraphQLエンドポイントを自動生成するコードファーストな仕組みで、WooCommerce 10.9で実験機能として導入された。今回の変更は、開発の自由度を高めるための構成変更である。
WooCommerce 11.2でDual APIの提供形態が変わる
WooCommerce 10.9で導入されたDual APIは、PHPクラスを定義するだけでGraphQLエンドポイントを生成できる実験的な拡張機能だった。これまではWooCommerce本体に組み込まれ、フィーチャーフラグで有効化する方式だった。
WooCommerce 11.2では、このDual APIエンジンがWooCommerceコアから削除される。代わりに、WooCommerce Dual APIプラグインとして独立したリポジトリで提供される形だ。
この変更により、WooCommerce本体のリリースサイクルに縛られず、Dual APIだけを柔軟にアップデートできるようになる。Dual APIエンジン自体は、独自のAPIを開発したいエクステンション開発者にとって引き続き有用だ。
検証用の商品・クーポンAPIは削除される
WooCommerce 10.9から11.1まで、商品とクーポンに関する検証用APIが組み込みで提供されていた。このAPIはWooCommerce 11.2で削除される。
この検証用APIを使っていた開発者は、利用を停止するか、自前のエクステンションで同等のAPIを構築する必要がある。注意点として、Dual APIプラグインをインストールしても、この検証用エンドポイントが復活することはない。
Dual API移行で開発者が知るべき変更点
独自のDual APIを開発しているエクステンション開発者には、いくつか重要な変更がある。フィーチャーフラグの廃止、APIビルダースクリプトの移設、ドキュメントの場所変更、そして依存関係の宣言方法だ。
プラグイン依存関係をヘッダーに宣言する
これまでDual APIエンジンを有効化していたフィーチャーフラグは利用できなくなる。代わりに、Dual APIプラグインをインストールして有効化することでエンジンが使えるようになる。プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上だ。
エクステンションがDual APIエンジンに依存する場合、プラグインのヘッダーで両方の依存関係を宣言する必要がある。具体的には以下のように記述する。
Requires Plugins: woocommerce, woocommerce-dual-apiこの記述により、エクステンションのインストール時にWooCommerce本体とDual APIプラグインの両方が必要であることが明示される。依存関係の宣言は、プラグインの動作に必要な前提条件をユーザーに伝える重要な役割を果たす。
APIビルダーとドキュメントの場所が変わる
APIビルダースクリプトは、WooCommerce Dual APIプラグインのリポジトリに移動した。利用するには、プラグインをインストールするか、リポジトリをローカルにクローンする。
ドキュメントもDual APIプラグインのリポジトリ内に移設された。GitHub Pagesでも閲覧できる形で提供されている。開発者は最新のドキュメントをプラグインリポジトリで確認することになる。
エンドポイント登録のコード例
Dual APIプラグインはエンジンを提供し、エクステンション側で独自のGraphQLエンドポイントを登録する。WooCommerceのシンプルイベントサンプルプラグインから、登録方法のコードを示す。
use Automattic\WooCommerce\Api\Infrastructure\Main as DualApiMain;
add_action(
'plugins_loaded',
static function () {
if ( method_exists( DualApiMain::class, 'register_graphql_endpoint' ) ) {
DualApiMain::register_graphql_endpoint(
__DIR__,
'wc',
'/graphql/simple-events'
);
}
}
);このコードは、プラグインの読み込み時にDual APIエンジンが利用可能か確認し、利用可能であればGraphQLエンドポイントを登録する。エンドポイントのパスや名前空間はエクステンションごとに自由に設定できる。
Dual APIは引き続き実験的ステータス
Dual APIはプラグインに移行した後も、実験的なステータスは変わらない。Automattic\WooCommerce\Api名前空間以下のすべての要素は、後方互換性のない形で変更される可能性がある。
つまり、将来のリリースでAPIの構造が変わったり、削除されたりする可能性があるということだ。このため、本番環境のエクステンションでDual APIを使用することは推奨されていない。開発用途や検証目的に限定して使うべきだろう。
開発者コミュニティへのフィードバック募集
WooCommerceチームは、Dual APIエンジンが実際に有用かどうか、非実験的な状態でWooCommerce本体に含めるべきか、改善点はないかについて、開発者からの意見を求めている。
フィードバックはGitHubの専用ディスカッションページで受け付けている。Dual APIを試した開発者は、実際の使用感や要望を共有することで、今後の方向性に影響を与えることができる。
この記事のポイント
- WooCommerce 11.2でDual APIエンジンがコアから削除され、専用プラグインとして独立した
- 10.9〜11.1の検証用商品・クーポンAPIは削除されるため、利用者は移行が必要
- プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上
- 依存関係はプラグインヘッダーで宣言する
- 引き続き実験的ステータスであり、本番利用は推奨されない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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 7.4と8.0は、PHP公式のセキュリティサポートがすでに終了している。サポートが切れたバージョンでサイトを運営し続けると、新しい脆弱性が発見されても修正パッチが提供されない。WooCommerce側でパッチを出しても、PHPランタイム自体のリスクは残る。
依存関係の更新とコードパスの削減
PHP 7.4と8.0に対応し続けるには、古い依存パッケージを固定し、バージョンごとの分岐コードを維持する必要がある。PHP 8.1を最低ラインにすることで、開発者とエクステンション製作者は新しいPHP機能を使え、テスト対象の環境も減らせる。WooCommerceはすでにPHP 8以上での動作を長年サポートしてきた実績がある。
今回の変更は、最低ラインを引き上げて将来のリリースの土台を作るものだ。コミュニティからのフィードバックを受けて、対象リリースをWooCommerce 11.6に設定した。繁忙期の後に十分なテストとアップグレードの時間を確保できるよう配慮されている。
デモで示したように、最低要件の引き上げは単なる制限強化ではなく、開発基盤を健全化するための措置だ。PHP 8.1以降には型システムの改善やJITコンパイラの成熟など、パフォーマンスと保守性の面で有利な機能が揃っている。
WooCommerce 11.3で表示される警告通知
WooCommerce 11.3から追加される通知は、PHP 7.4または8.0で稼働するストアの管理画面にのみ表示される。現在のPHPバージョンを表示し、ホスティング事業者にアップグレードを相談するよう案内する。通知は閉じられる仕組みで、11.3の利用自体は従来のPHPでも継続できる。
通知の役割はあくまで予告だ。実際に最低要件が変わるのはWooCommerce 11.6がリリースされたタイミングになる。それまでは通常どおり11.3、11.4、11.5へと更新を続けられる。
通知を閉じた後で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への更新が可能になる。
ステージング検証は省略しがちだが、決済や配送計算の不具合は売上に直結する。特に拡張機能やカスタムコードを多用するストアでは、本番前に必ず検証したい。
アップグレードが間に合わない場合の選択肢
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のパッチだけではランタイムのリスクを解消できない。
移行が遅れる理由として、特定の拡張機能が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アップグレードは早めに着手し、繁忙期に入る前に完了しておくのが安全だ。
この記事のポイント
- WooCommerce 11.6からPHP 8.1以上が必須になり、11.3で警告通知が追加される
- PHP 7.4と8.0は公式セキュリティサポートが終了しており、移行は不可避だ
- 11.5までは従来のPHP環境で更新可能だが、あくまで一時的な選択肢だ
- 移行前にはバックアップとステージング検証を必ず実施する
- PHP 8.3以上への更新がWooCommerceの現在の推奨だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI検索がECを変える。検索クエリは6語から24語へ拡大
AI検索エンジンの台頭により、ECサイトの商品発見の仕組みが根本から変わりはじめている。消費者は短いキーワードの組み合わせではなく、文脈や使用シーンを盛り込んだ長い自然言語で商品を探すようになった。
従来の検索エンジンでの平均クエリは約6語だった。一方、大規模言語モデル（LLM、人間のように自然な文章を理解・生成できるAIモデル）を活用したAI検索では、平均約24語にまで拡大している。この4倍の変化は、商品カタログとプロダクトページの設計思想そのものの見直しを迫るものだ。
この記事では、AI検索がECサイトに与える具体的な影響、対応策、そしてマーケティング担当者が見直すべき思考法について解説する。WooCommerceをはじめとするECプラットフォームを運営する事業者にとって、今後12ヶ月の優先課題が見えてくるはずだ。
AI検索が変える検索クエリの姿
消費者が検索窓に入力する言葉が劇的に変化している。かつては「防水 ランニング シューズ 軽量」のような短いキーワードの羅列が一般的だった。いまは「雨の日でも滑りにくくて、通勤でも使える軽いランニングシューズを探しています。週末は10キロ走るのでクッション性も欲しいです」といった会話調の質問に変わっている。
6語から24語へ、検索行動の変化
MarTechのポッドキャスト「Conversations with MarTech」に出演したOpiversalのCEO、Lucas Tieleman氏は、この変化を具体的な数字で示している。従来のGoogle検索での平均クエリは約6語だった。ところがLLMを活用した検索では平均約24語に拡大している。ユーザーは検索エンジンに「単語を投げる」のではなく「相談する」姿勢に変わったのだ。
会話的クエリが商品発見に与える意味
検索クエリが会話的になるということは、商品が文脈で選ばれる時代の到来を意味する。「軽いランニングシューズ」という単語だけでは用途が見えなかった。しかし「通勤で使える」「週末に10キロ走る」といった文脈が加わることで、同じ商品が異なる理由で選ばれる可能性が生まれる。Tieleman氏は「同じ商品でも、人によって異なる意味を持ちうる」と述べている。この多義性が、これからのECサイトの設計を難しくする一方で、差別化の余地も広げている。
検索クエリが短いキーワードから会話的な長文へ変化したことを示している。ECサイト側もこの変化に対応した情報設計が必要になる。
旧来の商品カタログが抱える限界
多くのECサイトの商品ページは、青いリンクとキーワード検索の時代に作られたものだ。商品名、価格、カテゴリ、簡単な説明文という最小限の属性を並べた静的ページが中心だった。この設計は、消費者が「単語を入力して結果の一覧から選ぶ」という行動パターンを前提にしている。文脈や使用シーンを含む24語のクエリに対して、こうした静的ページは十分な回答を提供できない。
ボットトラフィックの急増が見せる新しい現実
Tieleman氏が指摘するのは、AIエージェントによるボットトラフィックの急増だ。自律型AIエージェントが実際に購入を行う段階にはまだ至っていない。しかし、ユーザーの質問に答えるためにECサイトを巡回するLLMのトラフィックは爆発的に増えている。マーケティング担当者は、インプレッション（表示回数）とセールスの関係を従来とは異なる視点で捉え直す必要がある。表示回数が増えても、それが人間の目に触れているとは限らないからだ。
文脈的な属性情報とFAQを加えることで、AIが商品を理解しやすくなることを示している。
ECサイトがAI検索に対応するための3つの施策
AI検索時代において、ECサイトが取るべき具体的な対策は3つに集約できる。構造化データの整備、動的なランディングページ生成、そしてFAQの戦略的拡充だ。どれも特別なツールなしで今日から着手できる。
構造化データと会話的属性情報の整備
商品フィードの重要性はかつてないほど高まっている。構造化データとは、商品名や価格、属性などが機械に読み取りやすい形式で整理されたデータのこと。検索エンジンとAIプラットフォームに商品の存在を知らせるためには、高度に構造化されたデータを継続的に供給する必要がある。商品名と価格だけでは不十分だ。使用シーン、解決できる課題、関連するFAQなど、会話的な属性情報を追加することで、AIが商品を文脈に応じて提案しやすくなる。
WooCommerce運営者であれば、商品データの拡張は比較的容易だ。商品説明欄を充実させるだけでなく、カスタム属性やカテゴリタクソノミーを使って使用シーンや解決課題を明示的に登録できる。属性情報は商品のタイプごとに設計し、サイト全体で一貫した命名規則を保つことが重要だ。
動的なランディングページ生成
AIがコンテンツ制作の限界費用を大幅に下げたことで、EC事業者は変動するソーシャルトレンドや自然言語のクエリに合わせてカスタムランディングページを大量に生成できるようになった。Tieleman氏は「ウェブサイトは生きた有機体である」と表現している。固定された商品ページだけでなく、検索文脈に応じたランディングページを動的に用意することが、これからのECサイトには求められる。
FAQの戦略的拡充
FAQセクションは、AI検索対策の隠れた有力手段だ。商品に関する具体的な疑問と回答を構造化して掲載することで、AIエージェントが商品のユースケースを理解しやすくなる。「このシューズは幅広の足型に対応していますか」といった具体的な質問と回答は、まさに24語クエリの世界で求められている情報だ。FAQはユーザーが実際に抱く疑問を想定して作成し、商品データの一部として機械に読み取らせる意識が重要になる。
AIエージェントが商品データを巡回し、文脈に合う商品を提案する流れを示している。各ステップで構造化データが正しく読み取れるかが成否を左右する。
エージェント型購買の現実とマーケティングの再考
Tieleman氏との対話から浮かび上がるのは、AIエージェントが本当に「購入」を行うのはまだ先だという現実だ。現在はあくまで調査・比較の段階で、ボットが商品情報を収集しているにすぎない。しかし、この段階で商品データがAIに正しく理解されているかどうかが、将来の購入決定に直結する。準備を怠れば、AI検索の世界で商品が存在しないのと同じ扱いを受けるリスクがある。
単一の正解に執着することの無意味さ
Tieleman氏は「マーケティング業界が信じている最大の嘘」として、単一の正解を探し求めることへの執着を挙げている。現実には、現代のテクノロジーを使えば複数の施策を並行して検証し、効率的に失敗しながら最適解に近づくことができる。同氏の「いまのテクノロジーを使えば、もっと効率的に間違えることができる」という指摘は、マーケティングの思考法を変える視点だ。A/Bテストを繰り返すことへの心理的障壁を下げ、失敗をデータとして蓄積する姿勢が求められる。
商品を文脈で選ばせる設計へ
「AppleはUXとデザインの重要性を示す好例だ。Amazonはそうではないことを示している」というTieleman氏の発言は、ECサイト設計の2つの方向性を端的に表している。徹底したUXで差別化するのか、価格と品揃えで勝負するのか。AI検索時代には、どちらの戦略を選ぶにせよ、商品データが文脈を伝えられるかどうかが成否を分ける。デザインの優劣ではなく、データの伝達力が新しい競争軸になるのだ。
この記事のポイント
- 検索クエリは平均6語から24語に拡大し、会話調の質問へと変化している
- 従来の静的カタログは、文脈を含む長いクエリに十分応えられない
- AIエージェントによるボットトラフィックが急増し、商品データの構造化が必須になっている
- 構造化データ、会話的属性情報、FAQの拡充がAI検索対策の3本柱となる
- 単一の正解を求める思考を捨て、複数の施策を効率的に検証する体制が有効
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.1.2リリース！商品ギャラリーの無限再帰とメールレビュー検証を修正
WooCommerce 11.1.2が2026年9月22日にリリースされた。商品バリエーションギャラリーで発生する無限再帰の修正と、メール経由の商品レビューにおける入力検証の強化が含まれるドットリリースだ。
今回の更新はセキュリティ更新に該当する。データベースの更新は不要で、適用のハードルは低い。ECサイト運営者は早めのアップデートを検討したい。
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テーマや多くの人気テーマでは問題は発生しない。しかし、独自にカスタマイズしたテーマを使っている場合は注意が必要だ。
get_available_variations をテンプレート内で呼び出すと、内部フックが再帰的に実行されてスタックが溢れる。商品ページ全体が白画面になり、購入フローが停止する。上図のとおり、修正前は get_available_variations の再帰呼び出しにより商品ページ全体が停止する可能性があった。修正後はこの再帰が防止され、ギャラリーが正しく表示される。独自テーマを運用している場合は、この修正の適用前にステージング環境で動作確認することを推奨する。
メールレビューの検証を強化
2つ目の修正は、メール経由で投稿される商品レビューの入力検証を厳格化するものだ。GitHubのプルリクエスト番号68961で対応された。セキュリティ更新とされる理由はこの修正にある。
メールベースのレビュー機能とは
WooCommerceには、購入者からのレビューをメールで受け付ける仕組みがある。顧客が注文後に届くメール内のリンクからレビューを投稿できる機能だ。ECサイトにとってレビューは信頼構築の要であり、この導線はコンバージョン率にも影響する。
問題は、このメール経由の投稿経路において入力値の検証が十分でなかった点だ。悪意のある第三者が不正なデータを送信する余地があり、セキュリティリスクになり得た。今回の修正では、この検証処理が厳格化されている。
検証強化がもたらす効果
検証の厳格化により、不正な入力や改ざんされたデータがレビューとして投稿されるリスクが低減される。レビューの信頼性が保たれ、ECサイトの評判管理にも好影響を与える。
店舗運営者の目線では、この変更によってレビュー投稿のフローに大きな変化はない。顧客が正規のメールリンクからアクセスする限り、従来どおりの手順でレビューを投稿できる。内部のバリデーションが強化されただけなので、ユーザビリティへの影響はない。
上図のとおり、メール経由のレビュー投稿は4段階で処理される。今回の修正はSTEP 3の検証処理に焦点を当てており、不正なデータの流入を防ぐ役割を担う。顧客側の操作フローに変更はない。
ECサイト運営者が取るべき対応
この更新はセキュリティ更新のため、基本的には即時適用が望ましい。ただし、独自テーマやカスタムコードを使っているサイトでは、事前の動作確認を怠らないことが重要だ。
更新前の準備
更新の前に、サイト全体のバックアップを取得する。WooCommerceを運用するECサイトでは、商品データ、注文履歴、顧客情報が失われると事業に直結する。更新作業の前には必ずデータベースとファイルの両方をバックアップしておく。
また、ステージング環境が利用できるのであれば、本番環境に適用する前に更新後の動作を確認する。特にバリエーション商品を持つ場合は、商品ページでギャラリーが正しく表示されるかをチェックしたい。
更新手順の目安
WooCommerceの更新はWordPressの管理画面から行える。プラグイン一覧からWooCommerceを選択し、更新を実行するだけだ。データベース更新が不要なため、更新後のマイグレーション処理も発生しない。
更新後は、商品ページ、カート、チェックアウト、レビュー投稿の各フローが正常に動作するかを確認する。特にメールレビュー機能を有効にしている場合は、テスト用のレビューを1件投稿して検証すると安心だ。
この記事のポイント
- WooCommerce 11.1.2は2026年9月22日に公開されたセキュリティ更新で、データベース更新は不要
- 商品バリエーションギャラリーの無限再帰を修正し、独自テーマ利用時の白画面リスクを解消
- メール経由の商品レビューにおける入力検証を強化し、不正データの投稿リスクを低減
- 独自テーマやカスタムコードを運用中のサイトは、ステージング環境での事前確認を推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験