WordPress 7.1 Mary Louリリース。レスポンシブ対応強化と新メディアエディタ搭載
WordPress 7.1「Mary Lou」が2026年8月19日に正式リリースされた。今回のメジャーアップデートでは、カスタムCSSなしでレスポンシブ対応ができるスタイル機能、新しいメディアエディタ、リッチテキスト対応のNotes機能などが追加されている。800人以上の貢献者による1,500以上の改良と修正が含まれる大規模リリースだ。
従来のWordPressでは、画面サイズごとに表示を調整するにはカスタムCSSを書く必要があった。WordPress 7.1ではサイトエディタ内で完結するため、中小企業のサイト担当者やコーディングに不慣れなユーザーでも直感的にレスポンシブ対応できるようになる。画像処理のブラウザ内実行や新ブロックの追加も見逃せない変更点だ。
WordPress 7.1の全体像と主要な新機能
WordPress 7.1のコードネーム「Mary Lou」は、ジャズピアニストのメアリー・ルー・ウィリアムズに由来する。彼女はスウィング、ビバップ、セイクリッドジャズとジャンルを横断しながら常にサウンドを再発明し続けた。その革新と協働の精神が今回のリリースに反映されている。
リリース全体の規模を見ると、世界中から800人以上の貢献者が参加し、170人以上が初めてコントリビュートした。修正と改良の総数は1,500を超える。主要な変更点は、レスポンシブスタイルのビジュアル編集、管理バーの全エディタ対応、新しいメディアエディタ、Notes機能の拡張、PlaylistとTabsの2つの新ブロック、そして開発者向けAPI群の公開だ。
このデモでは、WordPress 7.1の主要な変更点を分野別に色分けして示している。青がレスポンシブ対応、橙がメディア編集、紫がコラボレーション、緑がパフォーマンス、赤が新ブロックを表す。
今回のリリースの特徴を一言でまとめると、「サイト制作の作業導線を管理画面内に集約する」方向性が鮮明になったことだ。従来はCSSファイルの編集や複数の画面を行き来する必要があった作業が、ブロックエディタやサイトエディタの中で完結するようになっている。特に中小企業のサイト担当者にとっては、外注や開発者への依頼なしで調整できる範囲が広がる。
レスポンシブスタイルと管理バーの改善
カスタムCSSなしのレスポンシブ対応
WordPress 7.1では、サイトエディタのグローバルスタイルと個別ブロック設定の両方にレスポンシブコントロールが追加された。具体的には、デスクトップ・タブレット・モバイルの各画面サイズでブロックの表示をどう変えるかを、ビジュアル操作だけで設定できる。
編集中の画面でビューポート（表示領域の幅）を切り替えながらスタイルを調整できるため、仕上がりを確認しやすい。従来のようにカスタムCSSでメディアクエリを手書きする必要がない。この変更は、コーディングに不慣れなユーザーにとって特に大きな意味を持つ。
このデモでは、従来のカスタムCSSによる対応と、WordPress 7.1のビジュアル編集による対応の違いを示している。上段の赤い枠がBefore、下段の緑の枠がAfterを表す。CSSの記述が不要になり、プレビューを見ながら調整できるようになった点が大きな変化だ。
管理バーがすべてのエディタで表示される
管理バーがサイトエディタを含むすべてのエディタで追従するようになった。投稿執筆中でもサイトデザインの編集中でも、ダッシュボードや関連ツールへのショートカットが常に画面上部に表示される。WordPressの管理画面を行き来する手間が減り、作業導線が分断されにくくなった。
さらに、ブロックテーマではテーマの設定ファイル（theme.json）にタブレットとモバイルのブレークポイントを独自に定義できるようになった。レスポンシブスタイルとブロック表示の切り替えに使う画面幅の基準を、サイトごとに調整できる。
メディア編集の刷新と画像処理の高速化
新しいメディアエディタ
従来はインラインで行われていた画像の切り抜きが、新しいモーダル形式のメディアエディタに置き換わった。自由な切り抜き、アスペクト比を固定した切り抜き、水平・垂直の反転、細かな角度調整ができるスナップ回転、そしてメタデータ編集が1つの専用画面に統合されている。
エントリーポイントは従来と同じ「切り抜き」ボタンのまま。既存の操作感を維持しつつ、機能が大幅に拡張されたかたちだ。画像編集のためにプラグインを追加していたユーザーにとっては、標準機能だけで済むケースが増える。
このデモは、新しいメディアエディタの操作手順を4ステップで示している。青・緑・橙・紫の順に進み、1つのモーダル内で画像編集からメタデータ更新まで完結する流れが分かる。
ブラウザ内での画像処理
画像の圧縮・リサイズ・サムネイル生成が、サーバーではなくブラウザ内で実行されるようになった。libvipsのWebAssemblyビルドを利用しており、大きな画像をアップロードしてもPHPのメモリ制限やアップロードタイムアウトに引っかかりにくくなる。
サーバー負荷の軽減は、共有サーバーや低スペックのレンタルサーバーを利用しているサイトにとって特に有効だ。画像の多いメディアサイトやECサイトでは、アップロード時のタイムアウトエラーが減ることが期待できる。
対応画像形式も拡充された。AVIF、HEIC、HDRゲインマップのネイティブサポートが追加され、最新のスマートフォンやカメラで撮影した画像をそのまま扱えるようになった。GIFを動画に自動変換するオプションもあり、ファイルサイズの削減が進む。
Notes機能の進化とコラボレーション強化
WordPress 7.1では、コンテンツのレビュー作業を支援するNotes機能が大幅に拡張された。従来はブロック単位でしかコメントを残せなかったが、今回から特定のテキスト範囲に対してノートを付けられるようになった。
リッチテキストにも対応した。太字、斜体、コード表示、リンクの挿入がノート内で使える。さらに「@」を入力すると共同編集者をメンションでき、通知が飛ぶ。複数の会話を同じブロック内で並行して進められるほか、長いノートを折りたたんでサイドバーをすっきり保つことも可能だ。
この機能強化は、複数人で記事をレビューする編集部や、クライアントとの校正作業を行う制作会社にとって実用的な価値がある。フィードバックの場所が明確になり、メールやチャットでのやり取りをWordPress内に集約できる。
執筆中の投稿エディタも全テーマでiframe化された。編集キャンバスが管理画面のスタイルから分離されるため、テーマのCSSが管理画面のスタイルと衝突しにくくなる。ビューポート単位やメディアクエリが編集キャンバスを正確に参照するようになり、レスポンシブレイアウトのプレビュー精度が向上した。
新ブロックと開発者向けAPIの拡充
PlaylistブロックとTabsブロック
WordPress 7.1では2つの新しいブロックが追加された。Playlistブロックは複数の音声トラックを1つのプレイリストにまとめて再生できる。オプションで波形表示も付けられ、リスナーは各トラックの長さや進行具合を視覚的に把握できる。
Tabsブロックは、関連する情報をタブ形式で整理するためのブロックだ。すべてのコンテンツを一度に表示するのではなく、タブを切り替えて必要な内容だけを見せる。FAQ、料金プランの比較、製品仕様など、関連情報をコンパクトに提示したい場面で役立つ。
開発者向けAPI群
開発者向けの変更も大きい。SVG Icon APIが公開APIとなり、wp_register_icon_collection()、wp_register_icon()、wp_get_icon()といった関数で独自のアイコンコレクションを登録し、エディタ全体で利用できるようになった。
Abilities APIは前バージョンで導入された基盤を拡張し、フィルタ可能な実行ライフサイクル、カスタムバリデーション、共有ディスカバリーを追加した。WordPress上での統合機能や自動化、AI搭載ツールの構築が容易になる。
新しいDesign Systemは、色、角丸、カーソルスタイルを含むWordPress管理画面のテーマリングを支援する。開発者はセマンティックなデザイントークンとThemeProvider Reactコンポーネントを使って、WordPressに馴染むカスタム管理画面を構築できる。
テーマ開発者には、theme.jsonでレスポンシブスタイルと疑似状態（hover、focus、focus-visible、active）のスタイリングが可能になった。DataViewsとDataForm画面を設定する新しいフィルタも追加され、サイトエディタのページ・テンプレート・パーツ管理画面をカスタマイズできる。
パフォーマンスとアクセシビリティの改善
パフォーマンス面では、前述のブラウザ内画像処理に加えて、GIFから動画への自動変換が導入された。GIFアニメは動画ファイルよりサイズが大きくなりがちで、この変換によりページの読み込み速度が改善する。アップロードの進捗インジケーターと自動リトライも追加され、接続が途中で切れてもアップロードが再開できるようになった。
メディアライブラリはデフォルトで無限スクロールになった。ページネーションに戻すオプションもユーザーごとに用意されている。多数の画像を扱うサイトでは、ページを切り替える操作なしで目的のメディアを探しやすくなる。
Speculative loadingのデフォルト設定を、環境変数や定数で指定できるようになった。ホスティング事業者やサイト運営者は、プラグインを書かずにWordPressの先読み動作を設定できる。これはサイト速度の調整手段として、特にトラフィックの多いサイトで有用だ。
アクセシビリティの改善も続いている。wp_get_tooltip()とwp_get_toggletip()という新しい関数が追加され、投稿メタボックスやログイン画面を含む管理画面の各所でアクセシブルなツールチップを利用できるようになった。スクリーンリーダーのサポートも強化され、投稿一覧テーブルでのラベル付けとナビゲーションがより予測しやすくなっている。
この記事のポイント
- WordPress 7.1「Mary Lou」が2026年8月19日にリリースされた
- カスタムCSSなしでレスポンシブスタイルを設定できるようになった
- 新しいメディアエディタが切り抜き・反転・回転・メタデータ編集を統合
- 画像処理がブラウザ内で実行され、サーバー負荷とタイムアウトが軽減された
- Notes機能がリッチテキストとメンションに対応し、コラボレーションが強化された
- PlaylistブロックとTabsブロックが標準搭載された
- 開発者向けにSVG Icon API、Abilities API、Design Systemが公開された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
EUのAIラベリング規則が8月2日施行。サイト運営者が知るべき4つの義務
EUでAI生成コンテンツのラベリング義務が2026年8月2日から始まった。対象はディープフェイク、チャットボット、完全AI生成テキスト、感情認識ツールの4種類に絞られる。
この規則はEU企業に限らない。EU圏のユーザーにAI出力を提供する世界中の企業が対象になる。つまり、日本語のサイトでもEUからのアクセスがあれば義務を負う可能性がある。
違反時の罰則は各国の監督機関が定めるが、GDPRと同様に高額な制裁金が科される可能性がある。AI生成コンテンツを公開するサイト運営者は、対象範囲と正しい表示方法を押さえておきたい。
ラベリング義務の対象は4つに絞られる
EUのAI法第50条(4)に基づく透明性義務では、ラベリングが必要なケースを4種類に限定している。すべてのAI生成コンテンツにラベルが必要なわけではない点が重要だ。
この4つのカテゴリに該当するAI生成物を提供する企業は、プロバイダー（AIシステムの開発・供給者）とデプロイヤー（利用者）の双方が法的義務を負う。外部製AIツールを使っていても免責にはならない。
ディープフェイクは「本物らしさ」が判断基準
ディープフェイクに該当するのは、実在の人物、物体、場所、出来事に似せていて、本物だと誤認させる画像・音声・動画だ。逆に、明らかにフィクションとわかるものや、本物らしく見せていないコンテンツは対象外になる。
広告やマーケティングで使うAI生成の商品画像、人物写真、ポスターも、実在のものに似せている場合は開示が必要になる。特にECサイトの商品画像には注意したい。
完全AI生成テキストは「公共の利益」が条件
完全にAIが書いた文章のラベリング義務は、公共の利益に関する事項が対象だ。公共の利益とは、健康、安全、環境、経済、金融、政治、科学、文化などを指す。人間による実質的な編集がない場合に開示が必要になる。
通常のブログ記事や商品説明でも、内容が健康や金融など公共性の高いテーマに触れる場合は対象になり得る。一方、単なる日記や創作は対象外だ。
人間が編集すればラベル不要になる境界線
「AIで下書きを作り、人間が編集した」場合、どこからラベルが必要になるのか。EU委員会のガイダンスでは、軽微な編集と実質的な編集の境界線が示されている。
文章の言い回しを微調整する程度ならラベル不要だが、文章全体をAIに生成させた場合は開示が必要になる。「公開前に人がざっと目を通した」だけでは実質的な編集とは認められない。
実務での判断ポイント
EUのガイダンスは、編集責任者を明示した上で実質的な編集管理を行うことを求めている。つまり、誰が責任を持って内容を確認し、修正したのかという記録が重要になる。
WordPressサイトでAI生成下書きを使う場合は、編集フローを整備しておくとよい。人間による確認作業を経た記事と、AI出力をそのまま公開する記事を区別し、後者にはラベルを付ける運用が現実的だ。
スパークルアイコンだけでは不十分
多くの製品がAI機能を示すために使うスパークル（✨）アイコンは、EUの要件を満たさない可能性が高い。スパークルは「AI搭載機能」という意味で使われることが多く、「この特定のコンテンツがAI生成」という意味にはならないからだ。
EUは公式のAIアイコンセットを公開している。これは「AI」の文字を含む専用バッジで、スパークルとは異なる。ただし、アイコンを使うだけでは法的準拠にはならない。アイコンは明確に見え、プレーンテキストと併用し、支援技術からアクセスできる必要がある。
適切なラベルの表示方法
EUのガイドラインでは、アイコンが小さすぎる、フッターに埋もれている、一瞬だけ表示される、といったパターンはすべて不適合とされる。ラベルはコンテンツの近くに常時表示し、共有やダウンロード後も保持される必要がある。
サイトでAI生成画像を掲載する場合は、画像の近くに「AI生成」というテキストラベルを置くのが現実的だ。altテキストにも「AI生成画像」と記載しておくと、スクリーンリーダー利用者にも伝わる。
世界で同時多発するAIラベリング規制
今回のEU規則は単独の動きではない。中国、カリフォルニア州、韓国、インドでも同様のAIラベリング規制が相次いで施行されている。
- 中国では2025年9月1日からAIコンテンツの表示義務が始まっている
- 米カリフォルニア州のSB 942はEUと同じ2026年8月2日に施行された
- 韓国ではAI基本法が2026年1月22日に施行され、ディープフェイク表示を義務化
- インドではIT規則改正により2026年2月20日から合成情報のラベル表示が必須になった
各国の規制は細部が異なるが、方向性は同じだ。AIが生成したコンテンツが人間の制作物と誤認される場合、明確に開示するという共通パターンが浮かび上がる。
サイト運営者が今からできる準備
AI生成コンテンツを扱うサイト運営者は、まず自社サイトでどの部分がAI生成に該当するかを棚卸しするところから始めたい。特に、商品画像、チャットボット、自動生成されるブログ記事、AIによる要約表示などが対象になる。
次に、ラベルの表示ルールを整備する。AI生成コンテンツには「AI生成」というテキストラベルと公式アイコンを併用し、目立つ位置に配置する。WordPressの場合はテーマのテンプレートやカスタムフィールドを使って、AI生成フラグを管理する方法もある。
最後に、編集フローを文書化しておく。人間が実質的に編集した場合と、AI出力をそのまま使った場合を区別し、後者だけにラベルを付ける運用にすると、無駄なラベル表示を避けられる。
この記事のポイント
- EUのAIラベリング義務は2026年8月2日から施行され、EU圏のユーザーにAI出力を提供する全世界の企業が対象
- ラベリングが必要なのはディープフェイク、チャットボット、完全AI生成テキスト（公共の利益）、感情認識ツールの4種類
- 人間が実質的に編集したAI生成コンテンツは開示不要。軽微な編集はAI生成に該当しない
- スパークルアイコンだけでは不十分。公式アイコンと「AI生成」というテキストラベルを併用する
- 中国、カリフォルニア、韓国、インドでも同様の規制が始まっており、サイト運営者は早めの対応が求められる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1正式版が8月19日リリース。レスポンシブスタイルと疑似状態の全容
WordPress 7.1の正式版が2026年8月19日にリリースされる。WordCamp US最終日と重なるタイミングで、すでにRC1とRC2が公開され、機能セットは確定済みだ。先月にはセキュリティリリース2件も出ており、影響を受けるサイトは自動更新が強制された。
今回のアップデートで注目が大きいのは、レスポンシブブロックスタイルと疑似状態スタイルのコア導入だ。テーマ開発者はモバイルとタブレットの表示をtheme.jsonだけで制御できるようになる。プラグイン開発者もリストテーブルの構造変更に注意が必要だ。正式版まで残り数日、互換性確認のポイントを解説する。
WordPress 7.1は8月19日リリース、RC2まで公開済み
正式版はWordCamp US最終日に到着
WordPress 7.1は8月19日にリリース予定だ。ちょうど8月16日から19日にかけて米国フェニックスで開催されるWordCamp USの最終日と重なる。年次フラッグシップイベントの最終日に正式版が出るのは珍しいスケジュールで、現地参加者はその瞬間をライブで目撃できる。
先週までにRC1とRC2が立て続けに公開された。RC（Release Candidate / リリース候補版）とは、正式版の一歩手前の段階だ。ここまで来ると新機能の追加は終了し、バグ修正だけが行われる。Field Guideも公開済みで、全機能の開発者向け詳細がまとまっている。
セキュリティリリース2件、強制自動更新も発動
先月はセキュリティリリースが2件公開された。7月17日に出たWordPress 7.0.2は、重大な脆弱性1件と高深刻度の脆弱性1件に対処したものだ。深刻度が高かったため、影響を受けるバージョンのサイトには強制自動更新が適用された。続いて8月6日には7.0.3が公開され、十数件の追加修正が入っている。
管理しているサイトが両方の自動更新を何らかの理由で逃していた場合、先にそちらの更新を済ませることが最優先になる。7.1のテストはその後でかまわない。
レスポンシブスタイルがコアに登場
上記の図は、theme.jsonでデスクトップ・タブレット・モバイルのパディングを切り替える様子を視覚化したものだ。実際には端末の画面幅に応じて、この3つの状態が自動的に切り替わる。
theme.jsonでモバイルとタブレットのスタイルを定義
春先から開発が進められていたレスポンシブスタイルが、WordPress 7.1で正式にコアに導入された。ブロックのスタイルをタブレットとモバイルのビューポートごとに定義できる。Global Styles（グローバルスタイル）ではブロックタイプ単位で、個別のブロック単位でも設定可能だ。theme.jsonでは@mobileと@tabletというキーの中にネストして記述する。
ここで押さえておきたいのは、@desktopキーが存在しない点だ。ブロックのデフォルトスタイルがそのままデスクトップスタイルになる。モバイルやタブレットで上書きしなかったプロパティは、すべてのビューポートでデフォルト値が適用される。
さらにテーマ側でブレークポイントを設定できる。theme.jsonのトップレベルにsettings.viewportプロパティを追加する仕組みだ。デフォルトはモバイルが480px、タブレットが782px。値はpx、em、remの非負の長さのみ許可され、CSS関数やパーセント、単位なしの値は無視される。タブレット値がモバイル値と同じか小さい場合は、モバイルのみが使われる。
標準ブロックサポートを使っているブロックは、タイポグラフィ、カラー、背景、ボーダー、寸法、スペーシング、レイアウトが自動的に対応する。逆に独自のスタイルコントロールを持つブロックは対象外だ。自作ブロックがある場合、この線引きで対応有無を確認してほしい。
疑似状態スタイルでホバーやフォーカスを制御
ホバーやフォーカスは実際の操作で状態が変わるため、上記は4つの状態を並べて示したものだ。実際の編集画面では「Hover」タブを選んでスタイルを設定する。
かねてから要望の多かった疑似状態スタイルも7.1で実装された。:hover、:focus、:focus-visible、:activeをtheme.jsonとエディタで定義できる。現時点ではButtonブロックとNavigation Linkブロックに限定されている。
さらに初期段階のカスタムステート機能も入った。現状はtheme.jsonのみで、管理画面のUIはまだない。Navigation Linkブロックが現在のメニュー項目をスタイルするために-currentプロパティを使う仕組みだ。カスタムステートは-接頭辞を使い、ブロックのblock.jsonにあるselectors.statesプロパティで宣言したクラス名をターゲットにCSSを生成する。現時点では限定的だが、今後の拡張に向けた重要な布石だ。
新しいデザインツール3点
テーマ開発者が長年待っていた変更を含む、デザインツールの追加が3つある。グラデーションと背景画像を同時に使えるようになるのは特に大きい。
背景グラデーションと背景画像を併用可能に
新しいbackground.gradientは既存のcolor.gradientとは別のサポートとして追加された。違いはCSSの出力先にある。従来のサポートはbackgroundショートハンドを通じて描画されるため、background-imageを含むすべてのbackground関連プロパティをリセットしてしまっていた。ブロックにグラデーションか画像のどちらか一方しか使えなかった理由だ。
新しいサポートはbackground-imageロングハンドで描画される。スタイルエンジンが1つの宣言内にグラデーションと画像をカンマ区切りで出力できるようになった。7.1ではGroup、Accordion、Pullquote、Post Content、Quoteがコアで対応する。値はstyle.background.gradientに保存される。
最小幅とテキストシャドウ
dimensions.minWidthは既存のminHeightと同じパターンで、CSSのmin-widthとして適用される。テーマがdimensionSizesプリセットを提供していれば、それを活用できる。1点注意があり、この設定はデフォルトではブロックインスペクターに表示されない。ブロック側で__experimentalDefaultControlsを通じてopt-inした場合のみ表示される。Global Stylesではデフォルトで表示される。
テキストシャドウもGlobal Stylesでサポートされた。これまでは個別ブロックやCSSでしか指定できなかったが、theme.jsonからサイト全体またはブロックタイプ単位で制御できる。
SVG Icon APIが正式公開
アイコン名の衝突を防ぐため、コレクション名が名前空間の接頭辞になる。プラグイン独自のアイコンを登録しても、コアのアイコンと混同される心配がない。
WordPress 7.0でエディタとIconブロック向けにSVGアイコンのセットが同梱された。7.1ではこれが正式な公開APIになり、プラグインやテーマから登録できるようになった。wp_register_icon_collection()でコレクションを登録し、wp_register_icon()でアイコンを追加する。PHPの任意の場所でwp_get_icon()を使えば、サイズやクラス、ラベルを指定してアイコンを表示できる。
計画時に意識したい制限が2つある。登録したSVGはwp_ksesによって保守的な許可リストでサニタイズされる。許可されるのは<svg>、<path>、<polygon>のみ。許可リストの拡大作業は進行中だ。fillは図形部分にのみ許可され、外側の<svg>には付けられない。またwp_get_icon()単体で呼び出すとSVG自身のfill（黒）で描画される。周囲のテキスト色に合わせたい場合は、渡したクラスに対して自前でCSSを指定するのが推奨される。
エディタのiframe化とプラグインへの影響
投稿エディタは常時iframe表示へ
テンプレートエディタがiframe化されたのはWordPress 5.8からだ。それ以来、投稿エディタも段階的に移行してきたが、7.1で最終段階に入った。テーマの種類や登録ブロックのAPIバージョン、コンテンツ内のブロックのAPIバージョンに関係なく、投稿エディタは常にiframeで表示される。レガシーメタボックスを登録しているサイトも同様だ。
7.0では投稿ごとに挿入されたブロックに基づいて判断されていた。つまりコンテンツによってiframedモードと非iframedモードが切り替わり得た。この条件付き動作がなくなり、挙動が単純化された。
大半のブロックは変更なしで動作する。問題が起きる場合、ほとんどは1つの根本原因にたどり着く。iframeは管理者ページとは別のdocumentとwindowを持つ。エディタスクリプトが実行される管理者ページからグローバルのdocumentやwindowにアクセスしてキャンバスを操作しようとすると、間違ったドキュメントを見ていることになる。対処としては、キャンバス内の要素からownerDocumentとdefaultViewでドキュメントを取得するか、useRefEffectでキャンバス要素にリスナーをアタッチ・クリーンアップするのが一般的だ。
リストテーブルの行ヘッダーが移動
カスタムCSSやJavaScriptを書いているプラグインにとって、静かに何かを壊す可能性が高いのがリストテーブルの変更だ。投稿一覧テーブルで、プライマリのth scope="row"がチェックボックス列からタイトル列に移動した。チェックボックスセルはtdになり、タイトルセルがthとして投稿タイトルを含むaria-labelを持つ。レスポンシブ表示で折りたたまれるセルはflexレイアウトを使うようになった。
これはアクセシビリティの大きな改善だ。スクリーンリーダーは各行を、場合によっては存在しないチェックボックスではなく投稿名で認識できるようになる。ただしこのマークアップは2010年以降ほぼ安定していたため、多くの拡張が暗黙的に依存している。th.check-columnを選択するCSSやJavaScript、td内の行アクションや投稿タイトルを期待するコードがある場合は確認が必要だ。
この記事のポイント
- WordPress 7.1は8月19日リリース予定、RC2まで公開済みで機能セットは確定
- セキュリティリリース7.0.2と7.0.3が先月公開され、強制自動更新も適用された
- レスポンシブスタイルがコアに入り、モバイルとタブレットのスタイルをtheme.jsonで定義可能に
- 疑似状態スタイルでホバー、フォーカス、アクティブをテーマから制御できる
- SVG Icon APIが公開され、プラグインが名前空間付きでアイコンを登録可能に
- 投稿エディタは常時iframe化され、リストテーブルの行ヘッダー移動も要確認
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressのdo_action()を見直す イベントをオブジェクト化し、フックをクラス名にする最新の開発パターン
WordPressの開発でdo_action()を一度も使ったことがない人はまずいないだろう。カスタムフックを定義して他のプラグインやテーマから振る舞いを拡張する手法は、バージョン1.2で導入されて以来変わらず愛用されている。
しかし長年の使い込みの中で、いくつかの「小さな摩擦」が無視されてきたのも事実だ。引数の順序を覚えきれない、フック名が大域空間で衝突する、戻り値の返し忘れでフィルターが壊れる、といった問題は大規模なコードベースになるほど開発者の時間を食う。
この記事では、do_action()に1つのオブジェクトを渡し、そのクラス名をフック名として使うことで、これらの問題を一掃するパターンを解説する。独自のライブラリもフレームワークも不要で、PHPの標準機能だけで実装できる。2026年8月にDeveloper WordPress Newsで公開された洞察をもとに、実装例と仕組みを詳しく見ていこう。
do_action()で起きていた4つの摩擦
従来のdo_action()は「フック名」と「任意の数の引数」を受け取るシンプルなAPIだ。会員登録をトリガーとするプラグインであれば、次のようにフックを発火させるのが一般的な書き方になる。
do_action( 'myplugin_member_registered', $userId, $plan );これを受け取る側のコードは以下のようになる。
add_action( 'myplugin_member_registered', static function ( $userId, $plan ) {
// ... 何らかの処理
}, 10, 2 );動作自体に問題はない。だが、よく見ると運用上のストレスがいくつも潜んでいる。Developer WordPress Newsの記事が指摘する摩擦点は大きく次の4つだ。
- 引数が位置に依存する
$userIdと$planの順序を覚えておかなければならず、間違えた場合のエラーは追跡しにくい。 - フック名がグローバルな名前空間
'myplugin_member_registered'という文字列が他のプラグインと衝突しないよう、prefixをつけて管理する必要がある。 - 型情報が一切ない
$planは文字列かもしれないしIDかもしれない。コードエディタの補完も静的解析も効かず、ドキュメントを読まなければ正体がわからない。 - フィルターの戻り値忘れ
apply_filters()を使うと、どのリスナーも必ず値を返さなければならない。うっかりreturnを書き忘れると、後続のフィルターがすべて破綻する。
これらはフックの仕組みそのものの問題ではなく、ペイロード（運ぶデータ）の渡し方に起因する。そして、このペイロード設計を見直すだけで、すべてがきれいに解決する。
上の比較でわかるとおり、do_action()に渡す情報をオブジェクトにまとめるだけで多くの摩擦が消える。フック名の衝突リスクがなくなり、コードエディタの補完も効く。
イベントオブジェクトとクラス名フック 1行で変わる設計
解決策の核心は驚くほど単純だ。Developer WordPress Newsの記事の著者が試みたのは、「引数をバラバラに渡すのではなく、起こった出来事を表すオブジェクトを1つだけ渡す」というやり方である。
具体的には、次のように書く。
do_action( $event::class, $event );$event::classが何が起きたかを示すフック名になり、$eventがその詳細を運ぶ。フック名にはそのクラスの完全修飾名が使われるため、名前空間が自動的に適用され、他のプラグインと衝突することはまずない。
フック名を::classで決めるか、あるいは固定の文字列にするかは選択できる。クラス名を使えば、IDEでクラスをリネームするとフックも追従する。文字列（例：'myplugin/member-registered'）を指定すれば、後からクラスを移動させてもフック名は変わらない。移行の危険を減らしたいなら固定文字列のほうが安全だが、どちらにせよペイロードは整ったオブジェクトになる。
また、このテクニックはapply_filters()を使わなくてもフィルター的な振る舞いを実現できる。オブジェクトのプロパティを書き換え可能にしておけば、リスナーが自由に値を変更し、ディスパッチャ側が後から読み取れるからだ。戻り値の管理に頭を悩ませる必要がなくなる。
具体例 会員登録のDispatcherとListener
ここでは会員登録を題材に、イベントオブジェクトを使ったフックの流れを具体的に見ていこう。名前空間MyPlugin\Membersの下に、登録イベントを表すクラスと、それを発行するクラス、そして受け取る側のコードを用意する。
イベントクラスの定義
namespace MyPlugin\Members;
final class MemberRegistered
{
public function __construct(
public readonly int $userId,
public readonly string $plan,
public bool $sendWelcomeEmail = true,
) {}
}$userIdと$planはreadonlyとして宣言され、リスナーは読み取り専用で使用する。一方、$sendWelcomeEmailは書き換え可能にしておき、ウェルカムメールを送るかどうかの判断をリスナーに委ねる。
Dispatcher（発行側）
namespace MyPlugin\Members;
final class MemberRegistrar
{
public function register( int $userId, string $plan ): void
{
// アカウント作成処理...
$event = new MemberRegistered( userId: $userId, plan: $plan );
do_action( $event::class, $event );
if ( $event->sendWelcomeEmail ) {
// ウェルカムメールをキューに追加
}
}
}ポイントは、do_action()の後で$event->sendWelcomeEmailを評価しているところだ。この値は後続のリスナーが変更したかもしれない。オブジェクトは参照で渡されるため、ディスパッチャはリスナーによる変更をそのまま拾える。ここにapply_filters()は必要ない。
ObserverとMutatorの2パターン
受け側はおおまかに2種類に分かれる。1つはイベントを観測するだけのObserverで、値を読み取るが変更はしない。もう1つはプロパティを書き換えるMutatorだ。
// Observer ログ出力のみ
add_action( MemberRegistered::class, static function ( MemberRegistered $event ): void {
error_log( sprintf(
'Member #%d registered on the %s plan.',
$event->userId,
$event->plan
) );
} );
// Mutator 無料プランの場合はウェルカムメールを無効化
add_action( MemberRegistered::class, function ( MemberRegistered $event ): void {
if ( 'free' === $event->plan ) {
$event->sendWelcomeEmail = false;
}
} );Mutatorのコールバックを見ると、型ヒントによって$eventのプロパティが自動補完されることがわかる。$userIdや$planの順序を気にする必要はなく、add_action()の第4引数で引数の数を指定する手間もない。これがオブジェクト化の地味ながら大きな恩恵だ。
$sendWelcomeEmailをfalseにすることで、メール送信の挙動を変更する。このように、1つのオブジェクトを受け渡すだけで、従来のアクションとフィルターの両方の役割を統一的に扱える。コードの見通しは飛躍的に良くなるはずだ。
オブジェクト化がもたらすメリットのまとめ
これまでの例から、イベントオブジェクトパターンを採用することで得られる具体的な利点を整理する。
- 型安全なリスナー すべてのコールバックがイベントクラスで型を宣言するため、エディタの補完と静的解析がフルに働く。
- 名前衝突からの解放 フック名は完全修飾クラス名（または明示的な文字列）で管理されるため、prefixを手動で付ける必要がなくなる。
- フィルターのような書き換えをアクションで実現 オブジェクトのプロパティをミュータブルにしておけば、
apply_filters()を使わずとも値の変更が可能。戻り値の返し忘れによるバグも消える。 - 自己文書化 各イベントクラスが独立したファイルになるため、どの拡張ポイントが存在するかがディレクトリを見るだけで把握できる。
これらの改善は、特別なライブラリを導入しなくても、今日から自社のプラグインに適用できる。既存のdo_action()やadd_action()をそのまま使いつつ、ペイロードをオブジェクトに切り替えるだけだ。
WordPressのルーツとPSR-14の関係
このパターンを「新しいアイデア」と感じるかもしれないが、実はWordPressが2004年のバージョン1.2で搭載したプラグインAPIの時点で、根幹の設計は既に存在していた。
PHPの世界でPSR-14（Event Dispatcher）として標準化された「イベント、リスナー、ディスパッチャ」の概念は、do_action()とadd_action()の組み合わせでほぼ表現できる。つまり、WordPressはとっくにイベント駆動の基盤を持っていたことになる。
PSR-14が定める厳密な契約（伝播制御、リスナープロバイダー、ディスパッチャの交換など）はWordPressには組み込まれていない。だが、「イベントをオブジェクトで表現し、そのクラス名でフックする」という発想は、PSR-14のイベントモデルと驚くほど調和する。結果として、WordPressのネイティブな関数の上に、よりモダンで安全なイベント設計を載せられるわけだ。
Developer WordPress Newsの記事の著者も、PSR-14を完全実装する試みの中で、大半の価値がこの小さな習慣に詰まっていることに気づいたと述べている。段階的な移行が可能で、いきなり大掛かりなフレームワークに乗り換える必要はない。
このパターンの限界と発展の方向性
ここまでのテクニックで、自作プラグインのカスタムフックの多くは十分に改善できる。ただし、次のような高度な要件に直面したときは、より本格的なイベントシステムの導入を検討してもいい。
- 伝播の停止 あるリスナーが「以降のリスナーは実行するな」と指示する仕組み。これは
remove_action()と優先度では再現しきれない場面がある。 - 複雑なリスナー管理 数十個のリスナーを手作業で登録するのではなく、1つのサブスクライバークラスにまとめて登録したいケース。
- テストのための差し替え ディスパッチャ自体を丸ごと入れ替えて、イベントの発生をテストダブルで差し替えたい状況。
これらの必要性を感じ始めた時が、PSR-14準拠のディスパッチャを導入する潮時といえる。しかし、そこに至るまでは、「do_action()にオブジェクトを渡す」習慣だけで、保守性も開発体験も大きく前進させられる。
今日からすぐに実践できる小さな設計変更が、コードベースの品質を長期にわたって支える土台になる。次のカスタムフックを書くときに、このパターンをぜひ試してみてほしい。
この記事のポイント
do_action()にバラバラの引数ではなく1つのイベントオブジェクトを渡すと、引数の順序問題や型の不明瞭さが解消される。- フック名にクラスの完全修飾名を使うことで、名前空間が自然に確保され、衝突リスクが劇的に下がる。
- オブジェクトの書き換え可能プロパティを利用すれば、
apply_filters()を使わずにフィルター的な挙動を安全に実装できる。 - オブザーバーとミューテーターの2種類のリスナーを型安全に記述でき、コードエディタの補完がフルに働く。
- PSR-14のような本格的なイベントシステムを導入しなくても、小さな習慣を変えるだけで開発体験が大幅に改善する。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.0が公開、ゲスト注文の連携と大規模ストア向けパフォーマンス改善
WooCommerce 11.0が2026年8月4日にリリースされた。このバージョンは551件のプルリクエストを含む、近年最大規模のアップデートのひとつだ。バックログの整理とコアの基盤強化に重点が置かれ、ゲスト購入者が過去の注文を自分のアカウントに紐づけられる機能や、アナリティクスの信頼性向上、大規模ストア向けのパフォーマンスチューニングが行われている。
本記事では、運用者と開発者の両方にとって重要な変更点を中心に、WooCommerce 11.0の中身を解説する。カタログが数千点を超える店舗でも体感できる速度改善や、新しいゲスト注文管理の仕組みを詳しく見ていこう。
大規模ストアで効くパフォーマンス最適化
WooCommerce 11.0のパフォーマンス改善は、商品点数が多く、過去の注文データが膨大な店舗ほど効果を発揮する。内部クエリの最適化を中心に、Store APIの改良や注文処理中の在庫ステータス管理がより軽量になった。
内部クエリの見直しとStore APIの改善
大規模ストアでは、商品一覧や注文履歴を表示するたびにデータベースへ重いクエリが走り、管理画面やフロントエンドのレスポンスが悪化しがちだ。今回のアップデートでは、こうしたクエリに不要なJOINやサブクエリが含まれていないかを洗い出し、インデックスを活用したシンプルな構造に書き換える修正が多数含まれている。
Store APIも改良された。Headless構成やカスタムストアフロントでWooCommerceを利用している場合、商品データの取得やカート操作がより高速になる。具体的には、APIの内部で使用するキャッシュ戦略とデータ構造が見直され、同じデータを重複して取得する無駄が省かれた。
在庫管理まわりの処理が軽量化
注文が入るたびに在庫数を更新し、ステータスを変更するフローもチューニングされている。特に、バックエンドで複雑な在庫チェックを繰り返していた処理が一本化され、注文から在庫確保までの一連の流れがスリムになった。商品バリエーションが多い店舗では、これによる管理画面の操作感向上が期待できる。
上記のように、規模が大きくなるほど効果が明確になる。クエリ最適化は累積的なため、今後のWooCommerceバージョンでも継続して改善が加えられる見込みだ。
ゲスト購入とアカウントの連携がスムーズに
WooCommerce 11.0では、購入後のアカウント作成フローがさらに強化された。これまではゲストとして注文した後にアカウントを作っても、過去の注文は引き継がれなかった。今回のアップデートで、ゲスト購入者が自分の過去注文を見つけ、メール認証を通じてアカウントに紐づけられるようになっている。
メール認証による過去注文の引き継ぎ
具体的な流れはこうだ。ゲスト購入者が新たにアカウントを作成すると、WooCommerceはそのメールアドレスに関連する過去のゲスト注文を検索し、一覧を提示する。ユーザーは「自分の注文」として承認するかどうかを選択でき、承認されるとアカウントの注文履歴に統合される。この仕組みにより、リピート購入への心理的なハードルが下がり、顧客ロイヤルティの向上にもつながる。
この機能は、WooCommerce 9.5で導入された購入後アカウント作成の自然な拡張だ。単に「購入後にアカウントを作れる」だけでなく、「過去の購入履歴もまとめて管理できる」ようになる点が、顧客体験として大きな進化といえる。
アナリティクス報告の信頼性が向上
WooCommerce 11.0では、売上分析や注文レポートの精度が高められた。イベントトラッキングの確実性が増し、返金データが売上APIの数値に正しく反映されるようになった。また、過去データのインポートに失敗した場合、再試行できる機能が追加され、管理画面からエラー状況を確認しやすくなっている。
返金が売上レポートに正しく反映
これまでのアナリティクスでは、返金処理が行われても売上APIの数値が更新されないケースがあった。11.0では、返金も含めた正味売上が計算されるため、ダッシュボードの数字と実際の会計がずれる問題が解消される。
失敗時のリトライ機能でデータ欠損を防止
大量の履歴データを一括でインポートする際、サーバーの制限などで処理が途切れることがある。今回のアップデートで、インポートに失敗したジョブの一覧が表示され、管理者が手動でリトライできるようになった。大規模なデータ移行やバックアップからの復元作業が、より安全で扱いやすくなっている。
開発者向けアップデートと基盤整理
WooCommerce 11.0には、開発者向けの変更も数多く含まれている。Abandoned Cartメールやブロックベースのメール編集、新しい設定UIといった試験的機能が追加されたほか、Product Editor Betaの完全廃止、内部依存ライブラリであるAction Schedulerが4.0.0へ更新されている。
Action Scheduler 4.0.0への移行
Action Schedulerとは、WordPressのWP-Cronに代わる形で定期的なジョブや遅延タスクを実行するライブラリで、WooCommerceの購読や自動メールなど多くの機能を支えている。今回、依存バージョンが4.0.0に引き上げられ、ジョブの登録と実行の仕組みが改善された。具体的には、処理の重複防止やエラーハンドリングが強化され、長期間のタスクでも安定して動くようになっている。
試験的機能と廃止スケジュール
Abandoned Cartメールは、カゴ落ちしたユーザーに自動でリマインダーを送る機能だが、これまではサードパーティのプラグインに頼る必要があった。今回、コアに試験的実装が加わり、将来的な標準機能化への布石となっている。ブロックベースのメール編集や新しい設定UIも、まだ試験的ではあるが、より直感的な管理画面を目指す方向性を示している。
一方、Product Editor Betaは今回のバージョンで完全に廃止された。すでに新しい商品編集エディタが安定版へ移行しており、以前のベータ版に依存していたカスタムコードがある場合は、早めの移行が推奨される。
この記事のポイント
- WooCommerce 11.0は551件のPRを含む大規模アップデートで、基盤整理とパフォーマンス改善が中心
- ゲスト購入者が過去の注文をメール認証でアカウントに紐づけられるようになり、リピート率向上に寄与
- 大規模ストア向けにクエリ最適化とStore API改良が行われ、管理画面とフロントエンドのレスポンスが向上
- 返金データが売上APIに正しく反映され、アナリティクスの信頼性が高まった
- 開発者向けにはAction Scheduler 4.0.0への移行や試験的機能の追加、Product Editor Betaの廃止が行われた
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
大量メール配信の落とし穴、800,000通で自社サイトがダウンした理由
2026年、WooCommerce.comが約80万の購読者に向けてニュースレターを一斉配信したところ、わずか数分でサイトがダウンするという思わぬトラブルが発生した。原因は攻撃でもリリースミスでもなく、メール配信そのものだった。配信先に企業向けメールシステムが多く含まれていたため、メールセキュリティスキャナーが一斉にリンク先を自動クロールし、膨大なトラフィックを引き起こしたのである。
この出来事は、当該チームに「大量メール配信はインフラの負荷テストと同義である」という教訓を残した。本記事では、この障害の経緯と原因、そして再発防止策を紹介する。メールマーケティング施策を運営するすべての企業にとって、無視できない警鐘だ。
800,000通のメールで自社サイトがダウン、その経緯
ある日の午前9時15分（UTC）、WooCommerceのチームは約80万人に向けたニュースレター配信を実行した。配信開始からわずか3分後の9時18分、同僚からの「サイトが落ちている」という一報が届く。監視アラートが作動したのはその4分後（9時22分）であり、人が気づく方が先だった。
状況をさらに混乱させたのは、その朝には一切のデプロイがなく、攻撃の痕跡も皆無だった点だ。にもかかわらず、エッジレベルでのリクエスト総数は平時の約25万から急増し、ピーク時には約53万を記録した。実際のダウンタイムは3〜4分程度にとどまった。この短い間に、一部のユーザーには「429 Too Many Requests」が返され、ごく一部で5xx系エラーも発生したが、大多数のリクエストは正常な200応答を返し続けている。つまり「短時間の部分的な停止」であり、それでも立派なインシデントだった。
補足すると、当初のトラフィックグラフでは合計リクエスト数が実際の2倍に表示されるというダッシュボードの不具合が見つかった。後に修正されたが、正しい数字はステータス別の線であり、ピークは約53万、平常時が約25万。いつも通りの約2倍のトラフィックが数分間だけ発生したことに変わりはない。
原因はメールセキュリティスキャナーだった
まず疑ったのは当日のリリースや攻撃の兆候だが、どれも該当しなかった。しかしアクセスログには二つの異様な痕跡が残されていた。
一つは、トラフィック元の大半がデータセンターやVPNのIPアドレスで、実際のショッピング利用者が使うような一般ISPからではなかった点だ。もう一つは「JavaScript ChunkLoadError」の大量発生である。ChunkLoadErrorとは、HTMLだけを取得し、ページのJavaScript（JS）をダウンロードする前に接続が切断された場合に起こるエラーだ。数千回のこのエラーが数秒のうちに集中した。
この断片的な情報をつなぎ合わせると、犯人像が見えてくる。企業向けメールシステム（Office 365やMimecastなど）は、メールが受信トレイに届いた瞬間に、本文中のすべてのリンクを自動的にたどり、マルウェアチェックを行う。受信者がメールを開封する以前に、セキュリティスキャナーがリンク先を叩くのだ。
WooCommerceのニュースレターはストアオーナー向けだったため、送信先には企業ドメインが非常に多かった。80万通を一斉に配信すると、それら企業メールシステムのスキャナー群もほぼ同時に作動し、一瞬のうちに大量のリクエストが殺到した。これがスパイクの正体である。もし同じ配信をGmailが中心の一般消費者向けに行っていれば、このような急増は起きなかっただろう。
なぜ同じ規模の前回は耐えられたのか
実はその1週間前にも、さらに大規模な配信を実施していた。その際にも今回とほぼ同じボットトラフィックのスパイクが発生していたが、誰も気づかないままインフラは何事もなく耐え抜いた。だから今回も「配信量が特に多すぎた」わけではない。
問題は配信のサイズではなく、タイミングだった。前回の配信では偶発的に、ボットの同時接続数がわずかに抑えられたり、キャッシュの状態が良好だったりした可能性がある。今回はほんのわずかな違いが、耐えられる負荷と許容限界との差になった。正確な理由を断定するのは難しいが、一瞬の集中がすべてを変えたことは確かだ。
オートスケーリングが追いつかなかった瞬間
WooCommerce.comはWordPress VIPのホスティング上で稼働しており、オートスケーリングは正常に動作していた。もしトラフィックが徐々に増加するパターンであれば、新しいリソースが立ち上がるまでの数分間で対応できたはずである。実際に追加されたキャパシティが整った頃には、スパイクはすでに通過し、被害も収束していた。
しかし今回の攻撃（自爆攻撃とも言える）は、段階的な増加ではなく「ステップ関数」のような瞬間的な跳ね上がりだった。スケーリングが反応するための傾斜が存在しないため、自動化の仕組みは事実上役に立たなかった。問題はサーバーに到達する前、配信の仕組みそのものにあったのだ。
トラフィックが瞬間的に跳ね上がる一斉配信と、分散されて緩やかな山になるバッチ配信の比較を示した。今回の対策では、後者の方式を採用することでスパイクを回避した。
対策〜バッチ配信でスパイクを防ぐ
次のキャンペーンは、たまたま1週間後のブラックフライデーに予定されていた。チームは全リストを一気に送信するのではなく、数時間かけて小分けにバッチ配信する方式に変更した。利用しているメール配信プラットフォームがこの機能をサポートしているかを事前に確認した上での判断である。
結果は明確だった。バッチ配信へ切り替えた後は、あのスパイクは一切発生しなくなった。追加のサーバーキャパシティは投入しておらず、今後も増強予定はない。オートスケーリングは自然な成長や季節変動を十分に吸収できるが、自ら招く瞬間的な高負荷には対応しきれないからだ。
大規模なマーケティングメールの配信は「インフラに関わるイベント」として認識し、特に最大規模の配信の前にはサーバー運用チームと連携することが推奨される。
大量メール配信は負荷テストである、という教訓
企業向けのメールアドレスを含む大規模リストに一斉配信を行うと、受信者が何もしなくても、配信開始と同時にメールセキュリティスキャナーがすべてのリンクを叩く。これは結果として、自社サイトに対して意図しない大規模な負荷テストを実施しているのと同じだ。
重要なのは、配信停止やメールマーケティングの否定ではない。適切に管理すればニュースレターは強力なチャネルである。ただし、送信ボタンを押す前に「ボットによる一斉アクセスが起こりうる」と想定しておくことが不可欠だ。配信のタイミングを分散するだけでも、今回のような障害は回避できる。
この記事のポイント
- 80万通のメール一斉配信で自社サイトが3〜4分ダウンした
- 原因は企業向けメールセキュリティスキャナーの一斉リンクチェックだった
- 同じ規模の前回は偶然耐えられたが、タイミング次第で失敗しうる
- オートスケーリングは段階的な増加には強いが、瞬間的なスパイクには無力
- 対策として配信を時間差バッチに変更し、再発を防止した
- 大量メール配信は意図しない負荷テストとなりうる、分散配信が鍵
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0でAIプラグインを作る！Abilities APIとAI Client連携の実際
WordPress 7.0から導入された3つのAI関連コンポーネント、Abilities API、AI Client、そしてMCP Adapterがプラグイン開発の風景を大きく変えようとしている。これらを組み合わせると、AIが画像を解析し、自動で記事を生成するプラグインを驚くほど少ないコードで実装できる。
本記事では、実際に「Photo to Post」というプラグインの構築を通して、各APIの役割と連携方法を具体的に解説する。WordPressの管理画面から画像URLを入力するだけで、AIがビジョンで内容を理解し、下書き投稿を自動生成する流れを追いながら、新しい開発スタイルの全体像をつかんでほしい。
情報源はWordPress Developer Blogのチュートリアル「Build your first AI-Powered WordPress plugin」（2026年7月30日公開）だ。ここで示されるコードと設計思想は、今後のWordPressエコシステムにおけるAI統合の方向性を色濃く反映している。
新しいAI開発基盤の3要素
WordPress 6.9以降で整備されたAbilities API、7.0で正式に取り込まれたAI Client、そしてMCP Adapterは、それぞれ独立して使えるが、組み合わせることで真価を発揮する。まずはこの3つの役割を押さえておく。
Abilities API
Abilities APIは、プラグインが提供する機能を「能力」として登録し、REST APIやAIエージェントなどが統一された方法で発見・実行できる仕組みだ。入力スキーマ、出力スキーマ、パーミッションコールバック、そして実処理を行うコールバックを定義する。これにより、従来のようにエンドポイントを個別に実装する手間が省け、一度登録した能力が管理画面・REST・MCP経由でそのまま利用可能になる。
WordPress AI Client
AI Clientは、プロバイダー（OpenAI、Anthropic、Googleなど）に依存しないPHPライブラリだ。プラグインコードはwp_ai_client_prompt()というフルーエントなビルダーでプロンプトを組み立て、テキスト生成やファイル送信を依頼するだけでよい。プロバイダーの切り替えは管理画面のConnectors API（後述）でAPIキーを設定するだけで済み、コードを一切変更する必要がない。
MCP Adapter
MCP（Model Context Protocol）は、AIエージェント（デスクトップアプリやVS Code拡張など）が外部ツールを呼び出すための標準プロトコルだ。MCP Adapterプラグインをサイトにインストールすると、登録したAbilityがMCPツールとして自動公開される。ClaudeやChatGPTなどのAIクライアントにWordPressの機能を認識させ、「この画像から投稿を作成して」と自然言語で指示するだけで、プラグインの能力が裏側で呼び出される。
同じ能力が3つの入口からシームレスに使える
上の図はAbilities APIの最大のメリットを示している。一度登録すれば、UI、REST、AIエージェントのどこからでも同一の能力を実行できる。エンドポイントごとに別の処理を書く必要はない。
プラグイン「Photo to Post」の仕組み
チュートリアルで構築する「Photo to Post」は、画像URLを入力するとAIが画像の内容を解析し、その説明文をもとにブログ投稿用のタイトルと本文を生成、さらにその画像をアイキャッチに設定した下書き投稿を作成するプラグインだ。
内部では、3つのAbilityが連携している。ここで重要なのは、最後の能力が他の能力を呼び出す「能力の合成（composition）」を実践している点だ。
この合成パターンは、WordPressのフィルターフックやアクションフックで築かれた「小さな機能を組み合わせて大きな機能を作る」という哲学のAI時代バージョンといえる。
実装の流れを追う
ここからはチュートリアルの主要な実装ステップを、要点を絞って解説する。すべてのコードはスタータープラグインをベースにしており、TODOコメントを置き換える形で進められる。AIプロバイダーとしてはOpenAI、Anthropic、Google Geminiなどが利用可能だ。
AIプロバイダーとの接続
WordPress 7.0では、設定メニューに「コネクター」画面が追加された。Connectors APIによって、各プラグインはAPIキーの保存場所を一元管理できる。従来はプラグインごとに設定ページでキーを管理する必要があったが、これで1箇所に集約される。
OpenAI、Anthropic、Googleの公式プロバイダープラグインをインストールし、コネクター画面でAPIキーを登録すれば、あとはAI Clientが自動的にそのプロバイダーを使う。ビジョンモデルを使う場合は、Anthropicのように画像をBase64で送る必要があるが、AI Clientが吸収するためコード上の差異はほとんど生じない。
能力の登録
Abilities APIにおける能力の登録は、wp_register_ability()関数にラベル、説明、入出力スキーマ、パーミッション、コールバックを渡すだけだ。ここで定義したスキーマが、RESTやMCP経由で能力を呼び出す際の「説明書」になる。
チュートリアルでは、describe-image（画像URL → テキスト説明）、generate-post-from-description（説明文 → 投稿タイトルと本文）、create-post-from-photo（画像URL → 下書き投稿）の3つを登録する。
能力を登録したら、wp_abilities_api_initアクションにフックし、RESTで表示するためにメタ情報にshow_in_rest => trueを指定する。これだけでアプリケーションパスワードを使ったcurlで能力の一覧を取得できる。
AI Clientによる画像解析とテキスト生成
最初の能力describe-imageのコールバックでは、wp_ai_client_prompt()でプロンプトを構築し、with_text()とwith_file()で画像のデータURIを渡してgenerate_text()を呼ぶ。戻り値はWP_Errorの可能性があるため、必ずチェックする。
画像はwp_remote_get()で取得しBase64エンコードしたデータURIにして送る。これにより、URLでの画像指定を受け付けないプロバイダーでも動作する。
2つ目の能力generate-post-from-descriptionでは、AIに「画像説明文から魅力的なブログ投稿を生成し、JSONで返す」よう指示する。プロンプトには「markdownコードフェンスで囲まない」と明示するが、AIは非決定論的なため、念のためpreg_replace()でフェンスを除外し、JSON文字列の中からオブジェクトを抽出する防御的なパース処理を入れている。
能力の合成
3つ目の能力create-post-from-photoがこのプラグインの心臓部だ。ここでwp_get_ability()を使って自分自身以外の能力を取得し、execute()で実行する。最初にdescribe-imageを実行して画像説明を取得し、次にその説明を使ってgenerate-post-from-descriptionを実行、最後に得られたタイトルと本文からwp_insert_post()で下書きを作成する。
このように、能力を「LEGOブロック」のように組み合わせられることがAbilities APIの真骨頂だ。各能力は単独でテスト可能であり、後から新しい能力を追加して組み合わせることも容易である。
管理画面の拡張
スタータープラグインに付属するDataFormベースの設定画面を、実際の能力と連携させる。JavaScript側からは@wordpress/abilitiesパッケージのgetAbility()とexecuteAbility()を使い、先ほどPHPで登録したcreate-post-from-photo能力を呼び出す。
スクリプトをモジュールとして読み込み、readyプロミスでAPIが利用可能になるのを待ってから実行する。これで管理画面から画像URLを入力し「投稿を生成」ボタンを押すだけで、一連のAI処理が走り、下書きが作成される。成功すると編集画面へのリンクが表示される。
MCP対応でAIエージェントにも開放
能力の登録時にメタに'mcp' => array( 'public' => true )を追加し、MCP Adapterプラグインを有効化するだけで、その能力がMCPサーバー経由で外部AIエージェントに公開される。
例えばClaudeデスクトップアプリの設定ファイルにWordPressサイトのURLとアプリケーションパスワードを記述すれば、「この写真から投稿を作成して」と話しかけるだけで、create-post-from-photoが自動的に呼ばれる。REST、管理画面、MCPという3つの入口を同じコードで実現できるのは、Abilities APIの設計の妙だ。
実装から見える将来性
WordPressのコアに組み込まれたこれらAIビルディングブロックは、単なる補助機能ではない。プラグイン開発のパラダイムを「単一の機能提供」から「再利用可能な能力の提供と合成」へとシフトさせる可能性を秘めている。
さらに、Connectors APIによるAPIキーの一元管理は、複数プラグイン間の設定のばらつきを解消し、サイト管理者の負担を大きく下げる。開発者は「どのAIモデルを使うか」を気にせず、ビジネスロジックに集中できる環境が整いつつある。
注意点として、AI呼び出しには時間がかかるため、デフォルトのHTTPタイムアウトでは処理が中断される可能性がある。チュートリアルではwp_ai_client_default_request_timeoutフィルタでタイムアウトを120秒に延長する対処が示されている。このような実運用の勘所も押さえておきたい。
プラグイン開発者がこうした基盤を活用し始めれば、WordPressエコシステム全体のAIリテラシーが一気に加速する。非エンジニアでも「写真から投稿を作って」と指示するだけでコンテンツ制作が進む未来は、すぐそこまできている。
この記事のポイント
- WordPress 7.0のAbilities API・AI Client・MCP Adapterにより、AI搭載プラグインを少ないコードで構築できる
- 能力を1回登録すればREST・管理画面・AIエージェントの3経路で同一機能を提供可能
- AI Clientはプロバイダー非依存で、Connectors APIがAPIキー管理を集約
- 能力の合成で「LEGOブロック」のように複雑な自動化を実現
- 実運用ではタイムアウト延長フィルタなど、実装上の注意点も必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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ホスティングの「セキュア」は本当か？実検証が明かした真実
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最適化の豊富な経験