WordPressの子テーマとは？仕組み・使い方・判断基準を具体的に解説

WordPressのテーマを少しだけ変えたいとき、「親テーマを直接編集してよいのか」「子テーマを作るべきなのか」で迷う方は少なくありません。結論から言うと、テーマのPHP、CSS、テンプレートファイルへ継続的な変更を加えるなら、子テーマは有力な選択肢です。一方、管理画面だけで完結する色や余白の調整まで、必ず子テーマにする必要はありません。

判断の軸は、変更量の多さではなく、変更がどこに保存されるかです。親テーマ内のファイルを書き換えると、テーマ更新時に配布元のファイルで置き換えられる可能性があります。子テーマなら、親テーマの機能とデザインを利用しながら、自分の変更を別フォルダーに分けて管理できます。ここでは、子テーマが必要になる場面から作成、有効化、更新後の確認までを、実際の作業順に整理します。

子テーマ：子テーマが必要になる場面

子テーマは、親テーマを土台として動く独立したテーマです。親テーマのファイル一式を複製する仕組みではありません。子テーマ側に存在しない機能やテンプレートは親テーマから利用し、必要な部分だけを子テーマ側で追加または上書きします。そのため、親テーマの更新を受け取りながら、独自変更を分離しやすくなります。

親テーマ更新と直接編集の問題

たとえば、利用中の親テーマにある single.php を開き、記事下へ独自の案内を追加したとします。表示はすぐ変わりますが、その変更場所は親テーマの配布ファイル内です。後日テーマを更新すると、新しい single.php が配置され、自分の変更が消える可能性があります。更新を避ければ変更は残りますが、修正やセキュリティ対応も受け取れなくなるため、安全な解決にはなりません。

子テーマへ必要なテンプレートだけを置けば、親テーマと自分の変更を別々に管理できます。どこを変更したのかも追いやすく、バックアップや別環境への再現もしやすくなります。ただし、子テーマを使えば自動的に互換性が保証されるわけではありません。親テーマのHTML構造、関数、フックが更新で変われば、子テーマ側の上書きが古くなることがあります。

子テーマが特に向くのは、テンプレートファイルの変更、独自PHP処理の追加、複数のCSSファイルを含む継続的なデザイン調整、テーマ固有フックを使った表示変更です。反対に、記事本文、固定ページ、メニュー項目など、WordPressのコンテンツとして保存される情報を守るために子テーマを作る必要はありません。子テーマはサイト全体のバックアップでも、データベースの復元機能でもない点を押さえてください。

サイトエディターや追加CSSとの使い分け

ブロックテーマでは、「外観→エディター」からテンプレート、ヘッダー、フッター、スタイルを調整できます。この変更の多くはデータベースへ保存されるため、親テーマのPHPファイルを直接書き換える操作とは性質が異なります。サイトエディターで目的を達成できるなら、子テーマを作らずに済むこともあります。

「外観→カスタマイズ→追加CSS」が利用できるテーマでは、小さなCSS調整を管理画面に保存できます。数行の色変更や余白調整なら手軽ですが、コード量が増えると変更理由や影響範囲を追いにくくなります。複数人で管理する、別サイトへ再利用する、Gitなどで差分を残す場合は、子テーマのCSSファイルへ分離した方が保守しやすくなります。

プラグインへ置くべき処理もあります。テーマを変更しても残すべき独自投稿タイプ、外部API連携、業務データ処理、ショートコードなどは、見た目を担う子テーマよりサイト固有プラグインへ分ける方が安全です。「テーマを変更したら、この機能も消えてよいか」と考えると判断しやすくなります。消えて困る機能は、原則としてテーマから切り離します。

子テーマの基本構成

WordPress公式のChild Themesでは、子テーマ用フォルダーを作り、最低限の情報を持つ style.css を用意する流れが説明されています。作業は本番サーバーで直接始めず、ローカル環境またはステージング環境で行うと、記述ミスで公開画面が止まるリスクを抑えられます。

フォルダーとstyle.cssを用意する

親テーマのフォルダー名が sample-parent なら、子テーマは sample-parent-child のように、役割が分かる名前にします。設置先は親テーマと同じ wp-content/themes/ の配下です。子テーマの style.css には、少なくともテーマ名と親テーマを示す情報を記述します。

/*
Theme Name: Sample Parent Child
Template: sample-parent
Version: 1.0.0
*/

Template には、親テーマの表示名ではなくフォルダー名を正確に指定します。大文字小文字、ハイフン、スペースの違いも確認してください。ここが一致しないと、WordPressは必要な親テーマを見つけられず、子テーマを正しく有効化できません。親テーマのZIP名と展開後のフォルダー名が違う製品もあるため、サーバー上の実名を確認するのが確実です。

子テーマのCSSがどのように読み込まれるかは親テーマの実装によって異なります。古い解説で見かける @import を機械的に追加せず、親テーマの公式マニュアルと実際の読み込み状態を確認してください。必要なら子テーマの functions.php から wp_enqueue_style() を使い、親子のスタイル依存関係とバージョンを明示します。二重読み込みになっていないかは、ブラウザーの開発者ツールにあるNetworkまたはSourcesで確認できます。

functions.phpとテンプレートを追加する

子テーマの functions.php は、親テーマの同名ファイルを置き換えるものではありません。子テーマと親テーマの両方が読み込まれるため、親テーマにある関数を同じ名前でそのまま再定義すると、致命的エラーになることがあります。独自の接頭辞を付け、既存フックの有無と実行順を確認して追加してください。

テンプレートは扱いが異なります。WordPressが同じ役割のテンプレートを探すとき、子テーマに該当ファイルがあれば、親テーマ側より子テーマ側が優先されます。変更したいファイルだけを親テーマから子テーマへコピーし、必要箇所を編集します。親テーマ一式を複製すると、更新で改善されたテンプレートを受け取れず、古いコードが大量に残るため避けます。

コピー元のファイルには手を加えず、どの親テーマ版から複製したかを作業記録へ残します。テンプレートの先頭コメントだけでは差分の理由が分からないため、「記事下CTAを追加」「見出し階層を変更」のように目的も記録します。PHPへ外部入力を表示する場合は、WordPressのサニタイズ、検証、文脈に合ったエスケープを使い、見た目の変更だからとセキュリティ確認を省略しないでください。

安全に有効化する手順

ファイルを作れた時点では完成ではありません。親テーマとの対応、PHP構文、管理画面、公開画面を確認して初めて有効化できます。特に運用中サイトでは、有効化直後にロゴ、メニュー、ウィジェット、テンプレート設定が変わる可能性を考え、戻せる状態を先に作ります。

親テーマとバックアップを確認する

最初に、現在の親テーマ名、フォルダー名、バージョン、配布元、ライセンス状態を記録します。有料テーマでは、子テーマの配布や更新方法が製品ごとに決められている場合があります。公式子テーマが提供されているなら、それを土台にした方が、テーマ固有の読み込み方式や推奨設定と合いやすくなります。

次に、データベースと wp-content を含むファイルをバックアップします。テーマのファイルだけ保存しても、サイトエディター、カスタマイザー、メニュー、ウィジェットなどのデータベース側設定は戻せません。逆にDBだけでは、子テーマやアップロード画像を復元できません。両方を同じ時点の一組として保管し、復元先と手順を確認します。

子テーマをZIPで管理画面から追加する場合は、「外観→テーマ→新しいテーマを追加→テーマのアップロード」からインストールします。親テーマが先にインストールされていること、ZIPを開いた直下に style.css があることを確認します。余分な親フォルダーが一段入ると、WordPressがテーマとして認識できません。

ローカルまたはステージングで試す

有効化前に、可能ならPHPの構文確認を行います。構文が正しくても、親テーマの関数名やフックと衝突する実行時エラーは残るため、実際のWordPressで有効化テストが必要です。有効化後はトップページだけでなく、投稿詳細、固定ページ、アーカイブ、検索結果、404ページ、問い合わせフォームを確認します。

表示確認では、パソコン幅だけでなくスマートフォン幅も見ます。ヘッダーとフッター、グローバルメニュー、画像、表、ボタン、長い日本語タイトルが画面外へはみ出していないかを確認してください。ログイン中だけ表示される管理バーがレイアウトへ影響することもあるため、ログイン中とログアウト状態を分けます。

ブラウザーのコンソールエラー、PHPエラーログ、404になったCSSや画像も確認します。問題があれば、一度親テーマへ戻して差が消えるかを調べると、子テーマ由来か判断しやすくなります。本番へ反映するときは、検証済みZIPとチェック結果を残し、同じファイルを使います。検証後に本番サーバー上で追加編集すると、試したものと公開物が一致しなくなります。

更新後も壊さない運用

子テーマを有効化した後の重要な仕事は、親テーマの更新を止めることではなく、更新内容と子テーマの差分を管理することです。親テーマの新機能や修正を受け取りながら、上書きしている部分だけを重点的に確認します。

親テーマの変更点を確認する

更新前に親テーマの変更履歴を読み、子テーマでコピーしているテンプレート、利用しているフック、HTML構造、推奨PHP版に変更がないか確認します。たとえば親テーマの header.php を子テーマへコピーしている場合、親側にアクセシビリティ改善や新しい必須処理が追加されても、子テーマの古いファイルが優先されると反映されません。

更新後は「画面が表示された」だけで終えず、上書き中のテンプレートごとに確認します。親テーマの最新ファイルと子テーマ版を比較し、自分の変更以外に差が増えていないかを見ます。親側の改善を取り込むときは、子テーマを最新親ファイルで丸ごと置き換えてから変更をやり直すのではなく、差分の意味を確認して必要部分を統合します。

ブロックテーマでは、サイトエディターで保存したテンプレートがファイル版より優先される場合があります。「子テーマのファイルを直したのに表示が変わらない」ときは、データベースへ保存されたカスタマイズが残っていないかも確認します。ファイル、サイトエディター、追加CSSの三か所へ同じ調整を重ねないことが、将来の切り分けを楽にします。

差分・復元・保守担当を記録する

子テーマにはバージョン番号を付け、変更日、目的、対象ファイル、確認した画面を記録します。Gitを使える場合は、親テーマそのものではなく子テーマの変更を中心に管理し、コミット単位を小さくします。Gitを使わない環境でも、反映前ZIPと一つ前のZIPを分けて保存すれば、少なくともファイル単位の復旧ができます。

ロールバック条件も決めておきます。致命的エラー、管理画面へ入れない、購入や問い合わせが動かない、主要ページが崩れるといった場合は、調査を続けながら公開状態を放置せず、親テーマまたは直前の子テーマへ戻します。復旧後にログと差分を確認し、原因を直した版を検証環境で再テストします。

子テーマは、更新で変更を消さないための箱ではなく、「親テーマの更新」と「サイト固有の変更」を分けて追跡するための仕組みです。管理画面で済む変更、プラグインへ分ける機能、子テーマで持つ表示変更を整理し、バックアップと差分確認を続けることで初めて効果を発揮します。まずは現在のテーマで直接編集しているファイルがないかを確認し、変更場所の一覧を作るところから始めてください。