Category Archive WordPress

WordPress 7.1.3 セキュリティアップデート公開。7件の脆弱性修正と即時更新の必要性

WordPress 7.1.3 セキュリティアップデート公開。7件の脆弱性修正と即時更新の必要性

WordPress 7.1.3が10月6日に公開された。セキュリティ修正とメンテナンスを兼ねたリリースで、7件の脆弱性修正と4件のバグ修正が含まれている。

セキュリティリリースであるため、公式サイトはすべてのサイト管理者に即時更新を推奨している。特にコメント管理画面に保存型XSSが発見されており、悪用されると管理者権限を奪われる可能性がある。

この記事では7.1.3で修正された脆弱性の内容、更新手順、バックポートの状況を解説する。サイトを安全に保つための具体的なチェックポイントもあわせて紹介する。

WordPress 7.1.3リリースの概要

WordPress 7.1.3リリースの概要

今回のリリースは定期アップデートではなく、セキュリティ上の問題に対処するための緊急リリースとして位置づけられている。WordPressのセキュリティリリースは、脆弱性の詳細が公開される前に修正版を配布する仕組みだ。今回も7件のセキュリティ修正が含まれており、いずれも悪用されるとサイトの安全性に重大な影響を及ぼす可能性がある。

リリースの基本情報

WordPress 7.1.3は、7.1系の3番目のメンテナンスリリースである。過去のメンテナンスリリースと同様に、バグ修正とセキュリティ修正が同時に行われている。セキュリティ修正が7件、バグ修正が4件だ。バグ修正の内訳はトラッカーのチケットで公開されており、特定の条件下で発生する不具合が対象となっている。

リリースを主導したのはJake Spurlock氏だ。WordPressコア開発のリリースリードとして、複数のコントリビューターと非同期で調整しながら安定版リリースまでこぎつけた。

即時更新が求められる理由

セキュリティリリースの性質上、更新を後回しにすればするほど攻撃を受けるリスクが高まる。攻撃者は公開された修正内容を逆に解析し、まだ更新していないサイトを狙うことが多い。特に今回修正された保存型XSSは承認待ちコメントを経由して悪用できるため、コメント機能を有効にしているサイトは注意が必要だ。

修正された7件の脆弱性

修正された7件の脆弱性

今回のリリースで修正された脆弱性を、影響度の高い順に見ていく。いずれも実際に悪用される前に報告・修正されており、報告者はWordPressセキュリティチームから謝辞が述べられている。

コメント管理画面の保存型XSS

最も深刻な問題は、コメント管理画面における保存型XSS(クロスサイトスクリプティング)だ。承認待ちコメントに細工を施すことで、管理者がコメント管理画面を開いた際にスクリプトが実行される可能性がある。XSSはWebアプリケーションの弱点を突く代表的な攻撃手法で、保存型の場合、悪意のあるコードがサーバーに保存された後に被害が発生する。

この問題は、セキュリティ企業のTrail of BitsとOpenAIの協力によって報告された。管理画面のコメント一覧は多くの管理者が日常的にアクセスするページであり、発見が遅れれば広範囲のサイトに影響が及ぶ可能性があった。

WXRエクスポート機能の2次SQLインジェクション

WXR(WordPress Extended RSS)エクスポート機能に2次SQLインジェクションの脆弱性が見つかった。WXRエクスポートとは、WordPressの投稿や固定ページをXML形式で書き出す機能だ。2次SQLインジェクションとは、悪意のあるデータが一度データベースに保存された後、別の処理でクエリとして使用される際に攻撃が成立するタイプの脆弱性を指す。

この問題はAnthropicによって報告された。サイトの移行やバックアップ目的で頻繁に利用されるエクスポート機能に脆弱性があったため、影響範囲は広い。

その他5件の脆弱性修正

  • HTTP通信処理の絶対URL生成メソッドにDoS(サービス拒否)脆弱性が存在した。Anthropicが報告した
  • 投稿者権限のユーザーが固定投稿を設定できる権限の不備が存在した。Anthropicが報告した
  • 未公開記事や非公開記事のコメントが認証なしで閲覧できる問題が見つかった。PatchstackのAnanda Dhakal氏が報告した
  • Imgur埋め込み機能にXSS脆弱性が存在した。複数の研究者が共同で報告した
  • ステータスとタイプを組み合わせたフックにパラメータ検証の不備があり、アクション名の衝突を引き起こす可能性があった。WordPressセキュリティチームのAlex Concha氏が報告した

報告元にAnthropicとOpenAIが複数含まれている点が今回の特徴だ。AI関連企業がWebアプリケーションのセキュリティ監査に積極的に関わるようになってきた流れを反映している。

更新前のサイト(脆弱な状態)
保存型XSS 承認待ちコメント経由で管理者を狙う
SQLインジェクション WXRエクスポートが攻撃対象
権限の不備 投稿者権限で固定投稿を設定可能
情報漏えい 未公開記事のコメントが閲覧可能
リスク 7件の脆弱性が悪用可能な状態
↓
更新後のサイト(対策済み)
XSS対策済み コメント管理画面が安全に
SQL対策済み WXRエクスポートが保護される
権限制御修正 投稿者権限の範囲が適正化される
アクセス制御修正 未公開コメントが適切に保護される
効果 7件の脆弱性がすべて修正済み
■ 更新前は脆弱性が残る ■ 更新後は対策済み

このデモは、7.1.3適用前後でサイトの脆弱性状態がどのように変化するかを示している。セキュリティリリースの適用により各脆弱性が解消される。

今回の脆弱性報告には、セキュリティ専門企業だけでなくAI関連企業の関与が目立つ。Anthropicは3件、OpenAIはTrail of Bitsとの協力で1件を報告している。AI技術を活用したコード解析やセキュリティ監査の精度が向上していることを示す事例と言える。

更新手順と確認事項

更新手順と確認事項

セキュリティリリースの適用は優先度が高いタスクだ。更新にはいくつかの方法があるが、いずれの場合も事前のバックアップが推奨される。更新後に問題が発生した場合にロールバックできる体制を整えておくことが重要である。

ダッシュボードから即時更新

最も簡単な方法は、WordPress管理画面からの更新だ。ダッシュボードにアクセスし「更新」セクションを開くと、WordPress 7.1.3への更新通知が表示される。「今すぐ更新」ボタンをクリックすると自動的に更新プロセスが実行される。自動バックグラウンド更新が有効なサイトでは、すでに更新が自動適用されている場合が多い。

手動で更新する場合は、WordPress.orgからzipファイルをダウンロードしてサーバーにアップロードする方法もある。FTPクライアントやホスティングサービスのファイルマネージャーを使って更新できる。ただし手動更新はファイルの上書きミスなどのリスクがあるため、ダッシュボードからの更新が推奨される。

更新前のバックアップと更新後の確認

更新前には必ずバックアップを取得すること。データベースとファイルの両方をカバーするバックアッププラグインを使うか、ホスティングサービスのバックアップ機能を利用する。更新後に問題が発生した場合、バックアップから復元することで被害を最小限に抑えられる。

更新後は、サイトのフロントエンドと管理画面の両方が正常に動作することを確認する。フォームの送信、コメント機能、固定投稿の表示などを重点的にチェックするとよい。キャッシュプラグインを使っている場合は、キャッシュをクリアしてから動作確認を行うことが重要だ。

STEP 1 サイトのバックアップを取得する
↓
STEP 2 ダッシュボードの「更新」画面を開く
↓
STEP 3 「今すぐ更新」をクリックする
↓
STEP 4 更新後の動作確認とキャッシュクリアを行う
■ STEP 1 準備 ■ STEP 2 確認 ■ STEP 3 実行 ■ STEP 4 検証

このデモは、WordPress 7.1.3への更新手順を4つのステップで示している。バックアップ、更新画面、更新実行、動作確認の順に進める。

バックポートとコミュニティの対応

バックポートとコミュニティの対応

セキュリティ修正は、サポート対象の全ブランチにバックポートされる。現在のサポート対象は最新版から4.7までだ。バックポートとは、最新版で見つかった脆弱性の修正パッチを旧バージョンにも適用する作業を指す。WordPressは多くのバージョンが並行して使用されているため、この措置が重要になる。

旧バージョンへのバックポート

バックポートは準備が整い次第、順次提供される。すべての旧バージョンに同時に提供されるわけではないため、旧バージョンを使用している場合は、各ブランチの更新通知を定期的に確認することが推奨される。ただし、WordPressは最新版のみが積極的にサポートされる方針だ。セキュリティリスクを低減するためには、可能な限り最新版へのアップグレードが望ましい。

リリースを支えた貢献者たち

WordPress 7.1.3のリリースには34名のコントリビューターが参加した。リリースリードを務めたJake Spurlock氏を中心に、コアコミッターやセキュリティチームのメンバーが非同期で調整しながら、安定版リリースの提供にこぎつけた。WordPressの開発体制はオープンソースコミュニティの典型的なモデルであり、世界中の開発者が自主的に参加している。

セキュリティ修正の報告者には、Trail of Bitsのような専門企業に加えて、AnthropicやOpenAIといったAI関連企業が含まれている点が注目される。AI技術を活用したコード解析や脆弱性スキャンが、オープンソースソフトウェアのセキュリティ品質向上に貢献する事例が増えている。

この記事のポイント

  • WordPress 7.1.3はセキュリティ修正7件とバグ修正4件を含む緊急リリースである
  • コメント管理画面の保存型XSSは承認待ちコメント経由で悪用できるため特に危険だ
  • WXRエクスポートの2次SQLインジェクションや投稿者権限の不備も修正された
  • 更新はダッシュボードから数クリックで完了する。自動更新が有効なら適用済みの可能性が高い
  • 更新前のバックアップと更新後の動作確認が安全なサイト運営の基本である
サイト改修の見積もり依頼で費用が変わる条件と、伝えるべき3つのこと

サイト改修の見積もり依頼で費用が変わる条件と、伝えるべき3つのこと

サイト改修の見積もり依頼で、費用が変わるのはページ数と、どこまで手を入れるかだ。

標準的なWordPressサイトを作り直す範囲なら基本の作業で収まるが、特殊な設定が残っていると作業量が増える。

私たちのサイト改修は、トップから下層まで全体をそろえ、スマホ表示と更新のしやすさまで整える。

見積もりと相談は無料だ。

サイト改修の見積もり依頼で、費用が変わる5つの条件

サイト改修の見積もり依頼で、費用が変わる5つの条件

見積もりの金額を左右するのは、ページ数と、特殊な設定が残っているかどうかだ。

標準的なWordPressサイトを作り直す範囲なら、基本の作業で収まる。

そこから外れる条件があると、調査と移行の作業が増えて金額に反映される。

ページ数が数百規模に及ぶ場合

標準的な構成のサイトは、ページの流れとデザインが一定で、移行の手順も揃う。

ページ数が数百規模に及ぶと、1つずつのレイアウトと並びを確認する作業が増え、見積もりは作業量に応じて追加になる。

特殊なプラグインや独自に開発された機能がある場合

古いサイトに特殊なプラグインや独自の機能が残っていると、動く範囲を調べ、移行の方法を個別に確かめる手間が加わる。

見極めには調査が必要で、その分が費用に反映される。

CDNやサーバー環境が一般的でない場合

CDNが設定されているサイトや、サーバーの構成が一般的でないサイトは、全ページの配信先と動きを確認する工程が増える。

移行前の調査と移行後の確認の両方で、作業量が上乗せになる。

WooCommerceを新しく入れる場合

ネットショップの機能を新しく入れるときは、商品の管理画面だけでなく、カートや決済、注文管理の設定まで加わる。

改修の範囲にショップの構築が乗るため、その作業量が見積もりに反映される。

条件作業量が増える理由
ページ数が数百規模全ページのレイアウトと並びの確認が増える
特殊なプラグインや独自機能動く範囲と移行方法の個別調査が加わる
CDNの設定がある全ページの配信先とキャッシュの確認が増える
サーバー構成が一般的でない環境調査と移行の手順が増える
WooCommerceを新しく入れるカートと決済と注文管理の設定が加わる

見積もり依頼の前に伝えると、金額が早く決まる3つのこと

見積もり依頼の前に伝えると、金額が早く決まる3つのこと

見積もり依頼で最初に伝えてほしいのは、いまのサイトのURLだ。

そこにおおよそのページ数と、どこを変えたいかを添えてもらえれば、手を入れる範囲が見えてくる。

いまのサイトのURL

サイトのURLが分かれば、古いテーマの状態や構成を先に確認できる。

手を入れるべき所と、そのままでよい所を分けて伝えるための材料になる。

おおよそのページ数と変えたいところ

ページ数は、全ページを確認する作業量に直結する。

変えたいところを「見た目を新しくしたい」「スマホでの表示を直したい」のように伝えてもらえれば、見積もりの範囲を絞れる。

雰囲気を寄せたい参考サイトがあればURL

参考サイトのURLがあれば、デザインの方向性を言葉で説明する手間が減る。

いまのサイトの文章と画像を引き継ぎながら、その雰囲気に寄せて作る。

私たちのサイト改修でやること、やらないこと

私たちのサイト改修でやること、やらないこと

私たちの改修は、トップページだけでなく下層ページまで含めて全体の見た目をそろえる。

見た目を新しくするだけではなく、更新のしやすさと問い合わせまでの導線を先に設計する。

トップから下層まで1つのデザインにそろえる

使うテーマを入れ替え、サイトに合わせて最適化する。

トップページと主な下層ページの構成を組み直し、ページ同士の行き来の仕方まで考え直す。

どのページを開いても同じ印象で見てもらえる。

スマホ表示とフォーム送信の確認まで済ませる

スマートフォンとタブレットでも崩れずに読める表示にする。

お問い合わせフォームは設置し直し、実際に送って届くことを確かめる。

訪問者が迷わずに進める導線と並び方に整える。

編集画面を整えて、あなた自身で更新できる状態で渡す

入っているプラグインを整理し、必要なものは別のものへ入れ替える。

内部SEOの基本的な設定も行う。

編集画面を使いやすく整え、お知らせやブログをあなた自身で追加できる状態で渡し、操作の説明も付ける。

全部を作り変える前提の提案はしない。

いまのサイトを拝見して、手を入れるべき所とそのままでよい所を分けて伝える。

いまの文章と画像を引き継ぐので、原稿を一から用意し直さなくてよい。

トップページだけの改修と、丸ごと改修の違い

トップページだけの改修と、丸ごと改修の違い

トップページだけを綺麗にしても、下層ページとの見た目がちぐはぐになる。

私たちは下層ページまで含めて全体をそろえ、ページ同士の行き来まで組み直す。

項目トップページだけの改修私たちの丸ごと改修
対象範囲トップページのみトップから下層まで全ページ
デザインの統一下層と食い違いやすい全ページで同じ印象にそろえる
スマホ表示下層は崩れたまま残る全ページで崩れずに読める
更新のしやすさ変わらない編集画面を整えて自分で更新できる
問い合わせ導線変わらないフォームの確認と導線の整理まで行う

サイト改修の見積もりを依頼すると、どう進むか

サイト改修の見積もりを依頼すると、どう進むか

まずは、いまのサイトのURLを送ってほしい。

手を入れるべき所と、そのままでよい所を分けてお伝えする。

どこまで変えるべきか決めきれていない段階でも相談できる。

おおよそのページ数と、どこを変えたいかを添えてもらえれば、見積もりの範囲が早く固まる。

参考サイトがあれば、そのURLも役に立つ。

相談と見積もりは無料だ。

胸を張って案内できるサイトが手に入り、名刺代わりに見せられる。

サイトから入る問い合わせが増え、紹介に頼らなくても仕事が回っている状態を、改修の設計から一緒に作っていく。

依頼はWordPressサイトの丸ごとリニューアルのご相談ページから。

WordPressサイトの丸ごとリニューアル古くなったWordPressのサイトを、トップも下層もまとめて作り直し、スマホ表示と内部SEOまで整えるサービスの詳細を見る

よくある質問

サイトを拝見するのに費用はかかるか

かからない。

見積もりと相談は無料だ。

原稿を一から用意し直す必要はあるか

いまの文章と画像を引き継いで新しいテーマへ移す。

原稿を新しく用意する必要はない。

スマホで崩れている表示は全ページ直るのか

スマートフォンとタブレットでも崩れずに読める表示にする。

トップページだけでなく、下層ページまで含めて整える。

更新を自分で回せるようになるのか

編集画面を使いやすく整え、お知らせやブログをあなた自身で追加できる状態で渡す。

操作の説明も付ける。

有料テーマを使う場合のテーマ代はどうなるのか

有料テーマを使う場合のテーマ代は依頼側の負担になる。

無料テーマでも作れる。

この記事のポイント

  • サイト改修の見積もりは、ページ数と特殊な設定の有無で費用が変わる
  • 見積もり依頼では、サイトのURLとページ数、変えたいところを伝える
  • 私たちの改修はトップから下層まで全体をそろえ、スマホ表示と更新のしやすさまで整える
  • トップだけの改修と違い、下層ページまで含めて見た目と導線を統一する
  • 見積もりと相談は無料だ
WordPressサイトの丸ごとリニューアル古くなったWordPressのサイトを、トップも下層もまとめて作り直し、スマホ表示と内部SEOまで整えるサービスの詳細を見る
WooCommerce高速化を外注する費用は95,000円、作業の中身を公開

WooCommerce高速化を外注する費用は95,000円、作業の中身を公開

WooCommerce高速化を外注する費用は、一式95,000円(税込)だ。

月額費用はかからず、現状分析からキャッシュ調整、画像最適化、CDN設定までをこの金額でまとめて施工する。

サーバーを乗り換えず、今の環境のまま表示を速くする。

申し込み前の診断は無料で、サイトURLを伝えればどれくらい速くなるかを先に確認できる。

広告費をかけて集めた見込み客が、表示を待つ間に戻るボタンを押している。

その離脱を止めることが、この費用の役割だ。

WooCommerce高速化を外注する費用は一式95,000円(税込)

WooCommerce高速化を外注する費用は一式95,000円(税込)

WooCommerce高速化の外注費用は、一式95,000円(税込)だ。

この金額で、サイトが遅い原因の特定からキャッシュの設計、画像の軽量化、CDNの設定までをまとめて行う。

一月ごとの請求や、作業が増えるたびに追加でかかる費用はない。

施工前の診断も無料で受けられるので、まず予算を確認したいあなたにとって、金額は分かりやすいと思う。

なぜ一式で金額が決まるのか

サイトごとにページ数や商品数、使っているテーマは違う。

だが、私たちの高速化サービスでは料金を一式95,000円(税込)にしている。

見積もりのたびに金額が上下しないので、発注前に予算を確定できる。

無料診断で効果の見通しが立つ

申し込み前の診断は無料だ。

サイトURLを伝えれば、私たちがページの読み込み速度を測り、どこが遅い原因になっているかを調べる。

診断の段階で費用は発生しない。

95,000円に含まれる作業と含まれない作業

95,000円に含まれる作業と含まれない作業

95,000円(税込)に含まれる作業は六つある。

最初から一式にしているので、高速化に必要なことを個別に判断して追加を検討する必要はない。

含まれる作業

作業内容
現状分析サイトが遅い真の原因を突き止める
独自開発プラグインの実装キャッシュを生成し切れを検知して自動で再構築する
W3 Total CacheとRedisの調整数百の設定項目をサーバー環境に合わせてフル調整する
画像とアセットの最適化画質を落とさずにWebPへ変換し不要なCSSとJavaScriptを断捨離する
CDN設定Cloudflare等のCDNを適切に設定し負荷を分散させる
施工前のバックアップ万が一の際も復元できる状態で作業する

含まれない作業

95,000円には、販売促進やマーケティングに関する作業は含まれない。

商品の売り文句を作る、広告運用の設定を変える、SEOのキーワードを調査する、といった作業はこの費用の対象外だ。

高速化に必要な作業だけを行い、それ以外はあなたのチームで進めてほしい。

外注する前に無料診断で分かること

外注する前に無料診断で分かること

WooCommerce高速化の外注を検討しているなら、まず無料診断を利用してほしい。

診断では、サイトのいまの表示速度を測り、どれくらい速くなる可能性があるかを私たちが確認する。

診断は義務ではない。

見積もりを取る前に「自分のサイトは本当に速くなるのか」を確認できる。

診断の結果を見てから、施工を依頼するかどうかを決めてよい。

診断で伝えること

診断を受けるときは、サイトのURLを伝えるだけでよい。

WooCommerceのサイトであれば、管理画面へのアクセスは最初の診断では不要だ。

私たちはURLを見て、読み込みに時間がかかっている場所を調べる。

診断の結果で分かること

診断では、ページの読み込みを待たせている原因がどこにあるかを特定する。

画像が重いのか、キャッシュの設定が合っていないのか、CDNが効いていないのか。

原因が分かれば、95,000円の施工でどのくらい状況が変わるかの見通しも立つ。

無料の高速化プラグインと外注は、ここが違う

無料の高速化プラグインと外注は、ここが違う

無料の高速化プラグインを入れて失敗した人は少なくない。

画面が真っ白になったり、スマホの表示が崩れてボタンが押せなくなったりする。

そのたびにプラグインを外して、設定を見直す作業が発生する。

私たちの外注は、この無料プラグインの失敗パターンから逆算して設計している。

設定項目が少ない簡易プラグインを使わず、W3 Total Cacheの数百の設定項目をサーバー環境に合わせて調整する。

無料プラグインで起きる失敗

  • 画面が真っ白になったり、スマホの表示が崩れてボタンが押せなくなる
  • キャッシュの設定を誤り、カゴに入れられない、決済画面に進めないという致命的な不具合が出る
  • キャッシュが切れた直後に来た最初のお客様だけが低速表示になり、機会を失う

外注が変えること

外注では、キャッシュをしてよい場所と、いけない場所を最初から見極めて設定する。

カート、決済、マイページはキャッシュから厳密に除外するので、個人情報をキャッシュしない。

トップページや商品一覧など、誰が見ても同じ内容の場所は、ログイン中でもキャッシュを効かせる。

無料プラグインだと更新のたびに低速へ戻る。

私たちの施工では、独自開発プラグインが失われたキャッシュを即座に再生成する。

スコアを出すことをゴールにせず、売上と体感速度をゴールに置いている。

サーバーを乗り換えずに高速化できる理由

サーバーを乗り換えずに高速化できる理由

WooCommerce高速化というと、サーバーをグレードアップするか、高スペックのレンタルサーバーへ引っ越すことを思い浮かべるかもしれない。

私たちの施工では、サーバーを乗り換えずに今の環境のまま高速化する。

表示速度の遅さは、サーバーの性能だけが原因ではない。

キャッシュの設定、画像の形式、CDNの有無、CSSやJavaScriptの重さが、サーバー本体よりも足を引っ張っていることが多い。

独自開発プラグインの役割

私たちは独自開発プラグインを常駐させる。

記事や商品を更新した瞬間にキャッシュを生成し、切れを検知して自動で再構築する仕組みだ。

キャッシュが切れた直後に来たお客様が低速表示に巻き込まれ、一日に何人も逃げていく機会損失をなくす。

アップデートしても高速化が崩れない

コアファイルを直接書き換えないので、WordPressやプラグインを更新しても高速化の仕組みが維持される。

運用中に気を遣わなくて済む。

商品数が増えたり、将来の機能を追加したりしても、負荷が増えることを前提に設計している。

ログイン中のお得意様にだけ遅いサイトを見せている状態は、キャッシュ設計の見直しで解消できる。

購入済みの顧客が商品選びで快適にページを回れるようになる。

依頼するとどう進むか

依頼するとどう進むか

私たちのWordPress・WooCommerce高速化サービスは、サーバーを乗り換えずに、今の環境のまま表示速度を上げる。

カートと決済を守るために、キャッシュしてよい場所と、いけない場所を手動で切り分ける。

料金は一式95,000円(税込)だ。

まずはサイトURLを拝見して、どれくらい速くなるかを無料で診断する。

診断の結果を見てから、施工を依頼するかどうかを決めてよい。

待たされて逃げていた客がそのまま買っていき、広告費は増やさないまま売上だけが伸びる。

表示の遅さに悩まされてきた日々が終わり、サイトの運営に集中できるようになる。

WordPress・WooCommerce高速化サービスの無料診断を申し込む

WordPress・WooCommerce 高速化サービス今のサーバーのまま、WooCommerceサイトを高速化して表示待ちによる離脱を止める施工サービスサービスの詳細を見る

よくある質問

95,000円以外に追加費用はかかるか

かからない。

料金は一式95,000円(税込)で、現状分析からCDN設定までを含む。

月額費用も発生しない。

販売促進やマーケティングの作業を追加で頼む場合は別途になるが、高速化の施工だけであれば追加費用はない。

サーバーを乗り換えなくても本当に速くなるのか

速くなる。

遅さの原因の多くはサーバーの性能ではなく、キャッシュの設計と画像の最適化にある。

私たちは今のサーバーのまま、キャッシュを生成する仕組みとCDNの設定を変える。

サーバーを替えずに体感速度を上げる。

無料診断は何を伝えれば受けられるか

サイトのURLを伝えるだけでよい。

私たちが読み込み時間を測り、遅い原因がどこにあるかを確認する。

管理画面へのログイン情報は診断の段階では不要だ。

カートや決済が壊れる心配はないか

カート、決済、マイページはキャッシュから厳密に除外する。

トップページや商品一覧など、誰が見ても同じ内容の場所だけをキャッシュする。

個人情報をキャッシュしない設計なので、安全に高速化できる。

施工前にはバックアップも取得する。

WordPressやプラグインを更新したら高速化は崩れるか

崩れない。

コアファイルを直接書き換えずに施工するので、アップデート後も高速化の仕組みが維持される。

独自開発プラグインがキャッシュの切れを検知して自動で再構築する。

この記事のポイント

  • WooCommerce高速化を外注する費用は一式95,000円(税込)だ
  • 現状分析、独自開発プラグインの実装、W3 Total CacheとRedisの調整、画像最適化、CDN設定、バックアップが含まれる
  • 申し込み前の無料診断で、どれくらい速くなるかを確認できる
  • サーバーを乗り換えず、今の環境のまま高速化する
  • カートと決済を守りながら、ログイン中のお得意様にも高速表示を届ける
WordPress・WooCommerce 高速化サービス今のサーバーのまま、WooCommerceサイトを高速化して表示待ちによる離脱を止める施工サービスサービスの詳細を見る
WooCommerce Dual APIが専用プラグインに移行、コアから削除へ

WooCommerce Dual APIが専用プラグインに移行、コアから削除へ

WooCommerce 11.2で、実験的なDual APIエンジンがコアから削除され、専用プラグインとして提供される。10.9から11.1まで利用できた検証用の商品・クーポンAPIも廃止されるため、使っていた開発者は対応が必要だ。

Dual APIとはPHPクラスからGraphQLエンドポイントを自動生成するコードファーストな仕組みで、WooCommerce 10.9で実験機能として導入された。今回の変更は、開発の自由度を高めるための構成変更である。

WooCommerce 11.2でDual APIの提供形態が変わる

WooCommerce 11.2でDual APIの提供形態が変わる

WooCommerce 10.9で導入されたDual APIは、PHPクラスを定義するだけでGraphQLエンドポイントを生成できる実験的な拡張機能だった。これまではWooCommerce本体に組み込まれ、フィーチャーフラグで有効化する方式だった。

WooCommerce 11.2では、このDual APIエンジンがWooCommerceコアから削除される。代わりに、WooCommerce Dual APIプラグインとして独立したリポジトリで提供される形だ。

WooCommerce 10.9〜11.1(Before)
WooCommerceコア にDual APIエンジンを内蔵
開発者 はフィーチャーフラグで有効化
商品・クーポンの検証用APIも利用可能
↓
WooCommerce 11.2以降(After)
専用プラグイン として独立提供
開発者 はプラグインをインストールして有効化
検証用APIは削除される

この変更により、WooCommerce本体のリリースサイクルに縛られず、Dual APIだけを柔軟にアップデートできるようになる。Dual APIエンジン自体は、独自のAPIを開発したいエクステンション開発者にとって引き続き有用だ。

検証用の商品・クーポンAPIは削除される

WooCommerce 10.9から11.1まで、商品とクーポンに関する検証用APIが組み込みで提供されていた。このAPIはWooCommerce 11.2で削除される。

この検証用APIを使っていた開発者は、利用を停止するか、自前のエクステンションで同等のAPIを構築する必要がある。注意点として、Dual APIプラグインをインストールしても、この検証用エンドポイントが復活することはない。

Dual API移行で開発者が知るべき変更点

Dual API移行で開発者が知るべき変更点

独自のDual APIを開発しているエクステンション開発者には、いくつか重要な変更がある。フィーチャーフラグの廃止、APIビルダースクリプトの移設、ドキュメントの場所変更、そして依存関係の宣言方法だ。

プラグイン依存関係をヘッダーに宣言する

これまでDual APIエンジンを有効化していたフィーチャーフラグは利用できなくなる。代わりに、Dual APIプラグインをインストールして有効化することでエンジンが使えるようになる。プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上だ。

エクステンションがDual APIエンジンに依存する場合、プラグインのヘッダーで両方の依存関係を宣言する必要がある。具体的には以下のように記述する。

Requires Plugins: woocommerce, woocommerce-dual-api

この記述により、エクステンションのインストール時にWooCommerce本体とDual APIプラグインの両方が必要であることが明示される。依存関係の宣言は、プラグインの動作に必要な前提条件をユーザーに伝える重要な役割を果たす。

APIビルダーとドキュメントの場所が変わる

APIビルダースクリプトは、WooCommerce Dual APIプラグインのリポジトリに移動した。利用するには、プラグインをインストールするか、リポジトリをローカルにクローンする。

ドキュメントもDual APIプラグインのリポジトリ内に移設された。GitHub Pagesでも閲覧できる形で提供されている。開発者は最新のドキュメントをプラグインリポジトリで確認することになる。

STEP 1 Dual APIプラグインをインストールして有効化
↓
STEP 2 エクステンションのヘッダーに依存関係を宣言
↓
STEP 3 エクステンション内でGraphQLエンドポイントを登録
↓
STEP 4 独自のGraphQL APIとして利用可能

エンドポイント登録のコード例

Dual APIプラグインはエンジンを提供し、エクステンション側で独自のGraphQLエンドポイントを登録する。WooCommerceのシンプルイベントサンプルプラグインから、登録方法のコードを示す。

use Automattic\WooCommerce\Api\Infrastructure\Main as DualApiMain;

add_action(
	'plugins_loaded',
	static function () {
		if ( method_exists( DualApiMain::class, 'register_graphql_endpoint' ) ) {
			DualApiMain::register_graphql_endpoint(
				__DIR__,
				'wc',
				'/graphql/simple-events'
			);
		}
	}
);

このコードは、プラグインの読み込み時にDual APIエンジンが利用可能か確認し、利用可能であればGraphQLエンドポイントを登録する。エンドポイントのパスや名前空間はエクステンションごとに自由に設定できる。

Dual APIは引き続き実験的ステータス

Dual APIは引き続き実験的ステータス

Dual APIはプラグインに移行した後も、実験的なステータスは変わらない。Automattic\WooCommerce\Api名前空間以下のすべての要素は、後方互換性のない形で変更される可能性がある。

つまり、将来のリリースでAPIの構造が変わったり、削除されたりする可能性があるということだ。このため、本番環境のエクステンションでDual APIを使用することは推奨されていない。開発用途や検証目的に限定して使うべきだろう。

⚠️ 実験的ステータスの意味
Dual APIは 後方互換性のない変更 が発生し得る
実験的機能 は将来のリリースで削除される可能性もある
本番環境での利用は推奨されない

開発者コミュニティへのフィードバック募集

開発者コミュニティへのフィードバック募集

WooCommerceチームは、Dual APIエンジンが実際に有用かどうか、非実験的な状態でWooCommerce本体に含めるべきか、改善点はないかについて、開発者からの意見を求めている。

フィードバックはGitHubの専用ディスカッションページで受け付けている。Dual APIを試した開発者は、実際の使用感や要望を共有することで、今後の方向性に影響を与えることができる。

この記事のポイント

  • WooCommerce 11.2でDual APIエンジンがコアから削除され、専用プラグインとして独立した
  • 10.9〜11.1の検証用商品・クーポンAPIは削除されるため、利用者は移行が必要
  • プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上
  • 依存関係はプラグインヘッダーで宣言する
  • 引き続き実験的ステータスであり、本番利用は推奨されない
WordPress 7.1.1セキュリティリリース公開。11件の脆弱性修正と即時更新のすすめ

WordPress 7.1.1セキュリティリリース公開。11件の脆弱性修正と即時更新のすすめ

WordPress 7.1.1が2026年9月17日に公開された。セキュリティリリースと位置づけられ、11件の脆弱性修正を含む。コアのバグ修正は17件、ブロックエディタのバグ修正は19件だ。

今回のリリースはセキュリティ修正を主目的としている。すべてのサイト管理者に即時更新が推奨される。自動更新が有効なサイトでは、すでに適用が始まっている場合もある。

セキュリティリリースの最大の特徴は、放置した場合のリスクが高いことだ。XSS(クロスサイトスクリプティング)やパストラバーサルなど、攻撃者に悪用されかねない脆弱性が多数修正されている。サイトを守るには更新が最優先となる。

WordPress 7.1.1リリースの概要

WordPress 7.1.1リリースの概要

WordPress 7.1.1は「ショートサイクルリリース」と呼ばれる短い間隔で提供される更新だ。メジャーリリースの7.1から間もない段階で、セキュリティと安定性の向上を目的に公開された。次のメジャーリリースは7.2で、12月を予定している。

今回の修正内容は、コア17件、ブロックエディタ19件、セキュリティ11件の合計47件にのぼる。セキュリティ修正が全体の約4分の1を占めており、いかにセキュリティ面が重視されたリリースかがわかる。

セキュリティリリースの最大の特徴は、対応の緊急性だ。通常の更新と異なり、脆弱性がすでに公開されている可能性があるため、更新を先延ばしにすると攻撃の標的になりやすい。公式発表でも「直ちに更新すること」が明記されている。

STEP 1 WordPress管理画面にログイン
↓
STEP 2 ダッシュボードの「更新」をクリック
↓
STEP 3 「今すぐ更新」をクリック
↓
STEP 4 更新完了のメッセージを確認

更新は管理画面から4ステップで完了する。自動更新が有効な環境では、手動操作なしで適用される。

修正されたセキュリティ脆弱性の詳細

修正されたセキュリティ脆弱性の詳細

11件のセキュリティ修正は、XSS、パストラバーサル、権限チェックの欠落、情報漏洩の4つに大別できる。それぞれ攻撃の仕組みや影響範囲が異なるため、サイト運営者は全体像を把握しておくとよい。

XSS(クロスサイトスクリプティング) 悪意のあるスクリプトを埋め込む攻撃
パストラバーサル アクセスできないファイルへの到達
権限チェックの欠落 不正なユーザーによる操作
情報漏洩 プライベートな情報の露出

11件のセキュリティ修正を種類ごとに分類すると、XSS、パストラバーサル、権限チェック欠落、情報漏洩の4つに大別される。それぞれの詳細を確認していく。

XSS関連の重大修正

XSS(クロスサイトスクリプティング)とは、悪意のあるスクリプトをWebページに埋め込む攻撃手法を指す。閲覧者がそのページを開くとスクリプトが実行され、クッキーの窃取やセッションハイジャックなどの被害につながる。

今回修正された中でも特に注意が必要なのが、wpautop()関数の格納型XSSだ。コメントを処理する際に悪意のあるスクリプトが保存され、コメントが承認されると訪問者のブラウザ上で実行される可能性があった。報告者はAwesome MotiveのRafie Muhammad氏だ。

カスタムヘッダーをサポートする一部テーマでも、同様の格納型XSSが確認された。テーマの機能を利用してスクリプトが保存され、後から閲覧したユーザーに影響が及ぶ構造だった。こちらはWordPressセキュリティチームのJeremy Felt氏が報告した。

修正前のwpautop関数(Before)
コメントに<script>悪意のあるコード</script>が保存される
閲覧者がコメントを開くとスクリプトが実行されてしまう
↓
修正後のwpautop関数(After)
コメントに<script>悪意のあるコード</script>が保存される
スクリプトタグが無害なテキストとして扱われる

wpautop()のXSS脆弱性が修正された。コメント内に埋め込まれたスクリプトが、実行可能なコードではなく単なる文字列として扱われるようになる。

権限・アクセス制御の修正

2件目はHTML APIのset_modifiable_text()関数で見つかった。突然閉じるシーケンスを使うことで、コメントの範囲を脱出できるという問題だ。WordPressセキュリティチームのJeremy Felt氏が報告した。

3件目は、特別に細工されたURLで非アクティブなテーマを自動的にインストールし、プレビューできる問題。攻撃者が意図しないテーマを読み込ませる可能性があった。Paulos Yibelo氏とpwn.aiの報告だ。

権限チェックの欠落も深刻だ。サイト管理者がネットワーク専用プラグインをネットワーク有効化できる問題、寄稿者(Contributor)以上の権限を持つユーザーが任意の投稿を上書きできる問題、WP REST Templates Controllerでの認証済みパストラバーサルなどが修正された。

パストラバーサルとは、ファイルパスを操作して本来アクセスできないファイルやディレクトリにアクセスする攻撃を指す。WP REST Templates Controllerの脆弱性では、認証済みユーザーがサーバー上のファイルに不正アクセスできる可能性があった。Anthropicの報告によるものだ。

寄稿者(Contributor)はWordPressのユーザー役割の一つで、投稿の作成はできるが公開はできない。この役割以上のユーザーによる不正な投稿上書きや、下書き・保留中投稿のスラッグ開示なども今回修正された。

XML-RPC経由の脆弱性も見逃せない。customize_changeset投稿を公開することでedit_cssのチェックを迂回できる問題が、WordPressセキュリティチームのBen Bidner氏によって報告された。XML-RPCはWordPressの外部アプリからの操作を受け付けるAPIで、これを悪用した攻撃が可能だった。

情報漏洩を防ぐ修正

attachment_submitbox_metadata()関数にread_postチェックが欠落しており、プライベートな親投稿のタイトルが漏れる問題が修正された。HDWSecの報告によるものだ。メディアライブラリの添付ファイル表示画面で、本来なら見えないはずの親投稿タイトルが露出する可能性があった。

コメントが認証済みユーザーなら誰でも再親付けできる問題も修正された。コメントの親子関係を任意に変更できることで、スレッド構造が破壊されたり、悪意のある内容が目立つ位置に表示されたりする可能性があった。Justin Hart氏とViridis Securityの報告だ。

コアとブロックエディタのバグ修正

コアとブロックエディタのバグ修正

セキュリティ修正以外にも、コア17件とブロックエディタ19件のバグ修正が含まれる。コアの修正はTracというバグ追跡システムで管理され、ブロックエディタの修正はGitHub上のGutenbergリポジトリで進められた。

ブロックエディタの19件の修正は、GitHubのPull Request #82383にまとめられている。エディタの安定性や操作性を向上させる修正が中心で、サイト制作に携わるユーザーにとっては作業効率の改善につながる。

メンテナンスリリースの目的は、新機能の追加ではなく既存機能の安定化だ。7.1系で発生していたバグが解消され、より快適な運用が可能になる。特にブロックエディタは日々のサイト更新作業に直結するため、19件の修正は実務での効果が期待できる。

更新手順と自動更新の仕組み

更新手順と自動更新の仕組み

WordPress 7.1.1への更新は、公式サイトからZIPファイルをダウンロードするか、管理画面の「更新」セクションから行う。管理画面では「更新」をクリックし、「今すぐ更新」をクリックするだけの簡単な操作で完了する。

自動バックグラウンド更新を有効にしているサイトでは、更新プロセスが自動的に開始される。共有サーバーやVPSなど、サーバー環境によって自動更新の動作は異なるが、手動更新でも数分以内に完了する。

更新前にバックアップを取得しておくのが望ましい。セキュリティリリースは即時適用が推奨されるが、万一のトラブルに備えて、データベースとwp-contentディレクトリのバックアップを取ってから更新するのが安全策だ。

更新前の確認(推奨)
データベースと wp-content のバックアップを取得する
↓
更新を適用
管理画面から 7.1.1 へ更新する
↓
更新後の確認
サイト画面と管理画面が正常に表示されるか確認する

更新前にバックアップを取り、更新後にサイト表示を確認する流れが安全だ。セキュリティリリースは緊急性が高いが、手順を守って適用する。

バックポートとサポート対象

バックポートとサポート対象

今回のセキュリティ修正は、WordPress 4.7まで遡ってバックポートされる。バックポートとは、最新版で修正された内容を古いバージョンにも適用することで、セキュリティ対策を広範囲に届ける仕組みだ。

ただし、公式にアクティブサポートされているのは最新版のWordPressのみだ。古いバージョンを使い続けるのはセキュリティリスクが高いため、できるだけ早く最新版へ移行するのが望ましい。バックポートはあくまで移行期間の猶予として機能する。

バックポートは順次進められており、準備が整い次第リリースされる。対象バージョンを使用している場合も、最新版への更新を優先して検討するのが推奨される。古いバージョンはセキュリティ面だけでなく、機能面でも取り残されるためだ。

この記事のポイント

  • WordPress 7.1.1はセキュリティリリースで、11件の脆弱性修正を含む
  • 格納型XSSやパストラバーサルなど、悪用リスクの高い問題が修正された
  • コア17件とブロックエディタ19件のバグ修正も含まれる
  • すべてのサイト管理者に即時更新が推奨される
  • バックポートは4.7まで提供されるが、最新版への移行が最優先
WordPress 7.2開発サイクル始動、Gutenberg 23.8と23.9の開発者向け新機能まとめ

WordPress 7.2開発サイクル始動、Gutenberg 23.8と23.9の開発者向け新機能まとめ

WordPress 7.1「Mary Lou」が2026年8月にリリースされた。レスポンシブスタイルステート、アイコン登録機能などが含まれる大型アップデートだ。まだ更新していない場合は早めの対応が推奨される。

続くGutenberg 23.8と23.9では開発者向けの改善が多数入っている。コードリファレンスの実行可能コード例、ブロックのキーボードショートカット宣言API、テーマJSONスキーマの修正など、実務に直結する変更が多い。

WordPress 7.2のBeta 1は2026年10月20〜22日、正式版は12月8〜10日に予定されている。本記事では2026年9月時点の開発者向け変更点を整理して解説する。

コードリファレンスがブラウザ上で実行可能に

コードリファレンスがブラウザ上で実行可能に

WordPress公式のコードリファレンスで大きな変化があった。コード例をその場で実行できるようになったのだ。WP_HTML_Processorクラスのclass_list()メソッドのページを開き、「Run」ボタンを押すと、Playgroundを使った実際のWordPress環境でコードスニペットが実行される。

従来のコードリファレンスは静的ページであり、コード例を読むだけだった。だが今回の変更で、関数の動作確認がブラウザ内で完結する。ドキュメントと関数定義が同じファイルに存在するため、コードと実行結果の乖離が起きにくい構造だ。

実装方法はDocBlocksの中に「php interactive」というコードフェンスを書くだけ。関数の説明コメント内に実行可能なコードを埋め込む仕組みで、ドキュメント提案として長く議論されてきた内容が実現した形だ。

ブロック開発の新APIと改善点

ブロック開発の新APIと改善点

キーボードショートカットを宣言的に定義可能に

Gutenberg 23.9では、ブロックのキーボードショートカットを宣言的に登録するAPIが追加された。これまで「Alt+Shift+2」で段落をHeading 2に変換する機能はハードコードされており、エディタパッケージごとに個別実装が必要だった。

新しいAPIでは、ブロックバリエーションにshortcutオブジェクトを指定するか、ブロック変換にshortcuts配列を指定する。後者の場合、1つの変換で最大6つのショートカットをまとめて定義できる。

インナーブロックテンプレートがブロック設定へ移行

Gutenberg 23.8では、templateとtemplateInsertUpdatesSelectionがブロックタイプ設定として追加された。従来のInnerBlocksコンポーネントのpropsを使う方式は非推奨となり、WordPress 7.2リリース前に移行することが推奨される。

この変更の背景にはリアルタイム共同編集の開発がある。propsベースの方式はマウント後にテンプレートを適用するため、3人の共同作業者がドキュメントを開いている場合、Listブロックを挿入すると3つのリスト項目が生成される問題があった。ブロックタイプ設定として宣言することで、ブロックとテンプレートが単一のストア操作で処理される。

kebab-case変換がJSとPHPで完全一致

WordPress Coreの_wp_to_kebab_case()は、数字の扱いに関して一般的なライブラリと異なる挙動をしていた。今回、JavaScript側でも同じ変換結果を返す@wordpress/kebab-caseパッケージが公開された。

一般的なライブラリの変換結果(Before)
kebabCase(‘white2white’) → white2white
kebabCase(‘font2xl’) → font2xl
kebabCase(‘white4th’) → white4th
※数字の前後で文字列が分割されず、出力が一貫していなかった
↓
@wordpress/kebab-caseの変換結果(After)
kebabCase(‘white2white’) → white-2-white
kebabCase(‘font2xl’) → font-2-xl
kebabCase(‘white4th’) → white-4th
※数字の前後にハイフンが入り、PHP版と同じ結果を返す

このデモで示したように、JSとPHPの間でスラッグ生成ロジックが統一された。ブロック名やCSSクラス名の変換で環境による差異がなくなる。

エディタが管理者カラースキームに対応

投稿エディタ、ウィジェットエディタ、カスタマイザーのウィジェットエディタが、アクティブな管理者カラースキームを反映するようになった。getAdminThemeColors()が@wordpress/admin-uiの公開APIとして提供され、拡張開発者も同じ仕組みを自前の管理画面に組み込める。

Data Viewsの改善と時刻フィールド追加

DataViewsパッケージからプライベートAPIの依存が排除された。これまで同パッケージをプラグインにバンドルすると「ロックされていないオブジェクトをアンロックできない」というエラーが出る問題があった。対応に伴い、CalendarやRangeCalendarなどのコンポーネントが公開APIとして移行している。

Gutenberg 23.8ではtime型のフィールドも追加された。営業時間やイベント開始時刻、予約枠など、日付を伴わない時刻データを扱う用途に向いている。値はHH:mm形式で保存されるため、訪問者のタイムゾーンに左右されない。

テーマ開発者向けの変更点まとめ

テーマ開発者向けの変更点まとめ

theme.jsonスキーマの修正

WordPress 7.1で導入されたレスポンシブスタイルステートと擬似クラスステートのスキーマが不完全だった。Gutenberg 23.8で複数の修正が入り、コードエディタでtheme.jsonを編集する際にステートが不正として表示されないようになった。

スタイルUIの制御オプション追加

blockStatesEditingEnabledとresponsiveEditingEnabledという2つのフラグが追加された。block_editor_settings_allフィルターを通じて無効化できる。クライアント向けのサイト構築で、設計済みのスタイルを崩させずに編集機能をロックダウンする用途に有効だ。

label要素とフォーム要素のスタイル対応

Gutenberg 23.9ではlabel要素がtheme.jsonのスタイル対象に追加された。styles.elements.labelで指定でき、Search、Form Input、Post Comments Form、Archives、Categoriesブロックなどでレンダリングされるlabelタグに適用される。

続けてcite、textInput、select要素もエディタのStylesインターフェースから直接編集できるようになった。エディタのTypographyパネルとColorsパネルで操作できる。

GroupブロックのblockGapが軸別指定に対応

GroupブロックのblockGapサポートが水平方向と垂直方向の両方に対応した。theme.jsonでblockGapの値として通常の文字列に加えて、topとleftのキーを持つオブジェクト形式を指定できる。エディタUI上ではflexレイアウトとgridレイアウトでのみ軸別コントロールが表示される。

そのほか、Listブロックがwideとfullの配置をサポート、Query No Resultsブロックがボーダーとスペーシングをサポート、Query Loopブロックがblock gapをサポートするようになった。Accordion Headingブロックのtheme.jsonスペーシングがトグルボタンに正しく適用される修正も入っている。

Playgroundの進化とWordPress 7.2の展望

Playgroundの進化とWordPress 7.2の展望

WordPress PlaygroundがWebMCPに対応した。これはAIエージェントが呼び出せるツールとしてブラウザ内のアクションを公開する草案APIだ。PlaygroundはWordPressをネストされたiframeで実行するため、新しいプロキシが埋め込みサイトのツールを外部ページに広告し、呼び出しを転送する仕組みになっている。

さらに、Playground上でWordPress 0.7まで遡って実行できるようになった。設定パネルで「Include older versions」にチェックを入れると、6.2までの全バージョンが選択肢に含まれる。PHPのバージョンも自動的にペアリングされるため、「いつこの機能が壊れたのか」を確認する用途に役立つ。

STEP 1 Beta 1(10月20〜22日)
最初のベータ版がリリースされ、新機能のテストが始まる
↓
STEP 2 Beta 2以降(11月)
追加のベータ版で機能の安定化とバグ修正が進む
↓
STEP 3 RC(リリース候補版)
正式版に向けた最終調整段階
↓
STEP 4 正式版(12月8〜10日)
WordPress 7.2が正式リリースされる
■ ベータ版  ■ 安定化  ■ RC  ■ 正式版

このタイムラインで示したように、WordPress 7.2の開発サイクルは約2ヶ月にわたって進行する。開発者向け機能の実装状況を確認しながら、互換性の検証を進めるのが良いだろう。

この記事のポイント

  • コードリファレンスがブラウザ上でコード実行に対応、Playgroundを使った動作確認が可能になった
  • ブロックのキーボードショートカットを宣言的に定義するAPIが追加された
  • インナーブロックテンプレートはブロックタイプ設定への移行が推奨される
  • theme.jsonのスキーマ修正とスタイルUIの制御オプションでテーマ開発が改善された
  • WordPress 7.2は12月8〜10日に正式リリース予定、Beta 1は10月20〜22日
WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5(2027年1月目標)から、最低動作環境がPHP 8.1以上になる提案が発表された。この変更が採用されると、PHP 7.4とPHP 8.0のサポートは将来のバージョンで終了する。

WooCommerceの利用データでは、PHP 7.4が追跡対象ストアの約7%、PHP 8.0が約2%を占めている。比較的新しいWooCommerceバージョンに限ると合計約6%まで下がり、減少傾向が続いている。

ストア運営者や拡張機能開発者は、移行の影響を早めに把握して準備を進める必要がある。本記事では提案の内容、影響範囲、推奨される対応をまとめた。

WooCommerce 11.5からPHP 8.1以上が最低要件に

WooCommerce 11.5からPHP 8.1以上が最低要件に
従来のWooCommerce(Before)
PHP 7.4 または PHP 8.0 で動作
WooCommerce 11.4 以前の最低要件
↓
WooCommerce 11.5以降(After)
PHP 8.1 以上が最低要件
PHP 7.4 と 8.0 のサポート終了

上の図のように、WooCommerce 11.5を境に最低PHPバージョンが引き上げられる。PHP 7.4と8.0を使うストアは、設定変更なしでは新しいバージョンへ更新できなくなる。

PHPサポート終了の現状

PHP 7.4は2022年11月に、PHP 8.0は2023年11月に公式サポートが終了している。以降はセキュリティ修正が提供されていないため、脆弱性が見つかっても修正されない状態が続く。

WooCommerceの内部データによると、追跡対象ストア全体ではPHP 7.4が約7%、PHP 8.0が約2%を占める。一方、直近1年以内にリリースされた比較的新しいWooCommerceバージョンでは合計約6%まで縮小している。

提案の具体的内容

WooCommerceエンジニアリングチームは、WooCommerce 11.5のリリースを目標に最低要件をPHP 8.1以上へ引き上げることを提案している。採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。

この変更により、WooCommerce 11.5以降はPHP 7.4と8.0向けの互換コードを削除できる。コードベースの保守性が高まり、開発スピードの向上につながると見込まれている。

PHPバージョン引き上げのメリット

PHPバージョン引き上げのメリット
最新構文 union types
match式
名前付き引数
セキュリティ EOL回避
安全な依存パッケージ
開発効率 CIテスト高速化
互換性コード削減
性能向上 PHP 8系の
ランタイム改善
■ 最新構文 ■ セキュリティ ■ 開発効率 ■ 性能向上

PHP 8.1以上への引き上げで得られる主な利点は4つ。最新構文の活用、セキュリティ向上、開発効率の改善、そしてランタイム性能の向上だ。

最新PHP機能の活用

PHP 8.1以上では、union types(複数の型を許容する宣言)、attributes(メタデータを付与する仕組み)、null-safe operator(null判定を簡潔に書く演算子)、match式、名前付き引数などが使えるようになる。WooCommerce本体だけでなくサードパーティ製の拡張機能も、これらの機能を前提に開発できる。

union typesとは、関数の引数や戻り値に「intまたはstring」のように複数の型を指定できる記法だ。これがあると、無理な型変換や冗長な分岐を減らせる。コードが読みやすくなり、バグの発生も抑えられる。

セキュリティとパフォーマンスの向上

サポート終了済みのPHPを使い続けると、既知の脆弱性が修正されないまま残る。PHP 8.1以上へ移行することで、セキュリティ修正が提供される安心な環境に切り替えられる。

さらに、WooCommerceと拡張機能が新しいPHP専用の安全な依存パッケージを採用できるようになる。旧バージョン向けの互換レイヤーを削除でき、継続的インテグレーション(CI)でテストするPHPバージョンも減るため、テストやリリースの速度も上がる。

PHP 8系へのアップグレード自体にも性能向上の効果がある。PHPランタイムの改善により、WooCommerceストアの表示速度や処理能力が底上げされる。これはコード変更なしで得られる利点だ。

PHP 7.4・8.0を使うストアへの影響

PHP 7.4・8.0を使うストアへの影響
PHP 7.4・8.0 のストア(Before)
WooCommerce 11.5 の更新が提供されない
既存バージョンのドットリリースのみ継続
↓
PHP 8.1 以上へ移行後(After)
WooCommerce 11.5 以降を更新可能
PHPアップグレード後に更新

PHP 7.4や8.0を使っていても、WooCommerceが自動でPHPを更新したり、ストアを停止させたりすることはない。ただし、WooCommerce 11.5以降への更新だけはブロックされる。

自動更新の停止と移行手順

提案が採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。WordPressの標準機能により、要件を満たさないストアにはWooCommerce 11.5の更新が表示されなくなる。

PHP 7.4または8.0を使うストアは、現在のWooCommerceバージョンをそのまま使い続けることになる。同じブランチのドットリリース(例 11.4.x)は引き続き提供される。新しいメジャーバージョンへ移るには、先にPHPを8.1以上へアップグレードする必要がある。

前例となったWooCommerce 8.2

今回の進め方は過去のWooCommerceのPHP要件変更と同様のアプローチを取っている。WooCommerce 8.2では最低要件をPHP 7.4以上へ引き上げ、事前通知と移行ガイダンスが提供された。

当時も、要件を満たさないストアは自動更新されず、既存バージョンの更新のみ継続する方式だった。今回のPHP 8.1引き上げでも同じ流れが想定されている。

WordPressと拡張機能開発者への影響

WordPressと拡張機能開発者への影響

WordPressのPHP要件との違い

WordPress本体は現在、PHP 7.4以上で動作し、PHP 8.3以上を推奨している。しかしWooCommerceは、WordPressより高いPHP要件を維持してきた経緯がある。

WooCommerceは決済処理や在庫管理、注文ワークフローなどを持つ複雑なECアプリケーションだ。独自の依存関係や性能要件があるため、最低PHPバージョンをWordPressと完全に一致させる必要はないとされている。

拡張機能開発者への推奨事項

WooCommerce向けの拡張機能を開発している場合、すでに新しいPHPバージョンでテストしていることが理想だ。今回の変更により、WooCommerce 11.5以降だけを対象にする拡張機能はPHP 8.1以上の機能を使えるようになる。

一方、古いWooCommerceバージョンを引き続きサポートする拡張機能は、互換レイヤーや別コードパスを維持する必要が出てくる。PHPバージョンが上がっても、すべての拡張機能やテーマ、カスタムスニペットがそのまま動く保証はない。

本番環境へ適用する前に、ステージングサイトでPHP 8.1以上への移行テストを行うことが重要だ。特に独自カスタマイズや古い拡張機能を使っている場合、互換性の問題が顕在化しやすい。

意見募集と今後のスケジュール

意見募集と今後のスケジュール

フィードバックの募集ポイント

WooCommerceエンジニアリングチームは、ストア運営者、代理店、ホスティングプロバイダー、拡張機能開発者などから幅広く意見を求めている。主な質問は以下の通りだ。

  • PHP 7.4や8.0から移行できない理由はあるか
  • 該当PHPバージョンを必要とする拡張機能やテーマは存在するか
  • WooCommerce 11.5(2027年1月目標)で準備期間は十分か
  • ホスティングプロバイダーはWooCommerceストアのPHP利用状況について追加データを持っているか
  • 対応が望まれる移行ガイダンスは何か

互換性の問題を報告する場合は、PHPバージョン、WooCommerceバージョン、影響を受ける拡張機能、エラーメッセージを添えることが推奨されている。

決定までのタイムライン

WooCommerceチームはフィードバックと利用データを確認した上で、対象リリースと最低PHPバージョンを最終決定する。決定後は事前告知を行い、開発者が新しい要件でテストできるよう準備期間を設ける方針だ。

現時点ではまだ提案段階であり、正式な決定ではない。ただし利用データの減少傾向やEOLの状況を踏まえると、PHP 8.1以上への引き上げは現実的な選択肢として有力だ。

この記事のポイント

  • WooCommerce 11.5(2027年1月目標)からPHP 8.1以上が最低要件になる提案が発表された
  • PHP 7.4と8.0はサポート終了済みで、利用は全体の約6〜9%まで縮小している
  • PHP 7.4・8.0のストアは自動更新されず、移行後にWooCommerce 11.5へ更新できる
  • 最新PHP機能の活用、セキュリティ向上、開発効率の改善が主な目的だ
  • 拡張機能開発者はステージング環境でPHP 8.1以上へのテストを推奨
ByTheWeb AIレビュー!無料GEOプラグインでAI検索に引用されるサイトを目指す

ByTheWeb AIレビュー!無料GEOプラグインでAI検索に引用されるサイトを目指す

ChatGPTやGeminiなどAI検索の利用が広がる中、従来型SEOだけでは不十分な局面が増えてきた。GEO(Generative Engine Optimization / 生成AI向け最適化)と呼ばれる、生成AIにサイトを理解させるための最適化が必要になっている。検索エンジン向けにメタディスクリプションやXMLサイトマップを整えても、AIが回答を組み立てる際に情報源として引用されるとは限らない。

WP Mayorの2026年9月2日付レビューをもとに、ByTheWebの料金体系、主要機能、実務での使い方、プライバシー面を整理した。

AI検索対策を低コストで始めたい中小企業や個人ブロガーが、この無料ツールをどこまで使えるかを判断するための内容だ。

ByTheWeb AIの全体像

ByTheWeb AIの全体像

ByTheWebは2つのWordPressプラグインに分かれている。無料のByTheWeb GEOがAI可読性スコアの算出、スキーマ生成、llms.txt出力、robots.txt管理という土台部分を担う。ここでllms.txtは、大規模言語モデル向けにサイト情報を整理したテキストファイルだ。任意のByTheWeb AIはクレジット制のアシスタントとして、不足するフィールドの自動補完やメタ情報の生成をクラウド処理で行う。

ByTheWebの2つのプラグイン構成
土台 WordPressサイト
記事、固定ページ、商品ページなどが格納される
↓
無料・必須ではない ByTheWeb GEO
AI可読性スコア、各種スキーマ、llms.txt、robots.txt、メタ情報の手動管理を担当
↓
任意・クレジット制 ByTheWeb AI
不足フィールドの自動生成、メタ情報最適化、FAQスキーマ生成をクラウド処理で実行
スコア改善 → llms.txt出力 → AI検索での引用されやすさ向上
■ WordPressサイト ■ GEO(無料) ■ AI(クレジット制)

重要なのは、どちらのプラグインも必須ではない点だ。ByTheWeb GEOはアカウントなしで手動機能をすべて使える。ByTheWeb AIは無料のAPIキーを接続して初めて生成機能が動く。この分離設計により、クレジット消費を伴うAI機能だけを後から追加できる。

料金とクレジットの仕組み

料金とクレジットの仕組み

ByTheWeb GEOの基本機能は無料だ。ダッシュボード、スキーマ、llms.txt、サイトマップ、robots.txt、手動フィールドはアカウント登録なしで利用できる。費用が発生するのはByTheWeb AIを接続した場合に限られる。新規アカウントには30日間有効の5,000クレジットが付与される。

試用期間後の有料プランは4段階ある。いずれも1プランで対応するドメインは1つで、未使用クレジットは翌月に繰り越されない。

  • Starter AIは月額10.95米ドルで5,000クレジットを利用できる
  • Creator AIは月額19.95米ドルで10,000クレジットを利用できる
  • Growth AIは月額29.95米ドルで20,000クレジットを利用できる
  • Pro AIは月額39.95米ドルで30,000クレジットを利用できる

クレジットの消費量はAIアクションごとに異なる。1回の操作で50クレジットで済む場合もあれば、450クレジットを消費する場合もある。利用頻度が高い場合は、月に何回のAIアクションを実行するかを事前に見積もるとよい。

プラグインとは別に、ByTheWebは無料のAI可視性およびSEOサイトスキャナーも提供している。URLを入力すると、OpenAI、Google Gemini、Perplexity、Claudeがそのビジネスをどう理解しているかを、実際のWeb検索結果と引用元付きで確認できる。接続と検証を済ませるとレポート全体が閲覧可能になり、見つかった課題をWordPressツールで修正できる。

主要機能の解説

主要機能の解説

AI向けフィールドとllms.txt

ByTheWeb GEOの中心となるのが、Short AnswerとAI Summaryという2つのAI向けフィールドだ。Short Answerは質問への直接的な一文回答であり、AI Summaryは重要事実を箇条書きにしたスキャンしやすい要約である。どちらもサイトが自動生成するllms.txtファイルに反映される。必要に応じてllms-full.txtとしてMarkdown形式の完全版も出力できる。

FAQビルダーは手動で書いた質問をJSON-LD形式のFAQスキーマへ変換する。ここでスキーマとは、ページ内容を検索エンジンやAIが機械的に理解できるよう構造化するマークアップの一種だ。JSON-LDはその構造化データを記述するフォーマットである。ショートコードまたはElementorウィジェットで訪問者にも表示できる。

そのほか、Article、Organization、Person、Local Business、Service、BreadcrumbListの各スキーマと、sameAsおよびContactPointフィールドが構造化データの側面を補う。sameAsは自社の公式プロフィールを紐付けるためのフィールドだ。

従来のSEO機能と既存プラグインとの共存

AI向け機能に加えて、ByTheWeb GEOは従来型のSEOレイヤーも備える。タイトルとメタディスクリプションの文字数インジケーター、最適化チェック、スマート変数を使った動的テンプレートの作成が可能だ。WP Mayorのレビューでは、主要なSEOプラグインにある基本機能はおおむねこちらでも揃っていると指摘されている。

ByTheWeb GEOはYoast SEOやRank Mathと併用できる。機能が重複するフィールドは重複を避けて調整される一方で、GEOスコアとスキーマ機能はそのまま有効になる。既存のSEOワークフローにByTheWebを追加しやすい設計だ。

実務での使い方とGEOスコア改善

実務での使い方とGEOスコア改善

初期設定とスキャン

ByTheWeb GEOをインストールして有効化すると、WordPress管理画面に専用メニューが追加され、バックグラウンドで初回サイトスキャンが実行される。最初にGEO設定とSEO設定の画面で、ビジネス名や所在地などの基本情報を登録するとよい。両方のプラグインを有効にした場合、Needs Attention(要対応)テーブルからページごとのGEOスコアを確認できる。スコアが低いページが上に並ぶため、改善対象を見つけやすい。

スコア改善の流れとAIアシスト

Short Answer、AI Summary、FAQを手動で追加すると、そのページのGEOスコアは上がる。これらの情報はページソースのメタタグやFAQスキーマとして出力され、llms.txtにも反映される。ByTheWeb AIを接続している場合は、不足フィールドの横にあるボタンを押すだけで自動生成できる。生成前にはページ内容、任意のトピック指定、クレジット消費量が表示される。

生成結果の編集が必要かどうかは、元のページにどれだけ情報があるかに左右される。このツールはゼロからリサーチするのではなく、ページ上の情報を素材にするためだ。既存コンテンツが充実していれば、そのまま使える精度の出力が得られやすい。

AI検索で引用されるまでの変化
従来のSEO対策のみ(Before)
タイトル最適化 メタディスクリプション XMLサイトマップ
AIはこれらの情報を直接の回答根拠として優先しない
↓
GEO対策を追加(After)
AI Summary Short Answer FAQスキーマ llms.txt
AIが回答を組み立てる際の引用元として認識されやすくなる
■ 従来型SEO要素 ■ AI向けフィールド ■ スキーマ ■ テキスト出力

このデモは、AI検索に引用される状態への変化を概念として示したものだ。実際の改善はプラグインが算出するスコアに沿って進める。スコアが上がると、ChatGPTやGeminiが回答の根拠としてサイトを使う可能性が高まる仕組みだ。

プライバシー、サポート、総合評価

プライバシー、サポート、総合評価

クラウド処理とプライバシー

ByTheWeb AIでコンテンツ生成を実行すると、該当ページの内容とドメイン情報がByTheWebのクラウドサービスを経由する。WP Mayorのレビューでは、厳格なデータ処理要件を持つサイトはプライバシーポリシーを確認し、必要に応じて運営チームへ問い合わせるべきだと触れられている。手動機能だけを使う場合はクラウド処理が発生しない。

サポート体制

サポートはWebサイト上のチケットシステムで受け付ける。WordPressプラグインのダッシュボードから簡単にアクセスできる。ナレッジベースには基本機能と一部の応用ケースがまとめられており、多くは短い動画ガイド付きだ。WP Mayorのレビューでは、動画だけでなくテキストによる詳しい説明が増えるとさらに良いという指摘もある。

導入に向くサイトタイプ

WP Mayorのレビューでは、ブロガー、複数サイトを監査するエージェンシー、構造化データを追加したいローカルビジネスにとって最も価値があると評価されている。一方、同レビューは成熟したSEOスタックを導入済みの場合やAI引用の保証を求める場合、複数ある判断材料の1つとして扱うのが現実的だとしている。確立されたリーダーというより、形成途中のカテゴリに登場した有望な初期段階の製品という位置づけだ。

この記事のポイント

  • ByTheWeb GEOは無料でAI可読性スコア、llms.txt、スキーマ、従来SEOを管理する
  • ByTheWeb AIは任意のクレジット制アシスタントで、不足フィールドを自動生成する
  • 新規アカウントには30日間有効の5,000クレジットが付与される
  • Yoast SEOやRank Mathと併用でき、GEOスコアとスキーマは有効なまま残る
  • AI生成を実行するとページ内容がクラウドを経由するため、プライバシー確認が必要だ
WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのコードベースで長年使われてきた「マジックストリング」が、人知れず問題を引き起こしていた。注文ステータス、商品タイプ、在庫状態、税金モード。これらの重要な値が、コード中で生の文字列として比較されていたのだ。タイプミス一つでバグになり、プレフィックスの有無で混乱し、コード検索でノイズが大量に混ざる。開発者にとって頭の痛い状況だった。

WooCommerceはこの問題に対処するため、Automattic\WooCommerce\Enumsという名前空間にエナムクラス群を導入した。注文ステータスや商品タイプを表す名前付き定数をパブリックAPIとして公開し、拡張機能開発者に採用を促している。本記事では、この変更の背景、利用可能なクラス、実際の導入方法を整理する。

マジックストリングがもたらす4つの問題

マジックストリングがもたらす4つの問題

WooCommerceは歴史が長い。そのため、注文ステータスや商品タイプといった重要な値が、PHPの近代的な慣習が生まれる前から存在している。コードベースの各所で、次のような生の文字列比較が行われてきた。

if ( 'completed' === $order->get_status() ) {
    // タイプミスがないことを祈るしかない
}

この書き方は一見シンプルに見えるが、WooCommerceのような大規模なコードベースでは深刻な代償を伴う。Developer WooCommerce Blogの記事では、その問題を4つの観点から説明している。

沈黙のエラー

文字列リテラルの最大のリスクは、タイプミスが静かに潜むことだ。'complete'と書くべきところを'completed'と書いても、リンターもオートローダーもテストもエラーを検出しない場合がある。コードは実行時に黙って失敗し、デバッグに時間を奪われる。

プレフィックスの有無による混乱

WordPressのデータベースでは、注文ステータスにwc-というプレフィックスが付く。データベースにはwc-completedとして保存されるが、WooCommerceの多くのAPIはプレフィックスなしのcompletedを期待する。この違いは、開発者が実際にコードを動かして初めて気づく類の落とし穴だ。

検索の非効率さとドキュメントの分散

エージェントやコード検索で'simple'という文字列を探すと、商品タイプのロジックを探しているのに無関係な箇所が大量にヒットする。一方、ProductType::SIMPLEのように名前付き定数で検索すれば、該当箇所を正確に絞り込める。さらに、on-holdのようなステータスの定義は、宣言箇所のdocblockにドキュメントとして残せるようになる。

マジックストリングの問題点(Before)
タイプミス検出困難 → 実行時まで気づけない
プレフィックス混乱 → wc-completed と completed の区別が曖昧
検索ノイズ → simple で検索すると無関係な箇所が大量ヒット
ドキュメント分散 → 値の意味がコード中に散在
↓
エナムクラス導入後(After)
名前付き定数 → タイプミスをコンパイル時に検出
意図の明確化 → OrderStatus::COMPLETED と OrderInternalStatus::COMPLETED を区別
検索精度向上 → ProductType::SIMPLE で該当箇所を正確に絞り込み
ドキュメント統合 → docblockに意味を記載

この比較で示したように、エナムクラスは文字列リテラルが抱える問題を構造的に解決する。特に、プレフィックス有無の違いを別々のクラスに分けることで、意図を明確に伝えられる点が重要だ。

ネイティブPHPエナムを採用しなかった理由

ネイティブPHPエナムを採用しなかった理由

PHPにはバージョン8.1からネイティブのエナム型が導入されている。しかしWooCommerceはこの選択肢を取らなかった。主に2つの理由がある。

PHP 7.4のサポート

WooCommerceの最低サポートPHPバージョンは7.4だ。このバージョンにはネイティブエナムが存在しない。PHP 8.1を前提にすると、多くのユーザーを切り捨てることになる。クラス定数として文字列を定義する方式なら、PHP 7.4でも問題なく動作する。

文字列互換性という設計判断

もう一つの理由はアーキテクチャ上の判断だ。注文ステータスや商品タイプの値は、すでに数百万のデータベースにプレーンな文字列として保存されている。数千の拡張機能もその形式を前提にしている。ネイティブPHPエナムを使うと値がオブジェクトに変換され、既存のコードが壊れる可能性がある。

文字列定数を使う方式なら、OrderStatus::COMPLETEDは従来の'completed'と同じ文字列を生成する。開発者はより明確な名前を使いつつ、WooCommerceの動作を変えない。既存コードが動き続け、拡張機能は準備ができた時点で新しい定数に移行できる。

final class OrderStatus {
    /**
     * 注文が完了した状態
     */
    public const COMPLETED = 'completed';
    // ...
}

このコードが示すように、エナムクラスはfinalで宣言され、public constとして定数を公開する。docblockで各定数の意味をドキュメント化できるのが利点だ。クラスを継承させないことで、APIの一貫性を保つ。

利用可能なエナムクラス

利用可能なエナムクラス

現在WooCommerceのsrc/Enumsディレクトリには、4つのカテゴリにまたがるエナムクラスが用意されている。各クラスの一覧を確認しよう。

注文と商品のエナム

  • OrderStatus(プレフィックスなしの値。例としてcompleted)
  • OrderInternalStatus(データベースに保存されるwc-プレフィックス付きの値)
  • OrderItemType(注文アイテムのタイプ)
  • ProductType(商品タイプ。例としてsimple)
  • ProductStatus(商品ステータス)
  • ProductStockStatus(在庫状態)
  • ProductTaxStatus(税金状態)
  • CatalogVisibility(カタログの表示設定)

支払いと設定値のエナム

  • PaymentGatewayFeature(ゲートウェイがsupports配列で宣言する文字列)
  • WeightUnit(重量単位)
  • DimensionUnit(寸法単位)
  • CurrencyPosition(通貨位置)
  • TaxBasedOn(課税基準)
  • TaxDisplayMode(税表示モード)
  • DefaultCustomerAddress(デフォルト顧客住所)
  • StockDisplayFormat(在庫表示形式)
  • CatalogSortOrder(カタログ並び順)

各クラスの完全な一覧は、WooCommerceのGitHubリポジトリにあるsrc/EnumsディレクトリとREADMEで確認できる。このディレクトリが権威ある情報源として公開されている。

注文関連 OrderStatus / OrderInternalStatus / OrderItemType
商品関連 ProductType / ProductStatus / ProductStockStatus 他
支払い関連 PaymentGatewayFeature
設定値関連 WeightUnit / DimensionUnit / CurrencyPosition 他

以上の4カテゴリが、現在WooCommerceで利用可能なエナムクラスの全体像だ。注文関連と商品関連が特に充実している。

拡張機能での採用方法

拡張機能での採用方法

エナムクラスは公的に発見可能なAPIとして設計されており、publicの可視性、docblock、開発者向けドキュメントを備えている。拡張機能開発者は安心して利用できる。

基本的な使い方

使い方はシンプルだ。use文で必要なクラスをインポートし、定数を参照する。例えば注文ステータスをチェックする場合、次のように書ける。

use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;

if ( OrderStatus::COMPLETED === $order->get_status() ) {
    // 注文が完了した場合の処理
}

$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );

採用前に確認すべき2つのポイント

エナムクラスを拡張機能に導入する前に、確認しておくべきことが2つある。

1. 最小サポートWooCommerceバージョン。エナムクラスは段階的に追加されてきた。OrderStatusはWooCommerce 9.5で導入され、商品関連クラスは9.7〜9.8頃、設定値クラスは10.xシリーズで追加された。古いバージョンもサポートする場合は、文字列リテラルを使い続けるか、class_exists()でガードする必要がある。

2. WooCommerceが期待する文字列。OrderStatus::COMPLETEDはcompletedを返すが、OrderInternalStatus::COMPLETEDはwc-completedを返す。ほとんどのWooCommerce関数はプレフィックスなしの形式を取るが、データベースレベルやpost_statusコンテキストではプレフィックス付きを使う必要がある。どちらの形式を使うべきかを意識するのが重要だ。

商品検索と注文検索の公式ドキュメントには、文字列リテラルとエナムクラスの両方の形式が併記されている。移行時の参考になる。

プレフィックスなし(API用)
OrderStatus::COMPLETED → completed を返す
使用場面 → wc_get_orders() などの API
↓
プレフィックスあり(DB用)
OrderInternalStatus::COMPLETED → wc-completed を返す
使用場面 → post_status やデータベース操作

このデモで示したように、2つの定数は同じ注文完了状態を表すが、使用するコンテキストが異なる。混同すると期待通りに動作しない。

今後の展開

今後の展開

Developer WooCommerce Blogの記事によれば、コアに新しい語彙(文字列値の集合)を追加する場合、エナムクラスをデフォルトで付ける方針が示されている。WooCommerceコアにはまだ名前の付いていない文字列値が多数残っており、コミュニティからの貢献も歓迎している。

この変更は拡張機能開発者にとって歓迎すべき動きだ。タイプミスのリスクが減り、コードの意図が読みやすくなり、IDEの補完機能も効きやすくなる。長期的にはWooCommerceエコシステム全体のコード品質向上につながる。

一方で、移行には段階的な対応が必要だ。既存の拡張機能は古いWooCommerceバージョンとの互換性を維持しながら、徐々にエナムクラスへ移行していくことになる。一括で全置換するのではなく、新規コードから採用していくのが現実的なアプローチだろう。

この記事のポイント

  • WooCommerceがマジックストリング(生の文字列リテラル)をエナムクラスに置き換える動きを進めている
  • エナムクラスはタイプミス防止、プレフィックス区別、検索精度向上、ドキュメント統合の4つの利点を持つ
  • ネイティブPHPエナムではなく文字列定数クラスを採用した理由は、PHP 7.4互換性と既存データベースの文字列互換性
  • 注文・商品・支払い・設定値の4カテゴリにエナムクラスが用意されている
  • 採用時は最小サポートWooCommerceバージョンと、プレフィックス有無のどちらの定数を使うかを確認する
WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0が2026年9月1日にリリースされた。今回のアップデートでは商品バリエーション画像ギャラリーが標準機能となり、専用プラグインが不要になった。Store APIとREST APIの応答速度も最大42%改善している。

今回のリリースは後方互換性を保っており、データベース更新を伴う。561件のプルリクエストがマージされ、77人のコントリビューターが参加した。WooCommerceを運用しているECサイトでは更新前に変更点を把握しておきたい。

この記事ではWooCommerce 11.1.0の主要な変更点を、店舗運営者向けと開発者向けに分けて解説する。更新作業の前に確認すべき注意点もまとめた。

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0では店舗運営者に直接影響する機能追加と、開発者向けの内部改善が同時に行われた。本番サイトへの適用前には公式の更新ガイドとチェンジログを確認することが推奨されている。

店舗運営者に影響する変更は3つある。1つ目は商品バリエーション画像ギャラリーの標準搭載、2つ目はEU顧客向け注文撤回フォームの追加、3つ目は仮想商品の管理画面表示の改善だ。これに加えて商品ギャラリーへの動画対応がベータ機能として導入された。

開発者向けにはブロックエディタアセットの統合、ブロック登録処理の最適化、注文アイテム削除ロジックの修正などが含まれる。特にStore APIとREST APIの応答速度は30%から42%改善しており、ヘッドレス構成や外部連携を運用している場合に効果が大きい。

WooCommerce 11.1.0の変更分類
店舗運営者向け バリエーション画像ギャラリーの標準化
店舗運営者向け EU顧客向け注文撤回フォームの追加
パフォーマンス Store APIとREST APIを最大42%高速化
ベータ機能 商品ギャラリーへの動画対応
■ 店舗運営者向け ■ パフォーマンス改善 ■ ベータ機能

上記デモはWooCommerce 11.1.0の変更点を影響範囲ごとに分類したものだ。青と緑が店舗運営者向け、オレンジがパフォーマンス改善、紫が実験的ベータ機能に該当する。

商品バリエーション画像ギャラリーが標準機能に

商品バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0で、商品バリエーションごとに複数の画像を持たせる「バリエーション画像ギャラリー」が全ストアで標準機能として有効化された。これまでこの機能は「WooCommerce Additional Variation Images」という別プラグインで提供されていたが、今回のリリースをもって公式の専用プラグインは提供終了となる。

バリエーション画像ギャラリーとは、商品のサイズやカラーといったバリエーションごとに、複数の商品写真や画像を登録できる仕組みだ。たとえばサイズ違いのTシャツ商品で、MサイズにはMサイズの着用写真を複数枚登録し、LサイズにはLサイズの写真を複数枚登録できる。購入希望者が自分に合ったサイズの写真だけを確認できるため、購入決定の精度が上がる。

今回の標準化では設定画面の実験的機能フラグが削除された。データベース更新(11.1.0-1)により、過去に実験的フラグをオフにしていたストアでも自動的に有効化される。個別に切り替える必要はなく、WooCommerceを11.1.0に更新すれば全ストアで利用できる。

11.1.0以前(Before)
追加プラグイン 必須 → プラグイン終了予定
バリエーション画像ギャラリーを利用するには専用プラグインの導入が必要だった。設定も個別のプラグイン管理画面から行う必要がある。
↓
11.1.0以降(After)
WooCommerce標準機能 追加費用なし → 全ストアで自動有効化
WooCommerce 11.1.0に更新するだけで全ストアで利用できる。実験的フラグは削除され、データベース更新で自動的に有効化される。

専用プラグインが不要になり、バリエーション画像ギャラリーはWooCommerceの標準仕様となった。既存の専用プラグインユーザーも移行作業なしでそのまま利用できる。

Store APIとREST APIのパフォーマンス改善

Store APIとREST APIのパフォーマンス改善

WooCommerce 11.1.0ではStore APIとREST APIの応答速度が大幅に改善された。ブロックタイプとパターンの登録処理が、ブロックを描画できないリクエストではスキップされるようになったことが主な要因だ。

Store APIとは、WooCommerceの商品データや注文データを外部から利用するためのAPIだ。ヘッドレス構成でフロントエンドとWooCommerceを接続する場合や、モバイルアプリから商品情報を取得する場合に使われる。REST APIも同様に外部連携の窓口となる。

今回の変更により、ブロックタイプ(block types)とパターン(patterns)の登録が、ブロックを描画・編集できないリクエストでは実行されなくなった。これまではAPIリクエストでも無駄にブロック関連の処理が走っていたため、応答時間が長くなっていた。変更後はStore APIとRESTリクエストの速度が30%から42%向上した。

11.1.0以前のAPIリクエスト(Before)
APIリクエスト → ブロック登録処理 → 無駄に実行
ブロックを描画できないAPIリクエストでも、ブロックタイプとパターンの登録処理が実行されていた。これが応答時間を長くする要因になっていた。
↓
11.1.0以降のAPIリクエスト(After)
APIリクエスト → ブロック登録をスキップ → 30〜42%高速化
ブロックを描画・編集できないリクエストでは登録処理がスキップされる。Store APIとREST APIの応答速度が最大42%改善した。

このデモはAPIリクエスト時の処理フロー変化を示している。ブロック登録の最適化は店内回遊の速度向上ではなく、外部連携やヘッドレス構成での応答性能に直接効く変更だ。

EU顧客向け注文撤回フォームの追加

EU顧客向け注文撤回フォームの追加

WooCommerce 11.1.0ではEU圏の規制に準拠するための「注文撤回フォーム」が追加された。デフォルトでは無効になっており、EUガイドラインへの準拠が必要なストアが手動で有効化する形だ。

注文撤回とはEUの消費者保護規則に基づく権利で、消費者が商品を受け取ってから一定期間内に購入をキャンセルできる仕組みだ。ストア側はこの権利に応じた返金・返品プロセスを用意する必要がある。今回追加されたフォームは、その撤回申請を顧客自身がオンラインで提出するための画面をマイアカウントページに作成する。

撤回申請が提出されるとシステムに記録され、ストア運営者にはメール通知と管理画面のダッシュボード通知が送られる。ただし実際の注文撤回処理と返金作業は手動で行う必要がある。各ストアのポリシーや商品特性によって処理手順が異なるためだ。

STEP 1 顧客がマイアカウントページで注文撤回フォームを開く
↓
STEP 2 顧客が注文撤回リクエストをオンラインで提出
↓
STEP 3 システムに記録され運営者へメールとダッシュボードで通知
↓
STEP 4 運営者が返金・返品処理を手動で実行

注文撤回フォームはデフォルト無効のため、通常の国内向けストアでは追加設定は不要だ。EU向け販売を行うストアはWooCommerceの設定画面から有効化できる。

商品ギャラリーの動画対応と仮想商品の表示改善

商品ギャラリーの動画対応と仮想商品の表示改善

WooCommerce 11.1.0では商品ギャラリーへの動画対応がベータ機能として追加された。クラシックテーマとブロックテーマの両方の商品ギャラリーで動画を表示できる。

初期リリースではローカルにアップロードした動画のみが対応する。外部ホスティングの動画URL(YouTubeやVimeoなど)は現時点ではサポートされていない。実験的機能のため、今後のリリースで仕様が変更される可能性がある。

この機能はデフォルトでは無効になっている。有効化するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、「商品ギャラリー動画」をオンにする必要がある。商品の見せ方を動画で強化したいストアはテスト環境での検証を推奨する。

仮想商品の管理画面表示が整理された

発送処理が不要な仮想商品のみの注文では、管理画面の注文サマリーに配送先住所が表示されないようになった。これまでStore APIのチェックアウト処理が互換性維持のために請求先住所から配送先住所を生成していたため、仮想商品のみの注文でも意味のない住所が表示されていた。

この変更により、仮想商品のみの注文画面がすっきりと整理される。実際の住所データが削除されるわけではなく、表示されなくなるだけだ。物理商品を含む注文や、配送情報が未確定の注文では従来どおり住所が表示される。

開発者向けの変更点

開発者向けの変更点

WooCommerce 11.1.0には複数の開発者向け変更が含まれる。ブロックエディタアセットの統合、注文アイテム削除ロジックの修正、WooCommerce Adminの安定済みフィーチャーフラグ廃止などだ。

統合ブロックエディタアセット(実験的)

実験的な新機能として、ブロックエディタ向けのJavaScriptとCSSファイルが統合された。これまでWooCommerceのブロックはそれぞれ個別のスクリプトとスタイルを読み込んでいたが、共有バンドルにまとめることでエディタ画面でのリクエスト数と総サイズが削減される。

デフォルトでは無効になっており、11.1.0では影響が出ない。有効化した場合もフロントエンド側のアセットは変更されず、既存のブロックハンドルは従来どおり動作する。管理画面の編集速度を改善したいストアは検討の余地がある。

注文アイテム削除ロジックの修正

WooCommerceの注文アイテム削除処理に含まれていた潜在的なバグが修正された。更新前は、拡張プラグインが注文保存前に差し込んだ置換用アイテムが、削除処理によって誤って消される可能性があった。

具体的にはWC_Abstract_Orderクラスのremove_order_itemsメソッドが、削除要求時に存在していたアイテムIDを記録するようになった。これにより拡張プラグインが追加したアイテムが誤って削除されるのを防ぐ。9割以上の拡張プラグインではコード変更は不要だが、カスタム注文データストアを実装している場合はget_item_idsとdelete_items_by_idsの実装を確認する必要がある。

安定済みフィーチャーフラグの廃止

WooCommerce Adminの安定機能として採用済みのフィーチャーフラグの一部が、設定パイプラインを介さず直接読み込まれるようになった。機能自体は削除されておらず、互換性維持のための互換レイヤーも残されている。

互換レイヤーはFeatures::is_enabled()とwindow.wcAdminFeaturesに対して従来の値を返し続けるが、非推奨警告を出力するようになった。自作の拡張プラグインでフィーチャーフラグに依存している場合は、互換レイヤーが撤去される前に対応を進めておきたい。

この記事のポイント

  • バリエーション画像ギャラリーがWooCommerce標準機能として全ストアで有効化された
  • 専用プラグイン「WooCommerce Additional Variation Images」は提供終了となる
  • Store APIとREST APIの応答速度が最大42%向上した
  • EU顧客向け注文撤回フォームが追加された(デフォルトでは無効)
  • 商品ギャラリーの動画対応はベータ機能としてデフォルト無効で提供される
  • 仮想商品のみの注文では管理画面に配送先住所が表示されなくなった