レガシーシステム刷新の事例では、資産と業務を可視化してから移行方式を選び、刷新後の運用体制まで設計しています。脱却の事例を知ることは、刷新判断の第一歩になります。
全体像はレガシーシステム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムを放置するリスクと刷新事例を学ぶ意義
「2025年の崖」が示す放置リスクの深刻さ
放置のリスクは、経済損失の予測と、企業が課題をどう認識しているかの両面から確認できます。
- 経済損失：経済産業省の2018年「DXレポート」は、刷新できなければ2025年以降に年最大12兆円の損失が出ると警告しました（出典：経済産業省 DXレポート）。
- 課題の継続：この警告は「2025年の崖」と呼ばれ、2026年になってもCOBOL基幹系や汎用機が稼働し続けています。
- 企業の認識：JUAS（一般社団法人日本情報システム・ユーザー協会）の調査では、約7割が老朽化を課題と認識しています（出典：JUAS）。
課題を認識していても、実際の刷新着手が追いつかない溝を埋めるには、先行企業がいつ動き、どんな判断軸で進めたかを具体的に学ぶことが有効です。
COBOL技術者の高齢化・枯渇という時限爆弾
放置が続くと、技術者の引退とハードウェアの保守切れが重なる点に注意が必要です。
- 技術者の高齢化：日本のCOBOL技術者の多くは50代〜60代で、引退後は保守困難なシステムが続出すると予測されています。
- 保守人材の不足：コードを読んで変更できる人がいなければ、バグ修正や法令対応、外部API連携も止まります。
- ハードウェアの保守切れ：COBOL基幹系はメインフレームや汎用機で動くことが多く、保守契約の期限切れも重なります。
- オフコンのサポート終了：特定ベンダーが保守を終えると、修理できない機械になってしまいます。
技術者の枯渇と保守切れが重なる期限は、すでに多くの企業で現実になっています。こうした背景のもとで、刷新事例がどう進んだかを次に見ていきます。
COBOL基幹系からの脱却に成功した刷新事例
製造業（従業員約1,200名）の16ヶ月リビルド事例
中堅製造業A社（従業員約1,200名）は、COBOLの基幹系を汎用機で30年以上稼働させてきました。課題は技術負債、夜間バッチの長時間化、保守費の高騰の三つに及んでいました。
- 技術負債：追加改修のたび処理がスパゲッティ状に複雑化し、業務とコードの対応を把握する担当者がほぼいませんでした。
- バッチ処理：在庫計算に8時間かかり、夜間の障害が翌朝の操業に影響しました。
- 保守費：汎用機ベンダーへの年間保守費は2,400万円でした。
A社は既存コードを自動変換するのではなく、業務要件を整理してJavaで再構築するリビルドを選びました。その判断の前に、IT資産を棚卸しして、有効な業務ロジックと20年前の廃止処理を仕分けました。
棚卸しの結果、刷新が必要なプログラムは想定の約60%と分かり、対象を絞り込めました。そのうえで約16ヶ月の段階移行（ストラングラーパターン）を進め、在庫管理から切り替えて、安定後に生産計画・販売管理へ移行しました。
一括切り替えを避けたことで、移行リスクを局所化できました。さらに、夜間バッチは8時間から90分へ約80%短縮し、サーバー保守費は年2,400万円から850万円へ約65%減りました。
ブラックボックスが解消したことで、新機能の追加やAPI連携を内製チームで担えるようになりました。また、システム変更のリードタイムも大幅に改善しています。
移行アプローチの選択：リホスト・リビルド・段階移行の使い分け
移行方式によって、移行期間や残る技術的負債、切り替え時のリスクは変わります。方式の選定では、AWSの7RやIPAの4分類を参考にしつつ、COBOL資産の規模・複雑さと技術者の残存年数を見ます。
- リホスト：COBOLは変えず、メインフレームからLinuxサーバーやクラウドへ移す方式です。
- リビルド：要件を整理したうえで、モダンな言語でシステムを再開発します。
- 段階移行：新旧システムを並行して稼働させ、機能を順に切り替えます。
リホストは書き直しがないぶん移行期間が短く、ハードウェア保守費の問題を解決できます。一方で、ブラックボックス化や技術者枯渇は先送りになります。
リビルドは工数と費用が最も大きい一方、技術的負債を根本から解消し、将来の変更コストを下げます。製造業A社はこの方式を採用しました。
段階移行は全面切り替えの失敗リスクを下げるため、強く推奨されます。たとえば、江崎グリコでは基幹システムの切り替えの際に、計画の不備から出荷停止を招く大規模障害が起きました。
AWSの7Rは、Rehost/Relocate/Replatform/Repurchase/Refactor/Retire/Retainという分類です。IPAの4分類には、リビルド、リライト、リホストに加えて、ハードウェア更改があり、移行方式を検討する際の参考になります。
業務・インフラのレガシー脱却事例——イオン・ユニリタの取り組み
イオングループ：属人化した手作業プロセスというレガシーからの脱却
レガシーは、COBOLやメインフレームだけでなく、人に依存した手作業のプロセスも含みます。イオングループではデジタル化前の業務が多く、フローの全容を誰も把握できていませんでした。ツールを入れれば自動化できそうに見えても、実際にはどんな作業があるかすら可視化されていない状態でした。
- 導入前の可視化：プロセスマイニングと業務ヒアリングで、繰り返し作業を洗い出しました。
- 適用業務の選定：可視化に時間と工数をかけ、RPAの効果が高い業務を優先しました。
- 得られた効果：月700時間の業務削減を実現しました。
ツール導入より先に現状を把握する順序が、成功の基盤になりました。
この考え方は、COBOL脱却にも応用できます。A社のように「何があるか」を把握せず刷新に進むと、スコープが膨らみ工数超過につながります。同社は、IT資産の棚卸しをリビルドの起点にしました。
業務プロセスとシステムの双方を可視化してから方式を決めることは、刷新事例に共通する成功要因です。
ユニリタ事例：老朽インフラのブラックボックスの可視化と保守費の削減
インフラ領域のレガシー脱却に取り組んだユニリタは、200種30,000台のネットワーク機器と10,000台のサーバーを抱えていました。ログは1日10億件にのぼり、機器ごとの保守費も分からないまま、全体がブラックボックスになっていました。
- ログの可視化：通信ログを自動集計・分析し、保守費の高い機器を特定しました。
- 機器の選別：廃棄・縮小と継続の対象を明確にし、不要機器を整理して保守契約も見直しました。
- 導入効果：作業負担は5分の1に減り、数億円規模の投資対効果を確認しました。
COBOL基幹系と同じく、管理できていないITインフラもレガシーといえます。可視化しないまま刷新すると、必要な機器まで廃止するおそれがあります。可視化ツールへの投資は、刷新コストの削減にもつながります。
事例に学ぶ——レガシー脱却を成功させる判断軸
判断軸(1)：COBOL資産の扱い——リライトとリビルドの選択
COBOL資産の扱い方は、刷新全体のコストや期間、リスクを左右します。方式を選ぶ際は、移行期間と保守性を見るのが基本です。
- リライトの適用場面：既存ロジックが複雑な場合や、短期間で移行したい場合に候補となります。
- 変換方法：自動変換ツールでCOBOLをJavaやPythonに変換すると、移行期間を短縮できます。
- 変換後の注意点：COBOLの構造を引き継ぐため、ブラックボックスのまま言語だけが変わり、保守しにくい場合があります。
- リビルドの進め方：IT資産を棚卸しして要件を整理し、現在の業務に合うシステムを設計します。
- リビルドの特徴：工数は大きい一方、モダンな設計と内製チームの継続改善につながります。
COBOL技術者に頼らず、クラウドネイティブな開発を進められることも、長期的な競争力になります。数年後に誰が保守するかを起点に判断します。
技術者枯渇の期限を踏まえると、リビルドへの投資は先送りするほどコストが増す傾向にあります。
判断軸(2)：移行先の選定——クラウドとオンプレミスの比較
汎用機やメインフレームからの脱却では、多くの企業がクラウドを選びます。移行先は、刷新後の運用コストの構造も踏まえて検討します。
- 移行先の違い：クラウド（AWS・Azure・GCP等）かオンプレミスの新サーバーかで、運用コストの構造が変わります。
- クラウドの利点：保守費の変動費化、拡張性、パッチ対応の自動化があり、中でもベンダー依存の解消が最大の理由です。
AWSの7Rでは、単純にクラウドへ移すリホスト（Lift&Shift）から、クラウドネイティブに作り直すリファクター（Refactor）まで、移行の深さを選べます。
製造業A社はリビルドと同時にクラウドへ移行し、保守費削減の大半を実現しました。
たとえば、トヨタ自動車はIT投資の評価にQCDS（Quality, Cost, Delivery, Safety）の4軸を使っています。移行先も一つの指標だけで比べず、多角的な視点から選ぶことが大切です。
判断軸(3)：技術者継承の計画——刷新後の運用体制設計
レガシー脱却の成否は、刷新後の運用体制の設計にも大きく左右されます。刷新後の運用を内製で担えるかどうかは、技術者の継承とベンダー依存を考えるうえで欠かせません。
- 運用体制：自社に技術者がいないまま刷新すると、新システムでも別のベンダーに依存する場合があります。
- 技術者の継承：内製エンジニアが構造を習得できるようにします。A社では社内SE2名が、要件定義から設計レビューまで経験しました。
その結果、A社は稼働後の機能追加や不具合対応を内製チームで担い、ベンダー依存を解消しました。ユニリタも、自社チームが運用できる可視化ダッシュボードを整備しました。
ユニリタでは、外部委託していた分析業務を内製化し、作業負担を5分の1にしました。刷新後も内製で運用する設計が、長期的なコスト削減と技術者継承を支えます。
まとめ：レガシーシステム刷新事例から得られる教訓
ここまで、COBOLや汎用機、オフコンなどの古い技術基盤から脱却した事例を中心に、刷新の取り組みを見てきました。
事例を横断すると、共通する成功要因は3つあります。それは、着手前に現状を把握し、資産の扱いを決めてから、段階的に移行することです。
- 現状を可視化する：資産の棚卸し、業務プロセスの洗い出し、インフラログの分析から着手します。
- 資産の扱いを決める：リホスト・リライト・リビルドを、将来の技術者継承と合わせて選びます。
- 段階移行する：一括切り替えの影響を避け、ストラングラーパターンでリスクを管理します。
製造業A社は、IT資産の棚卸しを起点にCOBOL基幹系を約16ヶ月かけて段階刷新しました。その結果、夜間バッチを約80%短縮し、保守費も約65%削減しました。
イオングループは、ツールを導入する前の業務可視化で月700時間を削減しました。ユニリタは、インフラの可視化により作業負担を5分の1にし、数億円規模の投資対効果を確認しました。
「2025年の崖」が警告した年間最大12兆円の損失リスクは、技術者枯渇や汎用機の保守切れと重なり、経営リスクになっています（出典：経済産業省 DXレポート）。
事例の判断軸を参考に、まず自社のレガシー資産を棚卸しし、刷新の準備に入ります。詳細な手順や体制づくりについては、専門家への相談も検討できます。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。