1日でMVPを作る — Supabase フル活用の高速開発術

はじめに — 「1日で作る」という選択

個人開発で「1日でMVPを作る」と聞くと、無謀に思えるかもしれません。しかし、適切な技術選定と設計パターン、そして Claude Code との協業 があれば、それは現実的な目標になります。

私は2025年末から2026年初にかけて、PMとしての企画・設計・判断に集中し、実装はAIに依頼するスタイルで、複数のプロダクトを「1日でMVPの骨格を構築する」方針で開発してきました。

• Wakulier（フリーランス向け依頼管理ツール）: 2025年12月27日に0から骨格を構築
• BandBridge（ミュージシャンマッチングサービス）: 2026年1月7日にPhase 1-4を完了

この記事では、1日でMVPを作り上げるための技術選定と設計パターンを、実際の開発日記をもとに解説します。

なぜ「1日」にこだわるのか

1日でMVPを作ることには、いくつかのメリットがあります。

勢いを維持できる

個人開発では、モチベーションの維持が最大の課題です。開発期間が長くなると、途中で飽きたり、他のアイデアに気を取られたりしがちです。

1日で動くものを作ってしまえば、「形になった」という達成感が得られます。翌日からは「新しく作る」ではなく「改善する」モードに入れるので、心理的なハードルが下がります。

Wakulier の開発日記（2025年12月27日）には、こう書いています。

1日で骨格を作り切ることで、翌日から改善に集中できる

意思決定が速くなる

時間制約があると、「どの技術を使うか」「どこまで作り込むか」の判断が速くなります。完璧を目指す余裕がないため、本当に必要な機能だけに集中できます。

フィードバックを早く得られる

1日でMVPを公開すれば、翌日からユーザーのフィードバックを得られます。作り込んでからリリースするより、早い段階で方向性の検証ができます。

技術選定 — Supabase がカギ

1日でMVPを作るためには、バックエンドの工数を最小化することが重要です。私の場合、Supabase を全面的に採用することで、これを実現しました。

Supabase を選んだ理由

BandBridge の開発日記（2026年1月7日）には、技術選定の理由がこう記録されています。

Supabase: PostgreSQL + Auth + Storage + Realtimeがオールインワン。個人開発でバックエンド工数を最小化

Supabase は、以下の機能を1つのサービスで提供しています。

これらを個別に構築・統合する工数を考えると、Supabase を使うことで数日分の作業を省略できます。

Google OAuth のみに絞る

認証方式も絞り込みました。

Google OAuth のみ: メールパスワード認証より離脱率が低い

メール・パスワード認証を実装すると、パスワードリセット機能、メール確認フロー、セキュリティ対策など、付随する作業が増えます。Google OAuth だけに絞ることで、認証周りの実装を最小限に抑えられます。

ターゲットユーザー（フリーランス、ミュージシャン）の多くが Google アカウントを持っているという前提も、この判断を支えています。

設計パターン — RLS First

Supabase を使う際に重要なのが、RLS（Row Level Security）を中心に設計する「RLS First」のアプローチです。

RLS First とは

RLS は、PostgreSQL のデータベース層でアクセス制御を行う機能です。「誰がどのデータを読み書きできるか」をデータベースのポリシーとして定義します。

Wakulier の開発日記には、この設計思想がこう記録されています。

RLS優先: セキュリティをデータベース層で担保。APIルートでの漏れを防ぐ

従来のアプローチでは、APIルート（サーバー側のエンドポイント）でアクセス制御を実装します。しかし、この方法には問題があります。

• APIルートごとに認可ロジックを書く必要がある
• 新しいエンドポイントを追加するたびに、認可漏れのリスクがある
• フロントエンドから直接データベースにアクセスできない

RLS First で設計すると、これらの問題が解決します。

• データベース層で一元的にアクセス制御
• APIルートを経由しなくても、クライアントから安全にデータアクセス可能
• 認可漏れのリスクが大幅に減少

「デフォルト拒否」の原則

RLS を設計する際は、「デフォルト拒否」の原則に従います。BandBridge の RLS 設計では、Claude Code との間でこんなやり取りがありました：

Zeronova

BandBridge はマッチングサービスだから、プロフィールの公開範囲とスカウトの送受信権限が複雑になりそう。最初はシンプルに始めたい。

Claude Code

RLS を「デフォルト拒否」で設計し、必要な権限だけを明示的に付与するのが安全です。何もポリシーを書かなければ誰もアクセスできない状態からスタートするので、権限の追加は後から段階的にできます。

Zeronova

それなら、まず最小限のポリシーで始めて、ブロック機能もRLSで制御できるか。

Claude Code

はい、ブロック機能をRLSと連携させれば、API レベルで完全にブロックできます。クライアント側でのバイパスも防げます。

開発日記にもこう記録しています：

RLSは「デフォルト拒否」で設計し、必要な権限だけ付与するのが安全

何もポリシーを書かなければ、誰もデータにアクセスできない状態からスタートします。その上で、必要なアクセス権限だけを明示的に付与していきます。

-- まず全テーブルで RLS を有効化（デフォルト拒否）
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- 必要な権限だけを付与
CREATE POLICY "Users can view own profile"
  ON profiles FOR SELECT
  USING (auth.uid() = user_id);

この方法なら、うっかりアクセス制御を書き忘れても、データが漏洩することはありません。

RLS First のメリット

RLS First で設計すると、APIルートの実装がシンプルになります。

Wakulier の開発日記にはこう書かれています。

「RLS first」で設計すると、APIルートの実装がシンプルになる

APIルート内で「このユーザーはこのデータにアクセスできるか？」を判断する必要がなくなります。データベースにクエリを投げれば、RLS が自動的にフィルタリングしてくれるからです。

BandBridge の実例 — 1日で何を作ったか

BandBridge は、ミュージシャン同士をマッチングするサービスです。2026年1月7日の1日で、以下のフェーズをすべて完了しました。

Phase 1: 基盤構築

開発日記には、最初に構築した内容がこう記録されています。

• Next.js 16 プロジェクト作成（App Router, Turbopack）
• TypeScript 5.9 (strict mode) + Tailwind CSS 4 + Shadcn UI
• Supabase セットアップ（PostgreSQL, Auth, Storage, Realtime）
• データベーススキーマ作成（profiles, music_stories, bands, recruitments, scouts, conversations, messages, reports, blocks）
• RLS ポリシー設定
• Google OAuth 認証実装
• 共通レイアウト作成（Header, Footer, Sidebar）
• Vercel設定、GitHub Actions CI

技術スタックを固定化することで、「どの技術を使うか」の意思決定時間を省略しています。Next.js + Supabase + Tailwind CSS + Shadcn UI の組み合わせは、他のプロダクトでも共通して使用しているため、PMとして要件を伝えれば Claude Code がすぐに着手できました。

Phase 2: プロフィール機能

• オンボーディングウィザード（ユーザー種別選択）
• プロフィール編集ページ（基本情報 + 音楽ストーリー）
• Supabase Storage バケット作成（avatars, sounds）
• 画像・音源アップロード、YouTube埋め込み
• 公開プロフィールページ（/u/[username]）+ 動的OGP生成

ユーザーが自分の情報を登録し、公開できる機能一式です。画像・音源のアップロードも Supabase Storage を使うことで、最小限のコードで実装できました。

Phase 3: バンド・検索・スカウト機能

• バンド作成・編集・管理ページ
• 募集作成・編集、ステータス管理
• 検索ページ（ミュージシャン/バンド/募集の3タブ）
• フィルター実装（パート、地域、ジャンル、活動頻度）
• pg_trgm インデックス作成（全文検索高速化）
• スカウト送信・受信・承諾/辞退機能
• 承諾時のチャットルーム自動作成

マッチングサービスのコア機能です。検索、フィルタリング、スカウト（マッチング申請）の機能を Claude Code で1日のうちに実装しました。PMとしてはビジネスロジックの要件定義とUIの方向性を指示し、実装結果をレビューして修正を依頼するサイクルを回しています。

Phase 4: メッセージング・安全機能

• リアルタイムチャット（Supabase Realtime）
• 未読表示・既読マーキング（last_read_at JSONBカラム）
• 通報機能（カテゴリ選択 + 詳細入力）
• ブロック機能（RLSでスカウト/メッセージ送信制限）
• 設定ページ、ブロックリスト管理

Supabase Realtime を使うことで、リアルタイムチャットも短時間で実装できました。ブロック機能は RLS と連携させることで、APIレベルでの完全なブロックを実現しています。

高速開発のための6つのポイント

BandBridge と Wakulier の開発経験から、1日でMVPを作るためのポイントをまとめます。

1. 技術スタックを固定する

毎回「どの技術を使うか」を考えていると、時間がかかります。自分にとっての「定番スタック」を決めておき、新しいプロダクトでもそれを使い回します。

私の場合：

• フレームワーク: Next.js（App Router）
• データベース/認証/ストレージ: Supabase
• スタイリング: Tailwind CSS + Shadcn UI
• デプロイ: Vercel

2. RLS First で設計する

APIルートでのアクセス制御を最小化することで、実装量を減らせます。RLS のポリシーを最初に設計しておけば、あとはクエリを投げるだけで安全にデータアクセスできます。

3. 認証方式を絞る

OAuth（Google, GitHub など）だけに絞ることで、パスワード管理やメール確認の実装を省略できます。ターゲットユーザーがどのアカウントを持っているかを考慮して、最適な方式を1つ選びます。

4. UI コンポーネントライブラリを使う

Shadcn UI のようなコンポーネントライブラリを使うことで、UIの実装時間を大幅に短縮できます。自前でボタンやモーダルを作る必要がありません。

5. AIに実装を任せ、PMの判断に集中する

1日でMVPを作れる最大の理由は、Claude Code に実装を依頼しているからです。PMとして「何を作るか」「なぜ作るか」の判断に集中し、「どう作るか」はAIに任せる。この役割分担が、1日という制約の中で最大限の成果を出すカギです。

6. 翌日以降に「改善」を回す

1日目は「動くもの」を作ることに集中し、細かい改善は翌日以降に回します。完璧を目指さず、まず形にすることを優先します。

注意点 — 1日で作るべきでないもの

「1日でMVPを作る」アプローチは万能ではありません。以下のようなケースでは、より時間をかけるべきです。

セキュリティが特に重要なサービス

金融系、医療系など、セキュリティ要件が厳しいサービスでは、慎重な設計とレビューが必要です。1日で作って終わりにすべきではありません。

複雑なビジネスロジックがあるサービス

ビジネスルールが複雑な場合、1日では設計しきれません。ドメイン知識を整理し、適切なモデリングを行う時間が必要です。

既存システムとの連携が多いサービス

外部APIとの連携が多い場合、それぞれのAPIの仕様理解と統合テストに時間がかかります。

まとめ — 「1日で動くもの」の価値

1日でMVPを作ることは、適切な技術選定と設計パターンがあれば可能です。

技術選定のポイント:

• Supabase でバックエンド工数を最小化
• Google OAuth のみに絞って認証を簡素化
• 使い慣れた技術スタックを固定化

設計のポイント:

• RLS First でデータベース層からセキュリティを担保
• 「デフォルト拒否」の原則でアクセス制御
• APIルートの実装をシンプルに

開発スタイルのポイント:

• PMとして「何を作るか」に集中し、実装は Claude Code に任せる
• AIの出力をレビューして修正を依頼するサイクルを回す
• 1日目は「動くもの」に集中、翌日から「改善」モードに移行

Wakulier の開発日記に書いた「1日で骨格を作り切ることで、翌日から改善に集中できる」という言葉が、このアプローチの本質を表しています。

動くものがあるかないかで、開発の進め方は大きく変わります。まず1日で形にして、そこから育てていく。Supabase という強力なバックエンド基盤と、Claude Code というAIパートナーの組み合わせが、個人開発の可能性を大きく広げてくれています。