WordPressテーマをFTPでカスタマイズする方法と安全な手順

FTPでテーマを直接編集する前に知っておくべきリスク

WordPressのテーマカスタマイズには複数の方法がありますが、FTPを使ったファイル直接編集は、管理画面では対応できない変更を加えられる反面、操作ミスの影響が即座にサイト全体に及ぶという特性があります。手順を進める前に、3つのリスクポイントを把握しておくことが重要です。

管理画面テーマエディタとFTP編集の違い

WordPress管理画面には「外観 ＞ テーマエディター」という機能があり、ブラウザ上でPHPやCSSを編集できます。ただし、この機能はサーバーのPHPバージョンや権限設定によって無効化されているケースも少なくありません。また、ファイルサイズが大きい場合や、新規ファイルの追加・ディレクトリ操作が必要な場合は管理画面エディタでは対応できません。

一方、FTPクライアントを使った編集は次のような場面で必要になります。

• 管理画面エディタが無効化されており、直接ファイルにアクセスする必要がある場合
• 子テーマのディレクトリ作成や複数ファイルの一括アップロードが必要な場合
• テーマ全体を差し替えたり、画像・フォントなどのアセットファイルを追加する場合

FTPはより広い操作範囲を持つ分、誤ったファイルを上書き・削除するリスクも高くなります。

テーマアップデートで変更が消える問題——本番直書きの落とし穴

最も見落とされやすいリスクが、親テーマのファイルを直接編集した場合にアップデートで変更が上書きされる問題です。WordPressのテーマは定期的にセキュリティ修正や機能追加のアップデートが配布されます。親テーマのファイルに直接加えたカスタマイズは、アップデートを適用した瞬間にすべて消えます。

加えて、FTPで加えた変更はステージング環境を経ずに本番サイトへ即時反映されます。構文エラーが1行あるだけでサイト全体が白画面（WSoD：White Screen of Death）になるケースがあり、その影響はエンドユーザーにも即座に及びます。

作業前に必ずやるべきバックアップの範囲

FTPでファイルを編集する前には、少なくとも以下の範囲をバックアップしておく必要があります。

• 編集対象のテーマフォルダ全体（/wp-content/themes/テーマ名/）
• データベース（テーマのカスタマイザー設定や投稿データが含まれるため）
• wp-config.php（誤って上位ディレクトリを操作した場合のリカバリー用）

バックアップはサーバー上のコピーだけでなく、ローカル環境にダウンロードして保管することを推奨します。サーバー障害が発生した場合、同一サーバー上のバックアップでは復元できないケースがあるためです。

これらのリスクを踏まえた上で、次章以降では接続設定から子テーマの作成・アップロードまでの安全な手順を順を追って解説します。

FTPでテーマを直接編集する前に知っておくべきリスク

管理画面テーマエディタとFTP編集の違い

WordPressにはブラウザ上でテーマファイルを編集できる「テーマエディタ」（外観 › テーマエディター）が標準搭載されています。ただし、テーマエディタはPHPの構文エラーが発生した瞬間にサイト全体が白画面になるリスクがあり、複数ファイルを横断した編集には向いていません。

一方、FTPクライアントを使ったファイル編集では、ローカル環境でコードを確認してからサーバーへアップロードできるため、作業の安全性が高まります。また、テーマエディタでは操作できない画像ファイルや独自ディレクトリの追加にも対応できます。FTPを選ぶ主な場面は次のとおりです。

• 子テーマの新規作成・アップロード
• functions.php への関数追加など、複数行にわたるコード変更
• カスタムCSSや画像ファイルの一括追加
• テーマエディタが無効化されているサーバー環境での作業

テーマアップデートで変更が消える問題——本番直書きの落とし穴

FTP編集で最も多いトラブルが、親テーマのファイルを直接書き換えた後にテーマをアップデートすると変更がすべて上書きされるという問題です。WordPressの親テーマはアップデートのたびにファイルが置き換わるため、直接編集した内容は痕跡なく消えます。

さらに、FTPでアップロードしたファイルは管理画面の操作を挟まず即座に本番環境へ反映されます。構文エラーを含むPHPファイルをそのままアップロードすると、サイトが閲覧不能になる可能性があります。本番直書きはリカバリーコストが高く、BtoB企業のサイトであれば機会損失にも直結します。

作業前に必ずやるべきバックアップの範囲

FTP編集を始める前に、少なくとも以下の3点をバックアップしておく必要があります。

1. 編集対象のテーマフォルダ全体（/wp-content/themes/テーマ名/ をまるごとローカルに保存）
2. WordPressデータベース（テーマ設定や投稿データが格納されている）
3. wp-config.php（誤って上書きした場合の復旧用）

バックアッププラグイン（UpdraftPlus など）を使えばデータベースとファイルを一括取得できます。ただし、FTP作業中はプラグインが動作していない状態になることもあるため、FTPクライアントで手動ダウンロードする習慣を持つほうが確実です。次章以降では、これらのリスクを踏まえた上で安全にFTP編集を進める具体的な手順を解説します。

FTPクライアントの設定とWordPressテーマディレクトリへの接続手順

FTPでWordPressテーマのファイル編集を行うには、まずFTPクライアントを正しく設定し、目的のディレクトリへ確実に到達することが前提になります。ここでは無料で利用できるFTPクライアント「FileZilla」を例に、接続情報の確認からwp-content/themesディレクトリへの到達までを順に説明します。

FTPクライアントの接続情報——ホスト・ユーザー・パスワードの確認場所

FTP接続に必要な情報は、ホスト名（FTPサーバーアドレス）・ユーザー名・パスワード・ポート番号の4つです。これらはレンタルサーバーの管理パネル（コントロールパネル）から確認できます。

• エックスサーバー：サーバーパネル →「FTP」→「サブFTPアカウント設定」または「サーバー情報」
• さくらのレンタルサーバー：コントロールパネル →「FTP情報」
• ConoHa WING：管理画面 →「サーバー管理」→「契約情報」→「FTP」タブ

ポート番号は通常「21」（FTP）または「22」（SFTP）です。セキュリティ面ではSFTPの使用が推奨されます。FileZillaでは「ファイル」→「サイトマネージャー」から新規サイトを作成し、上記4項目を入力して「接続」をクリックします。

wp-content/themes ディレクトリの構造と各フォルダの役割

接続後、サーバー上のディレクトリ一覧が右ペインに表示されます。WordPressのインストール先（多くの場合public_htmlまたはドメイン名のフォルダ）を開き、以下の順で目的のディレクトリへ進みます。

1. wp-contentフォルダを開く
2. その中のthemesフォルダを開く
3. 編集対象のテーマフォルダ（例：twentytwentyfour）を開く

themesフォルダ内には、インストール済みのテーマがそれぞれ独立したフォルダとして格納されています。現在有効化されているテーマのフォルダが編集対象です。フォルダ内にはstyle.css（テーマ情報とスタイル定義）・functions.php（機能定義）・各テンプレートファイル（header.php・footer.phpなど）が含まれます。

FTP接続時に気をつけるパーミッション（権限）設定

WordPressテーマのファイル編集をFTPで行う際、パーミッションの設定ミスがセキュリティリスクや動作不良につながるケースがあります。一般的な推奨値は以下のとおりです。

• ディレクトリ（フォルダ）：755（所有者が読み書き実行、その他は読み取りと実行のみ）
• ファイル：644（所有者が読み書き、その他は読み取りのみ）

FileZillaでパーミッションを確認・変更するには、対象ファイルまたはフォルダを右クリックして「パーミッションの変更」を選択します。ファイルのアップロード後に意図しない権限になっていないか、必ず確認するようにしてください。特にfunctions.phpなど実行に関わるファイルに777（全権限）を設定してしまうと、第三者による改ざんリスクが高まります。

FTPクライアントの設定とWordPressテーマディレクトリへの接続手順

FTPでWordPressテーマファイルを編集するには、まず適切なFTPクライアントを用意し、サーバーへの接続情報を正確に設定する必要があります。接続情報の入力ミスや誤ったディレクトリへの操作は、サイト障害につながるリスクがあります。ここでは、代表的なFTPクライアントであるFileZillaを例に、接続設定からテーマディレクトリの特定までの手順を説明します。

FTPクライアントの接続情報——ホスト・ユーザー・パスワードの確認場所

FTP接続に必要な情報は、「ホスト名」「ユーザー名」「パスワード」「ポート番号」の4つです。これらはレンタルサーバーの管理パネル（コントロールパネル）から確認できます。サーバーごとの確認場所は以下のとおりです。

• エックスサーバー：管理パネルの「FTPソフト設定」→「FTPソフト設定確認」にホスト名・ユーザー名が記載されています。
• さくらインターネット：サーバーコントロールパネルの「FTP情報」から確認できます。
• ConoHa WING：管理画面の「サーバー管理」→「FTP」に接続情報が表示されます。

ポート番号は通常「21」（FTP）または「22」（SFTP）です。セキュリティの観点から、SFTPが利用できる環境ではSFTPを選択することを推奨します。FileZillaでは「ファイル」→「サイトマネージャー」から新規サイトを作成し、上記の情報を入力して接続します。

wp-content/themes ディレクトリの構造と各フォルダの役割

接続後、サーバー上のファイル一覧が表示されます。WordPressのテーマファイルは、以下のパスにあります。

/public_html/wp-content/themes/（ドメイン直下にWordPressをインストールしている場合）

サーバーによっては「/www/」や「/httpdocs/」が起点になるケースもあります。WordPressのインストールディレクトリを確認しながら辿ってください。wp-content/themes/の中には、インストール済みのテーマがフォルダ単位で格納されています。現在有効化しているテーマのフォルダ名は、WordPress管理画面の「外観」→「テーマ」で確認できます。

FTP接続時に気をつけるパーミッション（権限）設定

FTPでファイルをアップロードまたは編集する際には、パーミッション（ファイルの権限設定）にも注意が必要です。不適切なパーミッションはセキュリティリスクや表示不具合の原因になります。一般的な推奨値は以下のとおりです。

• ディレクトリ（フォルダ）：755
• ファイル：644

FileZillaでは、ファイルやフォルダを右クリックして「ファイルパーミッションの変更」から数値を入力できます。アップロード後に表示が崩れる場合や、ファイルが正しく読み込まれない場合は、まずパーミッションを確認することをお勧めします。777など過剰な権限を付与することは、セキュリティ上の観点から避けてください。

子テーマをFTPで作成・アップロードしてカスタマイズを安全に反映する手順

WordPressのテーマをカスタマイズするうえで、最も避けたいリスクのひとつが「テーマのアップデートによるカスタマイズの消失」です。親テーマを直接編集した場合、公式アップデートを適用した瞬間にすべての変更が上書きされます。これを防ぐための標準的な手段が子テーマ（Child Theme）の利用です。

子テーマは親テーマの機能・デザインを継承しつつ、カスタマイズ内容だけを独立したファイルとして保持します。アップデートは親テーマにのみ適用されるため、子テーマ側のカスタマイズは影響を受けません。FTPを使ったカスタマイズを継続的に安全に運用するには、子テーマの利用が前提となります。

子テーマに必要な2ファイル——style.css と functions.php の最小構成

子テーマの作成に最低限必要なファイルは2つだけです。まずローカル環境に子テーマ用のフォルダを作成します。フォルダ名は任意ですが、慣例として親テーマ名に -child を付けた形（例：twentytwentyfour-child）にするとわかりやすくなります。

style.css の記述例：

• ファイル冒頭にテーマ情報をコメント形式で記述します
• Theme Name：子テーマの名称（管理画面に表示されます）
• Template：親テーマのフォルダ名を正確に記述します（大文字・小文字を区別します）

記述例は以下の通りです。

• /* Theme Name: Twenty Twenty-Four Child */
• /* Template: twentytwentyfour */

functions.php の記述例：

親テーマのスタイルシートを読み込むために、以下の記述が必要です。

• add_action( 'wp_enqueue_scripts', 'child_theme_enqueue_styles' ); で親テーマのCSSを明示的に読み込みます
• wp_enqueue_style に get_template_directory_uri() を使って親テーマのstyle.cssを指定します

この2ファイルがあれば、子テーマとして機能する最小構成が整います。

FTPで子テーマフォルダをアップロードして有効化するまでの流れ

ローカルでファイルの準備ができたら、FTPクライアント（FileZillaなど）でサーバーに接続し、以下の手順でアップロードします。

1. FTPクライアントでサーバーに接続し、/wp-content/themes/ ディレクトリに移動します
2. 作成した子テーマフォルダ（例：twentytwentyfour-child）をまるごとアップロードします
3. フォルダ内に style.css と functions.php の2ファイルが存在することをサーバー上で確認します
4. WordPress管理画面の「外観」→「テーマ」を開き、子テーマが一覧に表示されていることを確認します
5. 子テーマの「有効化」をクリックしてアクティブ化します

有効化後はフロントエンドの表示を確認し、親テーマと同じデザインが維持されていれば設定は正常です。

WordPress 子テーマ FTP 反映——管理画面に表示されない場合のチェックポイント

子テーマをアップロードしたにもかかわらず管理画面のテーマ一覧に表示されないケースがあります。以下の項目を順番に確認してください。

• style.css の Template 記述が間違っていないか：親テーマのフォルダ名と完全に一致している必要があります
• 子テーマフォルダがネストしていないか：FTPでアップロードする際に themes/twentytwentyfour-child/twentytwentyfour-child/ のように二重になってしまうミスが起きやすいです
• ファイルのパーミッションに問題がないか：style.css のパーミッションが読み取り不可になっている場合、WordPressがテーマとして認識できません。通常は644が適切です
• style.css のBOM（バイト順マーク）が含まれていないか：テキストエディタによっては保存時にBOMが付加され、コメントの解析に失敗することがあります

なお、「親テーマを直接編集するケース」と「子テーマを使うケース」を比較すると、前者は手軽に変更できる反面、アップデートのたびに変更内容のバックアップと再適用が必要になります。管理コストを考慮すると、長期運用を前提としたWordPressサイトでは子テーマの利用が合理的な選択といえます。一時的なテスト目的や破棄前提の環境であれば親テーマの直接編集も選択肢に入りますが、本番環境での運用には適しません。

子テーマをFTPで作成・アップロードしてカスタマイズを安全に反映する手順

WordPressのテーマをFTPで直接編集する際に見落とされがちなリスクが、テーマのアップデートによる上書きです。親テーマを直接カスタマイズしていた場合、テーマが更新されると編集内容はすべて消えます。これを防ぐのが子テーマの役割です。子テーマを使えば、親テーマの更新に関わらずカスタマイズ内容を維持できます。

子テーマに必要な2ファイル——style.css と functions.php の最小構成

子テーマの作成に必要なファイルは、最小構成で2つです。

• style.css：子テーマの識別情報を記述するファイル
• functions.php：親テーマのスタイルを読み込むためのファイル

style.cssの冒頭には、以下のようなコメントブロックを記述します。

style.css の記述例：

• Theme Name: 任意の子テーマ名（例：MyTheme Child）
• Template: 親テーマのフォルダ名（例：twentytwentythree）

Templateの値は親テーマのフォルダ名と完全に一致させる必要があります。大文字・小文字も含めて正確に記述してください。

functions.phpには、親テーマのstyle.cssを読み込む処理を記述します。wp_enqueue_style関数を使い、親テーマのスタイルシートを子テーマより先に読み込む形が一般的です。この2ファイルを用意するだけで、子テーマとして機能する最小構成が整います。

FTPで子テーマフォルダをアップロードして有効化するまでの流れ

手順はシンプルですが、フォルダ構成と配置場所を正確に守ることが重要です。

1. ローカル環境で子テーマ用のフォルダを作成する（例：mytheme-child）
2. フォルダ内にstyle.cssとfunctions.phpを配置する
3. FTPクライアントを使い、/wp-content/themes/ ディレクトリに子テーマフォルダをアップロードする
4. WordPress管理画面の「外観」→「テーマ」を開き、子テーマが表示されていることを確認する
5. 子テーマを選択して「有効化」をクリックする

有効化後は、カスタマイズしたいCSSやPHPを子テーマ内のファイルに記述します。親テーマのファイルは一切触れません。

WordPress 子テーマ FTP 反映——管理画面に表示されない場合のチェックポイント

子テーマをアップロードしても管理画面に表示されないケースがあります。原因として多いのは以下の3点です。

• style.cssのTemplateの値が誤っている：親テーマのフォルダ名と一字一句一致しているか確認する
• アップロード先のパスが間違っている：/wp-content/themes/ の直下に子テーマフォルダが置かれているか確認する
• style.cssが文字化けしている：ファイルの文字コードはUTF-8（BOMなし）で保存する

なお、親テーマを直接編集する方法と子テーマを使う方法を比較すると、判断の分かれ目は「テーマの更新頻度」と「カスタマイズの規模」です。テーマ更新が頻繁で、かつCSSやfunctions.phpを複数箇所にわたって変更する場合は、子テーマの使用が適しています。一方、テーマ更新を行わないと確定している検証環境や、1〜2行の一時的な変更確認のみであれば、親テーマの直接編集が選ばれるケースもあります。ただし、本番環境での親テーマ直接編集は更新リスクが常に伴うため、子テーマを標準の運用フローとして位置づけることが望ましいです。

functions.php をFTPで編集・アップロードする際の安全な手順

functions.php はWordPressの動作を広範囲に制御するファイルです。構文ミスが1つあるだけでサイト全体が真っ白になる、いわゆる「白画面（WSoD）」が発生するリスクがあります。編集前にリスクの全体像を理解しておくことが、安全な運用の前提となります。

functions.php を直接書き換えてはいけないケース——親テーマ編集の危険性

親テーマの functions.php を直接編集することは、原則として避けるべきです。理由は2点あります。

• テーマ更新で上書きされる：親テーマをアップデートすると、編集内容がすべて消えます。セキュリティアップデートのたびにカスタマイズを再適用する手間が生じます。
• テーマ本体の動作に影響する：親テーマの functions.php はテーマの中核機能を担っており、誤った変更がサイト全体の表示崩れや機能停止を引き起こすケースがあります。

カスタマイズは必ず子テーマの functions.php に記述してください。子テーマの functions.php は親テーマとは独立して動作し、add_action や add_filter といるWordPressの「フック」を使って機能を追加・変更します。たとえば、Google Fontsの読み込みや独自のショートコード追加は、子テーマ側の functions.php に add_action で記述するのが基本的な考え方です。

ローカル編集→構文チェック→FTPアップロードの推奨フロー

functions.php の編集は、次の順序で進めることを推奨します。

1. FTPでファイルをダウンロード：現行の子テーマの functions.php をローカル環境に取得します。
2. ローカルで編集：VS CodeなどのコードエディタでPHPの構文ハイライトを活用しながら編集します。括弧の対応ミスやセミコロン漏れはこの段階で発見できます。
3. 構文チェック：PHPの構文確認には、コマンドラインで php -l functions.php を実行する方法が手軽です。「No syntax errors detected」と表示されれば問題ありません。
4. FTPでアップロード：編集済みファイルをサーバー上の同じパスに上書きアップロードします。アップロード前に元のファイルをバックアップとして別名保存しておくと、復旧が迅速になります。

functions.php FTPアップロード後に白画面になった場合の対処法

アップロード直後にサイトが白画面になった場合は、構文エラーが原因であるケースがほとんどです。以下の手順で対処してください。

• バックアップファイルを即時アップロード：事前に保存しておいた正常なファイルをFTPで上書きアップロードすれば、サイトは元の状態に戻ります。
• wp-config.php でデバッグモードを有効化：WP_DEBUG を true に設定すると、エラーの詳細がブラウザやログファイルに表示され、問題箇所を特定しやすくなります。
• サーバーのエラーログを確認：FTPでサーバーのログディレクトリにアクセスし、PHPエラーログを確認する方法も有効です。

WordPress テーマファイルの編集をFTPで行う場合、functions.php は特に影響範囲が広いファイルです。「ローカルで編集・確認してからアップロード」という手順を省略しないことが、安全な運用の基本となります。

functions.php をFTPで編集・アップロードする際の安全な手順

functions.php はWordPressの動作を制御する中核ファイルです。一文字でも構文ミスがあると、サイト全体が白画面（WSoD：White Screen of Death）になり、管理画面にもアクセスできなくなるケースがあります。FTPでの編集は慎重な手順を踏むことが不可欠です。

functions.php を直接書き換えてはいけないケース——親テーマ編集の危険性

親テーマの functions.php を直接編集することは、原則として避けるべきです。テーマのアップデートが適用された際、編集内容が上書きされてすべての変更が消失します。加えて、アップデート前に構文エラーが混入していた場合、復旧作業がより複雑になります。

カスタマイズは必ず子テーマの functions.php に対して行います。子テーマの functions.php は親テーマのものを置き換えるのではなく、WordPress の読み込み順序に従って「追加的に」実行されます。add_action や add_filter といったフックの仕組みを使うことで、親テーマの処理に手を加えることなく機能を拡張できます。意思決定者の方へ平易に言い換えると、「元の設計図を改変せずに、別紙で追記する」イメージです。

ローカル編集→構文チェック→FTPアップロードの推奨フロー

1. ローカルで編集する：テキストエディタ（VS Code など）でファイルを開き、コードを追記します。エディタの構文ハイライト機能により、括弧の閉じ忘れなどの初歩的なミスを事前に発見しやすくなります。
2. 構文を確認する：PHPの構文チェックツール（php -l コマンドやオンラインのPHP lintツール）を使い、エラーがないことを確認します。
3. 既存ファイルをバックアップする：FTPでサーバー上の現行 functions.php をダウンロードし、ローカルに保存しておきます。
4. FTPでアップロードする：編集済みファイルを子テーマディレクトリ（wp-content/themes/子テーマ名/）にアップロードし、既存ファイルを上書きします。
5. 動作確認する：サイトのフロントエンドと管理画面の両方にアクセスし、正常に表示されることを確認します。

functions.php FTP アップロード後に白画面になった場合の対処法

白画面が発生した場合は、FTPを使って直ちに対処します。バックアップしておいた正常な functions.php を上書きアップロードすることで、ほとんどのケースでサイトを復旧できます。バックアップが取れていない場合は、問題のある functions.php をサーバーから一時的に削除（またはリネーム）するだけで、WordPressは動作を再開します。

WordPress テーマファイルの編集を FTP で行う際は、「編集前に必ずバックアップ、アップロード前に必ず構文確認」という手順を習慣化することが、安定した運用につながります。

CSSや画像ファイルをFTPで追加・上書きしてデザインをカスタマイズする方法

子テーマの作成が完了したら、次のステップはデザインのカスタマイズです。CSSの追記や画像・フォントなどのアセットファイルをFTP経由でアップロードすることで、親テーマを直接変更せずに見た目を調整できます。

子テーマの style.css にCSSを追記して親テーマのデザインを上書きする

子テーマには、作成時に生成した style.css が含まれています。このファイルにCSSを追記することで、親テーマのスタイルを上書きできます。

手順は次のとおりです。まずFTPクライアントで /wp-content/themes/子テーマ名/style.css をダウンロードします。ローカルのエディタで編集し、変更したいセレクタとプロパティを末尾に追記します。たとえば、サイト全体のフォントサイズを変更したい場合は以下のように追記します。

• 対象セレクタを開発者ツールで確認してから記述する
• 変更箇所をコメントで記録しておくと、後の管理が楽になる
• 編集後はFTPで元のパスに上書きアップロードする

CSSの詳細度（specificity）が不足していると、親テーマのスタイルが優先されるケースがあります。その場合は、セレクタをより具体的に指定するか、!important を限定的に使用してください。

画像・フォントなどのアセットを FTP でアップロードしてテーマから参照する

ロゴ画像やカスタムフォントなどのアセットファイルも、FTPで子テーマディレクトリに配置することで利用できます。一般的なディレクトリ構成の例は次のとおりです。

• /wp-content/themes/子テーマ名/images/：画像ファイルの格納先
• /wp-content/themes/子テーマ名/fonts/：カスタムフォントの格納先

アップロード後、style.css からファイルを参照する際は相対パスを使います。たとえば images フォルダに配置した背景画像を参照する場合、background-image: url(‘./images/bg.png’); のように記述します。フォントの場合は @font-face 構文でフォントファイルのパスを指定してください。

変更が反映されない場合のキャッシュクリアと確認手順

FTPでファイルを正しく上書きしても、ブラウザやWordPressのキャッシュプラグインが古いファイルを保持していると変更が画面に反映されないケースがあります。確認と対処の手順は以下のとおりです。

1. ブラウザのハードリロード（Windows：Ctrl＋F5、Mac：Command＋Shift＋R）を実行する
2. W3 Total CacheやWP Super Cacheなどのキャッシュプラグインを使用している場合は、管理画面からキャッシュを手動でパージする
3. CDN（Cloudflareなど）を利用している場合は、CDN側のキャッシュもクリアする
4. それでも反映されない場合は、FTPクライアントで対象ファイルのタイムスタンプを確認し、アップロードが正常に完了しているかを検証する

キャッシュの問題は見落とされやすいため、変更後は必ずシークレットモードのブラウザでも動作確認しておくと確実です。

CSSや画像ファイルをFTPで追加・上書きしてデザインをカスタマイズする方法

子テーマの作成とアップロードが完了したら、次のステップはデザインのカスタマイズです。CSSの追記や画像・フォントなどのアセットファイルをFTP経由で配置することで、親テーマに手を加えることなく見た目を変更できます。

子テーマの style.css にCSSを追記して親テーマのデザインを上書きする

子テーマディレクトリ内のstyle.cssに追記することで、親テーマのスタイルを上書きできます。FTPクライアントで/wp-content/themes/子テーマ名/style.cssをダウンロードし、ローカルのエディタで編集してから再アップロードするのが基本的な手順です。

たとえば、サイト全体のフォントサイズを変更したい場合は、以下のように追記します。

• ファイルの末尾に body { font-size: 16px; } などのルールを追加する
• 既存の親テーマCSSと競合しないよう、セレクタの詳細度（specificity）に注意する
• 変更は必ずローカルで編集・保存してからFTPでアップロードし、サーバー上を直接書き換えない

親テーマのスタイルが優先される場合は、!importantを付与する方法もありますが、後のメンテナンスが煩雑になるため、セレクタを具体的に指定して詳細度を上げる方法を優先するほうが管理しやすいです。

画像・フォントなどのアセットを FTP でアップロードしてテーマから参照する

カスタムロゴや背景画像、Webフォントファイルなどは、子テーマディレクトリ内に専用フォルダを作成して管理します。たとえば/wp-content/themes/子テーマ名/images/や/wp-content/themes/子テーマ名/fonts/といったフォルダ構成が一般的です。

FTPでファイルをアップロードしたあと、style.cssやfunctions.phpからパスを指定して参照します。

• CSSから参照する場合： background-image: url('./images/hero-bg.jpg'); のように相対パスで指定する
• PHPから参照する場合： get_stylesheet_directory_uri()関数を使い、子テーマのURLを動的に取得してパスを組み立てる

ハードコードした絶対URLはサーバー移行時に参照切れを起こす可能性があるため、WordPressの関数を使った動的な参照を推奨します。

変更が反映されない場合のキャッシュクリアと確認手順

FTPでファイルをアップロードしても、ブラウザ上で変更が反映されないケースは少なくありません。原因の多くはキャッシュです。確認すべき箇所は複数あります。

• ブラウザキャッシュ： Chromeであれば「Ctrl＋Shift＋R」（Macは「Command＋Shift＋R」）でハードリロードを実行する
• WordPressキャッシュプラグイン： W3 Total CacheやWP Super Cacheなどを使用している場合は、管理画面からキャッシュを手動クリアする
• サーバー側のキャッシュ： ホスティング環境によってはサーバーレベルでキャッシュが有効になっているため、ホスティング管理画面からクリアする

変更が正しく反映されているかを確認するには、ブラウザの開発者ツール（F12）でネットワークタブを開き、対象のCSSファイルが最新のタイムスタンプで読み込まれているかを確認する方法が確実です。キャッシュバスティングとして、CSSファイルのURLにバージョン番号のクエリ文字列（例：style.css?ver=1.2）を付与する手法も有効です。

FTP編集を継続的に安全に運用するための体制と注意点

FTPでWordPressテーマを編集できる環境を整えたとしても、それを継続的・安全に運用するための体制がなければ、ある日突然サイトが表示されなくなるリスクを抱え続けることになります。手順を覚えることと、仕組みとして運用を回すことは別物です。このセクションでは、セキュリティ・テスト環境・バージョン管理という3つの観点から、組織として整えておくべき体制を整理します。

FTP vs SFTP——セキュリティ観点からSFTPを使うべき理由

FTP（File Transfer Protocol）は通信が暗号化されていないため、ネットワーク上でID・パスワード・ファイルの内容が平文で流れます。社内LANであっても、外部のフリーWi-Fiや商用施設のネットワーク経由での作業では、認証情報が傍受されるリスクがあります。

SFTP（SSH File Transfer Protocol）はSSH経由でファイルを転送するため、通信全体が暗号化されます。FileZillaなど主要なFTPクライアントはSFTPに対応しており、接続時のプロトコル選択で「SFTP」を指定するだけで切り替えられます。サーバー側でSSHが有効になっていれば、追加のコストなしに導入できます。

WordPress テーマ ファイル編集 FTP を業務で継続するなら、まずFTPからSFTPへの切り替えを優先的に対応してください。これは設定変更数分で完了できる対策であり、セキュリティリスクの低減効果は大きいです。

ステージング環境でテストしてから本番に反映するフロー

本番環境に直接FTPでファイルをアップロードすることは、編集ミスがそのまま公開サイトに反映されるという点で、運用リスクが高い作業方式です。特にfunctions.phpのような1行のエラーがサイト全体をダウンさせるファイルは、必ずステージング環境で確認してから本番に反映する運用を徹底してください。

推奨するフローは以下のとおりです。

1. ステージング環境（本番と同構成のテスト用サーバー）で編集・アップロードを実施する
2. ブラウザで表示・動作を確認し、エラーがないことを検証する
3. 問題がなければ同じファイルを本番環境にSFTPでアップロードする
4. 本番反映後も即座に表示確認を行い、問題があればバックアップから即時ロールバックする

ステージング環境の構築には、WordPressのプラグイン（WP Stagingなど）を使う方法や、サーバー会社が提供するステージング機能を活用する方法があります。本番と同じドメイン・パス構成を再現することで、CSSのパスずれなどの問題も事前に検出できます。

FTPだけに頼らないワークフロー——Gitとの組み合わせ方

WordPress テーマ カスタマイズ FTPの作業をチームで行う場合、「誰がいつ何を変更したか」を追跡できない状態は、障害発生時の原因特定を著しく困難にします。FTPは変更履歴を自動記録しないため、Gitによるバージョン管理と組み合わせることが有効です。

基本的な運用イメージは次のとおりです。

• テーマディレクトリをGitリポジトリとして管理し、編集はローカル環境で行う
• 変更をコミットしてからSFTPでステージングにアップロードし、動作確認後に本番へ反映する
• コミットメッセージに変更内容・対応日時・担当者を記録することで、変更履歴が資産として蓄積される

Gitの導入にはある程度の学習コストが伴いますが、複数人がテーマファイルを触る環境であれば、ファイルの上書き事故やロールバックの手間を考えると、早期に導入を検討する価値があります。FTPはあくまでファイルの転送手段として位置づけ、変更管理の仕組みは別途設けることが、継続的な安全運用の基本的な考え方です。

FTP編集を継続的に安全に運用するための体制と注意点

WordPressテーマのFTP編集は、一度設定すれば終わりではありません。本番環境への直接アクセスを繰り返すほど、予期しない障害やファイルの破損リスクが積み重なっていきます。継続的に安全な運用を維持するには、ツールの選定・環境の分離・バックアップの仕組みを組み合わせた体制が必要です。

FTP vs SFTP——セキュリティ観点からSFTPを使うべき理由

従来のFTPはファイル転送時の通信が暗号化されません。ログイン情報やファイルの内容がネットワーク上を平文で流れるため、盗聴・改ざんのリスクがあります。一方、SFTP（SSH File Transfer Protocol）はSSH暗号化を通じて通信全体を保護します。

主要なレンタルサーバーやVPS環境の多くはSFTPに対応しており、FileZillaなどのクライアントでも接続設定を変えるだけで切り替えが可能です。新規に接続設定を作成する際は、プロトコルとして「SFTP」を選択し、ポート番号を22に設定するのが基本です。既存のFTP接続をそのまま使い続けることは、セキュリティ上の観点から見直しが必要なケースが少なくありません。

ステージング環境でテストしてから本番に反映するフロー

本番環境に直接FTPアップロードする運用は、確認漏れが即座にサイト障害につながります。ステージング環境（本番と同一構成のテスト用サーバー）を用意し、次のフローを標準化することが重要です。

1. ステージング環境にファイルをアップロードして動作確認する
2. 表示崩れ・PHP エラー・プラグインとの競合がないことを確認する
3. 問題がなければ同じファイルを本番環境に反映する

多くのレンタルサーバーはステージング機能を標準提供しています。本番と同じWordPressデータベースを複製して使うため、より実態に近い条件で検証できます。

FTPだけに頼らないワークフロー——Gitとの組み合わせ方

FTP単体では「誰がいつ何を変更したか」の履歴が残りません。複数人でカスタマイズを行う場合や、後から変更を差し戻したい場合に対応が難しくなります。Gitを組み合わせることで、この課題を解消できます。

具体的には、ローカル環境でテーマファイルをGitリポジトリとして管理し、変更をコミット・レビューしたうえでFTPで本番またはステージングに反映する流れが一般的です。FTPはあくまで「確定済みのファイルを転送する手段」と位置づけ、編集・確認・承認のプロセスはGitで管理するのが望ましいワークフローです。

加えて、本番環境のテーマファイルは定期的にバックアップを取得する運用も欠かせません。サーバー側の自動バックアップ機能と合わせて、重要な変更前には手動でもバックアップを確保しておくことが、安定した継続運用の前提となります。

FTP・コードエディタ・WordPress管理を一元化するワークフローの考え方

バラバラなツールを行き来することで発生するミスとタイムロス

WordPressテーマのFTPカスタマイズでは、FTPクライアント・テキストエディタ・ブラウザ・バックアップツールと、複数のアプリを同時並行で操作する場面が頻繁に発生します。

この「ツールの往来」が、実は多くのミスの温床になっています。たとえば、ローカルで編集したファイルをエディタで保存したつもりがFTPでのアップロードを忘れていた、あるいは旧バージョンのファイルを誤って上書きアップロードしてしまったというケースは少なくありません。

操作の手数が増えるほど、確認の抜け漏れや作業の中断が起きやすくなります。特に複数のファイルを連続して編集する場合、どのファイルをアップロード済みかの管理が煩雑になりがちです。

FTP・エディタ・検証を統合したワークスペースで変わること

編集・確認・アップロードのサイクルを短縮するには、これらの操作を一つの画面に集約した統合ワークスペースが有効です。ツールを切り替える手間がなくなるだけでなく、「編集したファイルをそのまま即時反映できる」状態を保てるため、作業ミスそのものを構造的に減らすことができます。

CLANEが提供するCLANE ONEのWeb制作ワークスペースは、FTP接続・コードエディタ・WordPress管理画面への操作を統合した環境を備えています。テーマファイルの編集からサーバーへの反映、動作確認までを一連の流れで完結できるため、ツールを横断する際に生じる確認漏れのリスクを軽減できます。

ツール選定の際は、単機能のアプリを組み合わせる構成と、統合型ワークスペースを活用する構成のどちらが自社の運用体制に合っているかを、作業の頻度や関与人数を踏まえて判断することが重要です。

FTP・コードエディタ・WordPress管理を一元化するワークフローの考え方

バラバラなツールを行き来することで発生するミスとタイムロス

WordPressテーマのFTP編集では、FTPクライアント・テキストエディタ・ブラウザ・バックアップツールと、複数のアプリを同時に操作する場面が続きます。ファイルをエディタで修正し、FTPクライアントに切り替えてアップロードし、ブラウザで表示確認して、問題があれば再度エディタに戻る——このサイクルを繰り返すうちに、「古いバージョンのファイルを誤って上書きしてしまった」「アップロード先のディレクトリを間違えた」といったミスが起きやすくなります。

操作の手数が多いほど、確認漏れや誤操作のリスクは高まります。特にfunctions.phpやstyle.cssなどの重要ファイルを扱う場合、ツール間の切り替えに伴う不注意がサイト障害に直結するケースが少なくありません。ツールの数を減らすことは、単なる作業効率の問題ではなく、品質管理の観点でも重要な判断です。

FTP・エディタ・検証を統合したワークスペースで変わること

FTP接続・コード編集・WordPressの管理画面操作を一つの環境にまとめると、編集→確認→アップロードのサイクルを大幅に短縮できます。具体的には、以下のような改善が期待できます。

• ファイル編集と同一画面でFTPアップロードが完結し、操作ミスが減る
• WordPress管理画面への切り替え不要で、テーマの有効化やプラグイン確認がすぐ行える
• バックアップ・バージョン管理が統合されており、誤上書き時のリカバリが速い

CLANEが提供するCLANE ONEのWeb制作ワークスペースは、FTPクライアント・コードエディタ・WordPress管理機能を統合した環境として設計されています。テーマカスタマイズの作業フローを見直す際のツール選定において、統合型ワークスペースという選択肢を比較対象として加えておくことは、制作品質と運用効率の両面から検討する価値があります。

まとめ——FTPを使ったWordPressテーマカスタマイズの安全な進め方

本記事で解説した内容を整理し、安全にWordPressテーマカスタマイズを進めるための要点を確認します。

• 親テーマを直接編集しない：WordPressテーマのカスタマイズは、必ず子テーマを作成してから着手します。親テーマを直接変更すると、テーマ更新のたびに上書きされるリスクがあります。
• 子テーマはFTPで確実にアップロードする：style.cssとfunctions.phpの2ファイルを/wp-content/themes/子テーマ名/に配置し、WordPress管理画面で有効化します。
• functions.phpの編集は構文確認を徹底する：ローカルエディタで編集・検証してからFTPでアップロードします。構文エラーがあるとサイトが真っ白になるため、事前のバックアップも必須です。
• FTP接続はSFTPに切り替える：通常のFTPはパスワードを平文で送信します。本番環境では必ずSFTP（ポート22）を使用し、認証情報の漏洩リスクを排除してください。
• 継続運用にはステージング環境を整備する：デザイン変更やプラグイン追加を本番に直接反映するのは危険です。ステージング環境で動作確認してから本番へ反映する流れを標準化します。

優先して着手すべき順序は次のとおりです。まず子テーマの作成とFTPアップロードを完了させ、カスタマイズの土台を整えます。次にSFTP接続への切り替えでセキュリティリスクを低減します。その後、ステージング環境の導入により、継続的な運用体制を構築します。この3ステップを段階的に整備することで、WordPressテーマのFTPカスタマイズを安全かつ安定した形で運用できるようになります。

まとめ——FTPを使ったWordPressテーマカスタマイズの安全な進め方

WordPressテーマのカスタマイズをFTPで安全に進めるために、本記事で解説した要点を以下に整理します。

• 親テーマを直接編集しない：アップデートで上書きされるリスクを避けるため、子テーマを作成してからカスタマイズを加えるのが基本です。
• 子テーマのFTPアップロード手順：style.cssとfunctions.phpの2ファイルを/wp-content/themes/子テーマ名/ディレクトリに配置し、管理画面で有効化します。
• functions.phpの編集はローカルで行う：FTPクライアントでファイルをダウンロードし、ローカル編集→アップロードの流れを徹底することで、構文エラーによるサイト停止を防げます。
• 接続はSFTPに切り替える：通常のFTPは通信が暗号化されないため、認証情報の漏えいリスクがあります。ホスティング環境が対応していれば、SFTPへの移行を優先してください。
• ステージング環境での検証を先行させる：本番環境への直接アップロードは変更の影響を予測しにくいため、ステージングで動作確認を済ませてから反映するフローが望ましいです。
• バックアップを作業前に必ず取得する：テーマファイル単体だけでなく、データベースを含むサイト全体のバックアップを習慣化します。

着手の優先順位としては、①子テーマの作成とFTPによる初期アップロード、②SFTP接続への切り替え、③ステージング環境の整備の順で対応を進めると、リスクを段階的に下げながら運用体制を整えやすくなります。すでに親テーマを直接編集している場合は、差分を子テーマに移行することを最初の一歩として検討してください。