仕様駆動開発（Spec-driven Development）は「作る側」の目線で何が変わるか
コーディングエージェントに「雰囲気でコードを書かせる」時代が終わりに向かい、仕様を先に固める流れが主流になってきた。この変化は開発の表層ではなく、「誰が何を決める責任を持つか」という根の部分に触れている。
出典: 仕様駆動開発への期待と誤解 ～「仕様」とは、結局何なのか～
要点 (事実のみ)
- 2025年にAIエージェントへ曖昧な指示でコードを生成させる「Vibe Coding」の限界が顕在化し、2026年現在は要件を整理・分解してからAIに渡す手法が主流になっている
- 「仕様駆動開発」（Spec-driven Development）はその代表例で、要件定義書・機能設計書・実施計画書などのドキュメントを順に作成し、実施計画に従って実装に移るワークフローを指す
- 「Planモード」はClineのPlan/Actをはじめ多くのCoding Agentに実装されており、実装前に計画をユーザーに提示・承認してから実装に移ることで「実装したがるAI」にブレーキをかける機能として位置づけられる
- 仕様駆動開発は「仕様を実装のインプットとして後に手放すのか、仕様そのものを本質として扱うのか」によって意味合いが大きく変わり、その解釈の差がSNS上の論戦を生んでいる
- 著者の渡邉洋平氏はNTTテクノクロス株式会社に所属し、AWS CDK・Hono等のOSS活動やCoding Agentに関する活動を精力的に行っている
徐 聖博の見解
私が注目するのは、「仕様を書く」という行為がAIエージェント文脈で再評価されている点だ。これは決して新しい発明ではない。ウォーターフォールでもアジャイルでも、「何を作るかを言語化する」ステップは常に存在した。ただ、AIエージェントがコードを大量に生成できる環境では、その言語化の精度がアウトプットの品質に直結する度合いが桁違いに大きくなる。根拠はシンプルで、エージェントが曖昧さを補完する際に使う「文脈の補完ロジック」は必ずしも発注者の業務知識と一致しないからだ。
私自身がコーディングエージェントを実務に使う中で感じるのは、「仕様の粒度」の問題がいちばん難しいということだ。詳細すぎる仕様は更新コストが高く、抽象的すぎる仕様はエージェントが補完に失敗する。Planモードのような「承認ゲート」は、この粒度の問題を人間が介在することで吸収するアプローチだ。一方、仕様駆動開発が目指すのは、承認ゲートを事後ではなく前倒しに設けることで、実装のやり直しを構造的に減らすことだ。
受託開発を主軸に置く立場からも一言添えると、この議論が「ウォーターフォールへの先祖返りか」という論点を呼ぶのは理解できるが、本質的には違う。ウォーターフォールの問題は「仕様を書いたこと」ではなく「仕様が現実から乖離しても修正しなかったこと」にある。仕様をLiving Documentとして扱い、実装と双方向に更新し続けるなら、むしろアジャイルの精神と整合する。AIエージェント時代の「仕様」は、一度書いて終わりの成果物ではなく、エージェントとの対話を通じて継続的に精緻化される素材として捉えるほうが実態に近い。
(編集レンズ: 実装・運用視点 / AIを「作る側」の目線)
仕様の粒度をどう決めるか
見解として「粒度が難しい」と書いたが、実務では判断基準が要る。私が使っている線引きは単純で、エージェントが間違えたときに、その間違いを人間が見つけられるかである。
| 仕様に書く | 仕様に書かない |
|---|---|
| 入出力の形（型・必須項目・エラー時の振る舞い） | 変数名・関数分割の粒度 |
| 業務ルール（判定条件、例外、権限） | 実装アルゴリズムの選択 |
| 既存コードのどの層に載せるか | ライブラリの細かい使い方 |
| やらないこと（スコープ外の明示） | コメントの書き方 |
左側は、間違っていてもレビューで気づけない類のものだ。業務ルールの取り違えは、コードを読んでも「そう書いてある」としか分からない。だから先に書く。右側は間違っていてもコードを見れば分かるので、エージェントに任せてよい。
もう1つ実務的なコツは、「やらないこと」を書くことである。エージェントは指示されていない領域を善意で補完する。「今回は認証周りは触らない」「既存のAPIレスポンス形式は変えない」と明記するだけで、レビュー対象が大幅に減る。
チームに導入するときの順番
仕様駆動を個人の作業スタイルで終わらせず、チームの運用に載せる場合は、次の順で入れるのが失敗が少ない。
- プロジェクト設定ファイルに規約を書く。 コーディング規約・ディレクトリ構成・命名規則をエージェントが毎回読む場所に置く。これだけで生成物の手直し量が変わる
- 実装前の計画を1機能ずつ残す。 設計方針・影響範囲・テスト方針を書いてから着手する。ドキュメントは後から読む人のために残す
- レビュー単位を小さく保つルールを決める。 仕様を先に書いても、1回の指示で数百行出せば結局レビューが破綻する（AIがPRを壊す——ヘッドレスエージェント時代のSDLC再設計）
- セキュリティ要件を仕様に含める。 指示していない非機能要件は満たされない（バイブコーディングの「動く≠安全」問題）
実際にこの進め方で回している事例として、稼働を止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発では、1機能ごとの実装計画ドキュメントを162本積み上げ、担当者が入れ替わっても設計判断が引き継がれる状態を作っている。仕様を書くコストは、引き継ぎコストの前払いだと考えるとつじつまが合う。
よくある質問
Q. 仕様駆動開発はウォーターフォールへの先祖返りではないか。
A. 違う。ウォーターフォールの問題は仕様を書いたことではなく、仕様が現実から乖離しても更新しなかったことにある。仕様を実装と双方向に更新し続けるなら、アジャイルの精神と矛盾しない。
Q. どこまでドキュメントを書けばよいか。
A. 「間違いをレビューで見つけられない部分」だけでよい。全部書こうとすると更新が止まり、更新が止まった仕様は現実と乖離して害になる。
Q. コーディングエージェントの選定基準は。
A. 生成速度や無料枠ではなく、既存コードの規約を読ませられるか、レビュー可能な単位で止められるかで選ぶ。詳しくはコード生成AIの選び方と実務での使い方にまとめた。
