【動作確認済み環境】
・WordPress：6.4（※2026年を見据えた最新環境を想定）
・PHP：8.2
・確認日：2024年5月
・テーマ：Twenty Twenty-Four（FSE対応テーマ）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「フルサイト編集（FSE）、そろそろ実案件で導入した方がいいのかな……」
最近、同業者やクライアントからこういった相談を受けることが増えました。ブロックエディター（Gutenberg）が標準になって久しいですが、サイト全体をブロックで構築するFSEとなると、従来のPHPテンプレートに慣れた制作者にとっては、学習コストや保守性への不安から二の足を踏んでしまうケースも多いのではないでしょうか。

実は私自身も、初めはFSEの自由度に戸惑い、「これまでのクラシックテーマで十分では？」と考えていた時期がありました。しかし、実際の制作現場で何度か検証と実装を重ねるうちに、FSEが持つ「運用時の手軽さ」と「開発工数の削減」というメリットが明確に見えてきました。同時に、すべての案件にFSEが向いているわけではないという判断基準も固まってきています。

この記事では、長年のWeb制作の実務経験に基づき、2026年のトレンドを見据えたフルサイト編集とGutenbergカスタマイズのリアルな活用術をシェアします。現場で直面した課題や、保守性を高めるための設計ポイントも包み隠さずお伝えしますので、今後のテーマ選定や制作フローの参考にしてみてください。

■ この記事でわかること
・FSE（フルサイト編集）を実案件で採用するかどうかの明確な判断基準
・Gutenbergを用いた効率的なブロック構築の手順
・従来のクラシックテーマとFSEの具体的な使い分け方
・カスタマイズ時に陥りやすい課題と、その解決策
・長期的な運用・保守を見据えた安全な設計ポイント

1. 2026年のWordPressフルサイト編集の実務における活用方法と判断基準

【動作確認済み環境】
・WordPress：最新バージョン（マイナーアップデート含む）
・PHP：8.1以上
・確認時期：最新アップデート適用時
・テーマ：Twenty Twenty-Four（FSE対応テーマ）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）が導入されてから、実際の案件でどう扱うべきか悩む場面が多くなりました。「クライアントが誤ってレイアウトを崩してしまうのではないか」「従来のクラシックテーマとどちらを選ぶべきか」といったご相談をよくいただきます。

この記事では、実務の現場でFSEをどのように活用し、どのような基準で導入を判断しているのかを正直にシェアします。

【この記事でわかること】
・FSE（フルサイト編集）を実案件で導入すべきかの判断基準
・クライアントの運用を想定した安全なカスタマイズ方法
・FSEのメリットと実務における注意点

1. WordPressフルサイト編集の実務における活用方法と判断基準

FSEの最大の魅力は、ヘッダーやフッター、テンプレートファイルといったこれまでPHPで記述していた部分まで、すべてブロックエディター（Gutenberg）の画面上で直感的に編集できる点です。これにより、コーディングの知識がないクライアントでも、テキストの修正や画像の差し替えだけでなく、サイト全体のレイアウト変更まで自社で完結できるようになります。

しかし、実務において「何でもできる」ことは、同時に「何でも壊せてしまう」リスクを伴います。

以前、FSEをフル活用して納品した案件で、クライアントが誤ってヘッダーのナビゲーションブロックを削除してしまい、サイト全体のメニューが消えてしまうというトラブルがありました。その時の経験から、現在ではクライアントのITリテラシーや運用体制に合わせて、編集権限を細かく制御するアプローチをとっています。

theme.json（テーマの全体的なスタイルやエディターの動作を設定するファイル）を活用することで、クライアントが触れる部分と触れない部分を明確に切り分けることが可能です。例えば、特定の色やフォントサイズのみを選択できるように制限したり、レイアウトを固定してブロックの移動や削除を禁止（ロック）したりすることができます。

この「権限と自由度のコントロール」こそが、実務でFSEを成功させる鍵になります。

では、どのような案件でFSEを採用し、どのような案件で従来のクラシックテーマ（PHPベースのテーマ開発）を採用するべきでしょうか。迷ったときは、以下の表を基準に整理すると判断しやすくなります。

FSEはWordPressの今後の方向性（コア機能の進化）と完全に一致しており、長期的な保守性や開発スピードの向上という観点では非常に優秀です。しかし、既存の複雑なシステムを無理にFSEに移行する必要はありません。要件に応じて、従来のPHPベースのテーマにブロックエディターの利便性を組み合わせたハイブリッドなアプローチを採用することも、実務では有効な選択肢となります。

迷ったときは、「誰が、どのような頻度で、どこまで更新するのか」という運用フェーズの要件から逆算して設計することをおすすめします。

2. Gutenbergカスタマイズで実案件の効率を上げるブロック構築の手順

実務においてGutenberg（ブロックエディター）のカスタマイズを求められる機会が増えています。しかし、すべてのデザイン要件に合わせてReactで独自のカスタムブロックをゼロから開発するのは、制作コストも保守の難易度も跳ね上がってしまいます。

現場で効率よく、かつクライアントが使いやすい環境を整えるための手順をシェアします。

既存ブロックの拡張を第一選択にする

ボタンや見出しといった基本的な要素は、WordPress標準のブロックに独自のスタイルを追加するアプローチが現実的です。`register_block_style`を活用して、標準機能にCSSクラスを追加する選択肢を用意します。

以下のコードは、標準のボタンブロックに独自の「矢印付きボタン」というスタイルを追加する例です。テーマのfunctions.php（テーマの機能を追加・カスタマイズするファイル）に記述します。特定のタイミングで処理を実行するアクションフックである`init`に割り込ませて実行します。

/
 Gutenbergブロックにカスタムスタイルを追加する
 記述場所: functions.php
 実行タイミング: initフック
/
function custom_register_block_styles() {
// ボタンブロックに「矢印付きボタン」のスタイルを追加
register_block_style(
'core/button', // 対象となる標準ブロック名
array(
'name'  => 'arrow-button', // CSSクラスとして出力される名前 (is-style-arrow-button)
'label' => '矢印付きボタン', // エディター上に表示される表示名
)
);
}
add_action( 'init', 'custom_register_block_styles' );

この記述を行うだけで、エディターの右側パネルに新しいスタイルの選択肢が増えます。あとはテーマのCSSファイルに`.is-style-arrow-button`に対する装飾を書くだけです。

なぜ独自のブロック開発を避けるのか

このアプローチを推奨する理由は、WordPress本体のアップデートへの耐性です。

標準ブロックのHTML構造や内部仕様は、アップデートによって変更される可能性があります。独自のReactコードで専用ブロックを作ってしまうと、コアの仕様変更に巻き込まれてエディター上でエラーを起こし、編集できなくなるリスクが生じます。

標準ブロックの拡張であれば、コアの機能に相乗りしてCSSクラスを付与するだけなので、そうしたトラブルを最小限に抑えられます。

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

正直に言うと、過去の案件でクライアントの細かな要望に応えるため、独自ブロックを大量にフルスクラッチで開発したことがありました。

しかし、WordPressのメジャーアップデートの際、いくつかのブロックが非推奨のAPIに依存していたため、急遽コードを書き直すという保守のトラブルが起きてから考え方を変えました。

現在、制作現場では「まずは標準ブロックのスタイル追加で対応できないか検討する」「複雑なレイアウトはブロックパターンとして登録する」をデフォルトのルールにしています。

ブロックスタイル拡張の使い分け

標準ブロックの拡張が適しているケースと、そうでないケースを整理しました。

入力項目が複雑で独自のデータを持たせる必要がある場合は、複数の標準ブロックを組み合わせた「ブロックパターン」の登録に切り替えるか、プラグインを活用したブロック構築に切り替えるのが、長期的な保守を考えた際の現実的な選択となります。

3. フルサイト編集を導入するメリットと従来テーマとの使い分け方

WordPressのサイト構築において、フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を採用するか、従来のクラシックテーマ（PHPファイルベースで構築するテーマ）をベースにするかは、現場でもよく議論される悩ましいポイントです。実際の案件でも、お客様から「管理画面からヘッダーの構成も自由に変更できるようにしてほしい」というご要望をいただく機会が増えてきました。

ここでは、実案件を通して見えてきたフルサイト編集の実用性と、従来テーマとの現実的な使い分けの判断基準をシェアします。

フルサイト編集を導入する大きなメリットは、運用時の柔軟性にあります。従来はPHPファイルを直接編集する必要があったヘッダーやフッター、アーカイブページのレイアウト変更を、管理画面のブロックエディターから直感的に操作できるようになります。これにより、サイト公開後の軽微なデザイン改修であれば、お客様自身で対応可能な範囲が大きく広がります。

開発側の視点でも、theme.json（サイト全体のスタイルを定義する設定ファイル）でタイポグラフィやカラーパレットを集中管理できるため、CSSの記述量を大幅に削減できるという利点があります。なぜこの設計が推奨されるかというと、WordPressのコア開発が完全にブロックベースの設計へとシフトしているからです。内部の仕様として、グローバルなスタイル設定をtheme.jsonに集約することで、エディター側とフロント側のデザインの不一致を防ぐ仕組みになっています。

正直にお伝えすると、以前は「まだクラシックテーマの方が細回りが利く」と判断し、FSEの導入を見送る時期もありました。しかし、ブロックテーマの機能が成熟してきた現在、シンプルなコーポレートサイトの案件では、FSEベースの構築をデフォルトの手法として採用しています。

ただし、すべての案件に適しているわけではありません。やめた方がいいケースとして「複雑な動的処理や会員機能が中心のサイト」が挙げられます。独自の条件分岐を多用するシステムライクなサイトを無理にFSEで構築しようとすると、カスタムブロックの開発工数が跳ね上がり、かえって保守性が低下するトラブルにつながりかねません。

このような複雑な要件がある場合は、代替案として従来通りのクラシックテーマを採用し、投稿ページなどのコンテンツ部分にのみブロックエディターを活用する「ハイブリッド型」の構築をおすすめします。

迷った際は、以下の表を判断基準の軸として整理してみてください。

長期的な将来性を考えると、WordPressの方向性としてFSEの仕組みがさらに強化されていく流れにあります。開発が継続されている公式の機能であるため、メジャーアップデートの影響を安全に吸収しやすいという点でも、新規構築の際はFSEの導入を検討する価値は十分にあります。要件に合わせて、適切な手法を選択する際の参考にしていただければ幸いです。

4. 実際の案件で直面したGutenbergのカスタマイズ課題と具体的な解決策

実際のWeb制作の現場において、Gutenberg（ブロックエディター）を活用する際、標準機能だけではお客様の要望を満たせない場面に直面することがよくあります。コーポレートサイトの構築案件で、お客様から「特定のブロックだけ入力項目を制限してほしい」「独自のデザインを適用しやすいように独自のクラスを付与したい」といったご相談をいただくケースです。

このような場合、ブロックそのものを自作するという選択肢もありますが、開発工数が膨らみ、その後の保守も複雑になります。そこで実務では、WordPressのコア機能を拡張するアプローチをとることが多くなります。

ここでは、実案件でよく遭遇する課題と、それを解決するためのフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を用いた具体的なコードをご紹介します。

標準の画像ブロックに独自のスタイルを追加する

お客様から「ブログ記事内の画像に、必ず特定の枠線と影をつけたいが、毎回手動で設定するのは手間だ」というご要望をいただいた際の解決策です。

Gutenbergにはブロックスタイルを追加する機能が用意されており、テーマの `functions.php`（テーマの機能を追加・カスタマイズするファイル）に以下のコードを記述することで、エディター上に独自のスタイル選択ボタンを追加できます。

// functions.php に記述します
// エディターが読み込まれたタイミングで実行されるアクションフック
add_action( 'enqueue_block_editor_assets', 'ebiz_add_custom_block_style' );

function ebiz_add_custom_block_style() {
// インラインスクリプトを用いてJavaScriptでブロックスタイルを登録
$script = "
wp.blocks.registerBlockStyle( 'core/image', {
name: 'custom-shadow-border',
label: '枠線と影付き（カスタム）',
isDefault: false
} );
";

// 依存関係として 'wp-blocks' を指定し、スクリプトを追加
wp_add_inline_script( 'wp-blocks', $script );
}

このコードを適用すると、画像ブロックのスタイル設定パネルに「枠線と影付き（カスタム）」という選択肢が表示されます。これを選択すると、フロントエンド側の画像要素に `is-style-custom-shadow-border` というクラスが付与されるため、あとはテーマのCSSで装飾を行うだけです。

なぜこのアプローチを採用するのか

この書き方が推奨される理由は、WordPressの標準仕様に沿った拡張であるためです。ブロックを一から自作した場合、将来的なWordPressのメジャーアップデート時に互換性が失われるリスクが高まります。標準の画像ブロックの機能をそのまま活かしつつ、クラスの付与だけをフックで行うことで、コアのアップデートによる影響を最小限に抑えることができます。長期的な保守性を考えると、可能な限り標準ブロックを拡張する形が安全です。

よくある間違いと注意点

Gutenbergのカスタマイズにおいてやりがちなのが、無理にPHP側でブロックのHTML構造を書き換えようとしてしまうことです。`render_block` フィルター（データを加工・変換するフック）を使えば出力されるHTMLを強制的に変更できますが、エディター側の表示とフロント側の表示に差異が生まれ、お客様が混乱する原因になります。

また、複雑な入力項目を必要とする場合は、無理に標準ブロックを拡張するのではなく、カスタムブロックの作成や、Advanced Custom Fieldsを活用したアプローチに切り替える判断も必要です。

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

カスタマイズの手法を選ぶ際は、以下の基準で整理すると判断しやすくなります。

開発手法に迷ったときは、まず「標準機能の組み合わせや軽微な拡張で実現できないか」を検討し、それでも不足する場合に独自ブロックの開発へ踏み切るという順序で進めると、保守性の高いサイトを構築できます。Web制作でのブロックエディターのカスタマイズについてご相談が必要な場合は、お気軽にeBIZクリエイトまでお問い合わせください。

5. 長期的な保守を見据えたフルサイト編集の設計ポイントと注意点

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実案件に導入する際、もっとも頭を悩ませるのが納品後の保守運用です。正直に言うと、初期のFSE案件では、クライアントが誤ってサイト全体のレイアウトを崩してしまうトラブルを経験しました。

自由度が高い反面、どこでも編集できてしまうのがFSEの難しいところです。長期的な保守を見据える場合、「どこを編集可能にし、どこをロックするか」の線引きが運用成功の鍵を握ります。

ここでは、実案件で取り入れている設計ポイントをシェアします。

■ テンプレートのロックと権限の制御
実務では、ヘッダーやフッターなどの共通パーツ、あるいは重要なレイアウト部分に対してブロックのロック機能を適用します。以下のコードは、テーマの `functions.php`（テーマの機能を追加・カスタマイズするファイル）に記述し、管理者以外のユーザーがブロックをロック解除できないようにする制御例です。

/
 管理者以外のブロックロック解除を制限する

 @param bool $block_lock_status 現在のロックステータス
 @param array $block ブロック情報
 @return bool
/
function ebiz_restrict_block_lock( $block_lock_status, $block ) {
// ユーザーが管理者の場合はロック解除を許可
if ( current_user_can( 'manage_options' ) ) {
return $block_lock_status;
}
// それ以外の権限グループはロック解除不可とする
return false;
}
// フィルターフック（データを加工・変換する仕組み）で処理を割り込ませる
add_filter( 'block_editor_settings_all', function( $settings ) {
$settings['canLockBlocks'] = current_user_can( 'manage_options' );
return $settings;
});

この書き方を案件のデフォルトにしている理由は、運用担当者が意図せずレイアウトを壊してしまうリスクを最小限に抑えつつ、テキストや画像の差し替えという本来のコンテンツ更新作業に集中してもらうためです。

■ よくある間違い・やめた方がいいケース
FSEの強力な機能を活かそうとして、theme.json（テーマのスタイルやエディター設定を制御するファイル）ですべてのスタイル設定を開放してしまうのは避けたほうが無難です。ブランドカラーやタイポグラフィのルールが崩れる原因になります。ブランドガイドラインが厳格なコーポレートサイトの場合、カラーパレットやフォントサイズのカスタマイズ機能は制限し、決められたプリセットからのみ選択できるようにする設計が適しています。

■ FSEの導入基準まとめ

■ 保守性・将来性の考察
WordPressの公式見解や開発の方向性を見ると、FSEは今後さらに中心的な役割を担っていくことが予想されます。メジャーアップデートのたびに機能が拡充されているため、クラシックテーマに固執するよりも、段階的にFSEを取り入れていくのが長期的な保守の観点でも理にかなっています。

迷ったときは、「誰が、どのような頻度で、どこを更新するのか」という運用体制をベースに権限と編集範囲を設計すると整理しやすいです。正解は一つではないので、クライアントの運用スキルに合わせて調整を重ねていくことが大切です。

Web制作や保守体制の設計に関するご相談はお気軽に、eBIZクリエイトまでお問い合わせください。読者の皆様のプロジェクトが円滑に進むことを応援しています。