「業務システムは問題なく動いているのに、開発会社から『来年11月で土台のサポートが切れるので、更新の予算を確保してください』と言われました。動いているものに、なぜお金をかけて手を入れる必要があるのか、正直ピンと来ていません」——業務システムを外注して数年運用している会社の担当者から、こんな相談を受けました。これは、とても自然な疑問です。そして、この「動いているのになぜ？」に納得できないまま先送りすると、あとで一番困るのは発注した側です。
マイクロソフトは2026年、多くの業務システムの土台に使われている「.NET 8」と「.NET 9」のサポートを、2026年11月10日で終了すると案内しました。ここで大事なのは、サポート終了＝システムが止まる、ではないことです。動きはします。にもかかわらず備えが必要な理由と、その進め方を本記事で整理します。
サポート終了（EOL）とは何が終わるのか
システムは、目に見える「アプリ」の部分だけで動いているのではありません。その下には、土台となる部品（プラットフォームやライブラリ）があり、アプリはその上で動いています。サポート終了（EOL: End of Life）とは、この土台の提供元が「もうこの版の面倒は見ません」と宣言することです。
終わるのは、主に次の三つです。動作そのものは終わりません。
| 終わるもの | 意味 |
|---|---|
| セキュリティ更新 | 新たな弱点（脆弱性）が見つかっても、修正が提供されなくなる |
| 不具合の修正 | 問題が起きても、土台側の直しは出てこない |
| 公式サポート | 困ったときに提供元へ問い合わせる窓口がなくなる |
このうち一番こわいのはセキュリティ更新の停止です。システムは作った瞬間から古くなり始め、時間とともに新しい弱点が見つかります。サポートが続いていれば、その都度ふさぐ更新が届きます。EOLを迎えると、この更新が止まる。動いてはいるが、穴が見つかっても誰もふさがない状態——これがEOL後のシステムの正体です。放置したシステムがやがて危険になる構造は技術的負債を経営リスクとして捉える記事でも扱っています。
「動いているのになぜ」への答え
冒頭の疑問に、正面から答えます。動いているのに手を入れるのは、「今困っていないから」ではなく「これから困らないため」です。EOL後のシステムは、車でいえば「走るけれど、リコール対象の欠陥が見つかっても部品が供給されない車」に近い状態です。ぶつかるまでは走れます。ですが、いざ問題が起きたときの守りが、時間とともに薄くなっていきます。
しかも、放置のコストは時間とともに膨らみます。サポートが切れて何年も塩漬けにしたシステムは、いざ更新しようとしたときに「土台が古すぎて、一段ずつ上げないと新しい版に届かない」状態になりがちです。期限内に計画的に上げれば小さな更新で済んだものが、先送りするほど大規模な作り直しに化けていきます。土台を定期的に上げ続ける発想は土台の年次更新と保守の記事でも整理しています。
いつ・どう備えるか
.NET のケースでは、後継である新しい長期サポート版（.NET 10、2028年11月までサポート）へ上げるのが基本方針になります。ただし、発注側がまず必要なのは技術の詳細ではなく、段取りです。次の順で進めると無理がありません。
- 棚卸し: 自社のどのシステムが、いつサポート終了を迎えるのかを一覧にする（.NET に限らず、土台となる部品はすべて期限を持つ）
- 優先順位づけ: 外部に公開しているもの・機微な情報を扱うものから先に手を入れる
- 移行計画: 期限から逆算し、テストの期間まで含めて予算とスケジュールを確保する
- 移行: 計画に沿って土台を上げ、動作を確認する
この棚卸しを一度やっておくと、「気づいたら期限が過ぎていた」という事故がなくなります。移行そのものは、近年はAIの支援で以前より進めやすくなっており、大規模な移行の考え方はAI支援による移行の記事で扱っています。
事例: 期限の3か月前に相談が来た会社
具体例を挙げます。業務システムを外注運用している会社（社名は伏せます）から、EOLの案内を受け取ったものの意味が分からず、期限のおよそ3か月前に相談が来ました。幸い、システムの規模がそれほど大きくなく、土台も一世代前だったため、期限内に新しい長期サポート版へ上げることができました。
このケースで効いたのは、慌てずにまず棚卸しをしたことです。「サポートが切れる部品はどれか」「そのうち外部に公開しているものはどれか」を一覧にし、リスクの高いものから順に手を入れました。担当者が驚いていたのは、先送りしていたら次の更新はもっと大変になっていたという点でした。土台が二世代・三世代と離れるほど、一気に上げるのは難しくなります。もし相談があと一年遅れていたら、小さな更新では済まなかったはずです。「動いているうちに、計画的に」が、結局いちばん安くつきます。納品後の保守・運用をどこまで契約に含めるかは保守・運用契約で発注者が見るべき点の記事も参考になります。
まず「期限の棚卸し」から始める
サポート終了は、ある日突然システムが止まる話ではありません。ですが、放っておくほど守りが薄くなり、更新の難易度と費用が膨らんでいく——静かに効いてくるタイプのリスクです。着手するなら、いきなり移行を決める前に、まず一つだけ。自社のシステムの土台が、いつサポート終了を迎えるのかを棚卸しすることです。これがあるだけで、慌てての対応も、期限切れの放置も避けられます。
自社のシステムのサポート期限が分からない、EOLの案内が来たが何をすべきか判断できない、期限に間に合うよう計画的に移行したい——そうしたお悩みがあれば、グリームハブのシステム開発・保守の無料相談からお気軽にご相談ください。土台の棚卸しから、優先順位づけ、期限から逆算した移行計画まで、御社のシステムにあわせてご一緒します。
