仕様駆動開発：インスピレーションより構造を

要点

• 仕様駆動開発（SDD）は、機械が読み取れる仕様を主要な成果物にする。コード、テスト、ドキュメントはそれから導出される
• GitHubは2025年9月にSpec Kitを公開。2026年4月までに星が9万を超え、20以上のコーディングエージェントをサポートしていた
• 開発者の66%が、AIへの最大の不満として「ほぼ合っているが、まだ完全ではない」コードを挙げている——この“失敗モード”を検出するために仕様が設計されている
• Birgitta Boeckelerは、SDDの成熟度を3つに分類している：spec-first（仕様を最初に）、spec-anchored（仕様に基づける）、spec-as-source（仕様をソースにする）
• 仕様にも失敗モードがある：Thoughtworks Radarは2025年11月にSDDを「Assess, not Adopt（採用ではなく評価）」と評価し、Marmelabは1つの機能（日付表示）のために1,300行の仕様を文書化した

AIが生成したコード例の45%が、100以上のテスト済みモデルにおいてOWASP Top 10の脆弱性を導入していた（Cloud Security Alliance, 2026年4月）。開発者の66%は、AIへの最大の不満として「ほぼ合っているが、まだ完全ではない」出力を挙げている（Stack Overflow 2025 Developer Survey）。モデルは改善し続けている。失敗モードは変わっていない。

初めてSaaSの請求ダッシュボードを“雰囲気でコード化（vibe code）”しようとしたとき、Claude Codeは40分かけて、すべてがもっともらしく見える別々のレイアウトを3つ生成したものの、いずれも認証境界を取り逃がしていた。私はチャットを閉じて、一枚のPRDを書いた——目的、非目的、触れる4つのテーブル、読み取る2つのロール——そしてそれを貼り付け直した。15分後には、ダッシュボードは最初の試行で正しくなっていた。仕様はウォーターフォールではない。3回の作り直しと1回の差になるのだ。

ギャップは仕様だ。仕様駆動開発はそれを、プロンプトでもコードでもなく、ツールやエージェントがそこから構築する“唯一の真実”として仕様を作ることで埋める。

仕様駆動開発とは？

Wikipediaの定義がいちばん明快だ：「仕様駆動開発とは、形式化された機械可読の仕様が主要な成果物として機能し、そこから実装、テスト、ドキュメントが導出されるソフトウェア工学の方法論である」（Wikipedia, 2026）。

GitHubのDen Delimarskyによる実務者視点の説明は、より運用寄りだ：「最初にコードを書いて後からドキュメントを書くのではなく、仕様駆動開発では、まず仕様から始める。これはコードがどう振る舞うべきかの契約であり、ツールやAIエージェントがコードを生成し、テストし、検証するために使う“唯一の真実”になる」（GitHub Blog, 2025年9月2日）。

両方の定義に共通するのは1つの考え方——仕様はすべての上流にあるということだ。コードは“コンパイル先”。テストは“整合性のチェック”。ドキュメントは“投影”だ。仕様とは、あなたが執筆し、レビューし、バージョン管理するものだ。

その用語は見た目よりずっと古い

仕様駆動開発はAIと一緒に登場したわけではない。Wikipediaはそれを1960年代のNASAのワークフローや、XP 2004カンファレンスでのOstroff、Makalsky、Paigeによる形式的な学術的取り扱いにまでさかのぼっている。形式手法、契約プログラミング、モデル駆動型エンジニアリングはすべて同じ系譜の中にある。2025年に変わったのは、大規模言語モデルによって「まず仕様を書け」というコストが崩れたことだ。仕様そのものを、同じエージェントが下書きし、磨き、コードに変換できるようになった——ただし、仕様が“みんなが議論するべき成果物”である限りにおいて。

「雰囲気でコード化」が生んだ問題

雰囲気でコード化によって、機能を平易な英語で説明し、数秒で動くコードを返してもらえるようになった。これが利点だ。欠点は規模が大きくなると表面化し、過去12か月のデータははっきりしている。

Cloud Security Allianceの2026年4月4日の調査ノートで引用されたVeracodeの研究によると、AI生成コードの45%が、100以上のテスト済みLLMにおいてOWASP Top 10の脆弱性を導入していた。Javaのサンプルは72%の確率で失敗し、さらに88%がログインジェクションに対して脆弱だった（CSA Research Note）。同じノートにあるApiiroのエンタープライズ向けテレメトリでは、AI支援を受けた開発者が同業他社よりも3〜4倍の頻度でコミットを行い、一方でセキュリティ上の指摘は約10倍に増え、特権昇格の経路は322%上昇し、6か月間でその傾向が見られた。

生産性データも同様に厳しい。2025年7月のMETRのランダム化比較試験では、経験のあるオープンソース開発者がAIコーディングツールを使うと19%遅くなったことが分かった。24%のスピードアップを予測していたにもかかわらず（METR RCT, 2025年7月）。Stack Overflow 2025 Developer Survey（n = 48,945）では、AIを使う、または使う予定の開発者は84%だが、AIの精度を信頼しているのはわずか33%で、46%は積極的に不信感を抱いていることが分かった。

「ほぼ正しい」税（ペナルティ）

開発者の66%が、AIへの最大の不満として「ほぼ合っているが、まだ完全ではない」AIソリューションを挙げている（Stack Overflow 2025）。もっともらしく見える誤ったコードのデバッグは、自分で書くより遅くなることが多い。“ほぼ正しい”が計画段階から一歩も出ないようにするために、仕様は存在する。

パターンは一貫している。AIは速く書き、表面的にはもっともらしいコードを生成して、あなたにアーキテクチャのドリフトやセキュリティ上の穴を片付けさせる。Stack Overflowのチームは、2025年の執筆でそのつながりを明確に結びつけており、構造的な解答として「仕様駆動開発」を名前付きで挙げている。私はスケールの全体像を『Vibe Coding Has a Scaling Problem』で詳しく扱った。

仕様駆動開発はどう機能するか

GitHubのSpec Kitは、最も分かりやすいリファレンス実装だ。これは、仕様駆動型のあらゆるプロジェクトが通過する4フェーズのワークフローを形式化しており、Claude Code、Cursor、Copilot、Gemini CLI、あるいはSpec Kitが対応対象にしている20以上の他のエージェントを使っていても、各フェーズは機能する。

4つのフェーズ

1. 憲法（Constitution）。 プロジェクト全体の不変条件。あなたの技術スタック、規約、すべての機能が継承するもの。これは下流のすべての仕様が参照するドキュメントだ。
2. 仕様化（Specify）。 機能レベルの仕様：目的、非目的、制約、受け入れ基準。エージェントが計画を始める前に読むものがこれだ。
3. 計画（Plan）。 エージェントが仕様を分解してアーキテクチャ上の意思決定とタスクの内訳に落とし込み、次にその計画を人間のレビュー用に返す。
4. タスク／実装（Tasks / Implement）。 ここで初めてコードが書かれる。各タスクは仕様内の受け入れ基準へと追跡できるため、ズレは“黙って”見過ごされるのではなく、可視化される。

任意の明確化（Clarify）フェーズが、SpecifyとPlanの間にあり、エージェントは人間のレビュー担当がアプローチを決める前に確認するであろう質問を行う。Spec KitのリポジトリはオープンソースでMITライセンスであり、2026年4月時点でv0.7.xのリリースが継続的に行われていて、星はおよそ9万だった（github.com/github/spec-kit）。

3つの成熟度レベル

返却形式: {"translated": "翻訳されたHTML"}

martinfowler.com の Birgitta Boeckeler 氏による 2025 年 10 月の記事は、spec（仕様）駆動開発を、コミットメントが段階的に高まる 3 つのレベルに分解しています（Boeckeler, October 2025）：

• Spec-first（仕様を先に）。 プロンプトを出す前に仕様を書きます。この仕様は AI に伝えるためのものですが、コードが変わってもコードに再生成されることはありません。最もシンプルで軽量、そして多くのチームはここから始めます。
• Spec-anchored（仕様に紐づける）。 仕様とコードは常に同期します。コードがずれたら仕様が更新され、仕様が変わったらコードが再生成されます。ここが Spec Kit と Amazon Kiro が位置する段階です。
• Spec-as-source（仕様を唯一の源泉にする）。 人間が作成するのは仕様だけです。コードは完全に派生物として生成されるもので、Terraform が HCL からインフラを生成するのに近い形です。Tessl Framework は最も公開された代表例です。

多くのチームはレベル 3 まで必要ありません。非構造的なプロンプトから spec-first に移行するだけで、信頼性向上の大半は回収できます。

Spec-Driven Development vs. Vibe Coding

spec 駆動開発は vibe coding（勢いコーディング）を置き換えるものではありません。制約を加えるものです。この 2 つは、ワークフローの異なるタイミングで、異なる問いに答えます。

この 2 つの健全な形は、階層化です。つまり、よく書かれた仕様の中に vibe-code を入れる。仕様が AI に許される範囲を縛ります。プロンプトは「どのように」を埋めます。出力がずれたときに直すのはプロンプトではなく、仕様です。

Context Engineering — The Layer Below Specs

仕様は AI に「何を作るか」を伝えます。コンテキスト・エンジニアリング（Context engineering） は、それに加えて「すでに分かっていること」を伝えます。この用語は 2025 年 6 月下旬に、Shopify の CEO である Tobi Lütke と Andrej Karpathy が、互いに 2 日違いで並行して考え出しました。

コンテキスト・エンジニアリングとは、次のステップに必要な情報をちょうどよい形でコンテキストウィンドウに詰め込む、繊細な技術と科学の芸術である。— Andrej Karpathy, June 25, 2025

それより 2 日早い Lütke の説明は、より実務的でした。「LLM がそれなりに解けるように、そのタスクのためのあらゆるコンテキストを提供する技術」（@tobi on X, June 23, 2025）。Simon Willison は両方の引用を集め、この用語は「実際のプロダクションでの LLM 業務がどう見えるか」をよりよく反映していると主張しました（Willison, June 27, 2025）。

仕様との関係は一方向です。コンテキスト・エンジニアリングが仕様へ流れ、仕様がタスクへ流れます。コンテキストがない仕様は、技術的には正しいコードを生むかもしれませんが、リポジトリのすべての慣習を破ります。仕様がないコンテキストは、リポジトリに合ったコードを生むかもしれませんが、やるべきことを間違えます。両方が必要です。

私はこれらを、structured vibe coding framework の 3 つの層のうち 2 つとして扱っています。すなわち、コンテキスト・エンジニアリング、AI コーディングのガードレール、そして spec 駆動のワークフローです。これらが揃って「完全なハーネス（検証・実行基盤）」になります。コンテキストのない仕様、あるいはコンテキストがあるのに強制（enforcement）がない場合は、予測可能な失敗が起きます。

The Tools Shipping Spec-Driven Workflows

現時点での spec 駆動開発の状況を定義するのは、3 つのツールです。各ツールは、Boeckeler の成熟度ラダーの異なる位置を取っています。

• GitHub Spec Kit. オープンソースで MIT ライセンス。2026 年 4 月時点で約 90,000 スター。Claude Code、Copilot、Cursor CLI、Gemini CLI、Codex CLI、Qwen、opencode などをサポートします。ここは spec-anchored レベルにあります。憲法（Constitution）/仕様の宣言（Specify）/計画（Plan）/タスク（Tasks）というフローによって、仕様とコードが一緒に進化します。
• Amazon Kiro. 商用の AWS 提供で、同じ spec-anchored ティアです。Kiro は AWS との緊密な統合と、サービス間での仕様の再利用を重視しています。
• Tessl Framework. 商用で、3 つの中では最も攻めた設計です。spec-as-source へ寄せています。人間が仕様を書き、それ以外はすべて生成されます。Thoughtworks の Technology Radar は、2025 年 11 月に「Assess」リングへ spec 駆動開発を配置した際に、3 つすべてを名前付きで挙げました（Thoughtworks Radar Vol. 33）。

これらのツールは生成を担います。強制（enforcement）を担うのではありません。そこで役に立つのが ハーネス・エンジニアリング（harness engineering） です。つまり、生成されたコードが実際に仕様に一致していることを検証するテスト、型チェック、品質ゲートです。仕様とハーネスは補完関係にあります。仕様は「こうしたかった」を表し、ハーネスは「得られたことを証明する」です。

When Spec-Driven Development Backfires

spec 駆動開発には、十分に筋の通った批判者たちがいます。彼らを無視すると、彼らが警告しているのと同じオーバーヘッドがそのまま発生します。

Marmelab の François Zaninotto は、2025 年 11 月に最も具体的な例を記録しています。現在の日付を表示するための単一機能には、Spec Kit を使って8 ファイルと、だいたい 1,300 行の仕様が必要でした（Marmelab, November 12, 2025）。彼の主張は、SDD はウォーターフォールを言い換えたものであり、開発者をループから外すことに最適化されているということです。

SDD は間違った方向への一歩です。誤った課題を解こうとしています。「どうやって開発者をソフトウェア開発から外すのか？」— François Zaninotto, Marmelab

Thoughtworks の Technology Radar はより慎重でしたが、それでもなお SDD を「Trial（試す）」や「Adopt（採用）」ではなく「Assess（評価）」に位置付け、「ワークフローは『手の込んだ（elaborate）で、意見に偏った（opinionated）』」ものであり、「苦い教訓になる可能性がある――つまり AI のために細かなルールを手作業で作っても、結局はスケールしない」という警告をしています。資格のある支持者である Boeckeler も、同じ失敗パターンを挙げています。小さな機能ではレビューの過負荷が起き、非決定的な LLM 出力が、約束された制御を損なうというものです。

実務的なヒューリスティック（経験則）は次のとおりです。仕様駆動開発は、機能仕様書よりも単純なものにはオーバーヘッドです。建築上のドリフト（設計の逸脱）のコストが高い領域（認証、課金、多テナントのデータ、API 契約）では使い、間違えたときにページをリフレッシュすれば済む程度の領域ではやらないでください。

How to Start Without Rewriting Everything

返却形式: {"translated": "翻訳されたHTML"}

仕様書キット、憲法文書、あるいは4フェーズのワークフローは不要です。仕様駆動開発を実践するには、1ページの仕様書と、プロンプトを出す前にその内容をAIへ渡すための規律が必要です。

1. プロンプトを出す前に1ページのPRDを書きます。 目標、非目標、制約、受け入れ基準。15分です。このたった1つのステップが、ほとんどのチームにとって最大の信頼性向上になり得て、費用は一切かかりません。
2. AGENTS.mdを憲法として使います。 技術スタックの選択、慣習、アーキテクチャ上のルール、禁止パターン。Next.js 16.2は現在、create-next-appでデフォルトとしてAGENTS.mdを同梱して出荷しています。vibeready.shのステップバイステップのチュートリアルで、AGENTS.md-firstの完全なワークフローを解説しています。
3. 仕様書を「差分の対象（diff target）」として扱います。 AIが間違ったものを出してきたら、まず仕様書を修正し、その後コードを再生成します。仕様の穴を埋めるためにプロンプトでごまかすのはやめましょう。あれはバイブ・コーディングの失敗モードです。
4. 仕様書をハーネスと組み合わせます。 自動テストや型チェックのない仕様書は、静かにズレていきます。仕様書は「こうしたい」という意図を示します。ハーネスは「コードがそれに一致している」ことを証明します。ハーネス工学は、強制のためのレイヤーです。
5. そのオーバーヘッドに見合うだけの段階でSpec Kitへ卒業します。 共通の「憲法」を共有する複数の機能がいくつか揃ってきたら、Spec KitやKiroで正式化することが回収につながり始めます。それまでは、マークダウン仕様書のディレクトリで十分です。

仕様書は、この流れにおける上流側です。下流側はハーネス——テスト、型チェック、リントルール——で、AIが仕様書を無視したときにそれを見つけます。私は両方をレイヤーとして維持しています。仕様書は意図を定義し、ハーネスが実行を検証します。

仕様駆動開発の目的は「仕様書」そのものではありません。AIに、あなたが本当に欲しかったものを、最初の一回で、将来の自分が保守しなければならないレベルのアーキテクチャとして作らせることです。1ページのPRDは、4時間のデバッグセッションに勝ります。いつだって。

当初は VibeReady に掲載されました。dev.toコミュニティ向けに、ここに再掲載しています。