PHPのパッチは「8.3のまま、末尾の数字を上げる」更新──同じ系列のセキュリティ修正の当て方と頻度、レンタルサーバーとVPSで違う責任の線

この記事は、PHPのパッチ、つまり同じ系列の中のセキュリティ修正（8.3.x の更新など）を、いつ、誰が、どう当てるかを扱います。

「PHPは8.3だから大丈夫です」と答えていないか

「御社のサイトのPHPは、サポート中の8.3なので大丈夫です」

保守先にこう答えて、安心していないでしょうか。
けれど、同じ8.3でも、8.3のどの版かによって、直っている弱点は違います。

8.3という「系列」がサポート中でも、その中の古い版のまま止まっていれば、すでに公開された修正を受け取っていないことになります。

PHPのパッチとは、同じ系列の中で、見つかった不具合と弱点を直した版に入れ替えることである

黒字化の外科医です。バージョンアップの陰に隠れがちな、PHPのパッチの運用を解剖します。

8.2から8.4へ上げるような系列をまたぐ移行は、すでに別の記事で扱いました。

▶ PHPバージョンアップを「無償の後始末」で終わらせない──保守の売上に変える考え方と、顧客への切り出し方の文例

今回は、系列はそのままに、末尾の数字だけを上げる更新の話です。
これを別に管理すべき理由は、三つあります。

第一に、パッチは、バージョンアップよりはるかに頻繁に出るから。
系列をまたぐ移行は数年に一度ですが、パッチは同じ系列の中で何度も出ます。

第二に、パッチを当てる人が、サーバーの種類で変わるから。
レンタルサーバーでは事業者が、VPSでは契約した側が当てることが多く、制作会社がどこまで責任を持つかが曖昧になりやすいのです。

第三に、「系列がサポート中」と「最新の修正が入っている」は、別のことだから。
顧客への説明でこの二つを混ぜると、守れていないものを守れていると言ってしまいます。

PHPのパッチはいつ出るのか：php.netで確かめた頻度

php.net の Supported Versions のページでは、各系列は公開から2年間は全面的にサポートされ、その後の2年間は重大なセキュリティの問題だけが直される、と説明されています。

系列　　公開日　　　　　　全面サポートの終了　　セキュリティ修正の終了
8.2　　 2022年12月8日　　 2024年12月31日　　　 2026年12月31日
8.3　　 2023年11月23日　　2025年12月31日　　　 2027年12月31日
8.4　　 2024年11月21日　　2026年12月31日　　　 2028年12月31日
8.5　　 2025年11月20日　　2027年12月31日　　　 2029年12月31日
（php.net Supported Versions、2026年10月に確認）

全面サポートの期間について、PHPのソースコードを管理する公式リポジトリの「release-process」の文書では、パッチの版は4週間ごとに出すと書かれています。

一方、セキュリティ修正だけの期間に入った系列は、Supported Versions のページで「必要に応じて」出すと説明されています。報告の数によって、何度も出ることも、一度も出ないこともある、とされています。

つまり、2026年10月の時点では、8.4と8.5はおおむね4週ごと、8.2と8.3は必要なときだけ、と見ておけばよいのです。

レンタルサーバーとVPSで、パッチを当てる人が違う

レンタルサーバーの場合

多くのレンタルサーバーでは、制作会社が選べるのは「8.3を使う」という系列までです。
その中のどの版が入るかは、サーバー事業者の運用で決まります。

制作会社の仕事は、事業者のお知らせで、系列の提供終了の予定を追うことと、今入っている版を記録することです。版の確認は、管理画面か、phpinfo の表示で行えます。確認用のファイルは、見終わったら必ず消してください。

VPS・クラウドの場合

OSのパッケージやコンテナでPHPを入れていれば、パッチを当てるのは契約した側です。
保守契約に書いていなければ、誰も当てていない状態が何か月も続きます。

なお、OSの配布元が提供するPHPのパッケージは、配布元の方針で修正が取り込まれるため、PHPの版の数字だけでは直っているかを判断できないことがあります。その場合は、配布元のセキュリティのお知らせを確認の場所に加えます。

今すぐ試せる：保守先のPHPのパッチの状況を整理するプロンプト

私はWeb制作会社の経営者です。保守しているサイトのPHPのパッチの状況を整理してください。

【前提】
・サイトごとの、サーバーの種類（レンタルサーバー／VPS／クラウド）：〔記載〕
・サイトごとの、PHPの版（例：8.3.〇）と確認した日：〔記載〕
・php.netで確認した、各系列のセキュリティ修正の終了日：〔記載〕
・保守契約で、パッチの適用を自社が引き受けているサイト：〔記載〕

1. サイトを「事業者が当てる」「自社が当てる」「誰も決めていない」に分ける。
2. 「誰も決めていない」サイトについて、顧客に確認する質問を3つ作る。
3. 系列の終了が1年以内に来るサイトを、別に一覧にする。
4. 月1回の確認で見る項目を、5つ以内にまとめる。

推測で版の数字を補わないこと。不明な項目は「不明」と書くこと。

パッチ確認工場：月1回の確認と、かかる時間

月1回の確認表

□ 各サイトのPHPの版（8.3.〇まで）を記録したか
□ php.net の ChangeLog で、その系列の新しい版が出ていないか見たか
□ 新しい版の告知や修正一覧に、セキュリティの修正が含まれるか見たか
□ レンタルサーバーなら、事業者のお知らせを見たか
□ VPSなら、自社で当てる予定日を決めたか
□ 系列のセキュリティ修正の終了日まで、1年を切っていないか

計算例：確認の時間を、保守料に入れる

例：保守しているサイト 20件
　　1件あたりの確認と記録：15分
　　20件 × 15分 ＝ 300分 ＝ 月5時間

時間単価 8,000円（例）
　　5時間 × 8,000円 ＝ 月40,000円
　　40,000円 ÷ 20件 ＝ 1件あたり月2,000円

実際に当てる作業と検証は、この外です。

▶ パッチ適用の手順を「本番でそのまま更新」で済ませない──検証環境、バックアップ、戻し方、顧客への告知までの本番反映フロー

構造的なリスク

逆説を指摘しておきます。

パッチをこまめに当てるほど、「当てたせいで動かなくなった」事故の機会も増えます。
パッチは不具合と弱点の修正が中心ですが、拡張機能や独自の設定との組み合わせで何が起きるかは、事前にわかりません。

だから、自社で当てるサイトは、検証の場所と戻し方を決めてからにします。決めていないなら、まず事業者が当てるレンタルサーバーに寄せることも、立派な判断です。

よくあるQ&A

Q. 新しいパッチが出たら、すぐ当てるべきか？

修正の中身で決めます。外から悪用できる弱点の修正なら早めに、それ以外なら月次の定期作業にまとめます。判断の基準は、パッチ管理台帳キットで表にしています。

Q. 顧客に、パッチのたびに連絡すべきか？

毎回の連絡は要りません。月次の報告に「PHP 8.3.〇 から 8.3.〇 へ更新」と一行書けば十分です。緊急で当てたときだけ、個別に知らせます。

Q. 弱点の情報は、どこで集めればいいか？

php.net の ChangeLog に加えて、JVNなどの公的な情報を決まった頻度で見ます。見る場所の決め方は、脆弱性情報の収集の記事で扱いました。

最後に

PHPの系列がサポート中であることと、最新の修正が入っていることは、別のことです。

末尾の数字まで記録し、誰が当てるかを契約で決めた会社だけが、「大丈夫です」を根拠のある言葉にできるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #PHP #セキュリティパッチ #脆弱性対策 #サーバー保守 #保守契約 #制作会社経営 #中小企業 #レンタルサーバー #VPS