Framer / Webflow / Wix / Lovable / ideavo.ai / Bolt で予約管理システムを作る手順【2026年版・実装ガイド】
予約管理システム(カレンダー表示、空き枠選択、予約送信、確認メール、管理画面)を6つのサービス(Framer / Webflow / Wix / Lovable / ideavo.ai / Bolt)で実装する手順を、それぞれ5ステップで整理しました。Web系3つは外部スケジューラ(Cal.com / Calendly / Wix Bookings)を組み合わせるパターン、アプリ系3つはプロンプトからフルスタックで生成するパターンを比較。実装難易度・カスタマイズ性・運用コストの早見表付き。
本記事のゴール — 「予約管理システム」の最低要件を6サービスで満たす
予約管理システムと一口に言っても範囲は広いので、本記事では次の最低要件を「共通要件」として定義し、それを各サービスで満たす最短手順を整理します。 - 顧客がブラウザでサービス/日時を選んで予約できる - 同じ枠が二重予約されない(基本的な排他制御) - 予約完了時に顧客と運営者にメール通知 - 管理者が予約一覧を確認・キャンセル・変更できる - 営業時間・休業日・スタッフごとのスケジュールを管理できる より高度な要件(決済、サブスク、保険適用、診療予約の電子カルテ連携など)は本記事のスコープ外です。なお、6サービスの全体比較はFramer / Webflow / Wix AI / Lovable / ideavo.ai / Bolt 徹底比較もあわせてご参照ください。
構築パターンは2つに分かれる
6サービスは予約システムの作り方が大きく2系統に分かれます。 - Web系(Framer / Webflow)+ 外部スケジューラ: サイト本体は Framer / Webflow で作り、予約機能は Cal.com(OSS)や Calendly を埋め込む構成。マーケサイトとの統合性が高く、保守も外部サービス側に寄せられる。 - オールインワン(Wix): Wix Bookings という公式の予約モジュールが標準で利用可能。Wix エコシステムで完結。 - アプリ系(Lovable / ideavo.ai / Bolt): 「予約管理システムを作って」とプロンプトで指示し、認証・DB・スケジュール画面・管理画面までフルスタック生成。カスタマイズ自由度は最高だが、生成後のコード保守は人手前提。 以降、それぞれ5ステップで実装手順を示します。
1. Framer で作る — Cal.com 埋め込みパターン
全体像: Framer でデザイン重視のランディング/コーポレートサイトを作り、予約UI は Cal.com(オープンソース)の埋め込みコンポーネントを差し込む。 5ステップ 1. Cal.com 側のセットアップ: Cal.com にアカウント作成 → 提供サービスをイベントタイプとして登録(30分の相談、60分の施術 等)→ 営業時間・休業日・バッファ時間を設定 → Google Calendar 等とカレンダー連携 2. Framer 側でページ構成: Hero、サービス説明、スタッフ紹介、FAQ などを通常のFramer ページ作成手順で構築 3. 予約UI を埋め込み: 予約セクションに Embed コンポーネントを置き、Cal.com の埋め込み iframe / スクリプトを貼り付け 4. テーマと色を合わせる: Cal.com 側で UI の配色・フォントをサイトに揃える(ダークモード対応も Cal.com 側で) 5. 動作確認・公開: テスト予約 → メール通知(顧客/運営)が届くことを確認 → 独自ドメインで公開 運用ポイント: 予約データは Cal.com 側に蓄積されるため、エクスポートや CRM 連携は Cal.com の Webhook / API を使う。Framer 側は基本的に「フロント」だけ。
2. Webflow で作る — Cal.com / Calendly / CMS 連携パターン
全体像: Framer と同じく外部スケジューラを埋め込むのが基本だが、Webflow CMS と組み合わせて予約データの一部をサイト側で再利用できるのが強み。 5ステップ 1. CMS でサービス・スタッフの構造化: Webflow CMS に「サービス」「スタッフ」「店舗」のコレクションを作成し、それぞれを動的ページとして展開 2. Cal.com / Calendly でスケジューラ準備: 各スタッフ/店舗ごとにイベントタイプを作成。複数人ラウンドロビン配分が必要なら Calendly Teams が有力 3. 動的ページに予約UI を差し込む: 各スタッフページの中に Custom Code Embed で対応する Cal.com / Calendly URL を出し分け 4. CMS Webhook 連携: 予約発生時の Webhook を Webflow 側ではなく Zapier / Make / 自前のサーバ経由でCRM・Slack・社内DBへ転送 5. 公開・運用整備: 業務担当向けに「いつ予約が入ったか」を Slack 通知に出す。CMS の更新権限は別途絞る 運用ポイント: B2B コーポレート × 営業相談予約の組み合わせで王道のパターン。Webflow の運用ノウハウがすでにある会社では学習コストが小さい。
3. Wix で作る — Wix Bookings ネイティブ利用
全体像: Wix にはネイティブの予約モジュール Wix Bookings がある。サロン・ジム・教室・士業相談など、サービス業の単一店舗運営にもっともフィットする。 5ステップ 1. サイト雛形を AI 作成: Wix の AI ビルダーで業種・コンセプトを入力、雛形サイトを生成 2. Bookings モジュール追加: ダッシュボードから Bookings を有効化 → サービス(コース)を登録、所要時間・価格・スタッフを設定 3. スタッフ・スケジュール登録: 各スタッフのアカウントを追加、勤務曜日・時間帯・休業日を入力。Google Calendar 同期も設定 4. オンライン決済(必要なら): Wix Payments / Stripe を有効化し、予約時に前払いを取れる構成にする(無料相談など決済不要なら省略) 5. 公開・運用: 予約ページをサイトナビに配置、テスト予約で確認メール/カレンダー登録が動くことを確認 → 独自ドメインで公開 運用ポイント: 「設定 1 時間でとにかく動かす」のはこのパターンが最速。一方、後から別プラットフォームへ移行する際の移植性は低いため、業種・規模が将来大きく変わる見込みがあるなら Webflow + 外部スケジューラのほうが長期運用に向く。
4. Lovable で作る — プロンプトでフルスタック生成
全体像: Lovable に「予約管理システム」を依頼して、フロントエンド(React / TypeScript)+ バックエンド(Supabase 等)+ 認証 + DB スキーマ + 管理画面までを一括生成。 5ステップ 1. 要件をプロンプトで明文化: 「30分単位の枠で予約/二重予約防止/メール通知/管理者画面でキャンセル可能/スタッフ別スケジュール」のように、共通要件をそのまま依頼文にする 2. データモデルの確認: Lovable が生成した users / services / bookings / schedules テーブル設計をレビューし、抜けがあれば追加プロンプトで補完(例: タイムゾーン、キャンセル理由、リマインダー時刻) 3. 画面を順番に詰める: 顧客側UI → 管理者側UI → メール通知 → エラーハンドリング、と機能ごとに小さくプロンプトを積む。1つずつ動作確認しながら進めるのが鉄則 4. 本番接続の整備: メール送信は Resend / SendGrid、認証は Supabase Auth など。プロンプトで「Resend を使って」「自社ドメインで送信」と具体的に指定 5. デプロイと運用: Vercel / Netlify 等へデプロイ。生成コードは GitHub に push し、本格運用前に人間によるコードレビュー(特に認可・排他制御・タイムゾーン)を必ず行う 運用ポイント: クレジット消費が読みづらいため、最初から要件を明確にして「やり直し回数」を減らすのが効く。プロトタイプで合意 → 本番は弊社受託(Hono+Inertia+React)で再実装、というハイブリッドが品質・コストの両立に効果的。
5. ideavo.ai で作る — API キー持込の本番志向アプローチ
全体像: ideavo.ai は「使い捨てプロト」ではなく「本番に出すアプリ」を志向しており、自社の OpenAI / Anthropic API キーを持ち込めるのが特徴。予約システムのような長期運用案件と相性が良い。 5ステップ 1. API キー設定: ideavo.ai のプロジェクトで自社の OpenAI / Anthropic キーを登録。コスト管理を自社側で完結させる 2. Agent Mode で要件を会話的に固める: 共通要件をベースに、AI と対話しながらドメインモデル(services / staff / bookings / time_slots)を確定 3. 段階構築: バックエンドAPI → DB スキーマ → 顧客側UI → 管理画面 → メール通知 の順で生成し、各段階で実行・検証 4. エクスポート・自社環境への移植性確認: ideavo.ai 公式が訴求する「ロックイン抑制」ポリシーを実際にチェック — 生成コードのエクスポート手段、データの CSV/JSON エクスポート、認証・決済の差し替え手段を契約前に確認 5. デプロイ・運用: 自社の Vercel / Cloudflare Workers / VPS にデプロイ。API キー請求は OpenAI / Anthropic 側に直接行くため、コスト透明性が高い 運用ポイント: 公開実績情報が他サービスより少ないため、本番採用前に SLA、データ保持・削除ポリシー、サービス停止時のエクスポート手段を契約条件で詰めておくのが安全。詳しくは6サービス比較コラムの「持続可能性」観点もあわせて確認してください。
6. Bolt(Bolt.new)で作る — StackBlitz 基盤の高速プロト
全体像: Bolt.new はブラウザ上で動く WebContainer(StackBlitz 技術)の上で、プロンプトから React + Supabase / Node 系のフルスタックアプリを即座に立ち上げる。プロトタイプ最優先のパターン。 5ステップ 1. 共通要件をプロンプト: 「予約管理システム、30分枠、二重予約防止、Supabase、Resendでメール、管理画面別ルート」のように要件を1ブロックで投げる 2. 生成結果のブラウザ即実行: WebContainer で立ち上がったプロトを、ブラウザ上でそのままテスト予約してフローを確認 3. Figma インポート(必要なら): ブランドガイドが既にある場合、Figma から UI をインポートしてビジュアルを統一 4. GitHub と Supabase を接続: 生成コードを GitHub に同期、データベースは Supabase に永続化(Bolt 内のサンドボックスは恒久的ではない) 5. 本番ホスティングへ移行: Vercel / Netlify / Cloudflare Pages にデプロイ。トークン課金がランニングコスト。重要なロジック(決済・タイムゾーン・排他制御)は本番投入前に人間がレビュー 運用ポイント: 動くプロトタイプを30分〜1時間で出して社内合意を取るフェーズに最適。本番運用は Lovable と同様、生成コードを Git 管理に入れて受託・社内エンジニアで仕上げるのが現実解。
実装早見表 — 難易度・コスト・カスタマイズ性
| サービス | 実装パターン | 立上げ時間 | 月額コスト目安 | カスタマイズ性 | 二重予約防止 | 決済組込 | 移行容易性 |
|---|---|---|---|---|---|---|---|
| Framer | + Cal.com 埋込 | 半日〜1日 | $10〜30 + Cal.com $0〜15 | サイト:高 / 予約UI:中 | Cal.com が担保 | Cal.com 側で対応 | ◎(Cal.com は OSS) |
| Webflow | + Cal.com / Calendly | 1〜3日 | $14〜39 + スケジューラ料金 | サイト:高 / 予約UI:中 | スケジューラが担保 | Calendly Pro / Stripe 連携 | ○ |
| Wix | Wix Bookings | 半日 | $17〜36 | 中(Wix の枠内) | Wix Bookings が担保 | Wix Payments / Stripe | △ |
| Lovable | プロンプト生成 | 半日〜2日 | $20〜100+クレジット | ◎(コードを所有) | 自前実装、要レビュー | 自前実装(Stripe 等) | ◎(コード所有) |
| ideavo.ai | プロンプト+API持込 | 1〜3日 | API実費+プラン料金 | ◎(コードを所有) | 自前実装、要レビュー | 自前実装 | ◎(持込前提) |
| Bolt | プロンプト生成 | 半日〜1日 | $25〜+トークン | ◎(コードを所有) | 自前実装、要レビュー | 自前実装 | ◎(GitHub連携) |
表中の「移行容易性」は、将来別環境(自社サーバや別の SaaS)への切替コストの低さです。Web系(Framer / Webflow)+ 外部スケジューラはスケジューラ側のデータエクスポート可否、Wix は移行困難、アプリ系3つは生成コードを持てるので原理的には移行しやすい、という整理になります。
案件タイプ別の選び方
迷ったらこのフローで決めるのが現実的です: - サロン・ジム・教室など単一店舗のサービス業: Wix(Wix Bookings の出来が良く運用も簡単) - B2B コンサル/士業の相談予約: Webflow + Calendly(フォーマルな見え方と運用安定性) - デザイン重視の個人事業/クリエイター予約: Framer + Cal.com(OSS なので長期コスト低) - 既存サービスにない機能(独自の予約ロジック・社内システム連携)が必要: Lovable / ideavo.ai / Bolt で生成→受託で本番化 - MVP・PoC でとにかく動くものを社内で見せたい: Bolt または Lovable(30分〜数時間で動くプロト) - 自社が API キー管理できる、ロックインを避けたい: ideavo.ai(要・契約前確認) 本記事の前提となる6サービス全体比較・持続可能性スコアは、Framer / Webflow / Wix AI / Lovable / ideavo.ai / Bolt 徹底比較を参照してください。
実装上の注意点 — どのサービスでも気をつけるべき4点
予約システム特有のハマりポイントです。サービス選定にかかわらず必ず確認してください。 1. タイムゾーン: サーバ・DB・クライアント・予約データすべて UTC 保存+表示時に変換が鉄則。日本国内のみでも夏時間や海外顧客対応で爆発する箇所。AI 生成コードでも要レビュー。 2. 二重予約防止(排他制御): 同じ時間枠に同時に予約が入らないよう、DB レベルでのユニーク制約 or トランザクションが必須。プロンプト生成だと省略されがちなので、生成後に必ず確認。 3. キャンセルポリシーとリマインダー: 「24時間前までキャンセル可」「2時間前リマインドメール」などの運用ルールは、最初に決めておかないと後から大改修になる。 4. 個人情報の取り扱い: 予約者の氏名・連絡先・場合により予約理由(医療系等)は個人情報。プライバシーポリシーと SSL(HTTPS)は前提、データの保存場所と保持期間も初期設計で決める。
オブライトでの活用方針
オブライトでは、お客様の業種・規模・将来計画に応じて次のように使い分けています: - 小規模サービス業の予約サイト: Wix Bookings で短期立ち上げ - コーポレート × 商談予約: Webflow + Calendly でブランド統一 - デザイン重視のスモールビジネス: Framer + Cal.com - 独自要件のある業務予約システム: Lovable / Bolt でプロト → Hono + Inertia + React や Next.js で本番実装(DocDD 駆動) ノーコードビルダーで生成した下書きを、本番品質に仕上げる二段階構築が品質・コスト・スピードのバランスで最も合理的です。「自社の業務にどれが合うか分からない」段階のご相談から、本番受託まで Web 開発 / ソフトウェア開発 / AI 導入コンサルティング でワンストップ対応します。
FAQ
Q1: 一番安く・一番速く立ち上げるなら? A: Wix Bookings が最速かつ追加費用が最小。半日で公開できます。ただし将来移行困難な点と性能・カスタマイズ性は割り切りが必要。 Q2: Cal.com と Calendly どちらを推奨? A: 単一ユーザーで安く済ませたいなら Cal.com(無料プランあり、OSS でセルフホストも可)。チーム運用・SaaS 統合の安定性なら Calendly Teams。 Q3: AI 生成コード(Lovable / Bolt)で予約システムを「本番運用」して大丈夫? A: 軽微な業務(社内予約、小規模顧客向け)なら可能ですが、人間によるコードレビュー必須です。特に二重予約防止・タイムゾーン・認可(自分以外のキャンセル禁止)は AI が抜かしがちです。 Q4: Stripe で前払い課金を入れたい A: Wix は Wix Payments / Stripe 連携、Calendly は Pro 以上で Stripe 連携、Cal.com は決済アドオン、Lovable / Bolt / ideavo.ai は Stripe SDK を直接組込(プロンプトで指示)。 Q5: 既存の Google Calendar / Outlook と連携できる? A: Cal.com / Calendly / Wix Bookings はネイティブ対応。アプリ系3つは Google Calendar API などを自前で叩く実装が必要(プロンプトで具体的に指示)。 Q6: 多店舗・多スタッフ運用は? A: Wix Bookings は標準機能で対応、Calendly はラウンドロビン機能あり、Cal.com もチーム機能あり。アプリ系3つは設計次第で柔軟に作れますが、その分実装工数が増える。
参考文献
お気軽にご相談ください
お問い合わせ