「成果はあるのに、見せる画面がありません」
前回の記事を公開して三日ほど経った頃、ある製造業の代表の方から短いメールをいただきました。「1000枚のデジタル化結果について、私たちの現場で直接覗き込める画面はありますか」。返事を書こうとして手が止まりました。運用データは確かに蓄積されていましたが、それを手軽に見せるダッシュボードがまだなかったからです。
OCRパイプラインはバックエンドの話でした。その手前 — 決裁者が指で直接触れる画面と、その裏のデータの流れを28日以内に削り上げる仕事は、また別の呼吸です。前回のOCR運用記録でやり残した後半にあたる話を、今回お届けします。
なぜ Next.js、Supabase、Vercel の三つなのか
まず率直に申し上げると、この三つを束ねた理由は「流行っているから」ではありません。4週間という期間でフルスタックMVPが手に収まる構成を逆算していった結果、この三つが残りました。
Next.js 14は2026年時点で新規フルスタックプロジェクトの事実上のデフォルトです。App Router、Server Components、Server Actions、Middlewareが一つのフレームワーク内に束ねられており、画面側(SSR/CSR)とAPI側を同じコードベースで完結させます。別途のバックエンドリポジトリ・デプロイラインを持たないだけで、1週目の摩擦が一段軽くなります。
SupabaseはPostgresの上に認証・ストレージ・リアルタイムが乗っており、その上に行レベルセキュリティ(RLS)が標準で敷かれています。要点は「ただのデータベース」ではなく「権限がデータベースの中で決まる」点です。28日という呼吸の二つ目の軸です。
VercelはGitHubリポジトリの一行接続でCI/CDが完結します。mainブランチへのpushは即プロダクション、他のブランチには自動でプレビューURLが付きます。別途のJenkins・Docker・Kubernetes設定は不要です。決裁者にPR段階で「このURLで一度見てください」と投げる流れが、意外と大きな役割を果たします。
5ya.io 自体を削り上げた28日
今この記事が掲載されている5ya.io自体も、そうやって作られました。4ヶ国語(韓・日・英・中)のmiddlewareルーティング、ブログ・外部メディア・プロスペクト管理の管理画面、コンタクトフォーム、画像の自動生成パイプライン — 一人が4週間で削り上げたフルスタックです。抽象的な自慢ではなく、このサイトのメニュー一つひとつが、28日という呼吸の中で何を入れ、何を外したかの結果物です。
1週目 — ルーティングと認証の骨組み
middlewareでko/ja/en/zhの4ロケールのルーティングを敷き、Supabase Authで管理画面のログイン導線を作ります。RLSポリシーの草案もこの時点で一緒に描きます。画面はほとんどありません。代わりに「以降3週間がぶれない骨組み」を立てる時期です。
2週目 — データモデルとRLS
blog、external_posts、prospect_companies、contact_submissionsといった中核テーブルを一度に設計します。管理権限はサーバーサイドで検証し、クライアントバンドルにservice_roleキーが絶対に混入しないよう、環境変数の名前から分離します。ここで数日多めに使うことが、運用に入った後の一ヶ月分の事故を防いでくれます。
3週目 — 画面とプレビューの反復
PR一つごとにVercelが自動でpreview-{sha}.vercel.appのようなURLを吐き出します。外注デザイナー・プランナーに「ステージングビルドをお待ちください」という言葉が消えた初めてのプロジェクトでした。小さな変更一つひとつをURLで共有することで、意思決定の速度が体感で二倍近く速くなります。
4週目 — 多言語化と運用準備
4週目はいつも「締まりそうにない細々したものたち」の集まりです。SEOメタ、sitemap、OpenGraph画像、エラーページ、モニタリング、RLSポリシーの再点検。派手ではありませんが、決裁者がサイトを初めて開く瞬間の印象を左右します。
月次運用コスト — 実際の数字で
ここでの決裁者の質問はほぼ同じです。「で、毎月いくらかかるのですか」。
5人規模のチームが本格的に運用を始めると、Vercel Proはユーザー1名あたり月20ドルから始まり、トラフィック・コンピュートに応じて月100〜250ドルの区間で動きます。帯域100GBを超えると40ドルが追加で乗る構造です。トラフィックが急増するキャンペーンがない通常運用では、200ドルをなかなか超えません。
Supabase Proプランは25ドル前後から始まります。PITR(ポイントインタイムリストア)のような運用に必須のオプションまで乗せると、100〜200ドルの間と見ています。二つを合わせて月換算で3〜6万円ほどが、一般的なMVP 1年目のインフラ固定費だと見て大きく外れません。
韓国の外注市場の相場と比べるとどうでしょうか。Wishket(ウィシュケット)のような場所の最近のデータを見ると、シンプルなサービスのMVPで100〜300万ウォン、複雑度が上がれば300〜500万ウォン以上、APIサーバーまで自前で作る構成だと1000万ウォンから8000万ウォンまで散らばります。Supabaseのようによくできたバックエンドサービスを使う場合、バックエンド開発費が30〜50%ほど削減されるというのが、市場全般の感覚です。
Supabase運用で予め知っておきたい三つのこと
RLSは作っておけば終わり、ではありません。運用を一年近く回してきた立場から挙げると、三つが最もよく足を引っ張ります。
一つ目、すべてのpublicスキーマのテーブルでRLSをオンにすることをデフォルトにします。マイグレーションにポリシーまで一緒に書いておかないと、ある瞬間、誰でも読めるテーブルが一つ二つ紛れ込みます。二つ目、service_roleキーは絶対にクライアントバンドルに入ってはいけません。環境変数の名前から分けておく方が安全です。三つ目、RLSポリシー内で参照されるカラムには必ずインデックスを張ります。インデックスを忘れたRLSは、実運用で「なぜこんなに遅いのか」の第一の原因です。
三つとも28日という呼吸の中で最も抜け落ちやすい項目ですが、運用に入った後では最も高くつく形で取り返さなければならない項目でもあります。
「このPRから一度入ってみてください」
VercelとGitHubの組み合わせの本当の強みは、コストではなく意思決定のスピードだと考えています。
5ya.ioの運用中、最もよく使う流れがこうです。小さなコピー修正、新しいブログカテゴリ、管理画面の新メニュー — 何でもブランチを切ってPRを開けば、Vercelが自動でプレビューURLを付けてくれます。意思決定者にそのURLを投げると、30分以内に「OK」あるいは「この行だけ直してください」が返ってきます。別途のステージングビルドキュー、デザイナー同士の相互レビューのスケジュール、デモ用のデプロイ日 — こうした摩擦が一気に消えます。
28日が可能な人、難しい人
ただし正直に書きますと、28日は誰にとっても可能な呼吸ではありません。決裁者の立場で最大の変数は「企画決定のスピード」です。コードは実は最も速い部分です。毎回会議を組み直し、意思決定が2週間ずつ後ろにずれれば、28日は56日になります。
5ya.ioを削るとき最も助けられたのは、「意思決定を非同期で下せる道具がすでに揃っている」点でした。プレビューURLをSlackに投げ、コメントで意見をやり取りする流れが定着していれば、4週間で十分です。逆に、すべての決定を対面会議でのみ行うのなら、同じビルドが8週間に伸びます。
次回予告とおわりに
次回は視点を少しずらして、ラグジュアリーD2Cブランドがデジタル構築に入るとき決裁者が直面する7つの決定 — ドメイン戦略から決済、CRM、在庫同期まで — を取り上げる予定です。同じフルスタック構築でも、決裁すべき項目の重さがどう変わるかが核心です。
28日 MVP という呼吸が自社のアイデアに合うかを測ってみたい方は、5years+ 無料相談はこちらに一行送っていただいても結構です。最初の30分は無料で、現在のアイデアのフルスタック範囲 — どこまでが28日で、どこからが56日か — を一緒に整理いたします。