reserve-optimizer 機能拡張ロードマップ — 競合リサーチ＆実装計画

策定: Claude Fable 5（2026-06-12） 実装担当: Sonnet / GLM（本計画書に従って実行） 目標: 「LINE予約システムとして日本一」— 競合の良い機能を取り込み、さらに改善して上回る

1. 競合リサーチ結果

調査対象（主要LINE予約システム）

サービス 強み（盗むべき機能） 弱み（こちらが勝てる点)
リザービア 予約完了まで最短20秒のUX、施術写真カルテ、顧客別クーポン、スタンプカード（★4.7）、集計分析 月額コスト高、汎用LLM対応なし
リピッテ スタッフ指名予約＋自動割り振り、5分単位予約枠、当日締切設定、キャンセル受付期限、質問フォーム AIチャットなし、多言語なし
ポチコ シンプルさ（設定3分）、地図付きリマインド、Googleカレンダー連携 事前決済なし、機能が少ない
STORES予約 月謝・回数券など複数決済、LINEミニアプリ連携、多店舗管理 整骨院特化でない
RESERVA キャンセル待ち、サブスク月額プラン、セルフチェックイン UI複雑
ONE MORE HAND 5分単位枠＋施術後インターバル設定（治療院特化） 規模が小さい
リザエン キャンセル待ち一斉案内→早い者勝ちで枠を埋める LINE特化でない
リピクル/スリーズプロ 電子カルテ・問診票・会計・回数券の一元化 高額、導入が重い
Liny タグ付け・セグメント配信・ステップ配信 予約特化でない

当システムの既存資産（競合に既に勝っている点）

  • ✅ ウェイティングリスト（キャンセル枠自動埋め）＝ コアバリュー
  • ✅ Stripeデポジット決済（ノーショー対策）
  • ✅ デジタル回数券（TicketService・Phase 5実装済み）
  • ✅ AIチャット（GLM-4.7・営業時間/料金Q&A自動応答）→ 競合のどこも持っていない
  • ✅ 多言語6言語対応 → 競合のどこも持っていない
  • ✅ CRMタグ自動付与・来院後フォローアップ
  • ✅ KPIダッシュボード
  • ✅ リマインダー（前日＋当日2-3時間前の2段階）

ギャップ分析（競合にあって当システムにない機能）

# 機能 持っている競合 価値
G1 スタッフ指名予約＋指名なし自動割り振り リピッテ 高（リピート率に直結）
G2 クーポン発行・利用管理 リザービア 高（再来店促進）
G3 デジタルスタンプカード リザービア 中（ロイヤルティ）
G4 事前Web問診票 リピクル 高（施術時間+9分/人の短縮実績）
G5 施術記録カルテ（簡易・メモ＋タグ） リザービア/リピクル 高（次回施術の質向上）
G6 口コミ依頼自動化（Googleレビュー誘導） — (手動が主流) 高（集客に直結）
G7 サブスク（月額通い放題）管理 RESERVA 中（安定収入化）
G8 施術後インターバル（バッファ時間）設定 ONE MORE HAND 中（連続予約の現実対応）
G9 当日予約締切時刻・キャンセル受付期限の設定化 リピッテ 中（運用柔軟性）
G10 地図付きリマインド ポチコ 小（実装容易）
G11 セグメント配信（タグ別一斉メッセージ） Liny 中（CRM資産の活用）
G12 セルフチェックイン RESERVA 低（Phase 2向き）
G13 Googleカレンダー双方向同期 ポチコ 低（CalendarService拡張）

2. 実装計画 — 3 Wave 構成

設計原則（全Waveに適用）

  1. 既存パターン厳守: GAS制約（ESModules不可・var/function・グローバルスコープ）、STATE_DISPATCH への状態追加、SheetConfig.js への定数集約、Result型 統一
  2. 機能はオプトイン: 全新機能は ScriptProperties のフラグ（例: FEATURE_COUPON=true）でON/OFF可能にする。「やりすぎて使いにくい」を防ぐ
  3. TDDファースト: 実装前にテストを書く（詳細は §3）
  4. 1機能=1コミット=1SSOT記録

🌊 Wave 1: リピート率向上3点セット（推定2〜3セッション）

狙い: 「予約が取れる」から「また来たくなる」への進化。リザービア/リピッテの中核価値を移植。

W1-1: スタッフ指名予約（G1）

  • 現状: StaffService.js は存在するが予約フローに指名ステップがない
  • 実装: 予約フロー（施術選択→スタッフ選択→日付→時間）に QuickReply でスタッフ選択を挿入。「指名なし」選択時は空きスタッフへ自動割り振り
  • 改善ポイント（競合超え）: 前回担当スタッフを CRM データから取得し「前回と同じ○○さん」をQuickReply先頭に表示
  • 新規状態: AWAITING_STAFF_SELECT を USER_STATES と STATE_DISPATCH に追加
  • データ: 予約シートに staffId 列追加、SheetConfig.js 更新
  • フラグ: FEATURE_STAFF_SELECT

W1-2: クーポン機能（G2）

  • 実装: services/CouponService.js 新規作成。クーポンシート（コード・割引額/率・有効期限・利用上限・対象タグ）
  • 予約確認画面で「クーポンコード入力」を任意ステップとして追加
  • 改善ポイント: CRMタグ連動 — 「30日来院なし」タグの顧客に自動でカムバッククーポンをプッシュ配信（FollowUpService 拡張）
  • フラグ: FEATURE_COUPON

W1-3: 口コミ依頼自動化（G6）

  • 実装: 来院後フォローアップ（既存 FollowUpService）に「満足度ヒアリング」を追加
  • ★4-5 と答えた顧客のみ Google レビューURLを送付（低評価は内部フィードバックフォームへ）
  • 改善ポイント: 評価分岐型は競合に存在しない。低評価を院長LINEに即時通知
  • フラグ: FEATURE_REVIEW_REQUEST

🌊 Wave 2: 施術品質・運用柔軟性（推定2〜3セッション）

W2-1: 事前Web問診票（G4）

  • 実装: Worker の reserve-page.html パターンを流用し intake-form.html を新設（/intake/:reservationId）
  • 予約確定メッセージに問診票URLを添付。回答は問診シートに保存し、当日朝のスタッフ通知に含める
  • 改善ポイント: AIチャット（GLM）で問診回答を3行サマリー化してスタッフに送る
  • フラグ: FEATURE_INTAKE_FORM

W2-2: 簡易施術カルテ（G5）

  • 実装: services/KarteService.js 新規作成。管理者LINEコマンド /karte <予約ID> <メモ> で記録
  • 次回予約時に前回カルテをスタッフ通知に自動添付
  • スコープ制限: 写真添付・本格的な電子カルテは Phase 2（Supabase移行後）。今回はテキスト＋タグのみ
  • フラグ: FEATURE_KARTE

W2-3: 運用柔軟性設定（G8 + G9 + G10）

  • 施術後インターバル分数（BUFFER_MINUTES）— 予約枠計算に組み込み
  • 当日予約締切時刻（SAME_DAY_CUTOFF）・キャンセル受付期限（既存の拡張）
  • リマインドに Google マップURL添付（CLINIC_MAP_URL）
  • すべて ScriptProperties で設定化（コード変更不要で調整可能に）

🌊 Wave 3: 収益・マーケ基盤（推定2セッション）

W3-1: デジタルスタンプカード（G3）

  • 実装: services/StampService.js。来院ごとに自動スタンプ（CRM来院記録と連動）、満了で特典クーポン自動発行（W1-2と連携）
  • リッチメニューから残数確認可能
  • フラグ: FEATURE_STAMP_CARD

W3-2: サブスク管理（G7）

  • 実装: Stripe Subscriptions 連携。TicketService のパターンを流用し SubscriptionService.js 作成
  • 月額プラン（通い放題/月N回）・予約時に有効性チェック・期限切れ通知
  • ⚠️ Tier 1（決済）: 実装前にユーザー確認必須
  • フラグ: FEATURE_SUBSCRIPTION

W3-3: セグメント配信（G11）

  • 実装: 管理者コマンド /broadcast <タグ> <メッセージ> で CRM タグ別プッシュ配信
  • 改善ポイント: 配信前に対象人数を表示して確認ステップを挟む（誤爆防止）
  • フラグ: FEATURE_SEGMENT_BROADCAST

見送り（やらない理由を明記）

機能 理由
G12 セルフチェックイン 店舗ハードウェア前提。Phase 2で再検討
G13 Googleカレンダー双方向同期 片方向は実装済み。双方向は競合状態のリスクが高く、GASのトリガー制約下では不安定
LINEミニアプリ（LIFF）化 UX向上は大きいがLIFF審査・保守コスト大。Phase 2（Next.js移行）と同時にやる方が二度手間にならない

3. TDD・テスト計画

基本サイクル（全機能共通） 

1. RED:    tests/unit-<service>.test.js にテストを先に書く（gas-mock.js 使用）→ 失敗確認
2. GREEN:  最小実装でテストを通す
3. REFACTOR: 既存パターン（Result型・SheetConfig定数化）に揃える
4. REGRESSION: node tests/run-all.js で全テスト PASS を確認してからコミット

機能別テストマトリクス（実装前に必ず作成するテスト）

機能 ユニットテスト（必須） E2Eテスト
W1-1 スタッフ指名 指名あり/なし割り振り・スタッフ満枠時・前回スタッフ取得 予約フロー全体（指名あり）
W1-2 クーポン 有効/期限切れ/利用上限超過/対象外タグ/割引計算（率・額） クーポン適用予約→決済額検証
W1-3 口コミ依頼 評価分岐（★1-3→内部 / ★4-5→レビューURL）・重複送信防止 フォローアップ→評価→分岐
W2-1 問診票 バリデーション・保存・サマリー生成（GLMモック） URL発行→回答→通知
W2-2 カルテ コマンドパース・保存・次回予約時の添付 —
W2-3 運用設定 インターバル込み枠計算・締切判定（境界値: 締切ちょうど） —
W3-1 スタンプ 自動付与・満了判定・特典発行・二重付与防止 来院→スタンプ→満了→クーポン
W3-2 サブスク 有効性チェック・期限切れ・月N回カウント Stripe Webhookモック→状態遷移
W3-3 配信 タグ抽出・対象人数計算・確認ステップ —

テスト規律

  • 境界値必須: 期限切れ「ちょうど」、上限「ちょうど」、0件、満枠
  • 冪等性必須: スタンプ二重付与・クーポン二重利用・口コミ依頼重複送信は必ずテストする（このシステムはWebhook再送がありうる）
  • 既存テスト保護: 全Waveで既存970+テストを壊さない。run-all.js PASS がコミット条件
  • ステートマシン検証: 新状態追加時は STATE_DISPATCH 網羅テスト（全 USER_STATES にハンドラが存在するか）を unit-message-router.test.js に追加

4. モデル分担（LLMルーティング）

工程 担当モデル 理由
本計画策定・Wave設計レビュー 🟣 Fable アーキテクチャ判断（完了）
各機能の実装・テスト作成 🔵 Sonnet / 🟡 GLM 計画書に従う定型作業
各Wave完了時のコードレビュー 🟣 Fable（推奨）or 🔵 Sonnet 設計逸脱の検出
ドキュメント更新・SSOT記録 🟡 GLM 定型作業
W3-2 サブスク（決済設計） 🟣 Fable で設計確認 → 🔵 Sonnet 実装 Tier 1（決済）のため

5. 実行手順（次セッション以降の指示テンプレート）

各Waveの開始時に以下を実行:

/goal W1-1: スタッフ指名予約を実装。docs/FEATURE_ROADMAP_2026-06-12.md の W1-1 仕様と §3 TDD計画に従うこと。
テストファースト（RED→GREEN→REFACTOR）、FEATURE_STAFF_SELECT フラグでオプトイン、既存テスト全PASS がコミット条件。

6. 成功指標（README Impact セクションに随時反映）

指標 現状 Wave 3 完了後の目標
機能数（競合比較表ベース) 競合並み 競合最多 + AIチャット/多言語/評価分岐口コミは独自
テスト数 970+ 1,100+
設定可能項目（ScriptProperties） 約20 約35（全新機能フラグ式）
差別化機能数（競合ゼロのもの） 2（AI・多言語） 5（+前回スタッフ提案・評価分岐口コミ・AI問診サマリー）
This site uses Just the Docs, a documentation theme for Jekyll.