PHP・WordPress 本体・プラグイン・テーマ — 更新するのは誰か。レンタルサーバーで「事業者の担当」と「サイト管理者の担当」を分けて考える
前回の記事「PHP 本体の重大な脆弱性が公表された」の続編。個別の事業者がどう対応しているかは、事業者ごとに異なり、時期によっても変わる。この記事では 特定の事業者の対応状況は断定せず、自分の契約で確かめるための考え方と手順を書く。
「誰かがやってくれている」が一番危ない
セキュリティ更新の話になると、「サーバー会社が当ててくれているはず」と「自分のサイトの更新は自分の仕事」という2つの思い込みが、同時に存在していることが多い。どちらも半分は正しく、半分は違う。
WordPress サイトは、下から順に次の層が積み重なって動いている。
| 層 | 例 | 更新の主な担い手（一般的な傾向） |
|---|---|---|
| ハードウェア・OS・Web サーバー | Linux、Apache / nginx | 事業者 |
| PHP（実行基盤） | 8.3 系など | 契約や設定による（事業者が上げる場合も、利用者が選ぶ場合もある） |
| データベース | MySQL / MariaDB | 事業者 |
| WordPress 本体 | コア | 利用者（自動更新の設定次第） |
| プラグイン | 各種 | 利用者（自動更新の設定次第） |
| テーマ | 各種 | 利用者（自動更新の設定次第） |
この表で大事なのは、PHP の行だけが「契約による」 という点だ。ここが曖昧なまま運用されやすく、前回のような PHP 本体の脆弱性が出たときに、「事業者が上げたと思っていたら、実は自分で切り替える設定だった」という行き違いが起きうる。
層ごとに、確認する場所が違う
PHP
レンタルサーバーでは、次のような運用が見られる。どれに当たるかは事業者・プランによって違うため、自分の契約で確認する必要がある。
- 管理画面で、ドメインごとに PHP のバージョンを 利用者が選ぶ 方式。選んだ系統の中でのパッチ更新は事業者側が行うことが多いが、そうでない場合もある
- 事業者が 一括で 上げる方式。お知らせで告知される
- 古い系統が、サポート終了後も 選択肢に残り続ける ことがある。選べることと、安全であることは別の話だ
確認の入口は2つ。事業者の お知らせ・障害情報ページ（PHP の更新やサポート終了の告知が出る）と、管理画面のバージョン表示。さらに、実際にサイトが動いている版は、WordPress 管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確かめられる。SSH の php -v はコマンドライン用で、Web を動かす版と違うことがある（前回の記事のとおり）。
WordPress 本体
マイナー更新（例: 6.8.1 → 6.8.2）は、既定でバックグラウンドの自動更新が有効になっている。メジャー更新（6.8 → 6.9）は既定では自動では入らない。この仕組みは以前の記事「WordPress の自動バックグラウンド更新は何を対象にしているのか」で扱った。サイト管理者の側で、設定が変えられていないか は確認の対象になる。
プラグイン・テーマ
既定では自動更新されない。プラグインごとに自動更新を有効にするかどうかを利用者が決める。ここは事業者の担当ではなく、完全にサイト管理者の担当 だ。更新の通知が来ていても、放置されれば何も起きない。
プラグインの更新待ちは、管理画面のほか、WP-CLI でも一覧できる。
wp plugin list --update=available
wp theme list --update=available
wp core check-update
事業者が担当する層でも、「確認」は利用者の仕事
「事業者の担当」と書いた層でも、利用者が何もしなくてよいわけではない。
- 事業者のお知らせを受け取れる状態にしておく: 登録メールアドレスが古く、告知が届いていない例は珍しくない。連絡先が最新か、迷惑メールに振り分けられていないかを確認する
- 告知された期限を把握する: PHP の旧系統が使えなくなる日など、期限が決まった告知は、カレンダーに書いておく
- 更新後にサイトが動くかを確認する: 事業者が PHP を上げた結果、古いプラグインが動かなくなる可能性は、利用者側の問題として残る
事業者が作業をしても、自分のサイトで何が起きたかを確かめるのは、サイトの持ち主 だ。
複数サイトを預かる場合は、表を作る
複数のサイトを管理していると、サイトごとに契約・サーバー・PHP の版がばらつく。前回の記事の最後に書いたとおり、通知を受けてから対象を洗い出すのでは時間がかかる。次のような表を、平常時に用意しておく。
| サイト | サーバー（契約） | PHP の版と確認日 | PHP の更新担当 | 事業者のお知らせの受け取り先 |
|---|---|---|---|---|
| example-a | 事業者 X | 8.3.36（10/29） | 利用者が選択 | 管理者のメール |
| example-b | 事業者 Y | 8.2.35（10/29） | 事業者が一括 | 共有アドレス |
最後の2列（更新担当と告知の受け取り先）が、普段は空欄になりやすい。ここが埋まっているかどうかが、緊急時の初動の差になる。
「責任共有」の考え方
クラウド業界には「責任共有モデル」という言葉がある。基盤の安全は事業者が、その上に載せるものの設定と運用は利用者が、という切り分けだ。レンタルサーバーも同じ構図で、どこまでが事業者で、どこからが自分か の線は、契約ごとに少しずつ違う。
線の位置を知らないまま運用すると、「事業者がやっているはず」と「自分がやっているはず」の隙間に、更新されない層が残る。保守の仕事の一部は、この 線を確認し、表に書き、定期的に見直す ことにある。
まとめ
- 更新の担い手は層ごとに違う。PHP は契約による ので、特に確認が必要
- WordPress 本体は設定次第、プラグイン・テーマは基本的に利用者の担当
- 事業者の担当の層でも、告知の受け取りと、更新後の動作確認は利用者の仕事
- 複数サイトでは、「更新担当」と「告知の受け取り先」を含めた表を平常時に作っておく
自分の契約で「PHP を更新するのは誰か」を、今日一度だけ確かめておく。それだけで、次の緊急時の動き出しが変わる。