よくあるご質問

更新前に自動でDBバックアップを取得し、プラグインを1件ずつ更新するたびに HTTP ステータスをチェックします。次のいずれかを検知した場合、そのプラグインだけを即座に 旧バージョンに自動巻き戻し（ピンポイントロールバック） し、サイトの正常表示が戻ったかを再確認します:
・HTTP 500番台のサーバーエラー（PHP Fatal や DB エラー等）
・HTTP 4xx の退行（更新前 200 が更新後 404・403・401 等になった場合）
・サイト到達不能（接続失敗・タイムアウト・DNS 障害等）
さらに「積極的自動修正モード」をONにしているサイトは、メンテナンス完了後もサイトが壊れている場合に DB とファイルを更新前の状態にまとめて自動復元します。壊れたままになる可能性は低いですが完璧ではありません。万が一の場合、ご自分で復旧できる方がご利用ください。

プラグイン更新ごとの HTTP チェックで、HTTP 500番台のサーバーエラー・HTTP 4xx の退行（200→404 等）・サイト到達不能のいずれかを検知すると、原因プラグインを旧バージョンに自動巻き戻し（ピンポイントロールバック）し、復旧確認まで自動で行います。WordPress 本体（コア）の更新でも同じ仕組みが動きます。ロールバックを実行する WP-CLI コマンドには「壊れたプラグインだけをロード対象から除外する」指定スキップ（--skip-plugins=<対象名>）が動的に付与されるため、ロールバック対象のプラグインが Fatal Error を起こしている場合でもロールバック処理自体は確実に実行されます。さらに「積極的自動修正モード」をONにしているサイトは、上記でも復旧しなかった場合の最終手段として DB とファイルをまとめて更新前の状態に戻します。なお、テーマの更新は一括処理のため個別ロールバックの対象外、データベース破損など深刻な障害、SSH を使用しないブラウザのみ更新モードでは自動復旧の対象外となる場合があります。

コア更新後の HTTP チェックで異常を検知すると、まずコアを直前のバージョンに自動で巻き戻します。その後の挙動は巻き戻しの結果によって 2 パターンに分かれます:

• 巻き戻し成功 + サイト復旧確認OK（一番多いケース）→ 残りのプラグイン更新も通常通り個別の HTTP チェック付きで進みます。コアは旧版に戻り、後続プラグインも個別に守られた状態で更新が継続されます。
• 巻き戻しに失敗した場合、または巻き戻したのにサイトがまだ正常応答に戻らない場合 → 後続のプラグイン/テーマ/翻訳更新を中断し、メールで報告します。サイトが壊れた状態のまま更新を続けると、無関係なプラグインまで誤って巻き戻してしまうリスクがあるため、安全側に倒す設計です。

後者の場合は、コアの状態を確認・修復してから（必要に応じて WordPress 管理画面や手動 SSH で）メンテナンスを再実行してください。実行ログには「コアロールバック後の後続更新を中断」と明記され、レポート・メールにも反映されます。

通常運用では OFF（既定） のままで多くの障害に対応可能です。ON にすると、メンテナンス完了後にもサイトが壊れている場合の 最終手段としての包括的な自動復旧 が追加で動作します。

ON にすべきケース

• エージェンシーで多数のクライアントサイトを運用しており、深夜の無人実行で「とにかく自動で復旧させたい」
• HTTP 500 エラーが起きた際に、人間の判断を待たずに最大限の自動復旧を試みたい
• SSH 接続が設定されているサイト（SSH 未使用の場合はこのモードは効きません）

注意点

• テーマ自動切替で見た目が変わる可能性：原因と判定された場合 Twenty シリーズに一時切替されます。クライアントが気づく前に確認・復旧することを推奨します（報告メールに記載されます）。
• 「最終手段」の名のとおりアグレッシブな処理：すでにサイトが壊れている前提で動くため、誤動作で意図しない復元が走る可能性もゼロではありません。
• 完璧ではありません：自動修正で解決できない複雑なエラーもあります。常に報告メールを確認してください。
• SSH 必須：このモードは SSH を使用しない設定のサイトには適用されません。

おすすめの始め方: まず OFF で運用を始め、上の表の「📦 / 🔧 / 🔍」カテゴリだけで多くのケースに対応できます。それでも対応しきれない複雑な障害が起きたタイミングで ON への切替を検討してください。

有料版や、アクティベートが必要なタイプのプラグイン・テーマは、自動更新されない場合があります。更新できなかった場合は報告メールに記載されます。

テーマは個別ロールバックの対象外です。テーマ更新は WordPress 標準の一括更新（wp theme update --all）で実行されるため、更新後にサイトが壊れていても「どのテーマの更新が原因か」を特定できません。

プラグイン・WordPress 本体（コア）の更新は1件ずつ実行＆ HTTP チェックを挟むため、原因特定とピンポイントロールバックが可能ですが、テーマは構造上それができません。これは設計上の制約です。

テーマ起因で問題が起きた場合の動作:

• メンテナンス完了後のトップページ HTTP チェックで 500/4xx 等を検知 → 報告メールで通知（ただしテーマ起因とは特定できないため、「サイト要確認」として通知されます）
• 「積極的自動修正モード」ON のサイトでは、Fatal ログからテーマ起因と判定された場合に WordPress デフォルトテーマ（Twenty シリーズ）への自動切替を試みます
• テーマファイルの自動巻き戻しは行いません（手動対応が必要）

補足: 実運用ではテーマ起因の障害はプラグイン起因の 1/10 以下と統計的に少ないため、優先度を下げています。

はい、確実に実行できます。本アプリは、ロールバックを実行する WP-CLI コマンドに「壊れたプラグインだけをロード対象から除外する」指定スキップ（--skip-plugins=<対象プラグイン名>）を動的に付与しています。

これにより、たとえ更新したプラグインが Fatal Error を起こしていても、ロールバックを実行する WP-CLI 自身はそのプラグインを load せず、確実にファイル置き換え（旧バージョンへの巻き戻し）が完了します。他の正常なプラグインや有料プラグインは引き続きロードされるため、独自更新フィルター等は通常通り発火し続けます。

具体的な処理の流れ:

• 1. プラグイン X を更新（ファイル置き換え）
• 2. サイトに HTTP リクエスト → Fatal で HTTP 500
• 3. wp plugin install X --version=旧 --force --skip-plugins=X を実行
• 4. WP-CLI は壊れたプラグイン X だけを load せず、ファイル置き換えを実行 → 成功
• 5. サイトに再度 HTTP リクエスト → 旧版で動作 → 200（復旧確認）

補足: PHP-CLI（コマンドライン）と PHP-FPM（Web）は別プロセスのため、Web 経由でサイトが完全に動かない状態でも SSH 経由のロールバックは独立して実行できます。

スケジュール機能は付いていません。手動でメンテナンスを実行してください。

この機能をオンにしている場合、更新前後でトップページのスクリーンショットを自動撮影し、実際のビジュアルの差異を検知します。差異が8%を超えた場合、異常として検知・報告します。
※カルーセルや動きのあるサイトはスクショ比較がずれる可能性が高いため、この機能の利用はおすすめできません。

スクリーンショットはアプリを実行しているPCの 「screenshots」フォルダ に保存されます。サーバーには保存されません。メンテナンス実行後、ログ詳細画面（各サイトのログをクリック）の「📸 スクリーンショット」欄からファイルをダウンロードできます。
※メンテナンス実行後のスクリーンショットはすべてのサイトで自動保存されます。「スクリーンショット比較」をONにしているサイトは更新前後の2枚が保存され、差分が自動検出されます。画像はデフォルトで90日間保持されます。

バックアップはサーバー上（WordPressインストールディレクトリ内の wpmm_backups/ フォルダ）とアプリを動かしているPCのローカルの2か所に保存されます。メンテナンス実行時に backup_YYYYMMDD_HHMMSS.sql が自動生成され、SSH/SFTP経由でローカルにもダウンロードされます。サーバー上・ローカル共に最新3世代のみ自動保持され、古いファイルは順次削除されるためディスクが溜まり続ける心配はありません。

※ この保持世代数（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 を自動配置します。

両ファイルはアプリが自動生成・更新します。万が一どちらかが消えてしまっても次回メンテナンス実行時に再生成されるため、運用中に保護が外れたままになることはありません。

競合自体は発生しませんが、安全性の観点から WP 標準の自動更新は OFF にして、更新は本アプリに一本化することを推奨します。

■ 注意：真に対象外のプラグインは別の話です
WordPress の「自動更新を有効化」トグルは、WordPress 標準の更新機構を使うプラグインにのみ効力があります。テーマバンドル品の同梱プラグインや、独自 API で更新を管理する一部の有料プラグインは、WordPress 標準の更新機構をそもそも使っていません。これらは自動更新トグルの ON/OFF に関わらず WP-Cron では更新されず、本アプリの更新対象にもなりません。WordPress 管理画面の各プラグイン個別の更新画面から手動で更新する必要があります。ご利用中のプラグインがどちらに該当するかは、各プラグインのドキュメントまたは管理画面の挙動でご確認ください。

■ 競合は起きない理由
本アプリは「現時点で更新可能なプラグイン」のみを対象に処理するため、WP-Cron で先に自動更新されていれば自動的にスキップされます。エラーや二重処理は発生しません。

■ 一本化を推奨する理由
WP 標準の自動更新には、本アプリが備える以下の安全機構が一切ありません:
・更新前の DB バックアップ
・プラグイン 1 件ごとの更新後 HTTP チェック
・ピンポイントロールバック（旧バージョンへの自動巻き戻し）
・更新前後のスクリーンショット差分比較

深夜に WP-Cron で自動更新 → 翌朝サイトが落ちていた、というケースでも気づくのが遅れるうえ、本アプリは巻き戻し用の旧バージョンを記録していないため自動復旧もできない状態になります。

■「除外プラグイン」設定との重要な注意
本アプリの「除外プラグイン」リストは WP 標準の自動更新を制御しません。特定プラグインのバージョンを意図的に固定したい場合は、以下の両方を設定してください:
① 本アプリの「除外プラグイン」リストに追加
② WordPress 管理画面の「プラグイン」一覧で、該当プラグインの「自動更新を無効化」を個別にクリック

片方だけだと WP-Cron が固定を破ります。

■ 推奨運用
・基本（推奨）: WordPress 側で全プラグインの自動更新を OFF にし、更新は本アプリで一括管理
・緊急セキュリティだけ自動更新したい場合: 該当プラグインのみ ON にする（上記のリスクを理解した上で）

v1.6.1 以降では、SSH プロファイルの WP-CLI パスを「サーバー共通のデフォルト」として保持しつつ、特定のサイトだけ別の PHP バージョンをサイト個別に上書きできます。

■ 推奨手順
① SSH プロファイルの WP-CLI パスには、サーバー内で主に使われている PHP バージョン（例: /opt/php-8.2/bin/php /usr/bin/wp）を登録します。多くの場合、これで全サイト動作します。
② 例外的なサイト（このサイトだけ PHP 8.3 で動かしたい等）はサイト編集画面の SSH関連タブ 内「WP-CLIパス（任意・上書き）」欄で個別指定します（例: /opt/php-8.3/bin/php /usr/bin/wp）。空欄ならプロファイル値が使われます。

上書き設定中のサイトは、サイト一覧に「⚙ 上書き」バッジが表示されます。マウスオーバーで実際に使われている WP-CLI パスも確認できます。

■ プロファイル複製は不要です
v1.6.1 より前は「PHP バージョンが違うサイトごとに SSH プロファイルを複製する」回避策が必要でしたが、v1.6.1 以降はこのサイト単位上書き機能で 1 プロファイルに集約できます。SSH 鍵の更新時もプロファイルひとつを書き換えるだけで全サイトに反映されます。

エックスサーバーで発生する典型的なエラーで、原因は「サーバーパネルで指定する PHP バージョン（Web 側）と、SSH で wp コマンドを実行したときの PHP バージョン（CLI 側）が別管理」になっていることです。CLI 側はデフォルトで古い PHP（7.0 系）が使われるため、最新の WP-CLI 互換コードが Parse error を起こします。

■ 解決方法
SSH プロファイル編集画面の「WP-CLI パス」欄を、PHP の絶対パス指定形式に変更してください：
/opt/php-<バージョン>/bin/php /usr/bin/wp

バージョン部分はサイトの PHP バージョンに合わせます：
・PHP 7.4 → /opt/php-7.4/bin/php /usr/bin/wp
・PHP 8.1 → /opt/php-8.1/bin/php /usr/bin/wp
・PHP 8.3 → /opt/php-8.3/bin/php /usr/bin/wp

v1.6.0 以降では「🔍 詳細診断」ボタン（SSH プロファイル編集画面の「接続テスト」ボタン横）でサーバー環境を読み取り専用で観測し、推奨される WP-CLI パスを自動提案できます（参考目安として活用してください）。

また v1.6.1 以降では、サーバー内に異なる PHP バージョンのサイトが混在する場合、上記のサーバー共通設定に加えて、サイト編集画面の SSH関連タブ 内「WP-CLIパス（任意・上書き）」欄でサイト単位の個別指定も可能です。

v1.6.2 でさらに改善されました。

■ v1.6.1 での改善
① 更新通知キャッシュの強制リフレッシュ：WordPress 内部の更新通知キャッシュ（最大 12 時間有効）が古いまま処理されることで、wordpress.org でリリース済みの最新バージョンが一時的に検知されない問題を解消しました。メンテナンス開始時（DB バックアップ完了後）に 3 種類のキャッシュ（プラグイン・テーマ・コア）を強制リフレッシュします。
② ブラウザ補完更新：SSH（WP-CLI）で取得できないプラグインを管理画面経由で一括更新する補助機能。サイト編集画面の 登録情報タブ 内「🌐 ブラウザ補完更新」トグルで ON/OFF できます（デフォルト ON）。

■ v1.6.2 での追加改善
SSH（WP-CLI）でのプラグイン・テーマ検出/更新の際に、独自の更新フィルターを持つプラグイン・テーマがロードされた状態で実行されるよう調整しました。これにより WordPress 管理画面の更新一覧に表示されるプラグイン・テーマは、より確実に SSH（ピンポイントロールバック対応）の対象になります。

■ 注意：補完更新で処理された分はピンポイントロールバックの対象外
ブラウザ補完更新は一括更新になるため、個別の HTTP チェックや旧バージョンへの自動巻き戻しは発動しません。実行ログ・結果メールにも「ステップ RB 無効」と明示されます。万一、補完更新中にサイトが壊れた場合は、更新前に取得済みの DB バックアップを使った全体復元が必要になります。

■ それでも更新されないプラグイン
WordPress 管理画面の更新一覧に表示されないプラグイン（テーマにバンドルされた同梱プラグイン・完全に独自のリンクから更新するもの等）は、本アプリの対象外です。これらは WordPress 管理画面から手動で更新する必要があります。

「WordPress 管理画面の更新一覧に表示されるかどうか」で判断してください。

多くの有料プラグインは、ライセンスを有効化すると WordPress 標準の更新一覧（黄色い「新バージョンが利用できます」通知）に表示されるようになり、その場合は本アプリの自動更新対象に含まれます。一方、独自リンクから手動更新する形でしか案内が出ず、標準の更新一覧には表示されないプラグインは、本アプリでは検出できません。

■ 動作経路（標準の更新一覧に表示される場合）
・SSH（WP-CLI）で取得できる場合 → SSH 経由で 1 件ずつ更新（ピンポイントロールバック対応）
・SSH では取得できないが管理画面に「更新あり」と表示される場合 → ブラウザ補完更新で一括処理（ピンポイントロールバック対象外）

■ ライセンスが未有効・独自更新のみのプラグイン
WordPress 標準の更新一覧に表示されないプラグインは、本アプリでは検出できず、各プラグインの独自更新画面から手動更新が必要です。事前にライセンスを有効化することで対象になるかどうか変わるケースが多いので、まずはご自身のサイトの管理画面の更新一覧をご確認ください。

停止ボタンを押すと、プログラムに停止シグナルが送られます。現在処理中のサイトが完了してから停止するため、途中で更新が中断されることはありません。処理済みのサイトはそのまま更新完了状態が維持され、未処理のサイトはスキップされます。
※停止シグナルを送信後、実際に停止するまで数秒〜数十秒かかる場合があります。

v1.6.2 新機能です。ツールバーの「プラグイン更新」ボタンから開くダッシュボードで「サイト × プラグイン」のチェックボックスを選び、フッターの「選択プラグインを更新」ボタンを押すと、選んだプラグインだけを更新できます。

通常のメンテナンスとの違いは「対象範囲だけ」です：

• ✅ DB バックアップ・1 件ごとの HTTP チェック・問題発生時の自動ピンポイントロールバック・更新後のビジュアル確認・サマリーメールは通常と同じ動作です
• ❌ Core（WordPress 本体）・テーマ・翻訳の更新だけがスキップされます

他社ツールの「Update All」ボタンとは思想が違います。それらは安全網なしで一気に更新するため、問題が起きてもピンポイント復旧ができません。本アプリの選択プラグイン更新は安全運用ポリシーを保ったまま対象を絞れるのがポイントです。

ログ履歴の一覧では「選択更新」タグが付与され、対象プラグイン名も記録されます。レポートにも「今回は対象プラグインだけを更新しました」の旨が日英で明記されるので、クライアントへの説明資料としてそのまま使えます。

以下の環境で動作します。

項目	Windows	Mac
OS	Windows 10 / 11（64bit）	macOS 13.5 Ventura 以降
CPU	64bit プロセッサ	Intel / Apple Silicon 両対応
メモリ	4GB 以上推奨
必須環境	インターネット接続、WordPress 5.0 以上のサイト

SSH接続では、パスワードの代わりに「秘密鍵」と「公開鍵」のペアを使います。秘密鍵はあなたのパソコンに保存するファイル、公開鍵はサーバー側に登録するデータです。この2つが揃って初めて接続できます。

主要サーバーでの鍵の発行方法：

• Xserver：サーバーパネル → SSH設定 → ON → 「公開鍵認証用鍵ペアの生成」→ .key ファイルをダウンロード
• ConoHa WING：サーバー管理 → SSH → +SSH KEY → .pem ファイルをダウンロード
• さくらのレンタルサーバ：サーバー情報 → SSH公開鍵 → 鍵ペアを生成して登録 → 秘密鍵をダウンロード

詳しい手順はご利用ガイドの「SSH接続・WP-CLIとは？鍵の準備方法」セクションをご覧ください。

ダウンロードした秘密鍵ファイルをパソコン上のどこに保存したか、そのファイルパスを入力します。

• Mac：~/.ssh/ファイル名.key（例：~/.ssh/xserver_id_rsa）
• Windows：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 タブをご覧ください。

サーバー側でお使いのPC（接続元 IP アドレス）が一時的にブロックされている可能性が高いです。エックスサーバーを含む共有レンタルサーバーには、短時間に SSH の認証失敗が複数回続いた接続元 IP を、一定時間アクセス拒否する保護機構があります。エックスサーバー公式サポートからは「fail2ban による接続元 IP の一時ブロック」と回答をいただいています（試行回数や継続時間などの具体的な閾値はセキュリティ上非公開）。

この事象は、複数の SSH 鍵を ~/.ssh/ や SSH エージェントで管理されている環境で発生しやすいです。1 回の接続で意図せず複数の鍵が試行され、対象サーバーが受け入れない鍵を先に提示してしまうと、認証失敗が積み上がってブロック判定の閾値に達してしまうためです。

v1.6.5 以降では、本アプリが「サイト設定で指定した鍵 1 本のみを使う」ように調整されているため、この事象は構造的に発生しにくくなっています。v1.6.4 以前をお使いの場合は最新版へのアップデートをご検討ください。

今すでにブロックされている場合の対処：

• そのPCからの SSH 接続試行を 半日〜1 日程度 完全に止めてください（自動再試行も含めて停止）。ブロック中の再試行はブロック時間が延長される可能性がありますので、「あれ繋がるかな」と試すのも避けてください。弊社環境での実測では半日〜1 日程度で自然解除を確認しています
• 解除確認は、ターミナルから 1 回だけ 以下のコマンドで安全に試せます（指定した鍵 1 本のみを使う設定で、ブロック中でも追加カウントを最小化）：
  ssh -i ~/.ssh/秘密鍵 -o IdentitiesOnly=yes -o IdentityAgent=none -p 10022 ユーザー名@サーバーホスト名 'echo ok'
• 解除されない場合や、急ぎ復旧したい場合は、別のネットワーク（スマートフォンのテザリング等）からの接続をお試しください。同じ鍵・同じユーザー名で別 IP からは即座につながる場合、お使いの IP がブロックされていることが確定します
• 長時間解除されない場合は、エックスサーバーのサポート窓口にお問い合わせください。問い合わせ時は、契約サーバー ID・接続元 IP・発生時刻・接続先ホスト名を併記すると話が早いです

エラーメッセージの見え方には軽重 2 段階があります。軽め＝ Connection closed by [サーバーIP] port 10022（TCP は通るがサーバー側で即切断）、重め＝ Connection refused（TCP 接続段階から拒否）。いずれも同じ fail2ban の発動症状で、ブロック中の追加試行を続けると重い側に進む傾向があります。

なお、この保護機構は本アプリだけでなく、Tera Term や macOS の Terminal 等の他の SSH クライアントを使用しても同じ条件で発動します。同じ環境から複数のサイトをお持ちの場合、SSH 鍵をサーバーごとに分けて管理し、接続コマンドや本アプリの設定で「使う鍵」を明示することをお勧めします。

問題ありません。v1.6.5 以降で意図的に撤去された警告です。

本アプリは内部で paramiko という Python の SSH ライブラリを使って接続しています。paramiko は OpenSSH コマンド（ssh や scp）と異なり、秘密鍵ファイルのパーミッション（ファイル権限）を厳密にチェックする仕組み（StrictModes）を持っていないため、ファイル権限が 644 のままでも接続自体は通常成功します。

v1.6.3〜v1.6.4 では予防として警告を出していましたが、その警告から発火する「修正してから接続」自動リトライが、一部のお客様環境で接続の繰り返しを引き起こし、サーバー側の保護機構による接続元 IP の一時ブロックを誘発するケースがあったため、v1.6.5 で撤去しました。

秘密鍵のパーミッションについての推奨は変わりません。Mac / Linux であれば chmod 600 ~/.ssh/秘密鍵、Windows であれば「現在のユーザーのみフルコントロール（継承を無効化）」に設定するのが OpenSSH 公式の推奨です。本アプリの動作には必須ではありませんが、コマンドライン版 OpenSSH も併用される場合や、ファイル共有環境にお使いの PC がある場合は、引き続き手動でパーミッションを整えておくことを推奨します。

ヘテムルや一部の共有サーバーでは、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 段階方式になっています：

1. 「🧪 まず隔離パスで試す」：~/wpmm_install_test_<時刻>/wp に設置して動作確認します。既存の ~/bin/wp には一切触らないため、安全に試せます
2. 隔離パスでの動作確認が成功したら、「📦 ~/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 越しにサーバーへ接続し、読み取り専用のコマンドだけを実行して以下を観測します。

• OS 種別とシェル種別
• HOME ディレクトリの位置と書き込み可否
• PHP コマンドの所在（PATH 内 / 絶対パス候補）
• 既存の WP-CLI（システム全体 / ホームディレクトリ）の有無と動作可否
• GitHub への到達性（自動インストールが可能かの判定）

これらの観測値から「最も確からしい WP-CLI Path」を 「参考目安」として提案します。サーバーには一切書き込みを行いません（一時的な書き込み権限テスト用に ~/.wpmm_diag_test_$$ という名前のファイルを一瞬作って即削除する処理のみ）。

⚠️ 提案値は確証ではありません。サーバー固有の事情（カスタム PHP セレクタ・chroot 環境・proxy 制約等）を完全にはカバーできないため、不正確な場合があります。提案値を入力した後は必ず「接続テスト」で動作確認してください。

エックスサーバー・さくらインターネット・ConoHa WING・ヘテムルの 4 ホストで実機検証済みです。それ以外のサーバーでも動く可能性は高いですが、保証はできません。

はい。カテゴリーとタグの2系統で柔軟に整理できます。

• カテゴリー：1サイトに1つだけつけられる排他的な分類。クライアント別やプロジェクト別の整理に向いています。お好きな色を割り当てると一覧で一目で識別できます。
• タグ：1サイトに複数つけられる横断的な属性ラベル。「EC」「要報告」「契約年内」など、カテゴリーをまたぐ属性付けに便利です。

アプリ右上の ⚙設定 → 「カテゴリー・タグ管理」 から登録・編集・削除できます。サイト追加・編集画面の 登録情報タブ でサイトに割り当て、登録サイト一覧の上部ドロップダウンから絞り込み検索ができます。

タグフィルタは「いずれかを含む」（OR）と「すべて含む」（AND）を切り替えられます。検索ボックスとの併用も可能です。

はい。登録サイト一覧の「最終メンテ」欄にある 「🕒 履歴 ›」 リンクをクリックすると、そのサイトのログ履歴だけに絞り込んだ状態でログ画面が開きます。

サイト名を後から変更しても履歴は引き継がれます。内部的な安定識別子でログを追跡しているため、リネーム前後のログを同じスコープで確認できます。

画面上部の「すべてのログを表示」リンクで全件表示に戻せます。本機能の導入（v1.5.8）以前に記録された古いログは内部識別子を持たないため、サイト名でのマッチングで表示されます。

はい、3つの方法で柔軟に削除できます。

• サイトごとに削除：サイト一覧の「履歴 ›」リンクから個別ログ画面を開き、「このサイトのログを削除」ボタン。他サイトのログは残ります。
• 絞り込み結果を削除：ステータス（Success / Error 等）や期間（直近7日 / 30日 / 90日）で絞り込んだ状態で「絞り込み結果を削除」ボタン。条件に合致するログだけが対象になります。
• 選択して削除：チェックボックスで個別に選んで「🗑️ 選択を削除」ボタン。1件単位の整理に便利です。

いずれの場合も削除前に**削除対象件数を表示する確認ダイアログ**が出ます。「全件削除」は何も絞り込みがない状態でのみ表示され、本当に全部消したい時の最終手段として残しています。

削除前に確認ダイアログで挙動を選べるため、サイト本体のデータは安全に保たれます。

• カテゴリー削除時：そのカテゴリーが付いているサイトを「未分類」に戻すか、別のカテゴリーに一括移動するか選べます（影響件数を表示）。
• タグ削除時：そのタグが付いている全サイトから自動的に取り除かれます。他のタグやサイト設定は影響を受けません。

サイト本体の設定（SSH情報・WordPressパス・実行履歴等）は一切影響を受けません。

基本操作は画面の指示に従うだけで完了します。ただしSSH接続の設定が必要なため、レンタルサーバーのコントロールパネルでSSHを有効にする作業やWP-CLIを利用可能にする作業などが必要です。エックスサーバー・さくらインターネットなど主要サーバーの設定手順はサーバー側がマニュアルで解説しています。

SSHプロファイルの登録から最初のメンテナンス実行まで、ご利用ガイドに画像つきで手順をまとめています。

可能です。SSH接続ができない場合は、ブラウザ自動操作（Playwright）モードで管理画面から更新を行う方法でメンテナンスを行います。ただし、DBバックアップなどの機能は利用できません。

不要です。プラグインのインストールは一切必要ありません。お使いのWordPressに変更を加えることなく、外部から安全に操作します。

はい。Mac・Windowsどちらにも対応したインストーラーをご用意しています。

SSH接続が有効であればサーバー会社を問わず使用できます。エックスサーバー・さくらインターネット・ConoHa WING・Heteml・AWS・Vultrなどで動作確認済みです。SSH接続が使えないサーバーでも、ブラウザ自動操作（Playwright）モードで対応しています。（DBバックアップなどは機能しません）

OSでデフォルトに設定されているブラウザが自動的に開きます。アプリ側にブラウザを選択する機能はありません。

• 🍎 Mac：「システム設定 → デスクトップとDock → デフォルトのWebブラウザ」でお好みのブラウザに変更できます。
• 🪟 Windows：「設定 → アプリ → 既定のアプリ → Webブラウザー」でお好みのブラウザに変更できます。

なお、自動で開いたブラウザのアドレスバーに表示されているURLをコピーして別のブラウザに貼り付ければ、同じ画面にアクセスできます。

v1.6.2 から正式対応しました。サイト編集画面の WordPress情報タブ 内に折りたたみの「🔐 Basic 認証（任意・ベーシック認証で保護されている場合のみ）」セクションがあり、ID とパスワードを入力できます。パスワードは暗号化して保存されます。

Basic 認証情報は次の処理で使われます：

• 更新前後のビジュアルチェック（Playwright によるトップページ HTTP チェック）
• サイト一覧用のサムネイル取得
• ブラウザ補完更新（v1.6.1 で追加された、ACF Pro 等の独自更新サーバーを持つ有料プラグインを管理画面経由で更新する機能）

SSH / WP-CLI 経由の更新自体は Basic 認証の影響を受けないため、上記 3 機能を使わないなら認証情報の登録は不要です。同じ Basic 認証セクション内の「🔗 接続テスト + サムネイル取得」ボタンを押すと、入力した認証情報で疎通確認＆サイト一覧用サムネイルの撮影が一度に完了します。

推奨用途: ステージング・開発環境・社内専用サイト・限定公開のキャンペーンサイトなど、HTTP Basic 認証で保護されている WordPress サイト全般。

「PHP Deprecated:（中略）is deprecated」という警告メッセージが大量に表示されて、プラグイン一覧の取得やメンテナンスの更新検出が失敗することがあります。これは、サーバーにインストールされている WP-CLI のバージョンが古いのに対して PHP が新しい（8.2 以降）組み合わせのときに、サーバー側から出る警告です。アプリやサイトが壊れているわけではありません。

v1.6.8 で対策済みです。この警告が出てもプラグイン一覧・更新検出が成立するように、アプリ側で警告を抑制し、警告に埋もれた結果を確実に取り出すよう改善しました。まずは v1.6.8 以降に更新してお試しください。

サーバー側の WP-CLI を新しいバージョン（2.8 以降）に更新できる場合は、警告自体が出なくなります。更新方法が分からない場合はご契約のレンタルサーバーのサポートにご確認ください。

はい。フリープランは登録不要で、1サイト・月3回まで無料でお使いいただけます。まず試してから有料プランをご検討ください。

月払い・年払いの両方をご用意しています。年払いは月払いと比べて約20%お得です。いつでも切り替えが可能です。

アプリ内でライセンスキーを登録した時点からスタートします。有効期限の単位は「月末まで」です。
例：月払いで購入したライセンスキーを3月15日に登録 → 4月30日まで有効
※購入後すぐに登録しなくても、キーを入力した日から期限がスタートします。

いつでも即時解約できます。解約はカスタマーポータルからご自身で手続き（契約時のメールアドレスが必要）が完結します。こちらに解約手続きをご依頼いただいても構いませんが、1〜2日のタイムラグが発生する可能性があります。解約後は次の請求日まで引き続きご利用いただけます。

決済はStripeを利用しています。クレジットカード（Visa・Mastercard・JCB・Amexなど）、Apple Pay / Google Pay、コンビニ決済、銀行振込、PayPayなど、100種類以上の決済手段に対応したグローバルな決済インフラです。

プランによって異なります。フリープラン1サイト、MINIプラン3サイト、LITEプラン15サイト、STANDARDプラン100サイト、BUSINESSプラン200サイトまで対応しています。200サイト以上はご相談ください。

アプリを起動しているローカルPCに保存されます。任意のフォルダに保存でき、ワンクリックでダウンロード可能です。

サーバー上のバックアップファイルはWordPressのインストールディレクトリ内の wpmm_backups/ フォルダ（サイト設定の「WordPressパス」に設定したフォルダ配下）に backup_YYYYMMDD_HHMMSS.sql という名前で保存されており、FTPソフトや、サーバーのコントロールパネルのファイルマネージャーから手動で取得できます。

サーバー上・ローカル共に最新3世代のみ自動で保持され、古いファイルは自動削除されるため、長期運用でもディスクを圧迫しません。なお、この保持世代数（3世代）は仕様として固定されており、設定画面からの変更には対応していません。wpmm_backups/ フォルダには .htaccess と index.php が自動配置され、外部からの直接アクセスはブロックされます。

はい。ログ一覧画面でサイトを選択してレポートをプレビューし、PDFまたはHTMLファイルとしてダウンロードできます（スタンダードプラン以上）。メールに添付してクライアントへお送りください。URL共有機能は現在未対応です。

ステータスは4種類あります。

• Success すべての更新・チェックが正常に完了しました。
• Warning 作業は完了しましたが確認が推奨される事象がありました。更新が保留されたプラグインがある・管理画面でDB更新などの操作が必要・HTTPチェックがタイムアウトした、などが該当します。
• Attention エラーではありませんが念のための記録です。HTTPステータスが4xx（404など）を返した・更新前後のスクリーンショット比較でレイアウトに差分が検出された場合が該当します。サイトの表示を目視で確認することをおすすめします。
• Error SSH接続・更新処理のエラー、またはHTTPステータスが500以上を返した場合です。早めの確認と対応をおすすめします。

最終メンテナンスの実行から7日以内はステータスバッジが表示されます。7日を超えると実行日時のみが表示され、バッジは非表示になります。次回メンテナンスを実行するとバッジが再び表示されます。

なお、メンテナンスログタブの実行履歴は365日間保持され、それを超えた古い記録は自動的に削除されます。

ステータスバッジにカーソルを合わせると実行内容の簡易詳細がポップアップ表示されますが、更新内容がなかった場合など詳細情報が記録されていないときは何も表示されません。詳しい実行内容は画面上部の「メンテナンスログ」タブからご確認ください。

設定バックアップにはSSH秘密鍵ファイルのパス情報のみが含まれており、秘密鍵ファイル自体はバックアップに含まれません。そのため、別のPCに復元した場合は以下の手順が必要です。

① 元のPCからSSH秘密鍵ファイル（例: ~/.ssh/id_rsa）を新しいPCにコピーする
② アプリのSSHプロファイル設定を開き、「秘密鍵のパス」を新しいPCでのファイルパスに更新する（サイトはプロファイルを参照しているため、プロファイルを修正すれば全サイトに反映されます）

PCを移行する際はアプリの設定バックアップと合わせて、SSH秘密鍵ファイルも必ず手動でコピーしてください。なお、パスワード認証のみを使用しているサイトはこの手順は不要です。

v1.6.2 新機能です。ツールバーの「プラグイン更新」ボタンから開きます。全サイトの「要更新プラグイン」を一画面で横断的に確認できる、いわゆる管理者用ダッシュボードです。

表示形式はプラグイン名でグループ化されます。たとえば「Elementor: 3 サイトで要更新（4.0.0 → 4.0.8）」のように一覧されるので、「このプラグインが古いサイトはどこか」が即座に分かります。展開すると影響サイトの一覧と各サイトの旧→新バージョンが見えます。

通常メンテとの使い分け：

• 通常のメンテナンス実行（ツールバーの「メンテナンス実行」）: Core / プラグイン / テーマ / 翻訳のすべてを更新。月次の定期メンテに最適
• プラグイン更新ダッシュボード: 特定のプラグインだけ急いで更新したい場合に。たとえば「セキュリティ系プラグインに緊急パッチが出たので 30 サイトに今すぐ適用したい」ようなケース

ダッシュボードでチェックを入れて「選択プラグインを更新」ボタンを押すと、選んだ「サイト × プラグイン」のペアだけが更新されます。DB バックアップ・HTTP チェック・ピンポイントロールバック・ビジュアル確認・サマリーメールなど、安全網は通常メンテとまったく同じです。

大量サイトを管理している場合、初回の取得は SSH 並列処理で 30〜60 秒かかることがあります。取得結果はブラウザに 24 時間キャッシュされ、再起動後でも即時表示されます（メンテナンス実行後は自動でキャッシュが無効化されて常に最新の状態が出ます）。

プレビュー（画面表示）とサンプル確認は全プラン無料でお試しいただけます。PDF・HTML形式でのダウンロードはスタンダードプラン以上でご利用いただけます。まずはレポート設定の「サンプルレポートを見る」からお確かめください。

はい。「レポート設定」からエージェンシー名・住所・メールアドレス・Webサイト・ロゴ画像・アクセントカラーを設定できます。WP Maintenance Managerの名称はレポートには一切表示されません。御社ブランドの保守報告書としてクライアントに届けられます。

実行日時・サイト名・更新内容（WordPress本体/プラグイン/テーマのバージョン変化）・ステータス（成功/要確認/エラー）・HTTP死活監視結果・スクリーンショット（オプション）が含まれます。挨拶文やサイトごとのメモもプレビュー画面から追記できます。

はい。ログ一覧画面でサイトを複数選択してまとめてレポートを生成できます。1サイトだけの単体レポートも作成可能です。クライアントごとに分けて作成することをおすすめします。

はい。プレビュー画面上部のセレクターで「今月」「先月」「全期間」を切り替えられます。ログ一覧で対象サイト・ログを手動選択してレポートに含める方法も選べます。

はい。プレビュー画面の「テキスト編集」ボタンから、挨拶文とサイトごとのメモをインラインで編集できます。編集内容を保存するとレポートに反映されます。

クライアントへの正式な報告書として渡すにはPDFが適しています。社内で加工・編集する場合はHTMLが便利です。どちらも同じデザインで出力されます。

はい。アプリを英語モードに切り替えると、ステータスラベル・更新内容・テンプレートテキストがすべて英語で出力されます。海外クライアントへの報告にもそのままお使いいただけます。

原因プラグインが自動で停止されています。「積極的自動修正モード」をONにしているサイトはDBとファイルも更新前の状態に復元されているため、サイトは通常通り表示されているはずです。OFFの場合はプラグイン停止のみ行われているため、サイトの表示を確認してください。問題の原因となったプラグインは報告メールに記載されます。提供元のリリースノートを確認するか、次回バージョンアップを待ってから改めて実行してください。

必ずしも問題があるわけではありません。Warningが出る主なケースは「更新できなかったプラグインが残っている」「管理画面に確認ダイアログが表示された」「スクリーンショット比較で差異を検知した」などです。報告メールの詳細欄を確認し、該当項目を手動でチェックしてください。

ブラウザ自動操作（Playwrightモード）使用時に起きます。主な原因は「管理画面URLの変更（セキュリティプラグインによるURL変更など）」「二段階認証の有効化」「ログインURLが /wp-login.php 以外に変わっている」です。サイト設定の「WordPress管理画面URL」が現在のログインURLと一致しているか確認してください。

ご利用いただけますが、プラグイン側の設定によって動作に影響する項目があります。

更新処理そのもの（SSH経由のWP-CLI実行）は影響を受けませんので、Core・プラグイン・テーマの更新は通常どおり行われます。一方で、更新後に行う「管理画面へのログイン確認」および「ブラウザ確認モードでの更新」は、以下の設定が有効だと失敗します（ログ上は「管理画面ログイン不可」として警告表示されますが、SSH更新の結果には影響しません）。

① 画像認証（ひらがな認証）／フェールワンス … ブラウザからの自動ログインが通りません。管理画面側の検証まで行いたい場合は、これらの機能を無効化してご利用ください。
② ログインページ変更 … サイト登録時の「WordPress管理画面URL」には変更後のURLをご入力ください。正しく入力されていれば更新・確認とも問題なく動作します。
③ ログインロック … 実行元のIPがロックされる場合は、サーバー側でIP許可リストへの登録をご検討ください。

※ SSH更新のみで運用される場合は、①〜③いずれもご利用中の設定のままで問題ありません。

以下の順に確認してください。
① レンタルサーバーのコントロールパネルでSSHが有効になっているか
② サイト設定のホスト名・ポート番号・ユーザー名に誤字・スペースが入っていないか
③ SSH鍵認証を使用している場合、鍵ファイルのパスが正しく入力されているか

主要レンタルサーバーのSSHポート番号：エックスサーバー / Xserver for WORDPRESS = 10022（標準の22ではないので注意）、さくらインターネット（スタンダード以上のレンタルサーバ）= 22、ConoHa WING = 8022。それ以外のサーバー（ヘテムル等）は標準では 22 ですが、ホスト固有の設定になっている場合があるためサーバー会社のコントロールパネルのSSH設定画面で必ずご確認ください。

v1.6.3 以降の自動対処：「UNPROTECTED PRIVATE KEY」「Permissions are too open」「too open」「bad permissions」などのエラーが出る場合は秘密鍵のパーミッションが緩すぎることが原因です。これはあなたのパソコン側 OS（Mac/Windows）の OpenSSH がチェックしているもので、サーバー会社は関係ありません。接続テスト画面で警告が出たら「🔧 修正してから接続」または失敗時の「🔧 秘密鍵のパーミッションを修正して再試行」ボタンを 1 クリックするだけで Mac は chmod 600、Windows は icacls による「現在のユーザーのみフルコントロール（継承無効化）」を実行します。鍵ファイルの中身もサーバーも変更しません（このパソコンのファイル属性のみ）。

SSH設定の各項目についてはご利用ガイド STEP 1もあわせてご確認ください。

v1.6.3 以降では発生しなくなります。さくらインターネットのコントロールパネル「鍵ペアを生成して登録」で現在発行される鍵は PKCS#8 という新しい形式（ECDSA-521）になっており、これまでのバージョンではアプリ側で読み込めずに接続テストが失敗していました。

v1.6.3 で PKCS#8 形式（暗号化版・非暗号化版いずれも）と PuTTY 形式（.ppk v2 / v3）を含む主要な鍵形式に自動で対応しました。さくらで発行した鍵ファイルをそのままサイト設定の「秘密鍵パス」に指定すれば接続できます（openssl コマンド等での事前変換は不要）。

v1.6.2 以前をお使いの場合は、当面の回避策として以下のコマンドで OpenSSH 互換の形式に変換できます：
openssl ec -in さくらの鍵.pem -out 変換後の鍵.pem
（変換後の鍵はパーミッションが緩い場合があるので chmod 600 変換後の鍵.pem も実行してください。あるいは v1.6.3 以降に更新する方が確実です）

v1.6.3 以降は使えます。PuTTY 形式（v2 / v3 両対応・パスフレーズあり/なし両対応・RSA / ECDSA / Ed25519 鍵タイプ対応）の .ppk ファイルをサイト設定の「秘密鍵パス」にそのまま指定できます。

v1.6.2 以前をお使いの場合は、PuTTY 付属の PuTTYgen で OpenSSH 形式に変換してください：
① PuTTYgen を起動して「Load」から .ppk を読み込み
② パスフレーズがあれば入力
③ メニューバーの「Conversions」→「Export OpenSSH key (force new file format)」を選択
④ 拡張子なし or .pem で保存して、その変換後ファイルをアプリで指定

v1.6.3 以降への更新でこの手順は不要になります。

各サイトはSSHプロファイルを参照しており、プロファイルを更新すると紐づいたすべてのサイトに自動で反映されます。それでもエラーが出る場合は以下を確認してください。

① サイト一覧から該当サイトの編集を開き、正しいSSHプロファイルが選択されているか確認する
② WordPressのインストールパスが正しいか確認する
③ SSHプロファイル管理画面で「接続テスト」を再実行する

別のパソコンにバックアップを復元した場合は、SSHプロファイルの秘密鍵パスを新しいPCのパスに更新してください。プロファイルを修正すれば全サイトに反映されます。

DBのバックアップ自体はサーバー上で成功しています。ローカルへの転送に失敗した状態です。主な原因はPCのディスク容量不足、またはSSH接続の途中切断です。

サーバー上のバックアップファイルはWordPressのインストールディレクトリ内の wpmm_backups/ フォルダ（サイト設定の「WordPressパス」に設定したフォルダ配下）に backup_YYYYMMDD_HHMMSS.sql という名前で保存されています。FTPソフトや、サーバーのコントロールパネルのファイルマネージャーから手動で取得できます。

判断のポイントは「WordPress 管理画面の更新一覧（「ダッシュボード → 更新」または「プラグイン」ページ）に新バージョン通知が表示されるかどうか」です。

・表示される場合 → 本アプリは v1.6.2 以降、SSH 経由でこれらのプラグインも検出・更新の対象にできます。SSH で更新できないケースでは、サイト編集画面の 登録情報タブ 内「🌐 ブラウザ補完更新」トグルを ON にすることで管理画面経由の補完更新が動作します。
・表示されない場合（独自の管理画面リンクからしか更新できないもの・テーマ同梱の付属プラグイン等） → 本アプリでは検出できず、各プラグインの専用画面から手動で更新する必要があります。

多くの有料プラグインはライセンスを有効化すると標準の更新一覧に表示されるようになります。「更新されない」場合は、まずライセンスの有効化状況と管理画面の更新一覧での表示有無をご確認ください。

まず迷惑メールフォルダをご確認ください。それでも届かない場合は、アプリの設定画面でSMTPホスト・ポート番号・メールアドレスに誤りがないか確認してください。

Gmailをご利用の場合は「アプリパスワード」の設定が必要です。Gmailの通常パスワードでは認証に失敗します。Googleアカウントのセキュリティ設定でアプリパスワードを発行し、パスワード欄に入力してください。

通知設定の各項目についてはご利用ガイド STEP 2もあわせてご確認ください。

誤検知です。ウイルス対策ソフトに未知のプログラムとして検知される場合があります。インストールマニュアルページをご参照ください。

初回起動時は、Playwright（ブラウザ自動操作エンジン）のダウンロードが行われます。インターネット接続のある状態で数分お待ちください。それでも起動しない場合は一度アプリを終了して再起動してください。

正常な動作です。特にMacでは、初回起動時にアプリの準備処理が行われるため、ブラウザが開くまで15秒前後かかる場合があります。そのままお待ちください。2回目以降の起動は短縮されます。

ブラウザのタブを閉じるだけでは、アプリ内部のサーバープロセスは稼働し続けています。macOSの仕様上、サーバーが動いている間はアプリアイコンをクリックしても新規起動されず、何も起きないように見えることがあります。

アプリを終了する際は、必ず画面右上の「アプリを終了」ボタンを使用してください。これにより安全にサーバーが停止され、次回の起動がスムーズに行えます。

タブを閉じたままにしてしまった場合は、約90秒待つとサーバーが自動的に終了します。その後にアプリアイコンをクリックすると正常に起動します。

アンインストールは不要です。新しいインストーラーをそのまま上書きインストールするだけでアップデートできます。サイト設定・ログ・バックアップなどのデータはすべて保持されます。

アップデート前に実行中のアプリを終了しておくことをおすすめします。

Windows：新しい .exe インストーラーをダウンロードして実行するだけです。
Mac：新しい .dmg を開き、.app を Applications フォルダにドラッグ＆ドロップ。「置き換えますか？」と表示されたら「置き換える」を選択してください。

v1.6.2 から追加されたバージョンバッジは、サイト一覧の各カードに Core 6.9 / PHP 8.3 のように表示されます。これらはメンテナンス実行のたびに自動取得・更新される情報です。

バッジが表示されない主な理由：

• そのサイトでまだ一度もメンテナンスを実行していない → 一度実行すると自動で取得されてバッジが出ます
• SSH 接続情報が登録されていない（ブラウザ更新モードのサイト） → SSH 経由でしかバージョン取得できないため、ブラウザ更新オンリーのサイトでは取得不可
• SSH 接続に失敗した → 一覧で SSH ステータス（緑バッジ）が出ているか確認、出ていなければ SSH プロファイル設定を見直してください
• WP-CLI が動作していない → SSH プロファイル編集の「② WP-CLI 動作テスト」ボタンで確認してください

ツールバーの Core / PHP フィルタも、バージョン情報が取得済みのサイトに対してだけ機能します。「未取得（メンテ未実行）」フィルタ項目を使えば「まだメンテしてないサイトはどれか」も簡単に絞り込めます。

バッジには短縮版（メジャー・マイナーのみ）が表示されますが、マウスホバーで完全バージョン（例: 6.9.4）が tooltip で確認できます。

これは、サーバーの PHP が PHP 8.2 以降で、サーバー側に標準でインストールされている WP-CLI のバージョンが少し古いケースで発生する事象です（エックスサーバー等の共有ホスティングで時々見られます）。

PHP 8.2 から「動的プロパティの作成」が Deprecated（非推奨）扱いになり、古い WP-CLI が内部で出す警告が大量に表示されるようになりました。本アプリの SSH テスト・WP-CLI パステストはシンプルなコマンド実行で判定しているため警告ノイズが混ざっても通過しますが、wp plugin list --format=json のように構造化されたデータを取得する場面ではこの警告が混入して読み取りに失敗します。

v1.6.6 以降では本アプリ側でこの警告ノイズを吸収する仕組みを実装したため、自動的に解消されます。v1.6.5 以前をお使いの場合は最新版へのアップデートをご検討ください。

なお、SSH 経由のメンテナンス実行自体には影響しません（プラグイン情報の一覧取得・ダッシュボード表示のみが影響を受けます）。

これは、SSH ログイン時に呼ばれる PHP のバージョンが古い（PHP 7.0 以下）ことが原因です。WordPress 本体の最新コードには ?string のような「nullable 型ヒント」（PHP 7.1+ で導入）が含まれているため、古い PHP では構文エラーになります。

Web 表示用の PHP は別バージョンで動いていることが多く、サイト自体は普通に表示されますが、SSH 経由でコマンドを実行すると古い方の PHP が呼ばれてエラーになる、というギャップが起きます。エックスサーバーで時々発生する典型的なケースです。

サイト編集画面の「🖥 SSH 関連」タブで「WP-CLI パス（任意・上書き）」欄に、新しい PHP を経由する WP-CLI コマンドを指定することで解決します。エックスサーバーの場合の例：

/opt/php-8.0/bin/php /usr/bin/wp

PHP 7.4 / 8.0 / 8.1 / 8.2 など、エックスサーバーのサーバーパネル「PHP Ver. 切替」で確認できる動作可能なバージョンであれば指定可能です（PHP 8.0 以上を推奨）。

保存後にプラグイン取得を再試行してください。サイトごとに個別の WP-CLI パスを指定できるため、他のサイトの設定には影響しません。

v1.6.6 から、メンテナンスの進行状況をサイト一覧の枠色でひと目で分かるようにしました。それぞれ次の意味があります。

• 青の脈動（実線）+ 青い背景: 現在メンテナンス処理中のサイト。同時に 1 サイトだけ点灯します
• 薄い青の点線: メンテナンス実行中の、まだ処理されていない実行待ちサイト
• 緑の実線 + 緑の背景: 直近のメンテナンスが正常に完了したサイト。24 時間後に自動で消えます
• 赤の実線 + 薄い赤の背景: 直近のメンテナンスでエラーになったサイト（v1.6.8 以降）。完了（緑）より目立つ表示で、エラーの見逃しを防ぎます。緑と同じく 24 時間後に自動で消え、そのサイトを正常にメンテし直すと緑に戻ります

緑・赤の表示は 24 時間維持されるので、後から「今日はどのサイトをメンテしたか・どれがエラーだったか」を一覧で振り返ることができます。新しいメンテナンス実行を始めても、今回のメンテ対象に含まれていないサイトの緑枠・赤枠は維持されます。

なお v1.6.8 から、メンテナンスが終わると今回実行したサイトの選択チェックは自動的に外れます。どのサイトをメンテしたかは上記の緑・赤の枠（24 時間表示）で確認できます。

OS のアニメーション抑制設定（macOS / Windows / Linux いずれも対応）が ON の場合、青の脈動は静的な枠線で表示されます。

v1.6.6 から、サイト一覧の 🔌 プラグインボタンの右上に「未更新プラグイン数バッジ」を表示しています。赤い数字は「このサイトで更新待ちのプラグインの件数」を示しています。

バッジが表示される条件:

• ツールバーの「プラグイン更新」横断ダッシュボードを実行し、結果がキャッシュされていること
• または、対象サイトの 🔌 プラグイン一覧モーダルを個別に開いたこと

バッジは 30 日間保持され、ホバー（マウスを乗せる）すると「最終取得: N 日前」のツールチップで情報の鮮度が分かります。メンテナンス実行で対象サイトのプラグインが更新されると、そのサイトのバッジは自動的に消えます（他サイトのバッジには影響しません）。

100 件以上のときは「99+」表記でコンパクトに表示されます。0 件のサイトはバッジを表示しません。

v1.6.6 から、最後のメンテナンス日の隣に「N 日前」の経過日数バッジを表示しています。経過日数によって色分けされており、「最近メンテしていないサイト」を一目で見つけられます。

経過日数	バッジ色	意図
0〜14 日	緑	最近メンテ済み・安心
15〜29 日	グレー	標準・許容範囲
30〜59 日	黄色	要注意
60 日以上	赤	要対応

経過日数は当日の時刻で再計算されるので、日付が変わると自動的に「16 日前」「31 日前」のように更新されます。

はい、v1.6.6 から仕様変更です。サイト選択（メンテナンス予約のチェックボックス）が、以下の操作でも消えないようになりました:

• リスト表示 ⇄ グリッド表示の切替
• ページ切替（次のページ・前のページ）
• フィルタ変更（カテゴリー・タグ・Core / PHP バージョン等）
• ブラウザのリフレッシュ（同じセッション内）

複数ページにまたがって選択した場合は、ツールバーの「N 件選択中 ・ 全解除」チップに件数が表示され、「全解除」リンクで一括クリアできます。

なお、アプリを再起動すると選択は自動でクリアされます。「前回の選択が残ったまま意図しないサイトをメンテしてしまう」事故を防ぐためです。

選択はサイトの内部 ID で管理しているため、サイトの並び替え・追加・削除で選択がズレることはありません。

以下をご確認ください。
① キーのコピーペースト時に余分なスペースが入っていないか
② インターネット接続が有効か
③ すでに別のPCで使用中の場合は1台のみ有効（プラン別の台数制限があります）

それでも解決しない場合はお問い合わせフォームからご連絡ください。

アプリの設定画面内「ライセンス」タブから「このPCの登録を解除」ボタンで解除できます。旧PCが使えない状態でも、お問い合わせフォームからご連絡いただければ管理側で解除します。

ビジネスプランは最大2台のPCに同時登録できます。例えばメインのMacと外出用のノートPCで同時に利用するといった使い方が可能です。

なお、2台のPC間で登録サイトの重複チェックは行っていません。チームでの利用や複数拠点での運用など、業務スタイルに合わせてご活用ください。

3台目以降のPCで使用したい場合は、いずれかのPCの登録を解除してから再登録してください。

登録済みのサイト情報・設定・バックアップファイルはすべてPC上に残ります。削除されることはありません。ただし、有効期限切れ後はメンテナンスの実行がフリープランの制限（1サイト・月3回）に戻ります。

はい、業界主要4ツール（ManageWP・MainWP・WP Umbrella・InfiniteWP）との詳細比較ページを公開しています。早見表で7項目を横並びで確認でき、各ツールの30秒サマリー、選びたい条件別の推奨ガイドも掲載しています。

👉 4ツールまとめ比較ページを見る

主な違いは3点です。
① クライアントサイトへのプラグインインストール不要（SSH + WP-CLI 接続）。ManageWP は ManageWP Worker プラグインが各サイトに必須。
② プラグイン1件単位のピンポイントロールバックが標準搭載。ManageWP の Safe Updates はサイト全体を巻き戻します。
③ 50サイトでフル機能の場合、ManageWP オールインワンバンドル $150/月に対して当アプリは ¥4,200/月（Standard・100サイトまで）。

一方で ManageWP は常時稼働監視・チーム機能・ブランド実績などの強みもあります。

👉 ManageWP との詳細比較を見る

いずれも当アプリと違って クライアントサイトへの専用プラグイン設置が必須、また プラグイン1件単位の自動ロールバック機能を持ちません。それぞれの主な特徴と詳細比較ページは以下の通りです：

・MainWP：オープンソース・自分でサーバーを用意するセルフホスト型。Pro $29/月 or $599 買切。MainWP との詳細比較 →

・WP Umbrella：EU 拠点 SaaS で €1.99/サイト/月。常時稼働監視・GDPR 対応が強み。WP Umbrella との詳細比較 →

・InfiniteWP：セルフホスト型・アドオン年間ライセンス（$147/年〜）。ホスト版 100サイト用 $597/年。InfiniteWP との詳細比較 →

既存ツールから当アプリへのサイト情報自動インポートには対応していません。ただし、1サイトの追加は SSH 認証情報＋WordPress インストールパスを入力するだけで 約30秒で完了します。

また、既存ツールと並行運用も可能です。当アプリは SSH 経由で動作するため、ManageWP・MainWP・WP Umbrella・InfiniteWP のいずれの管理対象サイトに対しても、それらのツール用プラグインと衝突しません。まず無料プラン（1サイト）で試してから、段階的に移行することをおすすめします。

詳しい併用フローは各 比較ページ の「並行して試す方法」セクションをご参照ください。