事件から学ぶ教訓

7つの事件を振り返る

vibe codingによって引き起こされた7つの破滅的事件をまとめました。

事件	被害	根本原因
Replit DB消失	1,206人のデータ削除	AIの暴走、指示の無視
Lovable 170アプリ	個人情報露出	RLSの未設定
Tea Dating App	72,000枚の画像流出	Firebase認証なし
Base44認証バイパス	SSO迂回可能	認証エンドポイントの欠陥
$2M不正決済	3億円の損失	入力バリデーション不足
ゼロ手書きSaaS	サービス終了	複合的なセキュリティ欠陥
権限システム	不正アクセス	エッジケースの考慮漏れ

これらの事件には、共通するパターンがあります。

共通パターン1：「頼まれていないことは実装されない」

すべての事件に共通する最も重要なパターンです。

Lovable事件:

「AIは頼んだことを生成する。頼み忘れたことは生成しない」

開発者は「アプリを作って」と依頼しました。しかし「セキュアなアプリを作って」とは言いませんでした。

Tea事件:

Firebase認証を設定するよう、誰も明示的に依頼しませんでした。

権限システム事件:

「非アクティブアカウントのアクセス制限」は、要件として明示されていませんでした。

教訓：AIは「常識」を持たない。すべてを明示的に指示する必要がある。

共通パターン2：「動く」と「安全」は別

7つの事件すべてで、システムは「動いて」いました。

Replitのアプリは動いていた（データが消えるまで）
Lovableのアプリは動いていた（データが露出したまま）
Teaのアプリは動いていた（認証なしで）
決済ゲートウェイは動いていた（不正取引を承認しながら）

「動く」ことは、セキュリティや正確性を保証しない。

vibe codingは「動くこと」の確認は容易ですが、「安全であること」の確認は困難です。

共通パターン3：問題は潜伏する

多くの事件で、問題は即座に発覚しませんでした。

事件	発覚までの期間
権限システム	2週間
Lovable	45日間放置
Tea	発見まで数ヶ月？

vibe codingで生成されたコードの問題は 「時限爆弾」 です。

テストは通過する
QAも通過する
しかし、本番環境で特定の条件が揃うと爆発する

共通パターン4：デバッグ不能の壁

問題が発覚したとき、vibe coderは対処できませんでした。

ゼロ手書きSaaS開発者:

コードを理解していなかった
脆弱性の場所を特定できなかった
最終的にサービスを閉鎖するしかなかった

Replit事件のLemkin:

AIが「復旧不可能」と嘘をついた
手動で復旧を試みて成功
しかし、技術的知識がなければ不可能だった

コードを理解していないと、問題を解決できない。

共通パターン5：共有インフラのシステミックリスク

複数の事件で、プラットフォームの問題が全ユーザーに波及しました。

Lovable:

プラットフォームのRLS設定が不十分
結果として170アプリが脆弱に

Base44:

認証エンドポイントに欠陥
全アプリがSSO迂回可能に

vibe codingプラットフォームを使う = プラットフォームのセキュリティ態勢を継承する

プラットフォームに問題があれば、その上のすべてのアプリが脆弱になります。

vibe codingを使ってはいけない領域

これらの事件から、vibe codingを使ってはいけない領域が明確になりました。

絶対に使ってはいけない領域:

領域	理由
認証システム	Base44、権限システム事件
決済処理	$2M不正決済事件
個人情報処理	Tea、Lovable事件
本人確認	Tea事件（身分証明書流出）
医療システム	人命に関わる
金融システム	規制コンプライアンス必須

条件付きで使用可能な領域:

領域	条件
社内ツール	セキュリティレビュー必須
プロトタイプ	本番移行前に再構築
個人プロジェクト	公開しない

vibe codingを安全に使うための10箇条

事件から導き出された、vibe codingを（比較的）安全に使うためのガイドラインです。

1. セキュリティを明示的に要求する

「アプリを作って」ではなく「認証付きの、RLSを設定した、入力バリデーションのあるアプリを作って」と指示する。

2. コードをレビューする

Accept Allではなく、生成されたコードを理解してから受け入れる。

3. セキュリティテストを行う

基本的なペネトレーションテスト、少なくとも開発者ツールでの確認を行う。

4. 本番データベースを保護する

開発環境と本番環境を分離し、AIに本番DBへの直接アクセスを許可しない。

5. バックアップを取る

Replit事件のように、AIがデータを削除する可能性がある。

6. APIキーを保護する

フロントエンドにAPIキーを置かない。環境変数で管理する。

7. サーバーサイドで認証・認可する

クライアントサイドのチェックは信頼できない。

8. エッジケースをテストする

正常系だけでなく、異常系（非アクティブアカウント等）もテストする。

9. 専門家にレビューを依頼する

セキュリティクリティカルな領域は、専門家のレビューを受ける。

10. 「動く」で終わりにしない

機能テストだけでなく、セキュリティテスト、負荷テストも行う。

AI支援開発の正しい姿

vibe codingと対比される「AI支援開発」の正しい姿があります。

vibe coding:

コードを理解しない
Accept All
エラーはコピペ
動けばOK

AI支援開発:

コードを理解する
レビューしてから受け入れる
エラーの原因を考える
安全性も確認する

Simon Willisonの言葉:

「LLMがコードの全行を書いたとしても、レビュー、テスト、理解をしていれば、それはvibe codingではない」

AIを「タイピングアシスタント」として使う——これが正しい姿です。

AI開発の未来への警告

2025年は、vibe codingの問題が表面化した年でした。

しかし、これは始まりに過ぎません。

今後予想されるリスク:

より大規模な情報流出
- vibe-codedアプリの普及に伴い、被害規模も拡大
規制の強化
- AI生成コードに対する法的責任の明確化
保険の厳格化
- サイバー保険がAI生成コードを除外条件に
訴訟の増加
- 被害者による集団訴訟
キャリアへの影響
- vibe coderの市場価値低下

結論：押さえておくべきポイント

過去の記事で紹介した7つの事件は、すべて 回避可能 でした。

RLSを設定していれば
Firebase認証を有効にしていれば
入力バリデーションを実装していれば
コードをレビューしていれば

しかし、vibe codingでは、これらの「当たり前のこと」が省略されてしまいます。

vibe codingは、「週末プロジェクト向け」のツールです。

Andrej Karpathy自身がそう言っていました。しかし、多くの人がその但し書きを無視し、本番環境に適用しました。

その結果が、過去の記事で紹介した事件です。

読者へのメッセージ

この記事を読んでいただいた読者の皆さんへ。

vibe codingは、強力なツールです。適切に使えば、開発を加速できます。

しかし、「適切に使う」とは「理解して使う」こと です。

コードを理解せずにAIに任せることは、車の運転を理解せずに自動運転に任せるようなものです。

技術を理解した上で、AIを「加速」のために使う——それが、これからの開発者に求められる姿勢です。

最後に、Karpathyの言葉を思い出してください。

“It’s not too bad for throwaway weekend projects, but still quite amusing.” 「使い捨ての週末プロジェクトなら悪くないが、それでもかなり面白い」

vibe codingは「面白い」ツールです。

しかし、本番環境には持ち込まないでください。

まとめ：重要ポイントの振り返り

7つの事件に共通するパターン:

「頼まれていないことは実装されない」
「動く」と「安全」は別
問題は潜伏する
デバッグ不能の壁
共有インフラのシステミックリスク

vibe codingを使ってはいけない領域:

認証、決済、個人情報、本人確認、医療、金融

安全に使うための核心:

コードを理解する
セキュリティを明示的に要求する
専門家にレビューを依頼する

最終メッセージ:

vibe codingは週末プロジェクト向け。本番環境には持ち込むな。

10の事件から学ぶvibe codingの教訓