2026年最新版！WordPressフルサイト編集（FSE）の実務での活用法と注意点
【動作確認済み環境】
・WordPress：6.7
・PHP：8.2
・確認日：2026年2月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
最近のWeb制作案件で、フルサイト編集（FSE）の採用を検討する場面がかなり増えてきました。
ブロックエディターでサイト全体を編集できる（FSE）は非常に便利な反面、実際の構築現場では従来のクラシックテーマと勝手が違い、「どこまで実務に組み込めるか」「クライアントワークで本当に採用して大丈夫か」と判断に迷うことも多いのではないでしょうか。
私自身、実案件でブロックテーマを導入した際、デザインの細かな調整やクライアントへの納品後の運用フローで壁にぶつかった経験があります。
この記事では、実際の制作現場でFSEをどのように取り入れ、どのようなケースで見送るべきか、実体験に基づいた判断基準をシェアします。
■ この記事でわかること
・FSEとクラシックテーマの実務レベルでの具体的な使い分け基準がわかります
・ブロックテーマ特有のトラブルと、その具体的な回避策がわかります
・theme.jsonを使った効率的なデザイン管理の考え方がわかります
・案件導入前に確認しておくべきクライアント要件のチェックポイントがわかります
・長期的な保守を見据えた、これからのテーマ選定の軸がわかります
1. FSEとクラシックテーマの実務における使い分け基準
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）が登場してから、新規案件のテーマ選定で迷う場面が増えてきました。実際の案件でも、お客様から「新しいブロックテーマにした方が良いのでしょうか」とご相談いただくことが多くなっています。
すべての案件をFSEで構築する必要はありません。サイトの目的や納品後の運用体制によって、従来型のクラシックテーマとFSEを明確に使い分けることが重要です。
以前、更新頻度が非常に高く、複数人の担当者が運用するコーポレートサイトの案件で、どちらのテーマを採用するか迷ったことがありました。最終的にクラシックテーマを選んだ理由は、入力項目を固定して管理画面の自由度を制限し、誰が更新してもデザインが崩れないようにするためです。FSEは直感的にサイト全体を編集できる反面、運用者が誤ってレイアウトを大きく崩してしまうリスクも伴います。
ここで、実務での使い分け基準を整理してみます。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSE（ブロックテーマ） | お客様自身で柔軟にレイアウトを変更したい場合 | 厳密なデザインルールの維持が必要な場合 |
| クラシックテーマ | カスタムフィールドを多用し、入力項目を固定したい場合 | ノーコードでヘッダーやフッターを頻繁に変更したい場合 |
新しい技術であるFSEを取り入れるメリットは、WordPress本体の開発の方向性がブロックベースに完全に移行している点にあります。長期的な将来性を考えると、シンプルな構成のサイトや、運用者が自由にページを組み立てたい場合には非常に適しています。
一方で、独自のPHP処理が複雑に絡むポータルサイトや、大規模なメディアサイトでは、現在のところクラシックテーマの方が開発効率や安定性の面で優位に立つケースが少なくありません。フック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を多用する複雑なカスタマイズも、クラシックテーマの方が制御しやすい場面が多いです。
どちらを選ぶか迷ったときは、「納品後に誰が、どこまで自由に更新するのか」を軸に考えると整理しやすいです。正解はひとつではないため、プロジェクトの要件に合わせて慎重に選択を検討してみてください。
2. 案件で直面したブロックテーマ特有のつまずきと解決法
フルサイト編集（FSE）を活用したブロックテーマでの制作は、従来のクラシックテーマとはアプローチが大きく異なります。実案件でブロックテーマを採用した際、多くの制作者が最初に直面する課題が「theme.jsonの制御」と「テンプレート階層の扱い」です。
以前、あるコーポレートサイトの案件でブロックテーマを導入した際、意図しない場所に余白が発生したり、エディター側でのみ独自のCSSが反映されないという問題に当たりました。その時の解決策をシェアします。
ブロックテーマでは、スタイルや設定をfunctions.phpではなく、theme.jsonというファイルで一元管理します。クラシックテーマの感覚でstyle.cssに直接記述していくと、ブロックエディターが自動生成するCSSと競合してしまい、画面が崩れる原因になります。
この問題を解決するためには、theme.jsonを使ってWordPressコアのデフォルトスタイルを制御し、必要な部分だけを上書きするというアプローチを取ります。
“`json
/ theme.jsonの記述例（テーマのルートディレクトリに配置します） /
{
“version”: 2,
“settings”: {
“layout”: {
/ コンテンツの基本幅を定義します /
“contentSize”: “800px”,
/ 幅広ブロックの幅を定義します /
“wideSize”: “1200px”
},
“spacing”: {
/ ユーザーがエディター上でマージンやパディングを変更できるようにします /
“margin”: true,
“padding”: true,
/ 意図しない余白を防ぐため、デフォルトのブロックスペースを無効化します /
“blockGap”: false
}
}
}
“`
この書き方が推奨される理由は、WordPress本体のアップデートによる影響を最小限に抑えられるからです。theme.jsonで設定を定義することで、フロントエンドとエディターの両方に同じCSSが自動的に適用されるため、編集画面と実際の公開ページの見た目が一致しないというトラブルを防ぐことができます。
よくある間違いとして、クラシックテーマと同じようにfunctions.phpで独自のエディター用CSS（editor-style.css）を無理やり読み込ませようとするケースがあります。ブロックテーマではtheme.jsonの機能を利用するほうが、保守性の観点でも長期的に見て安全です。
ただし、非常に複雑なアニメーションや、特定のブロックに対する高度な装飾が必要な場合は、theme.jsonだけでは表現しきれないことがあります。その際は、各ブロック専用のCSSファイルを分割して読み込む方法と併用するのが現実的です。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| theme.jsonでのスタイル管理 | 全体的なカラーパレットやタイポグラフィ、基本的な余白の統一が必要な場合 | 特定の1ページのみで使用する、非常に複雑で例外的なCSSアニメーションを実装する場合 |
| functions.phpでの機能追加 | プラグインが提供する独自の処理や、外部API（REST APIなど）との連携が必要な場合 | サイトの見た目やレイアウトに関する調整を直接行おうとする場合 |
WordPressの今後の方向性を考えると、FSEの機能はメジャーアップデートのたびに拡張されています。従来のPHPベースのテンプレートファイルから、HTMLベースのブロックテンプレートへと移行が進んでいるため、theme.jsonの仕様を深く理解しておくことは、Web制作者として今後の案件をスムーズに進めるための重要な判断基準になります。迷ったときは、「見た目のルールはtheme.json、裏側の処理はfunctions.php」と分けて考えると整理しやすいです。
3. theme.jsonを活用した効率的なデザイン管理の手法
FSE（ブロックエディターでサイト全体を編集できるWordPressの新機能）を利用したテーマ開発において、デザインシステムの中心となるのが`theme.json`というファイルです。従来のクラシックテーマでは、`style.css`や`functions.php`（テーマの機能を追加・カスタマイズするファイル）に分散していたカラーパレット、タイポグラフィ、余白などの設定を一元管理できる仕組みです。
実際の案件でFSEを導入する際、この`theme.json`をいかに設計するかが、その後の運用や保守の効率を大きく左右します。
まず、基本的な使い方として、ブランドカラーやフォントサイズを定義します。以下は、実務でよく使用する記述の一部です。
“`json
{
“version”: 2,
“settings”: {
“color”: {
“palette”: [
{
“slug”: “primary”,
“color”: “#005baa”,
“name”: “メインカラー”
},
{
“slug”: “secondary”,
“color”: “#f2f2f2”,
“name”: “背景グレー”
}
],
// ユーザーによるカスタムカラーの選択を制限する
“custom”: false
},
“typography”: {
// 任意のフォントサイズ入力を制限する
“customFontSize”: false
}
}
}
“`
この設定が推奨される理由は、デザインの統一性を保つためです。`”custom”: false`や`”customFontSize”: false`を指定することで、クライアントがエディター上で予期せぬ色や極端なフォントサイズを指定するのを防ぎます。内部的には、ここで定義した値がCSSのカスタムプロパティ（CSS変数）として出力され、エディター側とフロント側の両方で同じスタイルが適用される仕組みになっています。
以前、あるコーポレートサイトの案件で、これらの制限を設けずに納品したことがありました。数ヶ月後にサイトを確認すると、各ページで見出しの色や文字サイズがバラバラになっており、デザインの意図が崩れてしまっていました。その失敗を機に、現在では`theme.json`で利用可能なスタイルを厳格に定義し、不要な自由度を制限するアプローチをデフォルトにしています。
ただし、すべての案件でガチガチに制限をかけるのが正しいわけではありません。以下のように、プロジェクトの要件に応じて柔軟性を調整する必要があります。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| theme.jsonによる制限 | 複数人で更新作業を行う中規模以上のサイトの場合 | 担当者がHTMLやCSSに精通しており、自由な装飾を求めている場合 |
長期的に見ても、`theme.json`によるデザイン管理は、今後のWordPress開発における主流となります。メジャーアップデートの際も、設定ファイルとして構造化されているため、従来のCSSによる上書きよりも影響を受けにくく、保守性の面で優れています。迷ったときは、まずはカラーパレットとフォントサイズの定義から始め、プロジェクトの要件に合わせて少しずつ制限を解除していくと整理しやすいです。
4. フルサイト編集を導入する前に確認しておきたいクライアント要件
フルサイト編集（FSE）は、ブロックエディターでサイト全体を編集できるWordPressの新機能として注目を集めていますが、実際の案件ですべてのクライアントに提案してよいかというと、そうではありません。
正直なところ、以前は新しい技術を積極的に取り入れようと、運用体制の確認が不十分なままFSEをベースにしたテーマで納品したことがありました。結果として、クライアントがヘッダーやフッターのレイアウトまで誤って変更してしまい、サイトのデザインが大きく崩れてしまうというトラブルにつながりました。この経験から、導入前には必ずクライアントの要件と運用体制を深く確認するようにしています。
実務において確認すべき要件は、大きく分けて以下の3点です。
・サイト運営担当者のWordPressに対する理解度とリテラシー
・納品後にデザインやレイアウトを自社で頻繁に変更する予定があるか
・デザインの統一性（ブランドガイドライン）を厳格に守る必要があるか
FSEは「どこでも自由に編集できる」という強力なメリットがある反面、運用者がデザインのルールを理解していないと、意図しないレイアウト崩れを引き起こすリスクが伴います。そのため、あらかじめ編集できる権限を制限する設定（theme.jsonでのロックなど）を組み込むか、もしくはFSEを見送るという判断が必要になります。
導入の判断基準として、以下のように整理しています。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| フルサイト編集の導入 | 社内にWeb専任の担当者がいる場合 | 複数人で記事更新のみを行う場合 |
| 自由度の高いブロック構成 | 運用の中でABテストやレイアウト変更を繰り返す場合 | 厳格なブランドガイドラインがあり、デザインを固定したい場合 |
| テンプレートの自社編集 | ランディングページを頻繁に量産する体制がある場合 | ヘッダーやフッターなどの共通部分は制作会社に保守を任せたい場合 |
もし、クライアントが「記事の更新だけを安全に行いたい」というご要望であれば、FSEの導入は見送り、従来のクラシックテーマ（PHPベースのテンプレート）を採用しつつ、本文エリアのみブロックエディターで柔軟に構成できるようにする方が、保守性も高く安全に運用できます。
迷ったときは、「誰が、どのくらいの頻度で、どこまで編集するのか」をクライアントと一緒に整理することで、最適な構成が見えてきます。長期的な運用を見据えた設計を選択することが、最終的なクライアントの満足度につながります。
5. 今後の保守運用を見据えたWordPressテーマ選定の考え方
実際の案件でテーマを選定する際、フルサイト編集（FSE）に対応したブロックテーマを採用するか、従来のクラシックテーマを採用するかで迷う場面が増えてきました。ここでは、長期的な保守運用を見据えた際の、実務的な判断基準をシェアします。
FSE（フルサイト編集）は、ブロックエディターでサイト全体を編集できるWordPressの機能です。これを利用したブロックテーマは、HTMLやPHPを直接編集しなくてもヘッダーやフッターのレイアウトを変更できるため、運用時の柔軟性が高いという特徴があります。
一方で、柔軟性が高いということは、運用担当者が意図せずレイアウトを崩してしまうリスクも伴います。以前、社内に専任のWeb担当者がいないお客様の案件でFSEを採用した際、誤ってグローバルナビゲーションのブロックを削除してしまい、サイト全体に影響が出たというトラブルがありました。それ以降、運用体制に応じてテーマの作り方を切り替えるようにしています。
今後の方向性として、WordPress公式はブロックテーマの開発に注力しています。そのため、長期的な将来性や新機能への対応を考えると、FSEの仕組みを取り入れていくことは自然な流れです。しかし、実務においては「お客様がどこまで自社で更新したいか」が最も重要な判断軸になります。
以下に、保守運用を前提としたテーマ選定の基準を表にまとめました。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSE（ブロックテーマ） | 運用側で自由にレイアウトを変更したい場合、専任の担当者がいる場合 | 定型的な更新のみを行う場合、レイアウト崩れのリスクを極力避けたい場合 |
| クラシックテーマ | デザインを固定して安全に運用したい場合、PHPによる複雑な独自処理が必要な場合 | 頻繁にサイト全体のデザイン微調整を行いたい場合 |
迷ったときは、納品後の運用フェーズで誰がどのようにサイトを触るのかを想像してみてください。運用担当者がテキストや画像の差し替えのみを行うのであれば、クラシックテーマや、ブロックエディターの機能を意図的に制限したハイブリッドテーマの方が安全に運用できます。逆に、マーケティング施策に合わせてLP（ランディングページ）のような自由なレイアウトを頻繁に作成したい場合は、FSEの柔軟性が活きてきます。
目先の構築コストだけでなく、納品後の数年間の運用体制まで考慮してテーマを選定することが、お客様にとっても制作者にとっても安心できる結果につながります。