バイブコーディングで1日でプロトタイプ：向く場面と危ない場面
バイブコーディングは1日で動く試作を作れますが、セキュリティの穴や技術的負債への近道にもなります。この記事は、使ってよい場面、止める場面、1日の計画、試作を製品にする前のチェックリストを示します。
プロダクトに関わる人、プログラマー、AIでアプリを作り始めた人のための記事です。技術用語には短い説明を付けます。
数字は末尾の公開情報によるもので、多くはセキュリティ会社や報道の発表です。慎重に読んでください。登場する「ラン」は、イメージしやすいように作った例で、実在の人物ではありません。
先に要点#
- バイブコーディングは、AIにコードを書かせて細かく読まないこと。1日で作る使い捨てのプロトタイプによく合います。
- 実際の利用者、個人データ、ログイン、お金が入ると危険です。不具合は、誰も読まない所に潜みがちだからです。
- 目安：結果を負うのは誰か？ 自分だけなら気楽に。他の人なら、読んで、テストして、安全性を確かめます。
- 1日の計画は5つの区間：問題を問う、画面を描く、骨組みを作る、ダミーデータを入れる、実際の人に試してもらう。
- 1日の終わりに決める：捨てる、書き直す、強化する。プロトタイプをいつの間にか製品にしないこと。
むずかしい言葉をやさしく#
| 用語 | やさしい意味 |
|---|---|
| バイブコーディング | 望みを言葉で伝え、AIにコードを書かせ、動かし、壊れたらAIに直してもらう。コードは細かく読まない。 |
| プロトタイプ | アイデアを試すための試作。まだ製品ではない。 |
| MVP | 実際の利用者に出せるほど小さく、信頼されるほど堅い版。 |
| 技術的負債 | 今日急いだ分を、後で直す時間で払うこと。 |
| 行レベルセキュリティ（RLS） | 各人が自分のデータの行だけ読めるというデータベースの規則。 |
| 使い捨て | 捨てられるもの。学ぶために作り、残すためではない。 |
1. バイブコーディングとは何か、線はどこか#
この言葉は、2025年2月の初めごろのアンドレイ・カルパシーの投稿に由来します：AIにすべて書かせ、「雰囲気」に任せ、コードがどうなっているかは気にしない。その後、多くの人があらゆるAI支援のプログラミングにこの言葉を使うようになりました。
サイモン・ウィリソンは、もっとはっきりした線を引きます：コードをレビューし、テストし、説明できるなら、それはバイブコーディングではなくAI支援のプログラミングです。彼の言い方では、バイブコーディングは結果を負うのが自分だけの個人用ツールに向き、他の人が頼るコードには向きません。私は彼の公開された文章に拠っており、原文を一文ずつ確かめ直してはいません。
この記事では、バイブコーディングを読まずに動かすこととします。それ自体は悪くありません。悪いのは、読む必要がある場所へ持ち込むことです。
2. なぜプロトタイプは1日で足りるのか#
プロトタイプの価値はコードではなく、実際の人から得る答えです：理解できたか、必要か、どこで詰まるか。AIが骨組み作りを数週間から数時間に縮めれば、1つに決める前にいくつかの方向を試せます。
これが最もよく当てはまるのは：
- 実データやお金がなく、失敗の費用が低いとき。
- 目的が納品ではなく学ぶことのとき。
- 惜しまずに捨てられるとき。
3. バイブコーディングが向くとき#
| 場面 | なぜ大丈夫か |
|---|---|
| 5〜10人とアイデアを検証 | 1週間試して捨てる。目的は理解で、残すことではない。 |
| 顧客や仲間へのデモ | 見て触れればよく、頼れる必要はない。 |
| 個人用ツール（自分の作業の自動化） | 結果を負うのは自分だけ。 |
| 複数の画面案を試す | 会議で言い合うより安い。 |
| 新しい考えを学ぶ | AIがやるのを見て、良い所を読み返す。 |
4. 危険なとき#
| 場面 | なぜ危険か |
|---|---|
| ログインと権限 | ここの不具合は、他人のデータを見せてしまう不具合。 |
| 個人情報や機微な情報 | 漏えいは法的にも信頼の面でも重い。 |
| 決済、返金、残高 | 1行の間違いが実際のお金を失わせる。 |
| 多くの利用者、長く使う | 小さな不具合が重なり大きくなり、誰もコードを理解していないので直しにくい。 |
| 社内システムとの連携 | 1つの不具合が他のシステムに広がりうる。 |
実際の例。 CVE-2025-48757は、AIでアプリを作るツールLovableが生成したアプリで、行レベルセキュリティのポリシーが欠けていた、または弱かったことに関わる問題です。Superblocksの分析によると、170超のアプリが影響を受け、ログインなしで読めるデータテーブルがありました。研究者のMatt Palmerは2025年3月21日にLovableへ報告しました。この数は第三者企業の発表なので、参考値として扱い、必要ならCVEの記録を確かめてください。
これは2通りに読めます：ツールは完全ではない。そして、アクセス制御の部分は、画面をクリックしても見えないので、利用者が読んでいなかった。バイブコーディングでは、動く部分は見えますが、誰が何を読めるかは見えません。
また、第三者の小さな調査（VibeWrench、2026年3月、バイブコーディングされた100アプリ）は、基本的な防御を欠くアプリが多いと報告しています。私は独立には確かめていないので、個々の数字は引用しません。
5. 1日の計画、5つの区間#
作った人物による例です。
ランはプロダクトマネージャーで、「メール不要のチーム会議の日程調整アプリ」というアイデアを試したいと考えています。1日を使います。
| 時刻 | 作業 | 成果物 |
|---|---|---|
| 8:30〜9:30 | 問題を問う。 3文で書く：誰が困っているか、今何をしているか、成功とは何か。 | 1枚の紙 |
| 9:30〜11:00 | 画面を描く。 3つの画面を手で描き、AIに説明する。 | 3枚のスケッチ |
| 11:00〜13:00 | 骨組みを作る。 AIにダミーデータでメイン画面を作ってもらう。 | 手元で動く版 |
| 14:00〜16:00 | ダミーデータと変わったケースを足す。 空のリスト、長い名前、通信エラー。 | 見せられる版 |
| 16:00〜17:30 | 3〜5人に試してもらう。 どこで詰まるかを記録。 | フィードバックのメモ |
| 17:30〜18:00 | 決める。 捨てる、書き直す、強化する。 | 1行の決定 |
ランが正しくやったこと：実データなし、ログインなし、お金なしで、最初の画面に「プロトタイプ、11月15日に破棄」と書いたこと。得たのは答えでした：5人のうち2人が「チーム」という言葉を理解せず、5人全員がスマートフォンでカレンダーを見たがりました。
6. プロトタイプから製品へ：チェックリスト#
残すと決めたら、次をすべて通るまで利用者を増やさないでください。
- ログインと権限。 誰が誰のデータを読めるか？ 別のアカウントでログインして見る。
- データベースへのアクセス。 すべてのテーブルに行を絞るポリシーがあるか？ ログインなしでアクセスを試す。
- 入力。 すべての入力欄がチェックされているか？
- 秘密情報。 APIキーやパスワードが、コード、ファイル、Gitの履歴にないか？
- テスト。 主な経路と変わったケースのテストがあるか？ コードが間違うと失敗するか？
- ライブラリ。 すべて実在し、今も保守されているか？
- バックアップと復旧。 データのバックアップがあり、復旧を試したか？
- 読む人。 少なくとも1人がコードを読み、理解したか？
詳しい一覧はAIが書いたコードのレビューにあります。多くのチームは中核を書き直し、画面とプロトタイプからの学びを残します。1か所ずつ繕うよりきれいなことが多いのです。
7. バイブコーディングを安全にする3つの習慣#
- 期限を決める。 破棄する日を画面に書く。破棄日のないプロトタイプは製品になります。
- ダミーデータを使う。 確認していないツールに、顧客の実データを入れない。
- 本物のシステムから離す。 プロトタイプは本物のデータベース、決済、社内システムにつなげない。
8. バランスの取れた見方#
- バイブコーディングがいつも速いわけではありません。 METRの研究（2025年7月）では、経験豊富な16人の開発者が、慣れたプロジェクトで2025年初めのAIツールを使うと約19%遅くなりました。本人たちは速くなったと信じていました。標本は小さくツールも変わっていますが、速く感じることは測定ではありません。
- 「ほぼ正しい」がいちばん厄介です。 Stack Overflowの2025年調査では、約66%が「ほぼ正しいが完全ではない」解に出会い、約45%がAI製コードのデバッグのほうが時間がかかると答えました。コードを読まないと、「完全ではない」所がどこかを知りにくいのです。
- 「直してと頼んでは、また壊れる」循環。 あるブログ筆者は、直すたびに新しいエラーが生まれる、プロンプトの無限ループと呼びます。止まってコードを読むべきサインです。
- ツールは良くなっています。 ここでの限界は変わるかもしれませんが、誰が結果を負うかという考え方は変わりません。
9. 結論#
バイブコーディングは、アイデアが作る価値があるかを知る最も安い方法です。いちばん危ないのは、それが試作にすぎないことを忘れるときです。捨てられるものに使い、破棄日を書き、他の誰かが頼る前にチェックリストを使いましょう。
今すぐ試すなら：自分の問題を3文で書き、AIで画面を1つ作り、同じ日に3人に見てもらってください。
参考資料#
よくある質問
- バイブコーディングとは何で、AI支援のプログラミングとどう違いますか
- 2025年2月にアンドレイ・カルパシーが示した本来の意味では、AIにすべて書かせ、コードを細かく読まないことです。サイモン・ウィリソンは、コードをレビューし、テストし、説明できるなら、それはバイブコーディングではなくAI支援のプログラミングだと強調しています。線引きは、吟味するかどうかです。
- どんなときにプロトタイプをバイブコーディングで作るべきですか
- 製品が使い捨てで、結果を負うのが自分か数人の知人だけのとき：アイデアの検証、デモ、個人用ツール、複数の画面案の試作。実データ、ログイン、お金がなければ、失敗はまだ安いです。
- バイブコーディングが危険なのはどんなときですか
- 実際の利用者、個人データ、ログイン、決済、多数の利用があるときです。たとえばCVE-2025-48757は、Lovableというツールが生成したアプリで行レベルセキュリティのポリシーが欠けていた問題で、セキュリティ会社は170超のアプリが影響を受けたと報告しています。この数字は第三者の公表なので、慎重に読んでください。
- プロトタイプを安全な製品にするには
- 書き直すか、強化するかをはっきり決めます。強化するなら、ログインと権限、入力チェック、秘密情報と鍵、テスト、ログ、バックアップとデータへのアクセス制限のチェックリストを通し、コードを読める人にレビューしてもらいます。多くのチームは中核を書き直し、画面と学びを残します。