COBOLアプリケーションの開発を
生成AIで効率化
日立製作所は、新たな取り組みに着手した。それは基幹系システム向けCOBOLアプリケーションの開発に生成AIを適用するというものだ。
「当社では、新しいオープン基幹系システムを構築しました。アプリケーション構造の刷新と最新技術の活用により開発生産性向上などの成果を上げていますが、ここに生成AIを適用することで、生産性と品質・信頼性のさらなる向上を目指すのが今回の取り組みの目的です」と日立製作所の白井 剛氏は説明する。
もっとも、いきなりすべての開発プロセスに生成AIを適用するのは難しい。そこで今回は製造・単体テストのプロセスをターゲットに選定。「従来のやり方と比較して、どれくらい開発効率を上げられるのか」という観点から検証を行ったという。
「生成AI用フォーマット」で
コード生成の精度を向上
実際のPoC(概念実証)は、まず新規コード生成に適用して課題を洗い出した後、コード修正・単体テストケースに適用する流れで進められた。
「新規コード生成への適用においては、既に存在する詳細設計書をそのまま用いて、どの程度のCOBOLコードが生成できるのかを検証しました。ここでは検証対象として、A、B、C、3本のCOBOLプログラムを選定。これらは、ソースコードの量や条件分岐の多さが異なっているほか、プログラムCでは複数の設計書を参照する必要があるなど、コード生成の難易度がそれぞれ異なります」と白井氏は話す。
PoCがスタートした当初は、用意した詳細設計書の情報をあまり加工せず、そのままプロンプトで生成AIに入力することとした。生成されたコードについては、既存のコードと全く同じである必要はなく、経験豊富なCOBOL技術者がチェックした上で、処理内容が同じであれば正解と判定している。
「この技術検証の結果、処理内容が比較的シンプルであったプログラムAについては66%の正解率を上げることができました。ただし、その一方で、難易度が中レベルのプログラムBは41%、高レベルのプログラムCは14%と改善の余地を残す結果となりました」と白井氏は明かす。
この検証結果を通して、「複雑な表を含むなど、読み取りが難しい設計書は生成AIが読み取りやすい形に変換する必要がある」「データ項目の論理名を物理名に変換するなど、プロジェクト固有の情報はプロンプトで適切に指示する」などの点が課題として浮かび上がってきた。
そこで同社では、処理フローの改善を図るべく、生成AIが理解しやすく生成結果の品質向上も期待できる「生成AI用フォーマット」を新たに開発。この生成AI用フォーマットでは、実装させたいCOBOL命令文ごとに設計情報や指示の書き方を標準化しているほか、データ項目については論理名と物理名を記載する、Markdown記法を用いて文章を構造化するなどの工夫が凝らされている(図1)。
図1 新規コード生成の処理フロー
既存の詳細設計書だけでは十分な品質が確保できなかったことから、日立製作所では「生成AI用フォーマット」を開発。AIが読みやすい形で情報を入力することで、コード生成の精度を高めることに成功した
そして、これらの改善の結果、生成されたコードの精度を大幅に高めることに成功。プログラムAが66%→73%、プログラムBが41%→66%、プログラムCが14%→60%と、実用的なレベルにまで正解率を引き上げることができた。
「もっとも、単にこれだけでは、開発業務をどれくらい効率化できたのか分かりません。そこで、一般的なコーディング作業時間と、前処理/後処理も含めた生成AIによる開発時間を比較することにしました」と白井氏。その結果、作業時間も約23~44%削減できており、開発生産性向上にも十分寄与できることが確認できたという。
コード修正・単体テストケース生成でも
効果を実証
続いての検証は、コード修正・単体テストケース生成である。ここではコード行数が約6500行のプログラムDと約2000行のプログラムEを対象として選定。前者では50行程度、後者では100行程度の修正が必要となっており、難易度としては中レベルに相当する。
「コード修正の処理フローにおいても、新規コード生成のときと同じように詳細設計書を生成AI用フォーマットに変換。これと併せて、修正前のCOBOLコードとテンプレート化されたプロンプトも入力し、修正対象部分だけを変換するよう生成AIに指示しています。また、単体テストケース生成では、出来上がったCOBOLコードをベースに、変更対象部分のテストケースを生成させました」と白井氏は話す(図2)。
図2 コード修正・単体テストケースの処理フロー
コード修正の検証では、生成AI用フォーマットに変換した修正後詳細設計書と修正前COBOLコードを用いて修正対象部分のコードを修正。これに対しテストケース生成は非常にシンプルなフローとなっている
その結果、まずコード修正については、プログラムDは76%、プログラムDは94%と、かなり高い精度で既存コードを修正できることが確認できた。
また、単体テストケース生成では、プログラムD用に12ケース、プログラムE用に22ケースのテストケースが生成された。これを正解と突き合わせたところ、前者では11、後者では15のテストケースが正解判定を獲得。適合率はそれぞれ85%、92%となる。なお、本来生成されるべきテストケースはプログラムDが13、プログラムEが21であったため、再現率としては85%、68%という結果となった。
「不要なテストケースが一定数生成されてしまうものの、今回の検証では生成すべきテストケースの8割程度を生成できました。まだまだ課題はあるものの、より網羅性の高いテストを自動で行えるよう、さらなる検証に努めていきたい」と白井氏は話す。
こうした成果を上げられたことは、開発生産性向上の観点でも非常に大きい。先ほどと同じように一般的なコーディング作業時間と比較したところ、プログラムDでは110分→約90分、プログラムEでは156分→約110分と、それぞれ約19%、約30%の作業時間短縮が図れた。「この結果から、コード修正における開発生産性を、約2~3割程度向上できると推察しています」と白井氏は話す。
このように、今回の取り組みを通して、新規コード生成、修正・単体テストケースのいずれにおいても一定の生産性向上効果が期待できることが確認できた。さらに日立製作所では、コード品質を改善するための検証も進めていく考えだ。その1つが、RAG(検索拡張生成)を用いた知識DBの活用である。
「例えば、コーディング基準書のコーディング規約を知識DBに登録し、生成されたCOBOLコードと比較すれば、規約のチェックや差分の修正をより効率的に行える可能性があります。もっとも生成AIは日進月歩であり、RAGだけでなくAIエージェントのような新しい技術も登場しています。今後もいろいろな検証を行うことで、生成AIの活用を進めていきたい」と白井氏は話す。
なお、今回はCOBOLに関しての取り組みだが、日立製作所ではCOBOL→ピュアJava変換の分野でも生成AIの適用を進めている。レガシーマイグレーションを検討している企業にとっては、こちらも要注目といえそうだ。
お問い合わせ
株式会社日立製作所
金融システム営業統括本部
〒100-8220 東京都千代田区丸の内一丁目6番1号
お問い合わせフォーム:https://www.hitachi.co.jp/finance-inq/



