バイブコーディングで作ったアプリ、そのままデプロイしていい？ — プロンプトと本番のあいだの検証の空白

どんな問題か

バイブコーディングの約束は単純だ。言葉で説明すればアプリが出てくる。デザイナーもマーケターもコードを一行も書かずに動くソフトウェアを作る。問題は「動く」と「デプロイしてよい」がまったく別の話だという点にある。カーネギーメロンの研究では、AI生成コードの61%は正しく動いたが、セキュリティレビューを通ったのは10.5%だけだった。非開発者にはこの隔たりを見る目がない。画面に結果が出れば終わったと思う。その裏でハードコードされたデータベースのパスワードが入っているか、入力チェックが抜けてインジェクションが開いているか、そもそも存在しないパッケージ名をimportしているかは見えない。Escape.techが5,600件のバイブコーディングアプリを調べると、400件超のシークレットと175件の個人情報がそのまま露出していた。作った本人はそれを知らずに「デプロイ」を押した。

なぜ今か

ツールはすでに大衆化したのに、それを止める関門がない。Stack Overflowの2025年開発者調査では、AIツールを使うか使う予定だという回答が84%まで上がったが、AIの正確さを信頼するという回答は33%に落ち、積極的に不信だという側が46%でより多かった。プロの開発者ですら「ほぼ正しいが正確には違う」コード（回答者の66%が指摘）と格闘している。非開発者にはこれを選り分けるツールが端からない。同時にリスクは測れる速さで膨らんでいる。ジョージア工科大のVibe Security Radarは、AI生成コード由来のCVEが2025年5月の6件から2026年3月には74件に増えたと集計した。ガートナーは2028年までにプロンプト・トゥ・アプローチがソフトウェアの欠陥を2,500%増やすと見ている。作るのは楽になるのに検証はそのままなら、その隙間がそのまま事業になる。

どう作るか

非開発者がデプロイボタンを押す、まさにその地点にゲートを差し込む。既存のSAST・シークレットスキャナを非開発者向けに翻訳するのが肝だ。CVE番号やCWEコードを突きつけてはいけない。「データベースのパスワードがコードにそのまま書かれています。このまま上げると誰でも見られます — 直して上げますか？」のように、リスクを人の言葉に変え、ワンクリックの自動修正まで提案する。統合点はデプロイフックだ。Vercel・Netlify・Firebase・Replitのデプロイ直前に割り込み、通らないビルドを止める。差別化は三つ。ハードコードシークレット・インジェクション・幻覚パッケージ（223万サンプルのうち19.7%が存在しないパッケージ名を含んでいた）のように、バイブコーディングが特に出しやすい欠陥に特化したルールセット、非開発者が読んですぐ動けるレポート、そして止めるだけでなく直す自動リメディエーション。

成功の条件

これは開発者向けセキュリティツールのコピーになった瞬間に死ぬ。SnykもSemgrepもすでにある。生き残るには「コードを読めない人」を唯一の顧客に固定するしかない。営業はバイブコーディングのプラットフォームそのものに向ける — 彼らは自分のユーザーが事故を起こすのを恐れるので、検証ゲートを標準で組み込みたがる。だからB2B2CでプラットフォームにOEM供給する道がいちばん速い。リスクは明白だ。ReplitやLovableのようなプラットフォームがこの機能を自前で内蔵すると市場が蒸発する。だから一つのベンダーに縛られない横断的な標準と、複数のツールを行き来する非開発者（午前はLovable、午後はBolt）を追いかけるアカウント単位の検証履歴で陣地を先に取る。ゲートが厳しすぎてまともなデプロイまで止めると、非開発者はただ切ってしまう。誤検知をゼロに収束させることが生存線だ。