数年前、システム会社に予約システムの見積もりを取りました。
返ってきた答えは、「半年・最低500万円」。
その時点で諦めました。私はプログラマーではありません。コードは書けません。だから、その金額が妥当なのかどうかも判断できませんでした。
それから数年後の2026年、お盆休みのことです。
ふと思い立って、AI（Claude）にこう聞いてみました。
「レンタルスペースの予約システムって、オリジナルで作れる?」
返ってきた答えは、「作れます」でした。
そこから2週間。実際に動く予約システムが完成し、2026年8月30日に本番稼働しています。
このページは、その2週間を記録した全12話の連載のまとめです。
結局、何ができたのか
まず、完成したものから書きます。
- 予約カレンダー（日付から入る導線／◯△✕の空き表示／空き状況ページ）
- 料金設計（曜日別・シーズン別・任意の日を土日祝扱いにする機能／時間貸しと1日貸しの併売）
- 決済（Stripe連携／クレジットカード・コンビニ払い・銀行振込／入金の自動確認）
- Googleカレンダー双方向同期（自社予約＋ポータル経由の予約を1つの台帳に集約）
- メール通知50種類以上（予約、入金、変更、キャンセル、督促、リマインド)
- 回数券・チケット管理
- 多言語対応（日本語を更新すると英語も自動で更新される）
- デジタルサイネージ連携
- SwitchBot連携による自動解錠・自動施錠
- 管理画面（ブロック、商談中フラグ、公開時期の指定など）
これを、コードが書けない人間が2週間で作りました。
かかった費用
| 項目 | 金額 |
|---|---|
| Claude（AI） | 月額 約30,000円 |
| Cloudflare（サーバー） | 月額 約700円 |
| GitHub（変更履歴の管理） | 無料 |
ひとつだけ補足すると、無料プランでは進みませんでした。 ある程度まとまった量のやり取りが必要になるので、ここは有料にする必要があります。
全12話のあらすじ
#1 きっかけ編 — 「作れます」の一言から始まった
500万円と言われて諦め、海外製のWordPressプラグイン（Bookly）を3年間使ってきた経緯。お盆休みに思いつきでAIに聞いてみたところ、初日にモックで予約カレンダーと申込導線ができてしまった話。私が出した指示は「カレンダーから入りたい」の一言だけでした。
そして、以前システム会社のために作っておいた簡単な箇条書きのメモが、思わぬ形で役に立ちます。
#2 準備編 — Cloudflareが何かも分かっていなかった
サーバーもGitHubも、何のことか分からない状態からのスタート。それぞれを自分なりに理解した例え話と、「サーバーへのアップをお願いできる?」と聞いたら作業が一気に短縮されたという話。
ここで得た教訓は、AIは聞かれないと教えてくれないということでした。
#3 予約カレンダーと顧客導線 — なぜ日付から入らせるのか
なぜプランからではなくカレンダーから入る設計にしたのか。◯△✕をどういう基準で出しているのか。そして、空き状況ページを作ったら電話問い合わせがパタッと止まった話。
#4 料金設計という難所 — AIは「やめたほうがいい」とは言ってくれない
一番苦労したのが料金でした。昼夜で料金を分ける機能は「組める」と言われたのに、作りませんでした。 その理由は、システムの限界ではなく人間側の限界です。
そして、名古屋アジア競技大会に向けたレベニューマネジメントの考え方も書いています。
#5 決済とStripe — 「借りてくるもの」だという思い込み
決済はプラグインやパッケージがないと作れない、と思い込んでいました。実際にはStripeが柔軟で、足りなかったのはその手前のプラグインのほうだったという話。
自分で実際にコンビニと銀行から入金して、テストは100回を超えました。
#6 Googleカレンダー双方向同期 — 台帳は1つでいい
自社サイト、スペースマーケット、インスタベース。3つの経路の予約を、Googleカレンダー1つに集約しています。ダブルブッキングをどう防いでいるか、そして「商談中」フラグで次のお客様をプールする運用について。
実装は、拍子抜けするほど簡単でした。
#7 メールと通知の設計 — 10年間、諦めていたこと
ASPでは文面は変えられても、送る場面を増やすことはできません。 10年間「この場面でメールが飛ぶといいのに」と思いながら諦めてきたことを、全部やりました。
発想の源になったのは、WEB制作の知識ではなく自分がネットで買い物をしたときの体験でした。
#8 思わぬ落とし穴 — 2回、巻き戻しました
テスト環境を作らずに本番だけで作っていたこと。欲張りすぎて仕様が矛盾し、GitHubから2回巻き戻したこと。そして、作る前に「こういうことを実現したいけど可能?」と聞くやり方に変えた理由。
噛み合わないのはAIのせいではなく、私の説明不足でした。
#9 ローンチ当日 — 「あっ、ヤバい」
2026年8月30日、日曜日の早朝に切り替え。順調に見えた矢先、リピーターからの日程変更依頼で血の気が引きました。顧客データも、予約データも、回数券の残数も引き継いでいなかったのです。
人間なら何日もかかる復旧を、1〜2時間で終えました。
#10 ローンチ後に起きたこと — 作った本人には見つけられない
公開当日、スタッフに本番で予約操作をしてもらいました。そこで分かったのは、迷わない人間が何度テストしても、迷う場所は見つからないという当たり前の事実です。
バグではない正常動作が、お客様にとっては困る挙動だったという例も書いています。
#11 SwitchBot連携と、鍵のオペレーション
予約の5分前に自動で解錠。施錠はスペースごとに設定。最も警戒したのは「開かない」ことでした。閉まらないのは後で手が打てますが、開かないのは即座にお客様が困ります。
そして、予約より早く来て勝手に準備を始めてしまうという長年の悩みも、説明せずに解決しました。
#12 最終回 — 私でも、優秀なプログラマーを配下に置ける
2週間を通して一番驚いたこと。ノンプログラマーでもどこまでいけるのか。そして、全部を作らなくてもいいという話。
このシリーズの本当の行き先についても書いています。
通して分かった、3つのこと
1. 技術ではなく、説明できるかどうか
コードの知識は要りませんでした。必要だったのは、やりたいことを体系的に説明する力です。
5W1Hを押さえて、なぜそうしたいのかという背景まで伝える。そうすると、返ってくる提案の質が変わります。
2. 運営経験が、そのまま仕様書になる
なぜキャンセル規定を31日前で区切るのか。なぜ回数券を予約に跨がせないのか。なぜ商談中の表示が必要なのか。
これらはAIに聞いても出てきません。 10年やってきたから分かることです。
裏を返せば、自分の商売を何年もやっている方には、すでにその資産があるということでもあります。
3. つなげられるものは、つながる
決済も、カレンダー同期も、鍵も、「大がかりな仕組みが必要なのだろう」と思い込んでいました。
実際には、予約情報を外に届けるだけの話でした。
全部を作る必要はありません
ここまで読んで「さすがに自分には無理だ」と感じた方もいると思います。
でも、全部作る必要はありません。
- 鍵の自動化だけ
- 支払いの部分だけ
- 空き状況を見せるカレンダーだけ
- 館内サイネージだけ
部分的なオリジナルでも、十分に意味があります。むしろ、そこから始めるほうが現実的です。
そして、その先にあるのが直販です。
ポータルサイト経由には手数料がかかります。私たちの業界でいえば30%程度。直販にはそれがありません。受け皿さえ自前で持てれば、その可能性は確実に広がります。
関連記事
予約システムそのものの話だけでなく、運営ルールの設計についても記事を公開しています。
- レンタルスペースの予約システムがASPで合わない理由と、自社開発という選択肢
- レンタルスペースのキャンセルポリシー実例｜規定・料率・運用の考え方を公開します
- 前金か後払いか｜レンタルスペースの入金設計を10年やって出した結論
【筆者】
レンタルスペースALBE 運営会社 株式会社ファーストクリエイト 代表取締役 鬼頭創一
シリーズ一覧（全12話）
- 連載まとめ・目次（この記事）
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事