アプリが完成し、デプロイも済み、あとはリンクを世の中に公開するだけです。シリーズ最終回では、その直前に行う最終チェックを扱います。ユーザーを受け入れる前に確認すべき6項目と、第1回から続いてきた地図の全体像です。
まず、よくある誤解を一つ整理しましょう。「自分のアプリは小さくて有名でもないのに、誰が攻撃するのか」という考えです。第2回で見たように、攻撃者は人ではなくボットです。ボットは標的を選ばず、網を張ります。 インターネット上で公開されたすべてのアドレスを自動的に調べ、開いている入口を探します。小さなアプリだから安全なのではなく、小さいから誰にも見守られていないだけです。幸い、バイブコーディングアプリで突破される入口の多くは決まっており、以下の6つがその入口です。
公開前チェックリスト6
1. 秘密の値が漏れていないか。 第2回のチェックです。APIキーがフロントエンドやGitHubの公開リポジトリに露出していないか確認します。AIへの指示:「このプロジェクトで、APIキーや秘密の値がフロントエンドに送信されたり、Gitにコミットされたりした箇所をすべて探して。」
2. 権限チェックがバックエンドにあるか。 第1回の原則です。削除ボタンを隠すだけでは飾りにすぎず、リクエストは誰でも送れます。記事の削除・編集・取得それぞれについて、「このユーザーに実行する資格があるか」をバックエンドが確認しなければなりません。AIへの指示:「すべてのバックエンドAPIがログイン状態と所有権を確認しているか監査し、抜けている箇所を一覧にして。」
3. DBに誰でも入れる状態になっていないか。 倉庫(DB)には独自の入退室ルールがあります。SupabaseならRLS(Row Level Security、行単位のセキュリティ)です。簡単に言えば、「各データ行を誰が読み書きできるか」を倉庫のドアに掲示するルールです。これが無効だと、バックエンドを通らず倉庫へ直接侵入する経路が開きます。実際のバイブコーディングアプリの事故で、最も頻繁に指摘される項目です。AIへの指示:「自分のDBテーブルに、誰でも読み書きできるものがないか確認し、ロックする方法を教えて。」
4. 不正な入力に備えられているか。 ユーザーは入力欄に何でも入れます。10万文字の記事、奇妙なコード片、空の値などです。バックエンドが入力の長さと形式を検証しなければ、アプリは壊れたり突破されたりします。AIへの指示:「ユーザー入力を受け取るすべての箇所に、長さ制限と形式検証があるか確認して。」
5. 料金の安全装置が設定されているか。 第7回の5分設定です。支出上限と予算アラートを設定します。ユーザーが発生した瞬間から呼び出し量は自分の手を離れるため、公開前が最後の設定機会です。
6. 戻れる場所があるか。 第3回のセーブポイントです。公開直前の状態をコミット・プッシュし、DBバックアップが有効か確認します。公開後に最初の事故が起きたとき、「正常に動いていた時点」に戻れる手段があるかどうかが復旧速度を左右します。
6つすべてを確認するのが大変なら、最後の手段としてこのプロンプトだけでも実行してください。「あなたはセキュリティ監査人です。このプロジェクトを公開する前に、秘密の値の露出・権限チェックの漏れ・DBアクセスルール・入力検証の観点から危険な箇所をすべて探し、深刻度順に知らせてください。」作成時にミスをしたAIでも、監査を依頼すればよく見つけてくれます。ただしAIの「安全になりました」をそのまま信じず、このチェックリストと照合しながら一つずつ確認するところまでがチェックです。
シリーズ総まとめ:1枚の地図
8回分を1枚に折りたたむと、こうなります。
- 第1回 — 構造:アプリはホール(フロントエンド)・キッチン(バックエンド)・倉庫(DB)です。フロントエンドは公開空間なので、秘密を置きません。
- 第2回 — APIキー:キーは法人カードです。置き場所は
.envとデプロイダッシュボードの2か所だけです。 - 第3回 — Git:コミットはセーブです。うまく動くたびに、大きな修正の前にセーブします。
- 第4回 — デプロイ:デプロイはサーバーへの引っ越しです。
.envは荷物に積まれないため、ダッシュボードに別途登録します。 - 第5回 — エラー:エラーメッセージは自白書です。状況と一緒に全文をAIへ渡します。AIが堂々巡りを始めたら、進め方を変えます。
- 第6回 — ミステリー:「何も変えていないのに」の犯人は、キャッシュ・依存関係・外部サービス・昨日の自分です。安い確認から順番に進めます。
- 第7回 — 料金:請求はトークン・読み書き・トラフィックから発生します。支出上限とアラートは5分で設定できる保険です。
- 第8回 — 公開前チェック:上記の6つの入口を施錠して出発します。
おわりに
このシリーズはコーディングを教えませんでした。その代わりに地図を描きました。アプリがどんな部品でできていて、各部品がどこでどんな事故を起こし、事故が起きたときどこを見てAIに何と言えばよいのかを示す地図です。バイブコーディングの本当のスキルはコードを読む能力ではなく、この地図を持ってAIに正確な質問を投げる能力です。
地図はもう皆さんの手の中にあります。良いものを作って、世の中に見せてください。

![[バイブコーダー #8] ユーザー受け入れ前のセキュリティチェック6項目のカバー画像](/assets/images/posts/88a2c686-f9c2-4047-8809-30b6118aec87/launch-security-checklist-1.jpg)