WordPressのデザインを少し変えようと調べていると、「親テーマを直接編集せず、子テーマを使いましょう」という説明を目にすることがあります。しかし、子テーマが何を守る仕組みなのか、必ず作る必要があるのか、テーマ更新後も本当にすべての変更が残るのかまでは分かりにくいものです。
子テーマは、利用中のテーマを土台にしながら、自分の変更を別のテーマとして管理する仕組みです。適切に使えば、親テーマの更新で独自のコードが消える危険を減らせます。一方、管理画面の設定だけで目的を達成できる場合や、追加CSSを少し書くだけの場合まで、必ず子テーマが必要になるわけではありません。
この記事では、WordPress初心者が「自分のサイトに子テーマが必要か」を判断できるように、親テーマとの関係、向いている変更、不要なケース、基本的な作り方、更新前後の確認を順番に解説します。特定テーマの配布や制作代行ではなく、どのテーマでも判断に使える基礎知識に絞ります。
WordPressの子テーマとは
子テーマとは、別のテーマである親テーマのデザインや機能を受け継ぎながら、必要な部分だけを変更するテーマです。WordPress公式のTheme Handbookでは、子テーマを親テーマの拡張として説明しています。親テーマのファイルを直接変更せずに、独自の修正を分けて持てることが大きな特徴です。
通常のテーマは、それだけでサイトを表示するためのファイルや設定を持っています。子テーマは親テーマを前提に動くため、子テーマだけを別のサイトへ入れても、対応する親テーマがなければ正常に表示できません。親テーマが土台、子テーマが差分という関係を理解すると分かりやすいでしょう。
子テーマを有効化すると、WordPressは親テーマの機能を利用しつつ、子テーマに用意したファイルや設定を読み込みます。変更内容によっては子テーマ側のファイルが親テーマ側の同名ファイルより優先されます。ただし、すべてのファイルが同じ方法で置き換わるわけではありません。
親テーマと子テーマの役割
親テーマは、サイト全体のレイアウト、テンプレート、標準の装飾、テーマ独自機能などを提供します。子テーマは、その土台を一から複製するのではなく、変更したい部分だけを追加または上書きします。そのため、親テーマのファイル一式を子テーマへコピーする必要はありません。
子テーマへ必要以上にファイルを複製すると、親テーマ側の改善が反映されにくくなります。たとえば、親テーマのテンプレートに不具合修正やアクセシビリティ改善が入っても、古いテンプレートを子テーマ側で上書きしていれば、その変更を取り込めない可能性があります。子テーマは「親テーマを丸ごと保存する場所」ではなく「意図した差分を管理する場所」です。
テーマ更新で変更が消えにくくなる理由
管理画面から親テーマを更新すると、基本的には親テーマのフォルダ内にあるファイルが新しい版へ置き換わります。親テーマのPHPやCSSを直接書き換えていた場合、その編集内容も上書きされるおそれがあります。
子テーマのファイルは親テーマとは別のフォルダに保存されます。親テーマだけを更新する限り、子テーマのフォルダは置き換えの対象になりません。そのため、独自コードを保ちやすくなります。ただし、親テーマ更新による仕様変更と子テーマのコードが合わなくなり、表示崩れやエラーが起きる可能性は残ります。「消えない」と「必ず動き続ける」は別の話です。
子テーマが必要になりやすいケース
子テーマが必要かどうかは、変更量ではなく、どこへ何を保存するかで決まります。見た目の変更が小さくても、親テーマのテンプレートやPHPへ手を加えるなら子テーマを検討します。反対に大きく見える変更でも、サイトエディターやテーマ設定が正式に提供する範囲だけで完結するなら、子テーマを使わない選択肢があります。
テーマのテンプレートファイルを変更したい
投稿ページ、固定ページ、一覧ページ、ヘッダー、フッターなどの出力をテーマファイルで変更する場合は、子テーマが役立ちます。親テーマの同名テンプレートを子テーマへ置き、必要な箇所だけを修正すれば、独自変更を親テーマから分離できます。
ただし、コピーする前に本当にテンプレート編集が必要かを確認してください。ブロックテーマではサイトエディターからテンプレートやテンプレートパーツを編集できることがあります。クラシックテーマでも、ウィジェット、メニュー、テーマカスタマイザー、テーマ独自設定で実現できる場合があります。公式の編集機能で足りるなら、コードを増やさない方が保守しやすくなります。
functions.phpに独自機能を追加したい
テーマの表示に密接な短い処理を追加するため、子テーマのfunctions.phpを使うことがあります。WordPress公式ドキュメントが注意している通り、子テーマのfunctions.phpは親テーマのfunctions.phpを置き換えるファイルではありません。両方が読み込まれるため、親テーマのコード一式をコピーしてはいけません。
同じ関数名を重複して定義すると、致命的なエラーになる可能性があります。また、サイトのテーマを変更しても残すべき機能をfunctions.phpへ入れると、別テーマへ変更したときに機能まで消えます。投稿タイプ、業務ロジック、外部サービス連携など、デザインから独立した機能は専用プラグインとして管理する方が適切な場合があります。
継続してCSSやテーマ設定ファイルを管理したい
サイト固有のCSSを複数人で管理する、変更履歴をGitなどで記録する、検証環境から本番環境へ同じ差分を反映するといった運用では、子テーマにまとめる利点があります。変更場所が明確になり、テーマ更新前に独自部分を洗い出しやすくなるためです。
ブロックテーマでは、デザイン設定の多くをtheme.jsonで扱います。子テーマ側にtheme.jsonを用意して親テーマを拡張する方法もありますが、継承や上書きの挙動を理解する必要があります。クラシックテーマでよく使われるstyle.cssとfunctions.phpだけの説明を、そのままブロックテーマへ当てはめないことが大切です。
子テーマが不要なこともある
「WordPressを使うなら必ず子テーマを作る」という考え方は単純すぎます。子テーマは目的ではなく、テーマのコード変更を分離する手段です。コードを変更しないサイトに子テーマを追加すると、管理対象が増えるだけになることがあります。
管理画面の標準機能だけで変更できる
サイトタイトル、メニュー、ウィジェット、ロゴ、色、フォント、レイアウトなどを管理画面の正式な設定で変更できる場合、その設定は通常、親テーマのファイルへ直接書き込まれません。テーマが想定する方法で変更する限り、子テーマがなくても更新で消えにくい設計になっています。
ブロックテーマでは、サイトエディターのスタイル、テンプレート、パターンなどを使える範囲が広がっています。まず管理画面から目的を達成できるかを確認し、不足する部分が明確になってからコード編集を検討すると、不要な保守作業を避けられます。
追加CSSだけで完結する小さな変更
管理画面に追加CSS機能があり、数行の装飾調整だけで済むなら、子テーマを作らなくてもよい場合があります。追加CSSはテーマファイルとは別に保存されるため、親テーマ更新でファイルが上書きされる問題を避けられます。
ただし、CSSが長くなる、複数環境で共有する、担当者同士でレビューする、変更履歴を厳密に残す場合は、子テーマや別の管理方法が適しています。短期的に書ける場所より、後から誰が見ても変更理由を追える場所を選びましょう。
テーマ独自の子テーマが配布されている
有料テーマや制作会社のテーマでは、公式の子テーマが最初から用意されていることがあります。その場合は、自作する前に配布元の手順を確認してください。親テーマ固有の読み込み方法や推奨構成があり、一般的な作り方を独自に適用すると、スタイルの二重読み込みや機能の競合が起きる可能性があります。
配布元の子テーマを使う場合も、将来その子テーマ自体を更新する運用か、利用者が自由に編集する前提かを確認します。編集済みの子テーマを更新ファイルで上書きすれば、独自変更が消える可能性があります。親テーマと子テーマのどちらが更新対象なのかを区別してください。
ブロックテーマとクラシックテーマで考え方が異なる
現在のWordPressには、大きく分けてブロックテーマとクラシックテーマがあります。WordPress公式Theme Handbookでは、ブロックテーマは主にHTMLとtheme.jsonで構成され、サイト全体をブロックで編集できるテーマ、クラシックテーマは主にPHP、JavaScript、CSSを使う従来型のテーマとして説明されています。
子テーマという仕組みはどちらでも利用できますが、変更するファイルと読み込み方は同じではありません。インターネット上の古い記事はクラシックテーマを前提にしていることが多いため、自分のテーマの種類を確認してから手順を選びます。
クラシックテーマの子テーマ
クラシックテーマでは、style.cssのテーマ情報に親テーマのフォルダ名を指定し、必要に応じてfunctions.phpでスタイルシートを読み込みます。テンプレートPHPを変更する場合は、該当ファイルを子テーマへコピーして編集する方法が一般的です。
注意したいのは、親テーマと子テーマのCSS読み込み方がテーマごとに異なることです。親テーマが両方のstyle.cssを読み込む場合、子テーマ側で同じ処理を追加すると二重読み込みになる可能性があります。WordPress公式も、親テーマがどのスタイルを読み込んでいるか確認し、一律の決まりはないと説明しています。
ブロックテーマの子テーマ
ブロックテーマでは、テンプレート、テンプレートパーツ、パターン、theme.jsonなどを利用します。スタイル管理がtheme.json中心なら、style.cssの読み込みが不要な場合もあります。クラシックテーマ向けの記事を見て、無条件にfunctions.phpへCSS読み込みコードを追加しないようにします。
サイトエディターで行った変更はデータベースへ保存されることがあり、ファイルのテンプレートより優先される場合があります。そのため、子テーマのファイルを変えたのに表示へ反映されないときは、管理画面で保存されたカスタマイズの有無も確認が必要です。
自分のテーマの種類を確認する
テーマの公式サイトや説明書で、ブロックテーマ、フルサイト編集対応、クラシックテーマなどの表記を確認します。管理画面の「外観」に「エディター」があり、ヘッダーやフッターをブロックで編集できるテーマは、ブロックテーマである可能性が高いでしょう。ただし、テーマ独自機能で似た画面を提供している場合もあるため、配布元情報を優先します。
種類が分からないまま本番環境でファイルを作るのではなく、テーマ名とバージョンを控え、公式ドキュメントを確認してください。判断できない場合は、テーマのサポートへ問い合わせる方が安全です。
子テーマを作る前に準備すること
子テーマ作成はファイル数だけを見れば難しくありませんが、本番サイトへ直接追加する作業にはリスクがあります。タイプミス、文字コード、親テーマ名の指定ミス、PHP構文エラーなどで、子テーマを認識できない、またはサイトが表示できないことがあります。
バックアップと復旧手段を用意する
作業前に、ファイルとデータベースの両方をバックアップします。子テーマの作成だけなら主にファイル変更ですが、テーマを有効化するとウィジェットやメニューの位置、テーマ固有設定が変わることがあります。元の状態へ戻せるよう、利用中テーマ、メニュー割り当て、ウィジェット、主要ページの表示も記録します。
管理画面へ入れなくなった場合に、サーバーのファイルマネージャーやFTPで子テーマフォルダを無効化できるかも確認します。復旧方法が分からない状態で、本番サイトのfunctions.phpを編集しないでください。
検証環境で先に試す
可能であれば、ステージング環境やローカル環境に本番サイトを複製して作業します。子テーマを有効化した直後だけでなく、親テーマを最新版へ更新した後も確認します。トップページだけでなく、投稿、固定ページ、一覧、検索、404ページ、フォーム、スマートフォン表示などを見ます。
検証環境は検索エンジンや一般利用者から見えないように保護し、メール送信や決済などの外部連携を停止します。個人情報を含むデータを複製する場合は、アクセス権や保存期間にも注意が必要です。
変更目的を一つずつ決める
「将来使うかもしれない」という理由で多数のテンプレートをコピーすると、保守対象だけが増えます。最初に、何を変えたいのか、標準機能ではできないのか、どのファイルが関係するのかを整理します。変更理由を子テーマ内のコメントや管理メモに残すと、後の更新確認がしやすくなります。
クラシックテーマでの基本的な作り方
ここでは仕組みを理解するため、クラシックテーマの最小構成を説明します。実際の作業では利用中テーマの公式手順を優先してください。テーマによってスタイルの読み込み方法や必須ファイルが異なるため、コードをそのまま貼り付ければ必ず動くとは限りません。
子テーマ用フォルダを作る
WordPressのwp-content/themes内に、子テーマ用の新しいフォルダを作ります。名前は半角英数字とハイフンを使い、親テーマと区別できるものにします。たとえば親テーマのフォルダ名がexample-themeなら、example-theme-childのようにします。
ここで重要なのは、管理画面に表示されるテーマ名ではなく、実際の親テーマのフォルダ名を確認することです。大文字小文字やハイフンを含め、正確に指定します。親テーマのフォルダ名を変更すると更新や認識に影響するため、勝手に変更しないでください。
style.cssにテーマ情報を書く
子テーマのstyle.cssには、少なくとも子テーマ名と、親テーマを示すTemplate情報を記述します。Templateには親テーマのフォルダ名を入れます。テーマ名は人が読む表示名、TemplateはWordPressが親テーマを特定する値です。両者を混同しないようにします。
/*
Theme Name: Example Theme Child
Template: example-theme
*/保存後、管理画面のテーマ一覧に子テーマが表示されるか確認します。「親テーマが見つかりません」といった警告が出る場合は、Templateの値、親テーマのインストール状況、フォルダ位置を見直します。
必要な場合だけスタイルを読み込む
子テーマのstyle.cssへCSSを書いても、テーマの実装によっては自動で読み込まれません。その場合は子テーマのfunctions.phpで、WordPressの仕組みを使ってスタイルシートを読み込みます。ただし、親テーマがすでに子テーマのstyle.cssを読み込む設計なら追加処理は不要です。
読み込み順や依存関係を誤ると、子テーマのCSSが親テーマに上書きされたり、同じファイルが二度読み込まれたりします。ブラウザの開発者ツールで読み込まれたCSSを確認し、テーマ配布元の例に従って設定してください。
変更したいファイルだけを追加する
テンプレートを変更するときは、親テーマの対応ファイルを子テーマへコピーし、必要な箇所だけ編集します。ファイル名と階層が重要です。親テーマのすべてのテンプレートをコピーする必要はありません。
親テーマ更新後は、元になったテンプレートに変更がないか比較します。子テーマ側にコピーした時点で、そのファイルは自動的に親テーマ最新版へ置き換わりません。セキュリティ修正や仕様変更が入っている場合は、独自変更を保ちながら差分を取り込む必要があります。
有効化前にプレビューとエラー確認をする
テーマ一覧に表示されたら、可能ならライブプレビューや検証環境で見た目を確認します。空白画面、警告、レイアウト崩れがある場合は有効化せず、ファイル構成やコードを見直します。WordPress公式のテーマ操作ドキュメントも、プレビューが正常でないテーマを原因確認なしに有効化しないよう案内しています。
functions.phpとテンプレートを扱うときの注意
子テーマを作れば、どのコードでも安全になるわけではありません。更新で上書きされにくくなるだけで、PHPのエラー、セキュリティ上の問題、表示速度への影響、親テーマとの競合は起こり得ます。特にインターネット上のコードを意味を理解せず貼り付けるのは危険です。
functions.phpは親テーマを置き換えない
テンプレートファイルとは異なり、子テーマのfunctions.phpを置いても親テーマのfunctions.phpは読み込まれます。親テーマの内容を丸ごとコピーすると、同じ関数やフックが重複し、エラーや二重処理の原因になります。子テーマには自分が追加する処理だけを書きます。
追加する関数には固有の接頭辞を付けるなど、他のテーマやプラグインと名前がぶつからない工夫が必要です。PHPの開始タグや括弧、セミコロンの誤りでもサイトが停止する場合があります。編集前に必ず復旧手段を用意します。
同名テンプレートは古くなる可能性がある
子テーマ側のテンプレートが親テーマ側より優先される仕組みは便利ですが、長期間放置すると親テーマの最新版との差が広がります。テーマ更新後に表示は崩れていなくても、構造化データ、アクセシビリティ、セキュリティ、WordPress新機能への対応が古いままになることがあります。
更新履歴でテンプレート変更が案内されたら、親子のファイルを比較します。自分の変更箇所を把握していれば、新しい親テーマのファイルを基準に差分を適用し直せます。どこを変えたか分からない状態が、子テーマ保守で最も大きな負担になります。
テーマに依存させる機能を見極める
その機能がサイトの見た目と一緒に消えてよいなら、子テーマへ置く考え方があります。テーマを変更しても残したい機能なら、プラグインや別の仕組みを検討します。たとえば独自投稿タイプやショートコードを子テーマへ入れると、テーマ変更後に管理や表示が難しくなる場合があります。
親テーマを更新するときの確認手順
子テーマを使っていても、親テーマの更新は無条件に押すのではなく、更新内容と影響を確認します。更新で独自ファイルが消えなくても、HTML構造、CSSクラス、関数、フックの変更によって、子テーマが期待する前提が変わることがあります。
更新前に変更一覧とバックアップを確認する
親テーマの更新履歴、配布元のお知らせ、必要なWordPressやPHPのバージョンを確認します。子テーマで上書きしているテンプレート、追加したCSS、functions.phpの処理を一覧にし、影響しそうな変更がないか見ます。ファイルとデータベースのバックアップを作成し、復元手段も確認します。
検証環境で親テーマを更新する
本番より先に検証環境で更新し、エラーログと表示を確認します。トップページだけでなく、子テーマで変更したテンプレートが使われるページを重点的に見ます。画面幅、ログイン状態、投稿形式などで表示が変わる場合は、それぞれ確認します。
キャッシュを区別して確認する
更新後に古いCSSが残る、変更が反映されない場合は、ブラウザ、キャッシュプラグイン、サーバー、CDNなど複数のキャッシュが関係していることがあります。すべてを無計画に削除するのではなく、どのキャッシュを消したか記録しながら確認します。
問題があれば原因を分けて調べる
表示崩れが起きたら、親テーマ更新、子テーマのテンプレート、独自CSS、プラグインなど、要因を分けて確認します。本番サイトで子テーマを無効化すると表示や設定が変わる可能性があるため、まず検証環境で比較します。問題のある独自変更を修正できない場合は、更新を戻すだけで終わらせず、テーマ配布元や制作者へ相談してください。
よくある誤解と失敗
子テーマがあればバックアップは不要
子テーマはバックアップではありません。親テーマ更新による上書きを避ける仕組みであり、誤編集、サーバー障害、不正アクセス、データベース破損からサイトを復元するものではありません。子テーマのファイル自体も、別の保存先へバックアップする必要があります。
親テーマは削除してよい
子テーマは親テーマを利用して動くため、対応する親テーマを削除してはいけません。使っていない別テーマを整理することと、現在の子テーマが依存する親テーマを削除することは違います。親テーマと子テーマの名前を管理画面で確認してから整理します。
親テーマの全ファイルをコピーすれば安全
全ファイルをコピーすると、その時点の親テーマを子テーマ内に固定することになり、親テーマ更新の恩恵を受けにくくなります。差分が増えるほど、どの修正を取り込むべきか分かりにくくなります。必要なファイルだけを追加し、理由を記録する方が安全です。
子テーマならコードを貼るだけでよい
古い記事のコード、別テーマ向けのコード、出所不明のコードは、現在の環境で正しく動く保証がありません。テーマやWordPressのバージョン、PHPの対応、セキュリティ、既存機能との重複を確認します。意味を説明できないコードは本番へ入れないことが基本です。
子テーマを有効化すれば見た目は完全に同じ
通常は親テーマを継承しますが、メニューの割り当て、ウィジェット、テーマ独自設定、サイトエディターの保存状態などが変わる場合があります。有効化直後に主要ページを確認し、元テーマの設定を記録しておく必要があります。
子テーマが必要か判断するチェックポイント
判断に迷ったら、変更内容を「管理画面で完結する変更」「テーマのコードを変える変更」「テーマを変えても残したい機能」に分けます。最初の変更は子テーマ不要の場合が多く、二つ目は子テーマが候補、三つ目はプラグインなど別の管理方法が候補です。
- 親テーマのPHP、テンプレート、CSSを直接編集しようとしていないか
- 同じ目的を管理画面の標準機能で達成できないか
- 利用中テーマはブロックテーマかクラシックテーマか
- テーマ配布元が公式の子テーマや手順を用意していないか
- 変更はテーマを変えたときに消えてよい内容か
- 検証環境、バックアップ、管理画面へ入れない場合の復旧手段があるか
- 親テーマ更新後に差分を確認し続けられるか
一つでも判断できない項目があるなら、すぐに本番環境へ子テーマを追加する必要はありません。変更目的と現在のテーマ構成を整理し、配布元サポートやWordPressを扱う制作者へ相談すると安全です。
子テーマを安全に使うための考え方
子テーマの価値は、ファイルを作ることではなく、独自変更と配布元のコードを分離し、更新後も差分を管理できることにあります。必要なファイルだけを置き、変更理由を残し、親テーマ更新時に比較する運用まで含めて初めて効果を発揮します。
管理画面の設定で足りるなら、無理に子テーマを作る必要はありません。テンプレートやPHPを変更するなら、親テーマを直接編集せず、子テーマまたは目的に合うプラグインで管理します。ブロックテーマとクラシックテーマでは手順が異なるため、自分のテーマの種類と公式情報を確認して進めてください。
初心者が最初に行うべきことは、コードを書くことではなく、変更したい内容、保存場所、更新時の影響、復旧方法を明確にすることです。その四つが説明できれば、子テーマが必要か、別の方法がよいかを落ち着いて判断できます。
