導入済みOSSのサポート終了が中小企業の基幹システムに与えるリスクと更新判断のタイミング

「うちのシステムに使っているOSSのサポートが終わる、と業者に言われたけど、何が問題なの？」

業務のデジタル化が進むにつれ、受発注管理・勤怠管理・会計連携など、多くの中小企業の基幹システムにOSS（オープンソースソフトウェア）が組み込まれています。導入当初はコストの安さから選ばれたOSSですが、時間の経過とともに「サポート終了（EOL）」という見えないリスクを抱えるようになります。

この記事では、OSSのサポート終了が中小企業の基幹システムに与える具体的なリスクと、更新・移行を判断する正しいタイミングを解説します。IT担当者がいない、あるいは兼任状態の中小企業経営者・情シス兼任担当者が自社に必要な判断を下せるよう、経営目線で整理しました。

OSSのEOL（サポート終了）とは何か——中小企業に忍び寄る「静かなリスク」

OSSとはLinux、Apache、MySQL、PostgreSQL、PHP、Pythonのように、ソースコードが公開され誰でも無償で利用・改変できるソフトウェアの総称です。中小企業の業務システムでは、WebサーバーやデータベースにOSSが採用されているケースが大半を占めます。コスト面での優位性が高く、適切に管理すれば長期にわたって安定稼働します。

EOL（End of Life）とは、そのOSSの特定バージョンに対してコミュニティや開発元がセキュリティパッチの提供・バグ修正・公式サポートを打ち切る期日です。EOLを過ぎると、新たに発見された脆弱性に対して公式パッチが提供されなくなります。攻撃者が「穴を見つけても誰も塞がない」状態が永続します。

代表的なOSSのEOL事例を挙げると、PHP 7.4系は2022年11月にEOLを迎えました。CentOS 7は2024年6月にEOLとなり、MySQL 5.7も2023年10月にサポートを終了しています。Ubuntu 18.04 LTSは2023年4月にEOL、Ubuntu 20.04 LTSは2025年4月に標準サポートが終了しています。これらを組み合わせた「LAMP環境」（Linux・Apache・MySQL・PHP）で動く受発注システムや会員管理システムが、今も多くの中小企業で現役稼働しているのが実情です。

大企業では専任のIT部門が常時バージョンを追跡し、EOL到来の半年前から移行プロジェクトを開始するのが標準的な運用です。一方、情シス兼任担当者が1人で業務システムを抱える中小企業では、EOL日が過ぎた事実すら把握していないケースが少なくありません。「システムが動いているから大丈夫」という感覚が、静かにリスクを積み上げていきます。

EOLを過ぎたシステムの怖いところは、即座に障害が起きないことです。業務は今日も継続します。しかしその裏で脆弱性のリストが蓄積され続け、攻撃者にとっての「攻め口」が増え続けています。あるとき突然ランサムウェアに感染し、基幹システムが完全停止する——こういった事態の起点になるのが「サポートが切れたまま放置されたOSS」です。IT担当を兼任している管理部長や、毎日の業務に追われる2代目経営者が「まだ使えている」と安心している間に、リスクは複利で膨らんでいます。

EOLが中小企業の基幹システムに与える3つの具体的なリスク

1. 未パッチの脆弱性を突かれるセキュリティリスク

EOL後は、発見された脆弱性に対して公式パッチが提供されません。攻撃者はEOLを迎えたOSSのバージョンを特定し、既知の脆弱性を自動スキャンして侵入を試みます。たとえば、PHP 7.4に発見された脆弱性は2022年11月以降は公式修正がありません。EOL後に発見された脆弱性は「永久に未修正」として残り続けます。

中小企業の基幹システムがランサムウェアに感染した場合、受発注データ・顧客情報・財務データが暗号化されて業務が完全停止します。復旧に要する時間は数日から数週間、費用は数百万円に達するケースもあります。「うちは狙われない」は通用しません。攻撃者はIPアドレス帯を自動スキャンし、脆弱なシステムを無差別に探し出します。製造業であれば取引先の大手から「セキュリティインシデントが発生した」と通知することになり、取引関係にも影響が出ます。

2. コンプライアンス違反リスク

取引先の大手企業がサプライチェーンセキュリティの観点から「取引先のIT環境の安全性確認」を求めるケースが増えています（2026年8月時点）。セキュリティ監査やISMS取得を求められた場合、EOL済みOSSを使った基幹システムは「不適合」として指摘される可能性があります。

また、個人情報保護法の観点からも、既知の脆弱性を持つシステムで個人情報を管理することは「適切な安全管理措置」を欠くと判断されるリスクがあります。情報漏洩が発生した場合、「EOL済みOSSを使い続けていた」という事実は過失の証拠として使われます。対外的な説明責任を果たせない状況が生じます。

3. 技術的負債の蓄積によって将来の移行コストが増大するリスク

EOL済みOSSを使い続けるほど、そのシステムをサポートできるエンジニアが市場から減っていきます。PHP 7.4の修正を依頼できるエンジニアの数は年々減少しており、対応できるIT会社の数も限られています。需要と供給の観点から、古いバージョンへの対応費用は高騰していきます。

さらに、EOL済みOSSをベースに業務改修を積み重ねるほど、新しいバージョンへの移行コストが増大します。3年後に「やっぱり更新しよう」と判断したとき、移行に必要な改修費用が当初の3倍になっていたという事例は珍しくありません。先送りが「コスト削減」ではなく「コストの先送りと増大」になっているのが実態です。Before（早期対応）：移行費用70万円 / After（3年後対応）：移行費用210万円＋リスク対応コスト——この差分を経営判断に織り込む必要があります。

「今は動いているから大丈夫」——更新判断を先送りする中小企業の3つの誤解

誤解1：「サポート終了＝即故障ではない」から問題ない

EOLを迎えても、システムはすぐには止まりません。この「すぐには止まらない」という事実が、危機感を薄める最大の要因です。しかし、EOLは「今日から攻撃し放題」のフラグが立つ瞬間です。攻撃者がEOL日をウォッチしているのは誇張でなく、EOL直後からその製品の脆弱性スキャンが急増するという報告が複数の研究機関から出ています。

「問題ない」ではなく「まだ被害が出ていない」の状態であることを正確に認識する必要があります。火災報知器が鳴っていないからといって、火事のリスクがゼロとは言えないのと同じ理屈です。

誤解2：「更新はベンダーがやってくれる」

システムを外注で作った場合、多くの中小企業は「何かあれば業者が対応してくれる」と思っています。しかし、EOLへの対応は通常、開発当初の契約範囲に含まれていません。バージョンアップや移行は別途見積もりが必要な「追加作業」です。業者に相談しないまま放置すると、業者も把握しながら黙っているケースもあります。

能動的に「今のシステムに使われているOSSのEOL状況を確認してください」と業者に依頼することが、経営者・情シス兼任担当者の仕事です。主体的に動かない限り、リスクは発覚しません。

誤解3：「更新コストが高いので費用対効果が合わない」

EOL対応コストを「使えているのに費用が発生する無駄な出費」と捉える経営者は多いです。しかし、正しい比較は「更新コスト」対「更新しなかった場合の期待被害額」です。

たとえば、PHP 7.4からPHP 8.2への移行費用が80万円だとします。一方、ランサムウェア被害が発生した場合の業務停止損失・復旧費用・顧客補償・社会的信用の毀損を合計すると、製造業では数百万円から数千万円規模になることがあります。リスクを金額換算して比較することが、正しいIT投資の判断軸です。

更新・移行を判断する正しいタイミングと手順

ステップ1：自社システムに使われているOSSとバージョンを棚卸しする

最初にやることは「棚卸し」です。基幹システムを作った業者に「使用しているOSSとバージョンの一覧」を依頼します。受発注システム・勤怠システム・会計連携ツールそれぞれについて、OS・Webサーバー・データベース・言語（PHP・Pythonなど）のバージョンを書面で取得します。

業者が把握していない場合、または業者との連絡が取れない場合は、別のIT会社に「現状調査（技術監査）」を依頼することを検討します。費用は5万円～20万円程度（2026年8月時点）で、EOLリスクの全体像をレポートにまとめてもらえます。

ステップ2：EOL日と業務への影響を2軸で評価する

各OSSのEOL日を確認し、次の2軸で優先度を評価します。

・リスク軸：インターネットに公開されているか（外部攻撃の入口になりやすい）、個人情報や機密情報を扱っているか
・業務影響軸：そのシステムが停止したとき、業務が何日・何時間で止まるか。代替手段はあるか

両軸ともに高い（外部公開かつ基幹業務を担う）システムから優先的に対応します。社内のみで使う補助ツールは優先度を下げて構いません。

ステップ3：EOL日の「18ヶ月前」を判断の起点にする

EOL対応プロジェクトには、要件整理・業者選定・見積もり・実装・テスト・本番移行のサイクルが必要で、一般的に6ヶ月～1年の期間がかかります。EOLの1年前には具体的な移行計画を開始し、18ヶ月前には選択肢の検討を始めるのが現実的なタイムラインです。

「EOLまで2年ある」という状況でも、今から棚卸しと選択肢の検討を始めることで、余裕を持った意思決定ができます。

比較表：延命 vs バージョン更新 vs システム乗り換え

EOL対応には大きく3つの選択肢があります。それぞれの特徴と適した場面を整理します。

選択肢	内容	コスト目安	主なリスク	向いている場面
延命（有償サポート）	RHEL・Ubuntu Proなど商用ディストリビューションの延長サポートを契約し、EOL後もパッチを受け取る	年間20万円～80万円（規模による）	コストが継続発生。対象外のOSSには使えない	移行プロジェクトに準備時間が必要な場合の2年以内の「つなぎ」
バージョン更新	同一OSSのより新しいバージョン（例：PHP 7.4→8.2）に移行する	30万円～150万円（システムの複雑さによる）	互換性の問題でアプリケーション修正が必要になる場合がある	現行システムの業務要件が満たされており、あと3年～5年使う予定
システム乗り換え	クラウドサービスや最新の業務システムパッケージへ全面移行する	100万円～500万円以上	初期コストと移行期間が大きい。業務フロー変更が必要な場合も	現行システムが10年以上経過し機能面でも限界が近い

選択の判断軸として、現行システムの稼働年数と今後の使用予定期間で考えます。

・稼働5年未満・あと3年以上使う予定：バージョン更新がコスト効率で優位
・稼働5年以上・EOLまで1年以内：延命（有償サポート）で時間を確保し、乗り換えを並行計画
・稼働10年以上・機能限界も近い：システム乗り換えを優先し、IT導入補助金の活用も検討

なお、延命（有償サポート）はOSレベルであれば有効ですが、アプリケーション言語（PHP・Pythonなど）には商用延長サポートが存在しないものも多く、その場合はバージョン更新かシステム乗り換えの2択です。

よくある質問

Q1. EOLを迎えたOSSをそのまま使い続けると、必ず攻撃されますか？

必ず攻撃されるわけではありませんが、攻撃される確率は時間とともに上がります。EOL後は脆弱性が蓄積され、攻撃者にとっての既知の「穴」が増え続けます。特にインターネットに直接公開されているシステム（受発注ポータル・顧客向けWebアプリなど）は、自動スキャンツールで定期的に探索されているためリスクは高いです。社内ネットワークのみで使っているシステムも、VPN経由や内部からの横展開でリスクが生じます。

Q2. 更新コストが今すぐ捻出できない場合、何から始めればよいですか？

まずは「棚卸し」だけでも進めます。コストをかけずにできる第一歩は、現在使っているシステムのOSSバージョンとEOL日を業者に確認することです。次に、最も危険なシステム（外部公開・個人情報管理）を1つ特定して優先対応します。全システムを一度に更新する必要はなく、リスクの高いものから順番に対応します。IT導入補助金や小規模事業者持続化補助金が活用できる場合もあります（2026年8月時点の要件をご確認ください）。

Q3. システムを作ったベンダーが廃業・連絡不通になっています。どうすれば？

まず別のIT会社に「技術調査」を依頼し、システムの構成・OSSバージョン・EOL状況を調べてもらいます。そのうえで「引き継ぎ可能か、システム乗り換えが現実的か」を判断します。古いシステムほど引き継ぎコストが高くなるため、この機会にシステム乗り換えを検討するケースも多いです。まずは現状把握から始めることが先決です。

Q4. 「EOLまで2年ある」場合は今から動く必要がありますか？

2年あれば余裕があるように見えますが、移行プロジェクトには一般的に6ヶ月～1年の準備期間が必要です。要件整理・業者選定・見積もり・実装・テスト・本番移行のサイクルを考えると、EOLの1年前には具体的な検討を開始するのが理想です。2年前の時点で「何に使われているか」の棚卸しを済ませておくことで、余裕を持った計画が立てられます。早すぎる準備はありません。

更新判断前チェックリストとまとめ

以下のチェックリストで自社の状況を確認してください。未チェックの項目が多いほど、早急な棚卸しが必要なサインです。

・OSSバージョンの棚卸し：基幹システムに使用されているOSSとバージョンを書面で把握しているか
・EOL日の確認：各OSSのEOL日（サポート終了日）を確認し、18ヶ月以内に迎えるものをリストアップしているか
・外部公開システムの特定：インターネットから直接アクセスできるシステムを特定し、優先対応対象として管理しているか
・業者への確認依頼：システムを作った業者に「EOL対応の方針と費用見積もり」を依頼しているか
・バックアップ体制の確認：EOL対応作業に入る前に、現行システムのデータバックアップが取得できる体制になっているか
・予算・補助金の確認：更新・移行に必要な予算を経営判断で確保する準備ができているか、または補助金の活用を検討しているか
・移行後の保守体制：更新・乗り換え後のシステムを誰が継続的に保守するか決まっているか

OSSのサポート終了（EOL）は「気づいたときには手遅れ」になりやすいリスクです。EOL後も業務は動き続けるため、経営者や情シス兼任担当者の危機感は薄れがちです。しかし、被害が出てからの復旧コストは事前の更新コストの数倍になることが珍しくありません。リスクを「費用」として見るのではなく、「放置した場合の期待損失」と比較して判断することが、正しいIT投資の考え方です。

今すぐできることは「棚卸し」です。システムを作った業者に連絡し、「使用しているOSSのバージョンとEOL日を教えてください」と一文送ることが、リスク管理の第一歩です。更新・移行の判断は、棚卸しの結果が出てから業者と相談して進めます。

株式会社イーネットマーキュリーでは、中小企業の基幹システムにおけるOSSのEOL状況の調査・更新計画の立案・移行支援のご相談を承っています。「何から始めればよいかわからない」という段階でも、お気軽にお問い合わせください。

▶ 無料相談・お問い合わせはこちら