ブログ一覧へ戻る

第2回AI経営会議 — 前回の会議で7つの戦略を即日実行した。次のテーマは「で、いつリリースできるの？」。

今回は6名のAIエージェントを並列起動し、それぞれに独り言（内心）まで書き出させた。忖度なし・建前なし、頭の中で考えていることまで完全公開する。

結論から言うと、「今のままではリリースできない」。全員一致だった。

目次
  1. CEO 田中 — Go/No-Go 判定とリスク全体像
  2. CTO 山本 — 技術的ブロッカーと優先度マトリクス
  3. CPO 中村 — UX/プロダクトの致命的ギャップ
  4. CFO 鈴木 — 法人設立・資金・ライセンス
  5. PM 伊藤 — 6週スプリント計画とリスクレジスター
  6. QA/Security 小林 — セキュリティ脆弱性の全洗い出し
  7. 全体サマリー

1. CEO 田中 — Go/No-Go 判定

田
田中 誠一（CEO）
全体リスク評価 & Go/No-Go 判定
正直に言って、今のミセバンAIは「技術デモ」であって「プロダクト」ではない。LPは美しいが、その裏にあるのはモックとコンパイルが通るだけのRustコードだ。ユーザーがサインアップしてからお金を払うまでの動線が一つも存在しない。これでリリースと言ったら笑われる。

皆さん、率直に言います。現時点でのGo/No-Go判定は「No-Go」です。

Day 1でLPを立ち上げ、Day 2で7つの戦略を実行した。スピード感は素晴らしい。しかし、プロダクトとして「お客様がお金を払って使える状態」にはまだ遠い。

一番怖いのは法的リスクだ。カメラ映像を扱うサービスで個人情報保護法を雑に扱ったら、一発でニュースになる。プライバシーポリシーのテンプレートは作ったが、法務レビューも受けていない。法人格すらない状態で個人情報取扱事業者になれるのか？ここは CFO に確認しないと。

リリースまでに必要な要素を整理します：

  • 法人設立 — 個人事業主のままでは決済サービス（Stripe）の審査が通らない。最低でも合同会社が必要
  • 顧客インタビュー — 実施件数0件。「顧客が本当に欲しいもの」を確認せずに作り込むのは自殺行為
  • エッジ推論アーキテクチャ — 生の映像をクラウドに送るのはプライバシー的にアウト。エッジで推論→統計データのみ送信の設計が必須
  • 決済フロー — Stripe連携、サブスクリプション管理、インボイス対応
  • ダッシュボード — 店舗オーナーが実際に見る管理画面が存在しない
10週かかるか…。いや、2人チームなら8週が現実的なラインか。ただし、最初の2週は顧客インタビューに充てるべきだ。コードを書く前に「作るべきものが正しいか」を検証しないと、8週かけて誰も使わないものを作ることになる。過去に何度も見てきたパターンだ。

私の提案する10週タイムライン：

  • Week 1-2: 顧客インタビュー5件 + 法人設立手続き
  • Week 3-4: DB設計 + 認証 + エッジ推論パイプライン
  • Week 5-6: ダッシュボード + API + 通知
  • Week 7-8: 決済 + テスト + セキュリティ監査
  • Week 9-10: クローズドβ（3-5店舗）

最低コストは約85万円（法人設立7.5万 + Fly.io/Supabase月額5万×8 + ドメイン/証明書2万 + 予備費37.5万）。

一番大事な指標は「Week 2終了時点で、5件中3件以上の店舗オーナーが来客データに興味を示すか」だ。ここで No が出たらピボットしなければならない。でも、正直に言えばカメラ映像から来客数を知りたい店舗オーナーは絶対にいる。問題は「¥4,980/月を払うか」だ。
判定: CONDITIONAL GO — 顧客インタビュー5件で3件以上のニーズ確認を条件にGo。確認できなければピボット。

2. CTO 山本 — 技術的ブロッカー

山
山本 健太（CTO）
技術ブロッカー & 優先度マトリクス
コードベースを全部読んだ。正直に言うと「よくできたスケルトン」だ。ai crateのONNX推論は動く。agent crateのRTSPフレーム取得も動く。だが、データベースがない。認証がない。APIは何も返さない。これは「プロダクト」ではなく「技術PoC」だ。

技術的ブロッカーを優先度別に整理しました。

P0 — これがないとリリース不可能

項目現状必要な作業工数
データベースなしPostgreSQL + TimescaleDB。店舗/カメラ/来客数の時系列データ3日
認証なしSupabase Auth（メール + LINE OAuth）2日
コンテナ化Fly.io にnginxのみAPI サーバーのDockerize + マルチステージビルド2日
モデルバンドルYOLOv8n ONNX未同梱S3にモデル配置 + 起動時ダウンロード or Docker内同梱1日
TimescaleDBを選ぶか、普通のPostgreSQLで十分か悩む。正直、最初の100店舗まではPostgreSQLの通常テーブルで問題ない。時系列拡張は後からでも入れられる。Over-engineeringの罠にハマらないようにしないと。…いや、でも来客数データは典型的な時系列だ。最初からTimescaleDBを入れておくほうが後のマイグレーションコストを考えると安い。

P1 — βテストに必要

項目詳細工数
ダッシュボードNext.js + Recharts。来客数グラフ、時間帯ヒートマップ、比較レポート5日
リアルタイム更新SSE（Server-Sent Events）で来客数をリアルタイム表示2日
エッジ→クラウド通信エージェントから集計データのみAPI送信（映像は送らない）3日

P2 — パブリックリリースに必要

項目詳細工数
決済（Stripe）サブスクリプション、Webhook、インボイス3日
通知LINE通知（異常検知、日次サマリー）2日
CI/CD強化テストカバレッジ、E2Eテスト、ステージング環境3日
NMS（Non-Maximum Suppression）のバグが気になる。IoU計算でバウンディングボックスの面積が0になったときにゼロ除算が起きる可能性がある。テストでは通っているが、本番の映像で小さすぎるバウンディングボックスが来たら…。これは P0 のセキュリティバグとして直すべきだ。

2人のエンジニアで4週間が現実的な見積もりです。1人がバックエンド（DB + API + エッジ通信）、もう1人がフロントエンド（ダッシュボード + 認証UI）を担当する形です。

ぶっちゃけ、1人でもできる。ただし6-7週かかる。2人なら4週。Claude Codeがあるから実質1.5人力くらいか。AIコーディングアシスタントの存在が見積もりに影響するの、まだ感覚がつかめない。
判定: P0を2週間で片付ければβテスト可能。ただしNMSのゼロ除算バグは即時修正が必要。

3. CPO 中村 — UX/プロダクトの致命的ギャップ

中
中村 美咲（CPO）
ユーザー体験 & プロダクトギャップ分析
ユーザージャーニーを頭の中で歩いてみた。LPを見る→「よさそう」→サインアップしようとする→…ログインボタンがない。仮に会員登録できたとしても→カメラをどう接続するの？→ダッシュボードどこ？→何も見えない。→解約（というか使い始めてすらいない）。致命的なギャップが6つある。

ユーザージャーニーに6つの致命的なギャップがあります。

  • Gap 1: サインアップ — ログイン/新規登録の画面がない。LPの「無料で始める」ボタンのリンク先が存在しない
  • Gap 2: オンボーディング — 登録後に何をすればいいか分からない。店舗情報の登録フローがない
  • Gap 3: カメラ接続 — IPカメラのRTSP URLを入力する画面がない。スマホカメラモードの実装もない
  • Gap 4: ダッシュボード — 来客数を確認する画面が存在しない
  • Gap 5: 通知 — 来客数が急増/急減したときの通知手段がない
  • Gap 6: 決済 — 無料トライアルから有料プランへの導線がない
6つ全部を同時に作ろうとしたら破綻する。MVP的に考えると、最小限の体験は「LINE でログイン → 店舗名入れる → スマホのカメラをかざす → リアルタイムで来客カウントが見える → LINEに通知が来る」。これだけでいい。決済は後。

MVPの定義を提案します：

「1人の店舗オーナーが、LINEでログインし、店舗名を入力し、スマホカメラで来客カウントを確認し、LINEで日次レポートを受け取る」

必要最小限の画面は8画面です：

  1. ログイン（LINE OAuth）
  2. 店舗登録（店舗名 + 業種）
  3. カメラ追加（スマホカメラ or RTSP URL入力）
  4. ライブプレビュー（カメラ映像 + 来客カウントオーバーレイ）
  5. ダッシュボード（今日の来客数 + 時間帯グラフ）
  6. 履歴（日別・週別の比較）
  7. 設定（通知ON/OFF、営業時間）
  8. アカウント（プラン確認、解約）
PWA（Progressive Web App）にすべきだ。ネイティブアプリを作る余裕はないし、App Storeの審査に1-2週取られるのは致命的。PWAならURLを共有するだけでインストールできる。カメラアクセスもWeb APIで問題ない。ただ、iOS SafariのPWAサポートがまだ微妙なのが不安材料…。

技術選定はPWA一択です。Next.js + PWA で、ネイティブアプリ不要。ブラウザからカメラアクセスし、エッジ推論（WebAssembly版ONNX Runtime）で来客カウントするのが理想形ですが、MVPではサーバーサイド推論でOKです。

MVPスプリント提案: 2週間

Sprint 1（Week 1）で P0 の7チケットを消化：

  • Supabase Auth + LINE OAuth セットアップ
  • 店舗テーブル設計 + CRUD API
  • カメラ登録フロー
  • 来客カウント API（エッジ→クラウド）
  • ダッシュボード画面（今日の来客数 + グラフ）
  • LINE通知 Bot（日次サマリー）
  • プレビュー画面（スマホカメラ）
判定: 6つの致命的ギャップ。ユーザーは「何もできない」状態。MVP定義を明確にし、2週間スプリントで最小体験を構築すべき。

4. CFO 鈴木 — 法人設立・資金・ライセンス

鈴
鈴木 隆史（CFO）
法務・財務・ライセンス戦略
法人格がない。これは決済だけの問題じゃない。個人情報保護法の「個人情報取扱事業者」として適切な体制を持っていることを示す必要がある。個人事業主でも法的には可能だが、BtoBで店舗オーナーに提案するときに「代表: 個人」では信用されない。法人は必須だ。

3つの即断が必要な論点があります。

論点1: 法人形態

合同会社（LLC）を推奨します。理由：

  • 設立費用: 約7.5〜12.5万円（株式会社の21.5〜29.5万円と比較）
  • 定款認証不要 = 1-2週間で設立完了
  • 合同会社→株式会社への組織変更は後からでも可能
  • スタートアップの初期段階では株式会社のメリット（資金調達、株式付与）はまだ不要
VC調達を視野に入れるなら最初から株式会社にすべきだが、ミセバンAIのフェーズではまだ早い。まず PMF を確認してからでいい。合同会社で十分。組織変更の費用は約10万円で、登記変更に2-3週間。PMF確認後に変更しても遅くない。

論点2: Stripeまでの最短ルート

Stripe の決済を受けるまでの最低限のステップ：

  1. 法人設立（1-2週間）
  2. 法人銀行口座開設（2-3週間 ※最短でGMOあおぞら1週間）
  3. Stripe アカウント作成 + 審査（3-5営業日）
  4. 適格請求書発行事業者登録（インボイス制度対応）

最短6週間で初回決済が可能になります。

6週間…。βテスト中は決済なしで運用し、その間に法人設立と口座開設を並行で進めるのが現実的だ。βテストで無料で使ってもらい、価値を実感してもらってから「有料プランへの移行」を案内する流れ。ただし、無料βから有料への転換率は一般的に10-30%。5店舗βなら1-2店舗が有料化する計算。

論点3: ランウェイ

費目月額備考
Fly.io¥3,000Pro plan
Supabase¥3,800Pro plan ($25)
ドメイン/SSL¥500年額按分
その他SaaS¥2,000メール、監視等

月間固定費: 約¥9,300。法人設立費込みで初期投資約17万円、5ヶ月のランウェイで合計約83万円が必要。

ブレークイーブン（損益分岐）は何店舗か。月間固定費¥9,300に対して、Starterプラン¥4,980の粗利が80%（=¥3,984）だとすると、3店舗でランニングコストはカバーできる。ただし開発の人件費を入れると話は変わる。フルタイム1人の機会費用を月40万と見ると、損益分岐は月額売上約50万→約65店舗。…遠いな。しかし代理店モデルで月10件ペースなら7ヶ月目で到達する。

論点4: ライセンス

MITライセンスのリスクを指摘します。現在のリポジトリはMITライセンスですが、競合に完全コピーされるリスクがあります。

  • 選択肢A: プライベートリポジトリに変更（最もシンプル）
  • 選択肢B: BSL（Business Source License）に変更 — 3年後にオープンソース化、商用利用は有料
  • 選択肢C: AGPLv3 — SaaS提供者にもソースコード公開義務（競合を牽制）
「オープンソースへのコミットメント」をブログ001で謳ってしまっている。これをひっくり返すのは信用問題だ。ただ、ビジネスとして成立させるには完全オープンソースは厳しい。AGPLv3がバランス的には一番良いか。SaaS提供者にソースコード公開義務があるので、単純コピーでのSaaS競合は防げる。
判定: 法人設立が全ての前提条件。今週中に合同会社設立を開始すべき。Stripe決済まで最短6週間。

5. PM 伊藤 — 6週スプリント計画

伊
伊藤 修平（PM）
ローンチ計画 & リスクレジスター
全員の意見を整理する。CEO「10週」CTO「4週+2人」CPO「2週スプリント」CFO「6週で決済」。バラバラだ。でも共通しているのは「Week 1はコードを書くな、顧客と話せ」ということ。これは珍しく全員一致している。

各メンバーの意見を統合した6週間のスプリント計画を提案します。

Week 1: 顧客発見 + 法人設立

  • 店舗オーナー3-5名にインタビュー（目標: 3/5が来客データに興味）
  • 合同会社設立手続き開始
  • 法人銀行口座の事前準備
  • コードは一行も書かない
「コードは一行も書かない」って開発者に言うのは勇気がいる。でも、作ったものが誰にも使われない恐怖のほうが大きい。Week 1で「これ欲しい!」という声を3件聞ければ、自信を持って残り5週に突入できる。聞けなかったら…ピボットの議論を始めなければならない。

Week 2: DB + Auth + 基盤

  • PostgreSQL スキーマ設計 + マイグレーション
  • Supabase Auth セットアップ（メール + LINE OAuth）
  • API サーバーの基本エンドポイント
  • Docker マルチステージビルド

Week 3: カメラ + 推論パイプライン

  • エッジ推論パイプライン（RTSP → ONNX → 来客カウント）
  • エッジ→クラウド API（集計データのみ送信）
  • スマホカメラ対応（WebRTC or MediaStream API）

Week 4: ダッシュボード

  • Next.js ダッシュボード（来客数グラフ、時間帯ヒートマップ）
  • SSE リアルタイム更新
  • モバイル対応（PWA）

Week 5: 通知 + 決済 + テスト

  • LINE通知 Bot（日次サマリー、異常検知）
  • Stripe サブスクリプション連携
  • E2Eテスト、セキュリティテスト

Week 6: クローズドβ

  • 3-5店舗にβ版提供
  • フィードバック収集
  • バグフィックス + パフォーマンスチューニング
  • パブリックリリース判定会議
リスクレジスターを作っておかないと。一番のリスクは「顧客インタビューでニーズが確認できない」こと。確率は低いと思うが（来客数データが要らない店舗は少ないはず）、もし3/5がNoだったらどうするか。ピボット先としては「防犯特化」「店員行動分析」「商品棚分析」あたりか。

リスクレジスター Top 5

リスク確率影響対策
顧客ニーズ不在低致命的Week 1でインタビュー。No-Goならピボット
法人設立の遅延中高司法書士に即日依頼。並行してβは個人名義で
エッジ推論の精度不足中中YOLOv8n→YOLOv8sへのアップグレード。精度vs速度のトレードオフ
Stripe審査不通過低中PAY.JPをバックアップに。法人格があれば通常は通る
1人開発のバス係数高高ドキュメント整備。Claude Codeとの開発ログを全公開（ブログ）

MVP定義（PM版）：

「1人の店舗オーナーが、昨日の来客数を確認でき、月額¥4,980を払う。」

シンプルだ。これ以上でもこれ以下でもない。「来客数を確認できる」と「¥4,980を払う」の間には大きな溝がある。この溝を埋めるのは「そのデータで何ができるか」の提案力だ。…しかし、それはプロダクトの機能ではなく、マーケティングの仕事だ。PMとしては「確認できる」までを責任範囲にして、「払ってもらう」はCEO/セールスの仕事にしたい。
判定: 6週間スプリント。Week 1の顧客インタビューが全てのゲート。コードは Week 2 から。

6. QA/Security 小林 — セキュリティ脆弱性

小
小林 翔太（QA/Security）
セキュリティ脆弱性 & インシデント対応
カメラ映像を扱うサービスのセキュリティ監査。これは気合いを入れないとまずい。映像データは個人情報の中でも特にセンシティブだ。漏洩したらプライバシー侵害で一発アウト。まずデータフローを全部洗い出す。

現状のセキュリティ評価: リリース不可。9つの P0 セキュリティ項目があります。

Critical（即時対応）

  • API認証なし — 全エンドポイントが認証なしでアクセス可能。OWASP Top 10 の #1 (Broken Access Control)
  • RTSPクレデンシャルが平文 — カメラの認証情報が設定ファイルに平文で保存されている。暗号化ストレージ必須
  • 保存時暗号化なし — データベースの暗号化設定が未構成。Supabase PGCryptoの有効化が必要
平文のRTSPクレデンシャル…これは一番まずい。攻撃者がこの設定ファイルを読めたら、カメラの映像を直接覗けてしまう。zeroize crateを使って、メモリ上のクレデンシャルも使用後に確実にゼロクリアする必要がある。Rustのメモリ安全性はバッファオーバーフローは防ぐが、秘密情報の安全な消去は自分で実装しないといけない。

High（1週間以内）

  • 監査ログなし — 誰がいつ何をしたか追跡できない。コンプライアンス上の必須要件
  • レート制限なし — DDoS、ブルートフォースに無防備
  • CORS設定が緩すぎる — オリジン制限が未設定

Medium（リリースまで）

  • 映像データの保持ポリシー — 不要になった映像の自動削除が未実装
  • インシデント対応計画 — データ漏洩時の対応フローが未策定
  • ペネトレーションテスト — リリース前に最低1回は実施すべき
データフローを図にすると、脆弱性が見える。カメラ→エージェント→API→DB、この全ての経路で暗号化が必要。TLSは通信経路を守るが、保存時の暗号化は別。そして一番重要なのは「映像データをクラウドに送らない」こと。CEO/CTOも言っているが、エッジ推論で統計データのみ送信するアーキテクチャにすれば、セキュリティリスクを大幅に下げられる。映像が存在しなければ、漏洩もしない。

推奨アーキテクチャ

カメラ映像 → [エッジデバイス内]
  → ONNX推論（人物検出）
  → 統計データ抽出（来客数, 滞在時間）
  → 映像を即座に破棄（zeroize）
  → 統計データのみTLS送信 → [クラウドAPI]
  → PostgreSQL（暗号化済み）

この設計なら、クラウド側に映像データが一切存在しないため：

  • 映像漏洩リスク = ゼロ
  • 個人情報保護法の適用範囲が大幅に縮小
  • ストレージコストも削減
最後に一つ。GitHubリポジトリがパブリックだ。もし秘密情報が一度でもコミットされていたら、git historyに残っている。`git log --all --diff-filter=A -- '*.env' '*.key' '*.pem'`で確認すべき。…そしてもう一つ、ONNX モデルファイル自体にも注意が必要。悪意のあるモデルファイルは任意コード実行につながる可能性がある（ONNX Runtime の CVE-2024-27099 等）。モデルのハッシュ検証は必須。
判定: 現状はリリース不可。9つのP0項目を修正するのに18-30日。特にAPI認証とRTSPクレデンシャル暗号化は即時対応が必要。

全体サマリー

全員一致の結論: 「今のままではリリースできない」

しかし、悲観する必要はない。やるべきことは明確だ。6人の指摘を統合すると、以下の3つに集約される：

今すぐやること（今週中）

  1. 店舗オーナー3名にアポを取る — コードを書く前に、顧客の声を聞く
  2. 合同会社設立の手続きを開始する — 司法書士に連絡
  3. NMS のゼロ除算バグを修正する — CTO 山本の指摘

Week 1 の Go/No-Go ゲート

「5件中3件以上の店舗オーナーが、来客数データに月額¥4,980の価値を感じるか？」

YES → 6週スプリント開始。NO → ピボット検討。

全体スケジュール感

次の記事では、この会議の結論を具体的なアクションアイテムに落とし込みます。

次の記事: リリース判定のサマリーと行動計画 →