Opsfield
仕様駆動開発（SDD）は、仕様書を先に固め、その仕様を正としてAIに実装させる開発手法です。AI駆動開発やバイブコーディング、ウォーターフォールと並べて語られることが多く、どこが違うのかが分かりにくくなっています。
呼び名が似ているうえに、どれもAIに作らせる、あるいは先に決めてから作るという共通点を持つため、同じものの言い換えに見えがちです。しかし実際には、比べている層も、人が担う役割も異なります。違いを取り違えたまま導入すると、仕様書だけが増えて開発が遅くなりかねません。
逆に言えば、違いさえ押さえておけば、自社の開発にどの進め方を当てるべきかで迷わなくなるはずです。そこで、AI駆動開発やバイブコーディング、従来の設計書との違いに加えて、仕様駆動開発の流れやメリット、注意点、向く場面までを順に整理していきます。
目次
仕様駆動開発（SDD）とは？仕様書を正としてAIに実装させる開発手法
仕様駆動開発（SDD：Spec-Driven Development）とは、仕様書を先に書き、それを正としてAIに計画・タスク分解・実装を進めさせる開発手法で、スペック駆動開発とも呼ばれます。人がコードを書く代わりにAIが仕様を読み取って作業を進め、人は仕様を決めて結果を確かめる側に回るのが特徴です。
ここでいう仕様とは、何を、なぜ作るのかという要件に加えて、作り方の方針や完成とみなす条件までを文書にまとめたものを指します。例えば社内の申請フォームなら、申請できる人や承認の順番、差し戻したときの扱いまでを書いておくイメージです。
そしてAIは、この文書を手がかりに作業を組み立てます。つまり、書かれた内容がそのまま成果物の質を左右するわけです。
なお、この言葉はOpenAPIなどのAPI定義を先に決める進め方（スキーマ駆動開発）を指すこともあります。ただしAIコーディングの文脈では、自然言語で書いた要件や設計をAIに渡す進め方を指すのが一般的です。
仕様駆動開発とAI駆動開発の違い
仕様駆動開発とAI駆動開発の違いは、開発の起点と、AIが担う役割にあります。仕様駆動開発は先に決めた仕様を起点にAIが開発を進めるのに対し、AI駆動開発は仕様の検討そのものからAIとの対話で進めるのが特徴です。
まずAI駆動開発では、要件定義から設計、実装、テストまでの工程にAIを組み込みます。何を作るかを決める段階からAIに相談し、対話を重ねながら仕様を詰めていくため、仕様と実装が並行して形になっていくのです。
一方、仕様駆動開発では、開発に入る前に仕様を文書として固め、AIはその仕様を正として作業を組み立てます。
ただし、仕様駆動開発の仕様そのものをAIとの対話で詰めることもあるため、2つは完全に切り分けられるものではありません。見分けどころは、開発に入る時点で仕様が文書として固まっているかどうかだといえます。
例えば、既存コードの調査や画面の検討は対話で進め、新しい請求機能は仕様を固めてから作る、といったように1つの開発の中で使い分けることもできます。なお、AI駆動開発の全体像はAI駆動開発とは？メリットと工程別の進め方で詳しく解説しているので、あわせて参考にしてください。
| 仕様駆動開発 | AI駆動開発 | |
|---|---|---|
| 起点にするもの | 先に決めて文書にした仕様 | 仕様の検討も含めたAIとの対話 |
| AIの役割 | 決まった仕様をもとに、計画・タスク分解・実装を担う | 仕様の検討から実装・テストまで、対話しながら工程全体に関わる |
| 人の役割 | 仕様を決めて承認し、結果を仕様と照らす | AIとの対話で方向を決め、各工程の出力を判断する |
| 修正のしかた | 仕様を直してから実装を直す | 対話の中で指示を出し直して直す |
| 品質の確かめ方 | 仕様に書いた完成の条件と照らす | 各工程の出力を人がレビューし、承認する |
仕様駆動開発とバイブコーディングの違い
仕様駆動開発とバイブコーディングの違いは、作り始める前に仕様を固めるかどうかと、できたものを人が確かめるかどうかです。仕様駆動開発は仕様を先に固めて結果をそれと照らし、バイブコーディングは仕様を固めずに対話しながら形にします。
そもそもバイブコーディングは、コードをほとんど読まずに、自然言語の指示だけで動くものを作る進め方です。AIとの対話を起点にする点はAI駆動開発と同じですが、人が成果物を検証して承認する工程を省いているため、AI駆動開発のうち最も軽い形と位置づけられます。
そのため試作は速く進む一方、何を決めたのかが文書として残らず、機能が増えるほど直しにくくなるのが難点です。GitHubの公式ブログも、試作には向くものの、重要なアプリケーションでは信頼性が下がると指摘しています。
これに対して仕様駆動開発は、着手までに時間がかかるものの、仕様が残るため、担当者やAIツールが替わっても同じ方針で作り直せるのが強みです。つまり、速さを取るか、後から直せる状態を取るかが両者の分かれ目といえます。
なお、バイブコーディングの進め方やリスクについては、バイブコーディングとは？進め方とツール8選・リスクで詳しく紹介しました。
| 仕様駆動開発 | バイブコーディング | |
|---|---|---|
| 起点にするもの | 先に決めて文書にした仕様 | やりたいことの短い指示 |
| 仕様を固めるタイミング | 作り始める前 | 固めずに、動くものを見ながら形にする |
| 人の確認 | 仕様に書いた完成の条件と照らして承認する | 動くかどうかを見るだけで、コードはほとんど読まない |
| 後に残るもの | 仕様とコード | コード（決めた経緯は残りにくい） |
| 向く場面 | 複数人で長く保守する開発 | 試作・社内の小さなツール |
仕様駆動開発における仕様と従来の設計書の違い
仕様駆動開発の仕様と従来の設計書の違いは、誰が読み、いつ更新するかという点に表れます。仕様駆動開発でいう仕様は、人が読んで終わる資料ではなく、AIに渡す入力であると同時に、実装の正しさを判断する基準でもあるのです。
例えば、ウォーターフォール型の開発で書かれる設計書は、工程の最初にシステム全体の分をまとめて書き、完成後は更新されずに古くなりがちでした。一方で仕様駆動開発では、機能1つ分ほどの小さな単位で仕様を書き、変更のたびに先に直します。
しかも書く単位が小さいので、変更が入っても直す範囲を限って更新を続けられるわけです。言い換えれば、コードではなく仕様を唯一の正しい情報源（Source of Truth）として扱う考え方といえます。
実際、GitHubも仕様駆動開発向けのツールキットSpec Kitを公開した際の記事で、仕様がAIエージェントによるコードの生成・テスト・検証の拠り所になると説明しました。つまり仕様は、AIにとっての手順書にあたります。
| 仕様駆動開発の仕様 | 従来の設計書 | |
|---|---|---|
| 主な読み手 | 実装するAIと、結果を確かめる人 | 実装する人 |
| 書く単位 | 共通の方針に加え、機能やタスクごとに小さく書く | 工程の最初にシステム全体をまとめて書くことが多い |
| 更新のしかた | 変更のたびに先に直し続ける | 工程の完了時に確定し、原則として後戻りしない |
| 実装との関係 | 実装の正しさを判断する正 | 実装前の計画で、完成後は更新が後回しになりがち |
| 実装の担い手 | AIが実装し、人が承認する | 人が実装する |
仕様駆動開発の基本的な流れ
仕様駆動開発は、要件、設計、タスク、実装の4段階で進めるのが基本です。GitHubもSpec Kitを公開した際に、Specify・Plan・Tasks・Implementの4つの段階としてこの流れを紹介しました。各段階で決めることと人が確かめる点を4つ紹介します。
要件の定義
最初の段階では、何を、なぜ作るのかを要件として文書にまとめます。ここで決めた内容が、すべての段階の土台です。
具体的には、要件に誰がどんな場面で使うのか、何ができるようになればよいのか、そして受け入れ基準（完成とみなす条件）を書きます。依頼者のざっくりした要望をAIに渡し、下書きを作らせても構いません。その際、条件があいまいな箇所をAIに質問させると、抜けている前提が見つかりやすくなります。
例えば会議室の予約機能なら、予約できる時間の単位や、すでに埋まっている時間帯への予約を受け付けるかどうかまでが書くべき範囲です。下書きを読んだ人は、業務の実態と食い違っていないか、例外の扱いが漏れていないかを確認します。ここでの見落としは後になるほど取り返す手間が膨らむので、念入りに確かめておきましょう。
設計の決定
要件が固まったら、それをどう作るかを設計として決めます。何を作るかを決める要件に対し、設計は作り方をまとめる段階です。
具体的には、設計で使う技術や画面の構成、データの持ち方、既存システムとのつなぎ方などを決めます。AIに設計案を出させることもできますが、社内で使える技術の範囲や既存コードの書き方、守るべきセキュリティの決まりは先に伝えておかなければなりません。さもないと、運用に乗らない設計が出てきます。
人がこの段階で確かめるのは、設計が要件のすべてに応えているか、将来の変更に耐えられるかという点です。例えば、今は1部署で使う仕組みでも、全社に広げる予定があるなら、利用者を部署ごとに分けられる構成にしておくといった判断が求められるでしょう。設計の文書は、AIが実装するときの前提になります。
タスクへの分解
設計が決まったら、実装する作業を小さなタスクに分解します。AIが1回で仕上げられる大きさに区切るのが、この段階の目的です。
タスクの大きさは、1つ終えるごとに動作を確かめられる単位が目安になります。例えば、予約の入力欄を作る、入力内容を保存する、埋まった時間帯の予約を断るといった具合に、順番と依存関係が分かる形で並べるとよいでしょう。分解の下書きはAIに任せられますが、大きすぎるタスクが残っていないか、順番に無理がないかは人が見ます。
また、各タスクがどの要件に対応するのかを書き添えておけば、レビューで抜けを確かめやすくなるはずです。反対に、要件と結び付かないタスクは、頼んでいない機能が作られる兆しと考えてください。なお、受け入れ基準を確かめるテストを書く作業も、タスクに含めておきます。
AIによる実装と人の確認
最後に、AIがタスクを1つずつ実装し、人がその結果を確かめます。AIに任せきれず、人の判断が欠かせないのがこの確認の場面です。
AIは、要件・設計・タスクの文書を読み取りながらコードを書き、テストを動かします。人が見るのは、受け入れ基準を満たしているか、頼んでいない箇所まで書き換えていないかという点です。満たしていなければ、どの条件が足りないのかを示して差し戻します。
確認の負担を軽くするには、1つのタスクを終えるたびに確かめるのがコツです。まとめて実装させると、どの変更が不具合の原因なのかを切り分けにくくなります。
例えば、入力欄と保存の機能を同時に作らせるより、入力欄を確かめてから保存に進むほうが手戻りは小さく済むでしょう。こうしてすべての受け入れ基準を満たした時点で、その機能は完成です。
仕様駆動開発が注目される背景
仕様駆動開発が独立した手法として語られるようになった背景には、実装の担い手がAIエージェントに移り、仕様の役割が変わったことがあります。人なら仕様にない部分を経験で補えますが、AIは書かれていないことを意図どおりには補えません。
実際、対話だけで作る進め方が広がると、動くのに意図と違う、機能を足すと以前の部分が壊れるといった問題が目立ち始めました。そこで2025年には、仕様を起点にAIを動かす道具が相次いで登場します。
まず7月には、AWSの公式ブログで、仕様を前提に開発を進めるAI IDE（AIを組み込んだ開発用ソフト）のKiroが紹介されました。続いて9月には、GitHubがオープンソースのSpec Kitを公開しています。
さらにAWSは同じ7月に、AI-DLC（AI-Driven Development Life Cycle）という進め方も打ち出しました。これは、AIが計画や成果物の作成を担い、重要な判断は人が下すという分担を、構想・構築・運用の3フェーズで定めたものです。
なお、仕様から実装までを扱う仕様駆動開発に対し、AI-DLCはデプロイなどを扱う運用フェーズまでを含めた、開発のライフサイクル全体を対象にしています。
仕様駆動開発の4つのメリット
仕様駆動開発の強みは、仕様が文書として残り、更新され続ける点から生まれるものです。実装の前後や引き継ぎの場面で効いてくるメリットを4つ紹介します。
実装前の認識合わせによる手戻りの削減
1つ目は、実装前に認識を合わせることで手戻りが減る点です。
完成に近い画面を見てから思っていたものと違うと気づくと、指示を出し直す往復が何度も起こり、そのたびに作業が後戻りします。これに対して仕様駆動開発では、実装に入る前に要件と設計を文書で確かめておくため、認識のずれをコードが書かれる前に見つけられるのです。
例えば、経費精算の申請フォームを作る場合を考えてみましょう。上長の承認が必要な金額の基準や、差し戻し時の通知先を仕様に書いておけば、関係者はその段階で誤りを指摘できます。
実際、完成した画面を触ってから直すより、文書の1行を直すほうがはるかに軽く済むのは言うまでもありません。また、修正の指示が減る分、関係者が確認にかける時間も抑えられます。
仕様書とコードの乖離の防止
2つ目は、仕様書とコードの乖離を防ぎやすい点です。
設計書を実装前に書いても、リリース後の改修で更新が後回しになると、文書と実際の動きは食い違っていきます。そうなれば、もはや誰も設計書を信用しないでしょう。これに対して仕様駆動開発では、変更のたびに仕様を先に直し、その仕様をもとにAIが実装を直します。
つまり、仕様の更新を実装より先に置く進め方というわけです。消費税の端数処理を変える改修を例にすると、まず仕様の計算ルールを書き換え、それを受けてAIがコードを直します。こうして仕様は、半年後に別の担当者が読んでも現在の動きを説明できる状態に保たれるのです。ただし、この効果は順序を守り続けた場合にしか得られません。
仕様が残ることによる引き継ぎとレビューの基準化
3つ目は、仕様が残ることで引き継ぎとレビューの基準ができる点です。
AIが書いたコードのレビューでは、何をもって正しいとするかが曖昧になりやすく、どうしても確認する人の経験に頼ってしまいます。しかし仕様があれば、仕様どおりに動くかどうかという共通の物差しで判断できるはずです。特に受け入れ基準を仕様に書いておくと、確認すべき項目がそのまま一覧になります。
さらに、仕様は引き継ぎの場面でも役立つものです。担当者が異動しても、なぜその作りにしたのかという経緯が文書に残っているため、後任はコードを一から読み解かずに済みます。また、利用するAIツールを替える場合でも、特定のツール専用の書式に寄せすぎなければ、仕様ファイルは次のツールへの入力として使い回せるでしょう。
非エンジニアが仕様の段階から開発に関与できる点
4つ目は、非エンジニアが仕様の段階から開発に関与できる点です。
まず、AIに渡す仕様は自然言語で書かれるため、企画職や業務部門の担当者でも、コードを読まずに内容を確かめられます。これにより、従来は完成した画面を見るまで口を挟みにくかった人も、作る前の段階で誤りや抜けを指摘できるようになるのです。
例えば受注処理の仕組みなら、値引きの承認ルールや例外的な取引先の扱いを最もよく知っているのは営業事務の担当者でしょう。その人が仕様を読んで確認すれば、開発者の思い込みによる誤りを早い段階で減らせます。
なお、ここで問われるのは技術力ではなく、自分の業務を言葉にして分解する力です。業務を言語化できていない部分は、仕様にも書けません。
仕様駆動開発のデメリットと5つの注意点
仕様駆動開発は、導入すれば品質が上がる万能の手法ではありません。むしろ、仕様を書いて保ち続けるという新たな負担が生まれる点は押さえておくべきでしょう。導入前に知っておきたいデメリットと注意点を5つ紹介します。
仕様を書く初期コストと学習コストの増加
1つ目は、仕様を書く初期コストと学習コストが増える点です。
仕様駆動開発では、実装に入る前に要件・設計・タスクの文書をそろえるため、小さな機能でも着手までの時間は当然延びます。AIに下書きさせれば書く手間は減るものの、内容を読んで確認する時間までは省けません。
加えて、書き方の習熟にも時間がかかります。どの粒度で書けばAIが迷わないか、受け入れ基準をどう表現するかは、何度か試して身につけるものです。
そこで最初は、影響範囲の小さい機能を1つ選び、仕様を書いてから完成するまでの時間を測っておくことをおすすめします。従来の進め方と比べて手戻りがどれだけ減ったかを数字で確かめられれば、広げるかどうかの判断材料になるはずです。
仕様の曖昧さをAIが推測で埋めることによるレビュー負荷
2つ目は、仕様の曖昧な部分をAIが推測で埋めてしまい、レビューの負荷が残る点です。
そもそも、仕様を書けば意図どおりに実装されるわけではありません。書かれていない条件があっても、AIは質問せずにもっともらしい内容で実装を進めることがあります。しかも出来上がったコードは一見正しく動くため、誤りは見過ごされがちです。
例えば、在庫が少ないときは通知する、とだけ書いた場合、何個を下回ったら少ないのか、誰にどの手段で通知するのかはAIの推測に委ねられます。したがって、数値や条件、例外時の動きは仕様に明記しなければなりません。
とはいえ、それでも抜けは残ります。人による確認は減らせても、ゼロにはならないと考えてください。仕様を書く時間と確認の時間の両方を、あらかじめ計画に入れておくのが現実的です。
仕様の更新が止まったときの正の不明確化
3つ目は、仕様の更新が止まると、どれが正しいのか分からなくなる点です。
例えば、機能ごとに仕様を書く運用では、機能を追加するたびに仕様ファイルが増えていきます。ところが、急ぎの不具合修正でコードだけを直すと、仕様は古い内容のままです。これが数回続けば、仕様とコードのどちらが正しいのかを誰も判断できません。
さらに厄介なのが、複数の仕様ファイルが同じ機能について別々の内容を書いている状態です。古い仕様をAIに渡せば、直したはずの動きが元に戻ってしまいます。加えて、仕様が増えすぎればAIが一度に読み込める量を超えるおそれもあるでしょう。
そのため、どのファイルを現在の正とするのか、完了した変更の仕様をどう扱うのかを、始める前に決めておかなければなりません。仕様もコードと同じく、手入れを続ける対象です。
仕様の固めすぎによる硬直化
4つ目は、仕様を固めすぎると開発が硬直する点です。
抜けのない仕様を書こうとするほど、検討する項目は増え、実装に入れない期間が長くなります。その間に前提が変わってしまえば、書いた仕様を作り直すことになりかねません。これでは、変化に合わせて小さく作り直せるという利点が失われてしまいます。
そこで、仕様は1回で完成させるものではなく、小さく書いて実装し、確かめてから次を足していくものと捉えましょう。例えば会員登録の機能であれば、まずメールアドレスでの登録だけを仕様に書いて実装し、動きを確かめてから外部サービスのアカウントでの登録を追加します。
このように範囲を小さく区切れば、仕様を書く時間は短くなり、誤りにも早く気づけるはずです。完璧さより、1周を短くすることを優先してください。
既存コードの小さな改修との相性の悪さ
5つ目は、既存コードの小さな改修とは相性が悪い点です。
仕様駆動開発が力を発揮しやすいのは、新しく機能を作る場面でしょう。一方で、長く動いているシステムでは、現在のコードそのものが事実上の正になっているものです。そこに後から仕様書を起こそうとすると、既存の動きを文書に写すだけで大きな手間がかかります。
実際、ボタンの文言の修正や、1か所の計算式の誤りを直す作業に、要件・設計・タスクの文書を一式そろえる必要はありません。こうした改修では、変更内容を直接指示するほうが速く済みます。
したがって、すべての作業に同じ進め方を当てはめるのではなく、新しい機能の追加や大きな作り直しに絞って使うのが妥当です。対象を選ぶ基準も、チームで先に共有しておくとよいでしょう。
仕様駆動開発が向く場面と使い分け
大切なのはどの手法が優れているかではなく、開発の段階と対象に合った進め方を選ぶことです。仕様駆動開発が向く場面、向かない場面、組み合わせ方の3つを紹介します。
複数人で長く保守する開発や品質要件が重い開発【向く場面】
仕様駆動開発が向くのは、複数人で長く保守する開発や、品質要件が重い開発です。
まず、担当者が入れ替わる前提の開発では、なぜその作りにしたのかが残っていないと、後任が安全に手を入れられません。その点、仕様が残る進め方であれば、判断の経緯ごと引き継げます。また、顧客情報や金銭を扱う仕組みのように、誤りの損失が大きい領域にも向いているといえるでしょう。
例えば、請求金額を計算する処理では、端数の丸め方や割引の適用順を誤ると、取引先への請求に直接影響します。こうした処理は、仕様に条件を書いて関係者が確認し、その条件を満たすかどうかを検証してから公開するのが安全です。さらに、監査や取引先への説明を求められる場合でも、仕様と承認の記録があれば根拠を示せます。
要件が固まらない試作段階や小さな修正【向かない場面】
反対に向かないのは、要件が固まっていない試作の段階や、小さな修正です。
何を作るべきかを探っている時期は、画面を見るたびに方針が変わります。そのたびに仕様を書き直していては、せっかくの試す速さが失われてしまうでしょう。この段階では、動くものを早く作って関係者の反応を確かめるほうが、得られる情報は多くなります。
例えば、新しい社内ツールの案を上長に見せて感触を確かめたいだけの場面なら、仕様を整える必要はありません。また、使い捨てる前提の集計スクリプトや、1人で使う小さな自動化も同様です。
つまり、判断の基準は、作ったものを資産として残すかどうかにあります。残さないものにまで仕様を求めると、負担だけが増えて手法そのものが敬遠されかねません。
試作はバイブコーディング、本開発は仕様駆動開発という組み合わせ
現実的なのは、試作はバイブコーディング、本開発は仕様駆動開発という組み合わせです。
まずバイブコーディングで試作を作り、画面の流れや必要な項目を関係者と確かめます。次に、そこで分かったことを仕様として書き起こしましょう。そのうえで、試作のコードは原則として引き継がず、仕様をもとに作り直すという流れになります。
ここで重要なのは、試作のコードをそのまま本番に持ち込まない点です。試作には、確かめるために省いた入力チェックや権限の制御が残っています。そのため、試作から引き継ぐのはコードではなく、触って分かった要件のほうです。
例えば、試作を使った担当者から承認者を複数にしたいという声が出たなら、その内容を仕様に書き加えます。こうすれば、探る段階の速さと、作り込む段階の確かさを両立できるでしょう。
仕様を形骸化させないための3つのルール
手法やツールを選ぶ前に、人の側で決めておくルールがあります。ここが曖昧なままだと、どの進め方を選んでも仕様は形だけの文書になりかねません。形骸化を防ぐルールを3つ紹介します。
仕様より先に行う業務目的の言語化
1つ目は、業務で実現したいことを仕様より先に言葉にすることです。
仕様の書式やツールの使い方から入ると、何のために作るのかが抜け落ちたまま文書だけが整っていきます。そこでまず、誰のどの作業を、どう変えたいのかを書き出してみてください。新人に口頭で引き継げないほど曖昧な業務は、AIにも渡せません。
例えば、見積書の作成を楽にしたいという要望であれば、現在は誰がどの資料を見て金額を決めているのか、どこで確認待ちが発生しているのかを先に洗い出します。すると、作るべきものが見積書の自動生成なのか、承認の流れの見直しなのかが見えてくるはずです。
このように、業務を工程に分けて整理してから仕様に落とすと、作る範囲を誤りにくくなります。順番は業務が先、ツールが後です。
正とする仕様の置き場所と更新順序の一本化
2つ目は、正とする仕様の置き場所と更新の順序を1つに決めることです。
仕様が複数の場所に散らばると、どれが最新なのかを確かめる作業が毎回発生します。そのため、現在の動きを表す仕様を置く場所は1つに定めるべきです。変更のたびに作る作業用の仕様は、完了したら内容をそこへ反映して役目を終える、といった扱いも決めておきましょう。
あわせて、変更の順序も固定します。仕様を先に直し、その後で実装を直すという順番です。さらに、仕様が更新されていない変更は取り込まないという決まりを、レビューの確認項目に入れておきます。
もっとも、急ぎでコードを先に直すこともあるはずです。その場合は、その日のうちに仕様へ反映する担当者を決め、例外を常態にしないようにします。人の心がけに頼らず、手順として組み込むことが要です。
仕様の承認者と実装を任せる範囲の線引き
3つ目は、仕様を承認する人と、実装を任せる範囲を分けることです。
まず、仕様の下書きやタスクへの分解は、AIに任せて構いません。しかし、その内容が業務の目的に合っているかを判断し、承認するのは人の役割です。承認者が決まっていないと、AIが書いた仕様を誰も読まないまま実装が進んでしまいます。
そこで、機能ごとに承認者を決めておきましょう。業務のルールに関わる部分は業務部門の担当者が、技術的な構成に関わる部分は開発の責任者が、それぞれ1人ずつ確認する分け方が現実的です。
あわせて、AIに任せる範囲にも線を引きます。具体的には、実装とテストの実行までは任せ、本番環境への反映は人が判断するといった形です。作業はAI、判断は人という分担を、仕様の段階から明文化しておいてください。
まとめ
仕様駆動開発と他の手法との違いは、仕様をいつ固め、何を正として扱うかに表れます。まずAI駆動開発との違いは、仕様を先に決めてから開発に入るか、仕様の検討からAIとの対話で進めるかという起点の違いです。
またバイブコーディングとは、仕様を先に固めるかに加えて、人が成果物を確かめるかどうかが異なります。従来の設計書と比べると、小さな単位で書いて変更のたびに更新し続ける点が特徴的です。
ただし、手法を選べば成果が出るわけではありません。仕様は書く負担と保ち続ける負担を伴うため、長く保守する開発や誤りの損失が大きい領域に絞って使うのが現実的です。
そこで、手始めに小さな機能を1つ選び、業務で実現したいことを言葉にするところから始めてみてください。そのうえで正とする仕様の置き場所と承認者を決めておけば、仕様は形だけの文書になりません。チームの開発の進め方として根づかせたい場合は、AI駆動開発伴走のように外部の手を借りる方法もあります。
