仕様駆動開発とは？AIにコードを書かせる前に決める3つの文書と、Claude Code・Kiro・Spec Kitでの進め方

先日、あるエンジニアの短い動画で「AIにコードを書かせる前に、誰が・何を使って・どのデータとつながるかを決める。決めずに始めると修正の沼にはまる」という話を見ました。業務アプリの相談を受けていると、まさにこの沼で止まっている会社によく出会います。

画面は1日でできたのに、使い始めて2週間たっても直し終わらない。直すたびに別の画面の数字がずれる。原因をたどると、最初に決めておくべきことをAIとの会話の中で少しずつ決めていて、どれが最新の決定なのか誰も分からなくなっています。仕様駆動開発は、この状態を避けるための進め方です。

仕様駆動開発とは、仕様の文書を正にしてAIに作らせる進め方

仕様駆動開発（Spec-Driven Development）は、作りたいものを会話で伝えながら形にするのではなく、先に仕様を文書に書き、AIにはその文書を読ませて実装させる進め方です。GitHubが公開しているSpec Kitも、AWSのKiroも、この考え方を前提にしています。

大事なのは、文書を書くことそのものより、文書が「正」になることです。使ってみて直したいところが出たら、AIに「ここをこう変えて」と会話で頼むのではなく、まず仕様の文書を直します。そのうえで、直した文書をもとにAIに作り直させます。こうすると、何が決まっていて何が変わったのかが、会話の履歴ではなく1つの文書に残ります。

AIにコードを書かせる前に書く3つの文書

ツールによって名前は違いますが、中身はほぼ共通で、要件・設計・作業手順の3つに分かれます。ここでは、社員10人ほどの不動産会社が「内見予約をスプレッドシートから専用の画面に移したい」という場面を例にします（例として作った場面で、特定の会社の事例ではありません）。

仕様駆動開発で書く3つの文書（要件・設計・作業手順）のうち、非エンジニアがつまずきやすいのは、データ同士のつながりを決める設計です。「予約のデータに顧客名を直接書く」のか「顧客のデータを別に持って、予約からはそれを指す」のかで、あとから顧客の電話番号を直したときに全部の予約を書き換えるかどうかが変わります。データ同士のつながりを図にしたものをER図と呼びますが、名前を覚える必要はありません。「1件の○○に、△△はいくつ付くか」を、データの組み合わせごとに1行ずつ書けば十分です。

要件の段階で決める項目と決定者の置き方は要件定義の進め方で、業務の書き出し方は業務棚卸しのやり方で詳しく書いています。

完成条件は「誰が見ても合否が分かる文」で書く

「使いやすい予約画面」では、AIも人も合否を判断できません。「営業がスマホで、物件名を2文字入れると候補が出る」「同じ時間に同じ担当者の予約を2件入れようとすると止まる」のように、試せば合否が分かる文にします。Kiroは要件を条件と結果で表すEARSという書式を使います。予約画面の完成条件を書くときも、書式より「試せる文になっているか」を先に確かめてください。

AI駆動開発・バイブコーディングとの違い

AI駆動開発は開発にAIを使う進め方全般を指す広い言葉です。仕様駆動開発は、その中で要件・設計・作業手順の文書を正にしてAIに作らせる進め方です。バイブコーディングは、AIとの会話を重ねて画面や処理を早く形にする作り方です。SalesDockでは、業務の聞き取りから運用後の改善まで、開発全体にAIを組み込んでいます。

SalesDockでは、業務を聞き取り、要件を決め、設計・実装・検証を経て実業務で試し、運用後に改善する流れにAIを使います。仕様駆動開発は、このうち要件を決めてから実業務で試すまでを支える進め方です。全体の流れはAI駆動開発の進め方で説明しています。

仕様駆動開発のツール：Claude Code・Kiro・Spec Kitの違い

仕様駆動開発に使える主なツールは、AWSのKiro、GitHubのSpec Kit、Claude Codeです。どれを使っても、書く文書（要件・設計・作業手順）の中身は変わりません。違うのは、文書の型と進める順番がツールにあらかじめ用意されているかどうかです。

Claude Codeで仕様駆動開発をするときの手順

Claude Codeには、KiroやSpec Kitのように仕様書の型と手順があらかじめ組み込まれてはいませんが、Markdownの文書と計画モード（Claudeがファイルを読んで計画を示し、承認するまで編集しないモード）を使えば、次の順で同じ進め方ができます。

1. 作業フォルダに、要件・設計・作業手順の3つのMarkdownファイルを置きます。最初は空でも構いません。
2. Claude Codeに「コードは書かずに、要件のファイルを埋めるために私に質問して」と頼み、答えながら要件を書き上げます。
3. 計画モードに切り替え、要件をもとに設計と作業手順の案を出させます。計画モードの間はファイルを変更しないので、案を読んで直すことに集中できます。
4. 作業手順を1つ選んで実装させ、終わったら要件の完成条件と照らします。
5. 直したいことが出たら、先に要件か設計のファイルを直し、「更新した設計に合わせて直して」と頼みます。

毎回守らせたいこと（使う言語や保存先など）はCLAUDE.mdに、作るもの1つごとの内容は3つの文書に、と分けておくと、別のツールを作るときに混ざりません。権限やデータの扱いなど、Claude Codeならではの注意点はClaude Codeで業務ツールを作るときの注意点にまとめています。

仕様駆動開発の理想と現実：向かない場面もある

仕様駆動開発は万能ではありません。ボタン1つの配置を試したいだけなのに3つの文書を書くと、作るより書くほうが長くなります。Spec KitやKiroが作る文書は細かく、小さな修正には重すぎると感じる人もいます。

もう1つの現実は、仕様の文書も古くなることです。会話でこっそり直した部分があると、文書と実際の動きがずれ、次にAIが文書を読んだときに古い仕様へ戻してしまいます。「直すときは文書から」を1度でも破ると効果が薄れます。

目安として、次のどれかに当てはまるなら仕様を先に書きます。当てはまらないなら、会話で作って試し、うまくいったものを残す段階で仕様を書き起こしても遅くありません。

• 自分以外に2人以上が使う。
• データを貯め続け、あとから集計や検索をする。
• ほかのシステムやスプレッドシートとデータをやりとりする。
• 顧客情報や金額を扱う。

作ったツールを社内で使い続ける段階の線引きはバイブコーディングで作ったツールの本番公開ラインが参考になります。

効果は「作り始めてから前提に戻った回数」で測る

仕様駆動開発の効果は、完成までの日数だけでは見えません。文書を書く分、最初の数日はむしろ遅く見えるからです。次の記録を、仕様なしで作ったときと比べます。

• 作り始めてから「そもそも誰が使うのか」「このデータはどこから来るのか」に戻った回数を数えます。
• AIへの修正依頼を「仕様の書き漏れ」「AIの読み違い」「使ってみて気が変わった」に分けて記録します。
• 作業手順1つごとに、完成条件をそのまま満たした割合を残します。
• 作ったあと、仕様書だけを読んだ別の人が、画面の動きを説明できるかを試します。

「使ってみて気が変わった」修正は、仕様駆動開発でもなくなりません。減らしたいのは「仕様の書き漏れ」と「AIの読み違い」のほうです。この2つが減っていれば、文書に書く項目が足りているということです。

来週の一歩：作りたいもの1つで、要件だけ書いてみる

いきなりツールを入れる必要はありません。作りたい業務アプリを1つ選び、A4 1枚に「誰が使うか」「何ができれば完成か」「どのデータを持ち、1件の○○に△△はいくつ付くか」を書いてみてください。書けないところが、AIに作らせたら修正の沼になるところです。そこは業務を知っている人と話して埋めます。

一次情報・公式情報

• GitHub「Spec Kit」
• Kiro Docs「Specs」
• Kiro Docs「Feature Specs」（EARS記法の要件）
• Claude Code Docs「Common workflows」（計画モード）

仕様駆動開発のよくある質問