フルサイト編集（FSE）は実務で使える？2026年のWordPressコーディング新常識
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
“`
コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
—
なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
—
実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
—
制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
—
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
—
保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。
そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。
—
まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。
1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す
2. 不要なブロックは `allowed_block_types_all` フックで非表示にする
3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする
正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。
Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。
5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。
実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。
しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。
このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。
実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。
1.
要件定義での「運用制限」の合意
クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。
2.
デザインの自由度と構築工数の検証
FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。
3.
保守運用のロードマップ策定
数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。
FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。
—
Web制作のご相談はお気軽にeBIZクリエイトまで
福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。
[お問い合わせはこちら](https://ebiz-create.co.jp/contact/)
ここに紹介文が入ります。
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
<h4>コードの書き方とタイミング</h4>
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
---
<h3>なぜこの制御が必要なのか（内部仕様とメリット）</h3>
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
---
<h3>実案件での失敗から学んだ「守り」の設計</h3>
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
---
<h3>制限をかける際のはまりポイントと注意点</h3>
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
php
// 実務でのテーマ選定ロジック（イメージ）
if ( $client_needs_layout_change === true ) {
// 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合
$selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討
} else {
// デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合
$selected_theme_type = ‘classic’; // クラシックテーマが堅実
}
<h3>なぜその基準で判断するのか（内部仕様の違い）</h3>
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。
対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。
<h3>実案件でのエピソード</h3>
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。
FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。
<h3>よくある間違い・ハマりポイント</h3>
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。
FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（フルサイト編集）</strong> | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合<br>・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合<br>・複雑な条件分岐やカスタムクエリを多用する大規模サイト |
| <strong>クラシックテーマ</strong> | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合<br>・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
| 項目 | 向いているケース | 向いていないケース |
|---|
| サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 |
| デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト |
| 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 |
php
‘ヒーローセクション（メインビジュアル）’,
‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’,
‘content’ => ‘
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
“`
コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
—
なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
—
実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
—
制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
—
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
—
保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。
そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。
—
まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。
1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す
2. 不要なブロックは `allowed_block_types_all` フックで非表示にする
3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする
正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。
Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。
5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。
実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。
しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。
このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。
実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。
1.
要件定義での「運用制限」の合意
クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。
2.
デザインの自由度と構築工数の検証
FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。
3.
保守運用のロードマップ策定
数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。
FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。
—
Web制作のご相談はお気軽にeBIZクリエイトまで
福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。
[お問い合わせはこちら](https://ebiz-create.co.jp/contact/)
サイトのメインコピー
ここに紹介文が入ります。
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
<h4>コードの書き方とタイミング</h4>
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
---
<h3>なぜこの制御が必要なのか（内部仕様とメリット）</h3>
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
---
<h3>実案件での失敗から学んだ「守り」の設計</h3>
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
---
<h3>制限をかける際のはまりポイントと注意点</h3>
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
php
// 実務でのテーマ選定ロジック（イメージ）
if ( $client_needs_layout_change === true ) {
// 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合
$selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討
} else {
// デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合
$selected_theme_type = ‘classic’; // クラシックテーマが堅実
}
<h3>なぜその基準で判断するのか（内部仕様の違い）</h3>
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。
対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。
<h3>実案件でのエピソード</h3>
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。
FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。
<h3>よくある間違い・ハマりポイント</h3>
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。
FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（フルサイト編集）</strong> | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合<br>・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合<br>・複雑な条件分岐やカスタムクエリを多用する大規模サイト |
| <strong>クラシックテーマ</strong> | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合<br>・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
| 項目 | 向いているケース | 向いていないケース |
|---|
| サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 |
| デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト |
| 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 |
php
‘ヒーローセクション（メインビジュアル）’,
‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’,
‘content’ => ‘
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
“`
コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
—
なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
—
実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
—
制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
—
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
—
保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。
そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。
—
まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。
1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す
2. 不要なブロックは `allowed_block_types_all` フックで非表示にする
3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする
正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。
Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。
5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。
実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。
しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。
このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。
実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。
1.
要件定義での「運用制限」の合意
クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。
2.
デザインの自由度と構築工数の検証
FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。
3.
保守運用のロードマップ策定
数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。
FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。
—
Web制作のご相談はお気軽にeBIZクリエイトまで
福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。
[お問い合わせはこちら](https://ebiz-create.co.jp/contact/)
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
<h4>コードの書き方とタイミング</h4>
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
---
<h3>なぜこの制御が必要なのか（内部仕様とメリット）</h3>
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
---
<h3>実案件での失敗から学んだ「守り」の設計</h3>
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
---
<h3>制限をかける際のはまりポイントと注意点</h3>
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
php
// 実務でのテーマ選定ロジック（イメージ）
if ( $client_needs_layout_change === true ) {
// 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合
$selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討
} else {
// デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合
$selected_theme_type = ‘classic’; // クラシックテーマが堅実
}
<h3>なぜその基準で判断するのか（内部仕様の違い）</h3>
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。
対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。
<h3>実案件でのエピソード</h3>
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。
FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。
<h3>よくある間違い・ハマりポイント</h3>
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。
FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（フルサイト編集）</strong> | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合<br>・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合<br>・複雑な条件分岐やカスタムクエリを多用する大規模サイト |
| <strong>クラシックテーマ</strong> | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合<br>・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
| 項目 | 向いているケース | 向いていないケース |
|---|
| サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 |
| デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト |
| 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 |
php
‘ヒーローセクション（メインビジュアル）’,
‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’,
‘content’ => ‘
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
“`
コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
—
なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
—
実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
—
制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
—
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
—
保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。
そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。
—
まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。
1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す
2. 不要なブロックは `allowed_block_types_all` フックで非表示にする
3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする
正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。
Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。
5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。
実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。
しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。
このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。
実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。
1.
要件定義での「運用制限」の合意
クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。
2.
デザインの自由度と構築工数の検証
FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。
3.
保守運用のロードマップ策定
数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。
FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。
—
Web制作のご相談はお気軽にeBIZクリエイトまで
福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。
[お問い合わせはこちら](https://ebiz-create.co.jp/contact/)
ここに紹介文が入ります。
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
php
// 実務でのテーマ選定ロジック（イメージ）
if ( $client_needs_layout_change === true ) {
// 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合
$selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討
} else {
// デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合
$selected_theme_type = ‘classic’; // クラシックテーマが堅実
}
php
‘ヒーローセクション（メインビジュアル）’,
‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’,
‘content’ => ‘
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
<h4>コードの書き方とタイミング</h4>
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
---
<h3>なぜこの制御が必要なのか（内部仕様とメリット）</h3>
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
---
<h3>実案件での失敗から学んだ「守り」の設計</h3>
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
---
<h3>制限をかける際のはまりポイントと注意点</h3>
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
php
// 実務でのテーマ選定ロジック（イメージ）
if ( $client_needs_layout_change === true ) {
// 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合
$selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討
} else {
// デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合
$selected_theme_type = ‘classic’; // クラシックテーマが堅実
}
<h3>なぜその基準で判断するのか（内部仕様の違い）</h3>
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。
対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。
<h3>実案件でのエピソード</h3>
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。
FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。
<h3>よくある間違い・ハマりポイント</h3>
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。
FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（フルサイト編集）</strong> | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合<br>・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合<br>・複雑な条件分岐やカスタムクエリを多用する大規模サイト |
| <strong>クラシックテーマ</strong> | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合<br>・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
| 項目 | 向いているケース | 向いていないケース |
|---|
| サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 |
| デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト |
| 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 |
php
‘ヒーローセクション（メインビジュアル）’,
‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’,
‘content’ => ‘
‘,
‘categories’ => array( ‘header’ ),
)
);
}
add_action( ‘init’, ‘my_theme_register_block_patterns’ );
このコードを実行すると、管理画面のブロック挿入ツール内に、あらかじめ構築されたデザインパターンが表示されるようになります。
このように、HTMLに該当するブロックの構造をシリアライズされたテキストとして登録しておくことで、クライアント自身がエディター上でいつでもお気に入りのレイアウトを安全に呼び出せるようになります。
---
<h3>なぜこのアプローチを採用するのか</h3>
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。
ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。
1. <strong>一貫性のあるCSS管理</strong>
個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。
2. <strong>デザインシステムと同期した直感的な編集</strong>
あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。
---
<h3>実案件でのエピソードと失敗談</h3>
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。
しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。
この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。
---
<h3>やめた方がいいケースと注意点</h3>
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。
複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。
その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。
---
<h3>向いているケース・向いていないケースまとめ</h3>
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>サイトの要件</strong> | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト |
| <strong>デザイン仕様</strong> | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン |
| <strong>運用の体制</strong> | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 |
php
post->post_type ) {
return array(
‘core/paragraph’, // 段落
‘core/heading’, // 見出し
‘core/image’, // 画像
‘core/list’, // リスト
);
}
// それ以外（固定ページなど）は制限しない、または別の定義を返す
return $allowed_block_types;
}
// allowed_block_types_all フックに登録し、エディター読み込み時に実行する
add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 );
“`
コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。
`allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。
—
なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。
内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。
—
実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。
それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。
—
制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。
また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。
—
向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース |
|---|
| ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 |
| テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ |
—
保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。
そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。
—
まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。
1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す
2. 不要なブロックは `allowed_block_types_all` フックで非表示にする
3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする
正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。
Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。
5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：2024年11月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。
フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。
実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。
| 項目 | 向いているケース | 向いていないケース |
|---|
| <strong>FSE（ブロックテーマ）</strong> | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合<br>・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合<br>・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 |
| <strong>クラシックテーマ</strong> | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合<br>・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。
しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。
このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。
1.
クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。
2.
FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。
3.
数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。
FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。
—
福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。
[お問い合わせはこちら](https://ebiz-create.co.jp/contact/)
