誰も中身を知らないレガシーシステムを、LLMで読み解く——「ブラックボックス問題」への新しいアプローチ

大企業であれば、少なくとも1つはこうしたシステムを抱えています。事業の根幹を支えており、30年にわたって動き続け、今日も問題なく稼働している。それなのに、社内にはもう、それが何をしているのかを自信をもって説明できる人が一人も残っていない——そんなシステムです。

設計書に書かれているのは、2009年に置き換えられたバージョン。書いた技術者はすでに退職しています。長年保守を担ってきたSIerも、担当者が4回入れ替わりました。今残っているのは「挙動」だけです——観測することはできる、事業を支えていることもわかる、けれどなぜそう動くのか、誰にも説明はできない。

最初の打ち合わせで、私たちがよくこんな言葉を耳にします。いずれも、実際に繰り返されてきた会話を元にした複数の事例を組み合わせた表現であり、特定の顧客の発言をそのまま引用したものではありません。

本質的な問題は、この最後の一言に表れています。モダナイゼーションを計画するには、まず誰かがそのシステムを「読む」必要があります。そして読むという作業は、これまで、エンジニアのチームが1年がかりで発掘調査を行うことを意味していました。

本稿では、この調査フェーズがなぜ今、これまでとは異なる性質の問題になったのか、そこでLLMに何ができて何ができないのか、そしてLLMを使った「役に立つドキュメント作成」と「もっともらしい誤り」を分ける方法論について解説します。

本稿は、日本の現実的な制約のもとでエンタープライズAIをどう導入するかを扱う連載の一部です。前回の記事では、データを外部に出せない環境において、小規模なオンプレミスモデルを活用する方法を論じました。今回はその対極——法的に許される範囲で、可能な限り大きなモデルを投入したい——そんなタスクを扱います。

01  制約はコードの古さではなく、「理解の喪失」にある

この議論を8年間支配してきたのは、経済産業省の2018年『DXレポート』と、そこで示された「2025年の崖」——レガシーシステムを放置した場合、2025年以降、日本経済に年間最大12兆円の損失が生じうるという警告でした。この数字は広く引用されていますが、率直に言えば、すでに古い数字です。

では、その期限を迎えた今、実際にどうなっているのでしょうか。経済産業省は「レガシーシステムモダン化委員会」を設置し、2025年5月28日にその総括レポートを公表しました。同レポートには約4,000社のユーザー企業・ベンダー企業を対象とした市場動向調査（回答799社、実施期間2024年12月17日〜2025年2月14日）が収録されており、ユーザー企業の61%が現在もレガシーシステムを保有し、大企業に限れば74%に達すると報告されています。つまり、期限を迎えたことで一気に問題が解消されたわけでもなければ、何かが破綻したわけでもありません。レガシーシステムは、いまだに高い割合で残り続けています。

ただし、このレポートで注目すべきなのは、61%という数字だけではありません。さらに重要なポイントが2つあります。

第一に、同レポートにおけるレガシーシステムの定義は、稼働年数を要件としていません。挙げられている5つの要因のうちの一つが「システムのブラックボックス化」——仕様や設計書が適切に維持されておらず、新システムへの移行や再構築の妨げとなり、運用・維持・保守が属人的になっている状態です。つまり、本稿が扱う問題は、単に古いシステムだから起きている問題ではありません。経済産業省自身の定義においても、レガシーシステムを特徴づける性質の一つとして位置づけられています。

第二に、同レポートは、IT人材が減少するなかで人海戦術的な移行アプローチが早晩限界を迎えるとして、ベンダー企業に対し「生成AI等でのレガシーコード解析」の開発を明示的に求めています。本稿で述べるアプローチは、ベンダーが思いついた小技ではなく、政策文書が指し示している方向そのものです。

レガシーシステムがこれほど残り続けている背景には、明確な時限を伴う「知識継承」の問題があります。COBOL、PL/I、そしてこれらのシステムを繋いでいる社内独自のジョブ制御に習熟した技術者は、いままさに定年を迎えつつあります。ここでの困難は、有能な技術者が不足していることではありません——これらの技術で高い生産性を上げている方々は数多くいますし、言語そのものは学習可能です。困難なのは、これらのシステムが要求する知識の多くが文書化されておらず、その組織に固有である点です。40年分の意思決定、例外処理、回避策の蓄積は、どのマニュアルにも書かれておらず、それを保持している人々と共に働くことでしか受け渡せません。採用や研修だけではこの問題を解決する近道にはなりません。ある一社の文書化されていないバッチスケジュールを教える外部カリキュラムは存在しないからです。経済産業省のレポートも同じ問題を指摘しており、設計ドキュメントの不備と並べて「技術者の高齢化・離脱」を挙げています。体系的な引き継ぎを伴わない退職が起きるたびに、システムへの理解もまた一つ失われていきます。

つまり、本当のボトルネックは、コードが古いことではありません。古くても、その中身を理解できているコードであれば、単に保守コストがかかるだけです。

本当の問題は、コードが置き換えられていくよりも速いペースで、そのコードを理解できる人や知識が失われていることにあります。そして、先送りする年が1年増えるごとに、次に刷新を試みるときのコストは、前回よりも大きくなっていきます。

02  なぜこれは「本当にLLM向き」の問題なのか

私たちは、何でもLLMで解こうとする姿勢には一貫して反対の立場をとってきました。そのうえで、本件はLLMが適した数少ないケースです。

レガシーシステムの読解は、コード生成のタスクではありません。現代ではほとんど使われない古い言語・記法で書かれた、大量かつ雑然としていて、必要な情報が埋もれたデータの集合を「読み解く」タスクです——20万行のCOBOL、40年分のストアドプロシージャ、JCL、バッチスケジュール、そして「読み手も同じ文脈を共有している」という前提で書かれた日本語のコメント。

静的解析は、コードの構造を機械的にたどる作業を得意としています。コールグラフを構築したり、特定の変数がどこで使われているかを追跡したりすることはできます。しかし、顧客が本当に知りたい問い——「これはどのような業務ルールを実装しているのか。そして、なぜそのようなルールになっているのか」——には答えられません。

この問いに答えるには、未知のコンテキストを大量に保持したまま、情報の矛盾や不整合を許容し、英語の識別子と日本語のコメントを同時に読み解けるモデルが必要です。これはまさに、フロンティアLLMが近年得意とするようになったタスクです。つまり、専用の解析ツールが進化したからではなく、この作業をLLMで行うことで人手で行うよりも安くできるようになったのです。

そして、もう一つの大きな変化が「エージェンティック」なアプローチです。従来の試みでは、解析に入る前にコードベースを整理・正規化する必要がありました。それ自体が数年がかりのプロジェクトであり、多くの取り組みが提案段階で頓挫した理由でもあります。エージェンティックなシステムは、エンジニアと同じように、雑然としたリポジトリの中を辿っていきます——呼び出しを追い、参照されているコピー句を開き、ジョブスケジュールを確認し、また戻る。実際に存在するコードを、そのまま対象にできるのです。

ここから先の議論には、一つ重要な前提があります。 金融や公共分野では、こうしたコードを海外のAPIに送信できないケースが一般的です。ただし、なぜ送信できないのかは正確に区別しておく必要があります。それぞれ異なる理由によるものであり、そこを曖昧にすると、ベンダー側の理解不足として顧客に見抜かれます。

ソースコードそれ自体は個人情報ではなく、個人情報保護法（APPI）がソースコードを直接規制するわけではありません。 コードそのものに対する制約は、ほとんどの場合、契約や社内規程に基づくものです——顧客とのNDA、委託・再委託の条件、業界のセキュリティガイドライン、そしてソースコードを社外に持ち出すことを禁じる社内規則などです。APPIが関係してくるのは別の局面、すなわち送信する内容に実際に個人情報が含まれる場合であり、実務上これは頻繁に起こります。設定ファイル、テストフィクスチャ、ログサンプル、初期データ、あるいはコードと一緒に持ち出される本番由来の抽出データに個人情報が埋め込まれているケースです。これらは別個の義務であり、顧客社内でも所管部署が異なります。一括りに扱えば、見落とした細部でレビューに落ちることになります。いずれにせよアーキテクチャは、プライベート環境での実行（VPC内に閉じたフロンティアモデル、あるいはオンプレミスのオープンウェイトモデル）を例外ではなく既定として想定する必要があります。

03  中核事例：誰も触れない決済バッチ

ここでは、こうしたレガシーシステムに典型的に見られる状況を一つ取り上げ、ここまで説明してきた方法論を具体的に見ていきます。実在する特定の顧客案件ではなく、複数のケースに共通する特徴を組み合わせた想定例です。数字も実測値ではなく、あくまで規模感を示すための目安です。

たとえば、取引データを照合して元帳に記録する、数万行規模の夜間バッチがあるとします。20年間、一度も大きな問題を起こすことなく稼働してきました。数百に及ぶ業務ルールが組み込まれている可能性がありますが、文書化されているのはそのごく一部です。中には、すでに改正された規制に対応するための処理もあれば、今では存在しないハードウェア上の制約を回避するための処理もあります。そして、どの処理がどの理由で存在しているのかを説明できる人は、もう誰もいません。

誰もこのバッチに手を入れようとはしません。変更を誤れば規制上のインシデントにつながる可能性がある一方、うまくいったとしても、得られるのはコードが少しきれいになる程度だからです。その結果、バッチはそのまま残り、組織はそれを避けるように業務を組み立てていきます。こうして、ブラックボックスが事業を支える「荷重を担う構造物」になっていくのです。

最初から移行する必要はありません。まず目指すべきなのは、そのシステムを「読み解ける状態」にすることです。四半期単位ではなく数週間で、そのシステムが何をしているのか、何が依存しているのか、どの業務ルールが今も有効なのかを整理し、文書化します。そうすることで、移行するかどうかを、恐れではなく根拠に基づいて判断できるようにします。

04  アーキテクチャ：抽出、そして検証

ここからは、この問題をどう解くのか見ていきます。

パイプラインは意図的にシンプルな構成にしています。そして、譲れない原則が一つあります。それは、「モデルが生成したものは、モデル以外の仕組みで確認されるまで、事実として扱わない」ということです。

ここで重要なのは次の４つの点です。

静的解析はLLMの「代わり」ではなく、LLMに先立って実行する。 コールグラフ、依存関係マップ、デッドコード検出は、決定論的なツールから得ます。これは、モデルが推論を組み立てるための骨格であると同時に、モデルのハルシネーションを検出するための「検査」でもあります。LLMがコールグラフに存在しないデータフローを記述した場合、それはハルシネーションとして検出できます。

出力は文章ではなく、構造化データにする。 モデルが生成するのは、ルールID、該当箇所、平易な説明、入力、出力、確信度、未解決の疑問といった項目を持つ業務ルール一覧であり、文章形式のドキュメントではありません。構造化された出力なら、変更点を比較でき、項目ごとにレビューでき、未解決の事項がなくなるまで追跡できます。40ページの生成ドキュメントは、誰も一つひとつ検証しきれません。結果として、検証されないままになってしまいます。

確信度を独立した重要な項目として持たせる。 確信度の低いルールから優先的に人間のレビューに回します。これは通常の失敗パターン——出力の95%は一見問題なく、5%だけが見落としやすい誤りであるにもかかわらず、レビュアーの注意力をすべての項目に均等に割いてしまう——を逆転させる仕組みです。

人間による確認を、後付けの工程ではなく、アーキテクチャに組み込む。 業務知識を持つ専門家——退職を迎える、あるいはすでに現場を離れたベテラン技術者に協力を仰ぐケースもあります——が、業務ルール一覧を承認します。これは、長年培ってきた専門知識を、最も価値の高い形で次の世代につなぐ方法の一つです。ゼロから設計書を書き起こす作業は時間も負担も大きく、現実的ではありません。一方、LLMが作成したドラフトを確認・修正する形であれば、専門家の知識を効率よく反映できます。

05  方法論：安全にリバースエンジニアリングするために

規模ではなく「影響範囲」で対象を選ぶ。 障害が起きたときに最も損失が大きいサブシステムから着手します。そこでは、システムを理解することの価値が最も高いからです。最も着手しやすいモジュールから始めたくなりますが、それでは、動作することは確認できても、実際の移行に意味のある検証にはならないPoCになってしまいます。

本番挙動との差分で検証する。 生成されたドキュメントは、あくまで仮説です。検証では、レガシーシステムと移行候補の実装に同じ入力を与え、出力を項目単位で突き合わせます。

この入力は、合成データではなく本番由来である必要があります。合成ケースでは、誰かがすでに把握し、書き留めている挙動しか検証できません。それこそが、今回リスクとして問題にしている領域ではないのです。

ただし、規制産業において「本番由来」とは、本番データをそのままテスト環境に複製することではありません。 顧客自身のデータ取扱規程のもとで管理される抽出データを意味します——個人情報が含まれる箇所はマスキングまたは匿名化し、差分検証に必要な項目に限定し、アクセスを移行チームに制限し、保持期間を定め、アクセスや利用履歴を記録し、社内のデータ所管部門による明示的な承認のもとで利用します。

データの抽出自体が承認できない場合は、テスト基盤を本番環境の境界内で動かします。移行候補の実装をその場で実トラフィックに対してシャドー実行し、本番環境の外に出すのは差分検証の結果だけにします。

これらの管理下で差分テスト基盤を構築できない対象は、移行しません。 この原則を守ることで、案件を見送ったこともあります。しかし、それでよいのです。

ストラングラーフィグ方式で、ビッグバン移行はしない。 1機能ずつ新しい実装に処理を切り替え、レガシー経路は稼働させたまま、シャドーモードで比較を続けます。新しい実装が実トラフィック上で十分な期間、一致し続けるまで、正とするのはあくまで旧システムです。デモでは分かりにくい方法ですが、間違えたときのコストは大幅に抑えられます。

移行しなくても、検証済みのドキュメント自体が成果になる。 検証済みの業務ルール一覧には、それだけで価値があります。システムが保守可能になり、次の監査のリスクが下がり、次に誰かが退職しても、その人が持っていた知識まで失われることを防げます。

06  正直な限界—このアプローチが向かない場面

この技術がどのように失敗するのかは明確です。その条件を、ここでは正確に説明しておく価値があります。未知のコードを読むLLMは、流暢で、もっともらしく、自信をもって誤った説明を生成します。 モデルは「その形のコードが一般的に何をするか」を説明するからです。あるルーチンに20年前の文書化されていない回避策が埋め込まれていた場合——まさにそれを発見するために費用をかけているわけですが——モデルの事前知識は、むしろ逆方向に働きます。最も必要とされる場面で、最も信頼できないのです。

具体的には、以下のような場合、このアプローチを導入するメリットはありません。

▪ 挙動差分テスト基盤を構築できない場合。 再現できる本番トラフィックがない、テスト環境がない、比較する手段がない。検証経路がないまま進めれば、事業を支えるシステムについて「もっともらしい創作」を生成しただけになります。その時点で止めるべきです。

▪ 人が読み切れる規模の場合。 保守担当者がまだ在籍しており、少人数のチームが数週間で一から最後まで読み切れる規模であれば、パイプラインを構築するよりも、実際に人が読み解くほうが安価で確実です。その境目がどこにあるかは、言語、コードの密度、当時のチームがどれだけ残っているかによって変わるため、行数ではなくシステムごとに判断します。

▪ 本当に依存しているのがコードではなく「人」である場合。 重要な知識が運用上のものである場合——たとえば、月末処理でどの例外なら無視してよいのかといった知識です——それはソースコードには存在せず、コードをどれだけ読み解いても明らかにすることはできません。これは「暗黙知の可視化・継承」という別の課題であり、別のアプローチが必要です。

▪ コードを社外に出せず、かつオンプレミスのハードウェアもない場合。 このタスクでは、他の多くのタスク以上に読解品質がモデル性能に左右されます。小規模なローカルモデルでは、抽出される業務ルール一覧の精度や網羅性が低下します。それを認めずに進めることが、コンプライアンス上の制約を「誰も口にしない品質問題」に変えてしまいます。

▪ 規制対応上、人間が作成した証跡が求められる場合。 正確性にかかわらず、AIが生成したドキュメントを正式な記録として扱えない領域があります。その場合でも、人間が成果物を作成する作業を高速化することはできます。ただし、成果物そのものではなく、成果物を作成するための「加速手段」として位置づけるべきです。

07  まとめ

▪ 日本のレガシー問題は、かつて示された期限（2025年）を過ぎても、なお解決していません。 経済産業省が2025年5月に公表した総括レポートでは、ユーザー企業の61%、大企業では74%が現在もレガシーシステムを保有しています。

▪ 真のボトルネックは、コードの古さではなく「理解の喪失」です。「システムのブラックボックス化」は、経済産業省自身が定義するレガシーシステムの要因の一つです。同レポートでは、生成AIを活用したレガシーコード解析も求められています。

▪ 失われようとしている知識は、文書化されておらず、その組織に固有のものです。 そのため、体系的な引き継ぎを伴わない退職が起きるたびに、その人が持っていた知識も失われていきます。これは有能な技術者が不足しているという問題ではなく、知識をどう引き継ぐかという問題です。

▪ レガシーシステムの読解は、本質的にLLMに適したタスクです。 大量のコンテキストを保持しながら、雑然としたコードや文書を読み解き、英語の識別子と日本語のコメントを横断して理解する必要があるからです。さらにエージェンティックなシステムによって、コードを事前に整理・正規化しなくても、実際に存在するコードをそのまま辿れるようになりました。

▪ 機能するアーキテクチャでは、静的解析をLLMに先立って実行し、文章ではなく構造化された業務ルール一覧を生成します。 さらに、確信度を重要な項目として持たせ、業務知識を持つ専門家による承認を仕組みに組み込みます。

▪ 顧客自身のデータ取扱規程のもとで管理された本番由来の入力を使い、挙動差分を検証できるテスト基盤なしに、移行は行いません。 移行はストラングラーフィグ方式で段階的に進め、旧システムを正としたまま、新実装をシャドー実行して比較を続けます。

▪ 正直な限界： 未知のコードを読むLLMは、文書化されていない回避策が埋め込まれた、まさにその箇所で自信をもって誤ります。だからこそ、検証は、この方法論の最後に行う一工程ではありません。LLMの出力を検証できる仕組みまで含めて、初めてこの方法論が成立します。