設計書が無い・作った人もいないシステムでも、AIで解析できますか？

できます。仕様書ではなく、実際に動いているコードそのものを一次情報として読ませるためです。引き継ぎ資料がゼロでも、コメントが無く変数名が整理されていないコードでも、「要するに何をしている処理か」を業務の言葉で説明させられます。

COBOLなど古い言語の技術者不足は、どれくらい深刻ですか？

COBOLのような古い言語の技術者は平均57.8歳という調査があり、40歳未満は15%に満たないという報告もあります。出所の強い統計ではないため断定はできませんが、現場の肌感とはよく合う数字です。正解が人の頭の中にしか無いまま、その頭が会社を去っていくことが問題の核心です。

「AIで開発が速くなる」という話と、この話は何が違うのですか？

世の中の生成AIの話題の多くは「ゼロから新しく速く作る」側に寄っています。一方、基幹システムを抱える会社の本丸は「今動いているものをどうするか」です。この記事の変化は新規開発の高速化ではなく、現行システムをAIが意味で読み解けるようになったこと、つまり刷新の入口が開いたことを指しています。

AIで読み解いたら、すぐに全面刷新へ進んでいいですか？

いきなり全部を作り直す必要はありません。まず現行を読み解き、どこから手をつければ安全かを見極めるのが先です。実は「何から読み解くか」の順番で結果が大きく変わるため、読み解きの次の一歩は慎重に設計することをおすすめします。

基幹システムの刷新はなぜ進まないのか？──「誰も現行を説明できない」壁がAIで崩れ始めた話

AIで「新しく作る」話は、毎日のように流れてきます。新規開発が何倍速になった、という景気のいい話。もちろんすごい。でも、多くの会社の本丸はそこではありません。今動いている基幹システムを、これからどうするか ──そっちです。

刷新の会議は、だいたい毎回、同じ場所で止まります。「これ、触ったら何が起きるか分かる人、います？」──この一言で、会議室がしんと静まる。私はこの景色を、何度も見てきました。

何年も止まっていた理由のひとつが、生成AIの進化で消え始めています。今日はその話を、自分で試した体験と国内の実例から書きます。

Q01基幹システムの刷新は、なぜ何年も進まないのですか？

予算不足や経営の決断力の問題だと語られがちですが、現場で見てきた本当の理由はもっと身も蓋もないものです。今動いているものを、もう誰も丸ごと説明できない。設計書は古いか無く、作った人は退職し、変更したときの影響範囲が読めない。だから怖くて触れず、刷新が毎年先送りされます。

経済産業省のDXレポートでは、2025年には21年以上稼働している古いシステムが全体の約6割を占めるとされています。約8割の企業が老朽システムを抱え、約7割がそれをDXの足かせと感じている、という数字も同レポートにあります。

足かせだと分かっているのに、動けない。その連鎖をたどると、行き着く先はいつも同じでした。

設計書が古いか、そもそも存在しない
作った人が異動や退職でもういない
中身はベンダーに問い合わせないと分からない
変更したときに、どこまで影響が出るかが読めない──だから怖くて触れない

要するに、正解が人の頭の中にしか無い状態なんです。その頭が、一人また一人と会社を去っていく。

刷新が止まる連鎖をたどると、最後は「誰も全体を説明できない」に行き着くことを示す図解

Q02生成AIは、レガシーシステムの読み解きをどう変えたのですか？

生成AIはコードや設定を「文字」ではなく「意味」で読みます。設計書が無くても、実際に動いているコードそのものを一次情報として読ませれば、業務の言葉での説明や変更の影響範囲が返ってきます。「新しく作る」ではなく「今あるものを読み解く」側で、壁が崩れ始めました。

みんなが話す「新しく作る」より、本丸は「今あるを読み解く」側にあることを示す図解

抽象論ではありません。私が自分で試して、なるほどと唸ったことを3つ挙げます。

古いソースを一式渡して「これは要するに何をしている処理か、業務の言葉で説明して」と聞く。コメントゼロ・変数名がぐちゃぐちゃでも、「月次の在庫引当をやっています」くらいの粒度で返ってくる
「この項目を1つ変えたら、影響が出そうな箇所を全部挙げて」と頼む。人が数日かけて探す横断作業を、一気にたどってくれる
仕様書ではなく、実際に動いているコードそのものを一次情報として読ませる。引き継ぎ資料がゼロでも、実体に直接聞ける

従来のシステムは、フォーマットの揃った「形」でしか機械に読めませんでした。それが今は、内部のロジックまで意味で届く。設計書が無いから無理、という前提が足元から揺らいでいます。

Q03日本企業でAIをレガシー刷新に使った実例はありますか？

あります。各社の発表によれば、富士通は2026年に現行コードを解析して設計書を自動生成するサービスを始め、設計書づくりの時間を約1/30に短縮したとのこと。クレスコは初版で完成度90%の設計書をAIで生成し、東京海上日動は設計書からのコード生成で工数を44%削減したと公表しています。

企業	取り組み（各社の発表より）	公表されている効果
富士通	現行コードを解析して設計書を自動生成するサービス（2026年開始）	設計書づくりの時間を約1/30に短縮
クレスコ	AIによる設計書の初版生成	初版で完成度90%、残り1割を人が仕上げる
東京海上日動	設計書からのコード生成	工数を44%削減

「全コードを人手で読み解いて設計書を作り直す」──あの果てしない作業が、こう変わり始めています。

Q04巨大な基幹システムを、なぜ今はAIに丸ごと読ませられるのですか？

理由は2つです。AIが一度に読み込める量（コンテキストウィンドウ）が桁違いに大きくなったこと。そして、AIが自分で必要な箇所を探しに行くようになったこと。この2つが揃って、巨大で絡み合ったレガシーこそAIの得意分野に変わりつつあります。

正直に言うと、少し前まではこうはいきませんでした。巨大な基幹を丸ごと渡すと的外れな要約が返ってきて、「小さく区切って渡す」工夫が要ったんです。それがこの1〜2年で一気に変わりました。

効くのは、地味なほうの進化です。「この処理に関係するファイルを、自分で探して、たどって、まとめて」が成立する。人間が手でやっていた、どこを見ればいいか探す工程を、AIの側が引き受け始めたんですよね。

巨大で・絡み合っていて・どこに何があるか分からない──レガシーが一番つらかったその条件が、ちょうどAIの得意分野になってきた。つまり、 「複雑だから無理」が、「複雑なものほど任せられる」に逆転しつつある 。これが、なぜ今なのかの答えです。

Q05レガシー刷新は、結局なにから始めればいいですか？

全部を作り直す計画からではなく、「今あるものを読み解く」ことからです。完璧な全体計画ができるのを待っていたら、いつまでも始まりません。読み解きだけなら、設計書が無い状態からでも今日始められます。

刷新が毎年見送られるのは、計画が重すぎるからです。いきなり全面刷新を決める必要はありません。順番としては、こうです。

自社で一番「触るのが怖い」基幹システムを特定する
実際に動いているコード・設定を一次情報として、AIに業務の言葉で説明させる
項目を変えたときの影響範囲を挙げさせ、「怖くて触れない」の正体を可視化する
どこから手をつければ安全かを見極めてから、刷新の計画に進む

止まっていたのは、技術でも予算でもありません。「今あるものを、誰も説明できない」──それだけでした。その壁が、今ようやく崩れ始めています。

ちなみに、実は「何から読み解くか」の順番で、結果はけっこう変わります。読み解いた直後にいきなり全面刷新へ走らない──その順番の話は、別の論点としてまた改めて書きます。

よくある質問（FAQ）

Q. 設計書が無い・作った人もいないシステムでも、AIで解析できますか？: A. できます。仕様書ではなく、実際に動いているコードそのものを一次情報として読ませるためです。引き継ぎ資料がゼロでも、コメントが無く変数名が整理されていないコードでも、「要するに何をしている処理か」を業務の言葉で説明させられます。
Q. COBOLなど古い言語の技術者不足は、どれくらい深刻ですか？: A. COBOLのような古い言語の技術者は平均57.8歳という調査があり、40歳未満は15%に満たないという報告もあります。出所の強い統計ではないため断定はできませんが、現場の肌感とはよく合う数字です。正解が人の頭の中にしか無いまま、その頭が会社を去っていくことが問題の核心です。
Q. 「AIで開発が速くなる」という話と、この話は何が違うのですか？: A. 世の中の生成AIの話題の多くは「ゼロから新しく速く作る」側に寄っています。一方、基幹システムを抱える会社の本丸は「今動いているものをどうするか」です。この記事の変化は新規開発の高速化ではなく、現行システムをAIが意味で読み解けるようになったこと、つまり刷新の入口が開いたことを指しています。
Q. AIで読み解いたら、すぐに全面刷新へ進んでいいですか？: A. いきなり全部を作り直す必要はありません。まず現行を読み解き、どこから手をつければ安全かを見極めるのが先です。実は「何から読み解くか」の順番で結果が大きく変わるため、読み解きの次の一歩は慎重に設計することをおすすめします。

AUTHOR

黛政隆（まゆずみまさたか）

株式会社GembaShift 代表取締役CEO

エンジニア歴20年、PM経験50件超。生成AIの導入を、現場に入って一緒に組む仕事をしています。この記事の内容は、著者自身が実際に手を動かして業務で検証した実体験に基づいています。