システムの保守はなぜ必要か｜放置で起きる3つのこと

エラーも出ず、毎日問題なく動いている業務システム。この状態だと「困っていないのだから、わざわざコストをかけて手を入れる必要はないだろう」と感じるのは、ごく自然なことだと思います。むしろ、動いているものに触ってかえって不具合を生むくらいなら、そっとしておきたい。そうなるのも、よくわかります。

実際、現場でお話を伺っていても「壊れていないのに、なぜ手を入れる必要があるのか」という声はとても多くいただきます。

ただ、システムを扱う立場から少しだけお伝えしたいことがあります。建物でも、車でも、機械でも、使わずに放っておけば、どんなものでも少しずつ傷んでいきます。システムも、実はこれと同じです。自社のプログラムに一切手を加えていなくても、それが動いている周りの環境は、毎日少しずつ変わり続けているからです。

この記事は「すぐにアップデートしてください」とお願いするためのものではありません。動いている今だからこそ知っておいていただきたい、放置するとどうなるのか、そしてどう向き合えばいいのかを、できるだけわかりやすくお伝えできればと思います。

「バグがない」ことと「安全である」ことは、別の話

業務が滞りなく回っていると、つい「このシステムは健康だ」と思いたくなります。けれど、業務に不具合がないことと、システムが内側まで健全であることは、実は別の話です。

目に見えるバグと見えない傷み

画面がフリーズする、計算結果が合わない。こうした現象はすぐに気づきます。社内のどなたかが操作していて「おかしいぞ」となり、業務に支障が出るので、たいてい早めに直されます。これは目に見える傷みです。

一方で、もっと見えにくい傷みもあります。「脆弱性」と呼ばれる、セキュリティ上の隙です。これはプログラムの書き間違いだけでなく、外の環境が変わったり、新しい攻撃の手口が登場したりすることで、後からじわじわと生まれてきます。

やっかいなのは、脆弱性は普段使っている分には画面に何も現れないことです。社内からは完全に正常に見えていても、いつの間にか裏口の鍵が開いたままになっている。そういうことが起こり得ます。だからこそ「動いている＝安心」とは言い切れないのです。

コードは摩耗しないのになぜ傷むのか

建物や機械なら、放っておけば雨風による錆や部品の劣化が、目に見える形で現れます。ところがソフトウェアのソースコードそのものは、何年経っても物理的に劣化することはありません。

これが少しやっかいなところで、「物理的に劣化しないなら、触らなければそのまま使えるはず」という安心感につながりやすいのだと感じています。

けれど、コードは劣化しなくても、システムが乗っている土台は別です。サーバー、OS、ブラウザ、通信の暗号方式。こうした周りの環境は、こちらが何もしていなくても、世の中の流れに合わせて変わり続けています。自社のシステムだけが開発当時のまま立ち止まっていると、周りとの差が静かに、でも確実に広がっていきます。この「差」こそが、見えない傷みの正体です。

放置したシステムに起きうる3つのこと

では、立ち止まっているだけのシステムに、具体的にどんなことが起きるのか。代表的な3つをご紹介します。

その1：言語やOSの「サポート終了（EOL）」

システムは、プログラム言語（PHP、Javaなど）、サーバーOS（Linux、Windows Server など）、データベース（MySQL、PostgreSQL など）といった、たくさんの基礎技術の上に成り立っています。

これらの基礎技術には、ほぼ例外なく「サポート期限（End of Life = EOL）」があります。家電に保証期間があるのと、少し似ているかもしれません。

たとえば Web 開発で広く使われる PHP の場合、各バージョンはリリースから2年間が新機能やバグ修正を含む完全サポート、その後2年間がセキュリティ修正のみとなり、合計でおおむね4年でサポートが終了します。これは2024年3月の方針変更でセキュリティサポートが1年から2年に延長され、終了日が統一されたものです（出典: 後述の参考リンク）。

サポートが終わっても、利用している OS の提供元が緊急の脆弱性に限って独自に修正（バックポート）してくれるケースもあります。ただしこれは限られた範囲の対応で、公式サポートが続いている状態とは安心感が違います。

サポートが切れたバージョンを使い続けると、新しい脆弱性が見つかっても、もう公式の修正は届きません。これは攻撃する側から見れば「穴が見つかっても直されないシステム」ということになってしまいます。2026年現在でも、数年前にサポートが切れた言語のまま動いている社内システムは、決して珍しくありません。責められるようなことではなく、それくらいよくあることなのです。

その2：利用者側のブラウザやOSは「勝手に」新しくなる

自社のシステムをどれだけ大切に現状維持しても、それを使う側の環境までは止められません。

皆さまが日々お使いの Google Chrome や Microsoft Edge、Apple Safari といったブラウザは、数週間単位で自動的に新しくなっています。この更新では、便利な機能が増えるだけでなく、古い書き方が使えなくなったり、Cookie の扱いなどセキュリティの決まりが厳しくなったりします。

そのため、「自社のサーバーもプログラムも何ひとつ変えていないのに、ある日突然ボタンが反応しなくなった」「画面のレイアウトが崩れてしまった」ということが、実際に起こり得ます。これは、古いつくりがブラウザ側の新しい決まりについていけなくなったために起きるもので、こちらに落ち度があったわけではありません。

その3：暗号の方式が、相対的に古びていく

つくった当時は安全とされていた暗号化の方式も、時間が経つと安全とは言えなくなっていきます。

理由は、攻撃する側の技術が進歩することと、コンピューターの性能が上がり続けることの両方です。たとえば、長く使われてきた SHA-1 という方式は、2017年に Google が「同じ値を別のデータから作り出せる」ことを実証し、安全でないことがはっきりしました。通信の方式でも、かつて標準だった TLS 1.0／1.1 は、いまは非推奨とされています。IPA（情報処理推進機構）も2020年のガイドラインで、古い方式を避けるよう示しています（出典: 後述の参考リンク）。

つまり、自社のコードに間違いがひとつもなくても、世の中の攻撃の手段が進化することで、設計そのものが相対的に古びてしまう。これも、立ち止まっているだけで起きる傷みのひとつです。

見送りを続けると、対処はどんどん大変になる

「今は困っていないから」と手入れを数年単位で見送ると、傷みが少しずつ積み重なって、後からの対処が大変になっていきます。

あとでまとめて直すほど、負担は大きくなる

システムを健やかに保つコツは、小さな手入れをこまめに積み重ねることです。1回ごとの影響範囲も負担も小さく済みます。これは、家のちょっとした修繕や、車のオイル交換に近い感覚かもしれません。

ところが、5年、10年と見送り続けると、最新の環境への引っ越しが、もう簡単な上書きでは済まなくなります。あまりにベースが古いと、途中のバージョンを飛ばして一気に上げるのが技術的に難しくなり、結果としてゼロから作り直さざるを得なくなることもあります。こまめに手入れしていた場合と比べると、費用も時間も大きくふくらみます。弊社の経験でも、長く放置されたシステムほど、引っ越しの難しさと見積りが跳ね上がる傾向があります。

「ちょっとした改修」が大工事になることも

いまの Web 開発では、すべてを自作することはまずありません。世の中で公開されている部品（ライブラリやフレームワーク）を組み合わせてつくるのが一般的です。

これらの部品も、お互いに支え合いながら更新を続けています。そのため、たとえば法改正に合わせて消費税の計算を少し直したいだけでも、関係する部品をひとつ新しくする必要が出て、そのために言語を新しくすると、今度は別の部品が動かなくなる。こうした連鎖が起こることがあります。

数行直すだけのつもりが、部品の連鎖でシステム全体を点検し直す大工事になる。これは長く更新を止めたシステムでよく起きることです。「ちょっとした改修なのに、なぜか見積りが大きい」と感じたら、それは放置が進んできたサインかもしれません。

だからこそ、「メンテナンスする」という発想を

ここまでお伝えしてきたのは、決して「すぐにアップデートしないと危ない」と急かしたいからではありません。建物も車も道具も、手入れを続けるからこそ長く使えます。システムも同じで、放置せずに少しずつ面倒を見てあげることが、結局はいちばん負担の少ない付き合い方なのだと思います。

見た目が変わらない手入れにも、価値がある

新しい画面や便利な機能を足す手入れは、効果が目に見えるので、社内でも納得を得やすいものです。一方、土台を保つための手入れは、見た目が変わらないので、つい後回しになりがちです。

けれど、これは建物の修繕積立金や、車の車検と同じだと捉えています。外壁の塗り直しや配管の掃除を怠れば、建物の価値は少しずつ下がっていく。システムも、面倒を見続けるからこそ、資産としての価値を保てます。手入れの費用をあらかじめ予算に組み込んでおくと、慌てずに済みますし、長い目で見れば出ていくお金も抑えられます。

まずは「今どうなっているか」を知ることから

とはいえ、今すぐ大きな予算を割く必要はありません。最初の一歩としておすすめしたいのは、自社のシステムが「どんな土台の上で動いているか」を知ることです。

システムを動かしている言語(PHP、Javaなど)のバージョンは何か
そのバージョンの公式サポートはいつ終わるのか(もう終わっているか)
サーバーOSのサポート期限はいつまでか

これらを開発会社や情シスのご担当者に聞いて、終了時期をカレンダーに並べておく。たったそれだけでも、突然のトラブルや、慌てての大きな作り直しを避けるための、心強い手がかりになります。健康診断の結果を手元に置いておくような感覚です。

まとめ

システムの手入れは、壊れた箇所を直す「修理」ではなく、長く元気に使い続けるための「メンテナンス」です。建物や車と同じで、どんなものも放っておけば少しずつ傷みます。システムも例外ではない、というのが、今日いちばんお伝えしたかったことです。

要点を振り返ります。

「動いている」ことと「健全である」ことは別で、傷みは画面に現れないことが多い
言語やOSのサポート終了、利用者側ブラウザの自動更新、暗号方式の陳腐化。立ち止まっているだけでも、この3つで少しずつ傷みは進む
見送りを続けるほど、後からの対処は大変になり、費用もふくらみやすい
まずは身構えず、自社の言語バージョンとOSのサポート期限を「知る」ことから

動いている今は、じっくり向き合える絶好のタイミングでもあります。一度、システムの土台の健康状態に目を向けてみていただけたらうれしいです。

もし「うちのシステム、今どうなっているんだろう」と気になったときは、状況の確認からでもかまいません。お気軽にご相談ください。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/

参考

Supported Versions（PHP 公式）

出典: 各 PHP バージョンのサポート期間・EOL 一覧（公式）

https://www.php.net/supported-versions.php

TLS 暗号設定ガイドライン（IPA）

出典: 独立行政法人情報処理推進機構による SSL/TLS 設定の推奨

https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html