株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
レガシーコード変換AIとは、COBOL・Fortran・古いC言語などで書かれたコードを、現代的な言語(Java/Rust/Python/C++等)に自動変換するAIシステムである。米国のInstitute for Progressが2025年8月に公表した「Great Refactor」は、重要なオープンソースのC/C++コードをAIでRustへ移行するため、米国政府の資金支援を求める提言である。日本でも、NTTデータが生成AIによるCOBOLからJavaへの再設計手法を公開している。本記事では、レガシー言語からモダン言語への変換をAIで行う際の設計パターンを、手続き型言語のレガシーコード変換に関する一般的な実装知見をもとに解説する。
レガシーコード変換AIの難しさ
「LLMにコードを投げれば変換できるのでは?」と思われがちだが、本番品質の変換には以下の課題がある。
| 課題 | 内容 |
|---|---|
| 1. データ形式の曖昧さ | レガシー言語の書式付き入出力は、ソースの定義と実際のデータを突き合わせて形式を確認する |
| 2. 入出力の検証 | 変換後のコードが元と同じ出力を返すか確認が必要 |
| 3. 依存ライブラリ | 古いコードは当時の環境専用のライブラリに依存することが多い |
| 4. コンパイラ互換性 | コンパイラの世代交代で旧方式のサポートが打ち切られる |
| 5. 隠れた仕様 | コードには書かれていない、実行時の暗黙の動作 |
これらを解決するため、単純な「LLMに翻訳させる」だけでなく、本記事では「I/O観察」を事前工程とし、「仕様化→生成→コンパイル→実行→検証」の**5段階パイプライン**を設計例として提案する。
5段階変換パイプラインの全体像
Stage 0.5: レガシーコードの実行とI/O観察 — 最重要フェーズ
本番品質を確認するには、仕様とテストによる検証に加え、可能な環境で**実際にコードを動かして観察する**ことが有用である。本記事ではこのStageを「Stage 0.5」として独立させて扱う。
なぜI/O観察が重要か
レガシーコードの以下の特徴は、ソースの定義だけでは運用時の値や環境差まで確認できない場合がある。
- 入力ファイルの区切り文字(カンマ/タブ/空白)
- 数値の精度(整数/単精度/倍精度)
- 改行コード(LF/CRLF)
- エンディアン(リトル/ビッグ)
- 固定長レコードのバイト数
これらは仕様書・ソース・処理系の設定を確認し、実際のサンプルデータで動かした結果とも照合する。実行と観察は専用の実行監視処理で自動化する設計が望ましい。
コンパイラ実行環境の整備
変換元のコードを実行するには、当時のコンパイラを含む実行環境を再現する必要がある。
実行結果のデータ構造
このデータを次のStageに渡すことで、AIは「実際のデータ形式」を踏まえた変換を行える。
Stage 1: 仕様書生成
I/O観察結果とソースコードをLLMに渡し、詳細な仕様書を日本語で生成する。
仕様書に含める要素
- 処理概要: コードの目的、入出力の役割
- 入力仕様: ファイル名、形式、区切り文字、列定義、データ型
- 処理ロジック: 各ステップで何をしているか
- 出力仕様: ファイル名、形式、カラム構成
- エッジケース: エラーハンドリング、空ファイル対応
- 外部依存: 呼び出している関数、サブルーチン
日本語仕様書にする理由
LLMは英語と日本語の両方で生成できるが、**保守性**の観点で日本語が推奨される。変換後のコードをレビューする人間が日本の開発者である場合、日本語仕様書があればレビューが容易になる。また、将来別の言語に再変換する際も、日本語仕様書が中間表現として機能する。
Stage 2: モダン言語のコード生成
Stage 1で生成した仕様書を入力として変換先言語のコードを生成する。仕様書を中間表現として使い、必要に応じて元のソースも併せて参照するのがポイントである（元コードとJava仕様を併用する公開手法）。
仕様書ベース生成のメリット
- 曖昧な仕様が既に仕様書で言語化されているため、LLMが推測する余地が少ない
- 書式付き入力の読み取り処理を、仕様書に明記した情報に沿って生成し、テストで確認できる
- レビューワが「仕様書通りか」を確認しやすくなる。ただし、仕様の妥当性や変換前後の意味の一致には両言語の知識が必要になる場合がある
書式付き入力処理の生成
レガシー言語の自由書式入力は、言語や処理系の仕様に基づき、カンマ・空白・タブ等の扱いを確認する。実際の入力形式を仕様書に記載し、それを元に変換先言語の読み取り処理を生成して、区切り文字や異常値の扱いをテストする。
Stage 3-5: コンパイル・実行・検証ループ
変換後のコードを実際にコンパイル・実行し、元のコードと同じ出力を返すか検証する。
検証の流れ
- 変換元コードのコンパイル
- 変換後コードのコンパイル
- 同じ入力ファイルで両方を実行
- 出力ファイルをバイト単位で比較
- 不一致なら差分をLLMに渡して再生成
- 上限回数を決めてリトライ
検証の実装ポイント
- 浮動小数点誤差: 変換前後の処理系で微小な差が出る。許容誤差(epsilon)を設定
- 数値フォーマット: "1.0000" vs "1.0" のような表記揺れを吸収
- エンディアン: バイナリ出力の場合は特に注意
- 改行コード: LF vs CRLF の統一
Dockerランタイムチェックの重要性
事前チェック処理でコンテナ環境の問題を先に検知する設計にする。
よくあるDocker関連エラー
- コンテナが起動していない
- 変換元言語のコンパイラがインストールされていない
- ワークスペースディレクトリがマウントされていない
- ネットワーク設定で外部APIにアクセスできない
これらを事前検知することで、ユーザーに分かりやすいエラーメッセージを返せる。
旧環境専用ライブラリ問題（レガシー環境で一般に指摘される論点）
古いコードは**当時の環境専用のライブラリ**（例: 32ビット専用）に依存していることが多い。これは現代の実行環境では大きな問題となる。
問題の構造
- 古い環境では、ビルド設定が当時のコンパイラ前提のまま残っていることが一般に課題となります。
- コンパイラの新しい世代では旧方式（旧コンパイラや32ビット）のサポートが打ち切られ、旧世代は入手しにくくなる。
解決アプローチ
- 旧世代のコンパイラ環境を保持: 動作する世代のコンテナイメージをビルドして保存
- 旧環境専用ライブラリの再ビルド: ソースが残っていれば現行環境向けに作成
- ライブラリごと置き換え: ソースのない関数は変換先言語で再実装
- 段階的移行: まずライブラリ依存のない部分だけを変換
対話型UIの実装
UIは対話型で構築し、以下の機能を備えると使いやすい。
- コーディングタスクのストリーミング実行
- ワークスペース(セッション)ごとのGitリポジトリ管理
- コマンド実行やリポジトリ取得、ファイル編集といった基本的な操作をエージェントのツールとして備える。
- ユーザー認証
- 実行履歴・設定のデータ永続化
- 利用する LLM プロバイダの切替に対応
実装の発展形 — Stage 4-5の「実行履歴分析」
変換パイプラインの実行履歴を分析して改善提案を生成する「実行履歴分析」機能も発展形として考えられる。
これにより、同じ種類のエラーが繰り返される場合、プロンプトや処理ロジックの改善を自動的に提案できる。
業界別の適用パターン
| 業界 | 主なレガシー言語 | 変換先候補 |
|---|---|---|
| 金融・保険 | COBOL | Java / Kotlin |
| 製造業(科学計算) | Fortran | C / C++ / Python |
| 公共インフラ | C / C++ | Rust |
| 行政システム | COBOL | Java / Python |
| ゲーム業界 | C / C++ | Rust |
世界的な動向
米国の「Great Refactor」は、重要なオープンソースのC/C++コードをAIでRustへ移行する研究開発を支援するよう、米国政府に求めた2025年8月の提言である。メモリ安全性に関わる脆弱性の削減を目指し、変換結果の検証や専門家のレビューも提案している。COBOLからJavaへの移行や、実施済みの事業を報告したものではない（Institute for Progressの原文）。
日本では、NTTデータが2024年12月、COBOLからJavaへの変換で、プログラムごとにJava仕様を作成し、元コードと共に生成AIに渡して検証する再設計手法を公開している（NTTデータの解説）。移行期間はコード量に加え、依存関係や試験範囲によっても変わる。
導入時のよくある失敗パターン
- I/O観察をスキップする: データ形式が曖昧なまま生成され、動作しないコードが出来上がる
- 検証ループを省略する: 変換後のコードが本当に同じ結果を返すか確認しない
- 仕様書生成を飛ばす: LLMが推測でコード生成するため品質が不安定
- 旧環境専用ライブラリ問題を軽視する: 古いコードで後から詰まる
- Dockerランタイムチェックを実装しない: ユーザーがエラー原因を特定できない
- リトライ回数を無制限にする: 永久ループでコストが爆発する
renueのアプローチ — Self-DX First
renueは「Self-DX First」の方針のもと、社内の主要業務を自社開発のAIツールで自動化しており、レガシーコード変換のようなAIエージェント設計にも同じ考え方を適用している。
構成例の技術スタック
- バックエンド: Python 系 Web フレームワーク
- フロントエンド: React 系フレームワーク＋エージェント SDK
- LLM: 複数プロバイダを切替可能な構成
- 実行環境: 変換対象言語のコンパイラを含む隔離実行環境
- データ永続化: RDB＋ORM
- 認証: 標準的な認証ライブラリ
