仕様駆動開発への期待と誤解
～「仕様」とは、結局何なのか～

はじめに

　2025年、AIエージェントにコードを書かせる開発スタイルが急速に広まりました。しかし、曖昧な指示から雰囲気でコードを生成する「Vibe Coding」には限界があり、意図と生成物の間にギャップが積み重なる問題が顕在化しました。この反省から、要件を整理しタスクに分解してからAIに渡すアプローチが定着し、2026年現在ではこちらが主流の開発手法となっています。「仕様駆動開発」（Spec-driven Development）はその代表例です。

　仕様駆動開発という用語は広く受け入れられつつありますが、言葉が指す範囲の広さゆえに、思い描く前提が人によって異なります。仕様を実装のインプットとした後に手放すのか、あるいは仕様そのものを本質として扱うのか。言葉の受け取り方によって、仕様駆動開発の意味合いは大きく変わります。本記事では、仕様駆動開発における3つの疑問を軸に違いを整理し、仕様駆動開発が何をもたらし、その先に何が来るのかを考えていきます。

「実装のブレーキ」を担うPlanモード

　仕様駆動開発は、要件や設計を仕様（Spec）ファイルとして記録するステップを挟むワークフローです。要件定義書や機能設計書、実施計画書などのドキュメントを順に作成し、実施計画に従って実装に移ります。この一連の流れは、従来のソフトウェア開発プロセスと比べても自然な形に感じられ、Coding Agentユーザーに広く受け入れられつつあります。

　その反面、仕様駆動開発という用語の重みや言葉が指す範囲の広さから、期待が過度に膨らむこともあります。議論の前提となるスコープが人によって異なり、SNSなどで論戦になっているのも散見されます。

　仕様駆動開発と似たアプローチに「Planモード」があります。両者ともVibe Codingを乗り越えるための手法ですが、アプローチが異なります。Planモードは、実装前に人間の意図を明確にし、実装したがるAIエージェントに「まず考えさせる」ための、さながらブレーキとも言える機能です。実装に入る前に必要な情報を収集し、立てた計画をユーザーに提示し、承認を得てから実装に移るよう促します。ClineのPlan/Actをはじめ、多くのCoding Agentに実装されている機能です。

　仕様駆動開発もPlanモード同様にユーザーの希望を加味しながら実装のイメージをすり合わせていくプロセスであり、承認ゲートとして機能するのは、Vibe Codingの欠点を補うためのものでした。