AIへWP-CLIを渡す前の準備｜権限・バックアップ・テスト環境

AIへサイト操作を許可する前に、専用の鍵と権限、復元できるバックアップ、本番とテスト環境の分離を宿主が確認するイラスト AIサイト管理
2026.08.16

WP-CLIを使えるようにしただけで、CodexやClaude Codeへ本番サイトの操作を頼み始めるのは早すぎます。

WP-CLIには、記事の確認だけでなく、公開、削除、プラグイン更新、設定変更、データベース操作まで行える機能があります。AIへの依頼文を丁寧に書くことに加えて、実行できる権限と経路を技術的に狭め、失敗しても戻せる状態を先に作る必要があります。

この記事では、AIへWP-CLIを渡す前に整えるものを、責任者、権限、バックアップ、テスト環境、承認、記録の順に確認します。

準備なしで始めると何が起きるか

たとえば「古い記事を整理して」と依頼したとき、人は一覧の提案を期待していても、AIが更新や削除まで含む作業だと解釈する可能性があります。対象サイトやWordPressの場所を誤れば、テスト環境のつもりで本番を変更することもあります。

問題はAIだけではありません。管理者自身の曖昧な依頼、古い手順書、権限設定の間違い、バックアップの破損、プラグインの挙動も原因になります。そのため「AIが間違えないこと」ではなく、間違えても影響が広がらず、途中で止まり、戻せることを目標にします。

準備の全体像

責任者と契約範囲を確認
  ↓
本番・テスト環境を識別
  ↓
専用の接続経路と最小権限を用意
  ↓
バックアップ取得と復元試験
  ↓
許可する操作と承認境界を決める
  ↓
テスト環境で許可・拒否を確認
  ↓
本番では読み取り専用から開始

レンタルサーバーでは、SSHやWP-CLIの提供範囲が契約プランで決まります。VPSでは、OS利用者、ファイル所有者、Webサーバー、PHP、データベースまで管理者が設計します。自分の契約方式が分からない場合は、先にレンタルサーバーとVPSの違いを確認してください。

1. 誰が責任者か確認する

最初に、次の担当者を明確にします。

  • サーバー契約を管理する人
  • WordPress管理者
  • 記事内容と公開を承認する人
  • 障害時に復元する人
  • 制作会社や保守会社へ依頼する範囲

宿主が記事を承認できても、サーバー設定を変更してよいとは限りません。制作会社との契約中に、別の方法でテーマやプラグインを変更すると保守対象外になる場合もあります。

AIへ「使えるか調べて」と依頼することと、「未導入ならインストールして」は別の許可です。調査、ローカル準備、本番変更を分けます。

2. 本番とテスト環境を見分けられるようにする

本番とテスト環境が同じ見た目、同じ名前、似たURLだと、対象を取り違えやすくなります。

  • 本番とテストでURLを分ける
  • 管理画面へ「テスト環境」と分かる表示を付ける
  • WP-CLIの対象パスとURLを管理側で固定する
  • テスト環境を検索結果へ出さず、外部からのアクセスも制限する
  • テスト環境から実在の宿泊者へメールを送らない
  • 予約・決済はテストモードまたは送信を止めた構成にする

テスト環境へ本番データを複製する場合、予約者の氏名、連絡先、問い合わせ内容、決済関連情報をそのまま持ち込まないでください。必要な範囲へ絞り、個人情報を削除または置き換えます。

テスト環境を作れない場合

契約上テスト環境を作れない場合は、作業の危険度を下げます。

  • 読み取り専用の確認から始める
  • 新規記事は下書き一件だけにする
  • 公開前に管理画面のプレビューを確認する
  • テーマ、プラグイン、DB、予約機能は変更しない
  • 影響が大きい作業は保守担当者へ依頼する

「テスト環境がないから本番で全部試す」にはしません。

3. 権限を三つの層で分ける

AIがWordPressを操作するときの権限は、一種類ではありません。

接続の権限

SSH鍵、接続元、利用時間、ポート転送、対話シェルなど、サーバーへ入る入口の権限です。普段使う管理者の鍵をAI用として共有せず、用途を分けます。パスワードや秘密鍵の中身をチャットへ貼り付けません。

OSとファイルの権限

接続した利用者が、どのコマンドを実行でき、どのファイルを読み書きできるかという権限です。rootやサーバー全体を操作できる利用者でWP-CLIを実行させません。

WordPress公式のセキュリティ解説も、ファイルを書き込み可能にしすぎず、必要な場所だけに権限を与える考え方を示しています。環境によって所有者と実行方式が異なるため、権限エラーを理由に一律で777に変更しないでください。

WordPressの権限

WordPressには、管理者、編集者、投稿者、寄稿者などの権限グループがあります。公式資料では、編集者は他の利用者を含む投稿を公開・管理でき、寄稿者は自分の記事を書けても公開できない、といった違いが示されています。

記事の下書きだけが目的なら、プラグイン、テーマ、利用者、サイト設定まで変更できる管理者権限が本当に必要かを確認します。ただし、WordPressの権限を下げても、OS側でWordPressファイルやデータベースを自由に操作できれば十分な制限にはなりません。三層を合わせて考えます。

WP-CLIの--userは、WordPress上の利用者を指定して処理の文脈を設定する引数です。すべてのWP-CLIコマンドをその権限グループどおりに強制制限する仕組みとは考えず、OS側の権限と後述する許可リストを主な防壁にします。

4. WP-CLIの対象と実行経路を固定する

WP-CLIには、対象パス、URL、リモート接続先、WordPress利用者、事前に読み込むPHPなどを指定できるグローバル引数があります。便利な一方、外部から自由に変更できると、別サイトの操作やコード実行につながります。

次を管理者側で固定します。

  • WP-CLI実行ファイル
  • WordPressの場所
  • 対象URL
  • 実行するOS利用者とWordPress利用者
  • 許可するサブコマンドとオプション
  • 一回に操作できる件数

AIへ生のwpコマンドを自由に渡すのではなく、制限付きラッパーを入口にします。

5. バックアップは「復元できる」まで確認する

バックアップの目的は保存することではなく、問題が起きたときに戻すことです。

  • WordPressのデータベース
  • wp-content内の画像、テーマ、プラグイン
  • WebサーバーやPHPなど、今回変更する設定
  • バックアップの取得日時と対象環境
  • アーカイブの読み取りとチェックサム
  • 復元手順、所要時間、担当者

記事だけを追加する場合と、プラグインやサーバー設定を変更する場合では必要なバックアップが違います。変更範囲より狭いバックアップでは戻せません。

可能なら本番とは別の場所で復元試験を行います。少なくとも、アーカイブを開けること、データベースの完了を確認できること、必要なファイルが含まれることを点検します。

6. AIが止まる条件を決める

作業前に、次の場合は追加操作をせず停止すると決めます。

  • 対象サイト、本番・テストの区別ができない
  • 最新バックアップが失敗した、または復元方法が不明
  • 実行予定に許可していない変更・削除コマンドが含まれる
  • 対象件数が依頼より多い
  • WordPressの場所、投稿ID、URLが想定と違う
  • 実行結果がエラー、警告、タイムアウトになった
  • 公開後のHTTP応答が4xx・5xxになる
  • 予約、問い合わせ、決済への影響が疑われる

エラーの後に別の修正を重ねると、原因と変更範囲が分からなくなります。止めて、現状と復旧可否を報告させます。

7. テスト環境で「拒否」も試す

正常に動くことだけでなく、許可していない操作を止められることを確認します。

  • 許可した状態確認が成功する
  • 未知の操作名が拒否される
  • 余分な引数が拒否される
  • 複数件の変更が拒否される
  • 公開や削除が承認なしでは実行されない
  • 別のWordPressパスやURLを指定できない
  • 実行結果と失敗が秘密情報なしで記録される

テスト環境で成功した設定を本番へ導入しても、利用者、所有者、プラグイン、URLが違えば同じ結果になるとは限りません。本番では再び読み取り専用から始めます。

導入前チェックリスト

  • 契約方式と保守範囲を確認した
  • 作業責任者、公開承認者、復元担当者が決まっている
  • 本番とテスト環境をURLと表示で区別できる
  • テストデータに宿泊者の個人情報を残していない
  • AI専用の接続経路と実行利用者を分けた
  • rootや普段の管理者権限をそのまま渡していない
  • WordPressの権限を作業内容に合わせた
  • WP-CLIの対象パス、URL、コマンドを固定した
  • バックアップの内容と整合性を確認した
  • 復元方法と担当者を確認した
  • 許可する操作と人の承認が必要な操作を分けた
  • エラー時の停止条件を決めた
  • テスト環境で許可と拒否の両方を試した
  • 本番の最初の作業を読み取り専用にした

一つでも判断できない項目があれば、AIに推測で設定させず、契約先や管理者へ確認します。

AIへの準備確認プロンプト

このWordPressへWP-CLIで変更を加える前の準備状況を監査してください。

今回は読み取り専用の調査だけを行い、インストール、権限変更、
設定変更、投稿、更新、削除はしないでください。

確認する項目：
- 対象が本番かテスト環境か
- サーバー契約方式と保守範囲
- WP-CLIの利用可否と対象サイト
- 接続、OS、WordPressの各権限
- バックアップの取得対象、整合性、復元方法
- 許可された操作と人の承認が必要な操作
- エラー時の停止条件

秘密情報、利用者情報、内部設定値は表示せず、
確認済み、未確認、管理者へ質問すべき項目に分けて報告してください。

この依頼は調査のためのものです。未確認項目をAIの推測で埋めず、人が確認します。

まとめ

AIへWP-CLIを渡す準備では、強い管理者権限を一つ用意するのではなく、接続、OS、WordPressの三層を必要最小限に分けます。そのうえで、本番とテスト環境を識別し、復元できるバックアップ、承認境界、停止条件を用意します。

準備ができたら、変更しないWP-CLI入門で投稿、プラグイン、テーマ、カテゴリの読み取り確認から始めます。WP-CLIそのものを初めて知る方はWP-CLIの基礎と安全な始め方へ、技術的な実行制限は制限付きラッパーの作り方へ進んでください。実際の公開工程はバックアップからHTTP・表示確認までで解説しています。

参考資料

※サーバーとWordPressの権限、バックアップ、テスト環境の作り方は契約先ごとに異なります。既存の保守契約と公式マニュアルを優先してください。

タイトルとURLをコピーしました