2026年最新版！WordPressフルサイト編集（FSE）とGutenbergのカスタマイズ術
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2026年1月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
「フルサイト編集（FSE：ブロックエディターでサイト全体を編集できる機能）、実際のところ実務で使えるレベルに達しているのだろうか？」
最近、同業者やWeb制作会社の担当者様からこのようなご相談をいただくことが増えてきました。実際の案件で構築を進める中で、クラシックテーマからの移行タイミングや、どこまでをブロックで制御し、どこからを自前でコーディングすべきか迷う場面は少なくありません。
この記事では、実案件を通して見えてきたフルサイト編集の現状と、Gutenbergの独自のカスタマイズ手法についてシェアします。最後までお読みいただくことで、案件の要件に応じた適切なアプローチを選択する軸が明確になります。
この記事でわかること
・フルサイト編集を実案件で採用する際の明確な判断基準がわかります
・クラシックテーマからの移行手順とつまづきやすいポイントがわかります
・実務でそのまま活用できるブロックのカスタマイズ手法がわかります
・保守性を考慮したテンプレートの設計・管理方法がわかります
・実際の開発現場で起きたトラブルの事例とその解決策がわかります
1. 実案件から見えてきたフルサイト編集の活用タイミングと判断基準
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）の実案件への導入について、迷われている方は多いのではないでしょうか。
「クラシックテーマから乗り換えるべきか」というご相談をよくいただきます。
結論から申し上げますと、すべての案件で無理にFSEを採用する必要はありません。
サイトの目的や運用体制によって、クラシックテーマと使い分けるのが現在の最適解だと考えています。
以前、コーポレートサイトのフルリニューアル案件で、FSEと従来のクラシックテーマのどちらを採用するか迷ったことがありました。
お客様は「お知らせやブログ記事だけでなく、トップページのレイアウトも自分たちで自由に変更したい」という強いご要望をお持ちでした。
このケースでは、お客様自身で柔軟なレイアウト変更が可能になるFSEを採用し、結果として日々の運用コストを下げることに成功しています。
一方で、デザインの厳密な再現性が求められるブランドサイトや、複雑なカスタムフィールドを多用するポータルサイトでは、現在でもクラシックテーマを採用しています。
内部でHTML構造を細かく制御する必要がある場合、ブロックの標準仕様が制約になってしまうことがあるからです。
実務レベルで導入を判断する際、私たち独自の基準として以下の表のように整理しています。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| フルサイト編集（FSE） | 運用側でレイアウトを柔軟に変更したい場合 | ピクセルパーフェクトなデザイン再現が必須の場合 |
| クラシックテーマ | 複雑な独自のデータ構造や機能を実装する場合 | ノーコードでの直感的なサイト構築を優先する場合 |
FSEは、WordPressの今後の方向性を示す重要な機能です。
長期的な保守性や将来性を考えると、新規のシンプルなサイト構築から少しずつFSEの仕様に慣れていくアプローチをおすすめします。
迷ったときは、「運用者がどこまでデザインに介入する必要があるか」を軸に考えると、判断が整理しやすいです。
2. クラシックテーマからFSEへ移行する際の注意点と具体的な手順
クラシックテーマからFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）への移行は、単なるテーマの切り替えではありません。サイトの構造そのものをPHPベースからHTMLとブロックベースへと作り変える、大きな転換となります。実際の案件でも、この移行作業についてのご相談を頻繁にいただきます。
ここでは、実務の現場で直面した課題をもとに、安全に移行するための注意点と手順をシェアします。
移行前に知っておくべき最大の注意点
一番の注意点は、これまで当たり前のように使っていた「header.php」や「footer.php」といったテンプレートファイルが、FSEでは機能しなくなることです。FSE対応のブロックテーマでは、テンプレートは「theme.json」という設定ファイルと、HTMLファイルで構成されるようになります。
以前、運用中のコーポレートサイトをFSEに移行する案件を担当した際、従来のfunctions.php（テーマの機能を追加・カスタマイズするファイル）に記述していた独自のショートコードや、header.phpに直書きしていた計測タグがそのままでは引き継がれず、対応に追われた経験があります。クラシックテーマで行っていたカスタマイズは、基本的にブロックパターンの作成やtheme.jsonへの記述に置き換える必要があります。
具体的な移行のステップ
安全に移行を進めるために、実案件では以下の手順を採用しています。本番環境で直接作業するのは避け、必ず検証環境（ステージング環境）を用意して進めてください。
1. 既存機能の棚卸し
functions.phpに記述された独自の処理や、プラグインとの依存関係をリストアップします。特に、特定のテンプレートファイルに依存しているプラグインの動作確認は必須です。
2. theme.jsonの基本設定
FSEの要となるtheme.jsonファイルを作成し、サイト全体のカラーパレット、タイポグラフィ、余白などのグローバルスタイルを定義します。これにより、エディター上でのデザインの一貫性を保つことができます。
“`json
/ theme.jsonの記述例（抜粋） /
/ サイト全体の基本カラーを設定する箇所に記述します /
{
“version”: 2,
“settings”: {
“color”: {
“palette”: [
{
“slug”: “primary”,
“color”: “#005baa”,
“name”: “Primary”
}
]
}
}
}
“`
3. テンプレートパーツのブロック化
従来のheader.phpやfooter.phpの内容を、サイトエディター上で「テンプレートパーツ」として再構築します。ナビゲーションメニューも、従来のメニュー設定からナビゲーションブロックへの移行が必要です。
4. 独自機能のプラグイン化
テーマに依存しない独自の機能（カスタム投稿タイプの定義など）は、functions.phpから切り離し、専用のプラグインとして独立させることを推奨します。これにより、将来的なテーマ変更時のリスクを減らすことができます。
向いているケース・向いていないケースまとめ
サイトの状況によって、FSEへの移行を見送った方が良い場合もあります。実務的な判断基準を以下の表にまとめました。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSEへの移行 | 新規構築や、シンプルな構成のサイトをリニューアルする場合 | 独自のPHPテンプレートを多用した複雑なポータルサイトや、ECサイトの場合 |
複雑なシステムが組み込まれているサイトの場合は、無理にFSEに移行せず、クラシックテーマを維持しながらコンテンツ部分のみブロックエディターを活用するアプローチも一つの有効な選択肢です。今後のメンテナンス性やサイトの規模を見据えて、最適な方針を検討してみてください。
3. Gutenbergブロックの独自カスタマイズ手法と実務で使えるコード解説
Gutenberg（ブロックエディター）が導入されてから、Web制作の現場では「独自のブロックをゼロから開発するか」「既存のブロックをカスタマイズして使うか」という選択を迫られる場面が多くなりました。実際の案件では、保守性や開発コストの観点から、既存のコアブロック（WordPressに標準で用意されているブロック）に独自のスタイルを追加する手法を多く採用しています。
ここでは、実務で頻繁に使用する「ブロックスタイルの追加」について、具体的なコードとともに解説します。
既存ブロックに独自のスタイルを追加する方法
クライアントから「見出しブロックに自社独自の装飾パターンを追加してほしい」という要望をいただくことは非常に多いです。この場合、新しく見出しブロックを作るのではなく、`register_block_style`関数を使用して既存の見出しブロックにスタイルを追加するのが適切なアプローチです。
以下のコードは、使用しているテーマの`functions.php`（テーマの機能を追加・カスタマイズするファイル）に記述します。アクションフック（特定のタイミングで処理を実行する仕組み）である`init`のタイミングで実行します。
“`php
/
Gutenbergブロックに独自のスタイルを追加する
記述場所：functions.php
/
function ebiz_register_custom_block_styles() {
// 見出しブロックに「下線付き（コーポレートカラー）」のスタイルを追加
register_block_style(
‘core/heading’, // 対象となるブロック名（この場合は標準の見出しブロック）
array(
‘name’ => ‘corporate-underline’, // スタイルの識別子（CSSクラスの生成に使用されます）
‘label’ => ‘下線付き（テーマカラー）’, // エディター上に表示される名前
‘is_default’ => false, // デフォルトスタイルにするかどうか
)
);
}
// initフックで実行してスタイルを登録
add_action( ‘init’, ‘ebiz_register_custom_block_styles’ );
“`
このコードを記述すると、エディター上の見出しブロックのサイドバーに「下線付き（テーマカラー）」という選択肢が追加されます。これを選択すると、フロント側のHTMLには`is-style-corporate-underline`というCSSクラスが自動的に付与されます。あとは、テーマの`style.css`などでそのクラスに対して装飾を記述するだけです。
なぜこの手法を採用するのか
以前の案件で、JavaScriptとReactを使用して独自のカスタムブロックを多数開発したことがありました。しかし、WordPressのメジャーアップデートの際にReact側の仕様変更の影響を受け、表示崩れやエディターのエラーが発生し、その対応に追われることになりました。
その経験から、現在では「WordPressコアの標準機能にのっかる」という方針をベースにしています。コアブロックの構造はWordPressの開発チームによって保守されているため、`register_block_style`でクラスだけを付与する形にしておけば、将来のアップデートで動かなくなるリスクを大幅に軽減できます。
向いているケース・向いていないケースまとめ
ブロックのカスタマイズ手法を選ぶ際の判断基準として、以下の表を参考にしてください。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 既存ブロックのスタイル追加 | 見出しやボタンなど、見た目の装飾だけを変えたい場合 | 複雑な入力フィールドや、外部APIと連携する独自の機能が必要な場合 |
| 独自ブロックの新規開発 | 業務システムと連動する特殊なUIが必要な場合 | 予算と納期が限られており、将来的なメンテナンスコストを抑えたい場合 |
保守性と将来性を見据えた判断基準
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）が主流になりつつある現在、カスタマイズの軸足は「PHPでのテンプレート出力」から「ブロックの組み合わせとスタイル定義」へ移行しています。
機能が足りないと感じたとき、すぐにプラグインを導入したり独自のブロックを開発したりするのではなく、まずは「標準ブロックのバリエーション追加で要件を満たせないか」を検討してみてください。これにより、テーマがシンプルに保たれ、長期間にわたってクライアントが安心して運用できるサイトを構築することができます。迷ったときは、この保守性の観点を第一に考えることをお勧めします。
4. 保守性を高めるためのテンプレートファイル構成と管理のコツ
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入した際、多くの制作者が直面するのがテンプレートファイルの管理方法です。クラシックテーマの時代とは異なり、FSEではHTMLベースのブロックテンプレートが主体となります。実際の案件でも、複数の担当者が管理画面から直接テンプレートを編集してしまい、本番環境とローカル環境の同期が取れなくなるというご相談をよくいただきます。
FSEにおけるテンプレートは、主にテーマディレクトリ内の「templates」や「parts」フォルダにHTMLファイルとして格納されます。管理画面のエディターから直感的に編集できる利点がある一方で、コードのバージョン管理が難しくなる側面を持っています。そのため、実務ではファイルの役割を明確に切り分け、どこで何を管理するかのルール決めが保守性を左右します。
この構成において重要なのは、theme.json（テーマの全体的なスタイルやエディターの挙動を制御するファイル）を中心とした設計です。スタイルやベースとなるレイアウトの定義はtheme.jsonとテンプレートファイルに集約し、管理画面からの上書きは最小限に留める設計が推奨されます。
なぜこの管理方法をとるのかというと、データベースに保存されるユーザーのカスタマイズ情報と、ファイルとして管理されるテーマファイルが競合することを防ぐためです。管理画面でテンプレートを編集すると、その変更はデータベースに保存され、ファイル側の記述よりも優先して読み込まれます。この仕組みを理解せずに開発を進めると、「ファイルを修正したのに本番環境に反映されない」というトラブルを引き起こします。
以前、複数人で運用するメディアサイトの案件で、運用担当者が管理画面からヘッダーの構造を変更してしまい、後日のテーマアップデート時にデザインが大きく崩れるという問題に当たりました。その時の解決策として、コアとなる構造部分は変更不可のパターンブロックとして定義し、運用側で変更してよい部分はウィジェット領域や特定のテンプレートパーツに限定するという方針を採用しました。
やりがちですが避けるべきなのは、すべてのページデザインを個別のテンプレートファイルとして乱造することです。似たような構造のテンプレートが増えすぎると、後から共通パーツの仕様変更があった際、修正漏れが発生しやすくなります。
このような属人的な管理をやめた方がよいケースは、数年単位で運用を継続する中規模以上のサイトです。代わりに、ブロックパターンを活用してデザインの再利用性を高め、エディター側での自由度を適度に制限するアプローチをとることで、デザインの統一感を保ちやすくなります。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 管理画面での自由なテンプレート編集 | 個人のブログや小規模なサイトの場合 | 複数人で運用する企業サイトやメディアの場合 |
| 厳密なファイルベースの管理 | バージョン管理システムを用いたチーム開発の場合 | クライアント自身が頻繁にレイアウト変更を行いたい場合 |
長期的に見て、WordPressはFSEへの移行を推進しており、ブロックベースのアーキテクチャは今後の標準となっていく方向性にあります。しかし、すべてのサイトをFSEで構築する必要はありません。メジャーアップデートの影響を最小限に抑え、保守性を担保するためには、プロジェクトの規模や運用体制に合わせて、クラシックテーマとブロックテーマのハイブリッドな構成を選択することも有効な手段です。
迷ったときは、以下のように考えると整理しやすいです。
・開発チームのみが構造を触る場合は、ファイルベースでの管理を徹底する
・クライアントがレイアウトを変更したい要望がある場合は、ブロックパターンを用意して選択式にする
・予期せぬレイアウト崩れを防ぐため、theme.jsonでエディターの機能を適切に制限する
Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。
5. 開発現場で直面したトラブル事例とその根本的な解決アプローチ
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入した実案件で、実際に直面したトラブルとその対処法をシェアします。
以前、企業サイトのリニューアル案件で、`theme.json`のカラーパレットやタイポグラフィの設定を変更したのに、実際の画面に反映されないという問題に当たりました。エディター上では正しく表示されているにもかかわらず、プレビューや公開画面では古いスタイルのままという状態です。
内部でどのように動いているかを調査した結果、原因はWordPress内部のキャッシュ機能にあることがわかりました。`theme.json`の解析結果はデータベースにキャッシュされるため、ファイルを上書きアップロードしただけでは即座にクリアされないことがあります。
開発中のフラストレーションを解消するため、以下の解決策を採用しました。
“`php
// 開発環境用のtheme.jsonキャッシュクリア処理
// ※functions.phpに記述します
// ※本番環境ではパフォーマンス低下の原因になるため使用を控えてください
add_action( ‘init’, function() {
// デバッグモードが有効な場合のみ実行し、予期せぬ負荷を防ぐ
if ( defined( ‘WP_DEBUG’ ) && WP_DEBUG ) {
// ブロックCSSやtheme.json関連の一時キャッシュを削除
delete_transient( ‘wp_core_block_css_files’ );
}
} );
“`
なぜこの処理を追加するのかというと、`delete_transient`関数を使って一時的なキャッシュデータ（transient）を強制的に削除し、常に最新の`theme.json`が読み込まれる状態を作るためです。
正直に言うと、以前はブラウザのスーパーリロードを何度も試して時間を浪費していました。この仕組みを理解してからは、開発環境の`functions.php`にこのスニペットを入れておくことで、検証作業が非常にスムーズになりました。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| theme.jsonのキャッシュ無効化コード | ローカル環境やテスト環境で開発・調整中の場合 | トラフィックが多くパフォーマンスが求められる本番環境の場合 |
もう一つのよくある間違いとして、ブロックスタイルの詳細度（CSSが適用される優先順位）を理解せずに、独自CSSで無理やり上書きしてしまうケースがあります。エディター側とフロントエンド側でDOM構造がわずかに異なるブロックが存在するため、CSSだけで見た目を合わせようとすると、WordPressのメジャーアップデート時に画面が崩れるリスクが高まります。
長期的な保守性や将来性を考えると、ブロックのスタイル調整は極力CSSファイルに書かず、`theme.json`の`styles`プロパティを使ってグローバルに制御する設計方針をおすすめします。迷ったときは、「CSSで強制的に上書きする前に、WordPressのコア機能で用意されている設定で解決できないか」を基準に考えると整理しやすいです。