WordPressの管理画面には「テーマファイルエディター」という画面があります。
ここを開くと、テーマのCSSやPHPをブラウザ上でそのまま書き換えられてしまいます。
「見出しの色を変えたいだけ」なら、ここを1行直すのが一番早いように見えます。
編集できるようになってるんやから、編集してええってことちゃうん？
気持ちは分かりますが、親テーマを直接編集するのは、WordPressで最も後悔しやすい選択のひとつです。
この記事では、なぜダメなのかを仕組みから説明したうえで、代わりにどこへ書けばいいのかを4つの方法として整理します。
こんな人におすすめ
「テーマファイルエディターで直接直している」
「子テーマという言葉は聞くが、必要性がピンとこない」
「カスタマイズをどこに書くのが正解か分かっていない」
結論：更新のたびに、書いた内容はまるごと消えます
先に結論から書きます。
親テーマのファイルに書き足した内容は、テーマを更新した瞬間にすべて失われます。
CSSを1行足しただけでも、functions.phpに50行書いても、扱いは同じです。
警告も確認も出ません。更新したあとに「あれ、直したはずのところが戻ってる」と気づくのが典型的なパターンです。
なぜ消えるのか
理由は、テーマの更新が「差分の反映」ではなく「フォルダごとの置き換え」だからです。
更新を実行すると、WordPressは新しいバージョンのテーマをダウンロードし、既存のテーマフォルダを削除して、新しいものに入れ替えます。
あなたが編集したファイルも、そのフォルダの中にあります。
つまりWordPressは「ここは書き換えられている」という事実を一切記録していません。
Gitのように差分を管理しているわけではないので、守りようがないのです。
これは自動更新でも同じです。
むしろ自動更新のほうが、本人が気づかないうちに消えるぶんだけ厄介だと言えます。
上書きちゃうくて、まるっと入れ替えなんか…そら残らへんわな。
それでも直接編集が起きてしまう3つの理由
「消えると知っていたらやらない」はずなのに、直接編集は今も繰り返されています。
原因は知識よりも、置かれた状況のほうにあります。
1. 編集画面が最初から用意されている
管理画面に「テーマファイルエディター」がある以上、そこを使うのが正規の手順だと受け取るのは自然な反応です。
実際には、あの画面は緊急時の応急処置のために残されているようなもので、日常的なカスタマイズの窓口ではありません。
2. 「1行だけだから」という判断
子テーマを用意するのは、たしかに1行直すより手間がかかります。
ところがその1行は、ほぼ確実に2行目、3行目を呼びます。
気づいたときには、どこを何行変えたのか本人も追えなくなっているというのがよくある経過です。
3. 引き継いだサイトが最初からその状態だった
他の人が作ったサイトを引き継いだ場合、すでに親テーマが改変されていることがあります。
この場合、更新すると自分が書いた覚えのない何かが壊れます。
引き継ぎの際は、テーマが素の状態かどうかを最初に確認しておくと安全です。確認方法は記事の後半で触れます。
本当に困るのは「消えること」ではない
ここからが、この記事で一番伝えたい部分です。
コードが消えること自体は、書き直せば済む話です。
本当に怖いのは、その先で起きる二次被害のほうです。
1. 更新を当てられなくなる
一度「更新したらカスタマイズが消えた」を経験すると、次から更新ボタンを押すのが怖くなります。
結果として、テーマの更新通知を無視し続けるサイトができあがります。
ここが最大の問題です。
テーマの更新には、機能追加だけでなく脆弱性の修正が含まれることがあります。
つまり「見出しの色を変えた1行」を守るために、セキュリティ修正を丸ごと見送っている状態になりかねません。
更新そのものを安全に進める手順は、こちらでまとめています。
2. 何を変えたのか、誰にも分からなくなる
親テーマを直接編集すると、変更が元のコードに溶け込んでしまいます。
数か月後の自分が見ても、どこが元からの記述で、どこが自分の追記なのか区別できません。
子テーマなら、追記したファイルの中身がそのまま「変更点の一覧」になります。
3. テーマファイルエディターは保存した瞬間に本番反映される
管理画面のエディターには、プレビューも下書きもありません。
PHPの書き間違いがあれば、保存した瞬間にサイト全体が真っ白になります。
しかも管理画面ごと開けなくなることがあるため、そのエディターで元に戻すこともできません。
復旧にはFTPやサーバーのファイルマネージャーが必要になります。
4. 有料テーマではサポートを受けられなくなる
多くの有料テーマは、テーマ本体を改変した状態でのサポートを対象外としています。
不具合が起きても、それがテーマ側の問題なのか改変による問題なのかを切り分けられないためです。
規約の内容はテーマごとに異なるので、購入したテーマのサポート範囲は一度確認しておくことをおすすめします。
5. サイトを引き継げなくなる
制作を誰かに引き継ぐとき、あるいは他社に引き継ぐとき、この状態はかなり深刻です。
引き継いだ側は「配布されているテーマと中身が違う」ことにまず気づけません。
公式のテーマハンドブックでも、子テーマの利点として「カスタマイズを親テーマと切り離して保てること」「変更を持ち運び可能で再現可能にできること」が挙げられています。
安全にカスタマイズする4つの方法
では、どこに書けばいいのか。
選択肢は大きく4つあり、やりたいことの規模によって使い分けます。
方法1：カスタマイザーの「追加CSS」
管理画面の「外観」→「カスタマイズ」→「追加CSS」に書く方法です。
ここに書いたCSSはテーマファイルではなくデータベースに保存されるため、テーマを更新しても消えません。
入力しながらプレビューで結果を確認できるので、失敗しても本番に影響しないのも利点です。
ただしCSSしか書けません。また、量が増えると管理画面の細い入力欄で数百行を扱うことになり、現実的ではなくなります。
見た目の微調整に限って使うのが正解です。
方法2：子テーマを作る
もっとも本格的で、応用が利く方法です。
親テーマとは別のフォルダを用意し、差分だけをそこに置きます。
親テーマが更新されても、子テーマのフォルダは置き換えの対象にならないため、変更が残ります。
CSSもPHPもテンプレートも扱えるので、迷ったら子テーマを選んでおけば大きく外しません。
作り方は後半で説明します。
方法3：プラグイン側に置く
見落とされがちですが、重要な選択肢です。
判断の基準はシンプルで、「テーマを乗り換えたときに、残ってほしいかどうか」です。
| 内容 | 置き場所 |
|---|---|
| 見た目・レイアウトに関すること | 子テーマ（テーマを変えたら不要になる） |
| 投稿タイプの登録、独自の機能 | プラグイン（テーマを変えても残したい） |
たとえば導入事例のカスタム投稿タイプを子テーマに登録していると、テーマを変えた瞬間に事例が管理画面から消えます。
データベースには残っているので復旧はできますが、こうしたものは自作の小さなプラグインに切り出しておくほうが安全です。
カスタム投稿タイプの作り方そのものは、こちらで解説しています。
方法4：フックで処理を差し込む
フックは、WordPressの処理の途中に自分のコードを差し込む仕組みです。
公式のプラグインハンドブックでは、フックはアクションとフィルターの2種類があると説明されています。
アクションは「あるタイミングで何かを実行する」もの、フィルターは「渡ってきたデータを加工して返す」ものです。
たとえば「記事の末尾に注記を足したい」とき、親テーマのsingle.phpを開いて書き足す必要はありません。
<?php
// 子テーマの functions.php に書く（親テーマのファイルは触らない）
add_filter( 'the_content', 'add_notice_after_content' );
function add_notice_after_content( $content ) {
if ( ! is_single() ) {
return $content;
}
$notice = '<p class="post-notice">この記事の情報は公開時点のものです。</p>';
return $content . $notice;
}これを子テーマのfunctions.phpに置くだけで、親テーマのファイルを1文字も触らずに出力を変えられます。
フックはテンプレートの上書きより影響範囲が狭く、親テーマの更新にも強い方法です。
「テンプレートごとコピーして上書きする」前に、フックで済まないかを一度考える癖をつけると、保守がぐっと楽になります。
どれを使うか迷ったときの判断基準
| やりたいこと | おすすめの方法 | 理由 |
|---|---|---|
| 色や余白を少し変えたい | 追加CSS | 数行なら子テーマを作るより早い |
| CSSが100行を超えてきた | 子テーマ | 管理画面の入力欄では扱いきれない |
| テンプレートの構造を変えたい | 子テーマ | 同名ファイルで上書きできる |
| 出力に少し足し引きしたい | フック | テンプレートを丸ごと抱えずに済む |
| 投稿タイプや独自機能を追加したい | プラグイン | テーマを変えても残したいため |
| 親テーマのファイルを直接編集 | 選ばない | 更新で必ず失われる |
判断に迷ったら、「テーマを別のものに変えたとき、これは残ってほしいか」を自分に聞いてみてください。
残ってほしいならプラグイン、消えてよいなら子テーマ。この一問でほとんど整理できます。
子テーマの最低限の作り方
子テーマは、想像よりずっと少ないファイルで作れます。
必要なのは style.css だけ
公式ドキュメントでも、子テーマの成立に絶対必要なファイルはstyle.cssだとされています。
wp-content/themes/の中に新しいフォルダを作り、次の内容のstyle.cssを置きます。
/*
Theme Name: Tasknote Child
Template: tasknote
Version: 1.0.0
*/重要なのはTemplate:の行です。
ここには親テーマのフォルダ名を正確に書きます。表示名ではなくフォルダ名です。
1文字でも違うと子テーマとして認識されません。
親テーマのスタイルを読み込む
子テーマを有効化しただけでは、親のCSSが読み込まれずデザインが崩れることがあります。
その場合は、子テーマのfunctions.phpで明示的に読み込みます。
<?php
// 子テーマの functions.php
add_action( 'wp_enqueue_scripts', 'child_theme_enqueue_styles' );
function child_theme_enqueue_styles() {
// 親テーマのスタイルを読み込む
wp_enqueue_style(
'parent-style',
get_template_directory_uri() . '/style.css'
);
// 子テーマのスタイルを、親のあとに読み込む
wp_enqueue_style(
'child-style',
get_stylesheet_uri(),
array( 'parent-style' )
);
}ただしこの記述が不要なテーマもあります。
親テーマ側ですでに子テーマのスタイルまで読み込む作りになっている場合、二重に読み込むことになるためです。
公式ドキュメントも「すべてのテーマが自動で子テーマのスタイルを読み込むわけではない」として、親テーマの実装を確認したうえで判断することを求めています。
配布テーマを使うなら、まず公式マニュアルに子テーマの案内がないかを探すのが確実です。
functions.php は親と子の両方が読み込まれる
ここは誤解が多いところです。
テンプレートファイルは同名のものを置くと親のものが使われなくなり、子のものに差し替わります。
ところがfunctions.phpだけは例外で、親と子の両方が読み込まれます（子が先、親が後）。
したがって、親のfunctions.phpをコピーしてきてはいけません。
同じ関数が二重に定義され、致命的なエラーでサイトが停止します。
子テーマのfunctions.phpには追加したい処理だけを書いてください。
テンプレートは「差し替え」、functions.phpは「足し算」…ここ間違えたら死ぬやつやな。
テンプレートは同名ファイルで上書きする
親テーマのsingle.phpを変えたいなら、それを子テーマにコピーして編集します。
公式ドキュメントの表現では、親テーマに存在するテンプレートやパーツは、同じ名前のファイルを子テーマに置くことで上書きできるとされています。
ただしコピーした時点で、そのファイルは親テーマの更新から取り残されます。
親側が改善されても子テーマのコピーは古いままなので、上書きするテンプレートは必要最小限にとどめるのが鉄則です。
テーマの構造そのものを理解したい方は、こちらもあわせてどうぞ。
すでに親テーマを編集してしまっている場合
ここまで読んで「うちのサイト、まさにその状態だ」と思った方もいるはずです。
慌てて更新を実行しないでください。先に何を変えたかを回収するのが順番です。
手順1：バックアップを取る
ファイルとデータベースの両方をバックアップします。
この時点のテーマフォルダが、あなたのカスタマイズを含んだ唯一の記録です。
手順2：素のテーマと比較して差分を洗い出す
公式サイトや購入者ページから、今使っているのと同じバージョンのテーマをダウンロードします。
それとサーバー上のテーマフォルダを比較すれば、追記した箇所が浮かび上がります。
VS Codeの「フォルダーの比較」機能や、差分比較ツールを使うと確実です。
手順3：差分を適切な場所へ移す
洗い出した変更を、先ほどの4つの方法に振り分けます。
ここでそのまま子テーマに移すのではなく、フックで書き直せないかを検討すると、以降の保守が楽になります。
手順4：更新して、表示を確認する
移設が終わってからテーマを更新します。
可能ならステージング環境で試し、難しければアクセスの少ない時間帯に実行してください。
更新後は、トップページだけでなく記事ページ・一覧ページ・問い合わせフォームまで一通り確認します。
まとめ
親テーマを直接編集してはいけない理由は、更新でファイルごと置き換えられるからです。
ただし本当の問題は、消えたコードそのものではありません。
更新が怖くなり、セキュリティ修正まで見送るサイトになってしまうことが、最も避けたい結末です。
書く場所の選び方は、次の順で考えれば迷いません。
- 数行のCSSなら「追加CSS」
- 出力を少し変えたいだけならフック
- テンプレートや関数を本格的に変えるなら子テーマ
- テーマを変えても残したい機能ならプラグイン
どれを選んでも共通しているのは、親テーマのファイルには一切触らないという点です。
親テーマは借り物、子テーマは自分のノート。そう思っとけばええんやな。
よくある質問
- 追加CSSと子テーマ、どちらを使えばいいですか？
-
CSSだけで済み、量も数十行程度なら追加CSSで十分です。どちらもテーマ更新で消えない点は同じなので、あとは扱いやすさの問題になります。CSSが増えてきた、あるいはPHPやテンプレートも触りたいという段階になったら子テーマへ移行してください。
- 子テーマにするとサイトが重くなりますか？
-
読み込むCSSファイルが1つ増える程度で、体感できるような差は基本的に出ません。速度を心配して親テーマを直接編集するのは、得るものと失うものが釣り合っていない選択です。
- 親テーマのfunctions.phpをコピーして子テーマに置いてもいいですか？
-
絶対にやめてください。functions.phpはテンプレートファイルと違い、親と子の両方が読み込まれます。コピーすると同じ関数が二重に定義され、致命的なエラーでサイトが表示できなくなります。子テーマには追加したい処理だけを書いてください。
- 子テーマを有効化したらデザインが崩れました。
-
親テーマのスタイルが読み込まれていない可能性が高いです。子テーマのfunctions.phpでwp_enqueue_styleを使い、親のstyle.cssを読み込む記述を追加してください。ただしテーマによってはこの記述が不要な場合もあるため、まず配布元のマニュアルに子テーマの案内がないか確認するのが確実です。
- すでに親テーマを編集しています。今すぐ更新しても大丈夫ですか？
-
そのまま更新すると変更内容は失われます。先にバックアップを取り、素のテーマと比較して自分が何を変えたのかを洗い出してください。その差分を子テーマやプラグインに移してから更新するのが正しい順序です。
- 配布テーマに公式の子テーマが用意されている場合は？
-
自作せず、公式に配布されている子テーマを使ってください。親テーマ側の読み込み方に合わせて作られているため、スタイルの二重読み込みや不具合を避けられます。有料テーマの多くは公式サイトで子テーマを配布しています。