Sprint Cycle 1 — ダッシュボード・DB・認証を1時間で構築する

1. 1時間サイクルの設計

前回までの状態

まず、現時点で完成しているものを整理する。

• ランディングページ: デザイン・実装・デプロイ完了
• AI推論エンジン: Rust + ONNX Runtime で動作確認済み
• CI/CDパイプライン: GitHub Actions でテスト→ビルド→デプロイ自動化
• ブログ12本: 技術解説、会議録、戦略記事を公開済み

足りないもの

プロダクトとして「使える」状態にするには、まだ大きなピースが欠けている。

• データベース: 来客データ・店舗情報・ユーザー情報の永続化
• 認証システム: ログイン・サインアップ・セッション管理
• ダッシュボード: データを可視化するUI
• 決済システム: Stripe連携による課金
• LINE通知: リアルタイムアラート配信

これら全てを従来の開発プロセスで実装すると、最低でも2-3週間。しかし、AI駆動の1時間サイクルなら話が変わる。

サイクルの構造

なぜ1時間なのか。理由は2つある。

第一に、集中力の限界。人間が深い集中を維持できるのは60-90分が限界だ。1時間を1サイクルとすることで、集中力が切れる前に必ず成果物が生まれる。

第二に、フィードバックループの最短化。1時間ごとにデプロイ可能な状態にすることで、「作ったけど動かない」というリスクを最小化できる。動くものが手元にあれば、次のサイクルの方向修正も容易だ。

2. Cycle 1 の実装内容

今回のサイクルでは、3つのAIエージェントを並列に起動し、それぞれ独立したタスクを同時実行する。

-- stores テーブル: 店舗情報の中核
CREATE TABLE stores (
  id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  owner_id    UUID REFERENCES auth.users(id) NOT NULL,
  name        TEXT NOT NULL,
  address     TEXT,
  timezone    TEXT DEFAULT 'Asia/Tokyo',
  created_at  TIMESTAMPTZ DEFAULT now(),
  updated_at  TIMESTAMPTZ DEFAULT now()
);

-- RLS: オーナーのみ自分の店舗にアクセス
ALTER TABLE stores ENABLE ROW LEVEL SECURITY;
CREATE POLICY "owner_access" ON stores
  USING (owner_id = auth.uid());

-- visitor_counts テーブル: 来客カウントの時系列データ
CREATE TABLE visitor_counts (
  id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  store_id    UUID REFERENCES stores(id) NOT NULL,
  camera_id   UUID REFERENCES cameras(id),
  count_in    INTEGER DEFAULT 0,
  count_out   INTEGER DEFAULT 0,
  counted_at  TIMESTAMPTZ DEFAULT now()
);

-- 時間帯別集計関数
CREATE FUNCTION hourly_counts(target_store UUID, target_date DATE)
RETURNS TABLE(hour INT, total_in BIGINT, total_out BIGINT) AS $$
  SELECT
    EXTRACT(HOUR FROM counted_at)::INT,
    SUM(count_in),
    SUM(count_out)
  FROM visitor_counts
  WHERE store_id = target_store
    AND counted_at::DATE = target_date
  GROUP BY 1 ORDER BY 1;
$$ LANGUAGE sql STABLE;

RLS (Row Level Security) がなぜ重要か。SaaSにおいて、あるユーザーが他のユーザーのデータにアクセスできてしまうのは致命的なセキュリティバグだ。SupabaseのRLSを使えば、データベースレベルでアクセス制御が強制される。アプリケーションコードにバグがあっても、データ漏洩は起きない。

3. 成果と数字

Cycle 1 の実行結果を定量的に振り返る。

具体的な成果を列挙する。

1. /dashboard/ でログイン・ダッシュボード表示: メールアドレスとパスワードでサインアップ・ログインし、即座にダッシュボード画面が表示される
2. Supabase PostgreSQLスキーマ完成: 6テーブル、3集計関数、2トリガーを含む本番レディなスキーマ
3. RLSでマルチテナント対応: 全テーブルにRow Level Securityを適用。ユーザーは自分の店舗データのみ参照可能
4. Chart.jsでリアルタイムチャート表示: 時間帯別来客数、日別推移、曜日比較の3種類のチャート
5. モバイル対応レスポンシブUI: サイドバーがハンバーガーメニューに変化し、スマートフォンでも快適に操作可能

4. 次のサイクルで何をするか

Cycle 1 はダッシュボード・DB・認証の「ハコ」を作った。ここからは、ハコの中身を充実させていく。

各サイクルは1時間を基本単位とする。5サイクル = 5時間で、プロダクトはMVPとして「使える」状態になる計算だ。

1時間あれば、プロダクトは1歩進む。100時間あれば、100歩。完璧を待つな、サイクルを回せ。

次回の記事では、Cycle 2 の実装記録を公開する。Rustの推論エンジンとSupabase PostgreSQLをsqlxで接続し、カメラ映像から来客データをリアルタイムでDBに書き込むパイプラインを構築する。