技術概要：大規模言語モデルによる仕様駆動型コード翻訳

1. 問題定義

レガシーコードベースを現代的なプログラミング言語へ移行させることは、ソフトウェア工学において重要かつ困難な課題である。大規模言語モデル（LLM）はコード生成や翻訳において優れた能力を示しているが、既存のアプローチは主にソースコードに依存し、構文を保持する変換として翻訳を扱っている。これは、特に意味的に複雑なコードにおいて、モデルが高レベルのプログラム意図を捉える能力を制限しがちである。

本論文は、自然言語（NL）仕様を中間表現として用いることがコード翻訳を改善するかどうかを検証する。NL は LLM のトレーニングにおける主要なモダリティであり、プログラム意図を表現する自然な方法であるが、コードを NL に変換し、その後ターゲット言語へ変換する（あるいはソースコード alongside NL を用いる）ことが、直接のソースからターゲットへの翻訳に対して一般的な性能向上をもたらすのか、それとも恩恵は文脈に強く依存するのかは依然として不明である。

2. 手法

実験設計

本研究は、C、C++、Go、Java、Python の 5 つのプログラミング言語と 29 の言語ペアの順列を網羅する 3 つのデータセット（Avatar-Verified、CodeNet、EvalPlus）を評価対象とした。実験には、GPT-4（クローズドソース）、DeepSeek-Coder、Magicoder-S-DS-6.7B（オープンソース）の 3 つの異なる LLM を使用した。

ワークフロー

提案されたワークフローは、以下の 3 つの主要な段階から構成される：

1. NL 仕様生成：LLM がソースコードから疑似コード風の NL 仕様を生成する。プロンプト感度調査により、疑似コードベースのプロンプト（制御フローや変数の更新を保持する構造化された行単位の記述）が、抽象的な自然言語記述よりも優れていることが判明した。
2. 翻訳戦略：本研究は 3 つのプロンプト戦略を比較する：
   • ソースのみ：ソースコードから直接ターゲット言語へ翻訳する。
   • NL 仕様のみ：生成された NL 仕様からターゲット言語へ翻訳する（ソースコードは使用しない）。
   • ハイブリッド：ソースコードと生成された NL 仕様の両方を用いて翻訳する。
3. 反復修復：入力表現の効果を分離するため、本研究はコンパイルエラー、テスト不一致、ランタイムエラー、無限ループの修正に限定された自動修復パイプラインを採用した。LLM はエラータイプごとに最大 3 回の修復反復を許可された。

評価指標

• 計算精度（CA）：すべての対応するテストケースを合格した翻訳コードの割合。
• コード品質：SonarQubeを用いて分析し、「Blocker」と「Critical」の重大度を持つ問題の数をカウント（1,000 行のコメントなしコードあたり正規化）し、意味的およびセキュリティ上の欠陥を評価する。
• 統計分析：戦略の相補性を決定するために、ペアワイズ有意性検定（Holm-Bonferroni 補正を伴う McNemar の正確検定）および効果量分析（Cliff's delta）が用いられた。

3. 主な貢献

1. NL 仕様の実証的特徴付け：本研究は、NL 仕様を中間表現として体系的に評価し、それらが翻訳精度を普遍的に向上させるわけではないことを発見した。
2. 条件付きの有効性：本研究は、NL 仕様は特定のソース言語（特にPythonとC++）および特定の言語ペアに対してのみ有益であることを特定した。他の言語（C、Go など）では、抽象化はしばしば情報損失をもたらし、性能を低下させる。
3. 品質とエラー分析：本論文は失敗モードの詳細な分析を提供し、生成された NL 仕様におけるエラーが最終的な翻訳に決定的に伝播することを示した。また、C 言語の翻訳は、他の言語と比較して、はるかに高い欠陥密度（セキュリティおよびメモリ問題）を示すことを強調している。
4. 修復の影響：本研究は、翻訳後の修復の影響を定量化し、コンパイルエラーの修正のみでも、NL 仕様のみアプローチでは平均8.5%、ハイブリッドアプローチでは**6.1%**の精度向上をもたらすことを示した。

4. 主要な結果

翻訳精度（RQ1 & RQ2）

• ソースのみベースライン：すべてのデータセットおよびモデルにおいて、ソースのみのアプローチが最も高い平均翻訳精度を達成した。
• ハイブリッドアプローチ：NL 仕様とソースコードを組み合わせることは、特定のペア（例：Python から他の言語へ、C++ から他の言語へ）で改善をもたらしたが、すべての順列においてソースのみベースラインを一貫して上回ることはなかった。
• NL のみアプローチ：NL 仕様のみを使用することは、ソースのみ翻訳と比較して一貫して性能を低下させ、コードから NL への翻訳が、特に低レベル操作や言語固有の構文において情報損失をもたらすことを示している。
• 成功対失敗：NL 仕様は、複雑なロジックを正しく簡略化した場合（例：Python における同時タプル代入など）に役立った。しかし、生成された仕様が誤っていた場合（LLM の推論制限による）、そのエラーはターゲットコードに伝播し、翻訳をソースのみよりも悪化させた。

コード品質（RQ3）

• 問題密度：深刻な（Blocker/Critical）問題の数は、異なる戦略（ソースのみ対ハイブリッド）および修復前後において、ほとんど変化しなかった。
• 言語固有の欠陥：
  • C/C++：C を含む翻訳は、安全でないメモリアクセス、汚染された値、再入不可能な関数の使用（例：strtok）などに関連して、欠陥が大幅に増加した（しばしば 1,000 NCLOC あたり 30 超）。
  • Go：無効な変数名と高い認知的複雑さが支配的であった。
  • Java：問題はロギング慣行と命名規則に集中していた。
  • Python：頻繁に潜在的なインデックスエラーが発生した。
• ソース言語の影響：ソース言語は、ターゲット言語における問題の種類にほとんど影響を与えなかった。欠陥の分布は、ターゲット言語固有のパラダイムと標準によって決定された。

5. 意義と主張

本論文は、コード翻訳タスクにおいてNL 仕様はソースコードの普遍的な代替物として見なすべきではないと控えめに主張する。むしろ、それは特定の、ロジックが複雑なシナリオ（特に Python と C++ のソースにおいて）の網羅性を拡張できる補完的なシグナルとして機能するが、仕様生成が不正確な場合、性能を低下させるリスクがある。

実務家への主要な教訓：

• 「ソースファースト」ワークフローの採用：主要なパスとしてソースのみ翻訳を使用する。
• ターゲットされたフォールバック：NL 仕様アプローチは、複雑なロジックや恩恵が確認された特定の言語ペアに対してのみ、フォールバックとして使用する。
• 文脈が重要：NL 仕様の恩恵は、生成された仕様の正確性とソース言語の性質に条件付きである。
• 修復は不可欠：コンパイルエラーおよびランタイムエラーの自動修復は、特に中間表現を使用する場合、正しさを回復するための重要なステップである。

本研究は、多段または中間表現戦略（InterTrans のようなもの）が広範なモデル呼び出しを通じて高い精度を達成する可能性があるものの、直接のソースからターゲットへのアプローチが全体として最も堅牢であると結論付けている。今後の研究は、仕様の忠実度を向上させ、これらの知見をレポジトリレベルの翻訳システムに統合することに焦点を当てるべきである。