このシリーズについて
レンタルスペースALBEは、2026年9月に予約システムを全面的に入れ替えました。既存のサービスを導入したのではありません。自分たちで開発したシステムです。
作ったのは、私（鬼頭）です。
私はプログラマーではありません。WEB制作会社の代表ではありますが、自分自身はどちらかといえばクリエイティブと営業寄りで、システム構築の世界に関してはほとんど素人と言っていい人間です。
そんな人間が、AI（Claude）と一緒に、思い立ってから2週間でローンチまで漕ぎ着けました。
現在このシステムは本番稼働中です。5種類の決済が走り、キャンセル料が自動計算され、お客様の予約を毎日お預かりしています。
このシリーズでは、その全工程を包み隠さず書いていきます。どこでつまずいたか、何を間違えたか、ローンチ後にどんな不具合が出たか。うまくいった話だけでなく、恥ずかしい失敗も含めて記録として残します。
第1話は、そもそもなぜ自分で作ることになったのか、というところから始めます。
500万円と半年。そこで一度、諦めました
予約システムを自社で持ちたい、という思いは以前からありました。
そこで、システム開発会社に相談したことがあります。レンタルスペース向けのオリジナルの予約システムを作ってもらいたい、と。
返ってきた答えはこうでした。
期間は半年。費用は最低でも500万円。
この金額と期間を聞いて、私は諦めました。
決して法外な見積もりだとは思いません。むしろ妥当だと思います。これから書いていく内容を読んでいただければわかりますが、レンタルスペースの予約システムは想像以上に複雑です。時間軸での計算、曜日別の料金、オプションの在庫、複数の決済手段、キャンセル料の自動計算。真面目に作れば、それくらいはかかるでしょう。
ただ、私たちの規模で500万円を投じる判断はできませんでした。半年という期間も長い。その間、運営は止まりません。
こうして「自社の予約システム」という選択肢は、一度テーブルから消えました。
Booklyは悪くない。でも、入り口が違った
その後、私たちは3年ほど前から、WordPressのプラグイン「Bookly」を使って運用していました。
念のため書いておきますが、Booklyは良いプラグインです。海外製ですが非常に柔軟で、機能面では私たちの要件をほぼ満たしてくれていました。
ただ、ひとつだけ、どうしても解決できない問題がありました。
予約の入り口が「プランを選ぶ」から始まることです。
Booklyの設計では、お客様はまずプラン（サービス）を選び、それから日時を選びます。海外ではそれが自然な流れなのだと思います。
しかし日本のお客様は違います。まずカレンダーを見ます。 空いている日を探して、そこから予約に進もうとされる。
この順番の違いだけで、初めてのお客様にはハードルになりました。
WEB制作を生業にしている人間として、ここは見過ごせませんでした。お客様の使いやすさを追求するのは、事業者として必須だと思っています。ましてやWEB屋を名乗っているなら、なおさらです。
とはいえ、プラグインの設計思想そのものは変えられません。できることの範囲で工夫するしかない。そういう状態が続いていました。
「レンタルスペースの予約システムってオリジナルで作れる？」
2026年の、お盆休みの間のことです。
特に決意を固めたわけでも、計画を立てたわけでもありません。ほとんど雑談のような気持ちで、私はClaudeにこう聞きました。
「レンタルスペースの予約システムってオリジナルで作れる？」
返ってきた答えは、一言でした。
「作れます」
正直、拍子抜けしました。500万円と半年と言われて諦めていたものについて、こんなにあっさりと。
そして、その直後に起きたことのほうが印象的でした。
Claudeから、私の知識レベルを測る質問が返ってきたのです。
いきなりコードを書き始めるのではなく、まず相手がどこまで分かっているのかを確認しにきた。どこから説明すべきかを見極めようとしていたのだと思います。
これは今振り返ると、非常に重要なやり取りでした。人に仕事を頼むときと同じです。相手のレベルが分からないまま進めると、話が噛み合わなくなる。
私は正直に答えました。WEB制作の基礎知識はある。でもプログラマーではない。WEB屋ではあるけれど、どちらかといえばクリエイティブと営業寄りだ、と。
こうして、ほとんど素人のままシステム構築の世界に飛び込むことになりました。
実は、準備していたものがありました
ここで、思いがけず役に立ったものがあります。
以前システム会社に相談したときに作った、「どんなシステムにしたいか」のリストです。
500万円と言われて諦めた、あの相談のときの資料です。捨てずに残っていました。
内容は、拍子抜けするほど簡単なものです。箇条書きで、こんなことが並んでいるだけでした。
- カレンダーで予約できるようにしたい
- 領収書を発行できるようにしたい
- Googleカレンダーと双方向連携ができるようにしたい
技術的なことは何ひとつ書いてありません。専門用語も使っていません。ただ、運営者としてやりたいことを日本語で並べただけのメモです。
これをClaudeに渡しました。
すると、やりたいことの全体像が見えて助かるという趣旨の返答がありました。
正直、意外でした。こんな簡単なメモが役に立つのか、と。
でも今ならわかります。作る側にとって一番困るのは、依頼者が何を求めているか分からないことです。 技術的に正しく書かれているかどうかより、ゴールが見えていることのほうが大事なのだと思います。
諦めた相談の副産物が、数年越しに効きました。
手応えを感じたのは、その日のうちでした
ここからが、この話の一番面白いところです。
「いける」と確信したのは、2週間後ではありません。相談したその日です。
最初に取りかかったのは、モックアップでした。実際に動く画面を作ってみる。
そして私が最初に作ってもらったのが、予約カレンダーです。
理由はもうお分かりだと思います。Booklyでずっと引っかかっていた、あの「カレンダーから入る」という一点。日本人特有の、まずカレンダーを見たいという行動。そこを最初に作りました。
さらにそこから、申し込みまでの顧客導線の基礎を組み立ててくれました。私が指示したのは「カレンダーから入りたい」ということだけで、その先の画面の流れはClaudeが形にしてくれたものです。
初日のうちに、カレンダーを見て、日時を選んで、申し込みに進む——という流れが、実際に動く画面として目の前に現れました。
この瞬間に、「いける」と思いました。
動く画面が、判断を変えた
なぜ初日で判断できたのか。あとから考えると、理由ははっきりしています。
目の前に、動くものがあったからです。
システム開発会社に相談していたとき、私が見ていたのは見積書と提案書でした。金額と期間と、機能の一覧。画面を見ないまま、500万円という数字だけで判断を迫られていた。
一方、Claudeとのやり取りでは、その日のうちに画面が出てきました。クリックできる。日付が選べる。自分の頭の中にあったものが、形になって目の前にある。
これを見てしまうと、判断は速いです。「できるかどうか」を想像で考える必要がなくなるからです。
それに、最初に作ったのが「カレンダーから入る」という部分だったことも大きかった。ずっとどうにもならなかった課題が、初日の数時間で解決してしまった。
技術的に難しいことをやったわけではありません。ただ、入り口の順番を変えただけです。
それができなかったのは、既存サービスの設計思想が固定されていたからでした。自分で作るというのは、機能を増やすことではなく、こういう順番を自分で決められるようになることなのだと、この日に理解しました。
ただし、ここには前提があります
こう書くと、「AIがあれば誰でも予約システムが作れる」と読まれてしまうかもしれません。
それは違います。このシリーズを通して、繰り返しお伝えすることになると思います。
私が初日から迷わず「まずカレンダーを作ろう」と言えたのは、10年以上レンタルスペースを運営してきたからです。
お客様がどこで迷うか。どの順番なら申し込めるか。どんな料金設定が必要か。キャンセルの連絡はどう来るか。振込はいつ遅れるか。
これらは全部、運営の中で身体に入っていたものです。言い換えれば、私の頭の中にはすでに仕様書がありました。 あの箇条書きのメモは、その一部を紙に落としたものにすぎません。
AIは、実装を劇的に速くします。しかし何を作るべきかは教えてくれません。 要件を持っていない人が同じことをやれば、動くけれど使えないものが出来上がります。
2週間でローンチできたのは、AIが速かったからだけではなく、10年分の要件がすでに揃っていたからです。
この点は、次回の「準備編」でもう少し詳しく書きます。
次回：#2 準備編
第2話では、実際に着手する前に何を決めたのかを書きます。
技術の選定、データをどこに置くか、そして「10年分の要件」をどうやってAIに伝えたのか。ここが2週間という期間を決めた、最も重要な工程でした。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった（この記事）
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事