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

最近のWeb制作案件において、クライアントから「フルサイト編集（FSE）でサイトを構築してほしい」というご要望をいただく機会が非常に増えてきました。長年クラシックテーマに慣れ親しんだ方にとって、ブロックエディターでサイト全体を編集する新しい仕組みは、実務への導入に少しハードルを感じるかもしれません。正直に言うと、私自身も最初はテーマの構造変更や運用フローの構築に戸惑う場面がありました。この記事では、現場での試行錯誤を経て見えてきた、フルサイト編集を実案件で活用するための具体的な手法と、従来型テーマとの使い分けの基準をシェアします。

■ この記事でわかること
・フルサイト編集（FSE）の現在の仕様と対応状況
・実務で使えるテーマ構造と具体的なカスタマイズ手順
・独自のブロックパターンを作成する内部的な仕組み
・従来型テーマとフルサイト編集を選ぶ際の判断基準
・長期的な運用や保守を見据えた注意点と今後の展望

1. フルサイト編集の基本仕様と現在の対応状況について

WordPressの構築において、ブロックエディターでサイト全体を編集できる新機能であるFSE（フルサイト編集）の導入を検討されるケースが増えています。実際の案件でも「従来型のクラシックテーマとどちらを選ぶべきか」というご相談をよくいただきます。

まずはFSEの基本仕様について整理しておきます。従来のWordPressテーマでは、ヘッダーやフッター、アーカイブページなどのレイアウトはPHPファイル（テーマファイル）に直接コードを記述して構築していました。一方、FSEに対応したブロックテーマでは、これらの共通パーツも含めたサイト全体の構造を、管理画面のブロックエディター上から視覚的に組み立てることが可能です。

内部的な動作としては、テーマディレクトリ内のHTMLファイルにブロックのマークアップが保存され、それをWordPressのコアシステムが解析してページをレンダリングします。そのため、PHPの記述量が大幅に減り、ノーコードに近い感覚で全体のデザインを調整できるのが大きな特徴です。

現在の対応状況についてですが、WordPressの公式ディレクトリ（https://wordpress.org）に登録されているブロックテーマの数は日々増加しており、開発コミュニティ全体がFSEを推進する方向へシフトしています。機能面でも、以前は手探りだったナビゲーションメニューの構築や、グローバルスタイルの詳細な設定がアップデートごとに洗練されてきました。

ただし、実務の現場で完全にFSEへ移行しているかというと、まだ過渡期にあるというのが率直な印象です。小規模なコーポレートサイトや、クライアント自身でレイアウトを柔軟に変更したいというご要望がある場合にはFSEが非常に向いています。その反面、複雑なカスタム投稿タイプを組み合わせたポータルサイトや、ピクセルパーフェクトなデザイン再現が求められる要件では、従来のクラシックテーマとPHPによるテンプレート構築のほうが、予期せぬレイアウト崩れを防ぎやすく、保守性が高いと判断するケースが多くあります。

導入を検討する際は、クライアントの運用体制とサイトの規模をすり合わせ、柔軟性を優先するのか、堅牢なテンプレートによる運用を優先するのかを見極めることが重要です。

2. 実案件でのテーマ構造とカスタマイズ手順の具体例

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実際の案件で導入する際、最も悩むのがテーマのディレクトリ構造とカスタマイズの手順ではないでしょうか。従来型のクラシックテーマとFSE対応のブロックテーマでは、必要なファイルや考え方が根本的に異なります。

ここでは、実案件で私たちが採用しているベースの構造と、具体的なカスタマイズ手順をシェアします。

まず、最小限のブロックテーマを構築する場合、以下のようなファイル構成になります。

my-block-theme/
├── style.css         // テーマの宣言と基本スタイル
├── theme.json        // ブロックの設定、カラーパレット、タイポグラフィなどの中央管理
├── index.php         // 必須ファイル（空でも可。フォールバック用）
└── templates/
└── index.html   // サイトのベースとなるHTMLテンプレート

従来のクラシックテーマに慣れていると、PHPファイルではなくHTMLファイルがテンプレートディレクトリに入っていることに違和感を覚えるかもしれません。ブロックテーマでは、PHPのコードをテンプレートファイルに直接書き込むのではなく、ブロックの組み合わせとしてHTMLファイルに記述します。

実案件でよくある要件として、「独自のカラーパレットをクライアントに提供したい」というケースがあります。その場合は、`theme.json`ファイルを活用します。`functions.php`（テーマの機能を追加・カスタマイズするファイル）で色を定義するのではなく、一元管理できる`theme.json`を使うのが現在の主流です。

具体的な`theme.json`の記述例は以下の通りです。

{
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "brand-primary",
"color": "#0056b3",
"name": "ブランドメインカラー"
},
{
"slug": "brand-secondary",
"color": "#f8f9fa",
"name": "ブランドサブカラー"
}
]
}
}
}

この記述を追加するだけで、エディター画面のカラーピッカーに独自のブランドカラーが表示されるようになります。

以前の案件で、クライアントから「サイト内の見出しやボタンの色をエディターから自由に変えたいが、ブランドカラー以外の色は使わせないようにしてほしい」という要望をいただいたことがありました。クラシックテーマであればエディターの機能を複雑に制限するコードを書く必要がありましたが、`theme.json`であれば、デフォルトのカラーパレットを無効化し、上記のように独自パレットだけを定義することでスムーズに解決できました。

また、独自のCSSを当てたい場合、従来は`style.css`にすべてを記述していましたが、ブロックテーマでは少しアプローチが変わります。サイト全体の共通スタイルは依然として`style.css`に記述しますが、特定のブロックにだけ適用したいスタイルがある場合は、以下のように`functions.php`にフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を用いて登録するのが実務的です。

// functions.php に記述します
// initアクションフック（WordPressの初期化時に実行されるタイミング）でスタイルを登録
add_action( 'init', 'my_custom_block_styles' );
function my_custom_block_styles() {
// コアのボタンスタイルに独自のスタイルを追加
register_block_style(
'core/button',
array(
'name'  => 'arrow-button',
'label' => '矢印付きボタン',
)
);
}

このように登録すると、エディターの右側パネルに「矢印付きボタン」というスタイルが選択肢として表示されます。あとはCSS側で`.is-style-arrow-button`クラスに対してスタイルを定義するだけで済みます。

実案件では、「どこまでをtheme.jsonで制御し、どこからをCSSで書くか」の境界線を明確に引くことが保守性を高める鍵となります。レイアウトや基本的なタイポグラフィ、カラー設定は極力`theme.json`に寄せ、複雑なホバーアニメーションや特定のデバイス向けの細かな調整はCSSに任せる、という切り分けをしておくと、将来的な運用が非常に楽になります。

3. 独自のブロックパターンを作成する際の内部仕様の解説

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用する案件が増える中で、独自のブロックパターンをどのように管理するかが実務での大きなテーマになります。ブロックパターンを用意しておくことで、運用担当者がデザインを崩すことなく、あらかじめ設定したレイアウトを呼び出してコンテンツを作成できるようになります。

ここでは、独自のブロックパターンを登録する際の内部的な仕組みと、実際のコードの書き方について解説します。

WordPressでブロックパターンを登録するには、主にPHPの関数である`register_block_pattern`を使用します。この処理は、WordPressのコアがブロックの設定を読み込む`init`アクションフック（特定のタイミングで処理を実行する仕組み）のタイミングで実行する必要があります。

具体的なコードは以下のようになります。

<?php
/
 独自のブロックパターンを登録する

 記述場所: functions.php またはカスタムプラグイン内
 実行タイミング: initフック
/
function ebiz_register_custom_block_pattern() {
// パターンがすでに登録されていないか確認し、登録を実行
register_block_pattern(
'ebiz-theme/custom-hero-section', // ネームスペースとパターンの一意の識別子
array(
'title'       => __( 'カスタムヒーローエリア', 'ebiz-theme' ), // パターンの表示名
'description' => _x( '画像とテキストを組み合わせたメインビジュアル用のパターンです。', 'Block pattern description', 'ebiz-theme' ), // パターンの説明
'categories'  => array( 'featured', 'hero' ), // 割り当てるカテゴリー
// エディター上で作成したブロックのHTML（コメントアウト部分含む）を記述
'content'     => '<!-- wp:group {"layout":{"type":"constrained"}} --><div class="wp-block-group"><!-- wp:heading --><h2>メインコピーがここに入ります</h2><!-- /wp:heading --><!-- wp:paragraph --><p>サブテキストを記述します。</p><!-- /wp:paragraph --></div><!-- /wp:group -->',
)
);
}
add_action( 'init', 'ebiz_register_custom_block_pattern' );
?>

内部でこう動いているからこそ、この書き方が推奨されます。`register_block_pattern`を通して登録されたデータは、ブロックエディターが起動する際にREST API（外部からWordPressのデータにアクセスするための仕組み）を経由してエディター側に渡されます。これにより、JavaScript側で重い処理を記述することなく、PHP側で一元管理されたパターンをエディターのインサーター（追加メニュー）に表示させることが可能になります。

正直に言うと、以前はエディター上で再利用可能ブロック（現在の同期パターン）を作成し、それをエクスポートして各サイトに配るという運用をしていた時期もありました。しかし、クライアントが誤って元のブロックを削除してしまうトラブルが起きてから、テーマやプラグインのコード内でハードコードして管理する現在の方法に変えました。コードベースで管理することで、バージョン管理システム（Gitなど）での履歴追跡も容易になり、保守性が劇的に向上します。

最近のブロックテーマでは、テーマディレクトリ直下に`patterns`というフォルダを作成し、そこにPHPファイルを配置するだけで自動的にパターンとして読み込まれる機能も追加されています。どちらを採用するか迷ったときは、以下のように考えると整理しやすいです。

どちらの仕様を採用する場合でも、「なぜそのディレクトリに置くのか」「どのタイミングでWordPressに認識されるのか」という内部の動きを理解しておくことで、アップデート時に表示されなくなるなどの予期せぬトラブルを防ぐことができます。実案件の状況に合わせて、最適な登録方法を選択してみてください。

4. 従来型テーマとフルサイト編集の選び方と判断基準

クラシックテーマ（従来型のPHPベースのテーマ）と、ブロックエディターでサイト全体を構築するフルサイト編集（FSE）。実際の案件でどちらを採用すべきか、頭を悩ませる場面も多いのではないでしょうか。

私自身、FSEが登場した当初は手探りの状態が続き、保守性を考慮してクラシックテーマを選択することがほとんどでした。しかし、WordPressのバージョンアップとともにFSEの機能が成熟してきたことで、現在では案件の要件に応じて明確に使い分けるようにしています。

結論から申し上げますと、運用者がどこまで自由にレイアウトを変更したいかが、最大の判断基準となります。

クラシックテーマは、あらかじめ設計されたデザインと機能の中で、安全にコンテンツを更新していく運用に向いています。PHPテンプレートでガッチリと構造を固めるため、運用者が誤ってサイト全体のレイアウトを崩してしまうリスクを最小限に抑えられます。デザインの統一感を厳密に守りたいコーポレートサイトなどでは、今でも有効な選択肢です。

一方のFSEは、運用者自身がノーコードでヘッダーやフッター、さらにはアーカイブページのレイアウトまで柔軟に変更できる点が魅力です。マーケティング施策に合わせて頻繁にデザインをテストしたいオウンドメディアや、ランディングページを量産したいプロジェクトでは、その真価を発揮します。自由度が高い反面、運用ルールの策定や操作マニュアルの準備が不可欠になります。

実務における判断基準を整理してみました。

保守性と将来性について少し触れておきます。WordPress開発コミュニティの動きを見ていると、明確にブロックベースのFSEへと舵を切っています。そのため、新規で立ち上げるプロジェクトであり、かつ運用チームがブロックエディターの操作に慣れているのであれば、FSEを採用するメリットは大きくなります。

既存のクラシックテーマがすぐに使えなくなるわけではありません。無理にFSEへ移行して現場の更新業務が滞ってしまっては本末転倒です。まずは一部の機能からブロックエディターの柔軟性を取り入れ、運用体制と照らし合わせながら、次のリニューアルでFSEを検討するという段階的なアプローチも推奨しています。迷った際は、サイトの目的だけでなく、日々の運用担当者のスキルセットを含めて俯瞰してみると、自ずと答えが見えてきます。

5. 長期的な保守を見据えた運用上の注意点と今後の展望

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）で構築したサイトをクライアントに納品し、その後の保守・運用フェーズに入った際、クラシックテーマとは異なる独自の課題に直面することがあります。実際の案件でも、納品後の運用ルールを明確にしていなかったために、意図しないレイアウト崩れが発生したケースがありました。ここでは、実務経験に基づいた保守のポイントと、今後のWordPressの動向を踏まえた展望をシェアします。

まず、最も重要なのは「クライアントの編集権限のコントロール」です。FSEは直感的にどこでも編集できる反面、グローバルなテンプレートパーツ（ヘッダーやフッターなど）まで簡単に変更できてしまいます。実案件では、theme.jsonを活用して特定のブロックの設定をロックしたり、ユーザー権限に応じてテンプレートエディターへのアクセスを制限したりすることが推奨されます。

// theme.jsonで特定のブロックのスタイル変更を制限する例
{
"version": 2,
"settings": {
"blocks": {
"core/site-title": {
"color": {
"text": false // サイトタイトルの文字色変更を無効化
},
"typography": {
"customFontSize": false // カスタムフォントサイズを無効化
}
}
}
}
}

この記述をテーマの `theme.json` に追加することで、デザインの意図しない変更を防ぐことができます。

次に、メジャーアップデートへの対応です。WordPressのコアアップデートにより、ブロックのマークアップやデフォルトのスタイルが変更されることがあります。保守契約を結んでいる場合は、必ずステージング環境（本番環境を複製したテスト環境）でアップデートを検証し、フロントエンドの表示に影響がないかを確認するフローを標準化することが大切です。

長期的に見て、WordPressはFSEを標準機能としてさらに拡張していく方向で開発が進められています。クラシックテーマが即座に使えなくなるわけではありませんが、新規案件においてはFSEを前提とした設計・構築のノウハウを蓄積していくことが、保守性や将来性を考えると理にかなっています。迷ったときは、「クライアントのリテラシー」と「サイトの更新頻度」を軸に、どこまでをブロックで解放し、どこをパターンやロック機能で制御するかを判断基準にすると整理しやすいです。

Web制作や保守・運用に関するご相談はお気軽にeBIZクリエイトまでお問い合わせください。