元記事はまず、AI時代の開発スタイルの変化から話を始めます。
最近よく聞く vibe coding とは、ざっくり言うと「こんな感じでお願い」とAIに伝えて、出てきたコードを見ながら微調整していくやり方です。
たとえば、
という流れですね。
これは小さな試作ならかなり強いです。正直、**“とりあえず形にする” 速度はものすごく速い**。ここはAIのすごさを素直に感じるところです。
でも著者が指摘するように、これには弱点もあります。
たとえば、同じプロジェクト内で「MLモデルの学習をDBTパイプラインにどう組み込むか」が人やAIごとにバラバラになる、という例が出ています。
これはかなりリアルです。AIが優秀でも、ルールがなければ賢い混乱が起こるだけ、というのは本当にそうだと思います。
そこで登場するのが spec-driven development（SDD） です。
これは、いきなり実装に入るのではなく、先に spec（仕様） をきちんと書く開発手法です。
ここでのポイントは、仕様を「コードの前提」として扱うことです。
つまり、
を先に整理して、Markdown のような形でリポジトリに残します。
著者はこの考え方を、従来のソフトウェア開発にかなり近いものだと説明しています。
そして、SDD の良さは 仕様と実装を分ける ところにある、とまとめています。
これは地味に見えてかなり大事です。
AIにコードを書かせるとき、問題は「書けるか」ではなく「何を基準に書かせるか」だからです。
ここを先に決めると、AIの出力が一気に安定しやすい。これは実務でもかなり効く考え方ではないでしょうか。
元記事では、SDD の最初のステップを constitution（憲法） と呼んでいます。
ちょっと大げさに聞こえますが、要するに プロジェクトの基本ルール集 です。
ここには主に次のような文書が含まれます。
この考え方がいいのは、人間とAIの両方が同じ前提を見る ことができる点です。
AIの会話って、どうしてもその場しのぎになりがちですが、仕様書が残っていれば「前に何を合意したか」が見える。これが強い。
しかも著者は、SDD は新規プロジェクトだけでなく既存プロジェクトにも使えるとしています。
これは実用的です。理想論で終わらず、現場にそのまま持ち込める形になっているのがいいですね。
この記事の面白いところは、理屈だけで終わらず、著者自身が greenfield project（まっさらな新規プロジェクト）で試していることです。
作ったのは、Trainlytics という personal fitness tracking web app。
ランニングと筋トレを両立したい著者自身のニーズから生まれたアプリです。
ここはかなり共感しやすいです。
「世の中にツールはたくさんあるけど、自分にちょうどいいものがない」って、実は開発の一番自然な動機なんですよね。
そしてAIがある今は、その不満を自分で埋めに行ける。ここにAI時代の面白さがあると思います。
著者はまず新しい repository を作り、README.md に初期の product vision を書きました。
それから、AI に頼って constitution を作っていきます。
使った環境は Visual Studio Code + Claude Code plugin。
つまり、AIを別画面の“チャット相手”として扱うのではなく、エディタの中でコード変更を確認しながら進めるスタイルです。
これも実務っぽくていいです。
AIに丸投げするのではなく、エディタの中で変更を見て判断する。
この“見ながら進める”感覚が、vibe coding から一段上の開発っぽさを生んでいます。
著者はまず、AIに以下の3ファイルを作らせます。
mission.mdtech-stack.mdroadmap.mdその際、AIには AskUserQuestion tool を使って質問させ、プロジェクトの方向性を詰めさせています。
つまり、AIが勝手に決めるのではなく、不足情報を人間に確認しながら仕様を固める わけです。
ここ、かなり重要です。
AI開発というと「自動化」が注目されがちですが、本当に価値があるのは自動化そのものではなく、曖昧さを減らすことだと思います。
質問してくれるAIは、その意味でかなり実務的です。
著者はその後、できあがった仕様を自分で読み、必要なら修正し、さらに別の新しいAIセッションでレビューもさせます。
これはいわば 二重チェック です。
私ならここはかなり評価したいです。
AIは便利ですが、思い込みや抜け漏れも普通にあるので、別視点での再確認 は大事です。
しかも「反省・振り返りが出力品質を上げる」という考え方も紹介されていて、ただの作業記録ではなく、開発の知恵としてまとめられています。
constitution が固まったら、次は最初の feature phase に進みます。
このアプリでは、まず MVP（最小実用版） として「Core Activity Logging」を実装します。
この段階でできるようにするのは、ざっくり言うと次の通りです。
ここで大事なのは、いきなり全部を作らないことです。
SDD では、各 feature phase を
の流れで進めます。
つまり、
という、かなり王道の進め方です。
ただしこの王道を、AI時代に合わせてちゃんと再設計しているところが新しい。
著者が特に強調しているのが、feature を1つ作った後の replanning です。
普通なら「次いこう！」となりがちですが、ここで一度立ち止まって constitution や既存の計画を見直します。
これ、地味ですがかなり重要です。
AIを使うと作業速度が上がるぶん、間違った方向へ進む速度 も上がるからです。
だからこそ、途中で「今の方針で本当に合っているか」を確認する時間が必要になります。
個人的には、AI時代のプロジェクト管理で一番価値が出るのは、この 止まる力 ではないかと思います。
速く作るだけなら誰でもやりやすい。でも、速く作ってもズレていたら意味がない。
SDD はそのズレを減らすための仕組みとして、とても筋がいいです。
元記事が伝えているのは、単なる「AIでアプリを作ってみた」話ではありません。
むしろ本質は、
という点にあると思います。
つまり、これからの開発者は単に手を動かす人ではなく、
になっていく、ということです。
著者が好んで使う agentic engineering という言い方も、かなりしっくりきます。
AIに全部任せるのではなく、agent を指揮する。
この“指揮者”としての役割は、今後ますます重要になるはずです。
この記事を読んで感じたのは、spec-driven development は、AI時代の「ちゃんとした開発」を取り戻すための方法だということです。
vibe coding は速い。
でも速さだけでは、プロジェクトはだいたい壊れます。
その弱点を埋めるのが、仕様を先に作り、判断を残し、必要なら見直す SDD です。
個人的には、これはかなり本命の流れだと思います。
AIが強くなればなるほど、仕様の価値 は上がる。
そして仕様を書ける人、見直せる人、守れる人が、これからの開発で強くなるのではないでしょうか。
参考: From Vibe Coding to Spec-Driven Development | Towards Data Science