レガシーシステム可視化の全手法｜AI活用の進め方と成功事例を解説

【１分でわかるこの記事の要約】

• 可視化は「脱却」への絶対条件： 仕様書がなく、特定のベテランに依存した「ブラックボックス」状態では、DXも移行計画も立てられません。現行システムが「何（What）」を「なぜ（Why）」行っているかを紐解くことが全ての出発点です。

• 「AI×ベテラン」が従来の常識を覆す： かつて数千万円・１年を要した資産解析も、最新AIによる高速解析と、熟練技術者（平均57歳）の知見を掛け合わせることで、コスト・期間ともに従来の1/10で完了可能です。

• 「攻め」と「守り」の資料を使い分ける： 移行計画のための「要件定義書（攻め）」と、属人化を防ぐための「詳細設計書（守り）」を整理。可視化によって、経営層が納得する精度の高い投資判断と、持続可能な保守体制を同時に実現します。

「仕様書がない」「このシステムを理解しているのは、あと2年で定年を迎えるAさんだけ」——ブラックボックス化したレガシーシステムを前に、手をこまねいている企業は少なくない。

レガシーシステムの可視化とは、システムの構造・仕様・業務ロジックを解き明かし、ドキュメントとして再現する取り組みだ。モダナイゼーションもマイグレーションも、出発点はここにある。仕様が見えなければ、移行計画は立たない。RFPすら書けない。

IPA「2024年度ソフトウェア動向調査」によれば、レガシーシステムを使い続けている企業は56.6%。経済産業省の調査でも約61%が未対応のままだ。可視化の必要性を認識しながらも、「コストが読めない」「ベテランの手が空かない」と先送りしている現場が大半である。

この記事では、手動・ツール・AIの3つのアプローチを比較し、ASIS分析（現行分析）の進め方を6ステップで整理する。さらに、AI×ベテラン人材の融合で従来の1/10のコスト・期間を実現した事例も紹介する。

レガシーシステムの可視化とは？定義と全体像

レガシーシステムの可視化とは、長年の運用でブラックボックス化したシステムの構造・仕様・業務ロジックを明らかにし、ドキュメントとして再現するプロセスを指す。単にソースコードを読むだけの作業ではない。プログラムが「何をしているか」だけでなく、「なぜその処理が必要なのか」という業務意図まで紐解くことが、本質的な可視化だ。

レガシーシステムの定義と全体像を把握した上で、ここでは「可視化」に焦点を絞って解説する。

可視化の対象範囲

可視化が対象とする領域は、主に5つに分かれる。

• ソースコード: プログラムの構造、モジュール間の呼び出し関係、条件分岐のロジック

• データ構造: テーブル定義、ファイルレイアウト、データフロー

• 業務フロー: 業務プロセスとシステム処理の対応関係

• 外部連携: 他システムとのインターフェース仕様、EDI接続、API呼び出し

• 依存関係: プログラム間・モジュール間の影響範囲マップ

この5領域を網羅的に把握してはじめて、「このシステムを動かしている全体像」が見えてくる。

可視化で得られる成果物——「攻めの資料」と「守りの資料」

可視化の成果物は、目的によって2つに分類できる。

「攻めの資料」（DX検討用）

• 要件定義書: 現行システムの業務要件を整理し、モダナイゼーション計画の基盤とする

• 業務フロー図: TO-BE設計の出発点となる現行業務の全体像

「守りの資料」（保守用）

• 詳細設計書: プログラム単位の処理内容を記録し、保守作業の属人化を防ぐ

• テスト仕様書: 改修時の影響確認に使用する。回帰テストの基準にもなる

この「攻め」と「守り」の区分は、可視化プロジェクトのスコープを決める際に極めて有効だ。「何のために可視化するのか」を明確にすることで、成果物の粒度と優先順位が定まる。

なぜレガシーシステムの可視化が必要なのか——5つの理由

レガシーシステムの可視化は、モダナイゼーションの「前工程」ではない。可視化そのものが、企業のIT戦略を左右する重要な意思決定の土台となる。

理由1: 仕様がブラックボックス化している

仕様書が存在しないケースは珍しくない。存在していても、長年の改修内容が反映されておらず「5年前のバージョン」のまま放置されている例が大半だ。ブラックボックス化の原因と解消方法については別記事で詳しく整理している。

現場ではこう語られることが多い。「ドキュメントはある。ただし、それは10年前のもので、今のシステムとは別物になっている」。結果として、システムの仕様は特定のベテラン社員の頭の中にしか残っていない状態が常態化する。

理由2: ベテラン退職による技術継承の断絶

COBOL、RPG、PL/Iといったレガシー言語を読み書きできる技術者は、高齢化が進んでいる。IPA「2024年度ソフトウェア動向調査」によると、レガシーシステムを現在も使用している企業は56.6%。一方で、これらの言語を扱えるエンジニアの多くは50代後半から60代だ。

若手エンジニアがレガシー言語を新たに習得する動機は乏しく、協力会社でも人材確保は年々困難になっている。ベテランが退職すれば、業務知識ごと消滅する。可視化は、この「暗黙知の消失」に対する唯一の防衛手段といえる。

理由3: モダナイゼーションの前提条件

レガシーシステム移行の進め方でも解説したとおり、移行プロジェクトが頓挫する最大の原因は「現行仕様の把握不足」にある。

仕様が見えないまま移行に着手すれば、テスト工程で想定外の業務ロジックが続出し、手戻りが発生する。可視化を省略した脱却プロジェクトは、暗闘の中を手探りで進むようなものだ。

理由4: 保守コストの肥大化

IT予算の約80%が既存システムの維持・保守に消費される——レガシーシステムのコスト構造の根幹にあるこの問題は、経済産業省のDXレポート以降も改善されていない。

仕様が不透明なシステムほど、保守工数は膨らむ。影響範囲が読めないため、小さな改修にも慎重なテストが必要になり、工数は倍増する。可視化によって影響範囲を把握できれば、保守の効率は大幅に改善する。

理由5: 経営層への説明・稟議通過に不可欠

「レガシーシステムをどうにかしたい」——IT部門がそう考えても、経営層に説得力のある稟議を通すには定量的な根拠が要る。

経済産業省「レガシーシステムモダン化委員会」総括レポート（2025年5月）によれば、CxO（CDO/CIO/CTO）を設置している企業ほど、可視化とモダナイゼーションが進んでいる。経営層を動かすには、「何がどう問題なのか」を可視化した資料が必要であり、それ自体が可視化プロジェクトの成果物となる。

レガシーシステムの可視化方法——手動・ツール・AIの3つのアプローチ

可視化の方法は大きく3つに分かれる。それぞれの特性を理解し、自社の状況に合った選択をすることが重要だ。

手動解析——ソースコードリーディング＋ヒアリング

最もオーソドックスな手法。技術者がソースコードを1行ずつ読み解き、業務担当者へのヒアリングを重ねながら仕様書を作成する。

強み: 業務コンテキストまで踏み込んだ理解が可能。「なぜこの例外処理が入っているのか」といった経緯も把握できる。

弱み: 膨大な工数と期間を要する。数千本規模のプログラムでは半年から1年以上。技術者個人の力量に依存するため、品質のばらつきも生じやすい。

ツール活用——静的解析・構造可視化

Understand（テクマトリックス）やChangeMiner（アシスト）などの解析ツールを使い、ソースコードの構造を機械的に可視化する手法。

強み: コールツリー、モジュール間依存関係、デッドコードの検出など、定量的な分析が得意。人手では見落としがちな依存関係も網羅できる。

弱み: コードの「構文」は解析できるが、「意味」——つまり業務ロジックの背景や設計意図——までは読み取れない。ツールの出力を解釈し、業務仕様に落とし込むには結局人間の作業が必要になる。

AI活用——LLMによるリバースエンジニアリング

生成AI（LLM）を活用し、ソースコードからプログラムの処理内容を自然言語で記述する手法。2024年以降、急速に実用化が進んだ領域だ。

強み: 大規模コードベースでも高速に処理できる。ドキュメントの自動生成が可能なため、工数を劇的に圧縮できる。

弱み: AIは統計的にコードを解釈するため、業務固有の例外処理や歴史的経緯を正確に読み取ることには限界がある。AI出力の正確性を検証する「人間の目」が不可欠だ。

【比較表】手動 vs ツール vs AI

比較表が示すとおり、単独のアプローチにはそれぞれ弱点がある。AIの処理速度とベテラン技術者の業務理解を掛け合わせた「融合アプローチ」が、コスト・期間・精度のすべてを高い水準で両立する選択肢だ。

「仕様がわからない」を解決する、新しいアプローチ。

独自AI「ARIADNE」× 精鋭部隊「TITANS」（平均年齢57歳）が、レガシーシステムの仕様を可視化します。まずはお気軽にご相談ください。

無料相談はこちら →

ASIS分析（現行分析）の進め方——6つのステップ

ASIS分析（AS-IS分析）とは、「現状のシステムがどうなっているか」を体系的に解明するプロセスだ。可視化プロジェクトの中核をなすこの工程を、6つのステップに分けて整理する。

ステップ1: IT資産の棚卸し

対象システムの全体像を把握する工程。プログラム本数、使用言語、実行基盤、データベース構成を一覧化する。

ここで重要なのはスコープの定義だ。すべてのシステムを一度に可視化する必要はない。業務影響度やベテラン退職のタイムラインを考慮し、優先度の高いシステムから着手する判断が求められる。

ステップ2: ソースコード解析

プログラムの構造を読み解く工程。静的解析ツールやAI解析を組み合わせ、モジュール構成、呼び出し関係、条件分岐のロジックを把握する。

COBOL、RPG、PL/I、アセンブラといったレガシー言語の場合、対応できる解析ツールが限られる点に注意が必要だ。特にRPGやアセンブラに対応したAI解析は、選択肢が極めて少ない。

ステップ3: データ構造の可視化

テーブル定義、ファイルレイアウト、データフロー、外部連携のインターフェースを整理する。

レガシーシステムではデータ構造の変遷が記録されていないことが多い。カラムの追加理由や、使われなくなったテーブルの経緯を知る人が退職していれば、データ構造の全容把握は一段と難しくなる。

ステップ4: 業務ロジックの抽出

プログラムの「処理の意味」を読み解く、最も難易度が高い工程。コードの構文解析では把握しきれない「なぜこの計算式なのか」「この例外処理はどの業務要件に起因するのか」を特定する。

この工程こそ、レガシー言語に精通したベテラン技術者の知見が不可欠となる領域だ。業務ヒアリングとソースコード解析を並行で進め、AIの出力に業務コンテキストを付与することで精度が上がる。

ステップ5: ドキュメント生成

ステップ1〜4で得た情報を、目的に応じた形式の成果物に落とし込む。

• 要件定義書（攻めの資料）: モダナイゼーション計画のインプットとなる

• 詳細設計書（守りの資料）: 日常の保守作業で参照する

• テスト仕様書（守りの資料）: 改修時の回帰テスト基準として使用する

AI活用により、ドキュメント生成の工数は従来比で大幅に圧縮できる。ただし、AIが生成したドキュメントの精査・修正は人間が行う必要がある。

ステップ6: ステークホルダーへの報告と計画策定

可視化結果をもとに、経営層やプロジェクトオーナーに報告する。報告資料には以下を盛り込む。

• 現行システムの全体構成と課題の整理

• モダナイゼーションの選択肢と推奨案

• 概算コスト・期間・リスクの見積もり

• ロードマップ案

可視化はゴールではなく、次のアクション（マイグレーション、リビルド等）の起点だ。「現状がこうなっている。だからこう進めるべき」という意思決定の材料を提供するのが、ASIS分析の最終的な役割である。

AI × ベテラン人材——可視化の新しいアプローチ

レガシーシステムの可視化において、AIとベテラン人材の「融合アプローチ」が新たな選択肢として確立されつつある。ここでは、なぜ単独のアプローチでは不十分なのか、そして融合がどのような成果を生むのかを掘り下げる。

AIだけでは不十分な理由

AIはソースコードの構文を高速に解析し、処理内容を自然言語で記述できる。だが、その記述は「コードが何をしているか」の説明にとどまることが多い。

実際のレガシーシステムには、コードだけでは読み取れない情報が埋め込まれている。例えば、「この消費税計算ロジックは2019年の税制改正時に追加されたが、旧ロジックも残されている」「このフラグは年末一括処理でのみ使用され、普段はデッドコードに見える」といった歴史的経緯や業務背景だ。

AI単独では、こうした「なぜ」の部分を正確に読み解くことが難しい。出力に誤りや抜け漏れが混入するリスクを、常に想定しなければならない。

ベテラン人材だけでも不十分な理由

ベテラン技術者は業務ロジックの「意味」を理解している。長年の経験に裏打ちされた暗黙知は、どんなツールにも代替できない価値を持つ。

しかし、人力による可視化には限界がある。数千本のプログラムを1本ずつ読み解く作業は、工期と費用の面で現実的ではない。プログラム本数が数万本に達すれば、物理的に不可能だ。加えて、ベテラン技術者自身が高齢化しているため、「可視化を進めている間にベテランが退職する」というリスクも無視できない。

融合アプローチの強み——ARIADNE × TITANS

AI×ベテラン人材の融合アプローチは、双方の弱点を補い合う設計になっている。

独自AI「ARIADNE」の役割

ARIADNEは、プログラムの構文解析にとどまらず「処理の意味付け」まで行う独自のAIだ。一般的なLLMとの最大の違いは、シニア技術者の暗黙知——長年の現場経験から得られた業務理解のパターン——を学習している点にある。COBOL、RPG、PL/I、アセンブラに対応し、数万本規模のプログラムでも約1ヶ月で解析を完了する。

精鋭部隊「TITANS」の役割

TITANSは、22,000名超の人材データベースから厳格なスコアリングで選抜された上位1.3%、約300名の精鋭だ。平均年齢57歳。COBOL、RPG、PL/I、アセンブラを現役で扱えるエンジニアで構成されている。

TITANSの役割は、ARIADNEが出力したドキュメントの精査・修正、業務ヒアリングによるコンテキスト付与、SIerや保守ベンダーとの折衝。AIの「速度」とベテランの「深さ」を掛け合わせることで、精度の高い成果物を短期間で完成させる。

コスト・期間の実績値

• コスト: 従来の人力解析と比較して1/10

• 期間: 数万本のプログラムでも約1ヶ月で完了

• 対応言語: COBOL、RPG、PL/I、アセンブラ

成果物の二分類——「攻めの資料」と「守りの資料」

ARIADNE × TITANSによる可視化では、成果物を目的別に使い分ける。

「攻めの資料」はモダナイゼーションの起点として使い、「守りの資料」はベテラン退職後も保守を継続するための基盤として使う。この目的別の設計により、「可視化は終わったが、何に使えばいいかわからない」という事態を防げる。

従来の1/10のコストで、レガシーシステムを可視化。

数万本規模のプログラムでも約1ヶ月で完了します。22,000名超の人材DBから厳選した上位1.3%の精鋭が対応。

詳しくはこちら → ｜ 資料をダウンロード →

レガシーシステム可視化の成功事例

実際のプロジェクトで、可視化がどのように進められたのか。課題の異なる2つの事例を紹介する。

事例1: 富士通メインフレームCOBOL——テスト仕様書・保守ドキュメント自動生成

課題: 大手メーカーが、富士通メインフレーム上のCOBOLアプリケーションをオープン環境上のNetCOBOLへストレートコンバージョンするプロジェクトを推進していた。ところが統合テストフェーズで、完全に乗り換えられない資産が続出。プロジェクトの期限は迫り、追加コストの投入余地も限られていた。

対応: AIを用いてテスト仕様書と保守用プログラム仕様書を自動生成。TITANS（COBOL）6名がAI出力を精査・修正し、SIer・保守ベンダーとの成果物に対する折衝も担当した。

体制: PM + AI担当 + PMO + TITANS（COBOL）6名

成果: 限られた期間とコストの中で、テスト仕様書と保守ドキュメントを完成。移行後の保守体制も、生成された「守りの資料」をベースに構築できた。

事例2: 三菱オフコンProgress2——「解析不可能」を覆した全ASIS解析

課題: 三菱オフコン上に稼働するProgress2（P2）アプリケーション。本数は5万本超、外部システムとEDI接続。仕様は完全にブラックボックス化し、複数のベンダーから「解析不可能」と判断されていた。外部連携部分はリビルドのみでは対応できず、可視化が不可避だった。

対応: AIによる全ASIS解析を実施。P2言語を読解できるTITANS 2名が業務ヒアリングを並行で進め、AIの出力と照合しながら外部連携仕様書を作成した。

体制: PM + AI担当 + PMO + TITANS（P2）2名

成果: 「解析不可能」とされたシステムの全容を可視化。外部連携先を含めたリビルド計画の策定が可能になった。5万本超という規模でありながら、AI×少数精鋭のTITANSで完遂した点は、融合アプローチの威力を示す事例だ。

取引実績

日立、富士通、NTTデータ、デル・テクノロジーズ、野村総合研究所（NRI）など、90社を超える国内外の主要SIer・ITコンサルティング企業との成約実績がある。

5万本超のブラックボックス化システムも、可視化できた実績があります。

「解析不可能」と判断されたシステムでも、まずはご相談ください。

お問い合わせはこちら →

可視化を成功させるための3つのポイント

可視化プロジェクトを確実に成功させるために、押さえるべきポイントを3つに絞って整理する。

ポイント1: 経営層を巻き込む

経済産業省「レガシーシステムモダン化委員会」総括レポート（2025年5月）によれば、CDO・CIO・CTOを設置している企業ほど、可視化とモダナイゼーションが進んでいる。IT部門だけで進めようとしても、予算確保や全社的な協力を得ることは難しい。

可視化の結果そのものが、経営層を説得する材料になる。「現状のシステムはこうなっている。放置すれば年間これだけのコストが無駄になる」——こうした定量的な根拠を示すことで、稟議は通りやすくなる。

ポイント2: スコープを明確にする

「全システムを一括で可視化する」のは非現実的だ。以下の基準で優先順位を付け、段階的に進める。

• ベテラン退職が迫っているシステム（退職日がデッドライン）

• 業務停止時の影響が大きい基幹系システム

• サポート終了が近い基盤上のシステム

「すべてをやろうとして、何も終わらない」——これが可視化プロジェクトで最も避けるべき失敗パターンだ。

ポイント3: 「AI + 人間」の組み合わせを選ぶ

前述の比較表が示すとおり、AI単独でもベテラン単独でも、コスト・期間・精度のすべてを高い水準で満たすことは困難だ。

AIの処理速度でコストと期間を圧縮し、ベテランの業務理解で精度を担保する——この掛け合わせが、可視化プロジェクトの成功確率を最も高める組み合わせである。

可視化の後は、レガシーマイグレーションの具体的な手順に進むのが一般的な流れだ。レガシーシステム刷新の進め方と戦略も併せて参照されたい。

よくある質問（FAQ）

Q1. レガシーシステムの可視化にはどのくらいの期間がかかりますか？

手法と規模による。手動解析では数千本規模で半年〜1年以上。AI×ベテラン人材の融合アプローチであれば、数万本規模のプログラムでも約1ヶ月で完了した実績がある。

Q2. 仕様書が一切ない場合でも可視化は可能ですか？

可能だ。AIによるソースコード解析とベテラン技術者の業務ヒアリングを組み合わせれば、「仕様書ゼロ」の状態からでも着手できる。5万本超のプログラムが完全にブラックボックス化していたケースでも、全ASIS解析を完了した事例がある。

Q3. 可視化の費用の目安は？

手動解析では数百万〜数千万円規模になることが多い。AI活用により、可視化工程のコストを従来の1/10まで圧縮できるケースもある。具体的な見積もりはシステムの規模と対象範囲による。

Q4. COBOL以外のレガシー言語にも対応できますか？

COBOL、RPG、PL/I、アセンブラに標準対応している。Progress2のようなマイナー言語でも、5万本超の解析実績がある。

Q5. 可視化だけを依頼することは可能ですか？

可能だ。可視化（ASIS解析）のみを単独で依頼し、その結果をもとに自社でモダナイゼーション計画を検討するケースもある。「攻めの資料」（要件定義書）と「守りの資料」（詳細設計書・テスト仕様書）を目的に応じて選択できる。

Q6. 可視化の結果をモダナイゼーションにどう活かせますか？

可視化で得られた「攻めの資料」（要件定義書、業務フロー図）は、モダナイゼーション計画の策定やRFP作成の直接的なインプットとなる。現行仕様が明確になることで、移行手法の選定（リホスト・リライト・リビルド）の精度も格段に上がる。

まとめ——可視化は、すべてのモダナイゼーションの起点

レガシーシステムの可視化は、「やったほうがいい作業」ではない。モダナイゼーション、マイグレーション、保守体制の再構築——あらゆるアクションの精度を決める、最初の一手だ。

本記事の要点を振り返る。

• 可視化とは: ブラックボックス化したシステムの構造・仕様・業務ロジックをドキュメントとして再現すること

• なぜ必要か: 仕様の消失、ベテラン退職、保守コスト肥大化。56.6%の企業がレガシーを使い続け、61%がモダナイゼーション未着手

• 方法は3つ: 手動、ツール、AI。AI×ベテラン人材の融合がコスト・期間・精度を最も高い水準で両立

• ASIS分析の6ステップ: 棚卸し→コード解析→データ構造→業務ロジック→ドキュメント生成→報告・計画策定

• 成果物は2種類: 「攻めの資料」（DX検討用）と「守りの資料」（保守用）を目的別に設計

仕様が見えなければ、次の一歩は踏み出せない。逆に言えば、可視化さえ終われば、移行計画も稟議も、一気に前に進む。

レガシーシステムの「見えない仕様」を可視化しませんか？

独自AI「ARIADNE」× 精鋭部隊「TITANS」が、従来の1/10のコストでIT資産を可視化します。

数万本規模のプログラムでも約1ヶ月で完了。90社超の取引実績。

まずは無料相談から。

お問い合わせはこちら → ｜ 資料をダウンロード →