論文「Validated Code Translation for Projects with External Libraries」の技術的サマリー

この論文は、外部ライブラリに依存する Go プロジェクトを、メモリセーフな言語である Rust へ翻訳する際の問題点、特に大規模言語モデル（LLM）の幻覚（ハルシネーション）と、不透明なライブラリ型による意味的同等性の検証の難しさを解決するためのフレームワークを提案しています。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

1. 問題定義 (Problem)

既存のコード翻訳アプローチ（特に LLM を用いたもの）は、ソースコードが外部ライブラリに依存している場合に以下の 2 つの重大な課題に直面します。

1. LLM の幻覚と API 解決の失敗:
   • LLM は、ソースコードの外部ライブラリ呼び出しに対して、存在しないターゲット言語の API やライブラリを生成する（幻覚）傾向があります。
   • 既存の API を誤って使用したり、Rust のような言語特有の「呼び出しを可能にするインポート（import）」を生成し忘れたりします。Rust では、トレイト（trait）のスコープや再エクスポート（re-export）により、正しいインポートパスが非局所的になることが多く、これがコンパイル失敗の原因となります。
2. 不透明なライブラリ型による検証の困難さ:
   • 外部ライブラリで定義された型（例：暗号鍵や内部状態を持つ構造体）は、多くの場合「不透明（opaque）」であり、内部フィールドへの直接アクセスが禁止されています。
   • 従来の差分テストや同等性検証手法は、入力/出力型の構造的同一性を仮定していますが、外部ライブラリ型ではこの仮定が成り立ちません。また、フィールドレベルの変換が不可能なため、Go と Rust の間で値を直接交換してテストすることが困難です。

2. 提案手法 (Methodology)

著者らは、Go から Rust への翻訳と検証を行うための 3 つの主要なステージからなるフレームワークを提案しています。

ステージ 1: クロス言語ライブラリマッピング (RAG による API 解決)

LLM の幻覚を防ぎ、正しい Rust API とインポートを特定するために、**検索拡張生成（RAG）**アーキテクチャを採用しています。

• クレート（Crate）マッピング: Go のパッケージを対応する Rust クレートにマッピングします。
• 知識ベースの構築: 各 Rust クレートについて、公開 API、ドキュメント、および呼び出しを可能にする有効なインポートパスを含む構造化された知識ベース（ApiIndex）を事前に構築します。
• 検索と提示: 翻訳時に、Go の API 呼び出しに基づいてクエリを生成し、関連する Rust API 候補と、それらを使用するための正確な use 文（インポート）を LLM のプロンプトに含めます。これにより、LLM が正しい API とインポートを生成する確率を大幅に向上させます。

ステージ 2: 翻訳生成

LLM を用いて、上記の RAG コンテキストを基に、関数レベルで Go コードを Rust に翻訳します。各関数や型定義は、依存関係の要約と推奨される API 候補を提示された状態で独立して翻訳されます。

ステージ 3: 不透明なライブラリ型を伴うクロス言語検証

翻訳されたコードの機能同等性を検証するために、**プロトコルバッファ（Protobuf）**を中間形式として利用した 2 段階の検証パイプラインを構築します。

1. クロス言語相互運用性の確立（アダプタ合成）:

   • Go 型と Rust 型の間で直接値を交換できないため、言語中立な中間データ形式（IDF）として Protobuf スキーマ（$T_{Proto}$）を生成します。
   • LLM を用いて、元の Go 型から Protobuf 型への変換（アダプタ）と、Protobuf 型から Rust 型への変換（アダプタ）を合成します。
   • 重要点: これらのアダプタは、ライブラリの内部フィールドに直接アクセスするのではなく、公開 API のみを使用して合成されます。これにより、不透明な型（例：暗号鍵）でも安全にシリアライズ/デシリアライズできます。
   • ラウンドトリップ検証: 生成されたアダプタが情報を失わずに値を復元できるか（$f_{Go \to Proto} \to f_{Proto \to Go} = v$）、および Go と Rust の間での相互変換が正しいかを実際のユニットテスト入力を用いて検証します。

2. 差分 I/O 同等性検証:

   • 相互運用性が確立された後、ユニットテストから得られた入力値をアダプタ経由で Rust 側へ渡して実行し、出力を比較します。
   • 出力も同様にアダプタ経由で Go 側に戻し、元の Go 関数の出力と一致するかを確認します（$f(v) = A^{-1}_{Go}(g(A_{Go}(v)))$）。

3. 主要な貢献 (Key Contributions)

1. 外部ライブラリ依存を考慮した最初の検証付き翻訳アプローチ:
   • 構造的に異なり、不透明な入力パラメータ型を持つ関数対の同等性を検証可能にしました。
2. RAG による LLM 幻覚の低減:
   • 外部ライブラリ API のマッピングと、Rust 特有の複雑なインポート解決を自動化し、コンパイル成功率を劇的に向上させました。
3. プロトコルバッファを介したアダプタ合成による検証:
   • 不透明なライブラリ型を扱えるよう、公開 API のみを使用して値の交換アダプタを合成する手法を提案しました。これにより、従来の構造的マッチングに依存しないクロス言語検証を実現しました。
4. 実世界での評価:
   • 6 つの実世界の Go リポジトリ（暗号処理、パスワードハッシュ、時間解析など）で評価し、外部依存が重いケースでも高い成功率を達成しました。

4. 実験結果 (Results)

著者らは、6 つの Go プロジェクト（pbkdf2, easy-scrypt, age など）を対象に実験を行いました。

• 全体成功率: 平均して、コンパイル成功率と同等性検証成功率の両方で 95.83% を達成しました。
• 外部依存への効果: 外部ライブラリを多用するケース（例：age）において、提案手法はコンパイルおよび同等性成功率を 最大 100%、平均で 約 2 倍 向上させました。
• アブレーション研究:
  • RAG（知識ベース検索）とインポート解決を無効にした場合、ライブラリ依存関数のコンパイル成功率は 0% に低下しました。
  • インポート解決のみを無効にした場合も、同様に大幅な性能低下が見られました。
  • これらは、単なる API マッピングだけでなく、Rust 特有のインポート解決が不可欠であることを示しています。
• ベースライン比較: 既存のツール（Oxidizer）と比較して、外部ライブラリを含む関数において著しく優れた結果を示しました。

5. 意義と結論 (Significance)

この研究は、LLM を活用したコード翻訳が、単なる構文変換を超えて、複雑な外部依存を持つ実システムへの適用を可能にする重要なステップです。

• 実用性: メモリセーフな Rust への移行プロジェクトにおいて、外部ライブラリ（特に暗号ライブラリなど）の扱いがボトルネックとなることが多く、これを解決することで実用的な移行ツールとしての価値を高めました。
• 信頼性: 生成されたコードを「検証可能」にすることで、LLM の出力をそのまま信頼せず、自動テストと同等性チェックを通じて安全性を担保するアプローチを確立しました。
• 一般性: 提案手法は Go-Rust に限定されず、不透明な型を持つ他のモダンな言語間の翻訳にも応用可能な汎用的な枠組みを提供しています。

結論として、このフレームワークは、外部ライブラリに依存するプロジェクトの Rust への移行において、コンパイルの壁と検証の壁の両方を突破し、実用的かつ信頼性の高い翻訳を実現する有効な手法であることを示しました。