バイブコーディングが壁にぶつかるとき
目次
この記事はAakash Kavuruによる AI-Driven Development: From Vibe Coding to Structured Methodologies についての考察です。元の記事も読む価値があります。
バイブコーディングは楽しい。やりたいことを説明して、AIが書いて、リリースする。最初の2週間は最高だ。でもコードベースが大きくなると、AIはコンテキストを読み違えはじめ、アウトプットと戦う時間のほうが実際に作る時間より長くなる。
これはAIの問題ではない。ドキュメント化をサボっていた問題で、AIがそれを楽にしすぎたせいで見えなかっただけだ。元の記事はこう言っている。AIドリブン開発でほぼすべての失敗の根本原因は「何を作るべきかが文書化されていないこと」だ、と。
バイブコーディングが最初うまくいく理由
バイブコーディングとは、仕様なし、計画なし、やりたいことを自然言語で説明してアウトプットを繰り返し改善していくことだ。全部が頭の中に収まっているから速い。
週末プロジェクトをイメージしてほしい。ファイル3つ、機能1つ、会話1つにコンテキストが全部入る。プロンプトして、コードをもらって、リリース。3日で終わり。
6ヶ月後を想像してみよう。ファイルが30個、コントリビューターが2人、要件が4回変わった。AIに機能を追加するよう頼むと技術的にはやってくれるが、別の何かがずれる。直すと、また別の何かがずれる。もうビルドしていない。ドリフトを追いかけている。AIが劣化したわけではない。問題はインテントが一度も文書化されなかったことで、コードベースが育つにつれアウトプットを正しい方向に引き止めるものが何もなかった。
どこで壊れるか
壊れ方には特徴的なパターンがある。コードは動く。テストも通る。でも挙動が説明しにくい形でおかしい。
例えば「通知機能を追加して」とプロンプトしたとする。自分のイメージは1日1回のメールダイジェストだ。AIはリアルタイムのプッシュ通知を実装する。どちらもそのプロンプトの正当な解釈だ。AIは間違っていない。プロンプトが曖昧だっただけだ。
小規模なら、AIの推測が当たることが多いので問題にならない。規模が大きくなると、外れるたびに誤差が積み重なる。元の記事はこれを「仕様からの実装ドリフト」と呼んでいる。もっとシンプルに言うと、何を作っているかを書き留めなかったから、AIが正しい方向を保てなかっただけだ。
SDD: プロンプトの前に何を作るかを書き留める
Spec-Driven Developmentは大げさなプロセスではない。ルールはひとつだけ。AIに指示を出す前に、その指示が何を生み出すべきかの最小限の仕様を書く。
50ページのドキュメントではない。1段落でいい。曖昧さをなくすだけの量があれば十分だ。
このプロンプトの代わりに:
ユーザー認証を追加して。
まずこの仕様を書いてから、プロンプトする:
機能: ユーザー認証
- メール + パスワードのみ（OAuthはまだ対応しない）
- パスワードはbcryptでハッシュ、最低8文字
- JWTトークン、有効期限7日
- 「ログイン状態を保持」は対応しない
- レート制限: 10分以内に5回失敗で15分ロックアウト
- スコープ外: ソーシャルログイン、2FA、アカウント回復
曖昧さがなくなったので、AIのアウトプットは格段に予測しやすくなる。さらに重要なのは、アウトプットを照合できるものができたことだ。
SDD を使うタイミング: MVPを超えたプロジェクト、または既存コードに触る機能すべて。
VSDD: アウトプットを仕様と照合する
Verified SDD はステップをひとつ加える。AIがコードを生成したあと、次に進む前に仕様と照合する。それだけだ。
ほとんどの人はこれをスキップする。コードを読んで、まあ良さそうだとコミットする。2週間後、仕様に書いたエッジケースが実装されていないことに気づく。AIが静かにスルーしていたのだ。
自動化しなくていい。シンプルなチェックリストで十分だ:
認証機能チェックリスト:
[x] メール + パスワードのみ
[x] bcryptハッシュ
[x] JWTの有効期限7日
[x] 「ログイン保持」なし
[ ] 5回でレート制限 <-- AIは10回に設定していた
[ ] 15分ロックアウト <-- 実装されていない
2項目が漏れていた。5分で気づける。本番インシデントになってから気づくよりずっといい。
チームや本番に出るものは自動化しよう。AIを走らせる前に仕様から直接テストを書く。仕様が「5回でレート制限」と言っているなら、その数字を確認するテストを書く。曖昧な統合テストでは、AIが別の値を静かに使っていても通ってしまう。
CoDD: 複数の仕様を一貫させる
Coherence-Driven Developmentは、複数の仕様が互いに依存する大きなシステムのためのものだ。ひとつを変えると、それに依存するすべてが更新を必要とする。
決済システムがわかりやすい例だ。「注文作成」の仕様は「決済処理」に依存し、それは「返金ポリシー」に依存する。返金期限が30日から14日に変わると、すべての下流の仕様にそれを反映する必要がある。
CoDD なしだと何が起きるか。返金ポリシーの仕様を更新してAIに実装させる。AIは正しく実装する。でも「注文作成」のフローはその仕様を更新していないから、まだ30日を参照している。システムの2つの部分が同じルールについて意見が食い違うことになる。
ソロプロジェクトにはやり過ぎだ。複数のエンジニア、複数のサービスがあり、コンポーネント間の微妙な不整合が3日かかるバグを生み出す規模になったら必要になる。
正直なところ
SDD、VSDD、CoDD は段階的な進化として提示されている。バイブコーディングが壊れてきたらSDDから始める。検証が必要になったらVSDDを加える。一貫性が問題になるほど大きくなったらCoDDを加える。
そのフレームは役に立つ。でもはっきり言おう。これらは全部新しいものではない。
良いチームはAIが存在するずっと前から、仕様を書き、実装を検証し、コンポーネント間の依存を管理していた。AIがしたのは、それを全部スキップしてもとりあえず何かをリリースできるようにしたことだ。しばらくの間は。そして負債がより速く、よりわかりにくい形で返ってきた。
元の記事の本当の貢献はメソドロジーの名前ではなく、この言い換えにある。「AIはコードを書く速度で人間を超えたが、インテントを定義することは依然として人間の仕事だ。」ソフトウェアが安くなるという前の記事で言った話と同じ変化を、別の角度から見たものだ。コストがコードを書くことから、何を書くべきかを知ることへ、そしてそれをAIが正しい方向を保てるほど明確に書き留めることへと移動した。
実際に何が変わるか
3つのワークフローを比較する:
AI以前: インテント定義 -> 実装 -> レビュー
バイブコーディング: 説明 -> AIが実装 -> リリース
SDD + VSDD: 仕様を書く -> AIが実装 -> 仕様と照合して検証
真ん中のステップが速くなった。最初と最後のステップがより重要になった。仕様に投資すればAIのアウトプットが予測可能になる。検証に投資すればドリフトが早期に捕まえられる。両方スキップすると、速いスタートと辛い中盤が待っている。
今複利で効くスキルはプロンプトの技術ではない。曖昧さを取り除きながらも過剰に作りすぎない、明確で最小限の仕様を書く能力だ。それは文章力であり、同時に思考力でもある。理解していないものの明確な仕様は書けない。
まとめ
バイブコーディングは良いスタート地点だ。でも続けていい状態ではない。
AIでうまくやるチームは、最もクリエイティブにプロンプトするチームではない。AIに作るよう頼む前に、何を作りたいかを書き留める習慣を持ったチームだ。
出典: AI-Driven Development: From Vibe Coding to Structured Methodologies Aakash Kavuru著、Qiita。