https://xtech.nikkei.com/atcl/nxt/column/18/02613/101300003/?n_cid=nbpnxt_mled_itmh
生成AI（人工知能）をシステム構築に活用する取り組みが進んできた。ソースコードの自動生成やテストの効率化、運用自動化などカバー範囲は広く、省力化や品質向上といった成果を上げている。今回はNTTデータの取り組みを見よう。
前回の記事AWS・MS・Googleが生成AIでシステム構築支援、ソフト開発全般で効率化競う「長年にわたって生成AIを研究しており、AIガバナンスを徹底しながら、積極的に活用を推進していく」。NTTデータグループ 技術革新統括本部システム技術本部ADM技術部ADM担当EGMグループの村上功修部長は、NTTデータの生成AIへの取り組み姿勢をこう述べる。
同社が生成AIをシステム構築へ適用するに当たって指針は大きく2つある。1つは開発者が不足している領域への適用、もう1つはソフトウエア開発領域全般への拡大である。要求定義から設計、開発、テストなどの工程について、「Azure OpenAI Service」「GitHub Copilot」、独自の生成AIなどを活用し、作業の効率化を推し進める考えだ。
想定される活用例としては、「既存ソースコードから設計情報を復元」「要件をユースケース図に変換」などが挙げられる。村上部長が「これまでの案件の中でもシステムマイグレーションは多い」と話すように、システムのモダナイズ作業で生成AIを使うケースは増えそうだ。同社は米OpenAI（オープンAI）の生成AIを活用した既存資産のマイグレーションを行う技術やアセットを「Coding by NTT DATA」として展開。既にユーザー事例もある。
人手に比べて工数は7割減
コード変換の事例の1つが「画面UIの変換」である。ある顧客は、Webブラウザーのサポート切れに伴い、約1万4000に及ぶ画面コードを別の開発言語に書き換える必要に迫られた。その作業支援にAzure OpenAI Serviceを使った。
最終的に作業工数は人手に比べて7割削減できたが、その秘訣はプロンプト（指示文）をうまく使うことにあった。変換前のソースコードに基づいて、生成AIは新たな開発言語によるソースコードを提案する。担当者は変換後にテストを行い、思い通りに変換されていないものについては人手で修正していった。同時に、修正に基づいた「良い変換例」をプロンプトとして生成AIに還元した。こうした変換作業のスプリントを複数回繰り返すことで有用なプロンプトが蓄積され、変換の精度が向上。最終スプリントで7割の工数削減につながった。
データベースの移行作業に生成AIを活用した事例もある。Oracle DBからPostgreSQLへの移行に伴い、両DB間で非互換があるSQLについて生成AIを用いて変換。現新一致テストを実施し、結果が合致しないSQLについては人手で修正を加えた。すべて人手で変換する場合に比べて、工数を5割削減できたという。
生成AIの回答をユーザーの意図に近づける手法には、プロンプトのほかファインチューニング（追加学習）がある。村上部長は「ファインチューニングをやろうとするとデータ量が必要になるし、マシンリソースの利用料金もかかる。たとえファインチューニングを行ったとしても顧客やプロジェクト固有の要素はあるので、プロンプトとの組み合わせは必ず発生する」と話す。
次ページ 生成AIでCOBOLのソースコードから設計書の作成も可能に！
生成AIありきのSI探る
生成AIの活用を深める中で課題も見えてきた。その1つがどうやって品質を高めるかだ。「例えば、設計書から生成AIが自動生成したコードに対して生成AIによるテストを実施した際、最終的にどうやって品質を高めればよいのか」（村上部長）。現在、同社では生成AIを使った際の品質向上のためのガイドラインや考え方、様式をまとめている。製造・テストについては今年度ベータ版をつくって、幾つかの案件でトライアルを行い効果測定や修正などを実施。次年度にはより上流の要件定義や設計工程などにおけるベータ版を作成し、製造・テストと統合した1.0版を出す予定だ。
品質を高める上では、テストの自動化も欠かせない。同社では今後、テストの自動化ツールに生成AIを組み合わせて効率化や精度向上を図っていく。まずは、バグの原因分析でPDCAサイクルを回す「欠陥分析」や、ソースコード及びコメントからの「テストスクリプト作成」などに生成AIを活用する。
生成AIありきで進めるSIでは、発想の転換も必要になりそうだ。村上部長は設計書を例に挙げ、「設計書は今は人の可読性が重視されるが、生成AIネーティブになると、AIが分かりやすいように書く必要があるかもしれない」と話す。自動生成の精度を高めるために人の可読性を犠牲にするわけだが、「ソースコードがそろったら生成AIでリバースエンジニアリングして、人が読めるドキュメントをつくるようなことも考えられる」（村上部長）。
システムマイグレーションに強みを持つ同社でも、メインフレームで動いているCOBOLやPL／Iのマイグレーションへの生成AI適用は一筋縄ではいかないという。村上部長は「COBOLからJavaへのマイグレーションは現状の生成AIエンジンでは学習量の問題から汎用的に利用することは難しい。生成AIの学習元はモダンなアプリが多く、学習元となるCOBOLの量が学習データとして少ないためだ。プロンプトエンジニアリングだけで対応するにはプロンプトに相当なつくり込みが必要になる」と説明する。
この課題の解決に向けて、NTT研究所が整備を進めている独自の生成AIを使う。この生成AIに対して、NTTデータが持つ大量のCOBOL資産などを活用してファインチューニングを行い、COBOLに特化した生成AIをつくる計画だ。「COBOLのソースコードからリバースして設計書をつくったり、COBOLからモダンなプログラム言語へ変換したりするべく検証を進めている」（村上部長）。
COBOLのソースコードから設計書をつくる理由を村上部長は「移行先はJavaばかりではないので設計書を起こす。それに基づいてフロントはローコードでつくり、バックエンドは特定の開発言語で実装するようなことが可能になり、マイクロサービスの適用にもつながっていく」と話す。生成AIは同社のシステムマイグレーションを効率化するだけでなく、高度化するポテンシャルも秘めている。
0 コメント:
コメントを投稿