前回の記事では、既存の予約サービスを使わず、紹介を受けたエンジニアへ10万円程度で予約システムの開発を依頼したものの、最終的には本番で使わなかった経緯を書きました。
本番で採用したのは、私がClaude Codeを使って作った別の予約システムです。
大方の機能は、開発を始めてから4日程度で実装できました。ただし、これは「AIに頼めば、誰でも4日で安全な業務システムを完成させられる」という話ではありません。
実際には、必要な業務ルールを決めること、生成されたものを確認すること、本番利用を想定してテストすること、公開後も保守することが必要でした。
今回は、Claude Codeを使ってどのように予約システムを作ったのか、どのテストを重視したのか、実際の運用費や自作の負担も含めて振り返ります。
Webエンジニアではないが、まったくの未経験でもなかった
予約システムを作り始めた時点で、Claude Codeの利用経験は半年に満たない程度でした。
私はWebエンジニアではありません。Next.js、データベース、認証、フロントエンド、バックエンドなども、Claude Codeを使ってアプリを作る過程で学んだものです。
一方で、以前からPython、VBA、C、C++などを使った経験はあり、Claude Codeでも勉強や試作を兼ねて複数のアプリを作っていました。そのため、指示の出し方、エラーが出たときの調べ方、変更後に何を確認すべきかは、ある程度理解していました。
大方の機能を4日程度で実装できた背景には、この準備期間があります。使い始めた初日に、同じものを4日で作れたとは思いません。
外注版を作り直したのではなく、別のシステムを一から作った
外注した予約システムはWebアプリとして納品され、ソースコードは受け取っていません。画面デザインも流用していません。
また、外注時に作成した要件定義書を、そのままClaude Codeへ読み込ませて再現させたわけでもありません。
店舗で必要な業務ルールは自分の中にあったため、Claude Codeと対話しながら、技術構成、データの持ち方、画面、権限、処理の流れを一つずつ決め、スクラッチから実装しました。
必要だったのは、単純な予約受付だけではありません。
- 管理者、トレーナー、会員の認証と権限分け
- 会員・コース管理
- 予約、キャンセル、キャンセル待ち
- 契約回数の付与、仮押さえ、消費、繰り越し
- トレーニングカルテ
- メール通知
- 外部の決済サービスから受け取る会員情報との整合
- 定期処理
- 操作履歴
Claude Codeは実装を速めてくれましたが、「店舗で何をどう運用するか」まで自動的に決めてくれるわけではありません。曖昧な指示をすると、動くものはできても、実際の業務には合わないことがあります。
4日でできたのは「主要機能の大方」だった
開発を始めてから4日程度で、予約システムとして必要な主要機能の大方は動くようになりました。
ここでいう4日には、現在まで続いている改善や保守の時間は含まれていません。本番で安心して使える状態にするには、データの確認、例外処理、画面の使いやすさ、端末ごとの動作、バックアップや障害時の対応なども考える必要があります。
AIを使うと、画面や処理を作る速度は大きく上げられます。しかし、実装が速いことと、本番運用に耐えられることは別でした。
その差を埋めるために、私が特に重視したのが受入テスト、いわゆるUATです。
自動テストだけでなく、役割別のUATを行った
テスト環境を用意し、ユニットテスト、統合テスト、リグレッションテストは、ある程度Claude Codeに実行してもらいました。AgentやMCPも利用し、人が繰り返し操作しなくても確認できる範囲を増やしました。
それでも、自動テストだけで本番へ出すことはしませんでした。
予約システムは、最初の管理者を設定するところから始まります。管理者がトレーナーを招待し、トレーナーが認証を済ませます。
会員については、管理者から招待する方式ではありません。会員自身が名前とメールアドレスを入力して認証を済ませ、その後、会費ペイの登録情報と紐づけることで、契約コースやその他の会員情報が予約システムへ登録されます。
こうした登録・認証から、権限に応じた操作へ進む一連の導線を、実際の利用者になったつもりで確認しました。
会員の立場では、主に次の操作を確認しました。
- 予約とキャンセルが正しくできるか
- 満席時にキャンセル待ちへ登録できるか
- 空きが出た後の処理が想定どおり進むか
- 利用回数が適切なタイミングで付与・消費されるか
- トレーナーが公開したカルテを参照できるか
トレーナーの立場では、予約枠の設定、担当する会員情報の確認、トレーニングカルテの記載などを確認しました。
管理者の立場では、会員情報とコースの管理、外部の決済サービスから受け取る情報との整合、回数付与、定期処理などを確認しました。
重要だったのは、個々のボタンが動くかだけではありません。管理者がトレーナーを招待する流れや、会員が自ら認証して会費ペイの情報と紐づいた後に予約機能を利用する流れなど、役割をまたぐ一連の処理が成立するかを見ることでした。
UATをすると、仕様どおりでも使いにくい部分が見つかる
自分で会員やトレーナーとして操作すると、機能としては動いていても、使いにくい部分が見えてきます。
例えば、トレーナーが会員満足を考えながら予約枠を自由に設定できる仕組みを作りました。しかし、開業後に実際の枠を登録すると、一枠ずつ設定する作業に時間がかかることが分かりました。
これは、予約枠を作れるかどうかだけを確認しても見つけにくい問題です。翌月分の枠をまとめて準備する実際の業務を行って、初めて負担の大きさが分かりました。
また、操作履歴を細かく残す設計にしたため、後から見ると、データベース容量をもう少し意識してもよかったと感じています。
一部の古いスマートフォンでは正常に利用できない事象もありました。当初はパソコンで予約してもらう、公式LINEでやり取りするなど、運用で補ったケースもあります。現在は大きな問題なく運用できていますが、利用者の端末まで含めて確認する必要性を実感しました。
AIがテストを支援できる時代でも、利用者として操作するUATは省けません。むしろ、実装が速くなった分、現場に合っているかを人が確認する重要性は高まると感じました。
運用費は月額約20ドルに収まっている
現在、予約システムの運用費は、ほぼ無料枠の範囲に収まっています。商用利用のため、ホスティングサービスの有料プランに月額約20ドルを支払っています。
既存の業務システムへ毎月まとまった利用料を支払う場合と比べると、私の店舗にとっては固定費を抑えられています。
ただし、月額料金だけを見て「自作の方が安い」と結論づけるのは危険です。
自作では、仕様変更、テスト、セキュリティ更新、障害対応、データ管理などを自分で担います。自分の作業時間を費用として考えれば、月額約20ドルだけで運用できているとは言い切れません。
既製サービスの料金には、開発を続ける人、問い合わせ対応、障害対応、法令や環境変化への対応などの価値も含まれています。
私の場合は、自分で改善できることに価値を感じ、その負担も引き受ける選択をしました。
最大の利点は、開業後の改善をすぐ反映できること
自作して最も大きかった利点は、初期費用よりも、現場で見つけた不便を自分ですぐ直せることでした。
予約枠の登録方法を変えたいときも、外部の開発者へ改めて要件を説明し、見積もりと納期を確認する必要がありません。内容によっては、1日で修正し、テストを行い、本番へ反映できます。
一方で、急いで直せるからこそ、変更によって別の機能を壊さないよう、リグレッションテストが必要になります。自由に変更できることは、自由に事故を起こせることでもあります。
AIは実装やテストを手伝ってくれますが、変更するかどうかを決め、本番へ出す責任まで引き受けてくれるわけではありません。
すべての小規模店舗に自作を勧めるわけではない
今回の経験から、Claude Codeを使えば、個人でも短期間で業務システムを形にできる可能性は大きくなったと感じています。
ただし、予約が取れない、回数が誤って消費される、顧客情報が見えてしまうといった不具合は、店舗への信頼に直結します。作れることと、責任を持って運用できることは別です。
自作が向いているのは、少なくとも次の条件を満たせる場合だと思います。
- 業務ルールを自分で具体化できる
- 生成された結果が要件どおりか確認できる
- 利用者ごとの操作を本番前に検証できる
- 公開後も継続して保守する時間を確保できる
- 問題が起きたときの代替運用を用意できる
これらが難しければ、既製サービスや専門家への依頼に費用を払う方が、結果的に安全で安いこともあります。
まとめ
私はClaude Codeを使い、予約システムの主要機能を4日程度で実装しました。
短期間で形にできたことは大きな成果でしたが、本番利用で重要だったのは、コードを書く速さだけではありません。
- 店舗の業務ルールを具体化すること
- 管理者、トレーナー、会員の導線を確認すること
- 自動テストとUATを組み合わせること
- 実際の運用で見つかった不便を改善すること
- 公開後の保守責任を引き受けること
AIによって、開発の入口は以前より低くなりました。しかし、要件を決める責任、使いやすさを判断する責任、事故を防ぐ責任までなくなったわけではありません。
小規模店舗にとって重要なのは、「自分でも作れるか」だけではなく、「安全に使い続けられるか」まで考えて選ぶことだと思います。
