業務システムの部品の期限|.NET 8・9は11月10日、PostgreSQL 14は11月12日、PHP 8.2は12月31日(開発会社に聞く順番)
Python 3.10 は2026年10月1日に終了済み、.NET 8・9 は11月10日、PostgreSQL 14 は11月12日、PHP 8.2 は12月31日に期限が来ます。期限のあとに止まるもの、開発会社に出してもらう部品の表と聞く順番、上げるか上げないかの分け方、保守契約で確かめる5点を、各製品の公式情報でまとめました。
目次 クリックで開く
この記事の要点
- 業務システムの部品の期限は、Python 3.10 が2026年10月1日(終了済み)、.NET 8 と .NET 9 が11月10日、PostgreSQL 14 が11月12日(最終リリース)、PHP 8.2 が12月31日(セキュリティ修正の終了)。いずれも各製品の公式の表にある日付。
- 期限が来ても、システムはすぐには止まらない。止まるのは、脆弱性が見つかったときの修正の提供。上げる側の作業は、開発会社が持つことが多いので、発注側が最初にやるのは、使っている部品と版を一覧にしてもらうこと。
- 上げるかどうかは、外から開けるか、個人情報や取引先の情報があるかで急ぎ方が変わる。保守契約では、版を上げる作業が定額の中か、別見積かを先に確かめる。
4つの部品の期限まで、あと何日か(2026年10月3日から数えて)
日数は、10月3日から各期限の日までを数えたもの(当社の計算)。期限の日付は各製品の公式の表
出典:Microsoft .NET サポート ポリシー、PostgreSQL Versioning Policy、PHP: Supported Versions、Python Developer’s Guide(2026年10月3日確認)
開発会社に作ってもらった業務システムが、「部品のサポートが切れる」と言われたときに見るのは、4つの日付です。Python 3.10 は2026年10月1日にすでに終わり、.NET 8 と .NET 9 が11月10日、PostgreSQL 14 が11月12日、PHP 8.2 が12月31日です。10月3日から数えると、.NET は38日、PostgreSQL 14 は40日、PHP 8.2 は89日です(いずれも各製品の公式の表。2026年10月3日確認)。
期限が来たあとの扱いは、.NET については Microsoft が書いています。新しいセキュリティの更新と技術サポートが出なくなる一方、.NET 8・9 で作ったアプリは動き続ける、という説明です(.NET Blog)。止まるのは、システムの動作より、脆弱性が見つかったときに直してもらえる状態です。
この記事は、どの言語と DB を使っているのかも知らない担当の方が、開発会社に何を聞き、聞いたあとに何を決めるかを書いています。私たちの見立てでは、最初にやるのは、使っている部品と版の一覧を開発会社に出してもらうことです。そこに期限を並べれば、上げる費用と、保守契約の範囲の話に進めます。
期限の表:終わる日と、上げ先の版
上の4つは、それぞれ別の団体が決めています。表の「終わる日」が、その版の修正が出なくなる日です。上げ先は、1つ上の版でなく、期限の長い版を選べます。1つ上の版が、翌年に終わる場合があるからです。.NET 9 は、.NET 8 と同じ11月10日に終わります(Microsoft .NET サポート ポリシー)。
| 部品と版 | 終わる日 | 1つ上の版 | いちばん新しい側の版 |
|---|---|---|---|
| .NET 8(LTS) | 2026年11月10日 | .NET 9:2026年11月10日(同じ日) | .NET 10:2028年11月14日 |
| PostgreSQL 14 | 2026年11月12日(最終リリース) | PostgreSQL 15:2027年11月11日 | PostgreSQL 18:2030年11月14日 |
| PHP 8.2 | 2026年12月31日(セキュリティ修正の終了) | PHP 8.3:2027年12月31日 | PHP 8.5:2029年12月31日 |
| Python 3.10 | 2026年10月1日(終了済み) | Python 3.11:2027年10月 | Python 3.13:2029年10月 |
PHP 8.2 は、バグの修正を含む「アクティブサポート」が2024年12月31日に終わっていて、いまはセキュリティの修正だけの期間です(PHP: Supported Versions)。PostgreSQL は、発売から5年間が対象で、最終リリースのあとはバグもセキュリティも修正されません(PostgreSQL Versioning Policy)。Python 3.10 は、公式の表で終了(2026年10月1日)になっています(Python Developer’s Guide)。
どの部品が、どの版で載っているかの一覧づくりから、一緒に見る相談もできます(古い業務システムの移行・保守の案内)。
期限のあとに止まるもの:システムではなく、修正の提供
期限のあとに止まるもの(公式の説明)
確かめた範囲では、PostgreSQL と PHP の公式ページに、期限後もアプリが動き続けるかの記述はない。.NET だけが書いている
.NET 8・9
新しい修正と、技術サポートが出なくなる
- Microsoft は、期限のあとも .NET 8・9 で作ったアプリは動き続けると書いている
- 止まるのは、セキュリティの更新と技術サポート
上げ先:.NET 10(2028年11月まで)
PostgreSQL 14
最終リリースのあと、修正が出なくなる
- 11月12日が、14の最終リリースの予定日
- その後は、バグの修正もセキュリティの修正も出ない
上げ方:pg_upgrade か、ダンプと読み込み
PHP 8.2
すでに、セキュリティ修正だけの期間
- バグの修正を含む「アクティブサポート」は2024年12月31日に終わっている
- 12月31日で、その修正も終わる
上げ先:8.3 以降(終了日は表のとおり)
出典:.NET Blog(2026年6月29日)、PostgreSQL Versioning Policy、PHP: Supported Versions(2026年10月3日確認)
.NET の上げ方は、Microsoft の説明では、プロジェクトの設定の TargetFramework を net10.0 に変え、開発の環境と動かす環境も更新する流れです。Visual Studio 2022 は、今後の更新で .NET 8・9 の部品をサポート外として表示するようになる、とも書かれています(.NET Blog)。当社の見方では、開発会社の作業は設定の変更だけでなく、変えたあとの動作の試験が中心になります。
PostgreSQL は、版を上げるとき、pg_upgrade かダンプと読み込みが要ります。途中の版を飛ばして上げることもできますが、飛ばした版のリリースノートは読む、という案内です。同じ版の中のマイナー更新は、サーバーを止めて入れ替えるだけで、ダンプは要りません(PostgreSQL Versioning Policy)。
開発会社に聞く順番と、出してもらう「部品の表」
部品の表を出してもらっても中身が分からない、作った人がいないシステムは、ソースコードから AI で仕様書を起こす方法があります。読み取れる範囲は「作った人がいない業務システムの仕様書をAIでソースコードから起こす」で解説しています。
開発会社に聞く順番
1 と 2 は、回答を表にして出してもらう。3 以降は、その表を見ながら決める
聞く順番は当社の整理。期限の日付は各製品の公式の表(2026年10月3日確認)
聞く順番は、費用より先に、部品と期限です。使っている部品が分からないまま費用を聞くと、回答が「上げる作業の見積り」と「保守の費用」のどちらの話かが混ざります。1と2は、回答を表にして出してもらいます。
| 出してもらう欄 | 書いてもらうこと | 確かめ方 |
|---|---|---|
| 言語 | PHP・.NET・Python などと、その版 | 版の数字は、システムの管理画面か、サーバーの設定で開発会社が確かめる |
| フレームワーク・ライブラリ | 言語の上に載せている部品と、その版 | 各部品にも期限がある。公式の表で終了日を確かめる |
| データベース | PostgreSQL・MySQL などと、その版 | 版は、DB のサーバーに入って確かめる |
| OS・サーバー | Windows Server・Linux の種類と版 | OS の期限は別。Windows Server 2016 と Windows Server 2012 R2 は、別の記事に書いた |
| 動かしている場所 | クラウドか、自社のサーバーか、レンタルサーバーか | 誰が OS と DB の更新をしているかが、ここで分かれる |
フレームワークやライブラリにも、それぞれの期限があります。表に出てきた名前ごとに、公式の表で終了日を確かめます。この記事では、4つの部品以外の期限は確かめていません。
上げるか、上げないか:外から開けるか、個人情報があるか
期限が来た部品を、上げずに使い続けること自体を止める定めは、確かめた範囲にはありません。そのうえで、期限のあとに脆弱性が見つかっても、公式からは直されません。直されない状態のシステムが、インターネットから届く場所にあるか、個人情報や取引先の情報を持っているかで、急ぎ方が変わります。
上げる時期の決め方(当社の見立て)
期限が過ぎたあと、脆弱性が見つかっても公式からは直されない。外から届く経路と、守る情報の量で、急ぎ方が変わる
インターネットから開ける画面や API がある
取引先がログインする、外出先のスマホから使う、他社のシステムとつながっている
個人情報や、取引先・売上の情報が入っている
従業員・顧客・取引先の名前や連絡先、請求や売上のデータ
上げる作業の見積りと日程が、まだ出ていない
期限までに上げられるか、開発会社の回答がない
判断の分け方は当社の見立て。期限のあとに修正が出なくなることは、各製品の公式の説明(2026年10月3日確認)
上げない場合は、期限のあとの修正をどうするか、開発会社に聞きます。上げない理由と、次に見直す時期は、社内の記録に残します。上げる場合は、期限までに作業が収まるかを、見積りと日程で確かめます。上げる作業の大きさは、システムの中の独自の処理の数に左右されます(基幹システムの入れ替え費用と期間の記事で書いた見方が、ここにも当てはまります)。
保守契約を見直す:上げる作業が、定額の中か、別見積か
保守契約には、「不具合の対応」だけが入っている場合と、「部品の更新」まで入っている場合があります。どちらかは、契約書の文面と、開発会社の回答で確かめます。次の5点を、部品の表と一緒に聞きます。
| 保守契約で見る点 | 確かめること |
|---|---|
| 版を上げる作業 | 保守の費用に含まれているか、別の見積りか。含まれるなら、どの範囲まで(言語、DB、フレームワーク)か |
| 脆弱性の修正 | 期限の前の版に出る修正の適用は、契約に入っているか。期限のあと、開発会社はどう扱うか |
| 動かす環境の更新 | OS・DB・クラウドの更新を、誰が持つか。自社が持つなら、いつ、誰が |
| 試験と切り替え | 上げたあとの動作の試験、本番の切り替え、止める時間は、作業に入っているか |
| 期限の知らせ | 部品の期限が近づいたとき、開発会社から知らせが来る約束があるか |
回答は、保守の範囲に入る・別見積になる・どちらか分からない、の3つに分けて表に残します。別見積になる作業は、期限の前に見積りをもらうと、予算を取る時間が残ります。どちらか分からないものは、契約の文面を開発会社と一緒に読みます。
この記事で確かめられなかったこと
.NET Framework(Windows 専用の古い .NET)、Java、Node.js、Ruby など、上の4つ以外の部品の期限。フレームワークやライブラリごとの期限。Linux の配布元が出す延長の修正(OS の配布元によって扱いが違うため)や、有料の延長サポートの内容。上げる作業の費用と日数(システムごとに違い、公式の情報はありません)。PHP と PostgreSQL が、期限のあとも動き続けるかについての公式の記述。
部品の表づくりと、保守契約の範囲の確認は、Aurant Technologies の古い業務システムの移行・保守の案内から、困っている1点だけでも相談できます。
サービス一覧
業務ツール・Microsoft 365/Google Workspace・AI活用・データ基盤・広告運用・会計ソフト・LINE運用・アクセス解析の8領域で、選定から構築・定着まで支援しています。課題に近い領域からご覧ください。
