バイブコーディングの設計書について

バイブコーディングの設計書とは

バイブコーディングには、決められた形式の「専用設計書」が存在するわけではありません。

本来のバイブコーディングは、AIに自然言語で指示を出し、生成されたコードを細かく確認するよりも、実行結果を見ながら追加の指示を与えて開発を進める方法を指します。

そのため、厳密にいえば、詳細な設計書を作成し、その設計書を基準としてAIに実装させる方法は、純粋な意味でのバイブコーディングというよりも、AI支援開発やSpec-Driven Development（仕様駆動開発）に近い考え方です。

ただし、実際にAIを使ってある程度規模の大きいWebサービスやアプリを開発する場合、仕様をまったく整理せずに進めると、機能の抜けや仕様のズレが発生しやすくなります。

そこで、バイブコーディング的なスピード感を活かしながら開発の品質を高める方法として、設計書や仕様書を用意する方法が有効です。

バイブコーディングとは

バイブコーディングとは、AIに自然言語で指示を出しながら、アプリやWebサービスなどを開発していく方法です。

「Vibe Coding」という言葉は、AI研究者のAndrej Karpathy氏が2025年2月に提唱したことで広く知られるようになりました。

たとえばAIに、

「タスク管理アプリを作ってください」

「ログイン機能を追加してください」

「デザインをもっとシンプルにしてください」

「スマートフォンでも使いやすくしてください」

「このエラーを修正してください」

といった指示を与えながら開発を進めます。

ただし、AIに自然言語でコードを書かせる行為すべてが、厳密な意味でのバイブコーディングというわけではありません。

本来のバイブコーディングには、AIが生成したコードを細かく読み込まず、実行結果や挙動を確認しながら次の指示を出していくという意味合いがあります。

そのため、人間がコードレビューやテストを行いながらAIを活用する開発は、より広い意味で「AI支援開発」と考えたほうが正確です。

バイブコーディングで設計書を作るメリット

小規模な試作品であれば、設計書を作らず、AIとの会話だけで開発を進められる場合もあります。

一方、ページ数や機能数が増えると、仕様を文章として整理しておくことが重要になります。

AIによる仕様の勘違いを減らせる

たとえばAIに、

「美容院の予約サイトを作ってください」

とだけ指示した場合、AIは多くの仕様を推測しなければなりません。

具体的には、

・会員登録は必要なのか
・ログインは必要なのか
・スタッフを選択できるのか
・予約変更はできるのか
・キャンセルはできるのか
・決済機能は必要なのか
・管理画面は必要なのか

などです。

こうした条件を設計書に明記しておけば、AIが勝手に仕様を補完する範囲を減らせます。

結果として、利用者が想定していたものと異なるシステムが生成されるリスクを抑えやすくなります。

AIとの修正のやり取りを減らせる

設計書がない状態で開発を始めると、

「その機能はいりません」

「前の仕様に戻してください」

「ここは管理者だけ使えるようにしてください」

「そのページは作らないでください」

といった修正が増える可能性があります。

最初に仕様を文章として整理しておけば、AIがプロジェクトの全体像を把握しやすくなります。

そのため、プロンプトの往復回数や手戻りを減らしやすくなります。

プロジェクト全体のルールを統一しやすい

AIとの会話だけに仕様を残していると、長期間の開発では過去の判断が分かりにくくなることがあります。

そこで、

SPEC.md

requirements.md

architecture.md

などのファイルに仕様を保存しておけば、プロジェクトのルールを一元管理しやすくなります。

利用するAIツールがプロジェクト内のファイルを参照できる場合は、こうした文書をAIのコンテキストとして利用することも可能です。

バイブコーディングとSpec-Driven Developmentの違い

バイブコーディングと設計書について理解するうえでは、Spec-Driven Developmentとの違いを知っておくことが重要です。

バイブコーディングは実装しながら方向性を決める

バイブコーディングでは、最初から詳細な仕様をすべて定めず、AIに作らせた結果を確認しながら開発を進めるケースがあります。

たとえば、

「まずログイン画面を作って」

「もう少しシンプルにして」

「Googleログインも追加して」

といった形で、生成結果を見ながら機能を追加していきます。

試作品や個人開発など、スピードを重視する場面では有効です。

Spec-Driven Developmentは仕様を先に決める

一方、Spec-Driven Developmentでは、実装を始める前に仕様を明文化します。

たとえば、

・どのような機能が必要か
・どのユーザーが利用するのか
・どのような条件で処理されるのか
・何をもって完成とするのか

などをあらかじめ決めます。

その仕様を開発上の基準としてAIに実装させます。

したがって、両者は同じものではありません。

AIを使った本格的なシステム開発では、バイブコーディングのスピード感を活かしながら、Spec-Driven Developmentの考え方を取り入れる方法もあります。

バイブコーディング用の設計書に書く内容

バイブコーディング専用の正式な設計書フォーマットがあるわけではありません。

しかし、AIを使った開発で仕様書を作る場合は、以下の項目を整理しておくと便利です。

プロジェクトの目的

最初に「何を作るのか」を明確にします。

たとえば、

「個人経営の美容院向けに、ユーザーがスマートフォンから予約できるWebサービスを開発する」

といった形です。

単に「予約システムを作る」と書くよりも、対象ユーザーや利用目的まで明記したほうがAIに意図が伝わりやすくなります。

ターゲットユーザー

誰がサービスを利用するのかを整理します。

美容院の予約システムであれば、

・一般ユーザー
・美容院スタッフ
・店舗管理者

などが考えられます。

ユーザーごとに利用できる機能が異なる場合は、権限についても明記します。

必要な機能

システムに必要な機能を一覧化します。

たとえば、

・会員登録
・ログイン
・店舗検索
・スタッフ選択
・日時選択
・予約
・予約キャンセル
・予約履歴
・管理画面

などです。

必要な機能を最初に整理しておけば、実装漏れを防ぎやすくなります。

画面構成

必要なページをあらかじめ整理する方法も有効です。

たとえば、

/
トップページ

/login
ログインページ

/register
会員登録ページ

/shops
店舗一覧

/shops/[id]
店舗詳細

/reservation
予約ページ

/mypage
マイページ

/admin
管理画面

のように定義します。

URL構造まで決めておけば、AIがルーティングを設計するときにも役立ちます。

各画面の仕様

ページごとに表示する内容や機能も整理します。

たとえば店舗詳細ページなら、

・店舗名を表示する
・住所を表示する
・営業時間を表示する
・スタッフ一覧を表示する
・予約ボタンを表示する

といった形です。

AIに「何が表示されれば完成なのか」を明確に伝えられます。

使用する技術

技術スタックを指定する場合は、設計書に記載しておきます。

たとえば、

Frontend: Next.js
Language: TypeScript
CSS: Tailwind CSS
Database: PostgreSQL
Authentication: Supabase Auth
Hosting: Vercel

などです。

使用する技術を決めておけば、開発途中でAIが別のフレームワークやライブラリを選択するリスクを抑えられます。

技術に詳しくない場合は、

「初心者でも保守しやすい構成にする」

「できるだけ依存ライブラリを少なくする」

などの条件を指定し、AIに構成案を出してもらう方法もあります。

データベース設計

データを扱うサービスでは、データベース構造も重要です。

たとえば、

users
- id
- name
- email
- created_at

shops
- id
- name
- address
- phone

reservations
- id
- user_id
- shop_id
- reservation_date
- status

のように、必要なテーブルやカラムを整理します。

最初にデータ構造を決めておけば、AIが機能ごとに異なるデータ形式を作ってしまう問題を防ぎやすくなります。

デザインルール

AIにUIを生成させる場合は、デザインルールも明文化しておくと便利です。

たとえば、

・背景は白を基本とする
・アクセントカラーは青にする
・ボタンデザインを統一する
・スマートフォン表示を優先する
・過度なアニメーションを使わない
・余白を広めに設定する

などです。

ルールを決めておけば、ページごとにデザインの雰囲気が大きく変わる問題を抑えられます。

制約事項

「何をするか」だけではなく、「何をしてはいけないか」も記載しておくことが重要です。

たとえば、

・APIキーをソースコードへ直接記述しない
・既存データベースのカラム名を勝手に変更しない
・不要なライブラリを追加しない
・既存画面のデザインを無断で変更しない
・認証処理を省略しない

などです。

AIに禁止事項を明示しておくことで、意図しない変更を防ぎやすくなります。

完了条件

AIを使った開発では、特に重要なのが完了条件です。

たとえば、

・ユーザー登録ができる
・ログインできる
・店舗を検索できる
・予約できる
・予約をキャンセルできる
・管理画面から予約を確認できる
・スマートフォンでも正常に操作できる
・主要なテストがすべて成功する

などです。

こうした条件は「Acceptance Criteria（受け入れ条件）」とも呼ばれます。

「完成」という曖昧な表現ではなく、具体的な条件として定義しておけば、AIと人間の両方が実装完了を判断しやすくなります。

バイブコーディング向け設計書の具体例

設計書はMarkdown形式で作成すると管理しやすくなります。

たとえば、SPEC.mdというファイルを作成します。

# プロジェクト概要

美容院向けオンライン予約サービスを開発する。

## 目的

ユーザーがスマートフォンから美容院を検索し、
希望する日時を指定して予約できるようにする。

## ユーザー

### 一般ユーザー

- 会員登録
- ログイン
- 店舗検索
- 予約
- 予約キャンセル
- 予約履歴確認

### 管理者

- 店舗情報編集
- 予約一覧確認
- 予約ステータス変更

## ページ

- /
- /login
- /register
- /shops
- /shops/[id]
- /reservation
- /mypage
- /admin

## 技術

- Next.js
- TypeScript
- Tailwind CSS
- PostgreSQL
- Supabase
- Vercel

## デザイン

- モバイルファースト
- シンプルなUI
- 白をベースにする
- アクセントカラーは青
- ボタンのデザインを統一する

## セキュリティ

- APIキーをコードに直接記述しない
- 入力値を検証する
- 管理画面には権限制御を行う
- 認証が必要なページを保護する

## 完了条件

- 会員登録できる
- ログインできる
- 店舗を検索できる
- 予約できる
- 予約をキャンセルできる
- 管理画面から予約を確認できる
- スマートフォンで正常に操作できる

このような仕様書をプロジェクト内に保存し、AIに参照させながら開発する方法があります。

ただし、SPEC.mdという名称が正式な業界標準というわけではありません。

requirements.mdやdesign.mdなど、プロジェクトに合わせてファイル名を決めても問題ありません。

設計書は複数のファイルに分けてもよい

プロジェクトが大きくなる場合は、すべての情報を1つのファイルへまとめる必要はありません。

たとえば、

docs/
├── requirements.md
├── architecture.md
├── database.md
├── api.md
├── ui.md
├── security.md
└── testing.md

のように分割できます。

requirements.md

サービスの目的、ユーザー、必要な機能などを記載します。

architecture.md

フロントエンド、バックエンド、外部サービスなど、システム全体の構成を記載します。

database.md

テーブル構成、カラム、リレーションなどを記載します。

api.md

APIのURL、リクエスト、レスポンス、エラー処理などを整理します。

ui.md

デザインルール、コンポーネント、画面仕様などを記載します。

security.md

認証、権限管理、入力値検証、秘密情報の管理などを整理します。

testing.md

単体テスト、結合テスト、E2Eテストなどの方針を記載します。

プロジェクト規模が大きい場合は、このように役割ごとに分割したほうがAIも人間も仕様を確認しやすくなります。

設計書を細かく作りすぎる必要はない

設計書は重要ですが、最初から何十ページもの資料を作る必要はありません。

バイブコーディングのメリットの一つは、アイデアを素早く形にできることです。

小規模なプロトタイプなら、

目的

必要な機能

ページ一覧

使用技術

デザインルール

完了条件

程度でも十分な場合があります。

一方、企業向けシステムや多くのユーザーが利用するサービスでは、

要件定義

アーキテクチャ設計

データベース設計

API設計

UI設計

セキュリティ設計

テスト設計

運用設計

まで検討したほうが安全です。

開発するサービスの規模や重要度に応じて、設計書の詳細度を調整することが大切です。

バイブコーディングではセキュリティ確認も重要

AIが生成するコードが、必ずしも安全とは限りません。

特に、本来の意味でのバイブコーディングのように、生成コードを十分に確認せずに採用すると、セキュリティ上の問題を見逃す可能性があります。

APIキーなどをコードへ直接書かない

APIキーやパスワードなどの秘密情報は、ソースコードへ直接記述しないようにします。

環境変数やシークレット管理機能などを利用する必要があります。

認証と権限管理を確認する

ログイン機能が正常に動くだけでは十分ではありません。

「一般ユーザーが管理画面へアクセスできないか」

「他のユーザーの情報を閲覧できないか」

なども確認する必要があります。

入力値を検証する

フォームやAPIで受け取った値は、必ず検証する必要があります。

AIが生成したコードでも、入力値検証が十分ではない場合があるため、人間による確認が重要です。

コードレビューとテストを実施する

本番サービスでは、AIが生成したコードをそのまま公開するのではなく、

・コードレビュー
・自動テスト
・手動テスト
・セキュリティチェック

などを実施したほうが安全です。

この段階まで行う場合、純粋な意味でのバイブコーディングというより、AIを活用したソフトウェア開発と考えたほうが適切です。

AIに設計書そのものを作らせる方法

AIを使っているのであれば、設計書自体をAIに作成させることもできます。

いきなりコードを書かせるのではなく、まず要件整理から依頼します。

たとえば、

飲食店向け予約管理システムを作りたいです。

まだコードは書かないでください。

最初に以下を整理してください。

・サービス概要
・ターゲットユーザー
・必要機能
・画面一覧
・画面ごとの機能
・データベース構造
・技術構成
・セキュリティ要件
・テスト項目
・完成条件

不足している仕様については、合理的な案を提示してください。

と指示します。

AIが作成した内容を人間が確認し、問題がなければ、

この設計書を正式な仕様として、
実装可能な単位にタスクを分割してください。

と依頼します。

その後、

タスクを順番に実装してください。
各タスクの実装後にテストを行ってください。

と進めることができます。

こうした方法では、

アイデア
↓
要件整理
↓
設計書作成
↓
人間による確認
↓
タスク分割
↓
AIによる実装
↓
テスト

という流れになります。

単に「アプリを作ってください」と依頼するより、仕様のブレを抑えやすい方法です。

バイブコーディングの設計書では完成条件を明確にする

AIを使った開発で特に重要なのが、「どの状態になれば完成なのか」を具体的に定義することです。

たとえば、

「使いやすいログイン画面を作る」

だけでは、完成条件が曖昧です。

それよりも、

・メールアドレスとパスワードでログインできる
・入力内容に誤りがある場合はエラーを表示する
・ログイン成功後はマイページへ移動する
・未ログイン状態ではマイページへアクセスできない
・スマートフォンでも正常に表示される

などと定義したほうが明確です。

AIは曖昧な指示でも何らかのコードを生成できます。

しかし、生成できることと、ユーザーが求めている状態に完成していることは別です。

そのため、設計書では「何を作るか」だけでなく、「どの条件を満たせば完成なのか」まで決めておくことが重要です。

まとめ

バイブコーディングには、正式に決められた設計書のフォーマットが存在するわけではありません。

本来のバイブコーディングは、AIが生成したコードを細かく確認せず、実行結果を見ながらプロンプトを追加して開発を進める方法です。

一方、ある程度規模の大きいWebサービスや本番環境向けシステムをAIで開発する場合は、設計書を用意したほうが仕様のズレや手戻りを防ぎやすくなります。

設計書には、

・プロジェクトの目的
・ターゲットユーザー
・必要な機能
・画面構成
・技術構成
・データベース設計
・デザインルール
・制約事項
・セキュリティ要件
・完了条件

などを記載するとよいでしょう。

特に重要なのは、AIにすべてを任せるのではなく、設計書の内容や生成されたコードを人間が確認することです。

小規模なプロトタイプではバイブコーディングのスピードを活かし、本格的なサービスでは仕様書、コードレビュー、テスト、セキュリティ確認を組み合わせることで、AIをより安全かつ効率的に開発へ活用できます。

以上、バイブコーディングの設計書についてでした。

最後までお読みいただき、ありがとうございました。