私たちは動く予約アプリ —— サインイン、空き枠のカレンダー、決済、メールリマインダー —— を最初から最後まで 30 分で構築し、すべてのステップを記録しました。きれいなプレビューで止まるデモではありません。実在のドメイン上の、本物です。以下がそのスタックとプロンプトです。
スタック
必要なものは多くなく、AI ビルダーがそのほとんどを配線してくれます：
- Supabase —— Postgres データベースに加え、認証（メール/パスワード、マジックリンク、Google や GitHub による OAuth）と行レベルセキュリティ。これが屋台骨です。
- Stripe —— 有料予約の決済ステップ。
- Resend —— 確認メールとリマインダーメール。
肝心なのは Supabase です。本物のデータベース、本物の認証、ストレージを一つのダッシュボードから提供してくれます。だからこそ、ほとんどの AI ビルダーがこれを直接統合しています。
プロンプトごとに見る構築
おおよそ 5 つのプロンプトでたどり着けます：
- 足場作り —— 「予約アプリ。メールでサインイン。空いている 30 分枠を表示するカレンダー。」 数分で認証付きの動くアプリが手に入ります。
- データモデル ——
slotsテーブルとappointmentsテーブル。行レベルセキュリティにより、サインイン済みのユーザーは自分の予約しか見られません。 - 決済 —— 枠が確定する前の Stripe チェックアウトのステップ。
- 通知 —— 確定時の Resend メールと、予約前のリマインダー。
- 管理画面 —— 今日の予約を一覧表示するページ。
AI が間違える部分
AI ビルダーが毎回デフォルトで出荷するバグがこれです：ダブルブッキング。 素朴に作られた生成コードは、空き枠を読み取ってから予約を書き込みます —— そして 2 人が同じ瞬間に同じ枠をクリックすると、どちらの書き込みも成功してしまいます。一つの枠を二重に売ってしまったわけです。
修正は、予約を行レベルロックを伴う単一のデータベーストランザクションにすることです —— 枠の行をロックし、まだ空いているか確認し、予約を書き込み、解放する。Supabase ではこれはクライアントからの 2 つの別々のクエリではなく、Postgres のトランザクション（関数内の SELECT ... FOR UPDATE）です。頼まない限り、AI がこれに手を伸ばすことはまずありません。だから頼みましょう：
「2 人のユーザーが同じ枠を予約できないように、枠の予約を行レベルロック付きの単一の Postgres トランザクションにして。」
これがデモと、顧客に触らせられるものとの違いです —— そしてこれはまさに、AI が依然として人間によるチェックを必要とする、正しさが決定的に重要なロジックです。
出荷する
プレビュー URL 上の動くアプリは、まだ製品ではありません。自分のドメインに向けましょう —— それは10 分の作業です —— これで公開です。
結論
30 分は本物です。ただし一つだけ注釈があります：AI は素早く 95% まで連れて行ってくれますが、最後の 5% —— 並行性、セキュリティルール、お金が懸かるエッジケース —— こそ、あなたが報酬に値する働きをする場所です。その 5% がどこにあるかを知っていれば、スクリーンショットではなく本物を出荷できます。