あるくとまる — 固定費ゼロで動く越境ECサイト
約30商品を世界に向けて販売する小規模EC。Cloudflare + Stripe のみで構成し、サーバの月額固定費をかけずに運用しています。
- 担当範囲
- 設計・開発・運用（フルスタック）
- 期間
- 開発・運用中
- 技術スタック
- Astro (静的生成) React + Tailwind CSS Hono / Cloudflare Workers Cloudflare D1 + R2 d1zzle Better Auth Stripe Storyblok (Headless CMS)
- 固定費ゼロのスタック構成（Cloudflare の従量課金 + Stripe の決済手数料のみ）
- 店舗フロントは Astro の静的生成。商品ページは完成済みHTMLで配信
- 決済後の副作用処理をリース獲得＋再開可能な冪等ステップとして設計
- 設計判断を ADR として記録し、却下した案とその理由まで残す
何を解決するプロダクトか
商品数が数十点の小さなショップにとって、月額数万円の EC プラットフォーム利用料は 売上に対して重すぎます。あるくとまるは、Cloudflare の従量課金と Stripe の 決済手数料以外に固定費がかからない構成で、世界中からの注文を受けられる 自社 EC を実現したプロジェクトです。
構成
pnpm workspaces + Turborepo のモノレポで、3 つのアプリに分かれています。
| アプリ | 内容 |
|---|---|
apps/web | 公開ストアフロント。Astro（静的）+ React + Tailwind |
apps/admin | 商品管理 SPA。Vite + React、Cloudflare Access で保護 |
apps/api | Hono の REST API。Cloudflare Workers 上で D1 / R2 を扱う |
API は REST で、フロントからは Hono の型付き RPC クライアント（hc<AppType>）
経由で呼び出します。ルートのハンドラをメソッドチェーンで書いている限り、
API の型がそのままフロントの型になり、エンドポイントの変更はビルド時に検出されます。
商品画像は R2、ブログや読み物などの編集コンテンツのみ Storyblok（ヘッドレス CMS）で 管理し、商品データそのものは CMS に置かない切り分けにしています。
決済後の処理をどう壊さないか
EC で最も壊れてはいけないのは「支払いは通ったのに、その後の処理が落ちた」状態です。 このプロジェクトでは Stripe の Webhook 起点の副作用をリース獲得方式で処理し、 各ステップが自分専用の永続マーカーを持つ冪等な単位になっています。途中で失敗しても、 再実行すれば残りのステップだけが進みます。
こうした判断は ADR（Architecture Decision Record）として docs/decisions/ に残し、
採用した案だけでなく 却下した案とその理由 まで書いています。半年後の自分と
AI エージェントの両方が、同じ問いを二度検討せずに済むようにするためです。