Stripe決済で
「売れる」プロダクトへ

1. アーキテクチャ -- Dashboard から Stripe、そしてDBへ

Stripe決済統合の核心は「ユーザーの課金状態をサーバーサイドで正確に追跡する」ことにある。フロントエンドはあくまで表示と遷移のトリガーで、真の状態管理は Webhook 経由で DB に反映される。

Stripe Checkout Session はホスト型の決済ページを生成する。ユーザーはミセバンAIのドメインを離れ、Stripeのセキュアな決済ページでカード情報を入力する。決済完了後、Stripe が Webhook を叩き、サーバー側で plan_tier を更新する。フロントエンドを一切信用しない設計だ。

2. 料金プラン体系

小規模店舗から大規模チェーンまで、段階的にスケールする4つのプランを設計した。

フリープランで導入障壁を下げ、実際に効果を実感してからアップグレードする流れだ。スターターの¥9,800/月は従来の有人巡回コスト（月額5-10万円）の10分の1以下。プロプランのヒートマップとAPIは、データドリブンな経営判断を可能にする。

3. 実装の詳細

pub struct StripeClient {
    http: reqwest::Client,
    api_key: String,
    webhook_secret: String,
}

#[derive(Debug, Clone, Serialize)]
pub struct PricingPlan {
    pub tier: &'static str,
    pub name: &'static str,
    pub price_monthly: i64,
    pub max_cameras: Option<i32>,
    pub retention_days: i32,
    pub features: Vec<&'static str>,
    pub stripe_price_id: &'static str,
}

pub const PLANS: &[PricingPlan] = &[
    PricingPlan {
        tier: "free", name: "フリー", price_monthly: 0,
        max_cameras: Some(1), retention_days: 7,
        features: vec!["基本AI分析"],
        stripe_price_id: "",
    },
    PricingPlan {
        tier: "starter", name: "スターター", price_monthly: 9800,
        max_cameras: Some(4), retention_days: 30,
        features: vec!["高精度AI分析", "LINE通知"],
        stripe_price_id: "price_starter_monthly",
    },
    PricingPlan {
        tier: "pro", name: "プロ", price_monthly: 29800,
        max_cameras: Some(16), retention_days: 90,
        features: vec!["最高精度AI分析", "LINE通知", "ヒートマップ", "API"],
        stripe_price_id: "price_pro_monthly",
    },
    PricingPlan {
        tier: "enterprise", name: "エンタープライズ", price_monthly: 49800,
        max_cameras: None, retention_days: -1,
        features: vec!["カスタムAIモデル", "専用SLA", "全機能"],
        stripe_price_id: "price_enterprise_monthly",
    },
];

PricingPlan をコード内に定数として定義することで、料金表示・権限チェック・Checkout 生成のすべてが単一の真実の源 (Single Source of Truth) から導かれる。

async fn handle_stripe_webhook(
    State(state): State<AppState>,
    headers: HeaderMap,
    body: String,
) -> Result<StatusCode, ApiError> {
    // 1. 署名検証 -- なりすまし防止
    let sig = headers.get("Stripe-Signature")
        .ok_or(ApiError::Unauthorized)?;
    state.stripe.verify_webhook_signature(&body, sig)?;

    let event: StripeEvent = serde_json::from_str(&body)?;

    match event.event_type.as_str() {
        "checkout.session.completed" => {
            let session = event.data.object;
            let store_id = session.metadata.get("store_id")
                .ok_or(ApiError::BadRequest)?;
            let tier = price_id_to_tier(&session.price_id);
            // DB更新: stripe_customer_id + plan_tier
            update_store_billing(
                &state.pool, store_id,
                &session.customer, tier,
            ).await?;
        }
        "customer.subscription.updated" => {
            let sub = event.data.object;
            let tier = price_id_to_tier(&sub.items[0].price.id);
            update_store_tier_by_customer(
                &state.pool, &sub.customer, tier,
            ).await?;
        }
        "customer.subscription.deleted" => {
            let sub = event.data.object;
            update_store_tier_by_customer(
                &state.pool, &sub.customer, "free",
            ).await?;
        }
        "invoice.payment_failed" => {
            let invoice = event.data.object;
            flag_payment_failed(
                &state.pool, &invoice.customer,
            ).await?;
        }
        _ => { /* 未処理イベントは無視 */ }
    }

    Ok(StatusCode::OK)
}

price_id_to_tier() は Stripe の Price ID を内部のプラン名に逆引きする関数だ。Checkout Session の metadata に store_id を埋め込むことで、Webhook 受信時にどの店舗のサブスクリプションかを特定できる。

4. Webhook イベントフロー

Stripe Webhook は4つのイベントを処理する。それぞれが異なるビジネスロジックにマッピングされる。

すべてのイベントで署名検証を最初に実行する。Stripe の Webhook Secret で HMAC-SHA256 を検証し、正当なリクエストのみを処理する。不正リクエストは 401 で即座に拒否。

5. ダッシュボード -- 課金UI

// Dashboard: Checkout フロー
async function handleUpgrade(tier) {
  const res = await fetch('/api/v1/billing/checkout', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${token}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ plan_tier: tier }),
  });
  const { checkout_url } = await res.json();
  // Stripe Checkout ページにリダイレクト
  window.location.href = checkout_url;
}

// Dashboard: Customer Portal (カード変更・解約)
async function openPortal() {
  const res = await fetch('/api/v1/billing/portal', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${token}` },
  });
  const { portal_url } = await res.json();
  window.location.href = portal_url;
}

フロントエンドは URL を受け取ってリダイレクトするだけ。カード情報は一切ミセバンAIのサーバーを通らない。PCI DSS への準拠負担をゼロにする設計だ。

6. Before / After -- 「無料デモ」から「課金プロダクト」へ

最大の変化は「プロダクトからビジネスへの転換」だ。技術的に優れていても収益がなければ持続しない。Stripe統合により、ミセバンAIはユーザーに価値を提供し、対価をいただける事業体になった。

7. 新規APIエンドポイント

Cycle 3 までの12エンドポイントと合わせ、合計17エンドポイント。GET /billing/pricing は認証不要で、ランディングページからも呼べる。POST /webhooks/stripe は Stripe 署名ヘッダーで認証を代替する。

8. DB スキーマ変更

-- 004_billing.sql
ALTER TABLE stores
  ADD COLUMN stripe_customer_id TEXT UNIQUE,
  ADD COLUMN plan_tier TEXT NOT NULL DEFAULT 'free'
    CHECK (plan_tier IN ('free', 'starter', 'pro', 'enterprise')),
  ADD COLUMN line_user_id TEXT,
  ADD COLUMN payment_failed BOOLEAN NOT NULL DEFAULT false;

-- インデックス: Webhook で customer_id から店舗を逆引き
CREATE INDEX idx_stores_stripe_customer
  ON stores (stripe_customer_id)
  WHERE stripe_customer_id IS NOT NULL;

-- RLS: 自店舗の billing 情報のみ読み書き可能
CREATE POLICY "billing_own_store" ON stores
  FOR ALL USING (auth.uid() = owner_id);

stripe_customer_id に UNIQUE 制約を付けることで、1店舗 = 1 Stripe Customer の整合性を保証する。plan_tier の CHECK 制約は、不正な値の混入を DB レベルで防ぐ。

9. 技術的判断

10. 成果と数字

作成・更新したファイル

1. crates/api/src/billing.rs -- StripeClient、PricingPlan 定義、Checkout/Portal/Subscription (280行)
2. crates/api/src/main.rs -- 5エンドポイント追加、StripeClient 初期化 (+95行)
3. crates/api/Cargo.toml -- hmac, sha2 依存追加
4. web/dashboard/billing.js -- 料金グリッド、Checkout フロー、Portal リンク (185行)
5. web/dashboard/index.html -- 課金セクション、利用状況バー追加
6. web/dashboard/billing.css -- 料金カード、プラン比較のスタイル (92行)
7. supabase/migrations/004_billing.sql -- stripe_customer_id, plan_tier, line_user_id カラム (28行)
8. web/landing/index.html -- ランディングページ料金セクションを API 連動に更新

技術がどれだけ優れていても、ユーザーがお金を払う仕組みがなければ事業は成立しない。Cycle 4 で、ミセバンAIは「動くデモ」から「売れるプロダクト」になった。

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

Cycle 5 は本番運用 (Production Readiness)だ。具体的には以下を進める。

• 監視・ログ基盤 -- 構造化ログ、エラートラッキング、アップタイム監視
• カスタムドメイン -- api.misebanai.com / app.misebanai.com のDNS設定とTLS
• CI/CD パイプライン -- GitHub Actions でテスト → ビルド → デプロイの自動化
• パフォーマンスチューニング -- API レスポンスタイム、DB クエリ最適化、キャッシュ戦略
• セキュリティ監査 -- rate limiting、入力バリデーション、CORS 設定の総点検

4つのサイクルで「見て」「判断して」「知らせて」「稼ぐ」仕組みが揃った。Cycle 5 ではこの仕組みを壊れない基盤の上に乗せる。

コードを書くことは始まりに過ぎない。それを24時間365日、止まらずに動かし続けること。それが本番運用だ。