タグアーカイブ WooCommerce

WooCommerceアナリティクスでOops something went wrongエラーが出た時の直し方

WooCommerceアナリティクスでOops something went wrongエラーが出た時の直し方

WooCommerce を 10.6.1 にアップデートした直後、アナリティクス概要に「Oops something went wrong」と表示され、ブラウザコンソールに TypeError: t(…)(…).tz is not a function というエラーが記録される場合、JavaScript のタイムゾーンライブラリを巡るプラグイン競合か、キャッシュの不整合が原因だ。まず全プラグインの無効化と標準テーマへの一時的な切り替えで原因を特定し、競合するプラグインを見つけ出すことから始める。

なぜ WooCommerce アナリティクスで tz is not a function エラーが起きるのか

WooCommerce の管理画面アナリティクスは、内部的に Moment.js とそのタイムゾーン拡張を使い、日付や時間の演算をおこなっている。10.6.1 では JavaScript アセットの読み込み順や依存関係に変更が入ったため、別のプラグインやテーマが同じ Moment.js タイムゾーンライブラリを異なるバージョンで読み込んでいる場合に .tz メソッドが上書きされるか、存在しない状態になり、今回の TypeError が発生する。

また、ブラウザやサーバー側のキャッシュに古いスクリプトが残っていると、管理画面で本来動くはずの新しいコードと混ざり、同様のエラーが出ることもある。まずは「どの拡張機能やテーマが影響しているか」を切り分けるのが近道だ。

エラーの原因を特定する手順

エラーの原因を特定する手順
STEP 1 WooCommerce を残して 全プラグインを無効化する
↓
STEP 2 テーマを Storefront または Twenty Twenty-Five に一時的に切り替える
↓
STEP 3 ブラウザキャッシュ、サーバーキャッシュ、WP キャッシュをすべてクリアする
↓
STEP 4 アナリティクスを開いてエラーが消えたら、プラグインを1つずつ再有効化して原因を特定する

上図の手順で、問題の切り分けができる。WooCommerce 本体だけを有効にした状態でアナリティクスが正常に動けば、あとは再有効化の過程でエラーを再現させるプラグインを見つければよい。

全プラグインを無効化して競合を確認する

「プラグイン」→「インストール済みプラグイン」画面で、全てのプラグインにチェックを入れ、「一括操作」から「停止」を実行する。WooCommerce だけは残すか、最初はすべて停止し、その後 WooCommerce だけ有効化し直す。この状態で管理画面の「WooCommerce」→「アナリティクス」を開き、エラーが出ないか確認する。

テーマを Storefront など標準テーマに切り替える

有効化しているテーマの functions.php やフックが、管理画面の JavaScript 読み込みに干渉しているケースは意外に多い。「外観」→「テーマ」で Storefront や Twenty Twenty-Five など公式の軽量テーマに一時的に切り替え、同じくアナリティクス画面を確認する。

ブラウザキャッシュとサーバーキャッシュをすべて削除する

キャッシュ系プラグイン(W3 Total Cache、WP Rocket など)を使っている場合は管理画面からキャッシュを全削除する。さらにブラウザでシークレットウィンドウ(プライベートブラウジング)を開き、そちらで管理画面にログインしてテストすると、ローカルキャッシュの影響を排除できる。サーバー側で OPcache や Redis オブジェクトキャッシュを導入している場合は、それらのクリアもおこなう。

プラグインを1つずつ再有効化して原因を突き止める

無効化状態でエラーが消えたら、プラグインを1つ有効化するごとにアナリティクス画面を再読み込みし、エラーの再発をチェックする。再現したプラグインが競合元だ。よくあるのは、カスタムレポート系、日付や予約管理、多言語対応(WPML や Polylang)、ページビルダーの管理画面用スクリプトを追加するタイプのプラグインだ。

競合するプラグインを特定したあとの恒久対策

競合するプラグインを特定したあとの恒久対策

原因のプラグインが判明しても、サイト運営上どうしても外せない場合がある。そのときは、問題のスクリプトだけを管理画面のアナリティクスページでのみ読み込まないようにする手がある。

以下のコードを子テーマの functions.php に追加すると、特定のスクリプトをアナリティクス画面で解除できる。ここでは例として「moment-timezone」ハンドルを一旦解除し、WooCommerce が想定する正しいバージョンを再登録する方法を示す(実際のハンドル名は競合元により異なるため、ブラウザのデベロッパーツールで確認する)。

add_action( 'admin_enqueue_scripts', function( $hook ) {
    if ( false === strpos( $hook, 'woocommerce_page_wc-analytics' ) ) {
        return;
    }
    wp_dequeue_script( 'moment-timezone' );
    wp_deregister_script( 'moment-timezone' );
    wp_enqueue_script( 'moment-timezone', includes_url( 'js/moment-timezone.min.js' ), array( 'moment' ), null, true );
}, 100 );

この例では WordPress 本体バンドルの moment-timezone を読み直しているが、WooCommerce が読み込むパスとは異なる場合がある。より安全なのは、競合プラグイン側の更新を待つか、Asset CleanUp 系のプラグインで該当スクリプトを該当ページでのみブロックする方法だ。

それでも直らない場合の応急処置としての WooCommerce のロールバック

どうしてもすぐにエラーを止めたいときは、WooCommerce を問題のなかったバージョン(例:10.5.2)に戻す方法がある。無料プラグイン「WP Rollback」を使えば、管理画面からワンクリックで以前のバージョンにダウングレードできる。

「プラグイン」→「新規追加」で WP Rollback をインストールし有効化すると、プラグイン一覧の WooCommerce に「ロールバック」リンクが現れる。そこから 10.5.2 を選択し、ロールバックを実行する。ただし、これは一時しのぎであり、セキュリティ修正などが含まれている場合はリスクがあるため、問題の根本解決を優先する。

よくある質問

プラグインをすべて無効化してもエラーが消えないのはなぜか

テーマの functions.php や子テーマに管理画面用のスクリプトを追加している可能性が高い。必ず標準テーマ(Storefront や Twenty Twenty-Five)に切り替えて確認する。また、ブラウザ拡張機能やサーバー側のキャッシュが残っている場合もエラーが継続する。

キャッシュを削除しても改善しない場合はどうするか

ブラウザのシークレットウィンドウを使うか、別のブラウザでテストする。サーバー側で OPcache や Varnish、CDN のキャッシュが効いている場合は、そちらも合わせてクリアする。WP CLI が使えるなら wp cache flush も試す。

特定のプラグインが原因とわかったが、そのまま使い続けたい

プラグイン開発元に WooCommerce 10.6.1 への対応状況を問い合わせ、アップデートを待つのが最も確実だ。緊急時は、前述のコード例や Asset CleanUp で競合を回避する方法があるが、サイト全体の動作確認を十分におこなったうえで適用する。

WooCommerce をダウングレードしても問題ないか

ダウングレードすると、10.6.1 で修正されたセキュリティ上の問題や不具合が再発する可能性がある。あくまで原因究明と修正が終わるまでの一時的な措置と考え、早急に恒久対策を講じる。

同じエラーがフロントエンドのカートやチェックアウトでも出る

管理画面だけでなくフロントエンドでも同様の TypeError が発生する場合、テーマかキャッシュプラグインの JavaScript 最適化機能(結合・圧縮)が原因になっていることが多い。キャッシュプラグインの設定で JavaScript の結合を一時的に無効にし、テーマを標準テーマに切り替えて症状が消えるか確認する。

この記事のポイント

  • WooCommerce 10.6.1 でアナリティクスに tz is not a function エラーが出るのは JavaScript のタイムゾーンライブラリ競合かキャッシュ不整合
  • プラグイン全無効化+標準テーマへの切り替えで原因を特定し、1つずつ再有効化して競合プラグインを特定する
  • 競合プラグインが見つかったら、更新を待つか functions.php でスクリプトを制御する
  • 緊急時は WP Rollback で WooCommerce を一時的にダウングレードできるが、恒久対策が優先
WooCommerceで国別価格設定後にカートで価格が18%下がる原因

WooCommerceで国別価格設定後にカートで価格が18%下がる原因

国別価格プラグインとWooCommerceの標準税設定を併用していると、商品をカートに入れた瞬間に約18%引きの価格が表示される現象が起きる。これはインド向けの税率が米ドル建ての表示価格にまで漏れ出し、税抜き再計算が走ってしまうためだ。

なぜカートで価格が18%下がるのか

なぜカートで価格が18%下がるのか

カートに追加した直後に129ドルが約109ドルに減る理由は、WooCommerceの「税設定」と「価格表示」に潜む優先順位の構造にある。販売地域がインドで基本通貨を米ドルに設定し、かつ国別価格プラグインで国ごとに異なる価格を手動入力している店舗では、インド向けの18%税率が米ドル表示側に干渉しやすい。

WooCommerceの税設定には「税込で価格を入力する」か「税抜きで入力する」かの二択がある。税込(ベース価格に税が含まれている前提)を選ぶと、システムは表示価格を税込み総額とみなし、該当する税率に基づいて税抜き部分と税額に内部で分離する。ここに、本来その国には適用されるはずのないインドの18%スラブが食い込むと、129ドルを「税抜き価格+18%税相当」と計算し直し、税抜き価格約109ドルをカートに表示してしまう。

特にPrice Based on Country系のプラグインは、通貨ごとに手動価格を入力できても、WooCommerceの標準税テーブルと密接に連動しているわけではない。このため国検出ロジックと税ルールが別々に動き、非インド顧客の米ドル表示にもインド税率がかぶさる不整合が起こる。

税テーブルと国別価格の干渉を解消する手順

税テーブルと国別価格の干渉を解消する手順

不整合の根源である税テーブルを整理し、適用範囲を正しく限定すれば価格の引き下げは止まる。管理画面から次の流れで修正する。

STEP 1 WooCommerceの「設定」→「税」を開き、税率一覧を確認する
↓
STEP 2 インド向け税率の「国」欄が「IN」のみであることを確認し、誤って「全地域」などになっていれば修正する
↓
STEP 3 税設定の「税込で価格を入力する」を一旦「税抜きで価格を入力する」に切り替え、すべての通貨で正しい価格を再入力する

税率テーブルを開くと、インド向けの18%行の「国コード」欄が空白または複数国に誤設定されているケースがある。これをIN単独に直し、米国など他国に波及しないようにする。Price Based on Countryプラグイン側でも、米ドル表示の国リストに見落としがないか再確認する必要がある。

価格表示オプションの「税込」「税抜」を整理する

価格表示オプションの「税込」「税抜」を整理する

税込み入力モードは税テーブルと不可分に動くため、通貨ごとに手動価格を割り当てる運用との相性が悪い。税抜き入力に切り替えて価格を純粋な本体金額とし、税は決済時に国ごとのテーブルにしたがって自動加算する形が安定する。

ただし切替時に既存商品の価格は変わらないため、129ドルと入力していた商品は税抜き129ドルとみなされ、かえって値上がりする。そこで切り替え後は全商品の価格を意図した税抜き金額(たとえば税込み表示にしたいなら本体109ドル前後)に書き換える作業が必要になる。国別価格プラグインに一括更新機能があれば活用すると手間を減らせる。

Before 税込み入力モード
商品価格 129ドル → 自動で18%税抜き計算 → カートに109ドル表示
↓
After 税抜き入力モード
商品価格 109ドル(本体) → 税は決済時のみ加算 → カート表示は109ドルで安定
■ 税込み入力で誤動作  ■ 税抜き入力で安定

税込み入力モードのまま運用を続ける場合は、インドの税率をいったん無効化し、Price Based on Countryプラグイン側の価格に税込み金額を直接登録する方法もある。ただこの方法は今後の税率変更に弱く、国ごとの税計算をWooCommerceの標準機能に任せられなくなるため推奨しない。

よくある質問

米ドル建てに18%の税率が見当たらないのに価格が下がるのはなぜか

米ドル用の税率が存在しなくても、WooCommerceは税込み入力モード時に「顧客の所在地に連動した税率」を内部で適用しようとする。国検出がインドと判定された瞬間に18%スラブが動き、価格が再計算されるのが根本原因だ。

国別価格プラグインを一時停止すればすぐ直るか

プラグインを無効化すると国別の価格表示そのものが消え、全ユーザーに基本通貨の価格が表示されるため、18%引きは起こらなくなる。ただし根本解決ではなく、多通貨販売をあきらめることになる。

税率テーブルでIN以外の国をすべて削除しても問題ないか

税率を適用したい国が増えるたびに行を追加する運用になるが、現在問題が起きている状態よりは安全だ。税率テーブルには最低限必要な国コードだけを残し、ワイルドカード指定は避けることを勧める。

価格を税抜き入力に切り替えた後、カートで税が表示されずに困る場合の対処は

税抜き入力にしたら「表示価格」の設定を「税込み」に戻すと、フロントエンドでは本体価格に税が乗った金額が表示される。この設定は「WooCommerce → 設定 → 税」の「店舗での価格表示」で変更できる。

キャッシュが原因で設定変更がすぐ反映されないときはどうするか

WooCommerceの「ステータス → ツール」から顧客セッションと製品の価格キャッシュをクリアし、さらにサイトキャッシュやCDNキャッシュもあわせて削除する。プライベートウィンドウで確認すると切り分けが早い。

この記事のポイント

  • カートでの価格引き下げは税込み入力モードと国別税率の干渉で起こる
  • 税率テーブルの国コードを見直し、不要な適用範囲を削除する
  • 「税抜きで価格を入力する」モードに統一すれば価格は安定する
  • 設定変更後はキャッシュクリアと価格再設定を忘れずに行う
WooCommerce 11.0が商品オブジェクトキャッシュを標準化!新規ストアは自動有効

WooCommerce 11.0が商品オブジェクトキャッシュを標準化!新規ストアは自動有効

WooCommerce 11.0がリリースされ、商品オブジェクトキャッシュが新規ストア向けにデフォルトで有効化された。この機能は、商品ページやチェックアウト処理で同じ商品データを何度もデータベースから取得する無駄を省き、ECサイトの表示速度を底上げする。

可変商品がある製品ページでは約9〜12%、バンドル商品を含むチェックアウト処理では6〜12%の処理速度改善が報告されている。今回の変更は、WooCommerce 10.5で実験的導入が始まったキャッシュ機構が安定動作の段階に達したことを示している。

新規にWooCommerce 11.0以上をインストールしたストアには自動で適用されるが、アップグレードした既存ストアの設定は一切変更されない。必要に応じて管理画面から手動でオンにできる仕組みだ。

商品オブジェクトキャッシュの仕組みとパフォーマンス改善の数字

商品オブジェクトキャッシュの仕組みとパフォーマンス改善の数字

リクエスト内で商品データを使い回すメモリ内キャッシュ

このキャッシュは、一度のHTTPリクエストの間だけ生きている、揮発性のメモリ内キャッシュだ。wc_get_product(123)が呼ばれると、キャッシュに保存されていればデータベースに問い合わせず、すぐに商品オブジェクトの複製を返す。リクエストが終わればキャッシュは完全に消去されるため、次のリクエストで古い情報が残る心配はない。

特に、wc_get_product()を同じIDで何度もコールするパターンが多いテーマやプラグインで効果が大きい。各呼び出しが独立したオブジェクトのクローンを返すため、意図せず商品データの状態を共有してしまうバグも防げるようになった。

キャッシュなし(従来)
1回目 wc_get_product(123) → DBから取得(遅い)
2回目 wc_get_product(123) → DBから再取得(まだ遅い)
3回目 wc_get_product(123) → DBからまた取得
↓
キャッシュあり(WC 11.0)
1回目 wc_get_product(123) → DBから取得(初回のみ)
2回目 wc_get_product(123) → メモリ内キャッシュ(即返却)
3回目 wc_get_product(123) → メモリ内キャッシュ(高速)
※各呼び出しで返されるのは常に商品オブジェクトのクローン(複製)。呼び出し元どうしで状態が共有されることはない。

このデモは、同じ商品IDに対する繰り返し呼び出しがキャッシュによってどれだけ無駄を省けるかを示している。実際のECサイトでは、商品ループやセール情報の取得、決済フローの中で wc_get_product() が頻繁に呼ばれるため、体感速度の改善が期待できる。

実測値として9〜12%の高速化

WooCommerce 10.5の実験的導入時に公表されたパフォーマンス測定値は、今回の正式適用後も同じだ。可変商品(サイズや色のバリエーションがある商品)の製品ページでは、読み込み時間が9〜12%短縮された。バンドル商品を含むチェックアウト処理では6〜12%高速化されている。

この改善幅は、商品データを繰り返し取得する重いクエリがページ表示のボトルネックになっている状況で顕著だ。小規模なサイトでは効果が体感しにくいケースもあるが、商品数が多いストアや複雑な製品構成のサイトでは、目に見える速度向上が得られる。

WooCommerce 10.5から11.0への段階的な導入プロセス

WooCommerce 10.5から11.0への段階的な導入プロセス

10.5で実験的機能として登場、10.6で互換性の宣言が「互換」に

商品オブジェクトキャッシュは、WooCommerce 10.5で「実験的機能」として初めて公開された。当時はデフォルトで無効であり、ストア運営者が手動でオンにする必要があった。機能自体は、wc_get_product()の呼び出しをインターセプトし、リクエスト単位のメモリ内キャッシュからデータを返す仕組みだ。

WooCommerce 10.6では、この機能のプラグイン互換性宣言が「非互換」から「互換」に変更された。実験期間中に拡張機能エコシステム全体で互換性の問題が一切報告されなかったため、明示的に互換性を宣言していない拡張機能も、デフォルトで互換とみなされるようになった。

もし拡張機能が明示的に「この機能とは非互換」と宣言している場合は、WooCommerceの機能画面に従来通り非互換の通知が表示される。しかし、そのような宣言が必要になった拡張機能は見つかっていない。

11.0で新規ストアへの自動有効化を実装

WooCommerce 11.0のクリーンインストール時には、インストールプロセスの一環として商品オブジェクトキャッシュが自動で有効になる。機能登録自体は enabled_by_default => false のまま変更されていないが、新規インストール時に明示的に有効化が書き込まれる仕組みをとっている。

これは、HPOS(High-Performance Order Storage)など、他の機能がオプトインから新規インストール時デフォルトへ移行した際と同じパターンだ。バージョンアップだけでは既存ストアの設定を変更しない、慎重な設計が貫かれている。

既存ストアの挙動と手動有効化の手順

既存ストアの挙動と手動有効化の手順

アップグレードしても設定は一切変わらない

WooCommerce 11.0より前に構築されたストアは、11.0へアップグレードしても既存のキャッシュ設定がそのまま維持される。もし以前に無効だった(それが11.0以前のストアのデフォルト設定だ)なら、アップグレード後も無効のままだ。すでに手動で有効にしていたストアは、そのまま有効が継続される。

つまり、次の3パターンに整理できる。

  • WooCommerce 11.0以降を新規インストール → 自動的に有効(操作不要)
  • 既存ストアで機能が無効だった → アップグレード後も無効のまま(手動で有効にできる)
  • 既存ストアで機能が有効だった → アップグレード後も有効のまま(操作不要)

手動で有効化する方法

既存ストアでこの機能を試したい場合、管理画面の WooCommerce → 設定 → 詳細設定 → 機能 にアクセスし、「商品オブジェクトをキャッシュする(Cache Product Objects)」のトグルをオンにすればよい。ただし、設定変更後にサイト全体の動作を一通りチェックしておくことが推奨される。

手動有効化の流れ
STEP 1 WooCommerce → 設定 へ移動
↓
STEP 2 詳細設定 → 機能タブを開く
↓
STEP 3 「Cache Product Objects」をオンにする
↓
STEP 4 変更を保存して動作確認

トグルをオンにすると、その瞬間からリクエスト単位の商品キャッシュが働き始める。とくに、複数の拡張機能が同じ商品データにアクセスする大規模ストアでは、即効性のある改善が期待できるだろう。

拡張機能開発者への影響と注意点

拡張機能開発者への影響と注意点

標準APIを使っていればコード変更は不要

wc_get_product() やその他 WooCommerce 標準 API を通じて商品を取得している拡張機能は、このキャッシュの影響をまったく受けない。キャッシュは内部で透過的に動作し、呼び出し元には変わらず正しい商品オブジェクトが返る。

キャッシュから返されるのは、あくまで独立したクローンなので、取得した商品オブジェクトを編集しても他の処理に副作用が及ぶことはない。したがって、従来のコーディング規約に従っている拡張機能は、そのまま動作し続ける。

直接SQLを実行する拡張機能が注意すべきポイント

注意が必要なのは、WooCommerceのメタフックを経由せずに、商品データに対して直接SQLクエリを発行している拡張機能だ。これらのクエリはキャッシュの無効化フックを迂回するため、更新後のデータがキャッシュに反映されず、古い情報が返ってしまう可能性がある。

この問題は、商品オブジェクトキャッシュに限った話ではなく、WooCommerceのデータ整合性全般に関わる設計課題だ。該当する拡張機能を開発している場合は、標準の wc_get_product() やメタデータ更新用のAPIを使うことで、キャッシュの恩恵を受けつつ、データ不整合も回避できる。

今後のロードマップと全ストアへの有効化計画

今後のロードマップと全ストアへの有効化計画

データ蓄積後に全ストアで有効化へ

今回のリリースは通過点であり、最終的にはすべてのストア(既存ストアも含む)で商品オブジェクトキャッシュを有効化する計画が示されている。現時点で具体的な実施時期は明言されていないが、十分なストアでの稼働データが蓄積された段階で判断される。

すでに実験期間で問題が報告されていないこと、新規インストールのデフォルト有効化でさらなる実績が積み上がることを踏まえると、早ければ数バージョン後には全ユーザー対象の強制有効化に踏み切る可能性が高い。

問題が発生した場合の報告先

もし商品オブジェクトキャッシュに関連して予期せぬ挙動が見つかった場合、WooCommerceのGitHubリポジトリでIssueを報告してほしいと開発チームは呼びかけている。拡張機能開発者やストア運営者からのフィードバックが、今後の安定化に直結する。

この記事のポイント

  • WooCommerce 11.0 で商品オブジェクトキャッシュが新規ストア向けに自動有効化された
  • 可変商品の製品ページ読み込みは 9〜12% 高速化、バンドル商品のチェックアウトは 6〜12% 改善
  • 既存ストアはアップグレードしても設定変更なし、管理画面から手動でオンにできる
  • 標準の WooCommerce API を使う拡張機能はコード変更不要で動作する
  • 最終的には全ストアで有効化される予定で、Issue 報告を募っている
WooCommerceにEU契約撤回ボタンを無料で追加する方法

WooCommerceにEU契約撤回ボタンを無料で追加する方法

2026年6月19日からEU消費者へ販売するオンラインショップには、契約を撤回する「離脱ボタン」をストアフロントに設置する義務が発生する。WooCommerceには標準でこの機能がないため、無料の専用プラグインを見極めて導入すれば、技術的な難しい変更なしに対応できる。

なぜ2026年6月からEU向けWooCommerceに契約撤回ボタンが必要なのか

なぜ2026年6月からEU向けWooCommerceに契約撤回ボタンが必要なのか

EU指令2023/2673(従来の消費者権利指令に第11a条を追加)が、2026年6月19日以降にEU在住の消費者を対象に販売するすべての事業者に対して、契約を撤回するための「明確に表示されたワンクリック機能」の提供を義務付けている。これは商品の返品とは別に、契約そのものから離脱する手段を消費者に与えるものだ。

日本からEUへ越境ECを行う事業者も、現地の消費者をターゲットにしている限り例外ではない。WooCommerce単体ではこの離脱機能に対応しておらず、公式要望トラッカー上で議論は続いているものの、すぐに実装される見込みはない。そのためプラグインによる早期の対応が欠かせない状況になっている。

WooCommerce向け離脱ボタンプラグインで絶対に押さえるべき機能

WooCommerce向け離脱ボタンプラグインで絶対に押さえるべき機能

多数の無料プラグインが出回っているが、法令を満たすために最低限チェックするポイントは変わらない。見落としを防ぐために、以下の基準を事前にリストアップしておくことが大切だ。

ワンクリックで契約撤回が完了する仕組み

消費者がボタンを押すだけで、追加のフォーム入力や本人確認なしに撤回の意思表示が完了しなければならない。撤回の受付通知が自動的にメールで送られる仕組みも必須になる。

わかりやすく目立つボタン表示

「契約を撤回する」といったボタン文言が、注文確認画面やマイアカウントページなど、消費者が容易に見つけられる位置に常に表示される必要がある。テーマのスタイルに埋もれず、かつ法的に十分な表示であることが求められる。

GDPRおよび個人データ取り扱いへの配慮

離脱ボタンの動作に伴って取得される個人データ(注文ID、メールアドレスなど)の取り扱いがGDPRに準拠しているかも確認する。プラグインが不要なデータを保存していないか、またデータ保持期間の設定ができるかが重要な判断材料になる。

多言語対応と日本向けの翻訳品質

EU圏内で複数言語のサイトを運営する場合、ボタン文言や通知メールを各国語に切り替えられる多言語対応が必須になる。日本語で運用しているサイトでも、管理画面表示が適切に翻訳されているか、表示されるフロント文言が自然かを確かめておきたい。

更新の継続性とエコシステムとの相性

WordPress本体やWooCommerceのアップデートに追従しているか、アクティブインストール数や最終更新日を確認する。法典の変更に応じて仕様が変わる可能性もあるため、活発にメンテナンスされているプラグインを選ぶことで将来のリスクを抑えられる。

無料のEU契約撤回プラグインを安全に選んで導入する流れ

無料のEU契約撤回プラグインを安全に選んで導入する流れ

実際にプラグインを選ぶ際には、機能のチェックリストをクリアするだけでなく、自分のサイト環境で競合なく動作するかのテストがとても重要だ。以下の手順で進めれば、手戻りなく導入できる。

STEP 1 公式リポジトリで「withdrawal button」などのキーワードで複数の無料プラグインをリストアップする
↓
STEP 2 前述の必須機能を満たしているか、説明文とスクリーンショットで下調べする
↓
STEP 3 テスト環境またはステージングサイトでプラグインをインストールし、有効化する
↓
STEP 4 ボタンの表示位置や文言、撤回後の自動メール通知を確認し、必要に応じて外観やフックを調整する

上図は一般的な導入手順を示したイメージで、実際のプラグインによって設定画面の構成は異なる。

プラグイン導入後に必ずチェックする項目と表示カスタマイズのコツ

プラグイン導入後に必ずチェックする項目と表示カスタマイズのコツ

プラグインを有効化しただけでは、テーマの都合でボタンが正しく表示されなかったり、通知メールが迷惑メールに振り分けられたりするケースがある。以下のポイントを必ず実機で確認しておく。

Before(対応前)
注文確認ページに契約撤回の手段が一切表示されない
↓
After(プラグイン導入後)
「契約を撤回する」ボタンが目立つ位置に常時表示され、ワンクリックで撤回完了と通知が飛ぶ
■ 対応前 ■ 対応後

マイアカウントページと注文詳細画面の両方にボタンが現れるか

購入後の消費者がアクセスするマイアカウント内の注文一覧や個別注文画面、そしてゲスト購入者向けの注文確認ページの両方でボタンが機能するかを必ず検証する。プラグインによってはゲスト購入に対応していないこともあるため注意が必要だ。

撤回後のフローがEC事業者側にも通知されるか

消費者が撤回ボタンを押したあと、店舗運営者にメールや管理画面内の通知が届く仕組みになっているかも重要だ。対応が遅れるとトラブルに発展するため、通知が確実に飛ぶ設定になっているかを最初のテストでつかんでおく。

表示をCSSで微調整したい場合の注意

ボタンの色やサイズをテーマに合わせたいときは、追加CSSに直接スタイルを書いて調整するのが現実的な方法だ。ただし、プラグインが出力するHTMLのクラス名やIDはアップデートで変わることがあるため、子テーマのstyle.cssに依存しすぎないようにし、変更後は必ず再テストを行う。

よくある質問

WooCommerce用のEU離脱ボタンプラグインは本当に無料で使えますか

現在、WordPress公式リポジトリで複数の無料プラグインが公開されている。いずれも基本機能は無料で提供されており、有料版で追加機能が解放される場合もあるが、法令要件を満たすだけなら無料で十分対応できる。

ボタンの設置だけでEUの法律要件はすべて満たせますか

離脱ボタンは指令が求める機能の一部だ。合わせて返品ポリシーの明示や、撤回後の返金手続きを整備する必要がある。プラグインはあくまで技術的な「ボタンの提供」部分を解決するものだと理解しておくことが大事だ。

多言語サイトでボタン文言を日本語にしたい場合の対処法は

多くのプラグインは翻訳ファイルを内包しているか、管理画面でボタン文言を自由にカスタマイズできる。日本語の翻訳が不完全な場合はLoco Translateなどの別の翻訳プラグインを併用して、表示テキストだけを書き換えることも可能だ。

プラグインがWooCommerceの今後のアップデートで動かなくなる心配は

定期的に更新されているプラグインを選ぶことでリスクは下げられる。導入前に最終更新日とアクティブインストール数、サポートフォーラムの反応を確認し、万が一に備えてステージング環境を用意しておくのが堅実な運用だ。

この記事のポイント

  • 2026年6月19日からEU向け販売店に契約撤回ボタンの設置が義務化された
  • WooCommerce標準には機能がなく、無料プラグインでの対応が現実的な解決策
  • プラグイン選びではワンクリック完了、明確な表示、GDPR配慮、多言語対応をチェック
  • 導入後は表示場所とゲスト購入時の動作を必ずテストし、通知設定も確認する
  • 定期更新が続いているプラグインを選び、ステージング環境で動作検証を行う
WooCommerce MyParcelで重大エラーが出た時のデフォルト配送業者設定方法

WooCommerce MyParcelで重大エラーが出た時のデフォルト配送業者設定方法

WooCommerce の MyParcel プラグイン使用時に表示される「このサイトで重大なエラーが発生しました」というエラーは、プラグイン内にデフォルトの配送業者が設定されていないことが原因だ。プラグイン設定画面からデフォルトの配送業者を選択すれば、エラーはすぐに解消する。

なぜデフォルト配送業者が未設定だとエラーになるのか

なぜデフォルト配送業者が未設定だとエラーになるのか

このエラーは PHP の致命的エラー(Fatal Error)であり、MyParcel プラグインが「No default carrier available(利用可能なデフォルトの配送業者がない)」という例外を発生させて停止している。スタックトレースを追うと、発端は受注確認ページ(サンキューページ)などで追跡情報を表示しようとする際、プラグインが内部的に呼び出す getDefaultCarrierOrThrow() メソッドで落ちている。

MyParcel は配送ラベル作成や追跡情報の連携を行うプラグインであり、動作には「どの配送業者をデフォルトで使うか」という情報が必須だ。この設定を一度も行っていなかったり、アップデート時に何らかの理由で消えたりすると、サイトの該当ページでエラーが表示される。

≪ エラー発生時 ≫
MyParcel プラグインがデフォルトの配送業者を取得できず、例外をスロー
↓
≪ 設定後 ≫
デフォルト配送業者が設定され、プラグインが正常に動作
■ 設定未完了状態 ■ 設定完了後

デフォルト配送業者を設定する具体的な手順

デフォルト配送業者を設定する具体的な手順
STEP 1 WordPress 管理画面にログインし、左メニューから「WooCommerce」→「MyParcel」を開く
↓
STEP 2 「設定」タブを選択し、「デフォルトの配送業者」項目を探す
↓
STEP 3 プルダウンから利用する配送業者(例: ヤマト運輸や佐川急便など契約中のもの)を選択する
↓
STEP 4 画面下部の「変更を保存」をクリックし、エラーが消えたか確認する

管理画面にアクセスできる状態であれば、この手順だけでエラーは即座に解消する。設定項目の名称はプラグインバージョンによって「デフォルトの配送業者」「Default Carrier」などと表記が異なるが、いずれも一つのプルダウン形式で表示される。

管理画面にすらアクセスできない場合の対処

エラーがサイト全体に影響し、管理画面も真っ白になってしまうケースがある。その場合は FTP またはサーバーのファイルマネージャーを使い、一時的に MyParcel プラグインのフォルダをリネームして無効化する。

  • サーバーに接続し、/wp-content/plugins/ ディレクトリへ移動する
  • woocommerce-myparcel フォルダを woocommerce-myparcel_deactivated などに変更する
  • これでプラグインが停止し、管理画面へアクセスできるようになる
  • 管理画面に入れたら、上の STEP 手順で設定を行い、フォルダ名を元に戻して有効化する

設定を保存してもエラーが再発する場合

設定保存後に再び同じエラーが発生するなら、プラグインまたは関連データベース設定に不整合が起きている可能性が高い。以下の順で追加対応を試す。

  • 一度プラグインを完全に削除し、最新バージョンを再インストールする
  • WooCommerce のシステムステータス画面で、不要なトランジェント(期限付きキャッシュ)をクリアする
  • MyParcel アカウントとの API 接続情報(API キーなど)を再入力する

エラーを未然に防ぐための注意点

エラーを未然に防ぐための注意点

プラグインのメジャーアップデート後や WordPress 本体の自動更新後に、こうした設定がリセットされる事例は珍しくない。MyParcel に限らず、配送系・決済系プラグインは「接続先のデフォルト設定」が必須となるものが多い。アップデート後はテスト環境や低トラフィック時間帯に決済フローとサンキューページの動作を一通り確認する習慣をつけると安心だ。

よくある質問

エラーメッセージが英語で「No default carrier available」と表示されているが日本語環境でも同じ?

日本語環境の WordPress でも管理画面やログに表示されるエラーメッセージは英語のままになる。ただしサイト訪問者には「このサイトで重大なエラーが発生しました」という日本語の汎用エラー画面が表示されるため、管理者はサーバーのエラーログやデバッグモードで英語エラーを確認することになる。

MyParcel 以外の配送プラグインでも同様のエラーは起こる?

配送ラベル生成や追跡機能を持つプラグインは、内部で配送業者を特定する仕組みに依存していることが多く、設定不足で同種のエラーが起きる可能性がある。具体的には「デフォルトの配送業者」「デフォルトの配送方法」が未選択であると、ページ表示時に致命的エラーになる構造は共通している。

Divi テーマを使っていることがエラーと関係ある?

スタックトレースに Divi のパスが含まれているのは、サンキューページを Divi の WooCommerce モジュールで構築しているためだ。エラーの根本原因はあくまで MyParcel プラグイン側の設定不足であり、Divi そのものに問題があるわけではない。

デフォルトの配送業者を設定しても配送ラベルが発行できない

デフォルト配送業者の設定はエラー解消の第一歩だが、実際にラベルを発行するには MyParcel アカウントとの正しい API 接続と、WooCommerce の配送クラスや商品重量の設定が必要になる。エラーが消えた後は、MyParcel の管理画面で接続ステータスが「アクティブ」になっているか確認する。

この記事のポイント

  • PHP の致命的エラーは MyParcel のデフォルト配送業者未設定が原因
  • 管理画面の MyParcel 設定からデフォルト配送業者を選択して保存すれば解決
  • 管理画面に入れない場合はプラグインフォルダのリネームで一時無効化する
  • アップデート後は配送系プラグインの設定リセットに注意が必要
Action Scheduler 4.0.0の変更点、WooCommerceのテーブル肥大化を抑制

Action Scheduler 4.0.0の変更点、WooCommerceのテーブル肥大化を抑制

WooCommerceの裏側で動くAction Schedulerは、多くのデータベースの中でも特に負荷の高いテーブルを持つ。高トラフィックのストアでは、完了した処理を削除する仕組みが追いつかず、失敗したアクションは一切消えないまま蓄積し続けることが問題になっていた。4.0.0はその根本に手を入れたメジャーアップデートだ。失敗アクションの保持期間をデフォルトで3か月に制限し、クリーンアップを専用のデイリージョブとして分離した。これにより、アクションとログのテーブルサイズが際限なく肥大化する状態を防げる。

本バージョンは7月28日リリース予定のWooCommerce 11.0にバンドルされ、すでにWordPress.orgで単独でも入手可能だ。互換性を壊す変更が複数含まれているため、拡張機能を開発している人や大規模ストアを運用している人は、4.0.0での動作検証を早めに始める必要がある。

4.0.0が狙う根本的なテーブル肥大化の抑制

4.0.0が狙う根本的なテーブル肥大化の抑制

Action SchedulerはWordPress管理画面での注文処理やメール送信など、WooCommerceの非同期ジョブを支えるコアライブラリだ。これまでは小さなバグフィックスが中心で、3.9.x台を刻んでいた。しかし今回、互換性を壊す複数の変更をまとめて投入するため、バージョン番号が4.0.0にジャンプした。WordPress形式のバージョン付けでは3.9.3の次は3.10ではなく4.0だから、意図的な動きといえる。

従来のクリーンアップ(Before)
アクションテーブル 完了・キャンセルのみ削除
失敗アクション 無期限で保持
クリーンアップ キュー処理のついでに小分け
↓
4.0.0のクリーンアップ(After)
失敗アクション 3か月後に自動削除
専用ジョブ 毎日3時に一括処理
バッチサイズ 最低250件、最大まで連続

このデモが示すように、クリーンアップの仕組みが根本から見直された。特に失敗アクションが自動削除の対象になった点と、削除処理が専用ジョブとして分離された点が、テーブル肥大化を抑える大きな柱だ。

互換性の壁を越えるメジャーバージョンアップ

4.0.0ではWordPress 6.8以上の動作要件が課せられ、WordPress 7.0との互換性も明示された。これは今後のWooCommerceエコシステムにとって、基盤環境を一段上げる布石でもある。また、後述するユニークアクションの判定変更は、同じフックでも引数が異なれば別物として生成されるようになり、既存コードの重複防止ロジックに影響を与える可能性がある。

失敗アクションの保持期間を3か月に制限

失敗アクションの保持期間を3か月に制限

これまでAction Schedulerは、完了とキャンセルのアクションだけを削除していた。失敗ステータスのアクションは、自らフィルターで追加しない限り永久に残り続けた。多忙なストアではこれが原因でアクションテーブルとログテーブルが無制限に成長し、自力で回復できない状況に陥っていた。4.0.0では、失敗アクションが発生から3か月を超えると自動的に削除される専用のクリーンアップパスがデフォルトで有効化された。

保持期間の変更(変更前)
失敗したアクションは永久保持
テーブルが成長し続け、手動削除が必要
↓
保持期間の変更(4.0.0)
失敗後3か月で自動削除
四半期決算サイクルと整合し、調査猶予も確保
カスタマイズ例
保持期間を6か月に延長したり、削除そのものを無効化することも可能。

3か月という期間は、典型的な四半期会計サイクルに合わせつつ、障害調査のための十分な猶予を残す設計だ。より厳格なデータ保持ポリシーを持つストアでは、action_scheduler_retention_period_for_failedフィルターで秒単位の期間を変更できる。あるいはaction_scheduler_enable_failed_action_cleanupに__return_falseを渡せば、4.0.0以前と同じく無期限保持に戻せる。

注目すべき点は、既にaction_scheduler_default_cleaner_statusesフィルターで失敗ステータスを追加していた場合、そちらの設定が優先されることだ。その場合は、4.0.0の新しい失敗専用パスではなく、既存のクリーンアップサイクルに統合されるため、動作が変わることはない。

クリーンアップを専用のデイリージョブに分離

クリーンアップを専用のデイリージョブに分離

旧バージョンでは、古いアクションの削除はキューの各バッチ処理にインラインで埋め込まれ、一度に少量しか処理されなかった。そのため、処理量の多いストアではクリーンアップが追いつかず、テーブルが大きくなる一方だった。4.0.0では、クリーンアップを独立したタスクとし、サイト時刻で毎日午前3時に一度だけ実行する方式に変更された。

クリーンアップ実行の流れ
STEP 1 毎日午前3時に専用ジョブが起動
↓
STEP 2 一度に最低250件の削除を実行
↓
STEP 3 バックログがなくなるまで再スケジュール

この方式により、削除処理が通常のキュー処理のパフォーマンスに影響を与えなくなり、大規模テーブルでも遅延なく追いつけるようになった。バッチサイズはaction_scheduler_cleanup_batch_sizeフィルターで変更可能で、デフォルトの250件より少なくも多くもできる。もし従来のインライン方式に戻したい場合は、カスタムキュークリーナーを実装すれば自動的にそちらが使われるが、ほとんどのサイトではその必要はないだろう。

ユニークアクションの判定に引数が加わった

ユニークアクションの判定に引数が加わった

as_enqueue_async_action()やスケジュール系関数の$uniqueパラメータは、同じアクションが重複して生成されるのを防ぐためのものだ。従来はフック名とグループだけを比較していたため、引数が異なる2つのアクションでも同一とみなされ、後のほうが黙って破棄される挙動だった。これが4.0.0では、引数の内容まで含めて同一性を判定するように変更された。

従来の重複チェック(Before)
フック名 + グループ のみ比較
引数が違うアクションも重複とみなされる
↓
4.0.0の重複チェック(After)
フック名 + グループ + 引数 を比較
引数が異なれば別のアクションとして生成

この変更は互換性を壊すため、特に注意が必要だ。旧来のフックとグループだけの重複防止に依存していたコードでは、これまでよりも多くのアクションが生成されるようになる。意図しない大量のジョブがキューに積まれないよう、$uniqueを使っている箇所は必ず見直してほしい。

WooCommerceサイトへの実務的な影響と移行のポイント

WooCommerceサイトへの実務的な影響と移行のポイント

4.0.0はWooCommerce 11.0のバンドルに先立って単独テストが可能だ。大規模ストアや独自の拡張機能でAction Schedulerを利用している開発者は、以下の3点を中心にステージング環境で動作検証を行うことを推奨する。

  • 失敗アクションの保持ポリシー
    3か月のデフォルトが自社のデータ保持要件に合致するか確認し、必要ならフィルターで調整する。
  • ユニークアクションの重複防止ロジック
    $unique=trueを使用している全箇所を洗い出し、引数が異なるアクションが正しく生成されるかテストする。
  • クリーンアップの実行タイミング
    デイリージョブへの移行により、削除がバッチ処理から外れたことで、期待していたリアルタイム性が失われていないか確認する。必要に応じてカスタムクリーナーを実装する。

開発元のWooCommerceチームはGitHubでフィードバックを募集しており、予期しない動作があれば早期に報告するよう呼びかけている。WooCommerce 11.0の正式リリースまで1か月あまり。致命的なトラブルを回避するために、今のうちに4.0.0との互換性テストを済ませておくことが賢明だ。

この記事のポイント

  • Action Scheduler 4.0.0はテーブル肥大化を防ぐため、クリーンアップの仕組みを根本から見直したメジャーアップデート
  • 失敗アクションがデフォルトで3か月後に自動削除されるようになり、保持期間のカスタマイズも可能
  • クリーンアップが専用のデイリージョブとして実行され、キュー処理のパフォーマンスに影響しなくなった
  • ユニークアクションの重複チェックに引数が含まれるようになり、既存の重複防止ロジックへの影響に注意が必要
  • WooCommerce 11.0へのバンドル前に単体テストを行い、互換性の問題を早期に発見することが重要

特定商品ブロックを設置した固定ページでfatal errorが発生する問題の直し方

特定商品ブロックを固定ページに配置したときに「Uncaught Error Call to a member function get_id() on null」というfatal errorが表示されるのは、PreCart for WooCommerce のバグが原因だ。プラグインを最新バージョンへ更新するか、functions.php へ一時的な修正コードを追加すれば直る。

なぜ固定ページ上の商品ブロックで fatal error が起こるのか

なぜ固定ページ上の商品ブロックで fatal error が起こるのか

PreCart は WooCommerce の商品情報を扱うフィルターフック(woocommerce_product_add_to_cart_text など)にコールバック関数を登録し、その中で global $product から商品オブジェクトを取得して $product->get_id() を呼び出している。しかし、ブロックエディタで「特定商品」ブロックを通常の固定ページに配置すると、WooCommerce のブロック表示パイプラインではグローバル変数 $product が null のままフィルターが走るケースがある。PreCart のコードには null チェックがないため、null に対して get_id() を呼び出してしまい、致命的なエラーでページ全体が落ちる。

STEP 1 固定ページに「特定商品」ブロックを追加し任意の商品を選択
↓
STEP 2 WooCommerce ブロック描画時に PreCart のフィルターが発火
↓
STEP 3 グローバル変数 $product が null のままコールバックが実行される
↓
STEP 4 $product->get_id() で致命的エラー発生(画面が真っ白になる)

影響を受けるメソッドは change_add_to_cart_text()、display_pre_order_messgae()、display_pre_order_badge() など、いずれも保護コードがない。WooCommerce の商品ブロックを店舗ページ以外で使っているサイトはすべてこの問題に遭遇し得る。

PreCart を更新してエラーを解消する手順

PreCart を更新してエラーを解消する手順

開発元はこの問題を認識しており、すでに修正アップデートがリリースされている。まずは管理画面からプラグインを最新版に上げるのが最も安全で確実な対処法だ。

STEP 1 WordPress 管理画面へログインし「プラグイン」→「インストール済みプラグイン」を開く
↓
STEP 2 PreCart for WooCommerce に更新通知が出ていたら「今すぐ更新」をクリック
↓
STEP 3 サイトのキャッシュ(プラグインキャッシュ、サーバーキャッシュ)をすべて削除
↓
STEP 4 問題のあった固定ページをフロントエンドで再度開き、エラーが出ないことを確認

更新通知が表示されない場合

「ダッシュボード」→「更新」から更新の再確認を行うか、PreCart のプラグインページで一度「プラグインを削除」→ 公式リポジトリから再インストールする方法もある。ただしこの場合、設定がリセットされる可能性があるため、事前に PreCart の設定をメモしておくかエクスポート機能があれば使っておくと安心だ。

functions.php で null チェックを追加して一時的に対処する方法

functions.php で null チェックを追加して一時的に対処する方法

どうしてもすぐにプラグインを更新できない場合や、何らかの理由で更新後に問題が残る場合は、テーマの functions.php にフックを追加して一時的にエラーを回避できる。

/**
 * PreCart の null チェック不足による fatal error を回避(一時的対応)
 */
add_filter( 'woocommerce_product_add_to_cart_text', function( $text, $product ) {
    if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
        return $text;
    }
    // 以下は原本の処理が走るが、早期リターンで保護
    return $text;
}, 1, 2 );

add_filter( 'woocommerce_single_product_summary', function() {
    global $product;
    if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
        return;
    }
    // 同様に早期リターン
}, 1 );

上記のコードは PreCart が使っているのと同じフックに、より優先度の高いコールバック(優先度 1)で null チェックを追加し、商品オブジェクトが存在しないときは処理を打ち切る仕組みだ。PreCart のフィルターよりも先に実行されるため、致命的エラーに至る前に関数を抜けられる。

Before(危険)
global $product;
$product->get_id();
null チェックがないためエラー
↓
After(安全)
if ( ! $product || ! is_a( $product, ‘WC_Product’ ) ) { return; }
$product->get_id();
null のときは早期リターン
■ 修正前 ■ 修正後

functions.php 編集時の注意点

子テーマを使っていない場合、テーマ更新で修正が上書きされるリスクがある。必ず子テーマの functions.php にコードを追加するか、Code Snippets プラグインでコードを管理するのが望ましい。また、この一時対応はあくまで応急処置であり、PreCart の他の機能が正常に動作しない可能性もゼロではない。早めに公式アップデートを適用して、追加コードは削除する。

手動修正後に確認しておきたいポイント

手動修正後に確認しておきたいポイント
  • 一時的なコードを追加した後、サイトの表示速度やエラーログに変化がないか定期的にチェックする
  • PreCart の機能(カート追加テキストの変更や予約注文バッジなど)が期待どおり動作しているかテストする
  • PHP のエラーログを確認し、別の箇所で同様の null 参照エラーが隠れていないか調べる
  • サイト全体のキャッシュをクリアし、CDN を利用している場合は CDN キャッシュも破棄する
  • PreCart の更新が確認できたら必ずプラグインを最新版に上げ、追加コードを削除する

よくある質問

PreCart 以外のプラグインでも同じように商品ブロックでエラーが出ることはありますか

ある。WooCommerce のブロックを通常ページで使うと、$product グローバルを正しく取り扱っていない他の拡張プラグインでも同様の null 参照エラーが起きるケースが報告されている。エラーの文面に別のプラグイン名が含まれている場合は、そちらの開発元へ報告しつつ、同じように functions.php で早期リターンを追加すれば応急回避できることが多い。

WooCommerce の商品ブロックを固定ページで使うこと自体は問題ないのでしょうか

WooCommerce のブロックは基本的に店舗ページや商品ページで使うことを想定しているが、WordPress の標準ブロックとして技術的にはどの投稿タイプでも利用できる。プラグインがグローバル変数の有無を適切にハンドリングしていれば固定ページで使っても問題は起きない。ただ、テーマやプラグインが認めるまで、動作確認は入念に行ったほうがよい。

エラーメッセージが表示されずに画面が真っ白になる場合はどうすればよいですか

WordPress が致命的エラーを表示しない設定(WP_DEBUG が false)のときは、管理画面のメールに送られる復旧モード用のリンクを探すか、サーバーの PHP エラーログを確認する。wp-config.php で define('WP_DEBUG', true); を一時的に有効にすれば、画面上にエラー詳細が表示され、原因を特定しやすくなる。なお、本番環境ではデバッグモードをすぐに無効に戻すこと。

管理画面にも入れなくなってしまった場合はどうすれば直りますか

FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/precart/ ディレクトリの名前を一時的に変更(例:precart_deactivated)すれば、プラグインが無効化されて管理画面に再ログインできる。その後、前述の更新や一時コードで対処し、ディレクトリ名を元に戻す。

この記事のポイント

  • 固定ページに WooCommerce 商品ブロックを配置したときの fatal error は PreCart の null チェック不足が原因
  • 解決策は PreCart プラグインの最新版への更新が最も安全で確実
  • すぐに更新できない場合は、functions.php にフックで早期リターンを追加すれば応急回避できる
  • functions.php 編集は子テーマで行い、アップデート後は必ず追加コードを削除する
  • 管理画面に入れなくなったら FTP でプラグインフォルダ名を変更し無効化する
Googleのノンコモディティ方針、ECサイトが取るべきコンテンツ戦略

Googleのノンコモディティ方針、ECサイトが取るべきコンテンツ戦略

Googleが2026年5月、AI検索時代を見据えた新しい可視性ガイドラインを公開した。その中核にあるのが「ノンコモディティ・コンテンツ(Non-Commodity Content)」という概念だ。誰にでも書ける凡庸な情報ではなく、書き手自身の経験や独自の視点がにじむコンテンツを評価するという方針である。

Practical Ecommerceの記事によると、この考え方自体は目新しいものではない。Googleは長年にわたりEEAT(経験・専門性・権威性・信頼性)を重視してきた。しかしAIによるゼロクリック検索が急速に台頭する中で、改めて「人間にしか書けないコンテンツ」の重要性が言語化された形だ。

この記事では、Googleの「ノンコモディティ」方針の具体的な内容を整理する。あわせて、ECサイトを運営する事業者やWooCommerceユーザーがこの変化をどう受け止め、どんなコンテンツ戦略を取るべきかを実務目線で解説する。

Googleが定義する「コモディティコンテンツ」とは何か

Googleが定義する「コモディティコンテンツ」とは何か

GoogleのAI可視性ガイドラインは、検索上位を目指すコンテンツを2つに大別している。「コモディティコンテンツ」と「ノンコモディティコンテンツ」だ。まず前者の定義から確認しよう。

誰が書いても同じになる情報

コモディティコンテンツとは、いわゆる「一般的な知識」に基づいて書かれた情報のことだ。具体例としてGoogleが挙げているのが「初めて住宅を購入する人への7つのヒント」といった記事である。この手の内容は、どの書き手が担当しても似たような仕上がりになる。

実務的にいえば、競合他社の記事を参考に構成し、公開データだけを元にまとめた商品比較記事や、製品スペックを並べただけの紹介ページが該当する。生成AIを使えば数分で量産できるタイプのコンテンツだ。

検索におけるコモディティコンテンツの限界

Google検索のインハウスリエゾンであるダニー・サリバン氏は、2026年4月のSearch Central Live Torontoでこのテーマを取り上げている。同氏が示した業界別の対比表を見ると、コモディティコンテンツの問題点がより明確になる。

  • ランニングシューズ販売店の場合「ランニングシューズ購入時に考慮すべき10のポイント」
  • インテリアデザイナーの場合「2024年に見逃せないキッチントレンド」

これらは情報として誤りではない。しかし、検索エンジンから見れば「どのサイトを上位表示してもユーザー体験に大差がない」と判断されるリスクをはらむ。AIによる回答生成が進むほど、この傾向は強まるだろう。

ノンコモディティコンテンツが評価される理由

ノンコモディティコンテンツが評価される理由

一方のノンコモディティコンテンツは、書き手固有の経験や専門知識に裏打ちされた情報を指す。生成AIが簡単に要約したり、出典なしで再利用したりしにくい性質を持つ。

Googleが示した具体例

先のダニー・サリバン氏による業界別の対比表では、ノンコモディティに該当する例として以下が挙げられている。

  • ランニングシューズ販売店「なぜこの顧客のシューズは400マイルで壊れたのか、摩耗パターンの分析」
  • インテリアデザイナー「大理石 vs ブドウジュース、5人家族に石材を勧めなかった理由」

どちらも実際の顧客対応や施工現場で起きた具体的なエピソードだ。競合が簡単に真似できる内容ではなく、読み手に「この店で買いたい」「このデザイナーに依頼したい」と思わせる力がある。

EEATとの関係性

ノンコモディティという用語は新しいが、背景にある考え方はGoogleが長年重視してきたEEATと重なる。EEATとは「Experience(経験)」「Expertise(専門性)」「Authoritativeness(権威性)」「Trustworthiness(信頼性)」の頭文字を取った評価基準だ。

Practical Ecommerceの記事では、Googleが以前から人間の評価者に対してEEATに基づくサイト評価を指示しており、ランキングアルゴリズムにもヘルプフルコンテンツシステムの一部としてEEATに似た要素が組み込まれている可能性が高いと指摘している。要するに、新しい概念が登場したというより、AI時代に合わせて既存の評価軸を再定義したと見るのが自然だ。

コモディティコンテンツ(Before)
「ランニングシューズ購入時に考慮すべき10のポイント」
どのサイトにも載っている一般的なアドバイスを列挙した記事。生成AIで容易に複製できる。
検索評価: 差別化要因が乏しく、上位表示が難しい
↓
ノンコモディティコンテンツ(After)
「なぜこの顧客のシューズは400マイルで壊れたのか、摩耗パターンの分析」
実際の顧客事例と店舗独自の分析データに基づく記事。生成AIでは再現できない具体性がある。
検索評価: 独自性が評価され、上位表示の可能性が高まる
※Practical Ecommerce掲載のGoogle公式事例を基に再構成

上図の対比からわかるように、ノンコモディティコンテンツは「そのサイトでなければ読めない情報」を提供する。この一点がAI時代の検索評価において決定的な差となる。

ECサイトが取り組むべきコンテンツ戦略

ECサイトが取り組むべきコンテンツ戦略

では、WooCommerceをはじめとするECサイト運営者は、この方針転換にどう対応すればよいのか。具体的な打ち手を3つの軸で整理する。

独自データに基づく分析記事

顧客の購買データや問い合わせ履歴を分析し、傾向を記事化する手法はノンコモディティコンテンツの典型例だ。「昨年と比べて20代女性の購入単価が15%上昇した理由」「雨の日に売れる商品トップ5とその背景」といった内容である。

WooCommerceのレポート機能やGoogleアナリティクスのデータを活用すれば、小規模店舗でも十分に独自性のある分析が可能だ。数字と具体的な事例をセットにすることで、読み手の信頼を得やすくなる。

実際の使用例や顧客ストーリー

商品紹介ページに顧客の使用シーンを詳細に盛り込むことも効果的だ。「30代男性がキャンプで3日間使用した感想」「子育て中の女性が選んだ理由と1カ月後の変化」といった具体的なエピソードは、スペック表では伝わらない価値を読者に届ける。

重要なのは、単なるレビュー評価の転載ではなく、店舗スタッフが直接ヒアリングした内容や観察した気づきを文章化することだ。この一手間が、生成AIでは代替できない独自性を生む。

専門家としての見解や実験結果

自社で取り扱う商材について、スタッフが実際に検証した結果を公開する方法もある。「3種類の防水スプレーを実際に試して効果を比較した」「同価格帯の Bluetooth イヤホン5製品を音質測定器でテストした」といった記事だ。

これらは手間とコストがかかるが、検索エンジンからの評価だけでなく、ブランドの信頼構築やリピーター獲得にも直結する。YouTube動画と組み合わせれば、さらに効果は高まるだろう。

コモディティコンテンツが無価値というわけではない

コモディティコンテンツが無価値というわけではない

ここまでノンコモディティの重要性を強調してきたが、誤解してはいけない点がある。商品リリース情報や価格改定のお知らせ、採用情報といった「コモディティ的」なコンテンツにも確かな価値は存在する。

読者が求めるなら迷わず発信する

Practical Ecommerceの記事はこの点を明確に指摘している。読者が知りたい情報であれば、それがコモディティコンテンツであっても積極的に発信すべきだ。自社ブランドのファンは新製品の発表を待っているし、既存顧客はメンテナンス情報を必要としている。

直接流入の強化は、結局のところ最も確実なSEO対策である。コモディティかノンコモディティかという区分に過度に縛られるより、まずは目の前の顧客が何を求めているかに集中する姿勢が大切だ。

バランスの取れたコンテンツ設計を

理想的なのは、両方のタイプをバランスよく配置することだ。商品ページはコモディティ的な基本情報をしっかり押さえつつ、ブログ記事ではノンコモディティ的な独自コンテンツで差別化する。この二層構造が、AI検索時代のECサイトに求められるコンテンツ戦略の基本線となる。

WooCommerceサイト運営者が今すぐ始めるべき3つの施策

WooCommerceサイト運営者が今すぐ始めるべき3つの施策

ここまでの内容を踏まえ、WooCommerceでECサイトを運営する事業者が今日から取り組める具体的なアクションを3つに絞って提案する。

1. 商品説明文に実体験を注入する

メーカー提供のスペック情報をそのまま転載している商品説明ページがあるなら、すぐに手を入れるべきだ。スタッフが実際に商品を使った感想や、想定外の使い方の発見、競合品との微妙な違いなどを追記するだけで、コンテンツの独自性は格段に高まる。

2. 社内ブログに顧客事例カテゴリを新設する

WooCommerceサイトにブログ機能を追加するのは難しくない。そこに「お客様事例」というカテゴリを作り、月1本のペースで実際の顧客ストーリーを掲載していく。許可を得た上で、購入のきっかけや使用後の変化を具体的に聞き取って記事化する。

3. アクセス解析から問いの種を探す

Googleサーチコンソールで自社サイトに流入している検索クエリを確認し、まだ十分に回答できていない質問を特定する。「〇〇 比較」「〇〇 口コミ」「〇〇 使い方」といったクエリに対して、自社の実体験やデータに基づいた回答記事を用意すれば、それがそのままノンコモディティコンテンツになる。

この記事のポイント

  • GoogleはAI検索時代に対応するため「ノンコモディティコンテンツ」の重要性を正式に打ち出した
  • ノンコモディティとは、書き手固有の経験や専門知識に裏打ちされた、生成AIでは簡単に再現できない情報を指す
  • ECサイトでは顧客データ分析、使用事例の詳細な紹介、自社検証記事の公開が有効な差別化策となる
  • 読者が求める情報であれば、コモディティ的なコンテンツにも価値はある、バランスが肝心
Amazonプライムデーが変えた夏季EC商戦、中小事業者が取るべき戦略

Amazonプライムデーが変えた夏季EC商戦、中小事業者が取るべき戦略

Amazonプライムデーは11年を経て、夏のeコマース商戦を完全に塗り替えた。2025年の米国EC売上高はプライムデー期間中だけで241億ドルに達し、前年比30.3%増を記録している。今やブラックフライデーに次ぐ第二の商戦期として、大手企業だけでなく中小EC事業者にも波及する新しい季節が誕生した。

かつて夏はECにとって「閑散期」だった。しかし今では消費者が値引きを待ち構え、競合が一斉にセールを重ねる構図が定着している。本記事ではこの変化をデータとともに整理し、中小規模のネットショップが取るべき具体的な戦略を掘り下げる。

Amazonプライムデーの変遷

Amazonプライムデーの変遷

初年度から4日間開催への拡大

プライムデーは2015年、Amazonが会員向けに24時間限定の特別セールとしてスタートした。当初は夏の販売不振を補う実験的な位置づけだったが、マーケティングと大幅な割引により消費者が「夏の買い時」を学習するきっかけを作った。

その後、期間は段階的に延長され、昨年は4日間の大型イベントへと成長した。開催期間の長期化は売上拡大に直結しており、Adobe Analyticsのデータによると、プライムデー中の米国業界全体のオンライン支出は年々増加し、2025年には過去最高を更新した。

2025年の売上高と市場への影響

2025年のプライムデー期間中、米国全体のEC売上は約241億ドル。Amazon自身の売上高は非公開だが、複数の推計では約130億ドルとされ、全体の半分強を占めた。これは単なるAmazonの成功事例ではなく、EC市場全体の底上げを意味する。

重要なのは、この期間に合わせて消費者が購買を先延ばしする行動が定着した点だ。夏のセールを待つという消費者心理が強まり、プライムデーをピークとした数週間が「第二のブラックフライデー」の様相を呈している。

従来の夏季商戦(Before)
6〜8月は大型セールがなく、消費者の購買意欲も低調。EC事業者は広告費を抑え、淡々と商品を流す時期だった。
※プライムデー導入前
↓
プライムデー導入後の夏(After)
6月後半から7月にかけて、Amazonを皮切りに大手ECが連続セールを実施。消費者の購買意欲が高まり、中小ECにも波及。夏が新たな商戦期に変わった。
※プライムデー経済圏の拡大

このように、プライムデーは夏季のECカレンダーを根本から変えた。11年の歴史を経て、ブラックフライデーに次ぐ第二の商戦シーズンが確立されているのである。

競合他社が追従する新たなセールシーズン

競合他社が追従する新たなセールシーズン

ウォルマートやターゲットが重ねる独自セール

プライムデーの影響力を示す最も明確な証拠は、競合各社の反応だ。Amazonが2026年のプライムデー日程を発表すると、わずか1週間後にはウォルマートが「Walmart Deals」を6月22日〜28日に設定し、ターゲットも「Circle Deal Days」を23日〜26日に開催すると公表した。いずれもプライムデーに軒並み日程を重ねている。

ベストバイや倉庫型クラブ、アパレルチェーン、ホームセンター、D2Cブランドに至るまで、似たようなプロモーションが同時多発的に展開される。この現象は単なる模倣ではない。消費者がAIや検索エンジン、マーケットプレイス、SNSで商品を横断比較する時代に、購買意欲がピークに達するタイミングに合わせなければ機会損失が生じるという現実への適応なのだ。

STEP 1 Amazonがプライムデー日程を発表(6月22〜25日)
Amazon 会員限定ディスカウント
↓
STEP 2 Walmartが重なるセールを発表(6月22〜28日)
Walmart 「Walmart Deals」を実施
↓
STEP 3 Targetも追随し、6月23〜26日に独自セール
Target 会員向け先行アクセス
↓
その他多数の小売業者も同様のプロモーションを展開
Best Buy、倉庫型クラブ、アパレルチェーン、ホームセンター、D2Cブランドなど

結果として、プライムデー単体のイベントを超えた「夏の新商戦シーズン」が形成されつつある。アクセス集中と高い購買意欲が広範囲に波及し、EC事業者全体がこの波に備えなければならない状況だ。

製造業や広告業界にも波及する影響

影響は小売業者だけにとどまらない。メーカーはこの時期に合わせて新製品の投入を計画し、販売店はベンダーとのプロモーション資金の交渉を前倒しする。マーケティング担当者は6〜7月の広告予算を確保し、値引きをしないブランドでさえコンテンツカレンダーやメール配信のタイミングを調整している。

ブラックフライデーには秋を通じた準備が必要だが、プライムデーも同様に数か月前からの在庫計画、人員配置、マーチャンダイジングの見直しを迫る。もはや無視できない恒常的な「商戦カレンダー」の一部なのである。

中小規模EC事業者が取るべき戦略

中小規模EC事業者が取るべき戦略

価格競争を回避する3つのアプローチ

プライムデーの主役は間違いなくAmazonであり、ウォルマートやターゲットなどの大手も恩恵を受ける。しかし中小ECにもチャンスはある。消費者はこの期間、積極的に買い物をしようというモードに入っているため、代替品や専門性の高い商品を探す動きが活発になるのだ。

重要なのはAmazonや大手と真っ向から値下げ合戦をしないこと。代わりに以下の3つの戦術が有効だ。

  • 独自カテゴリの訴求。大手が扱いにくい専門商品やニッチなジャンルで存在感を出す
  • 商品バンドル。複数の関連商品をセット販売し、単純な価格比較をかわしながら平均注文単価を上げる
  • プライベートブランドや独占アイテムの活用。他店との直接比較を不可能にし、価格主導の競争から脱却する

いずれも「価格」ではなく「価値」で勝負する発想である。プライムデーの波に乗りつつ、自社の強みを際立たせる戦略が求められる。

大手EC企業の戦略
  • 低価格と大量広告で集客
  • セール期間の重複で市場を占有
  • 会員プログラムを活用
  • 在庫・物流の大規模な事前準備
中小ECの戦略(推奨)
  • 独自カテゴリで差別化
  • 商品バンドルで単価向上
  • プライベートブランドで価格比較を回避
  • メール・SMS・コンテンツマーケティングを活用

中小事業者は、大手と同じ土俵で価格勝負をする必要はない。購入意欲の高い消費者に対して自社ブランドや独自商品を提示することで、持続的な顧客獲得を目指すべきだ。

マーケティングとコンテンツで存在感を高める

プライムデー前後は、消費者の情報収集行動が活発化する絶好のタイミングだ。メールマーケティング、SMS、リスティング広告、SNS広告はいずれも高い反応率が見込める。特に、あらかじめセグメントを組んだ既存顧客へのアプローチが費用対効果に優れる。

また、コンテンツマーケティングでは「購入ガイド」「比較記事」「おすすめ特集」といった形式が効果を発揮する。目的はAmazonの顧客を奪うことではなく、買い物モードに入った消費者に自社ブランドを認知してもらい、将来的な購入につなげることだ。1回のセールで終わらせず、長期的な関係構築を見据えた施策が求められる。

この記事のポイント

  • Amazonプライムデーは夏季のEC商戦を一変させ、今やブラックフライデーに次ぐ大規模セールシーズンに成長した
  • 競合他社が相次いでセールを重ねることで、業界全体に波及効果が生まれ、製造業や広告出稿計画にも影響が及んでいる
  • 中小EC事業者は、独自カテゴリ・バンドル・プライベートブランドで価格競争を回避しつつ、マーケティング施策で購買意欲の高い消費者を捉える戦略が有効
WooCommerce処理中注文を未払いのまま請求書プラグインに連携する方法

WooCommerce処理中注文を未払いのまま請求書プラグインに連携する方法

WooCommerceで銀行振込(BACS)や後払い決済を使う場合、注文を「処理中」にした途端に、外部の請求書発行プラグインがその注文を「支払い済み」と認識してしまうことがある。この原因は、WooCommerceが処理中ステータスに遷移する際に支払い日(_date_paid)を自動で記録し、多くのプラグインがそのメタデータを支払い完了の合図として読み取るからだ。ここではこの仕組みを詳しく解説し、後払い注文を未払いのまま連携させる確実な修正方法を紹介する。

なぜ処理中になった注文が「支払い済み」扱いになるのか

なぜ処理中になった注文が「支払い済み」扱いになるのか

WooCommerceの内部動作として、注文が「処理中(processing)」または「完了(completed)」に切り替わると、maybe_set_date_paid()というメソッドが呼ばれ、現在の日時を_postmetaテーブルの_date_paidに保存する。この動作は、クレジットカード決済など即時払いが完了した瞬間を記録するためにある。ところが銀行振込(BACS)は標準で「保留中(on-hold)」になるが、運用上「処理中」に手動変更したり、コードで処理中に固定すると、実際には入金前でも支払い日が書き込まれてしまう。

請求書発行プラグイン(WooCommerce PDF Invoicesや会計連携プラグインなど)は、通常この_date_paidをもとに「支払い済み」かどうかを判断する。さらに、WC_Orderクラスのis_paid()メソッドは内部的に「処理中」「完了」といったステータスを見てtrueを返す設計のため、_date_paidが空でも「支払い済み」と扱われるケースも多い。結果として、入金前の後払い注文が会計ソフト上で「支払い済み請求書」として取り込まれてしまうのだ。

修正前
注文ステータス:処理中 → WooCommerceが_date_paidを自動記録 → 請求書プラグインが「支払い済み」と判定
↓
修正後
注文ステータス:処理中 → _date_paidは記録されない(未払いのまま) → 請求書プラグインは「未払い」として連携

上図のように、_date_paidの書き込みを止めるか、支払い済み判定のロジック自体を書き換えることで、請求書が正しく「未払い」で連携されるようになる。次に、具体的にどう対処すればよいかを方法別に紹介する。

支払い済み判定のメカニズムを特定する

支払い済み判定のメカニズムを特定する

修正に入る前に、自分が使っている請求書発行プラグインがどのタイミングで「支払い済み」と判断しているかを知っておくと無駄な試行錯誤が減る。大きく分けると以下の3パターンがあり、フィルターの効き方が変わる。

  • _date_paidのメタデータを直接 get_post_meta() や$order->get_meta(‘_date_paid’) で読み取っている
  • WC_Order::get_date_paid() メソッドを呼び出している(フィルターフック posible)
  • WC_Order::is_paid() メソッドで判定している(ステータスベース)

多くのプラグインは最後のis_paid()や、直接メタデータを読む形をとる。get_date_paid()フィルターだけでは直らなかった場合、is_paid()の返り値を書き換えるか、そもそも_date_paid自体を保存させないアプローチが有効だ。

強制的に未払いにする3つの方法

強制的に未払いにする3つの方法

方法1. _date_paidが記録されるのを根本から防ぐ

WooCommerceが処理中ステータスに変わったときに_date_paidをセットするのは、maybe_set_date_paid()の中で「このステータスは支払い完了とみなす」という配列に「processing」が含まれているからだ。この配列はwoocommerce_payment_complete_order_statusフィルターで変更できる。以下のコードをテーマのfunctions.phpまたはCode Snippetsプラグインで追加すれば、BACS(bank transfer)決済の注文でのみ「processing」を支払い完了ステータスから外せる。

add_filter('woocommerce_payment_complete_order_status', function($statuses, $order) {
    if ($order instanceof WC_Order && 'bacs' === $order->get_payment_method()) {
        $statuses = array_filter($statuses, function($s) {
            return $s !== 'processing';
        });
    }
    return $statuses;
}, 10, 2);

これにより、BACSの注文が「処理中」に移行しても、WooCommerceは「これは支払い完了ステータスではない」と認識し、_date_paidを一切書き込まない。注文メモなどに残る変わったログも出ず、動作は非常にクリーンだ。結果として、請求書プラグインが_date_paidを見ている限り、未払いのままとなる。

方法2. is_paid()の返り値を上書きする

もし日付メタデータを消してもなお請求書が「支払い済み」になってしまう場合は、プラグインがWC_Order::is_paid()メソッドを使っている可能性が高い。このメソッドは内部的にwc_get_is_paid_statuses()が返すステータス配列(デフォルトでは’processing’と’completed’)と照合し、trueを返す。こちらもフィルターでBACSだけ処理中を除外できる。

add_filter('woocommerce_order_is_paid_statuses', function($statuses, $order) {
    if ($order instanceof WC_Order && 'bacs' === $order->get_payment_method()) {
        $statuses = array_diff($statuses, array('processing'));
    }
    return $statuses;
}, 10, 2);

このコードを追加すると、is_paid()は見かけ上「処理中」でもfalseを返すため、請求書プラグインは「未払い」と判断する。方法1と併用すれば、_date_paidの直接読み取りもis_paid()経由の判定も両方ブロックできる。

方法3. プラグイン側のエクスポートフィルターを利用する

どうしても上記のフィルターで直らない、あるいは他プラグインとの兼ね合いで処理中ステータスを支払い完了扱いのままにしたい場合は、請求書発行プラグインが用意しているデータ書き換え用のフックを使う。たとえば、WooCommerce PDF Invoices & Packing Slips であれば wpo_wcpdf_document_data や wpo_wcpdf_invoice_data といったフィルターがある。請求書に含める「支払い済み」フラグや日付を、注文の支払い方法がBACSのときだけ空にすることで解決できる。

プラグインのフィルター一覧は開発元のドキュメントで確認する必要があるが、一般に「Paid = 1」や「paid_date」といったキーを書き換えることが多い。次のサンプルは、WooCommerce PDF Invoicesで支払い状況を未払いに戻す例だ。

add_filter('wpo_wcpdf_invoice_data', function($data, $document) {
    if ($document->order instanceof WC_Order && 'bacs' === $document->order->get_payment_method()) {
        $data['paid'] = 0;
        $data['date_paid'] = '';
    }
    return $data;
}, 10, 2);

なお、プラグインが読み取るフィールド名は製品によって異なるため、実際のソースコードや開発元への問い合わせで正確なキー名を調べるのが確実だ。

カスタム注文ステータスで処理中と区別する方法

カスタム注文ステータスで処理中と区別する方法

根本的に「後払い専用の処理中ステータス」をWooCommerceに追加するという手もある。標準の処理中ステータスは、支払い完了後の発送準備として使われる場面が多い。これに対し、後払いは「入金確認前だが、すでに注文を受け付け、請求書を発行したい」という微妙な状態だ。そこで「後払い処理中」のようなカスタムステータスを作れば、WooCommerceの支払いロジックに干渉せず、かつ請求書プラグインも処理中ではないため誤って支払い済み扱いしなくなる。

function register_custom_order_status_invoice_processing() {
    register_post_status('wc-invoice-processing', array(
        'label'                     => '後払い処理中',
        'public'                    => true,
        'show_in_admin_status_list' => true,
        'show_in_admin_all_list'    => true,
        'exclude_from_search'       => false,
        'label_count'               => _n_noop('後払い処理中 (%s)', '後払い処理中 (%s)')
    ));
}
add_action('init', 'register_custom_order_status_invoice_processing');

add_filter('wc_order_statuses', function($order_statuses) {
    $order_statuses['wc-invoice-processing'] = '後払い処理中';
    return $order_statuses;
});

このステータスをBACSの注文に割り当てれば、標準の処理中ルートを通らずに済む。ただし、配送プラグインや在庫連動がこのカスタムステータスを「処理中」同様に扱うよう追加のフックが必要になるケースもある。その場合は、woocommerce_order_is_paid_statusesフィルターなどで「wc-invoice-processing」も支払い完了とみなしたい処理にだけ含めると調整できる。

よくある質問

この修正を適用すると、クレジットカードの処理中注文まで未払いになりませんか

紹介したコードはいずれも if 文で’ bacs ‘決済に限定しているため、クレジットカードや他の即時決済には影響しない。条件を厳密に書けば、安全に導入できる。

後払い注文のステータスをカスタムステータスにしたら、WooCommerceの標準メールは飛びますか

新規ステータスを追加しただけでは自動的にメールは送信されない。woocommerce_order_status_invoice-processing のようなアクションフックを利用して、独自のメールテンプレートをトリガーするか、処理中と同じメールを送るように設定する必要がある。

どの方法を選ぶべきかの判断基準は

まずは方法1と方法2を組み合わせて適用してみるのが最も手軽で汎用性が高い。それで解決しない場合はプラグイン固有のフィルターを探す。長期的に後払いワークフローを整理したいならカスタムステータスがおすすめだ。

この記事のポイント

  • 処理中へのステータス変更で_date_paidが自動保存される仕様が原因
  • woocommerce_payment_complete_order_statusフィルターで_date_paid書き込みをBACSだけ無効化できる
  • is_paid()の返り値を上書きすれば、日付以外の「支払い済み」判定もブロック可能
  • 請求書プラグイン固有のフィルターがあれば、そこからも支払い情報を空にできる
  • 後払い専用のカスタム注文ステータスを導入すれば、処理中と混同せずに管理できる