多くのバイブコーダーは、まだセキュリティゼロのアプリをリリースしている。機能やデザイン、迅速なリリースに集中している。退屈な作業は宿題のように感じられる。
その代償を払っている人もいる。一晩で $200 の Supabase 請求書。初日からスパムの洪水。予想外の警告書を受け取る人も数人いる。
そして、毎回のローンチ前に静かに30分のチェックリストを実行している小さなグループがいる。デモには現れないが、アプリが最初の実ユーザーを乗り越えられるかを左右する類のものだ。
私は最初にこの簡易版を投稿としてシェアした。90万ビューを超え、返信や DM ではみんな同じことを求めていた。完全版の深掘り。エージェンシーの文脈。文字数制限でカットせざるを得なかった部分。というわけで、多くの人が求めてくれたので、ここに2026年の実際の状況に合わせてアップデートしたものをお届けする。
私はエージェンシーで約2年間に60以上の MVP を構築してきた。21日で製品をリリースし、そのまま本番環境に投入したこともある。そして学んだのは、セキュリティは後から追加するものではないということだ。ローンチ前に組み込むか、さもなければ炎上対応、返金、評判の低下という代償を払うことになる。
この記事は完全版だ。まず、20年以上の開発者が Reddit でシェアした内容から始め、さらにエージェンシーですべてのプロジェクトで本番公開前に実行していることをすべて積み重ねている。
完全な内訳は以下の通り。
Reddit 投稿が正しかった点（そして見逃した点）
20年以上の経験を持つ開発者が最近、Reddit にローンチ前のチェックリストを投稿し、バイブコーディングコミュニティで話題になった。簡潔で、5つのカテゴリにまとめられ、Claude や Cursor にそのままコピーできる実際のプロンプトが含まれていた。
彼は基礎をしっかり押さえていた。
→ メールアドレスを1つも収集する前に、法的に自分を守る
→ AI を使って2分で自分のセキュリティ態勢を監査する
→ セキュリティヘッダーだけでなく、OWASP に準拠する
→ フロントエンドと API ルートのデータ漏洩をチェックする
→ API キーをブラウザに絶対に送り込まない
しかし、クライアントのために再構築の見積もりを取る前に、バイブコーディングされたアプリを数十件監査した結果、ほとんどのビルダーが見逃しているもう一つの層がある。
Reddit 投稿は表面をカバーしていた。この記事はその下にある基礎をカバーする。両方が重要だ。片方だけでは、まだ脆弱なままである。
ほとんどのバイブコーダーがセキュリティに取り組む方法の問題点
ほとんどのビルダーはセキュリティをバージョン2で追加する機能のように扱っている。
それは機能ではない。それは最低限の基準だ。
AI を使えば、週末で製品をリリースできる。その同じスピードで、週末に責任もリリースできる。コードベースはきれいに見える。UI は洗練されて見える。デモは完璧に動作する。誰かが DevTools を開いてデータベース全体を読んだとき、それらのどれもあなたを守ってくれない。
創業者がエージェンシーに壊れた MVP の再構築を依頼に来るとき、ほぼ毎回同じ5つのカテゴリの失敗が現れる。データベースが無防備。情報を漏洩する認証フロー。フロントエンドのバンドルに置かれた API キー。高額なエンドポイントへのレート制限なし。攻撃者がトリガーするとスキーマ全体をマッピングするエラーメッセージ。
修正方法は偏執的になることではない。
修正方法は、毎回のローンチ前に実行する30分のチェックリストだ。5つのカテゴリ。エージェンシーで実行しているものと同じ。これから説明するものと同じだ。
セクション1: アプリだけでなく、自分自身を守る
ユーザーデータを収集した瞬間、あなたは法的領域に足を踏み入れている。GDPR、CCPA、プラットフォームの利用規約。
ほとんどのバイブコーダーは、手遅れになるまでこれについて考えない。
最低限、3つのこと。
→ 本物のプライバシーポリシー。たとえ自動生成でも構わない。Termly や PrivacyPolicies.com はどちらも無料で5分以内に作成してくれる。
→ ユーザーデータがどこに保存されているかを正確に把握する。Supabase のリージョン、Vercel のリージョン、データに触れるサードパーティサービス。
→ 怪しいことはしない。ユーザーデータを売らない。自分の個人メールにエクスポートしない。パスワードを平文で保存しない。
完璧である必要はない。無謀でさえなければよい。
これは今年で最も安上がりな10分間の作業であり、通常のローンチと、2週間目に警告メールを受け取ることの違いを生む。
2026年に変わったこと、そしてこのセクションが今より重要である理由
AI で構築されたアプリを取り巻く法的な基盤は今年大きく変わり、ほとんどのビルダーはまだ追いついていない。
→ 最高裁判所は人間の著作者性に関する判決を支持した。AI だけで書かれたコードは米国で著作権を取得できない。競合他社があなたの AI 構築アプリをそっくりそのままクローンしても、法的に阻止する根拠がない可能性がある。
→ あなたの AI が GPL のようなライセンスのオープンソースコードを静かに取り込んだ場合、コードベース全体をオープンソースにするか、権利侵害の請求に直面することを強いられる可能性がある。責任はすべて負い、保護は一切得られない。
→ これまでで最大の AI 著作権訴訟は 15 億ドルの和解で終結し、今週最終的な裁判所の承認を得た。弁護士たちは来るのではなく、すでに来ている。
これは構築をやめろということではない。盲目的にリリースするなということだ。このチェックリストの残りの部分は、そのための方法である。
セクション2: データベースをロックダウンする
これは、インバウンドプロジェクトを監査する際に最も時間を費やすセクションだ。これまで開いたバイブコーディングされたアプリのほとんどすべてが、以下の3つのチェックのうち少なくとも1つに合格していない。
Supabase の行レベルセキュリティ。
RLS がないと、誰でもブラウザの DevTools を開き、クエリを実行してデータベース全体を読み取ることができる。ハッキングでも悪用でもない。単にコンソールを開いてコマンドを入力するだけだ。
Supabase のダッシュボードに移動する。Authentication をクリックし、Policies をクリックする。ポリシーがゼロの場合、アプリは裸同然だ。
修正は簡単だ。認証されたユーザーに基づいて、誰が行を読み取り、挿入、更新、削除できるかを制限するポリシーを追加する。Lovable や Bolt を使っている場合は、エージェントに RLS を有効にしてテーブルのポリシーを作成するよう依頼するだけで、自動的に SQL が生成される。
5分。セキュアなアプリと、発生寸前のデータ漏洩の違いだ。
すべてのフォームでのサーバーサイドバリデーション。
クライアント側の Zod はセキュリティではない。それは UX だ。
攻撃者は JavaScript を無効にし、Postman を開いて、好きなものを直接 API に送信する。フロントエンドにしかバリデーションがない場合、不正なデータ、SQL インジェクションの試行、スクリプトを送信される可能性がある。フォームがデータベースに書き込む場合は、サーバー側で再度バリデーションを行う。データ型をチェックする。長さ制限をチェックする。入力をサニタイズする。
これは最低限だ。選択肢ではない。
データを漏洩しないエラーメッセージ。
悪いエラーメッセージ: "SELECT * FROM users WHERE email failed."
これは攻撃者にテーブル名、カラム名、クエリロジックを教えている。
良いエラーメッセージ: "User not found."
完全なエラーはサーバー側でコンテキスト付きでログに記録する。ユーザーには汎用的なメッセージを表示する。本番環境でスタックトレースを絶対に公開しない。基本的な運用セキュリティだ。ほとんどのアプリは初日にこれに失敗する。
悪いメッセージは攻撃者にスキーマを渡す。良いメッセージは何も明かさない。
1つのプロンプトで、30秒でほとんどの OWASP 脆弱性がフラグされる。
セクション3: 認証の失敗ケースをテストする
ほとんどの開発者は正常系のみをテストする。有効なメールでサインアップする。ログインする。完了。
アプリは問題が発生したときに壊れる。それはまさに攻撃者が最初に探るポイントだ。
以下は、プロジェクトの承認前に実行する、正確な4ポイントの失敗ケーステストである。
→ 間違ったパスワードで5回連続ログインを試みる。アカウントはロックされるか？ 汎用的なエラーを表示するか、それともメールアドレスが存在することを確認するか？
→ 存在しないメールアドレスでパスワードリセットを試みる。メールがシステム内にあるかどうかを明かすか？
→ メール確認リンクを2回クリックする。フローが壊れるか、それとも適切に処理されるか？
→ 既に登録されているメールアドレスでサインアップする。ユーザーが既に存在することを漏洩するか？
10分のテスト。本番公開前に認証の脆弱性の80%を捕捉する。
私たちは今年、すべてのインバウンド監査でこの正確なテストを実行してきた。約7割のコードベースで問題を発見している。美しい UI を持つバイブコーダーたちは、毎回これを見逃していた。
セクション4: 毎回のローンチ前に実行する4つの AI プロンプト
これは Reddit 投稿が完璧に捉えた部分だ。以下の4つのプロンプトで表面レベルのセキュリティ監査の80%をカバーし、合わせて約8分で完了する。
Claude Code、Cursor、または使用しているエージェント内で実行する。保存しておき、ローンチの儀式の一部にしよう。
プロンプト1: ベースラインセキュリティ態勢
セキュリティ専門家として私のアプリをレビューし、強力なセキュリティヘッダーと堅牢なベースラインセキュリティ態勢が整っていることを確認してください。
2分。明らかなギャップを修正する。ヘッダーだけでは十分ではないが、最低限の基準にはなる。
プロンプト2: OWASP 標準チェック
OWASP 標準に照らして私のアプリをレビューし、脆弱性を強調してください。
ここで SQL インジェクション、XSS、認証の問題が実際に捕捉される。
プロンプト3: データ漏洩監査
フロントエンドまたは API ルートにおける、認証情報や機密データの漏洩がないか、私のアプリをチェックしてください。
AI が生成したコードは、ほぼ毎回3つの箇所でデータを漏洩する。.env の値がフロントエンドコードに紛れ込む。API レスポンスがデータを返しすぎる。シークレットがログに表示される。
プロンプト4: API キー露出チェック
フロントエンドコードやネットワーク呼び出しで API キーが露出していないことを確認してください。
キーがブラウザにあるなら、すでに取得されたと思え。この1つのバグだけで、インディープロジェクト全体が1週末で枯渇したことがある。
API キーについてさらに深く
そのプロンプトは明らかなケースを捕捉する。以下は、それを超えてすべてのプロジェクトで実行するルールである。
公開キーはフロントエンドに残してよい。Supabase の anon キー、Stripe の公開可能キー、明示的に公開とマークされたもの。これらは露出するように設計されている。
秘密キーはサーバーサイドに置かなければならない。サービスロールキー、Stripe の秘密キー、OpenAI キー、"publishable" という接頭辞がないものすべて。Supabase Edge Function Secrets または Vercel 環境変数に保存する。バージョン管理にコミットしてはならない。フロントエンドコードにペーストしてはならない。
キーが露出した可能性があると思ったら、すぐに再生成する。待ってはいけない。誰も見つけていないと願ってはいけない。公開 GitHub リポジトリは、数分以内にキーをスクレイピングされる。
2分で、セキュリティヘッダーが機能しているかどうかがわかる。
セクション5: インフラストラクチャを保護する
このセクションは、データだけでなく、あなたの財布を守る。
すべてのエンドポイントにレート制限を設定する。
これはバイブコーディングされたアプリがあなたの財布を空にする最も速い方法だ。レート制限がないと、誰かが1分間に10,000回 API をスパムできる。ログインのブルートフォースかもしれない。データベースのスクレイピングかもしれない。単に悪意があるだけかもしれない。
私はサイドプロジェクトで、1つのエンドポイントにレート制限がなかったために、Supabase の請求額が1日で $20 から $200 に跳ね上がるのを実際に見た。あっという間に起こる。
最低限、3つ。
→ 有料 API（OpenAI、Anthropic、Stripe、Resend）を呼び出すすべてのエンドポイントにレート制限を設定する
→ OpenAI と Anthropic のダッシュボードでハードな日次上限を設定する
→ 日次上限の50%でアラートを設定し、朝に急増が発生する前にキャッチする
Supabase Edge Functions の場合、Upstash が最も簡単なレート制限ソリューションだ。公開エンドポイントには IP あたり1分間に100リクエスト、認証済みユーザーには1分間に1,000リクエストが妥当なベースラインである。
すべての公開フォームに CAPTCHA を設置する。
お問い合わせフォーム、サインアップページ、ウェイトリスト。CAPTCHA がないと、初日からボットに flood される。保護のないアプリで、お問い合わせフォームが1時間に500件のスパム送信を集めるのを目撃したことがある。
Cloudflare Turnstile は無料でプライバシー重視だ。統合には10分かかる。
API に CORS 制限を設定する。
デフォルトでは、多くのフレームワークがどこからでも API リクエストを許可する。ローカル開発には問題ない。本番環境では災害だ。
API にアクセスできるドメインを正確に指定する。本番ドメインを許可する。テスト用に localhost を許可する。それ以外はすべてブロックする。2分。クロスサイトリクエストフォージェリと不正な API アクセスを防ぐ。
ハードな上限とアラート。月々の請求額を節約する3分の設定。
最後にビルトインのセキュリティスキャンを実行する
セクション4の4つのプロンプトは手動だ。貼り付けて、結果を読む。3日前から、最終ゲートとしてより良いものがある。
Anthropic が Claude Code 用の Claude Security プラグインをリリースした。
ベータ版で、7月22日にリリースされた。単一のプロンプトではない。ターミナル内で直接実行されるマルチエージェント脆弱性スキャナーだ。Claude Code セッション内でインストールする:
/plugin install claude-security@claude-plugins-official 然后 /reload-plugins。これで1つのコマンド /claude-security が使えるようになる。
プロンプトを貼り付けるのと何が違うのか。
→ エージェントのチームがアーキテクチャをマッピングし、脅威モデルを構築し、4つのカテゴリ（インジェクション、認証とアクセス、メモリ、暗号とシークレット）にわたって探索する
→ すべての発見は、レポートに到達する前に3エージェントの敵対的パネルを通過する必要があるため、誤検知に悩まされることはない
→ レポートは深刻度、CWE ID、正確なファイルと行番号を提供し、発見結果を自分でレビューして適用できるパッチファイルに変換できる
→ 背後にあるモデルは、オープンソースのコードベースですでに500以上の未知の高深刻度脆弱性を発見している
有料の Claude Code プラン（v2.1.154 以降）が必要で、スキャンはプランのトークンを使用する。
Cursor や Lovable のようなビジュアルビルダーも、RLS の設定ミス、露出したシークレット、脆弱な依存関係、安全でないパターンをフラグする独自のスキャナーを搭載している。自分のスタックにあるものを実行すればよい。
フラグされたものはすべて修正する。警告が出ている状態でリリースしてはならない。後で直すと言い聞かせてはならない。セキュリティ負債は機能負債よりも速く複利する。
このスキャンをデプロイ前の最終ゲートとして扱う。手動プロンプトはスキャナーが見逃すものを捕捉する。スキャナーはプロンプトを忘れたものを捕捉する。Anthropic が Claude Code に本物のスキャナーを組み込んだ今、それをスキップする言い訳はない。
このチェックリストを使うタイミング
このチェックリストは、MVP、SaaS、AI ツール、またはユーザーデータを扱うものをリリースするビルダーの80%向けに作られている。
以下の場合に使用する。
→ ユーザーデータ（メールアドレスだけでも）を収集するアプリをリリースする場合
→ Supabase、Firebase、またはデータベースアクセスを伴うバックエンドで実行している場合
→ コードベースから有料 API（OpenAI、Anthropic、Stripe）を呼び出している場合
→ アプリを初めて公開しようとしている場合
以下の場合は、徐々に導入する。
→ 認証の背後で自社チームのみが使用する内部ツールをリリースする場合
→ すでに包括的な監査を実行しているセキュリティチームと協力している場合
→ MVP 前の探索モードで、ユーザーデータをまったく収集していない場合
実際のものをリリースするほとんどのバイブコーダーにとって、このリストのすべての項目が該当する。どれか1つでもスキップすることは、必要のない責任を負うことになる。
注意すべき点
これを最終決定版として扱う前に、いくつか正直な注意点を挙げておく。
このチェックリストは、自信を持ってベースラインに到達するためのものであり、エンタープライズグレードのコンプライアンスではない。健康データ、金融データ、または規制対象のデータを保存する場合は、その上に実際のセキュリティ監査が必要になる。
AI プロンプトとスキャナーは表面レベルの問題を捕捉する。ビジネスロジックの脆弱性、複雑な認証状態のバグ、高度なインジェクション攻撃は捕捉しない。それらを下限として扱い、上限としては扱わない。
セキュリティ負債は複利する。待てば待つほど、後片付けは苦痛になる。最初の1回だけでなく、毎回のローンチ前にこれを実行する。
RLS ポリシーは間違って書きやすい。別のユーザーとしてデータにアクセスしようとしてテストする。テストせずに RLS を有効にするだけでは、誤った自信を与えるため、ないよりは悪い。
これが実際に意味すること
これが私の正直な見解だ。
バイブコーディング経済は急速に成熟している。1年前は、何をリリースしても誰も気にしなかった。今やプラットフォームはセキュリティポリシーを enforced している。ユーザーはそれを期待している。投資家はそれをチェックしている。裁判所は今年、実際の線を引き、弁護士たちも現れ始めている。
ローンチ前にスキップする30分は、何かが壊れたときに30日間の炎上対応として戻ってくる。今年、複数のインバウンド監査でそれを目の当たりにしてきた。最初のバージョンがデータを漏洩したり、資金を燃やし始めたりした後、再構築を求めて創業者がやってきたのだ。
エージェンシーでは、このチェックリストをデプロイメントのように扱っている。選択肢ではない。リリースの一部だ。そして Anthropic がセキュリティスキャナーを Claude Code に直接組み込んだ今、このチェックリストを実行するビルダーとスキップするバイブコーダーの差はさらに速く広がっていくだろう。
偏執的になる必要はない。初日にエンタープライズグレードのセキュリティは必要ない。このチェックリストだけでいい。
毎回のローンチ前に実行する。ワークフローの一部にする。テストやデプロイメントと同じように扱う。
なぜなら、2026年に生き残るアプリは、単に速くリリースするものだけではない。実際のユーザーが現れても壊れない、速くリリースするものだからだ。
2026年は、セキュリティを後付けではなくワークフローとして扱うビルダーにとって、UNFAIR な年になるだろう。
TLDR
→ バイブコーダーは訴えられ、罰金を科され、資金を枯渇させられている。ほとんどの人はまだそれに気づいていない。
→ 2026年の新常識: AI のみのコードは米国で著作権を取得できず、GPL の汚染はアプリ全体をオープンソース化することを強制する可能性があり、史上最大の AI 著作権和解（15億ドル）が最終的な裁判所の承認を得た。まず自分自身を守ること。
→ ステップ1. 法的に自分を守る。プライバシーポリシー、データの保存場所、不正な取り扱いをしないこと。
→ ステップ2. データベースをロックダウンする。Supabase の RLS、すべてのフォームでのサーバーサイドバリデーション、データを漏洩しないエラーメッセージ。
→ ステップ3. 認証の失敗ケースをテストする。間違ったパスワードを5回、偽のメールでパスワードリセット、確認リンクを2回クリック、既存のメールでサインアップ。
→ ステップ4. 4つの AI セキュリティプロンプトを実行する。セキュリティ態勢、OWASP、データ漏洩、API キー露出。
→ 環境変数をロックダウンする。公開キーはフロントエンドに置いてよい。秘密キーは Supabase Edge Function Secrets または Vercel 環境変数に。露出した場合はすぐに再生成する。
→ ステップ5. インフラストラクチャを保護する。すべてのエンドポイントにレート制限、有料 API にハードな上限、公開フォームに CAPTCHA、API に CORS 制限。
→ 最終ゲートとして実際のスキャナーを実行する。Anthropic の新しい Claude Security プラグインは、ターミナル内でマルチエージェントスキャンを実行する。ベータ版、有料 Claude Code プラン。
→ これには30分かかる。毎回のローンチ前に実行する。
→ これを実行するビルダーとスキップするビルダーの差は、2026年に急速に広がるだろう。
この発端となった Reddit 投稿の全文。 https://www.reddit.com/r/vibecoding/comments/1sthzcj/if_youre_about_to_launch_a_vibe_coded_app_read/
これをスクリーンショットして、毎回のローンチ前に実行しよう。
さあ、行こう。
