Claudeで予約システムを作ったら致命的なバグがあった話｜非エンジニアのAI開発失敗談

Claudeで予約システムや申し込みフォームを自作しようとしているなら、先に読んでほしい話です。

予約は入っていないはずなのに、カレンダーが埋まっている。

最初は表示ミスかと思いました。でも確認していくと、A商品に予約が入っただけで、B商品もC商品も同じ日が予約不可になっていました。

しかも、稼働当初からずっとそうだったらしい。

なぜ自作しようとしたか

もともとはSTORESで予約管理をしていました。でも私のレンタルショップは2泊3日が基本で、STORESの予約機能では複数日にまたがるレンタルに対応できませんでした。返送・受け取り・次の準備のための前後2日のブロックも、手動で毎回入力しなければならず、手間がかかりすぎていました。

「Claudeを使えば自分仕様に作れる」と知って、自分で作ることにしました。このブログを始める前の話で、予約ページが私のClaudeデビューでした。

今思えば、浮足立ってたんだと思う。

はじめてClaudeと何かを作れた興奮で、「動いてる！すごい！」で完成にしてしまいました。当初はGitHubで公開していてセキュリティ的にも危うかったのですが、そこはすぐ気づいてCloudflareに移行しました。でも肝心の動作確認は、甘いままでした。

あわせて読みたい

AIに任せてたのに2週間気づかなかった話｜Search Consoleで発覚したサイト引越しの失敗

何が起きていたか

ある商品が予約済みになると、まったく別の独立した商品の同じ日程も、自動的にブロックされてしまっていました。

商品はそれぞれ物理的に独立しています。AさんがA商品を6月1日に予約しても、B商品・C商品は同じ6月1日に別のお客様が予約できて何も問題ない。それが普通のレンタルショップの当たり前の前提のはずでした。

なのにシステムは「誰かが6/1を予約したら、その日は全商品がNG」という判断をしていました。

え、それって…もしかして予約できなかったお客様がいたってこと？

そう。「空いていない」と思って諦めてしまった方がいたかもしれない。システム稼働当初からずっと。

原因：設計の前提が間違っていた

修正作業でClaudeに原因を聞いたところ、こんな説明が返ってきました。

「バグの原因は、GAS（Google Apps Script）の設計ミスでした。最初にシステムを作ったとき、すべての商品の予約データをひとつの『ブロックリスト』にまとめて返す設計になっていました」

ん？どういうこと？

つまりこういうこと。

3つの商品の予約状況を、「1つのリスト」でまとめて管理していました。A商品の予約が入るとそのリストに日程が追加されます。でもB商品・C商品を確認するときも同じリストを見てしまうので、「その日は使用中」と判断されてしまっていました。

商品が3つあることはClaudeに伝えていました。でもClaudeは「3つが独立して同時に予約できる」ではなく「全商品の予約をひとつのリストで管理する」設計を選んでしまいました。

正確には、Claudeの設計ミスというより、私がそこまで確認しなかったのが問題でした。「複数商品が同時に予約できること」を完成後に一度も試さなかった。Claudeに任せて、動いているように見えたから大丈夫だと思っていました。

発覚したのは偶然だった

予約システムが完成したとき、もちろん私はテストをしていました。

メールがちゃんと届くか、予約情報がスプレッドシートに記録されるか。自分が確認できることは確認しました。Claudeが「できました」と言っていたし、ちゃんと動いているように見えました。

「これで十分」と思い込んでしまっていました。

「複数の商品を同じ日に別々に予約できるか」なんて、頭にありませんでした。メールが届いて、スプレッドシートに記録されていれば、動いている。そう判断してしまいました。

Claudeの「できました」を信じすぎてしまっていた。

意図して確認しようとしたわけではなく、完全な偶然でした。

幸いだったのは、事業再開してすぐのことだったこと。最初の予約が入った直後に発覚したので、お客様への実害はなかったと思います。でも、もっと後になってから気づいていたら——と思うとぞっとします。

しかもこのとき、もうひとつのバグも同時に判明しました。

以前、予約フォームにお客様のお住まいの都道府県を入力してもらう欄を追加したのですが、その情報がスプレッドシートに反映されていませんでした。予約が入るたびに、お客様にもう一度「どちらにお住まいですか？」と聞き直すことになっていました。

気づいてなかっただけで、ずっとそうなってたんだと思うと…ぞっとする。

対処した内容

修正はClaudeと一緒にすぐ行いました。

裏側のプログラム（GAS）の修正： 全商品の予約をまとめて管理していた部分を廃止し、商品ごとに個別で管理するよう変更しました。A商品の予約はA商品のカレンダーにだけ反映されるようになりました。

予約ページ側の修正： お客様が商品を選んだタイミングで、その商品専用の空き情報をカレンダーに反映するよう変更しました。

修正にかかった時間はそれほど長くありませんでした。Claudeに状況を伝えたところ、すぐに原因を特定してコードを直してくれました。そして今度は複数商品で実際に予約テストをしました。A商品を予約してからB商品・C商品が別々に予約できることを確認して、ようやく本当の意味で「完成」しました。

今回やらかして学んだこと

AIが「できました」と言っても、正しく動いている保証はありません。今回の失敗から、自分なりの確認ルールを作りました。

プロの開発者は「テストコード」を書いて、さまざまなパターンを自動で検証します。「A商品を予約したらB商品は空いたままか？」「フォームの全項目がスプレッドシートに届いているか？」——こういった確認をプログラムが自動で繰り返す仕組みです。

でも私がやったのは、1商品に1件だけ予約を入れて「メールが届いた、OK！」それだけでした。「AIだし、間違えないでしょ」ってたかをくくっていた。何を試せばいいかも、そもそもわかっていませんでした。

複数の商品があるなら、「A商品を予約したあと、同じ日にB商品も予約できるか」を必ず試します。これをやるだけで、今回のバグはすぐ気づけました。

テスト予約でフォームの全項目を入力して、スプレッドシートの全列に届いているかチェックします。項目を追加・変更したときも毎回やります。都道府県バグもこれで防げました。

「予約できた？」だけじゃなく、実際のお客様がやりそうな操作を最初から最後まで自分で通します。画面上は動いていても、お客様の使い方とはズレていることがあります。

「前は動いてたから大丈夫」は禁物です。何かを追加・変更するたびに①〜③を一通り確認するようにしました。

でも、どこを確認すればいいかって、最初はわからなくない？

そう。だから私は「お客様になりきって最初から最後まで操作する」ってやるようにしてる。それだけで、けっこう気づけるよ。

まとめ

Claudeの設計ミスと、私の確認不足、そして知識不足からきた失敗でした。確認を省いたわけじゃない。何を確認すればいいのかが、そもそもわからなかった。これが、非エンジニアがAIと一緒に開発するときの一番怖いところだと思います。これから予約ページを作ろうとしている方に、この記事が少しでも参考になれば。

「動いてる」と「正しく動いている」は別です。Claudeを信じるのと、自分で確認しないのは別だった。そこに気づけたのが、今回一番の収穫でした。