2025年11月01日·1 分
7日で作るEC MVP：実際の決済で小さなストアを公開する
7日で作るECのMVP：カタログ、チェックアウト、実際の決済、基本管理画面、そして安全なリリースを日別プランで実装する方法。
7日で作るECのMVP：カタログ、チェックアウト、実際の決済、基本管理画面、そして安全なリリースを日別プランで実装する方法。
1週間で完成するECのMVPにとって、「実際の決済」が意味するのは一つだけです：顧客が支払いでき、あなたが注文を確認して推測せずに発送できること。
最初のバージョンは狭く絞ってください：1つの国、1つの通貨、1つの支払い方法（通常はカード）。すべてをサポートしようとすると、1週間が例外処理で潰れてしまい販売に集中できません。
最短ルートは、お金の流れとフルフィルメントの起点だけを扱う小さなストアです：
「完了」は完璧なショッピング体験ではありません。注文を受け、課金に成功し、収集した情報で同じ日に発送できることが「完了」です。これを10件連続で手動修正なしにこなせれば、動くMVPです。
その目標を守るために、最初から範囲外のものを決めておきましょう。ウィッシュリスト、レビュー、高度な検索、複雑な在庫ルール、クーポン、複数の支払い方法、複数通貨といった機能は今週支払いを受けるためには不要です。
まずは一つのデバイスをターゲットにしてください。ほとんどの購入者がSNS広告経由ならモバイルファーストのウェブ、法人向けならデスクトップ優先で問題ありません。どちらでもまずは一つの画面サイズ向けにデザインしてから調整します。
Koder.aiのようなチャットベースのツールで作る場合は、画面やフローを生成する前にスコープを書き出してください。厳格なスコープが「あとひとつだけ」の機能追加が日数オーバーになるのを止める最も簡単な方法です。
ECのMVPが「実際の」ものになるのは、見知らぬ人が商品を見つけて支払いができ、あなたがやり取りなしに発送できるときです。
まずは商品から。必要なのはタイトル、価格、メイン画像1枚、短い説明、そして公開/非公開のスイッチだけです。バリアントやバンドル、複雑な価格設定は後回しにしましょう。
カタログはシンプルで構いません：商品一覧ページと商品詳細ページ。カテゴリや在庫フィルタなどの基本的な絞りはOKですが、週目にフル検索エンジンを作るのは避けてください。
カートとチェックアウトは退屈で予測可能であるべきです。カートは追加、削除、数量変更をサポートし、明確な小計を表示すること。送料と税は最初は一つの簡単なルール（例えば一律送料、税は必要な場合のみ）を選びます。
最小のエンドツーエンドの流れは通常：
管理画面はMVPが失敗しがちな場所です。チャートは不要です。必要なのはロックされたログイン、商品追加/編集、注文一覧でステータスを変えられること（new, paid, shipped, refunded）です。
例：キャンドルを3種類売る。各商品に写真1枚と価格1つ。購入者が2つをカートに入れ、一律$5の送料を見て住所を入力し支払い、あなたはラベルを印刷して発送済みにマークする。
Koder.aiのようなvibe-codingプラットフォームを使う場合はプロンプトを厳格に：「これらのページだけ、これらのフィールドだけ、アカウントなし、クーポンなし、ウィッシュリストなし」。
決済は創意工夫を避ける場所です。すばやく導入できるプロバイダを一つ選び、カード決済のみを最初に実装してください。デジタルウォレットやBNPL、銀行振込は後回しで構いません。
最大の選択は支払いフローです：
決済は一目でわかる少数の状態にします：created, paid, failed, canceled, refunded。
照合やサポートに必要な情報だけを保存してください：プロバイダの支払いID、オプションでプロバイダの顧客/セッションID、金額、通貨、内部注文ID。生のカードデータは絶対に保存しないでください。
Webhookは注文を信頼できるものにします。チェックアウト後にブラウザのリダイレクトだけを「支払い済み」とみなさないでください。イベントを検証するWebhookハンドラを作り、対応する注文を有料にマークします。
再配信に耐える安全設計にしてください。Webhookは何度も届くことがあるので、ハンドラは冪等であるべきです：注文が既に有料なら何もしないで成功を返す。
Koder.aiのようなチャット駆動のビルダーで素早く作る場合は、まず決済状態と最小フィールドを定義し、その後Webhookエンドポイントと注文更新ロジックを生成してください。これで「支払い済みの顧客に対して注文は未処理」のような古典的な混乱を防げます。
Day 1: lock the scope. 1ページの仕様を書いてください：購入者が何をできるか、管理者が何をできるか、範囲外は何か。支払いプロバイダを選び、合計の計算方法（税/送料は今やるか後回しか）を決めます。カタログ、商品ページ、カート、チェックアウト、支払い結果の5つの画面をスケッチします。
Day 2: ship the catalog. 商品は必要最小限のフィールドだけ保存します：名前、価格、通貨、写真、短い説明、公開フラグ。「すべての商品」ページ（または簡単なカテゴリ）と商品詳細ページを作り、テスト用に約10件の商品を投入してフローを検証します。
Day 3: cart and order drafts. 追加/削除/数量変更を実装します。チェックアウト開始時に注文ドラフトを作り、後で商品編集で過去の注文が変わらないように価格をスナップショットします。顧客のメールと配送先は早めにキャプチャします。
Day 4: payments in test mode. チェックアウトと決済作成をつなぎます。成功、キャンセル、失敗を扱い、注文に決済ステータスを保存します。注文番号と次の手順を明確に示す確認ページを表示します。
Day 5: basic admin for fulfillment. 管理は小さくします：商品作成/編集/無効化、注文一覧とステータス更新（paid, packed, shipped, refunded）、発送に必要な情報を表示する注文詳細ページ。
Day 6: deployment and safety. ステージングと本番環境を用意し、ログを有効にしてテストカードでフローを通します。ロールバック計画を書いておきます。
Day 7: go live (small, controlled). 実際の少額購入で最終確認を行い、メール/領収書を確認してから小さなオーディエンスに公開します。Koder.aiを使う場合は主要な変更の前にスナップショットを撮ってすぐ戻せるようにしてください。
1週間で作るストアは注文の明瞭さにかかっています。誰かが支払ったら：何を買ったか、どこへ発送するか、今の状態は何かをすぐに答えられる必要があります。
最小で退屈なデータモデルを使ってください。以下の5つのレコードでほとんどをカバーできます：
配送先は最小限にしてください。通常は名前、住所行1、市区町村、郵便番号、国があれば十分です。電話はキャリアが要求する場合のみ必須にします。
合計は購入時にスナップショットとして記録します。Productテーブルから後で再計算しないでください。価格は変わり、送料ルールも変わるため「顧客はXを支払ったのに注文はYになっている」といった不整合が起きます。
ステータスは支払いプロバイダ用語ではなくフルフィルメントに合わせて分かりやすく：new, paid, packed, shipped, canceled。返金は本当に対応する場合のみ追加します。
決済更新の冪等性を計画してください。Webhookは重複や順序入れ替わりで届くことがあります。プロバイダの一意なイベントIDを保存し、重複は無視する設計にします。
例：Webhookが「succeeded」を2回送ってきても、システムは二重の出荷や二重メールを行わないようにします。もしGoバックエンドとPostgreSQLでKoder.ai上に作るなら、(provider, raw_event_id)にユニーク制約をかけ、ステータス更新をトランザクションで行うだけで十分なことが多いです。
管理画面は「ダッシュボード」ではなく、裏で次の3つの質問に素早く答える場所です：何が売られているか、何が支払われたか、何を発送するか。
最初は単一の管理ログインで十分です。ロールは1つで足ります。強力なパスワード、基本的なレート制限、短めのセッションタイムアウトを設定します。スタッフ管理や権限は今週はスキップ。もし誰かに手伝ってもらうなら、意図的にアクセスを共有して後でパスワードを回す運用で問題ありません。
商品管理はシンプルに：作成/編集、メイン画像1枚アップロード、価格設定、公開トグル。在庫数を厳密に管理できないなら在庫有無スイッチで過販売を防ぎます。
注文ビューは送り状のように読みやすく。注文IDや顧客メールで検索しやすくし、次を表示します：
ステータス操作は「Mark packed」「Mark shipped」の2ボタンに絞ります。発送済みにするときに追跡情報（配送業者＋追跡コード、または「店頭受け取り」など）を保存できるようにします。自動メールは遅くなるなら後回しにして構いません。
CSVエクスポートはオプション。週内で使うと分かっているなら追加してください。
Koder.aiのようなビルドツールを使うなら管理画面は同じアプリに置き、保護されたルートでセッション必須にします。
まずはテストモードで始めます。目標は「チェックアウトページ」ではなく、支払いが完了し、記録され、発送準備ができた注文を1つ作ることです。
重要ルール：生のカード情報はサーバに保存しない。ホスト型チェックアウトかクライアント側トークン化を使い、機微なデータは直接プロバイダへ送るようにします。
支払いエラーは対応可能なコンテキストとともにログに残します：注文ID、セッションID、顧客メール（あれば）、期待合計、プロバイダのエラーコード、短いメッセージ（例：「金額不一致」や「Webhook署名無効」）。
例：顧客がマグカップ2個を買おうとしてサーバは$24＋送料でセッションを作り注文を保留にする。顧客がページを閉じたら注文はキャンセル、支払えばWebhookでpaidに切り替わり自信を持って発送できます。
1週間しかないとき、デプロイが静かにチェックアウトを壊すことがあります。目標は派手なDevOpsではなく、驚きを減らし逃げ道を用意する再現可能な手順です。
ステージングと本番の2環境を用意します。ステージングは本番にできるだけ近づけ、同じ設定・テンプレート・税送料ルールで支払いだけテストモードにします。ステージングで最終確認をし、同じビルドを本番に昇格します。
リリースにはバージョンを付けます。v1, v2といったタグを付け、前のバージョンをすぐ戻せる状態にしておきます。ロールバックはワンアクションで戻せるように：ビルドを切り替えるかスナップショットを復元します。プラットフォームがスナップショットとロールバックをサポートしているなら（Koder.aiなど）、本番前に必ずスナップショットを撮る習慣をつけてください。
DBマイグレーションはMVP週ではリスクが高いので注意。後方互換の変更を優先：新しいテーブルや列を追加し、名前変更や削除は避け、新しいリリースが安定するまで旧コードパスを残します。データのバックフィルはリクエスト内で行わず別ジョブで処理します。
秘密情報はリポジトリに入れないでください。APIキー、Webhook署名秘密、DB URL、管理者パスワードは環境変数やシークレットマネージャに入れます。
リリースチェックリスト：
早く作る目標を逃す最速の方法は、収益の流れを壊す「きれい」な機能を作ることです。目的は支払いを受け、信頼できる注文を作り、発送できるストアを作ることです。
よくあるミスはブラウザ側に最終的な価格を任せること。クライアントで合計や割引、送料を計算すると必ず誰かが間違った金額を払います。サーバを単一の真実の源にして、product IDと数量から注文を再構築してから支払いを作るようにします。
送料と税のルールも時間を食います。すべての国や例外をサポートしようとして数日失うチームが多いです。週目は一つの簡単なルールに絞ってください。
チェックアウトで「動く」けど運用で失敗するもう一つの落とし穴はWebhookを省くことです。顧客は支払ったのにDBが有料にしておらず発送が止まることがあります。Webhook処理は必須です。
気をつけるべき5つの罠：
例：顧客が支払いを完了してタブを閉じた場合、Webhookがなければ顧客は失敗したと思い再度支払い、二重請求が発生する可能性があります。
Koder.aiを使う場合はスナップショットとロールバックを運用に組み込み、小さな変更を出して既知の良いバージョンを保持し、何か壊れたらすぐ復旧できるようにしてください。
まずステージングで以下を確認し、本番で切り替える直前に同じチェックを繰り返します。目標はシンプル：お客様が一度だけ支払いを行い、あなたが一度だけ記録して発送できること。
購入者の流れから始めます。商品をカートに入れ、チェックアウトを完了し、明確な成功ページに到達することを確認。管理画面で正しい合計の有料注文が見えることを確認します。
次にWebhookを遅延や再試行を含めて厳しくテストします。Webhookは遅れて来たり、2回来たり、順序が入れ替わったりします。注文更新ロジックは冪等で、再試行で二重の有料注文が作られないことを確認してください。
プレローンチチェックリスト：
告知前に一度だけ本当に少額で自分で課金してみてください。実在のカードで少額、配送先は自分、注文が1件だけ正しく表示され、タイムスタンプとステータスが明確に残ることを確認します。
Koder.aiを使うならスナップショットでこれを練習：デプロイ→注文を置く→ロールバック→既存注文が正しく読み込まれることを確認。
小さなコーヒーロースターが豆12袋を売りたいとします。サブスクやレビュー、ロイヤルティは不要で、実際の決済を受けてきれいな注文を作れるストアが必要です。
Day 2までに、各商品に写真1枚、価格、短い説明（ローストレベル、テイスティングノート、袋のサイズ）があればカタログは十分です。オプションは最小限：商品ごとにサイズは1つ、送料は1つ（例：国内一律）にします。
Day 4までに、チェックアウトは一つの仕事をします：配送先を集め、カードで支払いを受け、ユーザーがスクリーンショットできる確認ページを表示すること。注文IDと短い要約（商品、合計、配送先）を出しておけば、サポート対応が楽になります。
Day 5には管理画面は意図的に簡素のまま。ロースターはサインインして新規注文を見て、paid→packed→shippedと移動します。追跡は後回しで構いません。週目は「ラベルを印刷して3:10に発送済み」といった内部メモで十分なことがよくあります。
このスコープはKoder.aiのようなチャットファーストビルダとも相性が良いです：画面が少なく、テーブルも少なく、ワークフローが明確です。
Week 2で待つ価値があるもの：割引コード、検索改善、在庫カウント、自動化メール。実際の注文が何を求めているかを見てから一つずつ追加してください。
最初の週は学習スプリントです。実際の注文を処理して、最大の摩擦点を取り除いていきます。
小さなパイロットを始めましょう：友人や同僚、小さなメッセージ可能なオーディエンスから10件の有料注文を目標にします。各人にどこで躊躇したかを聞き、離脱を簡単なシートで追跡します：商品ページ → カート → チェックアウト開始 → 支払い成功。
パイロット後は一度に一つだけ変更を加えます。初期の改善は通常シンプルなもの：送料の明確化、商品写真の改善、チェックアウト項目の削減。メモから次の最大の阻害要因を選んで直し、また小さなバッチで試します。
カスタマーサポートも何が足りないかを素早く教えてくれます。よく来る問いには短い定型文を用意しておくと良い：注文はどこ？キャンセルできる？支払いが失敗した理由は？送料はいくらでいつ届く？住所を変更できる？
チェックアウトを壊さずに素早く反復したいなら、Koder.aiで次バージョンをチャットから生成し、スナップショットとロールバックを使って本番に影響を与えずにテストするのがおすすめです。
「実際の」MVPは、見知らぬ誰かが正常に支払いでき、あなたが正しい合計と配送先を含む有料注文を確認でき、そして集めた情報で同じ日に発送できることを意味します。
もし10件連続で手作業なしに処理できれば、実用的なMVPと言えます。
まずは一つの国、一つの通貨、一つの支払い方法（通常はカード）に絞ってください。送料や税も一つの簡単なルール（例：一律送料、税は不要）にするのが早道です。
スコープを小さく保てば、決まった流れ（商品→カート→チェックアウト→有料注文→発送）に集中できます。
最初に必要なページは：
アカウント、ウィッシュリスト、レビュー、クーポン、多通貨や複数支払い方法はスキップしてください。
7日間のMVPでは、ホスト型チェックアウトがデフォルトでおすすめです。導入が速く、センシティブなUIを提供者が扱ってくれるため安全です。
埋め込み型カードフォームは見た目は良いですが、エッジケースやセキュリティ対応が増えて手間がかかります。
リダイレクトはUX上は便利ですが信頼できません（タブを閉じる、通信切断など）。Webhookを事実の一次情報源として扱い、イベントを検証してから注文を有料にマークしてください。
Webhookが最終的な「支払い成功」の判定です。
冪等な（idempotent）Webhookハンドラを作ってください：
これで二重のメールや二重発送、支払い二重扱いを防げます。
購入時にスナップショットとして保存する項目：
後でProductテーブルから再計算すると、価格変更やルール差異で矛盾が生じます。購入時点の値を保存してください。
ステータスはシンプルで配送に即したものにします：
管理画面はダッシュボードではなく、裏方の作業場です。素早く答えを出せることだけを重視してください。
最小限の機能：
週目はチャートや複雑な役割管理は不要です。
安全で繰り返せる手順：
Koder.aiを使うなら本番前にスナップショットを撮る習慣を。
new, paid, packed, shipped, canceled（返金を本当に対応するなら refunded を追加）created, paid, failed, canceled, refunded一目で次に何をすべきか分かることが目的です。