バックアップ・修正・確認・公開・復元までを一つの手順にする
最終更新：2026年7月
AIでWordPressを管理するときの要点は、AIへ本番サイトを丸ごと任せることではありません。バックアップを取り、ローカルまたはステージング環境で修正し、差分と表示を人が確認してから本番へ反映できる流れを作ることです。AIはコードの説明・修正案・チェックリスト作成を助けますが、公開判断と復元責任は運営者が持ちます。
AIでWordPress管理はどこまでできる？
| 作業 | AIが助けられること | 人が確認すること |
|---|---|---|
| 記事 | 構成案、下書き、校正、HTMLの確認 | 事実、経験、著作権、公開内容 |
| HTML・CSS | 修正案、レスポンシブ対応、原因の切り分け | 差分、スマホ表示、既存機能への影響 |
| PHP | コードの説明、小さな変更案、エラー読解 | 構文、セキュリティ、テスト、復元手段 |
| プラグイン | 設定項目の整理、公式資料の要約 | 互換性、更新履歴、権限、バックアップ |
| 公開作業 | 手順書や確認表の作成 | 本番反映、動作確認、障害時の判断 |
Claude CodeやほかのAIエージェントは、許可したローカルフォルダのファイルを直接編集できる場合があります。一方、通常のチャットへコードを貼っただけではサーバーは更新されません。どのツールが、どの場所へ、どの権限で触れるのかを最初に区別します。
最初にバックアップと復元方法を確認する
WordPressの完全な復元には、通常データベースとファイルの両方が必要です。データベースには投稿・設定など、ファイル側にはテーマ・プラグイン・アップロード画像などがあります。片方だけでは元どおりにならないことがあります。
- データベースのバックアップを取得する
wp-contentを含む必要なファイルを保存する- バックアップを本番サーバー以外にも保管する
- 取得日時と変更前の状態をメモする
- 管理画面やサーバーで復元する手順を先に確認する
バックアップが「正常終了」と表示されただけで終わらせないでください。対象サイト・日時・容量・保存先を確認し、可能ならステージング環境で復元できるかも試します。
親テーマを直接編集せず子テーマを使う
市販・配布テーマを使っている場合、親テーマのファイルを直接変更すると、テーマ更新で修正が失われることがあります。WordPress公式は、親テーマを変更せずに機能や見た目を上書きできる子テーマの仕組みを案内しています。
AIへ修正を頼むときも「親テーマは変更しない」「子テーマ内だけを対象にする」「変更するファイル名と理由を先に示す」と伝えます。すでにCocoonなどの子テーマを利用しているなら、原則としてその子テーマ側で管理します。
安全な実務フローは7段階
「スマホの見出しが画面からはみ出さない」のように、変更後に判定できるゴールへします。複数の大改修を一度に頼むと原因を追いにくくなります。
データベースとファイルを保存し、取得日時を記録します。更新・一括置換・PHP編集の前は必須です。
ローカル環境かステージング環境へ対象ファイルを用意します。公開中のPHPをFTPやファイルマネージャーで直接上書きする作業は避けます。
対象ファイル、変えたい箇所、変えてはいけないもの、WordPress・PHPの環境、出力形式を伝えます。
GitやGitHub Desktopで、追加・削除された行を見ます。依頼と無関係な変更、外部通信、認証情報、危険な関数が増えていないか確認します。
PCとスマホ、主要ページ、フォーム、ログイン、リンク、キャッシュを確認します。PHP変更では構文エラーやデバッグログも確認します。
アクセスの少ない時間帯に反映し、直後にページと管理画面を確認します。問題があれば追加修正を重ねず、まず変更前へ戻します。
AIへ渡す指示の例
「全部最適化して」よりも、対象と合格条件を限定した方が確認できます。コードが長い場合は、秘密情報を除いたうえでファイルを扱えるAIツールを使い、作業フォルダを必要最小限にします。基本的な指示設計はプロンプトの書き方も参考にしてください。
Gitはバックアップではなく変更履歴として使う
Gitは「いつ、何を変えたか」を比較し、以前の版へ戻すのに役立ちます。ただしデータベースやアップロード画像まで自動で保護するわけではありません。Gitの履歴と、サーバー・データベースのバックアップは役割が違います。
- 作業前に現在の正常な状態をコミットする
- 1つの目的ごとに小さくコミットする
- 「修正」ではなく変更内容がわかるメモを付ける
wp-config.php、バックアップ、APIキーを公開リポジトリへ入れない- 本番反映に使った版を記録する
FTP・SFTPは「卒業すべき古い方法」ではありません。安全な接続で、確認済みファイルを反映する手段として使えます。危険なのは、履歴もテストもなく本番ファイルだけを直接編集する運用です。
本番でデバッグ表示を出さない
原因調査にWP_DEBUGやログは役立ちますが、WordPress公式はデバッグ機能をローカルやステージングで使うことを勧めています。本番画面へ警告やファイルパスを表示すると、訪問者に内部情報が見える可能性があります。
本番でログが必要な場合も、表示と記録を分け、調査後に設定を戻します。AIへエラーログを渡す前に、URL、ユーザー名、メール、パス、キーなど不要な情報を伏せます。
AIへ入力してはいけない情報
- WordPress・サーバー・FTP・データベースのパスワード
- APIキー、秘密鍵、認証Cookie、バックアップファイル
wp-config.phpの実値- 顧客の氏名、住所、注文情報、問い合わせ内容
- 非公開契約、社内限定資料、未公開の商品情報
「CSSなら何でも安全」とは限りません。コメントやファイルパスに内部情報が残る場合があります。入力前の確認はAIに入力してはいけない情報で詳しく解説しています。
公開前チェックリスト
- バックアップの日時・対象・保存先を確認した
- 子テーマ、ローカル、ステージングのいずれかで作業した
- AIが変えた差分を自分で読んだ
- PC・スマホと主要機能を確認した
- キャッシュを消して公開画面を確認した
- 元に戻すファイルまたはコミットを特定できる
- 認証情報や個人情報をAI・Gitへ入れていない
よくある質問
まとめ
- AIは修正案と確認作業を助けるが、公開責任は人が持つ
- 復元には原則としてデータベースとファイルの両方が必要
- 親テーマを直接変えず、子テーマと検証環境を使う
- 目的を小さく分け、差分・構文・表示・機能を確認する
- Gitの変更履歴とWordPress全体のバックアップを併用する
- 秘密情報をAIや公開リポジトリへ入れない
コメント