2026年最新版！WordPressのフルサイト編集を実務で活用するための具体的な手順
【動作確認済み環境】
・WordPress：6.7
・PHP：8.2
・確認日：2026年1月
・テーマ：Twenty Twenty-Six
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
最近のWeb制作案件で、「フルサイト編集（FSE）を使って構築してほしい」というご相談をいただくことが増えてきました。FSEはブロックエディターでサイト全体を編集できる画期的な機能ですが、実際の案件で採用するとなると、運用時の保守性や従来のクラシックテーマとの違いなど、判断に迷う場面も多いのではないでしょうか。正直に言うと、導入初期は設定の自由度が高すぎるゆえに、運用ルールづくりで苦労した経験があります。この記事では、実案件での試行錯誤から見えてきた、実務でFSEを安全に活用するための判断基準や具体的な手順をシェアします。
【この記事でわかること】
・フルサイト編集（FSE）を実務で採用するための具体的な判断基準がわかります
・案件の要件に合わせたクラシックテーマとブロックテーマの使い分けがわかります
・導入前に知っておくべき注意点や、実案件での構築手順がわかります
・長期的な運用や保守性を見据えたサイト設計の考え方がわかります
1. FSE（フルサイト編集）は実務で使えるか？現役Web制作者の判断基準
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：最新
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
WordPressの機能拡張が進む中、FSE（ブロックエディターでサイト全体を編集できるWordPressの新機能）を実際の案件に導入すべきか、迷う場面が増えてきました。「新しい機能だからとりあえず導入してみよう」と見切り発車をしてしまうと、後々の保守で思わぬつまずきを経験することがあります。
実務で10年以上WordPressに触れてきた経験からお話しすると、現在のFSEは「条件付きで実務でも十分に活用できる」というのが正直なところです。
従来のクラシックテーマでは、PHPファイル（header.phpやfooter.phpなど）を編集してサイトの共通部分を構築していました。一方でFSEは、管理画面上からブロックを配置するだけでヘッダーやフッター、さらにはテンプレート全体を構築・編集できます。直感的な操作が可能になる反面、細かなPHPのカスタマイズや複雑な条件分岐が求められる要件では、クラシックテーマの方が柔軟に対応できるケースも少なくありません。
以前、頻繁にデザインの微調整が行われるオウンドメディアの案件でFSEを導入しました。お客様自身でレイアウトを変更できる点は非常に好評でしたが、特定のカテゴリーにだけ複雑な独自処理を入れたいという追加要望が出た際、ブロックの制御だけでは対応しきれず、結局独自ブロックを開発する工数がかかってしまったという経験があります。
このような経験を踏まえ、現在では案件の要件に応じてFSEとクラシックテーマを以下のように使い分けています。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSEの導入 | お客様自身でレイアウトを柔軟に変更したい場合 | 高度な条件分岐や、PHPによる緻密な制御が必要な場合 |
長期的な保守性や将来性を考えると、WordPressの開発方針がブロックベースへ移行していることは間違いありません。そのため、シンプルなコーポレートサイトやブログなど、標準的なブロックで要件を満たせるプロジェクトからFSEを導入し、知見を蓄積していくアプローチをおすすめします。
2. クラシックテーマとブロックテーマの比較と案件に応じた選び方
実際のWeb制作の現場で、どちらのテーマ構造を採用すべきか迷う場面が増えてきました。ここでは、従来からあるクラシックテーマと、新しいブロックテーマの違いを整理し、実務でどう使い分けるかの判断基準をシェアします。
クラシックテーマは、PHPファイルでテンプレートを構築し、functions.php（テーマの機能を追加・カスタマイズするファイル）を中心に制御する従来の手法です。長年培われてきたノウハウがあり、複雑な処理を組み込みやすい特徴があります。
対してブロックテーマは、HTMLファイルとtheme.jsonで構成され、FSE（ブロックエディターでサイト全体を編集できるWordPressの新機能）を前提としています。管理画面から直感的にサイト全体を編集できるのが大きな違いです。
以前、更新頻度が非常に高く、クライアント自身でレイアウトを柔軟に変更したいというご要望の案件がありました。その際、ブロックテーマを採用したことで、運用時の修正対応がスムーズに進み、非常に喜ばれました。
一方で、複雑なカスタムフィールドを多用し、ブランドガイドラインに沿ってデザインを厳格に固定しなければならない案件では、クラシックテーマを選択しています。自由に編集できるブロックテーマでは、意図しないデザイン崩れを引き起こすリスクがあるためです。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| クラシックテーマ | デザインを厳格に固定したい場合 | クライアントが自由にレイアウト変更したい場合 |
| ブロックテーマ | 運用側で柔軟にレイアウトを組みたい場合 | 複雑なPHP処理や独自のシステム連携が必要な場合 |
WordPress公式（https://wordpress.org）の動向を見ると、ブロックテーマやFSEの機能拡充が積極的に進められています。しかし、クラシックテーマのサポートが打ち切られるわけではなく、当面は共存していくと考えられます。
長期的な保守性を考慮する場合、クライアントの運用リテラシーと要件の複雑さを天秤にかけて選択することが、結果的に運用後のトラブルを減らすことにつながります。設計の段階で迷ったときは、「納品後、誰がどこまでページを更新するのか」を軸に考えると整理しやすいです。
3. フルサイト編集を導入する前に確認しておきたい注意点とデメリット
【動作確認済み環境】
・WordPress：6.4.3
・PHP：8.1
・確認日：本記事執筆時点
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）は、直感的な操作でサイトを構築できる魅力的な機能ですが、実務の案件で導入する際にはいくつか慎重に検討すべきポイントがあります。
実際のWeb制作現場でFSEを導入した際、特に壁となりやすいのが既存の運用フローとの乖離です。これまでのクラシックテーマでは、PHPファイル（header.phpやfooter.phpなど）を直接編集してレイアウトを制御するのが一般的でした。しかし、FSEではHTMLベースのブロックマークアップやtheme.jsonという設定ファイルが主役となります。
以前、福島県郡山市にある弊社（eBIZクリエイト株式会社）の保守案件で、従来のクラシックテーマからFSE対応テーマへの移行を検討したことがありました。正直に言うと、既存のショートコードや独自に組んでいたPHPのカスタム処理をブロックとして再構築するコストが想定以上に大きく、その案件では移行を見送った経緯があります。長期的な運用を見据えた場合、クライアントの担当者がブロックエディターの操作にどこまで慣れているかも重要な判断基準となります。
また、プラグインとの互換性も忘れてはいけないポイントです。歴史のある有名なプラグインであっても、FSEのテンプレートでは意図した位置に出力されなかったり、デザインが崩れてしまったりするケースが散見されます。特に、特定のフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）に依存している機能は、事前の入念なテストが必要です。
よくある間違いとして、テーマファイル内で直接CSSを多用してしまうことが挙げられます。FSE環境では、全体の色やタイポグラフィの管理はtheme.jsonで行う仕組みとなっています。無理にstyle.cssで強制的に上書きすると、エディター画面と実際の表示でデザインが食い違う原因となるため注意が必要です。
実務における導入の判断基準として、以下の表に整理しました。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 新規サイト構築 | シンプルな構造で、クライアント自身がレイアウト変更を行いたい場合 | 複雑な動的処理や、独自仕様のAPI連携が多数必要な場合 |
| 既存サイト改修 | ブロックエディターの利用が定着しており、小規模なリニューアルの場合 | 従来のPHPカスタマイズが深く根付いており、予算と工数に余裕がない場合 |
| 保守・運用 | サイト全体のデザインルールをtheme.jsonで一元管理したい場合 | クライアントにレイアウト変更の権限を与えたくない場合 |
FSEはWordPressの今後の方向性を示す重要な機能であり、開発も活発に行われています。将来性という意味では非常に期待できる技術ですが、現在の案件の要件やクライアントの運用体制と合致するかどうか、フラットな目線で評価することが大切です。迷ったときは、まずテスト環境でプロトタイプを作成し、既存の必須プラグインが正常に動作するかを確認することをお勧めします。
4. 実案件で活用するための具体的なテーマ構築とカスタマイズ手順
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実際の案件で導入する際、従来のクラシックテーマとは構築のアプローチが大きく異なります。ここでは、実務でFSEテーマを構築していくための具体的な手順と、カスタマイズの勘所を解説します。
まず、FSEテーマの核となるのが「theme.json」ファイルです。従来のfunctions.phpやstyle.cssで行っていた設定の多くを、このJSONファイルで一元管理します。
“`json
/ theme.json : テーマのルートディレクトリに配置します /
{
“version”: 2,
“settings”: {
“appearanceTools”: true, / 余白やタイポグラフィなどの高度な設定ツールを有効化 /
“color”: {
“palette”: [
{
“name”: “メインカラー”,
“slug”: “primary”,
“color”: “#005baa”
},
{
“name”: “テキストカラー”,
“slug”: “text”,
“color”: “#333333”
}
]
},
“layout”: {
“contentSize”: “800px”, / コンテンツの標準幅 /
“wideSize”: “1200px” / 幅広設定時のサイズ /
}
}
}
“`
このようにtheme.jsonを定義することで、エディター画面のカラーパレットや余白設定のUIを制御できます。実務においては、クライアントが意図しない色やサイズを指定してデザインが崩れるのを防ぐため、あえてカラーパレットを制限したり、特定のブロックの設定を無効化したりするコントロールが非常に重要になります。
以前、コーポレートサイトの案件でFSEを導入した際、クライアントから「見出しの色を自由に少し変えたい」という要望がありました。当初はすべてのカラーピッカーを解放していましたが、結果としてサイト全体のブランドカラーにばらつきが生じてしまうトラブルがありました。それ以降、案件のデフォルト設定として、theme.jsonでブランドガイドラインに沿った色だけをパレットに登録し、カスタムカラーの入力は「”custom”: false」として制限する手法を取り入れています。
よくあるハマりポイントとして、テンプレートファイル（htmlファイル）の修正がエディター上の設定に上書きされてしまう現象があります。FSEでは、管理画面の「エディター」から行った変更がデータベースに保存され、ファイル側の記述よりも優先されます。そのため、開発環境でファイルを修正したのに本番環境に反映されない場合は、エディター側で該当テンプレートのカスタマイズ履歴をクリア（リセット）する必要があります。
FSEテーマの構築を行う際、あらかじめブロックの構造を細かくテンプレートパーツとして分割しておくことも推奨されます。ヘッダーやフッターだけでなく、CTAエリアやループのアイテム部分などもパーツ化しておくことで、複数のテンプレート間での使い回しが容易になり、保守性が向上します。
ただし、すべての案件でFSEが適しているわけではありません。複雑な条件分岐を伴うポータルサイトや、会員ごとに表示内容が動的に大きく切り替わるようなシステム要件が強いサイトの場合、従来のPHPベースのテンプレート階層を用いたクラシックテーマの方が、処理の見通しが良く安全に開発できるケースが多いです。
| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSEテーマの採用 | クライアント自身がLPや新規ページをノーコードで柔軟に作成・編集したい場合 | 複雑なPHPの条件分岐や、独自のカスタムデータベース連携が多用される場合 |
FSEはWordPressの今後の方向性として中心的な役割を担っており、開発も活発に継続されています。長期的な保守性や将来性を考慮すると、シンプルなコーポレートサイトやメディアサイトであれば、FSEでの構築に切り替えていく価値は十分にあります。要件に合わせて、theme.jsonによる的確な制限と柔軟性のバランスを設計してみてください。
5. 今後のWordPressの方向性と保守性を踏まえた運用プランの考え方
フルサイト編集（FSE）を実務で導入する際、一時的な構築のしやすさだけでなく、数年先を見据えた保守性や運用プランを考えることが重要です。WordPress自体がブロックベースのアーキテクチャへと舵を切っている中、私たち制作者もその流れに合わせた運用設計を行う必要があります。
ここでは、今後のWordPressの動向を踏まえた上で、実務でどのように運用プランを組み立てていくか、私の経験に基づいた考え方をシェアします。
プラグイン依存からの脱却とネイティブ機能の活用
これまでのWordPress制作では、ページビルダープラグインや多数のカスタムフィールドプラグインを組み合わせて複雑なレイアウトを実現することが一般的でした。しかし、FSEの進化により、コア機能だけで実現できる範囲が飛躍的に広がっています。
運用プランを考える上で重要なのは、「可能な限りWordPressのネイティブ機能（ブロックエディターやFSE）に寄せる」という方針です。プラグインへの過度な依存は、WordPressのメジャーアップデート時に互換性リスクを生み、保守コストを押し上げる要因になります。
以前、ページビルダーで構築されたサイトの保守を引き継いだ際、プラグインのアップデートによって大幅なレイアウト崩れが発生し、対応に苦慮した経験があります。FSEを活用し、コアのブロックを中心に構成することで、こうしたリスクを最小限に抑え、長期的な安定稼働を見込めるようになります。
クラシックテーマとFSEのハイブリッド運用の検討
すべての案件でいきなり完全なFSEテーマを採用するのが適しているとは限りません。特に既存サイトのリニューアルや、複雑なPHPロジックが組み込まれたサイトの場合、段階的な移行が現実的です。
現在、私が案件でよく提案しているのが、従来のクラシックテーマをベースにしつつ、ブロックエディターの機能を拡張する「ハイブリッド型」の運用です。例えば、theme.jsonを導入してエディター側のカラーパレットやフォントサイズを制御し、クライアントの運用負荷を下げつつデザインの統一性を保つ、といった手法です。
このアプローチのメリットは、使い慣れたPHPベースのテンプレート階層を維持しながら、執筆体験をモダンにできる点にあります。WordPressの方向性を視野に入れつつ、現在の技術スタックとのバランスを取る現実的な選択肢と言えます。
クライアントへの操作権限の適切なコントロール
FSEは「サイト全体をブラウザ上で視覚的に編集できる」という強力な機能を提供します。しかし、これは同時に「クライアントが意図せずサイト全体のレイアウトを壊してしまうリスク」も孕んでいます。
運用プランを策定する際は、権限管理の設計が不可欠です。実務では、以下のようなコントロールを必ず行っています。
テンプレート編集機能のロック: 管理者（制作者）のみがテンプレートを編集でき、編集者権限（クライアント）には記事の執筆と指定されたブロックの編集のみを許可する。
ブロックパターンの活用: あらかじめデザインされたブロックパターンを登録しておき、クライアントはそれを呼び出して中身のテキストや画像を差し替えるだけの運用にする。
theme.jsonでの制限: 使用できる色やフォントサイズ、余白の設定を制限し、ブランドガイドラインから逸脱しないようにする。
FSEの自由度をクライアントにそのまま渡すのではなく、「安全に更新できる範囲」を設計して提供することが、結果的にクライアントの満足度向上と保守トラブルの軽減につながります。
向いているケースと向いていないケースの整理
運用プランを検討する際の判断基準として、FSEの導入が適しているケースとそうでないケースをまとめました。
| 項目 | 向いているケース | 向いていないケース |
| :— | :— | :— |
| 完全なFSE導入 | 新規構築のコーポレートサイトやメディアサイト、デザインの柔軟性を重視する案件 | 複雑なカスタムデータ構造を持つポータルサイト、既存の重厚なクラシックテーマからの移行 |
| ハイブリッド運用 | 既存サイトの部分的なモダン化、クライアントの執筆体験向上を優先する場合 | すでにElementorなどのページビルダーで強固に運用フローが組まれている場合 |
| 権限の強力な制限 | 複数の担当者が更新作業を行う企業サイト、デザインの一貫性を厳密に守りたい場合 | 担当者がWebの知識を持ち、自らレイアウトを積極的に変更・テストしたい場合 |
迷ったときは、「クライアントが日常的にどこを編集したいのか」と「数年後のWordPressアップデートに耐えうるか」の2点を軸に考えると整理しやすいです。正解は一つではありませんので、案件の特性に合わせて最適なバランスを見つけてみてください。