技術概要：LLM 支援によるソフトウェア進化のための仕様ベースのコード–テキスト–コード再構築

1. 問題定義

大規模言語モデル（LLM）は、ソフトウェアの移行、リファクタリング、コード再生成にますます活用されるようになっている。しかし、直接的なコードからコードへの変換アプローチは、重大な限界に直面している。これらには以下が含まれる：

• 意味の漂移（シフト）： モデルは表面的な構文を維持しつつも、背後にあるビジネスロジックを変更したり、隠れた振る舞いの変化を導入したりする可能性がある。
• 非慣習的な出力： 生成されたコードは、ターゲット環境には不適切なソース言語の構文を保持している可能性がある。
• 追跡可能性の喪失： ソースコード、モデルの解釈、再生成された成果物の間には、明確なリンクが存在しないことが多い。
• 文脈の欠落： 直接変換は、データ依存関係、例外処理、非機能的な仮定を考慮できないことが多い。

本論文は、LLM 支援によるソフトウェア進化は、単なるコード生成としてではなく、意味の一貫性と構造の維持を確保するための中間表現層を必要とする制御された再構築プロセスとして捉えるべきであると主張している。

2. 手法：コード–テキスト–コードフレームワーク

提案されるフレームワークは、仕様ベースのコード–テキスト–コード再構築モデルを導入する。中核となる変換フローは以下のように定義される：
$$C_0 \rightarrow S_n \rightarrow C_1$$
ここで、$C_0$ はソースコード、$S_n$ は中立なテキスト仕様、$C_1$ は再生成されたターゲットコードである。

A. 中立なテキスト仕様（$S_n$）

単純なコード要約とは異なり、$S_n$ は以下の要素を捉えるように設計された構造化された検証可能な成果物である：

• プログラムの振る舞い、識別子、計算フロー。
• 条件、副作用、データ依存関係。
• ソース言語の構文バイアスなしのドメイン固有の意図。
• ソフトウェアが「何を行うか」と「どのように実装されるか」を分離する「意味の仲介者」として機能する。

B. 知識表現層

フレームワークは、追跡可能性と検証を支援するために、複数の表現層を統合する：

• AST およびメタデータ抽出： 生成プロセスを制約し、幻覚を減らすために、事実（関数名、シグネチャ、依存関係）を構造化して抽出する。
• オントロジーと意味注釈： 中間表現を構造化された知識（OWL/SKOS）にマッピングし、推論と再利用を支援する。
• グラフ表現： コードプロパティグラフ（CPG）を活用して依存関係（呼び出し、読み取り、書き込み）を追跡し、変換損失を推定する。
• ハイブリッド検索： 意味的類似性のためのベクトル検索、構造的依存関係のためのグラフ探索、メタデータフィルタリングを組み合わせ、Code2Text および Text2Code の両段階を根拠付ける。

C. パイプラインアーキテクチャ

エンドツーエンドのパイプラインには以下が含まれる：

1. 事実的コンテキストの抽出： 仕様生成前に識別子と依存関係を収集する。
2. Code2Text 生成： RAG と事実的コンテキストを用いて、初期の中立仕様を作成する。
3. 反復的検証と洗練： 仕様をソースコードと比較し、欠落した振る舞いや過度な仮定を検出する。
4. ヒューマン・イン・ザ・ループ： 曖昧なビジネスロジックや隠れた仮定に対する、専門家の修正をオプションとして行う。
5. Text2Code 生成： 検証済みの仕様に基づいてターゲットコードを生成し、慣習的なターゲット言語の実装を確保する。
6. ターゲット検証： 構文、機能的同等性、インターフェースの安定性を検証する。
7. DBMS フィードバック（SQL の場合）： 実行ベースの検証を用いて、方言固有の正確性を確保する。

D. 意味を考慮したチャンキング

本論文は、単純なチャンキングが意味単位を破壊することを強調している。原子性、自己解析可能性、意味的意識によって定義され、Boundary F1 や Chunk Certainty などの指標で評価される「理想的なコードチャンク」を提案している。

3. 主要な貢献

本論文は、5 つの主要な貢献を提示する：

1. 概念的解釈： コード–テキスト–コードを単なる変換パイプラインではなく、中立テキストが制御された知識成果物である仕様ベースの再構築プロセスとして再定義する。
2. パイプラインアーキテクチャ： 事実抽出、反復的検証、人間の修正、DBMS 支援フィードバックを統合する包括的なシステム。
3. 知識表現モデル： ソースコード、ドキュメント、再生成された成果物をリンクするための、AST メタデータ、オントロジー、グラフ依存関係、中立テキストを統合した統一モデル。
4. 実験的評価： 複数の言語（Java、Python、C++、SQL 方言）を網羅するデータセットと、中間表現（疑似コード、グラフ IR、コンパイラ IR、自然言語 IR）を比較する評価プロトコル。
5. 形式的損失推定： 変換損失を定量化するためのグラフベースの形式化：
   • 方向性構造保持（$\alpha$）： ソース依存関係の保持を測定する。
   • 逆互換性（$\beta$）： 不要なターゲット依存関係の導入を測定する。
   • インターフェース保持（$\delta_{IO}$）： 入出力の安定性を確保する。
   • 総グラフ類似度（$S$）： 上記の加重調和平均。

4. 実験結果

著者は、9 つのプログラミング言語と 5 つの SQL 方言にわたる、言語あたり 1,000 スクリプトのデータセットを用いて実験を行った。

• 中間表現の比較： 自然言語 IR（中立仕様）は、疑似コード、グラフベースの IR、コンパイラスタイルの IR と比較して、LLM 支援による変換に対して最も実用的な適合性を示した。
• 検索評価： ベクトル検索は意味的関連性においてより正確であることが証明されたが、グラフ検索は依存関係のナビゲーションにおいてより低い遅延を提供した。ハイブリッドアプローチが推奨された。
• ドキュメント変換： TechDoc から BusinessDoc への変換実験において、24 チャンク中 22 チャンクが検証を通過した。失敗は論理の歪曲またはスコープの省略に関与しており、検証ループの必要性を浮き彫りにした。
• プロンプト調整： DSPy/MIPROv2 を使用して、著者は慎重に制約された元のベースラインプロンプトが、自動生成された変種よりも優れていることを発見した。これは、制約された再構築タスクにおいては、プロンプトの複雑さよりも、中立性や構造などの明示的な制約がより重要であることを示唆している。
• グラフ指標： 形式的指標は、構造保持とインターフェースの安定性を成功裏に定量化し、「もっともらしいが誤った」変換を検出する方法を提供した。

5. 意義と主張

本論文は、仕様ベースのコード–テキスト–コード再構築が、不透明な直接コード生成に対する制御可能で、追跡可能で、監視可能な代替手段を提供すると主張している。

• 透明性： 中間仕様を明示的にすることで、モデルの解釈が可視化され、レビュー可能かつ修正可能になる。
• 品質管理： フレームワークは、局所的な構文の正しさを越えて、意味的カバレッジ、検索の根拠、構造保持を評価する。
• インテリジェントな監視： 著者は、このフレームワークを変換ツールとしてだけでなく、意味的一貫性と変換損失が継続的に評価される「インテリジェントな監視」の対象として位置づけている。
• 再構築対翻訳： この研究は、LLM によって仲介されるソフトウェア進化には、単純な翻訳から、コード、技術ドキュメント、ビジネス要件、グラフ構造を含む多レベル表現プロセスへの移行が必要であると主張している。

本論文は、このアプローチが有望であることを示している一方で、意味の漂移や幻覚のリスク、特に金融や医療システムなどの高リスク領域におけるリスクを軽減するために、チャンキング、検索の根拠付け、ヒューマン・イン・ザ・ループによる検証の慎重な処理が必要であると結論付けている。