【動作確認済み環境】
・WordPress：6.5
・PHP：8.1
・確認日：2024年5月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

フルサイト編集（FSE）の機能が充実してきたいま、実際のWeb制作案件でクラシックテーマからFSEへ切り替えるタイミングについて、判断に迷うというご相談をよくいただきます。既存のサイトをブロックエディター（Gutenberg）中心の構成へ移行する際、エディターをどこまで独自に作り込むべきか、設計の落としどころに悩む場面は多いのではないでしょうか。

この記事では、日々の案件で実践しているフルサイト編集のカスタマイズ手法や、テーマ移行時に直面しやすい課題と具体的な解決策を、実際のコードとともに共有します。案件を進めるうえでの意思決定に役立つ、保守性を見据えた設計の軸をお渡しできればと思います。

【この記事でわかること】
・フルサイト編集を実務の案件に導入するための具体的な判断基準
・Gutenbergブロックエディターの安全なカスタマイズ手順とコードの書き方
・クラシックテーマから移行する際のつまずきやすいポイントと解決策
・ブロックパターンを活用して制作の効率を上げる仕組みの作り方
・将来的なWordPressのアップデートを見据えた保守性の高い設計方針

1. フルサイト編集の導入で変わる制作フローと実務での活用判断

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

WordPressでのWeb制作において、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実案件に導入するかどうかで悩むケースが増えています。従来のPHPベースのテーマ構築から、HTMLとブロックマークアップを中心とした開発へ移行することで、制作の進め方自体が大きく変わるためです。この記事では、FSEを取り入れた際の制作フローの変化と、案件ごとの導入判断について、実務の現場からシェアします。

■ この記事でわかること
・FSE導入による制作工程の具体的な変化
・実案件におけるブロックテーマ採用の判断基準
・従来型テーマ（クラシックテーマ）との使い分けの考え方

FSEを導入すると、ヘッダーやフッター、アーカイブページといった共通部分のレイアウトまで、すべてエディター上で構築・調整することになります。これまでのようにテーマファイルのPHPコードを直接編集してレイアウトを組むのではなく、theme.jsonという設定ファイルでサイト全体のデザインルールを定義し、エディターのGUIからブロックを配置していくスタイルへと移行します。

正直に言うと、導入初期は細かなデザインの調整において、CSSで直接指定するほうが早いと感じる場面が多々ありました。しかし、theme.jsonでカラーパレットやタイポグラフィのルールをしっかり設計しておくことで、運用フェーズに入ってからの保守性が飛躍的に向上することに気づきました。クライアント自身が安全にサイトの見た目を微調整できる範囲が広がるため、納品後の軽微な修正依頼に割く工数を減らすことができます。

■ なぜtheme.jsonでの一元管理が推奨されるのか
FSEのコアとなるtheme.jsonは、サイトのデザインシステムを定義するためのファイルです。ここで設定した値はエディターのUIに直接反映されるだけでなく、フロントエンド用のCSSカスタムプロパティとしても自動生成されます。これにより、エディターの見た目と実際の公開画面のズレを防ぎやすくなります。内部で一貫したスタイルが適用されるため、後からデザインを微修正する際も、このファイルの一部を変更するだけでサイト全体に適用されます。長期的な保守性を考えると、デザインルールをハードコードするのではなく、設定ファイルに持たせる設計は非常に理にかなっています。

迷ったときは、サイトの「運用主体」と「デザインの固定度合い」を軸に考えると整理しやすいです。運用側で柔軟にページを作りたい場合はFSEが適していますが、ブランドガイドラインが厳格で、意図しないレイアウト崩れを防ぎたい場合は、従来通りPHPでガチガチに固めたクラシックテーマを選ぶのも一つの正しい選択です。案件の要件に合わせて、適切な手法を選んでみてください。

Web制作に関するお悩みや、WordPressのカスタマイズについてのご相談はお気軽にeBIZクリエイトまでお問い合わせください。

2. Gutenbergブロックエディターの独自カスタマイズ手順とコード解説

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：4月
・テーマ：独自開発テーマ（ブロックテーマ）
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「クライアントから、見出しブロックのデザインを独自のものに変更したいと要望された」
「既存のブロックスタイルだけでは、デザインカンプを再現しきれない」

実際のWeb制作案件では、Gutenberg（ブロックエディター）の標準機能だけでは対応しきれない場面によく遭遇します。この記事では、実務で頻繁に使用する「ブロックスタイルの追加」を例に、エディターのカスタマイズ手順とその背景にある仕組みをシェアします。

ブロックスタイルを追加する具体的なコード

今回は、最も頻出する「見出しブロック（core/heading）」に独自のスタイル（サブタイトル付きの装飾など）を追加する方法を解説します。

スタイルを追加するには、テーマの `functions.php` に以下のように記述します。

<?php
/
 独自のブロックスタイルを追加する
 記述場所：functions.php または独自のプラグインファイル
/
function ebiz_register_block_styles() {
// 見出しブロックに「下線付き（青）」スタイルを追加
register_block_style(
'core/heading', // 対象となるブロック名
array(
'name'         => 'ebiz-underline-blue', // CSSクラスとして出力される名前
'label'        => '下線付き（青）',      // エディター上に表示される表示名
'is_default'   => false,                 // デフォルトスタイルにはしない
)
);
}
// 'init' フック（WordPressの初期化時）で実行する
add_action( 'init', 'ebiz_register_block_styles' );

このコードを追加すると、エディター画面で見出しブロックを選択した際、右側の設定パネルに「下線付き（青）」というスタイルが選べるようになります。選択すると、フロントエンド側のHTMLには `is-style-ebiz-underline-blue` というCSSクラスが付与されるため、あとはテーマの `style.css` で該当クラスに対してデザインをあてるだけです。

なぜこの方法で実装するのか（内部の仕組み）

ブロックスタイルの追加には、JavaScript（クライアントサイド）を使う方法と、PHP（サーバーサイド）を使う方法の2種類があります。

以前の案件で、私はJavaScript側で `wp.blocks.registerBlockStyle` を使ってスタイルを登録していました。しかし、JavaScriptのビルド環境（Webpackなど）の整備が必要になり、少しの変更でもコンパイルの手間がかかるという課題がありました。

PHPの `register_block_style` 関数を使用するこの書き方が推奨される理由は、ビルド不要で手軽に実装できる点と、WordPressの初期化（initフック）という確実なタイミングで登録されるため、エディターの読み込みエラーに強いという点です。実案件の保守性を考えると、サーバーサイドで完結するPHPでの登録が扱いやすいと判断し、現在うちの制作チームではこの方法をデフォルトとしています。

向いているケース・向いていないケース

ブロックスタイルの追加は便利ですが、万能ではありません。状況によってブロックパターンと使い分ける必要があります。

複雑なレイアウトをひとつのブロックのスタイルとして無理やりCSSで表現しようとすると、後からHTML構造を変更したくなった際に破綻しやすくなります。そういった場合は、ブロックパターンとして登録する方が適しています。

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

WordPressの開発が進む中で、エディターのカスタマイズ方法は大きく変化してきました。フルサイト編集（FSE）が普及しつつある現在、デザインの定義は `theme.json` ファイルに集約していくのが公式の方向性です。

長期的に見てこの選択は正しいかというと、単純な色やフォントサイズの変更であれば `theme.json` で定義する方が将来のメジャーアップデートの影響を受けにくく安全です。一方で、疑似要素を使った複雑な装飾や、既存のCSSフレームワークと連携させるような独自クラスの付与が必要な場面では、今回紹介した `register_block_style` によるアプローチが依然として有効です。

迷ったときは、以下のように整理すると判断しやすいです。

・単純な色や余白の変更 → `theme.json` で設定する
・特定のCSSクラスを付与して独自にスタイリングしたい → `register_block_style` を使う
・複数のブロックが絡む複雑な構成 → ブロックパターンを作る

エディターのカスタマイズは、制作者の自己満足ではなく「クライアントが運用しやすい状態を作る」ことが最終的な目的です。現場の運用体制に合わせて、最適な方法を選んでみてください。

3. 実案件で直面したテーマ移行時の課題と具体的な解決手順

【動作確認済み環境】
・WordPress：6.4.2
・PHP：8.1
・確認日：検証完了時
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

従来のクラシックテーマからFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）対応テーマへ移行する際、多くのWeb制作者が頭を悩ませるのが既存コンテンツの互換性です。

以前、数千記事を持つメディアサイトのテーマ移行案件で、既存のコンテンツが意図しない形で崩れるという問題に当たりました。その時の解決策と、実務での判断基準をシェアします。

クラシックブロックへの意図しない変換と対処法

従来のクラシックエディターで作成された記事をブロックエディターで開くと、多くの場合「クラシックブロック」として読み込まれます。しかし、これらを一括で通常のブロックに変換しようとすると、独自のHTMLタグやショートコードが欠落するトラブルが発生します。

正直に言うと、以前は無理にすべての過去記事をブロックへ変換しようとしていました。でも、表示崩れのチェックに膨大な工数がかかるというトラブルが起きてから方針を変えました。

現在では、過去のコンテンツはクラシックブロックのまま保持し、新規記事のみブロックエディターの機能をフル活用するという運用を推奨しています。

theme.jsonでのスタイル競合と解決手順

FSEテーマでは、`theme.json`（テーマ全体のスタイルやエディターの設定を管理するファイル）でデザインを制御します。移行時に、既存の`style.css`に記述されたCSSと、`theme.json`から出力されるグローバルスタイルが競合し、CSSが効かない理由がわからないという状況に陥りがちです。

このエラーが出たときの対処法として、`functions.php`（テーマの機能を追加・カスタマイズするファイル）で既存のCSSの読み込み優先順位を調整する方法があります。

// functions.php に記述
// ブロックのスタイルの後に独自のCSSを読み込む
add_action( 'wp_enqueue_scripts', 'ebiz_enqueue_custom_styles', 20 );
function ebiz_enqueue_custom_styles() {
// get_stylesheet_uri() は現在のテーマの style.css のURLを取得します
wp_enqueue_style(
'ebiz-custom-style',
get_stylesheet_uri(),
array(), // 依存関係なし
wp_get_theme()->get('Version')
);
}

この書き方が推奨される理由は、WordPressの内部仕様において、フック（WordPressの処理に割り込んで独自の処理を追加する仕組み）の優先順位を遅らせることで、コアのブロックスタイルが読み込まれた後に独自のCSSを上書きできるからです。

移行手法の選定基準

テーマ移行において、FSEを全面的に採用するか、クラシックテーマを維持しながら部分的にブロックエディターを活用するかは、サイトの規模や運用体制によって異なります。

長期的に見てこの選択は正しいかという観点では、WordPressは明確にFSEへと方向性を進めています。しかし、メジャーアップデートの影響を受けない堅牢なサイトを維持するためには、無理な完全移行よりも、段階的なハイブリッドアプローチが保守性の観点から安全です。

迷ったときは、既存コンテンツの量と、運用担当者のITリテラシーを軸に考えると整理しやすいです。正解は一つではないため、現状のリソースに合わせて無理のない手法を選択してください。

Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。一緒に最適なサイト構築を目指していきましょう。

4. ブロックパターンを活用した効率的なサイト構築の仕組み

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）が普及する中で、実務における制作効率を大きく左右するのが「ブロックパターン」の活用です。複数のブロックを組み合わせたデザインのテンプレートをあらかじめ用意しておくことで、クライアント自身がページを追加する際にも、デザインの統一感を保ちながら運用できるようになります。

実際の案件でも、「毎回同じようなレイアウトを作るのが手間」「クライアントが操作するとデザインが崩れる」という相談をよく受けます。以前は再利用ブロック（現在の同期パターン）を使って対応していましたが、クライアントが一部のテキストだけを変更したつもりが、サイト全体の共通部分まで書き換わってしまうトラブルがありました。その点、非同期のブロックパターンであれば、挿入後に独立したブロックとして編集できるため、運用時の事故を防ぎやすくなります。

ブロックパターンを自作する場合、テーマのfunctions.php（テーマの機能を追加・カスタマイズするファイル）から登録するのが一般的です。以下は、独自のお問い合わせセクションをパターンとして登録する実務的なコード例です。

/
 カスタムブロックパターンを登録する
 記述場所: functions.php
 実行タイミング: initフック（WordPressの初期化時）
/
function ebiz_register_custom_pattern() {
register_block_pattern(
'ebiz-theme/contact-section', // パターンの名前空間とスラッグ
array(
'title'       => __( 'お問い合わせセクション', 'ebiz-theme' ),
'description' => _x( '標準的なお問い合わせへの誘導エリア', 'Block pattern description', 'ebiz-theme' ),
'categories'  => array( 'call-to-action' ), // 表示されるカテゴリ
// ブロックエディターからコピーしたHTMLをエスケープして記述します
'content'     => '<!-- wp:group {"layout":{"type":"constrained"}} --><div class="wp-block-group"><!-- wp:heading --><h2>お問い合わせ</h2><!-- /wp:heading --><!-- wp:paragraph --><p>お気軽にご相談ください。</p><!-- /wp:paragraph --><!-- wp:buttons --><div class="wp-block-buttons"><!-- wp:button --><div class="wp-block-button"><a class="wp-block-button__link wp-element-button" href="/contact">相談する</a></div><!-- /wp:button --></div><!-- /wp:buttons --></div><!-- /wp:group -->',
)
);
}
add_action( 'init', 'ebiz_register_custom_pattern' );

この書き方を推奨する理由は、テーマに依存する固有のデザインパーツを、コードベースで安全に管理できるからです。データベースに保存される同期パターンとは異なり、Gitなどのバージョン管理システムで変更履歴を追えるため、複数人での開発や保守対応がスムーズになります。

ただし、すべてのレイアウトをパターン化すれば良いというわけではありません。

迷ったときは、「挿入後に個別の編集が必要かどうか」を基準に考えてみてください。個別の編集が必要ならブロックパターン、サイト全体で一括更新したいならテンプレートパーツや同期パターン（旧再利用ブロック）を選ぶと整理しやすいです。将来的なメンテナンス性まで見据えて、適切な手法を選択していきましょう。

5. 保守性と将来性を考慮したカスタマイズ設計のポイント

WordPressのフルサイト編集（FSE）やGutenberg（ブロックエディター）を活用する際、目の前の要件を満たすことと同じくらい重要なのが、長期的な保守性と将来性の担保です。Web制作の現場では、アップデートによってレイアウトが崩れたり、過去に作成した独自ブロックが動作しなくなったりするトラブルが多く見受けられます。

実案件でカスタマイズ方針を決定する際、私たちは常に「WordPress本体の進化に逆らわない設計」を心がけています。WordPress公式（https://wordpress.org）が提供するコアブロックの機能を最大限に活用し、独自開発を最小限に抑えることが、長期的な安定運用につながるからです。

例えば、独自のカスタムブロックをReactでゼロから開発する場合と、標準のグループブロックに独自の設定を追加する「ブロックスタイル」を活用する場合とでは、数回先のメジャーアップデート時のメンテナンスコストに大きな差が生じます。以前、複雑な独自ブロックを多用したプロジェクトで、エディター側のAPI変更に伴う改修に膨大な時間を要した経験がありました。それ以降、私たちは極力「theme.json」によるグローバル設定の制御と、ブロックスタイルの追加を優先する設計方針に切り替えています。

カスタマイズ手法を選択する際の判断基準として、以下の表を参考にしてください。

theme.json（テーマの基本設定を定義するファイル）を活用することで、CSSの記述量を大幅に削減しつつ、エディター側とフロント側のデザインを安全に同期させることができます。これは、WordPressの今後の方向性と完全に一致したアプローチです。将来的なテーマの切り替えや、新たなコアブロックの追加時にも、設定したデザインルールがスムーズに引き継がれるという大きな利点があります。

迷ったときは、「このカスタマイズはWordPressの標準機能で代替できないか」をまず検討してみてください。無理な独自開発を避け、エコシステムに寄り添うことこそが、結果として最も保守性の高いサイト設計を実現します。長期的な視点での設計にお悩みの際は、Web制作の運用・保守に強いeBIZクリエイト株式会社までご相談ください。