前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、開発中に踏んだ3つの落とし穴を書きました。テスト環境を作っていなかったこと、欲張りすぎて2回戻したこと、そして説明不足だったこと。
今回は、公開当日です。
このシリーズで、一番冷や汗をかいた日の話になります。
2026年8月30日、日曜日の早朝
切り替えを行ったのは、8月30日の日曜日でした。
日曜日を選んだのには理由があります。防音室の当日予約はありますが、それ以外の予約は少ない曜日だからです。完全に止まる日ではありませんが、動きは比較的穏やかです。
他の曜日も検討しました。ただ、最終的に日曜で踏み切ったのは、別の理由もあります。
この2週間で、何かあっても迅速に対応できることが実証されていたからです。
開発中、何度もつまずきました。そのたびに、Claudeと一緒に短時間で直してきた。だから「何かあっても、なんとかなる」と考えました。
完璧を期して延期するのではなく、動かしながら対応する前提で日を決めた、というのが正直なところです。
そして作業は、早朝に開始しました。
それほど時間はかからないだろう、と思っていました。
結論から書くと、この日は1日がかりになりました。
切り替え自体は、スムーズでした
まず名誉のために書いておくと、システムの切り替え作業そのものは問題なく進みました。
事前にClaudeと打ち合わせをしていたので、手順は明確でした。つまずくことなく、新しい予約システムが動き始めました。
ここまでは、想定どおりです。
お客様からの1本の連絡で、血の気が引きました
公開してまもなく、リピーターのお客様から連絡がありました。
内容は、ごく普通のものです。
先の予約について、日程を変更したいという依頼でした。
障害の通知でもなければ、エラーの報告でもありません。いつもどおりの、何でもない問い合わせです。
そして対応しようとした瞬間、気づきました。
「あっ、ヤバい」
引き継いでいませんでした
何に気づいたのか。
元々の予約システムから、データを引き継いでいなかったのです。
引き継げていなかったのは、次の3つでした。
- 顧客データ
- 予約データ
- 回数券（チケット）の残数情報
新しいシステムは、まっさらな状態から作りました。テストも、空の状態で繰り返してきました。だから「すでに存在しているもの」が、完全に視界の外にあったのです。
考えてみれば当たり前の話です。新しい箱を用意したなら、中身を移さなければならない。
しかし私は、システムを作ることに集中しすぎて、その工程自体を忘れていました。
経験のある方なら、移行計画は最初から工程表に入っているはずです。私にはその発想がありませんでした。
特に怖かったのが、回数券の残数です。
予約であれば、最悪こちらで台帳を確認できます。しかし回数券は、お客様がすでに支払い済みの権利です。消えたままにしておくわけにはいきません。
そこからは、爆速で対策しました
気づいてからは、すぐに動きました。
まず、データを取り出す
幸い、BooklyはCSVで出力ができました。
ここは本当に助かりました。もし閉じたシステムだったら、打つ手がなかったかもしれません。
予約情報と顧客情報をダウンロードして、データを整えていきました。
照合のキーは、メールアドレス
移行の設計はシンプルにしました。
メールアドレスを照合キーにする、という方法です。
- 回数券の残数があるお客様は、メールアドレスを照合して、顧客登録が完了すると同時に残数が確認できるように
- 先の予約があるお客様も、メールアドレスで照合して、マイページで予約を確認できるように
ここで意識したのは、お客様に余計なことをしていただかないということです。
移行のために特別な手続きをお願いしたり、申告していただいたりする形にはしたくありませんでした。それ自体がお客様にとっての負担になりますし、離脱の原因にもなります。
とにかく、お客様に迷惑がかからないようにする。 それだけを考えました。
一発では終わりませんでした
ただ、すんなりとはいきませんでした。
Booklyから抽出したデータが完全ではなく、バグが発生しました。
どこまで戻ってデータを整え、再度アップし直す。この作業を繰り返しました。
それでも、1〜2時間で完了しました
そして最終的に、この移行作業は1〜2時間で完結しました。
冷静に考えると、これは相当なことだと思います。
顧客データを精緻化して、予約情報と突き合わせて、回数券の残数を紐づけて、バグを見つけて修正して、再投入する。
人間が手作業で処理していたら、明らかに何日もかかる仕事です。
それが、1日どころか数時間で終わりました。
実害は、ありませんでした
結果として、実害は出ませんでした。
処理が早かったおかげです。
もし対処が遅れていたら、混乱していたと思います。既存の予約が入っていない状態のカレンダーは、埋まっているはずの枠が空いて見えるということです。そこに新規の予約が入っていたら、ダブルブッキングになっていました。
スピードで対策できたのは、不幸中の幸いでした。
備えていたから助かったわけではありません。速く動けたから助かっただけです。ここは正直に書いておきます。
その後も、細かい調整が続きました
移行対応が終わっても、この日は終わりませんでした。
公開した日には、細かい調整が頻繁に発生しました。
たとえば、こういうことです。
今回のシステム改修で、キャンセルや変更に関する仕組みを変更しました。 ところが、WEBサイト側の表記が古いままで、矛盾が生じてしまったのです。
予約フォームは新しいルールで動いている。しかし、ご案内のページには以前のルールが書いてある。
お客様から見れば、どちらも同じALBEの案内です。矛盾していれば混乱しますし、キャンセル料のような金銭が絡む部分であれば、後々のトラブルにもなりかねません。
これも、前回書いた「周辺情報の抜け」と同じ構造でした。システム本体に集中していると、その周りにある文章や案内が視界から外れます。
こうした修正を繰り返しているうちに、早朝に始めた作業は、結局1日がかりになりました。
もしこれが、お客様に納品したシステムだったら
最後に、正直なことを書いておきます。
今回、大事には至りませんでした。
ただそれは、自社のサービスだったからです。
自分たちのシステムなので、全責任は私にあります。だから気づいた瞬間に自分の判断で動けました。報告も、承認も、待つ必要がない。謝る相手も、自分たちのお客様だけです。
もしこれが、お客様に提供するシステムだったら、大問題になっていたと思います。
既存データの移行を忘れて公開する。発注者から見れば、あってはならない事故です。
このシリーズでは、ここまで「AIと一緒なら2週間で作れた」という話を書いてきました。それは事実です。
しかし同時に、本番のシステムを切り替えるということは、実際にお金と信用が動くということでもあります。
自社のものなら、試せます。失敗しても、自分でかぶればいい。
人様のシステムとなれば、それはまったく別の話です。
この日の冷や汗は、そのことを教えてくれました。
次回：#10 ローンチ後に起きたこと
次回は、公開した後の話です。
直後に発覚した抜け。お客様の反応。そして今も続いている改良。
「作って終わり」ではなかった、という話を書きます。
設計資料を、無償でお渡しします
自社で予約システムを独自開発したいとお考えの事業者さまへ。
今回私たちが作成した予約システムの基本機能を構築するための設計資料を、無償でお渡しします。
どんな資料か
Claude Codeに読み込ませることで、基本機能が再現できる粒度で書いたものです。
読んで理解するための資料ではなく、開発の起点として使える資料です。
カスタマイズは、ご自身で
この資料で再現できるのは、あくまで基本機能です。
キャンセル規定も、料金体系も、回数券の扱いも、運営によって違います。 そういった部分は、ご自身でカスタマイズしてください。
そして、その作業こそが、このシリーズで書いてきたことそのものです。ポイントは技術ではなく、やりたいことを体系的に説明できるかどうかだと思っています。
ご注意
動作を保証できるものではありません。
設計資料であって、製品ではありません。環境も、使うサービスも、事業者さまごとに異なります。そのままで動くことをお約束するものではない、という点はご理解ください。
また、お渡しできるのはレンタルスペース事業または同種の事業を生業にされている方のみとさせていただきます。
お申し込み方法
お問い合わせフォームからご連絡ください。
ご用件の項目に「予約システムの設計資料を申し込む」をご用意しています。
差し支えのない範囲で、運営されている施設やご事情をお聞かせいただければ幸いです。
実際に触れるデモを公開しています
この連載で作った予約システムを、搭載している機能の一覧とあわせてご案内しています。ご予約は入りませんので、カレンダーの動き、料金の出方、申し込みの流れを自由にお試しください。同業の方、これから予約システムを作ろうとしている方に向けたものです。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」（この記事）
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事