TL;DR：今回の検証で分かったこと
GnuCOBOLのサンプルプログラムを使い、コーディングAIエージェントによるCOBOLモダナイゼーションをEnd-to-Endで検証しました。
結論として、AIエージェントは単なるCOBOL→Java変換だけでなく、
COBOL理解 → 仕様化 → 変更影響分析 → Java移行設計 → Java実装 → 現新比較
まで、一連のモダナイゼーション工程を横断して支援できました。
特に有効だと感じたのは、コード生成そのものよりも、既存コードの理解、仕様サルベージ、変更影響分析といった**「コードを書く前の作業」**です。
一方、Java移行後の比較では、売上・コミッション・給与など主要な業務計算はCOBOL版と一致したものの、Report Writer由来の帳票レイアウトには差異が残りました。
つまり今回の検証から得られたポイントは、次の3つです。
- AIは「コード変換器」より、モダナイゼーション工程を横断するエージェントとして使う方が可能性が大きい
- 「コードが生成できた」ことと「移行が正しい」ことは別であり、現新比較・テストが不可欠
- AIの生成物を正解とせず、原典コード・実行結果・テスト・人間のレビューをSource of Truthとして扱う必要がある
なお、本検証は単一のGnuCOBOLサンプルを対象とした探索的検証であり、大規模な実システムへの適用可能性を保証するものではありません。
はじめに
生成AIを活用したソフトウェア開発というと、「コードを生成する」「既存コードを書き換える」といったコーディング支援がまず思い浮かびます。
しかし、レガシーシステムのモダナイゼーション、とりわけCOBOL資産を対象とする場合、問題は単純なコード変換だけではありません。
長年利用されてきたシステムでは、ソースコードそのものが事実上の仕様書になっていることがあります。また、プログラムの変更にあたっては、既存ロジックの理解、業務仕様の復元、変更影響の調査、移行方式の設計、テスト、そして現行システムとの動作比較までを行う必要があります。
IBMもCOBOLモダナイゼーションについて、単なる新しいプログラミング言語への翻訳ではなく、既存のビジネスロジックや機能を維持しながら、アプリケーションや開発方式を更新していく取り組みとして説明しています。[1]
一方、近年のコーディングAIは「コード補完ツール」から、計画・実装・検証といった複数の工程を横断して処理するAIエージェントへと発展しつつあります。たとえばIBM Bobは、コード生成だけではなく、既存コードの理解、ドキュメント生成、リファクタリング、デバッグ、タスクの自動化などをSDLC全体で支援するAI Development Partnerとして位置付けられています。[2][3]
そこで今回、次の問いを設定しました。
コーディングAIエージェントは、COBOLコードをJavaに変換するだけでなく、「理解 → 仕様化 → 変更影響分析 → 移行設計 → 実装 → 検証」というモダナイゼーションの一連の工程をどこまで支援できるのか？
本記事では、GnuCOBOLで動作するサンプルプログラムを対象に、コーディングAIエージェントを利用したEnd-to-Endの探索的検証を行った結果を紹介します。
なお、本検証は限定されたサンプルプログラムを用いた探索的検証です。大規模な実システムや本番環境における性能・品質・適用可能性を保証するものではありません。
1. 今回検証したかったこと
今回あえて「COBOL→Java変換」だけを検証対象にはしませんでした。
実際のモダナイゼーションでは、Javaコードを生成できたとしても、それだけで移行が完了するわけではないからです。
今回想定したワークフローは次のとおりです。
| Step | モダナイゼーション工程 | AIエージェントに期待する役割 |
|---|---|---|
| 1 | 既存資産の理解 | COBOLコードを読み、処理内容や構造を説明する |
| 2 | 仕様サルベージ | コードから業務ルールや入出力、計算ロジックを仕様として整理する |
| 3 | 変更影響分析 | 業務要件の変更がどこに影響するかを分析する |
| 4 | 移行設計 | COBOL固有の構造をJavaでどう実装するか設計する |
| 5 | Java実装 | 設計に基づきJavaコードを生成する |
| 6 | 現新比較 | COBOL版とJava版を実行し、結果を比較・検証する |
ポイントは、コード変換をモダナイゼーションの「中心」ではなく、一連の工程の一部として扱ったことです。
2. 検証対象：GnuCOBOLのサンプルプログラム
今回の検証には、オープンソースのCOBOLコンパイラであるGnuCOBOLで動作するCOBOLプログラムを利用しました。
GnuCOBOL（旧OpenCOBOL）は、COBOL 85、X/Open COBOL、およびCOBOL 2002、2014、2023などの新しいISO COBOL標準の相当部分に加え、IBM COBOLやMicro Focus COBOLなどの各種COBOL処理系に由来する拡張機能をサポートしています。また、COBOLソースをCへ変換し、ネイティブCコンパイラを用いて実行可能形式を生成します。[4]
検証対象には、GitHubで公開されている michelou/cobol-examples リポジトリのCOBOLサンプルを利用しました。[5]
このリポジトリには、Windows環境でCOBOLを試すためのサンプルコードやビルドスクリプトが収録されており、GnuCOBOL 3.2が依存ソフトウェアの一つとして指定されています。今回利用した coughlan-examples には、Michael Coughlanの書籍をもとにしたCOBOLサンプルが収録されています。[5]
今回の検証対象は、その中の以下のプログラムです。
Repository:
michelou/cobol-examples
Target:
coughlan-examples/18_SolaceSales
COBOL Source:
src/main/cobol/SolaceSales.cbl
対象の SolaceSales は、入力データから担当者別・州別の売上を集計し、売上に応じたコミッションや給与を計算して帳票を生成するプログラムです。
単純なHello Worldではなく、集計処理、コミッション・給与計算、コントロールブレーク、Report Writerを用いた帳票出力などを含んでいるため、今回のモダナイゼーション検証の題材として採用しました。
検証時には488件の入力レコードがあり、最終的に135名の担当者、46州のデータが処理対象となりました。COBOL版の総売上は $5,741,647.18 であり、後述するJava移植後の現新比較では、この値を含む主要な業務数値を比較しました。
このプログラムを題材として、AIエージェントとの対話を通じて、
理解 → 仕様化 → 変更影響分析 → Java移行設計 → Java実装 → 現新比較
という一連のモダナイゼーションワークフローを検証しました。
3. Step 1：まずCOBOLを「理解」させる
最初に行ったのはJavaへの変換ではありません。
AIエージェントにCOBOLソースを読み込ませ、
「このプログラムが何をしているのか説明してください」
というところから始めました。
AIエージェントは、プログラム構造だけではなく、入力データ、売上集計、担当者単位の処理、州単位の処理、コミッション計算、帳票出力といった処理の流れを整理しました。
ここで重要だと感じたのは、単純な「コードの日本語訳」ではなく、プログラム全体を業務処理の単位として説明させられることです。
レガシーシステムでは、設計書が存在しない、あるいは設計書と現行コードに乖離があるケースも珍しくありません。その場合、最初の作業は「現行コードが実際に何をしているのか」を把握することになります。
IBM Bobの公式ドキュメントでも、既存コードベースについて質問し、コードを説明したり、コードからドキュメントを生成・更新したりすることが主要機能として挙げられています。[2]
今回の検証でも、この「理解」の工程が、その後の仕様化や影響分析の前提となりました。
→ Step 1：COBOL理解に関するAIエージェントの生成成果物を見る
4. Step 2：ソースコードから現行仕様を復元する
次に、
「このCOBOLプログラムをもとに、現行仕様を整理してください」
と依頼しました。
AIエージェントは、コード中のデータ構造や処理フローから、入力、出力、計算ロジック、集計単位などを整理していきます。
ここでは単なるソースコード解説から一歩進み、コードに埋め込まれた業務ルールを人間が読める形に変換することを狙いました。
生成された現行仕様書の一部
| 項目 | 抽出された仕様 |
|---|---|
| 売上集計 | 担当者単位で売上を累積し、担当者変更時に集計を確定 |
| コミッション | 担当者の売上合計を基にコミッションを算出 |
| 給与計算 | 州別の基本給とコミッションを基に給与を算出 |
| 州別集計 | 州変更時に州単位の集計を確定 |
| 帳票出力 | COBOL Report Writerを利用して担当者・州・全体の結果を出力 |
これはいわゆる「仕様サルベージ」に近い作業です。
たとえば今回のプログラムでは、担当者の売上からコミッションを算出し、それを給与計算へ反映するロジックが存在します。
COBOLコードだけを読めば計算式は確認できます。しかし、AIエージェントに処理を追わせることで、
「どの入力値が使われるのか」
「どのタイミングで集計されるのか」
「計算結果が最終的にどの帳票項目へ影響するのか」
までを連続した処理として整理できます。
この工程は、単純なコード生成とは異なるAIエージェントの使い方として興味深い部分でした。
→ Step 2：現行仕様の復元に関するAIエージェントの生成成果物を見る
5. Step 3：「コミッション率を8%から10%へ変更」で影響分析
次に、あえて業務変更要求を与えました。
今回設定した変更要求はシンプルです。
コミッション率を8%から10%へ変更したい。影響範囲を調査してください。
単純に考えれば、ソースコード中の0.08を0.10へ変更すればよいようにも見えます。
しかし実際の保守では、「どこを書き換えるか」だけではなく、その変更が何に波及するかを把握する必要があります。
今回、AIエージェントはコミッション率そのものだけでなく、その値を利用するコミッション計算、給与計算、帳票出力、関連する仕様書やテスト観点まで影響を追跡しました。
概念的には次のような依存関係です。
コミッション率
↓
コミッション金額
↓
給与計算
↓
帳票出力
↓
仕様書・テストケース
AIエージェントが整理した影響範囲
| 対象 | 影響 | 対応 |
|---|---|---|
| コミッション率 | 8% → 10% | 変更 |
| コミッション計算 | 算出結果が変化 | 要確認 |
| 給与計算 | コミッション増加に伴い変化 | 要確認 |
| 帳票出力 | コミッション・給与表示に影響 | 要確認 |
| 売上集計 | 計算ロジック自体には影響なし | 変更不要 |
| 州別売上集計 | 計算ロジック自体には影響なし | 変更不要 |
| テスト | 期待値の変更が必要 | 要更新 |
また、適用開始日や既存データへの遡及適用など、ソースコードだけでは判断できない事項については「要確認事項」として整理されました。
一方、売上金額そのものの集計や州別集計など、変更の影響を受けない処理については変更対象から切り分けられました。
さらに興味深かったのは、AIエージェントがコード変更だけでは判断できない事項も挙げたことです。
たとえば、「新しい料率をいつから適用するのか」「既存データへ遡及適用するのか」といった業務判断は、当然ながらソースコードだけから確定することはできません。
つまりAIエージェントは影響候補を広く洗い出すことはできますが、最終的な業務仕様の確定までAIだけで完結するわけではないことも確認できました。
これは実運用を考えるうえで重要なポイントです。
→ Step 3：変更影響分析に関するAIエージェントの生成成果物を見る
6. Step 4：いきなり変換せず、Java移行方式を設計する
影響分析の次にJava化へ進みました。
ただし、ここでもいきなり、
「このCOBOLをJavaにしてください」
とは依頼していません。
まず、COBOL固有の構造や処理をJava側でどう表現するかを設計させました。
今回のプログラムには、固定長データ、PICによるデータ定義、コントロールブレーク、Report Writer、GROUP INDICATEなど、Javaへ単純に1対1変換しにくい要素が含まれています。
AIエージェントはこれらを分析し、Java側のクラス構造や責務、帳票生成方式、金額計算などへ対応付ける移行設計を作成しました。
Java移行設計の一例
| COBOL側 | Java側での実装方針 |
|---|---|
| 固定長入力レコード | 入力レコードクラスとしてモデル化 |
| PICによる数値定義 | Javaのデータ型として再設計 |
| 担当者単位のコントロールブレーク | Javaの集計ロジックとして実装 |
| 州単位のコントロールブレーク | 州別集計処理として実装 |
| Report Writer | Java側の帳票生成処理へ再設計 |
| GROUP INDICATE | 出力制御ロジックとして実装 |
ここでのポイントは、Syntax TranslationではなくSemantic Transformationを考えさせることです。
たとえばCOBOLのある段落をそのままJavaのメソッドへ置き換えるだけでは、必ずしも保守しやすいJavaになるとは限りません。
COBOLが持つ処理上の意味を理解したうえで、Java側ではクラスやメソッドとしてどう再構成するかを考える必要があります。
この「理解 → 設計 → 実装」の間に設計工程を置くことは、AIを使ったモダナイゼーションでも重要だと感じました。
→ Step 4：Java移行設計に関するAIエージェントの生成成果物を見る
7. Step 5：設計をもとにJava実装を生成する
移行設計ができたところで、Java実装を生成しました。
今回の検証では、最終的にJava 21を前提とした13クラスの実装が生成されました。
ここまで来ると、一般的にイメージされる「生成AIによるコード変換」に近づきます。
しかし今回のワークフローでは、その前段階ですでに、
COBOL理解 → 仕様復元 → 影響分析 → Java移行設計
を行っています。
そのため、Javaコード生成は独立した一発変換ではなく、それまでにAIエージェントが構築したコンテキストを引き継いだ実装工程になります。
この違いは大きいと考えています。
近年の研究でも、LLMを利用したレガシーコード変換について、単純なコード生成だけでは十分な正確性を保証できず、コンパイル結果やテスト、外部コンテキストを利用した反復的な改善が重要であることが報告されています。
たとえば2026年に報告されたLegacyTranslateでは、単一のLLMによる翻訳だけではなく、初期変換、API Grounding、コンパイラフィードバックを利用したRefinementという複数エージェント型のアプローチが提案されています。[6]
今回の検証も規模や手法は異なりますが、「一度のプロンプトでコードを変換して終わり」ではなく、複数工程を連続して処理するという点では近い考え方です。
→ Step 5：Java実装に関するAIエージェントの生成成果物を見る
8. Step 6：一番重要なのは「変換できた」ではなく「同じ結果になるか」
Javaコードが生成できました。
しかし、ここで検証を終了すると、
「AIにCOBOLを渡したらJavaが生成されました」
というだけの記事になってしまいます。
モダナイゼーションで本当に重要なのは、生成されたJavaが現行COBOLと同じ業務結果を出すかです。
そこで最後に、COBOL版とJava版の双方を実行し、出力結果を比較しました。
今回の結果は以下のとおりです。
| 比較項目 | COBOL版 | Java版 | 結果 |
|---|---|---|---|
| 入力レコード | 488件 | 488件 | 一致 |
| 担当者 | 135名 | 135名 | 一致 |
| 州 | 46州 | 46州 | 一致 |
| 総売上 | $5,741,647.18 | $5,741,647.18 | 一致 |
| 売上・コミッション・給与計算 | 基準 | 比較 | 一致 |
| ページ数 | 32ページ | 31ページ | 差異あり |
| 出力行数 | 2,100行 | 2,015行 | 差異あり |
業務上重要な売上集計、コミッション、給与計算については一致しました。
一方で、すべてが完全一致したわけではありません。
差異が残ったのは帳票レイアウトです。
COBOLのReport Writerが持つページブレークや空白行などの帳票制御をJava側で完全には再現できず、COBOL版が32ページ、Java版が31ページとなりました。
この結果は今回の検証で特に重要だったと考えています。
「Javaへ変換できたか」をYes/Noで評価するのではなく、
何が一致し、何が一致しなかったのか
を明示する必要があるからです。
→ Step 6：COBOL版とJava版の現新比較に関するAIエージェントの生成成果物を見る
9. AIによるCOBOL→Java変換では「検証」が独立した工程になる
この点は、近年の研究でも重要な課題として扱われています。
Kumarらは、LLMによるCOBOL→Java変換について、生成されたJavaコードをそのまま正しいと仮定することはできないとして、COBOLとJavaの意味的等価性をテストによって検証する手法を提案しています。[7]
関連研究でも、COBOL側からテストを生成し、対応するJUnitテストをJava側で実行することで、変換前後の機能的等価性を確認するアプローチが報告されています。[8]
今回の検証でも、まさに同じ問題に遭遇しました。
コードがコンパイルできることと、業務的に正しいことは同じではありません。
さらに、
コンパイルできる
↓
実行できる
↓
主要な計算結果が一致する
↓
帳票・副作用まで一致する
↓
業務的に同等である
というように、「正しさ」には複数のレベルがあります。
AIによるコード変換を実用化するためには、TransformationとValidationをセットで設計する必要があると考えます。
10. 実際に試して見えてきたAIエージェントの得意領域
今回の探索的検証から、コーディングAIエージェントの価値は「Javaコードを高速に生成できること」だけではないと感じました。
むしろ、以下のような工程を連続して支援できることに大きな可能性があります。
| 工程 | 今回確認できた支援 |
|---|---|
| 理解 | COBOLの構造・処理フロー・計算ロジックの説明 |
| 仕様化 | コードから現行仕様・業務ルールを整理 |
| 影響分析 | 変更要求から関連ロジック・帳票・テストへの影響を追跡 |
| 移行設計 | COBOL固有構造をJava側の設計へマッピング |
| 実装 | 設計を踏まえたJavaコード生成 |
| 検証 | COBOL版とJava版の実行結果比較、差異の分析 |
つまり、
AIを「コード変換器」として使うのではなく、「モダナイゼーション工程を横断するエージェント」として使う
という考え方です。
IBM Bobも現在、単純なコード生成ではなく、計画・実装・検証をSDLC全体で扱う方向へ機能を拡張しています。IBMの2026年7月の発表では、メインフレーム向け機能として影響分析、依存関係分析、ビジネスコンテキストの発見、コード説明、リファクタリング、変換などが示されています。[9]
ただし、ここは注意が必要です。
今回検証したのはGnuCOBOLのサンプルプログラムを利用した探索的なワークフローであり、IBM Z上の実システムを対象とした検証ではありません。
したがって、IBM Bob Premium Package for Zなどのプラットフォーム固有機能の評価と、今回のGnuCOBOLによる検証結果は分けて考える必要があります。
11. 一方で、AIの出力をそのまま信じてはいけない
今回の検証では、AIエージェントが非常に多くの成果物を生成しました。
しかし、AIが生成した分析レポートや仕様情報の中には、元のコードや別の生成物と照合すると細かな不整合が見つかる箇所もありました。
これは重要な示唆です。
AIエージェントが仕様書らしい文章を生成すると、人間はそれを「正しい仕様書」と認識しやすくなります。しかし、その文章もあくまでAIによる推論結果です。
したがって、
Source of TruthはAIが生成したドキュメントではなく、原典となるコード、実行結果、テスト結果である
という原則は変わりません。
COBOLに特化したLLMの研究でも、一般的なLLMではCOBOLコード生成・変換の正確性に課題があることが報告されています。2026年のCOBOL-Coderの研究では、COBOL向けに特化したデータやコンパイラによる検証を組み合わせることで性能向上が確認されており、レガシー言語に対するドメイン知識と検証の重要性が示されています。[10]
AIが非常にもっともらしい回答を生成できるからこそ、コンパイル・実行・テスト・人間によるレビューを組み合わせたHuman-in-the-Loopの設計が重要になると考えます。
12. 今回の検証の限界
今回の結果をそのまま大規模な企業システムへ一般化することはできません。
今回対象としたのは単一のGnuCOBOLサンプルであり、実際のエンタープライズCOBOL環境では、複数プログラム間の依存関係、COPY句、DB、ファイル、JCL、トランザクション、外部システム連携、長年蓄積された例外処理など、より複雑な要素が存在します。
また、今回の評価では主要な業務計算結果を比較しましたが、完全な意味的等価性を形式的に証明したわけではありません。
したがって本検証の結果は、
「AIを使えばCOBOLを自動的にJavaへ移行できる」
ことを示すものではありません。
今回確認したのは、
「限定されたサンプルにおいて、AIエージェントがCOBOL資産の理解から仕様化、影響分析、移行設計、Java実装、現新比較までを連続して支援できる可能性」
です。
この違いは強調しておきたいと思います。
13. 次に検証したいこと
今回の検証を通じて、次のテーマは「変換精度をさらに上げること」だけではないと感じました。
より実践的なPoCでは、実際のCOBOL資産を対象として、AIエージェント導入前後で人間の作業がどの程度変化するかを測る必要があります。
たとえば、既存コード理解に要する時間、変更影響調査時間、仕様書作成時間、テストケース作成時間、有識者によるレビュー時間などをBefore / Afterで測定する方法が考えられます。
さらに、単一ファイルだけではなく、複数プログラムや仕様書、データ定義、テスト資産などをコンテキストとして与えた場合に、どの程度正確に依存関係や業務ルールを把握できるかも検証したいテーマです。
AIエージェントにとって重要なのは、モデルそのものの能力だけではなく、「どのコンテキストを与え、どのツールを利用させ、どこで人間が承認し、どのように実行結果をフィードバックするか」だからです。
IBM Bobでも、MCPを通じて外部のツールやシステムをコンテキストに接続する仕組みが提供されています。[11]
このあたりまで進むと、「AIにCOBOLコードを読ませる」という話から、AIエージェントを組み込んだモダナイゼーション・ワークフローそのものを設計するという話になってきます。
まとめ
今回、GnuCOBOLのサンプルプログラムを題材に、コーディングAIエージェントによるCOBOLモダナイゼーションを探索的に検証しました。
その結果、AIエージェントは単純なコード変換だけでなく、既存コードの理解、仕様化、変更影響分析、移行設計、Java実装、現新比較までを一連の流れとして支援できる可能性を確認できました。
一方で、主要な業務計算はCOBOL版とJava版で一致したものの、帳票レイアウトには差異が残りました。
「コードが生成できた」ことと「モダナイゼーションが完了した」ことは同義ではない
AIの生成物をそのまま正解とするのではなく、原典コード、実行結果、テスト、人間によるレビューを組み合わせて検証することが重要です。
今回の検証で最も可能性を感じたのは、AIを単なる「COBOL→Java変換器」ではなく、既存システムの理解から変更・移行・検証までを一緒に進める開発・保守のパートナーとして活用することでした。
今後は、より実践的なCOBOL資産を対象に、人間の調査・設計・検証作業をどこまで効率化できるのかを検証していきたいと考えています。
参考文献
[1] IBM, “What Is COBOL Modernization?”, 2025, updated 2026.
IBM — What Is COBOL Modernization?
[2] IBM, “Welcome to IBM Bob — IBM Bob Docs”, 2026.
IBM Bob Documentation
[3] IBM, “AI coding agent for enterprises — IBM Bob”, 2026.
IBM Bob product page
[4] GnuCOBOL Project, “GnuCOBOL — A free COBOL compiler.”
GnuCOBOL Project
[5] Michelou, “cobol-examples: Playing with COBOL on Windows,” GitHub.
michelou/cobol-examples — GitHub
[6] Z. Moti, H. Soudani, J. van der Kogel, “LegacyTranslate: LLM-based Multi-Agent Method for Legacy Code Translation,” arXiv, 2026.
LegacyTranslate paper
[7] A. Kumar et al., “Automated Validation of COBOL to Java Transformation,” arXiv, 2025.
Automated Validation of COBOL to Java Transformation
[8] S. Hans et al., “Automated Testing of COBOL to Java Transformation,” arXiv, 2025.
Automated Testing of COBOL to Java Transformation
[9] IBM, “IBM Bob advances agentic software development with Premium Packages and a new enterprise AI foundation,” 2026.
IBM Bob Premium Packages announcement
[10] A. T. V. Dau et al., “COBOL-Coder: Domain-Adapted Large Language Models for COBOL Code Generation and Translation,” arXiv, 2026.
COBOL-Coder paper
[11] IBM, “Shifting from AI-assisted coding to AI-assisted delivery with IBM Bob,” 2026.
IBM — AI-assisted delivery with IBM Bob