この記事は martinfowler.com の「Exploring Gen AI」シリーズの一編であり、自らを SDD ツールと称する 3 つのツール、すなわち Kiro、GitHub Spec Kit、そして Tessl Framework（Tessl）を見ていくことで、仕様駆動開発（SDD）が何を意味するのかを解きほぐそうとしている。著者は、定義はまだ流動的であると指摘したうえで、自分が見てきた用法を、AI でコードを書く前に「仕様（spec）」を書き、その仕様が人間と AI にとっての信頼できる唯一の情報源（source of truth）になること、とまとめている。
用語とツールの用法から、著者は SDD にはいくつかの実装レベル、すなわちスペックファースト、スペックアンカード、スペック・アズ・ソース（スペックファースト、スペックアンカード、スペック・アズ・ソース）があると結論づける。さらに仕様についての独自の定義を示し、それを一般的なコンテキスト文書から成るメモリバンクとは区別している。彼女は 2025 年 9 月に自分が使った時点での各ツールの動作を説明し、そのうえで観察と未解決の問いを提示する。その際、ツールは急速に進化していること、また実際のコードベースで長期間使った報告はまだ聞いていないことを断っている。
要点
- 著者による定義では、仕様とは「自然言語で書かれた、構造化され振る舞い指向の成果物（または関連する成果物の集合）であり、ソフトウェアの機能を表現し、AI コーディングエージェントへのガイダンスとして機能するもの」である。SDD の各バリエーションは、仕様の構造、詳細度、構成をそれぞれ独自に定めている。
- 彼女が見つけた SDD のアプローチはどれもスペックファーストだが、すべてがスペックアンカードやスペック・アズ・ソースを目指しているわけではなく、仕様を長期的に保守する戦略は曖昧なままか、未定のまま残されていることが多い。
- Kiro は 3 つの中で最も軽量で、おおむねスペックファーストだと説明されている。VS Code ベースのディストリビューションの中で、Requirements → Design → Tasks というワークフローを、各ステップにつき 1 つの Markdown 文書で進める。要件は GIVEN/WHEN/THEN 形式の受け入れ基準を伴うユーザーストーリーであり、そのメモリバンクは「steering」と呼ばれる。
- spec-kit は GitHub 版の SDD であり、多数のコーディングアシスタント向けにワークスペースのファイルを用意し、その後はスラッシュコマンドで操作する CLI である。そのため 3 つの中で最もカスタマイズ性が高い。ワークフローは Constitution → Specify → Plan → Tasks で、「constitution（憲章）」が強力なルールファイルとして働き、ファイル内のチェックリストに大きく依存している。GitHub の文章からはスペックアンカードを目指す志向がうかがえるものの、著者は spec-kit が仕様ごとにブランチを作ることを指摘し、それゆえ現状はまだスペックファーストにとどまっていると考えている。
- Tessl Framework は当時プライベートベータであり、3 つの中で唯一、明示的にスペックアンカードを目指し、スペック・アズ・ソースも探っている。仕様を保守対象の成果物とし、それが編集禁止とマークされた生成コードファイルに 1 対 1 で対応する。このように抽象度が低いレベルであっても、同じ仕様から繰り返しコードを生成すると非決定性が見られたと著者は述べている。
- 3 つのツールは大きく異なっており、SDD は「一つのものではない」。
- Kiro と spec-kit はそれぞれ 1 つの意見の強いワークフローを提供しているが、著者はそれが現実の大半の問題に合うのか疑っている。Kiro は小さなバグを 16 の受け入れ基準を持つ 4 つのユーザーストーリーに変え、spec-kit は既存コードの上に構築する中規模の機能に対して過剰に感じられた。彼女は、効果的な SDD ツールは、さまざまな規模や種類の変更に対応できる柔軟性を提供しなければならないと論じる。
- spec-kit は繰り返しの多い冗長な Markdown ファイルを大量に生成した。著者は、それならむしろコードをレビューしたいと述べ、効果的な SDD ツールには非常に優れた仕様レビュー体験が必要だとしている。
- これだけのファイル、テンプレート、チェックリストがあるにもかかわらず、エージェントがすべての指示に従わない場面を彼女は頻繁に目にした。たとえば、リサーチノートに記述された既存のクラスを新規のものであるかのように再生成したりした。また逆に、指示に過剰に熱心に従う場面もあった。小さな反復的ステップこそがコントロールを保つ最良の方法であると実証されてきたことを踏まえ、彼女は大規模な事前の仕様設計に懐疑的である。
- 彼女は実際には機能仕様と技術的詳細を切り分けるのが難しいと感じた。また、これらのツールは開発者が要件分析を行うことを当然の前提としているため、想定ユーザーは誰なのかと問いかけている。
- 特にスペック・アズ・ソースについて、彼女はキャリア初期に携わったモデル駆動開発（MDD）との類似を指摘する。LLM は MDD のオーバーヘッドや制約の一部を取り除くが、非決定性をもたらし、パース可能な仕様言語が可能にしていたツールサポートを失う。そして彼女は、スペック・アズ・ソース、さらにはスペックアンカードでさえ、両者の欠点、すなわち柔軟性のなさと非決定性を併せ持つことになるのではないかと考えている。
- 彼女は、スペックファーストの原則は多くの状況で価値があると結論づける一方で、「仕様駆動開発」は十分に定義されておらず、すでに意味が拡散している（意味の拡散（Semantic Diffusion））と述べる。そして、一部のツールは既存のワークフローを AI エージェントにあまりにも文字どおりに流し込み、レビューの過負荷やハルシネーションを増幅させているのではないかと問いかけている。
背景
この記事は、2025 年 9 月に著者自身が 3 つのツールを試した結果に明示的に基づいており、ツールごとの試行回数は限られている。彼女は自分の説明を、ツールがこう動いていると自分は考える、というものとして提示している。3 つのレベルと仕様の定義は、まだ流動的だと彼女が見なす用語を整理するための、彼女自身の提案である。