合同会社 CitrusApp(シトラス・アップ)は、カフェ「となりのと commons kitchen」様向けに、期間限定のコラボイベントで使う事前予約・店頭受取システムを開発しました。

お客様はスマートフォンから受取日・商品・受取時間を選び、その場でクレジットカード決済まで完了。お店側は、入った予約がそのままその日の製造数として一覧に積み上がっていく——「予約を受ける」と「何をいくつ作るか決める」を1つの画面でつないだ事例です。

「となりのと commons kitchen」様では、一昨年・昨年もこのイベントを開催されていましたが、その際は Shopify などの既存のサービスで予約をさばこうとされていました。ところが予約が殺到し、「誰が・いつ・何を受け取りに来るのか」を整理しきれない状態に。汎用的なサービスは便利な反面、このお店の「店頭受取」というビジネスモデル・業務フローにはどうしても噛み合わなかった——ここが一番のペインポイントでした。

そこで「自分たちの受取の流れに最適な予約システムを一から作れないか」とご相談いただいたのが、今回の開発のきっかけです。「食べ物を作りすぎて捨てたくない。でも足りなくてお客様に謝るのも嫌だ」——受注生産のお店が抱えるこのジレンマを、予約を先に確定させることで解消する。それが、このシステムの出発点でした。

なお今回のイベントは、漫画家・水木しげる先生ゆかりの街・調布で開かれる記念イベント「ゲゲゲ忌2026」とのコラボ企画です。「となりのと commons kitchen」様が妖怪にちなんだ限定メニューを期間限定で提供されるにあたり、その事前予約・店頭受取を支える仕組みとして開発しました。

お客様トップ画面(スマホ)

▲ お客様が最初に見る画面。受取日をタップするところから予約が始まります

受取日の選択(スマホ)商品の選択(スマホ)注文の確認(スマホ)

▲ 実際の「ゲゲゲ忌2026」コラボ版の予約画面。左から、受取日を選ぶ → 商品を選ぶ → 注文を確認、の順に進みます

目次
  1. このシステムとは?
  2. 主な機能
  3. 抱えていた課題 / 依頼の背景
  4. 依頼から公開までの流れ
  5. 今回の開発のポイント
  6. 開発責任者からのコメント
  7. 使用技術
  8. イベント・店舗向けの予約システム、CitrusApp にご相談ください

1. このシステムとは?

「予約を受ける」と「いくつ作るか決める」を、1本の線でつなぐ

期間限定のコラボイベントでは、通常営業とは違う特別メニューを、限られた日数だけ提供します。しかもすべて受注生産。作り置きができない以上、前日までに「明日は何をいくつ作るか」が確定している必要があります。

今回のシステムは、お客様の予約をそのまま製造数として積み上げる仕組みです。予約が1件入れば、その日のその商品の受付枠が1つ減り、製造計画の数字が1つ増える。前日の締め切り時間に受付を締め切った時点で、翌日の仕込み数がそのまま確定します。

特徴

  • 受取日 → 商品 → 受取時間 の3ステップ予約 — スマートフォンで完結。会員登録は不要
  • その場でカード決済 — Square を利用し、クレジットカード決済に対応。3Dセキュア(本人認証)にも対応済み
  • 商品ごと・日ごとの受付上限 — 「カレーは1日20食、ケーキは12個」のように、商品単位で上限を設定
  • 製造計画の自動集計 — 全日程 × 全商品の予約数を1枚の表に。前日までの数字を見ながら仕込みができます
  • 店頭販売の記録 — 予約なしで来店されたお客様への販売も管理画面から登録でき、同じ在庫から自動的に差し引かれます
  • 受取管理 — 当日分だけを一覧表示。お渡しごとにタップでチェックし、進捗をその場で把握
  • 店休日・締切の自動反映 — 店休日は予約一覧に出さず、締切を過ぎた日は自動的に受付終了に切り替わります
  • スマホ最適化 — お客様側だけでなく、管理画面もスマートフォンで使える設計
  • お店のブランドに寄せたデザイン — ロゴと店舗の世界観から配色を起こし、既存のブランドと違和感のない見た目に

2. 主な機能

お客様側:3ステップで予約完了

  1. 受取日を選ぶ — 開催期間の日付が一覧で並び、「受付中」「残りわずか」「受付終了」がひと目で分かります
  2. 商品と数量を選ぶ — 残数を超える数量は選べないようになっており、売り切れの商品は最初から選べません
  3. 受取時間・お客様情報を入力して決済 — 1時間刻みの受取時間帯を選び、お名前・連絡先を入力してカード決済

予約が完了すると注文番号が発行され、確認メールが自動送信されます。

商品選択画面(スマホ)受取時間の選択(スマホ)予約完了画面(スマホ)

▲ お客様側の予約フロー(スマホ)。左:商品選択(残数を超えて選べず、売り切れは最初から選べません)/中央:1時間刻みの受取時間の選択/右:予約完了。受取時にお伝えいただく注文番号を大きく表示しています

お店側:予約が「その日の製造数」になる

  • ダッシュボード — 本日の受取進捗・明日の予約数・総売上・在庫アラートを1画面で
  • 製造計画 — 全日程 × 全商品の予約数を1枚の表に集約。「11/21(土)はカレー3、ナン0、ケーキ1、合計12個」といった読み方がそのままできます
  • 在庫管理 — 商品ごと・日ごとの受付上限を設定。すでに入っている予約数を下回る数には下げられないよう保護されています
  • 注文一覧 — 全予約の検索・絞り込み、CSV一括ダウンロード、キャンセル処理
  • 受取管理 — 当日分だけを表示し、お渡しごとにチェック
  • 商品マスタ — 商品名・価格・説明・写真の登録。写真は管理画面から直接アップロードできます

管理画面:製造計画

▲ 製造計画:全日程 × 全商品の予約数を1枚の表に。太字が予約数(=製造数)、下の数字が受付上限です

管理画面:ダッシュボード

▲ ダッシュボード:本日の受取進捗・売上・在庫アラートを1画面で確認できます

管理画面:注文一覧

▲ 注文一覧:名前や注文番号での検索、受取日・ステータスでの絞り込み、CSV一括ダウンロードに対応

管理画面:受取管理

▲ 受取管理:当日分だけを表示。お渡しごとにチェックすると、進捗バーがその場で更新されます

3. 抱えていた課題 / 依頼の背景

期間限定イベントで受注生産のメニューを出す場合、現場は次のような課題を抱えます。

  • 作る数が読めない — 当日にならないと何がどれだけ出るか分からず、作りすぎれば廃棄、足りなければ機会損失
  • 電話・SNSでの予約受付が回らない — 営業中に電話が鳴り、手が止まる。メモの取り違えや二重受付も起きる
  • 当日の会計に時間がかかる — 受取のたびに会計が発生し、ピーク時にレジが詰まる
  • 誰がいつ何を取りに来るか分からない — 紙のリストから該当のお客様を探すのに時間がかかる
  • イベント期間だけのために、高い月額の予約システムは契約したくない

「予約の時点でお代をいただいて、作る数を確定させたい。当日は商品をお渡しするだけにしたい」——この形をイベント期間中だけ、シンプルに実現できる仕組みが求められていました。

4. 依頼から公開までの流れ

  1. 運用フローのヒアリング — 「いつ締め切るか」「受取時間を分けるか」「当日の会計はどうするか」を整理。受注生産である以上、前日には数字が確定している必要があることから、締切は受取日の前日の締め切り時間、支払いは予約時のカード前払いと決めました。

  2. メニュー・数量の確定 — お店側に受取日・商品・1日あたりの提供数をスプレッドシートで記入いただき、そのまま本番データとして投入。「この商品は土日だけ多めに作る」といった日ごとの差も、そのまま設定に落とし込みました。

  3. 生成AIを活用したスピード開発 — 生成AI(AIコーディング)を開発プロセスに組み込み、設計・実装・テストを高速に反復。短期間で本番環境を用意しました。

  4. 決済の組み込みと実機確認 — Square の決済を組み込み、クレジットカード決済(3Dセキュアによる本人認証を含む)に対応。実際のカードで決済が通ること、お店の Square アカウントに売上が立つことを本番環境で確認しました。

  5. 本番想定のテストと負荷検証 — 各段階で自動テストを整備(後述)。あわせて、告知直後に注文が殺到しても耐えられるかを負荷テストで確認しました。

  6. イベント本番へ — 現在は本番環境を公開し、11月のイベント開始に向けて最終調整を進めています。

5. 今回の開発のポイント

ポイント1:予約がそのまま製造計画になる

このシステムで最も大事にしたのは、「予約を見る画面」と「何を作るか決める画面」を分けないことでした。

受注生産では、予約数がそのまま製造数です。ところが多くの予約システムは「予約の一覧」までしか見せてくれず、そこから「じゃあ明日は何をいくつ作るのか」を人が数え直すことになります。この数え直しこそが、ミスと手間の発生源です。

今回は、全日程 × 全商品の予約数を1枚の表にまとめた「製造計画」画面を中心に据えました。縦に商品、横に日付。太字が予約数(=作るべき数)、その下が受付上限。合計行を見れば、その日の総製造数が分かります。仕込みの前にこの画面を開けば、それ以上考えることはありません。

ポイント2:「告知直後の殺到」にも耐えられる

イベントの予約サイトで怖いのは、SNSで告知した直後にアクセスが集中し、サイトが固まって誰も予約できなくなることです。

そこで本番と同じ構成を再現し、本番のサーバーとデータベース間の通信遅延まで含めた状態で、「大勢が同時に注文し、さらに大勢が同時にサイトを見ている」ような高負荷の状況を想定した負荷テストを実施しました。注文が殺到している最中でも、閲覧も予約もストレスなく応答し、決済の取りこぼし(失敗した注文)が起きないことを確認したうえで本番に臨んでいます。

「たぶん大丈夫だと思います」ではなく、実際に負荷をかけて確かめてからお渡しする。決済を扱うシステムでは、ここを省略しないことが信頼につながると考えています。

ポイント3:店頭販売も、同じ在庫から引く

予約サイトを作ると、どうしても「予約」だけを見る仕組みになりがちです。しかし実際の店舗では、予約なしで立ち寄られたお客様に、残っている分をその場で販売します。

この分を記録しないと、システム上の残数と棚の上の実物がずれていきます。そこで管理画面から店頭販売をその場で登録でき、登録すると同じ日の在庫が自動的に減り、製造計画にも反映されるようにしました。予約か店頭かは一覧上でタグで区別できるので、あとから「予約が何割だったか」を振り返ることもできます。

管理画面:店頭販売の登録

▲ 店頭販売の登録:残数を見ながら数量を選ぶだけ。登録すると在庫と製造計画に自動反映されます

ポイント4:管理画面こそスマホで使えること

飲食店の現場に、開いたままのノートPCはありません。エプロンのポケットに入っているのはスマートフォンです。

そこで管理画面も、お客様側と同じようにスマートフォンで完結する設計にしました。特に、当日いちばん使う「受取管理」と、仕込み前に見る「製造計画」は、スマホの画面幅でも読める形に作り込んでいます。製造計画の表は横スクロールしつつ、左端の商品名だけは固定して常に見えるようにしました。

製造計画(スマホ)受取管理(スマホ)

▲ 左:製造計画(スマホ)。表は横にスクロールし、左端の商品名は固定されて常に見えます/右:受取管理(スマホ)。当日分だけを表示し、お渡しごとにタップでチェックできます

ポイント5:お店のブランドに合わせた見た目

予約サイトは、多くのお客様にとってそのお店に触れる最初の画面になります。テンプレートそのままの見た目では、せっかくのイベントの世界観が伝わりません。

今回は、お店のロゴと店舗の雰囲気から配色を起こしました。ロゴの扉に使われている深いティールグリーンを基調色として抽出し、余白には店舗の壁のような淡い青白を敷いています。「よくある予約フォーム」ではなく、そのお店のサイトとして自然に見えることを目指しました。

お客様トップ画面(スマホ)

▲ お客様側トップ(スマホ):ロゴから起こした配色で、お店の世界観に合わせています

ポイント6:AIで速く作り、人の目で品質を担保する

開発は生成AI(AIコーディング)を全面的に活用して進めましたが、速さと引き換えに品質を落とさないことを徹底しました。

判断のロジック(締切・売り切れ・受取時間の判定など)から、サーバー・データベースと連携する処理、実際のブラウザでの予約導線まで、各段階で自動テストを整備し、繰り返し検証しています。特に在庫まわりは、注文が同時に集中しても受付上限を超えないかといった同時実行の挙動まで確認し、データベース側にも制約を設けて二重の安全網をかけています。

AIで実装を速く終えられるぶん、このテストと検証にしっかり時間をかけられたことが、今回の品質につながっています。

管理画面:在庫管理

▲ 在庫管理:日ごと・商品ごとの受付上限を設定。予約済みの数を下回る値には下げられません

6. 開発責任者からのコメント

「イベント期間だけの予約サイト」と聞くと小さな案件に思えますが、実際に作ってみると、お金と在庫という、間違えたら取り返しのつかないものを両方扱うシステムでした。

お金も在庫も、ひとつ間違えればお客様の信頼に直結します。在庫の数がずれれば、当日「予約したのに商品がない」という事態にもなりかねません。だからこそ、注文が殺到したときに何が起きるかを、想像ではなく実際に負荷をかけて確かめることにこだわりました。

生成AIを活用することで、こうした検証にかける時間を確保できたのが大きかったと感じています。実装そのものを速く終わらせられるぶん、「どこが壊れうるか」を考え、テストを書き、負荷をかけて測る時間に回せる。AI駆動開発の価値は、単に速く作れることよりも、品質に使える時間が増えることにあるのではないかと思っています。

イベント本番は11月。当日、お店の方が慌てずに商品をお渡しできて、お客様が「予約しておいてよかった」と思ってくださる——そこまでが今回のゴールだと考えて、引き続き伴走していきます。

7. 使用技術

  • フロントエンド/バックエンド:Next.js 16(App Router)+ React 19 + TypeScript
  • スタイリング:Tailwind CSS v4
  • ORM:Drizzle ORM
  • データベース:Neon(サーバーレス PostgreSQL)
  • インフラ:Vercel(東京リージョン)
  • 決済:Square(Web Payments SDK/Node SDK)— クレジットカード決済・3Dセキュア対応
  • メール配信:Resend
  • テスト:Node.js 標準テストランナー + Playwright(ブラウザ操作テスト)
  • 開発手法:生成AI(AIコーディング)を活用した高速・反復開発

8. イベント・店舗向けの予約システム、CitrusApp にご相談ください

合同会社 CitrusApp(シトラス・アップ)は、AI駆動開発で、業務システム・SaaS・専用アプリのアイデアを最短でカタチにする開発会社です。

「期間限定のイベントだけ、予約と決済ができる仕組みが欲しい」「月額の高い予約サービスは契約したくない」「予約の管理と、仕込みの数の管理を一本化したい」——そんなお悩みがあれば、お気軽にご相談ください。

無料で相談する