生成AIが救うレガシー、見捨てるレガシー 4/7回
はじめに
第3回では、RPAやノーコード／ローコードといった現代の市民開発基盤が、神エクセルを凌ぐ負債化のリスクを秘めていることを確認した。
ではその延長線上に、生成AIの登場は何を変えるのか。
生成AIは既存のプログラム資産を解析し、移植や再設計の補助を行える。
だが一方で、コードとして書き残されなかった資産――ノーコードやRPAのブラックボックスは、AIであっても現実的には救うことが難しい。
つまり未来に残る負の遺産は、「コード化されなかったもの」に集中する可能性がある。
シリーズ全編
- 市民開発の未来を見通す──歴史・現在・生成AI・そしてその先へ0/7
- 市民開発はEUCの再来か？──神エクセルが教える歴史の教訓1/7
- 神エクセルは本当に悪か？──救世主から負の遺産へ2/7
- 現代の市民開発プラットフォームの光と影3/7
- 生成AIが市民開発に与える影響4/7（本編）
- ガバナンスと負の遺産を回避する方法5/7
- 視座のズレが負の遺産を量産する6/7
- レガシーは生まれ続ける、それでも飼いならせ──市民開発の未来像7/7
生成AIの強み──コード資産を「解凍」する
従来、レガシーコードの移植は膨大な人手を要する作業だった。
COBOLやVBのような旧来言語で書かれた数百万行のプログラムは、ドキュメントも残っておらず、解析には熟練者が必要だった。
生成AIはここに突破口を開く。
-
コードリーディングの自動化
関数の依存関係を図示し、変数や構造体の意味を文脈から推測できる。 -
言語変換の補助
COBOLをJavaへ、VBをPythonへといった「移植のたたき台」を生成できる。 -
リファクタリングの半自動化
スパゲッティ化したロジックを関数ごとに整理し、テストコードを生成することで、後世が扱える形に近づけられる。
要するに、コードという形で残っているものは、AIが半自動的に“解凍”できるのである。
この点で生成AIは、レガシー刷新のゲームチェンジャーになりうる。
ただし「コードがあるから必ず救える」というわけではない。依存環境がすでに消滅していたり、業務知識を知る人がいなかったりすれば、AIでも補えない部分は残る。だがそれでも「ブラックボックスしか残っていない資産」に比べれば、再生可能性は格段に高い。
救えないモノ──コード化されなかった資産
対照的に、ノーコードやRPAで作られた資産はどうか。
これらはGUI操作やフローチャートとして存在し、内部表現はベンダー固有のデータ構造に閉じ込められている。
生成AIが最も得意とするのはテキスト情報であり、暗号化や独自形式で格納されたブラックボックスは解析が難しい。
たとえばRPAの「業務フロー」は、表面的にはブロック図に見えても、実体は暗号化されたプロジェクトファイルであることが多い。
ノーコードの「アプリ」も、クラウド上でしか実行できず、ソースコードという形での輸出は想定されていない。
現実的には、救済よりも再設計のほうが早い場合が大半である。
もちろん将来的には、スクリーン操作や画面キャプチャからフローを推定する研究が進めば、一部はAIで取り出せるかもしれない。だが少なくとも現状では、ブラックボックス化した資産を直接引き継ぐのは難しい。
負の遺産の分水嶺──コードで残したか否か
ここで見えてくるのは、未来に残る負の遺産の分水嶺である。
- コードとして残されたものは、生成AIにより再利用・移植・改善への道が開く。
- コード化されなかったものは、生成AIにとっても“不可視”な部分が多く、再設計するしかない。
つまり将来の救済可能性を左右するのは、**「コードとして残されているかどうか」**にかかっている。
生成AIはこの分水嶺をより鮮明にしたと言えるだろう。
展望──AIは万能の救世主ではない
生成AIは確かに強力だが、少なくとも現時点で万能ではない。
ブラックボックス化した市民開発資産を完全に救うことはできないし、過去の判断を正当化することもない。
AIが突きつけるのは、「コードを書かない自由」の代償である。
短期的な即効性に魅了されてノーコードを選んだ組織は、生成AIの助けを得られず、自ら再設計のコストを負担することになる。
だからこそ次回は、「どうすれば負の遺産を作らずに済むのか」──ガバナンス設計の視点を掘り下げていく。