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テーマのアクセシビリティ対応、思ったより簡単な理由
アクセシビリティ対応を難しく感じる本当の理由
WordPressテーマのアクセシビリティ対応に取り組もうとした開発者の多くが、最初の段階でつまずくポイントがある。WordPress.orgのテーマリポジトリで「accessibility-ready」タグを取得するための要件文書だ。WP TavernのポッドキャストでJessica Lyschik氏が指摘したように、この要件文書は初めて読む人にとって「暗号的」に映りがちだ。
問題の核心はドキュメントの書き方にある。要件には「こうあるべき」という達成目標と簡単なテスト手順は書かれているが、具体的にどのような技術的実装をすればよいのかが明示されていない。例えば「適切なHTML5タグを使用すること」という趣旨の要件があっても、header、footer、main、section、asideの各タグをどう配置すべきかまでは書かれていない。
Lyschik氏自身もこの問題を実感した一人だ。彼女が管理するテーマを新要件に合わせて見直した際、アクセシビリティの知識を何年も積んできた自分ですら「なるほど、こういう意味だったのか」と再確認する場面があったという。ましてやアクセシビリティに初めて触れる開発者にとっては、抽象的な要件と実際のコードを結びつけること自体が大きな障壁になる。アクセシビリティは「難しい」のではなく、「何をすればいいかが分かりにくい」分野なのだ。
Lyschik氏がWordCamp Europe 2026のセッションで伝えたかったのは、まさにこの点だ。要件文書の「行間」に埋もれた実装知識を言語化し、開発者が自信を持ってアクセシビリティに取り組めるようにすること。ドキュメント改善は現在進行形の課題だが、基本的なHTMLとCSSの知識があれば、大半の要件は想像よりはるかに簡単にクリアできる。
今日から実践できる3つの具体的な改善策
WP TavernのインタビューでLyschik氏は「ロー・ハンギング・フルーツ（手の届きやすい果実）」という表現を使った。大きな努力をしなくてもすぐに成果が出る、アクセシビリティ改善の第一歩が確かに存在する。以下は彼女が実際に推奨する3つの即効性のある施策だ。
画像の代替テキストを省略しない
最も基本的かつ効果が大きいのが代替テキスト（alt属性）の付与だ。WordPressのメディアライブラリには代替テキストを入力するフィールドが標準で用意されている。ブロックテーマなら画像ブロックを選択するだけで、サイドバーにaltテキスト入力欄が表示される。目の前にある入力欄を飛ばさずに埋めるだけの作業で、スクリーンリーダーユーザーやAIエージェントに画像の意味を伝えられる。
正しいHTMLタグの選択とスキップリンクの設定
ブロックテーマでは、HTMLタグの割り当てが驚くほど簡単になっている。コンテンツ全体をグループブロックで囲み、そのグループに「main」のHTMLタグを設定するだけで、WordPressがスキップリンク（Skip to Content）を自動生成する。このスキップリンクは、キーボード操作ユーザーが毎回ヘッダーメニューを通過せずに、直接本文へジャンプできる重要な導線だ。
クラシックテーマでは手動で実装する必要があったこの機能も、ブロックテーマなら数クリックで完了する。テンプレートパーツのheader/footerも適切に割り当てれば、Coreが自動で正しいHTML構造を出力してくれる。
本文中のリンクには下線を付ける
本文中のリンクテキストに下線を付けることは、CSS1行で実現できる変更だ。Lyschik氏は「text-decoration: underline; の1行を追加するだけ」と表現している。色だけに依存したリンク識別は、色覚特性のあるユーザーやコントラストが低下した環境で機能しなくなる。特にWCAG（Web Content Accessibility Guidelines）が要求するコントラスト比を満たす設計では、下線による補助表示が欠かせない。
Lyschik氏が強調するのは「最初から組み込む」ことの重要性だ。後から数百ページにわたってボタンのaria-labelを修正する作業を想像してみてほしい。彼女の同僚が実際に経験した「12箇所×2種類のボタン」修正は、事前に対応していれば5分で済んだはずの作業だった。あとから修正するコストは、最初に対応する手間と比べて指数関数的に増大する。
ブロックテーマが変えるアクセシビリティの常識
WordPressのテーマ開発はクラシックテーマからブロックテーマへと大きな転換点を迎えている。アクセシビリティの観点から見ると、この移行は単なるトレンドではなく、根本的な実装難易度の低下をもたらしている。
Coreが肩代わりするようになった処理群
ブロックテーマで最も大きな変化は、WordPress Core（コア）がアクセシビリティ対応の多くを自動処理するようになった点だ。Lyschik氏が具体的に挙げた例をいくつか紹介する。
特筆すべきは検索フォームとコメントフォームの扱いだ。クラシックテーマではフォームのラベル設定やエラー処理をテーマ開発者が実装する必要があったが、ブロックテーマではCoreがこれを完全に引き受けている。テーマ開発者はブロックを配置するだけで、自動的にアクセシブルなフォームが出力される。
既存テーマの構造をテンプレートとして再利用する
Lyschik氏が提案する効率的なアプローチは、アクセシビリティ対応済みのテーマからテンプレート構造をコピーすることだ。新しいテンプレートを作成する際、ゼロから設計するのではなく、すでに正しいHTML構造を持つ既存テンプレートを複製して色やレイアウトだけを変更する。これにより、header、main、footerのタグ割り当てが自動的に継承され、意図せずアクセシビリティを損なうリスクを回避できる。
この手法の前提として「どのテーマが正しくアクセシビリティ対応されているか」の知識が必要になるが、WordPress.orgテーマリポジトリで「accessibility-ready」タグを取得しているテーマ（現在約270テーマ、全体の1.5%程度）が信頼できる参照先となる。
AIエージェントが変えるアクセシビリティの優先順位
インタビューの中でLyschik氏が特に強調したのが、AIエージェントの台頭がアクセシビリティの重要性を根本的に変えつつあるという洞察だ。この視点は、従来の「障がい者支援」という枠組みを超えて、アクセシビリティをビジネス上の競争力として再定義する可能性を秘めている。
AIエージェントは「見た目」ではなく「構造」を読む
Lyschik氏がAnne-Mieke Bovelett氏から共有されたという資料では、AIエージェントとスクリーンリーダーの動作原理が本質的に同じであることが指摘されている。AIエージェントはWebサイトを人間のように「視覚的」に理解するわけではない。HTMLの構造、適切なタグ、正確なラベル付けに依存して情報を取得し、操作を実行する。
■ アクセシビリティ対応サイト:AIエージェントがスムーズに取引を完了
Googleが2026年6月に発表したドキュメントでも、AIエージェント向けのアクセシビリティに注力する方針が示されている。これは単なる技術的関心ではなく、ECサイトの将来像に直結する話だ。ユーザーが直接ブラウザを操作せず、AIエージェントに「コーヒー豆を購入して」と依頼する世界では、アクセシビリティ対応の有無が売上に直結する。
アクセシビリティは「コスト」ではなく「投資」になる
Lyschik氏が言及したAnne-Mieke Bovelett氏の事例では、ある企業がWebサイトのアクセシビリティ改善に取り組んだ結果、売上が実際に増加したという。この事例が示すのは、アクセシビリティ対応が単に「法的リスクの回避」や「道徳的義務」という枠を超えて、ビジネス成果に寄与するという事実だ。
AIエージェントの普及はこの傾向を加速させるだろう。適切に構造化されたHTML、明確なラベル付け、正しいフォーム処理を持つWebサイトは、AIエージェントによる自動操作の信頼性を高める。2025年以降、この「AIフレンドリー」な設計がECやサービスサイトの競争優位性を左右する可能性は高い。
最初から組み込むアクセシビリティの設計思想
Lyschik氏が一貫して訴えているのは「アクセシビリティは後付けの修正ではなく、設計段階から組み込むべきもの」という原則だ。彼女自身の経験と、同僚が直面した「24回のaria-label追加作業」のエピソードが、この主張を裏付けている。
ボタンのaria-label追加に見る「後付けの代償」
インタビューで紹介された実例がある。クライアントのアクセシビリティテストで、アイコンのみのボタン（電話アイコンなど）がスクリーンリーダーで機能しないと指摘された。アイコンだけでは「このボタンが何をするのか」を読み上げられないからだ。修正にはaria-label属性を追加するだけで済むが、問題はその数だった。12箇所×2種類のボタン、合計24回の手動修正が必要になった。
Lyschik氏はこの経験を「設計時にaria-labelを追加しておけば5分で終わっていた作業」と総括する。テーマやサイトの構築時にアクセシビリティを考慮していれば、後から数百ページにわたって同じ修正を繰り返す必要はなかったはずだ。
学際的な意識共有が不可欠
アクセシビリティは開発者だけの責任ではない。Lyschik氏は「interdisciplinary（学際的）」という言葉を使い、SEO担当者、コンテンツ制作者、デザイナーを含む全ての関係者が基本的な知識を持つべきだと指摘する。
見出しタグ（H1〜H6）の正しい階層構造は、その典型的な例だ。H1の下にH2、その下にH3という順序を守ることは、スクリーンリーダーユーザーの文書理解を助けるだけでなく、検索エンジンのコンテンツ解析精度にも影響する。SEOとアクセシビリティは、しばしば同じ方向を向いている。
この記事のポイント
- アクセシビリティ対応の難しさは「技術そのもの」ではなく「ドキュメントの分かりにくさ」に起因している
- 画像の代替テキスト入力、正しいHTMLタグ割り当て、リンク下線付与は今日から着手できる即効性の高い施策だ
- ブロックテーマではスキップリンクやフォームラベルなど、Coreがアクセシビリティ処理を大幅に肩代わりする
- AIエージェントの普及により、アクセシビリティ対応はECサイトの売上やビジネス成果に直結する要素になりつつある
- 設計段階からの組み込みが、後工程での膨大な修正作業を回避する最も効率的なアプローチだ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WP Rigで始めるWordPressテーマ開発——現代的なワークフローと学習環境
WP Rigは無料のWordPressテーマ開発ツールキットだ。スターターテーマとしての機能に加え、ComposerやNode.jsを統合した現代的な開発環境を提供する。2026年3月時点でバージョン3が公開されており、従来のクラシックテーマからブロックベースのテーマ、ハイブリッドなアプローチまで幅広く対応している。
プロジェクトの現在の管理者はRob Ruiz氏である。氏は2026年3月4日に公開されたWP Tavernのポッドキャストで、WP Rigの現状と将来像について語った。このツールキットは、テーマ開発の学習からプロダクション環境での利用まで、多様なユーザー層をサポートすることを目指している。
WordPressのエコシステムがブロックエディタとフルサイト編集（FSE）へと移行する中で、テーマ開発の在り方も変化している。WP Rigはこうした変化に対応し、開発者が最新のベストプラクティスを学びながら実践できる環境を整備した。
WP Rigとは何か——スターターテーマと開発ツールキット
WP Rigは「スターターテーマ」と「開発ツールキット」の両方の性格を持つ。Underscoresのような最小限のテーマ基盤を提供する一方で、現代的なフロントエンド開発に必要なツール群をあらかじめ統合している点が特徴だ。
コアとなる機能と統合ツール
WP Rigのプロジェクトをクローンすると、Node.jsとComposerの依存関係が自動的に解決される。これにより、開発者はすぐにコーディング作業に取りかかれる。統合されている主なツールは以下の通りだ。
- CSS処理: Lightning CSS（旧PostCSS）による最新CSS機能の先行利用とブラウザ互換コードへの変換
- JavaScript処理: esbuildによるTypeScriptのトランスパイルとバンドル
- コード品質: PHPCS（PHP Coding Standards）とWordPressコーディング標準（WPCS）に基づく自動チェック
- 開発サーバー: ファイル変更の監視と自動ビルド
これらのツールは、開発者が個別に設定する必要がなく、WP Rigの設定ファイルを介して一元的に管理される。これにより、開発環境の構築にかかる時間を大幅に短縮できる。
従来のスターターテーマとの違い
従来のスターターテーマは、主にテンプレートファイルのひな形を提供することに焦点が当てられていた。一方、WP Rigは開発「プロセス」そのものを標準化することを目指している。コードの書き方からビルド、品質チェックまで、一連のワークフローをツールが支援する。
Rob Ruiz氏はポッドキャストで、このアプローチについて次のように説明している。「WP Rigは単なるファイルの集合ではない。ベストプラクティスを学び、適用するためのガードレールを提供するものだ」。特にチーム開発では、この標準化されたワークフローがコードの一貫性を保ち、レビュー工数を削減する効果がある。
誰のためのツールか——学習者からプロフェッショナルまで
WP Rigの対象ユーザーは幅広い。WordPress管理画面でのサイト構築に慣れたユーザーが、次のステップとしてコードベースのカスタマイズに挑戦する場合にも適している。一方、経験豊富な開発者が新規プロジェクトを効率的に立ち上げるためにも利用できる。
ページビルダーユーザーからの移行
ページビルダーやブロックエディタによるビジュアル編集には限界がある。デザインの細かい調整や、最新のCSS機能をすぐに利用したい場合、コードを直接編集する方が柔軟性が高い。WP Rigは、こうしたユーザーがローカル開発環境を整え、段階的にテーマ開発を学ぶための足がかりとなる。
Ruiz氏はポッドキャストで、コードによる制御の利点を強調した。「データベースに保存された設定値を一つずつ変更するのではなく、CSSファイルを一行修正するだけでサイト全体の見た目を変えられる。これがコードの持つ『超能力』だ」。WP Rigは、この「超能力」を安全に習得するための学習環境を提供する。
エージェンシーとチーム開発での活用
カスタムテーマをクライアントに提供するWeb制作会社では、開発プロセスの標準化が重要だ。WP Rigをプロジェクトの基盤とすることで、複数の開発者が同じコーディング規約とビルドプロセスを共有できる。新規メンバーのオンボーディングも容易になる。
また、WP Rigにはテーマの「バンドル」機能が備わっている。開発が完了したテーマを配布用にパッケージ化する際、すべてのソースコード内の「WP Rig」という文字列がテーマ名に置換される。これにより、エンドユーザーが基盤技術を意識することなく、完成したテーマを利用できる。
開発環境の構築とワークフロー
WP Rigを利用するには、ローカルマシンに特定のソフトウェアをインストールする必要がある。リモートサーバーではなく、ローカル環境でテーマ開発を行うのが基本だ。
必要な事前準備
WP Rigを動作させるための最小限の環境は以下の通りだ。
- Node.js: JavaScriptの実行環境。バージョン管理ツール（nvmやfnm）でのインストールが推奨される。
- Composer: PHPの依存関係管理ツール。グローバルにインストールする。
- ローカル開発環境: Local WP、WordPress Studio、Dockerベースのwp-envなど、任意の環境を選択可能。
これらのツールをインストールした後、WP RigのGitHubリポジトリをクローンし、依存関係をインストールする。プロジェクトルートでnpm installとcomposer installを実行すれば、開発環境の準備は完了だ。
開発からバンドルまでの流れ
WP Rigを使った典型的な開発ワークフローは以下のステップで構成される。
- 1. 開発サーバーの起動:
npm startでファイル監視と自動ビルドが開始される。 - 2. コーディング: CSS、JavaScript、PHPファイルを編集する。変更は自動的に反映される。
- 3. コードチェック:
npm run lintでPHPとJavaScriptのコード品質を検証できる。 - 4. ビルド:
npm run buildで本番用の最適化されたアセットを生成する。 - 5. バンドル:
npm run bundleで配布用のテーマパッケージを作成する。
このワークフローの中で、開発者は複雑なビルド設定を意識する必要がない。ツールの更新が必要な場合も、WP Rigのバージョンアップに追随するだけで済む。
ブロックエディタ時代のテーマ開発
WordPressのフルサイト編集（FSE）とブロックベースのテーマが普及する中で、クラシックなテーマ開発の価値が問われている。WP Rigはこの変化を先取りし、複数の開発パラダイムをサポートするように進化した。
3つのテーマパラダイムへの対応
WP Rigは、一つのコードベースから以下の3種類のテーマを生成できる。
- クラシックテーマ: 従来通りのPHPテンプレートファイルを使用する。
- ユニバーサルテーマ: クラシックテーマとブロックテーマの機能を併用する。
- ブロックテーマ: HTMLテンプレートファイルとtheme.jsonで構成される。
プロジェクトの初期化後、コマンドラインからnpm run configureを実行すると、対話形式でテーマの種類を選択できる。選択に応じて、必要なファイルが自動的に生成または変換される。
テーマレベルでのブロック開発
WP Rigの特徴的な機能の一つが、テーマ内でのカスタムブロック開発をサポートしている点だ。通常、カスタムブロックはプラグインとして開発されるが、テーマに密接に関連するブロック（例: 特化したナビゲーションブロック）をテーマ内に実装できる。
ただし、この方法で開発したテーマをWordPress.orgの公式テーマリポジトリに投稿することはできない。リポジトリのガイドラインでは、ブロックの提供はプラグインに限定されているためだ。クライアントワークや自社サイトでの利用が主な用途となる。
Ruiz氏はこの機能について、「境界線を曖昧にすることを厭わない」と表現した。テーマとプラグインの役割分担に縛られず、プロジェクトの要件に最適な技術的選択を可能にする姿勢が反映されている。
教育資源としてのWP Rig
WP Rigの公式サイト（wprig.io）には、ツールの使い方だけでなく、WordPressテーマ開発そのものを学ぶための資源が豊富に用意されている。これはプロジェクトの重要な側面だ。
学習コンテンツの構成
サイトの「Learn」セクションには、以下のような教育資源が整理されている。
- ビデオチュートリアル: YouTubeチャンネルで基礎から応用までを解説
- 技術文書: CSS、JavaScript、PHPの各言語におけるベストプラクティス
- サンプルコード: 実際のユースケースに基づいた実装例
- 開発ガイド: ローカル環境構築からデプロイまでの手順
これらの資源は、単にWP Rigの使い方を教えるだけでなく、現代的なWeb開発の概念そのものを伝えることを目的としている。例えば、CSSのカスケードや詳細度、PHPの名前空間といった基礎概念も丁寧に説明されている。
コミュニティと貢献の機会
WP Rigはオープンソースプロジェクトであり、GitHub上で開発が進められている。バグ報告や機能提案はIssuesを通じて受け付けている。また、Discordサーバーでは開発者同士の交流が行われている。
Ruiz氏はポッドキャストで、コミュニティの重要性を強調した。「WordPress自体がコントリビューターに依存している。テーマ開発を学ぶ人が増え、やがてコアへの貢献者になる——そんな好循環を生み出したい」。WP Rigは、その入り口となることを目指している。
この記事のポイント
- WP Rigはテーマ開発のスターターキットであり、現代的な開発ツールを統合している。
- ローカル環境での開発を前提とし、Node.jsとComposerが必要だ。
- クラシック、ユニバーサル、ブロックテーマの3パラダイムに対応する。
- コード品質チェックや自動ビルドなど、チーム開発での標準化を支援する。
- 教育資源が豊富で、テーマ開発の学習環境としても機能する。
出典
- WP Tavern「#207 – Rob Ruiz on WP Rig and the Future of Theme Development」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験