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最適化の豊富な経験
WP-Stagingサイトが重大なエラーで表示されない原因と直し方
WP-Stagingの複製サイトにアクセスすると「このサイトで重大なエラーが発生しました」と表示され、デバッグログに call_user_func_array の TypeError が記録される場合、PHP 8系ではコアファイルの欠落や混在が致命的エラーへ変わる。PHP 7.4系へ一時的に切り替えて管理画面へ入り、WordPressコアの再インストールとプラグイン更新を行えば根本から直る。
WP-Stagingサイトが重大なエラーになる原因
デバッグログの最終行には call_user_func_array() が「Argument #1 ($callback) must be a valid callback」という趣旨の TypeError を投げ、_wp_register_default_icon_collections という関数が見つからないことが記録される。この関数は WordPress 本体の wp-includes/theme.php で定義されるもので、本来は必ず存在しているはずだ。
WP-Staging はライブサイトのファイルとデータベースをコピーしてステージングサイトを作る。このとき wp-includes 内のファイルが不完全にコピーされていたり、旧バージョンのコアファイルと新バージョンが混在したりすると、関数が未定義のまま WordPress の読み込み処理が進み、このエラーが発生する。
PHP 8.0 以降は call_user_func_array() に存在しない関数を渡すと、警告ではなく TypeError を投げて処理を停止する。PHP 7.4 までは警告を出して読み込みが続いたため、バージョンを下げると画面が復帰する。ただし原因であるコアファイルの欠落は残ったままなので、根本解決にはならない。
同じログに Wordfence や ThemeWhizzie の Deprecated 警告も出ている。これらは PHP 8 で廃止予定になった古い記法への警告で、単体ではサイトを落とさない。ただ PHP 8 非対応の古いコードが残っている証拠なので、更新で片付けておく必要がある。
debug.logに記録されたエラーを読み分ける
WordPress のデバッグ情報は wp-content/debug.log に保存される。今回のログには Deprecated 警告が数件並び、最後に Fatal error が1件出ている。サイトが落ちる直接原因は Fatal error の1件だけだ。まだログを有効にしていない場合は、wp-config.php を編集して次の3行を追加する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Fatal error の内容は「呼び出そうとした関数が見つからない」という意味だ。_wp_register_default_icon_collections が WordPress 本体に無いことから、コアの関数定義が不足していると判断できる。Wordfence の Non-canonical cast や ThemeWhizzie の Creation of dynamic property は、PHP 8 で非推奨となった書き方を警告しているにすぎない。
PHP 7.4系へ切り替えて管理画面に戻る
最初の応急処置として、サーバーの PHP バージョンを 7.4 系へ変更する。ホスティングの管理画面にある「PHP バージョン管理」や「PHP Selector」などから選択するのが一般的だ。IIS 10 で FastCGI を使っている場合は、php-cgi.exe のパスを 7.4 系へ変更する。切り替え後はステージングサイトを再読み込みして、管理画面に入れるか確認する。
PHP 8 系ではコールバック不足が TypeError で致命化し、PHP 7.4 系では警告として読み込みが継続する。この違いにより、バージョンを下げると一時的にサイトが復帰する。
ただし PHP 7.4 系はセキュリティサポートが終了している。常用するのは避け、次の手順で WordPress 本体とプラグインを整えた後、PHP 8 系へ戻すのが安全だ。
WordPressコアを再インストールして欠落ファイルを戻す
根本原因は WordPress 本体のファイルが不完全なことだ。管理画面に戻れたら、ダッシュボードの「更新」画面から現在のバージョンを再インストールするのが最も簡単だ。ファイルの欠落や破損が解消され、関数が再び見つかるようになる。
復旧手順の全体像は上のとおり。各ステップの詳細を以下に示す。
ダッシュボードからコアを再インストールする
管理画面の「ダッシュボード」→「更新」を開くと、「WordPress の最新バージョンを実行しています」の下に「バージョン XX を再インストール」というボタンが表示される。ここを押せば、同じバージョンのコアファイルが公式配布パッケージから取得され、欠落している wp-includes 内のファイルが上書きされる。
再インストール後にステージングサイトを更新し、重大なエラーが消えたかを確認する。もし管理画面にも入れない状態なら、次の FTP で対処する方法を試す。
管理画面に入れないなら FTP で wp-includes を上書きする
ステージングサイトにアクセスできない場合、FTP または SFTP でサーバーへ接続する。WordPress の公式サイトから同じバージョンのパッケージを取得し、その中の wp-includes と wp-admin フォルダを、壊れているステージング側へ上書きアップロードする。
wp-content フォルダは上書きしない。ここにはテーマやプラグイン、アップロード画像が入っており、上書きすると設定が消える危険がある。あくまでコアのファイルだけを入れ替えるのが安全だ。
ステージングサイトを作り直す判断
破損の範囲が広い場合や、エラーが複数回繰り返される場合は、WP-Staging でステージングサイトを作り直すのも有効だ。その際、除外設定やファイルコピーの途中で止まっていないか、保存容量が十分かを確認する。ライブサイト側が正常なら、再作成のほうが速く済むことも多い。
Wordfenceと使用テーマをPHP 8対応版へ更新する
Fatal error とは別に、Wordfence と ThemeWhizzie から Deprecated 警告が出ている。これは今すぐサイトを落とすものではないが、PHP 8 系で廃止された書き方を使っており、将来の PHP 更新で同じく致命的エラーへ変わる可能性がある。根本解決の段階でまとめて更新しておく。
Wordfence はプラグインの更新画面から最新版へ更新できる。テーマが市販テーマで更新が止まっている場合は、PHP 8 非対応の警告が出続けるため、テーマの差し替えや該当するウィザード機能の無効化を検討する。更新が終わったら PHP を 8 系へ戻し、ステージングサイトが表示されるか、デバッグログに Fatal error が出ないかを確認する。
よくある質問
PHP 7.4に戻すだけで問題は解決するのか
サイトは一時的に復帰するが、コアファイルの欠落や混在という原因は残る。PHP 7.4 系はセキュリティサポートが終了しているため、WordPress コアの再インストールで根本解決してから PHP 8 系へ戻すのが正しい流れだ。
管理画面にも入れないときはどうするのか
FTP または SFTP でサーバーへ接続し、WordPress 本体の wp-includes と wp-admin を公式パッケージから上書きする。その前に wp-config.php でデバッグログを有効にしておくと、上書き後もエラーが出る場合に原因を特定しやすい。
WordPressコアの再インストールでデータは消えるのか
ダッシュボードからの再インストールでは wp-content を触らないため、テーマやプラグイン、アップロード画像、データベースの内容は消えない。念のため実行前にバックアップを取るのが安全だ。
ステージングサイトを作り直した方が速いのか
ファイル破損の範囲が広い場合や再発を繰り返す場合は、WP-Staging で作り直す方が確実だ。その際は除外設定と保存容量を確認し、ライブサイト側が正常であることを先に確かめておく。
Wordfenceの警告をPHP 8のままで消せるのか
Wordfence を最新版へ更新すれば大半の Deprecated 警告は消える。テーマ側の警告が残る場合は、該当するウィザード機能を無効化するか、PHP 8.1 系を選んで一時的に警告を抑える方法もある。ただし警告を無理に隠すより、コードを更新する方が安全だ。
この記事のポイント
- call_user_func_array の TypeError はコアファイル欠落が PHP 8 で致命化したもの
- PHP 7.4 への切り替えは応急処置で根本解決ではない
- 管理画面から WordPress コアを再インストールして欠落ファイルを戻す
- Wordfence とテーマを更新し PHP 8 へ戻して確認する
- ステージング作成時の除外設定やファイルの完全性も確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressでデータベースのテーブルが見つからないエラーの原因と対処法
WordPressで「テーブルが見つからない」エラーが表示されたら、まずwp-config.phpのテーブル接頭辞（$table_prefix）とデータベース内の実際のテーブル名を照合する。接頭辞が一致していなければ設定を修正し、そもそもテーブルが存在しない場合はバックアップからの復元が必要になる。
なぜWordPressで「テーブルが存在しない」エラーが発生するのか
WordPressは投稿や固定ページ、ユーザー情報をすべてデータベースに保存している。データベースの中には複数のテーブルがあり、それぞれ「接頭辞＋テーブル名」という形式で管理される。接頭辞はセキュリティ対策としてサイトごとに変えられる仕組みだ。たとえば初期状態ではwp_posts、wp_optionsという名前になる。
この接頭辞はwp-config.phpという設定ファイルの$table_prefixで指定する。実際のデータベースにあるテーブル名と、この設定ファイルの値が食い違うと、WordPressが存在しない名前のテーブルを探しに行き「テーブルが見つからない」エラーを起こす。サイト移転や手動バックアップの復元時に、データベースだけ別の接頭辞で持ってきてしまった場合に起きやすい。
データベース修復機能は破損したテーブルを直すためのもので、存在しないテーブルを新しく作ることはできない。そのため「修復」を実行してもエラーは解消されない。問題の切り分けには、まず実際にどんなテーブルが存在するのかを確認する必要がある。
データベース内の実際のテーブル接頭辞を調べる方法
エラーの原因が接頭辞の不一致か、それともテーブル自体が消えているのかを切り分けるには、データベース管理ツールを開いて実在するテーブル名を確認する。レンタルサーバーの管理画面にログインし、phpMyAdminと呼ばれるデータベース管理ツールを選択するのが最も確実だ。
テーブル一覧にwp_postsやwp_optionsという名前が見えたら、実際の接頭辞はwp_だ。この場合、設定ファイルが別の値を指していることが原因なので、次の手順で修正する。一方、テーブル一覧が空だったり、別の名前でも見当たらない場合は、テーブル自体が失われている可能性が高い。
wp-config.phpのテーブル接頭辞を正しい値に直す手順
設定ファイルの修正は、FTPソフトかレンタルサーバーのファイルマネージャでwp-config.phpを直接編集する。WordPressをインストールしたルートディレクトリにあるこのファイルを開き、$table_prefixが書かれた行を探す。
保存後にサイトを再読み込みすると、これまで表示されていたテーブル関連のエラーが消えて通常の画面が戻る。管理画面にもアクセスできるようになるはずだ。なお、wp-config.phpを編集する前には必ずファイルのバックアップを取っておくこと。
ファイルマネージャで編集できない場合は、FTPソフトでサーバーに接続して同じファイルをダウンロードし、テキストエディタで修正してアップロードする。文字コードはUTF-8のまま保存する。
テーブルが実際に消えている場合の復元方法
phpMyAdminで確認しても該当するテーブル自体が存在しない時は、設定の不一致ではなくデータが失われている状態だ。この場合は修復機能では戻らないため、バックアップからの復元が必要になる。
- レンタルサーバーの自動バックアップ機能を確認する
- 運用中に取得していたバックアップデータから復元する
- ホスティング事業者のサポートに問い合わせる
バックアップが手元にない場合でも、ホスティング事業者が定期的にサーバー全体のバックアップを保持していることが多い。データベースだけを復元できるか、サポートに確認するのが得策だ。復元後は接頭辞の一致を必ず確かめる。
テーブル接頭辞の不一致を防ぐための確認ポイント
サイト移転やバックアップ復元の後に同じエラーを再発させないためには、接頭辞とデータベースの状態を習慣的に確認しておくとよい。最低限のポイントを挙げる。
- サイト移転時は設定ファイルとデータベースの接頭辞を照合する
- テスト環境と本番環境では同じ接頭辞にそろえる
- wp-config.php を編集する前に必ずバックアップを取る
- 不要なデータベース修復を連続実行しない
よくある質問
接頭辞を直したのにまだテーブルが見つからないエラーが出る
設定ファイルを保存した後もブラウザやサーバーのキャッシュが残っていると表示が変わらない場合がある。ブラウザをスーパーリロードし、サーバー側のキャッシュを削除してから確認する。それでも出る場合は、実際に存在するテーブル名と設定値をもう一度照合し、データベース名やホスト名も確認する。
phpMyAdmin を使わずに接頭辞を確認できるか
wp-config.php の設定だけでは実際のテーブル名は分からない。データベース管理ツールか、ホスティング事業者の管理画面にあるデータベース一覧で確認する。どうしても見つからない時はサポートに問い合わせると接頭辞を教えてもらえる場合がある。
WordPress の修復機能でテーブルが消えることはあるか
修復機能は既存テーブルの破損を修復するのが目的で、テーブル自体を削除する動作ではない。ただし存在しないテーブルは作成できないため、修復を実行してもテーブルがないエラーは解消しない。元のテーブルが消える主な原因はデータベースの操作ミスやインポート時の上書きだ。
バックアップからデータベースだけ復元する手順は
ホスティングの管理画面にあるバックアップ機能を開き、復元したい日時のデータベースを選ぶ。phpMyAdmin からインポートできる SQL ファイルがある場合は、該当するデータベースを選択してインポートを実行する。操作前に現在のデータを追加でエクスポートしておくと安全だ。
接頭辞を wp_ に変更すると既存データは消えるか
接頭辞の変更そのものはテーブル名を読み替えるだけで、データを削除しない。ただし実在しない接頭辞に変更すると WordPress がテーブルを見つけられず、同じエラーになる。必ずデータベース内の実名と一致する値に変更する。
この記事のポイント
- テーブルが見つからないエラーは接頭辞の不一致が第一原因
- phpMyAdmin で実際のテーブル名を確認する
- wp-config.php の $table_prefix を実在の接頭辞に合わせる
- テーブル自体が無い時はバックアップ復元が最短ルート
- 設定変更前に必ず wp-config.php とデータベースのバックアップを取る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceのApple PayとGoogle Payがクラシックカートで表示されない時の直し方
ECサイトでWooCommerceのクラシックカートとクラシックチェックアウトにApple PayやGoogle Payのボタンが表示されない場合、原因の多くはStripeが提供するホスト型決済方法設定がショートコード版ページのJavaScript初期化と衝突していることにある。商品ページやブロックカートでは正常でも、ショートコード版だけ動かないという状況では、決済ゲートウェイの初期化スクリプトが正しく読み込まれていない可能性が高い。
なぜクラシックカートだけApple PayとGoogle Payが表示されないのか
WooCommerceのStripeゲートウェイは、ページの種類に応じて決済ボタンを表示するためのJavaScriptを別々のタイミングで初期化する。ブロックカートとブロックチェックアウトは新しいGutenbergブロックとしてレンダリングされるため、StripeのExpress Checkoutボタンを配置する専用のコンテナが自動で用意される。
一方、クラシックカートとクラシックチェックアウトはショートコード（[woocommerce_cart]と[woocommerce_checkout]）でページに埋め込まれる。この方式では、テーマのJavaScriptやjQueryの読み込み順によってStripeの初期化スクリプトが正しく実行されず、ボタンが表示されないことがある。特にカスタムテーマやテーマビルダーを使っている場合は競合が起きやすい。
もう一つの有力な原因が、WooCommerceのログに出力されている「Stripe-hosted payment method configuration（ホスト型決済方法設定）」への切り替えエラーだ。Stripeがホストする決済方法設定に切り替わると、従来のローカル設定で動いていたExpress Checkoutボタンの初期化ロジックと整合しなくなることがある。これはStripeアカウント側の設定変更によって発生する。
つまり、症状がショートコード版ページに限定されるのは、決済ゲートウェイ自体の設定ミスではなく、ページのレンダリング方式とStripeスクリプトの初期化タイミングのずれが主因であるケースがほとんどだ。
JavaScriptコンソールでエラーを確認する手順
真っ先に調べるべきは、クラシックカートとクラシックチェックアウトのページでJavaScriptエラーが出ているかどうかだ。ブラウザのデベロッパーツールを使えば、原因となるスクリプトを特定できる。
Chromeの場合、クラシックカートのページを開いた状態で「F12」キーを押し、「Console」タブを確認する。赤いエラーメッセージが表示されていれば、その内容を記録する。特にwc_stripe_upe_paramsやwp.escapeHtmlに関連するエラーはStripeゲートウェイの初期化失敗を示す代表的なものだ。
FirefoxやEdgeでも同様に、開発者ツールのコンソールから確認できる。スマートフォンで確認する場合は、パソコンのブラウザでデベロッパーツールを開き、デバイスエミュレーションモードにして同じページを読み込むとよい。
Stripeのホスト型決済方法設定を無効化する
WooCommerceのログにホスト型決済方法設定への切り替えエラーが出ている場合、Stripeダッシュボード側の設定を変更するか、プラグイン側でホスト型設定を手動設定に戻す必要がある。
このデモはStripe設定の確認から修正までの手順の流れを示したものだ。実際の管理画面の項目名はWooCommerce Stripeプラグインのバージョンによって若干異なる。
Stripeダッシュボードでは、ホスト型決済方法設定が有効になっていると、決済方法の組み合わせがStripeサーバー側で管理される。これがWooCommerce側のExpress Checkoutボタン初期化と競合し、クラシック版ページでのみボタンが出ない状態を引き起こすことがある。WooCommerce側のStripe設定画面で「決済方法を手動で管理」するオプションを選択し、Apple PayとGoogle Payを明示的に有効化すると改善するケースが多い。
プラグインの再設定だけでは直らない場合は、Stripeアカウントの接続を一度解除して再接続するのも有効だ。WooCommerceの「決済」タブからStripeを選び、「接続を解除」を押した後、再度Stripeアカウントで接続する。この操作でプラグインがStripeサーバーから最新の設定を取得し直し、ホスト型決済方法設定とのずれが解消されることがある。
クラシックカートのショートコードとページ設定を再確認する
クラシックカートとチェックアウトのページに正しいショートコードが貼られているかも併せて確認する。カートページには[woocommerce_cart]、チェックアウトページには[woocommerce_checkout]が必須だ。
WooCommerceの「設定」→「詳細設定」タブにある「カートページ」と「チェックアウトページ」の指定が、実際にショートコードを貼ったページと一致しているか確認する。別のページを指定したままだと、表示されている地図ページとStripeの初期化対象ページがずれて、ボタンが出ないことがある。
ページビルダー（ElementorやBeaver Builderなど）でカートページを作成している場合は、ショートコードウィジェットを配置しているか確認する。ページビルダーのテキストブロックにショートコードを直接入力していると、WooCommerceのテンプレートフックが正しく読み込まれず、StripeのExpress Checkoutボタン用のフックが実行されないことがある。
キャッシュとCDNを削除して再テストする
設定変更後もボタンが表示されない場合は、サーバー側のキャッシュとCDNのキャッシュが古いスクリプトを配信し続けている可能性がある。WooCommerce専用のキャッシュプラグインを使っている場合は、そのキャッシュを全削除する。CDN（コンテンツデリバリネットワーク / 配信網）を利用している場合は、CDNのダッシュボードからキャッシュをパージする。
その後、シークレットウィンドウ（プライベートブラウジング）でクラシックカートのページを開いて確認する。通常のブラウザに残っているクッキーやサービスワーカーが古いスクリプトを参照していることがあるため、シークレットウィンドウで確認するとキャッシュの影響を排除できる。
それでも直らない場合、一時的にすべてのプラグインを無効化して標準テーマに切り替え、WooCommerceとStripeゲートウェイだけを有効化した状態でテストする。この最小構成でボタンが表示されれば、別のプラグインかテーマが原因だ。影響しているプラグインを一つずつ有効化して切り分けていく。
よくある質問
商品ページではボタンが出るのにクラシックカートでは出ないのはなぜか
商品ページとクラシックカートではExpress Checkoutボタンを初期化するJavaScriptのフックが異なる。商品ページはWooCommerce標準のフックで動くが、カートとチェックアウトはページテンプレートの構造に依存するため、テーマやプラグインの競合で初期化が妨げられることがある。
ブロックカートに切り替えれば解決するのか
ブロックカートとブロックチェックアウトはGutenbergブロックとしてレンダリングされるため、Stripeゲートウェイが専用コンテナを確実に配置でき、ボタンが正常に表示される。どうしてもクラシック版を使い続ける必要がなければ、ブロック版への移行は有効な回避策になる。
Stripeアカウントの再接続だけでは直らない場合はどうするか
再接続で直らない場合は、WooCommerceのStripe設定画面でExpress Checkoutボタンの表示オプションを一度すべてオフにして保存し、再度オンにして保存する。これでプラグインの設定値がリフレッシュされ、クラシックページ用のフックが再登録されることがある。
ログに出るホスト型決済方法設定のエラーは無視してよいか
無視しないほうがよい。ホスト型決済方法設定への切り替えエラーは、Stripe側の設定とWooCommerceプラグインの設定が同期していない状態を示している。この状態を放置すると、クラシックページでのボタン非表示だけでなく、支払い処理自体に影響が出る可能性がある。Stripeダッシュボードで決済方法設定を確認し、手動設定に切り替えることを推奨する。
スマートフォンでもボタンが表示されないのは同じ原因か
基本的には同じ原因だ。ただしスマートフォンではApple PayとGoogle Payの表示条件が端末の対応状況にも左右される。iPhoneならSafari、AndroidならChromeで、ウォレットにカードが登録されていないとボタン自体が表示されない。パソコンで表示されることを前提に原因を切り分けるほうが正確だ。
この記事のポイント
- クラシックカートとチェックアウトだけボタンが出ないのはStripeスクリプトの初期化タイミングのずれが主因
- デベロッパーツールのコンソールでJavaScriptエラーを確認する
- Stripeダッシュボードのホスト型決済方法設定を手動設定に切り替える
- ショートコードの貼付位置とWooCommerceの設定ページ指定が一致しているか確認する
- キャッシュとCDNを削除し、シークレットウィンドウで再テストする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1 Mary Louリリース。レスポンシブ対応強化と新メディアエディタ搭載
WordPress 7.1「Mary Lou」が2026年8月19日に正式リリースされた。今回のメジャーアップデートでは、カスタムCSSなしでレスポンシブ対応ができるスタイル機能、新しいメディアエディタ、リッチテキスト対応のNotes機能などが追加されている。800人以上の貢献者による1,500以上の改良と修正が含まれる大規模リリースだ。
従来のWordPressでは、画面サイズごとに表示を調整するにはカスタムCSSを書く必要があった。WordPress 7.1ではサイトエディタ内で完結するため、中小企業のサイト担当者やコーディングに不慣れなユーザーでも直感的にレスポンシブ対応できるようになる。画像処理のブラウザ内実行や新ブロックの追加も見逃せない変更点だ。
WordPress 7.1の全体像と主要な新機能
WordPress 7.1のコードネーム「Mary Lou」は、ジャズピアニストのメアリー・ルー・ウィリアムズに由来する。彼女はスウィング、ビバップ、セイクリッドジャズとジャンルを横断しながら常にサウンドを再発明し続けた。その革新と協働の精神が今回のリリースに反映されている。
リリース全体の規模を見ると、世界中から800人以上の貢献者が参加し、170人以上が初めてコントリビュートした。修正と改良の総数は1,500を超える。主要な変更点は、レスポンシブスタイルのビジュアル編集、管理バーの全エディタ対応、新しいメディアエディタ、Notes機能の拡張、PlaylistとTabsの2つの新ブロック、そして開発者向けAPI群の公開だ。
このデモでは、WordPress 7.1の主要な変更点を分野別に色分けして示している。青がレスポンシブ対応、橙がメディア編集、紫がコラボレーション、緑がパフォーマンス、赤が新ブロックを表す。
今回のリリースの特徴を一言でまとめると、「サイト制作の作業導線を管理画面内に集約する」方向性が鮮明になったことだ。従来はCSSファイルの編集や複数の画面を行き来する必要があった作業が、ブロックエディタやサイトエディタの中で完結するようになっている。特に中小企業のサイト担当者にとっては、外注や開発者への依頼なしで調整できる範囲が広がる。
レスポンシブスタイルと管理バーの改善
カスタムCSSなしのレスポンシブ対応
WordPress 7.1では、サイトエディタのグローバルスタイルと個別ブロック設定の両方にレスポンシブコントロールが追加された。具体的には、デスクトップ・タブレット・モバイルの各画面サイズでブロックの表示をどう変えるかを、ビジュアル操作だけで設定できる。
編集中の画面でビューポート（表示領域の幅）を切り替えながらスタイルを調整できるため、仕上がりを確認しやすい。従来のようにカスタムCSSでメディアクエリを手書きする必要がない。この変更は、コーディングに不慣れなユーザーにとって特に大きな意味を持つ。
このデモでは、従来のカスタムCSSによる対応と、WordPress 7.1のビジュアル編集による対応の違いを示している。上段の赤い枠がBefore、下段の緑の枠がAfterを表す。CSSの記述が不要になり、プレビューを見ながら調整できるようになった点が大きな変化だ。
管理バーがすべてのエディタで表示される
管理バーがサイトエディタを含むすべてのエディタで追従するようになった。投稿執筆中でもサイトデザインの編集中でも、ダッシュボードや関連ツールへのショートカットが常に画面上部に表示される。WordPressの管理画面を行き来する手間が減り、作業導線が分断されにくくなった。
さらに、ブロックテーマではテーマの設定ファイル（theme.json）にタブレットとモバイルのブレークポイントを独自に定義できるようになった。レスポンシブスタイルとブロック表示の切り替えに使う画面幅の基準を、サイトごとに調整できる。
メディア編集の刷新と画像処理の高速化
新しいメディアエディタ
従来はインラインで行われていた画像の切り抜きが、新しいモーダル形式のメディアエディタに置き換わった。自由な切り抜き、アスペクト比を固定した切り抜き、水平・垂直の反転、細かな角度調整ができるスナップ回転、そしてメタデータ編集が1つの専用画面に統合されている。
エントリーポイントは従来と同じ「切り抜き」ボタンのまま。既存の操作感を維持しつつ、機能が大幅に拡張されたかたちだ。画像編集のためにプラグインを追加していたユーザーにとっては、標準機能だけで済むケースが増える。
このデモは、新しいメディアエディタの操作手順を4ステップで示している。青・緑・橙・紫の順に進み、1つのモーダル内で画像編集からメタデータ更新まで完結する流れが分かる。
ブラウザ内での画像処理
画像の圧縮・リサイズ・サムネイル生成が、サーバーではなくブラウザ内で実行されるようになった。libvipsのWebAssemblyビルドを利用しており、大きな画像をアップロードしてもPHPのメモリ制限やアップロードタイムアウトに引っかかりにくくなる。
サーバー負荷の軽減は、共有サーバーや低スペックのレンタルサーバーを利用しているサイトにとって特に有効だ。画像の多いメディアサイトやECサイトでは、アップロード時のタイムアウトエラーが減ることが期待できる。
対応画像形式も拡充された。AVIF、HEIC、HDRゲインマップのネイティブサポートが追加され、最新のスマートフォンやカメラで撮影した画像をそのまま扱えるようになった。GIFを動画に自動変換するオプションもあり、ファイルサイズの削減が進む。
Notes機能の進化とコラボレーション強化
WordPress 7.1では、コンテンツのレビュー作業を支援するNotes機能が大幅に拡張された。従来はブロック単位でしかコメントを残せなかったが、今回から特定のテキスト範囲に対してノートを付けられるようになった。
リッチテキストにも対応した。太字、斜体、コード表示、リンクの挿入がノート内で使える。さらに「@」を入力すると共同編集者をメンションでき、通知が飛ぶ。複数の会話を同じブロック内で並行して進められるほか、長いノートを折りたたんでサイドバーをすっきり保つことも可能だ。
この機能強化は、複数人で記事をレビューする編集部や、クライアントとの校正作業を行う制作会社にとって実用的な価値がある。フィードバックの場所が明確になり、メールやチャットでのやり取りをWordPress内に集約できる。
執筆中の投稿エディタも全テーマでiframe化された。編集キャンバスが管理画面のスタイルから分離されるため、テーマのCSSが管理画面のスタイルと衝突しにくくなる。ビューポート単位やメディアクエリが編集キャンバスを正確に参照するようになり、レスポンシブレイアウトのプレビュー精度が向上した。
新ブロックと開発者向けAPIの拡充
PlaylistブロックとTabsブロック
WordPress 7.1では2つの新しいブロックが追加された。Playlistブロックは複数の音声トラックを1つのプレイリストにまとめて再生できる。オプションで波形表示も付けられ、リスナーは各トラックの長さや進行具合を視覚的に把握できる。
Tabsブロックは、関連する情報をタブ形式で整理するためのブロックだ。すべてのコンテンツを一度に表示するのではなく、タブを切り替えて必要な内容だけを見せる。FAQ、料金プランの比較、製品仕様など、関連情報をコンパクトに提示したい場面で役立つ。
開発者向けAPI群
開発者向けの変更も大きい。SVG Icon APIが公開APIとなり、wp_register_icon_collection()、wp_register_icon()、wp_get_icon()といった関数で独自のアイコンコレクションを登録し、エディタ全体で利用できるようになった。
Abilities APIは前バージョンで導入された基盤を拡張し、フィルタ可能な実行ライフサイクル、カスタムバリデーション、共有ディスカバリーを追加した。WordPress上での統合機能や自動化、AI搭載ツールの構築が容易になる。
新しいDesign Systemは、色、角丸、カーソルスタイルを含むWordPress管理画面のテーマリングを支援する。開発者はセマンティックなデザイントークンとThemeProvider Reactコンポーネントを使って、WordPressに馴染むカスタム管理画面を構築できる。
テーマ開発者には、theme.jsonでレスポンシブスタイルと疑似状態（hover、focus、focus-visible、active）のスタイリングが可能になった。DataViewsとDataForm画面を設定する新しいフィルタも追加され、サイトエディタのページ・テンプレート・パーツ管理画面をカスタマイズできる。
パフォーマンスとアクセシビリティの改善
パフォーマンス面では、前述のブラウザ内画像処理に加えて、GIFから動画への自動変換が導入された。GIFアニメは動画ファイルよりサイズが大きくなりがちで、この変換によりページの読み込み速度が改善する。アップロードの進捗インジケーターと自動リトライも追加され、接続が途中で切れてもアップロードが再開できるようになった。
メディアライブラリはデフォルトで無限スクロールになった。ページネーションに戻すオプションもユーザーごとに用意されている。多数の画像を扱うサイトでは、ページを切り替える操作なしで目的のメディアを探しやすくなる。
Speculative loadingのデフォルト設定を、環境変数や定数で指定できるようになった。ホスティング事業者やサイト運営者は、プラグインを書かずにWordPressの先読み動作を設定できる。これはサイト速度の調整手段として、特にトラフィックの多いサイトで有用だ。
アクセシビリティの改善も続いている。wp_get_tooltip()とwp_get_toggletip()という新しい関数が追加され、投稿メタボックスやログイン画面を含む管理画面の各所でアクセシブルなツールチップを利用できるようになった。スクリーンリーダーのサポートも強化され、投稿一覧テーブルでのラベル付けとナビゲーションがより予測しやすくなっている。
この記事のポイント
- WordPress 7.1「Mary Lou」が2026年8月19日にリリースされた
- カスタムCSSなしでレスポンシブスタイルを設定できるようになった
- 新しいメディアエディタが切り抜き・反転・回転・メタデータ編集を統合
- 画像処理がブラウザ内で実行され、サーバー負荷とタイムアウトが軽減された
- Notes機能がリッチテキストとメンションに対応し、コラボレーションが強化された
- PlaylistブロックとTabsブロックが標準搭載された
- 開発者向けにSVG Icon API、Abilities API、Design Systemが公開された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressでHTTPS切替後に画像やメニューが崩れる時の直し方
WordPressサイトをHTTPからHTTPSへ切り替えた直後に、メニューが反応しない、画像ギャラリーが表示されない、ページレイアウトが崩れるといった症状が出る場合は、データベース内に残った「http」形式のURLが原因だ。Better Search Replaceというプラグインで旧URLを一括置換し、ElementorのCSSを再生成すれば解消できる。
なぜHTTPS切替後にサイト表示が崩れるのか
HTTPSへ切り替えただけでは、WordPressのデータベースに保存された古いURLは自動的に更新されない。投稿本文やメタ情報、ウィジェット設定、ElementorのCSSファイル内に「http」形式のURLが残ったままになるためだ。
ブラウザはHTTPSページの中にHTTPの画像やスクリプトが混在している状態を「混合コンテンツ」と呼び、セキュリティ上の理由で読み込みをブロックする。この結果、画像が途中で消える、メニュークリックが反応しない、ギャラリーのスライドが止まるといった症状が起きる。
HTTPとHTTPSが混在するとブラウザがリソースをブロックする仕組みのデモ。
Better Search Replaceでデータベースを一括置換する手順
壊れたURLを手作業で直す必要はない。Better Search Replaceという無料プラグインを使えば、データベース内のすべての「http」形式のURLを「https」形式に一括で置換できる。事前に必ずバックアップを取っておくこと。
Better Search ReplaceによるURL置換の全体の流れのデモ。
バックアップが最優先だ
置換操作はデータベース全体に影響を与えるため、失敗すると復旧が難しくなる。必ずプラグインやサーバー側のバックアップ機能で、データベースとファイルの両方を取得してから作業する。
検索と置換のURL指定を間違えない
検索フィールドには「http、自サイトのドメイン」、置換フィールドには「https、自サイトのドメイン」を入力する。ドメインの前後やスラッシュの有無を間違えると置換が正しく行われないため、コピーアンドペーストで正確に入力するのが安全だ。
置換後の確認ポイント
置換が完了したら、ブラウザのシークレットモードでサイトを開き、画像やメニューが正常に表示されるか確認する。管理画面の「設定 → 一般」に記載されたURLもHTTPSになっているか合わせてチェックする。
WordPress設定とElementorを修復する手順
データベースの置換後も、WordPressの「一般設定」に記載されたサイトURLとWordPress URLが正しいHTTPS形式になっているか確認する必要がある。管理画面にログインできる場合は、設定画面から変更するだけでよい。
管理画面に入れなくなった場合はphpMyAdminから修正する
URLを誤って書き換えてログインできなくなった場合は、サーバーの管理画面からphpMyAdminを開き、wp_optionsテーブルの「siteurl」と「home」の2つの値を正しいHTTPSのURLに戻す。これでWordPressに再ログインできる。
ElementorのCSSを再生成する
ElementorはCSSを自動生成して保存しているため、URL変更後はこのCSSが古いHTTPのURLを参照したままになることがある。Elementorの設定画面から「CSSを再生成」を実行し、合わせて「Elementorのデフォルト設定を更新」も確認する。
ElementorのCSS再生成の手順と修復後の状態のデモ。
置換しても直らない場合の追加対策
一括置換後にキャッシュやサーバー設定が原因で症状が残ることがある。順番に確認していくことで、残りの問題を特定できる。
ブラウザのデベロッパーツールで混合コンテンツを探す
ChromeやEdgeのデベロッパーツール（F12）を開き、コンソールタブを確認する。「Mixed Content」という警告が出ていれば、まだHTTPのURLが残っている。該当するURLをメモし、Better Search Replaceで追加の置換をかける。
キャッシュ系プラグインとサーバーキャッシュを削除する
キャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）が古いHTTPのページを保存していると、データベースを置換しても表示が変わらない。プラグインの設定からキャッシュを全削除し、あわせてサーバー側のキャッシュも管理画面からクリアする。
htaccessでHTTPをHTTPSへリダイレクトする
WordPressサイトのルートにあるhtaccessファイルに、HTTPアクセスをHTTPSへリダイレクトする設定を追加する。これにより、古いHTTPのURLにアクセスしても自動的にHTTPSへ転送され、検索エンジン評価の分散も防げる。不安であればサーバー会社のサポートに設定を依頼してもよい。
よくある質問
Really Simple SSLプラグインでは直らないのか
Really Simple SSLはHTTPSへのリダイレクトと、管理画面のURL更新を自動で行うプラグインだ。ただし、データベース内のすべてのHTTP URLを置換する機能は制限版では一部に限られる。画像やElementorのCSSに残るURLを完全に直すには、Better Search Replaceによる一括置換が必要になる。
置換後にログインできなくなったらどうするか
URL設定を誤るとログアウトして再ログインできなくなることがある。その場合はphpMyAdminからwp_optionsテーブルの「siteurl」と「home」を正しいHTTPSのURLに戻す。これで管理画面に再アクセスできる。
置換しても一部の画像が表示されない場合は
置換後の画像不表示は、キャッシュが古いHTTPのページを返しているか、CDNや外部サービスが元のURLを参照している可能性がある。キャッシュを全削除し、CDNを利用している場合はCDN側のキャッシュもクリアする。
HTTPS化後のSEOへの影響はあるのか
HTTPS化はGoogleのランキングシグナルとして評価されるため、正しくリダイレクトを設定すればSEOにはプラスに働く。サイト側でHTTPとHTTPSが両方アクセスできる状態を放置すると評価が分散するため、リダイレクト設定まで済ませておく。
Elementorで編集画面が真っ白になった場合は
URL変更後にElementorの編集画面が読み込めない場合は、CSS再生成とあわせて「Elementorのデフォルト設定を更新」を実行する。さらにWordPressのパーマリンク設定を一度「保存」して書き換えることで、内部リンク構造がリフレッシュされる。
この記事のポイント
- HTTPS切替後もデータベースにHTTPのURLが残り、混合コンテンツとしてブロックされる
- Better Search Replaceでhttpからhttpsへ一括置換する
- 置換前に必ずフルバックアップを取る
- ElementorはCSS再生成とデフォルト設定の更新が必要
- キャッシュ削除とリダイレクト設定で仕上げる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
2026年8月スパムアップデート開始！Google検索への影響と対策を解説
Googleが2026年8月18日、8月のスパムアップデートの展開を開始した。全言語・全地域が対象で、完了までに数日かかる見込みだ。Search Status Dashboardにランキングへ影響を与えるインシデントとして記録されている。
これは2026年に入って3回目のスパムアップデートとなる。3月の更新は過去最速の19時間30分で完了し、6月の更新は生成AI検索への操作対策もスパムポリシーの対象に含める方針が示された直後に行われた。
検索順位に動きが出た場合、スパムポリシー違反がないか確認することが重要になる。復旧には数ヶ月かかることもあるため、早期の対応が求められる。
8月スパムアップデートの概要
今回のアップデートは太平洋時間8月18日午前9時27分に開始された。日本時間では8月19日午前1時27分となる。Search Status Dashboardには開始時刻の約1分後、午前9時28分にリリースノートが掲載された。
適用範囲は全世界・全言語だ。Googleは完了までに数日かかる可能性があると案内している。この種のアップデートは、展開中に順位の変動が大きくなることがある。短期間のデータだけで判断せず、数日単位で傾向を見る必要がある。
公開時点では、Search Status Dashboardの注記に加えて公式ブログ記事は投稿されていない。スパムアップデートの概要ページも2025年12月から変更されていない。今回は新しいスパムポリシーの種類は追加されていない。既存のポリシーがそのまま判断基準になる。
このデモは8月スパムアップデートの展開フローを示している。各ステップの色分けは進行段階を表しており、青が開始、緑が適用範囲、橙が展開期間、紫が完了通知を意味する。
2026年のスパムアップデート史
2026年はスパムアップデートが立て続けに実施されている。8月の更新は3回目だ。過去2回の傾向を把握しておくと、今回の展開期間や影響範囲を推測しやすくなる。
3月の更新は過去最速で完了
3月のスパムアップデートは19時間30分で完了した。これはSearch Status Dashboardの記録上、確認済みの展開としては最速だった。展開期間が短いほど、順位変動も短期間に集中しやすい。
6月の更新は生成AI検索の操作対策も対象に
6月のスパムアップデートは2日と1時間かけて完了した。その前月の5月15日には、GoogleのスパムポリシーがAI OverviewsやAI Modeなど、生成AI検索の結果を操作しようとする試みにも適用されるという方針が明確化されている。6月の更新がこの種の操作を具体的に狙ったものかどうかは、Googleから公式な説明はない。
8月の更新についても、生成AI検索の操作を特に標的にしているかどうかは明らかにされていない。ただし、スパムポリシーは検索結果全般に適用されるため、生成AI検索への操作も対象範囲に含まれると考えるのが自然だ。
このデモは2026年に実施された3回のスパムアップデートを比較したものだ。青が3月、緑が6月、橙が8月を表す。完了までの時間が回を追うごとに長くなる傾向が見える。
サイト運営者が取るべき行動
スパムアップデートの展開中は、検索順位が一時的に変動することがある。1日だけのデータで判断せず、Search Consoleのデータを数日分確認するのが基本だ。特に8月18日以降の動きに注目する必要がある。
Search Consoleで順位変動を確認する
順位の変動を確認するには、Search Consoleのパフォーマンスレポートが最も信頼できる。表示回数・クリック数・平均掲載順位を日別で確認し、8月18日以降に急激な変化が出ていないかを見る。
もし変動が見つかったら、それがスパムアップデートの影響なのか、他の要因によるものなのかを切り分ける必要がある。季節要因や自サイトの変更、競合サイトの動きなども同時に確認することだ。
このデモはSearch Consoleを使った確認手順を示している。青から紫への色分けは、各ステップの進行順を表す。
スパムポリシーの見直しが復旧の最短経路
順位が大きく下がった場合、Googleのスパムポリシーに違反していないかを見直す必要がある。主なポリシーには、クローキング、隠しテキスト、リンクスパム、キーワードの乱用、ユーザー生成スパムなどがある。自サイトが該当する可能性がないか、コンテンツとリンクの両面から確認する。
Googleの公式ドキュメントによると、スパムポリシー違反からの復旧には数ヶ月かかることがある。自動化されたシステムが、サイトがルールに従うようになったことを認識するまでに時間が必要なためだ。違反を修正しても、すぐに順位が戻るわけではないことを理解しておく必要がある。
このデモはGoogleのスパムポリシーで代表的な違反の種類を示している。赤い左線が注意を促す配色だ。
今後の展開と監視ポイント
Googleはアップデートの展開が完了すると、Search Status Dashboardに完了記録を掲載する。3月は19時間30分、6月は2日と1時間で完了しており、今回も同様に記録される見込みだ。
サイト運営者としては、完了通知が出るまでの間、Search Consoleのデータを注視するのが現実的な対応になる。特に8月18日以降の表示回数と平均掲載順位の推移を数日分まとめて確認し、変動の傾向を掴むことだ。
Search Engine JournalはGoogleが完了を確認次第、続報を伝えるとしている。今回のアップデートで新たなスパムポリシーが追加されたり、特定のスパム手法が集中的に取り締まられたりした場合は、その情報も出てくるだろう。
この記事のポイント
- 8月スパムアップデートは2026年8月18日に開始、全言語・全地域が対象
- 今年3回目のスパムアップデートで、新ポリシーの追加はなし
- 完了までに数日かかる見込みで、完了後にSearch Status Dashboardで通知される
- 順位変動があればSearch Consoleで8月18日以降のデータを確認する
- スパムポリシー違反からの復旧には数ヶ月かかることがある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceのバリエーション商品だけ検索にヒットしない時の原因と直し方
WooCommerceで複数のバリエーションを持つ商品のうち特定のバリエーションだけサイト内検索に表示されない場合、Algoliaなどの検索インデックスに「非公開扱い」「価格未設定」「在庫切れの非表示」などの条件が記録されたままになっている可能性が高い。まず商品編集画面で該当バリエーションの有効状態とカタログ表示の設定を確認し、再保存してインデックスを更新する。
なぜ特定のバリエーションだけ検索にヒットしないのか
WooCommerceはバリエーションを親商品とは別の商品データとして管理する。検索用のインデックスを作る仕組みでは、親商品に加えて各バリエーションが別レコードとして登録されることが基本になる。その際、各バリエーションの公開条件や商品データに不備があると、そのバリエーションだけインデックスから除外される。
たとえば一部のバリエーションは検索に出るのに特定の型番だけ出ないという症状は、インデックス全体の問題ではなく、該当バリエーションの扱いに原因が集中している場合が多い。親商品の更新では直らず、バリエーション単位の設定を見直す必要がある。
WooCommerceでバリエーションの公開設定を確認する手順
バリエーションが検索に引っかからない場合、まず商品編集画面から該当バリエーションを開き、公開状態とデータの入力を確認する。単純商品であれば「更新」ボタンを押すだけで直る症状でも、バリエーション商品は個別の設定がそのまま残ることがある。
このデモでは、検索に出ないバリエーションを確認する流れを示している。ここからは各ステップの詳細を見ていく。
「有効」チェックボックスがオフになっていないか
バリエーション編集画面の上部には「有効」のチェックボックスがある。ここがオフになっていると、そのバリエーションはカタログや検索から除外される。特定のバリエーションだけ検索に出ない場合、最初に確認したい項目だ。
チェックが外れている場合はチェックを入れて保存する。複数のバリエーションで同じ問題が起きているなら、一覧画面の絞り込み表示を活用し、無効化されたバリエーションだけを確認するのが早い。
価格と在庫が正しく入力されているか
バリエーションに価格が入力されていない場合、WooCommerceはそのバリエーションを非表示にする。また在庫切れでかつ「在庫切れ商品をカタログから隠す」設定が有効だと、検索インデックスからも外れる。価格と在庫はバリエーションごとに独立して管理されるため、親商品が正常でも特定のバリエーションだけ欠けていることがある。
親商品の「カタログ表示」設定が検索対象になっているか
親商品の編集画面には「カタログ表示」の設定がある。ここが「ショップと検索結果」または「検索結果のみ」になっていないと、その商品のバリエーション全体が検索に出なくなる。ただし一部のバリエーションはヒットするというケースでは、親商品の設定は原因になりにくい。それでも親商品が「非表示」になっていないか併せて確認しておく。
Algoliaにバリエーションが同期されない場合の対処
WooCommerceとAlgoliaを連携しているサイトでは、商品データの変更がAlgolia側に正しく同期されないと、特定のバリエーションだけ検索結果から漏れることがある。管理画面からインデックス設定と同期キューを確認する。
変動商品のインデックス設定を確認する
AlgoliaのWooCommerce連携プラグインには、バリエーションをインデックスに含めるかどうかの設定がある。ここが無効だと親商品だけが検索対象になり、バリエーションの型番検索が機能しない。設定を開き、バリエーションが検索可能になっているか確認する。
該当バリエーションを無効化して再度有効化する
検索に出ないバリエーションの「有効」チェックを一度外して保存し、その後に再びチェックを入れて保存する方法が有効なことがある。これによりWooCommerce側の更新イベントが発火し、Algoliaへの同期処理が再実行される。単純商品の「更新」で直るのと同じ理屈だが、バリエーションは親商品の更新だけではイベントが伝わらない場合がある。
インデックスキューをリセットして再構築する
Algolia連携プラグイン側でキューに滞留しているタスクがあると、一部の商品だけ同期されない。プラグインの設定画面からインデックスを再構築するか、キューをクリアしてから商品を再保存する。再構築には数分かかることがあるため、完了後に検索結果を確認する。
再保存しても直らない時に確認するデータ不整合
設定面で問題がないのにインデックスされない場合は、バリエーションデータそのものに不整合が起きている可能性がある。データベース上のpost_statusやSKUの重複を確認する。
重複するSKUや空の価格が原因になっていないか
SKUが別の商品と重複していると、検索プラグイン側でレコードの上書きや取り込みスキップが発生することがある。また親商品で価格を設定せずバリエーション側だけ価格を入れる運用では、空の値が検索条件から除外される場合もある。SKUの重複は管理画面の商品一覧からCSV書き出しなどで確認できる。
バリエーションの投稿状態が下書きになっていないか
WooCommerceのバリエーションは内部的に「product_variation」という投稿タイプで保存される。何らかの操作で投稿状態が下書きのままになっていると、検索インデックスに登録されない。通常は管理画面から確認できないため、WP CLIやデータベースの直接確認が必要になる。WP CLIが使える環境なら次のコマンドで該当バリエーションの状態を調べられる。
wp post list --post_type=product_variation --post_status=draft検索インデックスを更新したあとに確認する動作
設定とデータを修正したら、実際にサイトの検索窓から該当するバリエーションを検索して表示されるか確認する。検索結果に出るかだけでなく、リンク先のURLが正しく該当バリエーションに飛ぶかも見る。
フロントエンドで検索して該当バリエーションが出るか
型番やSKUを検索語にして、対象のバリエーションがヒットするか確かめる。キャッシュが残っていると更新前の結果が表示されることがあるため、ブラウザのシークレットウィンドウを使うか、サイト側のキャッシュを削除してから検索する。
検索結果のURLが正しいバリエーションに飛ぶか
バリエーション検索では、インデックスから返されるURLにバリエーション識別子が含まれていないと、親商品のページに飛んで該当するオプションが初期表示されない。検索結果をクリックして商品ページを開き、狙った型番が選択された状態で表示されるか確認する。URLに属性のクエリパラメータが付いているかを目視で確かめるのが確実だ。
よくある質問
バリエーション検索はWooCommerce標準機能でも使えるのか
WooCommerce標準の商品検索は親商品を対象にすることが多く、バリエーション単位の型番検索には対応が弱い。Algoliaなどの専用検索プラグインを入れることで、バリエーションごとのインデックスが可能になる。
Algoliaの再インデックスにかかる時間はどのくらいか
商品数が多いほど時間がかかる。数百件程度なら数分で完了するが、数千件を超える場合は10分以上かかることもある。完了後に何度か検索して結果が安定するのを確認する。
特定のバリエーションだけ在庫切れになるたびに検索から消えるのはなぜか
WooCommerceの設定で「在庫切れ商品をカタログから隠す」が有効になっていると、在庫がゼロになったバリエーションは検索インデックスから除外される。在庫切れでも検索に表示したい場合は、この設定を無効にするか、検索プラグイン側で在庫切れの扱いを調整する。
親商品を更新してもバリエーションが同期されないのはなぜか
Algolia連携プラグインによっては、親商品の更新イベントがバリエーションの個別更新まで伝わらないことがある。該当バリエーションを直接開いて保存するか、無効化と有効化の操作を行うことで同期が再開される。
バリエーションの一括修正はできるのか
商品一覧のCSV書き出しと取り込みを使うと、複数のバリエーションに対してSKUや価格、在庫を一括で修正できる。ただしインデックスへの同期までは自動で走らないことがあるため、取り込み後に再インデックスを実行する。
この記事のポイント
- 特定のバリエーションだけ検索に出ない原因は、公開状態や価格、在庫といったバリエーション単位の設定に集中している
- 商品編集画面で該当バリエーションを開き、「有効」チェックと価格、在庫を確認する
- 親商品の更新だけでなく、該当バリエーションを一度無効化して再度有効化すると同期が再開されることがある
- Algolia連携プラグインではインデックス設定と同期キュー、再構築の状態を確認する
- それでも直らない場合はSKU重複やpost_statusの不整合を調べる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressの__GA_INJ_START__マルウェア感染を完全駆除する手順
WordPress のテーマファイル functions.php に「__GA_INJ_START__」というコメント記述を見つけたら、Google Analytics を装ったマルウェア感染の可能性が高い。完全に駆除するには、functions.php を元に戻すだけでは不十分で、データベースに潜む隠し管理者アカウントの削除と侵入経路の遮断まで行う必要がある。
__GA_INJ_START__マルウェアとは何か
このマルウェアは、テーマの functions.php 内に不正なコードを注入する際、開始位置の目印としてコメント文「__GA_INJ_START__」を書き込む。Google Analytics の計測タグに似せた外見のため、コードをざっと見ただけでは正規のトラッキングコードと勘違いしやすい。
実際に注入されるコードは、Google Analytics とは無関係の永続的なバックドアとして働く。具体的には、不正な管理者アカウントを定期的に生成したり、攻撃者が自由にサイトへ再侵入するための隠し経路を維持する機能を持つ。コード自体が自己修復的に動くこともあり、単に該当部分を削除しても再び書き戻されるケースがある。
感染の典型的な流れは、まず正規の WordPress 管理者アカウントへ何らかの方法でログインし、管理画面内のファイル編集機能やコードスニペット系プラグインを経由して functions.php に到達する。その段階で不正な管理者アカウントを追加し、数日から数週間かけて隠しアカウントを増やした後、最終段階として __GA_INJ_START__ 付きのコードがテーマに注入される。
このデモは侵入から感染完了までの典型的な進行パターンを示している。攻撃者は一度管理者権限を得ると、すぐに目立つ改ざんを行うのではなく、まず隠しアカウントを作って持続的なアクセスを確保するのが特徴だ。
隠し管理者アカウントをどうやって見つけるか
このマルウェアに感染したサイトでは、データベース内に通常では一覧に表示されない形で不正な管理者アカウントが追加されている。管理画面のユーザー一覧に表示されない場合もあるため、phpMyAdmin などでデータベースを直接確認するのが確実だ。
まず wp_users テーブルを開き、ユーザー名に不審な接頭辞が付いていないかを確認する。具体的には sync_agent、cdn_worker、seo_service の後にランダムな英数字が続く形式のアカウントが典型的だ。テーブルプレフィックスが wp_ 以外の場合は、その文字列に読み替えて探す。
次に wp_usermeta テーブルで、該当ユーザー ID に administrator 権限を付与するエントリが存在するかを調べる。さらに wp_options テーブルには __ga_hidden_users、_theme_inject_status、__ga_r_cache という見慣れないキーが保存されていることがある。これらのキーはマルウェアが隠し管理者の一覧を管理するために使う。
サーバーに SSH でログインできる環境なら、ファイルシステム全体を横断検索するのが最も早い。以下のコマンドでマルウェア特有の文字列を探せる。
grep -RniE '__GA_INJ|__ga_hidden_users|__ga_r_cache|_theme_inject_status|sync_agent|cdn_worker|seo_service' .SSH が使えない場合は、FTP でファイルをダウンロードしてエディタの検索機能を使うか、運営中のレンタルサーバーが提供するファイルマネージャの検索機能を活用する。また、WordPress 管理画面から有効化されているプラグイン一覧を確認し、心当たりのないプラグインが増えていないかも必ず調べる。
マルウェアを完全に駆除するにはどうすればいいか
重要なのは、functions.php を置き換えるだけでは駆除できないという点だ。隠し管理者アカウントとバックドアをすべて取り除くまで、攻撃者は何度でも再侵入できる。以下に駆除の全体フローを示す。
このデモは駆除作業の全体像を示している。以下、各ステップの具体的な進め方を詳しく解説する。
バックアップを必ず先に取得する
駆除作業ではデータベースのレコード削除やファイルの書き換えを行うため、操作を誤るとサイトが壊れる恐れがある。作業前にデータベースとファイルの両方を丸ごとバックアップしておく。レンタルサーバーにバックアップ機能が付属している場合も、念のため別の場所にもコピーを保存する。
隠し管理者アカウントをデータベースから削除する
phpMyAdmin などで wp_users テーブルを開き、不審なユーザー名のレコードを特定する。sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式が典型だが、まったく別の名前で偽装している可能性もある。新規登録した覚えのない管理者権限ユーザーはすべて削除対象だ。
ユーザーを削除する際、wp_usermeta テーブルに残った関連エントリも忘れずに削除する。SQL を直接実行する場合は、該当ユーザー ID を指定して両テーブルからレコードを消す。操作前に必ずバックアップを取り、プレビュー画面で対象レコードを確認してから実行する。
functions.php の不正コードを除去する
テーマの functions.php をエディタで開き、__GA_INJ_START__ から始まるコメントと、それに続くコードブロックを特定する。__GA_INJ_END__ または類似の終了マーカーがある場合は、その範囲全体を削除する。マーカーが無い場合は、不審な関数定義や管理者アカウントを操作するコードを丁寧に確認しながら取り除く。
該当テーマが親テーマなら、修正がテーマ更新で失われないよう子テーマ化を検討する。また、他のテーマファイルや wp-content 直下の PHP ファイルにも同じマーカーが仕込まれている可能性があるため、前述の grep コマンドで全ファイルを横断検索してから作業するのが安全だ。
セッションとパスワードをリセットする
攻撃者が既存のセッションを保持していると、アカウントを消してもアクセスが続く。WordPress の管理画面からユーザー一覧を開き、すべての管理者ユーザーに対して「全てのセッションを破棄」を実行する。さらに全管理者のパスワードを新しいものへ変更する。可能ならメールアドレスも再確認し、見覚えのない転送設定が無いか調べる。
アクセスログから感染時期を特定するにはどうするか
__GA_INJ_START__ が functions.php に現れた日が感染開始日とは限らない。実際には、その数日前から数週間前にかけて攻撃者が隠し管理者アカウントを作り、段階的に足場を固めていたケースが多い。駆除後に再発を防ぐには、感染の起点となった脆弱性や認証情報を特定することが欠かせない。
まずデータベースの wp_users テーブルで、不正な管理者の登録日時を確認する。WordPress はユーザー作成日時を user_registered カラムに記録している。次にサーバーのアクセスログを同じ期間分さかのぼり、wp-login.php へのログイン試行や、admin-ajax.php、theme-editor.php などへの不審なアクセスが無いかを照合する。
攻撃者が最初に正規の管理者アカウントでログインしていた場合、ログには正常なログインとして記録されているため見落としやすい。ログイン元 IP アドレスの突発的な変化、深夜帯のログイン、短時間での連続したファイル編集操作などを手がかりにする。ログの保存期間が短いレンタルサーバーでは、可能な範囲でログ保管期間を延ばしておくと今後の調査に役立つ。
再感染を防ぐには何をすればいいか
駆除が完了しても、侵入経路が残っていれば同じ手口で再び感染する。再発防止には、まず WordPress 本体、テーマ、プラグインを最新版へ更新する。侵入経路として悪用された可能性のあるファイル編集系プラグインやコードスニペット系プラグインは、使用していないなら削除する。
管理者アカウントに対しては二段階認証を有効にし、パスワードは推測されにくい長いものへ変える。管理画面へのアクセスを IP アドレス制限で絞るのも効果的だ。さらに wp-config.php にファイル編集機能を無効化する定数 DISALLOW_FILE_EDIT を追加すると、管理画面からテーマやプラグインのコードを書き換えられる経路を塞げる。
定期的な点検も重要になる。ユーザー一覧に知らない管理者が増えていないか、wp_options に見覚えのないキーが無いか、functions.php などのテーマファイルに不審なコメントが追加されていないかを毎月確認する。可能ならセキュリティプラグインによる定期スキャンを導入し、変更検知の通知を受け取れるようにしておく。
functions.php に __GA_INJ_START__ が注入され、データベースには sync_agent や cdn_worker などの隠し管理者が存在する。攻撃者はいつでも再侵入できる状態。
不正コードが除去され、隠し管理者はデータベースから完全に削除済み。パスワードとセッションもリセットされ、更新も適用されている。
このデモは駆除前後の状態を対比したものだ。感染状態ではマルウェアの目印と隠し管理者が残っているが、駆除後は不正な要素がすべて取り除かれている。
よくある質問
__GA_INJ_START__はGoogle Analyticsの正規コードではないのか
正規の Google Analytics 計測コードにこのようなマーカーは存在しない。__GA_INJ_START__ は不正なコードの開始位置を示す目印で、マルウェアが後からコードを書き戻す際の識別子として使われる。テーマファイルにこの文字列を見つけたら感染を強く疑うべきだ。
隠し管理者アカウントはデータベースのどこを確認すれば見つかるか
wp_users テーブルと wp_usermeta テーブルの両方を確認する。ユーザー名が sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式なら要注意だ。さらに wp_options テーブルに __ga_hidden_users や _theme_inject_status などの見慣れないキーが無いかも調べる。
セキュリティプラグインを導入しているのに感染したのはなぜか
プラグインが検出できるシグネチャを持たない新種や変種だった、定義が古かった、正規の管理者としてログインしてから活動したため不正ログインと判定されなかった、などの理由が考えられる。プラグインに頼るだけでなく、定期的なユーザー一覧やファイルの目視確認も併用する。
感染後、サイトを公開したまま駆除作業はできるか
推奨されない。攻撃者がバックドアを持っている間、サイトを公開し続けると訪問者の情報が窃取されたり、別の攻撃の踏み台にされたりする恐れがある。可能ならメンテナンスモードに切り替え、バックアップを取ってから作業するのが安全だ。
駆除後にサイトが真っ白になった場合の対処方法は？
デバッグモードを有効にしてエラー内容を特定し、テーマやプラグインを一つずつ有効化して切り分ける。テーマの functions.php を編集した際に記述ミスがあると画面が真っ白になることが多い。感染前のバックアップがあれば、その時点から修復する方が確実な場合もある。
この記事のポイント
- __GA_INJ_START__はGoogle Analyticsを装ったマルウェアの目印
- 隠し管理者アカウントはデータベースを直接確認しないと見落とす
- functions.phpの置き換えだけでは再感染する
- アクセスログを数日〜数週間さかのぼって感染起点を探す
- 駆除後は全パスワード変更とセッションリセットが必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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最適化の豊富な経験