Vibe Codingで作ったプロダクトを本番公開するロードマップ【2026年完全版】

Bolt.new、Lovable、Cursor、Claude Codeといったvibe codingツールを使えば、アイデアを数時間でプロトタイプに変えることができる。画面は動く。データも入る。デモは見せられる。だが、それを「本番環境で実際のユーザーに使わせる」となると話は変わる。多くの非エンジニア起業家が「あと少し」と思いながら、そこで止まる。その「あと少し」が実態として30%を占めており、最も難しい部分だ。

AIが生成したコードには、45%の確率でセキュリティ上の脆弱性が含まれているという分析結果がある（Wiz Research, 2024）。JavaScriptとPythonで書かれたコードでも約40%、Javaに至っては10件中7件に問題が見つかった。プロトタイプの段階ではそれでも動く。しかし本番環境でリアルなユーザーデータ・決済情報・個人情報が流れ始めた瞬間、隠れていた脆弱性は攻撃可能な穴になる。AIツールはコードを書く。しかし「そのコードが本番で安全に動くか」は、別の問題だ。

このページはその「別の問題」を解決するためのロードマップだ。STEP 1からSTEP 5まで、プロトタイプを本番公開するために必要な全領域を体系化している。各セクションは概要と判断軸を示し、詳細な手順は個別記事にリンクしている。今自分がどのステップにいるかを確認しながら読み進めてほしい。

まず結論：本番公開に必要な5つのステップ

本番公開に必要な作業は、大きく5つのステップに分類できる。以下が全体像だ。

1. プロトタイプのクオリティ確認 — コードが本番に耐えられる状態かを検証する
2. セキュリティの確認・修正 — 脆弱性を特定し、本番前に修正する（最重要）
3. インフラ・デプロイ設定 — ドメイン・SSL・環境変数・デプロイパイプラインを整える
4. 認証・データ設計の本番化 — 認証フロー・権限管理・DBスキーマを本番仕様にする
5. 運用設計（監視・バックアップ） — リリース後に継続運用できる体制を作る

この5つのどれが欠けても、本番公開は「動いているように見えるが、いつ壊れるかわからない状態」になる。プロトタイプと本番の差は、このチェックリストの差に等しい。

どのツールで作っても「30%の壁」は同じ

vibe codingツールは種類が増えたが、本番公開の壁は共通している。ツールが変わっても、「やってくれないこと」の範囲はほぼ同じだ。

どのツールも「コードを書く」ことには長けている。しかしセキュリティ監査、インフラ設計、運用設計はツールの外側にある。この領域が「30%の壁」の正体だ。Vibe Codingガイドではツール選定の考え方を詳しく解説している。

STEP 1: プロトタイプのクオリティ確認

本番公開の作業を始める前に、まずプロトタイプ自体が一定の品質を満たしているかを確認する。ここをスキップすると、後のステップで想定外の手戻りが発生する。

確認すべき項目は以下の5点だ。

1. ローカルでエラーなく動くか — npm run build や npm run dev がエラーゼロで通ること。コンソールに警告が大量に出ている状態は本番向きではない。
2. 環境変数が .env.example に記載されているか — 必要な環境変数が文書化されていること。本番環境でどの変数を設定すべきかが明確でなければ、デプロイ時に確実に詰まる。
3. DBマイグレーションがテスト済みか — データベースのスキーマ変更が、ゼロの状態からでも再現できること。ローカルのみで通っていてもCI環境で失敗するケースは多い。
4. ビルドコマンドが通るか — ローカルでは動くのに、Vercel等のクラウド環境でビルドが失敗するケースは頻繁に起きる。事前にクリーンな環境でのビルド確認が必要だ。
5. コードに機密情報がベタ書きされていないか — APIキー、DBパスワード、JWTシークレットがソースコード内にハードコードされていないか確認する。GitHubに公開した瞬間に漏洩する。

これらの確認を体系的に行うためのチェックリストをAIプロトタイプ 本番公開チェックリストにまとめている。最初に目を通しておくことを推奨する。「デモまでできたのに先に進めない」という方はデモで止まったプロダクトを出荷する方法も参照してほしい。

STEP 2: セキュリティの確認（最重要）

前述の通り、AI生成コードの45%に脆弱性が含まれる。この数字はプロトタイプ段階では問題として表れないが、本番で実データが流れ始めると攻撃対象になる。セキュリティ確認はリリース前に必ず実施しなければならない。

確認すべき領域は5つだ。

1. 認証フロー

ログイン・ログアウトが正しく機能するかだけでなく、「ログアウト後にプライベートなURLに直接アクセスできないか」を必ず確認する。セッションタイムアウトの設定、パスワードの適切なハッシュ化（bcrypt等）、ロールベースのアクセス制御（管理者と一般ユーザーの分離）が本番要件として最低限必要だ。

2. 入力値のバリデーション

全フォームの入力値が検証・サニタイズされているか確認する。メールアドレスのフォーマット検証、SQLインジェクション対策、XSS（クロスサイトスクリプティング）対策が含まれる。AIが生成したバリデーションコードは、エッジケースを見落とすことが多い。

3. APIキー・シークレットの管理

ブラウザの開発者ツールでネットワークリクエストを確認し、APIキーやパスワードがリクエストに含まれていないかを検証する。クライアントサイドのコードに埋め込まれた認証情報は、誰でも閲覧できる。全てのシークレットは環境変数（env var）に移行する必要がある。

4. Supabase RLSの設定

SupabaseのRow Level Security（RLS）は、最も見落とされやすいセキュリティ設定だ。RLSが無効のままだと、全ユーザーが他のユーザーのデータを読み書きできる状態になる。「自分のデータしか見えない」を実現するRLSポリシーの設定と、ユーザーデータの分離テストが必須だ。

5. レートリミット

APIエンドポイントに対するレートリミットが設定されていないと、ブルートフォース攻撃やDDoS攻撃に対して無防備になる。認証エンドポイント、特にログインと登録には必ず設定する。

セキュリティに関する詳細は以下の記事で解説している。

• AI生成コードのセキュリティリスク10選 — 具体的な脆弱性のパターン
• セキュリティ 5つの対策 — 非エンジニアが最低限対応すべき対策
• Supabase RLSのリスク — RLS設定の落とし穴と対処法
• 7payが失敗した理由 — セキュリティ設計の欠如が引き起こした実際の事例

セキュリティは「後から対応できる」ではなく、「本番公開前に対応しなければならない」項目だ。リリース後に脆弱性が発覚した場合のコストと信頼損失は、事前対応のコストを大幅に上回る。

STEP 3: インフラ・デプロイ設定

プロトタイプが動き、セキュリティの基礎が整ったら、次はインフラとデプロイの設定だ。この段階でのミスは、本番環境でのビルド失敗や接続エラーとして現れる。

ドメイン・SSL（HTTPS）の設定

本番環境では独自ドメインとHTTPS（SSL証明書）が必須だ。HTTPのままのサイトはブラウザにセキュリティ警告が表示され、ユーザーの信頼を損なう。また決済機能がある場合はHTTPSが法的・契約的要件になることが多い。

環境変数の本番環境設定

ローカルの .env ファイルに設定した値は、本番環境には引き継がれない。Vercel、Netlify、Cloud Run等のプラットフォームのダッシュボードで、本番用の環境変数を個別に設定する必要がある。最も多いデプロイ失敗の原因は「本番環境で環境変数が undefined になっている」だ。

デプロイプラットフォームの選定

継続的デプロイのフロー

ローカルで動作確認 → GitHubにpush → プレビュー環境で自動デプロイ → 動作テスト → PRマージ → 本番環境に自動デプロイ、というフローを最初から構築しておく。これにより毎回の手動デプロイ作業がなくなり、ヒューマンエラーも防げる。

デプロイの詳細な手順とよくあるエラーの対処法は以下を参照してほしい。

• デプロイ・ドメイン・SSL設定 — 設定手順の完全ガイド
• Vercel Next.jsデプロイエラー — よくあるエラーと解決法一覧

STEP 4: 認証・データ設計の本番化

プロトタイプの認証とデータ設計は、多くの場合「動けばいい」レベルで作られている。本番公開では、実ユーザーのアカウント・データを扱うため、設計を本番仕様に引き上げる必要がある。

認証ライブラリの選定

プロトタイプで使った認証の実装が本番に耐えられるかを評価する。主な選択肢はClerkとNextAuthだ。Clerkはマネージドサービスで実装コストが低く、NextAuthは自前でDBを持つ場合に柔軟性が高い。それぞれのトレードオフの詳細はClerk vs NextAuthで解説している。

RBACの設計（権限管理）

管理者・一般ユーザー・ゲストといったロールが異なる場合、権限の分離を明示的に設計する必要がある。「管理者だけが見られるページ」「ログイン済みユーザーのみアクセス可能なAPI」を正しく実装しないと、一般ユーザーが管理者機能にアクセスできる状態になりかねない。RBACの基本設計で最小限の実装パターンを解説している。

DBスキーマの本番対応

適切なリレーション（主キー・外部キー）の設定、データ型の妥当性確認、頻繁にクエリされるカラムへのインデックス設定、大きなデータセットへのページネーション実装が必要だ。また、本番データのバックアップ設定もこの段階で済ませる。

詳細は以下の記事を参照してほしい。

• 認証・DB・運用の最小構成 — 最小限の本番構成
• データベースの基礎 — 非エンジニア向けDB設計の考え方
• RBACの基本設計 — 権限管理の最小実装
• Clerk vs NextAuth — 認証ライブラリの選定基準

STEP 5: 運用設計（監視・バックアップ）

本番公開はゴールではなく、運用の始まりだ。リリース後に「何かが起きたときに対応できる体制」がなければ、ユーザーに迷惑をかけ、信頼を失う。最低限の運用設計をリリース前に整えておく。

監視・アラートの設定

エラーが発生したときに通知が届く仕組みが必要だ。Sentryのようなエラートラッキングツールを設定しておけば、ユーザーがエラーを報告する前に問題を把握できる。また、APIのレスポンスタイムや可用性を監視するアップタイム監視ツールも合わせて設定する。

バックアップとリストアの確認

データベースの自動バックアップが設定されているか、バックアップから実際にリストアできるかを確認する。RPO（どこまで遡れるか）とRTO（どれくらいで復旧できるか）を把握しておく。特にユーザーデータを扱う場合、バックアップなしの運用はリスクが大きすぎる。詳細はバックアップ・リストアで解説している。

管理画面の最小構成

ユーザー管理、コンテンツ管理、基本的な統計確認ができる管理画面は、運用の基本インフラだ。最初から高機能なものは必要ないが、最低限の管理機能がないとオペレーションが成り立たない。管理画面の最小構成で必要な機能と実装方法を解説している。

クラウドコスト管理

予想外のトラフィックやループ処理のバグによって、クラウドコストが急増するケースがある。Vercel、Supabase、AWSそれぞれの課金モデルを理解し、予算アラートを設定しておく。クラウド破産を防ぐで具体的な対策を解説している。

「2週間で本番公開」は現実か

結論から言えば、条件次第で現実的だ。

プロトタイプの品質が一定以上であれば、2週間での本番公開は達成できる。具体的には以下の条件が揃っていることが前提になる。

• ビルドエラーがなく、主要機能がローカルで正常動作している
• 使用している技術スタック（Next.js + Supabase等）が確定しており、変更がない
• セキュリティ・インフラ対応を担当できる人材（または外注先）が確保できている
• 要件が固まっており、リリース後に大きな機能追加が発生しない

条件が揃わない場合、2週間という数字は机上の空論になる。よくあるのは「セキュリティ対応で止まる」「デプロイエラーが解消できない」「認証の設計をやり直す」ケースだ。2週間で本番公開できる条件でリリーススピードの現実的な見方を詳しく解説している。

また、本番公開を遅らせる具体的なブロッカーのパターンを知りたい場合はリリースを阻む7つのブロッカーを参照してほしい。「最後の30%」の全体像は本番公開の最後の30%にまとめている。

自力でやる vs AIのあとしまつに頼む

この5つのステップを自力で進めることは可能だ。ただし以下の点を正直に伝えておく。

自力で進める場合、このロードマップと各詳細記事が地図になる。ただし「セキュリティの確認」だけは専門家の目を入れることを強く推奨する。45%の確率で脆弱性があるコードを、自分で全て発見するのは難しい。

AIのあとしまつは、vibe codingで作ったプロトタイプを本番公開するための専門サービスだ。プロトタイプを捨てずに、セキュリティ・インフラ・認証・運用設計を整えて本番公開まで導く。費用は50万円〜、期間は2週間を目標としている。

無料相談では、現在のプロトタイプの状態を確認した上で、どのステップに課題があるかを具体的にフィードバックする。費用や工数のおおよその見込みもその場でお伝えできる。

よくある質問

Q. vibe codingで作ったアプリの本番化にどのくらいかかりますか？

プロトタイプの品質と求める本番要件によって異なる。ビルドエラーがなく、主要機能が動いている状態であれば、専門家の支援ありで2週間は現実的な目標だ。自力で進める場合は1〜3ヶ月を見込む人が多い。セキュリティ対応とデプロイ設定で詰まるケースが大半を占める。

Q. Bolt.newで作ったアプリの本番公開に開発者は必要ですか？

厳密に言えば「必須」ではないが、セキュリティ設定（特にRLS・環境変数・認証フロー）を正しく行うためには、コードと設定ファイルを理解できる人材が必要だ。完全にノーコードで本番品質のセキュリティを担保することは現実的ではない。最低でもセキュリティ監査だけは専門家に依頼することを推奨する。

Q. 本番公開後もAIツールで修正・機能追加できますか？

できる。ただし本番環境で変更を加える際は、必ずステージング環境でテストしてから本番に反映するフローを守ることが重要だ。AIが生成したコードのバグが本番に直接入ると、実ユーザーに影響が出る。継続的デプロイのパイプラインを最初から整えておくことで、この問題はコントロールできる。

Q. セキュリティ審査は必ず必要ですか？

決済機能、個人情報、医療・金融データを扱う場合は必須と考えるべきだ。これらを扱わない小規模なサービスであっても、OWASP Top 10の基本的な対策は最低限実施する。脆弱性を放置した場合のリスク（情報漏洩、サービス停止、法的責任）は、審査・対策コストを大幅に上回る。

Q. AI生成コードの45%に脆弱性があるなら、自分のプロダクトは大丈夫ですか？

「大丈夫かどうか、確認しなければわからない」が正直な答えだ。45%という数字は統計であり、あなたのコードが安全かどうかは確認しなければ判断できない。逆に言えば、確認することで問題を事前に発見できる。AI生成コードのセキュリティリスク10選で具体的なリスクのパターンを確認し、セキュリティ 5つの対策で最低限の対策を進めることが第一歩だ。