この記事（「Specification-Driven Development：AI エージェントの時代における仕様の復権」）で Alberto Ruiz は、AI 支援開発が、存在感を失ったかに見えていた考え方、すなわち仕様をもう一度見直すことを迫っていると論じる。エージェントが分析、計画、変更、検証、変更の調整といったより広いタスクを担うようになるにつれ、問題はもはや生産性だけではなく、人と自動化されたシステムの双方が理解できるほど明確に、永続的に、検証可能な形で意図をどう表現するかにある、と彼は書く。仕様駆動開発（SDD）がその問題に対する彼の答えである。
記事は SDD を、より多くのドキュメントを書くことではなく、開発の出発点を変えることとして定義する。ツールやエージェントに何かを実装させる前に、何を作るのか、なぜ作るのか、どのような制約の下で、どのような検証基準で作るのかを構造化された形で定義する、というものだ。続いて、記事がまだ定まっていないと見なすツールのエコシステムを概観し、最後に、SDD を全面的な自動化の約束としてではなくエンジニアリングの実践として、分別をもって導入するよう勧めて締めくくっている。
要点
- 記事は SDD を、コードがすぐに主要な信頼できる情報源となり、当初の仕様がほどなくそれに従属してしまう従来のモデルと対比している。SDD では仕様は少なくとも開発中の変更のライフサイクルの間は生き続けようとし、最も野心的なモデルでは、機能やシステムがどう進化するかについての恒久的な参照点になることもある。
- Martin Fowler のサイトに掲載された Birgitta Böckeler の記事を引きながら、仕様をコードより前に書かれ、人と AI の間で共有された信頼できる情報源として機能するものと説明し、これが SDD を、アシスタントとの逐次的なプロンプトや一時的な会話の上に築かれる非公式な作業と区別する点だとしている。
- 単発のプロンプトはスケールしにくいと論じる。ちょっとした試しや小さなユーティリティには有効でも、ソフトウェアが大きくなり、意思決定が積み重なり、関わるチームメンバーが増えるにつれて限界に突き当たるという。そして問題の所在を、モデルの品質だけでなく、永続的なコンテキストの欠如に求めている。
- 仕様を単なる機能記述以上のものとして提示する。それは人間の意図と自動化された実行の間の調整インターフェースであり、エージェントがあるセッションから覚えていることの中ではなく、プロジェクトの中に存在する構造化されたコンテキストの源泉だという。
- Böckeler による Kiro、GitHub Spec Kit、Tessl の分析では、アプローチの野心の度合いが異なると記事は指摘する。仕様は作業の開始時に現れるだけの場合もあれば、変更が進化する間も拠り所として残る場合もあり、コードを導き出す主要な源泉となることを目指す場合もある。
- OpenSpec を、AI アシスタントやエージェントと協働するプロジェクトに仕様のレイヤーを加え、要件をチャット履歴の外に保つための軽量な手段として説明し、Spec Kit を、仕様、計画、タスクといった成果物を中心に構成された、コーディングエージェントのワークフローで SDD を運用することにより重きを置いたものとして説明している。
- SDD を自動的なコード生成に矮小化すると、その主要な価値を見落とすと論じる。その価値は、仕様が変更のライフサイクル全体 ―― 分析、設計、計画、実装、レビュー、テスト、その後の進化 ―― を形づくり、ニーズ、意思決定、実装の間のトレーサビリティを保つときに現れるという。
- SDD はエンジニアリングをなくすのではなく、むしろその重要性を高めると主張する。エージェントが有能になればなるほど、問題をうまく定義し、スコープを区切り、制約を明示し、結果を批判的にレビューすることが重要になるという。
背景
この記事は著者自身の主張であり、ツールの状況についての説明は Böckeler の分析に依拠している。記事は、SDD がまだ確立された標準ではないこと、それを適用する唯一の普遍的な方法は存在しないこと、そして現在のツールは成熟度の異なる段階で急速に進化していることを強調している。ユースケースを絞り込むこと、仕様の書き方とレビューの仕方を定めること、SDD を既存のワークフローに統合すること、そして重要な意思決定について技術的な監督を維持することを推奨しており、SDD の価値を、場当たり的なプロンプトと従来のドキュメントの間の領域に位置付けている。