LegacyTranslate: LLM-based Multi-Agent Method for Legacy Code Translation
本論文は、大規模なレガシーシステム（PL/SQL から Java への移行）の現代化において、LLM を活用した 3 つの専門エージェント（初期翻訳、API 接地、リファインメント）を協調させることで、コンパイル成功率とテスト通過率を向上させる「LegacyTranslate」という多エージェントフレームワークを提案し、金融機関での実証実験を通じてその有効性を示したものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
この論文は、**「古いシステムのコードを新しい言語に翻訳する」**という、企業にとって非常に難しく、かつ重要な課題を解決するための新しい方法（LegacyTranslate）を紹介しています。
まるで、**「古びた城（レガシーシステム）を、最新のスマートマンション（モダンなシステム）に建て替える」ような作業です。しかし、ただ壁を塗り替えるだけではダメで、「その土地の独特なルール（社内 API やアーキテクチャ）」**に厳密に従わなければ、完成した家は住めません。
この論文が提案する「LegacyTranslate」は、その作業を**「3 人の専門家チーム（マルチエージェント）」**で分担して行うことで、失敗なく建て替えを成功させる方法です。
以下に、この仕組みをわかりやすく解説します。
🏗️ 背景：なぜこれが難しいのか？
昔の銀行や大企業には、PL/SQL（古いデータベース言語）で書かれた巨大なシステムが動いています。これをJava（現代の標準言語）に書き換えたいのですが、単純に「PL/SQL を Java に変換してください」と AI に頼むだけでは失敗します。
- AI の失敗例: AI は文法は正しい Java コードを作りますが、**「その会社の決まり（社内ライブラリや API）」**を無視して作ってしまいます。
- 結果: コードは綺麗に見えますが、実際に動かそうとすると**「コンパイルエラー（建築許可が下りない）」**が出たり、テストに落ちたりして、使い物になりません。
🤖 解決策：3 人の専門家チーム「LegacyTranslate」
この問題を解決するために、著者たちは**「1 人の天才 AI」ではなく、「3 人の役割分担した AI エージェント」**でチームを組むことを提案しました。
1. 最初の翻訳者（Initial Translation Agent）
- 役割: 「見本を見て、まず草案を作る」
- 仕組み: このエージェントは、過去の「PL/SQL と Java の対応例（見本）」をデータベースから探して持ってきてきます。「あ、この古いコードは、こういう新しいコードに変換するのが正解だったな」という**「文脈（コンテキスト）」**を AI に教えます。
- 成果: これだけで、約 45% のコードが「コンパイル（建築許可）」に通るようになりました。しかし、まだ完璧ではありません。
2. 社内ルール担当（API Grounding Agent）
- 役割: 「会社のルールブック（API 知識ベース）を確認する」
- 仕組み: 最初の草案は、会社の「社内ルール（特定の API やライブラリ）」を無視していることが多いです。このエージェントは、**「このエラーを直すには、会社のどの機能（API）を使えばいい？」**を、会社の知識ベースから探してリストアップします。
- 重要性: これがなければ、AI は「架空の機能」を使ってしまい、現実に存在しないコードを作ってしまうのです。
3. 修正・仕上げ担当（Refinement Agent）
- 役割: 「エラーを直して、最終チェック」
- 仕組み: 1 番と 2 番の情報を元に、AI はコードを修正します。もしコンパイルエラーが出たら、そのエラーメッセージと「使うべき API」を AI に見せて、「直して！」と指示します。これを**「エラーが出なくなるまで」**繰り返します。
- 成果: このプロセスを経て、最終的に**52.9%**のコードがコンパイルに成功し、**33.8%**がテストもパスするようになりました。
📊 結果：何がわかったのか？
この実験から、いくつかの重要なことがわかりました。
- 「ルール」を教えないとダメ:
単に「変換して」と頼むだけでは、AI は会社のルールを知らないので、**0%**しか成功しません。必ず「社内ルール（API）」を教える必要があります。 - 「見本」の質が重要:
ランダムな見本を渡すだけでは効果薄ですが、**「似たような過去の成功例」**を適切に選んで渡すことで、精度が劇的に上がります。 - 「頭の良い AI」が必要:
小さな AI モデルでは、長い文脈や複雑なルールを理解できず失敗します。**大きなモデル（Qwen2.5-14B など）**を使うことで、初めて高い精度が出せました。
💡 まとめ：この論文のメッセージ
レガシーコードの現代化は、単なる「言語の翻訳」ではなく、**「会社のルールや文化を踏まえた、新しいシステムへの再構築」**です。
この「LegacyTranslate」は、**「1 人で抱え込まず、専門家のチーム（マルチエージェント）に役割を分担させ、エラーを繰り返しながら修正していく」**というアプローチが、現実のビジネス現場では非常に有効であることを証明しました。
まるで、**「建築士（翻訳者）」が設計図を描き、「法規制チェック係（API 担当）」がルールを確認し、「現場監督（修正担当）」**がミスを直していくことで、初めて完成する家のようなものです。
この方法を使えば、銀行や大企業が抱える「古くて危険なシステム」を、安全に、かつ効率的に「最新のシステム」へ移行できる可能性が広がりました。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。