2026.10.20 アーキテクチャ

生成AIモダナイゼーションの実装手順｜コード解読・仕様復元・テスト生成と限界

COBOLの業務ロジックを生成AIに読ませて設計書を起こし、Javaへ書き換え、新旧システムの出力を突き合わせる。生成AIモダナイゼーションの成否は、この一連の工程のどこにLLMを入れ、どこを決定的な変換ツールと人の検収に残すかで決まります。この記事では、AWS Transform、GitHub Copilot modernization、OpenRewriteの公式ドキュメントをもとに、コード解読・仕様復元・テスト生成・移植の4工程を実装者の視点で分解しました。入力資産の揃え方、新旧出力を突き合わせるスクリプト、コストダウン効果の読み方、生成AIを入れるべきでない場面まで、2026年10月時点の情報で整理しています。

まとめ：生成AIモダナイゼーションで任せる工程と人が判定を握る工程の境界

生成AIが確実に効くのは「読む」工程です。数十万行のCOBOLやJCLから業務ルールを抜き出し、設計書や要件定義書の下書きを作る作業は、人が1本ずつ読む方式と比べて一次稿までの時間を大きく縮められます。一方で「書き換える」工程は、文法の対応が決まっている部分を決定的な変換ツールに任せ、LLMは読みやすさの改善に限定する構成が主流になりました。AWS Transformも、機能等価を保つ初回変換とLLMによる整形（Reforge）を別の工程に分けています。

どの構成でも、正しさを最後に判定するのは人とテストです。本番相当の入力データで新旧の出力を突き合わせる仕組みを先に作り、差分ゼロを移行の合格条件に置いてください。ソースが欠けている、出力の正解を知る業務担当者がいない、数年以内に廃止予定といった条件に当てはまるなら、生成AIを入れても回収できません。自社の資産がどちらに当てはまるか判断がつかない段階なら、システムマイグレーション・リプレイスの相談窓口で現行資産の棚卸しから始めるのが近道です。

生成AIモダナイゼーションの位置づけ｜決定的変換とLLMを重ねる2層の構成

モダナイゼーションの手法（リホスト・リファクタ・リビルドなど）や進め方の全体像はモダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方で整理しました。本稿は、その工程の中で生成AIが何を代替できるかに絞ります。

生成AIが担うコード解読・仕様復元・テスト生成・移植の4工程の対応表

生成AIの効き方は工程ごとに大きく違います。実務で効果が出やすい順に並べると次のとおりです。

工程	生成AIの役割	決定的ツールの役割	人が持つ判定
コード解読	処理の要約・略語の展開	依存関係・呼び出し関係の解析	要約の誤読の指摘
仕様復元	業務ルール・要件書の下書き	データの流れの追跡	現行業務との一致確認
テスト生成	単体テスト・検証観点の提案	新旧出力の機械比較	差分の許容か不具合かの判定
移植	変換後コードの整形・命名改善	構文の機械変換・版上げレシピ	設計方針と例外処理の確定

表のとおり、生成AIはどの工程でも「下書き」と「整形」を担い、合否は決定的ツールの比較結果と人の判定で決まります。最初に投資するなら、効果が早く見えるコード解読と仕様復元からです。

AWS Transformが分けた機能等価の初回変換とLLMによるReforgeの分業

AWSのAWS Transformのメインフレーム向けユーザーガイドには、この2層構成がそのまま書かれています。COBOLからJavaへの初回変換は機能等価を保つ代わりに、COBOL由来のデータ構造や変数名を残します。そのコードをReforgeという工程でLLMが書き直し、Javaのコレクションや命名規則に寄せる流れです。

Reforgeには1ジョブあたり300万行、1ユーザーあたり月5,000万行の上限があります（2026年10月時点の記載）。コンパイルが通らなかったクラスは.java.incompleteとして別に保存され、元のファイルは置き換えられません。LLMの書き換えが失敗しても機能等価な初回変換が残る設計で、ここに「正しさは決定的変換、読みやすさはLLM」という分担が表れています。

レガシーコードの解読と仕様復元｜用語集と入力資産を揃える準備作業の手順

仕様復元の精度は、モデルの性能より入力の揃い方で決まります。ソースの欠落や社内略語の未定義は、そのまま生成ドキュメントの誤りになって返ってきます。

COBOL・JCL・コピーブックの入力構成とglossary.csvを置く位置の具体例

AWS Transformでは、COBOLプログラム・JCL・コピーブックなどのソースをS3へ置き、ジョブから参照させます。ドキュメント生成の対象となるのは、COBOLとJCLのファイルのみです。社内の略語と正式名称を並べたglossary.csvをzipのルートに置くと、生成される説明が顧客の用語に沿うと公式ガイドに記載があります。

ARTIFACT_ID.zip
├── app/
│   ├── ACCTUPD.CBL
│   ├── DAILYBAT.JCL
│   └── copy/ACCTREC.CPY
└── glossary.csv

# glossary.csv（略語,正式名称 の2列。ヘッダ行なし）
ACCT,Account
CUST,Customer
INTRT,Applied interest rate
BTCH,Nightly batch

# zipにまとめてS3へ配置する
zip -r ARTIFACT_ID.zip app glossary.csv
aws s3 cp ARTIFACT_ID.zip s3://example-transform-input/mainframe/ARTIFACT_ID.zip

用語集は数十語で十分に効きます。対象は、変数名やコピーブックの項目名に頻出する3〜6文字の略語です。業務担当者が普段の会話で使う呼び名を正式名称の欄に書くと、生成された業務ルールを検収するときに読み違いが減ります。バケット名は例示なので、自社のS3バケットに置き換えてください。

Program IDの重複や欠落参照など解析前に潰すべきコードベースの不備

同じガイドは、COBOLのProgram IDが一意でないと解析結果が不正確になると注意しています。ファイル名が違っても同じProgram IDを持つプログラムが混ざっていると、呼び出し関係を正しく追えません。長年の改修で「旧版をコピーして手直しした」プログラムが残っている現場では、珍しくない状態です。

解析結果には、参照先が見つからない文やサポート外のリンクも「Codebase issues」として列挙されます。ここで欠けたコピーブックやサブプログラムを探し出してから再実行すれば、依存関係の図と業務機能の分解を埋めることが可能です。生成AIに推測で補わせるより、構成管理の棚卸しを先に済ませるほうが手戻りは小さく済みます。

生成された業務ルールと要件書を現行の業務担当者が検収する3段階の手順

AWS Transformでは、業務ロジック抽出の後にGenerate Requirementsというエージェントが動き、業務機能ごとにrequirements.mdを出力します。内容は技術に依存しない機能仕様であり、テスト可能な受け入れ基準を含むという説明です。これを鵜呑みにせず、次の順で検収します。

月次締め・利率計算など、誤ると金額が変わる業務機能から優先して読む
受け入れ基準の各項目を、現行システムの実データ1件ずつで答え合わせする
担当者が「その条件は実際には使っていない」と判断した分岐を、移行対象外として記録する

3番目の記録は見落とされがちです。使われていない分岐まで忠実に移植すると、変換量もテスト量も膨らみます。仕様復元は、移さないものを決める工程でもあります。

テスト生成と新旧突き合わせ｜生成コードの機能等価を確かめる検証の設計

生成AIが書いた単体テストは、生成AIが書いたコードの正しさを証明しません。同じ誤解から両方が作られる可能性があるからです。機能等価の判定には、現行システムの実出力という「動かせない正解」を使います。

本番相当の入力で新旧の出力を比べるPython突き合わせスクリプトの実例

夜間バッチなら、同じ入力ファイルを旧システムと新システムに流し、出力CSVをキー列で比べるのが最も確実です。次のスクリプトはPythonの標準ライブラリだけで動きます。COBOLの数値項目で出る先頭ゼロや末尾ゼロの表記差は吸収し、値そのものの違いだけを報告します。

import csv
import sys
from decimal import Decimal, InvalidOperation


def norm(v):
    v = (v or "").strip()
    try:
        # 先頭ゼロ・末尾ゼロなど、数値の表記差だけを吸収する
        return str(Decimal(v).normalize())
    except InvalidOperation:
        return v


def load(path, key):
    with open(path, newline="", encoding="utf-8") as f:
        return {row[key].strip(): {k: norm(x) for k, x in row.items()} for row in csv.DictReader(f)}


old = load(sys.argv[1], sys.argv[3])
new = load(sys.argv[2], sys.argv[3])
diffs = 0
for k in sorted(old.keys() | new.keys()):
    a, b = old.get(k), new.get(k)
    if a != b:
        diffs += 1
        print(f"{k}: old={a} new={b}")
print(f"差分 {diffs} 件 ／ 旧 {len(old)} 件 ／ 新 {len(new)} 件")
sys.exit(1 if diffs else 0)

# compare_outputs.py として保存し、旧・新の出力とキー列名を渡す
python compare_outputs.py old/out.csv new/out.csv account_no

差分があれば終了コード1を返すので、CIに組み込めば変換をやり直すたびに自動で判定できます。旧側に「0000300.50」、新側に「300.49」が出た口座は差分として表示され、片側にしか無いキーも検出されます。旧システムの出力がShift_JISやEBCDICの場合は、比較の前にUTF-8へ変換しておいてください。

端数処理と文字コードで出る差分を許容か不具合かに振り分ける判定基準

突き合わせで出る差分の多くは、変換の誤りではなく言語仕様の違いです。COBOLのROUNDED指定の有無とJavaのBigDecimalの丸めモードがずれると、1円・1銭単位の差が出ます。金額・税額・利息に関わる差分は許容せず、丸めの規則を現行に合わせて直します。

許容してよいのは、日時の書式やCSVの引用符など、後続システムが読み取れることを確認済みの表記差に限ります。判定を個人の裁量にすると、移行後に「この差は前から許容していた」という説明が通らなくなります。許容リストを文書にし、業務担当者の承認を残してください。

生成AIを使ったコード移植｜Java版上げと言語変換で異なる自動化の深さ

同じ「移植」でも、Javaの版を上げる作業とCOBOLをJavaに変える作業では、自動化できる深さがまるで違います。

Java 8から21への版上げをOpenRewriteとCopilotで分担させる実行例

版上げは、書き換え規則が決まっている作業の比率が高い領域です。OpenRewriteのMigrate to Java 21レシピは、ビルド設定の版変更や非推奨APIの置き換えを束ねた複合レシピで、公式ページには次のコマンド例が載っています（2026年10月時点でプラグイン6.50.0系）。

mvn -U org.openrewrite.maven:rewrite-maven-plugin:6.50.0:run \
  --define rewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:RELEASE \
  --define rewrite.activeRecipes=org.openrewrite.java.migrate.UpgradeToJava21 \
  --define rewrite.exportDatatables=true

レシピはModerne Source Available Licenseで提供されているため、商用の案件では利用条件を先に確認してください。レシピで書き換えきれない箇所やビルドエラーの修正は、生成AIの出番です。GitHub Copilot modernizationの公式解説によると、MavenとGradleのプロジェクトでJava 8・11・17・21・25の間の版上げを扱い、修正後のビルド確認、CVEの確認、単体テストの移行と生成までを担います。jdepsでの事前調査やjavaxからjakartaへの移行を含む手順全体はJavaマイグレーションの進め方｜JDK 8→21/25の手順にまとめています。

COBOLからJavaへの言語変換で読めるコードにするまでに残る手作業の範囲

言語変換は、版上げより人の判断が多く残ります。COBOLのPERFORMで組まれた手続き的な処理を、Javaのクラス設計に落とし直す決定は変換ツールにはできません。AWS TransformのReforgeが対象にするのも、初回変換で生成されたProcessImpl.javaで終わるクラス群の書き直しで、ドメインの切り方そのものは事前の分解工程で人が確定させます。

COBOL資産がなぜ今も残り、どこで保守が詰まるのかという背景はCOBOLはなぜ廃れたと言われるのかで扱っています。変換後のJavaを誰が保守するのかを決めないまま移植を始めると、「COBOLの癖を残したJava」を読める人がいない状態に移るだけになります。

生成AIモダナイゼーションのコストダウン効果とベンダー公表値の読み方

「モダナイゼーションコストダウン」で調べると、期間や工数の削減率を掲げたベンダー発表が多く見つかります。数字を自社の見積りに使う前に、何の工程の何を短縮した値なのかを分解して読む必要があります。

富士通が掲げる移行期間約40%短縮が対象とする工程と前提条件

富士通は2026年7月14日にFujitsu AIドリブンモダナイゼーションサービスの国内提供を始め、リライト・リホストを中心とした移行で工程期間を約40%短縮できるとしています。発表文を読むと、AIエージェントによる変換と検証の自動化に、専門エンジニアが最終判断を補うHuman-in-the-loopを組み合わせた体制が前提です。

つまり40%は、生成AIだけで出た数字ではありません。同社は2026年3月に設計書自動生成のサービスも始めており、資産分析から変換・検証までを一社で通す前提の値と読むのが妥当です。自社で一部の工程だけに生成AIを入れる場合、同じ率は見込めません。

削減が出る工程と出ない工程を分けたモダナイゼーション費用の見積り方

見積りでは、工程を「読む・書く・確かめる・切り替える」に分け、生成AIで縮むのは前の2つだと考えます。設計書が残っていない資産の調査工数と、機械的な書き換え工数は大きく減ります。新旧突き合わせのテスト、データ移行、本番切り替えのリハーサルは、生成AIを入れてもほとんど減りません。

したがって全体の削減率は、「読む・書く」が総工数に占める比率で頭打ちになります。見積りの段階で工程別の工数を出し、生成AIが効く工程だけに削減率を掛けてください。経産省の調査をもとにした費用の見積り方はレガシーシステム脱却の判断基準と進め方で解説しました。「事例」として公表される削減率は、条件の良い案件の値であることも念頭に置いてください。

生成AIモダナイゼーションの適用判断｜採用する条件と見送るべき場面

生成AIを入れるかどうかは、資産の状態で決まります。モデルの性能ではありません。

生成AIを工程に入れる条件はソースの完全性と正解データの有無

採用してよいのは、次の条件がそろう資産です。本番で動いているソースとコピーブックが全量そろい、構成管理と一致していること。現行システムの入出力データを、テスト用に取り出せること。出力の正しさを判定できる業務担当者が、検収の期間中に時間を割けること。

この3つがそろえば、仕様復元と新旧突き合わせが回り、生成AIの誤りを機械と人の両方で止められます。一度に全面移行せず、業務機能単位で切り出して順に置き換える場合は、ストラングラーフィグパターンの実装手順と切り戻し設計と組み合わせると、検収の単位を小さく保てます。

生成AI導入を見送るべき場面はソース欠落・正解不明・短期の延命の3類型

次の場面では、生成AIを入れても費用を回収できません。本番のロードモジュールに対応するソースが見つからない資産は、生成AIが読む対象そのものが欠けています。出力の正解を知る担当者が退職し、現行の出力が正しいかどうか誰も答えられない資産は、突き合わせても合否を決められません。

2〜3年以内にパッケージへ置き換える予定の延命目的なら、変換に投資するよりリホストで基盤だけ移すほうが安く済みます。移行そのものの方式選びに迷う段階であれば、マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断から判断軸を確認してください。

生成AIモダナイゼーションの導入・費用・事例に関するよくある質問

生成AIを使ったモダナイゼーションについて、検討段階でよく出る質問に答えます。

生成AIだけでCOBOLをJavaに自動変換できますか？

公式情報を確認できたAWSと富士通のサービスは、どちらも生成AIだけで変換していません。AWS Transformは、機能等価を保つ初回変換を行ったうえで、LLMによるReforgeで読みやすいJavaへ書き直す2段構成です。富士通のサービスも、AIによる変換と専門エンジニアの最終判断を組み合わせています。生成AIだけに任せると、もっともらしいが現行と動きが違うコードが混ざります。新旧の出力を突き合わせる検証を前提に考えてください。

生成AIでモダナイゼーションの費用はどれくらい下がりますか？

下がるのは主に、現行コードの調査と機械的な書き換えの工数です。富士通は工程期間の約40%短縮を掲げていますが、変換と検証の自動化に専門エンジニアの判断を組み合わせた体制での値です。新旧突き合わせのテスト、データ移行、本番切り替えは大きくは縮みません。全体の削減率は、調査と書き換えが総工数に占める比率で上限が決まると見積もるのが安全です。

生成AIを使ったモダナイゼーションの事例にはどんなものがありますか？

公開情報で確認しやすいのは、ベンダーのサービス発表です。富士通は2026年3月に設計書を自動生成するサービス、同年7月に生成AIと専門エンジニアを組み合わせた移行サービスを国内で始めました。AWSはAWS Transformでメインフレームの解析から要件書生成、Java化までを提供しています。個社の事例は条件の良い案件が公表されやすいため、削減率はそのまま自社に当てはめないでください。

ITモダナイゼーションと生成AIモダナイゼーションは何が違いますか？

ITモダナイゼーションは、古い基盤やアプリケーションを現在の技術に作り替える取り組み全体を指します。生成AIモダナイゼーションは、その工程のうちコード解読・仕様復元・テスト生成・移植に生成AIを組み込むやり方のことです。手法の選び方（リホストかリビルドか）は従来と変わらず、生成AIは選んだ手法の作業量を減らす道具という位置づけになります。

社外の生成AIサービスに業務システムのソースコードを渡しても大丈夫ですか？

契約とデータの扱いを確認してから判断します。確認するのは、入力したコードがモデルの学習に使われないこと、処理されるリージョン、ログの保存期間の3点です。AWS Transformは自社のS3バケットに置いたソースを参照する構成で、保存場所を自社で管理できます。顧客情報を含むテストデータは、マスキングしてから渡すのが基本です。社内規程で外部送信が禁じられている資産は、対象から外してください。