WordPress 7.2ロードマップ公開。Beta 1は10月20日、wp_kses再構築も注目
WordPress 7.2の開発ロードマップが公開された。2026年最後のメジャーリリースとなる7.2は、Beta 1が10月20日、RC1が11月17日、正式版が12月8日に予定されている。
9月にはWordPress 7.1.1から7.1.3まで、3回のセキュリティリリースが続いた。7.1.1は11件、7.1.2は緊急の1件、7.1.3は7件のセキュリティ修正を含む。自動更新で対処済みなら問題ないが、更新を止めているサイトがある場合は先に済ませておきたい。
この記事では、開発者向けに発表された情報の中から、Web制作会社やプラグイン・テーマ開発者に影響する項目を絞って解説する。
WordPress 7.2のロードマップが公開、Beta 1は10月20日
WordPress 7.2は2026年最後のメジャーリリースだ。ロードマップでは、セキュリティ、ブロックとAPI、デザインツール、管理画面、メディアとパフォーマンスの5分野にわたって、現在進行中の項目が示されている。
ただし、ロードマップに載っている項目はすべて「開発が進められているが、最終版に入るとは限らない」と明記されている。プラグインやテーマを配布している開発者は、Beta 1からRC1までの約4週間で互換性を確かめておきたい。
- セキュリティはアプリケーションパスワードの改善、非HTTPS環境の検出、SameSite Cookieのサポートなどが候補に並ぶ
- ブロックでは説明リストの新ブロック、目次ブロックのサーバーサイドレンダリング移行、アイコンブロックのキーワード検索などが進む
- デザイン面はカスタムブロック状態、グローバルスタイルでのフォーム要素対応、ブロックサポートの拡張などが対象
- 管理画面は拡張可能なサイトエディタ、DataViewsとDataFormsの改良、管理バーとメニューのDashicons置き換えが候補
- メディアとパフォーマンスはダイナミックギャラリー、クライアントサイドメディア、スクリプトとスタイルの連結をプリフェッチへ置き換える作業が含まれる
ロードマップの中でも、プラグインやテーマの互換性に直結しやすいのがブロックサポートの拡張とDashiconsの置き換えだ。Beta 1のタイミングでテスト環境を用意し、管理画面の表示崩れや独自CSSとの衝突を確認するとよい。
セキュリティと管理画面まわりの注目点
セキュリティ分野では、アプリケーションパスワードの改善や非HTTPS環境の検出、SameSite Cookieのサポートなどが候補に挙がっている。SameSite Cookieとは、ブラウザーが別サイトへのリクエストにCookieを自動送信しないよう制御する仕組みだ。ログインセッションを狙った攻撃への対策として関心が高い。
管理画面では、サイトエディタの拡張性を高める作業、DataViewsとDataFormsの改良、管理バーと管理メニューで使われてきたDashiconsの置き換えが進められる。DashiconsはWordPressに組み込まれてきた管理画面用のアイコンフォントで、今回の置き換えは表示の一貫性とカスタマイズ性を高める狙いがある。
React 19と共同編集は7.2に入らない見込み
ロードマップにはReact 19へのアップグレードも載っているが、「WordPress 7.2には完全には入らない可能性が高い」とされている。共同編集機能も今回は意図的にロードマップから外された。開発チームはサーバー側の状態を軸にしたアプローチへ移行する理由を別途説明している。
AI関連ではAbilitiesやMCPアダプターの作業が進むが、これらは専用プラグインとして提供される。コア本体への組み込みは今回の対象外だ。
wp_kses()がHTML APIベースで再構築、出力と互換性に変化
wp_kses() はWordPressが投稿内容などをサニタイズ（無害化）する際に使う関数だ。不正なスクリプトや危険なタグを除去する、サイトの安全を支える部品の1つである。その wp_kses() がHTML APIの上に再構築される計画が明らかになった。7.2か7.3での導入が目標で、テスト結果次第で判断される。
新しいパーサーは、出力するマークアップの表記を正規化し、scriptとstyle要素の中身を除去する。さらに、不正な形式のSVG、MathML、コメントの一部を拒否する。プラグインやテーマでサニタイズ結果を比較したり、保存したり、テストしたりしている場合は、trunkバージョンでの動作確認が必要だ。
この変更でHTMLの加工結果が変わる可能性があるため、比較テストやスナップショットテストを導入している開発者は注意したい。新しいパーサーが自分のHTMLにどう影響するかは、専用のテストツールでも確認できる。HTMLを貼り付けると再構築後の処理結果を確認できる仕組みだ。
旧パーサーへ戻すフィルターも用意、ただし一時しのぎ
互換性を保つための逃げ道として、wp_kses_force_legacy_parser フィルターが用意されている。このフィルターを使えば従来の動作に戻せるが、恒久的な修正ではなく一時的な回避策として扱うべきだとされている。問題を検出した場合はTracチケットへ報告することが推奨されている。
Gutenberg 24.1、ブロック開発者に効く変更点
Gutenberg 24.1はデザインツールの一貫性に焦点を当てたリリースになった。約140件のプルリクエストが、ブロックサポートの適用範囲を広げている。ここではプラグインやテーマを開発するうえで押さえておきたい変更をまとめる。
レスポンシブなカスタムコントロールを自作できる
WordPress 7.1でレスポンシブなスタイル状態が導入されたが、当時はコアブロックしかブレークポイント別のコントロールを作れなかった。内部のヘルパーが公開されていなかったからだ。Gutenberg 24.1で、このビューポート状態を扱うヘルパーが公開された。
@wordpress/block-editor が getStyleForState() と setStyleForState() をエクスポートし、ブロックエディタストアには getSelectedBlockStyleState() と hasSelectedBlockStyleState() というセレクタが追加された。下の例は、モバイルのブレークポイントだけに最低高さを設定するコードだ。
const state = { viewport: '@mobile' };
const stateStyle = getStyleForState( attributes.style, state ) || {};
setAttributes( {
style: setStyleForState( attributes.style, state, {
...stateStyle,
dimensions: { ...stateStyle.dimensions, minHeight: '50vh' },
} ),
} );同じリリースでは、positionプロパティをブレークポイントごとに変えることも可能になった。たとえばヘッダーを「モバイルのときだけ固定表示にする」といった指定ができる。コアブロックと同じ感覚で、端末ごとに最適な表示設定を提供できるようになる。
ほぼ全コアブロックにブロックサポートが展開された
背景画像、グラデーション、影、リンクとボタンの色、ボーダー、テキストカラム、テキスト配置といった既存のブロックサポートが、ほぼすべてのコアブロックで使えるようになった。これまでカスタムCSSで補っていた部分を theme.json の styles.blocks に移せる場面が増える。
注意点として、Accordion、Tabs、Tab Panel、Post Templateの各ブロックでは、リンク色関連のクラスが出力されるようになった。テーマ側でこれらのブロック内リンクをスタイルしている場合は、セレクタの詳細度が衝突しないか7.2までに確認しておきたい。
コアアイコンは塗りではなく線に、コンポーネント5つは非推奨
約330個のコアアイコンが、塗りつぶし方式から線ベースに再描画された。各SVGにはインラインで fill をnoneにする指定が入る。fillプロパティやCSSのfillルールでは色を変更できなくなるため、CSSのcolorプロパティを使うことになる。
fill: none をインライン指定併せて @wordpress/icons と @wordpress/components はセットで更新しておきたい。新しいアイコンと古いIconコンポーネントを混在させると、統合されたスタイルが欠けることがある。
@wordpress/components では、Divider、ResponsiveWrapper、Scrollable、ZStack、Elevationの5つが非推奨になった。これらは7.2から非推奨の扱いで、7.4で削除される計画だ。置き換え先は原則として通常のCSSで、ResponsiveWrapperは aspect-ratio、DividerはSeparatorコンポーネントが推奨される。
なお、MediaUpload の unstableFeaturedImageFlow は featuredImageFlow として安定化した。旧名は同じく7.4で削除される予定だ。
プラグイン配布とデータベースに影響する変更
プラグインの新リリースに自動セキュリティレビューが入る
WordPress.orgディレクトリへプラグインを配布している開発者は、リリース時の扱いが変わる。プラグインチームが新リリース向けの自動セキュリティレビューを導入した。リリース後のクールダウン期間に、複数のAIモデルとJetpack Scanが新しいリリースをスコアリングする。
高リスクと判定された場合は、リリースが自動的にブロックされ、コミッターには結果がメールで通知される。コミッターアカウントに登録したメールアドレスは、実際に誰かが読むものにしておくこと。通知を見逃すと、リリースが止まったまま気づかないという事態になりかねない。
NO_BACKSLASH_ESCAPES SQLモードの既定無効化
WordPress 7.2から、wpdb はデータベースセッションから NO_BACKSLASH_ESCAPES SQLモードを取り除く。多くのサイトには影響しない変更だが、このモードに依存している環境では注意が必要だ。
どうしてもモードを維持したい場合は incompatible_sql_modes フィルターを使う。ただし使えるのは db.php ドロップインからのみで、プラグインやmu-pluginsからは読み込みが遅いため変更できない。
add_filter( 'incompatible_sql_modes', function ( $modes ) {
return array_diff( $modes, [ 'NO_BACKSLASH_ESCAPES' ] );
} );新テーマIpsum、ギャラリー拡張、Playground新ツール
新デフォルトテーマ「Ipsum」が登場
WordPress 7.2では新しいデフォルトテーマ「Ipsum」が同梱される。長く続いた年号ベースの命名から離れ、デフォルトテーマは独自の名前を持ち、カレンダーではなくデザインの必要性に応じて変更される方針になった。Ipsumという名前は、本番のコンテンツが入るまでページを埋める仮テキスト、lorem ipsumに由来する。
Ipsumは意図的にミニマルなブログテーマとして設計された。点線の下線と少数の書体で静かなページを作る。ヘッダー、ヒーロー、サイドバーは必要なときには表示され、執筆中は邪魔にならない。スタイルバリエーションは画像も含めてページ全体を塗り直すほど作り込まれている。開発チームは、デフォルトデザインだけでなくすべての組み合わせがWCAG AAを満たすと説明している。
ギャラリーブロックにグリッド表示とブレークポイント別設定
ギャラリーブロックにはグリッド表示のバリエーションが追加された。Gutenberg 24.0で導入され、Flexが従来どおりのデフォルトだ。既存のギャラリーは切り替えるまで挙動を維持する。
ギャラリーのCSSルールはFlexレイアウトのときだけ適用される形にスコープが絞られた。詳細度自体は変わっていないが、テーマ側で「常に適用される」前提のスタイルを書いている場合は、グリッド表示との組み合わせを確かめる必要がある。
ブレークポイント別の設定も強化された。Flexレイアウトでは列数とクロップ、全レイアウトでアスペクト比をビューポートごとに変えられる。表示端末に応じてギャラリーの見せ方を細かく制御したい場面で役立つ。
Playgroundにターミナルとメール受信トレイを追加
WordPress Playgroundに開発者向けのツールが2つ追加された。1つ目はDev Tools Dockだ。ライブサイトに対してPHPやWP-CLIのコマンドを実行できるターミナルが使えるようになった。TTYはなく、対話型や長時間実行するコマンドは拒否される。Blueprintの wp-cli ステップも同じ制限に従う。
2つ目はメールツールだ。wp_mail() 経由で送信されたメールをすべて捕捉し、ブラウザー上に表示する。通知メールのテストでメールキャッチャーを別途用意する手間が省ける。注意点として、捕捉対象はsendmail経路のみで、SMTPやAPIベースのプロバイダーを使う場合は表示されない。
この記事のポイント
- WordPress 7.2はBeta 1が10月20日、RC1が11月17日、正式版が12月8日に予定されている
wp_kses()はHTML APIベースへ再構築され、出力の正規化と除去ルールが強化される- Gutenberg 24.1でブロックサポートがほぼ全コアブロックに展開され、コアアイコンは線ベースへ移行した
- プラグインの新リリースには複数のAIモデルとJetpack Scanによる自動セキュリティレビューが入る
- 新デフォルトテーマIpsumとPlaygroundのターミナル、メールツールも登場した
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ACFブロックが編集画面で表示されない時の原因と対処（React 19実験を無効化）
GutenbergのReact 19実験が有効になると、ACFで登録したブロックが編集画面で「このブロックでエラーが発生したためプレビューできません」と表示され、プレビューできなくなることがある。この症状はACFがReact 19に未対応の段階で起こる互換性問題で、テーマのfunctions.phpにフィルターを追記してReact 18に固定すれば回避できる。
なぜACFブロックだけが編集画面でエラーになるのか
ACFで登録したブロックは、編集画面のプレビュー部分がReactコンポーネントとして扱われる。React 19ではコンポーネントの渡し方や内部処理が変更されたため、ACF 6.8.10以前の実装と噛み合わず「要素のタイプが無効です」という趣旨のReactエラー（コンソール上はReact error #130）が発生する。
コアブロックでは発生せずACFブロックだけに症状が出るのは、このエラーがブロックエディタ全体の不具合ではなくACFプラグイン側の互換性に起因するためだ。フロントエンドはサーバー側で描画されるため影響を受けず、編集画面のプレビューだけが壊れる。
編集画面では赤いエラー表示だけが出て手も足も出ないが、フロントエンドが正常ならこの互換性問題を強く疑ってよい。
React 19実験はなぜ自動で有効になるのか
GutenbergのReact 19実験は、互換性のないプラグインやテーマが見つからない限り自動で有効になる設計だ。不要なテーマやプラグインを整理した直後など、互換性チェックが通るようになったタイミングで突然有効化されることがある。
管理画面の「Gutenberg」メニューの「実験」画面で有効かどうかを確認できる。ただし一部のホスティング環境では、チェックを外しても保存されず、設定が既定値（有効）に戻ってしまう。そのため管理画面からの無効化だけでは対処できない場合がある。
この流れでReact 19が有効になった結果、ACFブロックのプレビューだけが壊れる。管理画面の設定が保存されない環境では、次の手順で強制的にReact 18へ固定する。
functions.phpでReact 18に固定する手順
対処は子テーマのfunctions.phpにフィルターを追記し、Gutenbergの実験オプションを上書きしてReact 18を維持する方法が確実だ。親テーマを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。
// ACFがReact 19に対応するまでブロックエディタをReact 18に固定する
$theme_disable_react_19 = function($experiments){
$experiments = is_array($experiments) ? $experiments : [];
$experiments['gutenberg-react-19'] = false;
return $experiments;
};
add_filter('option_gutenberg-experiments', $theme_disable_react_19);
add_filter('default_option_gutenberg-experiments', $theme_disable_react_19);このフィルターは、Gutenbergの実験設定を保存するオプションに対して gutenberg-react-19 フラグを常にfalseに上書きする。管理画面でチェックを外しても戻ってしまう環境でも、テーマ側から強制できるため再発しない。
ACFがReact 19に対応したバージョンにアップデートされたあとは、このコードを削除して通常の設定に戻す。削除し忘れると新しいReactを使うべきタイミングでも18に固定されたままになるため、ACFの更新履歴は確認しておく。
修正後にブロックが表示されるか確認する方法
functions.phpにコードを追加したあとは、サーバー側とプラグイン側のキャッシュを削除し、ブロックエディタをハード再読み込み（Ctrl + Shift + Rなど）する。ACFブロックを再配置し、プレビューが表示されることを確認する。
ブラウザのコンソールを開き、React error #130が消えていることも確認すると確実だ。本番環境で直接試すのが不安な場合は、ステージング環境に同じコードを入れて挙動を確認してから反映する。
ACF側の対応と今後のアップデート
この症状はACFがReact 19に正式対応するまでの過渡期の互換性問題として認識されており、ACFの開発側でも修正が進められている。今後のアップデートでReact 19対応が含まれた場合は、本記事のフィルターを外して編集画面の挙動を再確認する。
それまでの間は、本番環境でReact 19実験を有効にしたまま使い続けるリスクを避けるため、本記事のフィルターでReact 18に固定しておくのが現実的だ。関連するプラグインやテーマが更新されたタイミングで、ステージング環境から互換性を確認する流れを作っておくと安全だ。
よくある質問
React 19実験を無効化すればACFブロックは直るのか
直る。ただし一部のホスティング環境では画面上のチェックが保存されず、既定値の有効に戻ってしまう。その場合はfunctions.phpのフィルターで強制的に無効化する。
functions.phpを直接編集せずに対処する方法はあるか
コードスニペットプラグインを使ってフィルターを追加する方法がある。いずれも親テーマを直接編集しないこと。親テーマを更新するとコードが消えるため、子テーマかスニペットプラグインを使う。
フロントエンドは表示されるのに編集画面だけ壊れるのはなぜか
ACFブロックの公開ページはサーバー側で描画されるため、React 19の影響を受けない。編集画面のプレビューだけはReactで組み立てられるため、互換性の問題が表面化する。
ACF以外のブロックが同じエラーを出す場合はどうすればよいか
同じReact error #130がコアブロックや他のプラグインブロックでも出る場合は、React 19実験だけでなくブロックの登録方法やプラグインの競合も確認する。一旦全プラグインを無効化して切り分けるのが早い。
フィルターを入れたままACFをアップデートしても問題ないか
問題はないが、ACFがReact 19に対応した後もフィルターが残っていると、React 18に固定され続ける。ACFの更新履歴を確認し、対応が完了したらフィルターを外して動作を再確認する。
この記事のポイント
- React 19実験の有効化でACFブロックの編集画面プレビューがエラーになる
- フロントエンドは影響を受けず、編集画面だけに症状が出る
- 管理画面のチェックが保存されない環境ではfunctions.phpから強制する
- ACFがReact 19に対応したらフィルターを外して再確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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最適化の豊富な経験
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最適化の豊富な経験
WooCommerce 11.1でREST APIとStore APIが最大42%高速化。ブロック登録スキップの仕組み
WooCommerce 11.1がブロック登録の仕組みを大きく変更する。REST APIとStore APIのリクエストが従来より13〜18ミリ秒、割合で30〜42%速くなる見込みだ。
これまでWooCommerceはほぼすべてのリクエストでブロックタイプとパターンを登録していた。画面にブロックを描画しないAPIリクエストでも同じ準備処理が走り、無駄なコストになっていた。
この記事では変更の背景と仕組み、影響を受ける開発者の条件、具体的な対応方法を解説する。11.1は正式リリース前の段階のため、エクステンションを配布している開発者は事前テストが求められる。
なぜブロック登録をスキップするのか
ほぼ全リクエストで発生していた無駄な処理
WooCommerceはこれまで、ブロックタイプとパターンをほぼすべてのリクエストで登録していた。商品データを返すだけのREST APIリクエストでも、カート情報を返すStore APIリクエストでも、ブロックを描画しないのに登録処理が実行されていた。
ブロック登録にはファイル読み込みやメタデータ解析が伴う。1リクエストあたりの負荷は小さくても、APIを多用する店舗やヘッドレスコマース構成では応答速度に影響する。WooCommerceチームは「リクエストはブロックを描画または編集できる場合にのみ、ブロック登録のコストを支払うべき」という方針を取った。
Beforeではすべてのリクエストがブロック登録を経由していた。Afterではブロックを描画しないAPIリクエストが登録処理を飛ばし、その分だけレスポンスが速くなる。
描画しないリクエストに課されるコスト
従来の挙動は、ブロックを編集も描画もしないリクエストまでブロックエディタの準備をさせるものだった。この無駄はアクセス数に比例して増える。とくにモバイルアプリやフロントエンドを別システムで構築し、WooCommerceをAPI経由で使う構成では影響が大きい。
今回の最適化は、APIリクエスト全体に占めるブロック登録のコストが想定以上に大きかったことを示している。13〜18ミリ秒の改善は体感的には小さいが、ピーク時に多数のリクエストを処理する店舗では合計の短縮効果が積み上がる。
11.0から11.1へ段階的に進めた変更
11.0で導入したパターンの遅延読み込み
第一段階はWooCommerce 11.0で実装された。パターンがファイルパスで登録され、エディタから要求されたときだけ内容が読み込まれるようになった。WordPressコアと同じ挙動だ。ブロックを登録するリクエストごとに5〜8ミリ秒の節約が確認されている。
11.1のBlockRegistrationContextガード
11.1では新しいBlockRegistrationContextガードが追加された。このガードがリクエストを判定し、ブロックを描画しない場面ではブロックタイプとパターンの登録をまとめてスキップする。
商品説明を守るオンデマンド登録の例外
1つだけ例外がある。商品説明やバリエーション説明にWooCommerceブロックが含まれる場合、woocommerce_short_descriptionフィルター経由で必要なときにブロックタイプが登録される。これにより商品REST API、Store API、バリエーションAJAXエンドポイント、商品のWebhookでも説明が正しく描画される。
2段階の変更により、パターン読み込みとブロック登録という2つの重い処理がAPIリクエストから外れた。完成した最適化の効果が30〜42%という数字に表れている。
対象リクエストと安全性の設計
スキップ対象と従来どおりのリクエスト
スキップされるのはブロックを描画しないリクエストのみだ。フロントエンド、管理画面、ブロックエディタ、サイトエディタのリクエストは従来どおりブロックを登録する。
見落としがあっても表示は壊れない
ガードは自身が認識したコンテキストだけをスキップする。認識できない場面では登録を継続するため、分類に漏れがあったとしても描画の後退にはつながらない。性能が少し落ちるだけで済む設計だ。
この設計は保守性の面でも合理的だ。未知のリクエストに対して安全側に倒すため、WooCommerceの内部判断が変わっても既存サイトの表示が突然崩れるリスクを抑えられる。
開発者が確認すべき影響範囲
影響を受けるエクステンションの条件
この変更はWooCommerce 11.1.0から適用される。スキップされるリクエスト中にWooCommerceブロックを描画するエクステンション、またはWooCommerceのブロックタイプ、パターン、ブロックごとのアセット登録に依存するエクステンションが影響を受ける。
スキップされた場面では、WooCommerceブロックは生のブロックマークアップか、動的出力のない静的なHTMLとして返る。テンプレートに直接ブロックを組み込んでいるエクステンションは、表示内容が変わらないか確認が必要だ。
コードで確認する方法
影響の有無はコードで確認できる。以下のコードはWooCommerce 11.1以降のスキップ対象リクエストでfalseを返す。
// WooCommerce 11.1以降、スキップされた場面では false を返す。
WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' );商品説明と自前ブロックは影響なし
商品説明とバリエーション説明はオンデマンドで処理されるため対応は不要だ。register_block_type()で自前登録しているブロックも影響を受けない。今回の変更はWooCommerce自身が行う登録だけが対象になる。
実務では「自前でブロックを登録しているか」「WooCommerceのブロック登録に依存しているか」の切り分けが重要になる。前者は今回の変更を意識する必要がなく、後者だけが対応を検討すればよい。
開発者が取るべき対応と正しいブロック作成
woocommerce_should_register_blocksフィルターで復帰
影響を受けるエクステンションは、新しいwoocommerce_should_register_blocksフィルターを使い、実際にブロックを描画するリクエストのときだけtrueを返す。
add_filter(
'woocommerce_should_register_blocks',
function ( $should_register ) {
return my_context_renders_blocks() ? true : $should_register;
}
);フィルターはプラグイン読み込み時に実行され、メインクエリが解析される前の段階で呼ばれる。そのため条件には$_SERVERや$_GETなど、この初期段階で利用できる情報だけを使うことになる。
復帰させる範囲を絞りすぎるとブロックが見つからず表示が変わることがある。逆に広げすぎると今回の性能改善が失われる。描画が実際に発生するリクエストを正確に判定する条件を書くのが開発者の作業になる。
内部クラスAbstractBlockを避ける
WooCommerceはブロックをAbstractBlockという内部クラスの上に構築しないよう推奨している。内部クラスを継承すると、WooCommerceが下すすべての登録判断、今回のスキップも含めて引き継ぐことになる。
登録の最適化が進むにつれ、内部クラスのライフサイクルは今後も変わり続ける。依存すると将来のアップデートで予期しない挙動になる可能性が高い。
標準のWordPress Block APIを使う
サポートされる方法は標準のWordPress Block APIだ。ブロックをblock.jsonに定義し、init時にregister_block_type()で登録する。カートやチェックアウトの内部ブロックには@woocommerce/extend-cart-checkout-blockテンプレートがある。
WooCommerceの公式ドキュメントにあるスキャフォールディングとサンプルストアデータ、@wordpress/create-blockも出発点として適している。標準APIに沿って作れば、今後の最適化に追随しやすい。
正式リリース前の段階で、WooCommerceはエクステンション開発者に11.1へのテストを呼びかけている。とくに商品データやカート情報をAPIで扱う拡張を配布している場合は、早めの動作確認が安全だ。
この記事のポイント
- WooCommerce 11.1はブロックを描画しないリクエストでブロック登録をスキップする
- Store APIとREST APIは13〜18ミリ秒、割合で30〜42%高速化する
- 商品説明や自前登録ブロックは影響を受けず対応不要
- 影響を受ける場合のみ woocommerce_should_register_blocks フィルターで復帰させる
- 内部クラスAbstractBlockではなく標準のWordPress Block APIでブロックを作る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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最適化の豊富な経験
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 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最適化の豊富な経験
WordPress 7.1 Beta 3リリース、グローバルスタイル適用の改善点を解説
Beta 3がもたらす現場へのインパクト
WordPress 7.1の正式リリースは2026年8月19日に迫っている。今回公開されたBeta 3は、単なるバグ修正の積み上げではない。ブロックエディタのスタイル管理に根本的な考え方の変更をもたらす機能が含まれている点が最大の注目点だ。
具体的には、「Apply globally（グローバルに適用）」機能の改善だ。これまで、あるブロックに加えたスタイル変更をサイト全体に反映させる操作は、すべての変更を一括で上書きするか、まったく適用しないかの二者択一だった。この「全か無か」の動作は、実際のデザインワークフローにおいて多くの小さなストレスを生んでいた。
Beta 3で導入された改良では、適用前にレビューステップが挿入される。これにより、変更したスタイルのうち、どれをグローバルに適用し、どれをそのブロックだけのローカルな変更として残すかを選択できるようになる。部分的なグローバル適用が可能になることで、サイト全体のデザイン整合性を保ちながら、特定のブロックだけ微調整するという、現実的な運用が格段にやりやすくなった。
このレビューステップの導入により、デザイナーやサイト運営者は「うっかり全ブロックのスタイルを壊してしまった」というヒヤリハットから解放される。部分的な適用が可能になったことで、より積極的にグローバルスタイルを活用できるようになるだろう。
メディアアップロードの地味だが確実な改善
Beta 3には、日々の運用で遭遇しがちなメディア関連のバグ修正も含まれている。長尺のGIFアニメーションをアップロードした際に処理が停止してしまう問題が解消された。また、EXIFメタデータで回転情報が埋め込まれた画像が、正しい向きで処理されるようになった。
Safariブラウザで単一のHEIC画像をアップロードすると、誤ってエントリーが二重に作成される問題も修正されている。これらの修正は派手さこそないが、クライアントワークで大量の画像を扱う制作会社や、更新頻度の高いメディアサイトの運用者にとっては、地味に嬉しい改善と言える。
テストに参加する4つの方法
WordPress 7.1 Beta 3は、本番サイトでの使用を想定していない。あくまでテストと開発を目的としたリリースだ。テスト環境は、ローカルPC上のLocal by FlywheelやDevKinsta、あるいはXAMPPやDockerを使った手動セットアップなど、普段使い慣れたもので問題ない。
テスト環境を用意したら、以下のいずれかの方法でBeta 3を入手できる。
特にWordPress Playgroundは、データベースすら必要としないブラウザ完結型のテスト環境だ。とりあえず新機能を触ってみたいという場合には、最もハードルが低い選択肢だろう。
なぜベータテストへの参加が重要なのか
WordPressのメジャーバージョンアップは、世界中のサイトに影響を及ぼす。7.1では、Beta 1以降だけでも71件以上の課題が修正されている。これらの修正の質を高めるには、多様な環境でのテストが不可欠だ。
ベータテストは、開発経験の有無を問わない。普段使っているプラグインやテーマとの組み合わせで問題が起きないかを確認するだけでも、リリースの品質向上に大きく貢献できる。公式のテストガイドには、特に重点的に確認すべき項目がまとめられている。
不具合の報告はフォーラムへの投稿で十分だ。再現手順を明確に説明できる場合は、Tracでのチケット発行が推奨される。報告の前に既知のバグ一覧を確認すれば、重複を避けられ、開発チームの負荷も減らせる。
7.1正式版に向けた最終段階
WordPress 7.1のリリーススケジュールは、2026年8月19日が最終目標だ。8月16日から19日まで開催されるWordCamp US 2026の会期と重なるタイミングでのリリースは、コミュニティにとっても大きな節目となるだろう。
今回のBeta 3では、スタイル管理の柔軟性向上に加え、メディア処理の安定化、Notes機能やレスポンシブスタイリング、カスタムCSSに関するエディタの修正も含まれている。開発者向けには、WordPress Coding Standardsがバージョン3.4.0に更新された。
一方で、Unicodeメールアドレス対応は7.1への搭載が見送られることが決まった。この機能はコミュニティプラグインとして開発が継続され、互換性やセキュリティ面の検証がより広範囲に行われる予定だ。
なお、7月17日にはBeta 2がWordPress 7.0.2のリリースの一環として公開されており、重要なセキュリティ修正が含まれている。テスト環境を最新の状態に保つ際は、この点にも注意が必要だ。
この記事のポイント
- Apply globally機能にレビューステップが追加され、スタイル変更を部分的にグローバル適用できるようになった
- 長尺GIFの処理停止やSafariでのHEIC二重登録など、メディアアップロードの実用的な不具合が修正された
- テスト参加はプラグイン、直接ダウンロード、WP-CLI、Playgroundの4経路から選択可能
- Unicodeメールアドレス対応は7.1への搭載が見送られ、コミュニティプラグインとして開発が継続される
- 正式リリースは2026年8月19日、WordCamp US 2026の開催期間と重なるタイミングで公開予定
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験