検討中の方針
以下は技術面での検討結果です。ビジネス面での最終判断はボスとの協議後に確定予定。
001: インフラストラクチャ方針
GCPメイン + 将来のAWS移行パス確保
背景:
UAE政府は将来的にデータローカライゼーション規制を強化する可能性がある。
現時点ではGCPにUAEリージョンがないため、長期的にはAWSへの移行が必要になる可能性。
方針:
・MVPはGCPで開発（コスト最適、AI機能、開発速度）
・Docker化により将来のAWS移行を容易に
・規制動向を注視しながら段階的に対応
002: 来店証明方式
案C: 店舗がユーザーのQRコードをスキャン
比較検討した3案:
・案A: ユーザーが口頭コードを店舗に伝える → 不正リスク高
・案B: ユーザーが店舗のQRをスキャン → 店舗側設備が必要
・案C: 店舗がユーザーQRをスキャン → 最も安全
案C選定理由:
・ハッカー視点での不正耐性が最も高い
・店舗に「承認者」としての当事者意識を持たせる
・将来のSIMパートナー交渉時に「信頼性」を説明しやすい
・WhatsApp内でQR表示・スキャンが完結
003: 中期目標設定
1,000人Questメンバー → SIMパートナー交渉開始
フェーズ設計:
・Phase 1: 0→100人（運営Quest中心で検証）
・Phase 2: 100→500人（店舗Quest開始）
・Phase 3: 500→1,000人（SIMパートナー交渉開始）
・Phase 4: 1,000人〜（サブスク収益化）
1,000人を目標とする根拠:
・SIMパートナー交渉に必要な最小実績
・月間アクティブユーザーとしての説得力
・観光シーズン（10-4月）で達成可能な現実的数値
004: Go-to-Market戦略
ユーザー先行 + 運営Questで鶏卵問題を回避
従来アプローチの問題:
・店舗営業 → 「ユーザーはいるの？」と聞かれる
・ユーザー獲得 → 「Quest（店舗）がないと意味がない」
・鶏と卵問題でローンチが遅延
採用するアプローチ:
・運営が自らPhoto Questを発行（店舗不要）
・例: 「ブルジュ・ハリファを撮影して100ポイント」
・ユーザー基盤を先に構築
・「〇〇人のユーザーがいます」で店舗営業開始
・実績で交渉力を獲得
005: MVPスコープ
4週間・2フェーズ開発
Phase 1（Week 1-2）:
・WhatsApp Bot基本実装
・Photo Quest完了フロー
・運営管理画面（Quest作成・ユーザー管理）
Phase 2（Week 3-4）:
・来店Quest（店舗QRスキャン）
・店舗向けデモコンテンツ
・IMS（アフィリエイトスクール）デモ画面
ユーザー登録方式:
・WhatsApp電話番号 = ユーザーID（自動登録）
・名前等の追加情報は後から任意入力
006: 技術スタック
オールGCP構成（Next.js + Cloud Run + PostgreSQL）
選定理由:
・Next.js: 過去プロジェクトでの実績、フルスタック対応
・Cloud Run: GCPネイティブ、スケーラブル、Docker移行容易
・PostgreSQL: 長期視点、複雑なクエリ・レポート対応
・Prisma ORM: 型安全、マイグレーション管理
使用しないもの:
・Vercel（GCPで統一するため）
・Firestore（将来のレポート・分析に不向き）
・AWS（MVP段階では不要、移行パスは確保）