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

WordPressのフルサイト編集（FSE：ブロックエディターでサイト全体を編集できる新機能）や、Gutenbergのカスタマイズについて、「実際の案件でどこまで使えるのか」と悩む場面はありませんか。

実際の案件でも、「従来のクラシックテーマからFSEに移行すべきか」「カスタムブロックの運用をどう設計するか」といったご相談をよくいただきます。FSEは機能が日々進化しており、構築の手法も選択肢が増えているため、案件の性質によって適切なアプローチが変わってきます。

この記事では、実際のWeb制作現場での経験をもとに、フルサイト編集やGutenbergカスタマイズを実務に取り入れる際の判断基準や、運用を見据えた設計方法についてシェアします。

■ この記事でわかること
・フルサイト編集を実案件に導入する際の具体的な判断基準
・従来テーマからFSEへ移行する際のメリットと直面しやすい課題
・実務で使いやすいGutenbergブロックのカスタマイズ手法
・保守性を高めるカスタムブロックのコード管理と運用設計

1. フルサイト編集を実案件に導入する際の判断基準と注意点

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

フルサイト編集（FSE）を利用したテーマ構築のご相談をいただくことが増えてきました。従来のPHPベースのクラシックテーマで長年制作してきた方ほど、FSEを実案件のメインに据えるべきか迷うことが多いのではないでしょうか。

以前、あるコーポレートサイトの案件でFSEを全面導入しようと試みた際、独自の複雑なレイアウト要件とブロックの自由度が衝突し、結果的に工数が膨らんでしまった経験があります。FSEは強力な機能ですが、すべての案件にフィットするわけではありません。この記事では、実務の現場でFSEを導入する際に、どのような基準で判断しているかを正直にシェアします。

この記事でわかること
・フルサイト編集（FSE）を実案件で採用するかの判断基準がわかります
・FSEの導入でつまずきやすい注意点と対策がわかります
・長期的な運用を見据えたテーマ選定の考え方がわかります

フルサイト編集（以下、FSE）は、ブロックエディター（Gutenberg）の仕組みを用いて、ヘッダーやフッターを含むサイト全体を視覚的に構築・編集できるWordPressの機能です。ノーコードで直感的にサイトを組み上げられる点が大きな特徴ですが、実案件で導入するには、クライアントの運用体制とデザイン要件を慎重に見極める必要があります。

まずは、デザインの「固定化」と「自由度」のバランスが最大の判断基準になります。FSEは、運用者が自由にレイアウトを変更できる反面、意図しないデザインの崩れを引き起こすリスクも抱えています。そのため、実務では「クライアントがどこまでデザインを触る必要があるか」を要件定義の段階で明確にすることが欠かせません。

正直に言うと、以前は「最新の機能だから」という理由でFSEを提案したこともありました。しかし、運用担当者から「ブロックの設定項目が多すぎて、どこを触ればいいかわからない」「余白の数値を誤って変更してしまい、全体のレイアウトが崩れてしまった」というご相談を受けるトラブルが起きてから、提案の基準を大きく変えました。現在では、厳格なブランドガイドラインがあり、デザインの統一性をシステム側で強制したい案件では、従来のクラシックテーマに独自のカスタムブロックを組み合わせて提供する手法をデフォルトにしています。

FSEの導入において、やりがちですが避けた方がよいのは「すべてのテンプレートをFSEで構築しようとする」ことです。複雑な条件分岐が必要なアーカイブページや、外部API（外部のシステムとデータをやり取りする仕組み）と連携するような動的なページは、PHPで記述する方が保守しやすく、予期せぬ不具合を防ぐことができます。

FSEの導入について、迷ったときは以下の表を基準に整理すると判断しやすくなります。

長期的な保守性や将来性を考えると、WordPress本体の開発は完全にFSEとブロックベースのアーキテクチャに舵を切っています。そのため、FSEの仕組みやtheme.json（テーマの全体的なスタイルや設定を定義するファイル）の仕様を理解しておくことは、Web制作者として不可避です。しかし、無理に今すぐ全案件をFSEに切り替える必要はありません。ハイブリッドテーマ（クラシックテーマにtheme.jsonを導入してブロック設定を制御する手法）を採用し、徐々にブロックベースの開発に慣れていくアプローチが、現在最もリスクが少なく現実的な選択だと考えています。

Web制作に関する運用や技術選定でお悩みの際は、お気軽にeBIZクリエイトまでご相談ください。状況に合わせた最適なアプローチを一緒に考えさせていただきます。

2. 従来のテーマ開発からFSEへ移行するメリットとデメリット

従来のクラシックテーマ（PHPベースのテーマ開発）からFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）への移行について、制作現場ではよく議論になります。長年PHPやCSSを書いてきた制作者にとって、ブロックベースの構築はこれまでと異なる考え方を求められるからです。

実務を通して見えてきた、FSEへ移行するメリットとデメリットを整理してシェアします。

メリット：運用フェーズでの柔軟性と設定の一元化

最大のメリットは、納品後の運用フェーズでクライアント自身がサイトの構造を触れる点にあります。クラシックテーマでは、ヘッダーやフッターのレイアウトを変更するにはPHPファイルの改修が必要でした。FSEであれば、管理画面のエディターからブロックを配置する感覚で修正が可能です。

また、開発者視点での大きな利点は `theme.json` の存在です。タイポグラフィ、カラーパレット、余白などのデザイン要件をこのファイル一つで一元管理できます。これにより、従来の `style.css` に記述していた膨大なCSSの量を大幅に削減でき、保守性が高まります。

デメリット：学習コストの高さとバージョン依存

一方で、実務上クリアすべき課題もあります。一番のハードルは学習コストです。フック（WordPressの処理に割り込んで独自の処理を追加する仕組み）やPHPテンプレート階層に慣れ親しんだ状態から、ブロックマークアップや `theme.json` の仕様を理解するには時間がかかります。

さらに、FSEはWordPress本体の開発スピードと密接に連動しています。本体のメジャーアップデートによってエディターのUIが変更されたり、ブロックの仕様が変わったりするリスクがあります。納品後の保守・メンテナンス契約において、どこまでサポートを含めるかの事前のすり合わせが欠かせません。

実案件での判断：なぜFSEを選んだのか

以前、コーポレートサイトの案件で「将来的にキャンペーンに合わせてヘッダーのレイアウトやバナー位置を自社で頻繁に変えたい」という要望をいただきました。クラシックテーマでカスタマイザーを作り込むことも検討しましたが、運用コストを考慮してFSEでの構築を選択しました。結果として、クライアント側で直感的に微調整が可能になり、細かな修正依頼のラリーを減らすことができました。

FSEへの移行が向いているケース・向いていないケース

迷った際は、以下の基準で整理すると要件に合った選択がしやすくなります。

保守性と将来性を考慮した選択

WordPress.orgの公式の開発方針を見ても、エコシステム全体がブロックベースへと移行していることは明確です。長期的な将来性を考えると、FSEの知識と設計スキルはWeb制作者にとって必須になっていきます。

しかし、すべての案件をFSEに切り替える必要はありません。複雑なカスタムフィールドの出力が連続するようなサイトや、完全固定の特殊なアニメーションを実装する場合は、従来のクラシックテーマの方が保守しやすい場面も多々あります。技術の目新しさだけでなく、案件の要件とクライアントの運用体制に合わせて適切な手法を選択することが大切です。

3. 現場で重宝するGutenbergブロックのカスタマイズ手法

Gutenberg（ブロックエディター）でのサイト構築において、デフォルトのブロックだけではクライアントの細かなデザイン要件を満たせない場面によく直面します。以前、企業のコーポレートサイト制作案件で「ボタンのデザインを複数パターン用意して、運用担当者が自由に選べるようにしたい」という要望がありました。

初めは独自のカスタムブロックをゼロから開発することも検討しましたが、保守性や開発コストを考慮した結果、既存のコアブロック（WordPressに標準で用意されているブロック）に独自のスタイルを追加するアプローチを選択しました。この手法は、開発の負担を抑えつつ運用者の使い勝手を向上させることができるため、現在では実案件での基本方針として採用しています。

ここでは、実務で頻繁に使用する「ブロックスタイルの追加」について具体的な手法をシェアします。

以下のコードは、テーマの機能を拡張するためのファイルである `functions.php` に記述します。

// functions.php に記述します
// WordPressの初期化タイミング（init）で独自のボタンスタイルを追加
function ebiz_register_custom_block_styles() {
// core/button（標準のボタンブロック）に新しいスタイルを登録
register_block_style(
'core/button',
array(
'name'  => 'arrow-button', // CSSクラスとして出力される識別名
'label' => '矢印付きボタン', // エディター上に表示される表示名
)
);
}
// 'init' というアクションフック（特定のタイミングで処理を実行する仕組み）を使用して関数を呼び出します
add_action( 'init', 'ebiz_register_custom_block_styles' );

このコードを追加することで、エディター画面のボタンスタイル設定に「矢印付きボタン」という選択肢が追加されます。選択すると、フロントエンド側のHTMLには `is-style-arrow-button` というクラスが付与されるため、あとは `style.css` などのスタイルシートで該当クラスに対してCSSを記述するだけでデザインを適用できます。

この書き方を推奨する理由は、WordPressの標準機能に沿った拡張方法であるためです。コアブロックのアップデートが行われた際にもデザインが崩れるリスクが少なく、長期的な保守性の観点から非常に安定しています。逆に、ブロックのHTML構造自体をJavaScriptで直接書き換えるようなカスタマイズは、将来的なメジャーアップデートの影響を受けやすくなるため、特別な理由がない限りは避けるようにしています。

よくあるつまずきポイントとして、スタイルを登録したもののCSSがエディター側に反映されないというケースがあります。その場合は、エディター用のCSSが正しく読み込まれているか、`add_editor_style()` などの設定を確認してみてください。

ブロックスタイルの追加における判断基準を以下の表にまとめました。

迷ったときは、「HTMLの構造を変更する必要があるか」を基準に考えると整理しやすいです。単なる装飾の変更であればスタイルの追加で対応し、独自の入力フィールドや複雑なレイアウトが必要な場合は、カスタムブロックの開発やパターン機能の活用を検討してみてください。長期的な運用を見据え、WordPressの今後の方向性と合致した無理のないカスタマイズを選択することが、安定したサイト運営につながります。

4. カスタムブロック開発時の効率的なコード管理と運用設計

実際の案件でカスタムブロックを複数開発していると、コードの肥大化や管理の煩雑さに悩まされる経験はありませんか。
初期のGutenberg（ブロックエディター）開発では、`functions.php`（テーマの機能を追加・カスタマイズするファイル）にブロックの登録処理を直接記述し、JavaScriptファイル内で設定を完結させる手法が主流でした。しかし、この方法でブロック数が10や20と増えていくと、どこに何が書かれているのか把握できなくなり、保守性が著しく低下してしまいます。

実案件でこうした課題に直面した結果、eBIZクリエイト株式会社では現在の開発フローにおいて、公式パッケージである`@wordpress/scripts`と`block.json`を用いたメタデータ駆動型のコード管理をデフォルトとしています。

なぜ block.json を活用するのか

`block.json`は、ブロックの名前、カテゴリ、アイコン、読み込むべきCSSやJavaScriptのファイルパスなど、ブロックに関するメタデータを一元管理するためのファイルです。
この書き方が推奨される理由は、WordPress本体側（PHP）とエディター側（JavaScript）の両方から同じ設定ファイルを参照できるためです。これにより、コードの重複を防ぎ、アセット（CSS/JS）の読み込み最適化をWordPress本体に任せることが可能になります。

実務でのコード管理例

ここでは、カスタムブロックを登録する際の、推奨されるディレクトリ構成とコード例をシェアします。

<?php
// plugins/my-custom-blocks/index.php などのプラグインメインファイル、またはテーマの functions.php に記述
// action hook（特定のタイミングで処理を実行する）の init を使用してブロックを初期化します

/
 カスタムブロックを登録する関数
/
function ebiz_register_custom_blocks() {
// block.json が配置されているディレクトリを指定してブロックを登録
// これにより、PHP側でスクリプトやスタイルのエンキュー（読み込み）を自動で行ってくれます
register_block_type( __DIR__ . '/build/custom-hero-block' );
}
// initフックで実行
add_action( 'init', 'ebiz_register_custom_blocks' );

// plugins/my-custom-blocks/src/custom-hero-block/block.json
// ブロックのメタデータを定義するファイル
{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "ebiz/custom-hero",
"title": "ヒーローバナー",
"category": "design",
"icon": "cover-image",
"editorScript": "file:./index.js",
"editorStyle": "file:./index.css",
"style": "file:./style-index.css"
}

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

よく見かける間違いとして、テーマの`functions.php`にすべてのブロック登録処理とスクリプトのエンキュー処理を直書きしてしまうケースがあります。
サイトの規模が小さいうちは問題ありませんが、ページごとに不要なブロックのCSSまで読み込まれてしまい、パフォーマンス低下の原因になります。`block.json`を使用すれば、そのブロックがページ内に配置されているときのみ必要なアセットが読み込まれるため、パフォーマンス面でも非常に有利です。

運用設計の判断基準

開発手法について迷ったときは、以下の表を参考にしてみてください。

保守性・将来性の考察

長期的に見て、WordPress公式が推奨する`block.json`と`@wordpress/scripts`を軸とした開発スタイルに寄せておくことは、今後のメジャーアップデートの影響を最小限に抑える上で重要です。
フルサイト編集（FSE）が進化を続ける中で、ブロック単位のメタデータ管理はさらに重要性を増しています。独自のビルド環境を複雑に組み上げるよりも、公式のレールに乗ることで、数年後のメンテナンスコストを大幅に削減できます。迷ったときは、公式ドキュメントに沿った標準的なアプローチを選択すると整理しやすいです。

5. 保守性と将来性を見据えたテーマ設計の考え方

WordPressのテーマ設計において、目先の構築スピードだけでなく、公開後数年先まで見据えた保守性が非常に重要になります。特にFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）が導入されて以降、テーマの作り方は根本的な転換期を迎えています。

実際の案件でも、「従来のPHPベースのクラシックテーマで構築するか、それともFSEを活用したブロックテーマで構築するか」というご相談をよくいただきます。結論からお伝えすると、WordPress公式の開発コミュニティがブロックベースの設計に大きく舵を切っている以上、新規構築においてはブロックエディターの活用を前提とした設計方針を採用することが推奨されます。

内部的な仕様に目を向けると、従来のクラシックテーマではPHPファイルに直接HTMLと独自の関数を記述していましたが、ブロックテーマではtheme.jsonという設定ファイルを中心に、デザインやレイアウトの共通ルールを定義します。これにより、コードの記述量が減り、デザインの一貫性を保ちやすくなるという構造上のメリットがあります。

以前、従来のクラシックテーマからブロックテーマへのリニューアル案件を担当した際のことです。当初は既存のPHPテンプレートをそのまま活かす方針も検討しましたが、運用担当者から「テキストの修正だけでなく、キャンペーンごとにレイアウトも自分たちで柔軟に変更したい」という強い要望がありました。そこでFSEを前提としたテーマ設計に切り替えた結果、納品後の軽微な修正依頼が激減し、お客様自身でスピーディーにページを量産できる体制を構築できました。

ただし、すべての案件で完全にFSEへの移行が適しているわけではありません。複雑なデータベース連携が必要なポータルサイトや、会員独自のマイページ機能を持つようなシステム寄りのWebサイトでは、従来のPHPによる細かい制御が必要になる場面も少なくありません。

ここで、テーマ設計方針の判断基準として、ブロックテーマ（FSE）の採用が向いているケースと向いていないケースを整理しておきます。

長期的に見て正しい選択をするためには、WordPress本体の開発方向性と合致しているかを常に意識することが大切です。コア機能として提供されている標準ブロックやAPIを最大限に活かし、独自のカスタマイズを最小限に抑えることが、将来的なメジャーアップデート時の不具合リスクを減らす確実な方法となります。迷ったときは、「WordPress公式が推奨する標準の仕組みに逆らっていないか」を基準に設計を組み立てていくと、保守性の高いテーマに仕上がります。