【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年5月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「フルサイト編集（FSE）は実務の案件で本当に使えるのか？」というご相談を、同業のWeb制作者や企業の担当者様からよくいただきます。

実際の案件でも、ブロックエディターでサイト全体を編集できるFSEへの移行を検討する場面が増えてきました。しかし、便利な反面、独自のディレクトリ構造やテンプレートファイルの管理方法など、従来のクラシックテーマでの制作フローとは大きく異なる部分があり、導入に踏み切れないという声も耳にします。

この記事では、現役のWeb制作者として実案件で得た知見をもとに、FSEの導入手順やつまずきやすい注意点、そして自社やクライアントの案件で採用すべきかの具体的な判断基準をシェアします。

【この記事でわかること】
・FSEを実案件で採用するかどうかの判断基準がわかります
・導入前に知っておくべきテーマ構造とファイルの役割がわかります
・クラシックテーマからFSEへ移行する際の具体的な手順がわかります
・カスタマイズ時に直面しやすい課題と現場での対応策がわかります
・将来のメンテナンスを見据えた運用設計の考え方がわかります

1. FSEを実案件で採用するかどうかの具体的な判断基準

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：検証完了時
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

フルサイト編集（FSE）は、ブロックエディターを使ってヘッダーからフッターまでサイト全体のレイアウトを構築できる機能です。登場した当初は実験的な要素が強く、実際のクライアントワークで採用するにはハードルが高いと感じていた方も多いのではないでしょうか。

実際、eBIZクリエイト株式会社の案件でも、以前はクラシックテーマと独自のPHPテンプレートを組み合わせた構築が基本でした。しかし、WordPress本体のアップデートに伴い機能が成熟してきたことで、現在ではFSEを前提とした構築も選択肢に入るようになっています。

とはいえ、すべての案件をFSEで構築できるわけではありません。実案件でFSEを採用するかどうかを決める際、私たちが基準としているポイントをいくつかシェアします。

まず考慮すべきは、サイトの構造とクライアントの運用体制です。FSEは、ノーコードに近い感覚で柔軟なレイアウト変更が可能になる反面、クライアント自身が誤ってサイト全体のデザインを崩してしまうリスクも伴います。
以前、あるコーポレートサイトの案件でFSEを採用した際、クライアントが直感的に操作できる点を高く評価いただいたものの、意図せずグローバルナビゲーションの構造を変更してしまい、修正の対応に追われた経験があります。この経験から、運用者がどこまでカスタマイズの自由度を求めているかを事前にすり合わせることが、採用の重要な判断基準となりました。

また、複雑なカスタムフィールド（投稿画面に独自の入力項目を追加する機能）や、独自のクエリ（データベースから特定の条件でデータを呼び出す処理）を多用する要件の場合、現在のFSEの標準ブロックだけでは実装が難しく、独自のカスタムブロックを開発する工数が跳ね上がることがあります。

迷ったときは、以下の表を参考に要件を整理すると、方針が定まりやすいです。

長期的な保守性や将来性を考えると、WordPressの公式ドキュメントでもFSEを中心としたブロックテーマの開発が推奨される流れにあります。そのため、新規の小規模なプロジェクトから少しずつFSEの概念を取り入れ、チーム内に知見を蓄積していくアプローチが安全です。

要件に合わせて、あえて従来のクラシックテーマ（PHPテンプレートベース）を選択することも、現時点では十分正しい判断です。どちらを選ぶにしても、クライアントが運用していく上でどちらがメリットを生むのかという視点を中心に据えて設計を行っています。

2. 導入前に確認しておきたいテーマ構造と必要なファイル

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務の案件で採用する際、まず直面するのがテーマ構造の大きな変化です。従来のクラシックテーマを作り慣れている方ほど、最初は戸惑うかもしれません。

クラシックテーマでは、`header.php`や`footer.php`といったPHPファイルを組み合わせてページを構築していました。しかし、FSEに対応したブロックテーマでは、PHPファイルの代わりにHTMLファイルとJSONファイルが主役になります。

ブロックテーマを構成するために、最低限必要となるファイルは以下の3つだけです。

・`style.css`（テーマの基本情報を記述するファイル）
・`theme.json`（全体の色やフォント、レイアウト設定を管理するファイル）
・`templates/index.html`（フォールバック用の基本テンプレート）

これらに加えて、実案件では機能を拡張するための`functions.php`（テーマの機能を追加・カスタマイズするファイル）を用意することがほとんどです。

正直にお話しすると、初めてブロックテーマを自作した際、従来の癖で`header.php`を作ってしまい、エディター上でテンプレートパーツとして認識されずに時間を溶かした経験があります。ブロックテーマでは、ヘッダーやフッターなどの共通パーツは`parts/header.html`のように、`parts`ディレクトリ内にHTMLファイルとして配置する必要があります。内部的な仕様として、WordPressはこれらのHTMLファイルをパース（解析）し、ブロックのデータとしてエディターに読み込ませているからです。

ここで、ブロックテーマの核となる`theme.json`の基本的な書き方をご紹介します。このファイルで設定した内容は、そのままエディターの右パネル（グローバルスタイル）に反映されます。

{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "primary",
"color": "#005baa",
"name": "メインカラー"
}
],
"custom": false /<strong> ユーザーによるカスタムカラーの追加を制限 </strong>/
},
"layout": {
"contentSize": "800px", /<strong> コンテンツの標準幅 </strong>/
"wideSize": "1200px"    /<strong> 幅広に設定した際のサイズ </strong>/
}
}
}

実務においては、上記の`”custom”: false`のように、クライアントが意図しない色を勝手に追加できないよう制限をかける設計が非常に重要です。自由度が高すぎるFSEだからこそ、制作者側で適切な手綱を握る必要があります。

長期的な保守性を考えた際、FSEのテーマ構造を採用すべきかどうかの判断基準を整理しておきます。

FSEは開発が現在も活発に進められており、WordPressの今後の方向性そのものです。しかし、すべての案件に適合するわけではありません。ファイルの構造と役割を正確に理解した上で、プロジェクトの要件に合わせてクラシックテーマと使い分ける判断が求められます。

3. 既存のクラシックテーマからFSEへ移行する際の手順

長年運用してきたクラシックテーマからFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）への移行は、実務において非常に慎重な判断が求められるフェーズです。PHPファイルで構成されたテンプレートをブロックベースのHTMLファイルに置き換える作業は、単なるテーマの切り替えではなく、サイトの構造そのものを再構築する意味合いを持ちます。

ここでは、実際の案件でクラシックテーマからFSEテーマへ移行する際に、私たちが踏んでいる具体的な手順を解説します。

手順1：独立した検証環境の構築

本番環境に直接FSEテーマを適用するのは避けてください。クラシックテーマ特有のウィジェットやメニュー設定は、FSEテーマに切り替えた瞬間に初期化、あるいは表示されなくなるケースが多々あります。まずは「Local」などのローカル環境構築ツール、あるいは本番サーバーのステージング機能を使用して、本番データと全く同じ検証環境を用意します。

手順2：theme.jsonによるデザインシステムの定義

FSEのコアとなるのが、テーマディレクトリ直下に配置する「theme.json」です。クラシックテーマでは「style.css」に記述していたカラーパレットやタイポグラフィ、余白のルールを、JSON形式で定義し直します。これにより、エディター画面とフロントエンドの表示を一致させ、運用者が意図しないデザインの崩れを防ぐことができます。

// theme.jsonの記述例
{
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "primary",
"color": "#005baa",
"name": "メインカラー"
}
]
}
}
}

※theme.jsonはJSONファイルであるため、実際の運用時にはコメントアウト（//）を含めるとエラーになります。記述の参考として捉えてください。

手順3：ヘッダー・フッターのブロック化

クラシックテーマの「header.php」や「footer.php」にあたる部分は、FSEでは「テンプレートパーツ」としてブロックの組み合わせで作成します。既存のロゴ画像、ナビゲーションメニュー、検索フォームなどを、対応するコアブロック（WordPressに標準で備わっているブロック）に置き換えていきます。

手順4：独自機能のカスタムブロック化

実務で最も時間がかかるのがこの工程です。既存のテーマ内で独自に作成していたショートコードや、PHPで出力していたカスタム投稿の一覧などは、そのままではFSEのエディター上で視覚的に編集できません。必要に応じて「ACF（Advanced Custom Fields）」プラグインのブロック作成機能などを活用し、運用者がエディター上で直感的に操作できるカスタムブロックへと作り変えます。

以前、不動産系のポータルサイト案件で移行を担当した際、元のクラシックテーマが「functions.php（テーマの機能を追加・カスタマイズするファイル）」に大量の独自処理を抱え込んでいたことがありました。FSEに切り替えた途端、それらの処理がエディターの動作と干渉して画面が真っ白になるトラブルに見舞われました。この経験から、移行前には必ず既存のPHPコードを洗い出し、「FSEの標準機能で代替できるもの」と「引き続きプラグイン等で独自実装が必要なもの」を切り分ける工程を必須としています。

既存サイトの移行において、FSE化が常に最適な選択とは限りません。以下の表を参考に、プロジェクトの要件と照らし合わせてみてください。

クラシックテーマからの移行は、サイトの表示速度改善や運用コストの削減につながる一方で、初期の学習コストや構築の手間がかかります。現在の運用における課題を整理し、FSE化がその解決に直結するかどうかをフラットな視点で評価することが大切です。

4. 実務で直面しやすいカスタマイズ時の注意点と対応策

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で導入し始めると、クラシックテーマの時代にはなかった特有の課題に直面します。実際の案件で私たちがよく直面する問題と、その具体的な対応策をシェアします。

まず、もっとも頻繁に起こるのが「クライアントが意図しないデザインの崩れを引き起こしてしまう」という問題です。FSEは画面上で直感的にあらゆる要素を変更できる反面、運用者が誤ってサイト全体のレイアウトやブランドカラーを変えてしまうリスクを伴います。以前、運用保守を引き継いだ案件で、担当者様が誤ってヘッダーのテンプレート部分を削除してしまい、全ページのレイアウトが崩れてしまったというトラブルがありました。

この問題を防ぐため、実務ではtheme.json（テーマの全体的なスタイルやエディターの動作を制御する設定ファイル）を使って、運用者が変更できる範囲を意図的に制限するアプローチをとります。

以下のコードは、エディター上で選択できるカラーパレットを、ブランドカラーのみに制限するためのtheme.jsonの記述例です。

// theme.json に記述します
// エディターの全体設定を行うファイルです
{
"version": 2,
"settings": {
"color": {
// カスタムカラーの入力を無効化します
"custom": false,
// ユーザーが選択できるカラーパレットを定義します
"palette": [
{
"slug": "brand-primary",
"color": "#005baa",
"name": "メインカラー"
},
{
"slug": "brand-secondary",
"color": "#f2f2f2",
"name": "背景用ライトグレー"
}
]
}
}
}

このように設定することで、運用者はあらかじめ定義された「メインカラー」と「背景用ライトグレー」しか選択できなくなり、ブランドガイドラインから逸脱した色使いを防ぐことができます。内部でこう動いているからこそ、PHPで複雑な制御をする必要がなく、JSONファイル一つでエディターのUIをコントロールできるのがFSEの大きな強みです。

また、もう一つの壁が「特定のブロックにだけ独自のCSSを当てたい場合の管理」です。FSE環境では、従来のstyle.css（テーマの見た目を整えるファイル）にすべてのスタイルを記述すると、エディター側とフロント側で表示がずれる原因になります。

解決策として、theme.json内でブロックスタイルを定義するか、必要に応じてWordPressのフック（処理に割り込んで独自の処理を追加する仕組み）を利用して、ブロックごとに専用のCSSを読み込ませる方法を採用しています。長期的な保守性を考えると、可能な限りtheme.jsonの標準機能に寄せて設計することが、将来のWordPress本体のアップデートによる影響を最小限に抑える鍵となります。

迷ったときは、サイトの運用体制に合わせて「どこまで自由度を持たせるか」を最初に定義すると整理しやすいです。正解を押し付けるのではなく、プロジェクトごとに最適な制限のバランスを見つけることが、FSEを実務で成功させるポイントです。Web制作の現場での判断の参考にしていただければ幸いです。

5. 保守性と将来性から考える今後のサイト運用設計

フルサイト編集（FSE）を実際の案件で導入する際、最も慎重になるべきなのは「リリース後の保守と将来性」です。作るだけならブロックエディターの直感的な操作で進められますが、数年先を見据えた運用設計をどう描くかが、Web制作の現場では問われます。

WordPressの公式の方向性として、ブロックベースのアーキテクチャへの移行は明確です。しかし、すべてのサイトを今すぐFSEで構築するべきかというと、現場の感覚としてはそうではありません。

実際の案件でFSEを採用した際、クライアントから「どこでも編集できて便利だ」と喜ばれる一方で、「ヘッダーのレイアウトを誤って崩してしまった」という相談を受けることがありました。クラシックテーマであればPHPファイルでガッチリと固定されていた部分が、FSEでは管理画面から編集可能になるため、運用者のスキルセットに応じた権限管理が今まで以上に重要になります。

長期的な保守性を考えると、FSEのメリットは「テーマファイルに依存しない柔軟なリニューアルや改修が可能になること」です。将来的にデザインを大きく変更する際も、テンプレートパーツを組み替えるだけで対応できる幅が広がります。一方で、テーマのメジャーアップデートに伴う仕様変更の影響を受けやすい面もあるため、コアアップデートの事前検証はクラシックテーマ以上に綿密に行う必要があります。

ここで、運用設計の観点からFSEの導入判断基準を整理してみます。

迷ったときは、以下の基準で整理してみてください。

・クライアントがサイトの構造（ヘッダーやフッター含む）を自社で頻繁にテスト・変更したいか
・運用担当者のITリテラシーはどの程度か
・数年後のデザインリニューアルをどの程度の規模で想定しているか

WordPressの進化は続いており、FSEの機能もアップデートのたびに洗練されています。クラシックテーマの安定感をとるか、FSEの柔軟性と将来性をとるかは、案件ごとの運用シナリオによって決まります。まずは自社のテストサイトや、影響範囲の小さいプロジェクトから小さく始め、社内に知見を蓄積していくアプローチが実務では現実的です。

サイトの運用設計やWordPressの実装方針で迷うことがありましたら、Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。長期的な視点で、プロジェクトに最適な技術選定をサポートいたします。