FOR USERS
アプリ不要。友だち追加からお店探し・予約・来店QRの受け取りまで、すべてLINE上で完結します。
スワイプで他の画面も →





FOR SHOPS
加盟店は店舗用LINEで予約リクエストを受け取り、その場で承認。来店はワンタイムQRのスキャンで計測します。
スワイプで他の画面も →


STORE PORTAL
加盟店がログインして使うWeb管理画面。今月のサマリー確認、予約の承認・来店確認、店舗用POSまでを1つのポータルに集約しています。



ADMIN CONSOLE
運営側が全加盟店を横断で管理するWebコンソール。店舗審査・承認、来店/売上の分析、ジャンルなどのマスタ管理を一元化しています。



ユーザーはLINEでエリア・人数・予算・ジャンルから検索し、コースを選んで予約リクエスト。店舗はLINEで承認して確定通知が届きます。
来店時に発行済みのワンタイムQRをスキャンして計測。成果ベースの送客実績として正確に記録されます。
来店実績を集計して加盟店へ月次で自動請求。ポータルで請求額を可視化し、運営の手作業を排除します。
SCOPE
「お店を探す人」「加盟店」「運営」——立場の違う3者が使う仕組みを、共同創業者として一人で設計・実装しました。要件定義・データベース設計・2つのLINE Bot・管理画面・店舗ポータル・3枚のLP・決済/請求の自動化・インフラ・運用監視・設計ドキュメントまで、サービスに必要なものを丸ごと担当しています。
ARCHITECTURE
「LINEでの操作」をきっかけに各パーツが連携して動く構成です。常時起動のサーバーを持たず、必要なときだけ動くサーバーレスにすることで、低コストかつ落ちにくい設計にしています。
ユーザー用・店舗用の2チャネル。会話UIと通知の入口。Messaging API + LIFF。
2つのBotのWebhookと定期ジョブを処理。会話状態はKV(TTL30分)。外部依存なしのTypeScript。
店舗・予約・来店・課金・ユーザーのデータ基盤。マイグレーションでスキーマを管理。
運営コンソールと3枚のLP。ホスト別ルーティングでドメインを出し分け(Vercel)。
加盟店向けのPCログイン管理画面。予約承認からQR発行・通知まで内部APIで連携。
請求書の発行・決済と、確定/請求の通知メール。AIの自由会話にはClaudeも利用。
ENGINEERING
「使う人にとっての分かりやすさ」と「技術的な堅牢さ」の両立を意識しています。
お店の質と、直近の露出回数の少なさを掛け合わせてスコアリング(品質×0.5 + 露出の逆数×0.5)。人気店に偏らせず、埋もれた名店にも来店機会が回る送客ロジックにしています。
課金のトリガーは予約ではなく、来店時のQRスキャン。24時間・1回限りのワンタイムトークンで来店を確実に計測し、成果が出たぶんだけ課金される、加盟店がリスクを負わない従量課金にしました。
毎月初のバッチが来店実績を自動集計し、Stripeで請求書を発行(消費税10%内税)。カード登録店は即時決済、未登録店は請求書送付、入金はWebhookで自動消込、通知はResendで自動送信します。
Cloudflare WorkersはUTCで動くため、ユーザーが指定する日本時間(JST)との変換を設計ルールとして徹底。「19時の予約が翌日4時にズレる」ような事故を、コード規約と共通関数で構造的に防いでいます。
定期ジョブの最終実行を /health で監視し、15分途絶で異常を検知(外部監視へ定期ping)。鍵が未設定ならログインを止める“fail-closed”など、安全側に倒す運用設計にしています。
将来まるごと削除しうるPOS機能は、本体から常に切り離せる状態を維持(依存は一方向・結合点を「キルスイッチ台帳」で管理)。機能を足してもサービス本体が壊れない構造にしています。
来店10回ごとに¥500を即時割引、1軒目の120分後に別ジャンルの2軒目を自動レコメンド、来店履歴からタグを蓄積して再来店を促す——送客後のリテンションまで設計に組み込んでいます。
ユーザー向け/加盟店向けの2種のLINE公式アカウントを軸に、Webhook・定期ジョブを Cloudflare Workers(会話状態は KV)、データ基盤を Supabase(PostgreSQL)、管理画面・LPと店舗ポータルを Next.js、決済/請求を Stripe、メール通知を Resend、AIの自由会話を Claude で構成。GitHub Actions での自動デプロイと /health 死活監視まで含め、予約・承認・来店確認・月次請求をつなぐ送客SaaSとして一貫して設計・運用しています。