この技術レポートは、AI コーディングアシスタントによって、仕様駆動開発（SDD） — コードではなく仕様を ソフトウェア開発の主要な成果物として扱うこと — が新たな意味を持つようになったと論じる。大規模言語モデルは パターン補完に長けているが、開発者の心を読むことはできない。仕様の定まらないプロンプトでは形式、権限、 エッジケースが当て推量に委ねられるのに対し、仕様はモデルが意図に合わせるのに十分な情報を与える、という のがその理由である。レポートは、スペクトラムに沿った仕様の厳密さの 3 つのレベル — スペックファースト、 スペックアンカード、スペック・アズ・ソース — と、調査した SDD ツールに共通する 4 フェーズのワークフローを 定義している。Specify（何を作るか）、Plan（どう作るか）、Implement（作る）、Validate（検証する）であり、 各チェックポイントで人間によるレビューを行う。
論文はこのスペクトラム全体にわたるツールを調査している。BDD/TDD フレームワークや API 仕様ツールから、 契約テストのツール、AI 支援の SDD ツールキット — GitHub Spec Kit、 Kiro、Tessl — 、そして認証された組み込みコードのための モデルベース設計ツールまでが含まれる。3 つのケーススタディがこのアプローチを例示している。API ファーストの マイクロサービスの導入、エンタープライズ機能のための Cucumber ベースの BDD の導入、そして ISO 26262 の 認証を受けた自動車のエンジン制御のための Simulink ベースのスペック・アズ・ソースのワークフローである。
要点
- 仕様の厳密さの 3 つのレベル — スペックファースト（仕様は最初の実装のみを導き、その後は乖離しうる）、 スペックアンカード（仕様はライフサイクル全体を通じてコードと並行して維持され、自動チェックによって 同期が保たれる）、スペック・アズ・ソース（仕様は人間が直接編集する唯一の成果物であり、コードはすべて 仕様から生成・再生成される） — を、単一のプラクティスではなく、チームが自らの位置を定められる スペクトラムとして提案している
- 調査したツールに共通する 4 フェーズの SDD ワークフロー（Specify、Plan、Implement、Validate）を、 フェーズ間のチェックポイントとしての人間によるレビューとともに記述している
- 2 つの研究を引用して、人間が洗練させた仕様が LLM 生成コードの品質を向上させ、対照研究ではエラーが 最大 50% 減少したことを報告している
- SDD がそのオーバーヘッドに見合うのはどのような場合かを判断する意思決定フレームワークを提案している。 AI 支援開発、複雑な要件、複数の保守者がいるシステム、統合の多いシステム、規制のある領域、レガシーの モダナイゼーションには有益である一方、使い捨てのプロトタイプ、個人による短期間のプロジェクト、探索的な コーディング、単純な CRUD アプリケーションにはおそらく過剰である
- SDD は新しい分野ではなく、既存のプラクティス（TDD、BDD、API ファースト設計、契約による設計）の進化で あり、主な違いは仕様を助言的なものではなく、テストと CI を通じて実行可能かつ強制されるものにする点に あると論じている
補足
- これは査読付きの出版物ではなく自費出版の技術レポートである（著者の所在地は米国シアトルとされている）。 ケーススタディは論文独自の実証研究ではなく例示として提示されており、引用されているエラー削減の数値は 著者自身が測定したものではなく、参照している他の研究から引かれたものである
- 自らを既存のプラクティスを置き換えるものではなく拡張するものと位置づけ、テスト駆動開発をユニット レベルの SDD、振る舞い駆動開発をその最も直接的な祖先として記述している