レガシーシステムのブラックボックス化とは？原因と解消への5ステップ

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

2026年現在、日本企業の約61%が依然として「レガシーシステムのブラックボックス化」という経営リスクを抱えています。これは単なるIT現場の問題ではなく、保守コストの肥大化（IT予算の約9割）や、年間最大12兆円の経済損失を招く重大な経営課題です。

しかし、近年の「AIによるコード解析」と「熟練技術者の知見」を掛け合わせることで、仕様書が皆無のシステムでも従来の1/10のコスト・期間で可視化することが可能になりました。現状を「ASIS解析」で正しく把握することこそが、DX推進のボトルネックを解消する唯一の最短ルートです。

「仕様書が存在しない」「システムの全容を把握しているのは、あと数年で定年を迎えるベテラン1人だけ」——こうした状況に心当たりはないだろうか。

レガシーシステムのブラックボックス化とは、長年の運用・改修を経てシステムの内部構造や仕様が不透明になり、誰も全体像を把握できなくなった状態を指す。経済産業省の「DXレポート」でも、この問題は日本企業のDX推進を阻む最大級の障壁として指摘されている。

2025年5月に公表された経産省「レガシーシステムモダン化委員会」総括レポートによれば、依然として約61%の企業がレガシーシステムを残したまま運用中だ。しかし、結論を先に述べると、ブラックボックス化は「解消できる課題」に変わりつつある。AIによるコード解析技術の進化で、仕様書がゼロの状態からでもシステムの可視化が可能になった。

この記事では、ブラックボックス化の6つの原因と5つのリスクを整理したうえで、解消に向けた5つのステップと、5万本超のブラックボックス化システムをAIで解析した実践事例を紹介する。

レガシーシステムのブラックボックス化とは

ブラックボックス化の定義

ブラックボックス化とは、システムの内部構造が外部から見えなくなり、「入力と出力はわかるが、中で何が起きているかわからない」状態になることだ。

経済産業省は2018年のDXレポートで、レガシーシステムを「技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム」と定義した。このうちブラックボックス化は、最も対処が困難な課題の一つとされる。

なぜ「最も困難」なのか。ハードウェアの老朽化であれば機器を更新すればよい。コストの肥大化であれば予算配分を見直す余地がある。しかしブラックボックス化は、「そもそも何を変えればよいかがわからない」という問題を引き起こす。対策の起点となる「現状把握」そのものが不可能に見える——この点が他の課題と本質的に異なる。

レガシーシステムの定義・問題点の詳細については別記事で体系的に整理しているため、併せて参照されたい。

ブラックボックス化と属人化の関係

ブラックボックス化と属人化は、しばしば混同される。両者は密接に関連するが、同じ現象ではない。

属人化は「原因」、ブラックボックス化は「結果」だ。

保守・運用が特定の担当者に集中する（属人化）→ ドキュメントが更新されなくなる → 担当者以外にはシステムの仕様が見えなくなる（ブラックボックス化）——この因果関係を正確に理解しておくことが、解消策を考えるうえでの出発点となる。

逆に言えば、属人化を解消するだけではブラックボックス化は解決しない。すでに失われた仕様を復元する作業が別途必要になる。

2026年の現状——61%の企業にレガシーが残存

「2025年の崖」という言葉が広まったのは2018年。経済産業省は、このまま放置すれば2025年以降、最大年間12兆円の経済損失が生じると警告した。

あれから8年。崖を越えた2026年現在、状況はどう変わったのか。

2025年5月公表の「レガシーシステムモダン化委員会」総括レポートは、約61%の企業にレガシーシステムが残存していると報告している。8割以上の企業がレガシーシステムを保有しているとされた2018年時点と比較すれば改善は進んだものの、6割超の企業がいまだブラックボックス化のリスクを抱えている現実は変わらない。

ブラックボックス化が起こる6つの原因

ブラックボックス化は、一朝一夕に起きるものではない。複数の要因が長期間にわたって積み重なり、ある日気づいたときには「誰もシステムの全容を説明できない」状態に陥っている。企業の現場で頻出する6つの原因を整理する。

原因1: 過剰なカスタマイズの蓄積

基幹システムは、業務要件の変化に合わせて繰り返し改修される。10年、20年と改修が積み重なると、当初の設計思想とはかけ離れた「ツギハギ構造」が出来上がる。

ある処理を修正すると、一見無関係な別の処理が停止する。こうした「予測不能な副作用」は、過剰なカスタマイズが生み出す典型的な症状だ。修正の影響範囲が予測困難になり、最終的には「触れない」システムになっていく。

原因2: 属人化の進行

前述のとおり、属人化はブラックボックス化の最大の原因だ。

保守・運用が特定の担当者に集中すると、その人物の頭の中にしか存在しない「暗黙知」が形成される。正規のドキュメントに記録されない業務ロジック、例外処理の判断基準、過去のトラブル対応の経緯——これらは担当者が退職した瞬間に消失する。

原因3: ドキュメントの未整備・散逸

「仕様書はあるが、5年前の改修が反映されていない」。この状況は珍しくない。

システム導入時に作成された仕様書が、その後の改修のたびに更新されずに放置される。やがて仕様書と実態のギャップが広がり、「この仕様書は信用できない」という認識がチーム内に定着する。結果、仕様書は参照されなくなり、形骸化が加速する悪循環に陥る。

原因4: ベテラン担当者の退職・異動

現役のCOBOLエンジニアの平均年齢は60歳前後とされる。COBOL、RPG、PL/I、アセンブラといったレガシー言語を扱える技術者は年々減少しており、数年以内に大量退職を迎える企業も少なくない。

ベテランの退職は、単に「人手が減る」問題ではない。そのベテランの頭の中にのみ存在していたシステム仕様が、組織から永久に失われるということだ。

原因5: ベンダーへの過度な依存

システムの開発・保守を外部ベンダーに丸投げし続けた結果、社内にシステムの知見がまったく残っていない——いわゆる「ベンダーロックイン」の状態も、ブラックボックス化を加速させる。

ベンダー側にも担当者の交代はある。引き継ぎが不十分であれば、ベンダー社内でもブラックボックス化が進行する。「委託元も委託先も仕様を説明できない」というケースは、想像以上に存在する。

原因6: 「動いているものは触るな」文化

「今のシステムは問題なく動いている。下手に触ると障害が起きる」——この考え方は、短期的にはリスク回避策として機能する。しかし長期的には、ブラックボックス化を黙認する文化を醸成してしまう。

IT投資やシステム刷新の優先度が低く設定され続けた結果、気づいたときには技術的負債が返済不能な水準にまで膨らんでいた。こうした企業は決して少数ではない。

ブラックボックス化がもたらす5つのリスク

ブラックボックス化を放置した場合、企業が直面するリスクは以下の5つに大別できる。いずれも「いつか起きるかもしれない」ではなく、「起きている企業がすでにある」リスクだ。

リスク1: システム障害の長期化

内部構造が不透明なシステムで障害が発生した場合、原因の特定に膨大な時間がかかる。通常であれば数時間で解決できるトラブルが、数日から数週間に及ぶケースもある。障害対応の長期化は、業務停止時間の拡大と売上機会の損失に直結する。

リスク2: 改修・機能追加の困難化

一箇所の変更が、どこにどう影響するかわからない。この恐怖が、改修そのものを躊躇させる。結果として、ビジネス側からの機能追加要求に「対応不可」と回答せざるを得ない状況が生まれる。

市場環境の変化への対応が遅れ、競争力を失う原因にもなりかねない。

リスク3: 保守コストの肥大化

経済産業省の調査では、IT予算の約9割が既存システムの維持・保守に消費されている企業が大半とされる。ブラックボックス化が進むほど、わずかな改修にも調査工数が膨らみ、保守コストは雪だるま式に増大する。

新規投資に回す予算が確保できなくなり、DXの推進力が根本的に削がれる構造だ。保守コストの構造的な問題と改善策はレガシーシステム保守の課題と解決策で詳しく解説している。

リスク4: DX推進の阻害

日本情報システム・ユーザー協会（JUAS）の調査によれば、約7割の企業がレガシーシステムをDX推進の「足かせ」と実感している。

クラウド連携、API公開、データ活用基盤の構築——いずれの施策も、既存システムの仕様が把握できなければ着手すらできない。ブラックボックス化は、DXのボトルネックとなっている。

リスク5: 年間最大12兆円の経済損失

経済産業省は、レガシーシステムの問題を放置した場合、2025年以降、最大年間12兆円の経済損失が生じると試算した。IT人材の不足も深刻で、2025年には43万人が不足するとされていた。

2026年現在、この試算が過大であったという検証結果は出ていない。むしろ生成AIの普及により、レガシーシステムを抱える企業と先進企業の間のデジタルデバイドは広がりつつある。ブラックボックス化も含めたリスクの全体像はレガシーシステムのリスクと評価手法で体系的に整理している。

ブラックボックス化を解消する具体的な方法

「深刻な問題であることは理解した。では何から着手すればよいのか」。ここからは、ブラックボックス化の解消に向けた5つのステップを順に整理する。

ステップ1: 現状把握（ASIS解析）から始める

ブラックボックス化の解消で最も重要なのは、最初のステップだ。「ASIS解析（AS-IS＝現状の分析）」と呼ばれる工程で、既存システムの内部構造を可視化する。

具体的には、ソースコードを解析してプログラムの処理内容を読み解き、モジュール間の依存関係を洗い出し、業務ロジックを復元する作業だ。仕様書が存在しない場合でも、ソースコードから仕様を逆引きする「リバースエンジニアリング」で対応できる。

「仕様書がないから解析できない」——この前提は、後述するAI活用によって覆されつつある。

ステップ2: システム資産の棚卸しと優先順位付け

ASIS解析の結果をもとに、システム資産を棚卸しする。プログラム本数、使用言語、外部連携の有無、業務上の重要度——これらを一覧化し、対応の優先順位を決定する。

すべてを一度に解消する必要はない。業務停止リスクの高い領域、保守コストが集中している領域など、インパクトの大きい箇所から着手するのが現実的だ。

ステップ3: ドキュメントの復元・再生成

可視化の結果を、組織として活用可能なドキュメントに落とし込む。

ここでの成果物は大きく2種類に分かれる。「攻めの資料」としての要件定義書（DX検討やリビルドの基礎資料）と、「守りの資料」としての詳細設計書・テスト仕様書（保守・運用の安定化）。目的に応じて成果物の形式を使い分けることで、投資対効果を最大化できる。

ステップ4: モダナイゼーション手法の選定

現状が可視化できたら、次は「どの手法で刷新するか」の判断だ。リホスト（環境移行）、リライト（言語変換）、リビルド（再構築）、リプレイス（パッケージ置換）——手法ごとにコスト・期間・リスクは異なる。各手法の比較と進め方はレガシーシステム刷新の進め方で詳しく解説している。

手法選定の精度は、ステップ1のASIS解析の精度に依存する。「仕様が見えない状態での手法選定」が最大の失敗要因であることは、レガシーマイグレーションの具体的な進め方でも詳しく解説している。

ステップ5: 再ブラックボックス化を防ぐ仕組みづくり

解消して終わりではない。最も見落とされがちなのが、「再ブラックボックス化の防止」だ。

新しいシステムでも、ドキュメントの更新が止まればいずれブラックボックス化する。改修のたびにドキュメントが自動更新される仕組みの構築、モジュラー設計によるシステム構造の透明化、定期的な棚卸しプロセスの制度化——これらを設計段階から組み込んでおくことが不可欠だ。

従来の1/10のコストで、レガシーシステムを可視化。 22,000名超の人材DBから厳選した上位1.3%の精鋭が対応します。→ ASIS解析の資料をダウンロード

AI × ベテランで実現する新しいブラックボックス解消アプローチ

従来型ASIS解析の限界

従来のASIS解析は、人海戦術が基本だった。エンジニアがソースコードを1行ずつ読み解き、処理内容を仕様書に書き起こす。数千本規模のプログラムを解析するだけで半年から1年以上かかるのが常識だった。

コストも膨大だ。あるSIerに見積もりを依頼したら数億円を提示された——こうした話は珍しくない。見積もり金額を見た時点で「やめよう」と判断する企業も少なくなかった。

加えて、COBOL、RPG、PL/I、アセンブラを読める技術者の確保自体が困難になっている。「解析したいが、解析できる人がいない」。この構造的な問題が、ブラックボックス化の放置を加速させてきた。

AIコード解析が変える現状把握のアプローチ

2024年以降、AIを活用したコード解析の実用化が急速に進んだ。

野村総合研究所（NRI）は2025年3月に「現行可視化・影響分析サービス」を開始。NTTデータも生成AIを活用したレガシーシステムのモダナイゼーション支援を強化している。システムズは「Re:structure AI」を展開し、AIによるソースコード解析市場に参入した。

AIコード解析市場が拡大している背景には、技術の成熟だけでなく、「人手では間に合わない」という現実がある。レガシー言語の読解が可能な技術者が減り続ける中、AIによる解析は選択肢ではなく必然になりつつある。

「AI × ベテラン人材」の融合が鍵

ただし、AIだけでブラックボックス化を完全に解消できるわけではない。

AIはソースコードの構造解析やデータフロー解析に強みを発揮する。一方で、「なぜこの処理が存在するのか」「この例外分岐はどんな業務判断に基づくのか」といった業務意図の読み解きは、AIだけでは限界がある。

ここで重要になるのが、レガシー言語に精通したベテラン技術者の存在だ。

エイジレスモダナイゼーションでは、独自AI「ARIADNE」がソースコードを解析し、プログラム処理の意味付けまで実行する。その結果を、精鋭部隊「TITANS」——22,000名超の人材データベースから上位1.3%を厳選した300名のベテラン技術者（平均年齢57歳）——が検証し、業務意図を織り込んだ仕様書へ仕上げる。

この「AI × ベテラン」の融合により、従来の1/10のコスト・1/10の期間でのASIS解析を実現している。数万本規模のプログラムでも約1ヶ月で完了した実績がある。

AIコード解析には各社が参入しているが、ベテラン人材との融合でここまでコスト・期間を圧縮した事例は、現時点ではきわめて限られる。

レガシーシステムの可視化手法を詳しく解説した記事も併せて参照されたい。

成果物の活用——「攻め」と「守り」の使い分け

ASIS解析の成果物は、目的に応じて2つに分かれる。

• 攻めの資料（要件定義書等）: DX検討、リビルド計画の策定、新システムの要件定義に活用

• 守りの資料（詳細設計書、テスト仕様書等）: 保守・運用の安定化、属人化の再発防止に活用

どちらの資料が必要かは、プロジェクトのフェーズと目的で異なる。両方をワンストップで生成できれば、プロジェクト全体のスピードと精度が向上する。

「仕様がわからない」を解決する、新しいアプローチ。 独自AI「ARIADNE」× 精鋭部隊「TITANS」（平均年齢57歳）が、レガシーシステムの仕様を可視化します。→ 無料相談はこちら

ブラックボックス化解消の実践事例

競合記事の多くは一般論にとどまるが、ここでは実際のプロジェクト事例を紹介する。「うちのシステムでも解析できるのか？」という問いに対する、現場からの回答だ。

事例1: 5万本超の「解析不可能」アプリケーションをAIで可視化

課題: 三菱オフコン上で稼働するProgress2（P2）アプリケーション。本数は5万本を超え、外部システムとEDI接続していた。仕様は完全にブラックボックス化しており、複数のベンダーから「解析不可能」と判断されていた。P2という開発言語ゆえに、読解できる技術者がほぼ存在しないことが根本的な問題だった。

対応: 独自AI「ARIADNE」による全ASIS解析を実施。並行して、P2言語を読解できるベテラン技術者（TITANS）2名が業務ヒアリングを行い、AIの解析結果と照合しながら仕様書を作成した。

成果: 「解析不可能」とされたシステムの全容を可視化。外部連携先を含めたリビルド計画の策定が可能になった。

この事例の核心は、「人間が読めないコードでもAIは読める」という点にある。AIが構造を解析し、ベテランが業務意図を補完する——この組み合わせが、従来の常識を覆した。

事例2: COBOL移行プロジェクトの仕様書を期限内に作成

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

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

成果: 限られた期間・コストの中でプロジェクトを完遂。移行後の保守体制も、生成されたドキュメントをベースに構築できた。

この事例は、「ブラックボックス化の解消はプロジェクトの途中からでも間に合う」ことを示している。初期段階で対応できれば理想的だが、テスト工程で問題が発覚してからでも、AI × ベテランの投入でリカバリーは可能だ。

2つの事例に共通する成功パターン

規模も言語も異なる2つの事例だが、成功要因は共通している。

1. ASIS解析を最初（または問題発覚時に即座）に実施した: 可視化を省略して移行に突き進む失敗パターンを回避

2. AI × ベテラン技術者を融合させた: AIの解析速度とベテランの業務知見を掛け合わせ、コストと期間を圧縮

3. 段階的にアプローチした: 一括で全てを解決しようとせず、優先度の高い領域から着手

なお、エイジレスモダナイゼーションは日立、富士通、NTTデータ、デル・テクノロジーズ、野村総合研究所（NRI）など90社を超える主要SIer・ITコンサルティング企業との取引実績を持つ。業界・規模を問わず対応可能な体制を整えている。

ブラックボックス化に関するよくある質問

Q. レガシーシステムのブラックボックス化とは？

システムの内部構造や仕様が不透明になり、「入力と出力はわかるが、中で何が起きているかわからない」状態を指す。長年の改修・属人化・ドキュメント未整備が重なることで進行し、改修や障害対応が困難になる。

Q. なぜレガシーシステムはブラックボックス化するのか？

主な原因は6つ。過剰なカスタマイズの蓄積、属人化の進行、ドキュメントの未整備・散逸、ベテラン担当者の退職、ベンダーへの過度な依存、「動いているものは触るな」という組織文化。これらが複合的に作用する。

Q. ブラックボックス化したシステムは解析できるのか？

AIを活用したコード解析により、仕様書がゼロの状態からでも解析は可能だ。5万本超のアプリケーションが「解析不可能」と判断されたケースでも、AI × ベテラン技術者の融合で可視化に成功した実績がある。

Q. ブラックボックス化を解消するには何から始めればよい？

ASIS解析（現状把握）が第一歩だ。既存システムのソースコードを解析し、内部構造・依存関係・業務ロジックを可視化する。この工程の精度が、以降の手法選定やコスト算出を左右する。

Q. 解消にどれくらいのコストと期間がかかる？

規模と手法により異なる。従来のASIS解析は数千本規模で半年〜1年・数億円というケースもあった。AI活用により、コスト・期間を従来の1/10に圧縮できる事例が出ている。数万本規模でも約1ヶ月で完了した実績がある。

Q. AIでブラックボックス化は完全に解消できる？

AI単独では不十分だ。AIはソースコードの構造解析に強みを持つが、業務意図の読み解きには限界がある。レガシー言語に精通したベテラン技術者と組み合わせる「AI × 人材」の融合アプローチが、現時点で最も効果的な手法である。

まとめ — ブラックボックス化は「解消できる課題」

ブラックボックス化は、放置するほど解消コストが膨らむ構造的な課題だ。この記事の要点を振り返る。

• ブラックボックス化の実態: 約61%の企業がレガシーシステムを残存させ、IT予算の9割が保守に消える構造が続いている。放置した場合の経済損失は最大年間12兆円

• 6つの原因: 過剰カスタマイズ、属人化、ドキュメント未整備、ベテラン退職、ベンダー依存、IT投資の後回し。いずれも「ある日突然」ではなく、長期間かけて進行する

• 解消の第一歩はASIS解析: 仕様書がない状態でも、AI × ベテラン技術者の融合で可視化は可能。「解析不可能」は過去の常識であり、AI技術の進化で状況は変わった

「解析不可能」と判断されたシステムでも、解決策は存在する。5万本超のブラックボックス化アプリケーションがAIで可視化できた事実が、その証明だ。

まず現状を把握すること。その一歩が、ブラックボックス化の解消につながる。

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

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

お問い合わせはこちら →