AIエージェントは、指示が曖昧でも手を止めない。
人間の開発者なら、仕様の穴に気づいた時点で確認に来る。「この場合はどうしますか」と聞かれて、決めていなかったことに初めて気づく。エージェントにその機能はない。曖昧なまま渡せば、曖昧なまま解釈して、迷いなく実装する。しかも速い。
コードを書く速度が上がったぶん、詰まる場所が移った。何を作るかが決まっていない状態そのものが、開発の律速になった。仕様駆動開発（Spec-Driven Development、SDD）は、この移動に名前を付けたものだ。
仕様駆動開発（SDD）とは何か
仕様駆動開発とは、AIエージェントに実装させる前に「何ができたら完成か」まで決めきってから作らせる進め方を指す。決めきる対象は、機能の一覧ではない。誰が、どういう状況で、何をしたら、どうなれば正しいのか。そこまで書いてからコードを書かせる。
これまでも設計書は書かれてきた。だから新しくないと言われれば、半分はそのとおりだ。違うのは、書いた仕様の読み手が人間だけではなくなったことにある。人間の読み手は、仕様の行間を経験で埋める。曖昧な記述を見たら、過去の似た案件を思い出して補うか、書いた人に聞きに行く。エージェントは補わない。書いてあることだけを、書いてあるとおりに実装する。
この性質は、欠陥のようでいて利点でもある。仕様の曖昧さが、実装物のずれとして即座に返ってくるからだ。人間相手なら「なんとなく通じてしまった」で済んでいた穴が、エージェント相手だと必ず表面化する。仕様駆動開発が広がったのは、方法論として優れているからというより、エージェントを使うと曖昧さを放置できなくなったから、という順序に近い。
バイブコーディングとの違い
バイブコーディング（vibe coding）は、AIと会話しながら、動くものを見て次の指示を出していく作り方を指す。仕様を先に書かない。作りながら決める。
速い。手元で試すものを作るなら、これ以上の方法はないと言っていい。頭の中にある曖昧なイメージを、対話しながら実物へ寄せていける。仕様書を書く時間を丸ごと省けるうえ、書いても伝わらなかったはずの微妙なニュアンスが、画面を見ながらなら伝わる。
問題は、できあがったものが誰のものでもないことだ。仕様が会話の履歴にしか存在しないので、あとから来た人には、なぜそうなっているのかがわからない。直そうとすると、動いている挙動を読んで意図を推測することになる。「これは仕様なのか、それとも当時の会話の副産物なのか」が判定できない。
二つは対立していない。使い分けの問題である。自分が作って自分だけが使うもの、捨てる前提の試作、明日には形が変わっているものは、バイブでいい。他人が使う、他人が引き継ぐ、お金が動く。このどれかが乗った瞬間に、完成条件が要る。
AI駆動開発との違い
AI駆動開発は、AIを前提に開発工程そのものを組み替えることを指す言葉で、仕様駆動開発より広い。調査、設計、実装、テスト、レビューのそれぞれで、人間がやることとAIに任せることを引き直す話だ。生成AI駆動開発（AIファースト開発）とはで扱っている範囲がこれにあたる。
仕様駆動開発は、そのうち「何を作るかをどう決めるか」の部分を担う。AI駆動開発を進めるとき、実装をエージェントに任せる比率を上げるほど、仕様の質がそのまま成果物の質になる。だから両者は競合せず、片方がもう片方の中に入っている。
言葉が二つある理由は、詰まる場所が違うところにある。AI駆動開発が答えるのは「どの工程を任せるか」で、仕様駆動開発が答えるのは「任せる前に何を決めておくか」だ。前者だけ整えてもエージェントは迷い、後者だけ整えても人間の工程が旧来のまま残る。
これはウォーターフォールへの回帰なのか
仕様を先に書く、と聞いた開発者が最初に思うのはこれだろう。散々アジャイルで否定してきた進め方に、AIを理由に戻るのか、と。
その警戒は正しい。実際、仕様駆動開発を導入して、要件定義フェーズが伸びるだけで終わる現場はある。書く分量が増え、レビューの会議が増え、実装が始まるのが遅くなる。それはウォーターフォールの再来であって、仕様駆動開発が意図したものではない。
分かれ目は、固める範囲にある。ウォーターフォールが固めるのはシステム全体で、しかも一度固めたら変えない前提で工程が組まれている。仕様駆動開発が固めるのは、いま作る一つ分の完成条件だけだ。次に何を作るかは、いま作ったものを見てから決めていい。反復はそのまま残る。
もう一つの違いは、仕様を書く目的だ。ウォーターフォールの設計書は、人間の実装者への指示であり、同時に契約上の合意文書でもあった。だから網羅性が求められ、分厚くなった。仕様駆動開発で書くのは、エージェントが迷わずに実装できる最小限であり、しかも実装が終われば受入確認にそのまま使える。網羅ではなく、判定可能性が基準になる。
では、その最小限とはどこまでか。
実際の手順
Beekleが自社の開発で回している順序は五つに分かれる。
要求を洗い出す。やりたいことを、粗い一行で並べる。この段階で詳細化しない。「営業担当が外出先から日報を出せる」程度の粒度で、思いつく限り出す。
作る、後回し、作らないを決める。並べた要求を、価値、現場で使えるか、技術コストの三つで評価して絞る。ここで落とすものを先に決めるから、詳細化の手間が無駄にならない。逆順にすると、切る分の作り込みが丸ごと捨てになる。
「作る」と決めた要求だけをユーザーストーリーにする。誰が、何をしたくて、なぜそれが要るのか。ユーザーストーリーの書き方で扱っている三要素の形に落とす。あわせて、システムの振る舞いをEARSの構文で書く。EARSは英語のテンプレートが原典だが、実務では日本語で書いて差し支えない。
- 常時：システムは、日報の下書きを自動保存すること。
- イベント駆動：日報が送信されたとき、システムは、上長に通知を送ること。
- 状態駆動：オフラインである間、システムは、送信をローカルに保留すること。
- オプション：写真添付が有効な場合、システムは、1件あたり5枚まで受け付けること。
- 望まない事象：送信が3回失敗した場合、システムは、下書きを保持したままエラーを表示すること。
五つの型に押し込むこと自体に意味があるわけではない。型に入れようとすると、「オフラインのときはどうなるのか」「失敗したら消えるのか」を書かざるを得なくなる。決めていなかったことが、書けないという形で見つかる。
受入条件をGherkinで書く。前提、もし、ならば、の三つで、動作を確認できる形にする。Gherkin入門に書き方をまとめてあるが、要点は、実行して合否が判定できる文になっているかどうかだけだ。「使いやすいこと」は判定できない。「送信ボタンを押してから3秒以内に完了画面が表示されること」は判定できる。
実装させる。ここまで書けていれば、エージェントに渡す情報は揃っている。実装が終わったら、Gherkinで書いた受入条件をそのまま確認手順として使う。仕様と受入確認が同じ文書なので、テスト項目を別に起こす工程が消える。
先ほどの問いに戻る。決めきる範囲は、この五番目まで書けるかどうかで決まる。判定できる受入条件が書けたなら、それで足りている。書こうとして書けない箇所が残っているなら、そこがまだ決まっていない。仕様の分量ではなく、判定可能性が基準になるというのはこの意味だ。
順序について一つ補足しておくと、詳細化は絞ったあとに来る。ユーザーストーリーを全件書いてから優先順位を決める進め方をよく見るが、切る分を先に作り込むことになるので効率が悪い。要件定義全体の流れは要件定義の完全ガイドに、要求と要件の区別は要求と要件の違いにまとめてある。
ツールは何を担うのか
仕様駆動開発を支援するツールは、大きく二つに分かれる。
一つは、コーディングエージェントの側で仕様を持つものだ。エディタやエージェントの設定として仕様ファイルを置き、実装のたびに読ませる。導入が軽く、個人でもすぐ始められる。書いた仕様がリポジトリの中にあるので、コードと一緒に版管理できるのも利点になる。
もう一つは、チームで仕様を持つものだ。仕様がリポジトリの外にあり、発注側や非エンジニアも読み書きできる。打ち合わせで決まったこと、まだ決まっていないこと、決まった結果どのタスクが増えたかが、一つの場所につながっている。
どちらが優れているという話ではなく、仕様の読み手が誰かで決まる。エンジニアだけで完結する開発なら前者で足りる。発注側と認識を合わせながら進める開発では、仕様がリポジトリの中にあると、そもそも読んでもらえない。
製品名を挙げて比較しないのは、この領域の顔ぶれが数か月で変わるからだ。エージェント側の機能として取り込まれたものもあれば、独立したツールとして伸びているものもある。選ぶときは、名前ではなく「仕様の読み手は誰か」「決まっていないことがどこに溜まるか」で見たほうが外さない。
Beekleは後者を自社で作って、実際の受託案件で使っている。議事録を入れると未確定の箇所を洗い出して確認に回し、返ってきた回答を要件とタスクに反映する仕組みで、PM on Railsという名前で外部提供の準備を進めている。
効かないケース
仕様駆動開発は、書く手間が先に来る。その手間が回収できない場面もある。
使い捨てのスクリプトには要らない。一度実行して結果が出れば役目が終わるものに、受入条件を書く意味はない。
探索フェーズにも向かない。実物を見ないと何が欲しいかわからない段階で仕様を書くと、書いた仕様が思い込みの塊になる。ここはバイブコーディングで動くものを先に作り、見てから決めたほうが早い。作ったものは捨てる前提で扱う。
一人で作って一人で使うものも、割に合わないことが多い。仕様を書く相手が自分しかいないなら、頭の中に置いておけば足りる。
逆に言えば、他人が使う、他人が引き継ぐ、お金が動く、監査が入る。このどれかが乗ったものは、規模が小さくても仕様駆動開発の対象になる。判断の軸は開発規模ではなく、間違ったときに誰が困るかにある。
よくある質問（FAQ）
Q. 仕様駆動開発とアジャイルは両立しますか？
A. 両立します。仕様駆動開発が固めるのは、いま作る一つ分の完成条件だけで、全体を先に固める進め方ではありません。1スプリントで着手する範囲について、着手前に受入条件まで書く、という運用になります。スプリントの区切りで次を決め直す点は変わりません。詳しい工程の組み方は要件定義の完全ガイドを参照してください。
Q. 仕様はどこまで細かく書けばいいですか？
A. 実行して合否が判定できるところまでです。「使いやすいこと」は判定できないので仕様になりません。「送信ボタンを押してから3秒以内に完了画面が表示されること」なら判定できます。分量を基準にすると書きすぎるので、判定可能性を基準にしてください。書き方の具体例は要件定義書テンプレートにまとめてあります。
Q. 小さいチームでも意味がありますか？
A. 人数ではなく、間違ったときに誰が困るかで決まります。二人のチームでも、他人が引き継ぐコードや課金が乗る機能を作るなら効きます。逆に、一人で作って一人で使う道具なら、規模にかかわらず要りません。
Q. 仕様を書く時間の分、開発全体は遅くなりませんか？
A. 着手までは遅くなります。速くなるのは、間違ったものを作り直す回数が減る部分です。受入条件を書く工程が、そのままテスト項目を起こす工程を兼ねるため、後工程で戻ってくる分もあります。ただし探索フェーズのように「そもそも作り直す前提」の場面では回収できないので、そこは対象外にしてください。
Q. 発注側や非エンジニアも関わる必要がありますか？
A. 完成条件を決められるのは、業務を知っている側だけです。エンジニアが書けるのは、決まったことを判定可能な形に整える部分までで、「この場合はどちらが正しいか」は業務側にしか答えられません。ただし、そのために発注側がGherkinを書けるようになる必要はありません。決まっていない点を質問の形で受け取り、答えを返す。それが仕様に反映される。この往復が回っていれば足ります。
Beekleにご相談ください Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。