バイブコーディングのセキュリティを徹底解説！事故例と安全に使う条件も紹介
AIに日本語で頼むだけでアプリが形になるバイブコーディングで、試作品が半日で動くようになりました。一方で、AIが本番のデータを消した事例やAI製のサービスから情報が漏れた事例の報道も海外から届きます。社内で勧めてよいのか、止めるべきなのか、判断を任されて迷っていないでしょうか。
この記事では、バイブコーディングで実際に起きた事故・AI生成コードのリスクに関する研究・安全に使う条件と会社としての線引きを、当事者や公的機関の一次情報に基づいて解説します。
記事を読めば、禁止か放任かの二択ではない現実的なルールを作れるはずです。結論から言うと、事故の原因はAIそのものではなく確認を省く運用にあります。条件を整えれば試作の道具として十分に安全へ寄せられる、が本記事の答えです。
バイブコーディングのセキュリティリスクとは【動くことと安全は別物】
まず前提を以下の3つで押さえます。
- 完成して動くことは安全の証明にならない
- 研究では生成コードの約半数に欠陥が見つかっている
- 危険の正体はAIではなく確認を省く運用
完成して動くことは安全の証明にならない
バイブコーディングの怖さは、素人目には成功にしか見えないことです。画面が表示され、ボタンが動き、データが保存される。それでも、外部から悪用できる穴が開いたままの場合があります。
セキュリティの欠陥は、正常な使い方では表面に出ません。「作れた」と「公開してよい」の間に検証の工程が必要になる点は、人間が作るシステムと変わらない原則です。エラーが出ないことと、悪用できる入口がないことは、確かめ方がまったく別だからです。
研究では生成コードの約半数に欠陥が見つかっている
AI生成コードの品質は、複数の研究で繰り返し調べられています。ジョージタウン大学の研究機関CSETは、5つのAIモデルが生成したコード断片の約半数に影響の大きい不具合が含まれたと報告しました。ニューヨーク大学の研究チームによる約1,700件の生成プログラムの検証でも、約4割に脆弱性が見つかる結果でした。セキュリティ企業Veracodeの2025年の調査でも、生成コードの45%が安全性の検査に不合格と報告されています。
さらにスタンフォード大学の研究では、AI支援を使った人の方が安全でないコードを書きやすく、しかも自分のコードを安全だと過信する傾向まで確認されました。「AIが優秀だから大丈夫」という感覚こそが、測定された危険要因です。
危険の正体はAIではなく確認を省く運用
研究が示すのは「AIのコードは一定の割合で欠陥を含む」という事実で、これは人間の初心者にも当てはまります。違いは、バイブコーディングでは確認できる人が最初から関与しない運用が起きやすいことです。
つまりリスクの中心は、生成の速さに検証が追いつかないまま公開してしまう運用にあります。人間の新人が書いたコードを無確認で公開する会社がないのと同じで、書き手がAIになっても検証の必要性は変わりません。禁止ではなく、確認の工程を組み込んだ条件付きの利用が現実解です。
バイブコーディングで実際に起きた事故3例
危険は想像上の話ではありません。当事者や調査企業の一次発表がある事故を3つ紹介します。
- AIエージェントが本番のデータベースを削除した
- 認証の抜け穴から非公開アプリに入れる状態だった
- AI任せで作られたサービスから認証情報150万件が露出した
AIエージェントが本番のデータベースを削除した
2025年7月、米国の投資家Jason Lemkin氏が自身の記事で事故を公表しました。開発サービスReplitのAIエージェントにバイブコーディングを試したところ、AIが本番のデータベースを削除したのです。消えた記録は役員1,200件超・企業1,100件超にのぼります。操作を止める指示を11回繰り返していたにもかかわらず実行されたと氏は書いています。削除の直後には「復旧できない」という誤った案内まで受けたとされ、実際には復旧できたことも後から分かりました。
Lemkin氏の記事によると、Replit側はこの後に開発用と本番用のデータベース分離や、ワンクリックで巻き戻せる仕組みを実装しました。「試す環境」と「本番」を分けていれば起きなかった事故が、最大の教訓です。
認証の抜け穴から非公開アプリに入れる状態だった
2025年7月、セキュリティ企業Wizは、バイブコーディング基盤のBase44に認証の欠陥があったと公表しました。公開情報だけを使って本人確認の仕組みを迂回でき、企業の非公開アプリへ入れる状態だったのです。Base44はWixが買収した利用者の多い有名サービスで、アプリを作った企業の側に落ち度はありませんでした。
報告の翌日には運営元が修正し、悪用の痕跡はなかったと発表されています。利用者側に落ち度がなくても、土台のサービス側の欠陥で全アプリが危険にさらされる構図を示した事例です。
AI任せで作られたサービスから認証情報150万件が露出した
2026年に入り、Wizは「コードを1行も書かなかった」と創設者が公言するAIエージェント向けサービスMoltbookの調査結果を公表しました。データベースの保護設定は無効のまま公開されていたのです。調査結果によると、API認証トークン約150万件・メールアドレス約3.5万件・非公開メッセージが誰でも読み書きできる状態でした。
報告から数時間で保護が完了し、悪用の報告もない状況です。話題性のあるサービスでも、公開前の基本設定の確認が抜け落ちる。バイブコーディングの負の面が最も分かりやすく出た事例です。
事故を防ぐ4つの条件【社内ルールに落とす】
3つの事故に共通する原因を裏返すと、以下の4つの条件になります。
- 本番のデータがある場所で試さない
- 秘密情報をAIに書かせない・置かせない
- 公開前に人の確認を必ず挟む
- ツールの安全機構を切らずに使う
本番のデータがある場所で試さない
バイブコーディングは、消えて困るものがない練習用の環境で行うのが大前提です。Replitの事故は、試行錯誤の場に本番のデータベースが同居していたことで被害が実害になりました。
試す環境と本番の分離は、AI以前からのシステム運用の基本でもあります。非エンジニアが試す場合は「このフォルダ・このデータなら全部消えても困らない」状態を先に作ってから始めてください。
秘密情報をAIに書かせない・置かせない
APIキーやパスワードのような秘密情報をコードへ直接書く形は、AI生成コードで起きやすい定番の欠陥です。Moltbookの事故でも、認証情報が外から見える場所に置かれていたことが被害を広げました。
「秘密の値はコードに直接書かない」を指示に含め、生成物に秘密情報らしき文字列が埋まっていないかを公開前の確認項目にしてください。この1項目だけで、事故の大きな部分を防げます。
公開前に人の確認を必ず挟む
外部に公開するものは、公開前にコードを読める人の確認を通します。確認の観点には、IPA（情報処理推進機構）が公開する「安全なウェブサイトの作り方」のような公的な基準がそのまま使えます。この資料は、データベースへ不正な命令を混ぜ込む攻撃や偽の入力画面の埋め込みなど、Webサービスで定番の欠陥への対処を一覧にした内容です。
社内に確認できる人がいない場合、「公開してよい体制がまだない」という判断材料になります。IPAの10大脅威2026でもAI利用のリスクが組織向け3位に初選出されており、公開物の検証は会社の責任範囲と考えてください。
ツールの安全機構を切らずに使う
Claude CodeやCodexのような主要なAI開発ツールには、ファイル変更やコマンド実行の前に承認を求める仕組みと、作業範囲を隔離するサンドボックスが標準で備わっています。公式ドキュメントは、承認前の確認は利用者の責任と明記しています。
Codexの場合は、外部との通信が最初から遮断されていて、必要なときだけ許可する設計です。事故への近道は、確認が面倒だからと全自動の設定に切り替えて放置する使い方にほかなりません。既定の安全設定のまま使い、承認の場面では内容を読む。この基本だけで、ツール側の防御は十分に働きます。
Claude Codeのサンドボックスを徹底解説！仕組みと設定・Windows対応も紹介
会社としての線引き【任せてよい範囲】
導入判断は、以下の2つの線引きで考えると迷いません。
- 社内の試作・検証には積極的に使ってよい
- 顧客データを扱う公開システムは専門家の関与を条件にする
社内の試作・検証には積極的に使ってよい
業務ツールの試作・アイデアの検証・自分専用の作業効率化のような「社内で閉じた低リスクの用途」は、バイブコーディングの利点が最も生きる領域です。失敗しても被害が個人の時間で収まるため、前節の条件を守れば積極的に使って構いません。
試作の段階では完璧を求めず、うまくいったものだけを本格開発の検討に上げる。この二段構えは、セキュリティだけでなく開発投資の失敗を減らす効果もあります。
顧客データを扱う公開システムは専門家の関与を条件にする
顧客情報・決済・外部公開を含むシステムは、事故が会社の信用問題に直結します。この領域では、バイブコーディングを禁止するのではなく、設計と公開前検証に専門家が関与することを条件にしてください。関与する専門家は社内の人材に限らず、外部の開発会社や診断サービスでも構いません。
Base44やMoltbookの事故は、いずれも「外部に公開され、他人のデータを預かる」段階で起きています。試作と公開の間に審査の関門を置くことが、会社としての現実的な線引きです。
生成AIのセキュリティを徹底解説！リスクの分類と会社でやるべき対策も紹介
バイブコーディングのセキュリティに関するよくある質問
判断で残りやすい疑問へ、3つ回答します。
- バイブコーディングは禁止すべきですか？
- 非エンジニアだけで作ったものを公開してよいですか？
- どのツールを選べば安全ですか？
バイブコーディングは禁止すべきですか？
禁止は勧めません。試作の速さの利点が大きく、禁止しても個人利用が水面下に潜るだけだからです。
推奨は「環境の分離・秘密情報の禁止・公開前確認・安全機構の維持」の4条件を付けた許可です。条件付きで公式に認める方が、実態の把握も教育もしやすくなります。既存の生成AI利用ルールがある会社なら、その中へ「開発利用の条件」の1節を足す形で始められます。
非エンジニアだけで作ったものを公開してよいですか？
社内限定・低リスクの用途なら問題ありません。外部公開や顧客データを扱うものは、公開前にコードを読める人の確認を挟んでください。
研究で確認された「自分のコードを安全だと過信する傾向」は、善意でも起きます。作った本人以外の目を通す仕組みは、個人の注意より確実です。
どのツールを選べば安全ですか？
「これを選べば安全」というツールはありません。どのツールでも、生成されたコードの検証が必要な点は共通です。
選ぶ基準にするなら、承認やサンドボックスのような安全機構が標準で備わり、その仕様を公式ドキュメントで公開しているツールを選んでください。安全性はツールの銘柄ではなく、機構と運用の組み合わせで決まります。
Claude Codeは危ない？安全性を徹底解説！事故を防ぐ最初の設定も紹介
バイブコーディングのセキュリティは「確認の工程」で確保できます
バイブコーディングの事故は、AIの能力不足ではなく、本番との同居・秘密情報の放置・確認なしの公開など運用の省略から起きています。研究でも生成コードの約半数に欠陥が見つかる以上、検証の工程を省く選択肢はない、が出発点です。
裏を返せば、環境を分けて秘密情報を遠ざけ、公開前に人の目を通してツールの安全機構を保てば試作の道具として安心して使えます。4つの条件はどれも、明日の社内ルールにそのまま書ける具体的な内容です。まずは「消えても困らない環境で試す」ところから、自社の条件付きルールを作りましょう。
