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

WordPressのフルサイト編集、実際の案件でどこまで導入すべきか迷った経験はありませんか。

ブロックテーマは直感的にデザインを作れる反面、クライアントが誤ってサイト全体のレイアウトを崩してしまうリスクもあり、従来のクラシックテーマとどちらを選ぶべきか悩むというご相談をよくいただきます。また、細かな独自デザインを適用しようとすると、従来とは違うコードの書き方が求められ、手が止まってしまうことも少なくありません。

この記事では、実務の現場で試行錯誤した結果たどり着いた、フルサイト編集と独自のカスタマイズを両立させる現実的な設計方針をシェアします。テーマ選びに迷っている方や、保守性の高いサイト構築を目指す方にとって、実案件での意思決定の軸となるはずです。

■ この記事でわかること
・フルサイト編集かクラシックテーマか迷ったときの明確な判断基準がわかります
・実案件にブロックテーマを導入するメリットと運用上の課題がわかります
・クライアントの誤操作を防ぎつつカスタマイズ性を保つ構築手順がわかります
・長期的な保守を見据えた最適なファイル構成の実例がわかります

1. フルサイト編集かクラシックテーマか迷った時の判断基準

【動作確認済み環境】
・WordPress：6.3
・PHP：8.1
・確認日：最新バージョンリリース時
・テーマ：Twenty Twenty-Three
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

リード文：
「新しくサイトを作るのですが、FSE（フルサイト編集）に対応したテーマで作るべきでしょうか。それとも従来のクラシックテーマで作るべきでしょうか」
実際のWeb制作の現場でも、またお客様からのご相談でも、このようなお声を聞く機会が非常に増えています。ブロックエディターでサイト全体を編集できるFSEは非常に魅力的ですが、すべてのプロジェクトにおいて最適な選択肢になるとは限りません。
実務のなかで私たちがどのようにこの2つを使い分け、お客様にご提案しているのか、具体的な判断基準をシェアします。

この記事でわかること：
・フルサイト編集（FSE）とクラシックテーマの具体的な違いがわかります
・プロジェクトの要件に合わせたテーマ選びの判断基準がわかります
・保守や運用を見据えた長期的な視点での選択方法がわかります

WordPressのテーマ選びにおいて、FSEとクラシックテーマのどちらを選ぶかは、サイトの目的と運用体制によって大きく変わります。
FSEは、ヘッダーやフッターを含むサイトのあらゆる部分を、直感的なブロックエディターの操作だけで構築・変更できる仕組みです。一方、クラシックテーマはPHPファイルを中心としたテンプレート群で構成され、高度な条件分岐や複雑なデータ処理を伴うカスタマイズに向いています。

実案件での判断の軸となるのは、「運用者がどこまでデザインに介入する必要があるか」と「独自機能の複雑さ」です。
たとえば、マーケティング担当者が日々のキャンペーンに合わせてヘッダーのレイアウトを変えたり、ランディングページをスピーディに量産したりしたい場合、FSEの柔軟性が活きてきます。
しかし、会員制サイトや、外部システムとAPI連携するような複雑なポータルサイトの場合、クラシックテーマをベースにしっかりとPHPベースのテンプレートを作り込む方が、予期せぬレイアウト崩れを防ぐことができます。

以前、頻繁にデザインテストを行いたいというご要望の案件でFSEを採用しました。導入直後は「自分たちで自由にレイアウトを変えられる」と大変喜ばれましたが、運用担当者が複数名に増えたタイミングで、意図しない箇所（共通のフッターなど）まで誤って編集してしまい、サイト全体のデザインが崩れるというトラブルが発生したことがあります。
この経験から、FSEを導入する際は「編集権限の細かな制御（theme.jsonを活用したロック機能など）」を必ずセットでご提案するようにしています。FSEは便利な反面、運用ルールの策定がクラシックテーマ以上に重要になります。

迷ったときは、「サイトの見た目を固定してコンテンツだけを更新したいのか」、それとも「レイアウトも含めて柔軟に運用していきたいのか」という視点で整理すると、スムーズに方向性が決まります。

Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。お客様のビジネス要件に合わせた最適なWordPress環境をご提案いたします。

2. 実案件でわかったフルサイト編集のメリットと運用上の課題

実際のWeb制作案件において、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの機能）を導入するかどうかは、制作者とクライアントの双方にとって大きな判断の分かれ道となります。ここでは、実務を通して見えてきた具体的なメリットと、現場で直面しやすい課題についてシェアします。

まず、FSEを導入する最大のメリットは、サイト公開後の運用における柔軟性です。従来のクラシックテーマでは、ヘッダーやフッター、アーカイブページのレイアウト変更にはPHPファイルの編集が必要でした。しかしFSEを導入すれば、管理画面のブロックエディターから視覚的にこれらのパーツを調整できます。広報担当者やマーケティング部門が、キャンペーンに合わせてサイト全体のデザインをスピーディーに変更したいケースでは、この柔軟性が強力な武器となります。

一方で、実案件の運用フェーズに入ると、この「自由度の高さ」が思わぬ課題を引き起こすことがあります。

以前、ある企業のコーポレートサイトをFSEで構築・納品した際のお話です。納品から数ヶ月後、クライアントから「サイトのデザインが崩れてしまった」というご相談をいただきました。確認してみると、運用担当者様がブロックエディターで全幅の設定を誤って変更してしまい、意図しないレイアウトになっていたのです。

FSEは、HTMLやCSSの知識がなくてもサイトの構造にアクセスできる反面、ブランドのガイドラインから逸脱したデザインや、レスポンシブ対応（スマートフォンやタブレットでの表示調整）を損なう変更が容易に行えてしまいます。内部構造として、FSEはすべてのレイアウト情報をデータベースまたはテーマ内の設定ファイルで管理しているため、管理画面からの操作がダイレクトにサイト全体へ影響を及ぼす仕組みになっています。

こうした経験から、現在では「どこまで編集権限を開放するか」を事前に綿密に設計することが不可欠だと考えています。実務では、theme.json（テーマの全体的なスタイルやブロックの設定を制御するファイル）を活用し、使用できるカラーパレットやフォントサイズを制限したり、特定のブロックをロックしたりすることで、運用上の安全性を担保しています。

FSEの導入を検討する際、すべての案件に適合するわけではありません。どのようなプロジェクトに適しているのか、以下の表に整理しました。

長期的な保守性や将来性を考えると、WordPressのコア開発はFSEの拡張へと明確にシフトしています。そのため、FSEの仕組み自体を理解し、案件に合わせて適切に制御する技術を持つことは、今後のWeb制作において非常に重要なスキルとなります。迷ったときは、「クライアントの運用リテラシー」と「ブランドデザインの保護の必要性」のバランスを軸に考えてみてください。運用上のリスクを最小限に抑えつつ、FSEの恩恵を最大限に引き出す設計が見えてくるはずです。

3. 独自のカスタマイズを安全に反映させるブロックテーマの構築手順

フルサイト編集（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": "背景用ライトグレー"
}
]
}
}
}

この設定により、投稿画面のブロックエディター上では「ブランドメインカラー」と「背景用ライトグレー」のみが選択可能になります。なぜこのように書くかというと、運用フェーズに入った際、コンテンツ作成者が意図せずデザインを崩してしまうリスクを根本から防ぐためです。

独自CSSの安全な読み込み方法

theme.jsonだけでは対応しきれない複雑なアニメーションや、特定の条件でのみ適用したいレイアウトについては、従来通りCSSファイルを使用します。ただし、ブロックテーマでは読み込みのタイミングに注意が必要です。

functions.php（テーマの機能を追加・カスタマイズするファイル）を使用して、ブロックエディターとフロントエンドの両方に独自のスタイルを適用します。

<?php
// テーマのセットアップ時に実行するアクションフック
add_action( 'after_setup_theme', 'ebiz_setup_block_theme' );

function ebiz_setup_block_theme() {
// エディター側にもテーマのスタイルを適用する機能を有効化
add_theme_support( 'editor-styles' );

// エディター用のCSSファイルを読み込む
add_editor_style( 'assets/css/editor-style.css' );
}

// フロントエンド用のCSSを読み込むアクションフック
add_action( 'wp_enqueue_scripts', 'ebiz_enqueue_custom_styles' );

function ebiz_enqueue_custom_styles() {
// メインのスタイルシートを読み込む
wp_enqueue_style(
'ebiz-main-style',
get_theme_file_uri( 'assets/css/main.css' ),
array(), // 依存関係なし
wp_get_theme()->get( 'Version' )
);
}

この方法が推奨される理由は、フロントエンドとエディターの見た目を極力一致させることができるからです。エディター上で確認したレイアウトが、公開後の画面でもそのまま反映されるため、運用担当者のストレスを大幅に軽減できます。

よくある間違いとハマりポイント

ブロックテーマの構築でやりがちなミスとして、クラシックテーマの感覚でheader.phpやfooter.phpといったテンプレートファイルを直接作成してしまうことが挙げられます。ブロックテーマでは、これらのパーツもHTMLベースのブロックテンプレート（parts/header.htmlなど）として管理するのが基本です。

PHPで動的な処理を記述したい場合は、独自のカスタムブロックを作成するか、既存のブロックをフックで拡張するアプローチに切り替える必要があります。

アプローチの判断基準

ブロックテーマでのカスタマイズ手法について、ケース別に判断基準を整理しました。迷った際はこちらを参考にしてください。

将来的なWordPressのアップデートや保守性を考慮すると、可能な限りtheme.jsonとコアブロックの組み合わせで解決し、どうしても足りない部分のみ独自CSSやカスタムブロックで補う設計が、長期的に安定した運用につながります。

4. 納品後のクライアント運用を見据えたハイブリッドアプローチの活用法

実際の案件で、クライアントから「納品後はお知らせやコラムを自分たちで自由にレイアウトしたい」というご要望をいただくケースが増えています。一方で、ブランドイメージを担保するために、トップページやサービス紹介ページはデザインを崩されたくないというジレンマに直面するWeb制作者は少なくありません。

この課題に対して、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）に全面移行するのではなく、従来型のテンプレートとFSEを組み合わせる「ハイブリッドアプローチ」が実務では非常に有効です。

ここでは、クライアントの運用負荷を下げつつ、デザインの品質を担保するためのハイブリッドアプローチの実装方法と判断基準をシェアします。

■ ハイブリッドアプローチの基本設定（LAYER 1・2）

クラシックテーマ（従来型のPHPベースのテーマ）をベースにしながら、特定の領域だけブロックエディターの機能拡張を利用するには、テーマの機能を追加・カスタマイズするファイルである `functions.php` に適切な設定を記述します。

以下のコードは、クラシックテーマの中で最新のブロック機能や余白設定を有効にするための記述です。

/
 ブロックエディターの機能をクラシックテーマで有効化する
/
function ebiz_setup_hybrid_theme() {
// 幅広・全幅ブロックを有効化
add_theme_support( 'align-wide' );

// エディター側にテーマのスタイルを読み込む
add_theme_support( 'editor-styles' );
add_editor_style( 'assets/css/editor-style.css' );

// カスタム余白設定を有効化（FSEの機能の一部を取り入れる）
add_theme_support( 'custom-spacing' );

// ブロックテンプレートパーツを有効化
add_theme_support( 'block-template-parts' );
}
// 特定のタイミング（テーマのセットアップ時）で処理を実行する
add_action( 'after_setup_theme', 'ebiz_setup_hybrid_theme' );

※動作確認済み環境：WordPress 6.4 / PHP 8.1 / クラシックテーマ環境
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

このコードを追記することで、従来型のPHPファイルでガッチリとレイアウトを固定したページ（トップページなど）と、クライアントが柔軟にブロックを組み合わせて構築できるページ（投稿やLPなど）を共存させることができます。

■ なぜハイブリッドアプローチを採用するのか（LAYER 3）

この書き方が推奨される理由は、権限と編集範囲の明確な分離ができるためです。内部的な仕様として、完全なブロックテーマ（FSE）を採用すると、ヘッダーやフッターを含むすべてのテンプレートがブロックエディターから編集可能になります。

正直に言うと、以前はクライアントの利便性を最優先し、完全なブロックテーマで納品していた時期がありました。しかし、運用担当者様が誤ってヘッダーのナビゲーションブロックを削除してしまい、サイト全体でメニューが消えてしまうというトラブルが発生した経験があります。

それ以来、レイアウトを崩してはいけない共通パーツやトップページはPHPで固定し、日々の更新が必要なコンテンツエリアのみブロックの自由度を高めるこのハイブリッド手法を、実務の標準として採用しています。

■ 向いているケース・向いていないケースまとめ

この手法を採用する際の判断基準として、以下の表をご活用ください。

■ 保守性・将来性の考察（LAYER 4）

長期的に見てこの選択は、現在のWordPressの方向性とも調和します。WordPress公式はFSEを推進していますが、クラシックテーマを直ちに切り捨てるわけではありません。ハイブリッドアプローチは、将来的なFSEへの完全移行を見据えつつ、現在の運用リスクを最小限に抑える現実的な架け橋となります。

迷ったときは、「誰が、どの頻度で、どこを編集するのか」という運用フローから逆算して設計すると整理しやすいです。正解は一つではありませんので、プロジェクトの要件に合わせて最適なバランスを見つけてみてください。

Web制作の設計やWordPressの運用保守に関するご相談は、お気軽にeBIZクリエイトまでお問い合わせください。

5. カスタマイズ性と保守性を両立するためのファイル構成とコードの実例

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入したテーマにおいて、どこまでをエディター上で制御し、どこからをコードで制御するかは、実務において非常に悩ましいポイントです。

実際の案件でも、すべてのスタイルをエディター側で設定できるようにした結果、お客様が誤ってレイアウトを崩してしまうというお問い合わせをいただくことがありました。そのため、カスタマイズの柔軟性を残しつつ、サイトの根幹となるデザインルールはコード側で担保するという設計が求められます。

ここでは、実務で採用しているファイル構成の考え方と、具体的なコードの実例をシェアします。

FSE環境下でのファイル構成の基本

FSE対応のブロックテーマでは、従来のクラシックテーマとは異なり、PHPファイルよりもJSONやHTMLファイルが主役になります。保守性を高めるためには、以下の役割分担を明確にすることが重要です。

theme.json: 全体的なカラースキーム、タイポグラフィ、余白などのグローバルなデザインルールの定義
functions.php: テーマの機能を追加・カスタマイズするファイル。カスタムブロックの登録や、コアブロックのスタイル拡張のみに限定
templates/.html: テンプレート構造の定義（PHPによる複雑な条件分岐は極力含めない）

theme.jsonによるデザインルールの制御

サイトのブランドカラーや、標準的な余白のルールは、テーマディレクトリ直下にある `theme.json` に記述します。これにより、エディター側での自由な変更を許可しつつ、あらかじめ定義した選択肢の範囲内で運用してもらうことが可能になります。

{
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "brand-primary",
"color": "#005baa",
"name": "ブランドブルー"
},
{
"slug": "text-main",
"color": "#333333",
"name": "メインテキスト"
}
],
"custom": false
},
"spacing": {
"units": ["px", "em", "rem", "vh", "vw"],
"customPadding": true,
"customMargin": true
}
}
}

※テーマのルートディレクトリに `theme.json` として保存します。WordPressのブロックエディター読み込み時に自動で適用されます。
※ `”custom”: false` を設定することで、カラーパレット以外の任意の色指定を制限し、ブランドガイドラインからの逸脱を防ぎます。

functions.phpでのブロックスタイル拡張

特定のブロックに対して、独自のCSSクラスを付与したい場合は、`functions.php` （またはそこから読み込む別ファイル）に以下のコードを記述します。

<?php
/
 カスタムブロックスタイルの登録

 記述場所: テーマの functions.php
 実行タイミング: after_setup_theme アクションフックの直後
/
function my_theme_register_block_styles() {
// 見出しブロックに「下線付き」のスタイルを追加
register_block_style(
'core/heading',
array(
'name'         => 'underline-heading',
'label'        => '下線付き見出し',
'is_default'   => false,
)
);
}
// init フック（WordPressの初期化処理のタイミング）で実行
add_action( 'init', 'my_theme_register_block_styles' );

このコードにより、エディターの右パネルに「下線付き見出し」というスタイルが追加され、出力されるHTMLに `is-style-underline-heading` というクラスが付与されます。あとは `style.css` でそのクラスに対する装飾を書くだけで済みます。

なぜこの構成を推奨するのか

この設計が推奨される理由は、デザインと構造の分離がより明確になるからです。

内部的な仕様として、`theme.json` に記述した内容は、WordPressが自動的にCSSのカスタムプロパティ（CSS変数）に変換して出力します。そのため、個別のCSSファイルにカラーコードを直接書き込むハードコードを避けることができ、将来的にブランドカラーが変更になった際も `theme.json` を1箇所修正するだけでサイト全体に変更を適用できます。

以前、コーポレートサイトの案件で、ページごとに個別のCSSを当ててデザインを微調整していたことがありました。しかし、その後の運用フェーズでサイト全体の見出しデザインを一新する改修が入った際、影響範囲の特定に膨大な時間がかかってしまったのです。この失敗経験から、デザインの基本ルールは `theme.json` に集約し、例外的な装飾のみブロックスタイルで対応するという方針をデフォルトにしています。

よくある間違いと注意点

やりがちですが避けた方がよいのは、テンプレートファイル（HTML）の中に、直接インラインスタイルを書き込んでしまうことです。エディター上で見た目を整えるために手っ取り早い方法ですが、保守フェーズにおいてスタイルの上書きが非常に困難になります。

また、複雑な動的コンテンツを出力したいからといって、ショートコードを多用するのも推奨しません。FSE環境では、動的なデータ出力はカスタムブロックを作成するか、既存のクエリループブロックを拡張するアプローチが将来的な互換性を保ちやすいです。

向いているケース・向いていないケース

保守性と将来性を見据えた判断

長期的な視点で考えると、WordPress本体の開発はブロックベースのアーキテクチャへと完全にシフトしています。そのため、クラシックなPHPベースのテンプレート階層に依存しすぎる設計は、今後のメジャーアップデートにおいて恩恵を受けにくくなる可能性があります。

設定ファイルである `theme.json` にデザインルールを委ね、表示の制御はWordPress本体の機能に任せるという方針は、サイトのパフォーマンス向上と保守のしやすさに直結します。迷ったときは、「この装飾はお客様がエディター上で変更する必要があるか」を基準に、コード化するかエディター機能として提供するかを切り分けると整理しやすいです。