予約システムを、​ゼロから​「作る」 ──マルチテナントSaaSを​設計から​本番まで​駆け抜けた​制作事例

制作事例 ｜ AI駆動開発の現場から

「予約システム、作れますか」——ある日、そんな相談が来た。世の中にはすでに予約サービスがいくつもある。だがそれらは、美容室特化だったり、月額が高かったり、ITが得意でない小さなお店には機能が多すぎたりする。求められていたのは、業種を問わず・シンプルで・何店舗でも展開できる、自分たちの予約システムだった。

これは、その予約システムを設計図ゼロの状態から、本番稼働まで作り切った制作事例だ。「予約」という、一見ありふれて"枯れた"領域。しかしいざ本気で作ると、マルチテナント・ダブルブッキング防止・低リテラシーへの配慮——技術の塊だった。どんな順番で、何を考えながら組み上げたのか。設計判断ごと、開示する。^[1]

01何を​作るか​："枯れた​"領域の、​本当の​難しさ

予約システムと聞くと、簡単そうに見える。「日時を選んで、ボタンを押すだけ」。だが、作る側から見ると話は逆だ。毎日たくさんの人が同時に使い、お金と時間が絡み、一つの取りこぼしがクレームになる——失敗が許されない、堅さが要る領域だ。

今回の要件は明快だった。① 業種を問わない汎用予約（美容室にも、整体にも、教室にも）。② ITが得意でない店主でも使えるシンプルさ。③ 1つの仕組みで何店舗でも展開できるマルチテナント。そして将来は、LINEやAI電話との連携まで見据える。"枯れた"どころか、本気で作れば作るほど奥が深い。だからこそ、最初に設計を固めることから始めた。

既製の予約サービスは世にたくさんある。それでも作る理由は、「だいたい合う」と「ちょうど合う」の差にある。既製品は多くの店に合わせて作られているぶん、特定の業務にはどうしても余分な機能や、足りない一点が出る。月額も、店舗が増えるほど積み上がる。"そこそこ"で妥協するか、自分たちにちょうど合うものを持つか。AIで開発のコストが下がったいま、その判断軸が変わりつつある。

02設計を、​最初に​固める

いきなりコードを書き始めない。まず設計仕様書（SPEC）とデザイン方針（DESIGN）を作り、「何を・どの順で・どう作るか」を言葉にする。AIと組むからこそ、ここがブレると全部ブレる。

決めたのは、データの設計だ。店舗・スタッフ・メニュー・予約・顧客……これらを9つのテーブルに整理し、すべてに「どの店舗のものか」を示す印（tenant_id）を持たせた。これがマルチテナントの背骨になる。さらに開発をPhase 1〜4の段階に分けた——まずは予約が取れる最小限（MVP）、次にシフト・顧客管理、その先にLINEやAI電話。いきなり全部を目指さず、動くものを最短で出してから積み上げる。この順番こそが、速さの正体だ。

なぜ、設計を先に固めることがそんなに大事なのか。AIは指示すれば猛烈な速さでコードを書く。だが「何を作るか」が曖昧なまま走らせると、速く間違った方向へ進むだけだ。データの形（どの情報を、どう関係づけて持つか）は、後から変えるほど高くつく。家の基礎と同じで、建ててから直すのは難しい。だから人間が時間をかけるべきは、設計の意思決定——ここを固めれば、実装はAIの速度に任せられる。「考える」と「書く」を分けることが、AI駆動開発の肝だ。

03マルチテナント：1つの​仕組みで、​何店舗でも

この設計の肝がマルチテナントだ。普通なら「店舗ごとに別々のシステムを作る」と考えがちだが、それでは10店舗で10個のメンテナンスが必要になる。代わりに、1つの仕組みの中に、データを店舗ごとに完全分離して同居させる。新しい店舗は、データを足すだけで増える。

怖いのは「A店のスタッフが、うっかりB店の予約を見られてしまう」事故だ。これを防ぐため、データベースの行レベルセキュリティ（RLS）を使い、「自分の店舗のデータ以外は、そもそも存在しないかのように見えなくする」仕組みを土台に敷いた。アプリ側のうっかりミスがあっても、データベースが最後の砦として店舗の壁を守る。多店舗を安全に同居させる——これが汎用予約SaaSの背骨だ。

04予約の​心臓部​：3ステップと、​ダブルブッキング防止

お客さんが触れる予約フローは、徹底して3ステップに絞った。スタッフを選ぶ → メニューを選ぶ → 日時を選ぶ。それだけ。指名なしも選べて、合計金額と所要時間はその場で自動計算。空き枠はリアルタイムで反映され、「さっきまで空いてたのに」のがっかりを減らす。

そして、予約システムで最も怖い事故がダブルブッキング——同じ時間に2人入れてしまう。画面側のチェックだけでは、2人が"同時"にボタンを押した一瞬をすり抜ける。だから最後の砦を、データベース自身に「同じスタッフの時間帯は重複させない」という物理的な制約（EXCLUDE制約）として刻んだ。アプリが何を見落としても、データベースが重複を物理的に拒否する。さらに「予定ブロック」（休憩・私用）も同じ仕組みで枠を塞ぐ。堅さは、いちばん下の層で担保する。^[2]

05店舗が​"使える​"管理画面

お客さん側がどれだけ綺麗でも、店舗側が使えなければ意味がない。ITが得意でない店主が、毎日触る場所だからだ。ここに、いちばん神経を使った。

管理画面には、開いてすぐ分かるダッシュボード（今日・今週・今月の予約数と、本日の予約一覧）。予約はリストでもカレンダーでも見られ、日・週・月で切り替えられる。スタッフを縦軸・時刻を縦に並べたタイムラインで、誰がいつ埋まっているかが一目で分かる。予約・メニュー・スタッフ・店舗設定（営業時間・休業日・お知らせ）まで、専門知識なしで運営が回るように組んだ。難しい操作は隠し、よく使うものを前に出す。"使える"とは、機能の数ではなく、迷わなさのことだ。

細部にも気を配った。電話で入った予約は管理画面から手で追加でき、休憩や私用は「予定ブロック」で枠を塞げる。同じお客さんを二重に登録しないよう、メールや電話番号で照合して名寄せする。指名料、最低限の予約受付リードタイム（「当日2時間前まで」等）、クーポンの割引……現場で実際に必要になる細かな仕様を、一つずつ潰した。店舗運営の"あるある"を、機能として先回りする。これも、使う人を具体的に思い描いて初めて出てくる配慮だ。

061日で​MVP、​そこから​怒涛の​拡張

ここからが、AI駆動開発の本領だ。設計を固めたその日のうちに、データベース・管理画面・お客さん向け予約サイト・メール通知まで——予約が取れる最小限（MVP）が動いた。

そして翌々日からは、機能が雪崩のように積み上がっていく。積み上げた拡張機能を表に整理する。

機能	内容
シフト管理	スタッフの勤務に連動した予約枠
顧客管理	来店回数・リピーター判定
カレンダー	日・週・月の3つのビューで予約を一覧
運営者画面	複数店舗を束ねて管理
クーポン	割引クーポンに対応
QRコード生成	店頭やSNSに貼れば、そこから予約ページへ
アクセス解析	簡易のアクセス解析を内蔵
カルテ	施術記録を残す

一つひとつが小さなアプリほどの重さだが、設計の土台（マルチテナント＋段階Phase）が効いて、足すたびに速くなる。枯れた領域に、これだけの機能を、これだけの速さで。これが「言語化できるものは、全て作る」の実体だ。

なぜ、足すほど速くなるのか。最初にtenant_idとRLSで「店舗ごとに分離する」土台を敷いたから、新しい機能はその上に乗せるだけでいい。クーポンを足すときも、解析を足すときも、「どの店舗のデータか」を毎回考え直さずに済む。土台が共通言語として効くので、機能間で設計がぶつからない。逆に言えば、最初の数時間の設計が、後の数十機能の速度を決めた。急がば回れ——AI駆動でも、いや、AI駆動だからこそ、土台に投資する。

07"使う​人"が​違う​：低リテラシーへの​配慮

このプロジェクトで一番こだわったのは、派手な機能ではなく「使う人への配慮」だ。お店のお客さんも、店主も、ITの専門家ではない。だから、技術を見えなくする工夫をいくつも仕込んだ。

• 予約は会員登録なしで完了。お客さんは名前とメールだけで予約でき、後からマイページで確認・キャンセルできる（確認は使い捨ての認証コードで安全に）。
• 連絡は自動で。予約確定・前日リマインド・キャンセル——必要なメールが、店舗にもお客さんにも自動で届く。「連絡を忘れた」が起きない。
• 空きはリアルタイム。同じ瞬間に他の人が予約しても、画面の空き枠がすぐ更新される。
• QRコードを置くだけ。店頭やSNSにQRを貼れば、そこから予約ページへ。難しい設定はいらない。

こうした一つひとつは地味だ。でも、地味な配慮の積み重ねが、「ITが苦手でも使える」を作る。日付のタイムゾーンずれ、メールの確実な送信、入力値の検証——表に出ない部分こそ、丁寧に潰した。とくに日時の扱いは予約システムの生命線で、「画面では14時なのに通知メールでは15時」のようなズレは、一件でも信頼を損なう。だから日本時間を基準に、表示・保存・通知のすべてで時刻がぶれないよう、ここは念入りに揃えた。使う人には見えない部分だが、見えないからこそ手を抜けない。^[3]

08​締め：枯れた​領域こそ、​作り切る

「予約システムなんて、もうあるでしょう」。確かにある。でも、"自分たちの業務に、ちょうど合う"ものは、案外どこにもない。既製品の制約に業務を合わせるか、自分たちに合うものを作るか。AIで開発のコストが変わったいま、後者が現実的な選択肢になった。

今回作ったのは、設計図ゼロから始めて、マルチテナント・ダブルブッキング防止・3ステップ予約・管理画面・シフト・顧客・クーポン・解析・カルテまでを備えた、本番で動く汎用予約SaaSだ。"枯れた"領域だからと侮らず、堅さの要る部分は最下層で担保し、使う人の目線で迷わなさを設計する。派手さはない。でも、毎日確実に動く——それが、いちばん難しい。電脳技巧集団（AI職人ギルド）は、こういう"地に足のついたものづくり"を、AI駆動で速く・確実に作り切る。

既製サービスに合わせる vs 自分たちに合わせて作る。AI駆動で、選択肢が変わった。

観点	既製の予約サービス	ゼロから作る（CAG）
業務との適合	サービスの制約に業務を合わせる	自分たちの業務に、ちょうど合わせる
多店舗展開	プランや台数で課金が膨らむ	マルチテナントで1基盤に集約
機能追加	提供側の都合・要望待ち	クーポン・カルテ・解析を必要な分だけ
連携	対応サービスの範囲内	LINE・AI電話まで設計に内包
開発速度	—（作らない）	設計初日にMVP、段階Phaseで拡張
堅さ	ブラックボックス	DB制約で重複を物理拒否＝設計を開示

※ 本記事はCAGが実際に開発した汎用予約SaaSの制作事例。顧客名・店舗名・関係者名・契約条件は伏せた匿名ケーススタディ。技術構成・設計判断は実際のものに基づく（v0・2026時点）。