レガシーシステムを使い続ける6つのリスクとは？実際の障害事例と対策を解説
「うちのシステムは古いけれど、まだ動いている。」その状態を、経営層や現場に「危ない」と説明するのは簡単ではありません。「レガシーシステム」「2025年の崖」という言葉を出しても、自分たちの話だと受け取ってもらえないことが多いからです。
伝わりにくい理由のひとつは、問題の本質が基盤システムの古さだけではないことにあります。改修を頼むと「影響範囲を調べないと見積もれない」と言われる。中身を説明できる人が社内に1〜2人しかいない。設計書はあるが、今の動きと合っているか誰も確認していない。こうした状態のシステムを、この記事ではレガシーシステムと呼びます。
この記事では、レガシーシステムに関する次の3つに答えます。
- レガシーシステムを使い続けると、具体的に何が起きるのか
- 実際に事故が起きた企業では、何が引き金になったのか
- 全面刷新に踏み切らずに、何から手をつければよいのか
目次
- レガシーシステムを使い続ける6つのリスク
- レガシーシステムが原因で実際に起きた事例4選
- 期限が決まっているリスク｜サポート終了と制度対応
- 【対策】全面刷新に踏み切らずにリスクを下げる4つの手順
- レガシーシステムの改修・刷新はスパイクスタジオまでご相談ください
レガシーシステムを使い続ける6つのリスク
レガシーシステムとは、構築から年数が経ち、改修が難しくなった業務システムを指します。判断の基準は稼働年数そのものではありません。「中身を説明できる人が社内にいない」「直したときにどこが壊れるか読めない」という状態かどうかです。
動いている間、この問題は表に出ません。表に出るのは、止まったとき、守れなくなったとき、変えなければならなくなったときの3つです。
そこから具体化すると、リスクは次の6つになります。
- ①障害が起きても復旧できない
- ②更改作業そのものが事故になる
- ③サポート終了で脆弱性を塞げない
- ④制度の変更に追従できない
- ⑤IT予算が維持費に食われ、新しい投資ができない
- ⑥中身が分かる人が社内からいなくなる
①障害が起きても復旧できない
レガシーシステムを使い続けるリスクで最も重いのは、止まること自体ではありません。システムが止まったあと、原因にたどり着けないことです。
設計書が現物と合っていない、改修履歴が残っていない、すでに当時の担当者が退職している。こうした3つが重なると、障害対応は「誰も中身を知らないプログラムを読むところ」から始まります。復旧の見通しが立たず、復旧時刻を取引先に伝えられない状態が続きます。
業務が止まっている間の損失は、システムの保守費とは桁が変わります。後述する江崎グリコの事例では、出荷の停止と再開が繰り返され、全品の出荷が元の状態に戻るまで7か月かかりました。このケースで、売上高への影響を約300億円と試算しています。
②更改作業そのものが事故になる
「いつか入れ替える」と先送りしているうちに、入れ替え作業そのものの難易度が上がっていきます。
長く使われたシステムには、仕様書に書かれていない振る舞いが積み上がります。特定の取引先だけ処理を分岐させる、月末だけ桁数の扱いが変わる、といったものです。移行先で再現すべき仕様が洗い出せていないと、切り替えた瞬間にデータの不整合が表に出ます。
やっかいなのは、この事故が「放置した会社」ではなく「動き出した会社」で起きることです。後述する4件の事例のうち3件は、放置ではなく更改・移行の作業中に発生しています。先送りは、将来の事故を大きくする行為だと考えたほうが実態に合います。
③サポート終了で脆弱性を塞げない
OS・データベース・ミドルウェアには、提供元が定めたサポート期限があります。期限を過ぎると、原則として修正プログラムが提供されなくなります。
これは「古いから何となく危ない」という話ではありません。攻撃側から見れば、修正されないことが確定している穴です。業種によっては、サポート切れの基盤を使い続けていること自体が、取引先の調達要件や監査で指摘対象になります。
具体的にどの製品がいつ期限を迎えるかは、この記事の後半で表にまとめています。
④制度の変更に追従できない
法令や業界ルールが変わると、システムは期限までに対応を迫られます。レガシーシステムでは、この「期限までに直す」が難しくなります。影響範囲が読めないため、改修の見積もりが立たないからです。
国が期限を切った例として、自治体システムの標準化があります。デジタル庁が2026年2月27日に公表したデータでは、標準化の対象3万4592システムのうち8956システム（25.9%）が期限内の移行に間に合わない見込みで、該当する自治体は1788団体のうち935団体（52.3%）と過半を占めました。遅延の主因として挙げられているのは、技術者の不足です。
期限が決まっていても、手を動かせる人がいなければ間に合いません。これは自治体に限った話ではありません。
参照日経クロステック「自治体システム標準化、遅延が全システムの25.9％ 自治体数では過半に」（2026年2月27日）
⑤IT予算が維持費に食われ、新しい投資ができない
レガシーシステムは、新しいことをする余力を静かに削ります。
日本情報システム・ユーザー協会（JUAS）の調査では、2024年度のIT予算の配分は、現行ビジネスの維持・運営（ラン・ザ・ビジネス）が76.2%、新たな価値創出（バリューアップ）が23.8%でした（JUAS「企業IT動向調査報告書2025」）。3年後の目標値を聞いても68.2%対31.8%で、維持・運営費が大部分を占める構造は続きます。
経済産業省が2018年のDXレポートで示した、技術的負債によって既存システムの維持管理費がIT予算の9割以上を占めるという見通しは、当時の試算です。JUASの数字は、そこまで至らない段階でも日本企業が足踏みしていることを示しています。AIを導入したくても、そのための予算を確保しにくい状態です。
⑥中身が分かる人が社内からいなくなる
最後のリスクは、時間とともに確実に進みます。人が辞めることは止められないためです。
GitHubは公式ブログで、銀行・保険・政府システムなどで推定200億行のCOBOLコードが現役で稼働している一方、書いた本人の多くが現役を退きつつあると説明しています（GitHub Blog「How GitHub Copilot and AI agents are saving legacy systems」2025年10月14日）。また、GitHubは生成AIでレガシーコードから業務ロジックを抽出して文書化する手法を紹介したうえで、完全な自動化は少なくともあと5年は先だとしています。
国内でも対策が始まっています。トヨタシステムズは2025年10月、日本IBMの支援でCOBOL・PL/Iのスキル継承を目的とした「レガシーコードラボ」を設立し、生成AIを使った開発支援ツールを共同開発しました。COBOL未経験の人材でもコードと仕様を読み解ける体制をつくる取り組みです（＠IT「『COBOL人材がいない』、基幹システムのレガシー継承に向けた模索が進む」2025年12月26日）。
レガシーシステムが原因で実際に起きた事例4選
ここからは、レガシーシステムが原因で起きた事例を4件紹介します。4件とも、システムが古いこと自体だけではなく、古いまま期限を迎えたこと、あるいは一気に入れ替えようとしたことが引き金になっています。
1. 金融の事例｜全銀ネットの中継機更改で10行の振込が全面停止
2023年10月10日、全国銀行資金決済ネットワーク（全銀ネット）が運営する全銀システムで障害が発生しました。三菱UFJ銀行など10の加盟金融機関で、他行宛ての振込ができなくなりました。
引き金は、金融機関と全銀システムをつなぐ中継コンピュータの更改です。2017年にサービス提供を開始した機種が保守期限を迎えたため、10月7日から9日にかけて14の加盟金融機関で新機種への移行が行われました。移行後の運用でプログラムの不具合が表面化し、10の加盟金融機関と全銀システムの間で、他行宛て振込の業務が全面的にできない状態になりました。
復旧は10月12日でした。全銀システムは稼働から50年間、安定稼働を続けてきたシステムです（全銀ネット・NTTデータ「全国銀行データ通信システムの障害について」2023年12月1日）。長く問題なく動いてきたことと、更改に耐えられることは別だと分かる事例です。
2. 食品の事例｜江崎グリコの基幹システム切り替えで全品出荷の再開まで7か月
江崎グリコは2024年4月3日、基幹システムをSAPのS/4HANAへ全面移行しました。移行後に障害が発生し、チルド食品の出荷を停止しました。
4月18日に一部を再開したものの、データの不整合などにより再び停止しています。障害発生前と同じ全品出荷の状態に戻ったのは、同年11月5日でした（江崎グリコ「当社基幹システム障害に伴うチルド商品（冷蔵品）の全品出荷再開に関するご報告」2024年12月6日）。
また、江崎グリコは2024年12月期の決算で、このシステム障害が売上高で約300億円、営業利益で約80億円の下押し要因になったと試算しています（日本経済新聞 2025年2月13日）。移行プロジェクト自体は2019年12月に始まり、当初の完了予定から延期されていました。
3. 製造の事例｜古河電気工業のERP刷新が頓挫し50億円超の訴訟に
古河電気工業と子会社の古河ASは2018年11月6日、ERPベンダーのワークスアプリケーションズを相手取り、50億円超の損害賠償を求めて提訴しました。
対象は、経理・購買・販売を含むグループ基幹系業務システムの刷新プロジェクトです。2016年に開始し、2018年の稼働を予定していましたが、開発の遅延が重なり中断しました。背景には、当時使っていた会計システムの保守サポートが2019年3月に終了するという期限がありました（日経クロステック「経理や購買システムの刷新が頓挫、ワークスアプリケーションズとの係争続く」2020年4月24日）。
サポート終了という期限に追われて刷新を立ち上げ、その刷新自体が間に合わないという経過をたどっています。
4. 海外金融の事例｜英TSB銀行の一斉移行で約4,865万ポンドの制裁金
英国のTSB銀行は2018年4月、親会社が持つシステムをもとにした新しい勘定系「Proteo4UK」へ一斉に移行しました。移行直後に障害が発生し、オンラインバンキングとモバイルバンキングが長期間使えなくなりました。顧客が自分の口座にアクセスできない状態に加え、他人の口座情報が表示される事象も起きています。
英金融行動監視機構（FCA）と健全性規制機構（PRA）は2022年、運用リスク管理とガバナンスの不備を理由に、TSB銀行へ4,865万ポンドの制裁金を科しました（Computer Weekly「TSB hit with huge fine after IT migration disaster」2022年12月20日）。当時の最高経営責任者は、障害の発生後まもなく同行を去っています。
移行は機能を分けた段階的な方式ではなく、一斉に切り替える方式で行われました。切り替えに失敗したとき、影響が全顧客に及ぶ構造だったことになります。
期限が決まっているリスク｜サポート終了と制度対応
レガシーシステムのリスクのうち、発生時期が読めないものと、すでに日付が決まっているものは分けて扱えます。先に着手すべきは後者です。日付が決まっているものは、社内で予算の必要性を説明しやすいという利点もあります。
| 期限 | 内容 | 影響・リスク |
|---|---|---|
| 2027年1月 | Windows Server 2016のサポート終了（Microsoft公式） | セキュリティ更新が停止する。新たな脆弱性が見つかっても修正されない |
| 2027年12月 | SAP Business Suite 7（ECC 6.0を含む）の標準保守終了（SAP公式） | 移行先の選定と移行作業に数年単位を要する。着手が遅れるほど選択肢が狭まる |
| 2030年12月 | 同・延長保守の終了。保守基準額に2ポイント上乗せで2028年から利用可能 | 費用を払って時間を買う選択肢。ただし先送りの期間が延びるだけで課題は残る |
| 2025年度末 | 自治体システム標準化の原則期限（期限を過ぎて移行中の団体が多数） | 技術者の確保が追いつかず、期限が決まっていても間に合わない例が出ている |
この表で確認してほしいのは、日付そのものではなく「決断を先延ばしできる残り時間」です。基幹システムの移行は、検討から稼働まで数年かかります。2027年の期限から逆算すると、着手のタイミングとしてはすでに余裕がありません。
なお、この表は代表的な製品と制度に絞っています。関係する期限は、自社のシステムがどの製品・どの版数で動いているかによって変わります。各製品の提供元が公表しているサポート期限を、保守ベンダーにもあわせて確認しておくことをおすすめします。確認の進め方は、次の章「期限のあるリスクから棚卸しする」で紹介しています。
【対策】全面刷新に踏み切らずにリスクを下げる4つの手順
ここまでの事例が示しているのは、「古いまま放置する」と「一気に全部入れ替える」のどちらにもリスクがあるということです。間を取る方法があります。現行システムを動かしたまま、分かる範囲から順に手を入れていく進め方です。
情報処理推進機構（IPA）の調査に、参考になる数字があります。ビジネスモデルの変革に取り組む企業のうち、レガシーシステムの刷新にも取り組んでいる割合は、成果が出ている企業で74.8%、出ていない企業で60.1%でした。IPAはこの項目について、取組割合は高いものの、成果の有無による差は他の項目に比べて小さいと分析しています。同じ調査では、顧客起点の価値創出による変革で成果が出ている企業は17.7%でした。
参照IPA「DX 動向 2024 - 日本企業が直面する DX の 2 つの崖壁と課題」（2024年1月）
刷新に取り組んでいるかどうかだけでは、成果の差は説明できないということです。着手するかどうかより、何から着手するかを先に決める必要があります。
1. 期限のあるリスクから棚卸しする
最初にやるのは、改修ではなく一覧化です。社内のシステムについて、基盤製品のサポート期限、保守契約の期限、制度対応の期限を一枚に並べます。
実践ポイント
- OS・データベース・ミドルウェアの版数と提供元の公表期限を突き合わせる
- 「期限が決まっているもの」と「いつ壊れるか分からないもの」を分けて書く
- 各システムについて、直近1年の改修回数と、改修できる人の人数を併記する
改修回数が多いのに、担当できる人が1人しかいないシステムが、最も危ない組み合わせです。
2. 中身を読み解いてから手を入れる
仕様書が現物と合っていないことを前提に進めます。動いているコードを正として仕様を復元し、影響範囲を可視化してから改修に入ります。生成AIが効くのは、この読み解きの工程です。
実践ポイント
- 対象を全体ではなく、1つの業務機能に絞って始める
- 復元した仕様は、人が読める文書として残す（次に触る人のために）
- 変換ツールでの一括移行から入らない。中身が分からないまま形だけ変わる
具体的な手順は「古いシステムの改修は全面刷新しかない？既存システムを読み解いて変更可能にする方法」で、富士通・SMBC日興証券などの事例とあわせて解説しています。
3. 変更頻度の高い部分から段階的に置き換える
全体を一度に移すのではなく、機能単位で切り出して置き換えます。TSB銀行の事例が示すとおり、一斉移行は失敗したときの影響範囲が全顧客に及びます。
実践ポイント
- よく直す機能から着手する。効果が早く出て、社内の合意を得やすい
- 置き換えた部分と残した部分をつなぐ方式を、着手前に決める
- 1区切りごとに本番で動かし、次に進む
生成AIを使って実際に改修した企業の数字は「レガシーシステムをAIで改修した事例8選｜COBOL・基幹システムの実名事例を紹介」にまとめています。明治安田生命の約25%効率化、三井住友銀行のシステムでの約65%短縮など、公表されている数値事例を基に紹介しています。
「自社の現行システムでどこから切り出せるか分からない」「まずは一緒に整理したい」という場合は、現行システムの棚卸しと移行方針をスパイクスタジオと進めることも可能です。まずは、ご相談ベースでも構いません。
4. 移行作業そのものの事故を減らす
全銀ネットと江崎グリコの事例は、どちらも更改・移行の作業中に起きています。移行は、それ自体が最もリスクの高い工程です。
実践ポイント
- 現行の挙動を固定するテストを、移行の前に作る
- 切り戻しの手順と判断基準を、作業前に文書化しておく
- 業務停止が起きた場合の代替手段を、業務部門と合意しておく
テストを先に作ると、移行後に「以前と動きが違う」と言われたときに、仕様なのか不具合なのかを切り分けられます。
スパイクスタジオの支援事例
株式会社Circloop様のケースでは、現行のシステムを動かしたまま、生成AIで既存コードを読み解きながら改修を支援しました。この進め方の詳しい経緯は「“使い捨て”をなくす、その先へ。株式会社Circloopが挑むリユーザブル容器の循環革命」で紹介しています。
なお、生成AIを開発や業務に使う際のリスクについては「生成AIの問題事例13選｜トラブルの原因や対処法を紹介」で、実際に起きた事例とあわせて整理しています。
レガシーシステムの改修・刷新はスパイクスタジオまでご相談ください
レガシーシステムの対応は、全面刷新か放置かの二択ではありません。中身を読み解き、期限のあるところから順に手を入れていけば、業務を止めずに進められます。
スパイクスタジオでは、次の支援を行っています。
- AIモダナイゼーション｜既存システムの解析・仕様の復元から、段階的な改修・移行までを支援します
- BPRコンサルティング｜システムを入れ替える前に、業務プロセスそのものをAI前提で組み替えます
- Spike AI Agent Studio｜専任エンジニアと開発を実行するAIがチームになり、月額定額で開発・改修を継続的に回します
- AI人材育成｜社内に、既存システムを読み解いて直せる人を育てます
「どこから手をつけるべきか分からない」「サポート期限は見えているが、社内で説明する材料がない」という段階でのご相談も承っています。現状の課題を整理するところから一緒に進められます。