子テーマを使うべき変更・
使わなくてよい変更

親テーマのファイルを直接編集すると、テーマ更新でファイルが置き換わり、変更が失われる可能性があります。子テーマはこの問題を避ける代表的な方法ですが、色を一つ変えるだけのために必ず子テーマが必要とは限りません。

WordPress公式のChild Themesでは、子テーマを親テーマの拡張として説明し、変更を分離したまま親テーマを更新できる利点を案内しています。

最初に変更の種類を分ける

変更を「表示」「サイトの機能」「コンテンツ」に分けます。テーマ変更と一緒に消えてよい表示変更はテーマ側、テーマを変えても残すべき機能やデータはプラグインまたはコンテンツ側へ置くのが基本です。

追加CSSで十分な変更

色、余白、文字サイズ、枠線など、既存HTMLに対する小さな見た目の調整は、管理画面の追加CSSまたはテーマが提供するCSS欄で対応できます。更新で親テーマのファイルが置き換わっても、データベースに保存された追加CSSは通常残ります。

ただし、長いCSSや複数ページにまたがる設計変更は管理が難しくなります。変更理由が分からないCSSが増えた段階で、子テーマへの移行を検討します。

ブロック・サイトエディターで行う変更

対応テーマでは、色、タイポグラフィ、テンプレート、ヘッダー、フッターをサイトエディターで変更できます。コードを書かずに済みますが、テーマ変更時の引き継がれ方は設定ごとに異なります。変更前にエクスポート手段と、別テーマに切り替えた検証結果を確認してください。

子テーマが向いている変更

• テンプレートファイルやテンプレートパーツを差し替える
• まとまったCSSやJavaScriptを管理する
• テーマ固有のフックを使って表示を追加・変更する
• 複数サイトへ同じカスタマイズを再利用する
• 変更内容をバージョン管理し、レビューできる形にする

子テーマ側に親テーマと同じ名前のテンプレートを置く場合、親テーマ更新で元テンプレートが変わっても、古い構造を上書きし続けることがあります。更新後は差分を確認し、子テーマ側のテンプレートも必要に応じて追従します。

プラグインへ分けるべき変更

独自投稿タイプ、ショートコード、外部API連携、業務ルールなど、テーマを変えても残すべき機能はプラグインに分けます。これらを子テーマへ置くと、テーマ変更時に機能まで停止し、保存済みデータを扱えなくなる可能性があります。

避けたい変更方法

• 管理画面のテーマファイルエディターで親テーマを直接変更する
• 目的を記録せず、インターネット上のコードをそのまま貼り付ける
• 本番サイトだけで編集し、元へ戻すコピーを残さない
• PHPエラー時に管理画面へ入る代替手段を用意しない

判断フロー

まとめ

子テーマは「何でも入れる場所」ではなく、親テーマの表示を安全に拡張する場所です。小さな見た目は追加CSS、テーマに依存しない機能はプラグイン、テンプレート変更は子テーマというように分けると、更新と将来の移行が容易になります。更新作業の準備は安全な更新チェックリストも参照してください。