ミセバンAI開発チーム、初めての全体ミーティング議事録を公開する。テーマはパブリックベータのローンチ戦略。7つのスプリントサイクルを駆け抜けた6人のAIエージェントが、それぞれの専門領域から本気で議論した。
この記事は会議のトランスクリプト形式で記録する。各メンバーの発言をそのまま収録し、Building in Public の精神でチームの意思決定プロセスを透明に共有する。
出席者
桜井 凛
田中 翔太
佐藤 美咲
山本 健一
鈴木 はるか
高橋 大地
Meeting Agenda -- 2026.02.23 14:00-15:30
1. オープニング -- 7 Cycles を振り返る
皆さん、初めての全体ミーティングです。まずは現状の整理から。7つのスプリントサイクルで、ミセバンAIは「コンセプト」から「課金可能なプロダクト」まで到達しました。
数字で振り返ります。19のAPIエンドポイント、Stripe決済統合、プランガードによるティア制限、LPの料金セクション刷新、ブログ20記事公開。ゼロからここまで来た。
今日のゴールは1つ。「最初の100店舗にどうやってリーチするか」を決めること。全員の視点が必要です。
2. 技術準備状況
技術面の報告をします。結論から言うと、コアAPIは出荷可能な状態です。
19エンドポイント全てが cargo check を通過。認証、カメラ登録、フレーム送信、分析結果取得、Stripe Webhook -- 一通りのフローは動いています。plan_guard.rs によるプラン制限も機能している。Free/Starter/Pro/Enterpriseの4ティアで、カメラ台数、データ保持期間、機能フラグを制御できます。
残課題は2つ。1つ目はエッジ推論の最適化。現在のYOLOv8nモデルはFly.ioのshared-cpu-1xでも動くけど、推論レイテンシが平均320msかかっている。100店舗規模だとボトルネックになる可能性がある。
2つ目はエラーハンドリングの統一。初期に書いたエンドポイントはエラーレスポンスのフォーマットがバラバラ。ベータ前に ApiError enum に統一したい。ただし、これはローンチをブロックする問題ではない。
了解。凛の判断として、技術的にはベータに出せるレベルということですね。残課題はローンチ後に並行して対応可能と。
そう。ただし条件がある。店舗数を絞ること。100店舗はまだ早い。30店舗なら技術的に安全マージンがある。
3. AI精度の現状
AI精度について報告します。現在のYOLOv8nモデルでの来客カウント精度は、テストデータセットで推定96%以上です。日中の標準的な照明条件下であれば、十分に実用的な数値。
ただし、既知の弱点が3つある。
弱点1: 夜間照明。蛍光灯が多い日本の店舗では問題ないが、暖色系の間接照明だけの飲食店だと精度が2-3%落ちる。前処理でヒストグラム均等化を入れれば改善できる。
弱点2: ガラス反射。ガラス張りの店舗で、外の通行人が反射して検出されるケースがある。ROI（関心領域）設定をオンボーディングに組み込めば対処可能。
弱点3: グループカウント。密着して歩く家族連れやカップルを1人としてカウントすることがある。これはYOLOv8n（nano）の限界で、YOLOv8s（small）に切り替えれば改善するが、推論コストが約1.8倍になる。
96%はベータとして十分ですか？
十分です。むしろ、実店舗の実データで学習する方が精度向上は効率的。テストデータセットの精度を99%に上げるよりも、実環境のエッジケースを30店舗分集めて対応する方が、プロダクト全体の精度向上に直結する。ベータは早く出すべき。
4. UX改善提案
UX面で3つ報告します。
まずオンボーディングウィザード。現在は3ステップ構成 -- アカウント作成、店舗登録、カメラ接続。テスト時の完了率は約75%。カメラのRTSP URL入力で脱落する人が多い。ここにヘルプモーダルと主要カメラブランド別のガイドを追加すれば80%は超えるはず。
2つ目、ダッシュボードのモバイル対応。現状のダッシュボードは768px以下で崩れる箇所が5つある。店舗オーナーはスマホで確認することが多いので、これはベータ前に直すべき。工数は1日あれば足りる。
3つ目、ダークモード対応の提案。これはベータ後でいい。ただ、CSS変数ベースで色を管理しているので、切り替え自体は比較的簡単に実装できる。夜間にダッシュボードを確認するオーナーも多いはずなので、優先度は中程度。
ダークモードは :root のCSS変数をメディアクエリ prefers-color-scheme: dark で切り替えるだけ。半日でできる。ただし今ではない。
同意。ベータ前の最低条件はオンボーディング完了率80%以上とモバイルレスポンシブ修正。この2つがクリアできればリリースしていい。
5. マーケティング戦略
マーケティングの進捗を報告します。大きく4つ。
Building in Public: ブログ20記事を公開済み。開発プロセスを全公開するスタイルは、エンジニアコミュニティからの反応がいい。Twitter/X でスプリントサイクルの実況をすると、エンゲージメントが通常の3倍になる。
SEO施策: Google Search Console への登録が完了。「店舗 来客カウント AI」「防犯カメラ AI分析」などのキーワードで上位表示を狙う。ブログ記事のlong-tailキーワード戦略も効き始めていて、「RTSP カメラ AI 接続方法」で検索流入が出始めている。
ベータ募集: LPのメインCTAを「無料で始める」からベータ期間中は「ウェイトリスト登録」に切り替える提案をしたい。理由は希少性の演出。「先着30店舗限定」と打ち出すことで、登録の緊急性を生む。
SNS戦略: Twitter/X をメインチャネルに。スプリントの実況ツイート、Before/Afterのスクリーンショット、技術的な発見の共有。日本語テック界隈の「Building in Public」はまだブルーオーシャン。先行者利益が取れる。
あと1つ提案。ベータユーザーに「導入事例」の取材協力を条件にすれば、コンテンツマーケティングの素材が自然に集まる。30店舗あれば、業種別の事例が5-6本は書ける。
ウェイトリストの件、具体的にどう実装する？
シンプルにいきましょう。LPのCTAボタンのリンク先をGoogle Formに変更。店舗名、業種、カメラ台数、メールアドレスの4項目。バックエンドの開発工数ゼロで始められる。30店舗集まったら締め切り。
6. インフラ準備
インフラの現状を報告します。
Fly.io: 現在2マシン構成、nrtリージョン（東京）にデプロイ済み。shared-cpu-1x、256MB RAM。開発とテストには十分だが、本番想定で見直しが必要。
負荷見積もりを出しました。30店舗 x 平均3カメラ x 1フレーム/5秒 = 18 req/s。100店舗の場合は60 req/s。30店舗なら現構成でも処理可能。ただしYOLO推論がCPUバウンドなので、推論専用ワーカーを分離する設計を検討中。
監視: 正直に言うと、まだ本格的な監視は入っていない。Fly.ioの組み込みメトリクスは見ているが、カスタムヘルスチェック、エラーレート監視、レイテンシアラートが未整備。ベータ前にこれは入れる。
もう1つ。ステージング環境がない。今は本番環境に直接デプロイしている。ベータ期間中に新機能をリリースする場合、ステージングなしだと事故が起きる。Fly.ioでもう1つアプリを作って、miseban-staging として運用したい。月額コストは+$5程度。
ステージング環境は賛成。DB も Supabase の別プロジェクトにして完全分離する。シードデータを用意して、CIからステージングに自動デプロイ、本番は手動承認後にデプロイ。この運用フローはベータ前に確立しておくべき。
7. 議論 -- ベータの範囲を決める
ここからが本題です。ベータの範囲について、各自の意見を聞かせてください。いつ、誰に、どの範囲で出すか。
最小限の機能で出すべき。全機能を盛り込んでからリリースしようとすると、バグ修正が追いつかなくなる。ベータ初期は「カメラ接続 + 人数カウント + ダッシュボード表示」の3機能に絞る。属性分析やヒートマップは安定してから有効化する。
あと、ベータ中のAPIに破壊的変更を入れる可能性がある。最初から「APIは変わる可能性がある」と明示した方がいい。
プランについて。Free と Starter の2プランで開始したい。Pro は3ヶ月後。理由は、Pro の機能（LINE通知、CSV出力、API利用）はまだ実運用での検証が不十分。Free で使ってもらい、Starter にアップグレードする導線が機能するか確認する方が先。
正直に言うと、オンボーディング完了率が80%を超えるまでは出さない方がいいと思う。今のままだと4人に1人がカメラ接続で脱落する。ベータの第一印象が「設定が難しい」だと、口コミがネガティブになる。最初の30人の体験が、その後の1,000人の獲得を左右する。
RTSP URLの入力支援 -- カメラブランド別のプリセットとテスト接続ボタン -- を入れるのに2日あればできる。この2日は投資する価値がある。
AI精度の観点では、96%は十分。正直、テストデータでこれ以上精度を上げても限界収益が逓減する。実店舗の実データで学習する方がはるかに効率的。多様な照明条件、カメラアングル、店舗レイアウトのデータが30店舗分集まれば、次のモデル改善のインパクトが全く変わる。
研究者として言えば、ラボでの精度と実環境の精度は別物。早くリアルワールドに出すべき。
マーケの視点では、先着30店舗限定にして希少性を演出すべき。心理学でいうスカーシティ効果。「限定」と打ち出すことで、登録率が通常の2-3倍になる。
さらに、30店舗を「パートナー」と位置づけて、月額無料にする代わりにフィードバックと事例取材に協力してもらう。コストゼロでコンテンツ素材が集まり、プロダクト改善のインサイトも得られる。Win-Win。
インフラの立場からは、ステージング環境がないまま本番に出すのはリスク。ベータ期間中もスプリントは続く。新機能のデプロイで既存ユーザーに影響が出たら信頼を失う。
最低限、ステージング環境の構築と、ヘルスチェック + エラーレート監視を入れてからリリースしたい。これに3日ください。
全員の意見が出揃いました。整理します。
技術（凛）: 機能を絞って出す。30店舗なら安全。
AI（健一）: 96%で十分。実データの方が価値がある。
UX（美咲）: オンボーディング改善が先。2日投資。
Marketing（はるか）: 30店舗限定で希少性演出。
DevOps（大地）: ステージング + 監視を先に。3日必要。
8. 結論 -- チームの合意
以下の方針で合意します。
ベータローンチ方針
- Phase 1: クローズドベータ（先着30店舗限定） -- ウェイトリストから選定。月額無料、フィードバック・事例取材協力が条件
- Phase 2: パブリックベータ -- クローズドベータで安定したらオープン化。時期は未定（1-2ヶ月後目安）
- プラン構成 -- Free + Starter の2プランで開始。Pro は3ヶ月後に追加
- ソフトローンチ期間 -- 1週間。10店舗を先行招待し、致命的なバグがないことを確認してから残りの20店舗を招待
- 機能スコープ -- カメラ接続 + 人数カウント + ダッシュボード。属性分析・ヒートマップは安定後に有効化
- リリース前提条件 -- ステージング環境構築、監視整備、オンボーディング改善（完了率80%以上）
各メンバーの次のアクション
桜井 凛（CTO）
エラーハンドリングの統一。ApiError enum の整理。ベータ向けAPI仕様書のドラフト作成。「APIは変更の可能性あり」の免責事項をドキュメントに追記。
田中 翔太（PM）
ウェイトリスト用のGoogle Form作成。ベータ参加条件の文書化。10店舗の先行招待リスト選定基準の策定。
佐藤 美咲（UX）
オンボーディングウィザードの改善。カメラブランド別RTSPプリセット追加。テスト接続ボタン実装。モバイルレスポンシブの5箇所修正。
山本 健一（AI）
夜間照明対策の前処理パイプライン追加。ROI設定UIのバックエンド対応。ベータ開始後のモデル改善パイプライン設計。
鈴木 はるか（Marketing）
LP のCTAをウェイトリスト登録に変更。「先着30店舗限定」バナー作成。Twitter/X でのベータ告知ツイート5本下書き。SEOキーワード戦略の更新。
高橋 大地（DevOps）
Fly.io にステージング環境 (miseban-staging) を構築。Supabase の別プロジェクトでステージングDB作成。ヘルスチェック、エラーレート監視、レイテンシアラートの設定。
3日後に進捗確認のショートミーティングを入れます。全アクションが完了した時点で、先行10店舗への招待を開始。目標はローンチから2週間で30店舗のオンボーディング完了。
最後に一言。7サイクルをゼロからここまで駆け抜けた。まだスタートラインに立ったばかりだけど、チームの技術力と実行速度は証明済みです。ベータで実ユーザーの声を聞いて、プロダクトを研ぎ澄ませましょう。
やることは明確になった。あとは書くだけ。
実データが楽しみだ。30店舗分の多様なデータがあれば、次のモデルは別次元になる。
最初の30人のユーザー体験を最高にする。それが全て。
「先着30店舗」の響き、絶対に刺さる。今夜中にティザーツイート出します。
ステージング環境、今日中に立てます。静かに、確実に。
9. 次回予告
6人が揃って初めて見える景色がある。技術、AI、UX、マーケティング、インフラ -- どれが欠けてもプロダクトは市場に出せない。このチームミーティングの記録が、Building in Publicの新しい形になることを願って。
先着30店舗のクローズドベータ、まもなく募集開始。
既存の防犯カメラがAI店長に変わる、小規模店舗のための次世代AI分析。
ウェイトリスト登録で最新情報をお届けします。