地域店舗のO2Oは、アプリを作る前に「来店をどう記録するか」を決める。

この事例の根拠と読み方

根拠は、AMELAの移行元ケース資料、CMS登録内容、AMELAが公開するMachiLinkケースページと、2026年8月30日に確認した操作可能なデモです。公開ケースにはAMELAのロゴと事例表記があり、利用者アプリ、店舗コンソール、運営コンソール、APIをAMELAの支援範囲として記録しています。

• 確認できること：地図・カテゴリからの店舗検索、店舗詳細、来店QR操作、ポイント付与、クーポン利用、店舗とのチャット、来店履歴、店舗登録申請の審査、サブスクプラン管理の画面と操作。
• 確認できないこと：本番の店舗数・利用者数・来店数、クーポン利用率、再来店率、売上効果、開発期間・工数、処理性能、セキュリティ水準、個人情報保護の適合性、SLA、可用性の実績。
• 公開上の扱い：企業名、プロジェクト名、画面、店舗名、利用者名、日付、件数、金額、ポイントは、機密保持のため承認済みの仮名またはモックです。デモ値を顧客の本番実績として扱いません。

AMELAがつないだのは、三つの画面と一つの来店記録です

AMELAのケース資料では、React Native、NestJS、Socket.IO、TypeScript、MySQL、MongoDBを用いた構成が示されています。公開デモでは、利用者が店舗を探して来店QRを操作し、その記録を店舗側が確認し、運営側が店舗申請とプランを管理する流れを確認できます。

読者が使える実践ツール

企画・RFP作成の前に、次の「役割・イベント・指標・同意・運用シート」を埋めると、既存サービスで足りる範囲と個別開発が必要な範囲を比較できます。記入例は公開デモの操作をもとにしたもので、本番の運用値ではありません。

• 役割：利用者は店舗検索・QR・特典・チャット、店舗は来店確認・特典・返信、運営者は店舗審査・公開停止・プラン管理を担当する、という初期案から権限表を作る。
• 来店イベント：例として「店舗固有QRを利用者が読み取る→時刻・店舗・利用者・付与ルールを記録→店舗側に表示」と定義する。重複判定、取消、端末紛失、オフライン時の扱いも決める。
• 特典：付与条件、利用条件、有効期限、併用可否、残高訂正、返金・取消時の戻し方、問い合わせ時に参照する記録を決める。
• 指標：表示回数、店舗詳細閲覧、QR読取、特典付与、クーポン利用、再来店を別イベントとして定義する。売上との因果を自動的に結び付けない。
• 同意と保存：位置情報、チャット、来店履歴について、取得目的、同意画面、保持期間、削除依頼、店舗への開示範囲を決める。
• 運用と受入確認：店舗申請、審査差戻し、公開停止、QR重複、特典取消、チャット通報、退会、障害時の手動処理を役割別に確認する。

評価用データには、複数カテゴリの店舗、同名店舗、期限切れクーポン、重複QR、取消済み来店、停止店舗、未読チャットを含めてください。正常系だけでなく、訂正と例外の記録が残るかを確認することが重要です。