Next.js Eコマース実践：カートと Stripe 決済の完全実装ガイド

午前3時、私は画面上のエラーログを見つめながら、Stripe Webhook の設定を27回目のチェックをしていました。ユーザーから「お金は引かれたのに、注文ステータスが『支払い待ち』のままだ」というクレームが入ったのです。私は混乱しました——テスト環境では完璧に動いていたのに、なぜリリースした途端に失敗するのか？

正直なところ、初めて Next.js でEコマースプロジェクトを作ったとき、一番難しいのはインターフェース構築やスタイル作成だと思っていました。しかし実際に手を動かしてみると、ショッピングカートの状態管理、決済連携、注文フロー、すべての段階に落とし穴があることに気づきました。Redux は重すぎて学ぶ気が起きないし、Context API はパフォーマンスが悪いし、Stripe のドキュメントは英語ばかりで頭が痛いし、Webhook に至っては意味不明でした。

最も挫折感を味わったのは、ネット上のチュートリアルが「カートだけ」か「決済だけ」しか扱っておらず、全体のフローをつなげて説明してくれるものがほとんどなかったことです。「結局どの状態管理ライブラリを選べばいいの？」「Webhook って何に使うの？」「注文ステータスと決済ステータスをどうやって合わせるの？」

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

この記事では、これらの落とし穴を一度に埋めたいと思います。Zustand でカートの状態を管理し（軽量で使いやすい）、Stripe で決済を連携し（国際的な主流）、Webhook で注文を処理します（唯一の信頼できる方法）。各ステップには完全なコードがあり、コピペですぐに動かせます。

「やっと動いた！」という達成感を味わったことはありますか？ この記事に従えば、間違いなく味わえます。

なぜショッピングカートの管理に Zustand を選ぶのか？

2025年の状態管理選定：もう迷わない

正直に言うと、状態管理ライブラリの選択は本当に頭が痛いです。Redux のドキュメントは辞書のように分厚いし、Context API のパフォーマンス問題は検索すれば山ほど出てくるし、Zustand は新しすぎて使うのが怖い。私もこの3つの間で揺れ動いていましたが、あるデータを見て決心しました。

2021年以降、Zustand は最も急成長している React 状態管理ライブラリになりました。2025年までに、その設計思想——関数型、Hooks 重視、シンプルでエレガントな API——は証明されました。さらに重要なのは、学習曲線が非常に緩やかで、Redux のように大量の概念（action, reducer, dispatch, middleware…）を理解する必要がないことです。

では、どう選べばいいのでしょうか？ 図解します：

• 小規模プロジェクト（10ページ未満）：Context API で十分。複雑にしない。
• 中規模プロジェクト（10-50ページ）：Zustand。軽量で十分な機能。
• 大規模プロジェクト（50ページ以上、多人数開発）：Redux Toolkit。ツールチェーンが充実。

ショッピングカートのようなシナリオは、実は Zustand に非常に適しています。なぜなら、コンポーネント間での共有（商品リスト、カートアイコン、決済ページなど）が必要で、永続化（リロードしてもデータを失わない）が必要で、高性能（関連コンポーネントだけ更新し、全体を再レンダリングしない）である必要があるからです。これらすべてを Zustand は解決でき、コード量は Redux の半分以下です。

Zustand カート実践コード

理屈はこれくらいにして、コードを見てみましょう。まずは依存関係をインストール：

npm install zustand

そしてカートの Store を作成します（/store/cartStore.js）：

import { create } from 'zustand'
import { persist } from 'zustand/middleware'

export const useCartStore = create(
  persist(
    (set, get) => ({
      // 状態
      items: [], // [{ id, name, price, quantity, image }]

      // 計算プロパティ
      get total() {
        return get().items.reduce((sum, item) => sum + item.price * item.quantity, 0)
      },
      get count() {
        return get().items.reduce((sum, item) => sum + item.quantity, 0)
      },

      // メソッド
      addItem: (product) => set((state) => {
        const existing = state.items.find(item => item.id === product.id)
        if (existing) {
          // 既に存在する場合は数量+1
          return {
            items: state.items.map(item =>
              item.id === product.id
                ? { ...item, quantity: item.quantity + 1 }
                : item
            )
          }
        } else {
          // 新商品ならカートに追加
          return { items: [...state.items, { ...product, quantity: 1 }] }
        }
      }),

      removeItem: (productId) => set((state) => ({
        items: state.items.filter(item => item.id !== productId)
      })),

      updateQuantity: (productId, quantity) => set((state) => ({
        items: state.items.map(item =>
          item.id === productId ? { ...item, quantity } : item
        )
      })),

      clearCart: () => set({ items: [] })
    }),
    {
      name: 'shopping-cart', // localStorage の key
    }
  )
)

コードは長く見えますが、ロジックは単純です。items 配列に商品を保存し、total と count は計算され（合計金額と総数量）、いくつかのメソッドで追加・削除・更新を処理します。persist ミドルウェアが自動的にデータを localStorage に保存するので、ページをリロードしてもデータは消えません。

コンポーネントでの使い方も超簡単です：

import { useCartStore } from '@/store/cartStore'

function ProductCard({ product }) {
  const addItem = useCartStore(state => state.addItem)

  return (
    <button onClick={() => addItem(product)}>
      カートに追加
    </button>
  )
}

function CartIcon() {
  const count = useCartStore(state => state.count)

  return <div>カート ({count})</div>
}

注目してください。useCartStore(state => state.addItem) という書き方はセレクターです。これは addItem メソッドだけを購読し、他のカートデータが変更されても再レンダリングされません。これが Zustand のパフォーマンスが良い秘密——正確な購読です。

ちなみに、以前 Redux の useSelector や useDispatch を使っていたなら、Zustand がどれだけシンプルかわかるでしょう。action type も reducer 関数も不要で、Store 内にメソッドを書くだけです。

「プロジェクトですでに Redux を使っているけど、Zustand に乗り換えるべき？」と聞かれるかもしれません。不要です。Redux Toolkit も実は非常に優秀で、オープンソースのEコマースプロジェクト C-Shopping などは Redux Toolkit + RTK Query を使用しており、データフローの追跡や安定性は抜群です。ただ、新規プロジェクトなら、学習コストが低く、すぐに成果が出せる Zustand を個人的にはお勧めします。

Stripe 決済統合の完全フロー

まず Stripe の決済フローを理解する

初めて Stripe のドキュメントを見たとき、頭の中は「？」だらけでした。Checkout Session って何？ Payment Intent って？ なぜ Stripe のページに飛ぶの？ 自社サイトで決済完了できないの？

今振り返ると、フローは非常に明確です：

1. フロントエンド：ユーザーが「支払う」をクリックし、API を呼び出して Checkout Session を作成する
2. バックエンド：Session を作成し、session.id を返す
3. フロントエンド：session.id を受け取り、Stripe.js を使って Stripe 托管の決済ページへ遷移する
4. ユーザー：Stripe ページでカード情報を入力し、支払いを完了する
5. Stripe：決済成功後、Webhook でバックエンドに通知を送る
6. バックエンド：Webhook を受信し、注文作成、在庫減算、メール送信を行う
7. Stripe：ユーザーをあなたのサイト（success_url）にリダイレクトする

重要な点：絶対にフロントエンドで決済成功ロジックを処理しないこと。なぜなら、ユーザーは支払いを終えた後に「完了」ボタンを押さずにブラウザを閉じるかもしれないし、ネットワークが切れるかもしれないし、意図的にリダイレクトを回避してタダ乗りしようとするかもしれないからです。唯一の信頼できる方法は Webhook です。これについては後で詳しく説明します。

Stripe Checkout Session の作成

ます依存関係をインストール：

npm install stripe @stripe/stripe-js

次に環境変数を設定（.env.local）：

STRIPE_SECRET_KEY=sk_test_xxxxx  # バックエンド用、絶対に漏洩させてはいけない
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_xxxxx  # フロントエンド用
STRIPE_WEBHOOK_SECRET=whsec_xxxxx  # Webhook 署名検証用

API ルートを作成（/pages/api/create-checkout.js）：

import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)

export default async function handler(req, res) {
  if (req.method !== 'POST') {
    return res.status(405).json({ error: 'Method not allowed' })
  }

  try {
    const { items } = req.body // カートデータ

    // line_items を作成（Stripe の要求フォーマット）
    const lineItems = items.map(item => ({
      price_data: {
        currency: 'usd',
        product_data: {
          name: item.name,
          images: [item.image],
        },
        unit_amount: Math.round(item.price * 100), // Stripe は「セント」単位
      },
      quantity: item.quantity,
    }))

    // Checkout Session 作成
    const session = await stripe.checkout.sessions.create({
      payment_method_types: ['card'],
      line_items: lineItems,
      mode: 'payment', // 一回払い（サブスクなら 'subscription'）
      success_url: `${req.headers.origin}/success?session_id={CHECKOUT_SESSION_ID}`,
      cancel_url: `${req.headers.origin}/cart`,
      metadata: {
        // カスタムデータを保存、後で Webhook で取得可能
        userId: req.user?.id || 'guest',
      },
    })

    res.status(200).json({ sessionId: session.id })
  } catch (err) {
    console.error('Checkout Session 作成失敗:', err)
    res.status(500).json({ error: err.message })
  }
}

いくつかの詳細に注意してください：

• unit_amount は100倍する必要があります。Stripe は**セント（分）**単位だからです（99.99ドル = 9999セント）。
• success_url 内の {CHECKOUT_SESSION_ID} はプレースホルダーで、Stripe が自動的に実際の session_id に置換します。
• metadata には独自のデータ（ユーザーID、注文メモなど）を保存でき、Webhook で取得できます。

フロントエンドでの Checkout 呼び出し

決済ページ（/pages/checkout.js）：

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

import { loadStripe } from '@stripe/stripe-js'
import { useCartStore } from '@/store/cartStore'

const stripePromise = loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY)

export default function CheckoutPage() {
  const { items, total } = useCartStore()

  const handleCheckout = async () => {
    try {
      // バックエンド API を呼び出して Session 作成
      const response = await fetch('/api/create-checkout', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ items }),
      })

      const { sessionId } = await response.json()

      // Stripe 決済ページへ遷移
      const stripe = await stripePromise
      const { error } = await stripe.redirectToCheckout({ sessionId })

      if (error) {
        console.error('決済ページへの遷移失敗:', error)
        alert(error.message)
      }
    } catch (err) {
      console.error('支払い開始失敗:', err)
      alert('支払いに失敗しました。後でもう一度お試しください')
    }
  }

  return (
    <div>
      <h1>決済</h1>
      {items.map(item => (
        <div key={item.id}>
          {item.name} x {item.quantity} = ${item.price * item.quantity}
        </div>
      ))}
      <div>合計: ${total}</div>
      <button onClick={handleCheckout}>支払う</button>
    </div>
  )
}

「支払う」をクリックすると、ユーザーは Stripe がホストする決済ページにリダイレクトされます。このページは Stripe がやってくれるので、フォーム作成やクレジットカード検証、不正検知などの面倒な作業を自分でする必要がありません。

「決済ページのデザインをカスタマイズできる？」とよく聞かれますが、可能です。カラー、ロゴ、フォントなどはカスタマイズできますが、レイアウトは固定です。もし UI を完全に制御したいなら、Stripe Elements（フロントエンド埋め込み決済フォーム）を使えますが、複雑度は跳ね上がるので初心者にはお勧めしません。

決済成功後のリダイレクト

ユーザーが支払いを完了すると、Stripe は設定した success_url にリダイレクトします。このページで注文詳細を表示できます：

// /pages/success.js
import { useEffect, useState } from 'react'
import { useRouter } from 'next/router'

export default function SuccessPage() {
  const router = useRouter()
  const { session_id } = router.query
  const [order, setOrder] = useState(null)

  useEffect(() => {
    if (session_id) {
      // バックエンドから注文情報を取得
      fetch(`/api/order?session_id=${session_id}`)
        .then(res => res.json())
        .then(data => setOrder(data))
    }
  }, [session_id])

  if (!order) return <div>読み込み中...</div>

  return (
    <div>
      <h1>支払い成功！</h1>
      <p>注文番号: {order.id}</p>
      <p>金額: ${order.total}</p>
    </div>
  )
}

しかし覚えておいてください。このページは表示用であり、実際の注文作成は Webhook で行う必要があります。次に Webhook のやり方について話しましょう。

Webhook による注文処理と状態同期

なぜ Webhook が重要なのか？

初めて決済機能を実装した時、ユーザーが success ページに戻ってきたら支払い成功とみなして、そこに注文ロジックを書いていました。しかしテスト中に、支払いを終えたユーザーがブラウザを閉じてしまい、注文が作成されず、返金されたかどうかもわからないという事態が発生し、パニックになりました。

後に Stripe の公式ドキュメントを見て理解しました：Webhook は唯一の信頼できる注文処理方法です。なぜなら：

• ユーザーのリダイレクトは信頼できない：ブラウザを閉じる、ネットワーク切断、完了ボタンを押さない等、様々な状況が起こり得る
• セキュリティ要件：注文作成、在庫減算、発送などの機密操作はバックエンドで行う必要があり、フロントエンドに制御させてはいけない
• Stripe 公式推奨：すべての重要なビジネスロジックは Webhook に置くべき

Webhook とは何でしょうか？ 簡単に言えば、Stripe のサーバーがあなたのサーバーを能動的に呼び出し、「おい、支払いが成功したぞ」とか「サブスクリプションがキャンセルされたぞ」と教えてくれる仕組みです。通知を受け取ったら、それに応じた処理を行います。

Webhook エンドポイントの作成

Next.js で /pages/api/stripe-webhook.js を作成します：

import Stripe from 'stripe'
import { buffer } from 'micro'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET

// 重要設定：Next.js のデフォルト body 解析を無効化
export const config = {
  api: {
    bodyParser: false,
  },
}

export default async function handler(req, res) {
  if (req.method !== 'POST') {
    return res.status(405).send('Method not allowed')
  }

  const buf = await buffer(req)
  const sig = req.headers['stripe-signature']

  let event

  try {
    // Webhook 署名を検証（超重要！）
    event = stripe.webhooks.constructEvent(buf, sig, webhookSecret)
  } catch (err) {
    console.error('Webhook 署名検証失敗:', err.message)
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  // イベントタイプごとに処理
  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutSessionCompleted(event.data.object)
      break
    case 'payment_intent.succeeded':
      await handlePaymentIntentSucceeded(event.data.object)
      break
    case 'invoice.payment_failed':
      await handleInvoicePaymentFailed(event.data.object)
      break
    default:
      console.log(`未処理のイベントタイプ: ${event.type}`)
  }

  res.status(200).json({ received: true })
}

async function handleCheckoutSessionCompleted(session) {
  console.log('支払い成功!', session.id)

  // カートデータを取得（metadata または session.id でクエリ）
  const userId = session.metadata.userId
  const sessionId = session.id
  const total = session.amount_total / 100 // ドルに戻す

  // 注文が既に存在するか確認（冪等性保証）
  const existingOrder = await db.order.findUnique({
    where: { stripeSessionId: sessionId }
  })

  if (existingOrder) {
    console.log('注文は既に存在します、スキップ')
    return
  }

  // 注文作成
  const order = await db.order.create({
    data: {
      userId,
      stripeSessionId: sessionId,
      status: 'paid',
      total,
      // ... その他のフィールド
    }
  })

  // 在庫減算
  await updateInventory(order.items)

  // 確認メール送信
  await sendOrderConfirmationEmail(userId, order)

  console.log('注文作成成功:', order.id)
}

async function handlePaymentIntentSucceeded(paymentIntent) {
  // 支払い着金確認
  console.log('支払い確認:', paymentIntent.id)
}

async function handleInvoicePaymentFailed(invoice) {
  // サブスク支払い失敗処理
  console.log('支払い失敗:', invoice.id)
  // リマインダーメール送信、サービス停止など
}

いくつかの重要ポイント：

1. bodyParser の無効化必須：Stripe は署名検証に生のリスエストボディ（raw body）を必要とします。Next.js が body を事前に解析してしまうと、署名検証に失敗します。
2. 署名検証必須：stripe.webhooks.constructEvent() はリクエストが確かに Stripe から来たことを検証し、悪意ある第三者の偽造リクエストを防ぎます。
3. 冪等性（Idempotency）処理：Stripe は Webhook を重複して送る可能性があります（ネットワーク問題、リトライメカニズム）。あなたのコードは重複呼び出しを処理できなければなりません。stripeSessionId を一意なインデックスとして使えば、同じ支払いで複数の注文が作られるのを防げます。

Webhook のローカルテスト

Stripe はあなたの localhost を直接呼び出せないので、ローカル開発には Stripe CLI を使う必要があります。まずは CLI をインストール：

# Mac
brew install stripe/stripe-cli/stripe

# Windows (Scoop 使用)
scoop install stripe

# または公式サイトからダウンロード
# https://stripe.com/docs/stripe-cli

ログインして Webhook をリッスン：

stripe login
stripe listen --forward-to localhost:3000/api/stripe-webhook

CLI は一時的な webhook secret（whsec_xxxxx みたいなの）を表示するので、それを .env.local にコピーします：

STRIPE_WEBHOOK_SECRET=whsec_xxxxx

そして別のターミナルでテストイベントをトリガーします：

stripe trigger checkout.session.completed

CLI と Next.js のコンソールにログが表示されれば、Webhook が受信できたことになります。これで注文作成ロジックをデバッグできます。

私はここで長いことハマりました。ずっと署名検証エラーが出ていたんです。後に Next.js の bodyParser をオフにし忘れていたせいだとわかりました。export const config を忘れずに追加してください！

注文ステータス管理

注文ステータスの遷移は大体こんな感じです：

支払い待ち → 支払い済み → 準備中 → 発送済み → 完了
             ↓
           キャンセル/返金済み

データベースには enum でステータスを保存します：

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

// schema.prisma
model Order {
  id               String   @id @default(cuid())
  stripeSessionId  String   @unique  // 冪等性保証
  userId           String
  status           OrderStatus @default(PENDING)
  total            Float
  createdAt        DateTime @default(now())
  updatedAt        DateTime @updatedAt
}

enum OrderStatus {
  PENDING      // 支払い待ち
  PAID         // 支払い済み
  PREPARING    // 準備中
  SHIPPED      // 発送済み
  COMPLETED    // 完了
  CANCELLED    // キャンセル
  REFUNDED     // 返金済み
}

Webhook が checkout.session.completed を受信したら、ステータスを PAID にします。その後の発送や完了ステータスは、バックオフィスシステムから手動または自動で更新します。

エラー処理

Webhook は失敗する可能性があります（DB接続断、サードパーティサービスダウンなど）。Stripe にはリトライ機能がありますが、失敗ログは記録しておくべきです：

async function handleCheckoutSessionCompleted(session) {
  try {
    // ビジネスロジック
  } catch (error) {
    console.error('注文処理失敗:', error)
    // ログシステム（Sentry, LogRocket 等）に記録
    await logError({
      type: 'webhook_error',
      event: 'checkout.session.completed',
      sessionId: session.id,
      error: error.message,
    })
    throw error // エラーを投げて Stripe に失敗を知らせ、自動リトライさせる
  }
}

Webhook が失敗したら？ Stripe は3日間自動リトライします。その間、Stripe Dashboard で失敗した Webhook を確認し、手動で再送することもできます。

完全な注文フロー実践

ここまでで、すべてのパーツが揃いました。これらをつなげて、完全な注文フローがどう動くか見てみましょう。

ユーザー注文の完全パス

1. 商品ページ：ユーザーが「カートに追加」をクリック、Zustand Store 更新、カートアイコンの数字+1
2. カートページ：ユーザーがカートを確認、数量調整、「決済へ進む」をクリック
3. 決済ページ：注文概要を表示、「支払う」ボタンをクリック
4. フロントエンド：/api/create-checkout を呼び出し、カートデータを送信
5. バックエンド：Stripe Session を作成、sessionId を返す
6. フロントエンド：Stripe 托管決済ページへリダイレクト
7. ユーザー：カード情報を入力、「Pay」をクリック
8. Stripe：支払いを処理し、成功すると Webhook を /api/stripe-webhook に送信
9. バックエンド Webhook：署名検証 → 注文作成 → 在庫減算 → メール送信
10. Stripe：ユーザーを /success?session_id=xxx にリダイレクト
11. フロントエンド：success ページが /api/order?session_id=xxx を呼び出し、注文詳細を表示

プロセスは複雑に見えますが、各ステップは明確です。重要なのは、ステップ9が Webhook 内で完了しなければならず、ステップ11に依存してはいけないということです。

データベース設計のポイント

model Order {
  id               String      @id @default(cuid())
  stripeSessionId  String      @unique  // 冪等性
  userId           String
  status           OrderStatus @default(PENDING)
  total            Float
  items            OrderItem[]
  createdAt        DateTime    @default(now())
  updatedAt        DateTime    @updatedAt

  user User @relation(fields: [userId], references: [id])
}

model OrderItem {
  id        String @id @default(cuid())
  orderId   String
  productId String
  quantity  Int
  price     Float  // 注文時の価格。後の値上げが影響しないように
  // ...
  order   Order   @relation(fields: [orderId], references: [id])
  product Product @relation(fields: [productId], references: [id])
}

OrderItem の price フィールドに注目してください。ここには Product の現在の価格ではなく、注文時の価格を保存します。これにより、後で商品が値上げされても、過去の注文記録は当時の価格のままになります。

エッジケースの処理

1. 在庫不足の場合は？

Checkout Session 作成前にチェックします：

// /pages/api/create-checkout.js
const { items } = req.body

// 在庫チェック
for (const item of items) {
  const product = await db.product.findUnique({ where: { id: item.id } })
  if (product.stock < item.quantity) {
    return res.status(400).json({ error: `${product.name} の在庫が不足しています` })
  }
}

// 在庫十分、Session 作成へ...

2. 支払いは成功したが Webhook が失敗した？

Stripe は3日間自動リトライします。Stripe Dashboard で手動再送も可能です。あるいは、「支払い成功だが注文未作成」の Session を定期チェックして補完するバッチ処理を書くのも手です。

3. 支払い済みだが発送前に在庫切れ？

発送前に再度在庫チェックします。在庫がなければ、ユーザーに連絡して返金か交換を行います。

本番環境デプロイの注意点

テスト環境で動いたからといって、そのまま本番に出してはいけません。いくつか注意すべき落とし穴があります。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

環境変数設定

本番環境のキーはテスト環境とは異なります。混同しないように：

# .env.production
STRIPE_SECRET_KEY=sk_live_xxxxx  # live であることに注意
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_xxxxx
STRIPE_WEBHOOK_SECRET=whsec_xxxxx  # 本番環境の Webhook Secret

Vercel 等にデプロイする際、環境変数を設定してください。Secret Key を Git にコミットしてはいけません。

Webhook エンドポイント設定

テスト環境では Stripe CLI 転送を使っていましたが、本番環境では Stripe Dashboard で手動設定が必要です：

1. Stripe Dashboard にログイン
2. “Developers” → “Webhooks” へ移動
3. “Add endpoint” をクリック
4. 本番環境の URL を入力：https://yourdomain.com/api/stripe-webhook
5. リッスンするイベントを選択：checkout.session.completed、payment_intent.succeeded 等
6. 保存後、Signing secret（whsec_xxxxx）をコピーし、環境変数に設定

私は初デプロイでこれを忘れ、リリース後に注文が作成されず、原因究明に多大な時間を費やしました。

セキュリティチェックリスト

デプロイ前にこのリストを確認してください：

• ✅ すべての支払いロジックはバックエンドで行う（フロントエンドは遷移のみ）
• ✅ Webhook 署名を検証する（stripe.webhooks.constructEvent）
• ✅ 支払い金額と注文金額が一致するか検証する（フロントエンドでの価格改ざん防止）
• ✅ 冪等性を実装する（stripeSessionId 一意インデックス）
• ✅ 支払い関連ログを記録する（Sentry, Datadog 等）
• ✅ 異常アラートを設定する（Webhook 失敗率、決済成功率）

3番目は特に重要です。Session 作成時にバックエンドで価格設定していても、念のため Webhook でも再検証し、誰かがフロントエンドをバイパスして Stripe API を直接叩くのを防ぐべきです（確率は低いですが、安全第一です）。

監視とアラート

本番環境には監視システムを導入しましょう：

// /pages/api/stripe-webhook.js
import * as Sentry from '@sentry/nextjs'

export default async function handler(req, res) {
  try {
    // ... Webhook ロジック
  } catch (error) {
    Sentry.captureException(error, {
      tags: {
        type: 'stripe_webhook',
        event: event.type,
      },
    })
    throw error
  }
}

監視指標の推奨：

• Webhook 失敗率（>5% でアラート）
• 決済成功率（急激な低下は Stripe のダウンや設定ミスを疑う）
• 注文作成時間（>3秒なら原因調査）

まとめ：ゼロからリリースへの道のり

長くなりましたが、重要なステップを振り返ります：

1. カート状態管理：Zustand（軽量）か Redux Toolkit（大規模）を選び、persist 中間件で永続化
2. 決済統合：Stripe Checkout Session を作成し、托管ページへ遷移させ、フォーム検証の手間を省く
3. 注文処理：Webhook で注文作成、在庫減算、メール送信を行い、信頼性を保証
4. 本番デプロイ：環境変数設定、Webhook エンドポイント設定、監視アラート導入

3つの核心原則を忘れないでください：

• 決済ロジックは必ずバックエンドで：フロントエンドは信用できない
• Webhook は唯一の信頼できる情報源：ユーザーリダイレクトは信用できない
• セキュリティは最優先：署名検証、リプレイ攻撃防止、ログ記録

初めて Eコマース決済を実装するなら、まず Stripe テスト環境で全フローを通すことをお勧めします。テストカード番号 4242 4242 4242 4242（有効期限と CVV は適当でOK）を使えます。テスト環境で問題なければ、本番環境へ切り替えましょう。

最後に、いくつかの参考資料をお勧めします：

• Stripe 公式ドキュメント：https://stripe.com/docs（英語ですが非常に詳細です）
• Next.js + Stripe 完全チュートリアル：Pedro Alonso の 2025 年ガイド（“Stripe Next.js 15 complete guide” で検索）
• オープンソースプロジェクト：C-Shopping Eコマースプラットフォーム（Redux Toolkit + Stripe を使用）

この記事があなたの落とし穴を減らす助けになれば幸いです。注文が自動的に作成され、在庫が正しく引かれ、ユーザーに確認メールが届くのを初めて見たとき、その達成感は格別です。頑張ってください！

8 min read · 公開日: 2026年1月7日 · 更新日: 2026年1月22日

Easton

技術開発