バイブコーディングで作ったコードは誰がテストするのか — AI生成コードの品質保証を考える
コードが速く書ける時代に、テストだけが残された
バイブコーディングの普及で、エンジニアがコードを書く速度は確かに上がった。実装そのものに費やす時間は短くなり、プロトタイプを数時間で作れるようになった。
しかし、あるジレンマが生じている。
コードは速く生成できるのに、 そのコードが「正しく動くか」を確認する作業は、依然として人間に依存している。
いや、正確に言えば「依存しがち」だ。AIに任せようにも、「何をもって正しいか」の基準が曖昧なままでは、テストを書くことも自動化することもできない。
AIが書いたコードのテスト、誰が書くか問題
バイブコーディングで実装を進めると、多くの場合こんな状況になる。
- AIがコードを生成する
- 動かしてみると「なんとなく動く」
- テストはあとで書こう、という判断になる
- 機能が増えると「あとで書く」コストが増大する
- 結果としてテストなしで本番に出る
これはAIのせいではない。テストを書くための「仕様」が存在しないことが問題なのだ。
TDD（テスト駆動開発）の文脈では、テストは実装の検証ではなく「仕様の表現」だとされる。「この関数は、この入力に対してこの出力を返す」という合意があってはじめて、テストは書ける。
バイブコーディングは実装を速くするが、その前工程にある「何を作るか」の合意を省略しがちだ。結果として、テストを書く根拠が消える。
AI生成コードのテストにある3つの課題
1. 意図が読めない
人間が書いたコードには、変数名やコメントに意図が滲む。しかしAIが生成したコードは、見た目は整っていても、なぜその実装になったかが不明なことが多い。テストを書こうとして「これ、何をチェックすればいいんだっけ」となる。
2. エッジケースが隠れる
AIはパターンから最適解を生成する。だから「よくあるケース」には強い。しかし、業務固有のエッジケース（「この取引だけ手数料が異なる」「このユーザーだけ権限が違う」）は、プロンプトに明示しなければ見落とされる。
テストでこれを後から発見するのは、デバッグの仕事になってしまう。
3. テスト自体もAI任せにするとループする
「テストもAIに書かせればいい」という発想は合理的だ。しかし、仕様が不明確なままAIにテストを書かせると、実装に合わせたテストが生成される。実装が間違っていれば、テストも間違って通る。これは「グリーンになるだけのテスト」であり、品質保証にならない。
仕様が先にあれば、AIはテストも正確に書ける
ここで仕様駆動開発（SDD）が役に立つ。
仕様書が先にあれば、「何をもって正しいか」が決まっている。AIへの指示はこうなる。
以下の仕様に基づいてテストケースを生成してください:
- 入力: ユーザーID、金額
- 正常系: 金額が0以上の場合、トランザクションを作成して成功を返す
- 異常系1: 金額がマイナスの場合、エラーコードE001を返す
- 異常系2: ユーザーが存在しない場合、エラーコードE404を返す
- 制約: 1日あたりの上限は100万円。超過した場合はE002を返すこのように仕様が構造化されていれば、AIはそれに忠実なテストを書ける。実装よりも先にテストが書け、テストが通る実装をAIに書かせる流れになる。これはTDDの発想と同じだ。
バイブコーディング × TDD — 速さと品質を両立する現実解
「仕様書を書く時間がない」という声をよく聞く。しかし、仕様書はドキュメントである必要はない。
会話メモでもよい。箇条書きでもよい。
重要なのは「何を作るか」の合意が、チームとAIの間で共有されていることだ。
実践的なアプローチとして:
- 着手前に5分だけ仕様 を書く: 正常系・異常系・制約をざっと箇条書きにする
- その仕様からAIにテストを生成させる: playwrightやjestのテストコードを仕様から直接出力させる
- テストが通る実装をAIに書かせる: バイブコーディングはここで使う
- 仕様に変更があればテストから更新する: 実装よりテストを先に変える
このサイクルを回せば、AIの高速実装と品質保証を両立できる。
SIer現場での現実
大規模なSIer案件では、テストは工程として独立していることが多い。結合テスト、システムテスト、受入テストがフェーズで区切られ、それぞれに工数がある。
AI導入で実装工程を短縮しても、テスト工程の工数はほぼ変わらないという現象が起きている。なぜなら、テスト設計の根拠になる仕様が曖昧なままだからだ。
仕様が曖昧 → テスト設計に時間がかかる → AIで実装を速くした恩恵が消える
これを解決するのが「上流からの仕様構造化」だ。要件定義の段階でAIが読める形式の仕様書を作れば、テスト設計も自動化できる。AIを実装フェーズにだけ使うのではなく、上流から連携させる発想が必要になる。
まとめ
バイブコーディングの品質問題は、AIの能力の問題ではない。「何を作るか」の合意が先行しているかどうかの問題だ。
仕様が先にあれば、AIはテストも実装も正確に書ける。仕様がなければ、速く書けるだけで、正しく書けているかどうかは誰にも分からない。
コードを速く書くためにAIを使うなら、AIがテストを書けるような仕様を先に作る習慣を持つこと。それが、バイブコーディング時代の品質保証の出発点だ。
AI開発の品質保証や仕様書の構造化に関心がある方は、ぜひお問い合わせからご相談ください。
