【動作確認済み環境】 ・WordPress：6.8 ・PHP：8.2 ・確認日：2026年1月 ・テーマ：Twenty Twenty-Four ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 フルサイト編集（FSE）が普及してきましたが、実際の案件で「ここだけはPHPで細かく制御したい」「独自デザインを当てたいけれど、どう組み合わせるのが正解か迷う」というご相談をよくいただきます。 すべてをブロックで完結させるのは理想的ですが、クライアントの細かな要望に応えるためには、従来型のカスタマイズが必要になる場面も少なくありません。正直に言うと、設計段階でこの境界線を見誤り、後から修正に追われた経験もあります。 この記事では、実務の現場で直面するブロックテーマと独自カスタマイズの境界線をどう引くか、私たちが実際の案件で採用しているハイブリッドな構築手順をシェアします。 ■ この記事でわかること ・フルサイト編集と従来型テーマを組み合わせる判断基準がわかります ・実務で使えるtheme.jsonの基本設計と独自CSSの適切な読み込み方がわかります ・運用を見据えたパターンとカスタムブロックの使い分けができるようになります ・納品後にクライアントが安全に運用するための編集権限の制御方法がわかります

1. フルサイト編集と従来型テーマのハイブリッド構築が求められる背景

WordPressのブロックエディターでサイト全体を編集できる機能であるFSE（フルサイト編集）が浸透し、ノーコードでの構築の幅が大きく広がりました。しかし、実際の制作現場では「すべてのテーマをFSEだけで構築する」というケースばかりではありません。 従来のPHPテンプレートを中心としたクラシックテーマの柔軟性と、FSEの直感的な操作性を組み合わせた「ハイブリッド構築」という選択肢をとる案件が増加しています。 以前、コーポレートサイトの全面リニューアル案件で、更新担当者から「お知らせやコラムのレイアウトは自由に組みたいが、商品詳細ページや会社概要などの根幹となるページは、デザインが崩れないようにガチガチに固定してほしい」という要望をいただきました。 FSEのみで構築した場合、クライアントが意図せず共通パーツのテンプレートを編集してしまい、サイト全体のレイアウトが崩れてしまうリスクがあります。一方で、従来のクラシックテーマのみで構築すると、ランディングページのような自由なレイアウトを組みたい場合に、都度コーディングの依頼が発生してしまい、更新のスピード感が失われます。 この相反する課題を解決するために、固定ページや投稿のコンテンツエリアはブロックエディターを活用して柔軟に構築しつつ、ヘッダーやフッター、特定のカスタム投稿タイプのアーカイブページなどは、従来のPHPファイルで制御するというハイブリッドな手法が選ばれるようになっています。 内部的な仕様として、WordPressはブロックテーマ（FSE対応テーマ）とクラシックテーマの中間的な設定を許可しています。`theme.json`という設定ファイルをクラシックテーマ内に配置することで、エディター側のカラーパレットやフォントサイズなどのブロック設定を一元管理しながら、出力は従来のPHPテンプレートに任せることが可能です。 この手法により、制作側はGitなどを用いたバージョン管理や複雑な条件分岐を用いた高度なカスタマイズを維持しつつ、クライアントには直感的なコンテンツ編集環境を提供できます。長期的な運用を見据えた際、保守性の高さと更新のしやすさのバランスが取れる点が、ハイブリッド構築が求められている最大の理由です。 迷った際の判断基準として、以下の表にハイブリッド構築の向き不向きを整理しました。

2. 実案件でつまずきやすいブロックテーマとPHPカスタマイズの境界線

WordPressのフルサイト編集（FSE）を実案件に導入する際、これまでクラシックテーマでの制作に慣れている制作者ほど直面しやすい壁があります。それが「どこまでをブロックエディターの機能で作り、どこからをPHPでカスタマイズするのか」という境界線の見極めです。 クラシックテーマでは、テンプレートファイルやfunctions.php（テーマの機能を追加・カスタマイズするファイル）に直接コードを書いて制御するのが一般的でした。しかし、FSEに対応したブロックテーマでは、サイト全体の設定やデザインをtheme.jsonやブロックエディター上で管理する設計思想に変わっています。 以前、コーポレートサイトの案件で、カスタム投稿タイプのアーカイブページのデザインを細かく制御しようとした際のことです。これまで通りfunctions.phpにフック（WordPressの処理に割り込んで独自の処理を追加する仕組み）を書いて出力を書き換えようとしましたが、ブロックテーマ側のテンプレート設定と競合し、意図したレイアウトが反映されないという問題に当たりました。 この時の解決策は、PHPでの出力制御を最小限に抑え、必要なデータをブロックとして呼び出せるようにカスタムブロックを開発し、レイアウト自体はFSEのテンプレートエディターで行うというアプローチに切り替えることでした。 この経験から、実務においては以下のように役割を明確に分けるようにしています。 ・デザインとレイアウトの制御：theme.jsonとFSEのエディターに任せる ・データの取得と複雑な処理：PHP（プラグインやfunctions.php）で行う ・両者の橋渡し：カスタムブロックやパターンとして登録する 例えば、特定の条件でしか表示させない複雑なバナー領域を作りたい場合、テンプレートファイルに直接PHPの条件分岐を書くのではなく、以下のようにショートコードやカスタムブロックを定義して、FSE側から配置できるようにします。

// functions.phpに記載します
// 特定の権限を持つユーザーにのみ表示するコンテンツをショートコード化
add_shortcode( 'member_only_content', 'ebiz_member_only_content_render' );

function ebiz_member_only_content_render( $atts, $content = null ) {
// ユーザーがログインしているか、特定の権限を持っているかを確認
if ( is_user_logged_in() && current_user_can( 'read_private_posts' ) ) {
// 安全に出力するためにエスケープ処理（出力データを安全な形に変換する処理）を行う
return '<div class="member-content">' . wp_kses_post( $content ) . '</div>';
}

// 条件を満たさない場合は何も表示しない
return '';
}

3. 実務で使えるtheme.jsonの基本設計と独自CSSの適切な読み込み方

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を利用する際、デザインのベースとなるのが`theme.json`です。実際の案件でFSEテーマを構築する場面において、このファイルにどこまで設定を持たせ、どこから独自のCSSで上書きするかの線引きが、保守性を大きく左右します。 まず、`theme.json`で制御すべきなのは、カラーパレット、タイポグラフィ、余白などの「サイト全体の基本ルール」です。これにより、エディター上でも一貫したデザインを維持しつつ、クライアントがブロックを追加した際にもデザインの崩れを防ぐことができます。 以下は、実務でベースとして使用している`theme.json`の記述例です。

{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"color": {
"palette": [
{
"slug": "primary",
"color": "#005baa",
"name": "Primary Color"
},
{
"slug": "secondary",
"color": "#f7f7f7",
"name": "Secondary Color"
}
],
"custom": false,
"customGradient": false
},
"typography": {
"customFontSize": false,
"fontSizes": [
{
"slug": "small",
"size": "14px",
"name": "Small"
},
{
"slug": "normal",
"size": "16px",
"name": "Normal"
}
]
},
"layout": {
"contentSize": "800px",
"wideSize": "1200px"
}
}
}

<?php
/
 独自のCSSをフロントエンドとエディターの両方に読み込む
/
function ebiz_enqueue_custom_styles() {
// タイムスタンプを付与してキャッシュをクリアしやすくする
$version = filemtime( get_theme_file_path( '/assets/css/style.css' ) );

// フロントエンド用のCSS読み込み
wp_enqueue_style(
'ebiz-custom-style',
get_theme_file_uri( '/assets/css/style.css' ),
array(),
$version
);
}
// wp_enqueue_scriptsはフロントエンドでスクリプトやスタイルを読み込むフック
add_action( 'wp_enqueue_scripts', 'ebiz_enqueue_custom_styles' );

/
 ブロックエディター内に独自CSSを適用する
/
function ebiz_enqueue_editor_styles() {
// エディター用にスタイルを追加（add_theme_support('editor-styles')が前提）
add_editor_style( 'assets/css/style.css' );
}
// after_setup_themeはテーマ初期化時に実行されるフック
add_action( 'after_setup_theme', 'ebiz_enqueue_editor_styles' );

4. パターン機能とカスタムブロックを活用した運用しやすい設計基準

FSE（フルサイト編集：ブロックエディターでサイト全体を編集できる機能）を実案件に導入する際、現場でよく議論になるのが「どこまでをパターン機能で作り、どこからをカスタムブロックとして開発するか」という線引きです。 実務において、クライアントが直感的に更新できる状態を作りつつ、将来的なデザイン変更にも耐えられる設計にするためには、この2つの使い分けが非常に重要になります。 ブロックパターンは、既存のコアブロックを組み合わせてレイアウトを定義する機能です。一方のカスタムブロックは、独自のHTML構造や入力項目を持たせた専用のブロックを開発する手法を指します。 以前、あるコーポレートサイトの案件で、見出しやボタン、カード型のレイアウトなど、あらゆる要素をブロックパターンとして登録して納品したことがありました。納品直後は問題なかったのですが、数ヶ月後に「すべてのカードレイアウトの余白を少し調整したい」というご要望をいただいた際、非常に手間がかかってしまったという失敗経験があります。 ブロックパターンは、一度エディターに配置されると、それぞれのブロックが独立した設定を持つため、後から一括でデザインを変更することが難しいという特徴を持っています。そのため、現在では以下のような基準で使い分けるようにしています。

// functions.php に記述します
// テーマのセットアップのタイミング（after_setup_theme）で実行します

function ebiz_register_custom_block_patterns() {
// まず独自のパターンカテゴリーを登録します
register_block_pattern_category(
'ebiz-corporate',
array( 'label' => 'コーポレート用レイアウト' )
);

// 次に具体的なパターンを登録します
register_block_pattern(
'ebiz/hero-section',
array(
'title'       => 'メインビジュアルセクション',
'description' => '画像とテキストを重ねたヒーローエリアです',
'categories'  => array( 'ebiz-corporate' ),
// エディターからコピーしたブロックのHTMLをcontentに記述します
'content'     => '<div class="wp-block-group"><div class="wp-block-group__inner-container is-layout-constrained wp-block-group-is-layout-constrained"><h2 class="wp-block-heading">メインタイトル</h2></div></div>',
)
);
}
add_action( 'init', 'ebiz_register_custom_block_patterns' );

5. 納品後の保守性を高めるフルサイト編集での編集権限コントロール

FSE（フルサイト編集）を実際の案件に導入する際、最も頭を悩ませるのが「クライアントの編集権限をどこまで許可するか」という問題ではないでしょうか。 フルサイト編集は、ブロックエディターでサイト全体を編集できる画期的な機能ですが、裏を返せば「クライアントが誤ってサイト全体のレイアウトを壊してしまうリスク」を抱えていることになります。実際の制作現場でも、「納品後にヘッダーが消えてしまった」というご相談をいただくことが増えてきました。 ここでは、実務で採用している具体的な権限コントロールの方法をシェアします。

theme.jsonを活用したブロック単位の制限

{
"version": 2,
"settings": {
"color": {
"custom": false, // カスタムカラーパレットを無効化
"customGradient": false // カスタムグラデーションを無効化
},
"typography": {
"customFontSize": false, // 任意のフォントサイズ指定を無効化
"dropCap": false // ドロップキャップ機能を無効化
},
"layout": {
"contentSize": "800px",
"wideSize": "1200px"
}
}
}

functions.phpでのエディター機能の制限

/
 編集者権限のユーザーに対して、フルサイト編集メニューを非表示にする

 どこに書くか：functions.php
 いつ動くか：管理画面のメニュー読み込み時（admin_menuフック）
/
function restrict_fse_menu_for_editors() {
// 現在のユーザーが「管理者（administrator）」でない場合
if ( ! current_user_can( 'manage_options' ) ) {
// サイトエディターのメニューを取り除く
remove_submenu_page( 'themes.php', 'site-editor.php' );
}
}
add_action( 'admin_menu', 'restrict_fse_menu_for_editors' );

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

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