WooCommerce 11.2.1リリース。住所フィールドと郵便番号の不具合を修正
WooCommerce 11.2.1が2026年10月9日にリリースされた。今回のドットリリースは、11.2.0で発生した2件のチェックアウト関連バグを修正する内容だ。
住所フィールドを削除したストアで発生するエラーと、アルゼンチンなど特定の国で郵便番号が拒否される問題が対象になる。セキュリティ更新とデータベース更新は含まれない。
記事を読めば、修正された2つのバグの内容と、アップデート前に確認すべきポイントがわかる。
WooCommerce 11.2.1の概要
WooCommerceはWordPressでECサイトを構築する無料プラグインだ。今回の11.2.1は「ドットリリース」と呼ばれる、バグ修正に限定された小規模な更新になる。新機能の追加はなく、11.2.0で見つかった不具合を修正するためにリリースされた。
修正対象は2件ある。1件目はクラシックチェックアウトで住所フィールドを削除したストアに発生するブロックエラーで、2件目はチェックアウトブロックでアルゼンチンなどの郵便番号が拒否される問題だ。
WooCommerceのチェックアウトには大きく分けて2つの方式がある。1つはショートコードで表示する「クラシックチェックアウト」、もう1つはGutenbergブロックエディタで構築された「チェックアウトブロック」だ。今回の修正は両方を1つずつカバーしている。
このデモは、11.2.1で修正された2つの不具合と、セキュリティ更新やデータベース更新が含まれないことを示している。
クラシックチェックアウトの住所フィールド修正
クラシックチェックアウトは、ショートコード [woocommerce_checkout] で表示される従来型のチェックアウト画面だ。WooCommerceの初期から提供されている方式で、現在も多くのストアで使われている。
住所フィールドとは、請求先住所や配送先住所の入力欄のことだ。多くのストアでは必須項目だが、デジタル商品のみを販売するストアなどでは不要な場合がある。そうしたストアは、woocommerce_billing_fields または woocommerce_default_address_fields というフィルターを使って住所フィールドを削除するカスタマイズを行う。
フィルターとは、WordPressやWooCommerceの動作をサイト独自に変更するための仕組みだ。テーマのfunctions.phpやカスタムプラグインにコードを追加して使う。住所フィールドを削除するカスタマイズは、決して珍しいものではない。
11.2.0では、注文サマリーが更新される際の住所データ送信に問題があった。住所フィールドを削除したストアで、以下のような不具合が発生する可能性があった。
- 「続行するには住所を入力してください」というエラーでチェックアウトがブロックされる
- 税金が正しく計算されない
- 配送方法の選択肢が表示されなくなる
11.2.1では、11.1の動作に戻す修正が入った。注文サマリーのリフレッシュ時に、住所データが正しく送信されるようになる。住所フィールドを削除するカスタマイズを利用しているストアは、このバージョンで問題が解消される。
住所フィールドを削除したストアでは、11.2.0のエラーが11.2.1で解消される。
チェックアウトブロックの郵便番号バリデーション修正
チェックアウトブロックは、ブロックエディタで構築された新しいチェックアウトフローだ。カートブロックやチェックアウトブロックなど、複数のブロックを組み合わせて柔軟にレイアウトを変更できる。
バリデーションとは、入力された値が正しい形式かどうかを検証する仕組みだ。たとえば郵便番号の入力欄に「123」など桁数の少ない値を入力するとエラーになるのは、バリデーションが働いているからだ。今回の問題は、この検証が厳しくなりすぎたことによって発生した。
11.2.0では、アルゼンチンの郵便番号で州文字なしの形式（例 1213）が拒否されるようになった。さらに、エルサルバドル、セントビンセントおよびグレナディーン諸島、イギリス領ヴァージン諸島の郵便番号フォーマットも拒否されていた。
11.2.1では、アルゼンチンの州文字なし郵便番号を再び受け入れ、上記3カ国のフォーマットにも対応する。該当する国への配送を行っているストアは、チェックアウトブロックでエラーが解消される。
11.2.1では、アルゼンチンの州文字なし郵便番号が再び有効になる。
アップデート前の確認ポイント
今回の修正はバグ修正に限定されているため、更新によるリスクは比較的低い。ただし、チェックアウトは売上に直結する機能だ。更新前には以下のポイントを確認しておきたい。
- 住所フィールドを削除するカスタマイズを使っているか
- チェックアウトブロックを利用しており、対象国に配送しているか
- ステージング環境で実際のチェックアウトフローをテストしたか
- 更新前にバックアップを取得しているか
特に住所フィールドを削除するカスタマイズを使っているストアは、11.2.0をスキップして11.2.1に直接更新することをおすすめする。11.2.0に更新してしまった場合は、できるだけ早く11.2.1への更新が望ましい。
この記事のポイント
- WooCommerce 11.2.1は2026年10月9日にリリースされたドットリリース
- クラシックチェックアウトで住所フィールドを削除したストアのエラーを修正
- チェックアウトブロックでアルゼンチンなどの郵便番号バリデーションを修正
- セキュリティ更新とデータベース更新は含まれない
- 住所フィールド削除カスタマイズ利用中のストアは更新推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.2が登場、商品CSVのUPC照合と決済日付入力を追加
WooCommerce 11.2が2026年10月8日にリリースされた。今回のアップデートでは商品CSVインポートの照合方法が拡張され、サプライヤーから届いたUPCだけの価格表をそのまま取り込めるようになった。ほかにもチェックアウトでの日付入力、注文撤回メールの設定、カタログ画面のパフォーマンス改善が含まれる。
ECサイトを運営する担当者にとって、日々の商品管理と受注業務に直結する変更が中心だ。特に商品コードを使った一括更新は、数千点規模の在庫を扱う店舗で作業時間を大きく短縮できる。本記事ではWooCommerce 11.2の主要な変更点と、アップデート前に確認しておきたい注意事項をまとめる。
WooCommerce 11.2の主な変更点
WooCommerce 11.2はWordPressのECプラグインとして広く利用されているWooCommerceのマイナーアップデートだ。公式ブログでは変更点を6つの項目に分けて紹介している。いずれも店舗運営の効率化に寄与する内容で、商品管理から顧客体験の改善まで幅広い。
上記のほか、セキュリティ改善とデータベース更新も含まれる。更新前にバックアップを取得しておくことが推奨される。
商品CSVインポートがUPC・GTINなどのコードに対応
商品コードとは
UPC（Universal Product Code）は主に米国で使われるバーコード規格で、商品パッケージに印刷された12桁の数字を指す。GTIN（Global Trade Item Number）は国際標準の商品識別コード、EAN（European Article Number）は欧州で広く使われるバーコード、ISBNは書籍の識別コードだ。いずれも商品を一意に特定するための番号で、サプライヤーから届く価格表にはこれらのコードだけが記載されていることが多い。
インポート時の照合の流れ
WooCommerceの商品CSVインポート機能では、これまで各行を商品IDまたはSKUで照合して既存商品を更新していた。11.2では照合の優先順位が拡張され、ID、SKU、GTIN、UPC、EAN、ISBNの順に一致する商品を探す。サプライヤーからUPCだけの価格表を受け取った場合でも、そのままCSVファイルとしてアップロードできるようになった。
利用するにはインポート画面で「既存の商品を更新」を有効にする必要がある。同一商品にSKUとUPCの両方が登録されている場合はSKUが優先される仕組みだ。
チェックアウトで日付入力を追加できる
日付フィールドの用途
チェックアウトブロックを使用している店舗では、注文手続き中に顧客へ日付を尋ねられるようになった。配達希望日や誕生日など、商品の性質に合わせて自由に用途を決められる。顧客はスマートフォンやブラウザ標準の日付ピッカーを使って日付を選択する。店舗側は選択できる日付の範囲も制限できる。
設定方法
この日付フィールドを追加するには、チェックアウトブロックの設定にショートコードスニペットを追加する。テーマのfunctions.phpやコード管理プラグインに数行のコードを貼り付けるだけで有効化できる。コードの詳細は公式のリリースノートに記載されている。
この例では配達希望日を追加しているが、誕生日や引き取り希望日など、店舗の運用に合わせて自由にラベルを変更できる。
注文撤回メールを管理可能に
EU圏の顧客に販売している店舗向けの変更も入った。注文撤回（キャンセル要求）が発生したときに送信される2種類のメールを、管理画面から設定できるようになった。1つは顧客が受け取る確認メール、もう1つは店舗側に届く通知メールだ。
WooCommerceの設定画面にある「メール」セクションで、それぞれのメールに独自のメッセージを追加できる。プレビューで内容を確認し、通知を受け取る担当者を選び、必要なければメール自体を無効化することも可能だ。これまではコードでしか変更できなかった設定が、管理画面だけで完結するようになった。
パフォーマンス改善とブロックの新スタイル
カタログと管理画面の高速化
商品数が5点でも5万点でも、カタログ画面で商品を自由に並べ替えられるようになった。可変商品（サイズや色などのバリエーションを持つ商品）を含む店舗では、商品ページの読み込みとチェックアウト処理が高速化している。レポート集計ではデータベースへのクエリ数が減り、顧客数が増えてもメモリ使用量が増加しにくくなった。
大量の顧客データを持つ店舗ほど、この改善による管理画面の体感速度は大きく変わる。レポート表示が遅くて開くのを待っていた店舗は、更新後に改善を実感しやすい。
商品フィルターブロックのスティッキー表示
商品フィルターブロックにスティッキー（追従）表示のオプションが追加された。長いカテゴリーページを顧客が下へスクロールしても、フィルター条件が画面上部に表示され続ける。絞り込みのたびにページ先頭まで戻る手間がなくなる。
ほかにも数量セレクター（カート内のものを含む）は枠線、影、色、角丸を設定できる。商品画像には枠線、フィルターチップにはフォントと余白のコントロールと角丸が追加された。これらのスタイルは外観 > エディター > スタイル > ブロックの画面で店舗全体に一括設定するか、ブロック単位で個別に調整する。
アップデート前に知っておくべき注意点
既存メール設定への影響
パスワードリセット、新規アカウント作成、メール確認の各メールについて、自分自身をCCまたはBCCでコピー受信していた場合、その配信が停止される。これらのメールにはログインリンクが含まれるため、本人以外には送られないようにするセキュリティ上の変更だ。
ダウンロードリンクと権限の変更
標準のダウンロードリンクは従来どおり動作する。ただし、まれにカスタム登録やインポートで不正なデータを持つリンクは動作しなくなる可能性がある。顧客から報告があれば、注文画面からリンクを再発行すればよい。
ショップマネージャー（店舗運営者）が、フォーラム権限や会員権限など特定の追加権限を持つユーザーを編集できなくなる。そのようなユーザーの編集はWordPress管理者が行うことになる。
アップデート手順の注意
WooCommerce 11.2にはセキュリティ改善とデータベース更新が含まれるため、運営中のすべての店舗でアップデートを適用することが推奨される。データベース更新が走るので、事前のバックアップが必須だ。
この記事のポイント
- WooCommerce 11.2は2026年10月8日にリリースされた
- 商品CSVインポートがUPC・GTIN・EAN・ISBNでの照合に対応した
- チェックアウトブロックに日付入力欄を追加できる
- 注文撤回メールの管理画面設定が可能になった
- パフォーマンス改善とセキュリティ更新を含むためバックアップしてアップデートを
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Nuxt 4.6リリース、Server API刷新と高速化した型推論の全容
Nuxt 4.6が2026年10月5日にリリースされた。Nuxt CLI v4が同梱され、開発サーバーの起動と再起動が大幅に速くなっている。今回の目玉はサーバーコードを移行しやすくする新しいimportソースだ。
サーバー非依存化への大きな一歩となる。型付き$fetchも再構築され、大規模プロジェクトで問題になっていた型推論の遅さが解消された。Nuxt 3は2026年7月末にEOLを迎えており、移行を考える契機になる。
Nuxt CLI v4の変更点
Nuxt 4.6にはメジャーアップデート版のNuxt CLI v4が含まれる。依存関係として自動的に導入されるため、Nuxt 4.6に更新すれば新しいCLIが使える。変更の中心は開発サーバーだ。
インタラクティブパネルと新コマンド
端末の下部に専用パネルが固定表示される。URL、起動の進行状況、ショートカットキーが並ぶ。キー1つで再起動、ページを開く、ログ確認、リクエスト確認、ページとサーバールートの一覧表示が可能だ。
各リクエストにはIDが付与され、ログとエラーがどのリクエストから発生したか追跡できる。クラシックな出力に戻したい場合は--no-tuiを渡せばよい。
開発サーバーは再読み込みと再起動の理由も教えてくれる。どのnuxt.configキーが変わったのか、起動が遅い場合に時間がどこにかかったのか、各モジュールのセットアップ時間も個別に表示される。内容が変わらない保存では再起動が起きない。
数値で見る高速化
初回表示は6.6倍速くなり、メモリ使用量も30%減った。ロックファイルによって複数の開発サーバー起動が衝突せず、新しいnuxt curlやnuxt taskコマンドも動作する。
Server API nuxt/serverの導入
今回のリリースで最も重要な変更がサーバーコードの抽象化だ。新しいimportソースであるnuxt/serverが追加された。ハンドラー、ミドルウェア、ユーティリティをここから読み込む。ブラウザでも動くnuxt/appのサーバー版にあたる。
サーバー非依存化の目的
これまでサーバーコードはh3とNitroに密結合していた。h3やNitroのメジャーバージョンが上がると、エコシステム全体に影響が波及する構造だった。Nuxt 5でNitro v3とh3 v2へ移行するにあたり、この結合を解消する必要があった。
nuxt/serverは自前の型を定義し、外部パッケージを参照しない。同じハンドラーがNitro v2、Nitro v3、実験的なViteサーバーのどこでも動く。モジュール作者はh3やnitropackへのピア依存を気にせずに済む。
サーバーコードをnuxt/serverで書いておけば、Nuxt 5に更新しても同じファイルがそのまま動く。モジュールも1つのファイルで両バージョンをサポートできる。
コード例とAPIサーフェス
import { defineEventHandler, getQuery } from 'nuxt/server'
export default defineEventHandler((event) => {
const { name } = getQuery<{ name?: string }>(event)
return { message: `Hello, ${name ?? 'world'}!` }
})イベントオブジェクトはWeb標準に基づく。リクエストURL、レスポンスヘッダー、クッキー、リダイレクト、セッションなどが扱える。必要ならZodなどのバリデーションライブラリと組み合わせて、リクエスト本文を検証してから処理を進められる。
従来のh3やnitropackから読み込む方法も削除されていない。特定のハンドラーで低レベルな機能が必要な場合は、これまで通りdefineEventHandlerをh3から読み込めば動く。
Typed $fetchの再構築
$fetchとuseFetchはサーバールートから型を推論できた。しかし数百ルートを超えるとTypeScriptのインスタンス化上限に達し、コンパイルが止まることがあった。
型推論の高速化
型システムをfetchdtsベースで再実装した。静的なパスは完全一致テーブルとしてコンパイルされ、ルート数ではなく参照箇所の数で処理コストが決まる。
3000ルートの処理が53.63秒から0.62秒に短縮された。ピークメモリも946 MBから140 MBへ大幅に減っている。大規模プロジェクトほど効果を実感できる。
新しい型チェック機能
ルートごとに検証済みのbody、query、headersが型情報に含まれる。間違った形のリクエストを送ると、呼び出し側でエラーが出るようになった。存在しないパスへの$fetchを拒否するexperimental.strictRouteTypesも追加されている。
Nuxt 4ではオプトイン機能だ。Dateの戻り値が呼び出し側ではstringになるなどの小さな推論の違いがあるため、デフォルトにはしていない。Nuxt 5では標準で有効になる。
開発体験の改善
開発時のエラー表示と起動画面が刷新された。開発者にとって地味に見える変更だが、原因特定までの時間を短縮する効果は大きい。
my-badによる新しいエラー表示
サーバーサイドエラーのスタックトレースにソース位置とコードフレームが表示されるようになった。Youchの埋め込みiframeは廃止され、my-badという新しいオーバーレイに置き換えられた。
エラーレポートにはコピーボタンがある。Markdown形式、エージェントに手渡せるプロンプト形式、JSON形式を選べる。AIコーディングエージェントが普及した今、エラー情報をそのまま渡せる設計は実務的だ。
致命的な起動エラーもページとして表示される。nuxt.config.tsに構文エラーがあっても専用ページが表示され、修正後に自動で再読み込みされる。ワーカー再起動をまたいでエラー情報が保持される仕組みだ。
Vue Vapor対応とローディング画面
Vue 3.6のVapor Modeに相互運用モードで対応した。アプリ本体は仮想DOMのまま、コンポーネント単位でVaporを選択できる。<script setup vapor>と書くだけだ。ルーティングやuseAsyncData、レイアウトは変更なしで動く。
開発サーバー起動中のローディング画面も新しくなった。WebGL2のパーティクルフィールドが山脈を描く。WebGL2非対応環境では静止画にフォールバックし、prefers-reduced-motion設定時はアニメーションを止める。モーションに配慮した実装になっている。
パフォーマンスと移行
実測値と改善ポイント
ベンチマークではNuxt 4.5.2と比較して、スタータープロジェクトのビルドが4.4秒から3.6秒に短縮された。200ページ・200コンポーネント・50ルートのビルドも11.6秒から10.3秒に改善している。
SSRスループットは300個の<NuxtLink>を含むページで1秒あたり110リクエストから140リクエストに向上した。内部リンクがサーバー上でプレーンな<a>タグとしてレンダリングされるようになり、リアクティブ状態を持たなくなった効果だ。
experimental.early404を有効にすると、ルートに一致しないリクエストがVueアプリの生成をスキップする。30ページでブート処理が約23 msのアプリでは、JSON 404応答が37.1 msから0.3 msに短縮される。
Nuxt 5への準備
Nuxt 5のデフォルト機能の多くがすでに4.6に入っている。future.compatibilityVersion: 5を設定すれば、一括で有効にできる。個別にトグルすることも可能だ。
- 型付きページ（
experimental.typedPages） - 型付き
$fetch（experimental.routeTypedFetch） - 大文字小文字を区別するルーティング
- ビルド時のページメタデータ抽出
- インラインエラーレンダリング
サーバーコードをnuxt/serverで書いておけば、Nuxt 5移行時に書き換えが不要になる。今のうちに移行しておくのが安全だ。
アップグレードはnpx nuxt upgrade --dedupeを実行する。ロックファイルを更新し、Nuxt CLI v4を含む最新の依存関係が導入される。Node.jsは22.22.3以上、24.15.0以上、または26.0.0以上が必要だ。
この記事のポイント
- Nuxt 4.6はサーバー非依存化への大きな一歩。新しいimportソース
nuxt/serverが追加された - Nuxt CLI v4が同梱され、開発サーバーの初回表示が330 msから50 msへ高速化
- 型付き$fetchが再構築され、3000ルートの型推論が53.63秒から0.62秒に短縮
- Nuxt 3は2026年7月末にEOL。移行を進めるなら
future.compatibilityVersion: 5で事前テストが可能 - アップグレードは
npx nuxt upgrade --dedupeで実行できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1.3 セキュリティアップデート公開。7件の脆弱性修正と即時更新の必要性
WordPress 7.1.3が10月6日に公開された。セキュリティ修正とメンテナンスを兼ねたリリースで、7件の脆弱性修正と4件のバグ修正が含まれている。
セキュリティリリースであるため、公式サイトはすべてのサイト管理者に即時更新を推奨している。特にコメント管理画面に保存型XSSが発見されており、悪用されると管理者権限を奪われる可能性がある。
この記事では7.1.3で修正された脆弱性の内容、更新手順、バックポートの状況を解説する。サイトを安全に保つための具体的なチェックポイントもあわせて紹介する。
WordPress 7.1.3リリースの概要
今回のリリースは定期アップデートではなく、セキュリティ上の問題に対処するための緊急リリースとして位置づけられている。WordPressのセキュリティリリースは、脆弱性の詳細が公開される前に修正版を配布する仕組みだ。今回も7件のセキュリティ修正が含まれており、いずれも悪用されるとサイトの安全性に重大な影響を及ぼす可能性がある。
リリースの基本情報
WordPress 7.1.3は、7.1系の3番目のメンテナンスリリースである。過去のメンテナンスリリースと同様に、バグ修正とセキュリティ修正が同時に行われている。セキュリティ修正が7件、バグ修正が4件だ。バグ修正の内訳はトラッカーのチケットで公開されており、特定の条件下で発生する不具合が対象となっている。
リリースを主導したのはJake Spurlock氏だ。WordPressコア開発のリリースリードとして、複数のコントリビューターと非同期で調整しながら安定版リリースまでこぎつけた。
即時更新が求められる理由
セキュリティリリースの性質上、更新を後回しにすればするほど攻撃を受けるリスクが高まる。攻撃者は公開された修正内容を逆に解析し、まだ更新していないサイトを狙うことが多い。特に今回修正された保存型XSSは承認待ちコメントを経由して悪用できるため、コメント機能を有効にしているサイトは注意が必要だ。
修正された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アプリケーションのセキュリティ監査に積極的に関わるようになってきた流れを反映している。
このデモは、7.1.3適用前後でサイトの脆弱性状態がどのように変化するかを示している。セキュリティリリースの適用により各脆弱性が解消される。
今回の脆弱性報告には、セキュリティ専門企業だけでなくAI関連企業の関与が目立つ。Anthropicは3件、OpenAIはTrail of Bitsとの協力で1件を報告している。AI技術を活用したコード解析やセキュリティ監査の精度が向上していることを示す事例と言える。
更新手順と確認事項
セキュリティリリースの適用は優先度が高いタスクだ。更新にはいくつかの方法があるが、いずれの場合も事前のバックアップが推奨される。更新後に問題が発生した場合にロールバックできる体制を整えておくことが重要である。
ダッシュボードから即時更新
最も簡単な方法は、WordPress管理画面からの更新だ。ダッシュボードにアクセスし「更新」セクションを開くと、WordPress 7.1.3への更新通知が表示される。「今すぐ更新」ボタンをクリックすると自動的に更新プロセスが実行される。自動バックグラウンド更新が有効なサイトでは、すでに更新が自動適用されている場合が多い。
手動で更新する場合は、WordPress.orgからzipファイルをダウンロードしてサーバーにアップロードする方法もある。FTPクライアントやホスティングサービスのファイルマネージャーを使って更新できる。ただし手動更新はファイルの上書きミスなどのリスクがあるため、ダッシュボードからの更新が推奨される。
更新前のバックアップと更新後の確認
更新前には必ずバックアップを取得すること。データベースとファイルの両方をカバーするバックアッププラグインを使うか、ホスティングサービスのバックアップ機能を利用する。更新後に問題が発生した場合、バックアップから復元することで被害を最小限に抑えられる。
更新後は、サイトのフロントエンドと管理画面の両方が正常に動作することを確認する。フォームの送信、コメント機能、固定投稿の表示などを重点的にチェックするとよい。キャッシュプラグインを使っている場合は、キャッシュをクリアしてから動作確認を行うことが重要だ。
このデモは、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インジェクションや投稿者権限の不備も修正された
- 更新はダッシュボードから数クリックで完了する。自動更新が有効なら適用済みの可能性が高い
- 更新前のバックアップと更新後の動作確認が安全なサイト運営の基本である
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能
WooCommerce 11.6が2027年2月にリリース予定で、このバージョンからPHP 8.1以上が必須要件になる。PHP 7.4または8.0で動かしているストアは、それまでに移行準備を進める必要がある。
移行期間を確保するため、WooCommerce 11.3では管理画面に警告通知が追加される。通知は現在のPHPバージョンとホスティング事業者への相談を促す内容で、閉じることもできる。11.5までは従来のPHP環境でも更新を継続できる仕組みだ。
WooCommerceが公開した利用統計によれば、追跡対象ストアの約7％がPHP 7.4、約2％がPHP 8.0で稼働している。この記事では移行の背景、通知の内容、具体的な手順、影響範囲を整理する。
PHP 8.1必須化の背景にある3つの理由
セキュリティサポートの終了
PHP 7.4と8.0は、PHP公式のセキュリティサポートがすでに終了している。サポートが切れたバージョンでサイトを運営し続けると、新しい脆弱性が発見されても修正パッチが提供されない。WooCommerce側でパッチを出しても、PHPランタイム自体のリスクは残る。
依存関係の更新とコードパスの削減
PHP 7.4と8.0に対応し続けるには、古い依存パッケージを固定し、バージョンごとの分岐コードを維持する必要がある。PHP 8.1を最低ラインにすることで、開発者とエクステンション製作者は新しいPHP機能を使え、テスト対象の環境も減らせる。WooCommerceはすでにPHP 8以上での動作を長年サポートしてきた実績がある。
今回の変更は、最低ラインを引き上げて将来のリリースの土台を作るものだ。コミュニティからのフィードバックを受けて、対象リリースをWooCommerce 11.6に設定した。繁忙期の後に十分なテストとアップグレードの時間を確保できるよう配慮されている。
デモで示したように、最低要件の引き上げは単なる制限強化ではなく、開発基盤を健全化するための措置だ。PHP 8.1以降には型システムの改善やJITコンパイラの成熟など、パフォーマンスと保守性の面で有利な機能が揃っている。
WooCommerce 11.3で表示される警告通知
WooCommerce 11.3から追加される通知は、PHP 7.4または8.0で稼働するストアの管理画面にのみ表示される。現在のPHPバージョンを表示し、ホスティング事業者にアップグレードを相談するよう案内する。通知は閉じられる仕組みで、11.3の利用自体は従来のPHPでも継続できる。
通知の役割はあくまで予告だ。実際に最低要件が変わるのはWooCommerce 11.6がリリースされたタイミングになる。それまでは通常どおり11.3、11.4、11.5へと更新を続けられる。
通知を閉じた後でPHPバージョンを確認したい場合は、管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認すればよい。ホスティング環境が更新済みなら、WooCommerceの推奨はPHP 8.3以上だ。
通知を確認した後の移行手順
通知が表示されたストアは、以下の手順でPHPアップグレードを進める。焦らず、ステージング検証を挟むのが安全だ。
PHPバージョンの確認
管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認する。PHP 7.4または8.0が表示された場合は、移行の対象になる。WooCommerceのPHPアップデートガイドも参考になる。
ステージング環境での検証
バックアップを取得し、ステージング環境でPHP 8.3以上に切り替える。決済と支払い方法、配送計算、税計算、注文管理、スケジュールジョブ、テーマ、拡張機能、カスタムコードを一通り検証する。互換性の問題があれば、本番を変更する前に解決する。
本番環境の切り替えと確認
ステージングで問題がなければ本番を切り替え、再度「WooCommerce」→「ステータス」と重要フローを確認する。その後、WooCommerce 11.6への更新が可能になる。
ステージング検証は省略しがちだが、決済や配送計算の不具合は売上に直結する。特に拡張機能やカスタムコードを多用するストアでは、本番前に必ず検証したい。
アップグレードが間に合わない場合の選択肢
WooCommerce 11.5はPHP 7.4と8.0に対応する最後のリリースになる予定だ。ホスティングや拡張機能の制約で移行が遅れる場合は、11.5に留まって作業を進められる。WordPressはPHP要件を満たさないプラグインの更新を通常ブロックするため、11.6への更新はサーバー側のPHPバージョンが8.1以上になるまで制限される。
11.5に留まるのは一時的な選択肢だ。WooCommerceのセキュリティパッチサポートポリシーでは、CVSS 9以上の重大な脆弱性の修正は、直近21メジャーリリースシリーズにバックポートされる。しかしそれ以外の修正は最新版にしか提供されない。加えてPHP 7.4と8.0自体のセキュリティサポートも終了しているため、WooCommerceのパッチだけではランタイムのリスクを解消できない。
移行が遅れる理由として、特定の拡張機能がPHP 8.1以上に対応していないケースがある。その場合は拡張機能開発者に互換性の状況を確認し、代替手段を検討するのが現実的な対応だ。
ストアと拡張機能への影響範囲
利用統計から見る影響
WooCommerceが公開した統計によると、追跡対象ストアの約7％がPHP 7.4、約2％がPHP 8.0で稼働している。直近1年間にWooCommerceを更新したストアに限ると合計約6％で、この数値は継続的に減少している。実際に要件が変わる2027年2月にはさらに低くなると見られる。使用状況の追跡はオプトイン方式のため、この数値はサンプルであり全ストアの正確なカウントではない。
拡張機能マーケットの静的解析
WooCommerceは全拡張機能マーケットプレイスを対象にPHP 8.1互換性の静的解析を実施した。購入可能な1,357個の拡張機能のうち、0.22％に潜在的な問題が見つかり、開発者と手動で確認中だ。ただしこのスクリーニングはすべての拡張機能、テーマ、カスタム統合の動作を保証するものではない。各ストアは自分の環境でテストする必要がある。
拡張機能開発者と制作会社向けには、WooCommerce 11.6が使うPHP 8.1と推奨PHPバージョンの両方でテストするよう案内がある。互換性の問題を見つけた場合は、PHPとWooCommerceのバージョン、影響する拡張機能、再現手順をGitHubのイシューかコメントで共有することが推奨されている。
影響範囲は限定的だが、該当するストアにとっては計画的な移行が欠かせない。PHPアップグレードは早めに着手し、繁忙期に入る前に完了しておくのが安全だ。
この記事のポイント
- WooCommerce 11.6からPHP 8.1以上が必須になり、11.3で警告通知が追加される
- PHP 7.4と8.0は公式セキュリティサポートが終了しており、移行は不可避だ
- 11.5までは従来のPHP環境で更新可能だが、あくまで一時的な選択肢だ
- 移行前にはバックアップとステージング検証を必ず実施する
- PHP 8.3以上への更新がWooCommerceの現在の推奨だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.1.2リリース！商品ギャラリーの無限再帰とメールレビュー検証を修正
WooCommerce 11.1.2が2026年9月22日にリリースされた。商品バリエーションギャラリーで発生する無限再帰の修正と、メール経由の商品レビューにおける入力検証の強化が含まれるドットリリースだ。
今回の更新はセキュリティ更新に該当する。データベースの更新は不要で、適用のハードルは低い。ECサイト運営者は早めのアップデートを検討したい。
WooCommerce 11.1.2のリリース概要
WooCommerceのドットリリースとは、メジャーバージョンやマイナーバージョンの間に挟まれる小規模な修正更新のことだ。新機能の追加はなく、既知の不具合修正とセキュリティ強化に絞られる。
今回の11.1.2は、2026年9月22日に公開された。公式のリリースノートによると、セキュリティ更新に該当し、データベース更新は不要とされている。つまり、プラグインの更新ボタンを押すだけで適用が完了する。
修正内容は2つに絞られている。1つ目は商品バリエーションギャラリーにおける無限再帰の防止、2つ目はメールベースの商品レビューにおける検証の厳格化だ。どちらもECサイトの安定稼働に直結する内容である。
商品バリエーションギャラリーの無限再帰を修正
1つ目の修正は、テーマがテンプレートファイル内で get_available_variations 関数を呼び出した際に無限再帰が発生する問題への対処だ。GitHubのプルリクエスト番号68939で修正されている。
無限再帰とは何か
無限再帰とは、関数が終了条件なしに自分自身を呼び出し続ける状態を指す。プログラミングの世界では「スタックオーバーフロー」と呼ばれるエラーにつながる。たとえるなら、合わせ鏡の間に立ったときに像が無限に反射して見えるのに似ている。どこかで止める仕組みがなければ、コンピュータのリソースを使い果たしてしまう。
WooCommerceの商品バリエーションギャラリーでは、テーマが独自に get_available_variations を呼び出すケースが問題になった。テーマのテンプレートファイルにこの関数の呼び出しが含まれていると、内部のフックが再帰的に呼び出されてスタックが溢れ、商品ページ全体が白画面になったり応答しなくなったりする。
修正の内容と影響範囲
修正後は、テーマが get_available_variations をテンプレートファイルで呼び出しても、再帰的な呼び出しが防止される。バリエーションごとの画像ギャラリーが正常に表示され、商品ページが通常どおり動作するようになる。
影響を受けるのは、バリエーション商品を持つECサイトで、なおかつテーマがこの関数を直接呼び出している場合に限られる。標準のWooCommerceテーマや多くの人気テーマでは問題は発生しない。しかし、独自にカスタマイズしたテーマを使っている場合は注意が必要だ。
get_available_variations をテンプレート内で呼び出すと、内部フックが再帰的に実行されてスタックが溢れる。商品ページ全体が白画面になり、購入フローが停止する。上図のとおり、修正前は get_available_variations の再帰呼び出しにより商品ページ全体が停止する可能性があった。修正後はこの再帰が防止され、ギャラリーが正しく表示される。独自テーマを運用している場合は、この修正の適用前にステージング環境で動作確認することを推奨する。
メールレビューの検証を強化
2つ目の修正は、メール経由で投稿される商品レビューの入力検証を厳格化するものだ。GitHubのプルリクエスト番号68961で対応された。セキュリティ更新とされる理由はこの修正にある。
メールベースのレビュー機能とは
WooCommerceには、購入者からのレビューをメールで受け付ける仕組みがある。顧客が注文後に届くメール内のリンクからレビューを投稿できる機能だ。ECサイトにとってレビューは信頼構築の要であり、この導線はコンバージョン率にも影響する。
問題は、このメール経由の投稿経路において入力値の検証が十分でなかった点だ。悪意のある第三者が不正なデータを送信する余地があり、セキュリティリスクになり得た。今回の修正では、この検証処理が厳格化されている。
検証強化がもたらす効果
検証の厳格化により、不正な入力や改ざんされたデータがレビューとして投稿されるリスクが低減される。レビューの信頼性が保たれ、ECサイトの評判管理にも好影響を与える。
店舗運営者の目線では、この変更によってレビュー投稿のフローに大きな変化はない。顧客が正規のメールリンクからアクセスする限り、従来どおりの手順でレビューを投稿できる。内部のバリデーションが強化されただけなので、ユーザビリティへの影響はない。
上図のとおり、メール経由のレビュー投稿は4段階で処理される。今回の修正はSTEP 3の検証処理に焦点を当てており、不正なデータの流入を防ぐ役割を担う。顧客側の操作フローに変更はない。
ECサイト運営者が取るべき対応
この更新はセキュリティ更新のため、基本的には即時適用が望ましい。ただし、独自テーマやカスタムコードを使っているサイトでは、事前の動作確認を怠らないことが重要だ。
更新前の準備
更新の前に、サイト全体のバックアップを取得する。WooCommerceを運用するECサイトでは、商品データ、注文履歴、顧客情報が失われると事業に直結する。更新作業の前には必ずデータベースとファイルの両方をバックアップしておく。
また、ステージング環境が利用できるのであれば、本番環境に適用する前に更新後の動作を確認する。特にバリエーション商品を持つ場合は、商品ページでギャラリーが正しく表示されるかをチェックしたい。
更新手順の目安
WooCommerceの更新はWordPressの管理画面から行える。プラグイン一覧からWooCommerceを選択し、更新を実行するだけだ。データベース更新が不要なため、更新後のマイグレーション処理も発生しない。
更新後は、商品ページ、カート、チェックアウト、レビュー投稿の各フローが正常に動作するかを確認する。特にメールレビュー機能を有効にしている場合は、テスト用のレビューを1件投稿して検証すると安心だ。
この記事のポイント
- WooCommerce 11.1.2は2026年9月22日に公開されたセキュリティ更新で、データベース更新は不要
- 商品バリエーションギャラリーの無限再帰を修正し、独自テーマ利用時の白画面リスクを解消
- メール経由の商品レビューにおける入力検証を強化し、不正データの投稿リスクを低減
- 独自テーマやカスタムコードを運用中のサイトは、ステージング環境での事前確認を推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1.1セキュリティリリース公開。11件の脆弱性修正と即時更新のすすめ
WordPress 7.1.1が2026年9月17日に公開された。セキュリティリリースと位置づけられ、11件の脆弱性修正を含む。コアのバグ修正は17件、ブロックエディタのバグ修正は19件だ。
今回のリリースはセキュリティ修正を主目的としている。すべてのサイト管理者に即時更新が推奨される。自動更新が有効なサイトでは、すでに適用が始まっている場合もある。
セキュリティリリースの最大の特徴は、放置した場合のリスクが高いことだ。XSS（クロスサイトスクリプティング）やパストラバーサルなど、攻撃者に悪用されかねない脆弱性が多数修正されている。サイトを守るには更新が最優先となる。
WordPress 7.1.1リリースの概要
WordPress 7.1.1は「ショートサイクルリリース」と呼ばれる短い間隔で提供される更新だ。メジャーリリースの7.1から間もない段階で、セキュリティと安定性の向上を目的に公開された。次のメジャーリリースは7.2で、12月を予定している。
今回の修正内容は、コア17件、ブロックエディタ19件、セキュリティ11件の合計47件にのぼる。セキュリティ修正が全体の約4分の1を占めており、いかにセキュリティ面が重視されたリリースかがわかる。
セキュリティリリースの最大の特徴は、対応の緊急性だ。通常の更新と異なり、脆弱性がすでに公開されている可能性があるため、更新を先延ばしにすると攻撃の標的になりやすい。公式発表でも「直ちに更新すること」が明記されている。
更新は管理画面から4ステップで完了する。自動更新が有効な環境では、手動操作なしで適用される。
修正されたセキュリティ脆弱性の詳細
11件のセキュリティ修正は、XSS、パストラバーサル、権限チェックの欠落、情報漏洩の4つに大別できる。それぞれ攻撃の仕組みや影響範囲が異なるため、サイト運営者は全体像を把握しておくとよい。
11件のセキュリティ修正を種類ごとに分類すると、XSS、パストラバーサル、権限チェック欠落、情報漏洩の4つに大別される。それぞれの詳細を確認していく。
XSS関連の重大修正
XSS（クロスサイトスクリプティング）とは、悪意のあるスクリプトをWebページに埋め込む攻撃手法を指す。閲覧者がそのページを開くとスクリプトが実行され、クッキーの窃取やセッションハイジャックなどの被害につながる。
今回修正された中でも特に注意が必要なのが、wpautop()関数の格納型XSSだ。コメントを処理する際に悪意のあるスクリプトが保存され、コメントが承認されると訪問者のブラウザ上で実行される可能性があった。報告者はAwesome MotiveのRafie Muhammad氏だ。
カスタムヘッダーをサポートする一部テーマでも、同様の格納型XSSが確認された。テーマの機能を利用してスクリプトが保存され、後から閲覧したユーザーに影響が及ぶ構造だった。こちらはWordPressセキュリティチームのJeremy Felt氏が報告した。
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ディレクトリのバックアップを取ってから更新するのが安全策だ。
更新前にバックアップを取り、更新後にサイト表示を確認する流れが安全だ。セキュリティリリースは緊急性が高いが、手順を守って適用する。
バックポートとサポート対象
今回のセキュリティ修正は、WordPress 4.7まで遡ってバックポートされる。バックポートとは、最新版で修正された内容を古いバージョンにも適用することで、セキュリティ対策を広範囲に届ける仕組みだ。
ただし、公式にアクティブサポートされているのは最新版のWordPressのみだ。古いバージョンを使い続けるのはセキュリティリスクが高いため、できるだけ早く最新版へ移行するのが望ましい。バックポートはあくまで移行期間の猶予として機能する。
バックポートは順次進められており、準備が整い次第リリースされる。対象バージョンを使用している場合も、最新版への更新を優先して検討するのが推奨される。古いバージョンはセキュリティ面だけでなく、機能面でも取り残されるためだ。
この記事のポイント
- WordPress 7.1.1はセキュリティリリースで、11件の脆弱性修正を含む
- 格納型XSSやパストラバーサルなど、悪用リスクの高い問題が修正された
- コア17件とブロックエディタ19件のバグ修正も含まれる
- すべてのサイト管理者に即時更新が推奨される
- バックポートは4.7まで提供されるが、最新版への移行が最優先
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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と改善点
キーボードショートカットを宣言的に定義可能に
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パッケージが公開された。
kebabCase(‘font2xl’) → font2xl
kebabCase(‘white4th’) → white4th
kebabCase(‘font2xl’) → font-2-xl
kebabCase(‘white4th’) → white-4th
このデモで示したように、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の展望
WordPress PlaygroundがWebMCPに対応した。これはAIエージェントが呼び出せるツールとしてブラウザ内のアクションを公開する草案APIだ。PlaygroundはWordPressをネストされたiframeで実行するため、新しいプロキシが埋め込みサイトのツールを外部ページに広告し、呼び出しを転送する仕組みになっている。
さらに、Playground上でWordPress 0.7まで遡って実行できるようになった。設定パネルで「Include older versions」にチェックを入れると、6.2までの全バージョンが選択肢に含まれる。PHPのバージョンも自動的にペアリングされるため、「いつこの機能が壊れたのか」を確認する用途に役立つ。
このタイムラインで示したように、WordPress 7.2の開発サイクルは約2ヶ月にわたって進行する。開発者向け機能の実装状況を確認しながら、互換性の検証を進めるのが良いだろう。
この記事のポイント
- コードリファレンスがブラウザ上でコード実行に対応、Playgroundを使った動作確認が可能になった
- ブロックのキーボードショートカットを宣言的に定義するAPIが追加された
- インナーブロックテンプレートはブロックタイプ設定への移行が推奨される
- theme.jsonのスキーマ修正とスタイルUIの制御オプションでテーマ開発が改善された
- WordPress 7.2は12月8〜10日に正式リリース予定、Beta 1は10月20〜22日
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Salesforce Winter ’27、マーケターが押さえるべき10の変更点
SalesforceのWinter ’27リリースにおける主要アップデートが公開された。マーケティング担当者に影響が大きい変更点は10項目あり、Agentforceによるキャンペーン自動化からボット調整済みクリック率まで幅広い。本記事では、ECやB2Bのマーケティング運用に関わる担当者向けに、各アップデートの実務的な意味を整理する。
Winter ’27は2026年8月下旬にプレビューサンドボックスへ展開され、本番環境へのリリースは9月4日、10月2日、10月9日の週末に段階的に行われる。Salesforceによると、全機能の一般提供は10月12日を予定している。組織が利用するインスタンスや製品によって更新日は異なるため、自社のリリーススケジュールを確認しておきたい。
Agentforceがキャンペーン運用を自動化する
Winter ’27で最も注目されるのは、Agentforce関連の新機能だ。マーケティング担当者の日々の業務を自動化するエージェントが複数追加された。特に影響が大きいのが、キャンペーン作成とリード育成を担う2つのエージェントである。
キャンペーン作成エージェントの実務インパクト
Salesforceは戦略立案からコンテンツ作成までを自動化するキャンペーン作成エージェントと、大量のリード獲得・育成に特化したエージェントを投入した。これまで単一の戦略をメール、SMS、ランディングページなど複数チャネルに展開する作業は、ツール間を行き来する煩雑なオペレーションになりがちだった。エージェントが一連の作業を引き受けることで、担当者は承認と戦略判断に集中できる。
このデモはキャンペーン運用の変化を概念的に示したものだ。実際のAgentforceはメールやSMS、ランディングページ向けのコンテンツを自動生成し、人間の承認を経て配信する。営業部門とマーケティング部門の往復が減ることで、キャンペーン立ち上げのスピードが大きく変わる。
メールに返信できる双方向エージェント
もう一つの注目機能は、マーケティングメールへの返信にAgentforceがリアルタイムで応答する「双方向メール」だ。従来のマーケティングメールは一方的な配信が基本で、見込み客が返信しても未対応のまま放置されることがあった。新機能ではエージェントが自動応答し、必要に応じてオムニチャネル受信箱を通じて人間の担当者へ引き継ぐ。購買意欲が高いタイミングで会話を始められる点が重要だ。
データ基盤と配信品質を強化する変更点
マーケティング成果の土台となるのが、データの正確さと配信の到達性だ。Winter ’27ではこの領域に複数の改善が入った。
メール到達性をリアルタイムで監視
Marketing Cloud NextとAccount Engagementのユーザー向けに、配信ボトルネックをリアルタイムで検出し、即座に解消するツールが追加された。これまで配信問題はキャンペーン終了後に発覚することが多く、ドメイン評価を傷つけてから対策するケースが少なくなかった。新機能は配信前に問題を検知し、対策を促す。
配信到達性はすべてのキャンペーン投資の前提になる。メールが届かない状態でクリエイティブやセグメントを改善しても成果には結びつかない。今回の変更で、配信インフラの健全性を維持しやすくなった。
重複プロフィールを減らすID解決ルールの拡張
データ品質の面では、ID解決ルールが拡張された。あいまいな名前表記を正規化し、メールアドレスや電話番号、住所を組み合わせて同一人物を判定するデフォルトのマッチングルールが追加されている。重複プロフィールはオーディエンス数を歪め、同じ相手に重複メッセージを送るコストを生む。プロフィール統合の精度が上がることで、セグメント設計やAIモデルの学習データが健全になる。
マーケティング運用をAIで効率化する
Winter ’27では、日常的な管理業務を自然言語で操作できる仕組みも拡充された。マーケティングオペレーション担当者の負荷を下げる変更だ。
MCPサーバーに40個の新ツール
Marketing Cloud EngagementのMCP（Model Context Protocol）サーバーに40個のツールが追加された。AIアシスタントがオートメーションの管理、コンテンツフォルダの整理、レコード操作などを実行できるようになる。これまではプラットフォーム管理やクエリ作成に専門知識が必要で、熟練スタッフの工数を毎週のように消費していた。自然言語で指示できる範囲が広がることで、経験豊富な人材はアーキテクチャ設計や戦略立案に集中できる。
このフローはMCPツールを活用した運用の一例である。実際にはMarketing Cloud Engagementの管理画面からAIアシスタントに指示を出し、裏側でMCPサーバーが対応するツールを呼び出す形になる。
コンテンツの再利用とパーソナライズ
チャネル横断コンテンツの管理も改善された。スクリプトベースのパーソナライズ、再利用可能な動的コンテンツブロック、一元管理できるブランドセンターが追加される。メール、SMS、ランディングページごとに似たメッセージ資産を作り直す運用は、コンテンツ負債とブランド不統一を生みやすい。一元化された資産を使えば、キャンペーン立ち上げが速くなり、すべての顧客接点でパーソナライズを一貫して適用できる。
レポートとプライバシー管理の精緻化
マーケティング成果を正しく測るための変更も入った。ボットによるクリックの除外と、トラッキングの細かい制御が主なポイントだ。
ボット調整済みクリック率
B2B Analytics for Marketersに加えて、クリック率レポートに自動ボットフィルタリングが導入された。セキュリティスキャナーなどの自動アクセスがクリック数を水増しすると、実際の見込み客がどのキャンペーンに反応したか分からなくなる。ボットを除外したクリーンなレポートにより、予算配分や最適化の判断を実際のオーディエンスデータに基づいて行える。
開封・クリック追跡の細かい制御
ビジネスユニット単位で、開封、リンククリック、高度な指標のトラッキングを個別にオン・オフできるようになった。地域ごとのコンプライアンス要件や社内のリスク許容度に合わせて、データ収集の範囲を調整しやすくなる。法務・コンプライアンス部門との連携がスムーズになり、顧客との長期的な信頼構築にもつながる。
このデモは設定の自由度を示す概念図である。実際には管理画面のトグルで各指標のトラッキングを個別に切り替える。
その他の管理機能アップデート
上記10項目以外にも、管理面のアップデートが複数含まれている。組織の構成によっては影響が大きいものもあるため、簡単に触れておく。
- 電話番号を非表示にしているユーザー向けのWhatsAppメッセージングサポート
- 複数アカウントのMarketing Cloudを単一のData Cloudインスタンスに接続するWhatsApp向け機能
- ユニークなクーポンコードと事前設定済みの小売ジャーニートリガー
- Journey Builderの判定スプリットに関する診断ログ
- 一括削除とコンテンツ整理ワークスペースの強化
- セキュリティダッシュボード、クライアントシークレット管理、フィッシング耐性認証
- プライバシー監査向けのデータ拡張アクセスログ
- Automation Studioにおける大文字小文字を区別しないファイル名トークン
Winter ’27にはセキュリティ関連のアップグレードも含まれている。管理チームは自社の設定に影響がないか、リリースノートの確認を推奨する。
この記事のポイント
- Agentforceがキャンペーン作成からメール返信までを自動化し、担当者は戦略に集中できる
- 配信到達性のリアルタイム監視とID解決ルールの拡張で、マーケティングの基盤が強化された
- MCPサーバーのツール追加により、自然言語での管理業務が拡大した
- ボット調整済みクリック率と細かいトラッキング制御で、レポート精度とプライバシー対応が両立する
- Winter ’27の一般提供は2026年10月12日を予定しており、組織ごとのリリース日程を確認する必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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では店舗運営者に直接影響する機能追加と、開発者向けの内部改善が同時に行われた。本番サイトへの適用前には公式の更新ガイドとチェンジログを確認することが推奨されている。
店舗運営者に影響する変更は3つある。1つ目は商品バリエーション画像ギャラリーの標準搭載、2つ目はEU顧客向け注文撤回フォームの追加、3つ目は仮想商品の管理画面表示の改善だ。これに加えて商品ギャラリーへの動画対応がベータ機能として導入された。
開発者向けにはブロックエディタアセットの統合、ブロック登録処理の最適化、注文アイテム削除ロジックの修正などが含まれる。特にStore APIとREST APIの応答速度は30%から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に更新すれば全ストアで利用できる。
専用プラグインが不要になり、バリエーション画像ギャラリーはWooCommerceの標準仕様となった。既存の専用プラグインユーザーも移行作業なしでそのまま利用できる。
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%向上した。
このデモはAPIリクエスト時の処理フロー変化を示している。ブロック登録の最適化は店内回遊の速度向上ではなく、外部連携やヘッドレス構成での応答性能に直接効く変更だ。
EU顧客向け注文撤回フォームの追加
WooCommerce 11.1.0ではEU圏の規制に準拠するための「注文撤回フォーム」が追加された。デフォルトでは無効になっており、EUガイドラインへの準拠が必要なストアが手動で有効化する形だ。
注文撤回とはEUの消費者保護規則に基づく権利で、消費者が商品を受け取ってから一定期間内に購入をキャンセルできる仕組みだ。ストア側はこの権利に応じた返金・返品プロセスを用意する必要がある。今回追加されたフォームは、その撤回申請を顧客自身がオンラインで提出するための画面をマイアカウントページに作成する。
撤回申請が提出されるとシステムに記録され、ストア運営者にはメール通知と管理画面のダッシュボード通知が送られる。ただし実際の注文撤回処理と返金作業は手動で行う必要がある。各ストアのポリシーや商品特性によって処理手順が異なるためだ。
注文撤回フォームはデフォルト無効のため、通常の国内向けストアでは追加設定は不要だ。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顧客向け注文撤回フォームが追加された（デフォルトでは無効）
- 商品ギャラリーの動画対応はベータ機能としてデフォルト無効で提供される
- 仮想商品のみの注文では管理画面に配送先住所が表示されなくなった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験