WC 11.0の注文アイテム削除アクションタイミング変更と開発者対応
WooCommerce 11.0.0のリリースに伴い、注文アイテム削除時のアクションフック woocommerce_removed_order_items の発火タイミングが大きく変わった。これまでは削除メソッド内で即座にデータベースからアイテムを消した直後にフックが走っていたが、今後は save() が呼ばれるタイミングまで遅延される。
この変更の本質は、注文復元フローで発生し得る「行アイテム消失」バグの修正だ。決済中断後の再開処理で、意図せず注文明細が空になる問題がこれで解消される。ただし、従来のタイミングを前提にした拡張機能やカスタムコードは、コールバックの変更が必要になる可能性がある。
この記事では、変更の背景、具体的な動作の差、そして開発者が取るべき対応策を整理する。内部的で動作確認用のフックに依存している開発者は特に注意が必要だ。
WooCommerce 11.0の注文アイテム削除フックに何が起きたのか
WooCommerceのコアクラス WC_Abstract_Order には、注文アイテムをまとめて削除する remove_order_items() メソッドがある。このメソッドは、チェックアウト時に注文内容を再構築する場面などで内部的に呼ばれる。
10.9系以前では、remove_order_items() が呼ばれるとすぐにデータベースから該当のアイテム行が削除され、その直後に woocommerce_removed_order_items アクションが発火していた。いわば「削除してからお知らせ」の流れだ。
11.0.0からは、アイテムのデータベース削除そのものは save() が呼ばれるまで引き延ばされる。そして woocommerce_removed_order_items アクションは、実際に削除がコミットされた直後の save_items() 内で発火するようになった。すぐに消さず、「保存のタイミングで消して知らせる」形へと変更されたわけだ。
この図のように、preフック（woocommerce_remove_order_items）の位置は変わっていない。変更されたのはpostフックのほうだけで、発火の場所が remove_order_items() の中から save_items() へと移動した。
なぜ削除の遅延が必要だったのか
変更の直接のきっかけは、チェックアウト時の注文再開フローで発生していたバグだ。WooCommerceの内部では、決済途中で何らかのエラーや中断が起きた場合、同じ注文データを使って再開を試みる仕組みがある。
10.9以前の処理は次のような流れだった。まず remove_order_items() で既存のアイテムをデータベースから削除し、その後に新しい内容を再構築して save() で保存する。ところが、削除と再構築の間に何らかの例外が発生したり、決済ゲートウェイが二重チェックアウトをトリガーしたりすると、新しいアイテムが書き込まれないまま保存処理に進んでしまうケースがあった。
その結果、合計金額は正しいのに注文明細が空になるという不整合が発生していた。管理者や店舗スタッフから見ると「注文はあるのに何を買ったのかわからない」状態で、商売上の大きな問題だ。
そこで11.0.0では、データベースからの削除を save() のタイミングまで遅延させる設計に変更された。これにより、再構築の途中で何か問題が起きても、直前の正しい注文内容がデータベース上に残っている。中断したら元のまま、成功したら新しい内容で上書きされる。再開フロー全体が原子的になるわけだ。
preフックの woocommerce_remove_order_items は引き続き remove_order_items() の先頭で同期的に発火する。postフックだけが「保存時に遅延」される形になる。両方のフックを組み合わせて使っているコードだけが影響を受ける可能性がある。
開発者が影響を受ける具体的なパターン
今回の変更は、あらゆる拡張機能に一律で影響するわけではない。影響を受けるかどうかは、フックの使い方によって明確に切り分けられる。
影響を受けるケース
次のようなコードが該当する。
woocommerce_removed_order_itemsにコールバックを追加し、その中で「アイテムはもうデータベースに存在しない」という前提で処理を行っているwoocommerce_remove_order_items（pre）とwoocommerce_removed_order_items（post）のペアで一連の操作を挟み込んでいるremove_order_items()が戻った直後に「データベースからアイテム行が消えている」と期待している
要するに、postフックが「同じコールスタック内ですぐ実行される」という暗黙の前提に依存しているコードは、動作が変わる可能性が高い。
影響を受けないケース
一方、次のような使い方をしている場合は問題ない。
- 最終的な保存済みの注文状態だけを監視する目的でpostフックを使っている
- コールバック内で、DB削除がコミットされた後の最終状態だけを参照している
- WooCommerceコア自体にはこのフックの利用箇所はないため、標準機能への影響はゼロ
postフックは変わらず「データベース削除の完了後」に発火するため、単純に「削除が終わったことを検知したい」だけのコードはそのまま動く。
開発者が今すぐ取るべき具体的な対応
コールバックの動作確認と修正
影響を受ける可能性のあるコードを発見したら、まず次の3点を確認してほしい。
remove_order_items()が戻った直後にデータベースのアイテム削除を前提にしている場合は、削除を期待する処理の前に明示的に$order->save()を呼ぶ- preフックとpostフックをペアで使っている場合は、postフックのロジックを注文の保存後に実行するように再構成する
- 動作確認はWooCommerce 11.0.0以降の環境で必ず実施する
コールバックが単に「削除後の状態を見たい」だけなら、特に対応は不要だ。postフックは依然としてDB削除のコミット後に発火するため、観測できる最終状態に違いはない。
save() を明示的に呼ぶことの意味
11.0.0以降のバージョンでは、remove_order_items() を呼んだだけではデータベースへの変更は一切発生しない。あくまでオブジェクトの内部状態が変わるだけだ。データベースへの反映は後続の save() でまとめて行われる。
つまり、「アイテムが消えた状態の注文をデータベース上で確定させたい」のであれば、プログラムの流れの中で明示的に $order->save() を実行する必要がある。これは今回の変更を正しく扱う上で最も重要なポイントだ。
この変更がもたらす開発者体験への影響
一見すると「動いていたコードが壊れるのか」と不安に思うかもしれないが、この変更の根底にはコードの安全性を高めるという明確な意図がある。削除と保存を分離することで、中途半端な状態に陥る可能性を根本から断ち切っている。
WooCommerceの内部設計に詳しい開発者であれば、データベース操作の遅延実行はむしろ現代的なパターンだと感じるだろう。トランザクション的な一貫性を重視する設計は、拡張機能の品質向上にもつながる。
影響範囲が限定的であることも安心材料だ。WooCommerceコア自身はこのフックを消費しておらず、実質的にはサードパーティ製のプラグインやテーマだけが該当する。大半のショップ運営者は特に意識することなくアップデートできる。
この記事のポイント
- WooCommerce 11.0.0で
woocommerce_removed_order_itemsフックの発火タイミングがsave()実行時へ変更された - preフックの
woocommerce_remove_order_itemsは変わらず同期的に動作する - 変更の目的は注文再開時の行アイテム消失バグの修正で、削除処理を遅延させることで安全なフローを実現
- postフックが「削除直後に走る」ことを前提にしたコードのみが影響を受ける可能性がある
remove_order_items()の直後にDB反映を期待するなら明示的にsave()を呼ぶこと
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
プラグイン更新後に WordPress ログイン不能になる「Cookie がブロックされました」エラーの直し方
CF7 Google Sheet Connector バージョン 5.2.1 へのアップデート直後から、WordPress の管理画面にまったくログインできず、ログインページで「Cookie は予期しない出力のためにブロックされました」というエラーが表示されるなら、直接の原因はそのプラグインの不具合にある。FTP を使ってプラグインフォルダをリネームし、強制的に無効化すればログイン機能をすぐに回復できる。
プラグイン更新後に WordPress へログインできなくなる根本原因
WordPress のプラグインやテーマは、PHP の開始タグを閉じずにファイルを記述するのが一般的だ。しかし、何らかの原因でファイルの末尾に余分なスペースや空行が紛れ込んだり、意図しない echo や print が実行されたりすると、WordPress 本体が HTTP レスポンスを送信する前に「予期しない出力」が生まれる。
この予期しない出力は、ログイン機能で使われるセッション Cookie や setcookie() 関数の動作を妨げる。PHP は一度でも出力が行われると、後から HTTP ヘッダーを書き換えられないため、WordPress が正しく Cookie を発行できなくなり、結果として「重大なエラー」画面や「Cookie は予期しない出力のためにブロックされました」というエラーメッセージを返すようになる。
このデモが示すのは、問題のプラグインが WordPress のログインプロセスに割り込んでしまう仕組みだ。CF7 Google Sheet Connector 5.2.1 をはじめ、ごく一部のバージョンでこの現象が発生するケースが海外フォーラムでも報告されている。根本的には、プラグイン開発者が PHP ファイルの末尾やインクルード処理に余計な出力を残してしまうヒューマンエラーに起因する。
「Cookie がブロックされました」はなぜ起こるのか── unexpected output の詳細
「Cookie は予期しない出力のためにブロックされました」は、WordPress のログイン時でなくても、プラグインの有効化画面で「このプラグインは有効化中に 3 文字の予期しない出力を生成しました」といった警告文とともに現れる。この警告は、まさに PHP が <?php の開始タグよりも前やファイル末尾に余計な空白文字を出力している証拠だ。
コンタクトフォームの送信自体は成功し、Google スプレッドシートへのデータ転送も動いているのに、ログインだけが機能しなくなるのは、フォーム送信とログイン認証で通る PHP の実行経路が異なるためだ。フォーム送信時にはセッション Cookie を新たに発行する必要がないため、表面上は問題が表面化しにくい。しかし wp-login.php や管理画面の認証周りでは、必ず Cookie のセットが行われるので、エラーが必ず検出される。
FTP で問題のプラグインを無効化する具体的な手順
管理画面にログインできない状態では、ブラウザ上の操作だけではプラグインを停止できない。ここで必要なのが、契約しているレンタルサーバーの FTP アカウントを使った直接のファイル操作だ。FTP クライアントやサーバー管理画面のファイルマネージャー機能を利用して、次の手順を実行する。
/wp-content/plugins/ ディレクトリに移動するcf7-google-sheet-connector）を探し、リネームする（末尾に _disable などをつける）/wp-admin/ にアクセスし、通常通りログインできるか確認するリネームはフォルダ名の先頭や末尾に「_」を付けるだけでも十分であり、WordPress がそのプラグインを認識できなくなる。ログインが回復したら、管理画面の「プラグイン」一覧から、無効化された状態の当該プラグインを確認できる。ここで「削除」を選べば、問題のバージョンは完全に取り除かれる。
プラグインを以前のバージョンに戻して再発を防ぐ
CF7 Google Sheet Connector を使い続ける必要があるなら、安定していた旧バージョンに戻すか、開発元が修正パッチを公開するのを待つことになる。WordPress 管理画面からプラグインを再インストールする際は、あえてバージョン 5.2.1 を避け、プラグインページ下部の「以前のバージョン」セクションや、WP Rollback のようなロールバック専用プラグインを使って前のバージョンにダウングレードできる。
また、問題が発生したプラグインをどうしても最新で使い続けたいのであれば、プラグインのサポートフォーラム（WordPress.org 内）で「バージョン 5.2.1 で unexpected output が発生しログイン不能になる」という事象を報告し、修正を促すのが建設的だ。開発者が原因を把握すれば、比較的早期に新しいバージョンがリリースされる可能性が高い。
よくある質問
FTP アカウント情報がわからない場合はどうすればいいか
契約しているレンタルサーバーの管理画面（コントロールパネル）に、FTP アカウントの設定やファイルマネージャー機能が用意されているケースが多い。cPanel なら「FTP アカウント」メニューから新規作成やパスワード再設定が可能だ。サーバー会社のサポートに問い合わせれば、FTP 接続情報を再発行してもらえることもある。
プラグインを無効化してもログインエラーが直らない
同様の症状が他のプラグインやテーマでも発生する可能性がある。全プラグインを無効化し、標準テーマ（Twenty Twenty-Five 等）に切り替えた状態で症状が消えるかどうかを確認する。それでも直らない場合は、サーバーの PHP エラーログを調べ、別の致命的エラーが起きていないか検証する必要がある。
プラグインの更新を止める方法はあるか
WordPress の標準機能では特定プラグインの自動更新だけを選択的に止めることはできないが、プラグイン「Easy Updates Manager」を使うと、プラグイン単位で自動更新を無効化できる。問題のあるバージョンを避けつつサイトを安全に保つには、ステージング環境で事前に更新テストを行うのが最も確実だ。
フォームのデータが送信されていれば問題ないのか
フォームが動いているからといって放置するのは危険だ。ログイン不能はサイト全体の管理を妨げるだけでなく、同じ予期しない出力が他の機能（RSS フィードや REST API）にも影響を及ぼす恐れがある。できる限り早急に原因のプラグインを停止し、サイト全体の健全性を取り戻す必要がある。
プラグインを手動で削除してもデータは残るのか
CF7 Google Sheet Connector の場合、コンタクトフォームの設定や Google スプレッドシートとの認証情報はデータベースに保存される。そのため、プラグインフォルダを削除しても設定情報は消えない。再度同じプラグインをインストールすれば、以前の連携設定を引き継げる可能性が高いが、念のためデータベースのバックアップを取ってから削除するのが安全だ。
この記事のポイント
- CF7 Google Sheet Connector 5.2.1 では unexpected output によりログイン不能になる不具合が報告されている
- 「Cookie がブロックされました」は PHP の予期しない出力が原因で、FTP を使ったプラグイン無効化で回復する
- 管理画面にログインできなくても、FTP やファイルマネージャーからプラグインフォルダをリネームすれば強制停止可能
- 旧バージョンへのダウングレードや開発元へのフィードバックで再発を防止できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
OpenAI、推論保持とコンパクションでARC-AGI-3スコア3倍化
OpenAIの最新モデル「GPT-5.6 Sol」が、ARC-AGI-3ベンチマークで当初のスコアを約3倍に伸ばした。わずか2つのAPI設定を切り替えただけである。単にベンチマーク成績を上げただけでなく、出力トークン量も6分の1に削減した。
GPT-5.6 Solは数学の未解決問題を証明し、ポケモンなどのゲームをクリアする実力がある。それにもかかわらず、2Dパズルゲームで構成されるARC-AGI-3では開始直後ほぼ無力に見えた。スコアはわずか7.8%である。
問題はモデルそのものではなく、評価を実行する「ハーネス（テスト環境）」の設計にあった。OpenAIが本番環境で使っている推論保持とコンパクションを適用したところ、スコアは13.3%から38.3%へと跳ね上がった。これは人間の平均スコア（48%）に大きく近づく数字である。
なぜGPT-5.6 SolはARC-AGI-3で苦戦したのか
ARC-AGI-3ベンチマークの概要
ARC-AGI-3は、AIエージェントが未知の2Dゲームを探索しながらルールを推論し、自力で解く能力を測るベンチマークである。人間には直感的に分かるような簡単なパズルでも、AIにとっては説明なしに仕組みを理解するのが極めて難しい。
このベンチマークは、AIがどれだけ「学習し、推論できるか」を厳密に評価するために設計されており、特殊なツールや支援機能は一切与えられない。公式が用意するハーネスは、どのモデルでも同じ条件で比較できるよう、意図的に簡素な作りになっている。
公式ハーネスの2つの問題点
OpenAIの調査チームは、GPT-5.6 Solがゲーム内でひとつ行動するたびに「思考が真っ白に戻っている」ことに気づいた。公式ハーネスは、次の行動を起こす前に、モデルが直前に行った非公開の推論メッセージをすべて破棄していた。
一連の行動記録や簡単なメモは残るものの、その行動を導いた計画やひらめきは記憶に残らない。つまり、モデルは毎ターン、ゲームの仕組みを一から考え直さなければならなかった。
さらに、会話のコンテキストが長くなると「ローリング打ち切り」が発動し、古い行動履歴から順に削除されていく。推論が消えたうえに、過去の行動すら見えなくなるため、長期的な学習がほぼ不可能だった。この2つの設計が、GPT-5.6 Solの性能を著しく抑え込んでいたのである。
この図のように、ハーネスの設計ひとつで、同じモデルの振る舞いが大きく変わる。単純な推論保持と圧縮によって、アシスタントとしての性能が劇的に改善することをOpenAIは示した。
推論保持とコンパクションがもたらした改善
推論保持の効果
GPT-5.6は、ChatGPTやCodexでも使われている仕組みとして、返答やツール呼び出しの前に非公開の推論メッセージを生成する。通常、この推論は会話履歴の一部として保持される。公式ハーネスではこれが破棄されていたが、OpenAIのResponses APIを使うと、前のレスポンスIDを次に渡すだけで自動的に推論が引き継がれる。
推論が保持されると、2つの大きな変化が起きた。まず、毎回ゲームのルールを最初から解釈する必要がなくなり、1回の行動にかかる思考時間が短縮された。次に、過去の思考を思い出せるようになったことで、モデルは時間をかけて学習し、一貫した戦略を取れるようになった。
コンパクションの効果
公式ハーネスは、コンテキストが175,000文字を超えると古いメッセージを削除する「ローリング打ち切り」を採用していた。これに対し、Responses APIのコンパクションは、会話が長くなったときに内容を要約して保持する。これにより、過去の観察や行動を失うことなく、より少ないトークンで同じ情報を維持できる。
コンパクションを有効にした環境では、GPT-5.6 Solはゲーム内で学んだことを長いプレイ時間にわたって保持しやすくなり、スコアがさらに向上した。結果として、出力トークン数も大幅に削減された。
パフォーマンスの大幅向上とトークン削減
公開タスクセットにおいて、公式ハーネスでのGPT-5.6 Sol（max）のスコアは13.3%だった。推論保持とコンパクションを適用した結果、38.3%まで上昇した。これは約3倍の改善であり、出力トークンはおよそ6分の1に減少している。
スコアに用いられている「RHAE（Relative Human Action Efficiency）」は、人間のパフォーマンスを基準にした指標である。ARC-AGI-3の公式プレイヤーログから推定される人間の平均スコアは48%であり、GPT-5.6 Solはその80%近くに達した。この数字は、適切なハーネスがいかに重要かを雄弁に物語る。
実務開発者への示唆
Responses API の活用推奨
OpenAIは、API利用者に対して、旧来のChat Completions APIではなくResponses APIを使うこと、そして推論保持とコンパクションを有効にすることを強く推奨している。これらの設定は、ChatGPTやCodexなどのプロダクトで実際に使われている本番構成と同じである。
特に、エージェント的な挙動や長期的なタスクをAIに任せる場合、推論保持とコンパクションは必須に近い。実装上の手間は最小限であり、Responses APIを使えばレスポンスIDを引き継ぐだけで実現できる。
ベンチマーク比較の注意点
今回の事例は、ベンチマーク評価がモデル単体の能力だけでなく、API設定やハーネス設計といった目に見えない要素も測っていることを思い出させる。低いスコアが報告されても、それはモデルの本質的な限界ではなく、評価環境の不備かもしれない。
OpenAI自身、過去にも公開ベンチマークで成績が低く驚いた後に、評価ランナーが推論メッセージを捨てる汎用ハーネスを使っていたことに気づいたという経験がある。モデルを比較する際は、ChatGPTやCodexの実運用に近い設定で評価された結果を基準にすることが望ましい。
この記事のポイント
- GPT-5.6 SolはARC-AGI-3で当初7.8%のスコアだったが、API設定変更後は38.3%まで向上
- 推論保持を有効にすると、過去の思考を再利用でき学習効率が上がる
- コンパクションによって古い情報を要約し、少ないトークンで文脈を維持できる
- Responses API を用いることで、ChatGPTと同等のパフォーマンスを引き出せる
- ベンチマーク評価にはハーネス設計が大きく影響するため注意が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceチェックアウトでVAT任意欄が空だと無効エラーになる不具合の修正方法
WooCommerce のチェックアウトで VAT 番号のフィールドが任意設定なのに、空のまま進むと「VAT が無効」と表示されて注文が完了しない場合は、使用している VAT 関連プラグインのアップデートに不具合が混入している。最新バージョンへ更新すれば多くのケースで直り、どうしても更新が難しいなら前のバージョンに戻すことでチェックアウトを復旧できる。
なぜ VAT 任意項目が空でエラーになるのか
WooCommerce の標準機能に VAT 番号のバリデーション（入力値の検証）は含まれていない。チェックアウト画面に VAT フィールドを追加し、「無効な VAT」「VAT が無効」といったエラーチェックを行っているのは、EU VAT Number 系の拡張プラグインだ。こうしたプラグインでは管理画面から VAT フィールドを必須にするか、任意にするかを切り替えられるが、特定のバージョン（報告では 4.7.6）で、空欄を「無効な VAT」と誤判定する不具合が発生した。設定上は任意でも、チェックアウト処理時に空の値を無効と見なしてエラーを返すため、購入完了まで進めなくなる。
この現象はプラグイン開発者側の不具合であり、サイト側の設定ミスではない。同様の症状が出た場合、まずはプラグインが最新の安定版かどうかを確認するのが最も確実な対処になる。
プラグインの最新バージョンに更新する
上の手順デモは、不具合が修正されたバージョンへ更新する際の流れを示している。実際の管理画面では、VAT 関連プラグインの名前（例 EU VAT Number for WooCommerce 等）を特定し、更新可能なバージョンが表示されていれば「今すぐ更新」をクリックするだけだ。
本件のフォーラム報告例では、バージョン 4.7.6 で問題が発生し、4.7.8 で修正された。同様のケースでは、開発元が既に不具合を認識して修正版をリリースしていることが多い。更新後も症状が続く場合は、プラグインの設定画面で VAT フィールドの「必須」オプションが誤ってオンになっていないか再確認する。
更新できない場合の緊急回避策
何らかの理由ですぐにプラグインを最新版にできない場合、一時的にチェックアウトの支障を取り除く方法として、プラグインを前の安定バージョンに戻す方法がある。プラグインの提供ページから過去のバージョンをダウンロードし、手動で上書きアップロードすれば、VAT フィールドが空でもエラーにならなかった状態に戻せる。
プラグインファイルを手動で置き換える際は、必ず FTP やサーバーのファイルマネージャーでアクセスするか、WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP ファイルでインストールする。作業前に必ずバックアップを取っておく。
もうひとつの緊急手段として、チェックアウト画面から VAT フィールドを一時的に非表示にする方法もある。子テーマの functions.php にフィルターを追加してフィールドを除去すれば、バリデーション自体が行われなくなる。ただしこれは購入者から VAT 番号を取得できなくなるため、後日プラグインが修正されたら元に戻す必要がある。
根本原因を特定して再発を防ぐ
プラグインの自動更新を有効にしていると、気づかないうちに不具合を含むバージョンが適用されてしまうことがある。VAT のような決済に直結するフィールドでトラブルが起きると、数時間の売上損失につながる可能性が高い。そのため、VAT 系プラグインや決済関連プラグインについては、本番環境へ適用する前にステージング環境で動作確認を行うか、少なくとも更新直後に手動でチェックアウトを通すテストを習慣化する。
また、プラグインの更新履歴（Changelog）に目を通し、「fix」「bug」「checkout」といったキーワードの修正が含まれているかどうかを更新前に確認しておくと、問題の発生にすぐ気づける。
よくある質問
どのプラグインが原因かを特定できない時はどうすればよいか
チェックアウト画面に VAT 関連の項目を追加しているプラグインをすべて疑う。プラグイン一覧で「VAT」「EU」「Tax」などで検索し、該当するプラグインをひとつずつ停止して、チェックアウトの動作を確認する。問題のプラグインが特定できたら、そのプラグインのサポートフォーラムで同様の報告がないか調べる。
VAT フィールドを必須に変更すれば一時的に回避できるのか
フィールドを必須にすると、常に VAT 番号の入力を求められるため、空欄によるエラーは発生しなくなる。しかし日本国内の顧客向けに VAT 不要のサイトでは、必須設定は購入体験を損ねる。商品やターゲットに応じて慎重に判断する必要がある。
コードを一切触らずにエラー表示だけ消す方法はあるか
管理画面の設定から VAT フィールドを無効化するか、チェックアウトのフィールド編集機能を持つプラグインで該当フィールドを削除する。ただし、これらの操作もバックアップを取ってから実行し、注文情報に必要なデータが欠落しないように注意する。
更新後もエラーが解消されない場合の次の手は
まずキャッシュ系プラグインや CDN が古いスクリプトを配信していないか確認する。次に、VAT プラグイン以外のチェックアウト関連プラグインとの競合を疑い、すべてのプラグインを一時停止しながら原因を切り分ける。それでも解決しない場合はプラグイン開発元に直接報告する。
この記事のポイント
- 任意設定の VAT フィールドが空でエラーになるのはプラグインの不具合
- 最新バージョンへの更新で修正されるケースが大半
- 更新できない時は前の安定バージョンに戻すかフィールドを一時非表示にする
- 決済関連プラグインはステージングテストと更新履歴確認を習慣化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressホスティングの「セキュア」は本当か？実検証が明かした真実
WP Tavernのポッドキャスト「Jukebox」に、WordPressセキュリティ企業PatchstackのMaciek Palmowski氏が出演した。同氏はWordCamp Europe 2026で「Testing the promise: does secure hosting deliver?」と題した講演を行い、ホスティング会社が掲げる「セキュアホスティング」の実態を検証した結果を発表した。
テストには30の既知のプラグイン脆弱性を用い、複数の主要ホストで同一条件のペネトレーションテストを実施した。結果は衝撃的で、WordPress固有の攻撃の大半が防御をすり抜けるというものだった。ここではポッドキャストの内容を基に、テストの詳細と、そこから得られる実務への教訓を解説する。
「セキュア」の看板をどう検証したのか
この調査のきっかけは、Patchstackが公開したWordPressセキュリティレポートに対する、WordPress共同創設者Matt Mullenweg氏の反応だった。WP TavernのポッドキャストでPalmowski氏は、「ホスティング会社がすでに対処しているのではないか」という趣旨の問いを受けたと述べている。同社はこれに対し、感覚ではなくデータで示す必要があると判断し、実環境でのテストに踏み切った。
30の既知の脆弱性と標準化手法
テストは2段階で行われた。最初の小規模な試験で、すでに「攻撃の80%が成功する」という結果が出たため、範囲を拡大した本試験が実施された。
- 対象: 30種類以上のプラグイン脆弱性。いずれもPatchstackのバグ報奨金プログラムを通じて報告され、攻撃手順（PoC）が確立しているもの。
- 環境: 複数の大手ホスティング会社で、提供されているすべてのセキュリティ機能を有効化した上でテスト。
- 脆弱性の種類: ファイルアップロード、パストラバーサル、SQLインジェクションなど、WordPressプラグインに典型的なものからEC向けまで幅広く選定。
つまり、現実に存在し、攻撃手法も公開されている脆弱性を「ホスティングがどこまで防げるか」を公平に調べたものだ。
この設計により、「マーケティング上のうたい文句」と「実際の防御力」の差が浮き彫りになった。
検証結果が示すギャップ
本試験の結果、WordPressに特化した攻撃の約70〜80%がホスティングの防御を通過した。Palmowski氏は「問題があるとは思っていたが、ここまで大きいとは」と語っている。
同じセキュリティツールでも結果はバラバラ
興味深いことに、同じサードパーティ製セキュリティツール（例としてCloudflareが示唆された）を導入しているホスト間でも、防御の成否に大きな差が出た。これは「どのツールを入れるか」より「どのように設定・運用するか」の重要性を示している。
この差は、設定の積極性と利便性のトレードオフにも関係する。攻撃を厳しくブロックすれば誤検知が増え、ユーザー体験を損なう可能性がある。一部のホストはユーザーへの影響を恐れて設定を緩めていると考えられる。
ホストの「その後の対応」にも差
テスト後、Patchstackは全対象ホストに結果を通知し、どの攻撃が通過したかを共有した。Palmowski氏によると、一部のホストは速やかに設定を修正し、防御力を大幅に改善した。一方で、通知後も何も手を打たなかったホストも存在したという。
「問題があること自体よりも、それを指摘された後の行動のほうが重要だ」と同氏は強調する。セキュリティに終わりはなく、発見→修正のループを回せるかどうかが本質的な強さを決める。
スイスチーズモデルと多層防御
Palmowski氏は、理想的なセキュリティを「スイスチーズモデル」で説明した。どの防御層にも穴（欠陥）は存在する。重要なのは、複数の層を重ねることで、全体として穴をふさぐことだ。
このモデルから言えるのは、ホスティングの防御は重要な第1・第2層だが、それだけでは不十分という点だ。特に第2層の「WordPressアウェア」な保護がないホストでは、第1層だけに頼ることになり、テストのように攻撃が素通りしてしまう。
AI時代の攻撃スピードとパッチ未適用問題
2026年のセキュリティ議論でAIの話題は避けられない。Palmowski氏は「攻撃の高速化」と「パッチ未適用率の高さ」の2点をリスクとして挙げた。
脆弱性公表から攻撃開始まで5時間
Patchstackの内部データによると、脆弱性が公表されてから実際に攻撃が観測されるまでの平均時間は約5時間だ。数年前はもっと長かったが、AIによる攻撃コードの自動生成がこの時間を劇的に短縮している。
「毎週の手動更新で大丈夫」というアドバイスは、2026年においてはほぼ無力だ。攻撃は日単位や週単位ではなく、時間単位で動いている。リアルタイムの防御か、少なくとも自動更新と組み合わせた仕組みが求められる。
50%の脆弱性は公表時点で未パッチ
さらに深刻なのは、発見された脆弱性の約半数が、ベンダーへの通知から30日が経過しても修正されずに公表されている事実だ。これは「とにかく更新すれば安全」という前提を崩す。更新したくてもパッチが存在しないケースが大量にあるからだ。
→ 30日間の修正猶予
STEP 2 未修正のまま公表（ケースの約50%）
→ 平均5時間で攻撃開始
STEP 3 パッチ不在のまま攻撃が拡散
このタイムラインを見れば、「プラグイン開発者が対応してから更新すればいい」という姿勢がいかに危険かがわかる。パッチが存在しない期間こそ、ホスティングレベルでの脆弱性ブロックや仮想パッチが有効になる。
ホスティング選びで問うべき質問
では、利用者や代理店はどのようにホスティングを評価すればいいのか。Palmowski氏は「WordPressに特化したセキュリティ層の有無を確認すること」が最初の一手だと述べる。
「WordPressアウェア」かどうかを見極める
営業担当者やドキュメントに「Webアプリケーションファイアウォールを備えている」とだけ書かれている場合は要注意だ。これはPHP全体に対する汎用防御であり、WordPressのプラグイン固有の脆弱性を検知できるとは限らない。
- 具体的な質問例: 「御社のセキュリティは、WordPressの特定プラグインの脆弱性を検知・ブロックする機能がありますか？」
- 答えられない、または「WAFで対応」とだけ返ってくる場合は、WordPressアウェアな層が存在しない可能性が高い。
- 逆に、特定のセキュリティパートナー（Patchstack、WPScanなど）と連携していると明言できるホストは、少なくともその層を意識していると判断できる。
「すべてを守る」という表現に注意
Palmowski氏は、ホスティング会社が「セキュリティは全てお任せください。追加ツールは不要です」と断言する場合に警戒が必要だと指摘する。同氏の言葉を借りれば、「現実には、どの防御層も完璧ではない」のだ。
「『当社はこの層を担当しますが、最終的なサイト運用のセキュリティはお客様の責任です』と明言するホストのほうが、かえって誠実で信頼できる」とPalmowski氏は評価する。完璧をうたうマーケティングよりも、限界を認めつつ強みを説明する姿勢が、これからの「セキュアホスティング」には求められる。
この記事のポイント
- 複数ホストでの実検証で、WordPress固有の攻撃の70〜80%が防御を通過していた。
- 同じセキュリティツールでも設定や運用次第で結果が大きく異なる。
- 「WAFがあるから安全」ではなく、WordPressのプラグイン構成を理解した層が必須。
- 脆弱性公表から平均5時間で攻撃が始まる現状では、手動更新だけでは不十分。
- 「スイスチーズモデル」に基づき、ホスティングの防御と自社の運用プロセスを重ねる必要がある。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GS Team Membersアップデート後にDiviサイトが壊れた場合の復旧と修正手順
GS Team Membersプラグインのバージョン2.7.17へのアップデート後にDiviサイトが壊れ「このサイトで重大なエラーが発生しました」と表示された場合、開発者が公開した修正版2.7.18へアップデートすれば解決する。リカバリーモードで管理画面に入りプラグインを一時停止したあと、最新版へ更新するだけでサイトは復旧する。
どんなエラーが発生しているのか
GS Team Members 2.7.17では、Diviテーマ向けの統合モジュールに含まれるファイル「TeamMembersModule.php」の25行目で、必要なインターフェースが見つからないという致命的なエラー（E_ERROR）が発生する。PHPが「インターフェースが存在しない」と判断し処理を停止するため、サイト全体が表示不能になる。
エラーメッセージの要点は次の通りだ。「Interface "ET\Builder\Framework\DependencyManagement\Interfaces\DependencyInterface" not found」という内容で、Diviのビルダーフレームワークが提供するDependencyInterfaceというインターフェースを読み込もうとしたが見つからなかったことを示している。
このエラーは管理画面にもフロントエンドにも影響し、WordPress本体が自動的にリカバリーモードへ移行させる。スタックトレースにはGoogle Site Kitも登場するが、これはエラーの連鎖で巻き込まれただけで、根本原因ではない。
なぜアップデートでサイトが壊れたのか
原因はGS Team Members側のコード不備だ。バージョン2.7.17でDivi向けの統合コードを更新した際、Divi本体のバージョンによっては存在しないインターフェースを参照してしまった。PHPでは存在しないクラスやインターフェースを使おうとすると即座に致命的エラーを投げるため、その瞬間にサイト全体の処理が停止する。
スタックトレースを見ると、DependencyInterfaceを読み込もうとした箇所からエラーが始まり、REST APIの初期化処理へ飛び火している。管理画面のダッシュボードでは複数のプラグインがREST API経由でデータを取得するため、Google Site Kitや他のプラグインの処理が次々にエラーに巻き込まれているが、これらは二次的なものだ。
根本的な問題はGS Team Members 2.7.17のコードにあるため、Diviを使っているユーザーだけがこのエラーに遭遇する。他のテーマやページビルダーを使っている場合は問題が起きない。
リカバリーモードで管理画面にアクセスする手順
サイトが壊れて管理画面にもアクセスできなくなった場合、WordPressは自動的にリカバリーモードへのリンクを記載したメールを管理者アドレスに送信する。このメールを使って管理画面へ入り、問題のプラグインを停止するのが最初の復旧手順だ。
リカバリーモードのリンクは24時間の有効期限が設定されている。メールが届かない場合は迷惑メールフォルダを確認し、それでも見つからなければFTPやサーバー管理ツールでプラグインフォルダの名前を変更して強制的に無効化する手段も取れる。
GS Team Membersを最新版へアップデートする
GS Team Membersの開発者はバージョン2.7.18でこの問題を修正している。アップデート内容は「Uncaught Error: Dependency Interface」への対応で、Diviテーマとの統合コードを修正したものだ。プラグインを停止した状態で管理画面の「プラグイン」ページを開き、「GS Team Members」が更新可能になっていればそのままアップデートを実行する。
更新が完了したらプラグインを再度有効化し、サイトのフロントエンドと管理画面の両方が正常に表示されることを確認する。この時点でプラグインのキャッシュが残っている可能性があるため、ブラウザキャッシュの削除も忘れずに行う。
もし更新通知が表示されない場合は、プラグインを一度削除してから新規インストールし直す方法もある。この場合、プラグインの設定や登録済みのチームメンバーデータが保持されるかどうかを事前に確認しておく必要がある。
FTPから手動でプラグインを停止する方法
リカバリーメールが届かない、あるいはメールアドレスが古くなっているなどで管理画面に入れないケースでは、FTPやサーバーのファイルマネージャーを使ってプラグインを一時停止する。手順は単純で、対象プラグインのフォルダ名を変更するだけだ。
サーバーに接続し「wp-content/plugins/」ディレクトリへ移動する。その中にある「gs-team-members」フォルダを「gs-team-members-backup」などにリネームする。WordPressはフォルダ名でプラグインを認識するため、名前が変わると自動的にプラグインが無効化される。
これでサイトが正常に表示されるようになったら管理画面へログインし、「プラグイン」ページでGS Team Membersが解除扱いになっていることを確認する。そのまま管理画面から最新版をインストールし、フォルダ名を変更した古いバージョンは削除しておく。
再発を防ぐためのアップデート前確認事項
プラグインのアップデートでサイトが壊れるリスクを減らすには、いくつかの事前対策が有効だ。第一に、本番サイトで直接アップデートを実行するのではなく、ステージング環境で事前にテストする方法が最も安全だ。国内のレンタルサーバーの多くは管理画面からワンクリックでステージング環境を作成できる機能を提供している。
第二に、WordPressにはプラグインの自動更新機能があるが、ビジネス用途で使っているサイトではこれをオフにし、すべてのアップデートを手動で確認する運用が推奨される。プラグイン一覧で更新通知を受け取ったら、そのプラグインの変更履歴（changelog）を読み、自分の環境に影響がありそうかを判断してから実行する。
第三に、バックアッププラグインを必ず導入し、アップデート前の状態をまるごと保存する習慣をつける。もし何か起きても数分で元に戻せる安心感が、トラブル時の心理的負荷を大きく下げる。
よくある質問
GS Team Members以外のプラグインでも同じようなエラーは起きるのか
起きる可能性は十分ある。特にDiviやElementorのようなページビルダー向けのアドオンを提供するプラグインは、テーマ側のバージョンと整合性が取れていないアップデートをリリースしてしまうことがある。致命的エラーに遭遇したら、まず該当プラグインを停止し、最新バージョンの有無を確認するのが基本だ。
リカバリーモードのメールが届かない場合はどうする
サーバーのメール送信設定が正しくない、管理者メールアドレスが古い、または迷惑メールに振り分けられている可能性がある。FTPで問題のプラグインを停止してから、WordPressの「設定」→「一般」で管理者メールアドレスを最新のものに更新し、SMTPプラグインを導入してメール送信を安定させるのが長期的な解決策になる。
Diviを使っていなければこのエラーは起きないのか
その通りだ。今回のエラーはGS Team MembersのDivi統合用コードに起因するため、他のテーマを使っているサイトでは発生しない。ただし、プラグインのアップデートで別のテーマとの組み合わせに問題が生じるケースは常にあり得るため、油断は禁物だ。
プラグインの更新前に毎回ステージングテストは必要なのか
小規模なサイトや個人ブログであれば必須ではないが、ECサイトや企業サイトなどビジネス用途では強く推奨される。数分のテストで数時間のダウンタイムを防げるなら、手間をかける価値は十分にある。最近の国内レンタルサーバーはステージング機能を標準搭載しているところも多い。
Google Site Kitは関係しているのか
関係していない。エラーのスタックトレースにGoogle Site Kitが登場するのは、REST APIの初期化時にたまたま処理が巻き込まれたためだ。GS Team Members単体の問題であり、Google Site Kit側での対応は不要だ。
この記事のポイント
- GS Team Members 2.7.17はDivi環境で致命的エラーを引き起こす
- リカバリーモードで管理画面に入りプラグインを停止すればサイトは復旧する
- 開発者が公開した修正版2.7.18へアップデートすれば根本解決する
- FTPでの手動停止も有効な代替手段だ
- 重要なサイトではステージング環境での事前テストが再発防止に効く
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法
Googleがクロールインフラストラクチャの公式ドキュメントを更新し、「クロールバジェットの最適化」に関する新たなガイドラインを公開した。ECサイト運営者にとって、この変更は商品ページのインデックス速度に直結する。クロールされなければ検索結果に表示されないからだ。
今回の更新で注目すべきは、新サイトに割り当てられる「保守的なクロールバジェット」の考え方と、304ステータスコードに関する注意喚起だ。特に304の扱いは、安易に導入すると検索順位に影響を与える可能性がある。
この記事では、Googleの新ガイドラインの要点と、ECサイトが実践すべきクロールバジェット最適化の手法を解説する。
クロールバジェットとは何か
クロールバジェットとは、Googlebotが一定期間内に特定のサイトをクロールするURLの総量を指す。インターネット上のURL数は膨大であり、Googleは各サイトに割り当てるクロール量を最適化する必要がある。この割り当てが「バジェット（予算）」と呼ばれる理由だ。
サイト構造が整理されておらず、無駄なURLが多いサイトは、クロールに時間がかかり、結果としてインデックスされるページ数が少なくなる。ECサイトの場合、商品ページがインデックスされなければ、検索経由の流入機会を失うことになる。
クロールバジェットを意識したサイト設計は、検索エンジンに「このサイトは効率的にクロールできる」と認識させる第一歩だ。以下、Googleの新ガイドラインに沿った具体的な施策を見ていく。
新サイトには保守的なクロールバジェットが割り当てられる
Googleの更新されたドキュメントで明確にされたのが、新規サイトに対するクロールバジェットの初期値だ。新サイトには「保守的な」バジェットが割り当てられ、サーバーに過負荷をかけずに重要なコンテンツをカバーできるよう設計されている。
段階的なコンテンツ公開が鍵
新サイトを立ち上げる際は、一度に大量のページを公開するよりも、徐々にページ数を増やす方がGooglebotの信頼を得やすい。たとえば、100商品を1日で公開するより、1日3商品ずつ約1ヶ月かけて公開する方が、クロールバジェットの観点からは有効だ。
この段階的アプローチにより、Googlebotはサイトの更新パターンを学習し、クロールバジェットを徐々に拡大していく。XMLサイトマップの自動更新と組み合わせることで、さらに効果が高まる。
表示速度の改善がバジェットを増やす
サイトの読み込み速度が速いほど、Googlebotは効率的にクロールできる。これは以前から知られていた事実だが、今回のガイドラインでも改めて強調された。表示速度の改善は、ユーザー体験の向上だけでなく、クロールバジェットの増加にも直結する。
Googleが提供するPageSpeed InsightsやLighthouseを使って定期的にパフォーマンスを測定し、改善を続けることが重要だ。ECサイトでは、画像の最適化や不要なスクリプトの削減が特に効果的だ。
人気ページはクロール頻度が高まる
外部リンクや内部リンクを多く集めているページは、Googlebotの巡回頻度が高くなる。ECサイトの場合、トップページや主要カテゴリページ、よく参照される商品ページが該当する。内部リンク構造を最適化し、重要なページへリンクを集中させることで、クロール頻度を向上させられる。
クロール効率を下げる要因とその対策
クロールバジェットを浪費する要因はいくつかある。以下に主要なものと対策を示す。
robots.txtで不要ページをブロック
プライベートログインページ、ショッピングカート、動的に生成されるページなど、インデックス不要なページはrobots.txtのdisallowディレクティブでブロックする。これにより、Googlebotが本当に重要なページだけを巡回するよう誘導できる。
重複コンテンツの削除と統合
同じ内容のページが複数存在すると、クロールバジェットが分散される。商品バリエーション（色違い、サイズ違い）でURLが分かれている場合は、canonicalタグで正規URLを指定するか、統合を検討する。
ソフト404とリダイレクトチェーンを回避
削除されたページが200ステータスコードを返す「ソフト404」は、Googlebotが無駄なクロールを続ける原因となる。存在しないページは404または410レスポンスを返すように設定する。また、1つのページに対して複数のリダイレクトが発生する「リダイレクトチェーン」も、クロール効率を低下させるため避けるべきだ。
Search Consoleのクロール統計を活用
Google Search Consoleの「設定」→「クロール統計」レポートでは、Googlebotのクロール頻度や発生した問題を確認できる。このレポートを定期的にチェックし、クロールバジェットの消費状況を把握することが、最適化の出発点となる。
304ステータスコードの注意点
今回のガイドライン更新で追加されたのが、304（Not Modified）ステータスコードに関する推奨だ。Googleは「前回のクロールからページが変更されていない場合、304コードを返すことでGoogleにキャッシュ版の再利用を促し、サーバー帯域とリソースを節約できる」としている。
しかし、この推奨には注意が必要だ。Practical Ecommerceの記事では、Jill Kocher氏が次のような見解を示している。304コードを重要なページに使用すると、検索結果での表示順位やインデックスステータスに影響を与える可能性がある。同氏は、期限切れ商品やポリシーページなど、重要性の低いページに限定して使用することを推奨している。
ECサイト運営者としては、この304コードの推奨を鵜呑みにせず、自社のSEO戦略に照らして慎重に判断する必要がある。売上に直結する商品ページやカテゴリページには適用せず、重要度の低い固定ページに限定するのが賢明だ。
この記事のポイント
- 新サイトのクロールバジェットは「保守的」に設定されるため、段階的なコンテンツ公開が有効
- 表示速度の改善と定期的な更新が、クロールバジェット拡大の鍵
- robots.txtの活用、重複コンテンツの統合、ソフト404の排除で無駄なクロールを削減
- Search Consoleのクロール統計レポートで状況を定期的にモニタリング
- 304ステータスコードは重要ページには使用せず、影響の少ないページに限定する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
The Events Calendarでカレンダー表示にならない原因と直し方
The Events Calendar でカレンダー表示（月表示）を設定しているのに、一覧（リスト表示）しか出てこない原因は、多くの場合「今後のイベントが存在しない」ことによるフォールバック動作だ。今後のイベントが1件もない場合、The Events Calendar は自動的に直近の過去イベントをリスト形式で表示する。そのため、設定を変えてもカレンダーが表示されず、タブ状の一覧だけが現れる。
カレンダー表示にならずリスト表示になるのはなぜか
この現象は、The Events Calendar プラグインが持つ「今後のイベントがない場合のフォールバック機能」により発生する。プラグインの仕様として、直近で開催予定のイベントがない状態で月表示ページにアクセスすると、デフォルトで「直近の過去イベント」がリストビューで表示される。したがって、カレンダーの月グリッドが見えないのは表示設定の不備ではなく、表示する「今後のイベント」がデータベース上に1件も存在しないことが根本原因だ。
管理画面のイベント設定や表示オプションをいくら変更しても、今後のイベントが0件であればリスト表示へのフォールバックが優先され、見た目は変わらない。特に「イベントを作成して公開したはず」と思っていても、日付が過去に設定されていたり、下書きのまま放置されていたケースが多い。
イベントが存在するのにカレンダーが出ない場合のチェックポイント
イベントの日付が過去になっていないか確認する
管理画面の「イベント」→「すべてのイベント」から各イベントの開始日時を確認する。日付が過去のものであれば、そのイベントは「今後のイベント」として認識されない。イベント編集画面で開始日を未来の日付に修正し、「更新」をクリックするだけで、カレンダー表示に反映される。
イベントの投稿ステータスが「公開済み」かを調べる
イベントが「下書き」や「非公開」のまま保存されていると、フロントエンドのカレンダーには表示されない。一覧画面でステータス列を確認し、公開済みになっていないイベントがあればステータスを「公開」に変更する。カレンダー表示に使われるのは公開済みのイベントだけだと覚えておく。
カテゴリページの表示設定を確認する
特定のイベントカテゴリページ（例：「学生向けイベント」カテゴリ）でリスト表示になってしまう場合、そのカテゴリに属する今後のイベントが存在しない可能性が高い。イベント編集画面で該当カテゴリを割り当てた未来イベントを最低1件作成する。カテゴリページの URL を直接確認し、月表示のクエリ文字列がついているかもあわせてチェックする。
テンプレートの上書きやテーマの干渉を調べる
The Events Calendar の表示テンプレートを子テーマやカスタムテーマで上書きしている場合、意図しないテンプレートファイルが読み込まれて月表示が無効化されることがある。特に `tribe/events/v2/month/` 配下のテンプレートファイルを触っていないか、`/wp-content/themes/使用テーマ/tribe-events/` ディレクトリの有無を FTP やファイルマネージャーで確認する。
根本原因かどうかを1分で見極めるテスト手順
この4ステップのテストでカレンダーが正常に表示されれば、根本原因は「表示すべき未来イベントの不在」だと特定できる。もしこれでも改善しない場合、プラグインの競合やテーマの上書きを疑い、別のトラブルシューティングに進む。
今後のイベントが0件でもカレンダーグリッドを強制的に表示させる方法
どうしても空のカレンダーグリッドを表示させたい場合は、`functions.php` にフィルターフックを追加するか、The Events Calendar のアドオン「The Events Calendar Pro」で追加されるカスタマイズオプションを利用する。無料版のまま対処するなら、`tribe_events_views_v2_use_period_for_request` フィルターを使ってフォールバックの挙動を変更できる場合があるが、これは将来のアップデートで動作が変わる可能性もある。
直近の過去イベントではなく「今後のイベントはありません」といったメッセージとともに空のカレンダーを出す運用がどうしても必要な場合は、子テーマのテンプレートを修正する方法が確実だ。
よくある質問
イベントは10件以上あるのにリスト表示のままなのはなぜか
すべてのイベントが過去日付で作成されている可能性が高い。イベント一覧で「開始日」の列を確認し、未来の日付が1件もない場合は、フォールバック機能によりリスト表示になる。1件でも未来の日付のイベントを公開すれば月表示に切り替わる。
特定カテゴリのページだけリスト表示になるのはなぜか
そのカテゴリに属する今後のイベントが存在していないためだ。カテゴリページでは、当該カテゴリに割り当てられた未来イベントが1件もないと、フォールバックでリスト表示に切り替わる。該当カテゴリを付与した未来イベントを作成すれば直る。
The Events Calendar で「月」表示をデフォルトに設定するにはどうすればよいか
管理画面の「イベント」→「設定」→「表示」タブにある「デフォルトのイベント表示」で「月」を選択する。ただしこの設定は今後のイベントが存在することが前提であり、未来イベントが0件の状態では設定にかかわらずフォールバックが作動する点に注意が必要だ。
メニューからカレンダーページに直接リンクしているのにリストが出るのはなぜか
URL が正しく `/events/month/` を指していても、表示する未来イベントがなければリスト表示のフォールバックが優先される。リンク切れや設定ミスではなく、データの問題だと判断してイベントの日付とステータスを確認するのが先決だ。
カレンダー表示が壊れているのか、フォールバック動作なのかを見分ける方法は
未来の日付で公開済みのテストイベントを1件作成し、フロントエンドで該当ページを再読み込みする。これで月グリッドが表示されればフォールバック動作だと確定できる。表示がまったく変わらない、あるいはレイアウトが崩れる場合はプラグインの競合やテーマの干渉を調べる必要がある。
この記事のポイント
- 今後のイベントが0件だと The Events Calendar はリスト表示にフォールバックする
- 未来日付で公開済みのイベントを1件作れば月表示に切り替わる
- カテゴリページでも同じフォールバック動作が発生する
- テーマのテンプレート上書きやプラグイン競合は二次的な原因にすぎない
- 空カレンダーの強制表示には子テーマやフィルターフックでの対応が必要
“`
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce 11.0リリース延期、致命的エラーで8月4日に再設定
WooCommerce 11.0のリリースが延期された。当初は2026年7月28日に予定されていたが、リリース候補版RC1のテスト中に致命的なエラーが発見されたため、新たなリリース日は8月4日を予定している。
WooCommerce Developer Blogが7月28日に発表した公式情報によれば、このエラーは特定の条件下で発生する新しいパフォーマンス機能に起因する。開発チームは修正を含むRC2を準備中で、7月29日から追加テストを開始する計画だ。
ECサイト運営者にとって、WooCommerceのメジャーアップデートは売上に直結する重要なイベントである。今回の延期がビジネスに与える影響と、本番環境への適用を検討する際の判断材料をまとめた。
WooCommerce 11.0リリースの経緯
WooCommerce 11.0は、ECプラットフォームとしての基盤を大幅に更新するメジャーリリースだ。注文処理の高速化や管理画面の応答性改善など、複数のパフォーマンス向上が含まれると見られている。
開発チームは当初の予定通り7月28日のリリースを目指してRC1（リリース候補版1）を公開したが、早期テストの段階で致命的なエラーが確認された。このエラーの重大性を考慮し、安定版の公開を1週間延期して8月4日に再設定した。
このデモが示すように、開発チームは品質を優先し、既知の致命的な問題を修正してから安定版を届ける判断を下した。RC2での追加テストが成功すれば、当初の予定からわずか1週間の遅れでWooCommerce 11.0が利用可能になる。
致命的エラーの内容と影響範囲
WooCommerce Developer Blogの発表では、エラーの詳細な技術情報は公開されていない。しかし、いくつかの重要なポイントが判明している。
エラーの発生条件
致命的エラーは「特定の状況下」で発生する。これは、すべての店舗で必ず起こるわけではないことを意味する。おそらく、特定のプラグインやテーマとの組み合わせ、あるいは特定のサーバー設定やデータ構成がトリガーになると考えられる。
fatal error（致命的エラー）とは、PHPの実行が停止してしまう深刻なエラーのことだ。WordPressサイトでこれが発生すると、該当ページが完全に表示されなくなる。ECサイトの場合、注文処理や決済フローが停止する可能性があり、事業者にとっては売上機会の喪失に直結する。
パフォーマンス機能に起因する問題
エラーの原因は「新しいパフォーマンス機能」にある。WooCommerce 11.0では、データベースクエリの最適化やキャッシュ機構の改善など、複数のパフォーマンス向上施策が導入される予定だった。これらの新機能のいずれかが、特定の条件下で予期せぬ動作を引き起こしたと見られている。
パフォーマンス改善はECサイトにとって重要なテーマだ。ページ読み込み速度が1秒遅れるごとにコンバージョン率が7%低下するというデータもある。開発チームがパフォーマンス向上を重視するのは当然だが、その実装が安定性を損なっては本末転倒である。今回の延期は、速度と安定性のバランスを取るための慎重な判断と言える。
今後のスケジュールと事業者が取るべき対応
8月4日へ向けた開発チームの動き
開発チームは7月29日からRC2の準備と追加テストを開始する。RC2にはエラー修正が含まれ、安定版リリース前の最終検証が行われる。テストが成功すれば、8月4日にWooCommerce 11.0.0が公開される予定だ。
追加の遅延や変更があれば、WooCommerce Developer Blogを通じてアナウンスがある。本番環境への適用を検討している事業者は、このブログを注視しておくとよい。
事業者が今すべきこと
本番環境のWooCommerceをアップデートする際は、必ず事前にステージング環境でテストすることが鉄則だ。特に今回のメジャーアップデートでは、新機能と既存環境の互換性を慎重に確認する必要がある。
具体的には、以下の手順を推奨する。
- ステージング環境を用意し、現在の本番環境を完全に複製する
- WooCommerce 11.0.0 RC2以降をステージング環境に適用する
- 注文処理、決済、在庫管理、メール通知など主要な機能を一通りテストする
- 利用中のプラグインやテーマとの競合がないか確認する
- テスト結果に問題がなければ、8月4日の安定版リリース後に本番適用を計画する
致命的エラーの具体的な条件が公開されていない現状では、すべての環境で安全とは言い切れない。RC1で発見された問題がRC2で完全に修正されるかどうかも、追加テストの結果を待つ必要がある。本番適用を急ぐよりも、安定性を優先した慎重なアプローチが賢明だ。
上記のSTEPに従うことで、致命的エラーのリスクを最小限に抑えつつ、WooCommerce 11.0の新機能を安全に導入できる。特に決済フローや在庫管理は事業の中核を担う機能のため、十分なテストなしにアップデートすることは避けたい。
今回の延期が示すWooCommerce開発チームの品質姿勢
今回のリリース延期は、WooCommerce開発チームの品質に対する真摯な姿勢を示している。RC1で致命的エラーを発見した段階で、リリースを強行せずに修正と再検証を選択したことは評価に値する。
大規模なECサイトでは、致命的エラーによるダウンタイムが数時間続くだけで数百万円規模の損失が発生することもある。WooCommerceは世界で最も利用されているECプラットフォームの一つであり、その影響範囲は極めて広い。安定版の品質を確保するために1週間の延期を決断したことは、長期的に見れば利用者全体の利益になる。
事業者としては、新機能をいち早く試したい気持ちもあるだろう。しかし、ECサイトの安定稼働が最優先である。開発チームの判断を信頼し、正式リリースまで待つことが賢明だ。
この記事のポイント
- WooCommerce 11.0のリリースが7月28日から8月4日に延期された
- RC1テスト中に発見された致命的エラーが原因で、パフォーマンス機能に起因する
- 開発チームはRC2の準備と追加テストを7月29日から開始する
- 事業者は本番適用前にステージング環境でのテストを徹底すべきである
- 品質優先の判断は長期的にEC事業者の利益となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
npmとGitHub Actionsのサプライチェーン攻撃を遮断する新防御策
npmとGitHub Actionsを舞台にしたサプライチェーン攻撃が、近年組織化された巧妙な手口で猛威を振るっている。2026年前半、GitHubはこの攻撃連鎖を根本から断つため、数多くの防御策を相次いでリリースした。
公式ブログで公開された内容をもとに、初期侵入の防止、認証情報の抜き取り対策、マルウェア拡散の阻止、インシデント対応まで、最新の変更点をまとめて解説する。CI/CDパイプラインやパッケージレジストリを扱う開発者や運用担当にとって、すぐに活用できる情報が揃っている。
サプライチェーン攻撃の実態と攻撃チェーン
オープンソースエコシステムを標的としたサプライチェーン攻撃は、複数の脆弱性を組み合わせて短期間に被害を拡大する。典型的な流れは、メンテナーのアカウント乗っ取りに始まり、CI/CDワークフローの欠陥を突いてプロジェクトへ侵入し、認証情報を窃取したうえで、マルウェアを仕込んだパッケージを一気に配布するというものだ。
GitHubはこうした攻撃チェーンを研究し、最も効果の高い箇所に対策を集中投入している。以下の図は、よく見られる攻撃のステップを簡略化したものだ。
この連鎖を断ち切るため、GitHubは複数の防御層を設けてきた。次節から順に見ていく。
初期侵入を許さない新たな対策
サプライチェーン攻撃の第一段階は、多くの場合フィッシングによるメンテナーアカウントの侵害だ。また、GitHub Actionsのワークフロー設定ミスを突いた手口も頻発している。これらに対抗するため、2026年6月にいくつかの重要な変更が施された。
高影響度npmアカウントの保護
npmでは、影響度の高いアカウントに対して予防的な保護措置が導入された。メールアドレスの変更や二要素認証のリカバリコードを使用した場合、アカウントは72時間にわたって読み取り専用となる。この猶予期間によって、正当なメンテナーがアカウント回復のための時間を確保し、攻撃者が即座に悪用することを防げる。
GitHub Actionsワークフローの安全強化
GitHub Actionsでは、「pwn request」と呼ばれるフォークからのプルリクエストを通じた不正コード実行が長年の課題だった。これに対処するため、actions/checkout のデフォルト動作が変更され、フォークからの信頼できないコードをチェックアウトしないようになった（明示的にオプトアウトすれば従来どおり利用できる）。
さらに、ワークフローのトリガー（実行条件）に対して、誰がどの種類のトリガーを使えるのかをエンタープライズや組織レベルで制御できるポリシーが追加された。これにより、不要な pull_request_target の使用を禁止したり、信頼できないトリガーの範囲を限定したりできる。
加えて、Actionsのキャッシュ操作にも制限がかかった。信頼度の低いワークフローからは、他のワークフローと共有しているキャッシュを変更できないようにし、キャッシュポイズニングによる権限昇格の道を塞いでいる。
認証情報の抜き取りを防ぐ仕組み
初期侵入に成功した攻撃者は、次にCI/CDパイプラインやリポジトリに残る認証情報を狙う。これらを抜き取られないようにすることが、攻撃拡大を防ぐ要となる。
信頼できる公開で長期クレデンシャルを排除
npmの「Trusted Publishing（信頼できる公開）」は、長期にわたって有効なトークンを使わずにパッケージを公開する機能だ。2026年4月より、CI/CDサービスとしてCircleCIが新たにサポートされたことで、より多くのプロジェクトがこの仕組みを利用できるようになった。CI/CD環境に直接シークレットを置く必要がなくなり、たとえ環境が侵害されてもトークンが漏洩するリスクが大きく下がる。
Actionsネットワークファイアウォール（技術プレビュー）
Actionsワークフローの実行中に発生するすべての外向き通信をログに記録する機能が、テクニカルプレビューとして提供開始された。これにより、悪意のあるコードのダウンロードや、未知のドメインへの認証情報の送信といった異常を検知できる下地が整う。将来的には、ネットワークの出口制限（egress restriction）やポリシーによる遮断も視野に入っている。
攻撃の拡散を封じるnpmとGitHub Actionsの強化
認証情報を手にした攻撃者は、次にマルウェアを仕込んだパッケージを大量に公開し、できるだけ多くのプロジェクトに感染させようとする。拡散速度を落とし、悪用の連鎖を食い止める対策がいくつか実装された。
段階的パブリッシュ（Staged Publishing）
2026年5月からnpmで利用可能になったStaged Publishing（段階的公開）は、CI/CDパイプラインのクレデンシャルだけではパッケージを直接公開できなくする仕組みだ。パイプラインからステージングされたバージョンは、別途npm CLIやWebサイト上での手動承認と二要素認証を経て初めて本公開される。これにより、CI/CDが侵害されても自動的にマルウェアが配布されるリスクを断ち切る。
npm v12でインストールスクリプトをデフォルト無効化
攻撃者はパッケージのインストール時に実行されるスクリプト（install scripts）を悪用し、即座に認証情報を抜き取る手法を多用してきた。2026年6月に発表されたnpm v12では、こうしたインストールスクリプトがデフォルトで無効化される。正当な用途でスクリプトが必要な場合は、利用者が明示的に許可を与えることで再び有効にできる。
Dependabotバージョン更新に3日間のクールダウン
攻撃者は新たに公開した悪意あるバージョンが、Dependabotの自動プルリクエストで一気に下流プロジェクトに取り込まれることを狙う。このスピードを抑制するため、2026年7月からDependabotのバージョン更新にはデフォルトで3日間のクールダウンが設けられた。リリース後少なくとも3日が経過するまでプルリクエストは開かれず、その間にコミュニティや自動検知が悪意あるバージョンを発見する猶予が生まれる。なお、セキュリティアップデートは即時に発行されるため、緊急の修正が遅れることはない。
インシデント対応を迅速化する機能
防御策と並行して、万一の侵害発生時に素早く対処できる機能も強化されている。
セルフサービスでのクレデンシャル無効化
2026年6月、エンタープライズ管理者やメンバーが、自身の全クレデンシャルを即座に無効化できるセルフサービスツールが提供された。2月にリリースされたエンタープライズ全体のクレデンシャル管理機能を拡張したもので、サプライチェーン攻撃で認証情報の漏洩が疑われる場合に、数クリックで影響範囲を封じ込められる。
OAuthトークンとAppトークンの即時失効API
2026年3月には、GitHubのOAuthトークンおよびAppトークンをプログラムから即座に失効させるAPIが拡充された。2025年4月に導入されたPersonal Access Token向けの失効APIに続くもので、公開リポジトリにクレデンシャルが漏れてしまった場合でも、開発者が自身で迅速に無効化できる。漏洩したトークンの悪用可能な期間を大幅に短縮する手段となる。
今後の展望
GitHubは製品をデフォルトで安全にする方針を掲げ、npmとGitHub Actionsの両面からサプライチェーン攻撃の遮断に取り組んでいる。今回紹介した変更は数カ月の成果に過ぎず、引き続きchangelogや公式ブログで新たな対策が発表される見込みだ。
オープンソースの持続可能性と企業の安全な利用を支えるこれらの取り組みは、コミュニティ全体にとって大きな前進といえる。
この記事のポイント
- サプライチェーン攻撃は、アカウント乗っ取りからCI/CD経由でマルウェア配布へと連鎖する。GitHubは各段階に多重の防御を適用している
- npmの高影響度アカウントに72時間の読み取り専用期間を設定し、乗っ取り後の即時悪用を防止
- GitHub Actionsの
pull_request_targetやキャッシュ操作を安全なデフォルトに変更し、初期侵入を抑止 - 長期クレデンシャルを使わない「Trusted Publishing」と「Staged Publishing」で認証情報漏洩と自動公開を遮断
- Dependabotのクールダウンとnpm v12のインストールスクリプト無効化で拡散速度を抑制
- クレデンシャルの即時失効機能により、万が一のインシデント対応を迅速に実施可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験