--skip-plugins=<対象名>）が動的に付与されるため、ロールバック対象のプラグインが Fatal Error を起こしている場合でもロールバック処理自体は確実に実行されます。さらに「積極的自動修正モード」をONにしているサイトは、上記でも復旧しなかった場合の最終手段として DB とファイルをまとめて更新前の状態に戻します。なお、テーマの更新は一括処理のため個別ロールバックの対象外、データベース破損など深刻な障害、SSH を使用しないブラウザのみ更新モードでは自動復旧の対象外となる場合があります。
コア更新後の HTTP チェックで異常を検知すると、まずコアを直前のバージョンに自動で巻き戻します。その後の挙動は巻き戻しの結果によって 2 パターンに分かれます:
後者の場合は、コアの状態を確認・修復してから（必要に応じて WordPress 管理画面や手動 SSH で）メンテナンスを再実行してください。実行ログには「コアロールバック後の後続更新を中断」と明記され、レポート・メールにも反映されます。
通常運用では OFF（既定） のままで多くの障害に対応可能です。ON にすると、メンテナンス完了後にもサイトが壊れている場合の 最終手段としての包括的な自動復旧 が追加で動作します。
| 機能 | OFF （既定） |
ON |
|---|---|---|
| 📦 メンテナンス開始時 | ||
| DB バックアップ取得（更新前） | ✅ | ✅ |
| 🔧 各更新中（プラグイン1件ずつ・コア更新） | ||
| ピンポイントロールバック 更新後 HTTP チェック → 5xx / 4xx 退行 / 接続不可を検知 → 旧版に巻き戻し → 復旧確認 | ✅ | ✅ |
| WP-CLI 安全モード（操作ごとに最適なスキップ指定） コア/DB/翻訳系は全スキップ・プラグイン検出/更新は全ロード・ロールバックは対象を指定スキップ | ✅ | ✅ |
| 🔍 メンテナンス完了後の点検 | ||
| トップページの HTTP チェック・スクリーンショット比較 | ✅ | ✅ |
| Fatal ログから原因プラグインを特定して自動停止 ※ SSH 接続が設定されているサイトのみ | ✅ | ✅ |
| メール通知（成功 / 要確認 / エラー） | ✅ | ✅ |
| ⚡ 上記でも復旧しなかった場合の最終手段 | ||
| DB 全体ロールバック（バックアップから復元） | — | ✅ |
| 更新したプラグイン・コアのファイル一括巻き戻し ※ WordPress.org 未掲載の有料プラグインはファイル復元対象外（停止のみ） | — | ✅ |
キャッシュ強制削除（wp cache flush + cache フォルダ削除） | — | ✅ |
| テーマ自動切替（Twenty シリーズへ一時切替） ※ Twenty 系が無い場合は切替せず警告メール送信 | — | ✅ |
| 追加プラグイン停止（Fatal ログから別の原因が見つかった場合） | — | ✅ |
| wp doctor で WordPress 健全性診断 | — | ✅ |
ON にすべきケース
注意点
おすすめの始め方: まず OFF で運用を始め、上の表の「📦 / 🔧 / 🔍」カテゴリだけで多くのケースに対応できます。それでも対応しきれない複雑な障害が起きたタイミングで ON への切替を検討してください。
テーマは個別ロールバックの対象外です。テーマ更新は WordPress 標準の一括更新（wp theme update --all）で実行されるため、更新後にサイトが壊れていても「どのテーマの更新が原因か」を特定できません。
プラグイン・WordPress 本体（コア）の更新は1件ずつ実行＆ HTTP チェックを挟むため、原因特定とピンポイントロールバックが可能ですが、テーマは構造上それができません。これは設計上の制約です。
テーマ起因で問題が起きた場合の動作:
補足: 実運用ではテーマ起因の障害はプラグイン起因の 1/10 以下と統計的に少ないため、優先度を下げています。
はい、確実に実行できます。本アプリは、ロールバックを実行する WP-CLI コマンドに「壊れたプラグインだけをロード対象から除外する」指定スキップ（--skip-plugins=<対象プラグイン名>）を動的に付与しています。
これにより、たとえ更新したプラグインが Fatal Error を起こしていても、ロールバックを実行する WP-CLI 自身はそのプラグインを load せず、確実にファイル置き換え（旧バージョンへの巻き戻し）が完了します。他の正常なプラグインや有料プラグインは引き続きロードされるため、独自更新フィルター等は通常通り発火し続けます。
具体的な処理の流れ:
wp plugin install X --version=旧 --force --skip-plugins=X を実行補足: PHP-CLI（コマンドライン）と PHP-FPM（Web）は別プロセスのため、Web 経由でサイトが完全に動かない状態でも SSH 経由のロールバックは独立して実行できます。
wpmm_backups/ フォルダ）とアプリを動かしているPCのローカルの2か所に保存されます。メンテナンス実行時に backup_YYYYMMDD_HHMMSS.sql が自動生成され、SSH/SFTP経由でローカルにもダウンロードされます。サーバー上・ローカル共に最新3世代のみ自動保持され、古いファイルは順次削除されるためディスクが溜まり続ける心配はありません。wpmm_backups/ フォルダには二重の防御を自動で適用しています。.htaccess による全リクエスト遮断：Apache 系サーバー（エックスサーバー・さくら・Heteml・ConoHa WING 等の主要レンタルサーバー）では .htaccess で当該フォルダ配下を全て 403 Forbidden に倒します。ブラウザから直接 SQL ファイルの URL を推測されても閲覧できません。Apache 2.2 / 2.4 両系統に対応した記述を入れています。index.php による Nginx 用フォールバック：.htaccess を解釈しない Nginx 系サーバーに対しても、フォルダ内に「即 403 を返す」だけの index.php を自動配置します。/opt/php-8.2/bin/php /usr/bin/wp）を登録します。多くの場合、これで全サイト動作します。/opt/php-8.3/bin/php /usr/bin/wp）。空欄ならプロファイル値が使われます。wp コマンドを実行したときの PHP バージョン（CLI 側）が別管理」になっていることです。CLI 側はデフォルトで古い PHP（7.0 系）が使われるため、最新の WP-CLI 互換コードが Parse error を起こします。/opt/php-<バージョン>/bin/php /usr/bin/wp/opt/php-7.4/bin/php /usr/bin/wp/opt/php-8.1/bin/php /usr/bin/wp/opt/php-8.3/bin/php /usr/bin/wpv1.6.2 新機能です。ツールバーの「プラグイン更新」ボタンから開くダッシュボードで「サイト × プラグイン」のチェックボックスを選び、フッターの「選択プラグインを更新」ボタンを押すと、選んだプラグインだけを更新できます。
通常のメンテナンスとの違いは「対象範囲だけ」です：
他社ツールの「Update All」ボタンとは思想が違います。それらは安全網なしで一気に更新するため、問題が起きてもピンポイント復旧ができません。本アプリの選択プラグイン更新は安全運用ポリシーを保ったまま対象を絞れるのがポイントです。
ログ履歴の一覧では「選択更新」タグが付与され、対象プラグイン名も記録されます。レポートにも「今回は対象プラグインだけを更新しました」の旨が日英で明記されるので、クライアントへの説明資料としてそのまま使えます。
以下の環境で動作します。
| 項目 | Windows | Mac |
|---|---|---|
| OS | Windows 10 / 11（64bit） | macOS 13.5 Ventura 以降 |
| CPU | 64bit プロセッサ | Intel / Apple Silicon 両対応 |
| メモリ | 4GB 以上推奨 | |
| 必須環境 | インターネット接続、WordPress 5.0 以上のサイト | |
SSH接続では、パスワードの代わりに「秘密鍵」と「公開鍵」のペアを使います。秘密鍵はあなたのパソコンに保存するファイル、公開鍵はサーバー側に登録するデータです。この2つが揃って初めて接続できます。
主要サーバーでの鍵の発行方法：
詳しい手順はご利用ガイドの「SSH接続・WP-CLIとは？鍵の準備方法」セクションをご覧ください。
ダウンロードした秘密鍵ファイルをパソコン上のどこに保存したか、そのファイルパスを入力します。
~/.ssh/ファイル名.key（例：~/.ssh/xserver_id_rsa）C:\Users\ユーザー名\.ssh\ファイル名.key鍵ファイルは .ssh フォルダ（なければ作成）に移動してから、そのパスを入力するのが一般的です。
ほとんどの場合、空白のままで大丈夫です。エックスサーバー・さくらなど主要なレンタルサーバーには WP-CLI が標準搭載されており、空白でも自動的に動作します。
WP-CLI をカスタムパスにインストールしている場合や、接続テストで「WP-CLI が見つかりません」と表示された場合のみ、サーバー管理者に確認の上パスを入力してください。ConoHa WING で同エラーが出た場合は、次の項目をご参照ください。
v1.5.9 以降では「🔍 詳細診断」ボタンが新設されました。SSHプロファイル編集画面の「接続テスト」ボタン横にあります。サーバーの状態を読み取り専用で観測し、推奨される WP-CLI パスを「参考目安」として提案します（ConoHa WING を含む 4 ホストで実機検証済み）。提案値が必ず正しいことは保証しませんので、必ず接続テストで再確認してください。
ConoHa WING は初期状態で wp コマンドが入っていないため、SSH 接続後に以下の 1 行コマンドで ~/bin/wp に設置するのが確実です（自動診断で詰まった場合の手動 fallback）。
mkdir -p ~/bin && cd ~/bin && \
curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
mv wp-cli.phar wp && chmod 755 wp && ~/bin/wp --info最後の ~/bin/wp --info で WP-CLI のバージョン情報が表示されれば成功です。SSH ターミナルが手元にない場合、ConoHa コントロールパネル → サーバー管理 → コンソール からブラウザ内で SSH セッションを開けます。
⚠️ ファイルマネージャーや FTP クライアント経由の wp-cli.phar アップロードは推奨しません。転送経路でファイルが書き換わって「broken signature」エラーが発生する事象が複数のホストで確認されています（実機検証済み）。SSH＋curl で直接ダウンロードする方式が最も確実です。
詳しい手順はご利用ガイドの ConoHa WING タブをご覧ください。
ヘテムルや一部の共有サーバーでは、php8.3 のようなバージョン番号付きの PHP は使えるものの、シェル PATH に素の php コマンドが置かれていない構成になっています。WP-CLI の起動行（#!/usr/bin/env php）が「php が見つからない」と判定して失敗するのがこのエラーの正体です。
対処は WP-CLI Path 欄に PHP の絶対パスと WP-CLI ファイルを併記すること。例えばヘテムルなら：
/usr/local/bin/php8.3 /home/users/0/(ユーザー名)/bin/wp「🔍 詳細診断」ボタン（v1.5.9 以降）を実行すると、PHP の絶対パスと WP-CLI ファイルパスを自動で組み立てて推奨してくれます。提案された値を「↑この値を WP-CLI Path 欄に入力する」ボタンで反映してから接続テストで再検証してください。
参考目安として提案される値です。サーバー固有の事情によって不正確な場合もあるため、接続テストで動作確認することを必ず行ってください。
はい。v1.6.0 から、SSHプロファイル編集画面の「🔍 詳細診断」結果に 「📦 WP-CLI を自動インストール」セクションが表示されます（WP-CLI が見つからず・ホーム書き込み可・GitHub 到達性 OK のサーバーに限り表示）。SSH 越しで WP-CLI（PHAR ファイル）を ~/bin/wp に自動設置できます。
誤設置を防ぐため 2 段階方式になっています：
~/wpmm_install_test_<時刻>/wp に設置して動作確認します。既存の ~/bin/wp には一切触らないため、安全に試せますwp ファイルがある場合は wp.broken_backup_<時刻> として退避されます（最新 3 件まで自動保持）途中で失敗しても壊れた状態のファイルは残りません。tmp ファイルにダウンロード → サイズ検証 → 動作検証（--info）を通過してから初めて本番ファイル名にリネーム（atomic 設置）するためです。検証段階で失敗した場合は tmp が削除され、退避していた既存 wp が自動的に元の場所に戻されます。
実行された SSH コマンド・サーバー応答・終了コードはすべて logs/install_wpcli_<時刻>.json に保存され、後から確認できます。
対応サーバー：書き込み可能なホームディレクトリ・curl または wget いずれか・GitHub への outbound HTTPS が利用可能なサーバー（一般的なレンタルサーバーはほぼ該当）。outbound 制限のあるホスト（一部のマネージド環境）では、エラーが明示的に表示されます。
SSHプロファイル編集画面の「接続テスト」ボタン横に v1.5.9 で追加された機能です。SSH 越しにサーバーへ接続し、読み取り専用のコマンドだけを実行して以下を観測します。
これらの観測値から「最も確からしい WP-CLI Path」を 「参考目安」として提案します。サーバーには一切書き込みを行いません（一時的な書き込み権限テスト用に ~/.wpmm_diag_test_$$ という名前のファイルを一瞬作って即削除する処理のみ）。
⚠️ 提案値は確証ではありません。サーバー固有の事情（カスタム PHP セレクタ・chroot 環境・proxy 制約等）を完全にはカバーできないため、不正確な場合があります。提案値を入力した後は必ず「接続テスト」で動作確認してください。
エックスサーバー・さくらインターネット・ConoHa WING・ヘテムルの 4 ホストで実機検証済みです。それ以外のサーバーでも動く可能性は高いですが、保証はできません。
はい。カテゴリーとタグの2系統で柔軟に整理できます。
アプリ右上の ⚙設定 → 「カテゴリー・タグ管理」 から登録・編集・削除できます。サイト追加・編集画面の 登録情報タブ でサイトに割り当て、登録サイト一覧の上部ドロップダウンから絞り込み検索ができます。
タグフィルタは「いずれかを含む」（OR）と「すべて含む」（AND）を切り替えられます。検索ボックスとの併用も可能です。
はい。登録サイト一覧の「最終メンテ」欄にある 「🕒 履歴 ›」 リンクをクリックすると、そのサイトのログ履歴だけに絞り込んだ状態でログ画面が開きます。
サイト名を後から変更しても履歴は引き継がれます。内部的な安定識別子でログを追跡しているため、リネーム前後のログを同じスコープで確認できます。
画面上部の「すべてのログを表示」リンクで全件表示に戻せます。本機能の導入（v1.5.8）以前に記録された古いログは内部識別子を持たないため、サイト名でのマッチングで表示されます。
はい、3つの方法で柔軟に削除できます。
いずれの場合も削除前に**削除対象件数を表示する確認ダイアログ**が出ます。「全件削除」は何も絞り込みがない状態でのみ表示され、本当に全部消したい時の最終手段として残しています。
削除前に確認ダイアログで挙動を選べるため、サイト本体のデータは安全に保たれます。
サイト本体の設定（SSH情報・WordPressパス・実行履歴等）は一切影響を受けません。
v1.6.2 から正式対応しました。サイト編集画面の WordPress情報タブ 内に折りたたみの「🔐 Basic 認証（任意・ベーシック認証で保護されている場合のみ）」セクションがあり、ID とパスワードを入力できます。パスワードは暗号化して保存されます。
Basic 認証情報は次の処理で使われます：
SSH / WP-CLI 経由の更新自体は Basic 認証の影響を受けないため、上記 3 機能を使わないなら認証情報の登録は不要です。同じ Basic 認証セクション内の「🔗 接続テスト + サムネイル取得」ボタンを押すと、入力した認証情報で疎通確認＆サイト一覧用サムネイルの撮影が一度に完了します。
推奨用途: ステージング・開発環境・社内専用サイト・限定公開のキャンペーンサイトなど、HTTP Basic 認証で保護されている WordPress サイト全般。
wpmm_backups/ フォルダ（サイト設定の「WordPressパス」に設定したフォルダ配下）に backup_YYYYMMDD_HHMMSS.sql という名前で保存されており、FTPソフトや、サーバーのコントロールパネルのファイルマネージャーから手動で取得できます。wpmm_backups/ フォルダには .htaccess と index.php が自動配置され、外部からの直接アクセスはブロックされます。
~/.ssh/id_rsa）を新しいPCにコピーするv1.6.2 新機能です。ツールバーの「プラグイン更新」ボタンから開きます。全サイトの「要更新プラグイン」を一画面で横断的に確認できる、いわゆる管理者用ダッシュボードです。
表示形式はプラグイン名でグループ化されます。たとえば「Elementor: 3 サイトで要更新（4.0.0 → 4.0.8）」のように一覧されるので、「このプラグインが古いサイトはどこか」が即座に分かります。展開すると影響サイトの一覧と各サイトの旧→新バージョンが見えます。
通常メンテとの使い分け：
ダッシュボードでチェックを入れて「選択プラグインを更新」ボタンを押すと、選んだ「サイト × プラグイン」のペアだけが更新されます。DB バックアップ・HTTP チェック・ピンポイントロールバック・ビジュアル確認・サマリーメールなど、安全網は通常メンテとまったく同じです。
大量サイトを管理している場合、初回の取得は SSH 並列処理で 30〜60 秒かかることがあります。取得結果はブラウザに 24 時間キャッシュされ、再起動後でも即時表示されます（メンテナンス実行後は自動でキャッシュが無効化されて常に最新の状態が出ます）。
/wp-login.php 以外に変わっている」です。サイト設定の「WordPress管理画面URL」が現在のログインURLと一致しているか確認してください。
10022（標準の22ではないので注意）、さくらインターネット（スタンダード以上のレンタルサーバ）= 22、ConoHa WING = 8022。それ以外のサーバー（ヘテムル等）は標準では 22 ですが、ホスト固有の設定になっている場合があるためサーバー会社のコントロールパネルのSSH設定画面で必ずご確認ください。chmod 600、Windows は icacls による「現在のユーザーのみフルコントロール（継承無効化）」を実行します。鍵ファイルの中身もサーバーも変更しません（このパソコンのファイル属性のみ）。openssl ec -in さくらの鍵.pem -out 変換後の鍵.pemchmod 600 変換後の鍵.pem も実行してください。あるいは v1.6.3 以降に更新する方が確実です）
.ppk ファイルをサイト設定の「秘密鍵パス」にそのまま指定できます。wpmm_backups/ フォルダ（サイト設定の「WordPressパス」に設定したフォルダ配下）に backup_YYYYMMDD_HHMMSS.sql という名前で保存されています。FTPソフトや、サーバーのコントロールパネルのファイルマネージャーから手動で取得できます。
.exe インストーラーをダウンロードして実行するだけです。.dmg を開き、.app を Applications フォルダにドラッグ＆ドロップ。「置き換えますか？」と表示されたら「置き換える」を選択してください。
v1.6.2 から追加されたバージョンバッジは、サイト一覧の各カードに Core 6.9 / PHP 8.3 のように表示されます。これらはメンテナンス実行のたびに自動取得・更新される情報です。
バッジが表示されない主な理由：
ツールバーの Core / PHP フィルタも、バージョン情報が取得済みのサイトに対してだけ機能します。「未取得（メンテ未実行）」フィルタ項目を使えば「まだメンテしてないサイトはどれか」も簡単に絞り込めます。
バッジには短縮版（メジャー・マイナーのみ）が表示されますが、マウスホバーで完全バージョン（例: 6.9.4）が tooltip で確認できます。