バイブコーディングの特徴と「コケて直す」ループ

Transcript

1. バイブコーディングの特徴と 「コケて直す」ループ エラーが出るたびにAIへ「対策して」と頼む進め方と、本番に向け て仕様書から作るSDDへの切り替え ループ
2. バイブコーディングの4つの特徴 1. バイブコーディング 要 自然な言葉で頼む 結果で判断する 設計書なしで「〇〇を作って」と やりたいことを伝える コードは細かく読まず、 動かした画面や出力を見て決める 対話で小刻みに直す うまくいく道が先にできる 「ここを直して」を何度も重ねて 少しずつ形にしていく 想定外への備え（エラー処理）は 頼まない限り後回しになりがち 速く動く形にできる反面、「想定外のとき」の備えは、コケてから足していくことになる バイブコーディングの特徴と「コケて直す」ループ 2
3. エラー処理がないと、想定外の入力でコケる 1. バイブコーディング 最初にAIが書くコード 現実のデータで起きること 「sales.csv を読んで、金額の合計を出して」 × import csv rows = csv.reader(open("sales.csv")) total = sum(int(r[2]) for r in rows) print("合計:", total) うまくいく前提だけで書かれ、失敗時の分岐がない 要 × × ファイル名が違う・置き場所が違う → FileNotFoundError で停止 Excel保存で文字コードがShift_JIS → UnicodeDecodeError で停止 1行目に「金額」という見出しがある → ValueError で停止 想定外のことは、人が言わない限りAIにも分からない バイブコーディングの特徴と「コケて直す」ループ 3
4. 「コケて直す」を繰り返して、動くコードに育てる 1. バイブコーディング 人の役割 AIがコードを書く • エラーに気づき、メッセージをAIに渡す • 直ったか、動かして確かめる 人が「対策して」 と指示 動かしてみる AIの役割 • エラーから原因を推測する コケる（エラー） • エラー処理を足して、コードを直す ✓ エラーが出なくなったら完成 バイブコーディングの特徴と「コケて直す」ループ 4
5. ループの実例：CSV集計が動くまで 1. バイブコーディング 1回目 2回目 3回目 コケる コケる コケる FileNotFoundError UnicodeDecodeError ValueError: '金額' 人の指示 人の指示 人の指示 「ファイルが無いときは、 分かるメッセージを出して 終了して」 「Excelで保存した Shift_JISのCSVも読めるよ うにして」 「見出し行と、数字でない 行は飛ばして件数を表示し て」 4回目 エラーなし 合計: 1,284,500 （スキップ 2行） AIの修正 AIの修正 AIの修正 存在チェックを追加 文字コード指定を追加 見出し・不正行をスキップ バイブコーディングの特徴と「コケて直す」ループ 動くコードの完成 5
6. このループの強みと落とし穴 1. バイブコーディング 強み ＋ ＋ ＋ 落とし穴 速い 動くものが数分〜数十分で手に入る 無駄がない 実際に起きたエラーだけを直す コードが読めなくても進む エラーを渡して頼めば前に進める － － － 直るのは「起きたエラー」だけ まだ起きていない想定外は残る エラーを握りつぶす修正 エラーは消えるが、誤った結果が静かに出る 継ぎはぎで収束しない 直すと別の場所が壊れ、ループが終わらない 「エラーが出ない」と「正しく動いている」は別物 バイブコーディングの特徴と「コケて直す」ループ 6
7. ループを短く・安全に回す5つのコツ 1. バイブコーディング 最初に失敗を挙げさせる エラーは全文を貼る 握りつぶしを禁止する 「起こりそうな失敗と対策も 入れて」と最初の指示に添える 「動きません」ではなく、 メッセージをそのまま渡す 「原因と対処が分かる メッセージを出して」と頼む 直したらテストを1つ残す 3往復で収束しなければ止まる 約束はSKILL.mdに書く 同じエラーを再現する 小さなテストで再発を防ぐ 継ぎはぎをやめ、分かったことを 伝えて作り直してもらう 毎回言わなくても守らせる （本番化するならSDDへ） バイブコーディングの特徴と「コケて直す」ループ 7
8. 仕様駆動開発（SDD）とは：コードの前に仕様を書く 2. 仕様駆動開発（SDD） 仕様 Specify 計画 Plan タスク Tasks 実装 Implement 何を・なぜ作るか どう作るか（技術） 小さな作業に分解 タスク順に作り、 仕様と照らして確認 各段階の間で、人が確認してから次へ進む どんな手法か 仕様書に書くこと • 仕様書を唯一の正本（よりどころ）にする • 誰が・何をできるか • 仕様にないことはAIに作らせない • どうなれば完成か（受け入れ条件） • 曖昧な点は推測させず、質問させる • 失敗したとき、どう振る舞うか • 代表的な道具：GitHub Spec Kit、Kiro • 技術の話は後回し（計画の段階で決める） バイブコーディングの特徴と「コケて直す」ループ 8
9. エラー処理を「後から足す」か「先に仕様に書く」か 2. 仕様駆動開発（SDD） バイブコーディング コケてから足す FileNotFoundError → 対策して UnicodeDecodeError → 対策して ValueError → 対策して 3往復してやっと動く。 直っているのは「起きたエラー」だけ 勧 仕様駆動開発（SDD） 先に仕様に書く ## 受け入れ条件（spec.md） - 金額列を合計して表示する - ファイルが無ければ、理由を出して終了 - Shift_JIS / UTF-8 のどちらも読める - 見出し・不正な行は飛ばし、件数を表示 - エラーを握りつぶさない 最初からエラー処理込みで実装し、 条件ごとにテストも書く おすすめ：ループで見つけた想定外は、仕様書の受け入れ条件に書き戻す バイブコーディングの特徴と「コケて直す」ループ 9
10. 結論：仕様書をちゃんと書いて、SDDで作る まとめ 本番で使うものは、仕様書をちゃんと書いてSDDで作る バイブの「コケて直す」ループは試作まで。動く ≠ 正しい バイブで見つける 仕様書に書く SDDで作る 試作で「何が必要か」 「どこでコケるか」を早く知る 受け入れ条件と、失敗時の 振る舞いを仕様書に書き起こす 仕様を正本に、計画→タスク→ 実装。ずれたら先に仕様を直す バイブコーディングの特徴と「コケて直す」ループ 10