EC-CUBEからNext.js + Supabaseへ ― AIと進める、わが家のECリニューアル記

はじめに
安心して使えるECへ

妻が運営するフラワーショップ「花製作所」（以下、花製作所）のECを、EC-CUBE（Xserverが提供する構築サービスを利用）からNext.js + Supabaseへ段階的に移行します。

うちの販売手法（販売開始時にアクセスが集中する運用）との相性もあり、結果として在庫の不整合が起きてしまいました。既存のサービス自体は一般的な用途では十分に満足できる点も多かった**と思います。それでも、花を楽しみに待ってくれている方に不安を与えない仕組みを自分の手で作りたいと考え移行を決めました。

プロジェクト概要

目的：在庫・購入まわりの不整合をなくし、スムーズに買える体験をつくる
方針：Next.js + Supabase による内製化。段階的ロックとリアルタイム同期で衝突を抑制
配慮：既存サービスを否定しない。うちの販売運用と特性のミスマッチが主因
働き方：平日昼は会社、夜・週末の時間で進める（AIに補助してもらいながら）
目標：購入トラブルのゼロ化、運用負担の軽減、体感の速さ

背景と現状

会員：2,658名
商品：4,306点
販売スタイル：月2回の販売開始タイミングにアクセスが集中（同時200アクセス前後）
良かった点（既存環境）：
- 導入が早い、運用の初期コストが低い
- 一般的なトラフィックや使い方には十分応えてくれる
つまずきポイント（うちの運用では）：
- 販売開始直後のアクセス集中と在庫競合で不整合が発生しやすい
- 問い合わせ・返金対応が続くと、心理的な負担が大きい

ここが本当に難しいところで、「サービスの良し悪し」ではなく「うちの売り方との相性」が主な論点だった、という理解です。

なぜ移行するのか

同じ課題を繰り返さないために、在庫・購入まわりの処理を自分たちでコントロールしたい
妻がひとりで運用しやすいように、画面と導線を"うち仕様"にしたい
長く続けられるように、心配ごとを減らす（心理的コストの削減）

技術的アプローチ（計画）

1) 衝突を減らすための"段階的ロック"

短時間ロック → 決済確定ロックの二段構え
取り置きの時間は短すぎず長すぎず。機会損失とのバランスを見ながら調整します

// 在庫テーブルのステータス管理
CREATE TABLE inventory (
  id UUID PRIMARY KEY,
  product_id UUID NOT NULL,
  status TEXT CHECK (status IN ('available', 'soft_locked', 'hard_locked', 'sold')),
  locked_by UUID REFERENCES users(id),
  locked_at TIMESTAMP,
  lock_expires_at TIMESTAMP
);

ロックの段階:

フェーズ	ロック種別	ロック時間	解除条件
①カート投入	ソフトロック（警告表示）	2-3分	タイムアウト or 明示的な削除
②購入手続き開始	ハードロック（完全確保）	5分	決済完了 or タイムアウト
③決済処理中	トランザクションロック	30-60秒	成功 or 失敗

2) リアルタイム在庫同期

Supabase Realtimeで在庫の変化を即時反映
カート内状態と在庫状態のズレを最小に

// クライアント側での在庫状態監視
const channel = supabase
  .channel('inventory_changes')
  .on('postgres_changes', {
    event: 'UPDATE',
    schema: 'public',
    table: 'inventory'
  }, (payload) => {
    // 在庫状態変更を即座にUIに反映
    updateProductUI(payload.new)
  })
  .subscribe()

3) 集中アクセスを前提にした設計

販売開始時の同時アクセス200を目安に
読み込み・描画の分割、キャッシュの工夫、静的＋動的のいいとこ取り

技術的な対策:

Next.js ISR（Incremental Static Regeneration）で商品一覧を静的生成
在庫情報だけクライアント側でリアルタイム取得
Supabase Pro Plan（同時接続200対応）
Vercel Edge Networkで静的コンテンツ配信

4) UIのやさしさ（特に40〜60代を意識）

文字は少し大きめ、ボタンは押しやすく
迷いにくい導線、間違えても戻れる画面設計

実装方針:

// Tailwind CSS設定
{
  fontSize: {
    'mobile-base': ['18px', '1.75'],  // モバイルで18px以上
    'desktop-base': ['16px', '1.5'],  // PCで16px以上
  },
  spacing: {
    'touch-target': '44px',  // タップしやすいボタンサイズ
  },
}

AIとの付き合い方（私のルール）

正直、夜と週末だけの開発は、ひとりだと厳しいです。だからこそClaude / ChatGPTに協力してもらっています。ただ、丸投げにはしません。

設計やレビューの相棒として活用
実装は自分の目と手で最後まで確認
最終判断と責任は私にある、という前提

AI活用で変わったこと（実感）

観点	以前（AIなし）	今（AI協働）
時間の制約	平日夜・週末では厳しかった	夜・週末でも現実的に回る
学び方	本や記事中心	作りながら学ぶに移行
設計の幅	自分の経験に依存	代替案がすぐ試せる

できることが増えました。でも、楽になるだけではなく、判断する場面はむしろ増えたと感じています。

具体的な活用方法

Claude/ChatGPTに依頼したこと:

設計レビュー（在庫管理ロジックの検証）
コード生成（Supabase RPC関数、Realtime実装）
技術選定の相談（tRPC vs Server Actions、Drizzle vs Prisma）
技術的な問題の分析
ドキュメント作成（技術仕様書、API設計書）

自分が担う責任:

最終的な判断（技術選定、設計決定）
品質保証（テスト、負荷テスト、データ移行検証）
ビジネス要件の理解（妻との対話、顧客ニーズの把握）
運用責任（本番環境の管理、トラブル対応）

AI協働開発の3原則

1.判断は自分、実装はAI

設計判断・技術選定は人間が行う
コード生成・実装はAIが支援
AIは選択肢を提示し、人間が最適解を選ぶ

2.検証は必須

AIのコードも必ずレビュー・テスト
品質基準は妥協しない
負荷テスト、セキュリティ検証も人間が実施

3.責任は自分

最終的な品質・運用責任は開発者
AIは「思考のパートナー」であり「コピペツール」ではない
実装しながら学び、理解を深める

いま大事にしているKPI（目安）

購入トラブル：ゼロを目指す（在庫不整合の再発防止）
体感の速さ：初回表示と購入フローのストレスを下げる
運用工数：妻の負担を減らす（作業の簡素化・自動化）

具体的な目標値

購入トラブル:

在庫バグ: 現状3件/年 →0件
クレーム対応時間: 月5時間 →0時間

運用効率:

商品登録時間: 30分/商品 →15分/商品（50%削減目標）
配送ラベル作成: 手書き20分 →自動印刷5分（75%削減目標）
レポート作成: 手動集計2時間 →自動生成0時間

顧客満足度:

購入完了率: 推定60% →80%目標
リピート購入率: 現状35% →50%目標

データ移行の課題

会員データ（2,658名）の移行戦略

最大の懸念: パスワードハッシュの互換性

EC-CUBEのパスワードハッシュ形式（bcrypt/sha256）とSupabase Auth（bcrypt）の互換性問題があります。

移行戦略（検討中）:

Option A: 一括移行 + パスワードリセット必須

EC-CUBEからCSVエクスポート
Supabaseにメールアドレスと基本情報のみインポート
全会員に「パスワード再設定メール」送信
初回ログイン時に新しいパスワード設定

Option B: 段階的移行

旧システム併用期間を設ける
初回ログイン時にSupabaseに移行
パスワードは旧システムで検証 → Supabaseに新規登録

推奨: Option A（理由）

セキュリティ面で最も安全（新しいパスワードハッシュ）
実装がシンプル
移行完了が明確

管理ダッシュボード（最優先機能）

要件:

EC-CUBE管理画面と遜色ない機能
妻（非エンジニア）が直感的に操作できること

実装アプローチ: React Admin

// app/admin/page.tsx
import { Admin, Resource } from 'react-admin'
import { supabaseDataProvider } from '@/lib/supabaseDataProvider'

export default function AdminApp() {
  return (
    <Admin dataProvider={supabaseDataProvider}>
      {/* 商品管理 */}
      <Resource name="products" list={ProductList} edit={ProductEdit} create={ProductCreate} />

      {/* 注文管理 */}
      <Resource name="orders" list={OrderList} edit={OrderEdit} />

      {/* 顧客管理 */}
      <Resource name="customers" list={CustomerList} show={CustomerShow} />

      {/* ダッシュボード */}
      <Resource name="dashboard" list={Dashboard} />
    </Admin>
  )
}

必要なレポート機能

日次レポート:

当日の売上合計
当日の注文件数
当日の新規会員登録数
人気商品ランキング（当日）

月間レポート:

月間売上推移（グラフ）
月間注文件数
月間新規会員数
商品カテゴリ別売上
販売イベント別実績（月2回の販売）

年間レポート:

年間売上推移
年間注文件数
会員数推移
年間人気商品TOP10

コスト目標

年間10万円以内（月額約8,333円）を目標としています。

想定コスト構成

項目	サービス	月額コスト	年間コスト
ホスティング	Vercel Pro	$20 (約3,000円)	約36,000円
データベース	Supabase Pro	$25 (約3,750円)	約45,000円
ドメイン	お名前.com等	約100円	約1,200円
合計	-	約6,850円/月	約82,200円/年

✅目標10万円以内に収まる見込み

※Stripe手数料（3.6%）は別途、売上に応じて発生

まとめ
「責任の所在」をはっきりさせる設計へ

今回の見直しは、誰かを責めるためのものではありません。私たちの売り方と既存サービスの相性がよくなかった。だから、自分たちの手で調整できる設計に切り替える。それだけの話です。

お花を楽しみにしてくれている方に、安心してもらえる体験を。妻が続けやすい仕組みを。そのために、地道にやっていきます。

このプロジェクトが証明するスキル

観点	証明できるスキル
問題発見	運用特性とシステムのミスマッチを技術的に分析
意思決定	内製化 vs サービス利用の判断、技術選定の根拠
設計力	在庫管理ロジック、段階的ロック、リアルタイム同期
実装力	フロントエンド + バックエンド + 管理画面の一貫開発
品質管理	負荷テスト、トランザクション整合性、データ移行戦略
ビジネス理解	高齢者UX、運用効率化、コスト最適化
AI活用	Claude/ChatGPTとの協働開発手法
働き方	フルタイム勤務と並行した夜・週末開発

同じ悩みを持つEC事業者へ

このプロジェクトで得た知見は、同じ悩みを持つ中小EC事業者にも応用可能です。特に以下のような課題を抱えている方には参考になるはずです：

✅ 在庫管理の不安定さに悩んでいる
✅ アクセス集中時の問題に困っている
✅ 高齢者向けのUX改善が必要
✅ 少人数での運用効率化を図りたい
✅ AI活用で開発コストを抑えたい
✅ 既存サービスとの相性問題を感じている

同じ課題に直面している方、技術的な相談をしたい方は、お気軽にお問い合わせください。

これから

小さく検証 → 改善のサイクルを回す（販売日ごとに学びを反映）
在庫・決済まわりは保守的に、UIはやさしく
進捗や気づきは、また記事にしていきます

📅 移行スケジュール（2025年内予定）

Phase 1: 設計・プロトタイプ（2-3ヶ月）

在庫管理ロジックの実装・負荷テスト
会員データ移行戦略の確定
管理ダッシュボードのプロトタイプ

Phase 2: 開発（2-3ヶ月）

フロントエンド実装（商品一覧、カート、決済）
管理画面実装（React Admin）
Stripe決済統合

Phase 3: データ移行・テスト（1-2ヶ月）

会員2,658名の移行
商品4,306点の移行
負荷テスト（同時200アクセス）

Phase 4: 本番移行（1ヶ月）

旧システムとの並行運用
段階的な切り替え
運用マニュアル整備

参考リソース

技術ドキュメント

在庫管理の参考事例

プロジェクトステータス: 2025年内移行予定（現在計画・準備段階） 最終更新: 2025-01-15 応用可能性: 中小EC事業者向けモデルケースとして発展予定

EC-CUBEからNext.js + Supabaseへ
AIと進める、わが家のECリニューアル記

Technologies Used

はじめに
安心して使えるECへ

プロジェクト概要

背景と現状

なぜ移行するのか

技術的アプローチ（計画）

1) 衝突を減らすための"段階的ロック"

2) リアルタイム在庫同期

3) 集中アクセスを前提にした設計

4) UIのやさしさ（特に40〜60代を意識）

AIとの付き合い方（私のルール）

AI活用で変わったこと（実感）

具体的な活用方法

AI協働開発の3原則

いま大事にしているKPI（目安）

具体的な目標値

データ移行の課題

会員データ（2,658名）の移行戦略

管理ダッシュボード（最優先機能）

実装アプローチ: React Admin

必要なレポート機能

コスト目標

想定コスト構成

まとめ
「責任の所在」をはっきりさせる設計へ

このプロジェクトが証明するスキル

同じ悩みを持つEC事業者へ

これから

📅 移行スケジュール（2025年内予定）

参考リソース

技術ドキュメント

在庫管理の参考事例

Challenges Overcome

Key Learnings

Technologies Used

はじめに 安心して使えるECへ

プロジェクト概要

背景と現状

なぜ移行するのか

技術的アプローチ（計画）

1) 衝突を減らすための"段階的ロック"

2) リアルタイム在庫同期

3) 集中アクセスを前提にした設計

4) UIのやさしさ（特に40〜60代を意識）

AIとの付き合い方（私のルール）

AI活用で変わったこと（実感）

具体的な活用方法

AI協働開発の3原則

いま大事にしているKPI（目安）

具体的な目標値

データ移行の課題

会員データ（2,658名）の移行戦略

管理ダッシュボード（最優先機能）

実装アプローチ: React Admin

必要なレポート機能

コスト目標

想定コスト構成

まとめ 「責任の所在」をはっきりさせる設計へ

このプロジェクトが証明するスキル

同じ悩みを持つEC事業者へ

これから

📅 移行スケジュール（2025年内予定）

参考リソース

技術ドキュメント

在庫管理の参考事例

Challenges Overcome

Key Learnings

はじめに
安心して使えるECへ

まとめ
「責任の所在」をはっきりさせる設計へ