ConoHa VPS（KUSANAGI）でWordPressを運用していると、管理画面に「KUSANAGIプラグインの新しいバージョンがリリースされました」という通知が出ることがあります。今回は、この通知への対応手順と、更新したのに通知が消えなかったときに、何を確認してどう判断したかを、実際の画面とコマンドの流れに沿って詳しくまとめます。
この記事で分かること
- KUSANAGIの更新通知が出たときの正しい更新手順（コマンドをそのままコピペできます）
- 「profile」の部分を自分のプロファイル名に置き換える意味
- 更新済みかどうかを確かめる方法（バージョンの確認コマンド）
- OS側の更新が溜まっていたときの対処と、再起動のタイミング
- 通知が消えないときに、どこまで確認すれば安心できるか
環境
| 項目 | 内容 |
|---|---|
| サーバー | ConoHa VPS |
| OS | AlmaLinux 9 |
| 環境 | KUSANAGI 9 |
| サイト（プロファイル） | site1、site2、site3、site4 の4つ（実際の名前は伏せて仮の名前で表記しています） |
| ログイン方法 | SSH（rootで接続） |
1. 管理画面に出た通知
WordPress管理画面のKUSANAGIの設定ページに、次の内容の通知が表示されました。
- KUSANAGIプラグインの新しいバージョン「1.4.12」がリリースされました
- モジュールの更新は
dnf upgrade kusanagi kusanagi-wp-pluginsで実行できる - 更新後は
kusanagi update plugin profileでプロファイルのKUSANAGIプラグインを更新する
つまり、更新は2段階です。
| 段階 | やること | 対象 |
|---|---|---|
| 1段階目 | サーバー全体のモジュール（パッケージ）を更新する | VPSに1回だけ |
| 2段階目 | 各サイトのKUSANAGIプラグインを更新する | サイトごとに1回ずつ |
2. 最初の更新（9月29日ごろ）
2-1. SSHでVPSにログインする
TeraTermなどでVPSにSSH接続します。rootで入れている場合は、コマンドの前に sudo は不要です。通知にある # は「rootで実行中」という意味の記号なので、コマンドに # は入力しません。
2-2. モジュールを更新する
dnf upgrade kusanagi kusanagi-wp-plugins途中で Is this ok [y/N]:（日本語環境では「これでよろしいですか？」）と聞かれたら y を入力してEnterです。最後に「完了しました！」と出れば成功です。このときの更新内容は次のとおりでした。
| パッケージ | 更新前 | 更新後 |
|---|---|---|
| kusanagi | 9.11.2 | 9.11.6 |
| kusanagi-wp-plugins | 20260803 | 20260911 |
2-3. つまずきポイント：「profile」はそのまま入力しない
次に通知のとおり kusanagi update plugin profile を実行すると、エラーになります。理由は、「profile」は「プロファイル名を入れる場所」という意味で、そのまま入力する言葉ではないからです。まずプロファイル名（サイトごとのフォルダ名）を調べます。
ls /home/kusanagi今回は site1、site2、site3、site4 の4つが表示されました。
2-4. 試運転（–dryrun）してから本番更新する
いきなり更新するのが不安なときは、--dryrun を付けると「何が更新されるか」だけを表示して、実際には何も変更しません。site1の例です。
kusanagi update plugin --dryrun site1表示された内容は次のとおりです。
| プラグイン | 更新前 | 更新後 |
|---|---|---|
| KUSANAGI plugin | 1.4.11 | 1.4.12 |
| KUSANAGI Plus plugin | 1.0.8 | 1.0.10 |
| KUSANAGI configure plugin | すでに最新（更新不要） | |
問題なければ、--dryrun を外して本番実行します。最後に update completed. と出れば成功です。
kusanagi update plugin site1これを4サイト分、同じ流れで繰り返しました。
kusanagi update plugin site2kusanagi update plugin site3kusanagi update plugin site43. 数日後、まだ通知が出ている
更新した2、3日後に管理画面を開くと、同じ通知がまだ表示されていました。ここから原因を順番に確認していきます。
3-1. 本体のバージョンを確認する
rpm -q kusanagi kusanagi-wp-plugins結果は次のとおりでした。
- kusanagi-9.11.6
- kusanagi-wp-plugins-20260911
この表示だけでは「これが最新かどうか」は分かりません。そこで、もう一度更新コマンドを実行して確かめます。
3-2. もう一度アップデートを実行する
dnf upgrade kusanagi kusanagi-wp-pluginsすると、kusanagi が 9.11.6 から 9.11.7 に上がる更新が見つかりました。9月29日の更新後に、新しい版が公開されたものと思われます（公開日までは確認していません）。「これでよろしいですか？」と聞かれるので y で進めます。
kusanagi-wp-plugins は一覧に出なかったので、こちらは最新のままでした。
3-3. 各サイトのプラグインを再度更新する
念のため、4サイトすべてで更新コマンドを実行しました。
kusanagi update plugin site1kusanagi update plugin site2kusanagi update plugin site3kusanagi update plugin site44サイトとも「Installed KUSANAGI plugin is already the latest version. Nothing to do.」（すでに最新です）と表示され、最後は update completed. で終わりました。つまり、各サイトのプラグインは、すでに最新だったということです。
4. OS側の更新が溜まっていた
通知とは別に、サーバー側に更新待ちのパッケージがないかも確認しました。
dnf clean expire-cache && dnf check-update | grep -i kusanagiキャッシュを期限切れにしてから更新待ちを調べるコマンドです。KUSANAGIのリポジトリから、次のような更新待ちが表示されました。
| パッケージ | 更新後のバージョン |
|---|---|
| kusanagi-httpd24 | 2.4.68 |
| kusanagi-php83 | 8.3.35 |
| kusanagi-openssl | 3.5.9 |
| kusanagi-python312 | 3.12.14 |
| kusanagi-libcurl | 8.22.0 |
| kusanagi-composer | 2.10.3 |
ここに kusanagi-wp-plugins は出ていないので、通知の直接の原因ではなさそうです。ただ、セキュリティ面でも更新しておいて損はないので、まとめて更新しました。
dnf upgrade -y-y は確認の質問にすべて「はい」と答えるオプションです。パッケージの数が多いので、数分から10分ほど時間がかかります。途中で止まったように見えても動いていることが多いので、「完了しました！」が出るまで待ちましょう。
今回はカーネル（OSの中核部分）も新しいものが入り、古いカーネルは自動で削除されました。
5. 再起動して動作を確認する
カーネルが更新されたときは、再起動しないと新しいカーネルが使われません。再起動するとSSHが切れ、全サイトが1〜2分ほど止まります。アクセスの少ない時間帯に実行しましょう。
reboot2分ほど待ってからSSHで入り直し、サービスの状態を確認します。
kusanagi status今回の結果は次のとおりで、更新後も正常に動いていました。
| 項目 | 状態 |
|---|---|
| php-fpm（php83） | active（running） |
| MariaDB 10.11 | active（running） |
| Python | 3.12.14 |
6. 通知のキャッシュを消してみる
WordPressは更新情報を「transient（一時データ）」としてデータベースに保存しています。通知がキャッシュに残っている可能性を考えて、これを消してみました（WP-CLIを使います）。
wp transient delete --all --path=/home/kusanagi/site2/DocumentRoot --allow-rootsite2では「244 transients deleted from the database」と表示され、削除できました。他のサイトも、site2 の部分をプロファイル名に替えて実行できます。
そのうえで管理画面を Ctrl + F5 で強制リロードしましたが、通知は消えませんでした。
7. 実際に入っているバージョンを直接確認する
通知が消えないなら、「本当に1.4.12が入っているのか」をファイルから直接確かめます。site2の例です。
grep -m1 -i "Version:" /home/kusanagi/site2/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php /home/kusanagi/site2/DocumentRoot/wp-content/mu-plugins/wp-kusanagi-plus.php /home/kusanagi/site2/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php| ファイル | バージョン |
|---|---|
| wp-kusanagi.php（KUSANAGI plugin） | 1.4.12 |
| wp-kusanagi-plus.php（KUSANAGI Plus plugin） | 1.0.10 |
| kusanagi-wp-configure.php（configure plugin） | 1.1 |
通知の「1.4.12がリリースされました」と同じ番号になっています。つまり、更新は確実に完了していたことが、ファイルの中身から確認できました。
ちなみに、mu-plugins はWordPressの管理画面のプラグイン一覧には出てこない「必須プラグイン」用のフォルダです。KUSANAGIのプラグインはここに入っています。
8. 結局どういうことだったのか
ここまでの確認をまとめると、次のようになります。
| 確認したこと | 結果 |
|---|---|
| 各サイトのKUSANAGIプラグイン | 1.4.12（9月29日の時点で更新済み） |
| kusanagi 本体 | 9.11.7（今回あらたに更新） |
| OS側のパッケージ・カーネル | 更新して再起動済み |
| 通知 | まだ表示されている（原因は不明） |
通知が消えなかったのは、更新漏れではなかったということです。KUSANAGIの公式ページを調べましたが、この通知がいつ消えるのかについての説明は見つかりませんでした。実害はないので、今回は「更新済みであることを確認できた」ところで区切りとしました。どうしても消したい場合は、KUSANAGIユーザーフォーラムで質問するのが確実だと思います。
今回のまとめ：更新手順の早見表
| 順番 | やること | コマンド |
|---|---|---|
| 1 | モジュールを更新 | dnf upgrade kusanagi kusanagi-wp-plugins |
| 2 | プロファイル名を確認 | ls /home/kusanagi |
| 3 | サイトごとにプラグインを更新 | kusanagi update plugin プロファイル名 |
| 4 | （任意）OS側もまとめて更新 | dnf upgrade -y |
| 5 | （カーネル更新時）再起動 | reboot |
| 6 | 動作確認 | kusanagi status |
おわりに
VPSの管理は「コマンドが多くて大変そう」と感じますが、実際は決まった手順の繰り返しです。ポイントは次の3つです。
- 「profile」は自分のプロファイル名に置き換える
- 更新は「全体のモジュール」と「サイトごとのプラグイン」の2段階
- 通知が消えなくても、
Version:を直接確認すれば更新済みかどうかが分かる
同じ通知で困っている方の参考になれば幸いです。
コメント