AIにレガシーコードを読ませたら何が起きるか——20年物の請求計算を、実際に解読してみた

前回の記事で、20年もののVB6（Visual Basic 6＝四半世紀前に主流だった開発言語）で作られた販売管理システムを抱えた食品卸の話を書きました。「AI（Artificial Intelligence＝人工知能）で丸ごと作り直せないのか」という社長の願いに対して、筆者がたどり着いた答えはこうでした。

AIの一番の出番は、変換ではなく「解読」です。

でも、これだけでは半分しか伝わりません。「解読って、実際に何が起きるの？」——そこが見えないと、ただのきれいごとです。

そこでこの記事では、実際にやってみます。20年分の制度対応が継ぎ足された請求計算のコードを1本用意して、AIに読ませました。設計書がよみがえっていく様子と、AIが堂々と間違えた場面の、両方を包み隠さずお見せします。

（前回の記事はこちら: 「AIで丸ごと作り直せないのか」——3年動けずにいる食品卸のVB6販売管理に、誌上で移行計画を立ててみた）

この記事には2つの層があります。コードは実物ではありません。 筆者が担当者から聞き取った業務内容をもとに、VB6風に再現したサンプルです。一方で、解読の過程で起きたこと・得られた教訓は、筆者が実際の案件で体験した事実です。守秘のため、会社や担当者を特定できる情報は変えて再構成しています。「実際に見た失敗」と「説明のために作ったコード」を、混ぜずに読み分けられるよう書きました。

この記事でわかること

AIにレガシーコードを「解読」させると、失われた設計書がどこまでよみがえるのか
AIが自信満々に間違える瞬間——「もう使っていない機能」を現行仕様として読んでしまう罠と、その避け方
解読はAIで速くなるが、検証は人の時間で決まる——発注側が準備しておくべきこと

「解読」とは、コードに日本語のふりがなを振ること

まず言葉の整理から。「解読」と言われても身構えなくて大丈夫です。

やることは単純です。人間には呪文にしか見えないプログラムを1行ずつAIに読ませて、「この部分は何のための処理か」を日本語に翻訳させる。それだけです。失われた設計書、つまり「このシステムは何をどう計算しているか」の説明書を、コードから逆算して復元する作業だと思ってください。

前回の会社——食品卸のマルタニ食品（仮名）には、設計書がありませんでした。仕様のすべては、20年間たった1人でシステムを守ってきた井川さん（仮名）の頭の中にあります。その「頭の中」を、井川さんが在職しているうちに会社の資産へ変える。解読は、そのための道具です。

では、実際のコードを見てみましょう。

謎のコード——20年、継ぎ足されてきた請求計算

下のコードは、請求金額を計算する部分です。読めなくて大丈夫です。 むしろ「うわ、無理」と感じたなら、それが正しい反応です。井川さん以外の全社員が、20年間ずっとこの「無理」と付き合ってきたのですから。

一点だけ見てほしいところがあります。先頭の ' で始まる行（プログラム内のメモ書き）の年号です。2006年に作られたあと、2014年、2019年、2023年と、制度が変わるたびに継ぎ足された跡が残っています。

' ============================================
'  請求金額計算  M.Igawa
'  2006/04 新規作成
'  2014/03 税率変更対応（5%→8%）
'  2019/09 税率変更・軽減税率対応
'  2023/09 インボイス対応
' ============================================
Public Function CalcSeikyu(ByVal tokuiCode As String, _
                           ByVal itemCode As String, _
                           ByVal qty As Long, _
                           ByVal unitPrice As Currency, _
                           ByVal denpyoDate As Date) As Currency

    Dim kingaku As Currency
    Dim zeiritsu As Double
    Dim tokubetsu As Double     ' 得意先別の掛率

    kingaku = qty * unitPrice

    ' --- 掛率補正 ---
    tokubetsu = GetKakeritsu(tokuiCode)
    If tokubetsu > 0 Then
        kingaku = kingaku * tokubetsu
    End If

    ' --- 税率の判定 ---
    If denpyoDate < #4/1/2014# Then
        zeiritsu = 0.05
    ElseIf denpyoDate < #10/1/2019# Then
        zeiritsu = 0.08
    Else
        ' 2019/10以降：軽減税率
        If IsKeigen(itemCode) Then
            zeiritsu = 0.08          ' 食品は据え置き
        Else
            zeiritsu = 0.1           ' 資材は10%
        End If
    End If

    ' --- 端数処理 ---
    If denpyoDate >= #10/1/2023# Then
        ' インボイス対応：1請求単位で切り捨て
        kingaku = Int(kingaku * (1 + zeiritsu))
    Else
        ' 旧：明細ごとに四捨五入
        kingaku = Round(kingaku * (1 + zeiritsu))
    End If

    CalcSeikyu = kingaku
End Function

正直に言えば、これはまだ「きれいな」ほうです。実際のシステムでは、こうした関数が何百本も絡み合い、If文（条件分岐）が10段以上ネスト（入れ子）していることも珍しくありません。それでも、素人目には十分に呪文でしょう。

このコードを、AIに読ませてみます。

AIに読ませたら、設計書がよみがえった

筆者が使ったのはAIアシスタントのClaude（クロード）です。「このVB6のコードが何をしているか、制度対応の年ごとに説明してください」と頼みました。返ってきた解読を、表に整理したのがこちらです。

読み方はこうです。コードの各分岐が「いつの、何のための対応か」を、AIが日本語に翻訳してくれています。

コードの分岐	AIの解読（何年の何対応か）
伝票日付 < 2014/4/1 → 税率5%	2014年3月までの旧税率（消費税5%時代）
< 2019/10/1 → 税率8%	2014年4月の増税（5%→8%）対応
`IsKeigen` で 8% / 10% を分岐	2019年10月の軽減税率対応。食品は8%据え置き、資材は10%
2023/10以降 → `Int`（切り捨て）	インボイス制度対応。1請求単位で消費税の端数を切り捨てる方式に変更
それ以前 → `Round`（四捨五入）	旧方式。明細ごとに四捨五入していた

いかがでしょう。井川さんが頭の中だけで覚えていた「なぜこんな分岐があるのか」が、質問に答えるだけで文章になっていきます。ここまでは、AIの独壇場です。人間が同じことをやろうとすれば、1本の関数に半日かかってもおかしくありません。それが数分で片付きます。

ただし、AIが「わからない」ことがある

ここで立ち止まりたいのは、コードから分かることには限界があるという点です。AIが解読できるのは「何をしているか（What）」まで。「なぜそうしたのか（Why）」は、コードに書かれていません。

たとえば、こういう問いにはコードは答えられません。

インボイス対応で、なぜ「明細ごと」ではなく「1請求単位」で切り捨てる方式を選んだのか。取引先と何を合意したのか。
品目コードで食品か資材かを判定していますが、そのコード体系はいつ誰が決めたのか。例外品目はないのか。

これらは、コードという「結果」を見ても復元できません。当時の判断や、取引先とのやりとりという「経緯」だからです。ここは井川さんのような、事情を知る人に聞くしかない。AIは解読を速くしますが、人への質問をゼロにはしません。 むしろ、AIが「ここは経緯が読めません」と正直に印を付けてくれるおかげで、井川さんに聞くべき質問が絞り込めます。

……と、ここまでは順調な話です。問題は次に起きました。

AIが自信満々に間違えた——「掛率」の落とし穴

もう一度、コードの上のほうを見てください。税率判定より前に、こんな処理がありました。

    ' --- 掛率補正 ---
    tokubetsu = GetKakeritsu(tokuiCode)
    If tokubetsu > 0 Then
        kingaku = kingaku * tokubetsu
    End If

これをAIに解読させると、迷いなくこう答えます。

この処理は、得意先ごとに設定された掛率（割引率）を金額に掛けて補正しています。得意先別の価格設定を実現する、現行の請求ロジックの一部です。

もっともらしいです。文法的にも、まったく正しい解読です。コードはたしかに「掛率を取ってきて、金額に掛ける」と書いてあります。

ところが——前記事の移行計画（あの提案書）をまとめる過程で、これとよく似た処理の解読結果を「現行仕様」として担当者に見せたとき、返ってきたのはこんな反応でした。

「掛率……？そんな運用、もう何年も前にやめたはずだけど……」

種明かしをします。この会社では昔、得意先ごとに掛率を変える制度がありました。でも数年前に価格体系を一本化し、掛率制度は廃止されました。にもかかわらず、コードは消されずに残っていた。GetKakeritsu が参照するデータは空になっていて、実際には tokubetsu > 0 の条件が一度も成立しない。つまり、このコードは「動いてはいるが、何もしていない」死んだ機能だったのです。

AIには、これが見抜けません。AIが読めるのは「コードに何が書いてあるか」であって、「それが今も使われているか」ではないからです。そしてAIは、死んだコードも生きたコードも、同じ自信たっぷりの口調で解読します。ここが、いちばん怖いところです。

この会社では、もしこの解読を鵜呑みにしていたら、「得意先別の掛率設定」という、もう誰も使っていない機能を、わざわざ新システムに作り込むところでした。使われない機能の分だけ、費用も期間も、将来の保守の手間も増えます。

教訓を一行にすると、こうなります。

コードは嘘をつかない。でも、そこに書いてあることが今も使われているとは限らない。

AIは、コードという「地図」を猛烈な速さで読み解きます。でも、その地図に描かれた道が今も通れるのか、それとも廃道になっているのかは、実際にそこを歩いている人——現場の担当者——にしか分かりません。

解読はAIで速い。でも検証は人の時間で決まる

死んだコードを弾くには、どうすればいいのか。答えは単純で、AIの解読を、事情を知る人が検証する工程を必ず挟むことです。下の図が、その流れです。

AIが猛スピードで解読し、人がそれを検証し、通ったものだけが設計書に確定する。死んだコードは「人の検証」で弾かれる、という段取りを示しています。

図で「現場の担当者が検証」のところが、業務全体の関門になります。AIがどれだけ速くても、ここを人が通さない限り、設計書は確定しません。そして——ここが正直に書いておきたいところですが——この検証こそが、いちばん時間のかかる工程でした。

ところが提案書をまとめる過程では、この検証を頼める唯一の相手である井川さんが、日々の障害対応で手一杯でした。検証のためにまとまった時間を取ってもらうことができず、やりとりはメール中心。こちらが解読結果を送っても、返事が返ってくるのは数日後、ということもざらでした。

つまり、こういう構図です。

解読（AIの担当）: 速い。1本の関数が数分。
検証（人の担当）: 遅い。担当者の空き時間に依存する。

レガシー刷新というと「開発が大変」というイメージがありますが、少なくとも解読フェーズの本当のボトルネックは、開発でもAIでもなく、検証してくれる人の時間でした。

だからこそ、これは技術の話であると同時に、経営の話でもあります。発注する会社の側が、「解読結果を検証する担当者に、週に数時間でいいから確実に時間を確保する」体制を作れるか。ここを曖昧にしたまま始めると、AIがいくら速くても、プロジェクト全体は担当者の空き待ちでずるずると延びます。**検証は外注できません。**それができるのは、業務を知っているその人だけだからです。

社外のAIにコードを渡して、大丈夫なのか

ここまで読んで、経営者の方がまず気になるのは、たぶんこれでしょう。「うちの大事なシステムのコードを、外のAIに渡して平気なのか」と。

まっとうな心配です。この点について、実際の案件でどうしたかを書いておきます。

まず、先方とはNDA（Non-Disclosure Agreement＝秘密保持契約）、つまり「見聞きした情報を外に漏らしません」という契約を結んでいます。これが大前提です。契約上、ソースコードを受け取れる状態にはなっていました。

そのうえで、実務として大事にしたのは、必要な箇所だけを、必要なぶんだけ受け取るという進め方です。全ソースコードを一度にごっそりもらう、ということはしませんでした。今回のように請求計算を解読するなら、請求まわりのコードだけ。在庫の話が出てきたら、そのとき在庫まわりだけ。対象業務に関係する部分に絞って、段階的に受領します。

理由は2つあります。

リスクを最小に抑える。 手元に置くコードが少ないほど、万一のときの影響範囲も小さくなります。
相手も渡しやすい。 「全部ください」より「この画面のこの計算だけ見せてください」のほうが、先方も心理的なハードルが低い。話が前に進みます。

AIにコードを渡すこと自体を怖がりすぎる必要はありません。ただし、無防備に全部を渡す必要も、まったくありません。契約で守り、対象を絞る。この2つを押さえておけば、解読は現実的な選択肢になります。

経営者のあなたへ——最初の一歩は「1本、読ませてみる」

長くなりました。要点を、持ち帰れる形にまとめます。

AIの解読は本物です。 20年分の継ぎ足しコードから、失われた設計書が数分でよみがえります。これは誇張ではありません。
でもAIは万能ではありません。 コードに書いてある「何をしているか」は読めても、「なぜそうしたか」と「今も使っているか」は読めません。だから、事情を知る人の検証が必ず要ります。
本当のボトルネックは検証する人の時間です。 ここに社内の体制を用意できるかが、プロジェクトの速さを決めます。
守秘は、契約と段階受領で守れます。 全部を渡さなくても、解読は始められます。

そして、これが一番大事な点です。前回の記事に書いた通り、設計書の復元は、キーパーソンが在職しているうちにしかできません。 AIがどれだけ速く解読しても、「そんな運用してたっけ？」に答えられる人が社内からいなくなったら、生きたコードと死んだコードの区別がつかなくなります。そうなれば、20年分の記憶は、二度と設計書には戻りません。

だから、大きな決断はまだ要りません。刷新をやるかやらないかを決める前に、試しに1本だけ——いちばん怖い、いちばん誰も触れない計算処理を1本選んで、AIに読ませてみる。そして、その解読を担当者に見せて「これ、合ってる？」と聞いてみる。

そこで返ってくる「合ってるよ」と「いや、それはもう使ってない」の両方が、あなたの会社にとって、何よりの資産です。井川さんが、まだ答えてくれるうちに。