8月24日、Vu Hung NguyenとThanh Nguyenが「SDAD: Spec-Driven Agentic Development for the AI-Native SDLC」と題した論文をarXiv上に公開した。本論文はプレプリント（査読前）であり、AIエージェントを前提とした新たなソフトウェア開発ライフサイクル（SDLC）の方法論「SDAD（仕様駆動型エージェント開発）」を体系的に提唱している。
「規律はなくなるのではなく、上流に移動する」
LLMベースのコーディングエージェントが普及する中、ソフトウェア開発の現場では「エージェントに投げれば実装してくれる」という期待が先行しがちだ。しかし本論文が主張するのは正反対の方向性である。
エージェントの速度が上がるほど、仕様の精度が実行燃料になる。
論文のキーフレーズを借りれば、「agentic speed does not eliminate engineering discipline; it relocates discipline upstream（エージェントの速度はエンジニアリングの規律を消去しない。規律を上流へ移動させる）」。この一文がSDADの本質を端的に示している。
既存研究との位置づけ
コーディングエージェント研究はここ数年で急速に蓄積されており、AgentCoderのようにテスト実行フィードバックループを組み込んだ自律実装エージェントや、SWE-benchに代表される実世界GitHubイシューへの対応能力評価など、実装品質そのものを競う研究が主流を占めてきた。
SDADが異なるのは、「エージェントに何をさせるか」ではなく「エージェントへの入力をどう設計するか」に焦点を当てている点だ。実装能力の向上を前提とした上で、その能力を最大化するための上流プロセス——すなわち機械可読な仕様書の設計と、検証の制度的分離——をSDLC全体として再定義しようとする試みである。言い換えれば、エージェントの「何を作れるか」ではなく「何を作らせるか」の設計論だ。
SDADとは何か
SDAD（Spec-Driven Agentic Development）は、以下の4フェーズで構成される開発フローとして定式化されている。
- Intent Capture（意図の捕捉） — 人間がビジネス要件・制約・優先度を明文化する
- Machine-Readable Specification（機械可読仕様） — エージェントが直接解釈できる形式の仕様書（FRD: Functional Requirement Document）を作成する
- Agentic Synthesis（エージェントによる合成） — LLMエージェントが仕様を元にコードを生成・実装する
- Independent Multi-Agent Verification under Human Sign-off（独立した多エージェント検証＋人間の承認） — 生成エージェントとは別のエージェント群が検証を担い、リリース権限は人間が保持する
現在のフロンティアモデルはコンテキストウィンドウが数十万〜数百万トークンに達しており、大規模なFRDやリポジトリ全体を1ワークフローで処理できるようになった。この能力の拡大が、SDADを実現可能にした技術的背景だ。
ウォーターフォール・アジャイル・そして「AI-code」
論文は開発手法の歴史的変遷を整理し直し、生産パラダイムを以下の4つに分類している。
- Manual（手動）
- Waterfall（ウォーターフォール）
- Human-Agile（人間主体のアジャイル）
- AI-code（第4パラダイム）
論文内では「Human-Agile」と「Agentic-SDAD」を、成果物・開発リズム・説明責任・セキュリティ姿勢の4軸で比較している。アジャイルが「人間チームの反復速度」を最適化していたのに対し、SDADは「仕様の機械可読性」を最適化の主軸に置く。なお、各パラダイムに付記されている「約2020年」「約2026年」といった時代区分は論文著者による区分であり、特定の標準化団体による定義ではない。
定量ガバナンス指標：曖昧さにコストをつける
SDADが単なる概念論にとどまらない理由のひとつが、定量的なガバナンス指標の導入だ。論文では以下の指標を定義している。
- Ambiguity Tax（曖昧さ税） — 仕様の曖昧さがエージェントの再実行・修正サイクルを通じて生むコストの定量化
- Spec Fidelity（仕様忠実度） — 生成コードが仕様にどれだけ準拠しているかの指標
- SER（Specification Error Rate） — 仕様起因のエラー率
- TCI_agentic（修復乗数φ付き） — エージェント開発における総変更コスト指標。修復フェーズのコスト増幅を係数φで表現する
「仕様が曖昧だと後で何倍もコストがかかる」という経験則を、測定可能な形に落とし込もうとする試みである。ただし本論文はプレプリント段階であり、これらの指標の実証的な有効性は今後の検証を要する。
チームの役割はどう変わるか
論文はエンジニア・QA・プラットフォーム・プロダクトの各職能における「役割の変容（metamorphosis）」も論じている。エージェントが実装を担う世界では、エンジニアの価値は「コードを書く速度」から「仕様を正確に書く能力」と「検証ゲートを設計する能力」にシフトする、という主張だ。
また、合成（synthesis）とリリース権限（release authority）を分離することを強く推奨しており、AIが生成したコードをそのままリリースする経路を制度的に遮断すべきとしている。これはAIを活用したテスト・検証に関する産業界と研究界のエビデンスを踏まえた提言だ。
移行をどう進めるか
既存チームがSDADへ段階的に移行するための「ハイブリッド見積もり」と「段階的移行ブループリント」も提示されている。一気にエージェント全振りにするのではなく、現行のアジャイルプロセスと並走させながら移行する実用的な道筋を示している点は、CTO・エンジニアリングマネージャーにとって参照しやすい構成だ。
「仕様書を書く」という行為は、これまで「実装前の準備」として扱われてきた。SDADはそれを「エージェント時代の最重要エンジニアリング成果物」として再定義する。この視点の転換は、エージェント活用を本格化しようとする組織にとって検討に値する論点だ。
詳細はSDAD: Spec-Driven Agentic Development for the AI-Native SDLCを参照していただきたい。
