バイブコーディングで本番プロダクトを作る -- 理想と現実
バイブコーディングで本番プロダクトは作れるのか。個人開発での実践経験から、うまくいくケースと課題を解説する。
バイブコーディングとは
バイブコーディングとは、自然言語でAIに指示を出してコードを生成させる開発手法のことだ。2025年にAndrej Karpathyが提唱し、「コードを書く」から「AIにコードを書かせる」へのパラダイムシフトとして注目を集めた。
では、バイブコーディングで本番プロダクトは作れるのか。答えは「条件付きでYes」だ。
理想: 自然言語だけでプロダクトが完成する
バイブコーディングの理想形はこうだ。
- 作りたいものを自然言語で説明する
- AIがコードを生成する
- 動作確認して、問題なければデプロイ
実際、簡単なWebアプリやプロトタイプなら、これだけで動くものが作れる。プログラミング未経験者でもアプリが作れる、という夢は半分実現している。
現実: 本番プロダクトには壁がある
しかし、ユーザーにお金を払ってもらうプロダクトを作るとなると、話は変わる。
うまくいくケース
| ケース | 理由 |
|---|---|
| プロトタイプ・MVP | 完成度より速度が重要 |
| 社内ツール | 限定的なユーザー、緩い品質基準 |
| 静的サイト・LP | ロジックが少なく、見た目が主体 |
| 単機能のユーティリティ | スコープが狭い |
うまくいかないケース
| ケース | 理由 |
|---|---|
| 複雑なステート管理 | AIが全体の整合性を維持できない |
| セキュリティが重要な機能 | 認証・認可の穴を見逃すリスク |
| パフォーマンス最適化 | AIはとりあえず動くコードを優先する |
| 長期的な保守 | 一貫性のないコードが蓄積する |
R3O Works での実体験
私は Shutter というノートアプリを開発している。バイブコーディングを多用しているが、それだけで作っているわけではない。
バイブコーディングが効いた場面:
- UIコンポーネントの生成（デザインを言葉で説明 → コード化）
- API エンドポイントの雛形作成
- テストケースの網羅的な生成
- ドキュメントやコメントの自動生成
人間の判断が不可欠だった場面:
- データベース設計（正規化の度合い、インデックス戦略）
- セキュリティ設計（認証フロー、トークン管理）
- アーキテクチャの選定（技術スタックの組み合わせ）
- パフォーマンスのボトルネック特定と解消
体感では、全工程の60〜70%はバイブコーディングでカバーできる。残りの30〜40%が、プロダクトの品質を左右する部分だ。
テスト・セキュリティ・保守性の課題
バイブコーディングで生成されたコードには、共通の課題がある。
テスト: AIは「動くコード」を書くのは得意だが、「壊れないコード」を書くのは苦手だ。エッジケースの考慮が甘く、テストカバレッジが不十分になりがちだ。テスト設計は人間が主導する必要がある。
セキュリティ: AIはSQLインジェクション対策やXSS対策など、教科書的な防御は入れてくれる。だが、ビジネスロジックに起因する認可の抜けなど、コンテキスト依存の脆弱性は見逃す。セキュリティレビューは必須だ。
保守性: 異なる文脈で生成されたコードを組み合わせると、命名規則やアーキテクチャの一貫性が崩れる。定期的なリファクタリングと、プロジェクト全体のルール設定（linter、コーディング規約）が欠かせない。
結論: AIは武器、判断力は鎧
バイブコーディングは強力な武器だ。開発速度は劇的に上がる。一人で本番プロダクトを作ることも、確かにできる。
ただし、エンジニアリングの判断力なしにバイブコーディングだけで本番プロダクトを作ると、見えない負債が積み上がる。AIが生成したコードの品質を見極め、セキュリティを担保し、長期的に保守できる設計を判断する力。それが、バイブコーディングを本番で使いこなすための条件だ。
AIは開発を加速する武器であり、エンジニアリングの判断力はプロダクトを守る鎧だ。両方揃って初めて、本番プロダクトが作れる。