スペックファースト（spec-first）、スペックアンカード（spec-anchored）、スペック・アズ・ソース（spec-as-source）は、Birgitta Böckeler が 仕様駆動開発を理解する：Kiro、spec-kit、Tessl で、この用語の使われ方と、それを実装すると称するツールを調べたうえで提案した、仕様駆動開発 の三つの実装レベルである。スペックファーストでは、よく練られた仕様が最初に書かれ、目の前のタスクのための AI 支援開発ワークフローで用いられる。スペックアンカードでは、仕様はタスクの完了後も保持され、その機能の進化と保守に用いられる。スペック・アズ・ソースでは、仕様が長期にわたって主要なソースファイルとなる。人間が編集するのは仕様だけであり、コードには決して手を触れない。彼女はこれらのレベルを、互いの上に積み重なるものとして提示している。
用法
記事のレベルの図では、スペックファーストの仕様は機能が作られた時点で削除され、以後の変更ごとにそれを記述する新しい仕様が書かれるのに対し、スペックアンカードの仕様は機能の進化に合わせて編集される。著者は、自分が見つけたすべての SDD のアプローチと定義はスペックファーストであるが、すべてがスペックアンカードやスペック・アズ・ソースを目指しているわけではなく、仕様を長期にわたって保守する戦略はしばしば曖昧であるか未定のままにされていると述べている。三つのツールにレベルを当てはめ、彼女は Kiro をおおむねスペックファーストと読み、GitHub Spec Kit を、GitHub がスペックアンカードを志向すると表明しているにもかかわらず、仕様ごとにブランチを作るためにまだスペックファーストにとどまると読み、Tessl を、明示的にスペックアンカードを目指し、スペック・アズ・ソースを探っている唯一のツールと読んでいる。
三つの流派として
深蓝居ブログの中国語の記事（2026 年 2 月）は、同じ三つの名前を、仕様をコードに対してどう位置付けるかで異なる SDD の三つの流派に用い、それらをレベルではなく選択肢として扱っている。その説明では、スペック・アズ・ソース（「急進」）派は、コードを仕様とバイナリの間の中間生成物とみなす。保守されるのは仕様だけであり、コードは破棄して再生成でき、生成されたコードへの手作業の修正は仕様にフィードバックしなければならない。記事はこの流派を、金融の基幹システム、通信プロトコル、暗号アルゴリズムなど、極めて高い一貫性が求められるシステムに位置付けている。スペックアンカード開発（「伝統」）は、仕様を双方向の同期を伴うアンカーとして保持する — 仕様の変更がコードの更新を駆動し、コードの改善が仕様を更新することもある — 一方で、中核となるビジネスロジックの制御は人間が保つ。記事はこれを大半のエンタープライズアプリケーションに適するとみている。スペックファースト（「軽量」）は、仕様を開発開始時の「スーパープロンプト」として扱う。Markdown のチェックリストのような軽量な仕様が AI の生成を導き、その後仕様は強制的な同期なしに意思決定記録としてアーカイブされるため、その権威は時間とともに薄れていく。記事はこれをラピッドプロトタイピング、探索的な作業、小規模な社内ツールに位置付け、成熟したチームは三つすべてを組み合わせる — 中核モジュールにはスペック・アズ・ソース、業務モジュールにはスペックアンカード、ツールスクリプトにはスペックファースト — と論じている。
適用される場面
これらのレベルは、2025 年後半時点での一人の著者による用語の使われ方と三つのツールのレビューから得られた記述的な分類であり、確立された標準ではない。彼女はスペックファーストの原則を多くの状況で価値あるものとみなしている。スペック・アズ・ソースについては特に、ビジネスアプリケーションでは結局普及しなかったモデル駆動開発との類似を指摘し、スペック・アズ・ソース、さらにはスペックアンカードでさえ、モデル駆動開発と LLM の双方の欠点、すなわち柔軟性の欠如と非決定性を抱え込むことになるのではないかと疑問を呈している。後の記事の、状況に応じた流派の選び方に関する指針も同様に、測定された結果ではなく一人の著者の推奨である。