【動作確認済み環境】
・WordPress：6.5以上
・PHP：8.1以上
・確認日：2026年4月
・テーマ：独自テーマ（FSE対応および従来型）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

最近のWeb制作の現場において、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）を実際の案件にどう組み込むべきか、頭を悩ませている方は多いのではないでしょうか。
弊社にも「新しく立ち上げるサイトはFSEで構築するべきか、それとも従来のクラシックテーマで作るべきか」というご相談を頻繁にいただきます。

正直にお伝えすると、すべての案件をFSEに切り替える必要はありません。プロジェクトの規模やクライアントの運用体制によって、適切なアプローチは大きく変わります。

この記事では、長年の実務経験をもとに、現場で実際に使っているFSEの導入判断基準や、Gutenberg（ブロックエディター）の具体的なカスタマイズ手法をシェアします。ただ機能を解説するのではなく、保守性や将来のアップデートを見据えた「なぜその方法を選ぶのか」という意思決定の軸をお渡しできればと考えています。

■この記事でわかること
・FSE（フルサイト編集）を実案件に導入する際の明確な判断基準
・Gutenbergブロックエディターを案件ごとに最適化するカスタマイズ手法
・従来型テーマとFSEを併用した際に起きやすいトラブルとその対処法
・保守性を高める独自ブロックの具体的な開発手順
・今後のWordPressアップデートに備えたテーマ設計と運用ルールの考え方

1. 2026年の実務で使えるWordPressフルサイト編集の導入判断基準と基礎知識

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：直近のメジャーアップデート時
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「新しい案件が来たけれど、従来通りのクラシックテーマで組むべきか、それともFSE（フルサイト編集）に挑戦するべきか」

実務の中で、このような相談を制作会社の担当者様からいただくことが増えました。FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）は、公式であるhttps://wordpress.orgでも今後の基盤として推進されていますが、実際の案件に導入するには、まだ迷いが生じる部分もあるのではないでしょうか。

この記事では、実際のWeb制作現場でFSEをどう評価し、どのような基準で導入を決定しているのかを正直にシェアします。

■ FSE（フルサイト編集）の基礎知識

FSEの最大のメリットは、ヘッダーやフッター、アーカイブページといった、これまでPHPファイル（テーマファイル）を編集しなければならなかった領域まで、管理画面のブロックエディターから直接構築できる点にあります。

従来、functions.php（テーマの機能を追加・カスタマイズするファイル）や各テンプレートファイルにPHPコードを書いて制御していた部分が、フロントエンドの直感的な操作に置き換わります。これにより、コーディングの知識が浅い運用担当者でも、サイト全体のレイアウト変更を行いやすくなりました。

■ 実案件での導入判断基準

以前、あるコーポレートサイトの案件で、運用側から「キャンペーンのたびにヘッダーのナビゲーション構造や色味を自分たちで自由に変えたい」という強い要望がありました。このケースではFSEの柔軟性が活きると判断し、ブロックテーマを採用しました。

一方で、デザインの自由度が高すぎることは、運用フェーズでのリスクにもなります。FSEを導入すると、クライアントが誤ってサイト全体のレイアウトを崩してしまう可能性が高まるからです。そのため、保守契約の範囲内でどこまでサポートするのか、あらかじめ明確にしておく必要があります。

迷ったときの判断基準として、以下の表を参考にしてみてください。

長期的な保守性や将来性を考えると、WordPressのコア開発はFSEを中心に進んでいます。しかし、すべての案件をすぐにFSEに切り替える必要はありません。運用者のITリテラシーや、サイトの更新頻度、必要な機能要件を総合的に見て、プロジェクトごとに適切なアプローチを選ぶことが大切です。

2. Gutenbergブロックエディターを案件に合わせて最適化するカスタマイズ手法

実際のWeb制作案件でGutenberg（ブロックエディター）を導入する際、そのままの状態でクライアントに納品すると、思わぬトラブルを招くことがあります。

よくあるのが、用意されているすべてのブロックが使える状態になっているため、クライアントが意図しないブロックを配置してしまい、サイトのレイアウトが大きく崩れてしまうケースです。

このような事態を防ぐため、実務ではプロジェクトの要件に合わせて、エディターで使える機能を適切に制限し、最適化する作業が欠かせません。

ここでは、functions.php（テーマの機能を追加・カスタマイズするファイル）を使って、使用できるブロックを制御する方法をシェアします。

使用できるブロックを必要最小限に絞り込む

WordPressにはデフォルトで多くのブロックが用意されていますが、企業サイトなどの構築では、見出し、段落、画像、リストなど、限られたブロックのみを使用するよう設計することが一般的です。

以下のコードをfunctions.phpに記述することで、指定したブロックのみをエディター上で有効化できます。

// functions.phpに記述します
// 'allowed_block_types_all' はブロック一覧を制御するフィルターフック（データを加工・変換する仕組み）です
add_filter( 'allowed_block_types_all', 'custom_allowed_block_types', 10, 2 );

function custom_allowed_block_types( $allowed_blocks, $editor_context ) {
// 許可するブロックの配列を定義します
return array(
'core/paragraph', // 段落ブロック
'core/heading',   // 見出しブロック
'core/image',     // 画像ブロック
'core/list',      // リストブロック
'core/list-item', // リスト項目ブロック
);
}

この処理は、エディター画面が読み込まれるタイミングで実行されます。配列に記載されていないブロックは、ブロックインサーター（追加メニュー）から完全に非表示になります。

実案件での失敗談と設定の最適解

以前、ある企業サイトの案件で、レイアウト崩れを極端に恐れるあまり、使用できるブロックを3つ程度まで厳しく制限して納品したことがありました。

しかし運用開始後、クライアントから「表や動画を入れたいけれど追加できない」というご相談を頻繁にいただく結果となってしまいました。

運用者のスキルレベルや、将来的なコンテンツ拡張の可能性を十分にヒアリングできていなかったことが原因です。

現在eBIZクリエイト株式会社では、基本となるテキスト・画像系のブロックに加え、カラムブロックやグループブロックなどの汎用的なレイアウトブロックも許可した上で、パターン機能を使って安全にレイアウトを組めるよう設計する方針を基本としています。

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

ブロックの制限を行う手法について、ケース別の判断基準をまとめました。

クライアントの運用体制を考慮し、自由度と安全性のバランスをどこに設定するかが、長く使いやすいサイトを構築する鍵となります。迷った際は、まずは少し多めにブロックを許可しておき、運用テストを通じて不要なものを削っていくアプローチも有効です。

3. 従来型テーマとフルサイト編集の併用時に発生しやすいトラブルと対処法

クラシックテーマ（従来型のPHPベースのテーマ）を運用しながら、部分的にFSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）やGutenbergのブロックパターンを導入しようとする際、実案件で非常によくご相談いただくのが「表示崩れ」と「スタイルの競合」です。

少しずつ新しい仕組みに移行したいというご要望は多いのですが、両者を混在させると特有のトラブルが発生します。実務で直面した主な問題と、その具体的な対処法をシェアします。

よくあるトラブルのひとつが、クラシックテーマのCSS（style.css）と、ブロックエディターが出力するデフォルトのCSSが干渉してしまう現象です。例えば、テーマ側で余白を細かく制御しているのに、ブロック側のグローバルスタイルが上書きされてしまい、意図しないレイアウト崩れが起きるケースがあります。

この問題に対処するため、実案件ではテーマサポート機能を使って、エディター側のスタイル読み込みをコントロールします。以下のコードをfunctions.php（テーマの機能を追加・カスタマイズするファイル）に記述して調整を行うことが多いです。

// functions.phpに記述します
// テーマのセットアップ時に実行されるアクションフックを利用
add_action( 'after_setup_theme', 'ebiz_setup_block_styles' );

function ebiz_setup_block_styles() {
// ブロックのデフォルトスタイルをテーマ側でサポートする
add_theme_support( 'wp-block-styles' );

// エディター側にもフロントと同じCSSを読み込ませて差異をなくす
add_theme_support( 'editor-styles' );
add_editor_style( 'style-editor.css' ); // エディター専用のCSSファイル
}

この書き方が推奨される理由は、フロントエンド（実際のサイト表示）とバックエンド（編集画面）の見た目を一致させるためです。内部的な仕様として、WordPressはブロックごとに特有のクラスを付与しますが、クラシックテーマ側でそれらのクラスに対するスタイルが定義されていないと、編集画面と実際の公開ページで見た目が大きく変わってしまいます。

正直にお話しすると、以前は既存のstyle.cssを無理やりエディターに読み込ませていましたが、エディター固有のUI（設定パネルなど）まで崩れてしまうトラブルがありました。そのため現在では、フロント用とエディター用でCSSを適切に分離するか、theme.jsonを活用して設定を一元管理する方針に切り替えています。

また、テンプレート階層の優先順位にも注意が必要です。FSEが有効な環境では、ブロックテンプレート（HTMLファイル）が従来のPHPテンプレートよりも優先して読み込まれる仕様になっています。意図せずブロックテンプレートが読み込まれてしまい、「修正したはずのPHPファイルが反映されない」というご相談を受けることも少なくありません。

段階的な移行を検討する際、両者の併用について判断に迷った場合は、以下の表を参考にしてみてください。

保守性や将来性を考えると、WordPressの方向性としてはフルサイト編集への移行が進んでいます。しかし、現在稼働している複雑なシステム連携やカスタムフィールドを多用しているサイトを急いでFSEに完全移行することは、リスクが伴う場合もあります。

迷ったときは、「エディターの使い勝手を向上させたいのか」「サイト全体の構造をモダンにしたいのか」という目的を切り分けて考えると整理しやすいです。まずは投稿や固定ページのコンテンツ部分のみブロックエディターに最適化し、ヘッダーやフッターなどの共通部分はクラシックテーマのPHP管理を残す、というハイブリッドなアプローチも実務では有効な選択肢となります。

Web制作のご相談や、既存テーマから新しい環境への移行に関するお悩みがありましたら、お気軽にeBIZクリエイトまでご相談ください。

4. 現場のWeb制作者が実践する保守性を高める独自ブロックの開発手順

WordPressのブロックエディターが普及し、サイト全体を編集できるFSE（フルサイト編集）が主流になる中で、独自ブロックの開発は避けて通れないテーマになりました。実務においてブロックを作る手段はいくつかありますが、保守性をどこまで担保できるかがプロジェクト成功の鍵を握ります。

独自ブロックの開発には、主にReactを用いたネイティブな開発手法と、PHPベースで開発できるプラグイン（例えばAdvanced Custom Fields PROのACF Blocks機能）を利用する手法があります。

Reactを用いたネイティブ開発は、エディターの挙動を細かく制御できるメリットがあります。しかし、WordPress本体のメジャーアップデートに伴うReactコンポーネントの仕様変更に追従するための学習コストやメンテナンスコストが高くなる傾向にあります。

以前、ある企業サイトの構築案件で、すべてのカスタムブロックをネイティブのReactで開発しました。納品直後は軽快に動作していましたが、数回のWordPressアップデートを経た後、非推奨となったAPIの影響でエディター画面が真っ白になるというトラブルが発生しました。それ以来、将来のアップデートに対するリスクを最小限に抑えるため、案件の性質に合わせて開発手法を分けるようにしています。

現在、多くの受託制作の現場ではACF Blocksを利用したPHPベースの開発をデフォルトとして採用しています。その理由は、WordPressのコアアップデートの影響を直接受けにくく、既存のPHPやHTMLの知識をそのまま活かせるため、数年後に別の制作者が保守を引き継ぐ際にもコードの意図が伝わりやすいからです。

ACF Blocksを利用して独自ブロックを登録する場合、functions.php（テーマの機能を追加・カスタマイズするファイル）に以下のようなコードを記述します。

// functions.php に記述
// 'init'アクションフック（WordPressの初期化タイミング）でブロックを登録します
add_action( 'init', 'register_custom_block_type' );

function register_custom_block_type() {
// ACFの関数が存在するか確認
if ( function_exists( 'register_block_type' ) ) {

// block.json を使用してブロックを登録
// get_template_directory() は親テーマのディレクトリパスを取得します
register_block_type( get_template_directory() . '/blocks/custom-banner' );

}
}

このコードでは、ブロックの定義を `block.json` という設定ファイルに分離しています。以前はPHPファイル内にすべての設定を記述していましたが、現在はこの手法が推奨されています。設定ファイルに情報をまとめることで、サーバー側とエディター側の両方でブロックの情報を効率的に読み込むことができるためです。

独自ブロックを開発する際にやりがちな間違いとして、特定のページでしか使わないようなニッチなデザインまで個別のブロックとして開発してしまうことが挙げられます。ブロックの種類が増えすぎると、クライアントが記事を更新する際にどのブロックを使えばよいか迷ってしまい、結果的にエディターの使い勝手が低下します。

そのような場合は、標準の「グループブロック」に対してカスタムCSSクラスを付与する運用にするか、あらかじめレイアウトを組んだ「ブロックパターン」として登録する方が、保守性と利便性の両面でメリットがあります。

長期的な視点で考えると、WordPress本体はブロックエディターを中心に機能拡張を続けています。コアの仕様変更に振り回されないためには、「本当に独自ブロックを作る必要があるのか」を立ち止まって考えることが大切です。標準のブロックやパターンで対応できるものは極力それに任せ、どうしても専用の入力UIが必要な部分にだけ独自ブロックを開発するという判断基準を持つと、破綻しにくいサイト設計が可能になります。

5. 今後のWordPressアップデートを見据えたテーマ設計と運用ルールの構築

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）が本格的に普及する中で、実務において最も頭を悩ませるのが「アップデートに強いテーマ設計」と「クライアントへの引き継ぎ方」です。

WordPressのコアアップデートは日々進んでおり、以前のようにテンプレートファイル（PHP）にガチガチにレイアウトを直書きするアプローチは、将来的なメンテナンスコストを跳ね上げる要因になります。

長期的な運用を見据えた場合、デザインの基礎となるカラーパレットやタイポグラフィ、余白のルールは、極力 `theme.json` に集約することをおすすめします。これにより、WordPress側が提供するUIと連携しやすくなり、エディター上での予期せぬレイアウト崩れを防ぐことができます。

以前、あるコーポレートサイトの案件で、クラシックテーマ（従来のPHPベースのテーマ）からFSE対応テーマへのリニューアルを行いました。当初はすべてのブロックのスタイルを独自CSSで上書きしようと試みましたが、WordPressのメジャーアップデートのたびにCSSのクラス名やHTML構造が微妙に変わり、保守作業が追いつかなくなる事態に直面しました。その経験から、現在は「コアのブロック機能を最大限活かし、足りない部分のみを `theme.json` とカスタムブロックで補う」という設計をデフォルトにしています。

ここで、FSEを利用したフルブロックベースのテーマ設計における、向いているケースと向いていないケースを整理しておきます。

また、運用ルールの構築においては「クライアントにどこまで触らせるか」の線引きが非常に重要です。ブロックのロック機能（特定のブロックの移動や削除を制限する機能）を活用し、触ってほしくないヘッダーやフッター、あるいはレイアウトの枠組みとなるコンテナブロックは固定化しておきます。これにより、運用者が誤ってサイトの構造を壊してしまうリスクを大幅に減らすことができます。

迷ったときは、「システムを制限で縛る」のではなく、「安全に編集できる枠組みを用意する」という視点で設計すると整理しやすいです。WordPressの進化の方向性は、明確にユーザー主導のコンテンツ作成に向かっています。その波に逆らわず、コアの機能を活かす設計こそが、結果的に長期的な保守性を高めることにつながります。