コンテンツへスキップ
WordPress保守

WordPress 保守の品質を上げる SSH+WP-CLI ── 安全に更新するための仕組み

WordPress の定期保守といえば、本体・プラグイン・テーマの更新が中心になります。多くの現場では、管理画面にログインしてプラグインの「更新」ボタンを順に押し、表示確認をして次のサイトへ──という手順を繰り返しているのではないでしょうか。

この方式は、サイトが数件であれば成立します。ただ、扱うサイトが増えてくると、別の課題が見えてきます。

  • 管理画面の「全部更新」と「個別チェック」しか選択肢がない
  • 更新後に問題が起きたとき、どのプラグインが原因か切り分けにくい
  • バックアップ・表示確認・ロールバックのすべてが手作業
  • 担当者・時間帯・サイトごとに、保守の品質がばらつく

本記事では、SSH と WP-CLI という 2 つの基礎技術を組み合わせることで、人の手では再現の難しいレベルの安全性と再現性を担保する保守の仕組みを紹介します。

軸は「楽になるかどうか」ではなく、「保守作業として一定品質を担保できるかどうか」です。

1. SSH と WP-CLI とは何か

まず前提として、この 2 つの技術を整理します。

SSH（Secure Shell）

レンタルサーバーに対して、自分の PC から直接コマンドを送り込める接続方式です。FTP がファイル転送専用だとすれば、SSH は 「ファイル転送もできて、サーバー上で任意のコマンドも実行できる」 より万能な接続経路です。通信は暗号化され、鍵認証で運用するのが基本になります。

WP-CLI

WordPress をコマンドラインから操作するための公式ツールです。普段ブラウザで管理画面に入って行っているほぼすべての操作（更新・バックアップ・設定変更・ユーザー管理 等）を、コマンド 1 行で実行できます。

この 2 つが揃うと、自分の PC から、サーバー上の WordPress に対して、管理画面を経由せずに直接命令を送れるようになります。

管理画面を「お客様用の受付窓口」とすれば、SSH+WP-CLI は 「管理者用の通用口」 に相当します。ボタンを探す必要も、画面遷移を待つ必要もありません。命令を投げれば、サーバーが直接 WordPress に対して処理を実行します。

2. 安全な更新を実現する具体的な手法

ここからが本題です。SSH+WP-CLI を保守作業のどこに、どう組み込むかを順に解説します。

2-1. 更新前の DB バックアップ

更新作業で最も避けたいのは、何かが壊れたときに 戻せない状態 に陥ることです。WP-CLI なら、バックアップは 1 行で済みます。

wp db export backup_$(date +%Y%m%d_%H%M%S).sql

実行するとサーバー上に SQL ダンプが書き出されます。世代管理（古いバックアップを自動的に整理）まで含めれば、「更新前の状態にいつでも戻せる」状態を毎回確実に作ってから次の作業に進む という運用が成り立ちます。

管理画面からプラグイン経由でバックアップを取るやり方と比べて、

  • 確実に毎回実行される（人的な「忘れ」が起きない）
  • ファイル名にタイムスタンプを含められる（履歴が一目で追える）
  • 同じスクリプトで複数サイトを順次バックアップできる

といった違いが生まれます。バックアップの「品質」を毎回同じ水準に揃える という観点で重要な工程です。

2-2. 構成情報の棚卸し

更新作業に入る前に、現在の構成を機械可読な形で記録しておきます。

wp plugin list --format=json
wp theme list --format=json
wp core version

これで、稼働中のプラグイン名・バージョン・有効/無効状態がすべて取得できます。

補足: JSON とは
JSON（JavaScript Object Notation の略・ジェイソンと読みます）は、機械にも人にも読みやすい構造化データ形式です。プログラムからの再利用がしやすく、保存しておけばあとから差分比較や集計に使えます。本記事では「機械が解釈できる形でサイト構成を記録しておく」用途で登場します。

出力を JSON として保存しておけば、

  • 更新前後の差分があとから比較できる
  • 何のバージョンを何のバージョンに更新したか、第三者にも説明できる
  • 万一トラブルが起きたときに「直前の状態」を正確に復元できる

つまり 証跡（記録） が自動で残ります。クライアントへの定期レポートに添付できる粒度の情報が、コマンド 1 つで揃う形です。

2-3. 1 件ずつのステップ更新

ここが、管理画面方式と最も差が出る部分です。

管理画面では「全部更新」か「個別チェック」しか選択肢がありませんが、WP-CLI なら 1 件更新 → HTTP チェック → 次の 1 件 というステップを明示的に組めます。

wp plugin update plugin-name

特定のプラグインだけを狙い撃ちで更新できます。これを次のように直列化します。

for plugin in $(wp plugin list --update=available --field=name); do
  wp plugin update "$plugin"
  curl -sI -o /dev/null -w "%{http_code}\n" https://example.com/
  # → ここで 200 以外なら停止する判定を挟む
done

このステップ実行が成立すると、「壊れた瞬間に止まる」「どのプラグインが原因かが切り分けられる」 という保守上の重要な性質が手に入ります。

「全部一括更新して、表示が変だったらどれが原因か特定する」というやり方では、原因の切り分けが推測に頼りがちで、複数のプラグインが絡んだときには再現性も低くなります。ステップ更新では、どこで壊れたかが機械的に確定するため、特定作業そのものが不要になる場合もあります。これは「楽になる」という話ではなく、「人の手では再現の難しい精度で原因を切り分けられる」 という違いです。

2-4. HTTP ステータスチェック

更新の各ステップで、サイトが 200 を返しているかを毎回確認します。

curl -sI https://example.com/ | head -1

HTTP/2 200 以外（500 や 503 など）が返れば、直前の更新で何かが壊れた可能性が高いと判断できます。チェックポイントを更新の合間に挟むことで、異常を早期に検知 できる仕組みが組めます。

トップページだけでなく、お問い合わせ・カート・記事ページなど、サイトの主要動線を複数チェックする設計にすると、より確実に異常を捕捉できます。

2-5. ピンポイントロールバック

ステップ更新と HTTP チェックを組み合わせると、「特定のプラグイン更新が原因で壊れた」という状況を機械的に検知できるようになります。次に必要なのは、そのプラグインだけ を旧バージョンに戻す手段です。

WP-CLI ならこれも 1 行です。

wp plugin install plugin-name --version=1.2.3 --force

--version で旧バージョンを指定し、--force で上書きインストール。これで該当プラグインだけが以前のバージョンに戻ります。

管理画面でこれをやろうとすると、FTP で当該プラグインフォルダを差し替える、または旧バージョンの ZIP を再アップロードして展開する、といった手作業が発生します。WP-CLI なら同じ作業が 1 行で完結し、サイト全体ではなく、本当に壊れたプラグインだけを旧バージョンに戻して、残りの更新は引き続き適用する という細かい制御ができます。

サイト全体を巻き戻すと、せっかくの安全な更新分まで戻ってしまいます。「壊れた箇所だけを最小範囲で巻き戻す」 ほうが、サイトの状態としても、セキュリティ上も望ましい。これも「人の手では難しいレベルの精度」の一例です。

2-6. 証跡の自動記録

ここまでの工程をスクリプトに組むと、副産物として大量の証跡が残ります。

  • どのプラグインを、いつ、どのバージョンからどのバージョンに更新したか
  • 各ステップで HTTP ステータスはどうだったか
  • どこかで異常が起きた場合、どのタイミングで、どう自動対処したか
  • ロールバックが発生した場合、どのプラグインを、どのバージョンに戻したか

これらは保守業務の 品質を客観的に説明する材料 になります。「お任せください」だけで済む規模を超えると、「どんな確認をしたか」を示せることが信頼の根拠になります。

3. レンタルサーバー別の SSH / WP-CLI 事情

実運用では、サーバーごとに細かい違いがあります。主要な国内レンタルサーバーの状況を整理します。

Xserver

  • SSH 対応
  • wp コマンドが PATH に通っており、そのまま wp plugin list で動く
  • WordPress 簡単インストール時の初期構成が安定している

さくらインターネット

  • SSH 対応
  • 標準で WP-CLI が利用可能
  • パスや PHP バージョンの指定でつまずくケースは少ない

Heteml

  • SSH 対応
  • ただし wp コマンドはフルパスでの呼び出しが必要
  • 例: /usr/local/php/8.3/bin/php /home/users/0/<account>/bin/wp plugin list

ConoHa WING

  • SSH 対応（プランによる）
  • セキュリティ設定で SSH のポート番号や接続元 IP を絞っている場合があり、初期セットアップは丁寧に
  • WP-CLI の wp コマンドはサーバーごとに微妙にパスが異なる

共通の運用上の注意

  • WP-CLI のパスがサーバーごとに異なる ため、複数サイトを横断するスクリプトでは「サーバー別の WP-CLI パス設定」を持っておくと安定する
  • PHP バージョンが古いと WP-CLI が動かない。新しい WP-CLI ほど新しい PHP を要求する
  • SSH ホスト鍵の fingerprint を known_hosts に正しく登録する。MITM 対策として重要
  • 鍵認証で運用し、パスフレーズも設定する。秘密鍵そのものが漏れた場合の二段の防御になる

4. SSH 非対応サイトはどう扱うか

クライアントが契約しているサーバーが SSH 非対応である、あるいは SSH の接続情報を共有してもらえないというケースは、現実問題として残ります。

その場合は、ブラウザ自動操作（Playwright 等）でフォールバック する選択肢があります。管理画面に対して人間の操作を再現することで、更新自体は実行できます。

ただし、ブラウザ自動操作には次のような制約が残ります。

  • DB バックアップが SSH 経由ほど確実ではない（プラグイン依存）
  • ピンポイントロールバックは事実上できない（バージョン指定の差し戻し手段が限られる）
  • HTTP チェックや構成棚卸しの粒度が下がる
  • 管理画面の UI 変更で動かなくなる可能性がある

つまり、ブラウザ自動操作では保守の安全性レベルが SSH+WP-CLI より一段下がる のが事実です。これは保守契約の見直しや、SSH 対応サーバーへの移行提案を行う際の、客観的な根拠にもなります。

5. まとめ ── 保守の品質を一段上げる

SSH+WP-CLI は、「楽をするための技術」ではなく、「人の手では難しいレベルの安全性と再現性を担保するための技術」 です。

整理すると次のようになります。

  • 更新前 DB バックアップを毎回確実に取得する
  • プラグインを 1 件ずつステップ更新し、毎回 HTTP チェックを挟む
  • 異常があれば、該当プラグインだけをピンポイントでロールバックする
  • すべての操作の証跡を自動的に記録する

この組み合わせがあると、

  • 事故を未然に防げる（壊れる前に止まる）
  • ヒューマンエラーが減る（手順が機械化される）
  • 異常を早期に検知できる（チェックポイントが密に挟まる）
  • 保守の品質を客観的に説明できる（証跡が残る）
  • プロのサービスとしての標準を一段上げられる（保守レベルが安定する）

逆にいえば、SSH+WP-CLI を使わない手作業の保守は、仕組みとして安全性を担保しにくい ということでもあります。担当者の経験や注意力に依存するため、品質がばらつきやすい。これを技術で揃えていく、という発想です。

WP Maintenance Manager について

ここまで紹介した SSH+WP-CLI による安全な保守の仕組みを、コマンドを覚えなくても利用できる形にデスクトップアプリへまとめたのが WP Maintenance Manager です。

  • 複数サイトの SSH 接続情報をまとめて管理
  • DB バックアップ・1 件ずつのステップ更新・HTTP チェック・ピンポイントロールバックを GUI から実行
  • 更新ログ・スクリーンショットを自動記録（クライアント向けレポート出力にも対応）
  • ホワイトラベルレポートで会社情報・ロゴを入れた PDF も出力可

詳細・無料ダウンロードは WP Maintenance Manager 公式サイト からどうぞ。FAQ や ご利用ガイド も整備しています。

タグ