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