仕様駆動開発とは、開発者のプロンプトとエージェントの実装とのあいだに書かれた仕様を挟み、エージェントが元の依頼ではなくレビュー済みの成果物から構築するようにする実践である。プロンプトはまず仕様に変換される。その仕様は分析・洗練され、何かが構築される前に人間が修正することもできる。そのうえで実装は仕様から進められ、仕様に照らして検証される。ここではこの実践について九つの別々の説明を取り上げる — プラグインによる実装、あるツールベンダーのワークフローについての第三者による説明、実務家によるツール横断的なサーベイ、この実践を実装するフレームワークの学術的な比較、この実践を限界まで推し進めた一人の開発者の体験談、学部生への教育についての報告、仕様を形式的な記法へと近づける産業研究のケーススタディ、この実践をシステムの決定性の問題として扱う中国語のハンドブックの一章、そしてこの実践を、エージェントが毎セッション読み込む常設の指示ファイルと対比する投稿である。これらはここまでの点では一致しているが、以下に述べる具体的な仕組みでは異なっている。
用法
Context Engineering Kit の Spec-Driven Development プラグイン は、この実践を三つのコマンドにまで絞り込んでいる。一つは最初のプロンプトからタスクファイルを作成し、一つはプロンプトを分析して品質基準を満たすまで仕様を反復的に洗練し、一つは出来上がったファイルから動作する実装を生成して検証する。このプロジェクトは、その結果をコンパイルとしての開発 — タスク仕様を入れれば動くコードが出てくる — と特徴づけており、二つ目のステップが新しいコンテキストで始まるよう、計画と実装のあいだでエージェントのセッションをクリアすることを勧めている。計画は、調査、コードベースの探索、要件と受け入れ基準、アーキテクチャ、独立に検証可能なステップへの分解をそれぞれ担う専門のサブエージェントに分担される。実装はステップごとに実行され、各フェーズの終わりにレビューが行われる。その仕様フォーマットは arc42 に基づいている。プロジェクトはこれをソフトウェア開発ドキュメントの広く採用された標準と呼んでおり、実装品質に何も加えないとプロジェクトが判断した部分を取り除くことで、LLM が行動に移せるものに合わせて調整している。中核のループの周りには、任意の改良が用意されている。人間が仕様を編集したりコメントしたりした後に計画を再実行する --refine フラグ、計画と実装の各フェーズにゲートを設ける --human-in-the-loop フラグ、そしてタスク間の依存関係を宣言し、大きな作業を個別に仕様化された単位へ分解できるようにする機能である。
GitHub の Spec Kit は、別の出典で説明されているもので、同じ中核のアイデアを、ゲートで区切られた四つのフェーズ — Specify、Plan、Tasks、Implement — として構成している。人間は現在のフェーズが検証されるまで次のフェーズに進まない。Specify は技術スタックではなく、ユーザージャーニーと成功基準を扱う。Plan は、開発者がアーキテクチャ、スタック、制約を与え、エージェントがそれを技術計画に落とし込む段階である。Tasks は仕様と計画を、独立にレビュー・テスト可能な小さな塊に分割する。Implement はそれらのタスクを一つずつ（あるいは並列に）こなし、開発者は最後に大量のコードをまとめて受け取るのではなく、焦点の絞られた変更をレビューする。その出典は、いったん承認された仕様を、セッションをまたいでエージェントのコンテキストに繰り返し与えられる、永続的でバージョン管理された成果物として位置づけており、チームの製品要求仕様書（Product Requirements Document）になぞらえている。
第三の説明 は、2026 年の実務家による仕様駆動開発のサーベイ（コードから契約へ：AI コーディングアシスタント時代の仕様駆動開発）によるもので、SDD を単一の実践ではなく、厳密さの三つのレベルからなるスペクトラムとして捉えている。仕様が最初の実装だけを導き、コードができた後はずれていくに任せてよい スペックファースト（spec-first）、仕様がライフサイクル全体を通じてコードと並行して保守され、自動化されたチェック — 多くは仕様から導出されたテスト — によって両者の同期が保たれる スペックアンカード（spec-anchored）、そして仕様が開発者の直接編集する唯一の成果物であり、コードはすべてそこから生成・再生成される スペック・アズ・ソース（spec-as-source） である。最後のものは、Simulink ベースの組み込みシステム開発のような領域ではすでに確立されている。このサーベイは、調べたツールに共通する四フェーズのワークフロー — Specify、Plan、Implement、Validate — を、各フェーズの境界での人間のレビューとともに記述し、このスペクトラムにまたがる代表的な AI 支援ツールキットとして GitHub Spec Kit、Kiro、Tessl を挙げている。
第四の説明 は、AI 開発エージェントを支援するフレームワークの学術的な比較（プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価）によるもので、この実践に外側から迫っている。一つのワークフローを記述するのではなく、六つのそうしたフレームワークを 6 次元プロセス分類法 に照らして採点し、それらに共通する点を報告している。この研究は、根底にある動きをプロンプトを契約に変換することとして捉えている。最初の指示は出発点にすぎず、本当の作業はそれが PRD、仕様、計画、ストーリー、タスク、アーキテクチャ、あるいはチェックリストになったときに始まる。それこそがレビューの節目を生み出し、曖昧さを減らすものだという。その動きの中で、この研究はフルの変種と軽量の変種を区別し、GitHub Spec Kit、OpenSpec、Spec Kitty を、オーバーヘッドの水準が異なる同じ動きの変形として位置づけている。仕様は、採点したほぼすべてのフレームワークが最も高く評価される次元であり、だからこそこの研究は、それをこの分野の共通項であり、フレームワーク間を最も区別しない次元と呼んでいる。また、補完的な対極として リバースドキュメンテーションエンジニアリング を挙げている。これは、新しいシステムのために仕様を書くのではなく、既存のシステムから仕様を復元するものである。
第五の説明 は、フレームワークやサーベイではなく、一人の開発者による体験談である（仕様駆動開発：AI で開発するときに Markdown をプログラミング言語として使う）。GitHub Blog に寄稿した Tomas Vesely は、Markdown ファイルをアプリケーションの実際のソースコードとして扱い、GitHub Copilot にそれを Go へコンパイルさせる方法を述べており、生成された Go を直接編集したり見たりすることはほとんどないほどだという。彼の出発点は、この実践が取り組もうとする問題に反対側から行き着いたものである。連続するプロンプトで駆動されるエージェントは、アプリケーションの目的と過去の決定を見失い、そのコンテキストを保持するためのカスタム指示ファイルは、更新するとプロンプトですでに述べたことの重複になるため、古くなっていく。彼の答えは、Markdown をコードに付随する指示として扱うのをやめ、それをコードそのものとして扱うことである。ユーザー向けドキュメントは参照によって仕様に取り込まれ、その説明によればこれがドキュメントと実装の同期を保つ。そして、意図的に可搬性を持たせた短いプロンプトファイルがそれをコンパイルする。その説明は、仕様を書くことを、変数、ループ、条件を用いた Markdown と平易な英語によるプログラミングとして描き、仕様はコードと同じように lint できると報告している。二つ目のプロンプトがエージェントに、明確さのために仕様を最適化し、重複を取り除き、一つの概念には一つの用語を用いるよう求めるのである。これは、上記の実務家のサーベイが示すスペック・アズ・ソースのレベルの実例であり、論じられてではなく実践によって到達されたものである。
第六の説明 は、大学のチーム開発科目にこの実践を導入した報告（ソフトウェア開発 PBL における AI エージェントを用いた仕様駆動開発の導入に関する実践報告）によるものである。この報告は、この実践の登場をツールベンダーのドキュメントに位置づけ、そのドキュメントが示すワークフローを要約している。エージェントが要件分析、設計、実装計画を順に実行し、その過程で requirements.md、design.md、tasks.md を生成し、開発者は各ステップでそれらの文書を継続的に確認して自分の意図と一致させ続ける、というものである。その説明によれば、この実践の際立った特徴は、エージェントが曖昧な自然言語の指示ではなく構造化された仕様文書から作業すること、そしてそれらの文書がアーキテクチャパターン、コーディング規約、セキュリティ要件、テスト戦略を明示的に述べ、エージェントがそれを制約として扱うことにある。この報告は、GitHub Copilot をはじめとする多くのエージェントが、そうしたワークフローやプロジェクトのルールを Markdown のカスタム指示ファイル — この科目の場合は copilot-instructions.md — から読み取ることに触れている。この科目独自の適応では、要件分析と設計を単一の調査フェーズにまとめている。これにより、ワークフローが新しい要件だけでなく機能追加やデバッグにも一般化されるという理由からである。さらに、エージェントと開発者が実装が仕様と一致していることを確認する明示的なレビューフェーズを加えている。
第七の説明 は、IBM Research のケーススタディ（人工知能による形式的ソフトウェア仕様の強化）によるもので、仕様をツールの方向ではなく形式的な記法の方向へと推し進めている。著者たちは、仕様を LaTeX による軽量な数学的記法で補った自然言語で書き、それを非形式的な要件と完全に形式的な仕様言語とのあいだの中間表現として扱い、コードが生成される前にモデルに曖昧さや不整合がないかレビューさせている。その説明は、生成前にレビューするという順序こそが改善の源泉だと報告している。同じプログラムをこの方法で仕様化すると、実行結果から実装を反復的に修正する場合の約 6 分の 1 の時間で済み、最初の生成で正しいものが得られたという。また、周辺のプログラムについてはモデルにこの実践のやり方で作業させること — 実装の前に中間的な Markdown ファイルで問題を形式化すること — を許したと述べ、そうすることで、ビジネスロジック以外の要素についてモデルがどのような決定を下したかが見えるようになったと報告している。
キュレーションされたインデックス である Awesome Spec-Driven Development は、この実践のツールを集めたもので、Engineering4AI が GitHub で管理している。その価値は個々のエントリよりも、エコシステムに与える形にある。このインデックスはプロジェクトを、入門、標準、仕様ツール、開発フレームワーク、IDE・エディタ統合、MCP サーバー、ワークフロー管理、関連リストに分類している。これらのカテゴリは、この実践自体の文献がひとまとめにしがちな問いを切り分けている。その Standards セクションには、エージェントの振る舞いを指定するための Markdown ベースのフォーマットと説明される AGENTS.md と並んで、システム、方法、知識を監査可能な保証レベルでモデル化するための厳密なフレームワークと説明される First Principles Framework が置かれている。それらとは別に、仕様を作成するツール（GitHub Spec Kit、OpenSpec）、一つの仕様の周りに開発ワークフロー全体を組み立てるフレームワーク（BMAD（Breakthrough Method for Agile AI-Driven Development））、この実践をエディタに組み込む IDE・エディタ統合（Kiro）、そしてワークフロー管理の下にある、複数の仕様にまたがる作業を追跡するボードやオーケストレーターが並んでいる。この実践についてのインデックス自身の一行の説明 — 実装が始まる前に包括的な仕様を作成することであり、それが要件と成果物の整合、コード品質、テスト、ドキュメントを改善するという — は、上記の説明群に共通する一般性の水準にとどまっている。各エントリは名前と一文にすぎないため、これはツールがどのように広がり、実務家がそれをどう分類しているかの証拠ではあっても、個々のツールがどう動くかの証拠ではない。
第八の説明 は、Jimmy Song のオンラインハンドブック『智能体构建指南』の一章であり、その特徴は正確さをシステムの決定性の問題として扱う点にある。その定義は他の説明に近い — 構造化された仕様を、設計、実装、テスト、デプロイを駆動する単一の信頼できる情報源（single source of truth）とし、自然言語または構造化された Markdown で、ソフトウェアが何をすべきか、そしてなぜかを述べる実行可能な契約として書く — そして SDD を TDD や BDD と対比し、視点をさらに前へ移し、実装に入る前に「何を」と「なぜ」を確定させるものだとしている。異なるのは、正確さが何に依存するかについての主張である。高い正確さはモデルの賢さではなく、システムの決定性による のであり、それはルールによってモデルを制約し、コンテキストを通じてモデルに情報を与え、経験をワークフローとして再利用することで達成されるという。
その説明は、この実践がいつ割に合うかに数値を与えているが、それは測定値ではなく評価基準として示されている。成功率が 50% を下回るコード生成システムは、生産性として返すものよりも手戻りのコストのほうが大きいとし、出力の少なくとも 90% がそのままコンパイル・実行でき、少なくとも 85% が自動テストに通り、手作業での修正を要するのが多くとも 10% という目標値を挙げている。そして、あるタスクの種類がそれを 90% 超で維持できるようになったとき、それは実験ではなく本番の能力になるという。自動化されたパイプラインについてのその説明は、おなじみの Specify → Plan → Tasks → Implement → Deploy のループであり、ビルド、静的解析、テストスイートが検証のオラクルとして働き、失敗はフィードバックされて、正しさの条件が満たされるまでモデルが再計画と再試行を行う。
その中には、上記の説明にはない二つの捉え方がある。一つ目は、AI を点的なアシスタントからシステムの一員へと変えるとする三層のプロトコルスタックである。AI がツールとどうやり取りするかを定義する Model Context Protocol、エージェント同士の協働を可能にする Agent2Agent プロトコル（A2A）、そしてユーザーとエージェントのあいだのリアルタイムで可視的なやり取りを確立する AG-UI である。二つ目は、AI First in Non-Business Domain と呼ぶ導入原則である。タスクが高頻度で、すでに明確なルールがあり、コアビジネスから切り離されたところから始める — 例として挙げられているのは A/B 実験の終了、設定のクリーンアップ、セキュリティ修正である — そして、その管理された範囲で自動化が機能するようになってはじめて、ビジネス上のイノベーションへと広げる。理由として挙げる問題は他の説明と同じ — コンテキストのドリフト、制御できない結果、人間・AI・ツールのあいだの協働に標準がないこと — だが、それにゲートや成果物の厳密さではなく、順序づけのルールで答えている。
この章は研究ではなくオンラインハンドブックの一節であり、独自の評価は示していない。その正確さの目標値と導入原則は、測定された知見としてではなく、立場として示されている。
さらにもう一つの説明は、この実践に外側から迫り、機能仕様が、エージェントが毎セッションの開始時に読み込む常設の指示ファイルとどう関係するかを問うている。AIに渡す指示書の役割分担: AGENTS.md/SKILL.md/DESIGN.mdと仕様駆動開発の現在地 は両者を並べ、その根底に同じコミットメントがあることを見いだす — 実装する前に書くこと、機械可読な内容と人間可読な内容を一緒に保持すること、エージェントに参照できる永続的なコンテキストを与えること、構文を制約して曖昧さを減らすこと、決定を既知の場所に固定すること — 一方で、両者を時間軸によって区別している。その投稿の読みでは、単一の機能に範囲を限った仕様は、その機能のために作られ、その機能によって消費され、機能が完成すればアーカイブされる。これに対して AGENTS.md や DESIGN.md のようなファイルは、保守され成長していく常設の規範を記述する。これは、その投稿が挙げるツールにおける機能単位の仕様のライフサイクルについての特徴づけであり、承認された仕様がバージョン管理された成果物として保持され、後のセッションに繰り返し与えられるとする上記の説明を置き換えるものではなく、それと並ぶものである。
曖昧さを制約する構文の例として、この投稿は Kiro による EARS 記法 — Easy Approach to Requirements Syntax — の使用を挙げ、要件を五つの固定テンプレートのいずれかの形に整える記述規約として説明している。二種類のファイルのあいだに提案されているつながりは、機能仕様が、デザイントークンを再度書き記す代わりに、常設の DESIGN.md で定義されたものを参照できるというものであり、同じ規範を二か所で保守することを避ける方法として示されている。この投稿は、これがまだ広く確立された実践ではないと述べている。
さらにもう一つの説明は、この実践をチームレベルの規律として扱う ものであり、一人の開発者と一つのエージェントのためのワークフローとしてではない。エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする は、チームが行う四つのコミットメントによってこの実践を定義する。自明でない計画的な変更はすべて、その変更の契約として扱われる書かれた仕様から始まること。仕様はコードと並んでバージョン管理され、同じレビュー、監査、ロールバックの規律の下に置かれること。コード、テスト、ドキュメント、インフラは、人間、エージェント、あるいはその両方によって仕様から導出され、仕様への明示的な来歴を持つこと。そして仕様と成果物が食い違うときは仕様が信頼できる情報源であり、食い違いは成果物を再導出するか仕様を修正することで解消され、決して黙って編集することによってではないこと。この説明は仕様を二つのレベルに分ける。システム仕様は、永続的なアーキテクチャ、規約、規範的なルールを記述し、エージェントが毎セッション読み込むルールファイルとして具体化される。機能仕様は一つの変更を記述し、それが納品されるとアーカイブされる。そして、機能レベルだけを読み込むと機能的には正しいがアーキテクチャ的に一貫しないコードが生まれ、システムレベルだけを読み込むとエージェントはタスクに根拠を持てなくなると警告している。さらにこの説明は、その両方をスキルと区別している。スキルは手続き的でオンデマンドに読み込まれるものであり、規範的で常に有効なものではない。
この説明は、この実践についての二つの読み方を退けている。一つは、それがより多くのドキュメントを意味するという読み方である（実装前に仕様を書くことは設計行為として示され、既存のコードを文書化することはそれに遅れをとるものとされる）。もう一つは、それがウォーターフォール型のプロセスを意味するという読み方である（反復は保たれるが、提案・適用・アーカイブのサイクルのように、まず仕様について、次にコードについて行われる）。この説明はこの実践を、仕様の周りに構築されたチーム所有の仕組みからなる 方法論的ハーネス と組み合わせ、全体を主にグレー文献から引き出された概念的フレームワークとして提示しており、予測される利点は知見ではなく仮説だとしている。また、自らの適用範囲も限定している。要件が本当に未知である探索的な作業については、より軽い規律のほうが適切かもしれないと示唆している。
実務家向けのガイド（仕様駆動開発とは何か？ 実践者のためのガイド（と、使わないほうがよい場合））は、この実践を知能ではなく記憶を軸に捉えている。著者の Felipe Fontoura は、それを、コードが生成される前に構造化された仕様 — 要件、設計、受け入れ基準、制約、エッジケース — を書いて承認し、その仕様がエージェントの構築の拠り所となる信頼できる情報源であり続けることと定義する。これにより、ドキュメントがコードの副産物になるのではなく、コードが仕様の副産物になる。彼が挙げる理由は、エージェントにはセッション間の永続的な記憶がないということである。書き留められていないものは次の実行で作り直され、仕様はプロジェクトの決定を先へ運ぶ外部記憶なのだという。彼のワークフローは、要件、設計、タスク、実装の四フェーズで、それぞれが人間の承認ゲートで区切られている。タスクは、それぞれ単独でテストできる 2〜4 時間の単位に切り分けられ、彼自身のキットでは、requirements:approved のようなトークンを持つ機能ごとのステータスファイルだけが承認とみなされ、設計文書がディスク上に存在するだけでは承認にならない。彼は機能要件を Easy Approach to Requirements Syntax（EARS） で書き、作らないものを明示的に述べることを勧めている。彼はスペックファースト、スペックアンカード、スペック・アズ・ソースという厳密さのレベルを Thoughtworks の Birgitta Böckeler の仕事に帰し、MVP の機能にはスペックファーストを、お金に関わるものにはすべてスペックアンカードを使っていると報告し、TDD をユニットレベルの仕様駆動開発と呼んでいる。また、大きなコンテキストウィンドウがあれば仕様は不要だという反論に対しては、コンテキストの長さとコンテキストの精度を区別して答えている。コードベース全体をコンテキストに入れても、エージェントに伝わるのはシステムが現在どうなっているかであって、どうなるべきかではない。
適用される場面
この実践は開発者の時間とトークンを信頼性と引き換えにするものであるため、その引き換えに見合う場面に当てはまる。context-engineering-kit プロジェクトは、既存の構造を持つ複雑なあるいは大規模なコードベース向けにこれを位置づけている。グリーンフィールドの作業を対象とするフレームワークとは異なり、既存のコードが多いほど性能がよくなると主張しており、その理由は、各計画フェーズに、変更がどのファイルに影響し、どのパターンに従うべきかの分析が含まれているからだという。プロジェクト自身の比較では、仕様駆動のルートを、ワンショットのプロンプトから始まる段階的な進展の信頼性の高い側の端に置き、トークンのオーバーヘッドをベースラインの数倍とし、人間のレビューを加えるとさらに増えるとしている。
この実践は、仕様がそもそも書くに値し、開発者がそれに労力を注ぐことを前提としている。context-engineering-kit プロジェクトは、品質は仕様の反復に費やした時間に強く比例し、人間のフィードバックがなければ結果は動くが最適ではないものになると明言している。デフォルトでは、プラグインは明確化を求めるのではなく自ら仮定を置く。開発者の時間はモデルの時間より貴重だという理由からである。報告されている失敗モードは、ビルドが壊れることではなく、労力の無駄である。情報の不足やタスクの複雑さのために最初の仕様が間違っていた場合でも、エージェントは自己修正して動く解決策にたどり着いたが、はるかに長い時間がかかり、誤った道に時間を費やした。そのためプロジェクトは、作業をより小さなタスクに分解し、各仕様を独立にレビューすることを勧めている。
GitHub Spec Kit の説明は、同じ引き換えを別の形で捉えている。その四つのゲート付きフェーズは、その出典が Simon Willison を引いて「トランプの家のコード（house of cards code）」 — 精査に耐えずに崩れる脆い AI の出力 — と呼ぶものを防ぐためにあり、仕様と計画が検証されるまで実装を始めさせないことでそれを実現する。その説明の Plan フェーズでは特に、企業の標準化された技術選定、レガシー統合の制約、あるいはコンプライアンス要件が、開発者が与え、エージェントが技術計画に織り込むものである。
フレームワークの比較は、一つのリスクを最も直接的に前面に出す説明である。仕様が信頼できる情報源になるなら、それはコードと整合し続けなければならず、仕様、計画、タスク、テスト、実装のあいだのドリフトは、この研究が調べたフレームワーク全体にわたって見いだした繰り返し現れるリスクの筆頭である。その提案する答えは実践ではなく研究課題である。コードの変更が仕様を無効にしたときにそれを自動的に検出すること、そして最終結果だけでなく中間成果物の品質を測定することである。
実務家のサーベイの説明は、独自の判断枠組みを示している。SDD は、AI 支援開発全般、複雑な要件、複数の保守者がいるシステム、統合の多いシステム、トレーサビリティを必要とする規制領域、レガシーのモダナイゼーションには採用する価値があるとし、使い捨てのプロトタイプ、一人で行う短命なプロジェクト、探索的なコーディング、要件が自明な単純なアプリケーションにはオーバーヘッドが見合わないとしている。
体験談の説明は、フレームワークが想定するものではなく、一人の実務家が実際に突き当たる限界を付け加えている。仕様を書くことは、望むものを正確に記述することを求めるため、コードを直接書くより難しいことがあると報告されている。生成されるコードが増えるにつれてコンパイルは遅くなり、その説明が述べる次のステップは、仕様がエージェントに各セクションを独自のモジュールに分割するよう指示することである。著者は執筆時点ではテストを加えておらず、仕様は意図された振る舞いを記述し、テストはそれを検証するものであるため、仕様駆動のワークフローでもテストは不可欠であり続けると述べている。
IBM Research のケーススタディは、別の種類の境界を加えている。プログラムのどの部分を仕様が確定させなければならないか、である。著者たちは、システムアナリストは、モデルが変更してよいものと保持しなければならないものを分けなければならないと論じる。ユーザーインターフェースのような周辺的な要素はモデルに任せてよいが、ビジネスロジックに関わるものは、特に意図が曖昧な場合には、確認のためにアナリストに戻されるべきだという。彼らは、自らの精密な仕様を緩い散文に要約し、そこから再生成することで、その線引きを誤ったときの代償を示している。再構成では、元の仕様が確定させていたいくつかのこと — 別々の組織という概念、イベントの順序、ある当事者の予算の上限など — が抜け落ちたり損なわれたりしたと報告している。その説明はまた、概念的な限界ではなく注意の限界についても報告している。数ページを超えると、モデルは生成中にときおり仕様の一部を省略し、著者たちはこれを、より長い仕様を分解すべきだという論拠と読んでいる。
この実践がどの程度確立されているかは、これらの説明のどれも単独では決着をつけていない。この段落で扱う七つの説明は、いずれもその用語を自らの実装やパターンの説明に用いている。context-engineering-kit の信頼性に関する主張 — チームがテストしたすべてのケースでそのプラグインが動くコードを生成したという主張を含む — はプロジェクト自身のものであり、独立した評価ではなく社内での本番利用に基づいている。GitHub Spec Kit の説明は、Spec Kit そのものの独立した評価からではなく、ツール自身のドキュメントと、エージェントの指示ファイルについての別の GitHub の分析に基づく第三者のブログ投稿によるものである。実務家のサーベイも同様に、査読付きの研究ではなく自費出版の技術報告である。そのケーススタディは説明のための例として示されており、人間が洗練した仕様について引用している誤り削減の数値は、自らの測定ではなく参照している他の研究から引かれたものである。フレームワークの比較は単著のプレプリントであり、その次元ごとのスコアが、独立に検証された測定ではなく、各フレームワークの公式ドキュメントに基づく著者の判断であり、二人目のコーダーもなく評定者間信頼性も報告されないまま単一の評定者によって付けられたものだと明言している。また、採点したフレームワークの一つが著者自身のものであるという利益相反も申告している。第六の説明は四チームからなる単一の大学科目についての実施報告であり、したがってそれが述べているのは、この実践の一般的な評価ではなく、この実践の一つの適応の記述である。体験談の説明は、これら七つのうちで最も狭い証拠である。単一の個人プロジェクトについての数か月にわたる一人の開発者の経験であり、そこで使われたコーディングエージェントのベンダーによって公開され、著者自身によって推奨ではなく実験的なワークフローとして示されている。第七の説明は、単一のシミュレーションプログラムについての一つのチームの経験を報告する産業研究のケーススタディであり、その時間の比較は、統制された研究ではなく著者たち自身の二度の試みから引き出されたものである。
実務家向けのガイドは、一度の作業では終わらず、複数のセッションにまたがる作業、あるいは本格的なアーキテクチャや正しさの要件を伴う作業に線を引き、単発のスクリプト、使い捨てのプロトタイプ、探索的なスパイクは仕様に値しないと判断している。そのガイドは、仕様がフェーズごとに改訂される生きた文書であることを根拠にウォーターフォールという読み方を退けているが、Böckeler を引いて、2000 年代にモデル駆動開発を終わらせた失敗モード — とりわけ仕様のドリフトと早すぎる過剰な仕様化 — がこの実践にとってもリスクであり続けると警告している。その証拠は、13 のアプリからなるフィンテックを 70 日で一人で構築したという著者自身の報告であり、独立した評価ではない。
関連用語
- バイブコーディング — プロジェクトが自らのプラグインと対比する実践。プラグインはバイブコーディングのソリューションではないと述べつつも、デフォルトのまま人間のチェックポイントなしに単一のプロンプトから駆動すると、それと同じように振る舞うことを認めている
- サブエージェント駆動開発 — 同じプロジェクトがこの実践を凝縮したものとして提供する、より軽量なアプローチ
- LLM-as-a-Judge — フェーズ間の品質ゲートに用いられる評価手法
- AI エージェントのための良い仕様の書き方 — この実践についての GitHub Spec Kit の説明の出典
- 仕様駆動開発：AI で開発するときに Markdown をプログラミング言語として使う — 上記の体験談の出典。そこでは Markdown ファイルがアプリケーションのソースコードとして扱われ、生成された Go はほとんど直接編集されない
- コードから契約へ：AI コーディングアシスタント時代の仕様駆動開発 — 上記で示した、仕様の厳密さの三段階のスペクトラム（スペックファースト、スペックアンカード、スペック・アズ・ソース）と Specify/Plan/Implement/Validate のワークフローの出典
- 3 段階の境界（Three-Tier Boundaries） — サーベイではなく、上記の good-spec の投稿で示された、関連する仕様記述のパターン
- プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 — この実践を実装するフレームワークを比較した、上記の第四の説明の出典
- 6 次元プロセス分類法 — その比較が用いる評価手段であり、それによれば仕様はこの分野で最も区別力の低い次元である
- リバースドキュメンテーションエンジニアリング — 逆方向の取り組み。新しい作業のために仕様を書くのではなく、レガシーコードから仕様を復元する
- ソフトウェア開発 PBL における AI エージェントを用いた仕様駆動開発の導入に関する実践報告 — 学部のチーム開発科目でこの実践を教えたことを報告する、上記の第六の説明の出典
- 人工知能による形式的ソフトウェア仕様の強化 — 上記の第七の説明の出典。そこでは仕様が数学的記法で補った自然言語で書かれ、コードが生成される前にモデルによってレビューされる
- AgentScript — 第八の説明が挙げる実装の一つで、エージェント自身の計画が散文ではなくコードとして出力される
- エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする — 四つのコミットメントと二つのレベルの仕様を示す、上記のチームレベルの説明の出典
- 方法論的ハーネス — その説明が仕様の周りに構築する、チーム所有の仕組みの集合
- 仕様駆動開発とは何か？ 実践者のためのガイド（と、使わないほうがよい場合） — 仕様をエージェントに欠けている外部記憶として扱う、上記の実務家向けガイドの出典
- Easy Approach to Requirements Syntax（EARS） — そのガイドが機能要件の記述に勧める要件フォーマット