Claude Code、Codex、Cursor、GitHub Copilot などの LLM ベースのコード生成ツールは、開発者の生産性を大幅に向上させている。しかし、その効果は自然言語プロンプトの質に大きく依存しており、以下のような根本的な課題がある。

• プロンプトの曖昧さ: 自然言語プロンプトは解釈の幅が広く、期待と異なるコードが生成されやすい
• 反復コストの高さ: 正しいコードを得るまでに何度もプロンプトを修正する必要がある
• 構造化プロセスの欠如: 現在のツールは自由形式の対話を前提としており、開発プロセスとしての体系性が乏しい

こうした課題に対し、仕様駆動型（Specification-Driven） のアプローチでコード生成の品質と効率を改善できるのではないかという問いに答えようとする実証研究が、SANER 2026 に採択された。本記事では、Giovanni Rosa らによる論文 “Understanding Specification-Driven Code Generation with LLMs: An Empirical Study Design” の内容を紹介する。

研究手法 — CURRANTEツールと3フェーズワークフロー

研究の核となるのは、CURRANTE という Visual Studio Code 拡張機能だ。CURRANTE は人間参加型（human-in-the-loop）の LLM コード生成を実現するツールで、以下の3段階のワークフローを強制する。

フェーズ1: 仕様（Specification）

開発者が構造化された形式で要件を定義する。自然言語の自由記述ではなく、以下のような要素を明示的に記述する。

• 関数シグネチャとパラメータ型
• 入力の制約と有効範囲
• 期待される出力形式
• エッジケースとエラーハンドリング要件
• パフォーマンス制約

フェーズ2: テスト（Tests）

仕様に基づいてテストスイートを生成・精緻化する。LLM がテストケースを提案し、開発者がレビュー・修正する。このフェーズで仕様の抜け漏れが発見されることも多い。

フェーズ3: 実装（Function）

仕様とテストを満たすコードを LLM が生成する。テストの自動実行により即座にフィードバックが得られ、合否に基づいて受け入れか再生成かを判断する。

flowchart LR
    A[仕様定義] --> B[テスト生成・精緻化]
    B --> C[コード生成]
    C --> D{テスト実行}
    D -->|Pass| E[受け入れ]
    D -->|Fail| F[仕様 or テスト修正]
    F --> B

このワークフローは TDD（テスト駆動開発）の考え方を LLM コード生成に適用したものと言える。仕様を先に固め、テストで検証可能な形にし、それを満たすコードを生成するという流れだ。

リサーチクエスチョン

核心的な問いは、仕様やテストの精緻化における人間の介入が、LLM 生成コードの品質とダイナミクスにどう影響するかだ。この問いを以下の4つの観点から分析する。

観点	分析内容
有効性（Effectiveness）	テスト通過率、コード品質スコア（循環的複雑度、保守性指標）、正解ソリューションとの照合
効率性（Efficiency）	生成レイテンシ（仕様入力から初回出力まで）、タスク完了時間、反復回数
反復パターン（Iteration Patterns）	修正の種類（ロジック修正、API修正、エッジケース対応）、失敗の分類
人間の介入（Human Intervention）	自動生成コードと手動編集の割合、初回生成と最終コードの編集距離、介入の分類（軽微な修正、大規模な再構成、完全な書き直し）

実験デザイン

32名のプロフェッショナル開発者（実務経験2年以上）が、LiveCodeBench から選ばれた中程度の難易度の問題を解く。LiveCodeBench は LeetCode や CodeForces などから収集された実世界のプログラミング問題で構成されるベンチマークだ。

実験では、参加者に与える補助情報を変えた4つの条件を設定し、何がコード品質に最も影響するかを比較する。

条件	提供される情報
A	仕様のみ
B	仕様 + 参考実装サンプル
C	仕様 + テストケース
D	仕様 + 参考実装 + テストケース

CURRANTE は IDE 上のキーストローク分析によって自動生成コードと手動入力を判別し、きめ細かいインタラクションログを記録する。これにより、上記の各観点を定量的に評価できる。

実務への示唆

この研究は Registered Report のステージ1として採択されている。これはデータ収集前に研究計画（仮説・手法・分析方法）を査読・承認する形式で、結果に関わらず出版が保証される。結果を見てから仮説を後付けする行為（HARKing: Hypothesizing After the Results are Known）を構造的に防止でき、研究の信頼性が高い。

結果の報告はこれからだが、研究デザイン自体からいくつかの示唆を得ることができる。

1. 仕様を書くことの価値

LLM に対して「何を作るか」を構造化して伝えることは、プロンプトエンジニアリングの延長線上にある。しかし CURRANTE のアプローチは、自由形式のプロンプトではなく型付きの仕様を入力として使う点で一歩進んでいる。

実務でも、LLM にコードを生成させる前に以下を明確にすることで、生成品質が向上する可能性がある。

• 入出力の型と制約
• エッジケースの列挙
• 期待するエラーハンドリング

2. テストファーストのLLM活用

仕様→テスト→実装の順序は、LLM コード生成においても有効なパターンだ。テストを先に書く（あるいは LLM に生成させてレビューする）ことで、実装の正しさを自動検証できる。

3. 人間の介入ポイントの最適化

すべてを LLM に任せるのではなく、どこで人間が介入すべきかを明確にすることが重要だ。この研究は、仕様定義とテストレビューが最もインパクトの大きい介入ポイントであるという仮説を検証しようとしている。

まとめ

Giovanni Rosa らの研究は、LLM コード生成を「プロンプトを投げて結果を祈る」スタイルから、構造化された仕様駆動プロセスへと進化させるための実証的な基盤を提供しようとしている。

CURRANTE の3フェーズワークフロー（仕様→テスト→実装）は、TDD の原則を LLM 時代に再解釈したものであり、AI アシスタントとの協働における「人間の役割」を再定義する試みでもある。

結果の公開はこれからだが、研究デザインそのものが示す方向性、すなわちLLM には自由にコードを書かせるのではなく、明確な仕様とテストで制約を与えるべきだという考え方は、日々の開発で今すぐ活用できる。

以上、仕様駆動型コード生成の実証研究を紹介した、現場からお送りしました。

参考情報

• arXiv:2601.03878
• IEEE SANER 2026
• LiveCodeBench