【第2章】WP-CLI実戦編：サーバー別注意点・移行/保守テンプレ・マルチサイト・CI/CD（初心者〜中級）

【第1章】WP-CLI完全入門：WordPressを"コマンド"で管理する基礎（初心者〜中級）

WP-CLIの導入方法から基本コマンドまで初心者向けに解説。インストール手順、必須の10コマンド、グローバルオプション、トラブルシューティングまで網羅。WordPress運用を効率化したい方必見のWP-CLI入門ガイドです。

raplsworks.com

サーバー別（Xserver / ConoHa / さくら / ローカルDocker）の注意点

WP-CLIが「動かない」「エラーになる」という問題の大半は、サーバー環境固有の要因によるものです。ここでは、代表的なサーバー環境ごとに「ハマりやすい罠」と「解決方法」を詳しく解説します。自分の環境に該当するセクションを重点的に読んでください。

まず、環境を問わず共通する主な原因は以下の3つです。CLIのPHPが違う（Webサーバー経由で動くPHPとコマンドラインのPHPが別物）、権限が噛み合っていない（ファイルの所有者・パーミッションの問題）、WordPressのパスがずれている（–pathオプションの指定ミス）。これらを意識しながら、各環境の特有事項を見ていきましょう。

Xserver（エックスサーバー）

Xserverは日本で最も利用されているレンタルサーバーの一つで、WP-CLI利用者も多いです。基本的にWP-CLIは問題なく動作しますが、いくつかの注意点があります。

ありがちなハマりポイント

Xserverではsudoコマンドが使えません。そのため、WP-CLIをシステム全体にインストールする方法（/usr/local/binへの配置）は使えず、ユーザーのホームディレクトリ内（~/bin）に配置してPATHを通す方法を使います。これは第1章で解説した「sudoができない環境向け」のインストール方法です。

また、CLIで使われるPHPとWebサーバーで使われるPHPのバージョンが異なることがあります。Xserverのコントロールパネルで「PHP8.2」を選択していても、SSH接続後にphp -vを実行すると古いバージョンが表示される、ということが起こり得ます。これは、CLI用のPHPが別途設定されているためです。

さらに、Xserverでは複数のドメインを1つのアカウントで管理することが多く、WordPressがpublic_html/直下ではなく、public_html/サブディレクトリ/に設置されていることがあります。この場合、--pathオプションでの正確なパス指定が重要になります。

1) ~/bin に wp を入れる（sudo無し）

以下のコマンドを順番に実行して、WP-CLIをインストールします。SSH接続後、ホームディレクトリで実行してください。

# ~/bin ディレクトリを作成
mkdir -p ~/bin
cd ~/bin

# WP-CLIのPharファイルをダウンロード
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# 実行権限を付与
chmod +x wp-cli.phar

# wpという名前に変更
mv wp-cli.phar wp

# PATHに ~/bin を追加（bashの場合）
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# 動作確認
wp --info

これでwpコマンドが使えるようになります。次回以降のSSH接続時も、.bashrcによってPATHが設定されるため、すぐにwpコマンドが使えます。

2) CLIのPHPバージョンを確認する

WP-CLIが正しく動作するためには、適切なバージョンのPHPが使われている必要があります。まず現状を確認しましょう。

# CLIのPHPバージョンを確認
php -v

# PHPの実行ファイルの場所を確認
which php

# WP-CLIの情報を確認（使用しているPHPも表示される）
wp --info

3) 本番運用のコツ

Xserverでの本番運用では、以下の点に注意してください。

スクリプトやcronで実行する場合は、--pathオプションを必ず付けてください。実行時のカレントディレクトリがWordPressディレクトリである保証がないため、パスの明示は事故防止になります。

重要な操作（プラグイン更新、テーマ更新、search-replaceなど）の前には、必ずwp db exportでデータベースのバックアップを取得してください。レンタルサーバーの自動バックアップに頼るのではなく、作業直前の状態を手元に残しておくことが重要です。

ConoHa（WING）

ConoHa WINGも人気のレンタルサーバーで、WP-CLIは基本的に問題なく動作します。ただし、いくつかの環境固有の注意点があります。

ありがちなハマりポイント

ConoHaでは、SSH接続の設定をコントロールパネル側で行う必要があります。初期状態ではSSHが有効になっていない場合があるため、まずコントロールパネルでSSHの有効化と公開鍵の登録を行ってください。

複数のサーバーやサイトを管理している場合、毎回接続情報を入力するのは手間がかかります。~/.ssh/configファイルを設定しておくと、短いホスト名でSSH接続できるようになり、作業効率が大幅に向上します。

PHPのバージョンや設置場所は環境によって異なることがあります。インストール後は必ずwp --infoで確認してください。

~/.ssh/config の設定例

ローカルマシンの~/.ssh/configファイルに以下のように設定しておくと、接続が簡単になります。

# ConoHa本番サーバー
Host conoha-prod
  HostName xxx.xxx.xxx.xxx
  User your-user
  Port 22
  IdentityFile ~/.ssh/id_rsa

この設定を行うと、以下のように短いコマンドでSSH接続できます。

# 設定前（毎回入力が必要）
ssh -i ~/.ssh/id_rsa -p 22 your-user@xxx.xxx.xxx.xxx

# 設定後（これだけでOK）
ssh conoha-prod

複数のサーバーを管理している場合は、それぞれにHost名を付けておくと、サーバー間の切り替えがスムーズになります。WP-CLI作業のテンポが格段に良くなるので、ぜひ設定しておいてください。

さくら（さくらのレンタルサーバ）

さくらのレンタルサーバは老舗のサービスで、プランによってSSHの利用可否や制限が異なります。WP-CLIを使う場合は、事前にプランの仕様を確認してください。

ありがちなハマりポイント

さくらのレンタルサーバでは、プランや契約時期によって使えるコマンドや機能に制限がある場合があります。特に古いプランでは、一部のシステムコマンドが制限されていることがあります。

WP-CLIがプリインストールされていない場合も多いので、Pharファイルで自分でインストールする必要があります。第1章で解説した「sudoができない環境向け」のインストール方法を使ってください。

また、容量やプロセスに制限があるプランでは、大きなデータベースのexport/importや、大量のファイル操作で処理が中断されることがあります。大規模な作業は時間帯をずらしたり、分割して実行したりする工夫が必要です。

まずは存在確認

SSH接続後、WP-CLIが使えるか確認します。

# wpコマンドが存在するか確認
which wp || echo "wp not found"

# 存在する場合は情報を表示
wp --info || true

「wp not found」と表示された場合は、WP-CLIがインストールされていません。第1章の「sudoができない環境向けインストール」の手順でインストールしてください。~/binディレクトリを作成し、そこにWP-CLIを配置してPATHを通す方法です。

ローカルDocker（開発・検証）

ローカル開発環境としてDockerを使っている場合、WP-CLIの実行方法にはいくつかのパターンがあります。どの方法を使うかは、Docker構成や好みによって選択してください。

パターンA：WordPressコンテナ内で wp を実行

WordPressのDockerコンテナ内にWP-CLIがインストールされている場合、docker compose execを使ってコンテナ内でコマンドを実行します。これが最もシンプルな方法です。

# コンテナ内でwp plugin listを実行
docker compose exec wordpress wp plugin list

この方法を使うには、WordPressコンテナにWP-CLIがインストールされている必要があります。公式のWordPressイメージには含まれていないため、Dockerfileでインストールするか、WP-CLI入りのカスタムイメージを使う必要があります。

パターンB：wordpress:cli コンテナを使う

Docker公式のwordpress:cliイメージは、WP-CLI専用のコンテナです。これをWordPressコンテナと同じネットワーク・ボリュームに接続して実行します。

# WP-CLI専用コンテナでコマンド実行
docker run -it --rm \
  --volumes-from some-wordpress \
  --network container:some-wordpress \
  wordpress:cli plugin list

--volumes-fromでWordPressコンテナのボリュームを共有し、--network container:でネットワークも共有します。これにより、WP-CLIコンテナからWordPressのファイルとデータベースにアクセスできます。

パターンC：ホスト側の wp から –ssh=docker-compose: で叩く（発展）

ホストマシンにインストールしたWP-CLIから、Dockerコンテナ内のWordPressに対してコマンドを実行する方法もあります。

# ホストのwpからDocker内のWordPressを操作
wp --ssh=docker-compose:wordpress:/var/www/html plugin list

この方法は、「ホストのwp → コンテナ内WordPress」という形でコマンドを実行できるため、CIパイプラインや、複数の開発環境を統一的に管理したい場合に便利です。ただし、設定がやや複雑になるため、まずはパターンAかBから始めることをおすすめします。

WP-CLIでできる”移行・保守”テンプレ（定型スクリプト）

WordPress運用の作業は、多くの場合「だいたい同じ流れ」になります。更新作業、ドメイン移行、障害復旧、定期メンテナンス…これらをテンプレート化しておくことで、作業漏れを防ぎ、誰が実行しても同じ品質を保てるようになります。

ここでは、初心者から中級者でも扱いやすい形にアレンジしたテンプレートを紹介します。コピペしてすぐ使えますが、必ず本番環境に適用する前に、ステージング環境でテストしてください。

テンプレ1：安全なアップデート（基本形）

WordPress本体、プラグイン、テーマを安全に更新するための基本テンプレートです。メンテナンスモードのON/OFF、バックアップ、更新、キャッシュクリアという一連の流れを自動化します。

処理の流れは、1)メンテナンスモードON → 2)DBバックアップ → 3)WordPress本体更新 → 4)プラグイン更新 → 5)テーマ更新 → 6)DB更新 → 7)キャッシュ削除 → 8)メンテナンスモードOFF となります。

#!/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置換つき）

旧ドメインから新ドメインへの移行時に使うテンプレートです。データベース内のURLを一括置換するsearch-replaceコマンドを使いますが、非常に強力なため、必ずdry-run（リハーサル）を挟んで確認してから本実行します。

処理の流れは、1)DBバックアップ → 2)dry-run（リハーサル）実行 → 3)確認入力 → 4)本実行 → 5)キャッシュ削除 となります。

#!/usr/bin/env bash
# ドメイン移行スクリプト（URL置換）
set -euo pipefail

# 設定（環境に合わせて変更）
WP_PATH="${WP_PATH:-/path/to/wordpress}"
WP="wp --path=${WP_PATH}"

# 引数から旧URL・新URLを取得（デフォルト値あり）
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カラムを置換対象から除外します。guidは一度設定されたら変更しないのが一般的な運用です。また、read -pで確認入力を求めることで、うっかり本実行してしまう事故を防いでいます。

テンプレ3：障害対応（ログイン不可・真っ白）最短復旧

「管理画面にアクセスできない」「サイトが真っ白になった」という緊急事態に、まずサイトを復旧させることを目的としたテンプレートです。原因調査は後回しで、とにかくサイトを立たせることを優先します。

#!/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ジョブの実行、キャッシュクリアといった軽い保守作業を行い、結果をログファイルに記録します。

#!/usr/bin/env bash
# 定期保守スクリプト（cron向け）
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

マルチサイト運用（–network / サイトURL指定）の実例

WordPressのマルチサイト機能を使っている場合、WP-CLIでの操作には特別な注意が必要です。対象サイトを間違えると影響範囲が大きいため、ここで丁寧に解説します。

1) まずサイト一覧を確認

マルチサイトで最初に行うべきは、ネットワーク内のサイト一覧を確認することです。

# サイト一覧を表示（ID、ドメイン、パスなど）
wp site list

# URLだけを一覧表示
wp site list --field=url

wp site listで表示される情報を確認し、操作対象のサイトを特定してから作業に入ります。特に本番環境では、作業前に必ずこの確認を行ってください。

2) 特定のサイトにだけ実行（–url）

マルチサイトの特定のサイトに対して操作を行う場合は、--urlオプションでサイトURLを指定します。これにより、「そのサイトにログインした状態」でコマンドを実行できます。

# 特定サイトのオプション値を取得
wp --url=https://sub.example.com option get blogname

# 特定サイトのプラグインを有効化
wp --url=https://sub.example.com plugin activate my-plugin

マルチサイトを運用する中級者になるほど、--urlオプションは頻繁に使うようになります。「どのサイトに対する操作か」を常に意識することが、マルチサイト運用の鍵です。

3) ネットワーク全体に実行（–network）

ネットワーク全体に対する操作（ネットワーク有効化など）には、--networkオプションを使います。

# プラグインをネットワーク有効化
wp plugin activate my-plugin --network

# ネットワーク全体のDB更新
wp core update-db --network

--networkを付けると、ネットワーク管理者としての操作になります。個別サイトではなく、ネットワーク全体に影響する操作であることを意識してください。

4) 全サイトへ同じ作業を流す（ループ例）

マルチサイトの全サイトに対して同じ操作を行いたい場合は、シェルスクリプトでループ処理を書きます。

# 全サイトのサイト名を取得
wp site list --field=url | while read -r u; do
  echo "== $u =="
  wp --url="$u" option get blogname
done

# 全サイトにオプション値を設定（慎重に！）
wp site list --field=url | while read -r u; do
  wp --url="$u" option update my_option my_value
done

初心者向けポイントとして、一括操作は便利ですが、ミスした場合の影響も大きくなります。最初は必ずoption getで現在値を確認してからoption updateを実行してください。いきなり本番環境で一括操作するのは危険です。必ずステージング環境で動作確認してから本番に適用してください。

5) ネットワーク管理者（スーパー管理者）

マルチサイトには「スーパー管理者」という特別な権限があり、ネットワーク全体の管理操作（サイトの追加・削除、プラグインのネットワーク有効化など）はスーパー管理者のみが行えます。

# スーパー管理者一覧を表示
wp super-admin list

# ユーザーをスーパー管理者に追加
wp super-admin add adminuser

# スーパー管理者から削除
wp super-admin remove adminuser

スーパー管理者権限は強力なので、必要最小限のユーザーにのみ付与するようにしてください。

CI/CD（GitHub Actions等）でWP-CLIを使う（導入〜最小テンプレ）

CI/CD（継続的インテグレーション/継続的デリバリー）環境でWP-CLIを使うことで、WordPress開発・運用の自動化が実現できます。ここでは、GitHub Actionsを例に、最小構成のテンプレートを紹介します。

CI/CDでWP-CLIを使うメリット

CI/CDでWP-CLIを使うメリットは大きく3つあります。

まず、「毎回同じ手順」を自動化できることです。人間が手動で行う作業は、どうしても手順の抜けやミスが発生します。CI/CDで自動化すれば、設定した手順が確実に毎回実行されます。

次に、PRごとにWordPress環境を立てて検証できることです。プルリクエストが作成されるたびに、自動的にWordPress環境を構築し、基本的な動作確認を行うことができます。これにより、マージ前に問題を発見できます。

さらに、将来的にデプロイや更新の自動化にも繋げられることです。最初は検証の自動化から始めて、慣れてきたらステージングへの自動デプロイ、最終的には本番デプロイの自動化まで段階的に進められます。ただし、本番への自動デプロイは慎重に検討してください。

最小テンプレ：GitHub ActionsでWordPressを用意してWP-CLIを叩く

以下は、GitHub ActionsでWordPress環境を構築し、WP-CLIで基本的な動作確認を行う最小テンプレートです。MySQLはserviceコンテナとして起動し、WP-CLIはPharファイルをダウンロードして使用します。

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

このテンプレートの拡張例として、サイト独自のプラグインをwp plugin installでインストールして有効化する、テスト用のダミーデータ（投稿、ユーザーなど）を投入する、Playwright等のE2Eテストツールと連携して画面テストを行う、といったことが考えられます。

search-replaceを安全に使いこなす（重要！）

wp search-replaceは、サイト移行時に最も活躍するコマンドですが、同時に最も「破壊力」が高いコマンドでもあります。雑に使うと取り返しのつかない事態になりかねないため、ここで安全な使い方を詳しく解説します。

安全の鉄則（初心者はこれだけ守ればOK）

search-replaceを使う際は、以下の5つの鉄則を必ず守ってください。これだけ守れば、大きな事故は防げます。

1. 必ず wp db export でバックアップを取る：これが命綱です。search-replaceは一度実行すると元に戻せないため、実行前の状態を必ず保存しておいてください。

2. 必ず --dry-run を先に実行する：dry-runは「実際には変更せず、何が変わるかだけを表示する」リハーサルモードです。予想通りの結果かどうか確認してから本実行に進んでください。

3. guid カラムは基本スキップする：--skip-columns=guidオプションを付けてください。guidはRSSフィードの識別子で、一度設定されたら変更しないのが一般的な運用です。

4. 最初は「URLだけ」を置換する：複雑な正規表現置換や、複数パターンの一括置換は、慣れてから挑戦してください。まずはシンプルなURL置換から始めましょう。

5. できればステージングで先にテストする：本番環境で一発勝負は危険です。同じ構成のステージング環境があれば、そこで先に同じ操作を実行して結果を確認してください。

よく使う形（まずはこれ）

最も基本的なsearch-replaceの使い方は以下の通りです。旧URLから新URLへの置換を行います。

# 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の結果には、対象となるテーブル名と、置換される行数が表示されます。例えば「wp_posts: 150件の置換」のように表示されるので、予想通りの件数かどうか確認してください。異常に多い場合や、予想外のテーブルが含まれている場合は、一度立ち止まって確認しましょう。

“置換されてない気がする”ときのチェックポイント

search-replaceを実行したのに、サイト上でURLが変わっていない気がする…という場合は、以下のポイントを確認してください。

siteurl / home オプションの確認：これらの値は、search-replaceだけでなくwp option updateでの直接更新が必要な場合があります。wp option get siteurlとwp option get homeで現在値を確認し、必要ならwp option updateで更新してください。

wp-config.php の確認：wp-config.phpにURL関連の定義（WP_HOME、WP_SITEURLなど）がある場合、データベースの値よりもそちらが優先されます。ファイルを直接確認してください。

CDN設定の確認：CDNを使用している場合、CDN側の設定変更も必要です。Cloudflareなどの設定を確認してください。

キャッシュのクリア：単にキャッシュが残っているだけの場合もあります。wp cache flushを実行し、ブラウザのキャッシュもクリアしてから再確認してください。

よくある事故チェックリスト（本番前に読む）

本番環境でWP-CLIを使う前に、以下のチェックリストを確認してください。これらをクリアしてから作業に入ることで、多くの事故を防げます。チェックリストをコピーして、作業記録として残しておくことをおすすめします。

事前チェック項目

作業を始める前に、以下の項目を確認してください。

□ wp --info でWP-CLIとPHPが正常に動作しているか確認した

□ wp core version が通り、WordPressが認識されていることを確認した

□ wp plugin list が通り、プラグイン読み込みに問題がないことを確認した

□ 実行場所のパスが正しいことを確認した（--pathオプションを付けるか、正しいディレクトリで実行）

□ ファイルの所有者・権限が適切であることをls -laで確認した

作業の安全装置チェック

具体的な作業に入る前に、以下の準備ができているか確認してください。

□ DBバックアップをwp db exportで取得した

□ search-replaceを行う場合、--dry-runで結果を確認した

□ メンテナンスモードのON/OFFコマンドを準備した

□ 失敗時の戻し手順（DB import、バックアップからの復元）を把握している

□ 作業内容と結果を記録するログの準備ができている

参考リンク（一次情報中心）

WP-CLIを使いこなすために、公式ドキュメントをブックマークしておくことをおすすめします。困ったときは、まず公式ドキュメントを確認する習慣をつけてください。

おわりに：次にやると伸びること

第1章と第2章を通じて、WP-CLIの基礎から実践的な運用テクニックまでを解説しました。ここまで読み進めていただいた方は、WP-CLIを「日常的に使える道具」として活用するための知識が身についているはずです。

最後に、この先さらにスキルを伸ばすためのステップをご紹介します。

WP-CLIは、「使えるようになると、運用の景色が変わる」タイプの道具です。最初は覚えることが多く感じるかもしれませんが、基本コマンドをいくつかマスターするだけでも、日々の運用が劇的に効率化されます。

テンプレートを活用し、安全な手順を習慣化することで、「安全に、速く」WordPress運用ができるようになります。ぜひ、WP-CLIを日常のツールとして使いこなしてください。

【第1章】WP-CLI完全入門：WordPressを"コマンド"で管理する基礎（初心者〜中級）

WP-CLIの導入方法から基本コマンドまで初心者向けに解説。インストール手順、必須の10コマンド、グローバルオプション、トラブルシューティングまで網羅。WordPress運用を効率化したい方必見のWP-CLI入門ガイドです。

raplsworks.com