前回までのあらすじ
「半年・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 ローンチ後に起きたこと
次回は、公開した後の話です。
直後に発覚した抜け。お客様の反応。そして今も続いている改良。
「作って終わり」ではなかった、という話を書きます。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」（この記事）
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事