【動作確認済み環境】 ・WordPress：6.5 ・PHP：8.2 ・確認日：2024年5月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 最近のWeb制作案件で、フルサイト編集（FSE）で構築するべきか、それとも従来のクラシックテーマで進めるべきか、判断に迷う場面が増えてきました。 実際にご相談をいただく中でも、ブロックエディターの活用方法や独自のカスタマイズの進め方について、現場での対応に悩む声を多くお聞きします。私自身、日々の案件で実装や検証を重ねる中で、新しい仕組みのメリットを感じる一方で、運用時の思わぬ課題に直面し、方針を軌道修正した経験も少なくありません。 この記事では、実際の案件で得た経験をもとに、フルサイト編集とGutenbergを実務でどのように活用していくのか、具体的な判断基準と実践的な手法をシェアします。現場での迷いを少しでも減らし、今後の制作方針を決めるためのひとつの指標としてお役立ていただければ嬉しいです。 ■ この記事でわかること ・案件の状況に合わせたフルサイト編集とクラシックテーマの選び方 ・Gutenbergを活用した効率的なページ構築の進め方 ・実務で直面しやすい課題とその具体的な解決手段 ・運用保守の負担を減らすブロックパターンの活用法 ・長期的な運用を見据えた持続可能なテーマ構築の注意点

1. フルサイト編集とクラシックテーマの選び方：実案件における具体的な判断基準

【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：本記事執筆時点 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「フルサイト編集（FSE）、実際の案件でどこまで使えるんだろう？」 そんな疑問を抱えながら、従来のクラシックテーマで制作を続けている方は少なくないのではないでしょうか。私自身、実案件でFSEを導入するかどうか、かなり慎重に検討を重ねてきました。 この記事では、FSEとクラシックテーマのどちらを選ぶべきか、実務での具体的な判断基準をシェアします。 FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）が登場してからしばらく経ちますが、すべての案件にFSEが適しているわけではありません。案件の性質やクライアントの運用体制によって、クラシックテーマの方が保守性が高いケースもまだまだ存在します。

実案件での判断基準

FSEを導入するかどうかの最大の分岐点は、「クライアントがどこまで自由にサイトを編集したいか」と「デザインの厳密さ」にあります。 FSEはヘッダーやフッター、テンプレートまでブロックエディターで直感的に編集できるため、運用者が頻繁にレイアウトを変更したい、キャンペーンごとに特設ページのようなデザインを作りたいという要望には非常にマッチします。 一方で、ピクセルパーフェクトなデザイン再現が求められる場合や、意図しないレイアウト崩れを防ぐために編集権限を厳密に制御したい場合は、クラシックテーマ（PHPベースのテンプレート）の方が手堅いです。

なぜ判断を分けるのか

FSEの内部仕様として、テンプレート自体がHTML（ブロックマークアップ）で保存・管理されます。これにより、コードを書かずにサイト構造を変更できる柔軟性が生まれる反面、運用者が誤って重要なブロックを削除したり、想定外の設定に変更してしまうリスクも伴います。 クラシックテーマであれば、`header.php`や`footer.php`といったファイルにPHPやHTMLを直接記述するため、管理画面からの不用意な変更を物理的に防ぐことが可能です。この「自由度」と「堅牢性」のトレードオフをどう評価するかが、実務での選定の鍵になります。

実案件での失敗談と気づき

以前、更新性を高める目的でクライアントにFSEベースのテーマを納品したことがあります。納品時は喜ばれたのですが、数ヶ月後に「サイトのヘッダーが消えてしまった」と連絡がありました。原因は、運用担当者様が誤ってテンプレートエディターを開き、ヘッダーブロックを削除して保存してしまったことでした。 この経験から、FSEを導入する場合は、`theme.json`（FSEのデザインやブロックの設定を制御するファイル）で特定のブロックをロックしたり、編集権限を適切に設定するなどの防御策が必須だと痛感しました。

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

| 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | FSE（フルサイト編集） | 運用者が柔軟にレイアウトを変更したい場合、ノーコードでの運用を前提とする場合 | 厳密なデザイン管理が必要な場合、運用者の誤操作を防ぎたい場合 | | クラシックテーマ | デザインの再現性を最優先する場合、複雑なPHP処理をテンプレートに組み込む場合 | 運用側でヘッダーやフッターの構成まで自由に変えたい場合 | 迷ったときは、「納品後、誰がどのようにサイトを触るのか」という運用フェーズを具体的に想像すると、自然と答えが見えてきます。長期的な保守性を見据えて、プロジェクトに最適な手法を選択していただければと思います。 Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。

2. Gutenbergブロックを活用した効率的なページ構築の実践的な手法

Gutenberg（ブロックエディター）が導入されてから数年が経過し、実務でのサイト構築手法も大きく変化しました。以前は固定ページにページビルダープラグインを導入したり、カスタムフィールドを大量に用意したりしていましたが、現在ではGutenbergの標準ブロックと独自のカスタムブロックを組み合わせて構築する手法が主流になっています。 ここでは、実際の案件でどのようにGutenbergを活用してページを構築しているのか、具体的な手法とコードをシェアします。

標準ブロックとカスタムブロックの使い分け

実務において、すべてのデザインを独自のブロックで開発する必要はありません。見出し、段落、画像、リストといった基本的な要素はWordPressの標準ブロック（コアブロック）を使用し、企業の沿革タイムラインや独自の製品スペック表など、標準ブロックでは再現が難しい特定のデザインパーツのみをカスタムブロックとして開発します。 以下は、テーマの `functions.php`（テーマの機能を追加・カスタマイズするファイル）に記述して、特定のカスタムブロックカテゴリを追加するコード例です。 “`php // functions.php に記述します // 新しいブロックカテゴリを追加するフック（WordPressの処理に割り込む仕組み） add_filter( ‘block_categories_all’, ‘ebiz_custom_block_category’, 10, 2 ); function ebiz_custom_block_category( $categories, $post ) { // カスタムカテゴリを配列の先頭に追加して見つけやすくする return array_merge( array( array( ‘slug’ => ‘ebiz-blocks’, // カテゴリのスラッグ ‘title’ => ‘専用カスタムブロック’, // エディター上に表示される名前 ‘icon’ => ‘wordpress’, // アイコン ), ), $categories ); } “`

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

標準ブロックを最大限に活用する理由は、WordPressのアップデートに対する耐性を高めるためです。WordPress本体のアップデートに伴い、標準ブロックは常に最適化され、アクセシビリティやパフォーマンスの向上が図られます。独自のブロックを作りすぎると、将来的なアップデートの際にメンテナンスコストが膨大になるリスクがあります。

実案件での運用エピソード

以前、コーポレートサイトの案件で、ページ内のすべてのセクションをカスタムブロックでガチガチに固めて納品したことがありました。しかし、数ヶ月後にお客様から「少しだけレイアウトを変えたい」とご要望をいただいた際、お客様自身で変更を加えることができず、結果的に保守費用がかさんでしまうという課題が発生しました。 その経験から、現在では「枠組み（グループブロックやカラムブロック）」は標準機能を使い、その中に入れる「特殊なコンテンツ」のみを専用ブロックにするという設計をデフォルトにしています。これにより、お客様の自由度とデザインの崩れにくさを両立できるようになりました。

よくあるハマりポイント

Gutenbergを活用する際によく見かけるのが、不要な標準ブロックまでエディター上に表示したままにしてしまうことです。多機能すぎるエディターは、運用担当者を混乱させる原因になります。`allowed_block_types_all` というフィルターフック（データを加工・変換する仕組み）を使用して、案件で使用しないブロック（例えば、詩ブロックやタグクラウドブロックなど）は非表示に設定しておくのが実務的な配慮です。

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

| 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | 標準ブロック主体の構築 | お客様が頻繁にテキストや画像を更新する場合 | ピクセルパーフェクトな固定デザインが求められる場合 | | フルカスタムブロック構築 | 独自の複雑な計算やAPI連携を伴うUIが必要な場合 | 予算と納期が限られている小規模案件の場合 |

保守性と将来性を見据えた判断

Gutenbergのブロック構造は、Reactベースのモダンな技術で作られています。今後のWordPressの方向性（FSE：フルサイト編集への移行）を考えると、クラシックエディターに依存する設計から脱却し、ブロックベースの構築手法に慣れておくことは長期的な保守において非常に重要です。 運用フェーズでお客様がどこまで編集したいのかをヒアリングし、それに合わせて「標準ブロック」「カスタムブロックスタイル」「独自ブロック」の3つを適切に組み合わせる設計が、これからのWeb制作における一つの基準になります。迷ったときは、まず標準の「グループブロック」で要件を満たせないか検討することをおすすめします。

3. 実務で直面しやすいフルサイト編集の課題とカスタマイズによる解決手順

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実際の案件に導入すると、従来のクラシックテーマとは異なる特有の壁にぶつかる場面があります。特に企業サイトの構築において、クライアントに管理画面を引き渡す際に課題となりやすいのが、「どこまで編集を許可するか」という点です。 ここでは、実案件でよくご相談いただく課題と、その具体的な解決策をシェアします。 よくある課題として、ヘッダーやフッターなどの共通パーツまでクライアントが誤って編集・削除してしまうリスクが挙げられます。FSEは直感的に操作できる反面、レイアウトの根幹に関わる部分まで簡単に変更できてしまうため、運用フェーズでレイアウト崩れによるお問い合わせをいただくケースがありました。 この問題を解決するためには、theme.json（テーマの基本設定やスタイルを定義するファイル）を活用して、編集権限を適切にコントロールする手法が有効です。 以下のコードは、theme.json内で特定のブロック（ここではナビゲーションブロックとサイトロゴ）の編集を制限する具体的な記述例です。 “`json { “version”: 2, “settings”: { “blocks”: { “core/navigation”: { “color”: { “text”: false, “background”: false }, “typography”: { “customFontSize”: false } }, “core/site-logo”: { “spacing”: { “margin”: false, “padding”: false } } } } } “` この設定を行うことで、ナビゲーションの色やフォントサイズ、ロゴの余白といったデザインの核となる設定項目をエディター上から非表示にできます。これにより、クライアントは用意されたデザインの範囲内で安全にコンテンツの更新作業に集中できるようになります。 なぜこの手法を採用するのかというと、PHPやCSSで強制的に上書きするのではなく、WordPressの標準的な仕様であるtheme.jsonに沿って制御することで、将来的なメジャーアップデート時にも影響を受けにくく、保守性が高まるからです。 また、もう一つの課題として、意図しないカスタムカラーやカスタムフォントサイズが使われてしまい、ブランドガイドラインから逸脱してしまうケースがあります。これもtheme.jsonでカラーパレットやフォントサイズを厳格に定義することで防ぐことが可能です。 | 制御したい内容 | 向いているケース | 向いていないケース | |——|—————-|——————| | theme.jsonでの権限制限 | 企業サイトやメディアなど、ブランドイメージを厳格に保ちたい場合 | 個人ブログなど、運営者が自由にデザインをカスタマイズしたい場合 | | ブロックのロック機能（UI上からのロック） | ページ内の特定のセクションだけ一時的に編集を防ぎたい場合 | サイト全体の共通パーツを永続的に保護したい場合 | 実務においてFSEを採用する際は、すべての機能を開放するのではなく、「運用者が迷わず更新できる適度な制限」を設けることが、長期的なサイト運用を成功させるポイントとなります。クライアントのITリテラシーや運用体制に合わせて、制限の度合いを細かく調整していく設計を心がけると整理しやすいです。

4. 運用保守性を高めるブロックパターンと再利用ブロックの効果的な活用方法

フルサイト編集（FSE）環境での運用フェーズに入ると、お客様から「同じようなレイアウトを別のページでも使いたい」というご要望をいただく場面が非常に多くなります。ここで重要になるのが、ブロックパターンと再利用ブロック（現在は「同期パターン」とも呼ばれます）の使い分けです。 この2つは見た目こそ似ていますが、内部的な動作や保守の考え方が大きく異なります。実務でこの判断を誤ると、後々の修正対応で予期せぬトラブルにつながるため、運用を見据えた設計が必要です。 まずは、それぞれの特徴を整理します。 ブロックパターンは、あらかじめ組み上げたブロックの構成をテンプレートとして呼び出す機能です。呼び出した後は独立したブロックとして扱われるため、ページごとにテキストや画像を自由に変更できます。 一方の再利用ブロック（同期パターン）は、特定のブロック群を複数のページで共有する仕組みです。あるページで再利用ブロックの内容を修正すると、そのブロックが配置されているすべてのページに自動で変更が反映されます。 以前、店舗案内のセクションをすべてのページで再利用ブロックとして設定して納品したことがありました。しかし、後日お客様から「特定の1ページだけ、営業時間の表記を少し変えたい」とご相談を受けた際、そのまま修正すると全ページに反映されてしまうため、一度同期を解除してから修正するという手間が発生してしまいました。 この経験から、現在私たちの案件では、以下の基準で使い分けるようにしています。 | 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | ブロックパターン | 構成は同じだが、ページごとにテキストや画像を変えたい場合 | 全ページで全く同じ内容を表示し、一括で修正したい場合 | | 再利用ブロック（同期） | バナーや全社共通の注意事項など、常に同じ内容を保つ必要がある場合 | ページごとに少しだけ内容をカスタマイズしたい場合 | 実務において、よく使うレイアウトを独自のブロックパターンとして登録しておくと、お客様の運用ハードルが大きく下がります。テーマの機能を追加・カスタマイズするファイルである`functions.php`に以下のコードを記述することで、独自のパターンを登録できます。 “`php / カスタムブロックパターンの登録 記述場所: functions.php 実行タイミング: initフック（WordPressの初期化時） / function my_custom_block_pattern() { // パターンカテゴリーの登録 register_block_pattern_category( ‘my-custom-patterns’, array( ‘label’ => ‘オリジナルパターン’ ) ); // ブロックパターンの登録 register_block_pattern( ‘my-theme/cta-pattern’, array( ‘title’ => ‘お問い合わせCTA’, ‘categories’ => array( ‘my-custom-patterns’ ), ‘description’ => ‘記事下部に配置するお問い合わせ用のセクションです。’, // エディターからコピーしたブロックのHTMLをエスケープして記述します ‘content’ => ‘

‘, ) ); } add_action( ‘init’, ‘my_custom_block_pattern’ ); “` この書き方が推奨される理由は、テーマ内にパターンをコードとして持たせることで、誤って管理画面から削除されてしまうリスクを防げるためです。データベースに依存せず、バージョン管理システム（Gitなど）で構成を管理できる点も、長期的な保守を考えると大きなメリットとなります。 運用保守性を高めるためには、「どこまでをお客様が自由に変更できるようにするか」を事前に設計し、適切な形で機能を提供することが重要です。迷ったときは、将来的に一括修正が発生しそうか、それとも個別カスタマイズが必要になるかを基準に整理すると、判断しやすくなります。

5. 将来のアップデートを見据えた持続可能なテーマ構築に向けた注意点

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用したテーマ構築において、実務で特に意識しているのが「持続可能性」です。WordPress本体のアップデート頻度は高く、Gutenberg（ブロックエディター）の仕様も日々進化しています。そのため、現在動いているコードが将来的にレガシー化するリスクを常に考慮する必要があります。 実際の案件でも、「アップデートしたらデザインが崩れた」というご相談をいただくことが少なくありません。これを防ぐために、独自ブロックを過剰に作り込むことは避けるようにしています。標準ブロックの組み合わせで実現できるレイアウトであれば、あえてカスタムブロック（独自の機能を持つブロック）を開発せず、ブロックスタイルやパターン（ブロックの組み合わせテンプレート）を活用する方が、将来的なメンテナンスコストを抑えることができます。 また、`theme.json`（FSEテーマのスタイルや設定を一元管理するファイル）の記述も重要です。このファイルでカラーパレットやタイポグラフィのルールをしっかり定義しておくと、本体アップデート時の影響を受けにくくなります。 | 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | 標準ブロックの拡張 | 長期的な保守を前提とする一般的なコーポレートサイト | 複雑なアニメーションや特殊なUIが必須のキャンペーンサイト | | カスタムブロック開発 | 独自の業務システムと連携するような特殊な要件 | 標準機能で代替可能なシンプルなレイアウト | 迷ったときは、「WordPressのコア（本体）が持つ標準機能にどれだけ乗っかれるか」を基準に設計を考えるようにしています。標準機能に依存する割合が高いほど、将来のアップデートに強いテーマになります。 Web制作のご相談はお気軽にeBIZクリエイトまで。