最初に結論を述べます。バイブコーディングとは「AIにコードを任せ、diffを逐一読まずに雰囲気で進める作り方」であり、Cursor・Claude Code・v0・Lovable・Bolt は"エディタ型／エージェント型／ビルダー型"の3分類で使い分ければ迷いません。ただし、どのツールで作ろうと「動く」は「安全・壊れない」を意味しません。生成の速さを本番品質に変える鍵は、出荷前に機械的な検証ゲートを挟むことです。
この記事は、自分で手を動かして作る開発者向けです。「AIで作ったアプリの発注・受け入れをどう見極めるか」という発注者視点は別記事（本番化・ハードニング）にまとめてあります。読者が違うので、混同しないでください。ここでは、私自身が一人 × 生成AI（Claude Code）で経済産業大臣賞を受賞したB2B SaaSや本番二重課金0件の決済基盤を作ってきた前提で、ツールの選び方と、本番に出すための最小ラインを、作り手の目線で書きます。
1. バイブコーディングとは — Karpathy の定義に立ち返る
「バイブコーディング（vibe coding）」は、Andrej Karpathy が2025年2月2日に名付けた造語です（原典のポスト）。彼の定義はこうです——**「雰囲気（vibes）に完全に身を委ね、指数関数（AIの進化）を受け入れ、コードが存在することさえ忘れる」**新しいコーディングのやり方。彼はこう続けます。「私は『Accept All』を常に押し、もうdiffを読まない」。
ここで見落とされがちな一文があります。Karpathy 自身、これを**「使い捨ての週末プロジェクトには悪くない（not too bad for throwaway weekend projects）」**と限定していました。つまり原義のバイブコーディングは、壊れても困らないおもちゃを高速に作るための手法です。
問題は、その後この言葉が**「AI主導でコードを書く開発全般」**を指す広い意味に拡張され、本番SaaSまで同じノリで出荷されるようになったことです。原義の「diffを読まない」を、決済や個人情報を扱う本番アプリに適用したら——それは事故です。だから本記事の立ち位置はこうです。生成の"バイブ"は歓迎する。ただし出荷の直前にだけ、機械的な検証で正気に戻る。
2. ツールの3分類 — エディタ型 / エージェント型 / ビルダー型
AIコーディングツールは乱立していますが、**「抽象度」と「制御の粒度」**の2軸で見ると、きれいに3つに分かれます。ここを理解すると使い分けが一発で決まります。
| 分類 | 代表ツール | あなたの役割 | 抽象度 | 出力の単位 |
|---|---|---|---|---|
| エディタ型 | Cursor, GitHub Copilot, Windsurf | あなたが運転し、AIが補完・提案 | 低（行〜ファイル） | 差分・補完 |
| エージェント型 | Claude Code, Codex, Cursor Agent | タスクを言葉で委譲、AIが自律実行 | 中（機能・複数ファイル） | コミット・PR |
| ビルダー型 | v0, Lovable, Bolt | プロンプトからアプリを丸ごと生成 | 高（アプリ全体） | 動くアプリ＋バックエンド |
エディタ型 — あなたが手綱を握る
Cursor や Copilot は、エディタに埋め込まれた強力な補完です。あなたが1行ずつ、あるいは1関数ずつ運転し、AIは次の一手を提案します。制御の粒度が最も細かく、生成物が常に目の前にあるのが強みです。既存コードへの外科的な変更、微妙なリファクタ、"ここだけ直したい"に向きます。原義のバイブコーディングに最も近いのはCursorの Composer で、Karpathy が例に挙げたのもこれでした。
エージェント型 — タスクを委譲する
Claude Code や Codex は、「認証モジュールにテストを書いて、走らせて、落ちたら直して」のようなタスク単位の指示を、複数ファイルを跨いで自律的に実行します。ファイルを読み、編集し、コマンドを実行し、コミットやPRまで作る。抽象度は一段上がり、あなたはレビュアーに回ります。 既存コードベースでの機能追加・バグ修正・大規模リファクタの主力です。私が本番プロダクトを作る際の中心はここです。
ビルダー型 — プロンプトからアプリを生成
v0・Lovable・Bolt は、「〇〇できるアプリを作って」の一言から、UIもバックエンドも含めた動くアプリを生成します。抽象度が最も高く、最も速い。ゼロからの立ち上げ、デザインの叩き台、社内ツールのプロトタイプに圧倒的な破壊力があります。一方で、生成物の内部——特にデータベースや認可——があなたの視界から最も遠いのもこの分類です。ここが第4節の核心につながります。
3. 使い分けの基準 — 「何を作るか」で選ぶ
3分類を、実際の判断に落とすとこうなります。私の使い分けは単純で、「どこまで人間が手綱を握りたいか」＝リスクの高さで選ぶだけです。
ゼロから立ち上げ・UIの叩き台・使い捨てプロト
└─→ ビルダー型（v0 / Lovable / Bolt）で一気に形にする
既存コードベースへの機能追加・リファクタ・テスト整備
└─→ エージェント型（Claude Code / Codex）にタスクを委譲する
決済・認可・データ整合性など「間違えたら事故る」中核ロジック
└─→ エディタ型（Cursor / Copilot）で1行ずつ運転し、diffを必ず読む
重要なのは、この3つは排他ではなく、1つのプロジェクトの中で局面ごとに切り替えるものだということです。私は、ビルダー型で骨格を出し、エージェント型で機能を積み、お金や権限に触れる箇所だけはエディタ型に降りてdiffを1行ずつ確認する——という具合に混ぜます。抽象度を上げるほど速いが、上げるほど「何が起きているか」が見えなくなる。この見えなさをリスクに応じて調整するのが、作り手の腕の見せ所です。
4. 「動く」≠「安全・壊れない」— 抽象度が上がるほどリスクは隠れる
ここが本記事で最も伝えたい一線です。どの分類のツールで作っても、「デモが動く」ことと「本番で漏れない・壊れない」ことは別物です。生成AIはハッピーパスのコードを驚くほど速く書きますが、本番で問われるのは、**不正な入力・同時アクセス・そして"他人のIDを指す正規リクエスト"**にどう振る舞うかです。
そして抽象度が上がるほど、この穴は見えなくなります。
- エディタ型は生成物が目の前にあるので、まだ気づける。
- エージェント型は複数ファイルを跨ぐので、レビューを怠ると抜ける。
- ビルダー型はバックエンドを自動プロビジョニングする。v0 / Lovable / Bolt が Supabase を裏で立ち上げるとき、RLS（Row Level Security）や認可の設計は、あなたが一度も見ないまま本番相当になる。
これは机上の心配ではありません。AIビルダー製アプリのRLS未設定によって、未認証の攻撃者が他人のデータを読み書きできた事例が CVE-2025-48757（CVSS 9.3 CRITICAL） として登録されています。そして Supabase の service_role キーは PostgreSQL の BYPASSRLS で動き、RLSを完全に無視します——守りの境界が「鍵の置き場所」に移ることを、生成されたコードは教えてくれません。
さらに、**攻撃が"認証も書式も正しい正規リクエスト"**であるがゆえに、WAFやヘッダーでは防げない穴があります。オブジェクト単位の認可欠陥（IDOR/BOLA）は、OWASP API Security Top 10 で2019年以来ずっと第1位の最頻出リスクです。
どれくらいの頻度で起きているか。私が関わるOSS「Aegis」の一次調査では——公開Supabaseアプリ1,000件の一次調査で、RLSを持つアプリのうち約9.2%が『認証はするが行を所有者に絞らない』ポリシを持っていた（公開リポジトリ標本ゆえ下限値。所有者非スコープ＝即脆弱ではなく要確認）（調査の詳細と手法）。「ログインは通すが、他人の行を返してしまう」——この『認証はするが認可しない』構造こそ、バイブコーディングが最も踏みやすい罠です。
AI生成コードが具体的にどんな脆弱性を量産するか（認可欠落・入力検証漏れ・秘密のハードコード・slopsquatting など）は、AI生成コードの脆弱性診断で修正前後のコードとともに深掘りしています。ここでは繰り返しません。
5. 本番に出す最小ゲート — バイブのループに検証を1枚挟む
では、生成の速さを殺さずに本番品質へ持っていくには何をすればいいか。答えは**「生成のやり方は変えない。出荷の直前にだけ、機械的なゲートを4枚通す」**です。私が一貫して使っている、探索 → 計画 → 実装 → 検証のループの、最後の"検証"に当たる部分です。
| ゲート | 何を止めるか | 手段 |
|---|---|---|
| ① 型付き境界 | 不正な入力・想定外のデータ形状 | 外部入力を境界で Zod parse。process.env 直参照を型で排除 |
| ② 不変条件のテスト | 認可の省略・退行 | 「他人のIDで他人のデータが見えない」をテストに固定 |
| ③ CIの品質ゲート | 「人がレビューを忘れる」 | 型チェック・静的解析・依存/秘密スキャンをPRで強制 |
| ④ セキュリティスキャン | よくある注入・RLS/認可の罠 | npx @aegiskit/cli scan で静的解析 |
①②③の設計思想——受け入れ条件をテストに落とし、CIで機械的に守り続ける全体像は、AI駆動開発の品質ゲートにまとめています。そして**「diffを読まない」の対極**として、何を作るかを先に仕様として固め、AIに"その仕様を満たす実装"だけを任せる進め方は、仕様駆動開発（spec-driven）のワークフローで扱っています。バイブで速く生成しつつ、入口（仕様）と出口（検証）だけは人間が握る——これが両立の鍵です。
④ の位置づけ — 無料OSSで現状を可視化する
②③を整える前でも、今あるコードを1コマンドで診ることはできます。MITライセンスのOSS Aegis は、npx @aegiskit/cli scan でインストール不要のまま静的解析し、ヘッダー/CSP・レート制限・入力検証・CSRF・秘密情報衛生といった"水平の統制"の欠落を自動化して埋め、ライブラリには直せない"縦のリスク"（認可/IDOR・Supabase RLS の設計ミス）は検出して警告します。v0 / Lovable / Bolt からエクスポートしたコードも、そのまま食わせられます。
ただし——Aegisは「完全に守る」とは言いません。 そう謳うツールはむしろ危険です（「入れたから大丈夫」という油断が最悪の結果を生む）。第4節で挙げた認可・業務ロジック・テナント分離は"縦のリスク"であり、AIもスキャナも原理的に保証できません。 ここは「誰が何を所有し、どの操作を許されるか」というあなたの事業ルールの意味に依存するからです。スキャナができるのは"形"の検査であって、"意味"の保証ではない。だから縦のリスクを閉じるのは、最後まで設計とレビューという人間の仕事として手放さないでください。
6. この先の深掘り — 本番化クラスタの歩き方
このピラー記事から、目的に応じて次を読むのが最短ルートです。
- AIが何を作り込みがちかを、脆弱性クラス別に知りたい → AI生成コードの脆弱性診断（4層診断・slopsquatting・TOP5）
- 「動くが本番が不安」を作り直さず固めたい → AI生成コードの本番化・ハードニング（発注者・事業者視点）
- diffを読まない開発から卒業したい → 仕様駆動開発のワークフロー
- CIで品質を機械的に守り続けたい → AI駆動開発の品質ゲート
- Supabase RLS の「認証≠認可」を根治したい → 認証はするが認可しない、を潰す
まとめ — バイブは歓迎する。出荷の直前にだけ、正気に戻る
- バイブコーディングの原義は「使い捨て週末プロジェクト」（Karpathy）。本番に持ち込むなら、原義にはない検証ゲートを足す。
- ツールは3分類——エディタ型（Cursor/Copilot）／エージェント型（Claude Code/Codex）／ビルダー型（v0/Lovable/Bolt）。抽象度とリスクで使い分ける。
- 抽象度が上がるほどリスクは隠れる。特にビルダー型はRLS・認可が見えないまま本番相当になる（下限9.2%の実測、CVE-2025-48757）。
- 本番の最小ゲートは4枚——型付き境界 → 不変条件のテスト → CIの品質ゲート →
npx @aegiskit/cli scan。 - 認可・業務ロジック・テナント分離は人間の領域。仕様決定と設計レビューは手放さない。
私自身、この進め方で一人 × 生成AIのまま、実在15ロールでの第三者ペネトレーションテストを含む4ラウンドの監査を経て全221エンドポイントの認証欠落0件を実証したB2B SaaSや、本番二重課金0件の決済基盤を作ってきました。速さの源はAI、安全の源は検証——この設計さえあれば、バイブコーディングは最強の武器になります。まずは無料の Aegis で、今のコードの現状を可視化するところから始めてください。