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

最近のWeb制作案件において「フルサイト編集（FSE）で構築してほしい」というご要望や、「Gutenbergのブロックエディターをもっと柔軟にカスタマイズしたい」というご相談をいただくことが増えてきました。

実際の現場でブロックテーマを採用するべきか、それとも従来のクラシックテーマで進めるべきか、制作フローの選定に迷われている方も多いのではないでしょうか。FSEは画面上でサイト全体を直感的に編集できる強力な機能ですが、案件の要件やクライアントの運用体制によっては、あえて導入を見送ったほうが良いケースも存在します。

この記事では、実務の現場でフルサイト編集やGutenbergをどのように取り入れ、theme.jsonを活用してデザインを管理しているのか、実案件での経験をもとにしたカスタマイズ手法をシェアします。プロジェクトに合った適切なテーマ設計ができるよう、長期的な保守性を見据えた判断基準をお届けします。

■ この記事でわかること
・フルサイト編集（FSE）を実案件に導入するための明確な判断基準がわかります
・theme.jsonを使った効率的なデザインの一元管理方法がわかります
・運用保守を見据えた独自ブロックの開発とコード管理の手法がわかります
・クラシックテーマとブロックテーマを案件ごとに使い分ける視点がわかります

1. フルサイト編集の基本概念と実案件における導入の判断基準

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）は、従来のテーマ開発のあり方を根本から変える仕組みです。
これまでPHPファイルで制御していたヘッダーやフッター、アーカイブページなどのテンプレート階層も含め、サイト内のあらゆる要素をブロックとして直感的に構築・管理できるのが最大の魅力です。

しかし、実案件においてすべてのサイトをフルサイト編集で構築すべきかというと、実際のところそうではありません。実務では「何ができるか」だけでなく、「クライアントが安全に運用できるか」という視点が非常に重要になります。

以前、更新頻度が非常に高いオウンドメディアの案件で、サイト全体をフルサイト編集で構築したことがありました。直感的に編集できる点は好評だったのですが、運用担当者様が誤って全ページ共通のヘッダーテンプレートを編集してしまい、サイト全体のレイアウトが意図せず崩れてしまうというトラブルが発生しました。
この経験から、運用者のリテラシーや管理体制に合わせて、あえて編集できる領域を制限するクラシックテーマ（従来のPHPベースのテーマ）での構築や、ハイブリッドテーマを選択肢に含めるようにしています。

長期的な保守性や将来性を考えると、WordPress.orgが主導する今後の開発のコアは間違いなくフルサイト編集とGutenbergにあります。そのため、新規構築の際は少なくともブロックエディターを活用した運用を前提に設計することが推奨されます。

迷ったときは、まずは固定ページや投稿のコンテンツエリアのみをブロックエディターで柔軟に構築し、ヘッダーやフッターなどの共通部分はクラシックテーマで堅牢に守る、という段階的なアプローチから検討すると整理しやすいです。正解は一つではないため、プロジェクトの要件と運用体制を見極めて最適な形を選択してみてください。

2. Gutenbergを活用した効率的なページ構築とカスタマイズの実践

実際のWeb制作の現場でブロックエディターを本格的に導入する際、運用担当者から「自由すぎてデザインが崩れてしまう」というご相談をよく受けます。
Gutenberg（WordPress標準のブロックベースの編集画面）は非常に多機能ですが、実務においてはすべての自由度を渡すのではなく、あらかじめ設定したルールの中で運用していただく設計が求められます。

今回は、既存のブロックに独自のスタイルを追加し、運用しやすくする手法をシェアします。
以下のコードをテーマのfunctions.php（テーマの機能を追加・カスタマイズするファイル）に記述することで、エディター上に専用のスタイル選択ボタンを追加できます。

// functions.phpに記述します
// init（WordPress初期化時のアクションフック）で独自のブロックスタイルを登録します
add_action( 'init', 'ebiz_register_custom_block_styles' );

function ebiz_register_custom_block_styles() {
// WordPress標準の引用ブロックに新しいスタイルを追加します
register_block_style(
'core/quote',
array(
'name'       => 'highlight-quote', // CSSクラスとして出力される名前
'label'      => 'ハイライト引用',     // エディター上に表示されるラベル
'is_default' => false,             // デフォルト設定にはしない
)
);
}

このコードを適用すると、編集画面で引用ブロックを選択した際、スタイル設定のパネルに「ハイライト引用」という選択肢が増えます。
なぜわざわざPHPでスタイルを登録するアプローチをとるかというと、運用者にCSSのクラス名を手動で入力していただくよりも、ボタンとして視覚化することで入力ミスを防げるからです。また、内部的には指定した名前がそのままCSSのクラスとして付与されるだけなので、将来的にデザインを変更する際もstyle.cssを調整するだけで済みます。

正直に言うと、以前はページごとに専用のカスタムブロックを一から開発していました。
しかし、大規模なコーポレートサイトの案件で、ブロックの種類が多すぎて運用担当者がどれを使えばいいか迷ってしまい、結果的にページごとのデザインの統一感が失われるというトラブルを経験しました。
その経験から、現在では「既存の標準ブロックに対して専用のスタイルを追加し、必要最小限の選択肢を提供する」という方針をデフォルトにしています。

ブロックエディターの拡張カスタマイズについて、判断の目安を整理しました。

長期的な保守性を考えると、特定のページビルダープラグインに過度に依存せず、WordPress本体の開発方針に沿ってGutenbergの標準機能を拡張していくアプローチが推奨されます。
アップデートによる予期せぬレイアウト崩れを防ぐためにも、迷ったときはまず「標準ブロックの拡張で要件を満たせないか」を検討すると、安定したサイト運用につながります。

3. theme.jsonを用いたデザインの一元管理と現場での設定事例

フルサイト編集（FSE）を前提としたブロックテーマの構築において、デザインルールの根幹となるのが「theme.json」です。従来はstyle.cssに記述していたカラーパレットやタイポグラフィなどのベーススタイルを、このファイル一つで一元管理できるようになりました。

実際の案件でも、theme.jsonを正しく設定しておくことで、エディター上でのデザインのブレを防ぎ、運用フェーズでのクライアントの負担を大きく軽減できます。ここでは、実務で頻繁に使用する設定事例とともに、なぜこの仕組みが必要なのかを紐解いていきます。

theme.jsonの基本構造と実務での活用

theme.jsonは、テーマのルートディレクトリに配置するJSON形式のファイルです。大きく分けて「settings（エディターの設定とプリセット）」「styles（実際のCSS出力設定）」「templateParts（テンプレートパーツの定義）」などのセクションで構成されます。

実務で特によく設定するのが、クライアントがエディターで使用できる「カラーパレット」の制限と追加です。独自のブランドカラーを設定し、デフォルトの不要な色を無効化するコードをご紹介します。

/<strong> 配置場所: テーマのルートディレクトリ（theme.json） </strong>/
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"color": {
/<strong> デフォルトのカラーパレットを無効化 </strong>/
"defaultPalette": false,
/<strong> ユーザーによるカスタムカラーのピッカーを無効化 </strong>/
"custom": false,
/<strong> 独自のカラーパレットを定義 </strong>/
"palette": [
{
"slug": "brand-primary",
"color": "#0056b3",
"name": "メインカラー"
},
{
"slug": "text-base",
"color": "#333333",
"name": "基本テキスト色"
}
]
}
}
}

この設定を行うと、ブロックエディターの色選択パネルには「メインカラー」と「基本テキスト色」のみが表示されます。カスタムカラーの入力も無効化しているため、サイトのトンマナ（トーン＆マナー）を維持しやすくなります。

なぜCSSではなくtheme.jsonで管理するのか

「CSSで色やフォントを指定すれば済むのではないか」と疑問に思われるかもしれません。従来のクラシックテーマではそれが一般的でした。しかし、theme.jsonで管理することが推奨される理由は、WordPressが内部で自動的にCSSカスタムプロパティ（変数）やエディター用のユーティリティクラスを生成してくれる点にあります。

例えば、先ほどのカラーパレットを設定すると、フロントエンドとエディターの両方に自動で以下のようなCSS変数が読み込まれます。

`–wp–preset–color–brand-primary: #0056b3;`

これにより、ブロックエディター上でのプレビューと、実際の公開側（フロントエンド）のデザインが完全に一致します。エディター用のスタイルシートを別途用意して同期させる手間が省けるため、開発効率が大きく向上します。

実案件での失敗談と改善策

以前、コーポレートサイトの案件で、theme.jsonの理解が浅く、従来のやり方通りにstyle.cssでブロックのスタイルを強力なセレクタ（`!important`など）で上書きしてしまったことがありました。その結果、クライアントがエディター上で余白や文字サイズを変更しても、フロント側には反映されないというトラブルが発生しました。

ブロックテーマでは、「エディターでの操作を尊重する」という思想が根底にあります。ベースのデザインルールはtheme.jsonで定義し、CSSでの上書きは極力避ける、あるいはtheme.jsonの「styles」プロパティを介してブロックごとのデフォルトスタイルを設定するアプローチに変更しました。それ以降は、エディターの挙動と表示の乖離による問い合わせは劇的に減少しています。

保守性と将来性を考慮した判断基準

WordPressの開発方針は、フルサイト編集を軸としたブロックベースの設計へとシフトしています。そのため、新しくテーマを構築、あるいはリニューアルする際は、theme.jsonを中心とした設計を取り入れることが、中長期的な保守性の観点から非常に有効です。

WordPressのメジャーアップデートによりブロックの構造が変わった場合でも、theme.jsonでスタイルを抽象化して管理していれば、影響を最小限に抑えることができます。

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

デザインのルールをシステム側で統制し、運用時の品質を保つために、theme.jsonは非常に強力な仕組みです。設定項目が多く最初は戸惑うかもしれませんが、公式のスキーマ定義（`$schema`）をエディタに読み込ませることで、オートコンプリートが効き、効率的に記述を進めることができます。

4. 運用保守を見据えた独自ブロックの開発手法と適切なコード管理

独自ブロックの開発は、フルサイト編集（ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入する際、もっとも判断に迷うポイントの一つです。実際の案件でも、クライアントから独自のレイアウトや入力フォーマットを求められるケースは頻繁に発生します。

その際、開発手法をどう選ぶかで、数年後の運用保守のコストが大きく変わります。実務では主に、Advanced Custom Fields PROを使用した開発と、WordPress公式ツールであるCreate Blockを使用したネイティブ開発の2つの選択肢があります。

正直に言うと、以前は納期の短い案件でAdvanced Custom Fields PROを多用していました。PHPの知識だけで素早くブロックを作れるため、手軽に導入できたからです。しかし、WordPress本体のアップデートに伴う仕様変更や、Reactベースのネイティブな挙動との差異によるトラブルに直面し、現在では要件によって明確に手法を分けています。

長期的な保守性や表示速度を重視する場合、うちではCreate Blockを用いたネイティブ開発をデフォルトにしています。内部仕様として、React（ユーザーインターフェースを構築するためのJavaScriptライブラリ）を用いてエディター側の挙動を制御し、静的なHTMLとして出力されるため、フロントエンドのパフォーマンスが圧倒的に高くなるからです。

以下は、Create Blockを用いてブロックを登録する際の基本的なコード例です。

// src/index.js（ブロックの登録を行うメインファイル）
import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps } from '@wordpress/block-editor';
import './style.scss'; // フロント・エディター共通のスタイル
import './editor.scss'; // エディター専用のスタイル

registerBlockType( 'ebiz-create/custom-box', {
edit: function () {
// エディター側での表示を制御する関数
const blockProps = useBlockProps();
return (
<div { ...blockProps }>
<p>カスタムボックスブロック（編集画面）</p>
</div>
);
},
save: function () {
// フロント側へ出力するHTMLを生成する関数
const blockProps = useBlockProps.save();
return (
<div { ...blockProps }>
<p>カスタムボックスブロック（公開画面）</p>
</div>
);
},
} );

この書き方が推奨される理由は、エディターの表示（edit）と実際の出力（save）を明確に分離できる点にあります。WordPressの公式ドキュメント（https://wordpress.org）に準拠したこの構成にすることで、将来的なメジャーアップデートの影響を受けにくくなります。

ここで、開発手法の選定基準を表に整理します。迷ったときはこう考えると整理しやすいです。

ネイティブ開発を行う際、よくある間違いがビルドツールを自前で複雑に設定してしまうことです。Webpackなどの設定に時間をかけるよりも、公式の@wordpress/scriptsを使用する方が、WordPress本体の開発方針に追従しやすく、コード管理がシンプルになります。

長期的に見て、WordPressはブロックエディター中心の設計へ完全に移行しています。保守性を考慮するなら、可能な限りネイティブなブロック開発手法を取り入れることが、将来的な技術的負債を減らす鍵となります。

Web制作に関する技術的な選定や、運用を見据えたWordPress構築のご相談はお気軽にeBIZクリエイトまでお問い合わせください。

5. 従来のクラシックテーマとブロックテーマの使い分け方と将来的な展望

実際のWeb制作の現場で、お客様からテーマ選定についてご相談いただくことが増えています。とくに、従来のPHPベースで作られたクラシックテーマと、サイト全体をブロックエディターで構築できるブロックテーマのどちらを選ぶべきかというご質問です。

この記事では、実務の現場で私たちがどのようにテーマの使い分けを判断しているのか、その基準と将来への見通しをシェアします。

■ クラシックテーマとブロックテーマの基本的な違い
まずは前提として、2つのテーマの違いを整理します。クラシックテーマは、PHPファイル（header.phpやfooter.phpなど）を組み合わせてサイトの骨組みを作る、長年使われてきた手法です。一方、ブロックテーマはHTMLファイルとtheme.jsonという設定ファイルを中心に構成され、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用して構築します。

■ 実務での使い分けの判断基準
実際の案件で私たちがどちらを採用しているかをお伝えします。結論から言うと、プロジェクトの目的と運用体制によって明確に分けています。

クラシックテーマを選ぶのは、複雑なデータベース連携が必要な場合や、カスタムフィールドを多用して入力フォーマットを厳密に固定したい場合です。PHPによる柔軟な制御が可能なため、高度なシステム要件があるサイトに向いています。

ブロックテーマを選ぶのは、運用担当者様がノーコードで柔軟にレイアウトを変更したいというご要望がある場合です。ランディングページを頻繁に作成するメディアサイトや、デザインの自由度を社内で持たせたい企業のコーポレートサイトなどで採用しています。

■ なぜそのような使い分けになるのか
この判断基準になる理由は、それぞれの内部構造にあります。クラシックテーマは、開発者がPHPで出力内容を完全にコントロールできるため、予期せぬレイアウト崩れを防ぎやすいという特徴があります。これは、入力者がコンテンツの中身だけに集中できるという運用上のメリットにつながります。

一方ブロックテーマは、theme.jsonというファイルでサイト全体の色やタイポグラフィなどのグローバルスタイルを一元管理しつつ、エディター上での直感的な操作を実現しています。ただし、自由度が高い分、運用者がブロックの仕様を理解していないと、サイト全体のデザインの統一感を損なうリスクもはらんでいます。

■ 実案件でのテーマ選定エピソード
以前、定期的にキャンペーンページを立ち上げる企業様のサイトリニューアルを担当しました。クラシックテーマで固定テンプレートを用意するか、ブロックテーマを導入するかで迷いましたが、最終的にブロックテーマを選びました。

理由は、キャンペーンごとに必要な構成（ヒーローエリアの有無やカラム構成）が大きく異なり、開発側に都度テンプレートの作成を依頼する時間的コストが課題となっていたからです。ブロックテーマの導入により、運用チーム主導でスピーディにページを公開できる体制を構築できました。

■ 向いているケース・向いていないケースまとめ
テーマ選定で迷った際は、以下の表を参考にしてみてください。

■ 将来的な展望と保守性について
長期的な視点で見ると、WordPressの公式開発チームはブロックテーマとFSEの機能拡充に注力しています。そのため、新機能の恩恵を受けやすいのは間違いなくブロックテーマです。

しかし、クラシックテーマがすぐに使えなくなるわけではありません。世界中の膨大な数のサイトがクラシックテーマで稼働しており、後方互換性は維持され続けます。現に、実務ではクラシックテーマのアップデートや保守案件も数多く動いています。将来性を重視しつつも、目の前のプロジェクトの要件にどちらが適しているかを冷静に見極めることが大切です。

テーマ選定は、サイトの寿命と日々の運用コストに直結します。自社の運用体制に合った最適なアプローチを見つける手がかりにしていただければ幸いです。

Web制作におけるテーマ選定や運用を見据えたサイト構築のご相談はお気軽にeBIZクリエイトまでお問い合わせください。