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、銀行振込は後回しで構いません。

最大の選択は支払いフローです：

• ホスト型チェックアウトは通常最速で安全です。プロバイダがセンシティブなUIの多くを扱ってくれます。
• 埋め込みカードフォームは見た目が良くてもエッジケースやセキュリティ対応が増えます。

決済は一目でわかる少数の状態にします：created, paid, failed, canceled, refunded。

照合やサポートに必要な情報だけを保存してください：プロバイダの支払いID、オプションでプロバイダの顧客/セッションID、金額、通貨、内部注文ID。生のカードデータは絶対に保存しないでください。

Webhookは注文を信頼できるものにします。チェックアウト後にブラウザのリダイレクトだけを「支払い済み」とみなさないでください。イベントを検証するWebhookハンドラを作り、対応する注文を有料にマークします。

再配信に耐える安全設計にしてください。Webhookは何度も届くことがあるので、ハンドラは冪等であるべきです：注文が既に有料なら何もしないで成功を返す。

Koder.aiのようなチャット駆動のビルダーで素早く作る場合は、まず決済状態と最小フィールドを定義し、その後Webhookエンドポイントと注文更新ロジックを生成してください。これで「支払い済みの顧客に対して注文は未処理」のような古典的な混乱を防げます。

7日間のデイリープラン

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つのレコードでほとんどをカバーできます：

• Product: id, title, price, currency, active
• Customer: id, email, name（任意）
• Order: id, customer_id（またはemail）、配送先フィールド、status、合計のスナップショット、created_at
• OrderItem: order_id, product_id, title_snapshot, unit_price_snapshot, quantity
• Payment: order_id, provider, provider_payment_id, amount, currency, status, raw_event_id

配送先は最小限にしてください。通常は名前、住所行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や顧客メールで検索しやすくし、次を表示します：

• 顧客名、メール、配送先
• アイテム、数量、最終合計（送料・税含む）
• 決済ステータス（paid, failed, refunded）
• フルフィルメントステータス（new, packed, shipped）
• タイムスタンプと短い内部メモ

ステータス操作は「Mark packed」「Mark shipped」の2ボタンに絞ります。発送済みにするときに追跡情報（配送業者＋追跡コード、または「店頭受け取り」など）を保存できるようにします。自動メールは遅くなるなら後回しにして構いません。

CSVエクスポートはオプション。週内で使うと分かっているなら追加してください。

Koder.aiのようなビルドツールを使うなら管理画面は同じアプリに置き、保護されたルートでセッション必須にします。

ステップバイステップ：最初の成功した支払いを作る

まずはテストモードで始めます。目標は「チェックアウトページ」ではなく、支払いが完了し、記録され、発送準備ができた注文を1つ作ることです。

重要ルール：生のカード情報はサーバに保存しない。ホスト型チェックアウトかクライアント側トークン化を使い、機微なデータは直接プロバイダへ送るようにします。

最初の有料注文までの流れ

1. サーバでテスト商品と価格を作る。 チェックアウトはブラウザではなくDBから価格を取得すること。
2. テストモードでチェックアウトセッションを開始する。 バックエンドが支払いセッションを作り、クライアントにリダイレクトに必要な情報だけ返す。
3. ダブルクリック対策。 支払ボタンは最初のクリックで無効にする。サーバ側で冪等キー（例：カートID＋短い時間窓）を使い、重複は同じセッションを返すようにする。
4. サーバで支払いを検証する。 プロバイダのWebhookを一次情報源として扱い、イベントが実在し期待金額と通貨に一致することを確認してから注文を有料にする。
5. 失敗経路もテストする。 支払い失敗、チェックアウトキャンセル、セッション期限切れを試し、それぞれが不明瞭な状態にならないことを確認する。

エラーを直しやすくする

支払いエラーは対応可能なコンテキストとともにログに残します：注文ID、セッションID、顧客メール（あれば）、期待合計、プロバイダのエラーコード、短いメッセージ（例：「金額不一致」や「Webhook署名無効」）。

例：顧客がマグカップ2個を買おうとしてサーバは$24＋送料でセッションを作り注文を保留にする。顧客がページを閉じたら注文はキャンセル、支払えばWebhookでpaidに切り替わり自信を持って発送できます。

MVP週で実際に使える安全なデプロイワークフロー

1週間しかないとき、デプロイが静かにチェックアウトを壊すことがあります。目標は派手なDevOpsではなく、驚きを減らし逃げ道を用意する再現可能な手順です。

ステージングと本番の2環境を用意します。ステージングは本番にできるだけ近づけ、同じ設定・テンプレート・税送料ルールで支払いだけテストモードにします。ステージングで最終確認をし、同じビルドを本番に昇格します。

リリースにはバージョンを付けます。v1, v2といったタグを付け、前のバージョンをすぐ戻せる状態にしておきます。ロールバックはワンアクションで戻せるように：ビルドを切り替えるかスナップショットを復元します。プラットフォームがスナップショットとロールバックをサポートしているなら（Koder.aiなど）、本番前に必ずスナップショットを撮る習慣をつけてください。

DBマイグレーションはMVP週ではリスクが高いので注意。後方互換の変更を優先：新しいテーブルや列を追加し、名前変更や削除は避け、新しいリリースが安定するまで旧コードパスを残します。データのバックフィルはリクエスト内で行わず別ジョブで処理します。

秘密情報はリポジトリに入れないでください。APIキー、Webhook署名秘密、DB URL、管理者パスワードは環境変数やシークレットマネージャに入れます。

リリースチェックリスト：

• ステージングでテストカードとWebhookでチェックアウトがエンドツーエンドで動くことを確認
• ステージングでマイグレーションを走らせ、その後本番で同様に実行して注文作成が動くことを確認
• メール（注文確認、支払い失敗）が送られ見た目が正しいことを確認
• プレリリースのスナップショットを取り、リリースバージョンを記録
• 2人でチェック：1人が出し、もう1人がリストを確認

7日間MVPを遅らせるよくある罠

早く作る目標を逃す最速の方法は、収益の流れを壊す「きれい」な機能を作ることです。目的は支払いを受け、信頼できる注文を作り、発送できるストアを作ることです。

よくあるミスはブラウザ側に最終的な価格を任せること。クライアントで合計や割引、送料を計算すると必ず誰かが間違った金額を払います。サーバを単一の真実の源にして、product IDと数量から注文を再構築してから支払いを作るようにします。

送料と税のルールも時間を食います。すべての国や例外をサポートしようとして数日失うチームが多いです。週目は一つの簡単なルールに絞ってください。

チェックアウトで「動く」けど運用で失敗するもう一つの落とし穴はWebhookを省くことです。顧客は支払ったのにDBが有料にしておらず発送が止まることがあります。Webhook処理は必須です。

気をつけるべき5つの罠：

• クライアント側の合計を信頼してサーバで再計算しない
• 需要がないのに複雑な送料税テーブルを先に作る
• リダイレクトだけに頼りWebhookを使わない
• 明確な注文確認メッセージやメールを忘れる
• ロールバック方法なしで直接本番にデプロイする

例：顧客が支払いを完了してタブを閉じた場合、Webhookがなければ顧客は失敗したと思い再度支払い、二重請求が発生する可能性があります。

Koder.aiを使う場合はスナップショットとロールバックを運用に組み込み、小さな変更を出して既知の良いバージョンを保持し、何か壊れたらすぐ復旧できるようにしてください。

本番決済を有効にする前の簡単チェック

まずステージングで以下を確認し、本番で切り替える直前に同じチェックを繰り返します。目標はシンプル：お客様が一度だけ支払いを行い、あなたが一度だけ記録して発送できること。

購入者の流れから始めます。商品をカートに入れ、チェックアウトを完了し、明確な成功ページに到達することを確認。管理画面で正しい合計の有料注文が見えることを確認します。

次にWebhookを遅延や再試行を含めて厳しくテストします。Webhookは遅れて来たり、2回来たり、順序が入れ替わったりします。注文更新ロジックは冪等で、再試行で二重の有料注文が作られないことを確認してください。

プレローンチチェックリスト：

• テスト注文をエンドツーエンドで行い、管理画面にトランザクション/支払いIDが保存されていることを確認
• 同じWebhookイベントを再送して重複が発生しないことを確認
• 商品を無効化して購入できなくなることを確認
• 管理画面で注文をステータス移動（new → paid → shipped）させて、内部メモを追加
• 小さな変更をデプロイして数分でロールバックでき、注文データを失わないことを確認

告知前に一度だけ本当に少額で自分で課金してみてください。実在のカードで少額、配送先は自分、注文が1件だけ正しく表示され、タイムスタンプとステータスが明確に残ることを確認します。

Koder.aiを使うならスナップショットでこれを練習：デプロイ→注文を置く→ロールバック→既存注文が正しく読み込まれることを確認。

例：今週発送できる小さなストアのシナリオ

小さなコーヒーロースターが豆12袋を売りたいとします。サブスクやレビュー、ロイヤルティは不要で、実際の決済を受けてきれいな注文を作れるストアが必要です。

Day 2までに、各商品に写真1枚、価格、短い説明（ローストレベル、テイスティングノート、袋のサイズ）があればカタログは十分です。オプションは最小限：商品ごとにサイズは1つ、送料は1つ（例：国内一律）にします。

Day 4までに、チェックアウトは一つの仕事をします：配送先を集め、カードで支払いを受け、ユーザーがスクリーンショットできる確認ページを表示すること。注文IDと短い要約（商品、合計、配送先）を出しておけば、サポート対応が楽になります。

Day 5には管理画面は意図的に簡素のまま。ロースターはサインインして新規注文を見て、paid→packed→shippedと移動します。追跡は後回しで構いません。週目は「ラベルを印刷して3:10に発送済み」といった内部メモで十分なことがよくあります。

このスコープはKoder.aiのようなチャットファーストビルダとも相性が良いです：画面が少なく、テーブルも少なく、ワークフローが明確です。

Week 2で待つ価値があるもの：割引コード、検索改善、在庫カウント、自動化メール。実際の注文が何を求めているかを見てから一つずつ追加してください。

MVP公開後の次のステップ

最初の週は学習スプリントです。実際の注文を処理して、最大の摩擦点を取り除いていきます。

小さなパイロットを始めましょう：友人や同僚、小さなメッセージ可能なオーディエンスから10件の有料注文を目標にします。各人にどこで躊躇したかを聞き、離脱を簡単なシートで追跡します：商品ページ → カート → チェックアウト開始 → 支払い成功。

パイロット後は一度に一つだけ変更を加えます。初期の改善は通常シンプルなもの：送料の明確化、商品写真の改善、チェックアウト項目の削減。メモから次の最大の阻害要因を選んで直し、また小さなバッチで試します。

カスタマーサポートも何が足りないかを素早く教えてくれます。よく来る問いには短い定型文を用意しておくと良い：注文はどこ？キャンセルできる？支払いが失敗した理由は？送料はいくらでいつ届く？住所を変更できる？

チェックアウトを壊さずに素早く反復したいなら、Koder.aiで次バージョンをチャットから生成し、スナップショットとロールバックを使って本番に影響を与えずにテストするのがおすすめです。