2026年5月20日
2026年5月20日
WP-CLI とは?基本コマンド集|導入、wp core update-db、プラグイン・テーマの更新、DB バックアップ、URL 置換
WP-CLIは、WordPressの管理画面で行う作業の大半をコマンドラインから実行できる公式ツールです。この記事では、インストールと動作確認、実行ユーザーとパスの指定、コア・プラグイン・テーマの更新、ユーザー管理、データベースのバックアップとURL置換まで、日常の保守で使う基本コマンドを「失敗しにくい順番」で解説します。読み終えるころには、更新作業やサイト移行をコマンドで再現できるようになります(2026年10月現在の WP-CLI 2.x 系を前提にしています)。
WP-CLIをインストールして動作を確認する
WP-CLIは PHP で動く単体のファイル(phar形式)として配布されています。サーバーにSSHで入れる環境なら、次の手順で導入できます。レンタルサーバーの中には最初から wp コマンドが入っているところもあるので、先に wp --info を実行して確認してから入れると二重導入を避けられます。
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info
wp --info には、WP-CLIのバージョンと、WP-CLIを動かしているPHPのバージョンが表示されます。ここで表示されるのは「コマンドライン用のPHP」であり、Webサーバー(PHP-FPMなど)が使っているPHPとは別物の場合があります。管理画面のサイトヘルスに出るPHPバージョンと食い違っていても異常ではありませんが、PHPの拡張モジュール(mysqli など)がCLI側に入っていないとデータベースに接続できないので、エラーが出たらまずこの表示を確認してください。
使い方に迷ったら wp help で一覧、wp help plugin install のようにサブコマンドを付けると引数とオプションの説明が読めます。ネット上の古い記事より、手元の wp help のほうが今インストールされている版に正確です。
実行場所・実行ユーザー・対象サイトを正しく指定する
WP-CLIのつまずきで最も多いのが「どのWordPressに対して、誰の権限で実行しているか」の取り違えです。
WP-CLIは、カレントディレクトリから上にたどって wp-config.php を探し、見つかったWordPressを操作します。WordPressのディレクトリ以外で実行する場合は --path で場所を指定します。毎回指定するのが面倒なら、作業ディレクトリに wp-cli.yml を置いて path: /var/www/example.com/public のように書いておく方法もあります。
実行ユーザーにも注意が必要です。root のまま実行すると、WP-CLIは安全のため停止します。--allow-root を付ければ動きますが、プラグインのインストールなどで作られるファイルの所有者が root になり、あとで管理画面からの更新が失敗する原因になります。Webサーバーと同じユーザーで実行するのが基本です。
# Webサーバーのユーザー(例: www-data)として実行する
sudo -u www-data wp plugin list --path=/var/www/example.com/public
# マルチサイトで特定のサイトを対象にする
wp option get blogname --url=https://example.com/shop/
マルチサイトでは --url を省略するとメインサイトが対象になります。サブサイトの設定を変えたつもりがメインサイトを書き換えていた、という事故を防ぐため、マルチサイトでは --url を明示する習慣をつけておくと安心です。
コア・プラグイン・テーマを更新する
更新作業の前には、データベースのバックアップを取ります(後述の wp db export)。ファイル側も含めて戻せるようにしたい場合は、サーバーのスナップショットやバックアッププラグインも併用してください。
# 現在のバージョンと更新の有無
wp core version
wp core check-update
# 更新が出ているプラグインだけを一覧表示
wp plugin list --update=available
# 何が更新されるかを事前に確認してから更新
wp plugin update --all --dry-run
wp plugin update --all
# コア更新後はデータベースの更新処理も実行する
wp core update
wp core update-db
# テーマの更新
wp theme update --all
wp core update はファイルを入れ替えるだけで、バージョンをまたぐ際に必要なデータベースの更新処理は wp core update-db で行います。管理画面から更新した場合は自動で走る処理ですが、CLIでは別コマンドなので忘れやすい点です。
一括更新は便利な反面、どのプラグインで不具合が出たのか分からなくなりがちです。本番サイトでは wp plugin update プラグイン名 で1つずつ更新し、そのつどページの表示を確認する方法が安全です。特定のプラグインを除外したい場合は --exclude=プラグイン名 が使えます。
インストールと有効化は1行でまとめられます。不要になったプラグインは、無効化してから削除します。
wp plugin install query-monitor --activate
wp plugin deactivate query-monitor
wp plugin delete query-monitor
コアファイルの改ざんをチェックする
wp core verify-checksums は、WordPress.org が公開しているチェックサムとコアファイルを照合し、書き換えられたファイルや本来存在しないファイルを報告します。WordPress.org で配布されているプラグインについては wp plugin verify-checksums --all で同様の照合ができます。有料プラグインや自作プラグインは照合用のデータがないため対象外になります。
wp core verify-checksums
wp plugin verify-checksums --all
改ざんの疑いがあるときの初動チェックとして役立ちますが、照合できるのはコアと配布プラグインのファイルだけです。wp-content/uploads に置かれた不審なPHPファイルなどは検出されないので、これだけで安全と判断しないようにしてください。
ユーザーを管理する
# 管理者権限を持つユーザーだけを表示
wp user list --role=administrator --fields=ID,user_login,user_email
# ユーザーを作成(パスワードは自動生成されて表示される)
wp user create editor01 editor01@example.com --role=editor
# 権限の変更
wp user set-role editor01 author
# パスワードをリセット(新しいパスワードはユーザーにメールで通知)
wp user reset-password editor01
パスワードを --user_pass=... のようにコマンドへ直接書くと、シェルの履歴やプロセス一覧に残ります。手で設定する必要がある場合は、wp user update editor01 --prompt=user_pass のようにグローバルオプションの --prompt を使うと、値を対話入力にできます。
データベースをバックアップ・復元する
WP-CLIは wp-config.php の接続情報を読み取るので、データベース名やパスワードを打ち込まずにエクスポートできます。
# ファイルに書き出す
wp db export backup-$(date +%Y%m%d).sql
# 圧縮して書き出す
wp db export - | gzip > backup-$(date +%Y%m%d).sql.gz
# 復元(現在の内容は上書きされる)
wp db import backup-20261017.sql
# テーブルごとのサイズを確認
wp db size --tables
書き出したファイルを公開ディレクトリ(ドキュメントルート配下)に置いたままにすると、URLを推測されてダウンロードされるおそれがあります。保存先は公開領域の外にするか、作業後に移動してください。wp db import は既存のテーブルを上書きするので、実行前に現在の状態もエクスポートしておくと戻れます。
URLを一括置換する(サイト移行・https化)
ドメイン変更やhttps化では、記事本文やウィジェット設定に古いURLが残ります。データベースをテキストとして置換すると、PHPのシリアライズデータ(文字数を含む形式)が壊れ、ウィジェットや設定が消えることがあります。wp search-replace はシリアライズデータの文字数も合わせて書き換えてくれるので、移行時にはこちらを使います。
# まず件数だけ確認する(データベースは変更されない)
wp search-replace 'http://example.com' 'https://example.com' --dry-run --report-changed-only
# 内容に問題がなければ実行(guid列は書き換えない)
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid
--dry-run で表示されたテーブルと件数を見て、想定外のテーブルが大量にヒットしていないか確認してから本番実行します。置換文字列の末尾にスラッシュを付けるかどうかで結果が変わる点にも注意してください。guid 列は投稿の一意な識別子として扱われるため、慣例として書き換えない設定が推奨されています。
キャッシュ・パーマリンク・cronを操作する
設定を変えたのに表示が変わらない、特定のURLだけ404になる、予約投稿が公開されない、といった場面では次のコマンドが役立ちます。
# オブジェクトキャッシュを消去
wp cache flush
# 期限切れのトランジェントを削除
wp transient delete --expired
# リライトルールを再生成(管理画面でパーマリンク設定を保存するのと同等)
wp rewrite flush
# 予定されているcronイベントを確認し、期限が来ているものを実行
wp cron event list
wp cron event run --due-now
# メンテナンスモードの切り替え
wp maintenance-mode activate
wp maintenance-mode deactivate
wp cache flush は永続オブジェクトキャッシュ(Redis など)を使っている場合、同じキャッシュを共有している他のサイトの分まで消えることがあります。共有環境で使う場合は影響範囲を確認してから実行してください。
出力形式を変えて他のコマンドと組み合わせる
一覧系のコマンドは --format で出力形式を変えられます。table(既定)のほかに csv、json、count(件数のみ)、ids(IDをスペース区切りで出力)などがあり、--fields で列を絞れます。
# 公開済みの固定ページをCSVで出力
wp post list --post_type=page --post_status=publish --fields=ID,post_title,post_name --format=csv
# ゴミ箱の投稿の件数を確認してから完全削除する
wp post list --post_status=trash --format=count
wp post delete $(wp post list --post_status=trash --format=ids) --force
--force を付けた削除はゴミ箱を経由せずに消えるため、元に戻せません。--format=count で件数を確認し、データベースのバックアップを取ってから実行する流れを習慣にしておくと、取り返しのつかない操作を避けられます。
まとめ
- WP-CLIはphar形式で導入し、
wp --infoでCLI側のPHPと拡張モジュールを確認する - 実行はWebサーバーと同じユーザーで行い、対象は
--path(マルチサイトでは--url)で明示する - 更新は
--dry-runで確認してから実行し、コア更新後はwp core update-dbを忘れない - URL変更は
wp search-replaceを使い、--dry-runで件数を確かめてから本番実行する - 削除・インポート・置換の前には
wp db exportでバックアップを取る