EOLのソフトウェア管理、PHPだけ見ていないか──PHP・DB・OS・CMS・ライブラリのサポート終了を棚卸しし、1枚の台帳で追う

この記事は、EOLのソフトウェア管理、つまり保守しているサイトを支える部品のサポート終了（EOL）を棚卸しし、台帳で追う方法を扱います。

サポート終了の案内が、毎回「突然」になる

「PHPの終了は追っていたのに、データベースの版が先に切れていた」
「サーバーのOSが終了していると、事業者からの通知で初めて知った」

保守の現場では、サポート終了の知らせが、いつも別々の方向から突然届きます。
理由は単純で、どの部品がいつ終わるかを、一か所にまとめていないからです。

EOLの棚卸しとは、サイトを支える部品をすべて書き出し、それぞれの公式のサポート終了日と確認した日を、1枚の台帳に並べることである

黒字化の外科医です。サポート終了の「突然」をなくす棚卸しを解剖します。

台帳が必要な理由は、三つあります。

第一に、サポート終了は、PHPだけの話ではないから。
IPA（情報処理推進機構）は、Windows 10 のサポート終了に伴う注意喚起の中で、OSだけでなく、その上で動くアプリケーションもサポートが順次終わるため、あわせて対策が必要だと述べています。サイトも同じで、OS、データベース、PHP、CMS、ライブラリが、それぞれの日程で終わっていきます。

第二に、終了日は、部品ごとに確認する場所が違うから。
PHPなら php.net、フレームワークなら公式のリリースノート。確認の場所を台帳に書いておかないと、毎回探すところから始まります。

第三に、終了日は、変わることがあるから。
延長されることも、前倒しされることもあります。台帳には、日付と一緒に「いつ確認したか」を残します。

棚卸しする部品の6分類

① OS（サーバーのOS）
② Webサーバーと、PHPなどの実行環境
③ データベース
④ CMS（WordPress、EC-CUBEなど）とプラグイン
⑤ フレームワーク（Laravelなど）
⑥ ライブラリ（Composerやnpmで入れたもの）

レンタルサーバーなら、①〜③の多くは事業者の管理です。
それでも、事業者が提供をやめる予定は、台帳に書いておきます。PHPの系列の提供終了で、サイトが動かなくなる事故があるからです。

▶ サーバー移行とPHPの強制アップで、サイトが止まる前に──旧PHPの提供終了で起きる事故の型と防ぎ方、移行チェックリスト

公式で確かめた終了日の例

2026年10月に、公式の発表で確かめた例です。

部品　　　　　 版　　 セキュリティ修正の終了　 確認した場所
PHP　　　　　　8.2　　2026年12月31日　　　　　 php.net Supported Versions
PHP　　　　　　8.3　　2027年12月31日　　　　　 php.net Supported Versions
Laravel　　　　12　　 2027年2月24日　　　　　　Laravel公式 Release Notes
Laravel　　　　13　　 2028年3月17日　　　　　　Laravel公式 Release Notes

データベースやOSは、製品と配布元によって終了日の決め方が違います。
台帳には、必ずそれぞれの公式のページで確かめた日付だけを書いてください。記事や他社の一覧から写すと、古い日付が残ります。

今すぐ試せる：保守先の部品を書き出すプロンプト

私はWeb制作会社の経営者です。保守しているサイトの部品を、EOLの台帳の形に整理してください。

【前提】
・サイト名と、サーバーの種類（レンタルサーバー／VPS／クラウド）：〔記載〕
・わかっている部品と版（OS、PHP、データベース、CMS、フレームワーク、主なライブラリ）：〔記載〕
・公式で確認済みの終了日と、確認した日：〔記載〕

1. 部品を、上の6分類で並べる。
2. 版がわからない部品を「要調査」として挙げ、調べる方法を書く。
3. 終了日が未確認の部品について、確認すべき公式の場所の種類（開発元、配布元、サーバー事業者）を示す。
4. 終了日が1年以内の部品を、先頭に並べ替える。

終了日を推測で書かないこと。未確認は「未確認」と書くこと。

EOL台帳工場：列の設計と、棚卸しの工数

台帳の列（1行＝1サイトの1部品）

サイト名／顧客名
分類（①〜⑥）
部品の名前
今の版
管理する人（自社／顧客／サーバー事業者）
セキュリティ修正の終了日
確認した場所（公式のページ名）
確認した日
顧客への最初の案内日
次の行動と期日

「管理する人」の列が、一番大切です。ここが空欄の部品が、事故の入口になります。

計算例：初回の棚卸しと、その後の更新

例：保守しているサイト 30件
　　初回の書き出し：1件あたり30分
　　30件 × 30分 ＝ 900分 ＝ 15時間

時間単価 8,000円（例）
　　15時間 × 8,000円 ＝ 120,000円（初回）

その後の月次の見直し：月2時間
　　2時間 × 8,000円 ＝ 月16,000円
　　16,000円 ÷ 30件 ≒ 1件あたり月533円

初回は、社内の投資として行うか、点検の名目で顧客に提案するかを決めます。

構造的なリスク

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

台帳を作ると、終了が近い部品が一斉に見えて、「全部の顧客に一度に案内しなければ」と焦ります。
けれど、一斉の案内は、問い合わせと工事を同じ月に集中させます。

終了日の近い順に、月ごとに案内する顧客を割り振ってください。台帳は、案内の順番を決めるための道具です。

よくあるQ&A

Q. 顧客が自分で契約しているサーバーも、台帳に入れるべきか？

入れてください。「管理する人」の列に「顧客」と書き、終了の予定を案内した日だけを記録します。それが、範囲外であることを示す記録になります。

Q. 終了日が公式に出ていない部品は、どうするか？

「公式の発表なし」と書き、確認した日を残します。ライブラリでは、更新が長く止まっていること自体を、見直しのきっかけにします。

Q. 台帳は、どんな道具で作ればいいか？

表計算ソフトで十分です。大切なのは道具ではなく、確認した日の列を毎月更新することです。

最後に

サポート終了は、PHPだけでなく、サイトを支えるすべての部品で、それぞれの日程で来ます。

部品を書き出し、公式の終了日と確認した日を1枚に並べた会社だけが、「突然の終了」を、順番に案内できる予定に変えられるのです。

台帳の列と月次の運用表を、そのまま使える形にしたキットはこちらです。

▶ パッチ管理台帳のテンプレート、制作会社の保守キット──列設計、月次運用表、月次報告の型、緊急パッチの判断表、告知文例、AIプロンプト

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

#Web制作会社 #EOL #サポート終了 #ソフトウェア管理 #PHP #保守契約 #制作会社経営 #中小企業 #台帳管理 #脆弱性対策