バイブコーディングをチームで使う前に決めるレビュー責任
最初の一人がAIに頼んで画面を作る。数分で動く。チームは沸く。ここまではいい。
問題は、そのあとだ。
同じ勢いで別の人もAIに頼む。似たような部品が増える。例外処理の書き方がばらつく。誰かがレビューしようとするが、そもそも何を正と見ればよいか分からない。コードは増えているのに、チームの理解は追いつかない。
バイブコーディングは、個人の試作ではかなり強い。だがチームで使うなら、先に決めるべきものがある。レビュー責任だ。
バイブコーディングと仕様駆動開発の違いは、速さではなく責任の置き場所
バイブコーディングと仕様駆動開発の違いは、「AIを使うかどうか」ではない。どちらもAIを使う。違うのは、AIが何を根拠に動くかだ。
バイブコーディングでは、会話の流れが根拠になりやすい。「この画面を作って」「ここを直して」「もう少し自然にして」という指示を重ね、動くものを見ながら進める。速い。特にプロトタイプや小さな社内ツールでは、手を動かす前の迷いをかなり減らせる。
仕様駆動開発では、先に判断基準を置く。目的、制約、受け入れ条件、やらないこと、レビュー観点を短くてもよいので書く。AIはその仕様を読んで実装し、人間は仕様に照らしてレビューする。
海外でも、Vibe Coding vs Spec-Driven Development や Spec-Driven Development vs Vibe Coding のように、速度と保守性 の違いとして整理されることが増えている。だが実務で効くのは、もう一段具体的な問いだ。
「この変更を誰が承認したら、チームとして正しいと言えるのか」
ここが空白のままだと、AIが速く書くほどレビューは重くなる。
レビューが壊れる3つのパターン
チームのバイブコーディングでレビューが詰まる理由は、コードの量だけではない。判断の根拠が残っていないからだ。
1. 作った人しか意図を説明できない
AIとの会話は、本人の頭の中では自然につながっている。だがレビューする人から見ると、途中の判断が抜け落ちている。
なぜこの状態管理にしたのか。なぜこのAPIを分けたのか。なぜこの例外だけ握りつぶしているのか。コードを読めば処理は追えるが、理由は読めない。
理由が読めない変更は、レビューで止まりやすい。差し戻しが増え、結局「一回説明して」となる。AIで実装時間を縮めても、説明時間で相殺される。
2. 正常系だけで合格してしまう
バイブコーディングは、見える動作を直すのが得意だ。ボタンが動かない、表示が崩れる、エラーが出る。こうした問題は会話で直しやすい。
一方で、業務システムで怖いのは見えにくい条件だ。
- 権限が違う人には見えてはいけない
- 既存データを壊してはいけない
- 二重送信してはいけない
- 外部連携の失敗時に勝手に確定してはいけない
これらは、画面を触っただけでは分からない。先に受け入れ条件と禁止条件を書いておかないと、レビューする人も見落とす。
3. レビュー担当者が「仕様の代理人」になってしまう
仕様がないままレビューを回すと、レビュー担当者が仕様をその場で作ることになる。
「この挙動でいいんだっけ」
「たぶん違う気がする」
「ここは業務的に危ないかも」
この状態はかなりつらい。レビューが品質保証ではなく、要件定義のやり直しになるからだ。InfoWorldの比較記事 でも、実際に本番ソフトウェアを出す場面ではレビューやガードレールが追いつくかが論点になる。レビューは最後の砦ではなく、先に置いた判断基準を確認する工程にした方がよい。
チームで使うなら、5つの責任を先に分ける
バイブコーディングを禁止する必要はない。むしろ、使える場面では使った方が速い。
ただし、チームで使うなら次の5つを先に分ける。
| 責任 | 決めること | AIに任せてよいこと |
|---|---|---|
| 目的責任 | 誰の何を解決するか | 目的文のたたき台 |
| 仕様責任 | 入力、出力、制約、例外 | 仕様案の整理 |
| 実装責任 | どの範囲を変更するか | コード生成、差分提案 |
| レビュー責任 | 何を見れば合格か | 抜け漏れ候補の指摘 |
| 承認責任 | 本番に出してよいか | リスク一覧の作成 |
この表があるだけで、会話が変わる。
「AIが書いたコードを誰が見るか」ではなく、「どの責任の確認を誰が持つか」に話が移る。実装者が全部を背負う必要はない。PMが目的責任を持ち、テックリードが仕様責任とレビュー責任を見る。事業責任者が承認責任を持つ。そう分ければ、AIは作業を速める道具として扱える。
IBMのバイブコーディング解説 でも、AI搭載の開発環境として反復的に進める見方が示されている。反復自体は悪くない。問題は、反復のたびに責任の所在が薄くなることだ。
SIer案件なら、この責任分界はさらに具体的に置いた方がいい。
- 顧客側の業務責任者: 目的、業務例外、受け入れ条件を承認する
- SIerのPM: スコープ、変更管理、顧客承認のタイミングを持つ
- SIerのPL/テックリード: 技術制約、影響範囲、レビュー観点を持つ
- 実装担当: AIへの入力、差分説明、テスト結果を残す
- 品質管理/ 受入担当: 禁止条件と受入テストの抜けを確認する
この分け方にすると、「AIが作ったからレビューして」ではなく、「顧客承認に出す前に、誰が何を確認したか」が残る。受託開発では、この証跡がかなり大きい。後から仕様変更が入ったときも、どの判断を変えたのかを追いやすい。
仕様駆動へ切り替えるタイミング
ずっと仕様駆動で進める必要はない。小さな検証なら、会話しながら作る方が速い場面も多い。
ただし、次のどれかに当てはまったら、バイブコーディングから仕様駆動へ切り替える合図だ。
- 2人以上が同じコードベースを触る
- 権限、金額、個人情報、外部送信が絡む
- 変更後も継続的に保守する
- テスト観点を口頭で説明しないと伝わらない
- レビューで「そもそも何をしたいのか」が出る
この状態で会話ベースのまま進めると、AIは作るが、チームは迷う。
切り替えるといっても、分厚い設計書を書く話ではない。最初は1ページで足りる。
- 目的: 誰のどんな作業を変えるか
- 範囲: 何を変え、何は変えないか
- 制約: 権限、データ、外部連携、性能
- 受け入れ条件: 何ができたら合格か
- 禁止条件: 起きたら止めること
- レビュー担当: 誰がどの観点を見るか
これをAIに渡す。AIが実装する。人間はこの6項目に照らして見る。これだけで、レビューの負荷はかなり下がる。
レビューは赤入れではなく、判断基準の照合にする
AIが書いたコードのレビューで一番よくないのは、「なんとなく不安だから全部読む」ことだ。全部読むのは大事だが、観点がないと消耗戦になる。
レビューは、次の順番にした方がいい。
- 目的に合っているか
- 範囲外の変更がないか
- 禁止条件に触れていないか
- 受け入れ条件をテストできるか
- 将来の変更理由が残っているか
コードの美しさはその後でいい。まず見るべきは、AIが勝手に判断していないかだ。
以前の バイブコーディングに設計書はどこまで必要か でも書いた通り、AI時代に残すべき設計書は、実装をなぞる資料ではない。判断の理由、制約、テスト観点だ。さらに バイブコーディングで作ったコードは誰がテストするのか の論点を合 わせると、レビュー責任とテスト責任は同じ根から出ている。どちらも「何を正とするか」が先にないと成立しない。
Atsumellの見方
バイブコーディングと仕様駆動開発の違いは、開発手法の流行語の違いではない。AIに作業を任せる前に、人間がどの判断を閉じるかの違いだ。
バイブコーディングは、試す速度を上げる。仕様駆動開発は、チームで直し続ける力を上げる。だから二者択一にしなくていい。最初はバイブコーディングで形を出し、チームで扱う段階に入ったら、仕様をAIが読める構造に変える。
Kakusillでやろうとしているのも、この切り替えを楽にすることだ。要件、制約、例外、受け入れ条件、レビュー観点を、AIにも人間にも渡せる形に整える。そうすれば、AIは速く書くだけでなく、チームの判断基準に沿って動ける。
チームでAI開発を進めるなら、最初に決めるべき問いはシンプルだ。
誰が、何を見て、合格と言うのか。
ここが決まると、バイブコーディングは危ない近道ではなくなる。仕様駆動開発へつながる、かなり使える入口になる。
最初の一手は小さくていい。次のPRから、目的、制約、受け入れ条件、禁止条件、レビュー担当を5行だけ添える。AIに実装させる前にこの5行を書く。レビューでは、 その5行と差分が一致しているかを見る。
これだけで、会話の勢いで増えたコードが、チームで扱える変更に変わる。
