WordPress 7.1で追加CSSは不要になる？レスポンシブスタイルの対応範囲

パソコンでは整っている業務案内の見出しが、スマートフォンでは何行にも折り返される。余白を少し狭くしたいだけなのに、追加CSSの編集や制作担当者への依頼が必要になる――。こうした場面で、WordPress 7.1の新機能をどこまで使えるのか迷っている方もいるでしょう。
WordPress 7.1 Beta 1には、画面幅に応じてブロックのスタイルを変える「Responsive styling」が含まれています。ただし、2026年8月1日時点ではベータ段階であり、正式版までに仕様が変わる可能性があります。
本稿では、現時点で確認できる操作と対応範囲、士業・中小企業サイトで想定される利用場面、正式版公開後に行いたい検証手順を整理します。

WordPress 7.1のレスポンシブスタイルで何が変わるのか

デスクトップ・タブレット・モバイル別に値を設定できる

WordPress 7.1 Beta 1で案内されているResponsive stylingは、ブロックのスタイル値をデスクトップ、タブレット、モバイルの画面幅ごとに設定する機能です。個別ブロックだけでなく、サイト内の共通デザインを扱うグローバルスタイルでも利用できると説明されています。[1]

公式テスト案内では、次のような調整例が示されています。[2]

• デスクトップでは大きく表示している見出しを、モバイルでは小さくする
• デスクトップで広く取っている余白を、スマートフォンでは狭くする
• タブレット表示だけ文字色を変える

検証対象にはHeading（見出し）、Group（グループ）、Button（ボタン）、Image（画像）などのブロックが挙げられています。これまで追加CSSで対応することが多かった軽微な調整を、管理画面内で行える範囲が広がる可能性があります。

ただし、すべてのブロックやスタイル項目が同じように対応するとは、現時点の公式資料から断定できません。「WordPress 7.1に更新すれば、あらゆるデザインを端末別に変更できる」と捉えないことが大切です。

対応範囲ではカスタムCSSを書かずに調整できる

WordPress公式は、対応するスタイルについて、カスタムCSSを記述せずに画面幅別の設定ができる機能としてResponsive stylingを紹介しています。[1]

たとえば、行政書士事務所のサイトで「建設業許可申請・経営事項審査サポート」という長い見出しがスマートフォンでは大きすぎる場合、モバイル用の文字サイズをエディターから指定できる可能性があります。中小企業診断士が支援先のサイトを確認し、サービス案内の余白を狭い画面だけ調整したい場合にも、対応する標準ブロックであれば管理画面内で試せると考えられます。

一方、「追加CSSが不要になる」という説明には範囲があります。複雑なレイアウト、独自ブロック、プラグイン固有の設定、独自のスタイルコントロールなどでは、従来どおりCSSや開発作業が必要になる可能性があります。エディター上の設定が既存のCSSをすべて置き換えるわけではありません。

正式版公開前のベータ機能である

WordPress 7.1 Beta 1は2026年7月15日に発表され、正式版は同年8月19日に公開される予定です。[1] 2026年8月1日時点では正式提供前であり、今後のベータ版やリリース候補版を通じて改良が続くと案内されています。

そのため、Beta 1時点の機能名称、画面構成、対応ブロック、設定項目、操作手順が、そのまま正式版に採用されるとは限りません。本番サイトへの導入判断は、正式版のリリース記事や開発者向け資料を確認したうえで行う必要があります。

Responsive editingの操作とdesktop-firstの継承を理解する

端末プレビューからレスポンシブ編集を有効にする

公式テスト案内によると、レスポンシブスタイルを編集する基本的な流れは次のとおりです。[2]

1. エディターの端末プレビュー用ドロップダウンを開きます。
2. 「Responsive editing」を有効にします。
3. TabletまたはMobileの表示へ切り替えます。
4. 対象ブロックを選び、文字サイズや余白などの値を変更します。
5. プレビューと公開側の画面で変更結果を確認します。

TabletまたはMobileを選んでいる間は、ブロックインスペクターに対象端末を示すバッジが表示されます。このバッジは、現在どの画面幅向けの値を編集しているのかを見分ける手掛かりになります。

Desktopではバッジが表示されません。デスクトップで指定した値は、小さい画面にも引き継がれる基本値として扱われるためです。Responsive editingを無効にすると、編集状態はデフォルトに戻り、端末バッジも消えます。

なお、名称やボタンの位置を含むUIは正式版までに変更される可能性があります。正式版の操作マニュアルを作る場合は、Beta 1の画面だけを前提にしないほうがよいでしょう。

デスクトップの値は小さい画面へ継承される

Responsive stylingでは、デスクトップの値を基本として、必要な箇所だけタブレットやモバイルで上書きするdesktop-firstの方式が採用されています。[2]

たとえば、デスクトップの見出しを48ピクセルに設定し、モバイルだけ30ピクセルに変更したとします。この場合、モバイルには30ピクセルの値が保存され、タブレット側で上書きしていなければ、タブレットにはデスクトップの基本値が引き継がれるという考え方です。タブレットとモバイルの双方に異なる値を指定することもできます。

この継承方式は、すべての端末向け設定を一から作らずに済む点では扱いやすいと考えられます。しかし、デスクトップ側の基本値を後から変更すると、上書きしていないタブレットやモバイルにも影響する可能性があります。

更新担当者は「デスクトップを直しただけ」と考えていても、スマートフォン表示まで変わることがあります。変更後は上書き済みの端末だけでなく、値を継承している端末も確認する運用が必要です。

端末プレビューとキャンバス幅の変更が連動する

TabletまたはMobileを選ぶと、編集キャンバスの幅も対応する表示へ変わります。反対に、キャンバス端のリサイズハンドルをドラッグして幅を変えると、対応する端末表示へ切り替わる仕組みです。[2]

公式テスト案内では、次の4種類のエディターが検証対象に挙げられています。

• 投稿
• テンプレートまたはサイト
• パターン
• ナビゲーション

ページ本文だけでなく、共通パターンやナビゲーションにも関係する可能性があるため、確認範囲を一つの投稿に限定しないことが重要です。

また、編集キャンバスは確認手段の一つにすぎません。公式テスト案内でも、プレビューや保存後のフロントエンド、つまり訪問者が見る公開画面での確認が求められています。[2] エディターで整って見えても、使用中のテーマやブラウザー、実機の画面幅によって結果が異なる可能性があります。

士業・中小企業サイトではどこに活用できるか

長い見出しや事務所名をモバイル向けに調整する

行政書士や中小企業診断士などのサイトでは、資格名、事務所名、支援業務の名称が長くなりがちです。パソコンでは一行に収まる見出しでも、スマートフォンでは三行や四行に折り返され、画面の大半を占めることがあります。

Headingブロックが対応していれば、デスクトップの文字サイズを保ちながら、モバイルだけ小さな値へ変更できる可能性があります。見出しの前後にある余白も対応項目であれば、狭い画面だけ調整できると考えられます。

ただし、文字を小さくすれば読みやすくなるとは限りません。行数を減らすことだけを優先すると、利用者にとって読みにくい大きさになるおそれがあります。実機で文字の大きさや行間を確認し、見出しそのものを短くできないかも含めて判断する必要があります。

料金案内やプロフィール欄の余白を整える

料金案内、業務案内、事務所プロフィールなどをGroupブロックでまとめているサイトでは、デスクトップ用の広い余白がスマートフォンでは過剰に見える場合があります。対応する余白設定をモバイルだけ狭くできれば、追加CSSを書かずに画面内の情報量を調整できる可能性があります。

たとえば、料金案内の各項目に上下40ピクセルの余白があり、スマートフォンでは項目間が離れすぎて見える場合、モバイル用の値を小さくして表示を比較します。ただし、具体的な適正値はサイトのデザインや文字量によって異なります。特定の数値をすべてのサイトへ一律に適用することはできません。

担当者ごとに異なる値を設定すると、同じサイト内でもページによって見た目がばらつきます。共通するデザインはグローバルスタイルで管理し、個別ブロックの上書きは例外的な箇所に限るなど、運用ルールを決めることが望ましいと編集部は考えます。

問い合わせ・相談予約の導線を端末別に確認する

相談予約や問い合わせのButtonブロックも、公式テスト案内に挙げられた検証対象の一つです。[2] ボタン自体や周辺の余白が対応していれば、スマートフォン向けに表示を調整できる可能性があります。

確認する際は、ボタンだけを見るのではなく、前後の説明文、入力フォームへの移動、ナビゲーションとの重なりまで含めて検証します。文字が途中で切れていないか、周辺の余白が狭すぎないか、縦向きと横向きの双方で操作できるかを実機で確かめるとよいでしょう。

予約・問い合わせ系プラグインが提供する独自ブロックでは、同じ設定を利用できるとは限りません。また、表示を変更したことが問い合わせ率の向上に直結するとも断定できません。効果を評価する場合は、変更前後の利用状況を別途測定する必要があります。

導入前に確認したい対応差とリスク

標準ブロックと独自コントロールでは対応状況が異なる

WordPress Developer Blogによると、標準のブロックサポートを使用するブロックではレスポンシブスタイルを利用できますが、ブロックが独自に持つスタイルコントロールには自動で適用されません。[3]

この違いは、既存サイトで利用できる範囲を判断するうえで重要です。外見は同じボタンや画像でも、WordPress標準ブロックなのか、テーマやプラグインが提供する独自ブロックなのかによって対応状況が変わる可能性があります。

特に、次の要素は個別に確認する必要があります。

• 独自に開発したブロック
• テーマに付属する専用ブロック
• ページビルダーで作成した要素
• 予約や問い合わせプラグインの固有ブロック
• 独自の設定パネルを持つ装飾機能

設定欄が表示されるかだけで判断せず、値を保存できるか、再編集後も維持されるか、公開画面へ反映されるかまで確認してください。

既存テーマとtheme.jsonの確認が必要になる

Beta 1では、テーマ制作者がtheme.jsonでレスポンシブ用のブレークポイントを定義できる機能も案内されています。[1] ブレークポイントとは、デスクトップ、タブレット、モバイルなどの表示を切り替える基準となる画面幅です。

一方、今回の資料だけでは、正式版における具体的な設定構文、初期値、既存のtheme.jsonとの互換性は確定できません。ブロックテーマとクラシックテーマで利用範囲に差があるのか、WordPress本体だけでどこまで使えるのかも、正式版の資料で再確認すべき項目です。

テーマ制作者やWeb制作会社は、既存のメディアクエリーと新しいブレークポイント設定が競合しないかも検証対象に含める必要があります。すでに追加CSSで端末別の指定を行っているサイトでは、エディターから設定した値と既存CSSのどちらが適用されるかを代表ページで比較するとよいでしょう。

権限・実機表示・アクセシビリティも確認する

管理者以外の利用者がどこまで端末別スタイルを変更できるかは、今回確認した資料では明らかになっていません。特にグローバルスタイルは複数ページへ影響する可能性があるため、サイト全体の設定を変更できる担当者と、個別記事を更新する担当者を分けることが望ましいと考えられます。

公開前には、少なくとも次の4段階で表示を比較します。

1. 編集キャンバスでデスクトップ、タブレット、モバイルを切り替えます。
2. WordPressのプレビュー画面で対象ページを確認します。
3. 検証環境の公開側画面を複数のブラウザー幅で確認します。
4. スマートフォンやタブレットの実機で、文字、余白、色、操作性を確認します。

文字サイズや文字色を端末別に変更する場合は、読みやすさや文字と背景のコントラストも確認対象です。アクセシビリティ、表示速度、ブラウザー間の差異に対する影響は、取材資料では確認できていません。レスポンシブスタイルを設定できることと、利用者にとって適切な表示になることは分けて評価する必要があります。

正式版公開後に行う検証手順

現行サイトの構成を棚卸しする

正式版を待つ間にも、現在のサイト環境は整理できます。WordPressの管理画面や制作資料を確認し、次の項目を一覧にしてください。

• WordPress、テーマ、プラグインの名称とバージョン
• ブロックテーマかクラシックテーマか
• 標準ブロック、独自ブロック、ページビルダーの使用箇所
• theme.jsonと追加CSSの利用状況
• トップページ、業務案内、料金案内、プロフィール、問い合わせなどの重要ページ
• 各ページの更新担当者とWordPress上の権限

ブロックの種類が分からない場合は、代表ページを編集画面で開き、リストビューやブロック設定欄から名称を確認します。独自ブロックやページビルダーを使っている箇所には印を付け、標準ブロックと分けておくと、正式版公開後の検証対象を選びやすくなります。

検証環境で代表ブロックと重要ページを試す

ベータ版を公開中の本番サイトへ直接導入することは避け、正式版公開後も、まず本番とは別の検証環境で試すのが安全です。最低限、Heading、Group、Button、Imageを使用している代表ページを一つ選びます。

検証結果は、次の順序で記録します。

1. デスクトップで設定されている基本値を記録します。
2. Tabletへ切り替え、必要な項目だけ上書きします。
3. Mobileへ切り替え、文字サイズや余白を上書きします。
4. 保存後に設定値が維持されているか確認します。
5. プレビューと検証環境の公開画面で結果を比較します。
6. 実機で見出し、余白、ボタン、画像、ナビゲーションを確認します。
7. デスクトップの基本値を変更し、下位の画面幅への継承を再確認します。

独自ブロックやプラグイン固有ブロックでは、同じ項目が表示されるか、保存後に値が消えないかを別に記録します。不具合や表示差がある場合は、ブロック名、テーマ名、プラグイン名、確認した画面幅を残しておくと、制作会社や開発者へ相談しやすくなります。

導入効果は実測して判断する

Responsive stylingによって、作業時間や外注費が減ることは現時点で実証されていません。導入効果を判断する場合は、「便利そう」という印象だけではなく、少数ページで次の数値を測ります。

• 端末別の表示調整に要した時間
• CSS修正を制作担当者へ依頼した回数
• 公開後に見つかった表示不具合の件数
• 更新担当者から制作担当者への問い合わせ件数
• 1ページ当たりの表示確認時間

たとえば、標準ブロック中心の業務案内ページを1件選び、従来の作業時間と比較します。独自ブロックが多いページも1件試せば、どこまで内製でき、どこから制作担当者の作業が必要なのかを分けやすくなります。

測定結果によっては、すべてのページで使うのではなく、日常的に更新する標準ブロック中心のページだけに利用範囲を限定する判断も考えられます。

まとめ｜まずは対応範囲を確認し、正式版後に検証する

WordPress 7.1 Beta 1のResponsive stylingでは、対応するブロックやスタイル項目について、デスクトップ、タブレット、モバイル別の値をエディターから設定できます。長い見出し、料金案内の余白、問い合わせボタン周辺など、士業・中小企業サイトで頻繁に調整する箇所にも活用できる可能性があります。

ただし、独自のスタイルコントロールは自動対応せず、追加CSSが全面的に不要になるわけではありません。2026年8月1日時点ではベータ段階であり、正式版までに名称、UI、対応範囲が変わる可能性もあります。

今日からできる行動は、WordPressの管理画面と制作資料を開き、使用中のテーマ、プラグイン、独自ブロック、ページビルダー、theme.json、追加CSS、更新権限を一覧にすることです。そのうえで、2026年8月19日の正式版公開後に公式リリース記事、Field Guide、Dev Noteを確認し、対応ブロックと最終仕様を照合してください。

本番サイトへ直接適用せず、まずは長い見出しや問い合わせボタンを含む代表ページを検証環境で一つ選びます。編集画面、プレビュー、公開画面、実機の順に結果を比較し、作業時間も記録することで、自社や事務所の運用に適しているかを具体的に判断できます。

出典一覧

1. WordPress.org「WordPress 7.1 Beta 1」（2026-07-15）
2. Make WordPress Test「Call for Testing: Responsive Styling」（2026-07-03）
3. WordPress Developer Blog「What’s new for developers (July 2026)」（2026-07-10）

この記事はAIが生成し、編集長のチェックを受けて公開しています。