【2026年版】Next.js × Supabase × Vercel で作る業務システム──技術選定から本番運用まで

「自社の業務システムを作り直したい。でも、いったい何の技術で作るのが正解なのか、判断がつかない」——情シスや事業部長の方から、こうしたご相談をよくいただきます。

候補を調べるほど選択肢が増えて、かえって動けなくなる。発注先を探そうにも「Next.js」「Supabase」といった技術名で検索しても、向き不向きまで正直に書いてある記事は意外と少ないものです。

本記事では、いま中小企業の業務システムでよく採用される Next.js × Supabase × Vercel の3点セットを取り上げます。結論から言うと、多くの社内業務システムには十分フィットしますが、万能ではありません。向くケースと向かないケース、そして本番運用で実際につまずく所まで、2026年6月時点の事実をもとに正直にお伝えします。

結局、何で作るのが正解なのと立ち止まる方へ

先に結論をお伝えします。

一覧・検索・帳票・申請承認といった「業務の社内システム」なら、この3点セットはよく合います
ただし、リアルタイム性が極端に高い処理や、大規模なバッチ・ETL、厳格なデータ所在地要件には向きません
「最新版を入れれば速い」ではなく、バージョン選定と移行コストもセットで考える前提です

つまり、銀の弾丸ではありません。ですが「中小企業が、自社の業務に合わせたシステムを、無理のないコストで持つ」という目的には、現時点でかなり現実的な組み合わせだと考えています。同じ目線で、その理由と注意点を一つずつ見ていきましょう。

3つの登場人物を一言ずつで

まずは登場人物の役割を、ざっくり一言で押さえておきます。

Next.js：ユーザーが見る「画面」と、サーバー側の処理を1つにまとめて作れるフレームワーク
Supabase：データベース（DB）・認証（ログイン）・APIを最初からセットで用意してくれる基盤
Vercel：書いたコードを本番公開し、その後の運用まで自動化してくれるホスティングサービス

家を建てるのにたとえるなら、Next.js が間取りと内装、Supabase が水道・電気・ガスといったライフライン、Vercel が「鍵を渡して住める状態にする」引き渡し作業、というイメージです。3社で役割が分かれているので、それぞれの得意分野に乗れるのが利点です。

なぜ業務システムにこの3点セットか

「なぜ今この組み合わせなのか」を、メリットの側から整理します。

コストを抑えやすい（ただし規模次第）

GitHub にコードを push するだけでビルドとデプロイが自動化されるため、環境構築・認証まわり・公開作業といった工数のかかる工程をかなり省けます（出典：ラクス技術ブログ、2026年6月時点で参照）。サーバーの初期構築に人手をかけずに済むぶん、小〜中規模なら費用を抑えやすい構成です。ただし後述のとおり、トラフィックや保存量が増えると従量課金が乗るため「規模次第」という但し書きは外せません。

人材が見つけやすい

Next.js は世界的に利用者の多いフレームワークで、扱えるエンジニアの母数が厚いのが実務上の安心材料です。属人化を避け、引き継ぎや増員をしやすいことは、長く使う業務システムでは地味に重要です。

「あちこちのSaaSを行き来する疲れ」をまとめられる

部署ごとにバラバラのSaaSが増え、データが分断していく——いわゆるSaaS疲れは、多くの企業で起きています。自社の業務フローに合わせた一画面に集約できるのは、フルスクラッチならではの利点です。この論点はで詳しく触れています。

AI駆動開発と相性が良い

Next.js と Supabase は情報量が多く、AIによるコード生成・補助との相性が良い領域です。人がAIを使いこなして開発スピードを上げる、いわゆるAI＋人のハイブリッド運用がやりやすいのです。AIを使った開発の実際はで解説しています。

PoCから本番まで地続き

小さく試した試作（PoC）を、作り直さずそのまま本番へ育てやすいのも強みです。「まず小さく検証してから判断したい」という進め方はPoCを小さく始めるための手引きにまとめています。

ここは正直に、向かないケース

良い所だけ並べても判断材料になりません。向かないケースもはっきりお伝えします。

同時接続が極端に多い処理：常時大量のリアルタイム通信が前提なら、別の設計が要ります
オンプレ・閉域網が必須：外部クラウドに出せないデータが中心なら、自己ホスト構成を検討します
DBの権限設計が極端に複雑：行レベルの制御（RLS、後述）で表現しきれない権限はつまずきの元になります
既製SaaSで十分足りる：パッケージで足りる要件にゼロから作るのは、初期コストも保守も過大です

最後の点は特に大切です。フルスクラッチは「独自の業務フローや差別化が必要な部分」に絞るのが現実的で、全部を自前で作る必要はありません。折衷案として「定型業務は既製SaaS、自社の肝になる部分だけフルスクラッチ」という分担もよく取ります。判断の軸はも参考にしてください。

役割分担をもう一歩深く

ここからは、業務システムで実際に必要になる「一覧・検索・帳票・権限」に絞って、各ツールの実装現実を見ていきます。

Next.js：画面とサーバー処理を1つに

2026年6月時点で、Next.js の最新マイナーは v16.2 系です（2026年3月公開、出典：Next.js公式ブログ）。App Router という仕組みにより、画面とサーバー側の処理を同じプロジェクト内で同居させられます。

Server Actions が Next.js 15 で安定化し、APIルートを書かずにサーバー側関数を画面から直接呼べます
業務でよくある「一覧→検索→詳細→更新」の画面が組み立てやすい構造です
SSR（サーバー描画）かSSG（静的生成）かは、社内システムでは悩みすぎなくて構いません

なお Next.js 16（2025年10月21日リリース）では、バンドラのTurbopackが標準になり、開発時の更新が体感で速くなりました。一方でキャッシュが use cache を付けるオプトイン方式（Cache Components）に変わり、ミドルウェアが proxy.ts に置き換わるなどの破壊的変更もあります（出典：Next.js公式ブログ / InfoQ、2026年6月時点）。「最新を入れれば速い」と飛びつかず、移行コストも込みでバージョンを選ぶのが現実的です。

Supabase：DBと認証を最初から

Supabase は PostgreSQL（ポストグレス、広く使われるリレーショナルDB）の上に構築されています。データが標準的なDB形式で保持されるため、後から別ツールへ移しやすいのが安心材料です。

認証（ログイン）が標準装備。パスワード・マジックリンク・OTP・ソーシャルログイン・SSO（SAML）に対応します
MFA（多要素認証）はTOTPやSMSをサポートします
そして肝になるのが RLS（Row Level Security＝行レベルのアクセス制御） です

RLSは「このユーザーはこの行だけ見える／書ける」をDB自体に持たせる仕組みで、認証とアクセス制御が一体化している点がSupabaseの特徴です。ただしここは事故も起きやすい所なので、章を改めて深掘りします。

Vercel：公開と運用の自動化

Vercel は、コードを push するだけでプレビューURLを自動生成し、本番公開とスケール（負荷に応じた拡張）まで面倒を見てくれます。レビュー時に「この状態を実際に触って確認」がしやすいのは、業務システムの仕様調整で効いてきます。

一方で、コールドスタート（しばらく呼ばれていない処理の初回が遅れる現象）や料金体系には注意が要ります。この2点は、次の本番運用の章で具体的に扱います。

技術選定から本番までの流れ

3点セットの輪郭がつかめたところで、実際の進め方を流れで示します。費用の内訳は開発の流れと費用を公開した記事に詳しいので、本記事では「技術選定の順序」に絞ります。

業務の棚卸し：今ある業務とデータを洗い出し、何を社内システム化するか決めます
適合チェック：前述の「向かないケース」に当たらないかを先に確認します
PoC（小さく試作）：肝になる1画面だけ作り、使い勝手を確かめます
RLS方針を先に決める：権限設計は後回しにせず、ここで方針を固めます（事故予防のため）
AI＋人で実装：定型部分はAIで素早く、判断が要る部分は人が設計します
Vercelで公開：push起点でデプロイし、プレビューで関係者と確認します
内製化へ：運用しながら、自社で改修できる体制に少しずつ移します

順番のポイントは「RLS方針を実装より前に決める」ことです。権限は後から足すと漏れが出やすく、業務システムでは情報の見え方そのものが品質になります。

本番運用で詰まる4つの所

ここが本記事でいちばんお伝えしたい所です。きれいに動いた後、運用フェーズで実際につまずく4点を挙げます。

1. コストが思ったより増える

Supabase：無料プランはDB 500MB・月間アクティブユーザー（MAU）5万・アクティブ2プロジェクトが目安で、1週間未使用で一時停止されます。本番は実質Proプラン（プロジェクトあたり月25ドル〜＋超過従量）が前提です（出典：uibakery / metacto、2026年6月時点）
Vercel：Hobbyプランは個人・非商用が前提です。商用の業務システムはProプラン（シートあたり月20ドル〜）が必要で、利用クレジット20ドル分・関数呼び出し100万回／月などが含まれます（出典：Vercel公式、2026年6月時点）
さらにFluid Compute のCPU実行秒課金やデータ転送が乗るため、トラフィック次第で月額は動きます

「無料で本番運用できる」は誤解だ、と最初に共有しておくのが誠実だと考えています。

2. RLSの設定漏れは情報漏えいに直結する

これが最大の落とし穴です。Supabaseで新規テーブルを作ると、RLSはデフォルト無効です。有効化を忘れると、匿名（anon）公開APIキー経由で全行が読めてしまいます。

実際、2025年5月開示のCVE-2025-48757では、分析対象のあるプロジェクト群の10.3%で、未認証リクエストからテーブルが読めた事例が報告されています（出典：vibeappscanner、2026年6月時点）。「SupabaseならRLSを設定するだけで安全」は誤りで、設定と検証が前提です。典型的なつまずきは次のとおりです。

RLSを有効化済みでもポリシー未設定だと、クエリ結果が空になる
UPDATE用のポリシーには対応するSELECTポリシーが必要で、無いと更新が静かに失敗する
書き込みポリシーは authenticated ロールにスコープすべき（anonへの無意識な許可が危険）
RLSで参照する列にはインデックスを張る（最大の性能ボトルネックになりやすい）

検証のコツも一つ。RLSはSQL Editorではなくクライアント側SDKからテストしてください。SQL EditorはRLSをバイパスするため、Editorで動いてもクライアントから失敗するケースがあります。

3. コールドスタートと「常駐処理が動かない」問題

Vercelの関数は、しばらく呼ばれないとアーカイブされ、初回応答が通常より1秒以上遅れることがあります。DB接続はコールド時に張り直されるため、Supabaseへ直接つなぐと接続が枯渇しがちです。**Supavisorのトランザクションモード（ポート6543）**でプーリングするのが前提、という但し書きが要ります。

また、常駐ワーカーや長時間バッチ、永続的なバックグラウンド処理には向きません。関数タイムアウトは既定300秒（Fluid Compute有効・Pro時、最大800秒に拡張可）です。重い夜間バッチや常時稼働処理は、VPSや専用ワーカーなど別基盤へ逃がす設計が現実的です。

4. ロックインは「出口」を残しておく

特定サービスに縛られる不安は当然あります。救いは、Supabaseが標準のPostgreSQLである点です。データは一般的なリレーショナルDB形式で保持され、OSSとして自己ホストもできるため、いざとなれば別環境へ移せます（出典：Supabase公式ドキュメント、2026年6月時点）。「移れる構成にしておく」という出口設計を最初に意識しておくと安心です。

内製か受託か判断の目安

「では、自社で作るべきか、外に頼むべきか」。ここは中立にお伝えします。

内製が向く：社内に経験者がいて、長期的に手を入れ続ける体制がある場合
受託の伴走が向く：設計と権限方針だけ先に固め、その後の内製化を見据えたい場合
避けたいのは丸投げ：受託は「完全自動化」ではなく、要件の言語化はお客様側にも必要です

なお「フルスクラッチ＝常にベスト」でもありません。フルスクラッチは独自の業務フローや差別化に効く一方、SaaSで足りる部分まで自作すると保守が重くなります。自社開発を選ぶ判断軸そのものはに整理しました。発注先選びで失敗しないための観点はAI開発会社の選び方が参考になります。

よくある質問（FAQ）

Q1. 既製のSaaSやパッケージで足りるなら、そちらの方がいいですか？

足りるなら、その方がよいことが多いです。フルスクラッチは初期コストと保守の負担を伴うため、定型業務は既製SaaSに任せ、自社の差別化に効く部分だけ作る——という使い分けが現実的です。本記事の3点セットは「既製で足りない独自要件」がある時にこそ生きます。

Q2. Supabaseがサービス終了したら、データはどうなりますか？

Supabaseは標準のPostgreSQL上に構築されており、データは一般的なリレーショナルDB形式で保持されます。そのため任意のツールやプラットフォームへ移行でき、OSSとして自己ホストも可能です（2026年6月時点）。「出口がある」ことは、長期運用を前提とする業務システムでは重要な安心材料です。

Q3. コストは結局いくらかかりますか？

規模次第、というのが正直な答えです。無料枠から始められますが、本番運用は実質、Supabase Pro（月25ドル／プロジェクト〜）とVercel Pro（月20ドル／シート〜）に従量課金が乗ります（いずれも2026年6月時点）。トラフィックや保存量で変動するため、PoC段階で実トラフィックを当てて実測し、見積もるのが確実です。

まとめ、現実的な第一手

最後に、押さえておきたい3点を再確認します。

Next.js × Supabase × Vercel は、社内の業務システムにはよく合う一方で万能ではない
本番ではコスト・RLSの設定漏れ・コールドスタート・ロックインの4点に備える
フルスクラッチは「独自要件と差別化」に絞り、出口（移行できる構成）を残しておく

「最新ツールで何でも速く」ではなく、向き不向きを見極めて、要件に合う部分にだけ使う。それが遠回りに見えて、いちばん堅実な第一手だと考えています。

もし「自社の業務システムに、この構成が合うのか判断がつかない」とお感じなら、まずは要件の棚卸しから始めてみてください。ゼットリンカーの無料相談では、要件の棚卸しと向き不向きの見極めをご一緒にお手伝いできます。技術名だけで決めず、御社の業務にフィットするかを一緒に確かめましょう。