【動作確認済み環境】 ・WordPress：6.8 ・PHP：8.2 ・確認日：2026年3月 ・テーマ：Twenty Twenty-Four ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「フルサイト編集（FSE）は実務でどこまで使えるのか？」 最近、同業者や制作会社の担当者からこのような相談を受けることが増えました。実際の案件でも、従来のクラシックテーマからブロックテーマへの移行を検討する場面が多くなっています。ただ、Gutenbergでの意図しないレイアウト崩れや、独自のスタイル追加など、現場レベルでクリアしなければならない課題も少なくありません。この記事では、実案件での検証を通じて得た、フルサイト編集とGutenbergを実務で安全に運用するための判断基準やカスタマイズの手法をシェアします。導入や設計に迷っている方の参考になれば幸いです。 この記事でわかること ・実務で使えるブロックテーマ構築の具体的な手順がわかります ・Gutenbergに独自のスタイルを安全に追加する手法がわかります ・クラシックテーマからフルサイト編集へ移行する際の判断基準がわかります ・実案件で起きやすいレイアウト崩れを防ぐCSS設計の考え方がわかります ・保守性と運用効率を高めるブロックパターンの活用事例がわかります

1. フルサイト編集の基本から実務で使えるブロックテーマ構築の手順

【動作確認済み環境】 ・WordPress：6.4.3 ・PHP：8.1.22 ・確認日：2024年3月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「フルサイト編集（FSE）、そろそろ実案件で導入すべきかな…」 そんなご相談を、同業の制作者やWeb担当者の方からよくいただきます。ブロックエディターが登場して数年、いよいよサイト全体をブロックで構築する時代が本格化してきました。ただ、クラシックテーマに慣れ親しんだ私たちからすると、FSEの概念やテーマ構築の手順は少し戸惑う部分もありますよね。 この記事では、FSEの基本構造から、実際の案件で使えるブロックテーマ構築のステップまで、実体験を交えながら解説していきます。 ・FSEの基本的な仕組みとクラシックテーマとの違い ・実務でブロックテーマを構築する際の具体的な手順 ・FSEの導入を検討すべき判断基準 そもそもフルサイト編集（FSE）とは、ヘッダーからフッターまで、サイトのすべての部分をブロックエディターで構築・管理できる仕組みのことです。従来のクラシックテーマでは、`header.php`や`footer.php`といったPHPファイルでレイアウトを制御していましたが、FSE対応のブロックテーマでは、主にHTMLファイル（ブロックマークアップ）と`theme.json`（テーマの設定ファイル）で構成されます。 実務でブロックテーマを構築する際、うちのチームでは以下のような手順を基本にしています。 1. `theme.json`での基本設定 まずは`theme.json`で、サイト全体のカラーパレット、タイポグラフィ、レイアウトの基本幅などを定義します。これが従来の`style.css`の役割の大部分を担います。ここをしっかり作り込むことで、クライアントが運用する際のデザインのブレを防ぐことができます。 2. テンプレートパーツの作成 次に、ヘッダーやフッターなど、複数ページで使い回す部分を「テンプレートパーツ」として作成します。ブロックエディター上で組み上げていくこともできますし、直接HTMLファイルとして記述することも可能です。 3. ページテンプレートの構築 最後に、トップページや個別記事、アーカイブページなどのテンプレートを作成します。これもすべてブロックで構成するため、PHPの知識がなくても直感的にレイアウトを組むことができます。 正直に言うと、最初は「全部ブロックで組むなんて面倒じゃないか？」と思っていました。しかし、一度`theme.json`の設定やブロックパターンの活用に慣れてしまうと、コーディングの記述量が圧倒的に減り、運用時の修正もエディター上で完結するため、結果的に保守性が高まることに気づきました。 ただし、すべての案件でFSEが適しているわけではありません。

長期的なWordPressの方向性を考えると、ブロックエディター中心の設計に進んでいくことは間違いありません。既存のクラシックテーマを無理に乗り換える必要はありませんが、新規案件では少しずつFSEの要素を取り入れていくことをおすすめします。迷ったときは、「クライアントがどこまで自由に編集したいか」を基準に選定すると整理しやすいです。 Web制作に関する技術的なご相談や、ブロックテーマの導入を検討されている方は、お気軽にeBIZクリエイトまでお問い合わせください。

2. Gutenbergブロックの独自スタイルを追加する現場のカスタマイズ手法

実際の案件で、クライアントから「見出しブロックのデザインを、サイト独自の装飾から選べるようにしてほしい」というご相談をいただくケースがよくあります。かつてのクラシックエディター時代は、独自のクラスを手動で入力していただく運用が主流でした。しかし、ブロックエディターであるGutenbergが主流となった現在では、エディターの右側パネルからワンクリックでスタイルを切り替えられるように設定するのが現場での標準的なアプローチとなっています。 ここでは、実務で頻繁に使用する「ブロックスタイルの追加」について解説します。 まず、テーマの機能を追加・カスタマイズするファイルであるfunctions.phpに以下のコードを記述します。これにより、Gutenbergエディター内に独自のスタイル選択ボタンを追加することができます。

この処理を行う理由は、エディターの操作性を向上させ、HTMLやCSSの知識がない運用担当者でも直感的にデザインを適用できるようにするためです。内部的には、選択したスタイルの`name`属性に基づいて、フロント側のHTMLに`is-style-custom-underline`というクラスが自動的に付与されます。あとは、テーマのCSSファイルでそのクラスに対して装飾を定義するだけで完結します。 正直に申し上げると、Gutenbergが登場した直後の案件では、エディター側の設定を行わず、無理やりCSSの疑似要素などで元のブロックデザインを上書きしてしまう手法をとっていました。しかし、その方法では「特定のページだけデザインを変えたい」という運用上の要望に応えることが難しくなり、後から保守作業で苦労した経験があります。そのため、現在ではこの`register_block_style`を活用した手法を案件のデフォルトとしています。 ただし、すべてのブロックに大量のカスタムスタイルを追加すると、逆にエディター画面が複雑になり、運用担当者が迷ってしまう原因にもなります。 長期的な保守性を考えると、GutenbergのアップデートによってコアブロックのHTML構造が変化する可能性もゼロではありません。しかし、クラス名を付与するこの手法であれば、HTML構造に依存しすぎず、CSSの調整のみで対応できるため、将来的なメンテナンスコストを低く抑えることができます。迷ったときは、「運用担当者が直感的に選べるかどうか」を判断の軸にすると、管理しやすいサイト設計につながります。

3. 既存のクラシックテーマからフルサイト編集へ安全に移行する判断基準

クラシックテーマで構築された既存サイトを、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの機能）対応テーマへ移行すべきかどうか。実際の案件でも、この相談を受けることが非常に増えています。 結論から言うと、すべてのサイトが今すぐFSEに移行する必要はありません。FSEは強力な機能ですが、サイトの規模や運用体制によって、移行によるメリットよりも学習コストや改修コストが上回るケースがあるからです。 ここでは、実案件で私たちがお客様に提案する際の「判断基準」をシェアします。迷ったときは、以下の表を参考にしてみてください。

以前、長年運用されてきた大規模なメディアサイトでFSEへの移行を検討したことがあります。しかし、既存のショートコードや、functions.php（テーマの機能を追加・カスタマイズするファイル）に書き込まれた複雑な独自処理（特定のカテゴリーだけ表示を変えるような処理）がFSEのブロックとうまく噛み合わず、結果的にハイブリッドテーマ（クラシックテーマの基盤を持ちつつ、部分的にブロックエディターの機能を活用するアプローチ）を採用しました。 FSEの最大の魅力は「コードを書かずにサイト全体を視覚的にコントロールできる」点にありますが、それは同時に「ブロックエディターの仕様にサイトの構造を合わせる必要がある」ということでもあります。 もし既存サイトが、Advanced Custom Fields（ACF）などのプラグインを使ってガチガチに入力欄を制限している仕様であれば、FSEに移行することでかえって運用担当者が混乱するリスクがあります。そうした場合は、無理に完全なFSEテーマ（ブロックテーマ）へ移行せず、現在のクラシックテーマのままでエディター部分だけをGutenberg（ブロックエディター）に最適化していくアプローチをおすすめします。 長期的な保守性やWordPressの今後の方向性を考えると、FSEの概念を取り入れていくことは重要です。しかし、まずは検証環境を構築し、「現在のコンテンツがブロックとしてどう表現できるか」「運用担当者が直感的に操作できるか」を実際に触って確認することが、安全な移行の第一歩となります。

4. 実案件で頻出するGutenbergのレイアウト崩れを防ぐ具体的なCSS設計

Gutenberg（ブロックエディター）を使った案件で、納品後にクライアントが記事を更新したら、スマホ表示でレイアウトが大きく崩れてしまった。そんな経験はありませんか。 ブロックエディターは直感的な操作ができる反面、グループブロックやカラムブロックを深くネスト（入れ子にすること）しがちです。その結果、意図しない余白の相殺や幅の超過が発生し、横スクロールが生じてしまうトラブルが頻発します。 以前、企業サイトのオウンドメディア構築案件で、クライアントが独自に見出しと画像をグループ化して配置した際、モバイル端末で左右の余白が完全に消えてしまう問題に当たりました。原因は、WordPressコアが出力するデフォルトのコンテナ幅と、テーマ側で設定したCSSのパディングが競合していたことでした。 そのトラブル以降、eBIZクリエイトではブロックのネストに依存しない、堅牢なCSS設計をデフォルトのルールとして採用しています。

コンテナ幅の制御はtheme.jsonとCSSで役割を分ける

フルサイト編集（FSE）が普及して以降、レイアウトの基本設定はtheme.json（テーマの基本設定を定義するファイル）で行うのが基本です。しかし、すべてのスタイルをtheme.jsonに依存すると、複雑なネスト構造に対応しきれなくなります。 実務では、全体の最大幅や基本的な余白はtheme.jsonで設定し、予期せぬレイアウト崩れを防ぐための防御的なスタイルをテーマのstyle.cssに記述しています。 以下は、横揺れ（意図しない横スクロール）を防ぎつつ、画像やグループブロックが画面幅をはみ出さないようにするための基本的なCSSです。テーマのstyle.cssに記述します。

なぜこの書き方が推奨されるのか

この書き方をおすすめする理由は、WordPressのコアスタイルがアップデートで変更された場合でも、影響を最小限に抑えられるからです。 GutenbergのコアCSSはバージョンアップに伴い、余白の計算方法や出力されるクラス名が微妙に変更されることがあります。そのため、`.wp-block-group__inner-container`のような深い階層の固有クラスに直接スタイルを当てるのはリスクが伴います。 上記のように、大枠の要素に対して標準的なCSSの振る舞い（box-sizingなど）を強制することで、将来的なメジャーアップデートに対しても壊れにくい構造を作ることができます。

よくある間違いと注意点

やりがちですが避けた方がよいのは、すべてのブロックに対して`!important`を使って強制的にマージンを上書きすることです。これをやってしまうと、エディター画面（管理画面）とフロント側（公開画面）で見た目が大きく乖離してしまい、クライアントが直感的に編集できなくなります。 もし特定のページだけで特別なレイアウトを組みたい場合は、ブロックの「高度な設定」から独自のCSSクラス（例：`custom-lp-section`）を付与し、そのクラスに対してのみスタイルを当てるようにしてください。

CSS設計のアプローチまとめ

迷ったときは、「これはサイト全体のルールか、それとも特定の例外か」という基準で整理すると、どこにコードを書くべきか判断しやすくなります。全体のルールであればtheme.json、崩れを防ぐ安全網はstyle.css、例外的な装飾はエディターの独自クラスを活用しましょう。

5. 保守性と運用効率を高めるためのブロックパターン活用事例と運用ルール

フルサイト編集（FSE）やGutenbergのブロックエディターを使ったWeb制作において、ブロックパターンは非常に便利な機能です。しかし、実際の案件で運用を始めると「どのパターンを使えばいいかわからない」「パターンが多すぎて管理画面が整理されていない」といったご相談をよくいただきます。 現場で運用していく中で、ブロックパターンはただ作成するだけでなく、明確な運用ルールを設けることで保守性が大きく向上することがわかりました。ここでは、eBIZクリエイトの実務で取り入れているパターンの活用事例と、現場で決めている運用ルールをシェアします。

ブロックパターンの実践的な活用事例

実務では、よく使うレイアウトやデザインパーツをパターンとして登録しておくことで、クライアント自身がページを更新する際の運用効率が格段に上がります。例えば、企業サイトにおける「お問い合わせへの導線（CTA）」や「スタッフ紹介のレイアウト」などが挙げられます。 以下は、独自のカテゴリを作成し、シンプルなボタン付きのCTAパターンを登録する際のコード例です。テーマの機能を追加・カスタマイズするファイルである`functions.php`に記述します。 この処理はWordPressが初期化される`init`というタイミング（アクションフック）で実行されます。コードでパターンを管理することで、誤って管理画面から削除されてしまうリスクを防ぐことができます。

実案件で決めている運用ルール

以前の案件で、すべてのレイアウトをパターン化してクライアントにお渡ししたところ、かえって選択肢が増えすぎて使いこなせないという失敗がありました。それ以降、以下のルールを案件のデフォルトとしています。 1. 登録するパターンを厳選する クライアントが日常的な更新（ブログ記事や事例紹介など）で本当に使うレイアウトのみをパターン化します。一度しか使わないような複雑なレイアウトは、固定ページ内に直接組むようにしています。 2. 命名規則を統一する 「青いボタンのレイアウト」といった見た目ベースの名称ではなく、「サービス紹介用：3カラム」のように、用途が直感的にわかる名前をつけます。 3. 不要なデフォルトパターンを非表示にする WordPress本体が提供しているデフォルトパターンが多すぎると、独自のパターンが埋もれてしまいます。案件によっては、テーマ設定（`theme.json`など）でデフォルトパターンをオフにし、専用のものだけを表示するよう制御します。

ブロックパターンが向いているケースと向いていないケース

長期的な保守性を考えると、どこまでを機能としてロックし、どこからを自由に編集できるようにするかの線引きが重要です。クライアントのITリテラシーや更新頻度に合わせて、最適なバランスを設計してみてください。迷ったときは、「更新担当者が迷わず選べる数になっているか」を基準に整理すると、運用しやすい環境になります。