検証環境：WordPress 6.9.4 / PHP 8.3.2 / WP-CLI 2.12.0 / Xserver スタンダードプラン / ConoHa WING / Docker（wordpress:6.9.4-php8.3.2）/ macOS Tahoe 26.4 / GitHub Actions ubuntu-latest
サーバー別の注意点（Xserver / ConoHa / さくら / Docker）
WP-CLIが「動かない」「エラーになる」原因の大半は「CLIのPHPバージョンがWebと違う」「sudoが使えずインストール場所に困る」「WordPressのパス指定が間違っている」の3つで、サーバー環境ごとに対処法が異なります。
Xserver（エックスサーバー）
日本で最も利用者が多いレンタルサーバーです。WP-CLI自体は問題なく動作しますが、3つのハマりポイントがあります。
ハマりポイントと対処法
| 問題 | 原因 | 対処法 |
|---|---|---|
| sudoが使えない | 共用サーバーのため管理者権限なし | ~/binにWP-CLIを配置してPATHを通す（第1章参照） |
| CLIのPHPバージョンが古い | Web用とCLI用のPHPが別バイナリ | php -vで確認し、必要なら別パスのPHPを指定 |
| WordPressのパスがわからない | マルチドメインでpublic_html/サブディレクトリ/に設置 |
--pathオプションで正確なパスを毎回指定 |
インストール手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# ~/bin ディレクトリを作成 mkdir -p ~/bin && cd ~/bin # WP-CLIをダウンロード・設置 curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar && mv wp-cli.phar wp # PATHに追加（bashの場合。zshなら ~/.zshrc） echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc source ~/.bashrc # 動作確認 wp --info |
CLIのPHPバージョン確認
|
1 2 3 4 5 |
# CLIのPHPバージョンを確認 php -v # WP-CLIが使っているPHP情報 wp --info |
ConoHa（WING）
ConoHa WINGでもWP-CLIは問題なく動作しますが、SSH接続の初期設定が必要です。コントロールパネルでSSHの有効化と公開鍵の登録を先に行ってください。
~/.ssh/config で接続を効率化
ローカルマシンの~/.ssh/configに以下を追加しておくと、接続が一気に楽になります。
|
1 2 3 4 5 6 |
# ConoHa本番サーバー Host conoha-prod HostName xxx.xxx.xxx.xxx User your-user Port 22 IdentityFile ~/.ssh/id_rsa |
|
1 2 |
# 設定後はこれだけでSSH接続 ssh conoha-prod |
複数サーバーを管理しているなら、それぞれにHost名を付けておくことで、サーバー間の切り替えがスムーズになります。
さくら（さくらのレンタルサーバ）
プランや契約時期によってSSHの利用可否や使えるコマンドに制限があります。WP-CLIがプリインストールされていない場合が多いので、Pharファイルで自前インストールが必要です。
|
1 2 3 4 |
# wpコマンドが存在するか確認 which wp || echo "wp not found" # 存在しない場合は第1章の「sudo無し」手順でインストール |
容量やプロセスに制限があるプランでは、大きなDBのexport/importが中断されることがあります。大規模な作業は時間帯をずらしたり、分割して実行する工夫が必要です。
ローカルDocker（開発・検証）
Docker環境でのWP-CLI実行には3つのパターンがあります。
| パターン | 方法 | 特徴 |
|---|---|---|
| A: コンテナ内で実行 | docker compose exec wordpress wp ... |
最もシンプル。ただしWP-CLIがコンテナ内に必要 |
| B: wordpress:cli イメージ | WP-CLI専用コンテナをボリューム共有で起動 | WP-CLIの追加インストール不要 |
| C: ホスト側から –ssh | wp --ssh=docker-compose:wordpress:/var/www/html ... |
CI/CDや複数環境の統一管理向け。設定がやや複雑 |
パターンA：コンテナ内実行（最もシンプル）
|
1 2 |
# コンテナ内でwp plugin listを実行 docker compose exec wordpress wp plugin list |
パターンB：wordpress:cli コンテナ
|
1 2 3 4 5 |
# WP-CLI専用コンテナでコマンド実行 docker run -it --rm \ --volumes-from some-wordpress \ --network container:some-wordpress \ wordpress:cli plugin list |
まずはパターンAかBから始めて、CI/CD連携が必要になったらパターンCを検討するのがおすすめです。
コピペで使える移行・保守テンプレート4種
WordPress運用の定型作業を「安全なアップデート」「ドメイン移行」「障害復旧」「定期保守」の4テンプレートにまとめました。すべて「dry-run → backup → maintenance → 本実行」の安全フローを組み込んでおり、環境変数を書き換えるだけでそのまま使えます。
テンプレ1：安全なアップデート（基本形）
WordPress本体・プラグイン・テーマを一括更新する基本テンプレートです。メンテナンスモードのON/OFF、バックアップ、キャッシュクリアまで含んでいます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
#!/usr/bin/env bash set -euo pipefail WP_PATH="${WP_PATH:-/path/to/wordpress}" WP="wp --path=${WP_PATH}" STAMP="$(date +%F-%H%M)" BACKUP_DIR="${BACKUP_DIR:-$PWD/_backup}" mkdir -p "$BACKUP_DIR" echo "== maintenance on ==" $WP maintenance-mode activate || true echo "== db backup ==" $WP db export "$BACKUP_DIR/db-$STAMP.sql" echo "== core update ==" $WP core update echo "== plugin update ==" $WP plugin update --all echo "== theme update ==" $WP theme update --all echo "== update db ==" $WP core update-db || true echo "== flush cache/rewrite ==" $WP cache flush || true $WP rewrite flush || true echo "== maintenance off ==" $WP maintenance-mode deactivate || true echo "DONE" |
set -euo pipefailは「エラーが発生したらスクリプトを停止する」安全装置です。|| trueを付けている箇所は「失敗しても止めない」例外処理で、メンテナンスモードやキャッシュクリアなど致命的ではない処理に使っています。
テンプレ2：ドメイン移行（URL置換つき）
旧ドメインから新ドメインへの移行テンプレートです。必ずdry-run（リハーサル）を挟んでから本実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
#!/usr/bin/env bash set -euo pipefail WP_PATH="${WP_PATH:-/path/to/wordpress}" WP="wp --path=${WP_PATH}" OLD="${1:-https://old.example.com}" NEW="${2:-https://new.example.com}" STAMP="$(date +%F-%H%M)" BACKUP_DIR="${BACKUP_DIR:-$PWD/_backup}" mkdir -p "$BACKUP_DIR" echo "== db backup ==" $WP db export "$BACKUP_DIR/db-before-migrate-$STAMP.sql" echo "== dry-run search-replace ==" $WP search-replace "$OLD" "$NEW" --skip-columns=guid --dry-run echo read -p "Apply for real? type 'yes' to continue: " yn if [[ "$yn" != "yes" ]]; then echo "Canceled." exit 0 fi echo "== apply search-replace ==" $WP search-replace "$OLD" "$NEW" --skip-columns=guid echo "== flush cache/rewrite ==" $WP cache flush || true $WP rewrite flush || true echo "DONE" |
--dry-runは「実際には変更せず、何が変わるかだけを表示する」リハーサルモードです。--skip-columns=guidはRSSフィードの識別子であるguidカラムを除外します。read -pで確認入力を求めることで、うっかり本実行する事故を防いでいます。
テンプレ3：障害復旧（ログイン不可・真っ白画面）
「管理画面にアクセスできない」「サイトが真っ白」という緊急事態用です。原因調査は後回しで、とにかくサイトを復旧させることを最優先します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
#!/usr/bin/env bash set -euo pipefail WP_PATH="${WP_PATH:-/path/to/wordpress}" WP="wp --path=${WP_PATH}" echo "== minimal boot (skip plugins/themes) ==" $WP --skip-plugins --skip-themes core version echo "== deactivate all plugins ==" $WP plugin deactivate --all echo "== switch theme to default ==" $WP theme activate twentytwentyfour || true echo "== flush cache ==" $WP cache flush || true echo "DONE (try login)" |
復旧後は、プラグインを1つずつ有効化していき、有効化した瞬間にサイトが止まったものが原因プラグインです。「全部止めて1つずつ有効化」はWordPress障害対応の王道手法です。
テンプレ4：定期保守（cron向け）
cronで定期実行するテンプレートです。更新チェックとCronジョブ実行だけを行い、自動更新はしません。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#!/usr/bin/env bash set -euo pipefail WP_PATH="${WP_PATH:-/path/to/wordpress}" WP="wp --path=${WP_PATH} --quiet" LOG_DIR="${LOG_DIR:-$PWD/_logs}" mkdir -p "$LOG_DIR" LOG_FILE="$LOG_DIR/maintenance-$(date +%F).log" { echo "== $(date) ==" $WP plugin list --update=available || true $WP theme list --update=available || true $WP cron event run --due-now || true $WP cache flush || true echo } >> "$LOG_FILE" 2>&1 |
マルチサイト運用の実例
マルチサイトでWP-CLIを使う際は、--urlで操作対象サイトを毎回明示するのが鉄則です。--networkはネットワーク全体への操作に使い、全サイトへの一括処理はシェルのループで実現します。
サイト一覧を確認する
|
1 2 3 4 5 |
# サイト一覧（ID・ドメイン・パス） wp site list # URLだけを一覧表示 wp site list --field=url |
マルチサイトでは、作業前に必ずこの確認を行ってください。対象サイトを間違えると影響範囲が大きくなります。
特定サイトへの操作（–url）
|
1 2 3 4 5 |
# 特定サイトのオプション値を取得 wp --url=https://sub.example.com option get blogname # 特定サイトのプラグインを有効化 wp --url=https://sub.example.com plugin activate my-plugin |
ネットワーク全体への操作（–network）
|
1 2 3 4 5 |
# プラグインをネットワーク有効化 wp plugin activate my-plugin --network # ネットワーク全体のDB更新 wp core update-db --network |
全サイトへのループ処理
|
1 2 3 4 5 |
# 全サイトのサイト名を取得 wp site list --field=url | while read -r u; do echo "== $u ==" wp --url="$u" option get blogname done |
一括操作は便利ですがミスの影響も大きいです。最初は必ずoption getで現在値を確認してからoption updateを実行してください。
スーパー管理者の管理
|
1 2 3 4 5 6 7 8 |
# スーパー管理者一覧を表示 wp super-admin list # ユーザーをスーパー管理者に追加 wp super-admin add adminuser # スーパー管理者から削除 wp super-admin remove adminuser |
スーパー管理者権限は強力なので、必要最小限のユーザーにのみ付与してください。
CI/CDでWP-CLIを使う（GitHub Actions最小テンプレ）
GitHub ActionsでWordPress環境を構築してWP-CLIを実行する最小テンプレートを紹介します。PRごとに自動でWordPress環境を立ち上げ、プラグインの動作確認まで行えるため、マージ前に問題を発見できるようになります。
CI/CDで得られる3つのメリット
「毎回同じ手順」の自動化。人間が手動で行う作業では手順の抜けやミスが発生しますが、CI/CDなら設定した手順が確実に毎回実行されます。PRごとの自動検証。プルリクエストが作成されるたびにWordPress環境を構築し、基本的な動作確認を自動実行できます。段階的な自動化への足がかり。最初は検証の自動化から始めて、慣れてきたらステージングへのデプロイ自動化まで段階的に進められます。
最小テンプレート
MySQLはserviceコンテナとして起動し、WP-CLIはPharファイルをダウンロードして使用します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
name: wp-cli-smoke on: push: pull_request: jobs: wp-cli: runs-on: ubuntu-latest services: mysql: image: mysql:8 env: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: wp ports: - 3306:3306 options: >- --health-cmd="mysqladmin ping -h 127.0.0.1 -proot" --health-interval=10s --health-timeout=5s --health-retries=10 steps: - uses: actions/checkout@v4 - name: Setup PHP uses: shivammathur/setup-php@v2 with: php-version: "8.2" extensions: mbstring, mysqli tools: composer - name: Download WP-CLI run: | curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar php wp-cli.phar --info - name: Setup WordPress run: | mkdir wp && cd wp php ../wp-cli.phar core download --locale=ja php ../wp-cli.phar config create \ --dbname=wp --dbuser=root --dbpass=root \ --dbhost=127.0.0.1 --skip-check php ../wp-cli.phar db create php ../wp-cli.phar core install \ --url=http://example.test \ --title="CI Test" \ --admin_user=admin \ --admin_password=admin \ --admin_email=admin@example.com - name: Smoke check run: | cd wp php ../wp-cli.phar plugin list php ../wp-cli.phar option get home |
search-replaceを安全に使いこなす
wp search-replaceはサイト移行で最も活躍するコマンドですが、雑に使うと取り返しがつきません。「backup → dry-run → 確認 → 本実行 → キャッシュクリア」の5ステップを必ず守り、guidカラムはスキップし、ステージング環境で先にテストするのが安全の鉄則です。
安全の5原則
| # | 原則 | 具体的な操作 |
|---|---|---|
| 1 | 必ずバックアップ | wp db export before.sql |
| 2 | 必ずdry-runを先に | --dry-runオプションで変更内容を確認 |
| 3 | guidカラムをスキップ | --skip-columns=guidを付ける |
| 4 | 最初はURLだけ置換 | 正規表現や複数パターンは慣れてから |
| 5 | ステージングで先にテスト | 本番環境で一発勝負は絶対に避ける |
基本の使い方
|
1 2 3 4 5 6 7 8 9 10 |
# 1. バックアップを取得 wp db export before.sql # 2. dry-runで確認 wp search-replace 'http://old.example' 'https://new.example' \ --skip-columns=guid --dry-run # 3. 結果を確認してから本実行 wp search-replace 'http://old.example' 'https://new.example' \ --skip-columns=guid |
dry-runの結果には対象テーブル名と置換される行数が表示されます。異常に多い場合や予想外のテーブルが含まれている場合は、一度立ち止まって確認してください。
「置換されてない気がする」ときのチェックポイント
search-replaceを実行したのにURLが変わっていない場合は、以下を順番に確認してください。
siteurl / home オプション。wp option get siteurlとwp option get homeで現在値を確認し、必要ならwp option updateで直接更新します。
wp-config.php のハードコード。WP_HOMEやWP_SITEURLが定義されていると、DBの値より優先されます。ファイルを直接確認してください。
CDN設定。Cloudflareなどを使っている場合、CDN側の設定変更も必要です。
キャッシュ。単にキャッシュが残っているだけの場合もあります。wp cache flushを実行し、ブラウザのキャッシュもクリアしてから再確認してください。
本番作業前のチェックリスト
本番環境でWP-CLIを使う前に確認すべき項目を「事前チェック」「作業の安全装置」の2カテゴリにまとめました。このリストをコピーして作業記録として残しておくことで、多くの事故を未然に防げます。
事前チェック
□ wp --info でWP-CLIとPHPが正常動作しているか
□ wp core version が通り、WordPressが認識されているか
□ wp plugin list が通り、プラグイン読み込みに問題がないか
□ 実行場所のパスが正しいか（--pathオプション or 正しいディレクトリ）
□ ファイルの所有者・権限が適切か（ls -laで確認）
作業の安全装置
□ DBバックアップをwp db exportで取得した
□ search-replaceを行う場合、--dry-runで結果を確認した
□ メンテナンスモードのON/OFFコマンドを準備した
□ 失敗時の戻し手順（DB import）を把握している
□ 作業内容と結果を記録するログの準備ができている
参考リンク（公式情報）
WP-CLIの情報は公式ドキュメントが最も正確で網羅的です。困ったときはまず公式を確認する習慣をつけてください。
WP-CLI公式
GitHub Actions
次にやると伸びること
第1章・第2章の知識を実践に変えるには「自分用テンプレートを1つ作る」「ステージングで繰り返し練習する」「マルチサイトなら–urlを体に染み込ませる」「CIでsmoke testを自動化する」の4ステップが効果的です。
ステップ1：自分の運用に合わせてテンプレートを1つ作る。この記事のテンプレートをベースに、環境変数やパスを自分仕様に書き換えたスクリプトを1つ作ってみてください。更新スクリプトでも移行スクリプトでも構いません。
ステップ2：ステージングで何度も練習する。作成したテンプレートをステージング環境で繰り返しテストし、エラーが出る条件と対処法を身につけてください。本番で「初めて」のコマンドを実行するのは避けましょう。
ステップ3：マルチサイトなら–urlを身体に染み込ませる。「対象サイトを間違えた」という事故を防ぐために、--urlを付けることを習慣化してください。
ステップ4：CIでWordPress環境を作ってsmoke testできるようにする。最初は簡単なチェックだけで構いません。自動テストの第一歩を踏み出すことが大切です。
WP-CLIは「使えるようになると、運用の景色が変わる」タイプの道具です。テンプレートを活用し、安全な手順を習慣化することで、「安全に、速く」WordPress運用ができるようになります。ぜひ日常のツールとして使いこなしてください。
コメント