技術要約：LLM開発エージェント間における仕様のポータビリティ（移植性）

1. 問題提起

本論文は、台頭しつつあるマルチエージェント・ソフトウェアエンジニアリング（SDE）のワークフローにおける、重大な相互運用性のギャップに対処している。大規模言語モデル（LLM）が、プロンプトベースのアシスタントから、仕様からコードを生成する自律的なエージェントへと移行するにつれ、新たな問いが生じている。それは、「あるLLMエージェント環境によって作成された仕様は、別のエージェントによって信頼性を持って消費可能か？」という問いである。

現在の研究は、単一エージェントの性能、コンテキストの検索、または要件の明確化に焦点を当てている。しかし、エージェントA（例：Amazon Kiro）によって生成された仕様が、ターゲットとなるコードを生成するためにエージェントB（例：Google Gemini）によって消費された際、その運用の有効性が維持されるかどうかは、経験的に不明なままである。著者らは、仕様は「エージェント中立的」なアーティファクトではないと仮定している。すなわち、仕様の起源（生成元）および実装エージェントが用いる取り込み戦略に応じて、その有効性は著しく低下する可能性がある。

2. メソドロジー

本研究では、OracleからPostgreSQLへのデータベース移行を変換タスクとして用い、制御された2段階の実験デザインを採用している。このドメインが選ばれた理由は、方言特有の構成要素（手続き型ロジック、トリガー、データ型）を翻訳しながら、複雑なアプリケーションのセマンティクスを保持する必要があるためである。

ステージ1：仕様駆動型移行パイプライン

• タスク: 仕様優先のパイプラインを1,006個のPL/SQLソースファイルに対して評価した。
• プロセス: ソースコードをデータベースオブジェクトに分解した。エージェントが中間的なテキスト仕様を生成し、それがPostgreSQLの実装を導出するために使用された。
• 結果: 623個のファイルが正常に再生成され、そのうち380個がPostgreSQL 16で正常に実行された。これにより、このアプローチの実現可能性が確立されたが、クロスエージェント間の転送についてはまだテストされていない。

ステージ2：クロスエージェント互換性実験

• データセット: 1,802個のOracleスクリプトと、対応するPostgreSQL実装。
• 評価対象エージェント: Amazon Kiro、Google Gemini (Antigravity経由)、GitHub Copilot (Spec Kit経由)、Claude Code、およびCursor。
• 実験条件:
  1. ネイティブ・ベースライン: 各エージェントが自身の仕様と実装を生成した。
  2. クロスエージェント転送: あるエージェントによって生成された仕様が、別のエージェントに供給された（例：Kiroの仕様 $\to$ Geminiによる実装）。
  3. 適応戦略: 潜在的な劣化を軽減するため、外部の仕様に対して3つの戦略をテストした：
     • 書き換え (Rewriting): 実装エージェントが、コーディングを行う前に外部の仕様を自身の好みの形式に書き換える。
     • 圧縮 (Compression): 長さを削減するために外部の仕様を要約する。
     • 検索拡張生成 (RAG): エージェントが外部の仕様を全文直接取り込むのではなく、検索ツールを介してアクセスする。

評価指標

本研究では、語彙的、構文的、構造的、および運用の質を区別するために、多次元的な指標セットを利用した：

• Token F1: トークンレベルの類似度。
• Exact Match: 出力がターゲットと完全に一致する割合。
• SQL構文妥当性: 生成されたSQLの妥当性（sqlglotを使用）。
• AST Exact Match & Mean Similarity: 抽象構文木（AST）の構造的類似性。
• 即時実行可能性 (Immediate Runnability): 手動での修正なしにスクリプトが実行できた割合（テスト環境の制約による下限値として記載）。

3. 主要な結果

A. 仕様のサイズは品質の予測因子ではない

詳細な仕様ほど優れたコードが得られるという仮定に反して、本研究では仕様の長さと実装の品質との間に相関関係は見られなかった。

• Kiro は最も長い仕様（約1,597行）を生成した。
• Gemini は大幅に小さい仕様（約193行）を生成した。
• このサイズの違いにもかかわらず、より大きなKiroの仕様が、すべてのエージェントや指標において普遍的に優れたコードを生み出したわけではなかった。

B. 非対称かつエージェント依存の劣化

クロスエージェント転送は非常に変動の大きい結果をもたらし、仕様のポータビリティは方向性に依存すること（$C_{i \to j} \neq C_{j \to i}$）を確認した。

• 致命的な失敗ケース: Gemini が Kiro由来 の仕様を直接消費した場合、性能が崩壊した。
  • Token F1 は 0.035 に低下した（ネイティブの0.73に対し）。
  • SQL構文妥当性は 2.33% に低下した（ネイティブの45.54%に対し）。
  • AST平均類似度は 0.015 に低下した。
  • この失敗パターンは、2つ目の独立した実行においても再現されており、ランダムな非決定論によるものではないことが示された。
• 他のペアにおける安定性: 他の組み合わせ（例：Kiroの仕様を消費するCopilot）は、比較的安定しているか、あるいは混合的な改善を示した。これは、劣化が普遍的な法則ではなく、特定の「エージェントと仕様のペアリング」に固有のものであることを示唆している。

C. 適応戦略の有効性

• 書き換え (Rewriting): Kiroの仕様を消費する際のGeminiの性能を大幅に向上させた。これは、表現形式（内容だけでなく）が不適合の主要な原因であることを示唆している。この戦略はCopilotにはあまり効果的ではなかった。
• 圧縮 (Compression): 普遍的な利益をもたらさなかった。単純な長さの削減は不適合を解決できなかった。
• 検索拡張型取り込み (RAG): RAGはすべての指標で優れていたわけではないが、外部の仕様を扱う際のGeminiとCopilotの両方において、パレート境界（Pareto frontiers）上に現れた唯一の戦略であった。これは、テストされた代替案の中で、RAGが最も堅牢な共通のトレードオフ戦略であることを特定している。

4. 主な貢献

1. 非ポータビリティの経験的証拠: 本論文は、あるLLM環境で生成された仕様が、自動的に別の環境で有効になるわけではないという、制御された経験的証拠を初めて提供しており、「エージェント中立的な中間アーティファクト」という仮定に異を唱えている。
2. 多次元評価フレームワーク: 単純なコード生成ベンチマークを超え、クロスエージェントの仕様転送に特化した包括的な評価スイート（Token F1、AST類似度、実行可能性）を導入した。
3. 適応戦略の分析: 書き換え、圧縮、RAGを体系的に評価し、表現の適応（書き換え）と選択的アクセス（R明示的なRAG）が、単純なコンテンツ削減よりも効果的であることを特定した。
4. 形式モデルの提案: 実装の品質 $Q_{code}$ は、仕様の起源 ($A_g$)、実装エージェント ($A_i$)、取り込み戦略 ($I_s$)、およびコンテキスト ($C$) の関数であるというモデルを提案し、「知識の保持」と「運用の解釈の保持」を区別している。

5. 意義と主張

著者らは、本研究の知見は経験的かつコンテキスト依存的であり、評価されたエージェント、データセット、および指標に限定されるものであると控えめに主張している。外部の仕様が普遍的に劣っていると主張しているのではなく、その有効性がエージェントに依存することを示している。

主な意義:

• ワークフローへの影響: ヘテロジニアス（異種混在型）なマルチエージェントSDDワークフローにおいて、仕様は静的で交換可能なアーティファクトとして扱うべきではない。エージェント間で仕様を転送する際には、実装の劣化を防ぐために、明示的な適応（例：書き換えやRAG）が必要となる可能性がある。
• 設計ガイダンス: 本結果は、構造化された仕様表現（知識、表現、依存関係、および粒度の分離）およびエージェント固有の仕様ビューの開発を促すものである。
• 今後の方向性: 本研究は、未知のエージェント間のペアリングに対しては、仕様への検索ベースのアクセスが堅牢な戦略であることを示唆しているが、依存関係を考慮した検索や、構造化された仕様モデルに関するさらなる研究が必要である。

著者らは、「仕様のポータビリティ」は、異なるLLM開発環境間で情報がどのように構造化され、転送され、解釈されるかを明示的に考慮する必要がある、未解決の問題であると結論付けている。