「ゼロ手書き」SaaSの崩壊

誇らしげなツイート

ある開発者が、X（旧Twitter）でこう投稿しました。

“guys my saas was built with Cursor, zero hand written code” 「みんな、俺のSaaSはCursorで作った。手書きコードはゼロだ」

この投稿は多くの「いいね」を集めました。vibe codingの成功事例として、多くの人がリツイートしました。

「AIだけでSaaSを構築できる時代が来た」——そんな期待感が広がっていました。

しかし、数週間後、同じ開発者が別の投稿をすることになります。

パニックの投稿

数週間後、彼はこう投稿しました。

“guys, i’m under attack ever since I started to share how I built my Saas using Cursor random thing are happening, maxed out usage on api keys, people bypassing the subscription, creating random shit on db.” 「みんな、助けてくれ。CursorでSaaSを作った話を共有し始めてから、攻撃を受けている。APIキーの使用量が上限に達し、サブスクリプションをバイパスされ、DBに訳のわからないデータを書き込まれている」

彼のSaaSは、あらゆる方向から攻撃を受けていました。

発生した問題

彼が直面した問題を整理しましょう。

問題一覧:

問題	影響
APIキーの不正使用	使用量上限到達、高額請求
サブスクリプションバイパス	収益損失
データベースへの不正書き込み	データ汚染
サービス全体の不安定化	ユーザー離脱

これらの問題は、すべて セキュリティの基本が欠落していた ことに起因していました。

APIキーの露出

最初の問題は、APIキーの露出 でした。

vibe codingで生成されたコードでは、APIキーがフロントエンドのJavaScriptに直接埋め込まれていることがよくあります。

問題のあるコード例:

const API_KEY = "sk-xxxxxxxxxxxxxxxxxxxx";
fetch(`https://api.example.com/data?key=${API_KEY}`)

このようなコードは、ブラウザの開発者ツールで簡単に発見できます。

攻撃者はこのAPIキーを抽出し、自分のアプリケーションで使用しました。結果として、彼のAPIアカウントは使用量上限に達し、高額な請求が発生しました。

AI生成コードのサブスクリプションバイパス脆弱性

次の問題は、サブスクリプションのバイパス でした。

多くのvibe-codedアプリでは、支払い確認がクライアントサイドで行われています。

問題のあるパターン:

if (user.isPremium) {
  showPremiumContent();
} else {
  showPaywall();
}

このロジックは、ブラウザの開発者ツールで user.isPremium = true と書き換えるだけでバイパスできます。

彼のSaaSでも、同様の脆弱性が存在していました。有料機能が無料で使われていたのです。

AI生成コードによるデータベース不正アクセス

最も深刻だったのは、データベースへの不正アクセス でした。

vibe codingで生成されたアプリでは、Firebase や Supabase のセキュリティルールが適切に設定されていないことが多くあります。

結果:

攻撃者が任意のデータを書き込み可能
他のユーザーのデータを読み取り可能
データベースを「汚染」された

彼のデータベースには、攻撃者が書き込んだ「訳のわからないデータ」が大量に存在していました。

AI生成コードのデバッグ不能の壁

問題が発生したとき、彼は致命的な壁にぶつかりました。

彼はコードを理解していなかった。

「ゼロ手書きコード」で作ったSaaSは、彼自身にとってもブラックボックスでした。

直面した困難:

どこに脆弱性があるか分からない
どう修正すればいいか分からない
AIに聞いても的確な答えが得られない
セキュリティの専門家を雇う資金もない

vibe codingの最大の問題は、問題が発生したときに自分で対処できない ことです。

vibe codingプロジェクトのサービス終了

最終的に、彼は決断を下しました。

サービスの完全終了。

攻撃を止める方法が分からず、被害を拡大させないために、サービスを閉鎖するしかありませんでした。

「ゼロ手書きコード」で作られたSaaSは、わずか数週間で消滅しました。

「見えない複雑さのギャップ」

この事件は、ある重要な概念を浮き彫りにしました。

“The invisible complexity gap: the difference between ‘it works on my machine’ and ‘it’s secure in production.’” 「見えない複雑さのギャップ：『自分のマシンでは動く』と『本番環境で安全』の違い」

vibe codingで作られたアプリは、「動く」ことは確認できます。しかし、「安全である」ことは確認できません。

「動く」と「安全」は、まったく別のこと なのです。

SNSで成功を語る危険性

この事件には、もう一つの教訓があります。

彼は、vibe codingでSaaSを作ったことをSNSで公開しました。

これは、攻撃者に「このサービスはセキュリティが甘い可能性が高い」というシグナルを送ったことになります。

攻撃者の視点:

「vibe codingで作った」= セキュリティレビューされていない可能性
「手書きコードゼロ」= 開発者がコードを理解していない可能性
「Cursorだけで作った」= 脆弱性が存在する可能性

技術的な手法を公開することは、時として攻撃を招きます。

この事例から学ぶべき教訓

「ゼロ手書き」SaaS崩壊から学ぶべきことは以下の通りです。

コードを理解せずに本番運用するな
- 問題発生時に対処できない
APIキーは絶対にフロントエンドに置くな
- バックエンドで管理する
認証・認可はサーバーサイドで行う
- クライアントサイドは信頼できない
データベースセキュリティルールを設定する
- Firebase/Supabaseのデフォルトは危険
vibe codingで作ったことをSNSで公開するな
- 攻撃者への招待状になりうる
「動く」と「安全」は別
- 動作確認だけでは不十分

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

開発者がCursorで「ゼロ手書きコード」のSaaSを構築・公開
SNSで成功を語った直後から攻撃が始まる
APIキー不正使用、サブスクリプションバイパス、DB汚染
コードを理解していないためデバッグ不能
最終的にサービス完全終了
教訓：「動く」と「安全」は別

【SaaS崩壊】ゼロ手書きコードのスタートアップが数週間で破綻