数年使ってきた社内システムやWebサイトについて、開発会社から「言語（プログラミング言語）やOSのサポート期限が切れるので、バージョンアップが必要です」と見積もりが届く。画面も機能も変わらないのにまとまった金額がかかると聞くと、本当に今やる必要があるのか迷うのは自然なことです。
「開発会社から『バージョンアップが必要』と見積もりが来たけど、本当に今やる必要があるのか判断できない…」
先に結論をお伝えします。バージョンアップの要否は「サポート期限がいつか」「そのシステムがどれだけ狙われやすいか」「期限までの残り時間」の3つで判断できます。サポート期限は公式サイトで発注者自身も確認できます。そのうえで「そのまま更新」「段階的に更新」「作り直し」「延長サポート」「リスクを理解したうえで先送り」の5つの選択肢を比べれば、見積もりに納得して決められます。
この記事では、システムのバージョンアップの見積もりを受け取った発注者向けに、サポート期限（EOL）の意味、自分で確かめる方法、急ぐべきかの判断基準、選択肢の比較表、見積もりの中身を理解するための質問例を解説します。
バージョンアップの見積もりが来る理由：サポート期限（EOL）とは
サポート期限が切れると「セキュリティの修正」が止まる
システムは、OS（Windows ServerやLinuxなど、土台になるソフト）、プログラミング言語（PHP、Node.js、Javaなど）、フレームワーク（＝開発を効率化する骨組み）といった多くの部品の上に作られています。これらの部品には、提供元が修正版を出してくれる期間が決まっており、その期間が終わることを EOL（End of Life＝サポート終了） と呼びます。
サポート期限が切れても、システムがその日に止まるわけではありません。問題は、その後に弱点（脆弱性＝攻撃に悪用されうる欠陥）が見つかっても直してもらえなくなることです。
📰 出典：IPA「Windows 10 のサポート終了に伴う注意喚起」
IPAはこの注意喚起の中で、一般的にサポート終了後は新たな脆弱性が見つかってもベンダによる修正が行われず、情報漏えいや意図しないサービス停止などの被害を受ける可能性が高くなると説明しています。また、OSのサポート終了に伴い、その上で動くソフトウェアのサポートも終了することが考えられるとしています。これはWindows 10についての注意喚起ですが、考え方はサーバーのOSやプログラミング言語にも共通します。
部品ごとに期限が違い、数年ごとに必ずやってくる
やっかいなのは、部品ごとにサポートの期間やルールが違う点です。たとえば執筆時点（2026年9月）で各公式サイトは次のように定めています。
| 部品の例 | 公式サイトで確認できるルール・期限（執筆時点：2026年9月） |
|---|---|
| PHP（Webシステムでよく使われる言語） | 各バージョンはリリースから2年間は通常のサポート、その後2年間は重大なセキュリティ問題の修正のみ。PHP 8.1は2025年12月31日にサポート終了、PHP 8.2はセキュリティ修正が2026年12月31日まで |
| Node.js（Webシステムのサーバー側などで使われる実行環境） | 本番のシステムには「Active LTS」または「Maintenance LTS」（＝長期サポート版）の利用を推奨。Node.js 20はサポート終了（EOL）の表示。Node.js 27からリリースの周期が年1回に変わると案内 |
| Windows Server 2016（サーバー用OS） | 延長サポートの終了日は2027年1月13日（米国太平洋時間） |
📰 出典：Node.js「Node.js Releases」
📰 出典：Microsoft Lifecycle「Windows Server 2016」
PHPのように「4年でサポートが終わる」ルールの部品を使っている場合、数年運用すれば一度はバージョンアップが必要になります。つまり「バージョンアップの見積もり」は、特別なトラブルではなく、システムを使い続ける限り定期的に来るものだと考えておくと落ち着いて判断できます。
開発会社側の事情：「上げるだけ」では済まない
「バージョンの数字を上げるだけなのに、なぜこんなにかかるの？」と感じる方も多いと思います。実際には、新しいバージョンでは古い書き方が使えなくなっていることがあり、プログラムの修正が必要になります。さらに、修正後に全機能が今までどおり動くかを確認するテストが作業の大きな割合を占めます。
「画面は何も変わらないのに、裏側では『全部の機能を動かして確かめる』作業が必要なんです。長く更新していないほど、一度に直す量が増えてしまいます」
本当に今やるべき？判断のための4ステップ
ステップ1：見積もりの根拠になった「部品と期限」を一覧にしてもらう
まず、何のサポートが・いつ切れるのかを具体的に教えてもらいます。「バージョンアップが必要です」だけでは判断できないので、次のような一覧をもらいましょう。
| 部品 | 今のバージョン | サポート期限 | 更新先のバージョン |
|---|---|---|---|
| OS | （例：Windows Server 2016） | （例：2027年1月） | （例：Windows Server 2025） |
| プログラミング言語 | （例：PHP 8.2） | （例：2026年12月末） | （例：PHP 8.4） |
| フレームワーク・主なライブラリ | |||
| データベース |
ステップ2：公式サイトで期限を自分でも確かめる
一覧をもらったら、上の表にあるような提供元の公式ページで期限を確認してみましょう。英語のページが多いですが、「バージョン番号」と「日付」を見るだけなら難しくありません。検索するときは「製品名 supported versions」「製品名 lifecycle」「製品名 EOL」と入れると見つけやすくなります。
期限を一覧にまとめた有志のサイトもありますが、最終的な確認は提供元の公式ページで行うのが安心です。自分で確かめることは開発会社を疑うためではなく、社内の決裁で「なぜ今この費用が必要か」を説明する材料になります。
ステップ3：急ぐ度合いを3つの軸で判断する
同じ「サポート期限切れ」でも、システムによって急ぐ度合いは変わります。次の3つの軸で考えてみてください。
| 判断の軸 | 急いだほうがよい状態 | 比較的ゆとりがある状態 |
|---|---|---|
| 外部に公開しているか | インターネットから誰でもアクセスできるWebサイト・会員サイト・ECサイト | 社内ネットワークの中だけで使う業務システム |
| 扱う情報の重さ | 個人情報、決済情報、取引先の機密情報を扱う | 公開済みの情報や、漏れても影響が小さい情報のみ |
| 期限までの残り期間 | すでに切れている、または半年以内 | 1年以上先 |
外部公開で個人情報を扱い、期限がすでに切れているシステムは、最優先で対応を検討すべき状態です。反対に、社内だけで使う閉じたシステムで期限まで1年以上あるなら、他の改修と時期を合わせるなど、計画的に進める余地があります。ただし「社内だけだから安全」とは言い切れない点には注意が必要です。社内の端末が1台乗っ取られると、そこから社内システムが狙われることもあります。
ステップ4：選択肢を並べて比べる
急ぐ度合いが見えたら、次の選択肢を比べます。開発会社の見積もりが1案だけなら、他の案も出してもらえないか相談してみましょう。
バージョンアップの5つの選択肢を比較
| 選択肢 | 内容 | 費用・期間の傾向 | 向いているケース | 注意点 |
|---|---|---|---|---|
| そのまま更新 | 今の仕組みのまま、部品を最新の安定版へ上げる | 中程度。修正量とテスト量で変わる | 今後も数年使う予定で、業務に合っている | テストの範囲をどこまでにするか事前に決める |
| 段階更新 | 期限の近い部品から順に更新する／1つずつバージョンを上げる | 1回あたりは小さく、総額は増えることも | 予算を年度で分けたい、影響を小さく確かめたい | 全体の完了時期と総額を最初に確認する |
| 作り直し・乗り換え | 新しい技術で作り直す、またはSaaS（＝ネットで使うサービス）へ移る | 大きい。期間も長い | 業務が変わって使いにくい、更新の修正量が作り直しに近い | 期限までに間に合うか。間に合わない間の対策も必要 |
| 延長サポート | 提供元の有償延長サポートなどで一時的に修正を受け取る | 年額の費用がかかる | 移行の準備期間をどうしても確保したい | あくまで一時しのぎ。対象製品・期間が限られる |
| リスク受容（先送り） | 期限切れを理解したうえで当面そのまま使う | 目先の費用はかからない | 近く廃止が決まっている、外部から隔離されている | 社内で誰が判断したか記録し、見直し時期を決める |
延長サポートの例として、Microsoftは Windows Server 2012／2012 R2 向けに「Extended Security Updates（拡張セキュリティ更新）」を用意しています。Microsoftはこれをサポート終了後も古い製品を使う必要がある顧客のための「最後の手段」と位置づけており、Azure（同社のクラウド）上のサーバーでは追加料金なし、それ以外では有償購入としています。対象は重要度の高いセキュリティ更新で、新機能は含まれず、Windows Server 2012／2012 R2 向けの提供は2026年10月13日までと案内されています（執筆時点：2026年9月）。
📰 出典：Microsoft Learn「Overview of Extended Security Updates for Windows Server 2012, and 2012 R2」
このように延長サポートは「移行までの時間を買う」ための手段で、延長の期限が来れば結局は更新か移行が必要になります。また、PHPやNode.jsのようなオープンソース（＝誰でも無償で使えるソフト）では、公式の延長サポートがない場合もあります。どの部品に延長の手段があるかは、開発会社に確認しましょう。
なお「リスク受容」は、何もしないこととは違います。期限切れのまま使うと決めた場合でも、外部からの接続を制限する、監視を強める、いつまでに廃止・移行するかを決めるといった対策とセットで考えるのが一般的です。
見積もりの中身を理解するためのポイント
見積もりに納得するには、金額の内訳が「何にかかっているか」を知ることが近道です。バージョンアップの見積もりには、主に次のような作業が含まれます。
- 調査：どの部分の修正が必要かを洗い出す
- 修正：新しいバージョンで動かない書き方や部品を直す
- テスト：全機能が今までどおり動くかを確認する（多くの場合、ここが大きな割合を占める）
- 本番への切り替え：サーバーの入れ替えやデータの移行、切り替え当日の立ち会い
- 不具合対応：切り替え後にしばらく様子を見て直す
発注者側でも、テストの一部（普段の業務の流れで動かしてみる確認）を担当すると、確認の漏れを減らせます。何をどちらが担当するかは、見積もりの段階で決めておきましょう。
また、月々の保守費用の中にバージョンアップが含まれているかどうかは契約によって異なります。保守費用の内訳の確認方法は、システムの保守費用は何に払っている？月額保守費の内訳と見直す前に確認したいことで詳しく解説しています。
次のバージョンアップを予算に組み込む方法
今回の対応を決めたら、次回のことも考えておくと、同じ悩みを繰り返さずに済みます。
- 期限の一覧を社内で持つ：ステップ1でもらった一覧を保管し、年に1回更新してもらう
- 数年ごとの費用として予算化する：部品の期限から、次のバージョンアップの時期はおおよそ予測できます。「突然の出費」ではなく、数年ごとの計画的な費用として予算に入れておきましょう
- こまめに上げる：長く放置するほど一度の修正量が増える傾向があります。小さな更新をこまめに行うほうが、1回あたりの負担を抑えやすくなります
- 保守契約での扱いを決める：バージョンアップを月額保守に含めるか、都度見積もりにするかを契約更新時に話し合う
バージョンアップ判断でやりがちな失敗
- 「今動いているから大丈夫」と先送りし続ける：期限切れの状態が長く続くほど、更新の修正量が増え、結果的に費用も期間も膨らみやすくなります
- 期限ギリギリに相談する：開発会社の人手が空いていないこともあり、テスト期間が短くなりがちです。期限の半年〜1年前には相談を始めると余裕があります
- 金額だけで比べる：相見積もりを取る場合は、更新先のバージョンやテストの範囲がそろっているかを確認しましょう。範囲が違えば金額が違うのは当然です
- 先送りの判断を記録しない：担当者が替わると「なぜ更新しなかったのか」が分からなくなります
発注者がやることチェックリスト
- ☐ サポートが切れる部品・今のバージョン・期限・更新先を一覧にしてもらった
- ☐ 主な部品の期限を、提供元の公式ページで自分でも確認した
- ☐ 外部公開か・扱う情報の重さ・残り期間の3つで急ぐ度合いを整理した
- ☐ 「そのまま更新」以外の選択肢（段階更新・作り直し・延長サポート・先送り）も比べた
- ☐ 見積もりの内訳（調査・修正・テスト・切り替え・不具合対応）を確認した
- ☐ 自社が担当するテストや確認作業を決めた
- ☐ 先送りする場合は、判断した人・理由・見直す時期を記録した
- ☐ 次回のバージョンアップの時期と費用の目安を予算計画に入れた
開発会社への質問例
- 「サポートが切れる部品と、それぞれの期限・更新先のバージョンを一覧でいただけますか？」
- 「この見積もりのうち、調査・修正・テスト・切り替えはそれぞれどのくらいの割合ですか？」
- 「一度にすべて更新する場合と、期限の近いものから段階的に更新する場合で、費用と期間はどう変わりますか？」
- 「期限までに間に合わない場合、延長サポートや、期限切れの間のリスクを下げる対策はありますか？」
- 「次にバージョンアップが必要になるのはいつ頃の見込みで、その費用は保守契約に含められますか？」
まとめ：バージョンアップは「期限・狙われやすさ・残り時間」で判断する
「バージョンアップが必要」という見積もりは、システムを使い続けるうえで数年ごとに必ずやってくるものです。判断のポイントは次のとおりです。
- サポート期限が切れると、弱点が見つかっても修正されなくなる
- 期限は提供元の公式ページで発注者自身も確認できる
- 外部公開か・扱う情報の重さ・残り期間の3つで急ぐ度合いを判断する
- そのまま更新・段階更新・作り直し・延長サポート・リスク受容を比べて選ぶ
- 次回のバージョンアップを予算と保守契約に組み込んでおく
見積もりに疑問があれば、遠慮なく内訳や他の選択肢を聞いてみてください。一覧と選択肢がそろえば、「言われるがまま」ではなく、納得して決められるはずです。
あわせて読みたい関連記事
コメント
コメント一覧 （1件）
[…] […]