--- title: "バイブコーディングで1日でプロトタイプ：向く場面と危ない場面" url: https://www.thinnd.site/ja/purodakuto-shiko/vibe-coding-ichinichi-purototaipu/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "プロダクト思考" tags: ["バイブコーディング", "プロトタイプ", "AI", "プロダクト", "セキュリティ", "MVP"] summary: "バイブコーディング、つまりAIにコードを書かせて細かく読まないやり方は、使い捨てのプロトタイプに向いています：アイデアの検証、実際の人へのデモ、個人用ツール。実際の利用者、個人データ、ログイン、決済が入ると、誰も読まない部分に不具合が潜むため危険になります。規則：プロトタイプは使い捨てと考え、捨てる日を書き、セキュリティとテストのチェックリストを通してから本番環境に出す。" license: "Cite with the author name and the canonical URL above." --- # バイブコーディングで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. プロトタイプから製品へ：チェックリスト 残すと決めたら、次をすべて通るまで利用者を増やさないでください。 1. **ログインと権限。** 誰が誰のデータを読めるか？ 別のアカウントでログインして見る。 2. **データベースへのアクセス。** すべてのテーブルに行を絞るポリシーがあるか？ ログインなしでアクセスを試す。 3. **入力。** すべての入力欄がチェックされているか？ 4. **秘密情報。** APIキーやパスワードが、コード、ファイル、Gitの履歴にないか？ 5. **テスト。** 主な経路と変わったケースのテストがあるか？ コードが間違うと失敗するか？ 6. **ライブラリ。** すべて実在し、今も保守されているか？ 7. **バックアップと復旧。** データのバックアップがあり、復旧を試したか？ 8. **読む人。** 少なくとも1人がコードを読み、理解したか？ 詳しい一覧は[AIが書いたコードのレビュー](https://www.thinnd.site/ja/gijutsu/ai-ga-kaita-code-no-review/)にあります。多くのチームは**中核を書き直し**、画面とプロトタイプからの学びを残します。1か所ずつ繕うよりきれいなことが多いのです。 --- ## 7. バイブコーディングを安全にする3つの習慣 - **期限を決める。** 破棄する日を画面に書く。破棄日のないプロトタイプは製品になります。 - **ダミーデータを使う。** 確認していないツールに、顧客の実データを入れない。 - **本物のシステムから離す。** プロトタイプは本物のデータベース、決済、社内システムにつなげない。 --- ## 8. バランスの取れた見方 - **バイブコーディングがいつも速いわけではありません。** METRの研究（2025年7月）では、経験豊富な16人の開発者が、慣れたプロジェクトで2025年初めのAIツールを使うと約19%遅くなりました。本人たちは速くなったと信じていました。標本は小さくツールも変わっていますが、速く感じることは測定ではありません。 - **「ほぼ正しい」がいちばん厄介です。** Stack Overflowの2025年調査では、約66%が「ほぼ正しいが完全ではない」解に出会い、約45%がAI製コードのデバッグのほうが時間がかかると答えました。コードを読まないと、「完全ではない」所がどこかを知りにくいのです。 - **「直してと頼んでは、また壊れる」循環。** あるブログ筆者は、直すたびに新しいエラーが生まれる、プロンプトの無限ループと呼びます。止まってコードを読むべきサインです。 - **ツールは良くなっています。** ここでの限界は変わるかもしれませんが、**誰が結果を負うか**という考え方は変わりません。 --- ## 9. 結論 バイブコーディングは、アイデアが作る価値があるかを知る最も安い方法です。いちばん危ないのは、それが試作にすぎないことを忘れるときです。捨てられるものに使い、破棄日を書き、他の誰かが頼る前にチェックリストを使いましょう。 今すぐ試すなら：自分の問題を3文で書き、AIで画面を1つ作り、同じ日に3人に見てもらってください。 --- ## 参考資料 - [サイモン・ウィリソンのバイブコーディングについて](https://simonwillison.net/tags/vibe-coding/) - [Superblocks：Lovableの脆弱性、170超のアプリが露出](https://www.superblocks.com/blog/lovable-vulnerabilities) と [CVE-2025-48757の記録](https://cvemon.intruder.io/cves/CVE-2025-48757) - [Stack Overflow Developer Survey 2025、AIの章](https://survey.stackoverflow.co/2025/ai) - [METRの生産性研究についてのSimon Willisonの解説](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - ブログ内の関連記事：[AIが書いたコードのレビュー](https://www.thinnd.site/ja/gijutsu/ai-ga-kaita-code-no-review/)、[AIを鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)