AIやノーコードを使ったら、試作が数日で動いてしまった。社内デモも好評で、上司も「いいね、これお客様に出そう」と乗り気。
でも、いざ本番化となると手が止まる。「これ、本当にこのまま外に出していいのか」——その不安、よく分かります。
この記事は、そんな「動くPoCはできた、でも本番が怖い」という方に向けて書きました。
「動くPoC」と「本番システム」の間には、見えない崖がある
PoC（Proof of Concept＝概念実証。本当に作れるか・効果が出るかを試す小さな試作）は、そもそも使い捨て前提のものです。
近道・モック連携・暫定的な構成・最小限の安全策——それらを含むのが普通で、コードはほとんど再利用しない、というのが本来の考え方です（出典: BotsCrew「From AI Pilot to Production」, 2026年6月時点）。
ところが現実には、「もう動いているんだから、そのまま出せば安いはず」と考えてしまいがちです。ここに崖があります。
この記事が前提にするスタックは、AI駆動開発やノーコードで作られた試作によくある構成です。
- Next.js — フロントとサーバー処理をまとめて書けるフレームワーク
- Vercel — Next.js のホスティング/デプロイ基盤
- Supabase — PostgreSQL ベースの BaaS（Backend as a Service＝認証やDBをまとめて提供する裏側基盤）
PoC を「とりあえず動く」状態にするには最高の組み合わせです。一方で、本番運用に必要な設定は、ほとんどが「自分で有効にしないと有効にならない」ものばかりです。
そもそも PoC をどう始めるかはAI導入は「PoC」から始めるで整理しています。この記事は、その「次の一歩」——作れたものを安全に運用へ渡す段階に絞ります。
ゴールはシンプルです。本番化で最低限つぶすべき論点を、Supabase 設計と Vercel 運用に絞って具体的に示すこと。全部を完璧にする話ではありません。危ない順に固める話です。
まず棚卸し：PoCのままだと危ない5つのポイント
本題に入る前に、入口のチェックリストを置きます。自分のPoCに当てはまるものがないか、まず点検してみてください。
- ①認証とアクセス制御が甘い — 誰でも全データを読める状態になっていないか
- ②本番データとテストデータが同じ場所に混在している — 検証作業が本番を壊しうる
- ③バックアップを取っていない・取れているか確認していない — 事故時に戻せない
- ④環境変数（APIキー等）がコードに直書き、または1環境で使い回し — 漏洩リスク
- ⑤エラーが起きても気づけない — 監視・通知がなく、障害をユーザーの連絡で初めて知る
この5点が「本番化チェックの入口」です。以降の章で、それぞれを Supabase 設計と Vercel 運用に落とし込んで深掘りします。
Supabase 本番設計の勘所
PoC で一番事故が起きやすいのが、ここです。順に見ていきます。
RLS（行レベルのアクセス制御）を必ず有効にする
まず最重要から。RLS（Row Level Security＝テーブルの行ごとに「誰が見られるか」を制御する仕組み）は、Supabase ではデフォルトで無効です。
これは SQL でもマイグレーションでも ORM でも同じで、有効化とポリシー設定をしない限り、anon キーを持つ任意のクライアントがデータを読み書きできてしまう状態になります（出典: Supabase 公式「Going into Production」, 2026年6月時点）。
つまり、「Supabase は堅牢だから安心」は半分しか正しくありません。基盤は堅牢でも、RLS を有効にしていなければデータは実質公開状態です。Supabase 公式の本番チェックリストも、RLS のないテーブルは「任意のクライアントがそのデータにアクセス・変更できる」と明確に警告しています。
これは机上の話ではありません。CVE-2025-48757 という事例では、ある AI ビルダーで作られたアプリのうち約10.3%（1,645件中170件）でユーザーデータが露出していたと報告されています。別の分析では「Supabase のデータ露出の83%が RLS の設定ミスに起因する」とされています（出典: vibeappscanner.com、同ページが引用する Escape.tech 調査, 2026年6月時点）。
ポリシー設計の考え方はシンプルです。RLS ポリシーは、PostgreSQL が全クエリに自動で付ける WHERE 句のように働きます。
USING (user_id = auth.uid())と書くと- 各 SELECT に
WHERE user_id = auth.uid()が自動適用され - ユーザーは「自分の行」だけを取得できる
最低限の発想は「自分のデータだけ読める・書ける」を auth.uid()（ログイン中ユーザーのID）で縛ること。PoC 段階で「とりあえず全許可」にしていないか、本番前に必ず点検してください。
注意点をひとつ。Realtime（リアルタイム購読）も RLS を尊重します。SELECT ポリシーが配信対象の行を正しくカバーしていないと、購読が想定外に届く・届かない、ということが起きます。
そして最後の確認が一番大事です。RLS を有効化したら、想定ユーザーごとに「見えるべき／見えてはいけない」を実際に試す。別アカウントでログインして、他人のデータが見えないことを目で確認してください。設定したつもりで漏れている、が一番怖いパターンです。
バックアップと復元（取るだけでなく「戻せるか」）
次にバックアップです。ここでよくある誤解が「バックアップを取っているから安心」。重要なのは取ることではなく、戻せることです。
Supabase の PITR（Point-in-Time Recovery＝任意の時点に巻き戻せる復元） は、Pro/Team/Enterprise プランの有料アドオンです（2026年6月時点）。保持期間内なら秒単位の任意の時点に戻せますが、保持期間はプランと設定によって異なります。
- 保持期間は 7日 / 14日 / 28日 から選ぶ形（最大28日, 2026年6月時点）
PITR を有効にすると Daily Backups（日次バックアップ）は停止し、代わりに WAL（更新ログ）を短い間隔でバックアップする仕組みになります。この WAL の量が復元時間を左右する、という仕様です（出典: Supabase 公式 PITR / Backups ドキュメント, 2026年6月時点）。PITR 利用には Small コンピュートアドオン以上が必要、という前提もあります。
ここで強調したいのは、プラン別の数値や前提は時点で変わりうるということ。日数やアドオンの要件は、必ず自社プランの公式ドキュメントで最新を確認してください。記事の数字を鵜呑みにせず、契約画面で見るのが確実です。
そのうえで、本番前にひとつだけ実地でやってほしいことがあります。復元を一度試しておくこと。「バックアップがある」と「実際に戻せた」は別物で、本番障害時に初めて手順を調べるのは、一番つらいタイミングになります。
アプリ側の設計も合わせて決めておきましょう。データを消すとき、フラグで消す論理削除にするか、物理削除にするか。論理削除なら「うっかり削除」からの復旧が、アプリ内の操作だけで済むことが多くなります。
環境分離（本番・検証・開発を分ける）
3つ目は環境分離です。本番DBと検証DBを同じ場所で兼用しない——これが基本です。
検証で雑にデータを入れたら本番が汚れた、テストでテーブルを消したら本番ユーザーのデータも消えた。1環境兼用は、こうした事故の温床になります。
選択肢はいくつかあります。
- Supabase プロジェクトを環境ごとに分ける
- Branching（PR向けプレビュー環境）を使う — Pro プラン以上が前提で、各ブランチが独自のインスタンスとAPI認証情報を持つ独立環境になります
- 開発は Supabase CLI でローカルに行う
Branching の使い分けとしては、プレビューブランチは一時的（PRのマージ/クローズで削除）、永続ブランチはステージングやQAのような長期環境に向く、とされています（出典: Supabase 公式 Branching ドキュメント, 2026年6月時点）。機能の提供状況やプラン要件は変わりうるので、ここも導入前に最新を確認してください。
運用面でもうひとつ。マイグレーション（DBの構造変更）はコードで管理し、手作業でのスキーマ変更をやめること。
- 構造変更はマイグレーションファイルに残す
- まず検証環境で試す
- 問題なければ本番へ反映する
この流れにしておくと、「いつ誰が何を変えたか」が追え、本番への反映も安全になります。
最後に個人情報の注意。本番データを開発環境にコピーして使うのは便利ですが、氏名・メール・電話番号などはマスキング（仮の値に置換）してから持ち込むのが原則です。
キー・接続情報の扱い
4つ目はキーの扱い。ここを間違えると、RLS をどれだけ丁寧に設定しても無意味になります。
Supabase には役割の違う2種類のキーがあります。
- anon キー（公開用） — フロントエンドに公開してよい設計。隠しても意味はなく、漏れても致命傷ではない
- service_role キー（シークレット） — RLS を完全にバイパスする「管理者キー」。絶対にクライアントに出してはいけない
ここが一番の落とし穴です。anon キーと service_role キーの役割を混同しないこと。隠すべきなのは service_role キーの方です。
service_role キーが漏洩すると、攻撃者は全データの閲覧・任意の行の改ざん・テーブルの削除・管理者アカウント作成まで可能になり、RLS による保護は一切効きません（出典: Supabase 公式「Securing your data」, 2026年6月時点）。
安全に保つ運用ルールは明快です。
- service_role キーはサーバーサイドでのみ使う
NEXT_PUBLIC_/VITE_/EXPO_PUBLIC_のような公開接頭辞を絶対に付けない（これらはブラウザに露出します）- リポジトリに直書きせず、環境変数で管理する
なお、Supabase は新しいAPIキー方式（公開用 sb_publishable_xxx とサーバー用 sb_secret_xxx）への移行を進めています。従来の JWT ベースの anon / service_role キーは「2026年末までに廃止予定」と公式ドキュメントに明記されています（2026年6月時点）。
新しいシークレットキーには、ブラウザの User-Agent で検出されると HTTP 401 を返す保護や、キー単位での個別ローテーション・即時失効といった利点があります。1つのキーが漏れたときの影響範囲（blast radius）を限定できる設計です。
いずれの方式でも、万一漏れたときのローテーション（再発行）手順を把握しておくことを忘れずに。
Vercel 運用で見落としやすいところ
Supabase 側を固めたら、次は Vercel 側です。便利すぎて見落としがちな点を挙げます。
①プレビューデプロイと本番の区別 Vercel は PR ごとに自動で確認用環境（プレビューデプロイ）を立てます。便利ですが、その URL が外部に露出しうる点は意識しておきましょう。プレビューに本番相当のデータをつないだまま放置、は避けたいところです。
②環境変数のスコープ分け Vercel の環境変数は Production / Preview / Development の3つに分けて設定できます（出典: Vercel 公式ドキュメント, 2026年6月時点）。
- ブラウザに露出してよい変数だけ
NEXT_PUBLIC_を付ける DATABASE_URLのようなサーバーシークレットはサーバー専用に保つ- 変更後は再デプロイで反映される
③実行時間とペイロードの上限 「サーバーレスは無制限」と思い込まないこと。Vercel Functions（Node.js）の上限は、公式ドキュメント（2026-06-02 最終更新）によると、最大実行時間が Fluid Compute 有効時で全プラン既定300秒（5分）、Pro/Enterprise は設定で最大800秒です。リクエスト/レスポンスのボディは最大4.5MB（超過時は413エラー）。長時間バッチや大容量アップロードは、外部ストレージや別の仕組みで回避する設計が要ります。
④独自ドメイン・SSL・キャッシュ 独自ドメインの割り当て、SSL（転送時の暗号化）、キャッシュの再検証設定。地味ですが、本番として出す前に一度ひと通り確認しておきたい項目です。
⑤DB接続のモードに注意 ここは技術的ですが重要です。サーバーレス関数は永続的なDB接続を保持しないため、各起動ごとに新規接続が開かれ、負荷時には PostgreSQL の接続上限を圧迫しえます。
Vercel などから Supabase につなぐときは、トランザクションモードのプーラー（ポート6543）を使うことが推奨されています（出典: Supabase 公式「Connecting to Postgres」, 2026年6月時点）。ポート5432の直接接続のまま本番に出すと、アクセスが増えたときに接続が枯渇しやすくなります。トランザクションモードはプリペアドステートメント非対応などの制約があるので、事前に確認しておきましょう。
⑥監視と通知 エラーが起きても気づけない、は本番では致命的です。Vercel のログだけに頼らず、エラートラッキング（例: Sentry 互換のツール）を入れて「気づける」状態にしておきましょう。障害をユーザーからの問い合わせで知る、を卒業するための一歩です。
⑦コスト構造 Vercel は関数実行・帯域などで従量課金が伸びる構造です。コールドスタート（しばらく起動されていない関数の起動に時間がかかる現象）も、初回応答に数百ミリ秒〜数秒の上乗せが起きうるとされています。アクセス増に伴う想定外請求を防ぐため、課金がどこで増えるのかは把握しておきましょう。
このあたり、複数のSaaSを組み合わせると課金箇所が散らばって把握しづらくなります。ツールが散らばる悩みについてはも参考になるはずです。
AI/ノーコードで作ったPoCを本番化するときの進め方
ここまで論点を並べましたが、「全部やらなきゃ」と身構える必要はありません。
現実的なのは、**全部作り直すのではなく「動いている資産を活かして、危ない所から固める」**こと。おすすめの順序はこうです。
- 棚卸し — 先ほどの5つのポイントを点検
- RLS・キー — まず情報漏洩につながる箇所を止める
- 環境分離 — 本番を壊さない土台をつくる
- バックアップ — 戻せる状態にして、復元を一度試す
- 監視 — 気づける状態にする
- 負荷とコスト確認 — 接続モードと課金構造をチェック
漏洩リスクが一番こわいので、RLS とキーが最優先です。
もうひとつ大事な姿勢があります。AIで生成したコードは「動く」けれど「安全とは限らない」。これは生成AIを否定する話ではなく、役割分担の話です。AIで素早く形にして、人がレビューと型・テストの追加で耐久性を上げる——このAI＋人のハイブリッド運用が、現実的でいちばん速い道だと考えています。
内製で進める場合の落とし穴も正直に書いておきます。RLS のポリシー設計、接続プーラーの選択、復元の実地検証——このあたりは「動かす」より「事故を防ぐ」ための知識で、初見だと判断に迷いやすい領域です。
ノーコード／ローコードで内製を進めること自体は良い選択で、その進め方はにまとめています。そのうえで、本番のセキュリティ設計と運用基盤の部分だけ外部の手を借りる、という線引きにすると効率的なことが多いです。
費用感についても誤解を避けたいので触れておきます。本番化のコストは、MLOps・セキュリティ強化・連携・監視まで適切に見積もると、PoC の5〜15倍になることが多いとされています（出典: BotsCrew, 2026年6月時点）。「もう動いているから安い」という前提で2〜3倍しか見込まないと、運用基盤への投資不足が後で障害や技術的負債として跳ね返る、という指摘です。何にいくらかかるかの全体像はオーダーメイドシステム開発の流れと費用で透明にしています。
最後に。本番化は一度きりのイベントではありません。運用しながら、気づいた弱点を継続的に固めていく営みです。最初から完璧を目指すより、危ない順に一歩ずつ、が現実的です。
よくある質問（FAQ）
Q1. PoCを作り直さずに本番化できますか？
多くの場合、土台を活かしたまま、危険箇所（RLS・キー・環境分離・バックアップ・監視）を順に固める形で本番化できます。ただし、PoC は使い捨て前提の暫定構成を含むことが多く、設計が破綻している場合は一部を作り直すほうが現実的なこともあります。まず現状を見てからの判断になります。
Q2. SupabaseとVercelの構成は、小規模事業でも本番運用に耐えますか？
適切に設計すれば、中小規模の本番運用に十分使えます。耐えるかどうかは設定次第で、特にRLS・バックアップ・監視の3点を満たしているかが分かれ目です。逆に言えば、この3つが抜けていると、規模が小さくても事故は起きえます。
Q3. 本番化にはどれくらいの期間・費用がかかりますか？
規模と現状の作り込み次第で大きく変わるため、一概には言えません。具体額を先に出すより、まず現状の棚卸しから始め、危ない順に優先度をつけて見積もる進め方をおすすめします。「動いているから安い」と決めつけず、運用基盤まで含めて現実的に見積もるのが、結局いちばん安全で早い道です。
まとめ：本番化は「崖を渡す設計」から
最後に要点を整理します。
- 動くこと ≠ 安全に運用できること。PoC と本番の間には見えない崖がある
- Supabase の本番設計（RLS・バックアップ・環境分離・キー管理）と Vercel 運用の注意点が、最初の関門
- RLS はデフォルト無効。service_role キーはサーバー専用。ここを外すと他の設定が無意味になる
- 数値（プラン別の保持期間や実行上限）は時点で変わる。最終判断は必ず公式ドキュメントで確認を
まずは今日、自分のPoCで**「5つの棚卸し」**を点検してみてください。①アクセス制御 ②データの混在 ③バックアップ ④環境変数 ⑤監視。当てはまるものが見つかったら、そこが本番前に固める場所です。
私たちゼットリンカーは、Next.js フルスクラッチ × AI駆動開発 × AIコンサルで、こうした「動くPoCを安全な本番へ渡す」段階のお手伝いをしています。「自分たちで作ったものを、このまま出していいか一度見てほしい」——そんな段階での棚卸しや設計レビューから、お気軽にご相談ください。一緒に、崖を安全に渡す設計を考えます。
この記事を書いた人
株式会社ゼットリンカー