AIに指示するだけでアプリが作れる！
このようなイメージでバイブコーディング（AI駆動開発）の失敗事例7選｜リスクと対策を完全解説！は、プログラミング経験がなくてもシステムを開発できる手法として注目を集めています。
しかし、2025年後半から2026年にかけて、バイブコーディングで作られたサービスのセキュリティ事故や開発プロジェクトの破綻事例が相次いで報告されています。
この記事では、実際に起きた事故や公開されている研究データをもとに、バイブコーディングの失敗事例を7つ紹介します。
「どんなリスクがあるのか」
「自分も同じ失敗をしないためにはどうすればいいか」
について、エンジニアではない方にもわかるように解説します。
なお、本記事では出典が明確な事例・研究データのみを扱い、裏付けのない情報は掲載していません。
Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら
執筆者：山口 鳳汰
累計100万PV以上のAI・ノーコード専門メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。
その他、受託開発や教育など多数のノーコード事業に参画している。
運営会社：株式会社Walkers
AI・ノーコード専門の開発会社。
300件以上の開発/制作実績、200件以上の企業様を支援。
マーケティングやUI/UXと掛け合わせたサービス開発を得意としている。
執筆者：山口 鳳汰
累計100万PV以上のAI・ノーコード専門メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。
運営会社：株式会社Walkers
AI・ノーコード専門の開発会社。
これまでに300件以上の開発/制作実績、200件以上の企業様を支援。
バイブコーディング（AI駆動開発）の失敗事例7選
【失敗事例①】 72,000件の個人情報が丸見えに（Tea社データ漏洩事件）
何が起きたか
女性向けデートアプリ「Tea」で、バックエンドのデータベースがパスワードも暗号化もない状態で公開されていることが発覚しました。
72,000枚以上の本人確認用セルフィーと、13,000枚以上の運転免許証・パスポートなどの身分証明書が流出。
さらに、100万件以上のダイレクトメッセージも第二の漏洩で流出しました。
なぜ起きたか
データベース（Firebase）のセキュリティポリシーが手動で設定されていなかったことが原因です。
セキュリティ専門家によれば、この脆弱性はブラウザの開発者ツールを開くだけで発見できる程度のものでした。
この失敗から学べる教訓（筆者の意見）
AIは「動くコード」は生成できても、「安全なコード」を保証するわけではありません。
個人情報やログイン機能を含むサービスを公開する前には、必ずセキュリティ専門家のチェックを入れるべきです。
「動いたから大丈夫」ではなく、「チェックを通ったから大丈夫」が正しい判断基準です。
»出典1：Decrypt – Tea App That Claimed to Protect Women Exposes 72,000 IDs
»出典2：Digital Watch Observatory
»出典3：Barracuda Networks Blog – Vibe coding and the Tea app breach
【失敗事例②】 バイブコーディングで作られたアプリの「5つに1つ」に重大な脆弱性（Wiz社調査）
何が起きたか
クラウドセキュリティ企業のWiz社が、バイブコーディングプラットフォームで生成されたアプリケーションのセキュリティ状態を調査しました。
その結果、約20%に深刻な脆弱性や設定ミスが見つかりました。
具体的には、以下の4種類の問題が多く確認されています。
| 問題の種類 | 非エンジニア向けの説明 |
|---|---|
| クライアントサイド認証 | ログイン確認をユーザーの端末側だけで行っており、簡単にすり抜けられる |
| 秘密情報のハードコード | APIキーやパスワードがコードに直接書かれ、誰でも見られる |
| 不適切なデータアクセス設定 | 本来見えてはいけないデータが他のユーザーから閲覧可能 |
| 内部アプリの外部公開 | 社内向けツールがインターネット上に公開されてしまう |
なぜ起きたか
バイブコーディングでは、AIが「動く機能」の実装を優先し、認証やアクセス制御の設定を省略しがちです。
また、非エンジニアがセキュリティ設定の妥当性を判断するのは困難なため、AIの出力をそのまま受け入れてしまうケースが多いと考えられます。
この失敗から学べる教訓（筆者の意見）
「公開前にセキュリティチェックを入れる」という1工程を追加するだけで、これらの問題の大部分は防げます。
バイブコーディングで作ったものを「そのままリリース」するのではなく、「チェックしてからリリース」を開発フローに組み込むことが重要です。
»出典：Wiz Blog – Common Security Risks in Vibe-Coded Apps
【失敗事例③】 AIがエラーを直すとき、セキュリティ機能まで勝手に削除してしまう
何が起きたか
AIにコードのエラー修正を頼むと、エラーの原因を取り除くために、本来削除してはいけない「セキュリティ機能」まで消してしまうことがあります。
たとえるなら、「ドアの鍵が固くて開かない」という相談に対して、AIが「鍵ごと外しました。これでスムーズに開きます」と対応してしまうようなものです。
実際に報告されている例としては、以下のようなものがあります。
- ログイン機能の削除: 「ログインでエラーが出る」→ ログイン機能ごと外して、誰でもアクセスできる状態にしてしまう
- 入力チェックの削除: 「フォームでエラーが出る」→ 不正な入力を防ぐチェック機能を外してしまう
- データベースの保護設定の解除: 「データが読み込めない」→ アクセス制限を外して、誰でもデータを見られる状態にしてしまう
なぜ起きたか
AIはコードの「目的」や「意味」を理解しているわけではありません。
AIにとっての最優先事項は「エラーメッセージを消すこと」です。
セキュリティ機能がエラーの原因になっている場合、AIは「この部分を消せばエラーが消える」と判断し、セキュリティ機能ごと削除してしまいます。
人間なら「これは大事な機能だから消してはいけない」と判断できますが、AIにはその区別がつきません。
この失敗から学べる教訓（筆者の意見）
「エラーが消えた」からといって、「正しく直った」とは限りません。
AIがコードを修正したら、「何が変わったのか」を必ず確認しましょう。
特に、ログイン機能やアクセス制限に関わる部分が変更されていないかは要チェックです。
自分で判断できない場合は、エンジニアに確認を依頼しましょう。
»出典1：Kaspersky – Security risks of vibe coding
»出典2：Aikido Security – Vibe Coding Security
【失敗事例④】 最初の1週間は天国、その後は地獄（個人開発者の1ヶ月体験記）
何が起きたか
あるエンジニアがClaude Code（月額約100ドルのAI開発ツール）に課金し、1ヶ月間バイブコーディングだけで開発を行う実験を行いました。
- 最初の1週間: UIコンポーネントの生成やデプロイが高速で完了。デモアプリが1週間で完成し、生産性の高さを実感
- 2週目以降: 新機能を追加するたびに、既存の機能が壊れるデグレード（退行）が頻発。AIが「修正完了」と報告しても、実際には直っていないケースが多発。コードの約2割に、同じ処理が微妙に異なる方法で複数箇所に書かれるなどの問題が蓄積
なぜ起きたか
AIは会話のたびにコードの全体像を把握し直す必要がありますが、プロジェクトが大きくなるとその精度が下がります。
新しい機能を追加する際に既存コードとの整合性を保てず、同じ処理を別の書き方で複数箇所に生成してしまいます。
こうしたコードの重複や不整合が蓄積した結果、「1箇所を直すと別の箇所が壊れる」状態に陥りました。
この失敗から学べる教訓（筆者の意見）
この体験記の著者も「バイブコーディングはプロトタイプや概念実証には最適だが、本番運用には向かない。完全にAIに任せきるとツケを払うことになる」と結論づけています。
最初の1週間の成功体験で「このまま全部作れる」と判断するのは早計です。
本番運用に進む前に「このまま進めて大丈夫か」を立ち止まって判断するタイミングを設けましょう。
【失敗事例⑤】 3ヶ月後にスケーリングできず破綻
何が起きたか
小規模なバイブコーディングプロジェクトは最初の数ヶ月は順調に進むものの、システムの拡張段階で問題が顕在化するパターンが報告されています。
具体的には「1つの変更を加えただけで、他の機能が壊れてしまう」状態に陥ります。
なぜ起きたか
バイブコーディングでは、プロンプト（AIへの指示文）ベースで機能を追加していくため、システム全体の設計図（アーキテクチャ）が不在のまま開発が進みます。
小さい段階では問題になりませんが、機能が増えるにつれて、コード同士の依存関係が把握できなくなり制御不能に陥ります。
この失敗から学べる教訓（筆者の意見）
「小さく作って検証する」戦略は正しいですが、バイブコーディングで作った初期版を「そのまま拡大」してはいけません。
スケールさせる段階では、エンジニアによる設計の見直しが必要になることを最初から想定しておくべきです。
»出典：マイナビTECH+ – エキサイティングなバイブコーディングが3カ月後に破綻しないために必要なスキルとは
【失敗事例⑥】 「速くなった」と思ったら、実は19%遅くなっていた（METR研究）
何が起きたか
AI安全性の研究機関METR（Model Evaluation & Threat Research）が2025年に発表したランダム化比較試験（RCT）の結果は、多くの開発者の直感に反するものでした。
| 項目 | 数値 |
|---|---|
| 対象 | 経験豊富なオープンソース開発者16名（平均5年以上の経験） |
| タスク数 | 246タスク（各タスク平均2時間） |
| 開発者の事前予測 | 「AIで24%速くなる」 |
| 開発者の事後評価 | 「AIで20%速くなった」 |
| 実測値 | AIを使った方が19%遅かった |
つまり、開発者自身は「速くなった」と感じているのに、客観的に測定すると遅くなっていたのです。
なぜ起きたか
研究チームは、AIツールの導入による認知負荷の増加やコンテキストスイッチ（AIの出力確認と自分の作業の行き来）が生産性を下げていると分析しています。
また、画面録画データからは、AI利用時にアイドル時間（何もしていない時間）が増えていることも確認されました。
この失敗から学べる教訓（筆者の意見）
「AIで開発スピードが上がる」という前提でプロジェクト計画を立てるのは危険です。
体感と実測にズレがあることを認識し、AI導入後も客観的な進捗測定を行うことが、計画の破綻を防ぎます。
»出典1：METR Blog
»出典2：論文: arXiv:2507.09089
【失敗事例⑦】 「安全なコードを書いた」という思い込み（Stanford大学研究）
何が起きたか
Stanford大学のNeil Perry氏らの研究チーム（Dan Boneh教授研究室）が2023年に発表した論文「Do Users Write More Insecure Code with AI Assistants?」では、47名の参加者に対してセキュリティ関連のプログラミングタスクを実施する実験が行われました。
主な発見は以下の通りです。
- AIアシスタントを使ったグループは、使わなかったグループよりもセキュリティ上安全でないコードを書いた
- にもかかわらず、AIを使ったグループの方が「自分のコードは安全だ」と信じる傾向が強かった
なぜ起きたか
AIが生成したコードには一定の「それらしさ」があるため、利用者は出力結果を信頼しやすくなります。
特にセキュリティの知識がない場合、コードに問題があるかどうかの判断自体が困難です。
結果として、「AIが書いたから大丈夫」という根拠のない安心感が生まれます。
この失敗から学べる教訓（筆者の意見）
「AIが書いたコードだから安全」という思い込みは、最も危険なバイアスです。
バイブコーディングでは特に、自分でコードの安全性を判断できない以上、「わからないものは専門家に見てもらう」という原則を徹底する必要があります。
»出典1：Perry et al., ACM CCS 2023
»出典2：Stanford Electrical Engineering
バイブコーディング（AI駆動開発）で失敗が起こる3つの根本原因
【原因①】 コードがブラックボックス化する
上記の失敗事例に共通するのは、「コードの中身がわからないまま進めた」 という点です。
エンジニアであれば、AIが生成したコードに明らかなセキュリティホールがあれば気づけます。
しかし、非エンジニアにはその判断基準がありません。
失敗事例①〜③で見たように、データベースの設定ミスやセキュリティ機能の無効化が起きても、コードを読めなければ発見しようがないのです。
これはバイブコーディングの「コードを理解しなくてよい」という思想と本質的に矛盾しており、ビジネスで使う場合の最大のリスクポイントです。
【原因②】 「動いている＝安全」という誤解
バイブコーディングで最も危険な思い込みは、「画面上で動いているから、問題ないはず」 というものです。
失敗事例①のTea社のケースでも、アプリ自体は正常に動作していました。
しかし裏側では、72,000件以上の個人情報が誰でもアクセスできる状態で放置されていたのです。
失敗事例③のように、AIがエラーを解消するために安全装置を外してしまっても、見た目上は「正常に動く」ため気づけません。
「動く」ことと「安全である」ことは、まったく別の問題です。
【原因③】 初期の成功体験が過信を生む
失敗事例④〜⑦に共通するのは、最初はうまくいった経験が、判断を狂わせるという構造です。
失敗事例④では最初の1週間は高い生産性を実感し、失敗事例⑥のMETR研究では開発者自身が「速くなった」と感じていたにもかかわらず実測値は19%遅くなっていました。
失敗事例⑦のStanford研究でも、AIを使ったグループほど「自分のコードは安全だ」と信じていました。
この「根拠のない自信」が、セキュリティレビューの省略やエンジニアへの相談の先延ばしにつながり、失敗事例⑤のような3ヶ月後の破綻を招きます。
バイブコーディング（AI駆動開発）で失敗しないための5つの対策
【対策①】 プロトタイプ用途に限定する
バイブコーディングが最も力を発揮するのは、アイデアの検証段階です。
「こういうサービスは需要があるか？」を素早く確かめるためのプロトタイプ作成には適しています。
ただし、そのプロトタイプをそのまま本番サービスとして公開するのは避けましょう。
【対策②】 セキュリティレビューを必ず入れる
ユーザーの個人情報やログイン機能を含むサービスでは、公開前にセキュリティの専門家によるレビューを受けることを強く推奨します。
Wiz社の調査が示すように、バイブコーディングで作られたアプリの5つに1つに重大な問題があるという現実を踏まえれば、このコストは十分に正当化されます。
【対策③】 エンジニアとの協業体制をつくる
バイブコーディングは「エンジニア不要」の技術ではなく、「エンジニアの役割が変わる」 技術です。
コードを書く作業はAIに任せつつ、設計・レビュー・セキュリティチェックは人間が担当する体制が現実的です。
【対策④】 AIに指示する前に「何を作るか」を書き出しておく
バイブコーディングでありがちな失敗は、思いつきでAIに指示を出し続けた結果、全体の整合性が取れなくなることです。
これを防ぐには、AIに指示を出す前に「どんな機能が必要か」「どんなデータを扱うか」「やってはいけないことは何か」を箇条書きでもいいので書き出しておくことが有効です。
料理にたとえるなら、レシピなしで「なんとなく美味しいもの作って」と頼むのではなく、「材料はこれ、味付けはこう、アレルギー食材は使わないで」と伝えるイメージです。
【対策⑤】 「AIに丸投げ」から「AIを監督する」スタイルへ移行する
バイブコーディングの名付け親であるカーパシー氏自身が、2026年に入り「エージェンティックエンジニアリング」という次のステップを提唱しています。
簡単にいうと、これまでのバイブコーディングが「AIに作業を丸投げする」スタイルだったのに対し、人間が監督者の立場に立ち、AIに具体的な指示を出しながら開発を進めるスタイルです。
バイブコーディングの「便利だけど危険」という限界を、提唱者自身が認めた上での進化形といえます。
»出典：Business Insider Japan – 「バイブコーディング」の名付け親、次は「エージェンティックエンジニアリング」だと語る
バイブコーディング（AI駆動開発）はアイデアを素早く形にできる強力な手法ですが、使い方を誤れば深刻なセキュリティ事故や、修復困難な技術的負債を生み出します。
ぜひ皆さんは先人の事例から学び、失敗しないように有効活用いただければと思います。
Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。
