LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering

本論文は、自然言語プロンプトの曖昧性と品質の限界を克服するために構造化された仕様を活用し、リポジトリレベルでの高品質かつ検証可能なコード生成を可能にするパラダイムである構造化仕様駆動工学（SSDE）を提案する。

要約

非常に才能に恵まれているが、少し散漫な見習いシェフに、街全体のための巨大で複雑な宴会の調理を教える場面を想像してください。

問題：「曖昧な注文」
現在、トップクラスの AI（見習い）にソフトウェアシステム全体のコード作成を依頼する場合、通常は「会議を予約できるウェブサイトを作ってください」といった、長く自然な言語による記述を与えるだけです。これはシェフに「美味しい料理を作ってください」と伝えるのと同じです。

この論文は、AI は単一の玉ねぎを切る（小さな関数を書く）ことには長けているものの、宴会全体（完全なソフトウェアリポジトリ）の調理を任されると見失ってしまうと主張しています。自然言語は曖昧すぎるのです。AI は誤った推測をしたり、手順を忘れたり、見た目だけは良くても味が合わない料理を作ったりする可能性があります。さらに悪いことに、指示が曖昧だったため、なぜその料理が失敗したのかを証明することが困難です。

解決策：「構造化されたレシピブック」
著者たちは、構造化仕様駆動エンジニアリング（SSDE） と呼ばれる新しい作業方法を提案しています。曖昧な会話の代わりに、厳格で構造化された「レシピブック」を AI に与えることを提案しています。

この論文では、2 種類の構造化されたレシピが使用されています：

1. Gherkin 仕様：これらは「もし〜なら、〜である」というテストケースです。「動作するようにしてください」と言う代わりに、「ユーザーが『予約』をクリックした場合、部屋は『使用中』としてマークされなければならない」と記述します。これは正確な動作のチェックリストです。
2. ドメインモデル：これらは建築の設計図や材料の地図のようなものです。「ユーザー」「部屋」「日付」など、システム内の異なる部分がどのように互いに接続されているかを示します。

実験：味見テスト
研究者たちはパイロット研究を設けました。彼らはヘッドシェフとして振る舞い、5 つの異なる AI モデル（見習い）に、3 つの異なるソフトウェアシステムのための「ビジネスロジック（調理ルール）」を構築するタスクを与えました。

彼らは異なる組み合わせをテストしました：

• 対照群：曖昧な自然言語記述のみ。
• 試験群：曖昧な記述に加え、構造化された「レシピブック」（設計図と「もし〜なら、〜である」というチェックリスト）を含むもの。

結果：構造化が勝利
発見は明確でした：

• 精度の向上：AI が構造化された「レシピブック」（設計図とチェックリスト）を持っていた場合、曖昧な記述のみを持っていた場合よりもはるかに少ない間違いで済みました。
• 「設計図」によるブースト：AI に設計図と共に具体的なコード署名（材料と道具の正確なリスト）を与えたことが、最も効果的でした。これはシェフにレシピだけでなく、使用する小麦粉の正確なブランドや、使用するフライパンの具体的なサイズまで与えるようなものです。
• まだ成長の余地あり：構造化されたアプローチははるかに優れていましたが、AI は依然としていくつかの誤りを犯しました。しかし、研究者たちは、これらの誤りの70% 以上が、存在しない変数を参照したり、Python の構文エラーを起こしたりするといった、単純で検出可能なミスであることを発見しました。これらは、コードを実行して出力が仕様と一致するかを確認する「テストオラクル」さえ不要です。標準的なコンパイラやリンターがあれば、これらを検出できるのです。

将来のロードマップ
この論文は、これを完璧に機能させるためには、以下のことが必要だと示唆しています：

1. フィードバックループの追加：AI に一度だけ依頼するのではなく、コードを書かせ、それを「レシピブック」でチェックさせ、誤りを自動的に修正させるべきです。
2. より良いデータセットの構築：AI をより良く訓練するために、これらの構造化されたレシピブックの例をより多く必要としています。
3. 変化への対応：実際のソフトウェアは常に変化します。AI に、デザートを入れ替えるなど、宴会の一部だけを更新して、料理全体を台無しにすることなく行えるよう教える必要があります。

結論
この論文は、AI を曖昧な願いで機能する魔法の杖として扱うのをやめ、厳格で構造化された設計図に従う熟練労働者として扱うようにすれば、信頼性のあるソフトウェアシステム全体を構築させることができる、と結論付けています。これにより、AI は「創造的な推測者」から「精密な建設者」へと変貌します。

技術概要

技術概要：構造化仕様駆動エンジニアリングによる LLM 支援型リポジトリレベル生成

問題定義

大規模言語モデル（LLM）は関数レベルやファイルレベルでのコード生成において高い能力を示す一方で、リポジトリレベルのシステムにスケールするとその信頼性は著しく低下する。自然言語プロンプトのみに依存する現在のワークフローは本質的な曖昧さに起因し、コミュニケーションを「損失を伴うもの」とし、検証可能な出力（例えばソフトウェアテスト）の生成を阻害する。自然言語指示の冗長性を増すだけでは、信頼性のある大規模なコード生成と検証に必要な根本的な精度の欠如に対処できない。著者らは、信頼性が高く、検証可能で、高品質なリポジトリレベル生成を可能にするためには、非構造化の自然言語から構造化された仕様への転換が必要であると主張する。

手法：構造化仕様駆動エンジニアリング（SSDE）

本論文は、構造化されたアーティファクト（自由形式の自然言語ではなく）を LLM エージェントを導く主要な入力として用いるパラダイムである「構造化仕様駆動エンジニアリング（SSDE）」を提案する。著者らはこのビジョンの実現可能性を調査するためにパイロット研究を実施した。

実験設定

• タスク: 3 つの既存ソフトウェアシステム（Symboleo、CheECSEManager、MeetingGroups）に対するモデル・ビュー・コントローラー（MVC）ビジネスロジック（具体的には Python コントローラー）の生成。
• モデル: 大小さまざまなオープンソースモデル（Qwen 3、Llama 3.2）とクローズドソースモデル（Claude Sonnet 4.5、GPT 5.1、GPT 5 Nano）を含む 5 つの LLM を評価対象とした。
• 入力構成: コントローラーテンプレートに加えて LLM に提供された 4 種類の文脈入力を比較した。
  1. 自然言語仕様: システムの目的と制約に関する自由形式の説明。
  2. Gherkin 仕様: システムの振る舞いを定義する構造化された実行可能なシナリオ。
  3. ドメインモデル: ドメイン概念と関係を捉える抽象的なソフトウェアモデル（Umple または Ecore）。
  4. シグネチャモデル: ドメインモデルから導出された生成されたクラスおよび関数のシグネチャ（API）。
• 評価:
  • 定量的: Gherkin シナリオに対応付けられた人間が検証した Python ユニットテストスイートを、生成されたコントローラーに対して実行した。主要指標は**テストパス率（TPR）**であった。
  • 定性的: 生成されたコードを手動で検査し、反復して発生する失敗パターンとコード品質属性を特定した。
  • 反復: 確率的バイアスを考慮するため、各構成を LLM ごとに 10 回実行した。

主要な結果

パイロット研究により、構造化入力の有効性に関するいくつかの重要な知見が得られた。

1. 構造化入力の優位性: 自然言語仕様のみの使用をベースラインとした場合、構造化仕様（Gherkin、ドメインモデル、またはシグネチャ）のいずれかの形式を追加することで、出力品質が著しく向上した。
2. Gherkin の可能性: 初期段階では、モデルと組み合わせた Gherkin 仕様の平均 TPR は自然言語の組み合わせよりわずかに低く（6.8% 低下）、分散も大きかったが、30 の特定の組み合わせのうち 14 件において自然言語を上回った。著者らは、さらなる洗練によりこのアプローチが自然言語を上回る可能性を指摘している。
3. シグネチャの価値: ドメインモデルから生成されたモデル層のシグネチャ（API）を提供することは非常に効果的であった。この構成は、生粋のドメインモデルを使用した場合と比較して、平均 TPR を +7.82% 向上させ、標準偏差を -2.47% 減少させた。これは、LLM が抽象的なモデル構文よりも明示的な API 定義から恩恵を受けることを示唆している。
4. エラー分析: テスト失敗の70% 以上が、静的コード分析で検出可能なエラー（存在しない API の呼び出し、データ型の不一致、未検証の制約など）によって引き起こされていた。これは、生成失敗の大部分が論理的なものではなく構造的なものであり、自動修正の対象となり得ることを示している。
5. モデルのパフォーマンス: Claude Sonnet 4.5 がトップパフォーマンスを示し、いくつかの構成で 80% 超の TPR を達成した。しかし、実行間での高い標準偏差は LLM の確率的性質を浮き彫りにし、特定の誤りタイプが生成されたコントローラーを通じて一貫して伝播する傾向があることを示した。

主要な貢献

• SSDE の提案: 本論文は、高レベルの要件とリポジトリレベルのコード生成の間のギャップを埋めるための viable なパラダイムとして、構造化されたアーティファクトの検証可能性を活用した「構造化仕様駆動エンジニアリング」を提案する。
• 実証的な実現可能性研究: 著者らは、構造化入力（Gherkin、ドメインモデル、シグネチャ）が自然言語プロンプトと比較して LLM 生成によるリポジトリレベルコードの品質を具体的に向上させることを示す、初のパイロット研究を提供する。
• エラーパターンの特定: 本研究は失敗モードを分類し、エラーの大部分が構造的であり検出可能であることを明らかにした。これは、自動化されたフィードバックループへの明確な道筋を示している。
• 研究ロードマップ: 本論文は、以下の 3 つの柱に焦点を当てた、この分野のための具体的な前進の道筋を概説する。
  1. 出力品質の向上: 静的解析と動的テストを用いたフィードバックループを実装し、LLM が構造的エラーを自己修正できるようにする。
  2. 実世界への影響の評価: シングルショット生成を超えて、エージェントワークフロー、トークンコスト効率、構造化仕様を維持するための労力を考慮した純粋な生産性向上を評価する。
  3. 適用性: 継続的な進化に対応するための部分的なリポジトリ更新の技術を開発し、多様なモデリングツールや物理世界表現との SSDE の統合を図る。

意義と主張

本論文は、SSDE が高品質で検証可能なリポジトリレベルのコード生成への具体的な道筋を提供すると主張する。曖昧な自然言語から構造化された仕様への転換により、このアプローチは数十年にわたるソフトウェアエンジニアリングの知識（例えば、モデル駆動エンジニアリング、Gherkin）を活用して LLM を導く。

著者らは、LLM は現在大規模システムにおいて困難に直面しているが、構造化された仕様の統合により、コード生成を「ブラックボックス」プロセスから検証可能で保守可能なものへと変えることができると論じている。本研究は、現在の生成失敗の大部分は克服不可能な論理的欠陥ではなく、自動化されたフィードバックメカニズムによって解決可能な構造的な不一致であることを示唆している。究極的に、SSDE は、エンジニアが仕様アーキテクトとして機能し、LLM が実装への翻訳を担うという効果的な人間とコンピュータの協働を促進することで、手動のエンジニアリング負担を軽減することを目指している。