トレカ EC と業務システム
TorecaSpace の段階的構築

本書は、トレーディングカード EC と業務システム「TorecaSpace」の本実装に向け、株式会社ダイバーがご提供する設計方針・段階的リリース計画・初期構築スコープをまとめたご提案書です。

Phase 0 (モック検証) では、顧客 / スタッフ / マネージャー の 3 ロールそれぞれに専用の Next.js プロトタイプを並走させ、業務オペレーションと UI 体験の温度感を実機で確認しました。この合意のうえに、Phase 1 (EC 開店) を本実装で立ち上げ、その先のフェーズに無理なく接続できる基盤を組み立てます。

顧客 EC開く →

スタッフ UI開く →

マネージャー UI開く →

トレカ EC 市場では、多くのカードショップが「おちゃのこネット」に代表される汎用 ASP（Application Service Provider）を利用しています。初期コストの低さが採用理由として挙げられますが、事業の成長とともにその限界が顕在化してきます。

既存 ASP の課題

• デザインの画一性テンプレートベースのため、ブランド表現に限界があり、カード業界内での差別化が困難です。どの店も同じ見た目になりがちで、顧客からの信頼感・プレミアム感の醸成が難しい状況です。
• トレカ特有機能の欠如個体管理・買取申込・オリパ販売といった、トレカショップ固有の業務フローへの対応が事実上不可能です。無理に対応しようとすると手作業が増え、スタッフの負担が増大します。
• 月額費用と手数料の積み上がり売上規模が拡大するほど決済手数料（3.5〜5%/件）やオプション費用が重くなり、長期的にはコスト競争力を失います。年商規模が大きくなるほどこの差は顕著です。
• 拡張性の限界多店舗展開・在庫の多拠点管理・スタッフ向け業務 UI など、成長に必要な機能をスクラッチで追加することができません。

おちゃのこネットでは実現できない要件

おちゃのこネットは仕入れた商品を並べて売るだけの EC には機能しますが、「ユーザーから買い取る → 査定する → 値付けする → 出品する」というフローは ASP の設計思想の外にあります。

自社 EC 構築で得られるもの

• ブランド価値の確立顧客 EC・スタッフ UI・マネージャー画面がすべて一貫したデザイン体験となり、競合 ASP との明確な差別化が実現します。
• 業務フローとの完全整合買取・個体管理・オリパ販売など、貴社のオペレーションに合わせた機能を段階的に実装できます。現場のフローをシステムに合わせるのではなく、システムを現場に合わせます。
• スタッフ管理の標準化スタッフ UI 上でタスクとステータスが明示されるため、「次に何をすべきか」がシステムから自動的に提示されます。マネージャーはシステム上で承認・確認・指示を完結でき、口頭指示や属人的な業務進行から脱却できます。配送・連絡フローはメルカリに近い操作感で設計されているため、現場への浸透も容易です。
• 将来的なライセンス展開同様の課題を抱えるカードショップに本システムを提供するビジネスモデルも視野に入ります。業界標準となる EC プラットフォームとして展開することで、開発投資の回収を加速できます。
• オリパ導入への最短経路オリパは高付加価値商品として業界注目度が高まっています。個体管理基盤を先行整備する本提案の設計は、オリパ受注拡大のための最短ルートです。

主要アプローチ

• ドメイン型の一元管理Zod 4 で定義した @torecaspace/domain を正典とし、フロント / バック / バリデーションで型と実行時検証を完全共有。
• マルチファイル Prisma スキーマPrisma 7 (prisma-client generator) を core / catalog / inventory / order / buyback / work-order に分割。@namespace タグで ER 図と仕様書を自動生成。
• 3 アプリ並走の monorepo顧客 EC / スタッフ作業 UI / マネージャー ダッシュボード を独立した Next.js 16 アプリとして配信。ロール別に最適化された UX と、共通ドメインの両立。
• 静的エクスポート + エッジ配信Cloudflare Pages による静的配信で初期表示を最適化。API 層は段階的に追加し、初期コストを抑制。
• 個体管理を見据えたスキーマ先回りPhase 1 から OrderLine 構造・locationId フィールド等を先に組み込み、Phase 2 への移行時にスキーマを壊さない。

技術スタックの概要

フロントエンドは Next.js 16 (App Router / Turbopack) + React 19 + Tailwind v4 + shadcn/ui (@base-ui/react) を採用し、3 アプリ共通のデザインシステムを @torecaspace/domain のラベル / 並び順 / enum と組み合わせて運用します。バックエンドは Prisma 7 + MariaDB (mysql provider) を中心に、Phase 1 で @prisma/adapter-mariadb 経由で実 DB 接続を行います。CI / CD と監視は Phase 1 後半で整備予定です。

モノレポ構成

pnpm 10 workspace + Turborepo 2 によりルートから pnpm typecheck / pnpm build / pnpm lint を全パッケージに横断適用。prisma generate は postinstall で自動実行し、ER 図 (docs/api/er-diagram.md) も同時に更新されるため、スキーマと仕様書の乖離が発生しません。

事業の成長に合わせて、6 つのフェーズに分割してリリースします。各フェーズは独立した価値を提供しつつ、次のフェーズへの依存関係を明確にしています。

Phase 1 (EC 開店) で本実装に切り替える対象を、3 ロール別に整理します。Phase 2 以降に送る項目は明示的に除外し、移行時にスキーマを壊さない先回り設計のみ含めます。

顧客 EC (mock-ui → 本実装)

• 商品閲覧 / カート / チェックアウト149 商品のモックを本実装に置換。検索・絞り込みは基本機能のみ Phase 1 でリリース。
• マイページ注文履歴・配送状況・買取申込履歴。
• 買取申込受付・写真アップロード・査定金額提示まで。

スタッフ作業 UI (staff-ui → 本実装)

• 発送タスクSKU レベルでの発送管理。個体 ID の導入は Phase 2。
• 買取受付 / 出品 / 問合せ4 タスクフローを本実装に接続。WorkOrder + 親エンティティの denormalized view で運用。

マネージャー UI (manager-ui → 本実装)

• ダッシュボード売上 / 注文 / 買取 / スタッフ生産性 / 顧客 LTV の集計。
• CSV ファースト各タブで CSV ダウンロード対応 (要望確定済み)。

バックエンド

• 認証基盤顧客 / スタッフ / マネージャーの 3 ロール。
• 決済代行連携Stripe / Square / SBPS のいずれか (要相談)。
• 配送連携ヤマト B2 / ネコポス。API 連携が困難な場合は CSV 運用を初期は許容。
• メール通知注文確認・発送通知。

Phase 0（要件定義・UI 設計・DB 設計・モック）を受注前に先行実施済みのため、通常の受託開発より大幅に低コストでの実現が可能です。

通常の受託開発との費用比較

※ 相場値は一般社団法人 日本情報システム・ユーザー協会（JUAS）実績単価（スクラッチ 96万円/人月・全体回帰値 127万円/人月）× 典型工数から試算。出典・詳細は付録 Aをご参照ください。ASP / SaaS との月額コスト比較は付録 Bに記載しています。

まずカード販売 EC として稼働させ、手応えを確認してから買取査定機能を追加することも可能です。2 段階の構成をご用意しています。

Phase 1a — EC 販売（カード販売・スタッフ管理）

Phase 1b — 買取査定機能（追加オプション）

Phase 1a リリース後に追加発注も可能です。郵送買取の「申込 → 査定 → 承認 → 値付け → 出品」フローを実装します。

※ 価格設定の根拠・業界相場との比較は付録 Aをご参照ください。

Phase 2 以降の概算規模

※ Phase 2 以降の金額は現時点での参考値です。各フェーズ開始前に改めて詳細見積もりをご提示します。

お支払いスケジュール（Phase 1a 基本）

Phase 1a 費用 ¥7,000,000（税抜）は、以下のマイルストーンに分割してのご請求を予定しています。Phase 1b を追加発注する場合は別途ご契約となります。

※ 各回のご請求は該当マイルストーン到達後に請求書を発行します。お支払い期限は請求書発行日より 30 日以内です。

Phase 0 で UI・ドメイン型・DB スキーマが確定しているため、通常の受託開発で 3〜6 ヶ月を要する要件定義・基本設計フェーズをほぼ省略できます。一般的な受託開発では本規模のシステムに 12〜18 ヶ月かかるところ、Phase 0 完了を起点に開店まで約 5 ヶ月を目指します。

※ 決済代行・配送会社の審査期間（通常 2〜4 週間）は Month 1 と並行して進めることで、全体日程への影響を最小化します。

• 商品データ・画像の提供商品マスタ・価格情報・商品画像等はご依頼者様よりご提供いただきます。データ形式は別途ご相談のうえ確定します。
• 外部サービスとの契約決済代行会社（Stripe / Square / SBPS 等）、配送会社（ヤマト運輸等）との契約・審査対応はご依頼者様にてお願いします。
• ドメイン・インフラ費用ドメイン取得・更新費用、Cloudflare Pages / R2 等のインフラ費用は本見積もりに含まれません。利用状況に応じた実費が別途発生します（通常月数千円〜数万円程度）。
• 無償保証期間本番リリース後 3 ヶ月間（Month 5〜8 の運用支援期間）は、仕様書どおりの動作に関するバグの修正および軽微な仕様調整を無償で対応します。保証期間終了後の対応は別途お見積もりをご提示します。
• 著作権・知的財産権の帰属本開発で作成したソースコードおよび設計資料の著作権は、最終お支払い完了をもって貴社（発注者）に帰属します。ただし、本システムを第三者に販売・配布・貸与する場合は事前に書面にてご相談ください。
• 仕様変更・機能追加への対応要件定義確定後の仕様変更および機能追加は、内容に応じて別途お見積もりのうえ追加費用が発生します。変更が発生する際は実施前に書面にてご合意いただきます。
• 守秘義務本提案書の内容および開発過程で取得した貴社情報は、厳重に管理し第三者へ開示いたしません。
• 見積もりの有効期限本見積もりの有効期限は提出日より 30 日間です。

本提案の内容についてご不明な点やご相談がございましたら、contact@diver.jp までお気軽にご連絡ください。モック検証で固めた業務イメージを、無理なく本番運用に接続できるよう全力でサポートいたします。

業界実績の人月単価（JUAS 調査）

§06 の費用比較（通常受託 ¥1,300〜3,200万 vs 本提案 ¥700〜880万）はこの JUAS 実績単価（96〜127万円/人月）× 典型工数から算出しています。

ソフトウェア開発費用は「人月単価 × 工数」で算出されます。一般社団法人 日本情報システム・ユーザー協会（JUAS）が実績プロジェクトデータから報告した人月単価は以下のとおりです。

投資回収の試算

EC 経由の売上が年商の 30%（約 3.6 億円）と仮定した場合のコスト比較です。決済代行の選択は費用構造に直接影響するため、PG 選定時の比較検討を推奨します。

※ Stripe Japan 標準料率 3.6%（出典: stripe.com/jp/pricing）、GMO ペイメントゲートウェイは 3% 前後を目安に個別交渉が可能（個別見積もり）。おちゃのこネット決済手数料は SBペイメントサービス / ゼウス等の外部代行を経由するため 3.5〜5%（出典: おちゃのこネット公式サイト）。削減効果は現在の契約料率と選択 PG の組み合わせにより異なります。コスト削減以上の価値（独自機能・データ活用・他店展開）については下記をご参照ください。

他店舗への展開シナリオ

Phase 1 完成後、同システムを他のカードショップに提供するライセンス型ビジネスを展開した場合の参考値です。

※ ライセンス単価は 1 店舗あたり 150〜300 万円/年を想定した参考値です。実際の価格は交渉により変動します。