「画面はできた」から公開までに必要な最低セット（認証・DB・運用）

「画面はできています。あとは公開するだけです」。AIツールでプロトタイプを作った人から、この言葉をよく聞く。でも実際に確認してみると、公開できる状態にはほど遠いことが多い。

画面があることと、サービスとして公開できることは別の話だ。その間に何が必要なのかを、認証・DB・運用の3軸で具体的に整理する。

「画面がある」状態と「公開できる」状態の差

AIツールで作ったプロトタイプが「動いているように見える」理由は、データが固定値でハードコードされていたり、認証がモックだったりするからだ。

公開できる状態とは次のことが全部揃っている状態を指す。

• 誰がアクセスできるか（認証・権限）が制御されている
• データが実際にDBに保存・取得されている
• エラーが起きたときに気づける仕組みがある
• もし問題が起きたときに戻せる手段がある

これを「最低セット」として、順番に見ていく。

1. 認証の最低セット

ログイン・ログアウト

当然のように聞こえるが、「ログイン画面がある」だけでは不十分だ。セッションの有効期限管理、ログアウト後のトークン無効化、「ログイン済みでないと見られないページ」の保護（ルートガード）まで含めて初めて「ログインが実装されている」と言える。

ルートガードが抜けていた場合、URLを直接入力するとログインせずにダッシュボードに入れてしまう。これは実際によく起きる穴だ。

パスワードリセット

「忘れた」は必ず起きる。本番公開後に「パスワードを忘れたのですがどうすれば？」というサポート問い合わせが来て、そのたびに手動でDBをいじって対応するのは運用上あり得ない。メールでリセットリンクを送る仕組みは最初から入れておく。

メールアドレスの確認

架空のメールアドレスで登録されてスパムアカウントが増える、という問題を防ぐ基本的な仕組みだ。Supabaseなら設定2つで有効にできる。

実装時間の目安

• Clerkを使う場合： 1〜2日で認証全体が完成する。ログイン・サインアップ・パスワードリセット・セッション管理が全部ついてくる。費用はMAU 10,000人まで無料。
• Supabase Authを使う場合： 2〜3日。設定は少ないが、カスタムUIを作る場合は追加で1日かかる。
• NextAuth + 独自実装： 3〜5日。完全に自前で書くことになるため、最もリスクが高い。メールテンプレート、トークン管理、セキュリティ設定を全部自分で正しく実装する必要がある。

MVPフェーズでゼロから認証を書く理由はほぼない。ClerkかSupabase Authで十分だ。ClerkとNextAuthの詳しい比較はこちら。

2. DBとCRUDの最低セット

データモデルの設計

「この画面に表示されているデータはどのテーブルから来るか」が決まっていないと、実装が始められない。Supabaseであれば、テーブルの構造（カラム・型・リレーション）を最初に確定させる。

よくある失敗は、テーブル設計を後回しにしてフロントエンドから作り始めること。後からDBの構造を変えると、すでに書いたコードの大部分を書き直すことになる。

RLS（行レベルセキュリティ）

Supabaseを使う場合、RLSは絶対に設定する。これが設定されていないと、フロントエンドのコードを少し書き換えるだけで、他のユーザーのデータが見えてしまう。

-- 例：ユーザーが自分のデータだけ読める設定
create policy "ユーザーは自分のデータのみ参照可能"
on posts for select
using (auth.uid() = user_id);

RLSを設定し忘れたプロダクトが本番公開された事例は実際にある。Supabase RLSのセキュリティリスクについて詳しくはこちら。自分のアプリのデータが外から見える状態になっていないかチェックするならSupabaseセキュリティ診断が使える。

バリデーション

ユーザーが入力したデータは「何でも入ってくる」前提で設計する。必須項目のチェック、文字数の上限、メールアドレスの形式チェックなど。フロントエンドだけのバリデーションはすぐに回避されるので、サーバーサイドでも必ず検証する。

CRUD実装の時間目安

• シンプルなCRUD 1テーブル：1〜2日
• 複数テーブルのリレーション込み：3〜5日
• 検索・絞り込み・ソートが入る：+2〜3日

「このアプリには何個のテーブルがあり、それぞれで何の操作が必要か」を事前にリストアップしておくと、実装工数の見通しが立てやすい。

3. 運用の最低セット

エラーログ（Sentry または Vercel Logs）

本番でエラーが起きたとき、ユーザーからの「なんか動かない」という連絡で初めて気づく、という状態は避けたい。Sentryを入れておけば、エラーの発生を即座に検知してSlackやメールで通知できる。

Sentryの無料プランで月5,000エラーまでカバーできる。Next.jsへの導入はコマンド一発で終わる。

npx @sentry/wizard@latest -i nextjs

管理画面の最低限

ユーザーデータを確認したり、問い合わせ対応の際にアカウント状況を調べたりするための画面が最低限必要だ。本番公開後に「あのユーザーのデータを見たい」と思ったとき、毎回エンジニアがDBに直接アクセスするのは危険で非効率。

最低限あれば十分な機能：

• ユーザー一覧（名前・メール・登録日）
• 個別ユーザーの詳細表示
• 問題のあるコンテンツの削除

Supabase の Table Editor でも代用できるが、権限管理が雑になりやすいため、シンプルな管理画面を実装するほうが長期的には安全だ。管理画面の最低セットについてはこちらも参照。

ロールバック計画

「デプロイしたら動かなくなった」は必ず起きる。そのとき「元に戻す方法」が決まっていないと、復旧に時間がかかる。

Vercelを使っている場合、Instant Rollback機能で前のバージョンに1クリックで戻せる。これを「ロールバック手順」としてドキュメントに書いておく。

公開判断チェックリスト

以下の項目を全てクリアしていれば、公開できる状態だ。

認証

• ログイン・ログアウトが動く
• パスワードリセットメールが届く
• ルートガードが設定されている（未ログインでダッシュボードに入れない）
• メールアドレス確認が動く（任意だが推奨）

DB・CRUD

• 本番用DBが用意されている（ローカルのDBではない）
• RLSが設定されている
• 入力バリデーションがサーバーサイドにある
• データのCRUDが全て動作確認済み

運用

• Sentryまたはエラー通知の仕組みがある
• デプロイ手順がドキュメント化されている
• ロールバック手順が決まっている
• 緊急連絡先が決まっている

まだ公開できない状態の典型例

• 認証がモック（ハードコードされたユーザー名とパスワード）
• データが全部ハードコードされていてDBに保存されていない
• 本番環境の環境変数が設定されていない
• エラーが起きても誰も気づかない

本番公開の全体フローについてはこちらを参考にしてほしい。