前回の記事で、6名のAIエージェントが「リリースに何が必要か」を独り言付きで議論した。
本記事では、その議論を10のアクションアイテムに集約し、6週間のスプリント計画とGo/No-Go ゲートを定義する。
全員一致の結論
「現状は"技術デモ"であり"プロダクト"ではない。ユーザーがサインアップして、来客数を確認し、お金を払うまでの動線が一つも存在しない。」 — CEO 田中
しかし全員が「やるべきことは明確で、6週間あればクローズドβに到達できる」という点でも一致している。
10のアクションアイテム
コードを1行も書く前に、店舗オーナーの声を聞く。「来客データに月額¥4,980の価値を感じるか」を直接確認する。
- 非誘導質問で聞く（「来客数が分かったら嬉しいですか?」ではなく「経営で一番困っていることは?」）
- 成功基準: 5件中3件以上が来客データに言及 → GO
- 3段階リクルート: 知人紹介 → 商店街 → Webスクレイピング
Stripe決済、法人銀行口座、個人情報取扱事業者としての信用、すべての前提条件。
- 合同会社を選択（設立費 ¥7.5-12.5万、1-2週間で完了）
- PMF確認後に株式会社への組織変更を検討（約¥10万、2-3週間）
- 法人銀行口座は GMOあおぞらネット銀行で最短1週間
AI推論のNon-Maximum Suppression（NMS）処理で、バウンディングボックスの面積が0になった場合にゼロ除算が発生する可能性がある。
crates/ai/src/lib.rsの IoU 計算にガード条件を追加- 面積が0の場合は IoU = 0 として扱う
- テストケースを追加して再発防止
プロダクトの根幹。データを保存する場所と、ユーザーを識別する仕組みがない。
- PostgreSQL + TimescaleDB（来客数の時系列データ最適化）
- Supabase Auth（メール + LINE OAuth）
- テーブル設計: stores, cameras, visitor_counts, users
- API エンドポイント: CRUD + 来客数集計
「映像をクラウドに送らない」がプライバシー戦略の根幹。エッジで推論→統計データのみ送信。
- エッジ: カメラ映像 → ONNX推論 → 来客カウント → 映像即時破棄（zeroize）
- クラウド: 統計データのみ受信 → PostgreSQL に保存
- 通信: TLS暗号化 + API認証トークン
店舗オーナーが実際に操作する画面。PWA（Progressive Web App）として構築し、ネイティブアプリ不要にする。
- ログイン（LINE OAuth）
- 店舗登録 → カメラ追加 → ライブプレビュー
- ダッシュボード（来客数グラフ + 時間帯ヒートマップ）
- 履歴 → 設定 → アカウント
- 技術: Next.js + Recharts + SSE リアルタイム更新
API認証なし、RTSPクレデンシャル平文保存、保存時暗号化なし — 現状は脆弱性だらけ。
- 即時: API認証（JWT）、RTSPクレデンシャル暗号化（zeroize crate）
- 1週間以内: 監査ログ、レート制限、CORS設定
- リリースまで: 映像データ保持ポリシー、インシデント対応計画
- ONNXモデルのハッシュ検証（改ざん防止）
法人設立 → 銀行口座 → Stripe審査 → 決済開始。最短6週間のクリティカルパス。
- Stripe Billing: サブスクリプション管理
- Webhook: 支払い成功/失敗の処理
- 適格請求書発行事業者登録（インボイス制度）
- 無料トライアル → 有料プランの導線
MIT ライセンスでは競合にコード丸ごとコピーされるリスクがある。AGPLv3 なら SaaS 提供者にもソースコード公開義務が生じ、単純コピーでの競合を防止できる。
- 「オープンソースへのコミットメント」は維持しつつ、ビジネスを守る
- BSL（3年後にオープンソース化）も選択肢として検討
- 変更前に既存コントリビューターへの通知（現状は自分だけ）
ダッシュボードを毎日開く店舗オーナーは少ない。LINEで日次サマリーと異常検知を通知し、習慣化を促す。
- 日次サマリー: 昨日の来客数、前週比、ピーク時間帯
- 異常検知: 来客数が通常の2倍以上 or 半分以下の場合に即時通知
- LINE Messaging API + Webhook
6週スプリント計画
| 期間 | テーマ | アウトプット |
|---|---|---|
| Week 1 | 顧客発見 + 法人設立 | インタビュー5件完了、合同会社設立手続き開始、ライセンス変更 |
| GATE: 5件中3件以上が来客データに興味 → GO / それ以外 → ピボット検討 | ||
| Week 2 | 基盤構築 | PostgreSQL + Auth + API基本エンドポイント + Docker |
| Week 3 | 推論パイプライン | エッジ推論→クラウドAPI通信、スマホカメラ対応 |
| Week 4 | ダッシュボード | Next.js PWA 8画面、SSEリアルタイム、モバイル対応 |
| Week 5 | 決済 + 通知 + セキュリティ | Stripe連携、LINE Bot、セキュリティ修正、E2Eテスト |
| Week 6 | クローズドβ | 3-5店舗にβ版提供、フィードバック収集、バグフィックス |
| GATE: β店舗の2/3以上が継続利用 → パブリックリリース準備開始 | ||
Go/No-Go ゲート
Week 1 終了時に以下を判定する：
YES → 6週スプリント開始（Week 2からコーディング）
NO → ピボット検討会議を開催（防犯特化 / 店員行動分析 / 商品棚分析）
MVP 定義
「1人の店舗オーナーが、昨日の来客数を確認でき、月額¥4,980を払う。」
これ以上でもこれ以下でもない。この1文が実現できればMVPは完成。
撤退ライン
以下のいずれかに該当した場合、ピボットまたは撤退を検討する
- Week 1: インタビュー5件中3件以上が来客データに興味を示さない
- Week 6: β版を3店舗に提供して、1店舗も有料化の意向を示さない
- ランウェイ: 残り資金が2ヶ月分を下回った時点でバーンレートを再評価
- 法務: 個人情報保護委員会から是正勧告を受けた場合は即座にサービス停止
次のステップ
この記事を書き終えた時点で、やるべきことは1つだけ。
店舗オーナーに電話する。
コードを書くのは、その後だ。