仕様駆動開発：カテゴリ全体が収束した実践
あらゆる本格的な AI のコードのツールが、およそ 1 年のうちに同じ機能をリリースしました。それが偶然に起きることはほぼありません。
2025 年、興味深い問いはモデルがどれだけ良くなるかでした。2026 年、興味深い問いはそれに何を与えるかです。
GitHub は Spec Kit をリリースしました。AWS はこの考えを中心に構築された開発環境 Kiro をリリースしました。BMAD-METHOD、OpenSpec、Tessl がそれぞれ試みました。Cursor はルールファイル経由でそこに到達しました。Martin Fowler はこれらの実装の比較を公表しました。6 つの独立したチームが 12 か月で同じ答えに収束するとき、互いを模倣しているのではありません。全員が同じ壁に当たっているのです。
壁には今や名前があります。解決策にも。
仕様駆動開発とは実際に何か
コードが生成される前に要件、制約、成功の基準を書いてください。その文書を正しさの源として扱ってください。エージェントにそれに基づいて構築させてください。
それだけです。新しい考えではありません。業界が 30 年うまくやれず、その後遅すぎるとして大部分を捨てた要件の分析です。変わったのは概念ではありません。変わったのは経済です。
仕様は書くのに高くつき維持するのに高くついたため、ほとんどのチームは粗い線を書き、他のすべてをコードのレビューで発見することになりました。エンジニアリング担当者がどうせ 1 つの機能に 3 週間必要である限り、それは妥当な取引でした。生成が速くなったとき妥当でなくなりました。今は仕様が遅い部分であり、あらゆる判断は遅い部分に住んでいるからです。
これが対抗して発明された障害の形
プロンプトから始まるツールは仕様を完全に飛ばします。あなたが成果を説明し、ツールがそれらしい何かを生み、説明が覆わなかったあらゆる決定を生成ツールが静かに下します。
どの決定でしょうか。重要だと判明するものです。メールアドレスは一意か、そして何の中で一意か。解約されたアカウントはまだ何を見られるか。2 人が同じレコードを変えたら何が起きるか。その一覧は 1 万行になる前にページ分割を必要とするか。
誰もこれらの問いを立てなかったので誰も答えませんでしたが、アプリはそれぞれに答えを持っています。あなたの会社を一度も含まなかった文脈からの推論で選ばれた答えです。
同じ力学が定義のステップを飛ばすあらゆるツールに現れます。これは70 パーセント問題の背後にある仕組みです。前進が止まるのは残りの作業が難しいからではなく、数百世代前に静かに下され、システムを分解せずにはもう変えられないアーキテクチャ上の決定によって塞がれているからです。
それなしで何が起きるかについてのデータ
DORA の 2025 年の AI 支援ソフトウェア開発の現状の報告は、利用できる最も清潔な読み取りです。技術に携わる人の 90 パーセントが今や仕事で AI を使い、80 パーセント以上が生産性が上がったと信じています。そして高い AI の利用は、デリバリーのスループットの増加とデリバリーの不安定さの増加と同時に結びついています。
リリースはより速い。物事を動かし続けることはより悪い。両方が一緒にです。
GitClear の 6 億 2300 万件のコード変更に関する 2026 年の分析は損害の形を示します。2023 年の基準に対して、重複したコードブロックは 81 パーセント増、1 つの送信の中でのコピー＆ペーストは 2022 年の 9.4 パーセントから 2026 年前半の 15.7 パーセントへ上昇、エラーを隠す構造は 47 パーセント増です。同時にファイル間の関数呼び出し、つまりコードの再利用の利用できる最良の指標は 35 パーセント減、そしてコードを整理する作業は 2022 年の変更の 21 パーセントから 2026 年の 3.8 パーセントへ崩れました。
エンジニアリング担当者は今、コードを整理するよりおよそ 5 倍多くコピー＆ペーストしています。2022 年にはこの比率は逆方向に働いていました。
これのどれもモデルの質の問題ではありません。生成が安く、構造が明示的に誰の仕事でもないときに現れる結果です。
3 つの関与の度合い
誰もがこの語句を同じように理解しているわけではなく、その違いは実践で重要です。Martin Fowler の枠組みが私が見た中で最も清潔です。
仕様が先。 仕様を書き、それから生成し、その後コードを手で維持します。仕様が最初の構築を動かし、その後徐々に歴史的なものになります。導入が最も簡単で保証が最も弱いものです。半年後、文書はもう存在しないシステムを説明しています。
仕様が錨。 仕様とコードが一緒に進化します。仕様を変え、影響を受けた部分を再生成し、両方を最新に保ちます。より多くの規律が必要で、報酬は文書が信頼できるままであることです。
仕様が源。 仕様は変更する唯一の成果物です。コードは、コンパイルされたファイルが出力であるのと同じように出力です。手でパッチを当てません。最も強い保証と、チームの働き方における最も大きな飛躍です。
自らを仕様駆動と称するチームのほとんどは「仕様が先」の変種を実践しています。それは当てずっぽうにプロンプトを与えることに対する本物の改善であり、同時に静かに腐る版です。
仕様に何が入るか
有用な試験はこうです。生成ツールが推測しなければならないなら、それは文書に入ります。
- データモデル。 エンティティ、関係、多重度、レコードを一意にするもの、削除で何が起きるか。最も価値のある部分であり、最も頻繁に飛ばされる部分です。
- ユーザータイプと権限。 誰が存在し、それぞれが何を見て何をできて、境界で何が起きるか。
- 不変条件。 決して破られてはならない規則を明示的に。「エラーを優雅に処理する」ではありません。それは制約ではなく願いです。
- 成功の基準。 それが機能していることをどう知るか。機能しているかどうかの議論が決着できる程度に正確な言葉で。
そこに入らないもの。生成ツールがあなたより上手に選ぶ実装の詳細です。変数に名前を付ける仕様は仕様ではなく、より悪いツールで書かれたコードです。
誰もが誤る部分
仕様は、文章の外のどこかで強制できるときにだけ役に立ちます。
制約が文書にだけ住んでいるなら、それは提案です。生成ツールはそれを一度読み、影響を受けた 14 番目のファイルでそれを尊重するかもしれないししないかもしれません。制約はシステムが検査する場所へ行く必要があります。「空でない」と「一意」はフォームの処理ではなくデータベースに、型はコメントではなく境界に、認可は誰かが書くのを覚えていた条件ではなくシステムが評価する方針として。
これは実践としての仕様駆動開発と、文書の種類としての仕様駆動開発の違いです。文書はあなたがどう決めるかです。強制は決定をどう保つかです。
本当に実践しているかを見分ける方法
4 つの問い、意図的に不快なものです。
- 何かが壊れたとき、コードを直しますか、それとも仕様を直しますか。 答えが常にコードなら、よくても「仕様が先」を実践していて、文書はもう古びています。
- 新しい人が仕様を読んでシステムがどう振る舞うか予測できますか。 そのためにコードを読まなければならないなら、仕様は源ではなく要約です。
- 仕様の中にシステムが破れないものはありますか。 あらゆる規則が文章なら、どれも保証されていません。
- 仕様をレビューしていますか、それともコードの差分をレビューしていますか。 数千行の生成されたコードをレビューすることは演劇です。議論がまだ安いうちに文書について議論してください。
これはツールをどこに残すか
今日の実装のほとんどは特にコードの生成について仕様駆動です。仕様を生み、それに基づいて実装を生成し、作業する成果物はコードベースです。
より難しい版は同じ論理をアプリ全体（データモデル、API の表面、認証の境界、インターフェース）に広げ、仕様がコードが何をするかだけでなくシステムが何であるかを覆うようにします。Archie の計画フェーズはまさにそれで、だからそれをリポジトリではなくスタック全体に適用された仕様駆動開発として説明しています。異なる範囲、同じ原則です。生成する前に定義することです。
分別のある人々はこれをどこまで進めるかについて一致していません。本気で後戻りを主張する人はいません。
これのコストは何か
判断を先に移すことはプロジェクトの最初の週には遅く、その後のあらゆる週には速くなります。これは本物のコストで、前もって、まさに勢いが最も価値あるように感じられ競合が目に見える何かをリリースしている瞬間に支払われます。これらすべてを飛ばしたチームが勝っているように見える作業周期があるでしょう。
規律の面でも無料ではありません。制約を書くことはインターフェースが現れるのを見るより楽しくありません。仕様をレビューすることはコードをレビューするより満足感がありません。これらの習慣は納期の圧力の下で腐り、それはそれらを重要にしている同じ圧力です。
そして一部は本当に当てはまりません。この週末にアイデアを検証していて結果を捨てるつもりなら、捨ててください。これのどれも 2 日の寿命のソフトウェアには手間をかける価値がありません。
これが定着した理由
チームにまず仕様を書かせようとする以前のあらゆる試みは失敗し、良い理由で失敗しました。仕様は本物の仕事の上に乗る追加の重荷でした。文書を書き、それからどうせその物を構築しなければなりませんでした。
それはもうその取引ではありません。今は文書が仕事の大部分であり、構築が安い部分です。6 つの独立したチームが 1 年のうちにこれに気づいたのは、モデルが良くなったことの自明な帰結だったからです。
この実践は議論に勝ったのではありません。経済がその下で動いたのです。
関連する読み物
最初の診断：vibe coding は約束を破った。カテゴリがどこへ進んだか：vibe coding の次に来るもの。同じ主張をシステム全体に適用したもの：第一原理からの AI ファーストのソフトウェア設計。そして同じ考えのより古い枠組み：ソフトウェアを二度書かない。
よくある質問
仕様駆動開発とは何ですか。 コードが生成される前に要件、制約、成功の基準を書き、その仕様を AI エージェントがそれに基づいて構築する正しさの源として扱うことです。2025 年と 2026 年に、プロンプトから始まり定義のステップを飛ばす働き方への直接の応答として現れました。
古典的な要件の文書とどう違いますか。 概念は同じです。経済は違います。古典的な仕様はかなり高くついたので、チームは粗い線を書き、残りを実行中に発見しました。1 つを用意するのに数か月ではなく数時間で済み、安く直せるとき、それを終える価値があり、最新に保つ価値があります。
どのツールが仕様駆動開発を支えていますか。 GitHub Spec Kit、AWS Kiro、BMAD-METHOD、OpenSpec、Tessl が名前のある実装で、Cursor はルールファイル経由でより軽い版を支えています。本質的に、仕様がコードにどれだけ密に結びつくかで分かれます。生成を一度動かすのか、その横で進化するのか、それとも変更する唯一の成果物なのかです。
仕様駆動開発の 3 つの度合いは何ですか。 仕様が先：仕様が最初の構築を動かし、その後コードを手で維持します。仕様が錨：仕様とコードが一緒に進化します。仕様が源：仕様が変更する唯一のもので、コードは出力として扱われます。これを実践するチームのほとんどは「仕様が先」をやっています。
仕様駆動開発はチームを遅くしますか。 作業を追加するのではなく移します。仕様の中の決定は、前もって意識的にか、後から推測する生成ツールによって静かにか、いずれかで下され、後者の道が修正の源です。最初の週は遅く、その後は速くなります。
仕様には何を入れるべきですか。 生成ツールがそうでなければ推測しなければならないすべてです。関係と一意性の規則を持つデータモデル、ユーザータイプと権限、決して破られてはならない不変条件、そして議論を決着させる程度に正確な成功の基準です。生成ツールがあなたより上手に選ぶ実装の詳細は省いてください。
仕様駆動開発は AI ファーストの設計と同じものですか。 仕様駆動開発は生成する前に定義する実践です。AI ファーストの設計は、制約がどこで強制されるか、決定がどの順序で下されるか、人間の利用者と並んでエージェントの利用者のためにどう設計するかも含む、より広いアーキテクチャの帰結の集合です。
