複数のクライアントサイトを抱える制作会社やフリーランスのWordPress運用は、「ローカル → ステージング → 本番」の3環境、Gitによるコード管理、更新前バックアップを含む更新ルール、サイトごとの台帳という4つの型をそろえると安定します。この記事では、それぞれをどう作り、どこでつまずきやすいかを順に解説し、自社の運用フローを文書にできる状態を目指します。
なぜ運用フローを決めておくのか
担当者ごとにやり方が違うと、次のような事故が起きやすくなります。
- 本番サイトを直接編集して表示が崩れ、元に戻せない
- 誰がいつプラグインを更新したか分からず、不具合の原因を追えない
- 担当者の退職や外注先の交代で、サーバーやドメインの情報が行方不明になる
運用フローは、作業の順番と「どこに何を記録するか」を決めておくことで、こうした事故を減らす仕組みです。最初から完璧を目指す必要はなく、まず全案件で守る最低限のルールを決め、問題が起きるたびに追記していく形が続けやすい方法です。
3つの環境を分ける
ローカル環境
テーマやプラグインの開発、大きな改修は手元のパソコンで行います。Local、wp-env、Docker などの選択肢があり、チームで同じ構成を再現しやすいものを選びます。選び方は WordPressのローカル開発環境の作り方 で詳しく扱っています。PHPやMySQLのバージョンは、本番サーバーにできるだけ合わせておくと「手元では動いたのに本番で動かない」問題を減らせます。
ステージング環境
ステージングは、本番と同じ構成のコピーで、更新や改修を本番の前に確認する場所です。レンタルサーバーのステージング機能を使うか、サブドメインに複製を作ります。作る際につまずきやすい点は次のとおりです。
- 検索エンジンに載せない: Basic認証をかけるのが有効です。あわせて「設定 → 表示設定」の「検索エンジンがサイトをインデックスしないようにする」を有効にします。
- メールを外に出さない: 本番データを複製すると、問い合わせフォームや会員向けの自動メールが実在の顧客に送られることがあります。SMTPプラグインの送信停止機能や、メールをログに残すだけにする設定を使います。
- 環境を区別する:
wp-config.phpにdefine( 'WP_ENVIRONMENT_TYPE', 'staging' );を書くと、wp_get_environment_type()で環境を判定できます。対応しているプラグインは、この値を見て動作を切り替えることがあります。
本番環境
本番では原則として直接ファイルを編集しません。wp-config.php に define( 'DISALLOW_FILE_EDIT', true ); を入れて管理画面のファイル編集を止め、変更はステージングで確認したものだけを反映します。
Gitで管理する範囲を決める
WordPressをGitで管理するときは、自分たちが書いたコードだけを対象にするのが基本です。WordPress本体、配布されているプラグイン、アップロード画像、wp-config.php は管理対象から外します。
# WordPress本体と設定ファイル
/wp-admin/
/wp-includes/
/wp-*.php
/index.php
/xmlrpc.php
/license.txt
/readme.html
# アップロードとキャッシュ
/wp-content/uploads/
/wp-content/cache/
/wp-content/upgrade/
# 配布プラグイン（自社開発のものだけ例外として管理する）
/wp-content/plugins/*
!/wp-content/plugins/agency-*/
# 依存パッケージ
node_modules/
vendor//wp-*.php は wp-config.php も含むため、データベースのパスワードなどがリポジトリに入るのを防げます。データベースはGitで管理できないので、本番からステージングへ複製するときはWP-CLIでエクスポートし、URLを置き換えます。
# 本番でエクスポート
wp db export backup-before-sync.sql
# ステージングでインポートしたあと、URLを置き換える（まず --dry-run で件数を確認）
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guidsearch-replace はシリアライズされたデータも考慮して置き換えるため、SQLファイルを文字列置換するより安全です。逆向き（ステージング → 本番）のデータベース上書きは、本番で増えた注文や問い合わせを消すおそれがあるため、原則として行いません。本番側で必要な設定変更は、手順を記録したうえで本番で同じ操作を行います。
更新ルールを決める
更新は「いつ・誰が・どの順番で」を決めておくと、判断に迷いません。例としては次のような区分です。
- セキュリティ修正: 脆弱性が公表された更新は、案件の規模にかかわらず早めに適用します。WordPressのマイナーリリースはこの区分に入ることが多いです。
- 通常の更新: プラグインやテーマの更新は、月1回など決まった日にまとめて行います。
- 大きな更新: WordPressのメジャーバージョン、PHPのバージョン変更、ページビルダーの大型更新は、ステージングで動作を確認してから本番に反映します。
更新作業の手順は次の順で固定しておきます。
- 本番のファイルとデータベースをバックアップする
- ステージングで更新し、主要ページ・フォーム・決済などの動作を確認する
- 本番で同じ更新を行い、同じ箇所を確認する
- 適用した更新と確認結果を作業ログに残す
WP-CLIでは wp plugin update --all --dry-run で更新対象を一覧でき、wp core verify-checksums で本体ファイルが改ざんされていないかを確かめられます。更新前の確認ポイントは WordPressを安全に更新する方法 にまとめています。
バックアップと復元の決まりごと
バックアップは「取っている」だけでは不十分で、戻せることを確かめて初めて意味があります。最低限、次の3点を全案件で決めておきます。
- 保存先: サーバーと同じ場所だけに置かず、外部ストレージにも保存する
- 保存期間: 改ざんに気づくまで時間がかかることを考え、数世代分を残す
- 復元テスト: 年に1回程度、ステージングに復元して表示を確かめる
保守契約の範囲を文書にする
保守契約では、作業範囲を曖昧にするとトラブルになります。金額は案件ごとに違いますが、契約書や仕様書には次の項目を書いておくと、後から「どこまでが保守か」で揉めにくくなります。
- 更新作業の頻度と対象（本体・プラグイン・テーマ・PHP）
- バックアップの頻度、保存期間、復元作業の扱い
- 障害時の連絡手段と対応時間帯
- 改修・記事更新・コンテンツ追加を保守に含むか、別見積もりか
- 有料プラグインのライセンスを誰の名義で契約し、誰が更新費を負担するか
- 解約時に引き渡すもの
サイト台帳と引き継ぎチェックリスト
サイトごとに台帳を作り、担当者が変わっても運用を続けられるようにします。台帳には、パスワードそのものではなく、パスワード管理ツールのどこに保管しているかを書きます。
- ドメインの管理会社と更新期限、DNSの管理場所
- サーバーの契約者名義、プラン、PHPのバージョン
- SSL証明書の種類と更新方法
- 管理者アカウントの一覧と所有者
- 導入プラグインの一覧、有料ライセンスの契約者と期限
- バックアップの保存先と復元手順
- Gitリポジトリの場所とデプロイ方法
- クライアント側の連絡窓口
納品や解約で引き継ぐときは、この台帳をもとに次の点を確認します。
- ドメイン・サーバー・有料ライセンスの名義がクライアントに移っているか
- 制作会社のアカウントを削除または権限変更したか
- 最新のバックアップを渡し、クライアント側で保管したか
- 自社専用のmu-pluginsや保守用プラグインを残すか外すか、合意しているか
PHPの推奨バージョンやサーバーの提供機能は時期によって変わるため、台帳には確認した日付も残しておきます。たとえば「PHP 8.3（2026年10月現在）」のように書いておけば、次に見直す時期の目安になります。
まとめ
- 運用フローの柱は、ローカル・ステージング・本番の3環境、Gitの管理範囲、更新ルール、サイト台帳の4つです。
- ステージングは検索エンジン対策とメール停止を忘れずに行い、データベースは本番からステージングへの一方向で複製します。
- 更新は「バックアップ → ステージング確認 → 本番反映 → 記録」の順で固定します。
- 保守契約の範囲と引き継ぎで渡すものを文書にしておくと、担当者交代や解約の際にも困りません。