.NET 8と.NET 9が2026年11月10日に同時サポート終了｜あなたの業務システムのバージョンを保守会社に聞いたことがありますか

結論：あなたの会社の業務システムが「無サポートで動き続ける」時限爆弾になり得ます

マイクロソフトの.NET および .NET Core の公式サポートポリシーによると、開発・実行基盤である.NET 8(長期サポート/LTS)と.NET 9(標準サポート/STS)は、いずれも2026年11月10日にサポート終了(EOL)を迎えます。.NET 8は2023年11月にLTSとして登場し3年間、.NET 9は2024年11月にSTSとして登場し(通常18か月のところ24か月に延長され)、結果として両者のサポート終了日が同じ2026年11月10日にそろいました。マイクロソフトが推奨する移行先は.NET 10(LTS)で、こちらは2028年11月までサポートされます。この件は2026年7月17日にPublickeyや窓の杜などが、マイクロソフトが開発者向けにアップグレードを促す警告表示を始めた文脈で報じています。

経営にとっての意味は、サーバーやOSの話ではありません。「自社が日々使っている業務システムそのものが、11月11日以降は脆弱性修正の来ない状態で動き続けるかもしれない」という話です。.NETは、受託開発で作られた業務システム・社内システム・Web APIの実行基盤として国内で広く使われています。多くのシステムは納品時点の.NET 8で作られ、そのまま何年も稼働します。ここで問題になるのが、アプリケーションはEOLを迎えても止まらないという性質です。11月10日を過ぎても画面は開き、処理は流れます。壊れるのではなく、セキュリティ修正だけが静かに止まる。だからこそ社内の誰も気づかないまま放置され、後から脆弱性を突かれるリスクだけが積み上がります。

そして最大の落とし穴は、責任の所在です。多くの中堅・中小企業では、業務システムを開発会社に作ってもらい、月額の保守契約を結んでいます。しかしその保守契約に「.NETのようなランタイム/フレームワークのEOL対応」が役務として含まれているケースは多くありません。含まれていなければ、開発会社は「聞かれていないので提案しない」、発注側は「保守しているから大丈夫だと思っていた」という認識のずれが生まれ、誰もアップグレードしないまま期日が過ぎます。本稿では、まず「あなたの業務システムの.NETバージョンを保守会社に聞いたことがありますか」という一点から始め、保守会社への確認事項、約4か月の逆算スケジュール、.NET 8から10への移行の勘所、そして保守契約に何を書き足すべきかまでを、発注側の経営者・実務決裁者の目線で整理します。

この記事を読むべき人

• 業務システムや社内システムを開発会社に作ってもらったが、それが何という技術基盤の何というバージョンで動いているかを把握していない経営者・役員
• 月額の保守契約を結んでいるが、その範囲に「フレームワークのバージョンアップ」が含まれているか自信がない発注責任者
• 情シスが不在または兼任で、EOL(サポート終了)の管理を誰が担っているのか曖昧なままになっている事業責任者
• 「動いているのだから変えなくていい」と考えてきたが、セキュリティ上それでよいのか判断材料が欲しい実務決裁者
• レガシーシステムの刷新を検討しており、今回のEOLをその入口として使えないか考えている経営層

事実整理：何が、いつ、どうなるのか

まず一次情報を整理します。以下はマイクロソフトの公式サポートポリシーに記載されているサポートカレンダーです。

ここで押さえておきたい点が3つあります。

第一に、LTSとSTSの2バージョンが同じ日にEOLを迎えるという珍しい状況です。通常は偶数版(LTS)と奇数版(STS)でサポート期間が異なりますが、今回は.NET 9のSTS期間が延長された結果、たまたま.NET 8と同じ11月10日に着地しました。つまり「うちは新しい方の.NET 9だから当分大丈夫」という思い込みは成り立ちません。8でも9でも、期日は同じです。

第二に、サポート終了は「動作停止」ではありません。マイクロソフトの説明によれば、EOL後もアプリケーション自体は動き続けますが、サービス更新・セキュリティ修正・技術サポートが提供されなくなります。以降に新たな脆弱性が見つかっても、公式の修正パッチは出ません。稼働はするが、守られない。この「動くのに危険」という状態が、後述するとおり判断を先送りさせる最大の要因になります。

第三に、**11月10日はマイクロソフトの月例パッチ提供日(Patch Tuesday)**にあたります。既知の重大な問題があれば、この日に.NET 8/9向けの最後の更新が出て、以降は打ち切られる、という区切りだと理解してください。

なお、本稿が扱う「.NET」は、Windows Update経由でPCに入る「.NET Framework(4.x系)」とは別物です。ここで話しているのは、業務システムやWeb APIの実行基盤として開発会社が採用する、クロスプラットフォームの「.NET(旧称.NET Core、5以降)」の系列です。両者は名前が紛らわしいため、保守会社に確認する際は「.NET Frameworkですか、それとも.NET 8や.NET 9のような番号のついた.NETですか」と明確に切り分けて聞くのが安全です。

独自視点①：受託開発された業務システムが「無サポート化」する構造

今回の件で経営者が本当に理解すべきなのは、EOLの日付そのものではなく、「なぜ多くの会社でアップグレードが実行されないのか」という構造です。ここを理解しないと、対策が個人の努力頼みになり、再発します。

典型的な流れはこうです。数年前、業務改善やDXの一環で、開発会社に基幹システムやWeb APIを作ってもらいました。納品時点で最新に近かった.NET 8が採用され、無事に本番稼働しました。その後は月額の保守契約に移り、障害対応や軽微な修正を開発会社に任せています。ここまでは順調です。問題は、時間の経過とともにランタイムのサポート期限が近づいても、誰もそれを能動的に監視していない点にあります。

なぜ監視されないのか。理由は主に3つです。ひとつめは、フレームワークのバージョンアップは通常の保守範囲外であることが多いという契約構造です(詳しくは独自視点④で扱います)。ふたつめは、EOLの通知が経営の意思決定者まで届かないことです。マイクロソフトの案内は開発者向けのツールや告知として流れるため、開発会社のエンジニアは知っていても、それが発注側の経営者や管理部門に「これは判断が必要な案件です」という形で上がってこない。みっつめは、「動いているから」という安心感です。前述のとおりEOL後もシステムは動くため、目に見える障害が起きるまで、誰も緊急性を感じません。

この3つが重なると、アップグレードを提案する人も、承認する人も、実行を管理する人も不在のまま、期日だけが過ぎていきます。悪意のある人は一人もいないのに、結果として「無サポートの業務システムが動き続ける」状態に着地する。これが今回の本質です。だからこそ最初の一歩は、技術的な作業ではなく、経営側からの一本の問いです。「うちの業務システムは、何の上で、どのバージョンで動いているのか」。この問いを発注側から投げること自体が、止まっていた歯車を回し始めます。

独自視点②：保守会社への確認事項リスト（そのまま送れる質問テンプレ）

「バージョンを把握していない」状態を抜け出す最短ルートは、保守会社(または開発会社)に事実を照会することです。以下の質問を、そのまま担当者に送ってください。技術に詳しくなくても、返ってきた答えの「歯切れの良さ」だけで、相手の管理レベルがかなり見えてきます。

1. 現行バージョンの確認：「当社の各システムは、.NETの何というバージョン(例：.NET 8、.NET 9、あるいは.NET Framework 4.x)で動いていますか。システムごとに一覧で教えてください。」
2. EOL認識の確認：「.NET 8と.NET 9が2026年11月10日にサポート終了になることは把握されていますか。当社の該当システムはどれですか。」
3. 移行計画の有無：「該当システムについて、.NET 10などサポート内バージョンへの移行計画はありますか。ある場合、いつ・どの範囲で・誰が実施する想定ですか。」
4. 費用の扱い：「その移行作業は、現在の保守契約の範囲に含まれますか。含まれない場合、別途見積もりの概算レンジと標準的な作業期間を教えてください。」
5. 互換性リスクの確認：「移行にあたり、依存している外部ライブラリやパッケージで.NET 10に未対応のものはありますか。動作検証はどの範囲・どの環境で行いますか。」
6. やらなかった場合の説明：「もし11月10日までに移行しない場合、当社が負うことになるリスク(脆弱性修正が止まること等)を、書面で説明してもらえますか。」

これらへの回答が、システムごとに具体的な日付とバージョンで1〜2営業日のうちに返ってくるなら、その保守会社はEOL管理を含めてよく面倒を見ています。一方で、「調べてみないと分からない」「そういう話は聞かれていなかった」「バージョンアップは別案件です」という反応が返ってくるなら、それは相手を責める材料ではなく、あなたの会社に「EOLを管理する仕組みが存在しない」ことが判明したサインです。次の契約更新でここを埋める、という経営判断につなげてください。

独自視点③：11月10日までの逆算スケジュール（残り約4か月）

本稿執筆時点(2026年7月22日)から、11月10日のEOLまでは約4か月弱です。移行を「間に合わせる」なら、この期間を逆算で押さえる必要があります。以下は発注側が進捗を管理するための目安です。個別システムの規模や複雑さで前後しますが、「いつまでに何が終わっていれば安全圏か」の物差しとして使ってください。

重要なのは、「11月10日に間に合わせる」ことが唯一の正解ではないという点です。規模の大きいシステムや、依存ライブラリの対応待ちがある場合、4か月では安全に移行しきれないこともあります。その場合の現実的な選択肢は、(1)期日を過ぎても稼働は続くという前提で、移行完了までの間はネットワーク面の防御を厚くして時間を買う、(2)このEOLを機に部分的なモダナイズや再構築へ舵を切る、といった判断です。いずれにせよ大切なのは、「判断していないので結果的に無サポートで放置している」状態と、「リスクを把握したうえで、いつ・何をやるかを決めている」状態を、経営として明確に分けることです。同じ「まだ移行していない」でも、この2つは経営リスクとしてまったくの別物です。

独自視点④：.NET 8から10への移行の勘所（発注側が知っておくべき論点）

移行作業の詳細は開発会社の仕事ですが、発注側が「丸投げにしない」ために知っておくべき論点があります。移行は単なるバージョン番号の書き換えではなく、互換性リスクを伴う「改修案件」です。雑にやれば事故になります。押さえるべきは次の4点です。

• メジャーバージョンアップは破壊的変更を伴い得る：.NETのメジャー更新では、非推奨だった機能の削除や、既定の挙動の変更が入ることがあります。多くのアプリは大きな修正なく移行できますが、「必ず無改修で済む」とは限りません。だからこそ、いきなり本番を上げず検証が必要になります。個別システムへの影響は、実際に検証してみないと断定できません。
• 依存している外部ライブラリの対応状況が律速になる：.NETのアプリは、認証・帳票・PDF生成・データベース接続などで多数の外部パッケージ(NuGetパッケージ)に依存しています。本体を.NET 10に上げても、依存ライブラリのどれか一つが未対応だと、そこがボトルネックになります。移行可否は「本体」ではなく「最も遅れている依存先」で決まる、と考えてください。
• 検証環境での動作確認が必須：本番のコピーを使い、移行後に主要機能・夜間バッチ・外部連携が正しく動くかを一通り確認してから本番に反映するのが定石です。「検証は省いて本番で」と言う相手には任せない方が賢明です。
• 切り戻し計画の書面化：移行に失敗したとき、誰の判断で・何分以内に・どの状態へ戻すかを、事前に文書で合意しておきます。これを渋るベンダーは、失敗時の責任範囲を曖昧にしたがっている可能性があります。

発注側としては、これらを自分で実施する必要はありません。ただし、開発会社の見積もりや作業計画に「依存ライブラリの調査」「検証環境での確認」「切り戻し計画」が項目として入っているかどうかは、見積書を見ればチェックできます。ここが抜けている見積もりは、安く見えても後から追加費用や事故につながりやすい、という目で読んでください。見積もりの妥当性を自社だけで判断しにくい場合の考え方は、後述の相談の項でも触れます。

独自視点⑤：保守契約に「EOL対応」を書き込むという契約論

今回の件は、11月10日を乗り切って終わりではありません。.NET 10も2028年11月にはEOLを迎えます。OSも、データベースも、各種ライブラリも、システムは常に何かしらのサポート期限に囲まれています。今回だけ慌てて対処しても、数年後に同じことが繰り返されるだけです。だからこそ、仕組みで再発を防ぐ発想が要ります。

その中核が保守契約の見直しです。多くの保守契約は「現状のシステムを現状のまま動かし続けること」を役務範囲としており、フレームワークやランタイムのメジャーバージョンアップは「別途見積もりの改修案件」として範囲外に置かれています。この構造自体が悪いわけではありませんが、そうであるなら、少なくとも次の点を契約または別紙に明記させるべきです。

• EOL監視と事前通知の責務：利用しているフレームワーク・ランタイム・主要ライブラリのサポート期限を保守会社側が把握し、期限の一定期間前(例：6〜12か月前)に、発注側へ通知・提案する義務を明記する。条項がなければ「誰の仕事でもない」状態が続きます。
• バージョンアップ作業の扱いの明文化：保守範囲内か別途見積もりか、別途なら概算レンジと標準リードタイムの目安を示す。
• 月次・年次報告への組み込み：定例報告に「利用技術のサポート期限一覧と、次に対応が必要になる時期」を含める。

そして発注側自身も、ベンダー任せにせず、A4一枚でよいので「利用技術のEOL台帳」を持つことをおすすめします。システム名・利用技術とバージョン・サポート終了日(公式URL付き)・対応方針・社内判断期限・責任者、の列を持つ簡単な表で十分です。目的は網羅ではなく、「期限の一定期間前に、必ず一度は経営判断の机に載せる」仕組みをつくることにあります。この台帳を持っている発注者は、保守会社から見ても「分かっている客」として扱われ、提案の質が変わります。保守や再構築の全体設計を相談したい場合は、システム開発・DX基盤の現状診断と再構築支援が入口になります。

独自視点⑥：EOLを「レガシー刷新の入口」として使う

今回のEOLは、コストのかかる面倒事に見えるかもしれません。しかし見方を変えれば、普段は先送りされがちな「システムの棚卸しと将来判断」を、外部要因が強制的に前に出してくれる好機でもあります。

.NET 8のまま何年も動いているシステムは、多くの場合、作った当時のまま手が入っていません。ビジネスの実態は変わっているのに、システムだけが古い前提のまま動き続けている、というずれが溜まっていることも珍しくありません。今回のバージョンアップ検討は、そのシステムを一度開いて中を確認する機会になります。そこで、「単に.NET 10へ上げるだけでよいのか」「この機会に構成を見直すべきか」「そもそもこの機能はまだ必要か」といった問いを立てられるかどうかが、EOL対応を単なる延命に終わらせるか、次の数年に効く投資に変えられるかの分かれ目です。

とりわけ、古い技術で作られていて年々保守が重くなっているシステムを抱えているなら、無理に現行構成のまま延命するより、この機に段階的なモダナイズを検討する方が総コストで見合うこともあります。並行稼働で安全に移行を進める考え方はレガシーシステム刷新の進め方で整理しています。逆に、AIの活用余地も含めて「この投資は妥当か」を第三者の目で先に見極めたい場合は、AI・システム投資の導入可否アセスメントのような、作る前の判断を助ける枠組みが役立ちます。EOLは終わりの合図ではなく、次に何を作り直すかを考える起点として使えます。

よくある質問(FAQ)

Q1. 自社の業務システムが.NET 8や.NET 9で動いているか、どう確認すればよいですか?

A. 最も確実なのは、開発・保守を担当している会社に「各システムが.NETの何というバージョンで動いているか」を一覧で照会することです。本稿の「独自視点②」にそのまま送れる質問を用意しています。社内に把握できる担当者がいない場合、この照会自体が第一歩になります。なお、番号のない「.NET Framework 4.x」は別系列で、今回のEOL対象ではありませんが、これはこれで別途サポート状況の確認が必要です。

Q2. 2026年11月11日になったら、システムは止まってしまいますか?

A. いいえ。マイクロソフトの説明によれば、EOL後もアプリケーション自体は動き続けます。止まるのではなく、セキュリティ修正や技術サポートが提供されなくなります。以降に新しい脆弱性が見つかっても公式の修正は出ないため、「動くけれど守られない」状態になる、という点が本質です。

Q3. .NET 10に上げれば、次はいつまで安心ですか?

A. .NET 10はLTS(長期サポート)で、2028年11月までサポートされます。約2年強の猶予がありますが、「上げて終わり」にせず、次の期限としてEOL台帳に記録し、2028年が来る前に次の判断をする前提で計画してください。

Q4. 4か月では移行が間に合いそうにありません。どうすればよいですか?

A. 「間に合わせる」だけが正解ではありません。稼働は続くという前提のもと、移行完了までの間はネットワーク防御を厚くして時間を買う、あるいはこの機会に部分的な再構築へ切り替える、といった選択肢があります。大切なのは、リスクを把握したうえで「いつ何をやるか」を経営として決めることです。無自覚な放置と、判断のうえでの先送りは、リスクの意味がまったく異なります。

Q5. 保守契約を結んでいるのに、なぜ保守会社から連絡が来なかったのですか?

A. 多くの保守契約は「現状維持での運用」を役務範囲としており、フレームワークのメジャーバージョンアップは範囲外の「別案件」であることが一般的だからです。契約にEOL監視・通知の条項がなければ、連絡が来ないこと自体は契約違反とは言いにくいのが実情です。責任追及よりも、次回更新でEOL対応を役務に明記する交渉材料として使う方が建設的です。

Q6. 移行費用が高い気がします。妥当かどうか、どう見分ければよいですか?

A. 見積書に「依存ライブラリの調査」「検証環境での動作確認」「切り戻し計画」といった項目が含まれているかを確認してください。安く見える見積もりでこれらが抜けている場合、後から追加費用や事故につながりやすい傾向があります。金額と作業範囲の妥当性を自社だけで判断しにくい場合は、ベンダーと利害関係のない第三者に確認を依頼する方法もあります。

GXOに相談すべきタイミング

この件は、.NETという技術の話に見えて、実際には「保守体制と発注側の統制」の話です。次のいずれかに当てはまるなら、開発会社・保守会社と利害関係のない第三者を一度入れる価値があります。

• 保守会社に「うちのシステムの.NETバージョンは?」と聞いても即答が返ってこない。あるいは、そもそも誰に聞けばよいのか分からない
• 移行の見積もりは出てきたが、金額・作業範囲・検証や切り戻しの計画が妥当かどうかを自社で判断できない
• .NETに限らず、自社システム全体のサポート期限を棚卸しした台帳が存在せず、次に何が期限を迎えるのか誰も把握していない
• 今回を機に、延命ではなく段階的なモダナイズや再構築を検討したいが、どこから手をつけるべきか整理できていない

GXOは開発会社ですが、この種の相談では、いきなり作り替えを勧めるのではなく、まず「今の構成と契約のどこにリスクと無駄があるか」の整理から入ります。既存システムの現状把握と保守・EOLの棚卸し、再構築の要否判断はシステム開発・DX基盤の現状診断と再構築支援で、古い技術で作られたシステムを安全に刷新する進め方はレガシーシステム刷新で対応しています。AI活用も含めて投資の優先度を第三者の目で見極めたい場合はAI・システム投資の導入可否アセスメントが起点になります。

11月10日の期日が来てから慌てるのではなく、7〜8月のうちに「自社のどのシステムが該当するか」の一覧化と方針決定まで済ませておくのが理想です。保守会社への確認結果を見ても移行の要否や優先順位に迷うときは、お問い合わせから現在お使いのシステムの状況をお聞かせください。どのアプリを11月10日までに動かし、どれは計画的に後回しにできるか——その仕分けの整理からでも、意思決定は前に進みます。

参考文献

• マイクロソフト公式「.NET および .NET Core の公式サポートポリシー」
• Publickey「.NET 8と.NET 9は今年の11月でサポート終了、マイクロソフトが警告」(2026年7月17日)
• 窓の杜「『.NET 8』と『.NET 9』のサポートが終了へ 〜『.NET 10』へのアップグレードを」