2026 年 5 月 12 日に Felipe Fontoura の個人サイトで公開された 仕様駆動開発 のガイド。25 年にわたって本番コードを出荷してきたと自らを紹介する著者は、これを、2025 年後半に AI エージェントとともに 1 人で、Kubernetes 上で動く 13 のアプリ、3 つの API、3 つのデータベースから成る暗号資産フィンテックを 70 日で構築した際に用いた方法として提示している。詳細な数字は別のケーススタディ記事に譲られており、この記事が扱うのは方法そのものである。
記事の中心的な主張は、仕様駆動開発が解決する問題は知能ではなく記憶だ、というものである。著者によれば、AI エージェントは並外れた能力を持つが、セッションをまたぐ永続的な記憶を持たない。そのため、書き留められていないものは次の実行で作り直され、しかも二度と同じ形にはならない。仕様は、プロジェクトの決定事項を先へと運ぶ外部記憶なのである。そこから、ゲート付きの 4 つのフェーズから成るワークフロー、仕様の実例、一連の記述テクニック、そしてこの方法を使う価値がない場合についての明示的な説明が導かれる。
要点
- 仕様駆動開発は、コードを生成する前に、要件、設計、受け入れ基準、制約、エッジケースから成る構造化された仕様を書いて承認し、その仕様をエージェントが構築の拠り所とする信頼できる情報源（source of truth）として保ち続けることと定義される。記事はこの反転を、ドキュメントがコードの副産物になるのではなく、コードが仕様の副産物になることだと要約している。
- 著者は、Anthropic が公開している Claude Code のガイダンスを、モデル開発元自身がこの実践を推奨している例として挙げている。著者の報告によれば、このガイダンスは実装の前に計画することを推奨し、専用のプランモードを提供している。
- 記事は、仕様と混同されがちな成果物とを区別する。プロンプトはエージェントの 1 ターン分の指示であり、PRD は何を作るべきかをビジネスに伝え、設計ドキュメントは人間のレビュアーに決定を説明するものである。エージェントによって実行されるために書かれ、機能とともに存在し続けるのは仕様だけである。
- ワークフローは 4 つのフェーズから成る。要件（何を作るか。ビジネスの言葉で書き、技術に依存しない）、設計（どう作るか。すべての要件を決定に対応づけ、技術選択ごとに理由を示す）、タスク（2〜4 時間単位で、それぞれ独立してテスト可能）、実装であり、各フェーズの間に人間による承認ゲートが置かれる。
- 著者自身のキットでは、このゲートは機能ごとの 1 行の
.statusファイルで、requirements:approvedのようなトークンを保持し、エージェントは行動する前にこれを読む。design.mdがディスク上にあるだけでは承認とみなされず、承認となるのはステータストークンだけである。これは著者独自のツールであり、一般的な慣習ではない。 - 記事の実例は、リトライで決して二重請求してはならない決済の請求作成の仕様である。対象範囲内と範囲外の項目を列挙し、機能要件を EARS で記述し、具体的な受け入れ例を示し、金額を整数のセント単位に固定し、データベースの一意性制約によって厳密に 1 回だけの請求を強制し、最後にコードを書く前に要件を言い直すようエージェントに指示している。
- 記事は、機能要件を Easy Approach to Requirements Syntax（EARS） で記述することを推奨し、これを最も効果が高いのにほとんどのガイドが教えないテクニックと呼んでいる。また、対象範囲外を明示的に述べることが、誰も求めていないものをエージェントが作ってしまうことへの最良の防御だとしている。
- 記事は厳密さの 3 つのレベル――スペックファースト、スペックアンカード、スペック・アズ・ソース――を示し、これを Thoughtworks の Birgitta Böckeler の仕事に帰している。著者は、MVP の機能にはスペックファーストを、お金に関わるものにはすべてスペックアンカードを用いていると報告し、スペック・アズ・ソースはまだ研究段階の賭けだとしている。
- 記事はこの実践を TDD と BDD に続く系譜に位置づけ、TDD をユニットレベルの仕様駆動開発と呼ぶ。そして各手法がどこに真実を置くかを対比する。バイブコーディングは最後のプロンプトに、TDD はユニットテストに、BDD は振る舞いの例に、仕様駆動開発は承認された仕様に真実を置く。
- 記事は、非常に大きなコンテキストウィンドウがあっても仕様は不要にならないと論じる。コンテキストの長さとコンテキストの精度は別の問題だからである。コードベース全体をコンテキストに入れても、エージェントにわかるのはシステムが現在どうなっているかであって、どうなるべきかではない。
- 記事によれば、使い捨てのスクリプト、捨てる前提のプロトタイプ、探索的なスパイクには仕様を書く価値はなく、作業が 1 回の作業時間を超えて続く場合、複数のセッションにまたがる場合、あるいは本格的なアーキテクチャや正確性の要件を伴う場合に書く価値がある。
- 記事は、これはウォーターフォールだという批判を退ける。ウォーターフォールの問題は凍結された長いループの計画にあるとし、この方法の仕様はフェーズごとに改訂される生きたドキュメントだからである。ただし、再び Böckeler を引用して、2000 年代にモデル駆動開発を終わらせた失敗パターンは依然としてリスクであると警告している。
背景
この記事は 1 人の実践者の方法を、本人のサイトで、独立した評価ではなく本人のプロジェクトを根拠として書いたものである。見出しとなる数字はその単独での構築 1 件から来ており、記事はその成果を AI ではなく仕様によるものとしている。記事はランダム化比較試験を引用しており、著者の説明によれば、経験豊富なオープンソース開発者は AI の支援を受けると、速くなったと信じているにもかかわらず実際には遅くなった。これを、より能力の高いモデルほど曖昧な指示を間違った方向へより遠くまで運んでしまうことの証拠としている。また、ワークフローを体系化したツールキットとして GitHub Spec Kit、AWS の Kiro、著者自身の pi-sdd-kit を挙げる一方で、この方法には Markdown ファイルと有能なコーディングエージェント以外のツールは必要ないとしている。