NTT DATA

DATA INSIGHT

NTT DATAの「知見」と「先見」を社会へ届けるメディア

キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
2024.12.25技術トレンド/展望

生成AIによる脱COBOLで考慮すべき再設計指針

レガシーシステムのマイグレーション開発の代表的な目的の1つに脱レガシー言語があり、COBOLからJavaへの変更は特に要望が多い。しかし、ルールベースのソースコード変換ではCOBOL特有の仕様が残されるため、COBOLとJava両方の知識が必要となるソースが生成される問題がある。生成AIによりCOBOLの知識を必要としない「PureJava」なソースを生成できるようになりつつあるが、その正しさをチェックするため比較対象の設計書整備も必要になる。本記事では、COBOLからJavaへの仕様変換の方針であるJava再設計指針を用いて、言語の特徴の違いに注目しながら「PureJava」なソースを生成する方法を解説する。
目次

生成AIによる「PureJava」なソースの生成で生じる問題

脱メインフレームを目的としたCOBOLシステムのマイグレーション開発の事例は多数存在し、開発手法として主にリライト、リホストが採用されています。そのいくつかの事例では、Java技術者でも保守できるシステムを目標に、ルールベースの変換ツールを使用したJavaへのリライトが選択されています。しかし、ルールベース変換のリライトではCOBOL特有の仕様が残されるため、COBOLとJavaの両方の知識が必要となるソースが生成される問題があります。

図1:ルールベースの変換ツールでリライトされたJavaの例

近年、生成AIの精度向上によりCOBOLの知識を必要としない「PureJava」なソースの生成ができるようになりつつあります(※)。しかしその一方で生成AIを用いたJavaソース生成には不正確な結果が含まれるハルシネーションの問題があります。ハルシネーションの有無を確認するためには、人間が内容をチェックする必要がありますが、現行の設計書を修正せずそのまま流用した場合、設計書にはCOBOLに沿った仕様が記述されているため、設計書とソースの比較が困難になるという問題があります。

図2:Javaに沿った設計書を作らずに「PureJava」なソースを生成した場合の問題点

チェックを行うためには、Javaに沿った設計書を作成した上で、設計書とソースを比較する必要があります。本記事では、COBOL仕様からJava仕様への変換の方針であるJava再設計指針を用いた「PureJava」なソースの生成方法について、COBOLとJavaの特徴の違いに注目して解説します。

(※)「GitHub Copilot で COBOL をモダナイズ」

https://resources.github.com/ja/software-development/modernizing-cobol-with-github-copilot/

COBOLソースとJavaソースの違い

COBOLソースとJavaソースでは、オブジェクト指向の有無によるプログラム構造の違い、扱える型の違い、エラーハンドリングの違いなどいくつかの相違点がありますが、代表的なものとしてメモリ領域、ファイルのレコードの固定長/可変長の違いがあります。

COBOLにおいては、プログラムが使用するメモリ領域やファイルのレコードは、事前に固定長の領域が確保され、その範囲内で処理が行われる設計が一般的です。このため、文字列長および配列長は原則として固定長となります。ファイルの設計方針としては、一定サイズごとにレコードが分割される形式が採用されており、改行コードによるレコード分割は通常用いられません。

対照的にJavaでは、プログラムが使用するメモリ領域やファイルのレコードは、必要に応じて動的に確保される設計が主流です。これにより、文字列長および配列長は実データに基づいた可変長を基本とする設計となります。さらに、ファイルのレコード分割は、基本的に改行によって行われ、ファイルが扱うデータの特性に応じてCSV、JSON、XMLなどのフォーマットが使い分けられることが一般的です。

図3:COBOLソースとJavaソースの違い

COBOLソースのみを生成AIに入力しJavaソースを生成した場合の問題点

COBOLソースのみを生成AIに入力しJavaソースを生成するという方針にした場合、前述のルールベース変換のリライトと同様の問題が生じます。具体的には、COBOLのファイル入出力仕様に合わせるため、空き領域をスペースで埋めるための処理や、一定バイトごとに項目を区切るためのメモリ操作が必要となりますが、業務仕様とは関係のない冗長なロジックであり、可読性の低下やCOBOL知識が必要となる制約につながります。

図4:COBOLソースのみを生成AIに入力しJavaソースを生成した場合の問題点

生成AIを用いたCOBOL仕様の問題の解決策

前述のCOBOL仕様の問題点を解決するアプローチとして、2通りの解決方法があります。それぞれの解決方法について紹介します。

1.Java再設計指針を生成AIに入力しJavaソースを生成する方法

プログラム間で共通のJava再設計指針を生成AIに入力しJavaソースを生成した場合、COBOL仕様の問題の大半は解決できます。しかし、プログラムごとに仕様の判断が求められるケースで問題が残ります。以下の例では、数値項目を計算に使うか画面表示に使うかでint型とString型いずれの可能性もありえますが、COBOLソースにどちらかを判断するための情報がないため、int型を期待していたにもかかわらずString型でソースが生成されています。

また、設計書がCOBOL仕様に基づいているため、設計書とソースの単純比較ができずハルシネーションの検知が困難である点も、この解決方法のデメリットとなります。

図5:Java再設計指針を生成AIに入力した場合のJavaソース例

2.事前作成したJava仕様を生成AIに入力しJavaソースを生成する方法

プログラムごとに事前に作成したJava仕様を生成AIに入力しJavaソースを生成することによって、仕様判断が必要なケースの問題を解決することができます。COBOL仕様を元にしたJava仕様の作成は、Java再設計指針を用いることで効率的に行えます。

再設計指針の具体例として、「画面項目は、可変長の文字列型(String型)を使用する。その他の数値を扱う項目は数値型を使用する。扱う値の範囲に応じて、int型、long型、BigInteger型を使い分ける」があります。COBOL仕様を確認し画面項目かどうかを確認することにより、正しいJava仕様を作成することができます。

図6:再設計指針の例

こうして作成したJava仕様をCOBOLソースと共に生成AIに入力することにより、期待通りのJavaソースが生成できます。前述の数値項目は、Java仕様でint型と指定したことにより正しくint型でJavaソースが生成されるようになりました。

また、プログラムごとにJava仕様を作成したことによりソースと設計書の比較が可能になったため、生成AIのハルシネーションによって生じる抜け・漏れや矛盾性などの問題を検知することができるようになった点もこの解決方法のメリットになります。

図7:事前作成したJava仕様を生成AIに入力した場合のJavaソース例

まとめ

本記事では、COBOLからJavaへの再設計指針とその活用方法について解説しました。生成AIを活用してCOBOLの知識を必要としない「PureJava」なソースを生成するためには正しいJava仕様の作成が必要です。COBOLとJavaの特徴の違いを考慮したプログラム間で共通の再設計指針を定め、プログラムごとに再設計指針に沿った正しいJava仕様を作成することで、可読性の高い「PureJava」なソースを生成し、生成AIのハルシネーションの問題を検知することができるようになります。

NTT DATAでは、コード生成に限らず、システム開発の上流~下流工程、マネジメント分野の全てのユースケースを対象にした生成AIの技術開発を進めています。生成AI活用の効果を最大化するためには、どこがボトルネックになっているかを分析し、その内容に応じた生成AIの導入計画を策定することが重要です。NTT DATAは、AI技術・自動化技術を熟知したメンバによるコンサルサービスを提供していますので、ご興味があればお問い合わせください。

お問い合わせ