Spec-driven development guide for vibe coding beginners

要件定義仕様駆動開発の入門ガイド

思いつきを、
仕様変える。

AIに日本語で頼んでアプリを作るとき、最初に必要なのはコードより「何を作るか」を言葉にすることです。ズレを見つけ、直し、完成へ近づける道筋を、一般的な型と架空の例でたどります。

思いつき要件仕様計画動くもの人の判断
ズレの正体

頭の中の完成像は、そのままではAIに伝わりません。

思いつきを短いお願いだけで渡すと、AIは受け取った言葉の範囲で形にします。目の前の出力と自分の認識を比べて、初めて言葉にできる違いがあります。

バイブコーディングでは、最初から完璧な指示を作る必要はありません。まず出してもらい、触って、気づいたズレを返します。

大切なのは、ズレを「失敗」で終わらせないことです。ズレを見つける→言葉にする→直してもらう。この往復が、完成像を少しずつ共有する時間になります。

出てきたものが違う。
だから、次に伝えることが分かる。
左に頭の中の完成像、右にAIの出力があり、間のズレを発見して言葉にし、修正する流れを示す対比図です。
完成像と出力の間にあるズレが、次の指示の材料になります。
要件定義

最初に決めるのは「何を作るか」と「何を作らないか」です。

要件定義は、作りたいものの輪郭を先に言葉にすることです。最初に埋めるのは、4つの枠だけで構いません。

やりたいこと、使う場面、完成の条件、やらないことの4枠を並べた要件ボードです。
「やらないこと」も立派な要件です。4枠を並べると、作る範囲と止める範囲が同時に見えます。

やりたいことは、機能名ではなく「誰が・いつ・どうなったら嬉しいか」1〜3行の物語にします。

使う場面は、端末や人数など、実際に使う状況です。完成の条件は、できたかどうかを判断する合格ラインです。

やらないことは、作りたいものが膨らむのを防ぐ柵です。後から足せることでも、今回は入れないと決められます。

ひとことで言うと
要件定義 = 作る範囲と、完成の判断基準を先にそろえること。
4枠の書き方

機能名でなく、場面と合格ラインを書きます。

例えば、架空の教材として「買い物リストアプリ」考えます。機能名だけでなく、使う場面と、完成したか確かめる条件まで言葉にします。

やりたいことは、アプリ名や機能名だけで終わらせず、使う人・場面・得たい変化を入れます。これだけで「何のための機能か」が見えます。

惜しい例

買い物リストアプリを作る。

良い例

買い物の前にリストを作り、店でチェックして、買い忘れをなくす。

使う場面は、「買い物の前に家で作り、店でスマートフォンから見る」のように、いつ・どこで・どう使うかを書きます。

完成の条件は、あとで確かめられる形にします。例えば「品を足せる・消せる・画面を閉じても残る」と書けば、できたかを判断できます。

やらないことには、今回は広げない範囲を書きます。例えば「家族との共有」と「値段の記録」を外せば、作る範囲がぶれません。

買い物リストアプリを作るという惜しい例と、買い物の前にリストを作り店でチェックするという良い例を比べ、使う場面、完成の条件、やらないことの記入例を添えた図です。
買い物リストは架空の教材例です。4枠の主役は、場面・完成の条件やらないことを、あとで確かめられる形にすることです。
仕様駆動開発

仕様が先、コードが後。作る途中も仕様に戻ります。

仕様駆動開発は、先に決めた仕様を地図にして進める作り方です。決める・計画する・作るだけでなく、AIの確認と人の確認を分けます。

決める、計画、作る、AIの確認、人の確認、完成の判断、記録の7地点が続き、AIの確認と人の確認の間を往復する地図です。
7つの通過点。④の機械的な確認と⑤の人の感覚による確認は、役割が違うため分けて往復します。

作る係のAIには、仕様をもとに計画を出してもらい、その順番で形にしてもらいます。壊れていないかの確認も、AIに繰り返してもらいます。

ただし、確認項目を全部通っても「良いアプリ」になったとは限りません。使いやすいか、目的を満たしたかは、人が触って判断します。

つまり仕様は、最初に一度書いて終わる文書ではありません。作る途中でズレたとき、戻る場所です。

AIは壊れていないかを見る。
人は作りたかったものかを見る。
要素分解

作りたいことを、機能へ。機能を、画面とデータへ分けます。

大きな思いつきのままでは、何から作るか決めにくいものです。まず「できること」に分け、さらに画面に見える部品と、裏側で持つデータへ下ろします。

例えば買い物リストなら、目的は「買い忘れをなくす」です。そこから「品を足す」「チェックで消す」「次回も残る」という、利用する人ができる機能へ分けます。

さらに機能を、入力欄・一覧・チェックなどの画面に見えるものと、品目・チェック状態などの裏側で覚えるものへ分けます。

  • 機能 — 利用する人が「できること」
  • 画面・部品 — 見るもの、押すもの、入力するもの
  • データ・状態 — 裏側で覚える内容と、いまの動き
買い忘れをなくすという目的から、品を足す、チェックで消す、次回も残るという機能へ進み、画面に見えるものと裏側で覚えるものへ枝分かれする分解図です。
目的から機能へ、機能から「画面に見えるもの」「裏側で覚えるもの」へ分けると、作る要素が見えてきます。
作業分解

作業は「土台→つなぐ→仕上げ」の3段に分けます。

要素が見えたら、次は作る順番です。機能を細切れに並べるだけでなく、各段の終わりに「ここまで動く」を確かめる節目を置きます。

土台はまず骨組みが動く、つなぐは部品どうしを結ぶ、仕上げは確かめて届けるという3段の階段と、動いたと示す旗がある作業分解図です。
土台→つなぐ→仕上げの順に進み、各段の終わりで「ここまで動く」を確かめます。

土台は、まず骨組みが動く段です。買い物リストなら、「品を足して一覧に出る」までを確かめます。

つなぐは、部品どうしを結ぶ段です。買い物リストなら、「チェックすると表示と状態が変わる」までを確かめます。

仕上げは、自動の確認と公開の準備を整える段です。買い物リストなら、「閉じても残るか確かめ、公開を準備する」までを扱います。

一気に完成させない。
動く節目を、順に越える。
計画と承認

最後の節目は、人が決めます。

計画は、仕様を作業へ並べ替えた道順です。AIに案を出してもらい、依存する順番と動作確認の節目を、人が確かめます。

4枠の要件が、そのまま作業の一覧になるわけではありません。仕様をもとに、先に必要な土台から、後で結ぶ機能、最後の確認へと、依存する順に並べ直します。

各フェーズの終わりには、そこまでの動作を確かめる節目を置きます。途中でズレが見つかったら、次へ進む前に仕様や計画へ戻ります。

自動の確認まではAIに任せられても、公開や本番反映は外へ影響します。そこには、人の承認を待つゲートを置きます。

仕様から土台、つなぐ、仕上げの3つの箱へ作業を並べ、最後に公開は人の承認を待つという門へ進む図です。
計画は依存する順に並べ、各段の終わりで動作を確認します。公開と本番反映は、人の承認を待ちます。
持ち帰りテンプレート

まず4枠を埋めれば、あなたの仕様づくりが始まります。

文章をきれいにする必要はありません。思いついた言葉のまま書き、動くものを見た後で直してください。

やりたいこと、使う場面、完成の条件、やらないことを書き込める4つの空欄を備えたワークシートです。
作業会の仕様ワークで、そのまま使える空の4枠です。印刷した場合は、点線部分へ書き込めます。

最初は、4枠すべてに自信がなくても構いません。分からない場所が見えたら、それもAIへ質問する材料になります。

書いた後は、まず動くものを見せてもらいます。そして「思っていたのと違う」と感じた場所を、ひとつずつ返します。

  • やりたいことを、使う人の短い物語で書く
  • 完成したか判断できる条件を置く
  • 今回はやらないことを宣言する
  • 動くものと比べ、ズレた言葉を書き直す
このガイドの到着点 完璧な仕様書ではなく、アイデアが動き出し、完成までの道筋が見えることです。