WordPress を管理画面からしか触ったことがない方に、まず一行だけ見てもらいます。
| 1 | wp plugin update --all |
これで、インストール済みのプラグインが全部まとめて最新になります。管理画面で「更新」を何回もクリックしていた作業が、この一行で終わる。WP-CLI（WP コマンドラインインターフェース）は、そういう道具です。
私自身、最初は「黒い画面にコマンドを打つ」ことに身構えていました。でも一度使うと戻れなくなります。10個ほどコマンドを覚えれば、日々の更新やバックアップはほぼ手が止まらなくなりますし、管理画面が真っ白になったときの復旧手段にもなります。
検証環境：WordPress 6.9.4 / PHP 8.2 / WP-CLI 2.12.0 / Xserver / macOS Tahoe 26.4
この記事は2章に分けています。第1章（この記事）は、WP-CLI を動かして基本コマンドが打てるところまで。第2章は、サーバーごとのハマりどころ、コピペで使える移行・保守テンプレート、マルチサイト、CI/CD といった実戦の話です。
コマンドラインが苦手でも、読み終わる頃には手元で wp が打てる状態を目指します。
WP-CLI で日常のなにが変わるか
ふだん管理画面でクリックしている操作を、wp ... というコマンドに置き換えられる。それが WP-CLI です。2011年ごろに始まって、いまは WordPress 公式プロジェクトの一部になっています。世界中のサイト管理者が使っていて、運用まわりでは事実上の標準と言っていい道具です。
言葉で並べるより、何ができるかを見たほうが早いです。管理画面でもできる操作ばかりですが、コマンドにすると速くて、確実で、記録に残せます。
| やりたいこと | コマンド | ひとこと |
|---|---|---|
| 本体を更新 | wp core update → wp core update-db | クリック複数回が2行で終わる |
| プラグインを全更新 | wp plugin update --all | 10個でも20個でも一括。個別なら wp plugin update <slug> |
| テーマを全更新 | wp theme update --all | 使っていないテーマも更新対象にしておくと安全 |
| DBのバックアップ／復元 | wp db export / wp db import | phpMyAdmin を開かずに済む |
| URLの一括置換 | wp search-replace | サイト移行の主役。手作業やSQLより漏れが出にくい |
| キャッシュ削除 | wp cache flush | サーバー側から直接クリアできる |
| Cronの手動実行 | wp cron event run --due-now | 予約投稿が出ないときの確認に |
| 障害時の切り分け | --skip-plugins / --skip-themes | 問題のプラグインを読み込まずに起動できる |
パスワードを忘れた管理者のパスワードをリセットする、といった場面でも、データベースを直接いじらずに wp user で安全に変更できます。管理画面に入れないときの最後の手段になる、というのがWP-CLIのいちばん心強いところです。
私が便利だと感じている3つの理由
速いこと。管理画面でプラグインを10個更新するなら、更新して、戻って、また更新して、を10回やります。wp plugin update --all なら1行です。1サイト5分が30秒になり、10サイト管理していれば50分が5分になる。この差は毎週効いてきます。
同じ手順をそのまま再現できること。文章の手順書は、読む人によって解釈がずれます。コマンドはコピー＆ペーストすれば誰がやっても同じ結果になる。手順をコマンドの並びで書いておけば、それ自体がシェルスクリプトとして保存できて、次からは1回の実行で全部片づきます。
管理画面に入れないときの保険になること。プラグインの致命的エラーで画面が真っ白になっても、SSH でサーバーに入り --skip-plugins を付けて実行すれば、原因のプラグインを無効化できる見込みがあります。この一点だけでも、覚えておく価値があります。
WP-CLI を触る前に、3つの言葉だけ
最低限おさえるのは、CLI（ターミナルで命令する仕組み）、SSH（サーバーに入る手段）、ディレクトリ（コマンドを打つ場所）の3つです。ここだけ通れば、あとは実際に手を動かしながら覚えられます。
CLI ― ターミナルで命令する世界
CLI は「コマンドラインインターフェース」の略で、文字を打ってコンピュータに命令する方式です。Windows なら PowerShell やコマンドプロンプト、Mac ならターミナルがこれにあたります。
マウスでアイコンをクリックする GUI に対して、CLI はキーボードから文字を打ち込む。原始的に見えますが、同じ操作の繰り返しや条件つきの処理では、CLI のほうがずっと速いです。WP-CLI はコマンドの形がそろっていてヘルプも厚いので、CLI が初めてでも入りやすいほうだと思います。
SSH ― サーバーに入る入口
SSH（Secure Shell）は、ネットワーク越しに別のコンピュータへ安全につなぐ仕組みです。WP-CLI は基本的に WordPress が置いてあるサーバーの上で動かすので、そのサーバーにつなぐ手段として SSH が要ります。
自分の PC からレンタルサーバーへ SSH でつないで、その上で wp を打つ、という流れです。Docker や Local by Flywheel のようなローカル環境なら、SSH を挟まずにそのままターミナルから実行できます。
ディレクトリ ― いまどこで打っているか
WP-CLI を使い始めた人がいちばん最初にぶつかるのが、これです。
原因はたいてい一つで、いまいる場所（カレントディレクトリ）が WordPress のインストール先ではない、というだけです。WP-CLI は実行時にカレントディレクトリから wp-config.php を探し、それを見つけて設定を読み込みます。見つからなければ、この文言が出ます。
抜け道は2つあります。cd /path/to/wordpress で WordPress のディレクトリに移動してから打つか、コマンドに --path=/path/to/wordpress を付けて場所を明示するか。この2つを知っておくだけで、詰まる回数が一気に減ります。
入れる前に確認すること（ここで転びやすい）
導入前に見ておきたいのは、PHP が CLI で動くこと、WordPress の設置パスがわかっていること、ファイルの書き込み権限があること、の3点です。ここを飛ばすと「入れたのに動かない」に陥ります。
その1：PHP が CLI で動くか
WP-CLI は PHP で書かれたプログラムなので、サーバー上で PHP がコマンドラインから動く必要があります。確認はターミナルで一行です。
| 1 | php -v |
PHP のバージョンが表示されれば大丈夫です。ただしレンタルサーバーでは、Web サーバー経由で動く PHP と、コマンドラインで動く PHP が別物になっていることがあります。サイトは PHP 8.2 で動いているのに、CLI 用の PHP は 7.4 のまま、というずれです。この対処は第2章のサーバー別のところで詳しく書きます。
その2：WordPress の場所がわかっているか
WP-CLI を動かすには、WordPress の設置ディレクトリを知っている必要があります。よくある場所は、public_html/（Xserver など多くのレンタルサーバー）、/var/www/html/（VPS や Docker の既定）、htdocs/（一部のサーバー）あたりです。
わからなければ wp-config.php を探すのが確実です。
| 1 2 | # ホームディレクトリ配下を探す例 find ~ -maxdepth 4 -name wp-config.php 2>/dev/null |
その3：ファイルを書き換えられるか
プラグインやテーマの更新では、WP-CLI がファイルを書き換えます。所有者やパーミッションが合っていないと、更新に失敗したり、所有者が変わってしまったりします。まずは ls -la で現状を確認してください。WP-CLI を動かすユーザーと WordPress ファイルの所有者が同じであるのが理想です。
インストール（Phar が無難）と動作確認
WP-CLI の導入は、Phar ファイルを落として実行権限を付けるだけです。sudo が使える VPS でも、sudo が使えないレンタルサーバーでも、手順に大きな違いはありません。Phar は PHP アプリを一つのファイルにまとめたもので、環境による差がいちばん少ない入れ方です。
sudo が使える環境
sudo が使えるなら、システム全体で使えるよう /usr/local/bin に置きます。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # WP-CLIのPharファイルをダウンロード curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar # 動作確認（この時点ではphpコマンドで実行） php wp-cli.phar --info # 実行権限を付与 chmod +x wp-cli.phar # システムで使えるように移動（sudoが必要） sudo mv wp-cli.phar /usr/local/bin/wp # wpコマンドとして動作確認 wp --info |
最後の wp --info でバージョンや PHP 情報が出れば、インストールは完了です。
sudo が使えない環境（レンタルサーバー向け）
多くのレンタルサーバーでは sudo が使えません。その場合は ~/bin に置きます。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | # ~/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 |
~/.bashrc に PATH を書いておくと、次に SSH でつないだときも wp が使えます。zsh を使っているなら ~/.zshrc に足してください。
まずはこれだけ動かす
| 1 2 3 4 5 6 7 8 9 10 11 | # WP-CLI自体の動作確認 wp --info # WordPressのディレクトリに移動 cd /path/to/wordpress # WordPressのバージョンを確認 wp core version # プラグイン一覧を表示 wp plugin list |
バージョン番号やプラグイン一覧が出れば、セットアップは終わりです。wp core version でエラーになるなら、ほぼ --path の指定漏れか、CLI 側の PHP バージョンの問題です。
コマンドの「型」とヘルプの引き方
WP-CLI のコマンドは wp <カテゴリ> <操作> [引数] [--オプション] という形で一貫しています。この型さえつかめば、初めて見るコマンドも組み立てられます。迷ったら wp help が最強の辞書です。
基本の形
カテゴリは操作の対象（plugin / theme / core / user / db など）、操作は何をするか（list / install / update / delete など）です。
| 1 2 | # プラグインをインストールして有効化する例 wp plugin install contact-form-7 --activate |
分解すると、plugin がカテゴリ、install が操作、contact-form-7 が引数（プラグインのslug）、--activate がオプション（インストール後に有効化もする）です。この形が身につくと、テーマを更新したいなら wp theme update、ユーザーを作りたいなら wp user create、と自然に手が動くようになります。
困ったらヘルプに全部ある
| 1 2 3 4 5 6 7 8 | # 全体のヘルプ（利用可能なカテゴリ一覧） wp help # 特定カテゴリのヘルプ（pluginで使える操作一覧） wp help plugin # 特定コマンドの詳細ヘルプ（plugin installの使い方） wp help plugin install |
wp help plugin install を打つと、説明、引数、オプション、そして実行例まで出ます。とくに EXAMPLES の欄はそのままコピペできる形なので、最初はここを写経するのがいちばん早いです。
覚えておきたいグローバルオプション
数あるオプションの中で、最初に押さえたいのは --path（場所指定）、--skip-plugins / --skip-themes（障害時の切り札）、--debug（原因調査）の3種です。
–path＝WordPressの場所を指定する
--path は WordPress の設置ディレクトリを明示するオプションです。これを付ければ、いまどこにいても指定した WordPress に対してコマンドが打てます。
| 1 2 | # どこからでも指定したWordPressに対して実行できる wp --path=/var/www/html plugin list |
cron やシェルスクリプトから WP-CLI を動かすときは、とくに大事です。--path を毎回付ける癖をつけておくと、実行場所を取り違える事故を防げます。
–url＝どのサイトとして動かすか
単一サイトではあまり意識しませんが、マルチサイトでは要るオプションです。
| 1 2 | # 特定のサイトに対して操作 wp --url=https://example.com option get home |
マルチサイトの詳しい話は第2章に回しますが、いまは「マルチサイトでは --url が要る」とだけ覚えておいてください。
–skip-plugins / –skip-themes＝障害対応の切り札
実行時にプラグインやテーマの読み込みをスキップするオプションです。問題のあるプラグインがあると WP-CLI 自体が巻き込まれてエラーになることがありますが、これを付ければ最小構成で WordPress を起動できます。
| 1 2 | # プラグインとテーマを読み込まずに実行 wp --skip-plugins --skip-themes core version |
–debug＝何が起きているか見たいとき
| 1 2 | # デバッグ情報を表示しながら実行 wp --debug plugin list |
内部処理のログが細かく出るので、「なぜか動かない」の原因調査に使います。ふだんは要りませんが、詰まったときに思い出せると助かります。
最初に覚える10コマンド
WP-CLI には数百のコマンドがありますが、毎日使うのは10個くらいです。「情報確認」「プラグイン」「テーマ」「キャッシュ」「DBバックアップ」の5つ、それぞれ2コマンドずつ覚えれば、日常の大半は回ります。
1. 情報確認
| 1 2 3 4 5 | # WP-CLI自体の情報（PHPバージョン等も確認できる） wp --info # WordPressのバージョン確認 wp core version |
2. プラグイン
| 1 2 3 4 5 6 7 8 | # プラグイン一覧を表示 wp plugin list # 更新可能なプラグインだけを表示 wp plugin list --update=available # 全プラグインを一括更新 wp plugin update --all |
3. テーマ
| 1 2 3 4 5 | # テーマ一覧を表示 wp theme list # 全テーマを一括更新 wp theme update --all |
4. キャッシュ・リライトルール
| 1 2 3 4 5 | # オブジェクトキャッシュをクリア wp cache flush # リライトルールを再生成 wp rewrite flush |
5. DBバックアップ（作業前の儀式）
| 1 2 | # 日時付きのファイル名でDBをエクスポート wp db export backup-$(date +%F-%H%M).sql |
$(date +%F-%H%M) の部分は、実行時の日時に置き換わります。backup-2026-04-01-1430.sql のようなファイル名になり、いつのバックアップかがひと目でわかります。
安全に使い続けるための型
安心して使い続けるコツは、3ステップに集約できます。作業前にDBを export、更新はメンテナンスモードをONにしてから、実行したコマンドと結果を記録する。この3つです。
1. 何かする前にDBを export
| 1 2 | # 作業前にバックアップを取得 wp db export before-$(date +%F-%H%M).sql |
ファイル名を before-作業内容-日時.sql のようにしておくと、後から探しやすくなります。
2. 更新時はメンテナンスモードを使う
更新の最中に訪問者がアクセスすると、表示崩れやDBの不整合が起きることがあります。短い更新でも、メンテナンスモードをONにしてからのほうが安全です。
| 1 2 3 4 5 6 7 8 9 10 | # メンテナンスモードをON wp maintenance-mode activate # ここで更新作業を実行 wp plugin update --all wp theme update --all wp core update # メンテナンスモードをOFF wp maintenance-mode deactivate |
作業が終わったら、OFFに戻すのを忘れないでください。
3. 作業ログを残す
残すのは、実行したコマンド（そのままコピペできる形で）、日時、結果（成功か失敗か）、複数人なら作業者の4点です。テキストファイルへの追記でも、Slack への投稿でもかまいません。残す習慣そのものが効いてきます。
困ったらここ：よく出るエラーと最短の直し方
WP-CLI でよく出るエラーは、だいたい3つに収まります。WordPressが見つからない（パスの問題）、PHPバージョンの食い違い、プラグインの巻き添え。それぞれ --path 指定、PHP の切り替え、--skip-plugins で片づきます。
Error: This does not seem to be a WordPress installation.
いちばん出会うエラーです。WP-CLI が wp-config.php を見つけられなかったときに出ます。--path で正しいディレクトリを指定してください。
| 1 | wp --path=/path/to/wordpress core version |
それでも直らないなら、そのパスに本当に wp-config.php があるか確かめます。パスのタイプミスが原因のこともよくあります。
PHP まわりで失敗する（CLIのPHPが違う）
レンタルサーバーで起きやすいエラーです。Web 用の PHP と CLI 用の PHP が別バージョンになっているのが原因です。
| 1 2 3 4 5 6 7 8 | # CLIのPHPバージョンを確認 php -v # PHPの実行ファイルのパスを確認 which php # WP-CLIが使っているPHP情報を確認 wp --info |
サーバー別の具体的な直し方（別バージョンのPHPへパスを通す方法など）は、第2章で扱います。
プラグインの致命的エラーにWP-CLIも巻き込まれる
| 1 2 3 4 5 | # 最小構成でプラグイン一覧を表示 wp --skip-plugins --skip-themes plugin list # 問題のプラグインを無効化 wp --skip-plugins --skip-themes plugin deactivate 問題のプラグインslug |
どのプラグインが原因か見当がつかないときは、wp plugin deactivate --all で全部止めてから、一つずつ有効化して犯人を特定する手もあります。
次の自分へ：第1章のメモ
ここまでで、WP-CLI が動いて、基本のコマンドが打てる状態になりました。第1章で手に入れたのは、だいたいこの5つです。
Phar で入れて wp --info が通ること。wp <カテゴリ> <操作> の型で読めること。困ったら wp help を引くこと。日常は10コマンドで回ること。そして何かする前にDBを export すること。
この5つが手に馴染めば、第1章の目的は達成です。
第2章は、この基礎の上に実戦を積みます。Xserver・ConoHa・さくら・Docker それぞれのハマりどころと直し方、コピペで使える移行・保守テンプレート4種、マルチサイト運用、GitHub Actions での CI/CD まで。とくに search-replace を安全に使うための型は、サイト移行を控えている人に読んでほしいところです。
コメント