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

「そろそろフルサイト編集に切り替えるべきか、それとも従来のクラシックテーマを継続するか」

実際の案件で、このようなご相談をいただく機会が非常に増えました。FSE（フルサイト編集）やGutenberg（ブロックエディター）は機能が充実してきた一方で、実務への導入タイミングや、お客様が運用しやすい設計をどう実現するかで壁にぶつかることも少なくありません。

私自身も複数のプロジェクトで試行錯誤を繰り返し、時には運用フェーズで想定外のトラブルに直面しながら、現場で使えるノウハウを蓄積してきました。この記事では、Web制作の現場で実際に経験した課題と解決策をもとに、フルサイト編集を実案件で活用するための設計や判断の軸をシェアします。

■ この記事でわかること
・クラシックテーマとフルサイト編集の実務的な選び方と判断基準
・Gutenberg導入時に現場で起こりやすい課題とその解決手順
・保守性を高め、長期的な運用に耐えるブロックテーマの設計ポイント
・運用者の負担を減らす柔軟なレイアウト構築のアプローチ

1. クラシックテーマとフルサイト編集の使い分けと実案件での判断基準

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

WordPressの案件において、従来通りのPHPを中心としたクラシックテーマで構築するべきか、ブロックエディターでサイト全体を編集できるFSE（フルサイト編集）を採用するべきか、判断に迷う場面が増えてきました。実際の案件でも、お客様から「ブロックエディターを活用して自分たちでレイアウトも変更したい」というご要望をいただくことが多くなっています。この記事では、実務の現場でどのような基準で両者を使い分けているのか、リアルな判断軸をシェアします。

この記事でわかること
・クラシックテーマとFSEの根本的な違い
・実務における具体的な使い分けの判断基準
・将来を見据えたテーマ選定の考え方

クラシックテーマは、ヘッダーやフッター、アーカイブなどのテンプレートをPHPファイルで構築する従来の手法です。開発者がレイアウトを完全に制御できるため、お客様が誤ってデザインを崩してしまうリスクを最小限に抑えることができます。

一方、FSEはブロックエディターの機能を拡張し、サイト全体をブロックで構築・編集できる機能です。HTMLやPHPの知識がない管理者でも、管理画面から直接ヘッダーやフッターのデザインを変更できる柔軟性を持っています。

以前、頻繁にキャンペーン用のランディングページを追加し、サイト全体のレイアウトも柔軟に変更したいというご要望の案件がありました。当初はクラシックテーマで細かくテンプレートを作り込む予定でしたが、運用フェーズでの更新頻度と自由度の高さを優先し、FSEを採用しました。結果として、お客様自身でスピーディーにレイアウト変更を行えるようになり、運用コストの削減につながりました。ただし、自由度が高い反面、意図しないデザイン崩れが発生するリスクもあるため、運用ルールを明確に決めておくことが重要です。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| クラシックテーマ | 厳密なデザイン管理が必要な場合 | 運用者が頻繁にレイアウト変更を行う場合 |
| FSE（フルサイト編集） | 運用側でサイト全体を柔軟に変更したい場合 | 更新者のスキルにばらつきがあり、デザイン崩れを防ぎたい場合 |

長期的な保守性や将来性を考えると、WordPressの開発方針は明らかにブロックベースへとシフトしています。しかし、実務においては、お客様の運用体制やリテラシーに合わせて選択することが最も重要です。デザインの堅牢性を重視するならクラシックテーマ、運用の柔軟性を最大化するならFSEというように、プロジェクトの要件に応じて適切な手段を選択していただければと思います。Web制作でのテーマ選定や運用設計に関するご相談はお気軽にeBIZクリエイトまでお寄せください。

2. 実務で直面したGutenberg導入時の課題と具体的な解決手順

実際の案件でGutenberg（ブロックエディター）を導入する際、最も頻繁に直面するのが「クライアントが自由に編集できる反面、サイトのレイアウトが簡単に崩れてしまう」という課題です。

以前、企業のコーポレートサイトを構築した際、標準で用意されているすべてのブロックを利用可能な状態で納品しました。しかし運用フェーズに入ると、本来は使用を想定していなかったカラムブロックやボタンブロックが多用され、サイト全体のデザインの統一感が損なわれるという問題に直面しました。

この経験から、現在の制作案件では「必要最小限のブロックのみを許可する」というアプローチをデフォルトにしています。すべての機能を開放するのではなく、運用で実際に使うブロックだけをホワイトリスト形式で指定することで、保守性が大幅に向上します。

具体的な解決手順として、フィルターフック（データを加工・変換するWordPressの仕組み）である「allowed_block_types_all」を使用し、特定の投稿タイプに対して許可するブロックを制御します。以下のコードをテーマのfunctions.php（テーマの機能を追加・カスタマイズするファイル）に記述します。

“`php
/
投稿画面で使用できるブロックを制限する

@param array|bool $allowed_block_types 許可されているブロックの配列、またはすべて許可する場合はtrue。
@param WP_Block_Editor_Context $block_editor_context ブロックエディターのコンテキスト情報。
@return array 許可するブロックの配列。
/
function restrict_gutenberg_blocks( $allowed_block_types, $block_editor_context ) {
// 投稿（post）のみ制限を適用し、固定ページなどはデフォルトのままにする
if ( ! empty( $block_editor_context->post ) && $block_editor_context->post->post_type === ‘post’ ) {

// 許可するブロックを指定（段落、見出し、画像、リストのみ）
$allowed_blocks = array(
‘core/paragraph’,
‘core/heading’,
‘core/image’,
‘core/list’,
);

return $allowed_blocks;
}

// 投稿以外のページはすべてのブロックを許可する
return $allowed_block_types;
}
// エディターが読み込まれるタイミングで処理を実行する
add_filter( ‘allowed_block_types_all’, ‘restrict_gutenberg_blocks’, 10, 2 );
“`

この書き方が推奨される理由は、運用時のヒューマンエラーをシステム側で未然に防げるためです。内部的な動作としては、ブロックエディターの画面が読み込まれる直前にこのフィルターフックが実行され、利用可能なブロックのリストが上書きされます。

また、フルサイト編集（ブロックエディターでサイト全体を編集できるWordPressの新機能）に対応したテーマを構築している場合は、theme.jsonという設定ファイルを利用してブロックの制限やスタイルの固定を行う方法もあります。

| 制御方法 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| functions.phpでの制御 | 投稿タイプごとに細かく許可ブロックを変えたい場合 | コードを書かずにノーコードで制御したい場合 |
| theme.jsonでの制御 | フルサイト編集対応テーマで、サイト全体のデザインルールを統一したい場合 | クラシックテーマを使用している場合 |

迷ったときは、まず「クライアントが日常的な更新業務で本当に必要なブロックはどれか」をリストアップしてみてください。そこから逆算して許可するブロックを決定することで、安全で運用しやすい環境を提供できます。長期的な運用を見据えると、初期段階で編集の自由度を適切に制限しておくことが、結果としてサイトの品質維持につながります。

3. ブロックテーマ開発における保守性と運用効率を高める設計のコツ

ブロックテーマを用いたサイト構築において、実務で頻繁に直面するのが「どこでスタイルを管理するか」という問題です。FSE（フルサイト編集）環境では、エディター上での直感的な操作が可能になる一方で、制作者が意図しないデザインの崩れが起きやすくなるという側面があります。

保守性と運用効率を高めるための軸となるのが、「theme.json」を活用した中央集権的なスタイル管理です。

theme.jsonによるスタイルと設定の一元管理

theme.jsonとは、ブロックテーマの設定やスタイルを一元管理するための設定ファイルです。従来、style.cssに記述していたカラーコードやフォントサイズなどの基本定義を、このファイルに集約します。

この書き方が推奨される理由は、WordPressのコア（本体）がtheme.jsonの記述を読み取り、エディター側のUIとフロントエンドのCSS出力の両方を自動で制御してくれるためです。内部で連動して動いているからこそ、エディターと実際のページの見た目を簡単に一致させることができます。

以下は、実務でよく設定する独自のカラーパレットを定義するコード例です。

“`json
{
“version”: 2,
“settings”: {
“color”: {
“palette”: [
{
“slug”: “brand-primary”,
“color”: “#005baa”,
“name”: “メインカラー”
},
{
“slug”: “brand-secondary”,
“color”: “#f2f2f2”,
“name”: “背景グレー”
}
],
“custom”: false // ユーザーによる任意のカラーピッカー使用を制限する
}
}
}
“`

ここで重要なポイントは `”custom”: false` の記述です。実際の案件では、クライアントがエディター上で自由に色を変更できてしまうと、サイト全体のブランドガイドラインから逸脱してしまうトラブルが起こりがちです。カスタムカラーを制限し、あらかじめ定義したパレットのみを選択可能にすることで、運用時のデザイン崩れを未然に防ぐことができます。

実案件での失敗談と改善策

正直に言うと、ブロックテーマを導入し始めた頃は、クラシックテーマと同じ感覚で詳細なスタイルをstyle.cssで強制的に上書きしていました。しかし、WordPressのメジャーアップデートが行われた際、コアブロックのHTML構造が微妙に変更され、CSSが効かなくなるという問題に直面しました。

その経験から、現在は「WordPressの標準機能（theme.json）で制御できるものは極力それに任せ、どうしても対応できない複雑なレイアウトのみCSSで補完する」というルールを、案件のデフォルトにしています。

パターン管理による運用効率の向上

もう一つの設計のコツは、ブロックパターンの活用です。よく使うレイアウトの組み合わせをパターンとして登録しておくことで、運用担当者が迷わずページを作成できるようになります。

“`php
‘独自レイアウト’ ) // 管理画面での表示名
);
}
“`

パターンをあらかじめ用意しておくことで、運用フェーズでの作業時間が大幅に短縮され、引き継ぎ時の説明コストも下がります。

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

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| theme.jsonでの管理 | サイト全体の基本トーン（色・フォント）を統一する場合 | 特定の1ページのみの特殊な装飾 |
| カスタムカラーの制限 | 複数人の担当者が運用し、ブランドガイドラインを守りたい場合 | 運用者が自由にデザインを組む必要のあるLP制作 |
| パターン登録 | お問い合わせへの導線など、繰り返し使うレイアウトがある場合 | 構造が毎回大きく変わるニュース記事の本文 |

長期的な保守性と将来性を見据えて

長期的に見て、Gutenbergおよびフルサイト編集を中心とした開発アプローチは、WordPressの今後の方向性と完全に一致しています。コア側で用意されている仕組み（theme.jsonやパターン）に逆らわず、それに沿って設計を組むことが、将来的なアップデートによる影響を最小限に抑える一番の近道です。

迷ったときは、「この設定は将来の運用担当者がエディター上で直感的に扱えるか」という視点で判断すると整理しやすいです。正解は一つではありませんが、案件の要件に合わせて柔軟に設計方針を選択してみてください。

4. カスタムブロックと既存ブロックを活用した柔軟なレイアウト構築法

WordPressのブロックエディター（Gutenberg）を使った案件で、よく直面するのが「どこまで既存のコアブロックを使い、どこからカスタムブロックを作るか」という課題です。

ブロックエディターが導入された初期の頃は、独自のレイアウトを実現するために、何でもかんでもカスタムブロックとして自作してしまうケースがよく見られました。しかし、現在のフルサイト編集（FSE）環境では、既存ブロックとカスタムブロックを適切に組み合わせることが、運用しやすく保守性の高いサイトを作る鍵になります。

既存ブロックの拡張から検討する

新しいデザインを実装する際、まずは「既存のコアブロック（見出しや段落、グループブロックなど）のスタイルを追加することで解決できないか」を考えます。

例えば、特定の装飾が施された見出しが必要な場合、ゼロからカスタムブロックを作るのではなく、WordPressの標準機能である `register_block_style` を使って、既存の見出しブロックに新しいスタイルバリエーションを追加します。

このコードは、テーマの機能を追加・カスタマイズするファイルである `functions.php` に記述します。

“`php
/
見出しブロックにカスタムスタイルを追加する
記述場所：functions.php
実行タイミング：after_setup_theme（テーマのセットアップ完了時）
/
function mytheme_register_block_styles() {
// コアの見出しブロックに「リボン風」スタイルを追加
register_block_style(
‘core/heading’, // 対象となるブロック名
array(
‘name’ => ‘ribbon-style’, // CSSクラスとして出力される名前（is-style-ribbon-style）
‘label’ => ‘リボン風’, // エディター上に表示されるラベル
‘is_default’ => false, // デフォルトスタイルにはしない
)
);
}
add_action( ‘after_setup_theme’, ‘mytheme_register_block_styles’ );
“`

このアプローチを選ぶ理由は、WordPress本体のアップデートによる恩恵を受け続けられるからです。コアブロックは、余白の調整やタイポグラフィの設定など、バージョンが上がるごとに便利な機能が追加されていきます。自作ブロックでこれをすべて再現し、維持していくのは非常にコストがかかります。

実務での失敗談と現在の判断基準

以前、あるコーポレートサイトの案件で、運用者の入力の手間を省くために「画像とテキストがセットになったPRエリア」を、専用のカスタムブロックとして完全に作り込んだことがありました。

最初は便利だったのですが、運用していくうちに「ここだけボタンを追加したい」「画像の角を丸くしたい」といった細かな要望が出てきました。カスタムブロックとしてガチガチに固めていたため、その都度コードの改修が必要になり、結果的に保守の手間が増大してしまったのです。

この経験から、現在では「レイアウト（枠組み）」と「コンテンツ」を分けて考えるようにしています。枠組みはグループブロックやカラムブロックといった既存のレイアウト要素を使い、どうしても複雑な入力制御が必要なパーツ（例えば、独自の計算処理が入る料金シミュレーターや、外部APIと連携する特殊なスライダーなど）に限って、カスタムブロックを開発するようにしています。

使い分けの基準まとめ

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 既存ブロックの拡張 | デザインの装飾違い、シンプルなレイアウト、標準の余白・色設定を活用したい場合 | 複雑な入力項目がある場合、外部データと連携する場合 |
| カスタムブロック作成 | 独自の入力インターフェースが必要な場合、JSによる複雑な動きを伴うUIコンポーネント | 単純なテキストや画像の配置、見出しの装飾変更 |

長期的な保守性や、今後のWordPressの方向性を考えると、可能な限り「コアブロックの組み合わせ＋ブロックスタイルの追加」で表現する設計が望ましいです。これにより、将来的なメジャーアップデートの影響を受けにくく、運用者にとっても学習コストの低い、柔軟なレイアウト構築が可能になります。迷ったときは、「既存ブロックのスタイル追加で本当に実現できないか？」を一度立ち止まって検証してみてください。

5. 長期的なサイト運用を見据えたフルサイト編集のメリットと注意点

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの機能）を実務で採用するかどうか迷う場面は多いのではないでしょうか。実際の案件でFSEを導入し、数年にわたって運用保守を行ってきた経験から、長期的な視点でのメリットと注意点を共有します。

まず、FSEを採用する最大のメリットは、運用フェーズでの柔軟性にあります。従来であれば、ヘッダーのレイアウト変更やフッターのリンク追加といった改修は、テーマのPHPファイルを直接編集する必要がありました。しかし、FSE環境では、管理画面のブロックエディターからクライアント自身、あるいはWeb担当者が安全に変更を加えることが可能です。これにより、軽微な修正にかかるコミュニケーションコストと作業時間が大幅に削減されます。

内部的な仕様として、FSEはテーマの構造をPHPからHTMLベースのブロックテンプレートへと移行させています。これにより、WordPress本体のアップデートに対する互換性が高まり、メジャーアップデート時にサイトが崩れるリスクが軽減される傾向にあります。これは、長期的な保守性を考える上で非常に大きなポイントです。

一方で、注意すべき点も存在します。以前、デザインの自由度を優先する案件でFSEを全面的に採用した際、クライアントが誤ってサイト全体のレイアウトを崩してしまうというトラブルが発生しました。FSEは「どこでも編集できる」という強みがある反面、運用者のITリテラシーによっては意図しない変更を加えてしまうリスクが伴います。

そのため、現在eBIZクリエイト株式会社では、FSEを導入する際には必ず「theme.json（テーマの全体的なスタイルやエディターの動作を制御する設定ファイル）」を活用し、編集可能な領域とロックする領域を明確に定義するようにしています。色数やフォントサイズを制限することで、ブランドガイドラインを逸脱しない安全な運用環境を構築できます。

フルサイト編集を採用すべきかどうかの判断基準として、以下の表に整理しました。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| フルサイト編集の導入 | 運用フェーズで頻繁にレイアウト変更を行いたい場合 | 運用者のITリテラシーに不安があり、デザインを厳格に固定したい場合 |

長期的に見て、WordPressのコア機能は間違いなくブロックベース、そしてFSEへと舵を切っています。開発が継続されており、エコシステム全体がこの方向に向かっているため、新規案件においてはFSEを前提とした設計を検討する価値は十分にあります。

迷ったときは、「納品後に誰が、どの程度の頻度で、どこまで変更を加えるのか」をクライアントとすり合わせることから始めてみてください。それが、最適な技術選定の第一歩となります。Web制作や保守運用に関するご相談はお気軽にeBIZクリエイト株式会社までお問い合わせください。