バイブコーディングで、仕様書が完成する前にプロトタイプが動く。これは事実だ。では仕様書はもう要らないのか。答えは半分正しく、半分間違っている。

「実装前に完成させる詳細設計書」としての仕様書は省略できる。しかし「顧客との合意を記録する書類」としての仕様書の機能は、別の形で代替しなければ、プロジェクトは必ず「言った・言わない」で詰まる。

バイブコーディングとは何か

バイブコーディング（Vibe Coding）とは、詳細な仕様書を事前に作らず、感覚的・対話的な指示でAIに実装させる開発スタイルである。Andrej Karpathyが2025年に提唱し、Claude CodeやCursorの普及とともに広まった。

従来の開発は「仕様確定→実装」という直線フローだった。バイブコーディングは「指示→実装→確認→修正」の短いサイクルを繰り返す。仕様が固まる前にプロトタイプが動いている状態から、顧客とすり合わせながら磨いていく。

このスタイルのプロジェクト管理は、従来型とは別の設計が必要だ。

仕様書のどの機能が「省ける」のか

仕様書には、実は複数の機能が混在している。

  1. 設計の機能 — 実装前に「何を作るか」を定義する
  2. 合意の機能 — 顧客が「これで進めていい」と承認した証拠を残す
  3. 記録の機能 — 後から「あのとき何を決めたか」を追えるようにする

バイブコーディングで省けるのは1の設計の機能だけだ。プロトタイプを動かしながら設計を更新するため、事前に詳細設計書を作る意味が薄れる。

しかし2の合意と3の記録は、省けない。むしろバイブコーディングでは変更頻度が増えるため、合意と記録の重要性は上がる。

仕様書の代わりに何を使うか

合意と記録の機能を代替するのは、タスクに紐づいたコメント履歴だ。

動くプロトタイプを顧客に見せて「この画面はこうしてください」という指示があったとき、その内容をタスクのコメントに書き、顧客にコメントで「これで合ってますか」と確認する。顧客が「はい」と返答したコメントが、仕様書の合意ページに相当する。

この方式のメリットは3つある。

残す手間がほぼゼロ — Slackでの合意をタスクコメントに転記するだけで記録になる。別途仕様書を書き直すコストがかからない。

変更追跡が自動 — タスクのコメント履歴に変更の経緯が時系列で残るため、「どの時点でどの仕様を承認したか」が後から辿れる。

顧客がすぐ確認できる — メールを探したり過去のSlackを遡ったりせず、タスクを開けばその機能の合意状況がわかる。

バイブコーディングのプロジェクト管理で変わること

管理の単位が「ドキュメント」から「タスク」に変わる

従来型では仕様書→実装という順序があったため、仕様書のバージョン管理が管理の中心だった。バイブコーディングでは、機能・画面・APIエンドポイントを1タスク単位にし、そのタスクのコメントで設計の変遷を追う設計が機能する。

タスクが「仕様書の章」に相当し、コメントが「変更履歴」に相当する。

変更依頼の受け方が変わる

実装コストが下がると、顧客の変更依頼頻度が上がる。「ここはやっぱりこっちの方がいい」という修正が、口頭やSlackでカジュアルに来るようになる。

これを管理するには、変更依頼を必ずタスクに変換するルールが必要だ。口頭で「わかりました」と答えて終わりにすると、後で実装漏れが発生したときに経緯が追えない。変更依頼はタスクのコメントに書いてもらうか、開発側でタスクを作成して「この変更を承認してください」と顧客にコメントで確認する運用にする。

検収の設計が変わる

従来型は「仕様書通りに作れたか」が検収の基準だった。バイブコーディングでは仕様書が動的に変わるため、「最後に承認した状態と一致しているか」が基準になる。タスクのコメントに残った承認の記録が、検収の根拠になる。

受け入れテストのタスク設計についてはテンプレートギャラリーに受け入れテストテンプレートがあり、そのまま使える。

当社の開発案件での運用

当社のAI駆動開発案件では、タスクが200件を超えた（詳細事例）。この規模になると、仕様書を都度更新する運用は現実的ではない。

代わりに機能したのは、各タスクのコメント欄に「この仕様でいいですか？」「→ はい、進めてください」という短い合意のやり取りを残す設計だった。仕様書は作らなかったが、何を・いつ・誰が決めたかはタスクを見れば全て追えた。

仕様書の代わりとして機能した条件は2つ。タスクが機能単位で細かく切られていたこと、顧客がタスクにアクセスしてコメントできる環境があったことだ。

顧客を同じボードに招待し、コメントで合意を取る設計が「仕様書レス」のプロジェクト管理を機能させる前提になっている。受託開発でのこの設計パターンは受託開発・Web制作のタスク管理にまとめている。

仕様書を省いていいケース・省いてはいけないケース

全ての案件で仕様書が不要なわけではない。

省いていい場合

  • 顧客がプロトタイプを見て即断できる権限と習慣がある
  • プロジェクトの範囲が小さく、タスク数が50件以下
  • 変更のたびにタスクコメントで合意を取る運用が定着している

省いてはいけない場合

  • 顧客が大企業で、担当者に承認権限がなく決裁が必要
  • 法的・コンプライアンス上の記録義務がある
  • 複数の外注先が関わり、全員が参照する共通仕様が必要

後者のケースでも、仕様書を「事前に完璧に作る」必要はない。「現時点の合意をまとめた最新版」として都度更新していく方式でいい。

「仕様書ゼロ」より「合意記録ゼロ」の方が危険

バイブコーディングで失敗するプロジェクトに共通するのは、仕様書がないことではなく、合意の記録がないことだ。

口頭で決めたこと、Slackで流れたこと、定例で「じゃあそれで」と言ったこと——これらが記録されていない状態でプロジェクトが進むと、完成物を見た顧客が「こんな仕様は承認していない」と言い出したとき、反論できない。

仕様書を省くなら、その分だけ合意の記録を厚くする。これがバイブコーディング時代のプロジェクト管理の基本方針だ。

AI駆動開発シリーズの他の記事：