バイブコーディング vs スペックドリブン開発——プロトタイプでは正解でも、商用開発に「仕様書」が要る理由

「AIに頼めば、数時間でアプリの試作品ができる」——この数年で、そんな体験をした事業主・担当者の方は少なくないはずです。AIと対話しながらその場でコードを作っていく「バイブコーディング（Vibe Coding）」は、たしかにプロトタイプ作りにおいては驚くほど強力です。

ただし、その勢いのまま商用システムの開発を進めようとすると、思わぬところでつまずきます。この記事では、バイブコーディングと対をなす「スペックドリブン開発（仕様駆動開発）」という考え方を軸に、プロトタイプと商用開発で何が違うのか、そして商用開発ではなぜ「仕様書」が必要になるのかを、具体的な失敗パターンとともに解説します。

バイブコーディングとスペックドリブン開発とは何か

まず、2つの言葉を簡単に整理しておきます。「バイブコーディング」は、AI研究者のアンドレイ・カルパシー氏が2025年に提唱したことで広まった用語です。一方「スペックドリブン開発」は、バイブコーディングが抱える課題への対応として、GitHubの「Spec Kit」など開発ツール・コミュニティの中で使われるようになった用語です。

バイブコーディング — 会話しながら「事後修正」していくスタイル

バイブコーディングとは、AIに自然言語で「こんな機能が欲しい」と伝え、生成されたコードを動かしながらその場で修正・調整を重ねていく開発スタイルです。詳細な設計図を用意する前にまず動くものを作り、動かしながら直していく——いわば「作ってから直す」順番の開発です。

スペックドリブン開発 — 仕様を先に固める「事前設計」のスタイル

一方のスペックドリブン開発は、コードを書き始める前に「何を作るか」を仕様として言語化し、それをもとに実装を進める開発スタイルです。「直してから作る」のではなく、「決めてから作る」順番を徹底します。

どちらが優れているという単純な話ではありません。重要なのは、この2つは「労力をどこにかけるか」が違うという点です。バイブコーディングは労力を実装後の修正（事後）にかけ、スペックドリブン開発は労力を実装前の仕様策定（事前）にかけます。プロトタイプのように、間違ってもやり直すコストが小さい場面ではバイブコーディングの身軽さが活きますが、商用システムのように後から直すコストが大きい場面では、この労力配分がそのまま裏目に出ます。

プロトタイプでは正解、商用開発では危険——3つの失敗パターン

「バイブコーディングか、スペックドリブン開発か」を抽象的に比較しても、自社にとっての意味は掴みにくいものです。ここでは、商用開発の現場で実際に起こりやすい3つの失敗パターンに絞って見ていきます。

パターン1: レビューされないAIコードに潜む脆弱性

バイブコーディングでは、「動いたかどうか」がその場で分かるため、コードの中身を人が丁寧に読まないまま次の指示に進んでしまいがちです。しかしAIが生成するコードは、認証処理の抜け漏れや、外部から渡された値をそのまま実行してしまう設計など、セキュリティ上の弱点を含んだまま「一見動く」状態になっていることがあります。プロトタイプの検証段階ではほとんど問題になりませんが、実際にユーザーの個人情報や決済情報を扱う商用システムでこれが放置されると、情報漏洩やサービス停止につながるリスクになります。

パターン2: 気づかぬうちに積み上がる技術的負債

バイブコーディングは初速が非常に速い一方、対話を重ねるほどコードの前提や依存関係が複雑になっていきます。「あの機能をどう直したら、この機能が壊れないか」をAIも人も把握しきれなくなる状態です。開発初期の1〜2ヶ月は快調でも、機能が増えるにつれて一つの修正が別の箇所を壊す「もぐら叩き」のような開発になり、結果的に作り直しに近いコストがかかることがあります。仕様が文書として残っていないと、どこまでが「意図した仕様」でどこからが「AIの解釈による実装」なのかを後から切り分けるのも困難です。

パターン3: メンバーが増えた瞬間に露呈する引き継ぎ困難

バイブコーディングでは、実装の意図や判断の経緯が、チャットの対話履歴の中にしか残らないことがよくあります。開発した本人はその経緯を覚えていても、新しくチームに加わったメンバーやAmanity以外の開発会社に引き継ぐ際には、「なぜこの仕様になっているのか」を再現する手がかりがありません。結果として、「動いているが誰も全体を把握していないシステム」ができあがり、機能追加のたびに調査コストがかさむようになります。事業がうまくいって開発体制を拡大しようとした矢先にこの壁にぶつかるケースは、決して珍しくありません。

スペックドリブン開発はこれらをどう防ぐのか

上記の3つの失敗パターンは、いずれも「実装の意図が、実装そのものの中にしか存在しない」ことが根本原因です。スペックドリブン開発は、実装に入る前に仕様を文書として言語化することで、この根本原因に直接手を打ちます。

つまりスペックドリブン開発の本質は、「AIコードをレビューするかどうか」という話ではなく、労力を事前（仕様策定）にかけるか、事後（都度の修正・調査）にかけるかという配分の問題です。商用開発では、事後にかかる修正・調査コストが事前の仕様策定コストを大きく上回りやすいため、スペックドリブン開発が合理的な選択になります。

「仕様書」は目新しいものではない——従来の要件定義書・設計書との違い

ここまで読んで、「それは結局、従来からある要件定義書や設計書の話ではないか」と感じた方もいるかもしれません。その理解は正しく、スペックドリブン開発における「仕様書」は、従来の要件定義書・基本設計書と同じ系譜にあるものです。

違うのは、読み手が人間だけでなくAIも含むという点です。従来の設計書は人間のエンジニアが読み解いて実装する前提で書かれてきましたが、スペックドリブン開発の仕様書は、AIがそのまま実装のインプットとして解釈できる粒度・構造で書かれます。機能の範囲、画面と操作の流れ、扱うデータ、完成の判断基準——盛り込む要素そのものは従来の設計書と大きくは変わりませんが、「人間にもAIにも誤解なく伝わる」ことが今まで以上に強く求められるようになった、と捉えるのが実態に近いでしょう。

仕様書は人間とAIの協働でつくる——Amanityの実例

「仕様書が必要なのは分かるが、結局それを書く手間がかかるのでは」という懸念もよく聞かれます。ここが誤解されやすいポイントです。仕様書は発注者やエンジニアが一からすべて書き下ろすものではなく、人間とAIが役割分担しながら作るものです。

Amanityでの実際の進め方は、次のような流れです。

1. 人間が意図を出す: 発注者へのヒアリングで、「何を実現したいか」「誰が、どんな場面で使うか」「既存の業務フローとの関係」といった目的・背景を、箇条書きレベルで構いませんので言語化していただきます
2. AIが構造化ドラフト化する: ヒアリング内容をもとに、AIが機能一覧・画面ごとのイメージ・データの持ち方・受け入れ条件といった項目に構造化し、仕様書のドラフトを短時間で作成します
3. 人間が承認する: 作成されたドラフトを、発注者とエンジニアの双方で読み合わせ、過不足や認識のズレを確認したうえで正式な仕様書として承認します

このプロセスの利点は、仕様書作成のスピードとレビューの精度を両立できることにあります。人間がゼロから文書を書き起こす場合に比べて、AIによる構造化ドラフトがあることで仕様策定にかかる時間は大きく短縮されます。一方で、「AIが作ったから正しいはず」と鵜呑みにするのではなく、最終的な承認は必ず人間が行うため、パターン1で挙げた「レビューされないコード」と同じ問題が仕様の段階で発生することも防げます。

発注者にとってこのプロセスが持つ意味は小さくありません。仕様書という「共通言語」が最初に存在することで、開発の進捗や完成イメージを発注者自身が確認できるようになり、「思っていたものと違った」という完成後のギャップが起きにくくなります。バイブコーディングのスピード感を仕様策定の段階に取り入れつつ、商用開発に必要な確実性を仕様書というかたちで担保する——これが、Amanityが発注前後を通じて仕様書をきちんと書く理由です。

まとめ・次のアクション

この記事のポイントを整理します。

• バイブコーディングは「作ってから直す」、スペックドリブン開発は「決めてから作る」——労力を事前・事後どちらにかけるかが根本的な違いである
• プロトタイプでは正解のバイブコーディングも、商用開発では「レビューされないコードの脆弱性」「気づかぬ技術的負債」「メンバー増加時の引き継ぎ困難」という3つの失敗パターンを招きやすい
• スペックドリブン開発は、実装の意図を仕様書として残すことで、この3つのパターンに直接対処できる
• 仕様書は従来の要件定義書・設計書と同じ系譜にあり、違いは「人間だけでなくAIも読み手になる」点である
• 仕様書は人間が一から書くものではなく、人間が意図を出し、AIが構造化ドラフト化し、人間が承認するという協働プロセスで作るのが合理的である

「AIでどれだけ速く作れるか」だけでなく、「その速さを商用システムでどう安全に活かすか」が、これからの発注先選びの重要な判断軸になります。Amanityでは、発注前のヒアリングから仕様書の構造化ドラフト作成、承認プロセスまでを一貫してサポートしています。バイブコーディングのスピード感を活かしつつ、商用開発として安心して任せられる体制を整えたい方は、お気軽にご相談ください。