モダナイゼーションに生成AIを使う方法｜古いコードから仕様を戻す

「基幹システムを刷新したいが、設計書が古いまま止まっていて、今の動きを説明できる人がいない」「ベンダーから生成AIでソースコードを解析できると提案されたが、出てきた設計書をどう確かめればよいのか分からない」。刷新を任された情シスや経営企画から、こうした声が上がっています。設計書のない古いシステムに悩むのは、珍しいことではありません。経済産業省が2018年に公表した「DXレポート」は、約8割の企業が老朽化したシステムを抱えているという調査を引き、足かせの理由として「ドキュメントが整備されていないため調査に時間を要する」を挙げています。生成AIの解析で大事なのは、コードを速く書き換えることではありません。本当は、AIが戻した仕様を、発注側が業務の担当者と比較テストで確かめ、自分たちの設計書として受け取ることです。この記事では、仕様を戻す工程の進め方と、発注側が決めることを整理します。

この記事が扱うのは、替えると決めた後の工程

モダナイゼーションは、古いシステムを今の技術や業務に合う形に作り替えることを指します。替えるかどうか、いつ替えるかの判断軸は、システムのリプレースの判断を扱った別の記事で整理しています。この記事は、替えると決めた後に、今のシステムの仕様を取り戻す工程に絞ります。

対象は、会社の基幹システムです。販売、在庫、会計、給与のように、長年動いてきて、部署をまたいで使われているものを想定しています。部署の手元の表計算のマクロの引き継ぎは、マクロの解読を扱った別の記事に譲ります。基幹システムでは、発注側とベンダーの役割が分かれるため、何を誰が確かめるかの決めごとが中心になります。

新しいシステムを作るときの仕様の決め方や、社内の開発者にコード生成のAIを配る体制も、この記事では扱いません。ここで扱うのは、今あるコードから、今の業務ルールを読み戻す段階だけです。読み戻した仕様が、その後の設計や発注の土台になります。

読み戻す工程が大事なのは、刷新の失敗の多くがここから始まるからです。今の仕様が分からないまま新しいものを作ると、完成してから「前はできていたことができない」と分かります。仕様を戻す工程は、刷新の費用を削る所ではなく、後の手戻りを減らす所と考えておきます。

設計書が無いことが、刷新の最初の壁になる

DXレポートは、老朽化したシステムを、技術の古さ、肥大化と複雑化、中身が見えなくなるブラックボックス化などの問題を持ち、経営の足かせや高い費用の原因になっているシステムと説明しています。その足かせと感じる理由には、設計書が整っていない調査の手間に加えて、「影響が多岐にわたるため試験に時間を要する」も並んでいます。

設計書が失われる経緯は、多くの会社で似ています。最初の開発のときは設計書があっても、その後の改修でコードだけが直され、設計書が追いつかなくなります。何十年も改修を重ねると、正しいのはコードだけで、設計書は昔の姿を描いた資料になります。そのコードを読める人も、定年や異動で減っていきます。

DXレポートは、大規模なシステム開発を担った人が退職の時期を迎え、人に属していた知見が失われてブラックボックス化が起きているとも書いています。知見が人の頭の中に残る形では、その人が抜けた時点で、なぜその処理があるのかを説明できる人がいなくなります。

このため、刷新の最初の作業は、今のコードを読み、何をしているかを書き出すことになります。これまでは、読める技術者が1本ずつ読み、説明を書き起こしていました。コードの量が多いほど時間がかかり、読める人の数が上限になります。生成AIが入ってきたのは、この工程です。

「今と同じ動きで」と頼むと、何が起きるか

仕様が分からないまま刷新を発注すると、発注の条件は「今と同じ動きをすること」になりがちです。DXレポートは、ユーザー企業が今のシステムの複雑さも仕様も分からないまま、現行の機能を保証する条件でベンダーに刷新を委託する場合が多いと指摘しています。

その結果として、レポートは、でき上がったシステムが発注側の意図と違い、テストの工程で大きな手戻りが発生すると書いています。「今と同じ」が何を指すのかを、発注側もベンダーも言葉にできていないからです。テストで初めて違いが見つかり、そこから仕様を確かめ直すことになります。

レポートはさらに、今の仕様を完全に引き継ぐことは難しく、結果として以前より使い勝手が悪くなることも少なくないとしています。「今と同じ」という条件そのものが、実際には守りにくい約束なのです。守れない約束で発注しないために、まず今の仕様を言葉にする必要があります。

生成AIによる解析を入れる意味は、ここにあります。今の仕様を、発注の前に文書として手に入れられれば、「今と同じ」の中身を1つずつ確かめられます。ただし、AIが書いた文書をそのまま仕様にすると、同じ問題が形を変えて残ります。文書が正しいかを確かめる工程が要るのです。

生成AIの解析で、何ができるようになったか

国内では、富士通が2026年3月30日、ソースコードを生成AIで解析し、今のシステムを把握するための設計書を自動で作るサービスを国内で提供し始めたと発表しました。コボルなどのコードが対象で、発表では、言語の理解から設計書の作成までの作業を、有識者がいなくても約30分の1の時間に縮められるとしています。

同じ発表は、通常の生成AIだけの解析と比べて、設計書の網羅性が95％、読みやすさが従来比で60％向上したとも書いています。また、今のコードを次に生かす作り直しや、コードを書き直す機能は、2026年度以降に順次提供する予定としています。2026年3月の時点で提供を始めたのは、設計書を戻す部分です。

海外の例では、AWSが大型汎用機のプログラムを作り替える生成AIのサービス（AWSトランスフォームの大型汎用機向け）を、2025年5月15日に一般提供としました。発表では、コードの分析、説明文の生成、機能の切り分けなどが挙げられ、2025年7月16日には、業務ロジックの抽出をファイル単位に加えてアプリケーション単位でも行えるようにしたと発表しています。

2社の発表に共通するのは、今のコードから設計書や業務ロジックを読み出す工程を、機械で速くする点です。一方で、読み出した結果を業務の担当者がどう確かめるか、現行と同じ動きをどう保証するかは、どちらの発表でも中心の話題ではありません。確かめる段取りは、サービスを使う発注側が自分で用意する前提で考えておくのが安全です。

• 作業時間の短縮や網羅性の数字は、各社の発表によるもので、条件や対象のシステムによって変わります。自社のシステムで同じ効果が出ることを示すものではありません
• サービスの提供地域や対応する言語は変わることがあります。検討するときは、各社の最新の公式情報で確かめてください

仕様を戻す工程の全体像：5つの手順

ここからは、発注側から見た進め方です。解析の作業そのものはベンダーやサービスが行うとしても、何を戻すか、正しいかどうか、同じ動きかどうかは、発注側が決めて確かめる必要があります。全体を5つの手順に分けます。

この順番のうち、手順3から5は、AIがどれだけ速くなっても省けません。AIが縮めるのは主に手順2の後の解析の時間で、確かめる時間はむしろ前より大事になります。解析が速く終わるほど、確かめる側に大量の文書が一度に届くからです。

手順は、システム全体で一度に回すより、業務のまとまりごとに回すほうが進めやすくなります。受注の業務で5つの手順を回し、確かめ方の型ができてから、在庫や請求に広げます。最初のまとまりで、確認にかかる人と時間の見積もりが立ちます。

手順1：どこまで復元させるかを決める

最初に決めるのは、戻す深さです。コードから戻せるものには段階があります。プログラムごとに何をしているかの説明、画面や帳票やファイルの一覧とその関係、計算や判定の業務ルール、データの項目の意味、の順に深くなります。深くなるほど、解析の手間も、確かめる手間も増えます。

深さは、次の工程で何に使うかから決めます。今のコードをほぼそのまま新しい基盤に載せ替えるなら、プログラムの説明と関係の一覧があれば足りることが多いでしょう。業務を見直しながら作り直すなら、業務ルールとデータの意味まで要ります。使い道を決めずに「全部戻して」と頼むと、読まれない文書が大量に届きます。

深さは、業務のまとまりごとに変えて構いません。料金の計算や与信の判定のように、間違えると損害が大きい業務は、業務ルールまで細かく戻します。帳票の出力のように形が決まっている業務は、一覧の段階で止めます。誤りの損害が大きい所ほど深く戻し、深く確かめるのが基本の配分です。

どこまで戻すかを決めるのは、発注側です。ベンダーやAIに、どこが大事かを見立てさせることはできますが、その見立ては、コードの複雑さなど技術の側の物差しになりがちです。業務の損害の大きさは、業務を知る人でなければ測れません。

手順1の続き：範囲の切り方と、使われていないコード

深さと並んで決めるのが、範囲です。何十年も動いてきたシステムには、今は使われていないプログラムや、特定の年にだけ動く処理が混ざっています。これをすべて戻すと、手間の多くが使われないコードに消えます。範囲を決める前に、どのプログラムが今も動いているかを、実行の記録から確かめます。

実行の記録から外れたプログラムでも、すぐに範囲から外してはいけません。年に1回の決算や、制度の変更のときにだけ動く処理があるからです。1年分以上の実行の記録を見て、それでも動いていないものを、業務の担当者に確かめてから外すのが安全です。

範囲の切り方には、業務のまとまりで切る方法と、画面や帳票などの出口から逆にたどる方法があります。業務のまとまりで切ると、業務の担当者が確かめやすくなります。出口からたどると、利用者が今使っている機能を漏らしにくくなります。2つを組み合わせ、出口の一覧で漏れを確かめるのが実務的です。

範囲と深さは、1枚の表にして、発注の前に関係部署と合わせておきます。どのまとまりを、どの深さで、いつまでに戻すかが書かれていれば、ベンダーの見積もりも比べやすくなります。この表は、後の検収でも、約束した範囲が戻されたかを確かめる物差しになります。

手順2：解析に渡すもの、渡さないもの

解析の精度は、渡すものの揃い方で大きく変わります。まず、本番で動いているのと同じ版のコードを揃えます。開発用の控えと本番の中身が違っていることは珍しくありません。版が違うコードを解析すると、戻した仕様は今の本番の仕様ではなくなります。

コードのほかに、処理を動かす順番を決めた定義、ファイルやデータベースの項目の定義、運用の手順書、過去の障害の記録も渡します。コードだけでは、どの処理がどの順で動き、どのデータを受け渡すかが分からないことがあります。古い設計書も、昔の姿を描いた資料として、参考のために渡しておきます。

渡さないものも決めます。コードの中に、接続の合言葉や鍵が直に書かれていることがあります。テスト用のデータに、顧客の個人情報が残っていることもあります。これらは、解析に渡す前に取り除くか、置き換えます。インターネット経由で使う解析のサービスなら、データがどこで処理され、どこに保管され、学習に使われるかを契約で確かめる必要があります。

渡すものの一覧は、発注側が作り、ベンダーと合わせます。一覧に無いものは解析されず、戻した仕様に穴が残ります。後で穴が見つかったとき、渡していなかったのか、渡したのに解析されなかったのかを区別できるよう、渡した日付と版も記録しておきます。

手順2の続き：AIの出力を下書きとして受け取る

AIが戻した設計書や業務ルールは、下書きとして受け取ります。コードに書いてある処理を説明することは、生成AIの得意な作業です。しかし、変数の名前やコメントから意味を推し量る部分には、もっともらしい誤りが混ざります。昔の担当者が付けた略語の意味を、AIが別の意味に読むこともあります。

そこで、出力の書き方を最初に決めておきます。1つ目は、業務ルールの1行ごとに、根拠となるプログラムと場所を書かせることです。根拠が書かれていれば、確かめる人がコードの該当箇所に戻れます。根拠の無い行は、推測として扱います。

2つ目は、コードから読み取った事実と、名前などから推し量った解釈を分けて書かせることです。「この項目が1なら割引を適用する」は事実、「この項目は優良顧客の印と思われる」は解釈です。解釈の行には印を付けさせ、業務の担当者に確かめる候補の一覧にします。

3つ目は、読み解けなかった箇所を隠さず書かせることです。外部から呼ばれる処理や、別のシステムから届くデータの意味は、コードの中だけでは分かりません。未解明の一覧が短すぎる設計書は、分からない所を推測で埋めている可能性があります。未解明の数は、品質の悪さではなく、正直さの目安として見ます。

手順3：業務ルールの正しさは、業務の担当者が確かめる

戻した業務ルールが正しいかどうかは、コードを読める人ではなく、その業務を担う人が確かめます。コードに書いてあることと、業務として正しいことは同じではないからです。コードは今の動きを表しますが、その動きが今の取引の条件や社内の決まりに合っているかは、コードからは分かりません。

確かめ方は、設計書を丸ごと渡して読んでもらうのではなく、質問の形にするのが効果的です。「受注の金額が一定額を超えると、上長の承認に回る。この金額は今も同じか」のように、業務ルールを1つずつ、業務の言葉で問います。解釈の印が付いた行を優先して質問票にまとめます。

業務の担当者は、日々の仕事の合間に確かめることになります。1回に確かめる量を決め、週に1回など決まった場を設けると続きます。確かめた結果は、行ごとに、確かめた人、日付、合っている・違う・分からないの印で残します。誰がいつ確かめたかが残っていない業務ルールは、確かめていないのと同じです。

質問票の下書きをAIに作らせるのは効果があります。戻した業務ルールから、確かめるべき点を業務の言葉に直させるのです。ただし、答えをAIに推し量らせてはいけません。答えは業務の担当者が出し、出せない問いは、次に誰に聞くかを決めて残します。

手順3の続き：食い違ったときの決め方

確かめていくと、コードの動きと業務の担当者の理解が食い違う箇所が出てきます。食い違いには、大きく3つの形があります。コードが正しく、担当者の理解が古い場合。担当者の理解が正しく、コードが直されないまま残っている場合。どちらも今の業務には合わず、決まりを改めるべき場合です。

どの形かを決めるのは、その業務の責任者です。担当者どうしで決めると、声の大きい人の理解が仕様になります。食い違いの一覧を業務の責任者に上げ、コードどおりにするか、業務に合わせて直すか、決まりを改めるかを決めてもらいます。決めた理由も、行ごとに残します。

ここで注意したいのは、コードの誤りに見えるものが、実は昔の事故や特別な取引先への対応だった、ということがある点です。変わった条件分岐を見つけたら、消す前に、過去の障害の記録や古い担当者の記憶を当たります。理由が分からないまま消すと、何年かに1度起きる取引で問題が出ます。

決まりを改めると決めた箇所は、仕様を戻す工程の外に出し、新しい要件として別に管理します。今の仕様を戻す文書と、これから変える要件が混ざると、比較テストで「違っていてよい所」と「違ってはいけない所」を分けられなくなります。

手順4：発注側が検収で見る項目

戻した設計書を受け取る前に、発注側の基準で検収します。検収の項目は、発注のときに決めて、ベンダーと合わせておきます。後から基準を足すと、追加の費用や期間の話になりやすいからです。発注側が検収で見る主な項目を表にまとめます。

検収の項目	確かめること	確かめる人
範囲	約束した業務のまとまりと深さが、すべて戻されているか	情シス
版	解析したコードが、本番と同じ版か	情シス
根拠	業務ルールの各行に、根拠のプログラムと場所があるか	情シス
事実と解釈	推し量った行に印があり、質問票に回っているか	情シス
業務の確認	各行に、確かめた人・日付・結果が残っているか	業務の責任者
食い違い	食い違いの行に、責任者の決定と理由があるか	業務の責任者
未解明	読み解けなかった箇所の一覧と、次の手当てがあるか	情シス
持ち主	設計書の所有と、以後の更新の担い手が決まっているか	発注の責任者

表の中で、ベンダーだけで満たせる項目は多くありません。業務の確認と食い違いの決定は、発注側の人が動かなければ埋まらない項目です。検収の遅れの多くは、ベンダーの作業ではなく、発注側の確認の遅れから生まれます。確認にかかる人の時間を、発注の前に確保しておきます。

検収は、システム全体を最後に1回で行うより、業務のまとまりごとに区切って行うほうが確実です。受注のまとまりの設計書を検収し、合格してから在庫のまとまりに進む形にすれば、最初のまとまりで見つかった書き方の癖を、次のまとまりの解析の前に直してもらえます。区切りごとの検収の日程も、発注のときに決めておきます。

検収の点検をAIに手伝わせることはできます。根拠の抜けた行や、確認の記録が空の行を数えさせるのは、機械の得意な作業です。ただし、検収に合格とするかどうかは、表の右の列の人が決めます。

手順5：現行と同じ動きかは、比較テストで確かめる

新しいシステムができたら、今のシステムと同じ動きをするかを確かめます。設計書どおりに作ったとしても、設計書に書かれなかった動きは漏れています。そこで、同じ入力のデータを今のシステムと新しいシステムの両方に通し、出てきた結果を比べる比較テストを行います。

入力には、本番のデータの写しを使うのが効果的です。作ったテストのデータでは、実際の取引の変わった組み合わせが入らないからです。個人情報を含む場合は、置き換えてから使います。月末の締め、年度の切り替え、うるう年、税率の変わり目のように、日付で動きが変わる所は必ず含めます。

結果を比べると、違いが出てきます。違いは1件ずつ、理由を確かめます。新しいほうの誤りなら直します。業務の責任者が改めると決めた箇所なら、違っていてよい所として記録します。理由の分からない違いを、合格の範囲として見逃さないことが大事です。

比べる作業そのもの、つまり2つの結果の突き合わせと違いの一覧づくりは、機械に任せられます。違いの原因の候補をAIに挙げさせるのも役に立ちます。しかし、その違いを受け入れるかどうかは、業務の責任者が決めます。DXレポートが、影響が多岐にわたるため試験に時間がかかると書いているとおり、比較テストの期間は短く見積もらないでください。

書き換えか載せ替えかを、AIに決めさせない

仕様が戻ると、次は作り替えの方式を決める段になります。今のコードを新しい言語に書き換えるか、今の動きのまま新しい基盤に載せ替えるか、業務から作り直すか、既製の業務ソフトに置き換えるか、といった選択です。生成AIの解析サービスの中には、方式の提案まで出すものもあります。

方式の提案は参考になりますが、決めるのは発注側です。方式によって、費用、期間、業務の変え方、その後の保守の担い手が変わります。どれを選ぶかは、会社がそのシステムに何を求めるかという経営の判断で、コードの分析から自動で決まるものではありません。

生成AIを入れた刷新で起きやすい失敗を並べます。どれも、AIの出力を確かめる工程を飛ばしたことで起きるものです。

• AIが書いた設計書を、業務の担当者に確かめないまま新しい仕様にする
• 根拠の場所の無い業務ルールを、事実として検収してしまう
• 「AIで一気に書き換えられる」と見込み、比較テストの期間を削る
• 使われていないコードを実行の記録だけで外し、年に1回の処理を落とす
• 方式をAIの提案どおりに決め、保守の担い手が社内にいないことに後で気づく

AIの解析は、刷新の中の読み解く工程を速くする道具です。刷新そのものを短くするかどうかは、確かめる工程をどれだけ段取りよく回せるかで決まります。

発注の前に決めておく、契約と体制

ここまでの手順を回すには、発注の前に、契約と体制で決めておくことがあります。1つ目は、戻した設計書の持ち主です。設計書は、ベンダーの成果物ではなく、発注側がこれから保守していく資産として受け取ります。所有の扱いと、渡す形式を契約に書いておきます。

2つ目は、責任の分け方です。解析の正しさ、業務の確認、比較テストのそれぞれについて、誰が何を保証するかを書きます。DXレポートが指摘した、仕様が分からないまま現行の機能を保証させる形を避けるには、戻した仕様を発注側が確かめ、その仕様を基準に新しいものを検収するという順番を契約に落とします。

3つ目は、発注側の体制です。情シスの担当者だけでなく、業務のまとまりごとに確認を担う人と、食い違いを決める責任者を、名前で決めておきます。解析が速く進むほど、確認の担い手が足りなくなります。確認に使える時間を、各部署の上長と合わせておきます。

4つ目は、設計書を古くしない仕組みです。刷新の後も改修は続きます。改修のたびに設計書を直す決まりが無ければ、何年か後に同じ問題が戻ってきます。改修の手順の中に、設計書の更新と、その確認を組み込んでおきます。

まとめ

モダナイゼーションに生成AIを使うと、設計書の無い古いコードから、仕様と業務ルールの下書きを速く戻せるようになりました。ただし、AIが書くのはコードの説明で、その業務ルールが今も正しいか、新しいものが同じ動きをするかは別に確かめる必要があります。進め方は、どこまで戻すかを決める、解析に渡すものを揃える、業務の担当者が確かめる、発注側の基準で検収する、比較テストで同じ動きを確かめる、の5つです。AIには根拠の場所を書かせ、事実と解釈を分けさせ、分からない所を隠させない。業務ルールの正しさは業務の担当者が、同じ動きかは比較テストが確かめ、作り替えの方式はAIに決めさせず発注側が決める。この分担を守ることが、戻した仕様を自分たちの設計書として持ち続ける前提になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。