COBOLモダナイゼーションはコード変換ではない

AIで業務ルールを復元する3段階

COBOLモダナイゼーションという言葉を聞くと、COBOLをJavaやPythonへ変換する作業を想像しがちです。

確かに、古い言語を新しい言語へ置き換えることは重要です。しかし、コードを変換しただけでは、長年動いてきた業務システムを正しく刷新したことにはなりません。

本当に必要なのは、ソースコードの書き換えではなく、システムに埋め込まれた業務意図の復元です。

AWS公式ブログは2026年7月22日、AWS TransformとAccentureのAIエージェントを組み合わせた、メインフレーム刷新の共同手法を紹介しました。

この手法は、次の3段階で構成されています。

1. メインフレーム資産を解析し、業務ルールを抽出する
2. 業界・業務知識を加えて、抽出した仕様を補強する
3. クラウドネイティブまたはローコード環境で再構築する

AWS Transformによる自動コード解析と業務ルール抽出に、Accentureの業界知識や専用AIエージェントを組み合わせる構成です。再構築先としては、Kiroを使ったクラウドネイティブ開発と、Pega Blueprintを使ったローコード開発の2つの経路が示されています。

調査対象はCOBOLソースだけではない

この公式記事で重要なのは、解析対象がCOBOLコードだけではないことです。

実際のメインフレームシステムでは、プログラム単体を読んでも全体の動きは分かりません。

確認が必要なのは、次のような資産です。

• プログラム間のCALL関係
• COPY句とデータ構造
• JCLとバッチの前後関係
• CICS画面とトランザクション
• DB、ファイル、IBM MQとの連携
• ジョブの実行履歴
• 動的なプログラム呼び出し
• コード内に埋め込まれた業務ルール

AWSとAccentureの手法でも、バッチ実行履歴、CICSのトランザクション活動、IBM MQのイベント、システム性能情報、IMS DBログ、スケジューラ、ファイル転送、CICSのトレース情報などを解析対象としています。

さらに、COBOL、JCL、COPY句、SMFレコード、BMSマップ、DB2・IMS・IDMSのスキーマなどの資産を解析し、得られた情報を中央の知識グラフへ集約します。

これは、現場SEの感覚にも合っています。

同じCOBOLプログラムでも、どのJCLから呼ばれるかによって役割が変わります。どのCOPY句を使うかによって、入出力データの意味も変わります。

ソース上では使われていないように見える処理でも、特定の時期や条件でだけ実行されていることがあります。静的解析だけでなく、実際の実行履歴まで確認しなければ、業務上の重要性を見誤る可能性があります。

業務知識がなければ、正しい仕様にはならない

AIがソースコードを解析し、条件分岐や計算式を文章化できたとしても、それだけでは十分ではありません。

たとえば、ある計算処理が何を意味しているのかは、コードだけでは判断できない場合があります。

税率変更への対応なのか。
法改正による経過措置なのか。
特定顧客向けの例外処理なのか。
過去データを維持するための処理なのか。

その意味を理解するには、業界知識と業務知識が必要です。

AWS公式記事でも、抽出した業務ルールへ金融や通信分野の知識、規制対応、業務固有のルールを加えることで、仕様の精度と文脈を補強すると説明されています。

つまり、AIがコードから仕様を作るだけではなく、現場の業務知識を使って、その仕様が何を意味するのかを確認する必要があります。

変換後コードより、現行動作との比較が重要

新しいシステムを作ったあとに最も重要なのは、現行システムと同じ業務結果になるかを確認することです。

COBOLをJavaやPythonへ変換し、コンパイルが成功しただけでは不十分です。

入力データに対する計算結果。
固定長ファイルの出力位置。
帳票の金額や件数。
バッチの処理順序。
異常時の終了コード。
後続システムへ渡すデータ。

これらが現行システムと一致している必要があります。

特に自治体、金融、保険、医療などのシステムでは、1円、1件、1桁の差が大きな問題になります。

そのため、モダナイゼーションでは次の流れを固定すべきです。

資産一覧を作成する
　↓
依存関係を調査する
　↓
業務ルールを抽出する
　↓
業務知識で仕様を補強する
　↓
新しいシステムを実装する
　↓
現行結果と比較する
　↓
差異があれば原因を調査する
　↓
修正して再テストする

AIは、資産調査、依存関係の整理、業務ルールの下書き、テスト観点の抽出に活用できます。

一方で、業務上の正しさ、例外処理の必要性、移行リスク、最終的な合否は、人間のSEが判断する必要があります。

AI時代に価値が上がるのは、COBOLを読めるSE

AIがCOBOLを解析できるようになると、COBOL技術者は不要になると思われるかもしれません。

しかし、実際には逆だと考えられます。

AIが抽出した業務ルールが正しいか。
CALLやCOPY句の関係を見落としていないか。
JCLの実行順序と一致しているか。
固定長データの意味を理解できているか。
現行結果との差異が仕様なのかバグなのか。

これらを判断するには、COBOLと現場業務の両方を理解している人材が不可欠です。

さらに、こうした判断を担える人材を継続的に育成していくことも欠かせません。AIが支援する時代であっても、COBOLを読み解き、業務の文脈を理解できるSEを教育する必要があります。

AIは、大量の資産を読み、整理し、候補を提示することには適しています。

一方で、過去の経緯や暗黙知に基づく判断など、人間でなければ理解が難しい領域も依然として存在します。

COBOLモダナイゼーションは、古いコードを新しいコードへ変換するだけの仕事ではありません。

失われかけている業務知識を、ソースコード、設計書、実行履歴、データ構造から復元し、次のシステムへ引き継ぐ取り組みです。

AI時代のレガシー改善で重要なのは、変換速度だけではありません。

業務意図をどこまで正確に復元し、現行動作と比較しながら安全に再構築できるか。

そこまで実現できて、初めて本当のモダナイゼーションと言えるでしょう。

参考資料・外部出典

• AWS Blog: Reimagining Mainframe Applications with Accenture and AWS Transform