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

最近のWeb制作案件で、「フルサイト編集のテーマを使う場合、子テーマは作ったほうがいいのでしょうか？」というご相談をよくいただきます。

クラシックテーマの時代は、親テーマを継承しつつ独自のカスタマイズを安全に行う仕組みである子テーマ（child theme）を作成するのが定番のフローでした。しかし、ブロックエディターでサイト全体を編集できるフルサイト編集（FSE）が普及した現在、その前提が少しずつ変化してきています。

以前、ある企業サイトのリニューアル案件でブロックテーマを導入した際、カスタマイズのファイル構成や保守の考え方で迷う場面がありました。その実体験を踏まえて、現在のWordPress環境に合わせたテーマ運用のあり方を整理してシェアします。

この記事を読むことで、長期的に運用しやすいテーマ設計と、移行タイミングの判断基準が明確になります。

■ この記事でわかること
・フルサイト編集における子テーマの必要性と役割
・実案件でブロックテーマを選ぶ際のメリットと注意点
・安全にカスタマイズを管理するためのファイル構成
・クラシックテーマから移行するべきかどうかの判断基準
・保守性を高めるテーマ運用の具体的な考え方

1. フルサイト編集時代における子テーマの役割と必要性を再確認します

FSEが導入されたテーマ（ブロックテーマ）では、サイトエディターを通じてヘッダーやフッター、各種テンプレートを直感的にカスタマイズできるようになりました。これにより、ちょっとしたデザイン変更やレイアウト調整であれば、コードを直接触る必要がなくなっています。

しかし、実務において子テーマ（親テーマを継承しつつ独自のカスタマイズを安全に行う仕組み）が完全に不要になったわけではありません。機能の追加や複雑な処理を実装する場合、やはりファイルベースでの管理が求められます。

以前、管理画面のサイトエディターだけで完結させようとした案件がありました。初期構築はスムーズでしたが、運用フェーズに入ってからクライアント側で誤ってテンプレートをリセットしてしまい、独自のスタイルが初期化されるというトラブルが発生しました。この経験から、デザインの根幹に関わる部分や、上書きされたくない独自の関数（functions.php：テーマの機能を追加・カスタマイズするファイルでの処理など）は、依然として子テーマに分離して管理する方針をとっています。

FSE環境下でのカスタマイズは、大きく分けて「データベースに保存される変更（サイトエディター経由）」と「ファイルとして保存される変更（子テーマ経由）」の2種類が存在します。親テーマのアップデートによって上書きされるリスクを回避し、プロジェクト全体の保守性を高めるという目的において、子テーマの存在意義は今も健在です。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSEでの子テーマ運用 | 独自のPHP処理を追加する場合、デザインの初期化を防ぎたい場合 | 既存ブロックの簡単な配置変更のみで運用する場合 |

2. 実案件から見えたブロックテーマのメリットと注意点について

ブロックテーマを実際のクライアントワークに導入していく中で、従来のクラシックテーマとは異なる明確なメリットと、実務ならではの注意点が見えてきました。FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を活用した構築は、今後のWeb制作において重要な選択肢になります。

まず大きなメリットとして挙げられるのが、開発スピードの向上と運用時の柔軟性です。従来はPHPファイル（header.phpやfooter.phpなど）を直接編集する必要があったヘッダーやフッターの改修が、エディター画面から直感的に行えるようになりました。これにより、納品後の軽微なデザイン変更であれば、コードを書かずに対応できる場面が増えています。

しかし、この「どこでも編集できる」という自由度の高さが、実務においては両刃の剣になることもあります。

正直にお伝えすると、ブロックテーマの導入初期には運用上の課題に直面しました。クライアントに管理者権限をお渡ししたところ、記事の更新をおこなう感覚で意図せずテンプレート自体を編集してしまい、サイト全体の共通レイアウトが崩れてしまうというトラブルが起きたのです。クラシックテーマでは起こりにくい、FSEならではの課題でした。

この経験から、現在の案件では「theme.json」という設定ファイルを綿密に作り込むことをデフォルトの工程にしています。theme.jsonはブロックテーマのスタイルや機能を一元管理するファイルで、ここで特定の色やフォントサイズの設定を制限したり、ブロックのロック機能を活用したりすることで、クライアントが安全に運用できる枠組みを作ることが可能です。

実案件でブロックテーマを採用するかどうかは、以下の基準で判断しています。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| ブロックテーマ（FSE）の採用 | 納品後にお客様自身で柔軟にレイアウトを調整したい場合 | ブランド規定が厳しく、デザインの厳密な固定が必要な場合 |

長期的な保守性やWordPressの開発の方向性を考慮すると、ブロックテーマの重要性が高まっていくことは間違いありません。ですが、すべての案件に適合するわけではありません。迷ったときは「クライアントの更新頻度」と「運用担当者のリテラシー」を軸に、どこまで自由度を持たせるかを設計の初期段階で協議しておくと、その後の進行が非常にスムーズに整理しやすいです。

3. カスタマイズを安全に管理するための実践的なファイル構成例

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの機能）を導入したプロジェクトにおいて、子テーマ（親テーマを継承しつつ独自のカスタマイズを安全に行う仕組み）のファイル構成をどう設計するかは、その後の保守性に大きく関わります。

実際の案件で試行錯誤した結果、現在私たちのチームで基準としている実践的なファイル構成例をシェアします。

実務で活用している子テーマの基本構造

FSE対応の親テーマ（例として公式のTwenty Twenty-Fourなどを想定）を利用する場合、子テーマのディレクトリ内は以下のように必要最小限の構成にとどめるのが基本です。

“`text
my-fse-child/
├── style.css // テーマの宣言と独自のCSS（最小限に留める）
├── functions.php // 独自のPHP処理（フックの追加など）
├── theme.json // 親テーマの設定を上書き・拡張するコアファイル
├── parts/ // 独自のテンプレートパーツ（ヘッダーやフッターなど）
│ └── custom-header.html
└── templates/ // 独自のページテンプレート
└── custom-page.html
“`

クラシックテーマの時代は、親テーマのPHPファイルを丸ごと子テーマにコピーして修正する手法が一般的でしたが、FSEではそのアプローチは推奨されません。代わりに、`theme.json`とブロックテンプレート（`.html`ファイル）を活用してカスタマイズを管理します。

theme.jsonを中心としたスタイル管理

FSE環境におけるスタイリングの主導権は、`style.css`から`theme.json`へと移行しています。`theme.json`を使用することで、エディター側とフロント側の両方に一貫したデザインルール（カラーパレット、タイポグラフィ、余白など）を適用できます。

以下は、子テーマの`theme.json`で親テーマのカラーパレットを拡張する場合の記述例です。

“`json
{
“$schema”: “https://schemas.wp.org/trunk/theme.json”,
“version”: 2,
“settings”: {
“color”: {
“palette”: [
{
“slug”: “brand-primary”,
“color”: “#005baa”,
“name”: “ブランドメインカラー”
}
]
}
}
}
“`

この設定を追加することで、親テーマの設定を引き継ぎつつ、ブロックエディターのカラー選択パネルに独自の「ブランドメインカラー」を追加できます。

なぜこの構成を基準にするのか

この構成が推奨される理由は、コアや親テーマのアップデートに対する堅牢性にあります。内部的な仕組みとして、WordPressはまず子テーマの`theme.json`を読み込み、不足している設定を親テーマ、そしてWordPressコアの順にフォールバック（代替）してマージします。

つまり、変更したい部分だけを子テーマに記述しておけば、親テーマの大規模なアップデートがあった際にも、自前で構築したレイアウトやスタイルが破壊されるリスクを最小限に抑えることができるからです。

以前の案件で経験した失敗談

正直に言うと、FSEが登場したばかりの頃、従来のクラシックテーマと同じ感覚で`style.css`に大量のCSSを記述してデザインを上書きしようとしたことがありました。しかし、WordPressのアップデートによってコアブロックの出力するHTML構造やデフォルトのCSSクラスが変更され、画面が大きく崩れるというトラブルに直面しました。

それ以来、スタイルの制御は可能な限り`theme.json`とブロックの設定パネルに委ね、どうしてもエディターで表現できない特殊なアニメーションや複雑な疑似要素のみを`style.css`に切り出すというルールに切り替えました。

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

このファイル構成と管理アプローチについて、適用を検討する際の判断基準を整理します。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| theme.json中心の構成 | ブロックエディターの標準機能を最大限活用したい場合 | PHPによる複雑な条件分岐で出力するHTMLを細かく制御したい場合 |
| HTMLテンプレート | ノーコードでのレイアウト微調整を顧客に許可する場合 | 従来のPHPテンプレート階層に依存した既存の重いシステムがある場合 |

長期的な保守性を考慮した判断

長期的に見て、WordPressの方向性は明らかにブロックベースとFSEに舵を切っています。開発も継続して活発に行われており、メジャーアップデートのたびにエディターの機能が拡充されています。

そのため、新規案件においては、この`theme.json`とHTMLテンプレートを軸とした子テーマ構成を採用することで、将来的な機能拡張の恩恵を受けやすくなります。迷ったときは、「エディターでできることはエディター（またはtheme.json）で解決し、コード（PHP/CSS）は最終手段にする」という判断基準を持っておくと、保守性の高いサイトを構築しやすくなります。

4. クラシックテーマからフルサイト編集へ移行する際の判断基準

従来のPHPベースのクラシックテーマから、FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）へ移行するかどうかは、実務において頻繁に直面する悩ましいポイントです。
実際の案件でも、お客様や開発チーム内で「そろそろフルサイト編集に切り替える時期でしょうか」という議論がよく起こります。ここでは、実案件で採用を見送ったケースと、積極的に採用したケースを交えて、その判断基準をシェアします。

移行を推奨するプロジェクトの傾向

新規立ち上げのサイトで、運用担当者自身がレイアウトを柔軟に変更したいという要望が強い場合は、FSEが非常に適しています。ブロックテーマを利用することで、ヘッダーやフッターといった共通パーツもエディター画面から直感的に編集できるためです。
また、開発側にとっても、theme.json（テーマのスタイルや設定を一元管理する設定ファイル）を活用することで、CSSの記述量を大幅に削減し、グローバルなスタイル管理がしやすくなるというメリットがあります。

実案件での判断の分かれ道

以前、情報量が非常に多いメディアサイトのリニューアル案件を担当した際、FSEとクラシックテーマのどちらを採用するかで迷いました。最終的にクラシックテーマを継続して選んだ理由は、独自のカスタムフィールドを多用しており、複雑な条件分岐による細かなテンプレート出力が必須だったためです。
FSEはレイアウトの柔軟性が高い一方で、PHPによる高度な動的制御をブロックとして実装しようとすると、かえって独自ブロック開発の工数が膨らんでしまう傾向があります。

移行をやめた方がいいケースと注意点

既存のサイトにおいて、独自の機能を持たせたfunctions.php（テーマの機能を追加・カスタマイズするファイル）の記述が多岐にわたる場合や、利用している必須プラグインがFSEの構造に完全対応していない場合は、無理な移行はおすすめしません。
そうしたケースでは、代替案としてハイブリッドテーマ（クラシックテーマをベースにしつつ、部分的にtheme.jsonやブロックテンプレートを取り入れる手法）を採用するのが、より安全で現実的な選択となります。

フルサイト編集への移行判断まとめ

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| フルサイト編集の導入 | お客様自身で全体のレイアウトを変更したい場合 | 複雑なPHPの条件分岐や高度な動的出力が必要な場合 |

保守性と将来性を考慮すると、WordPress本体の開発は明らかにFSEを中核とした方向へ進んでいます。そのため、新規案件においてはFSEを前提とした設計を段階的に取り入れていくのが望ましいですが、既存サイトの移行については、現在の運用フローと必要な機能のバランスを冷静に見極めて判断してみてください。迷ったときは、無理にすべてをブロック化するのではなく、運用者がどこまで編集権限を求めているかを基準に整理すると、答えが出やすくなります。

5. 長期的な保守性を高めるテーマ運用の具体的な考え方

WordPressのテーマ運用において、初期構築のしやすさだけで構成を決めてしまうと、数年後のメンテナンスで頭を抱えることになります。特にFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）と従来の子テーマ（親テーマを継承しつつ独自のカスタマイズを安全に行う仕組み）をどう組み合わせるかは、実務において非常に重要な判断ポイントです。

以前、ある中規模な企業サイトの保守を引き継いだ際、親テーマのテンプレートファイルが直接書き換えられており、WordPress本体やテーマのアップデートができないという問題に直面しました。その時の苦い経験から、現在では明確な運用ルールを設けています。

長期的な保守性を確保するために、実務では以下のように運用ルールを定めています。

・ PHPによる複雑な機能追加が必要な場合は子テーマを利用する
・ デザインやレイアウトの微調整のみであれば、FSEの機能を活かしてエディター上で完結させる
・ functions.php（テーマの機能を追加・カスタマイズするファイル）に記述するコードは、テーマに依存する機能のみに留め、サイト固有の機能は独自プラグインとして切り出す

この書き方や運用方針を案件のデフォルトにしています。理由は、将来的にテーマを変更した際にも、重要な機能が失われるリスクを回避できるためです。WordPressの方向性として、デザインはブロックテーマで、機能はプラグインでという役割分担が明確になってきている点も、この判断を後押ししています。

ここで、よくある間違いとして挙げられるのが、FSE環境下で不要なテンプレートファイルまで子テーマにコピーしてしまうことです。ブロックテーマでは、HTMLベースのテンプレートがエディターから上書きできるため、ファイルとして子テーマに持たせると、どちらが優先されているのか管理が複雑になり、予期せぬ表示崩れの原因になります。

運用アプローチについて、向いているケースと向いていないケースを整理しました。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| FSE単体での運用 | デザインの変更が主で、複雑なPHP処理を伴わない場合 | 独自のカスタム投稿やAPI連携など、高度なバックエンド処理が必要な場合 |
| 子テーマを併用した運用 | 既存のテーマ構造を活かしつつ、フックを利用した機能拡張が必要な場合 | 定期的なメンテナンスを行う技術担当者が不在の場合 |

迷ったときは、「そのカスタマイズはデザイン（見た目）の変更か、機能の追加か」で切り分けて考えると整理しやすいです。機能の追加であれば子テーマや独自プラグインへ、見た目の変更であればFSEのエディター機能で対応するという基準を持つことで、将来のアップデートに強いサイトを構築できます。