UIはあるのに公開できない？『本番公開の最後の30%』完全ガイド

UIはできた。Bolt.newやLovableで画面を作り、「あとはデプロイするだけ」と思っていた。なのに公開できない。これはスキルの問題ではない。「動くコード」と「本番に出せるコード」が別物であることを、誰も最初に教えてくれないだけだ。

AI生成コードの45%にはセキュリティ脆弱性が含まれているという調査結果がある（Wiz社調べ）。JavaScriptやPythonで書かれたコードでも約40%、Javaに至っては10件中7件に何らかの問題が発見された。AIツールは画面を作ることに長けている。しかし認証の穴、データの露出、本番環境の設定――これらは指示しない限り省略される。

「動く」ことを確認したプロトタイプが、そのまま本番に出せる状態になっていることはほとんどない。MITの調査では、AIを活用した取り組みの95%以上が本番公開まで到達しないという数字も出ている。残りの30%がその壁だ。このガイドでは、その30%の正体を分解し、最短で埋める順番を示す。

「最後の30%」の正体

最後の30%は、画面や機能の話ではない。セキュリティ、インフラ、運用設計という3つのカテゴリに分かれる。どれか一つでも欠けると、本番公開の判断ができない。

セキュリティ

AIが生成したコードには、APIキーがソースコードにハードコードされていることがある。Supabaseを使ったアプリでRLS（行レベルセキュリティ）が無効のまま動いていることがある。入力値のバリデーションがなく、XSSやSQLインジェクションに無防備な状態のことがある。

これらは画面を見ても分からない。動作確認しても気づかない。本番で初めて問題になる。

インフラ・デプロイ

ローカルで動いていたアプリを本番環境に持ち込む際に必要な作業が残っている。環境変数の設定、ドメインの取得、SSL証明書の設定、本番DBの分離、ビルドエラーの解消。これらはコードの品質とは別の話で、インフラの知識が必要になる。

運用設計

公開後に何か起きたとき、どうやって検知するか。バックアップはどこにあるか。ユーザーからの問い合わせはどこで受けるか。管理者画面はあるか。これらが整っていなければ、公開はできても運用は続かない。

AIが得意なこと vs 苦手なこと

なぜAIツールはここで止まるのか

AIツールがプロトタイプを素早く作れる理由と、本番化できない理由は同じところにある。AIは「動くことを示す」ことに最適化されている。

AIは「ハッピーパス」を優先する

正常系、つまりすべてがうまくいく前提でコードを書く。エラー処理、異常系、タイムアウト、ネットワーク断絶――これらへの対応は指示しない限り省略される。本番環境では異常系が必ず起きる。

セキュリティは指示しない限り省略される

「ログイン機能を作って」と頼むと、ログインは動く。しかしセッションの安全な管理、他ユーザーのデータへのアクセス制御、ブルートフォース対策は含まれない。AIは聞かれたことに答える。聞かれなかったことは答えない。

インフラ設定はAIの視野外

AIはコードを生成する。しかし本番環境のサーバー設定、DNS設定、SSL証明書の更新、スケーリング設定はコードではなく設定の話だ。AIはローカルで動く状態を前提に動いている。本番環境に何が必要かは別の問題として扱われる。

「動くこと」と「安全に動くこと」は別

これが最大の盲点だ。プロトタイプを見て「動いている」と判断するのは正しい。しかし本番で「安全に動いている」かどうかは、セキュリティ監査をしなければ分からない。バグのあるAIモデルや壊れたDBマイグレーションは、単なる障害ではなくデータ漏洩や法令違反、顧客信頼の喪失につながり得る。

実際に起きたこと

Bolt.new ガイドで作ったアプリをそのままVercelにデプロイした。画面は動く。ユーザー登録もできる。しかしSupabaseのRLSが未設定だった。結果、認証したすべてのユーザーが、他のユーザーの全データをAPIから閲覧できる状態になっていた。これは設定一つの問題だが、気づくまでに誰かがデータを見ていた可能性がある。

詳細はSupabase RLSリスクを参照。

カテゴリ別：30%の具体的な中身

セキュリティ（最重要）

セキュリティは後回しにできない。公開後に「後で直す」は通じない。一度でも本番で動いた時点で、脆弱性を抱えたまま公開したという事実は消えない。

APIキー・シークレットの環境変数への移行

ソースコードにAPIキーが直書きされていないか確認する。GitHubにpushした瞬間に公開される。環境変数（.envファイル）に移行し、本番サーバーには環境変数として設定する。

Supabase RLSポリシーの設定

SupabaseはデフォルトではRLSが無効になっていることがある。有効にするだけでなく、ポリシーを正しく設定しないと意味がない。「自分のデータしか見えない」ことをAPIレベルで確認する。

入力値バリデーション

ユーザーが入力できるすべてのフィールドに対して、サーバーサイドでのバリデーションを実装する。クライアントサイドだけでは不十分だ。XSS対策、SQLインジェクション対策の基礎は外せない。

認証フローのテスト

AというユーザーでログインしてBというユーザーのデータのURLに直接アクセスできないか確認する。これをやっていないアプリは多い。

エラーメッセージの管理

エラーメッセージにスタックトレースやDB構造を含めない。「Internal Server Error」で十分な場合がほとんどだ。詳細はログに記録し、ユーザーには見せない。

詳細はAI生成コードのセキュリティリスクとセキュリティ基礎を参照。

インフラ・デプロイ

ドメイン・SSL証明書の設定

独自ドメインを取得し、HTTPSを設定する。SSL証明書の自動更新が機能しているか確認する。本番でhttp://のまま運用するのは論外だ。

本番環境変数の設定

開発用の環境変数（テスト用DBのURL、デバッグモードのフラグなど）と本番用を完全に分離する。本番DBに開発環境から繋がらないようにする。

本番DBの分離

プロトタイプで使っていたDBに、テストデータが混在していないか確認する。本番用の新しいDBを用意し、クリーンな状態で始める。

ビルドエラーの解消

TypeScriptの型エラーや、開発環境では無視していたwarningが本番ビルドでエラーになることがある。CIを通してから本番デプロイする習慣をつける。

スケーリング設定

アクセスが集中したときに何が起きるか。無料プランのサーバーは同時接続数に限界がある。最初から完璧にする必要はないが、限界を把握しておく。

詳細はデプロイ・ドメイン・SSLを参照。

認証・データ設計

権限設計

管理者と一般ユーザーの区別は最低限必要だ。「誰が何をできるか」をコードに落とす前に、紙でも箇条書きでも整理する。あとから権限を追加するのは、想像以上に大変だ。

セッション管理・ログアウト処理

ログアウトしたあとに「戻る」ボタンでデータが見えないか確認する。セッショントークンの有効期限を設定する。共有PCで使われることを想定する。

データスキーマの本番対応

NULL制約、データ型の整合性、外部キー制約を確認する。プロトタイプでは「とりあえず動く」ように曖昧にしていた部分を、本番では厳密に定義する。データが壊れてからでは遅い。

詳細は認証・DB・運用の最小構成を参照。権限設計のパターンはRBACの基本設計にまとめている。

運用設計

エラー監視

Sentryなどのエラー監視ツールを導入する。本番で何かが壊れたとき、ユーザーからの問い合わせで初めて気づくのは最悪のパターンだ。エラーが発生した瞬間に通知が来る仕組みを作る。

バックアップ設定

Supabaseの無料プランには自動バックアップがない。有料プランでも設定が必要な場合がある。「いつのデータまで戻せるか（RPO）」と「どのくらいの時間で復旧できるか（RTO）」を決めておく。

管理画面の最小構成

ユーザー一覧の確認、問題のあるデータの修正、利用状況の把握。これらができる最小限の管理画面がないと、運用が成立しない。具体的な構成は管理画面の最小要件を参照。

アラートの設定

サーバーが落ちたとき、DBの容量が上限に近づいたとき、エラーレートが急増したとき――これらを検知して通知するアラートを設定する。

詳細はバックアップ・リストアを参照。

自力でやる場合 vs 専門家に頼む場合

正直に比較する。どちらが正しいというわけではなく、状況によって変わる。

自力でやる場合、技術的な問題より「何が必要かを知っていること」が最大の壁になる。チェックリストを使えば対応できる項目も多いが、セキュリティの見落としが後から大きなコストになることがある。なお、専門家に依頼する場合の引き継ぎドキュメントの書き方は引き継ぎドキュメントテンプレートを参照。

詳細な費用の比較は本番化費用比較を参照。また、自力でやる場合の具体的な条件は2週間で本番公開できる条件にまとめている。

30%を最短で埋めるための順番

順番が重要だ。セキュリティ系は後回しにできない。インフラ系は公開前日に慌てないよう早めに着手する。運用系は公開後でも間に合うものがある。

必須（公開前に必ず対応）

• APIキー・シークレットを環境変数に移行
• Supabase RLSを有効化し、ポリシーを設定
• 認証テスト（他ユーザーのデータにアクセスできないか確認）
• HTTPSの設定（SSL証明書）
• 本番DBをテストデータと分離
• 入力値バリデーションの実装（最低限のXSS対策）
• エラーメッセージから機密情報を除去

推奨（公開後2週間以内に対応）

• エラー監視（Sentry等）の導入
• バックアップの設定と復元テスト
• パスワードリセット機能の動作確認
• アラート設定（サーバーダウン、エラーレート急増）
• 管理画面の最小構成
• Google PageSpeedで表示速度を確認（目標スコア: 70以上）

後でいい（安定してから対応）

• 高度な管理画面（詳細な利用統計、CSVエクスポートなど）
• A/Bテスト基盤
• 詳細ログ分析（BigQuery等への連携）
• 多要素認証（MFA）
• CDNの最適化

詳しくはリリースを阻む7つのブロッカーも参照。また、体系的なチェックリストは本番公開前チェックリストにまとめている。非機能要件の全体像は非機能要件の最低ラインを参照。

よくある質問

「30%って、実際どのくらいの工数がかかりますか？」

スコープによるが、最小構成で2週間〜1ヶ月が目安だ。セキュリティ設定だけなら数日、監視・運用設計まで含めると1ヶ月を超えることもある。「何をどこまでやるか」を先に決めることが、工数を読む上で最も重要だ。

「Bolt.newやLovableを使えば、30%が少なくなりますか？」

ツールによる差はほとんどない。Bolt.new ガイドもLovable ガイドも、画面を素早く作るためのツールであって、本番化の要件を埋めるためのツールではない。プロトタイプの品質が上がっても、本番に必要な要件は変わらない。

「まず公開して、後でセキュリティを直せばいい？」

セキュリティは後回しにできない唯一の項目だ。公開した瞬間から、脆弱性は攻撃対象になる。RLSが無効のまま公開して数日後にデータが漏洩した場合、「公開後に直す予定だった」は法的にも倫理的にも通用しない。最低限のセキュリティチェックは公開前に必ず済ませる。

「費用はどのくらいかかりますか？」

プロトタイプの規模と必要な機能によって大きく変わる。自力でやる場合は人件費のみだが時間がかかる。専門家に依頼する場合の相場感は本番化費用比較にまとめている。

「チェックリストを使えば、自分でできますか？」

インフラやセキュリティの基礎知識がある場合は、チェックリストを使って自力で対応できる。Claude Code ガイドを使ってAIに補助させながら進めることも有効だ。ただし、「知識があること」と「何が必要かを知っていること」は別問題で、後者を把握していない場合は専門家への相談を検討する。