Vibe-to-Spec開発_実践ガイド

Transcript

1. Vibe-to-Spec 開発 バイブで仕様書を育て、SDDで作る 試作から仕様を蒸留し、仕様書だけでAIに作らせる開発手法 バイブ段階 仕様蒸留（逆仕様化） 関門 SDD段階 Human-in-the-loop
2. Vibe-to-Spec 開発とは：バイブで育て、SDDで作る 1. 考え方 バイブで仕様書を育てる 本番はSDDで作る 判断は人が AIに素早く試作させ、仕様を見つけ る道具にする。試作コードは捨てる 前提 固まった仕様書だけを渡す。書かれ ていない事は作らせない AIが判断できない事だけを人に確認 させる（Human-in-the-loop） 試作から仕様を蒸留し、試作は捨てる Vibe-to-Spec 開発 実践ガイド 2
3. 仕様書は7項目を箇条書きで書く 2. 仕様書 項目 書くこと 例：社内勉強会の出欠管理 背景 なぜ今必要か。現状の困りごと 出欠をメールで集めていて、集計に毎回30分かかる 目的 何を良くしたいか 集計を自動にして、幹事の手間をなくす やりたい事 機能・振る舞いを箇条書き 名前を入れて参加／不参加を押す。一覧と人数を表示 やらない事 スコープ外をはっきり書く ログイン機能、メール通知は作らない 制約 使ってよい技術・守るルール 外部サービスなし。本物の個人情報は使わない 出力 作るもの・形式・置き場所 1ファイルのHTML＋JavaScript。CSVで書き出せる ゴール 何をもって完成か（確かめられる形で） 10人分を登録し、表示人数とCSVの行数が一致する 要 ゴールは確かめられる形で。「やらない事」と「制約」が、本番で書かれていない事を作らせない歯止めになる Vibe-to-Spec 開発 実践ガイド 3
4. 全体像：バイブ段階 → 関門 → SDD段階 3. 全体像 STAGE 2 SDD段階： 仕様書から作る STAGE 1 バイブ段階：仕様書を育てる 仕様書を書く バイブで試作 7項目の骨子（人＋LLM） AIに素早く作らせる 関門 計画・タスク 繰り返す 【追加】 【推測】を 全て仕分け 仕様書をupdate 仕様蒸留 要確認 0件 印を仕分けて仕様書に反映 試作から仕様書を書き起こす 仕様書から作り方を決める 本番実装 仕様書と計画だけで作る 最終確認 蒸留して【追加】0 Human-in-the-loop：AIが判断できない事は人に確認させる バイブ段階で 関門で SDD段階で 【追加】【推測】の採用／不採用を答える 仕様書が固まったかを判定する 計画と仕様の穴に答え、完成を判定 Vibe-to-Spec 開発 実践ガイド 4
5. 試作から仕様書をMarkdownに蒸留する 4. バイブ段階 ｜ ③ 仕様蒸留 プロンプト例 添付の試作コードを読んで、仕様書 をMarkdownで書き出して。 ・仕様書と同じ7項目で書く ・コードから読み取れた事実だけを 書く ・推測した所には【推測】 ・元の仕様書にない振る舞いには【 追加】と付ける 出力されたMarkdown # 出欠管理アプリ 仕様書（蒸留・抜粋） ## 目的 - 出欠集計の自動化 ## やりたい事 - 名前入力＋参加／不参加ボタン - 一覧と参加人数を表示 - 【追加】同じ名前でも2行登録される - 【推測】再読み込みでデータが消える ## やらない事 - 【推測】記述なし（ログイン機能もない） ## 出力 - index.html（1ファイル） ## ゴール - 【推測】コード上に完成条件の記述なし 得られるもの 試作の中身が見える コードを読まずに分かる 暗黙の仕様が分かる AIが決めた事が【追加】に 仕様書の候補になる 印の行を仕分けて反映 要 試作は捨てる。残すのは仕様書だけ。【追加】【推測】の行が、仕様書へ足す項目の候補になる Vibe-to-Spec 開発 実践ガイド 5
6. 【追加】【推測】はいつ具体的な仕様になるか 4. バイブ段階 ｜ ③→④ ③ 仕様蒸留 ④ update 人が回答 仕様書 v2 印が付く 「要確認」の質問になる Human-in-the-loop 印を外して具体化 【追加】同じ名前でも2行登録され る Q 同じ名前の二重登録を許す？ 上書きにする やりたい事：同じ名前は上書き ゴール：同名2回でも1行 【推測】再読み込みでデータが消 える Q データを残す必要は？ 締切日まで残す やりたい事：回答をブラウザ保存 ゴール：再読込後も人数が同じ 【推測】やらない事の記述なし Q 作らない機能は？ ログインとメール通 知 やらない事：ログイン・通知 タイミング 印は、その周の④で必ず質問にし、人の回答を「やりたい事」「やらない事」「ゴール」に書く。人が決めるまでは 印のまま残す。全ての印を仕分け終えたら、関門へ進む。 Vibe-to-Spec 開発 実践ガイド 6
7. 足りない項目を渡して、仕様書を育てる 4. バイブ段階 ｜ ④ 仕様書のupdate 現行の仕様書 v1 蒸留した仕様書 ③の結果 足りない項目 テキストの箇条書き 更新版の仕様書（v2） 変更箇所に【変更】の印 LLM 仕様書を更新 変更点の一覧 何をなぜ変えたか 要確認リスト → 人へ AIが決められない事を質問に プロンプト例 仕様書と、足りない項目の箇条書きを渡します。足りない項目を反映して仕様書を更新して。 ・形式は7項目のまま。変えた所には【変更】と付け、最後に変更点の一覧を出す ・決められない事は勝手に決めず、「要確認」として質問の形で書き出す Vibe-to-Spec 開発 実践ガイド 7
8. 関門を越えたら、試作を捨てて仕様書から作る 5. 関門とSDD段階 関門のチェックリスト SDD段階のルール ✓ 【追加】を全て「採用」か「捨てる」に仕分けた 1 試作コードは渡さない 仕様書と計画だけで作る ✓ 【推測】が全て人の回答で埋まった 2 書かれていない事は作らない 画面・入出力・データ ✓ 要確認リストが0件 3 作り方は計画に従う 細部は「制約」の範囲で ✓ ゴールがテストで確かめられる形になっている 4 穴を見つけたら止まる 推測で埋めず「要確認」で聞く プロンプト例 この仕様書と計画・タスクだけを正として実装して。書かれていない画面・入出力・データの振る舞いは作らない。 仕様の穴を見つけたら推測で埋めず、実装を止めて質問して。最後にゴールのテストを書いて全て通すこと。 Vibe-to-Spec 開発 実践ガイド 8
9. 育てた仕様書から、計画とタスクを作る 5. 関門とSDD段階 ｜ ⑤ 計画・タスク 7項目の振り分け 仕様 プロンプト例 何を・なぜ spec.md ／ requirements 背景 目的 やりたい事 やらない事 → AIが作り方を考える前に、作る物を固定する 計画の入力 制約 どう作るか plan.md ／ design 出力 Spec Kit specify → plan → tasks ゴール この仕様書から、計画とタスクを作って。 【計画】 ・構成、データの持ち方、使う技術を決める ・「制約」を越える選択はしない 【タスク】 ・1つ30分以内で終わる大きさに分ける ・各タスクに根拠を書く（例：やりたい事-2、ゴール-1 ） ・仕様書に根拠のないタスクは作らない ・作り方で迷う所は「要確認」で出す ＋ 人が確認したバイブ段階の学び Kiro 要件→設計→タスク ポイント タスクに根拠を書かせると、根拠のないタスクを実装前に弾ける。計画の材料は仕様書と、人が確認した学びだけ。試 作の構造は持ち込まない。 Vibe-to-Spec 開発 実践ガイド 9
10. AIが判断できない事は、人が決める 6. Human-in-the-loop AIに任せる 人が決める • 試作・本番のコードを書く • 目的・優先順位・やらない事 • 試作から仕様書を蒸留する • 【追加】【推測】の採用／不採用 • 仕様の抜け・矛盾を指摘する • 個人情報・セキュリティ・お金の判断 • テストを書いて動かす • 関門の通過と、完成の最終判定 確認の流れ AIが「要確認」を質問で出 す Vibe-to-Spec 開発 実践ガイド 人が答える 答えを仕様書に書き戻す 10
11. 仕様書が育ち、関門を越えるまで（例：出欠管理アプリ） 6. Human-in-the-loop ｜ 例 最初の仕様書 蒸留で発見 関門を通過 仕様書に足したこと 仕様書に足したこと 仕様書に足したこと 名前を入れて参加／不参加 一覧と人数を表示 同じ名前の二重登録の扱い 締切後は変更できない やらない事：ログイン CSV出力（Shift_JIS） 人が決めたこと 人が決めたこと 人が決めたこと 対象は社内メンバーだけ 二重登録は上書きでよい 仕様が固まったと判定 SDD段階へ v3の仕様書から計画・タスクを作り、本番を作り直す。試作コードは捨てる Vibe-to-Spec 開発 実践ガイド 11
12. うまく回すための6つのコツ 7. 運用のコツ ゴールはテスト可能に 「速い」ではなく「1秒以内に表示」 。AIが自分で完成を判定できる 試作は捨てる 試作コードを本番に流用しない。良い 所は仕様書に蒸留済み Vibe-to-Spec 開発 実践ガイド 1周は小さく 1回の更新で足す項目は3〜5個まで。 人が差分を読める大きさにする 推測は推測と書かせる 【推測】【要確認】の印で、人が見る べき所を絞り込む 仕様書はGitで版管理 仕様の差分＝判断の記録。更新はPRに して人が確認する リリース後も仕様書から 運用中の変更も、仕様書を直してから SDD段階で作る 12
13. 疑問タイム 7. 運用のコツ ｜ Vibe-to-Spec 開発 みんなの疑問タイム まず自分ならどう答えるか予想 → クリックで答えを表示 うまく動いた試作を捨てるのは、もったいなくない ？ Q A もったいなくない。価値は仕様書に移してある Q 人はどこまで見ればいい？全部読むのは無理… A 全部は読まない。仕様書の差分と「要確認」だ け見る • 試作の良い所は、蒸留で仕様書に残っている • コードより先に、仕様書の変更点を読む • 仕様書だけで作れるかが、仕様書の完成テスト • 【推測】【要確認】の印の所に答える • AIなら作り直しは速い • 関門と完成の判定だけは必ず人がする Vibe-to-Spec 開発 実践ガイド 13
14. Vibe-to-Spec 開発はSDDか？ 一般的なSDDとの比較 8. 位置づけ 観点 一般的なSDD（Spec Kit・Kiro） Vibe-to-Spec 開発 判定 仕様を先に書く 仕様 → 計画 → タスク → 実装 本番は、固まった仕様書から実装する 同じ 正本 仕様書 仕様書。試作コードは捨てる 同じ 仕様にない実装 作らせない 本番では作らせない（試作では発見に使う） 同じ どう作るか 計画・タスクで固める 育てた仕様書から計画・タスクを作る 同じ 仕様の作り方 人が最初に書き上げる バイブの試作から蒸留して育てる 独自 結論 SDDであり続ける条件 SDDそのもの。前段に「仕様を育てるバイブ段 階」を足した形 試作コードを本番に流用しない。本番は仕様書だけ で作る Vibe-to-Spec 開発 実践ガイド 14
15. バイブで育て、SDDで作る まとめ バイブで仕様書を育てる 試作 → 蒸留 → updateを繰り返し、7項目の仕様書を育てる 関門を越えたらSDDで作る 試作は捨て、仕様書 → 計画・タスク → 実装。書かれていない事は作らせな い 判断は人が 印の仕分け、関門の通過、完成の判定は人が決める Vibe-to-Spec 開発 実践ガイド 15