保守会社が撤退したら何から始めるか——サポート切れOSで動く公的機関のWebシステムを、単年度予算で刷新する順番

あなたの会社の業務システムは、どこの誰が面倒を見ているでしょうか。社内のたった1人でしょうか。それとも、付き合いの長い1社の開発会社でしょうか。もしその相手が、ある日「もう続けられません」と手を引いたら——明日から誰が、そのシステムを直すのでしょうか。

これは、めったに起きない不運の話ではありません。帝国データバンクによれば、ソフトウェア業の倒産は2024年度に220件と、前年度の約1.4倍に増えました。過去10年で初めて年200件を超えています。しかも倒産した会社の8割超が、従業員10人未満の小さな会社です（出典は文末）。あなたのシステムを黙って支えている「あの会社」も、その規模かもしれません。

この記事で取り上げるのは、ある公的機関のシステムです。ですが「保守してくれる会社がいなくなる」という出来事そのものは、規模も業種も選びません。むしろ、頼れる先が1社しかない中小企業ほど、より静かに、より深刻に起こります。

本記事は、筆者が実際に相談を受けている事例をもとにしています。守秘のため、機関やシステムの題材は特定につながらないよう変更・再構成しています（分野名・機関の種別は伏せ、「公的機関が運営する専門分野の研究データベース」として一般化しています）。ベンダーが撤退して依頼が筆者に戻ってきた経緯、筆者がこれまで行ってきた改修、そして先方から「クラウド化を検討したい」と相談を受けている段階までは、すべて事実です。第5章以降のモダナイゼーションの計画・構成は、筆者からの提案（誌上での検討）であり、まだ何も決まっていません。

この記事でわかること

モダナイゼーション（老朽化したシステムの近代化）には6つの種類があること。それぞれが、経営者にとって何を意味するのか
保守してくれる会社が撤退した後、何から手を付けるべきか——「全部やる」でも「何もしない」でもない一歩目
単年度予算と、公的機関ならではのセキュリティ制約の中で、筆者がどこから刷新すべきと考えたか（3案の比較つき）

1. 相談が戻ってきた現場——ある公的機関の研究データベース

その相談は、5年ぶりに筆者のところへ戻ってきました。

対象は、ある公的機関が運営しているWebシステムです。専門分野の研究データを集めたデータベースを、インターネット上で一般に公開しています。全国の研究者や企業が、研究や製品開発のためにこのデータベースを日々参照しています。地味ですが、その分野に関わる人にとっては「まず見に行く場所」になっている、公共のインフラのような存在です。

項目	内容
運営	公的機関（専門分野の研究データを一般公開）
利用者	全国の研究者・企業。継続的に使う企業だけで数十社
協力企業	データベースの更新に協力する企業も数社
システム構成	「登録システム」と「公開システム」の2系統。画面約20・機能約30
保守体制	従来は外部ベンダー1社に委託。現在は不在（後述）

もう少し中身を分けて説明します。このシステムは、大きく2つの顔を持っています。

登録システム: データ更新に協力する数社の企業が、研究データを登録・更新するための、内側向けの仕組み
公開システム: 全国の研究者・企業が、そのデータを検索・参照するための、外側向けの仕組み

筆者とこのシステムの付き合いは、実は今回が初めてではありません。7年前から5年前までの2年間、筆者がこのシステムの改修を担当していました。その後、5年前の入札で地元のベンダーが落札し、保守と改修の一切がそちらへ移りました。公共の仕事ではよくある、正当な引き継ぎです。

ところが、そのベンダーが撤退しました。保守を引き受ける会社が、いなくなってしまったのです。そして相談は、かつて中身を知っていた筆者のもとへ戻ってきました。

2. 発注元の悩み——「直せる人」がいなくなった

システムそのものは、今も止まらず動いています。研究者は毎日データを見に来ますし、協力企業も登録を続けています。派手な障害が起きているわけではありません。

問題は、何かあったときに直せる人がいないことです。

保守ベンダーが撤退した瞬間、このシステムは「動いてはいるが、誰も手を入れられない」状態になりました。制度が変われば画面の一部を直す必要が出ます。利用者から不具合の報告が来れば、原因を探して直さなければなりません。その「直す手」が、消えてしまったのです。

筆者はこれまで、相談ベースで何度か改修を引き受けてきました。古い仕組みで書かれたプログラムを読み解き、必要な手当てをする。応急処置としては回っています。ですが、前回の対応のとき、先方からこう相談を受けました。

「次回は、この古い仕組みそのものを刷新したいと考えています。クラウド化も検討したい」

言い換えれば、「その場しのぎの修理を続けるのではなく、そもそも直せる人がいる状態に作り替えたい」ということです。これは、保守が消えた会社が最後にたどり着く、まっとうな願いです。ただし、公的機関には公的機関の事情があり、「じゃあ全部作り直しましょう」とは簡単にいきません。その事情は、第4章と第5章で具体的に見ていきます。

3. 現状システム——2台の古いサーバの上で、20の画面が動いている

「刷新する」を考える前に、まず「今どう動いているのか」を押さえます。下の図は、2系統のシステムがデータベースを介してどうつながっているかを示したものです。

数社の協力企業がデータを登録し、職員が確認して公開する。公開された情報を、全国の数十社が毎日見に来る。整理すればとても素直な流れです。

問題は、これを動かしている「機器と道具の側」にあります。下の図が、システムを支える現在の構成です。

技術の名前が並びますが、経営者の方は読み流して構いません。要点は3つだけです。

プログラムは Perl CGI（Common Gateway Interface＝Webサーバが古くからプログラムを動かしてきた仕組み）という、四半世紀前によく使われた方式で書かれている
それを動かす土台の基本ソフトが RHEL（Red Hat Enterprise Linux＝レッドハット社の企業向けLinux。OS＝Operating System、機器を動かす土台のソフト）で、すでにサポートが切れている
データは MySQL（データベースソフト）に入っており、こちらは別の1台に載っているが、同じく老朽化した基盤の上で動いている（つまりWeb用とデータベース用、古いサーバ2台でこの公共サービス全体を支えている）

例えるなら、建物はまだ建っているのに、雨漏りのとき来てくれる大工さんだけがいなくなった家です。晴れている日には、何も問題は見えません。次の雨が降るまでは。

4. 経営リスク——「古いから危ない」ではなく「直せないから危ない」

老朽システムのリスクというと、「古いといつか壊れる」という漠然とした不安で語られがちです。ですがこのケースの本質は、もっとはっきりしています。直せる人がいないまま、部品のサポートも切れている——この2つが重なっていることです。相談を受けた筆者が最初に整理したのが、下の表です。

リスク	いま起きていること	3年後に予想されること	起きたときの影響
保守の担い手の不在	ベンダー撤退。直せるのは相談ベースの筆者のみ	相談先も体調・都合で対応不能になりうる	制度改正や不具合に誰も対応できず、公開の停止もありうる
基本ソフトのサポート切れ	RHEL（土台のOS）のサポートが終了済み	弱点が見つかっても修正が出ない	外部からの侵入・情報漏えいのリスクが年々上昇
Perl技術者の減少	新しく学ぶ人が減り、扱える人が細っている	直せる会社を探すこと自体が難しくなる	保守費が高騰、または引き受け手ゼロ
老朽サーバ2台への依存	Web用・データベース用とも古いサーバで、予備機なし	部品・後継機の入手が困難に	どちらか1台が故障しただけで全体が止まり、復旧の当てがない

とくに2行目の重みを、少し具体的に補足します。RHELのように広く使われている基本ソフトでも、メーカーの通常保守には期限があります。たとえばRHEL7は2024年6月に通常の保守が終了しました（出典は文末）。保守が終わったOSは、新しい弱点（セキュリティの穴）が見つかっても、原則として修正プログラムが提供されません。以降は有償の延命サービスでしか守れず、それも永遠には続きません。「動いている」と「安全に使い続けられる」は、まったく別のことなのです。

このシステムは公的機関が全国に公開しているものですから、この「安全に使い続けられるか」は、一民間企業の話より重く響きます。数十社が業務で参照しているデータが止まれば、その先の研究や製品開発にも影響が及びます。これは1つのサーバの話ではなく、BCP（Business Continuity Plan＝事業継続計画）、つまり「非常時にも役割を果たし続けられるか」の問題です。

「では、どれくらいの割合の会社がサポート切れのまま使い続けているのか」を示す直接の統計は、残念ながら見当たりません。参考として、IPA（Information-technology Promotion Agency＝情報処理推進機構）の調査では、中小企業でセキュリティの修正プログラムをきちんと適用できている企業は31.3%にとどまるという結果があります（出典は文末）。これは「サポート切れOSの継続利用率」そのものではありませんが、土台の安全対策が後回しになりがちな実態を示す代理の目安としては読み取れます。

人の側の見通しも厳しめです。経済産業省の試算では、IT人材は2030年に最大79万人不足するとされています（出典と鮮度注記は文末）。「撤退したベンダーの代わりを探せばいい」は、年々難しくなっていく——これが現実の方向感です。

ここまでが、筆者が見聞きしている実情の整理です。ここから先は、筆者からの提案になります。最初にやったのは、「刷新（モダナイゼーション）とは、そもそも何を指すのか」を、経営者にも分かる言葉に整理し直すことでした。

5. AIへ相談——モダナイゼーションの6つの種類と、「どこから手を付けるか」

「クラウド化を検討したい」という言葉は、実はかなり幅の広い言葉です。刷新（モダナイゼーション）と一口に言っても、直す場所によって中身がまるで違います。まずはその地図を広げるところから始めました。

老朽システムの近代化は、大きく6つの種類に分けられます。今後この記事以外でも繰り返し出てくる用語なので、経営者向けのたとえを添えて、一度きちんと整理しておきます。

種類	何を新しくするか	経営者にとっての意味（たとえ）
①UI（User Interface＝利用者が触れる画面）の刷新	画面。Web化・スマホ対応	古い専用画面を、誰でも使えるブラウザ画面へ。お店の「入口」を建て替える
②インフラ（動かす土台）の刷新	サーバ。クラウド化・コンテナ化	自前のサーバ管理をやめ、点検付きの土地を借りる。持ち家から管理付き物件へ引っ越す
③アプリケーション（プログラム本体）の刷新	中身。言語の書き換え・API化	古い言語の本体を作り替え、つなぎ口を作る。建物の躯体そのものを作り直す
④プラットフォーム（土台の部品）の刷新	部品。既製の共有ソフトへ乗せ替え	自作をやめ、世の中の出来合いの仕組みを使う。自作設備を市販品に替える
⑤開発・運用の刷新	作り方・回し方の自動化	手作業の更新・確認を自動化する。工事を手作業から機械化へ
⑥データ基盤の刷新	データの置き場と活かし方	データを整え、分析や連携に使える形へ。倉庫を整理して中身を見える化

補足すると、②に出てくるコンテナ化は「アプリを箱に詰めてどこでも同じように動かす技術」、③のAPI（Application Programming Interface＝システム同士をつなぐ窓口）化は「他のシステムとデータをやり取りできる口を作ること」です。⑤には、更新作業を自動化するCI/CD（Continuous Integration/Continuous Delivery＝継続的な統合・配信）や、基盤の構成を手作業でなく設計図（コード）で管理するIaC（Infrastructure as Code）といった手法が含まれます。名前は覚えなくて大丈夫です。大事なのは「刷新には6つの入口があり、全部を一度にやる必要はない」という一点です。

この地図を広げたうえで、AIアシスタントのClaudeに相談してみました。これは筆者が実際に行ったやりとりです。

相談: 「公的機関が運営する研究データベースのWebシステムがあります。Perl CGI＋Apache＋MySQLで、土台のOSはサポート切れ。保守ベンダーが撤退しました。単年度予算で、今年度内に完了できる範囲で刷新したい。6分類のうち、どこから手を付けるべきですか？」

Claudeの最初の答えは、教科書としては満点でした。要約するとこうです。

Claudeの初回回答（要約）: 理想的には、まず②インフラをクラウドへ移し、その際にプログラムをコンテナ化してマイクロサービス（機能ごとに小さく分ける方式）に再構成し、⑤のCI/CDパイプラインを整えてDevOps（開発と運用を一体で回す進め方）の体制を作るとよいでしょう。あわせて①UIをWeb標準に刷新し、③でPerlを現代的な言語へ書き換えれば、保守できる技術者の裾野も広がります。

正しい。正しいのですが、この会社には重すぎます。 ここで鵜呑みにせず、筆者から3つ、現場の条件を突きつけました。

指摘1（予算）: 「予算は単年度です。今年度内に完了・検収できない計画は、そもそも発注になりません。マイクロサービス化とDevOps体制の構築は、単年度では終わりません。」

指摘2（保守人員）: 「そもそも保守できる会社が撤退したのが出発点です。マイクロサービスに細かく分ければ分けるほど、運用は複雑になり、面倒を見られる人がさらに減ります。派手にするほど、次の撤退リスクが上がります。」

指摘3（制約）: 「公的機関なので、使うクラウドにはISMAP（Information system Security Management and Assessment Program＝政府情報システムのためのセキュリティ評価制度）のポリシーが関わってきます。選べるサービスは限られます。そして、Perlのソース全体を新しい言語へ移すことは、今回はしません。」

この3点でClaudeの初案を削り直した結果、選択肢は次の3案に整理されました。

案	内容	費用の目安【仮定】	期間	単年度で完了できるか	主なリスク
A. 全面再構築	Perlを新言語へ書き換え、UIも刷新し、クラウド上で作り直す	総額で数千万円規模	複数年	✕	単年度予算に乗らない。検証の負担も大きい
B. インフラの刷新から段階的に	土台をサポートのあるクラウドへ移す。Perl CGIは当面そのまま動かす	初年度で数百万円＋月額のクラウド利用料	今年度分は数ヶ月	◯	中身の古さ（Perl）はしばらく残る
C. 現状延命	サーバを新しい機器へ載せ替えるだけ	数百万円	短い	◯	「直せる人がいない」構造は何も変わらない

Claudeとのやりとりで、もう1つ現場的な注意も出ました。古い構成のまま、何も考えずにクラウドへ「そのまま載せ替える」と、月々のクラウド利用料が、今までの自前サーバの費用を上回ってしまうことがあるのです。クラウド化は「載せれば安くなる魔法」ではありません。何を選び、どう構成するかで、逆に高くつくこともある——ここも人間が押さえるべき勘どころでした。

AIの初案は、方向としては正しく、全部盛りの理想像を素早く描いてくれます。ですが現場の予算・人員・制度の制約で削るのは、人間の仕事です。この削り方こそが、同じ状況で悩む会社にとって一番参考になる部分だと思います。似た構図は、食品卸のVB6システムを段階移行で立て直す提案でも書いています。

6. 筆者の提案する経営判断——「今年度はここまで」と線を引く

3案のうち、筆者が提案するのは B案・インフラの刷新から段階的にです。決め手は費用の安さではありません。単年度予算で、今年度内にきちんと完了できる範囲に区切れること——この一点です。

B案を提案する理由: 一番危ないのは「土台のサポート切れ」と「直せる人の不在」です。B案は、今年度でその土台だけをサポートのある基盤へ移し、Perl CGIは当面そのまま動かします。中身の古さは残りますが、まず止まらないこと・安全であることを最優先にできます。「今年度はここまで」と線を引けるので、単年度予算にぴったり乗ります。
A案を勧めない理由: 全面再構築は、そもそも単年度では終わりません。理想ではありますが、公的機関の予算の仕組みの上では、計画倒れになるリスクが高すぎます。やるとしても、B案で土台を安定させた後、来年度以降に必要な部分だけ進めるのが順当です。
C案を勧めない理由: 一番手軽に見えますが、サーバを新品に替えても「直せる人がいない」構造は1ミリも変わりません。数年後にまた同じ相談を、より高い保守費で繰り返すことになります。

この判断で得るものは、サポート切れの土台からの脱出、セキュリティ上の安心、そして「メーカーが土台の面倒を見てくれる」状態です。失うものも正直に書きます。Perlの本体はしばらく古いまま残るので、「一気に新しくなった」という達成感はありません。UIの刷新やプログラムの書き換えは、来年度以降に持ち越しになります。地味です。ですがその地味さは、単年度で確実に一歩進め、途中で計画が破綻しないことの対価です。

下のグラフは、3案の総コストの目安を比べたものです。金額はこの規模のシステムを想定した筆者の【仮定】であり、実際の見積もりではありません。

刷新3案の総コスト目安【仮定】（この規模での概算・実見積ではない）

A 全面再構築

4000万円

B 段階（インフラから）

2200万円

C 延命（載せ替えのみ）

1500万円

C案が最安に見えますが、これは「直せる人が要らない前提」の数字です。実際には、土台が古いまま残るぶん、いずれ全面対応が必要になります。B案は初年度の負担を単年度予算に収めながら、来年度以降の刷新の足場も作れる——総額でも、時間の使い方でも、無理のない中間に位置します。

7. 提案を形にする——今年度の一歩と、その先の地図

言葉だけでは伝わりにくいので、B案を「時間軸のロードマップ」に落とし込みます。まず全体像です。

順番には理由があります。今年度は、一番危ない土台の問題だけを片付けることに集中します。UIの見た目やプログラムの書き換えは、魅力的ですが後回しです。まず「サポートの効く土台に引っ越し、データを安全な置き場に移す」。ここまでを単年度で終える、という区切り方です。

その今年度分だけを取り出したのが、下の構成図です。マネージドとは「メーカーやクラウド事業者が、土台の点検・更新を代わりにやってくれる」という意味です。

ポイントは、Perl CGIの本体には、今年度はほとんど手を入れないことです。土台と、データの置き場だけを、新しく安全なものへ移す。プログラムはそのまま乗せ替えて動かします。これなら検証すべき範囲が「ちゃんと今まで通り動くか」に絞られ、単年度でも現実的に終えられます。

古いPerlのコードを読み解く作業では、AIが力を発揮します。撤退したベンダーの引き継ぎ資料が乏しくても、コードをAIに読ませて「この処理は何をしているか」を書き起こしていけます。この使い方は、AIでレガシーコードを解読する実践編で詳しく書いています。来年度以降にUIの刷新やAPI化へ進むとき、この「解読して文書に残す」下準備が効いてきます。

8. 見込める効果——「直せる状態」を取り戻す

今年度分（B案の第1段階）で、何がどう変わるのか。5つの観点で、BeforeとAfterを並べます。

観点	Before	After（今年度分）
コスト	古いサーバの維持。障害時の対応の当てなし	クラウド利用料は発生するが、構成を選べば維持費は見通せる
保守（担い手）	直せるのは相談ベースの筆者1人	標準的なクラウド基盤なので、扱える会社の裾野が広がる
セキュリティ	サポート切れOSに弱点が残り続ける	メーカー・事業者が土台を自動更新。穴が塞がれ続ける
BCP	古いサーバが1台故障しただけで全体停止・復旧の当てなし	データはマネージドな置き場へ。復旧・冗長化の手段が持てる
業務・将来性	古い土台の上では次の刷新に踏み出せない	安定した足場の上に、来年度のUI刷新・API化を積める

正直に、限界も書いておきます。今年度分では、利用者から見える画面はほとんど変わりません。Perlで書かれた中身も古いままです。「見た目が新しくなった」という分かりやすい成果は出ません。効果は、地面の下で出ます。 危ない土台から安全な土台へ引っ越し、直せる会社を選べる状態を取り戻す——それが今年度の投資の本当のリターンです。

そしてこの一歩は、その次の一歩（UIの刷新、API化、必要な部分だけの言語刷新）を無理なく積むための土台になります。全部を一度にやらないからこそ、途中で息切れせずに続けられるのです。

9. 経営者向けまとめ——5年後に「直せる人が複数いる」状態か

5年後、この判断が成功だったと言えるかどうかの物差しは、システムが最新の見た目になったかどうかではありません。「このシステムを直せる人・会社が、複数いる状態になっているか」です。

保守が1社に依存し、その1社が撤退して立ち往生する——今回の出発点は、まさにこれでした。土台をサポートのある標準的な基盤へ移し、コードを文書に起こし、扱える会社の裾野を広げていけば、たとえ来年また1社が撤退しても、次を探せます。それが、この投資が守ろうとしている本当の資産です。

保守の担い手が消えかけている会社の経営者に、順番だけお伝えします。

今月やること（費用ゼロ）: 「このシステムを直せるのは、今どこの誰か」を紙に書き出す。名前が1社・1人しか出てこなければ、それが危険信号です。あわせて、土台の基本ソフト（OS）のサポート期限を調べる。
今期やること: 「全部作り直す」で考えない。一番危ない土台（サポート切れOS・老朽サーバ）から、単年度で終わる範囲に区切って手を付ける。設計図がなければ、AIも使って現状のコードを文書に起こし始める。
やらなくていいこと: 撤退の穴埋めに、いきなり全面再構築を発注すること。予算にも人員にも重すぎて、計画倒れになりがちです。まず「止まらない・安全・直せる」を取り戻すのが先です。

社長向け判断シート（筆者の評価）

項目	評価	根拠
緊急度	★★★★☆	派手な障害はまだ。だが保守の担い手が不在で、土台のサポートも切れている
ROI（Return on Investment＝投資対効果）	★★★★☆	今年度分は保守の継続性とセキュリティを確保。次の刷新の足場にもなる
投資規模	★★☆☆☆	段階移行の第1段階なら単年度予算に収まる。★が少ないほど着手しやすい
難易度	★★★☆☆	山は技術より「単年度に収まる範囲へ線を引くこと」と「制度の制約への適合」
おすすめ	★★★★☆	保守の担い手が消えた状態の放置だけは勧めない。まず土台から

タイトルの問い——「保守会社が撤退したら何から始めるか」——への筆者の答えは、こうです。「全部を作り直そうとしない。まず、一番危ない土台だけを、今年度で終わる範囲に区切って直す。そして『直せる人が複数いる状態』を取り戻すことを、ゴールに置く」。

この記事は読者のみなさんへのケーススタディであると同時に、あの相談への、筆者からの提案書でもあります。「では、今年度は土台の引っ越しから始めましょうか」と言っていただけたら、筆者としてこれほど嬉しいことはありません。

参考・出典

帝国データバンク「ソフトウェア業の倒産動向(2024年度)」(2025年4月発表) — 2024年度の倒産は220件で前年度の約1.4倍、過去10年で初の200件超。倒産企業の8割超が従業員10人未満。https://www.tdb.co.jp/report/industry/20250423-software-br24fy/
東京商工リサーチ「2024年情報通信業の倒産動向」 — 情報通信業の倒産425件（11年ぶりに400件超）、うちソフトウェア業223件。https://www.tsr-net.co.jp/data/detail/1200895_1527.html
Red Hat「Red Hat Enterprise Linux Life Cycle」 — RHEL6は2020年11月、RHEL7は2024年6月に通常保守（メンテナンスサポート）が終了。以降の延命は有償の拡張サポートに限られる。https://access.redhat.com/support/policy/updates/errata
IPA（情報処理推進機構）「中小企業の情報セキュリティ対策に関する実態調査(2024年)」 — セキュリティの修正プログラムを適用している中小企業は31.3%。（本文では「サポート切れOSの継続利用率」そのものではなく、土台の安全対策が後回しになりがちな実態を示す代理指標として引用）
経済産業省（みずほ情報総研受託）「IT人材需給に関する調査」(2019年) — 2030年にIT人材が最大79万人不足との試算。https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf（2026年時点では7年前の試算だが、保守人材の確保が年々難しくなる方向感を示す数字として引用）
本文中の費用・期間はいずれも【仮定】と明記した筆者の概算・一般的な目安であり、個別の見積もりに代わるものではありません。クラウド移行の費用・期間には権威ある公表相場が存在せず、この規模のシステムを想定した参考値です。システム投資の判断にあたっては、複数の専門事業者への相談をお勧めします。