仕様駆動開発（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を「作る側」の目線)
