COBOL 1万本超をAIでJavaへ ― PoCから見えた「現実解」

はじめに

COBOLで構築された基幹システムの刷新は、多くの企業にとって「いつかやらなければいけない」と分かっていながら、なかなか踏み出しづらいテーマです。あるお客様でも同様に、長年使い続けてきた基幹システムが、サーバーの保守期限やCOBOL技術者の減少といった現実的な制約によって、いよいよ限界に近づきつつありました。

基幹システムのうち、バッチ処理のCOBOLだけでも1万本超。しかも、過去の改修の積み重ねで中身はブラックボックス化し、「分かる人にしか分からない」状態になっている――。このままでは保守も刷新も難しい、という危機感から、「COBOLからの脱却」を本格的に検討することになりました。

本記事では、この基幹システムの刷新をテーマに、AIを活用しながらCOBOLをJavaへ移行するPoC（概念実証）にどのように取り組んだのか、「全部AIで自動変換」ではない現実的なアプローチと、その中で見えてきた成果・課題をご紹介します。

AIで3倍の生産性を目指したCOBOL→Javaマイグレーション

プロジェクト背景：COBOLからの脱却「今やるしかない」

お客様はバッチ処理だけでもCOBOLの規模が1万本超の大規模な基幹システムをお持ちでした。

この基幹システムは、

• サーバーの保守期限が迫っている
• COBOL技術者が減少し、今後の保守が困難
• 長年の改修により中身がブラックボックス化
• ハードウェア／ソフトウェアの保守費用が高止まり

といった課題が表面化していました。
そこでお客様は、この状況をシステム刷新の好機と捉え、

• 基盤をオープン系環境へ移行
• 開発言語もCOBOLからJavaへ移行

という方針を固めました。

ただし、バッチだけでも1万本を超える規模であるため、最初からすべてをCOBOL→Javaに変換するのはリスクが高すぎます。
そこでまずは、比較的規模の小さい機能を対象に選定し、「AIを活用したCOBOL→Java変換」が現実的かどうかを検証するPoC（概念実証）をすることになりました。

当社の提案：AIで「3倍」の生産性を目指す

当社は、多くのマイグレーション案件を担当してきており、その実績やノウハウはお客様から高く評価いただいてきました。
今回のPoCでは、そうした従来の経験に加えて、単に「COBOLをJavaに書き換える」のではなく、AIを活用して従来の3倍の生産性向上を目指しました。

従来の進め方では、

• COBOLプログラムの解析
• Javaに変換するためのオブジェクト指向設計
• Javaプログラムの実装（変換）
• 比較検証テスト（現新比較）

といった工程の多くを人手で行う必要があり、大規模な案件ではどうしても工数やコストが大きくなってしまいます。
そこでPoCでは、当社のAIサービス「sync!A」を活用し、COBOLプログラムの解析～Javaプログラムの多くの工程をAIに担わせることで、人が行う作業をできるだけ減らし、全体の生産性を大きく引き上げることを目指しました。

ポイントは「プロンプト設計」と「段階的変換」

COBOL→Java変換：「機械的変換」ではない

「COBOL→Java変換」と聞くと、手続き型の構造を維持したままのいわゆる「JaBOL（COBOL構造をそのままJavaに持ち込んだプログラム）」のイメージを持たれるかもしれません。
しかし、それでは保守性も拡張性も期待できず、COBOLから移行した意味がありません。

そこで、お客様の望む“Java”（ネイティブJava）となるよう、オブジェクト指向の観点でクラス設計を行い、Javaを生成するという手順を踏むようにしました。
AIを活用し、

• COBOLプログラムの解析
• 解析結果をもとにした「クラス設計」

この「解析→設計」という段階をふむことで、オブジェクト指向設計のプログラムに変換を目指しました。

AI活用の実際：プロンプト設計に一番時間をかけた

AIを利用されたことのある方はご存じと思いますが、ポイントとなるのが「プロンプト次第で結果が大きく変わる」という点です。
今回も、最初はとにかくプロンプトの試行錯誤に時間をかけました。Javaフレームワークには「Spring Batch」を採用したのですが、

• Spring Batchのフレームワーク構成をどう定義するか
• クラス設計の基準をどう表現するか

特に規模の大きなプログラムや、ネストの深いプログラムを解析・変換しようとすると、
「途中まで書きました。あとは同じようにしてください。」といった“途中でやめる”ような結果になり、そのままでは利用できない状態になることも多くありました。
そこで、

• COBOLプログラムのプロシージャ単位に分割して変換する
• クラス（役割）ごとに変換範囲を細かく区切る

といった工夫を盛り込み、変換の抜け漏れが発生しないようにしました。
また、「クラス構成」「フレームワーク構成」などの背景情報を事前に読み込ませ、「この情報に従ってクラス設計を行い、COBOLからJavaに変換しなさい」という形で、AIが判断しやすいようにしました。

固定長データ→RDB化：データ構造の刷新に合わせた変換

今回のPoCでは、COBOLで扱った固定長データのRDB化という「データ構造の刷新」も同時に行いました。

COBOLのCOPY句をもとに、各項目をカラムに分解し、ツールでDB設計を生成、そのDB設計をAIに読み込ませ、COBOL側の読み書きロジックをJava+SQLに置き換えという流れで進めました。

特徴的だったのは、一部のコピー句では項目数が900を超えていたため、RDB化した際にテーブルのカラム数が900超になったことです。
最初は素直に SELECT * で全カラムを取得していましたが、全件取得した場合に性能面で影響があることが分かりました。

そこで、コピー句に対してCOBOLプログラム内で実際に参照している項目だけを抽出し、その項目だけを SELECT するSQLになるようにAIに指示することで、不要なカラムへのアクセスを削減し、性能向上につなげることができました。

このように、「使用している項目に絞ってプログラムを変換する」というタスクにおいてAIが有効に働き、効率化につながりました。

品質確保のために、COBOL有識者の「目」が必須だった

AIを活用してのCOBOL→Java変換ができたとしても、品質面では比較検証テストなど後工程に影響が出るリスクがあると考えていました。そこで、当社のCOBOL有識者による変換結果チェックの工程を設けました。
具体的には、次のように進めました。

• AIでのCOBOL→Java変換を実施
• 変換されたJavaを、COBOL有識者が「変換結果レビュー」という形で確認し、明らかにおかしい処理や不自然なロジックを洗い出す
• 見つかった問題点をもとに、AIへの指示内容（プロンプト）を見直し・改善
• 改善したJavaプログラムをコンパイルし、単体テストで基本的な動作（疎通）を確認
• 新旧環境で同じデータを使ってバッチ処理を実行し、入出力結果が一致するかを比較検証
• 差分が出た箇所については、人手で原因を分析し、必要な修正を加える

変換結果のレビューには複数のCOBOL有識者が関わりました。
AIへのプロンプト設計とその調整は一人に集約し、プログラムごとに指示内容がぶれないように注意しました。このようなプロセスを踏むことで、

• AIだけでは正しく変換しきれない複雑な業務ロジック
• COBOL特有の書き方をしている処理

といった部分を人間の目で補正しながら、品質を高めることができました。

おわりに：マイグレーション×AI の会社として

最近は「AIでレガシーシステムのプログラムを自動変換します」とうたうサービスやベンダーが増えています。
しかし、今回のPoCを通じてあらためて実感したのは、「AIにすべてを任せれば、短期間・低コストで移行できる」といった“魔法のような解決策”は存在しない、ということです。

理由は3つあります。

1. プロンプト設計には対象言語やフレームワークへの深い理解が欠かせない
   COBOLからJava（Spring Batch）へ変換する場合でも、「どういう構造のクラスに分割するか」「どのフレームワーク機能をどう使うか」といった設計方針を、AIに正しく伝えられる知識が必要
2. 変換結果が本当に正しいかどうかを判断するには、COBOL有識者の目が不可欠
   AIが生成したJavaプログラムが、元のCOBOLと同じ動きをしているか、業務ロジックとして破綻していないかを見極めるには、COBOLと業務の両方を理解した人間によるレビューが必要
3. 性能チューニングやRDB設計といった領域は、依然として人間の設計スキルに大きく依存している
   どの項目をどのようにテーブル設計するか、どのカラムを絞り込んでSQLを発行するか、といった判断は、システム全体の構造や運用を踏まえた設計力が必要

こうした前提のもとで、当社はこれまでに培ってきた

• レガシーマイグレーションの実戦ノウハウ
• COBOLを熟知した有識者の知見
• Java、RDBの設計・実装スキル

といった人の知見と、生成AIをはじめとするAI技術を組み合わせることで、
「現実的なコストとスケジュールで成立するマイグレーション」を実現します。

当社では、ホスト／オープンを問わずレガシーシステムの棚卸し・分析から、マイグレーション計画の策定、クラウド（AWS）を含む新基盤への移行、そして移行後の保守・運用まで、一気通貫でご支援しています。今回のようなPoCレベルでの検証からのご相談も可能です。

レガシー資産を活かしながら、現実的なコストとスケジュールで次の一歩を踏み出したいとお考えの企業様は、ぜひお気軽にお問い合わせください。