レガシーシステムは経過年数で定義されるものではありません。次の3つの兆候で定義されます。中身を全体として理解している人がもういない、変更にかかるコストがシステムが生み出す価値を上回るペースで増えていく、そして新しいシステムやデータとつながらない——この3点です。
刷新が必要になる時期は、システムが壊れたときではありません。多くの老朽化したシステムは、最後の日まで安定して動き続けます。その時期は、3本の曲線が交差したときに訪れます。保守コストが上がり、保守できる人の数が減り、サポート終了（EOL）の期限が近づく、という3本です。
本記事は、レガシーシステムをどう移行するかを論じるものではありません。その前段にある問い——自社の既存システムは本当に「問題」なのか、問題であるならどれほど緊急なのか——にお答えします。自社のレガシーシステムを自己評価するための測定可能な4つのシグナル、ブラックボックス化の度合いを確かめるチェックリスト、そして経営層に上げる際に課題を財務の言葉で表現する方法をお持ち帰りいただけます。
お忙しい方向けの要約: 見分けるための3つの兆候 — 判断のための4つの定量シグナル — そして1つの原則。先延ばしはコストを据え置きにしません。先延ばしは対象範囲を膨らませます。
レガシーシステムとは？年数ではなく「症状」で定義する
「システムは何年経つとレガシーシステムと見なされるのか」という問いは、そもそも立て方が誤っています。実際のコンサルティングの現場では、18年稼働していながら極めて健全に運用されているシステムもあれば、納品から3年で、業界の文献が「レガシー」と呼ぶ状態にちょうど陥ってしまったシステムもあります。
レガシーシステムを見分ける3つの兆候
ツールを使わず、いますぐ使える見分け方です。
- 理解できない — システムが何をしているのかを網羅的に説明できる人も、資料も存在しない。知識はコードの中と、数名の記憶の中に散らばっている。
- 妥当なコストでは直せない — 小さな業務変更にも長い調査と広範なテストが必要で、他の箇所を壊すリスクが常について回る。
- つながらない — APIが提供されておらず、データはファイルやバッチ処理でしか取り出せないため、新しい連携がすべて不相応に高くつく。
この3つのうち2つが同時に現れていれば、そのシステムはすでにレガシーシステムの部類に入っており、本気で再評価する必要があります。
レガシーシステムでは「ない」3つのケース
この節は前節と同じくらい重要です。レガシーシステムを評価する際の高くつく誤り——まだ健全なシステムを、古いという理由だけで置き換えてしまうこと——を防いでくれるからです。
- 稼働15年、ドキュメントが揃っており、自動テストがあり、保守できる人が3名以上いる → レガシーシステムではありません。 それは単に成熟したシステムです。置き換えコストが便益を上回る可能性がほぼ確実です。
- 古い言語を使っているがベンダーサポートは継続中、業務範囲も安定しており、新規連携の必要もない → まだ刷新は不要です。正しい選択は、EOLの時期を追いながら現状を維持することかもしれません。
- 稼働3年、納期に間に合わせるために急いで書かれ、ドキュメントがなく、たった1人の開発者に依存している → 保証期間内であっても、すでにレガシーシステムです。
この3ケースから、覚えておく価値のある一文が導かれます。レガシーとは「経過年数」ではなく「マネジメントの状態」である。 実務上の帰結として、新しいシステムをわずか24か月でレガシーシステムに変えてしまうこともできますし、逆に、ドキュメント・テスト・理解している人数を十分に維持できれば、20年経ったシステムを健全なまま保つこともできます。
より詳細な定義と技術的な分類が必要な場合は、レガシーシステムとは — 定義と典型的な5つの課題でシステムの類型ごとに掘り下げています。
自社のシステムがレガシーシステムだと分かったら、次の問いはこうです。それはどこで損失を生んでおり、どの損失が最も大きいのか。
レガシーシステムの4つの課題領域 — 最もコストが大きいのはどれか
レガシーシステムの課題が単独で現れることは稀です。それらは積み上がっていきます。そして厄介なのは、その大半がゆっくりと、着実に進行し、組織を行動させるほど大きな障害を起こさない点です。
運用の課題：動いてはいるが、誰も触りたがらない
レガシーシステムに特徴的な症状は、システム停止ではなく凍結です。古いモジュールは触れてはいけない領域になります。直す必要があることは誰もが分かっていて、誰も直す当事者になりたがりません。
これに伴い、障害発生時の復旧時間も長引きます。ドキュメントもテストもないため、原因の切り分けは個人の経験に完全に依存します。つまり、その「当の本人」がその場にいるかどうかに依存するということです。
コストの課題：「運用」予算が「変革」予算を食いつぶす
レガシーシステムの課題の中で最も測りやすく、同時に稟議書で最も見落とされやすいのがこの領域です。レガシーシステムを抱える組織のコスト構造は、たいてい次のように推移します。
- 保守コストは急騰せず一定のペースで増えていくため、どのアラートも鳴らない。
- 影響範囲を誰も断言できないため、小さな変更のたびに必要以上に広い調査とテストが求められる。
- EOL後の延長サポート契約は、標準サポートの何倍もの価格になる。
結果として、「守りのIT（ラン・ザ・ビジネス）」に配分される予算比率が徐々に上がり、「攻めのIT（チェンジ・ザ・ビジネス）」に残る分が縮んでいきます。そして組織は、成長を生む取り組みに投資する力を失っていきます。
コンプライアンスとセキュリティの課題：EOLは動かせない期限
レガシーシステムの土台となるプラットフォームのサポートライフサイクルには、交渉の余地がありません。日本での典型例を挙げると、多くの基幹システムの基盤となっているSAP ERP 6.0（ECC 6.0）の標準サポートは2027年末に終了します。
その時期を過ぎると、企業はセキュリティパッチも、法改正に伴うコンプライアンス更新も受け取れなくなります。問題は、基幹システム規模のプロジェクトが12か月未満で完了することは稀だという点です。つまり、2027年のEOLは実質的に「2026年中の意思決定期限」を意味します。
人材の課題：知識は人と一緒に去っていく
経済産業省（METI）は、2030年時点で日本のIT人材が約79万人不足すると試算しています。中でも減少が最も激しいのが、COBOL・RPG・VB6といった旧世代の言語を理解する層です。
レガシーシステムにおいて、ベテランエンジニアが1人辞めることは、単に1名の人員を失うことではありません。システムの地図の一部——どこにも記録されたことのない部分——を永久に失うことです。
では、最もコストが大きい課題はどれか
レガシーシステムの4つの課題領域を「目立ちやすさ」で並べれば、運用が首位に来ます。障害は誰の目にも見えるからです。しかし実際の財務インパクトで並べると、順序は逆転します。
| 課題領域 | 気づきやすさ | 財務インパクト | 稟議書に登場するか |
|---|---|---|---|
| 運用（障害・停止時間） | 高い | 中程度 | する |
| コンプライアンス／セキュリティ（EOL） | 中程度 | 高い（ただし期限次第） | する |
| 人材 | 中程度 | 高く、かつ増大していく | まれ |
| 機会損失 | 低い | 最も高い | ほぼしない |
レガシーシステムで最も高くつくのは機会損失——システムが許さなかったために実行できなかった事業変更の価値——です。開けなかった販売チャネル、断らざるを得なかったパートナー連携、市場投入が2四半期遅れた製品。
この金額はどの請求書にも載らないため、予算の稟議に含まれることはほぼありません。レガシーシステム刷新の提案が先送りされがちな理由もここにあります。提案が「技術的な支出」として語られてしまい、「事業の制約を取り除く投資」として語られていないのです。
ブラックボックス化：システムの知識がコードと数名の中にあるとき
いま挙げたレガシーシステムの4つの課題領域の背後に立ち、その4つすべてを悪化させている現象があります。ブラックボックス化です。システムは正しく動いているのに、なぜそう動くのかを誰も十分に説明できない状態を指します。
ブラックボックスはどう生まれるか
自社のシステムを意図的にブラックボックスにする組織はありません。それは、その時々では合理的だった判断の積み重ねから生まれます。
- 急ぎの要件をクイックな修正で処理し、ドキュメントは後で更新することにした——そして「後で」は永遠に来ない。
- アプリケーション層を直すより速いからと、業務ルールをストアドプロシージャに直接埋め込んだ。
- 夜間バッチに例外処理を追加し、その存在を知るのは書いた本人だけになった。
これを10〜20年繰り返すと、設計ドキュメントは実際の運用から少しずつ離れていきます。そしてある時点で、ソースコードが唯一まだ正しい仕様書になります。 しかしソースコードは、その背後にある業務上の意図を説明してくれません。
ブラックボックス化がもたらす4つの具体的な帰結
ブラックボックスが危険なのは、組織がレガシーシステムから抜け出そうとするときにまさに必要となることを、ちょうど塞いでしまう点です。
- 課題設定ができない — 本当の対象範囲が分からなければ、意味のあるRFP（提案依頼書）は書けません。
- 見積もりを評価できない — 3社のベンダーが数倍違う数字を出してきたとき、どれが妥当なのかを判断する材料がありません。
- 変更に踏み切れない — あらゆる修正が定量化できないリスクになるため、安全な選択は常に「何もしない」になります。
- IT資産を評価できない — M&A、組織再編、運用移管の場面において、説明できないシステムは大きくディスカウントされる資産です。
言い換えれば、ブラックボックス化は技術的な問題にとどまりません。企業が自社のシステムに対する意思決定権を失う原因そのものです。
自己診断：あなたのレガシーシステムはどこまでブラックボックスか
以下の6問に「はい／いいえ」でお答えください。「いいえ」1つにつき1点です。
- 直近24か月以内に更新されたシステムアーキテクチャのドキュメントはありますか。
- 主担当者が3か月不在になっても、残るチームで計算ルールを1つ変更できますか。
- 稼働中のバッチジョブの完全な一覧と、各ジョブの目的の説明はありますか。
- どのシステムと、どのプロトコルでデータを交換しているかを正確に把握していますか。
- 修正後にシステムが正しく動くことを確認できる自動テストはありますか。
- 平均的な変更の工数を見積もるとき、誤差は±30%の範囲に収まりますか。
結果の読み方
| 点数 | 状態 | 意味 |
|---|---|---|
| 0〜1点 | まだ統制できている | 古いが健全なシステム。ドキュメントとテストの維持を優先。 |
| 2〜3点 | 属人化が進んでいる | リスクが数名に集中。人を失う前にドキュメント化が必要。 |
| 4〜6点 | すでにブラックボックス | 本格的なシステム評価を経るまで、大きな投資判断をすべきではない。 |
3つ目の区分に入った場合、重要な結論は「すぐにシステムを替えるべき」ではありません。結論はこうです。この時点で提示されるコスト・期間・リスクのあらゆる数字は推測にすぎない——社内のチームが出した数字であっても同じです。
ブラックボックス化はレガシーシステムの修正を妨げます。しかしそれは、2026年の計画で多くの企業がより高い優先度を置いているもう1つのこと——AIの実運用への組み込み——も同時に妨げます。
なぜレガシーシステムがData＆AI活用を阻むのか
長く「技術的な作業」に分類されてきたレガシーシステムと刷新というテーマが、この2年で経営会議の議題に戻ってきた理由がここにあります。
AIの取り組みが失敗するのは、モデルではなくデータと連携点
企業のAIプロジェクトが前に進まないとき、原因がモデルの品質にあることは稀です。たいていは、次の3つの非常に具体的な場所にあります。
- データをリアルタイムに取り出せない — 独自フォーマットや旧バージョンのデータベースに閉じ込められ、バッチでしか抽出できない。
- APIがない — すべての連携が中間ファイルとバッチ処理を経由し、遅延は時間単位・日単位になる。昨日のデータをもとに答えるAIアシスタントは、実務では使えません。
- 業務ロジックが明示されていない — 業務ルールを機械可読な形で記述できる人がいないため、AIやエージェントに安全に再利用させることができません。
端的に言えば、自社でまだ理解できていないシステムを、AI化することはできないのです。
システムが「AIレディ」と言えるための最低4条件
「このシステムは新しいか」と問う代わりに、より使える問いは「このシステムはAIが活用できる条件を満たしているか」です。
- アクセスできる — データを手作業のエクスポートではなく、APIや標準的な接続方式で取得できる。
- 定義が統一されている — 同じ業務概念が、システム間で同じ定義になっている。「アクティブな顧客」の算出方法が3か所で3通りあれば、あらゆる分析がずれます。
- 文脈がある — 業務ルールが機械可読な形で文書化され、それがどこで実装されているかまで追跡できる。
- 統制がある — 権限管理、アクセスログ、追跡可能性が、AIを実験ではなく実際の業務プロセスに組み込めるレベルで備わっている。
典型的なレガシーシステムは、この4条件のどれも満たしていません。AIの取り組みがPoC段階で止まりがちな理由もこれです。手作業で抽出したデータの上でPoCを回すことはできても、日々の運用に載せることはできないのです。
これは、レガシーシステム刷新とData＆AI戦略が、予算を争い合う2つの別プロジェクトではなく、同じ軸の上に置かれるべき理由も説明します。刷新の過程で行うドキュメント化とデータの開放こそが、その後のあらゆるAI施策が再利用する土台になります。
レガシーシステムの刷新時期を示す4つの定量シグナル
レガシーシステムを替えるべきか否かという社内議論が長引く最大の理由は、双方が感覚で語っていることです。以下の4つのシグナルは、この議論を情報システム部門と財務部門の双方が読める数字へと移します。
| # | シグナル | 測り方 | 推奨する警戒しきい値 |
|---|---|---|---|
| 1 | 保守予算の比率 | 「運用（ラン）」費用 ÷ IT予算総額 | 約70%を超え、かつ3年連続で上昇 |
| 2 | 保守できる人の数 | 中核モジュールごとに人数を数える | 中核モジュール1つあたり2名以下 |
| 3 | EOLまでの残り期間 | 基盤コンポーネントごとにライフサイクルを確認 | 24か月未満 |
| 4 | 小さな変更のリードタイム | 依頼受領から本番リリースまで | 週単位ではなく月単位 |
注：上記のしきい値は業界慣行に基づく参照値であり、社内議論を始めるためのものです。自社に適したしきい値は、規模・業種・リスク許容度によって変わります。
自己採点と結果の読み解き方
使い方は単純です。しきい値を超えたシグナルの数を数えます。
- 0〜1個 — レガシーシステムはまだ緊急度が高くありません。やるべきことは定期的なモニタリングと、特に1人しか理解していないモジュールのドキュメント補完です。
- 2個 — システム評価（アセスメント）と計画づくりに着手すべき段階です。大きな予算の確約はまだ必要ありません。
- 3〜4個 — すでにリスク領域です。留意点は、シグナル3（EOL）がしきい値に達した瞬間、時期を選ぶ権利を失うことです。スケジュールを決めるのは自社ではなく、プラットフォームのベンダーになります。
実務で最も過小評価されているのは、シグナル2とシグナル4です。どちらも障害を起こしませんが、どちらも、事業が求めるスピードでシステムを変える力を組織が失ったことを示すサインです。
もう1年待つことの代価
レガシーシステム刷新を先送りする最も一般的な論法は「次の会計年度に回そう」です。この論法は、1年待ってもコストは変わらない、という誤った前提の上に立っています。
実際には、1年の先延ばしごとに、問題は3つの方向で難しくなります。
- 対象範囲が膨らむ — システムは修正され続け、パッチ1つごとに、後で分析し移行しなければならない部分が増えます。
- 理解している人材が薄くなる — 定年退職や転職で1人抜けるたびに地図の一部が消え、それはお金で買い戻せません。
- 時間の窓が狭くなる — EOLが近づくにつれ、選択肢は「最良の方式を選ぶ」から「納期に間に合う方式を選ぶ」へと狭まり、納期に間に合う方式は常に高くつきます。
国家レベルでは、経済産業省がDXレポートの中で、既存システムの複雑化・老朽化・ブラックボックス化が解消されなければ、2025年以降、年間で最大12兆円の経済損失が生じ得ると警告しました。「2025年の崖」としてよく知られる数字です。
企業レベルでは、この数字はもっと静かな形で現れます。「攻めのIT」予算が、毎年少しずつ縮んでいくという形で。
費用のかからない最初の一歩
シグナルを2つ以上数えた方にとって、次の合理的な行動は予算申請ではなく、自社システムの実データを取ることです。HBLABでは期間限定でAIアセスメントツールを無償提供しています。ソースコードをZIP形式でアップロードいただくと、コード構造・依存関係・移行難易度・リスクの分析レポートを24時間以内にお返しします。事前の打ち合わせは不要、ファイルは3日後に自動削除されます。
→ 無償AI診断に申し込む
課題の特定から対応ロードマップへ — どこから始めるか
ここまでで、自社のシステムが本当に対処すべきレガシーシステムだと判断できたとしましょう。本記事の最後の問いは、次の段階の入口となる問いです。予算の全額をいますぐ確約せずに、どこから始めればよいのか。
原則：まず理解し、次に定量化し、それから範囲を決める
この段階で最も多い誤りは、自社のレガシーシステムを理解する前に方式を選んでしまうことです。「Javaで書き直す」「クラウドに載せる」といった判断が、システムの中身に関するデータが1つもない状態で、会議の場で下されるプロジェクトは非常に多くあります。
その帰結はほぼ例外なく同じです。途中で対象範囲が膨らみ、コストが見積もりを超え、追加分が契約に含まれるかどうかで両者が揉めます。
正しい順序は逆です。システムを理解する → 範囲とリスクを定量化する → そのうえで部分ごとに方式を選ぶ。 モジュールごとに選べる方式は複数あります——現状維持、インフラ移行、リファクタリング、書き直しまで。詳細な選択肢の一覧と導入ロードマップの全体像は、System Modernization：レガシーシステムから発展可能な基盤へで解説しています。2つの概念の違いで迷っている場合は、ModernizationとMigrationの違いとMigrationとはが、それぞれの適用範囲を明確にしています。
HBLABのアプローチ
HBLABはMigration Solution（Powered by Migurei）を、まさにこの順序に沿って設計しました。全体を通じる原則は1つ——スピードはAIから、信頼性は人から。 AIが読解・ドキュメント化・機械的な変換を大規模に処理し、エンジニアとBA/SAがアーキテクチャを決定し、業務ルールを確認し、品質に責任を持ちます。
本記事で挙げたレガシーシステムの課題に直接対応する3点です。
- データ化によるブラックボックス対策。 変換の過程で30種類以上のドキュメントを納品します。形式と内容の両面でAIフレンドリーに設計されており、機械可読で、用語が統一され、要件 → コード → テストまで一貫して追跡できます。目的はシステムの移行を終えることだけではなく、移行後の資産が再びブラックボックス状態に戻らないようにすることです。
- LOCによるコストの定量化。 移行範囲をコード行数（LOC）に換算するため、予測コストは勘ではなく測定可能な根拠に基づきます。これにより、一括承認を待つのではなく、会計年度ごとの予算に合わせて範囲を分割し、優先順位をつけられます。
- 小さく始めて、リスクを下げる。 ロードマップは3ステップです。全体像を掴む無償AI診断 → 実現可能性を検証する小規模PoC → より大きな範囲へ段階的に拡大。
効果の面では、繰り返し作業（読解、ドキュメント化、骨格部分の変換）の自動化により、手作業と比べて工数を30〜50%削減し、アセスメントとドキュメント化のフェーズの期間を約40%短縮します。（HBLABの実績に基づく参考値です。対象言語、コード規模、個別の要件によって変動します。）
その基盤にあるのは、10年以上にわたる日本市場での実績、630名を超えるエンジニア組織、そしてISO/IEC 27001（ISMS）、CMMIレベル3、プライバシーマーク（Pマーク）の各認証です。これまでの導入事例はHBLABの導入事例ページでご覧いただけます。
次はどの記事へ
いま最も気にかかっている問いに応じてお選びください。
| こんな方は… | 次に読む記事 |
|---|---|
| システム現代化の全体ロードマップを知りたい | System Modernization — 完全ロードマップ |
| ModernizationとMigrationの違いを整理したい | ModernizationとMigrationの違い |
| 移行（Migration）の範囲を知りたい | Migrationとは |
| レガシーシステムの定義から確認したい | レガシーシステムとは — 定義と典型的な5つの課題 |
同じテーマの他の記事はHBLABのブログ、ツール群についてはMigureiもあわせてご覧ください。
次の3ステップ
1. 無償AIアセスメントツールに申し込む — 24時間以内にレポート
2. Migration Solutionの詳細を見る
3. HBLABに相談する
よくあるご質問
レガシーシステムが安定して動いているなら、刷新は不要ではありませんか。
安定は安全と同義ではありません。レガシーシステムは、ベンダーがサポートを終了する日、あるいは最後の保守担当者が退職する日まで、非常に安定して動き続けることがあります。障害の発生回数ではなく、上記の4つの定量シグナルで評価してください。
何年経つとレガシーシステムと見なされますか。
年数の基準はありません。15年経っていてもドキュメントが揃い保守できる人が複数いれば健全ですし、3年でもドキュメントがなく1人に依存していれば、すでにレガシーです。
設計ドキュメントが残っていないレガシーシステムでも対応できますか。
できます。そして実務では、これが最も多いケースです。ドキュメントはソースコード、データベース、バッチ処理から再構築でき、その後、業務部門と突き合わせてどのルールがまだ有効かを確認します。
EOLが近い場合、暫定的にパッチを当てるべきか、完全に置き換えるべきか。
延長サポート契約で時間を買うことはできますが、コストが高く、根本的な解決にはなりません。すでにある刷新計画を完了させるための緩衝期間として使う場合にのみ合理的で、先延ばしを続けるための手段としては合理的ではありません。
経営層に予算を承認してもらうにはどうすればよいですか。
技術の言葉ではなく、財務の言葉で示してください。最も重みを持つ事実は3つです。各構成要素の具体的なEOL時期、直近3年間の「守り（ラン）」対「攻め（チェンジ）」の予算比率の推移、そして現行システムが理由で止まっている事業施策の一覧です。
レガシーシステム刷新の費用は、何を基準に見積もられますか。
最も透明性の高い基準は、コード規模（LOC）にモジュール種別ごとの複雑度係数を掛け、アセスメント・テスト・データ移行の費用を加えたものです。アセスメント前に出るあらゆる数字は、概算にすぎません。
まとめ
本記事では、レガシーシステムを抱える組織が技術的な方式を論じる前に答えるべき4つの問いを見てきました。自社のシステムは危険な意味で本当にレガシーシステムなのか、4つの課題領域のどれが損失を生んでおり、どれが最もコストが大きいのか、ブラックボックス化はどこまで進んでいるのか、そして現行システムはData＆AI活用を阻んでいないか。あわせて、社内の議論を感覚から数字へ移すための4つの定量シグナルもご紹介しました。
最も記憶に留めていただきたいのは、次の2文です。レガシーとは「経過年数」ではなく「マネジメントの状態」である——そして先延ばしはコストを据え置きにしない。先延ばしは対象範囲を膨らませる。
シグナルを2つ以上数えた方にとって、次の合理的な一歩は、予算申請ではなく自社システムの実データを取ることです。HBLABは、レガシーシステム刷新の道のりにおける最初の評価の段階から、企業に伴走します。
