Summary
この文書の要点
- AIエージェントはコード修正や手順整理を助けますが、本番秘密情報やSSH秘密鍵は渡しません。
- 本番反映は、バックアップ、ドライラン、反映、検証、ロールバックを毎回同じ流れで行います。
- テーマや独自プラグインはrsyncで差分反映し、WordPressの状態確認やキャッシュ処理はWP-CLIで行います。
- 重要なのはAIが自動で出すことではなく、人が判断できる形で安全に公開することです。
AIで作るほど、本番反映の手順が重要になります。
AIエージェントを使うと、WordPressのテーマ修正、テンプレート調整、CSS変更、軽微なプラグイン修正、不要コードの整理を短時間で進められます。従来なら数時間かかっていた修正案の作成や差分確認も、対話しながら進めやすくなりました。
一方で、AIが速く修正できることと、本番サイトへ安全に反映できることは別の問題です。WordPressは公開サイトであり、管理画面、データベース、アップロード画像、問い合わせフォーム、SEO、キャッシュなど、多くの要素がつながっています。変更の反映を雑にすると、表示崩れ、問い合わせ停止、管理画面エラー、検索流入への影響が起きます。
本稿では、エックスサーバーで運用しているWordPressを想定し、AIエージェントで作成した変更を、SSHとWP-CLIを使って安全に本番反映するための基本手順を整理します。目的は、AIに本番作業を丸投げすることではありません。AIの速度を活かしながら、人が確認できる形で公開することです。
対象範囲を先に決めます。
ここで扱うのは、エックスサーバー上で稼働している一般的なWordPressサイトです。作業対象は、テーマファイル、子テーマ、独自プラグイン、静的アセット、設定確認、キャッシュ削除、簡易な動作確認を中心にします。
データベースの大規模移行、会員サイトの複雑な権限変更、ECサイトの注文処理、外部API連携を含む大規模改修は、より慎重な計画が必要です。特に売上や顧客情報に直結するサイトでは、ステージング環境、作業時間帯、ロールバック、関係者への連絡を別途設計します。
また、サーバーの契約プラン、SSH設定、ディレクトリ構成、PHPバージョン、WordPressのインストール先は環境によって異なります。この記事のコマンドは、そのまま貼り付けるものではなく、自社環境に合わせて読み替える前提で使います。
- 対象：テーマ、子テーマ、独自プラグイン、CSS、JavaScript、軽微なPHP修正。
- 対象外：本番DBの構造変更、EC決済、会員権限、大規模移行、停止許容時間が短い重要サイト。
- 前提：SSH接続、WP-CLI利用可否、バックアップ方法、復旧手順を事前に確認する。
AIエージェントに任せる範囲と、人が持つ判断を分けます。
AIエージェントには、差分の作成、影響範囲の洗い出し、確認コマンドの提案、チェックリスト化、ロールバック手順の整理を任せやすいです。コードの読み取りと修正案の作成は、AIの得意領域です。
一方で、SSH秘密鍵、サーバーパスワード、本番データベースの認証情報、WordPress管理者パスワード、顧客情報をAIへ渡してはいけません。AIに本番環境の操作を完全に委ねるのではなく、人が接続し、人が実行し、人が結果を確認する流れを基本にします。
AIへ依頼するときは、環境情報をそのまま貼るのではなく、抽象化して伝えます。例えば、実際のドメインやユーザー名を伏せ、テーマ名や変更範囲だけを伝えます。AIは判断材料を作る担当、人は公開判断をする担当と考えると安全です。
全体の流れを固定します。
本番反映で大切なのは、毎回違うやり方をしないことです。急ぎの修正ほど確認が抜けやすくなります。AIで修正が速くなったとしても、公開までの流れは固定し、作業前後の状態を残します。
基本の流れは、変更内容の把握、ローカル確認、バックアップ、SSH接続、WP-CLI確認、rsyncのドライラン、本番反映、キャッシュ削除、表示確認、ログ確認、ロールバック準備です。この順番を崩さないことで、問題発生時にどこまで戻ればよいかが分かります。
作業ログも残します。作業日時、担当者、対象サイト、反映したブランチやコミット、実行したコマンド、反映後の確認結果を簡単に記録しておくと、後から原因調査しやすくなります。
- 1. AIで修正案を作成し、差分を人が確認する。
- 2. ローカルまたはステージングで表示と管理画面を確認する。
- 3. 本番ファイルとデータベースをバックアップする。
- 4. rsync --dry-run で本番へ入る差分を確認する。
- 5. 本番反映後、WP-CLIとブラウザで状態を確認する。
SSH接続を確認します。
エックスサーバーでは、サーバーパネルからSSH設定を有効化し、公開鍵認証を使って接続します。まずは、本番反映の前に自分の端末から安定してSSH接続できることを確認します。
接続情報は、サーバーID、ホスト名、ポート番号、ユーザー名、秘密鍵の場所で構成されます。実運用では、毎回長いコマンドを打つのではなく、手元のSSH設定に接続先を登録しておくとミスを減らせます。
接続後は、すぐに作業ディレクトリへ移動しないことも大切です。まず `pwd`、`ls`、`whoami` で現在地とユーザーを確認します。似た名前のサーバーや別サイトを触る事故を避けるため、最初の確認を習慣化します。
- SSH設定例：`Host xserver-wordpress`、`HostName svxxxx.xserver.jp`、`User サーバーID`、`Port 10022`、`IdentityFile ~/.ssh/xserver_key`。
- 接続確認：`ssh xserver-wordpress`。
- 現在地確認：`pwd`、`whoami`、`ls -la`。
- 作業先確認：対象ドメインの `public_html` 配下かどうかを必ず確認する。
WP-CLIが使えるか確認します。
WP-CLIは、WordPressをコマンドラインから確認・操作するための公式ツールです。WordPressのバージョン確認、プラグイン一覧、テーマ確認、データベースのエクスポート、キャッシュ削除などをブラウザを開かずに実行できます。
エックスサーバーではWP-CLIを利用できる環境がありますが、利用可否やパスは環境によって確認が必要です。本番作業前に、対象WordPressのインストールディレクトリで `wp --info` や `wp core version` が動くことを確認します。
WP-CLIが使えると、反映前後の確認が安定します。管理画面にログインできない状態でも、プラグイン状態やテーマ状態を確認できるため、トラブル時の復旧にも役立ちます。
- WP-CLI確認：`wp --info`。
- WordPress本体確認：`wp core version`。
- サイトURL確認：`wp option get siteurl`、`wp option get home`。
- テーマ確認：`wp theme list`。
- プラグイン確認：`wp plugin list`。
本番反映前に、必ずバックアップを取ります。
WordPressの本番反映では、ファイルとデータベースの両方を戻せる状態にしてから作業します。テーマファイルだけの修正でも、プラグイン更新や設定変更が含まれる場合はデータベースに影響することがあります。
バックアップは、取ることよりも戻せることが重要です。バックアップファイルの保存先、ファイル名、取得日時、復元手順を確認します。作業前にバックアップを取っても、どこに置いたか分からない、復元できない、対象が違うという状態では意味がありません。
小さな修正でも、最低限、対象テーマまたはプラグインのコピーと、データベースエクスポートを用意します。重要サイトでは、エックスサーバー側のバックアップ機能や手動ダウンロードも併用します。
- DBバックアップ例：`wp db export ~/backup/example-$(date +%Y%m%d-%H%M%S).sql`。
- テーマバックアップ例：`cp -a wp-content/themes/your-theme ~/backup/your-theme-$(date +%Y%m%d-%H%M%S)`。
- バックアップ確認：`ls -lh ~/backup` でサイズと作成日時を見る。
- 復元方針：ファイルだけ戻すのか、DBも戻すのかを作業前に決める。
AIが作った差分を、人が確認します。
AIエージェントが作成した変更は、必ず差分で確認します。見た目が合っていても、不要なファイルが増えていないか、秘密情報が混ざっていないか、WordPressのテンプレート階層を壊していないかを見る必要があります。
確認では、変更されたファイル一覧、削除されたファイル、追加された依存関係、PHPの構文エラー、CSSやJavaScriptの影響範囲を見ます。AIが広い範囲を触っている場合は、本番へ入れる前に変更を絞る判断も必要です。
特にWordPressでは、`functions.php`、テンプレートファイル、独自プラグイン、問い合わせフォーム関連、SEO関連、キャッシュ関連の変更に注意します。小さな修正に見えても、サイト全体へ影響することがあります。
- 差分確認：変更ファイル、削除ファイル、生成物、設定ファイルの混入を確認する。
- PHP確認：ローカルで可能なら `php -l` を使って構文エラーを確認する。
- 秘密情報確認：パスワード、APIキー、SSH設定、個人情報が含まれていないか確認する。
- 表示確認：PC、スマホ、主要ページ、問い合わせフォームを確認する。
rsyncのドライランで、本番に入る差分を確認します。
本番反映前には、`rsync --dry-run` を使って、実際に反映されるファイルを確認します。ドライランは、反映予定の差分を見るための工程です。ここで意図しない削除や不要ファイルの反映が見つかれば、本番へ入れる前に止められます。
`--delete` を使う場合は特に注意が必要です。ローカルに存在しない本番ファイルが削除対象になります。WordPressでは、アップロード画像、キャッシュ、生成ファイル、サーバー上だけにある設定ファイルを誤って消さないように除外設定を行います。
AIにrsyncコマンドを提案させる場合でも、除外対象は人が確認します。`wp-content/uploads`、キャッシュディレクトリ、環境固有の設定ファイルは、反映対象から外すことが多いです。
- ドライラン例：`rsync -avz --delete --dry-run ./wp-content/themes/your-theme/ xserver-wordpress:/home/serverid/example.com/public_html/wp-content/themes/your-theme/`。
- 除外例：`--exclude .DS_Store --exclude node_modules --exclude .git --exclude .env`。
- 確認観点：削除対象、アップロード画像、キャッシュ、環境固有ファイルが含まれていないかを見る。
- 違和感があれば、反映せずにコマンドと対象ディレクトリを見直す。
本番反映は、対象を絞って実行します。
ドライランで問題がなければ、本番反映を行います。反映対象はできるだけ絞ります。WordPress全体を丸ごと同期するのではなく、テーマ、子テーマ、独自プラグイン、必要な静的ファイルなど、今回の変更に必要な範囲だけを送ります。
反映中は、別の作業者が同じファイルを触らないようにします。管理画面からテーマエディターで直接修正している人がいる場合、rsyncで上書きされる可能性があります。作業前に関係者へ共有しておくと安全です。
反映後は、WP-CLIで基本状態を確認します。WordPress本体、テーマ、プラグイン、サイトURL、致命的エラーの有無を見ます。必要に応じてキャッシュを削除し、ブラウザで主要ページを確認します。
- 反映例：`rsync -avz --delete ./wp-content/themes/your-theme/ xserver-wordpress:/home/serverid/example.com/public_html/wp-content/themes/your-theme/`。
- 状態確認：`wp core version`、`wp theme list`、`wp plugin list`。
- キャッシュ確認：キャッシュプラグイン、サーバーキャッシュ、ブラウザキャッシュの影響を確認する。
- 作業ログ：反映日時、対象ファイル、確認結果を残す。
反映後は、表示だけでなく機能を確認します。
本番反映後は、トップページが表示されるだけでは確認不足です。変更した箇所、関連するテンプレート、スマホ表示、問い合わせフォーム、検索、投稿詳細、固定ページ、管理画面、ログイン、画像表示などを確認します。
WordPressでは、キャッシュが効いていると表示上は問題が見えないことがあります。逆に、キャッシュ削除後に初めて崩れが出ることもあります。確認時には、キャッシュの状態を意識します。
エラー確認では、ブラウザのコンソール、サーバーのエラーログ、WordPressのデバッグログを確認します。すべてのサイトでデバッグログが有効とは限らないため、事前にログ確認方法を決めておくと復旧が早くなります。
- 画面確認：トップ、主要固定ページ、投稿詳細、問い合わせ、検索、404、スマホ表示。
- 機能確認：フォーム送信、メール通知、ログイン、管理画面、画像アップロード。
- ログ確認：PHPエラー、JavaScriptエラー、WordPressデバッグログ、サーバーログ。
- SEO確認：title、description、canonical、構造化データ、noindex混入を確認する。
問題が出たら、迷わず戻せる状態にします。
本番反映で問題が起きた場合、原因調査に時間をかけすぎると公開サイトへの影響が長引きます。重要なのは、調査するか、戻すかの判断基準を事前に決めることです。
軽微な表示崩れで原因が明確な場合は、その場で修正して再反映できます。一方、管理画面に入れない、問い合わせが動かない、サイト全体が白画面になる、ECや予約などの重要機能に影響する場合は、まずバックアップへ戻す判断が必要です。
ロールバックは、ファイルだけ戻せばよい場合と、データベースも戻す必要がある場合があります。作業前に取得したバックアップを使い、戻した後も再度表示・機能・ログを確認します。
- ファイル復旧：バックアップしたテーマやプラグインを元の場所へ戻す。
- DB復旧：必要な場合のみ `wp db import backup.sql` を検討する。
- 切り戻し判断：重要機能停止、白画面、問い合わせ停止、原因不明のエラーは早めに戻す。
- 再発防止：原因、検知方法、次回のチェック項目を作業ログに残す。
運用に組み込むと、AI開発は安全に速くなります。
AIエージェントを使ったWordPress運用は、一度きりの便利技ではなく、運用の型として整えることで効果が出ます。修正依頼、AIによる差分作成、人によるレビュー、ステージング確認、本番反映、検証、記録を同じ流れにします。
担当者が一人でも、チェックリストを使うことで抜け漏れを減らせます。複数人で運用する場合は、AIへの依頼文、反映手順、確認項目、ロールバック手順を共有しておくと属人化しにくくなります。
AIは作業速度を上げますが、公開責任は人と会社に残ります。だからこそ、AIの力を使うほど、手順、確認、記録、復旧の仕組みを整える必要があります。
参照元
本稿では、エックスサーバーの公式マニュアルとWP-CLI公式ドキュメントを参照しています。サーバー仕様や管理画面、WP-CLIのコマンド仕様は更新される可能性があるため、実作業時には最新の公式情報を確認してください。
- エックスサーバー SSH設定: https://www.xserver.ne.jp/manual/man_server_ssh.php
- エックスサーバー WP-CLI: https://www.xserver.ne.jp/manual/man_tool_cli.php
- WP-CLI Commands: https://developer.wordpress.org/cli/commands/
AIに速さを任せ、人が安全に公開します。
AIエージェントを使えば、WordPressの修正は速くなります。しかし、本番公開まで自動化すれば安全になるわけではありません。むしろ、速く作れるからこそ、差分確認、バックアップ、ドライラン、検証、ロールバックの手順が重要になります。
エックスサーバー、SSH、WP-CLI、rsyncを組み合わせると、WordPressの本番反映を比較的シンプルに整理できます。大切なのは、毎回同じ流れで行い、作業の前後を確認できる状態にすることです。
AIは手を動かす速度を上げ、人は公開判断と安全確認を担う。この役割分担ができると、WordPress運用は速さと安心を両立しやすくなります。
