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

実際の案件で「そろそろフルサイト編集を本格的に導入した方が良いのだろうか」と悩む声をよくいただきます。ブロックエディターでサイト全体を構築できるのは魅力的ですが、いざ実務で使おうとすると、従来のクラシックテーマとの仕組みの違いに戸惑うことも多いのではないでしょうか。私自身、初めてのフルサイト編集案件では独自のファイル構成やテーマjsonの扱いに試行錯誤を繰り返しました。この記事では、現場での失敗から学んだ、フルサイト編集を実案件で安全に運用するための具体的な手順や判断基準をシェアします。導入に迷っている方の指標になれば幸いです。

【この記事でわかること】
・従来テーマからフルサイト編集へ移行する際の具体的な手順
・実案件にフルサイト編集を導入するべきかどうかの明確な判断基準
・現場で直面しやすい課題とそれを解決するためのコード設計
・保守性と運用効率を両立させるファイル構成と運用ルール

1. 2026年最新のWordPressフルサイト編集を実務へ導入する具体的な手順

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

1. 最新のWordPressフルサイト編集を実務へ導入する具体的な手順

最近の案件で、「FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）は実際のところ業務で使える状態なのか」というご相談をよくいただきます。
クラシックテーマでの構築に慣れていると、新しい概念であるFSEへの移行には心理的なハードルがあるかもしれません。
この記事では、実案件での経験をもとに、FSEを制作フローに組み込むための実践的なアプローチをシェアします。

この記事でわかること
・FSEを実案件に導入する際の具体的なステップがわかります
・theme.jsonを用いたデザイン管理の基本がわかります
・FSEの導入が適している案件の判断基準がわかります

FSEを実務へ導入するには、まず「theme.json」によるグローバルスタイルの定義から始めるのがスムーズです。
従来のstyle.cssで各要素のスタイルを上書きしていく手法とは異なり、theme.jsonでカラーパレットやタイポグラフィ、余白のルールをシステム側に登録します。

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

※theme.jsonはテーマのルートディレクトリに配置します。このファイルにより、エディター上のカラーパレットに設定した色が追加されます。

この書き方が推奨される理由は、エディターとフロントエンドのスタイルを完全に一致させることができるためです。
内部でCSS変数が自動生成されるため、運用時にクライアントが直感的にブランドカラーを選択できるようになります。

正直に言うと、以前はFSEでも無理に従来のPHPテンプレートと混在させるやり方で構築していました。
でも、ブロックのスタイル指定と独自CSSが競合してしまい、意図しない余白が発生するというトラブルが起きてから、設定をtheme.jsonに一本化する方針に変えました。

やりがちですが、FSEテーマの中で過度に固定のHTMLをテンプレートパーツに直書きするのは避けた方が無難です。
クライアントがエディターから編集できなくなり、FSEのメリットが失われてしまいます。
複雑なレイアウトが必要な場合は、独自のカスタムブロックを開発するか、パターンの登録で対応する手法をおすすめします。

| FSEの導入 | 納品後にお客様自身で柔軟にレイアウトを追加・変更したい場合 | ピクセルパーフェクトなデザイン再現が必須で、運用時のデザイン変更を制限したい場合 |

2. 従来テーマからフルサイト編集へ移行する際の正しい判断基準

「長年使ってきたクラシックテーマから、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる新機能）へ乗り換えるタイミングに悩んでいます」

実際の案件やご相談の場で、このような声をよく耳にします。新しい技術が普及してくると、すべての案件で新しい手法を採用したくなる気持ちはとてもよくわかります。ですが、実際のWeb制作現場では、プロジェクトの性質に合わせて適切なアプローチを選ぶことが求められます。

実務において、従来テーマからフルサイト編集へ移行する際の判断基準を整理しました。

以前、中規模なコーポレートサイトのリニューアル案件で、どちらを採用するか迷ったことがありました。最終的にクラシックテーマを選んだ理由は、運用担当者が複数名おり、意図しないレイアウト崩れを防ぐために編集権限を厳格にコントロールする必要があったからです。FSEは画面上で直感的にすべてを編集できる反面、操作に慣れていない方が重要なテンプレートを誤って変更してしまうリスクを伴います。

この選択の根拠となるのが、保守性と将来性の観点です。WordPressはブロックベースの開発へ大きく舵を切っていますが、クラシックテーマがすぐに使えなくなるわけではありません。functions.php（テーマの機能を追加・カスタマイズするファイル）を用いた高度なフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）や、緻密なテンプレート階層を駆使した開発は、現在でも非常に堅牢なアプローチです。

一方、新規のオウンドメディア立ち上げや、柔軟なページ作成が求められるランディングページ主体のサイトでは、FSEの恩恵を最大限に受けることができます。再利用ブロックやパターンの管理が容易になり、制作スピードの向上に直結するからです。

無理にすべてをFSEへ移行しようとするのではなく、まずは既存テーマの一部でブロックテンプレートを活用するなど、段階的なアプローチを検討するのも一つの方法です。迷ったときは「誰が運用し、どの程度の自由度が必要か」を軸に考えると、自ずと最適な選択肢が見えてきます。

3. 実案件で直面したフルサイト編集の課題と乗り越えるためのコード設計

フルサイト編集（ブロックエディターでサイト全体を編集できるWordPressの新機能）は、ノーコードで柔軟な構築ができる反面、実務でそのまま導入するといくつかの壁にぶつかります。

実際の制作現場で特に多く直面したのが、「クライアントが自由に編集できることで、逆にサイト全体の統一されたデザインが崩れてしまう」という課題でした。自由度が高すぎるゆえに、ブランドカラー以外の色が使われたり、余白のバランスが崩れたりするトラブルが起きたのです。

この課題を乗り越えるために実務で取り入れているのが、`theme.json`を活用した厳密なエディター制御です。

以下のコードは、案件でベースとして使用している`theme.json`の一部です。クライアントが選択できるカラーパレットやフォントサイズを、あらかじめ定義したものだけに制限しています。

// theme.json（テーマのルートディレクトリに配置）
{
"version": 2,
"settings": {
"color": {
// 自由な色の選択を無効化
"custom": false,
// 自由なグラデーションの選択を無効化
"customGradient": false,
// テーマ専用のカラーパレットを定義
"palette": [
{
"slug": "brand-main",
"color": "#005baa",
"name": "メインカラー"
},
{
"slug": "brand-accent",
"color": "#e60012",
"name": "アクセントカラー"
},
{
"slug": "text-base",
"color": "#333333",
"name": "テキストカラー"
}
]
},
"typography": {
// 自由なフォントサイズの入力を無効化
"customFontSize": false,
// 指定のフォントサイズのみを提供
"fontSizes": [
{
"slug": "small",
"size": "0.875rem",
"name": "小"
},
{
"slug": "normal",
"size": "1rem",
"name": "標準"
},
{
"slug": "large",
"size": "1.25rem",
"name": "大"
}
]
},
"spacing": {
// マージンやパディングの自由な入力を無効化
"customMargin": false,
"customPadding": false
}
}
}

この書き方を推奨する理由は、WordPressのコア機能に逆らわずにエディターの挙動をコントロールできるからです。以前は`functions.php`（テーマの機能を追加・カスタマイズするファイル）でフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を用いて制御していましたが、現在のフルサイト編集では`theme.json`で一元管理するアプローチが標準的な設計思想となっています。

正直に言うと、フルサイト編集を導入し始めた頃は、すべての機能を解放した状態で納品していました。しかし、納品から数ヶ月後にサイトを確認すると、ブランドガイドラインから外れた蛍光色が使われていたり、見出しのサイズがバラバラになっていたりするというトラブルが起きてから、この制御方法へ変えました。

実務においては、機能を提供することと同じくらい「必要のない機能を安全に隠すこと」が重要になります。

長期的な保守性の観点から見ても、`theme.json`での制御は有用です。WordPressのメジャーアップデートにおいて、ブロックエディターの仕様変更は頻繁に行われますが、`theme.json`のAPIは後方互換性が保たれるように設計されています。将来的なアップデートでエディターの表示崩れが起きるリスクを抑えるためにも、デザインシステムの中核として機能させておくことを推奨します。

迷ったときは、「誰がそのサイトを更新するのか」を想像して設計してみてください。更新者のスキルレベルに合わせて、制限と自由度のバランスを調整することが、フルサイト編集を実務で成功させる鍵になります。

4. フルサイト編集の導入に向いている案件と見送るべき案件の比較表

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実際の案件で導入するかどうかは、制作者として非常に悩ましいポイントかと思います。実務の現場では、すべての案件にFSEを導入するのが正解というわけではありません。

私自身、クライアントの要望や運用体制に合わせて、従来のクラシックテーマとFSEを明確に使い分けています。案件を進める中で定着した判断基準を以下の表にまとめました。

以前、社内に専任のWeb担当者がおり「自分たちで自由にキャンペーンページを組み立てたい」という要望があった案件では、FSEを採用しました。結果として、運用側でヘッダーやフッターの微調整、新しいレイアウトの追加がスムーズに行えるようになり、非常に喜ばれました。

正直に言うと、外部のライターが多数関わるようなメディア構築の案件では、FSEの導入を見送るケースが多いです。権限管理を行っても、予期せぬレイアウト崩れを引き起こすリスクがあるためです。このような場合は、入力項目を制限して運用を安定させやすい従来のクラシックテーマとカスタムフィールドの組み合わせを選択しています。

迷ったときは、「納品後に誰が、どのようにサイトを触るのか」を具体的に想像してみると整理しやすいです。技術的な新しさだけでなく、運用者のスキルや長期的な保守性を考慮することで、最適な選択が見えてきます。

5. 保守性と運用効率を高めるフルサイト編集のディレクトリ構成と運用ルール

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）を用いたテーマ構築において、ディレクトリ構成と運用ルールは保守の要になります。クラシックテーマの時代とは異なり、PHPファイルよりもHTMLとJSONファイルが主役となるため、ファイルの配置や命名規則を事前に整えておくことが運用効率を大きく左右します。

実際の案件で私たちが採用している基本的なディレクトリ構成は以下のようになっています。

/my-fse-theme/
├── theme.json // 全体的なスタイルや設定を管理するファイル
├── style.css // テーマの宣言とフォールバック用のCSS
├── functions.php // ブロックの登録や独自のPHP処理を記述
├── /templates/ // ページ全体のレイアウト（HTMLファイル）
│   ├── index.html
│   ├── single.html
│   └── archive.html
└── /parts/ // 共通部品（HTMLファイル）
├── header.html
└── footer.html

このように、テンプレートとパーツを明確に分離することで、後から修正が入った際の影響範囲を最小限に抑えることができます。

以前、FSEを導入した初期の案件で、すべてをエディター上で作り込み、ファイルでの管理を怠ったことがありました。その結果、本番環境とテスト環境で設定が同期できず、手作業で修正を繰り返すという苦い経験をしました。この経験から、重要なレイアウトや設定は必ず `theme.json` とテンプレートファイルに書き出し、Gitなどのバージョン管理システムで管理するルールを定めています。

なぜこのようにファイル管理を徹底するかというと、FSEの内部仕様として、データベースに保存された設定よりもファイルの設定が優先的に読み込まれる（または初期化のベースになる）仕組みがあるからです。これにより、予期せぬ画面崩れを防ぎ、常に安定した状態を保つことができます。

長期的な保守性や将来性を考えると、WordPressの進化の方向性は明らかにFSEにシフトしています。そのため、独自のPHPコードで無理に制御するのではなく、WordPressコアが提供するJSONやブロックの仕組みに沿った運用ルールを築くことが、メジャーアップデートの影響を受けにくい堅牢なサイト運営に繋がります。チーム内で「どこまでをテーマファイルで管理し、どこからをエディターで許可するか」の線引きを明確に決めておくことが、運用フェーズでのトラブルを減らすための鍵となります。