CONTENT
ここから
第35章では、Next.jsでECサイトを作るときのディレクトリ構成を整理しました。
app、components、lib、types、schemas、actions、constants、testsを分けることで、保守しやすいECシステムを作れることを学びました。
この章では、実務でそのまま使えるチェックリストを整理します。
EC開発では、画面ができただけでは完成ではありません。
要件定義
Square設定
決済テスト
Webhook
セキュリティ
SEO
表示速度
管理画面
公開前確認
公開後運用
これらを確認して、初めて安心して本番公開できます。
攻略本風に言えば、第36章は「ラスボス前に装備・回復薬・地図を確認する最終準備ステージ」です。
36.1 要件定義チェックリスト
要件定義とは、何を作るのかを決める作業です。
EC開発では、最初にここを曖昧にすると、あとで大きな手戻りが発生します。
なんとなくECを作る
↓
途中で必要機能が増える
↓
設計が崩れる
↓
公開が遅れる
最初に確認する項目です。
□ 何を販売するか決まっている
□ 物販、サービス、チケット、予約販売のどれか整理できている
□ 商品数が分かっている
□ 商品カテゴリが決まっている
□ 単品販売、セット販売、ギフト販売の有無が決まっている
□ 在庫管理が必要か決まっている
□ 配送が必要か決まっている
□ 店頭受取や催事受取の有無が決まっている
□ 会員機能が必要か決まっている
□ ゲスト購入を許可するか決まっている
商品に関する確認です。
□ 商品名
□ 価格
□ 商品説明
□ 商品画像
□ 在庫数
□ 内容量
□ サイズ
□ 重量
□ 配送方法
□ 注意事項
食品ECの場合は、次も確認します。
□ 賞味期限
□ 保存方法
□ 配送温度帯
□ 原材料
□ アレルゲン情報
□ ギフト対応
□ のし対応
□ 納品書の扱い
工芸品・作品ECの場合は、次も確認します。
□ 一点ものか
□ 作家名
□ 制作年
□ 素材
□ サイズ
□ 技法
□ 売約済み表示の有無
□ 展示会連携の有無
□ 問い合わせ後決済の有無
要件定義で大切なのは、最初から全部作ろうとしないことです。
最初に必要：
購入できる
決済できる
注文管理できる
発送できる
後から追加：
会員機能
定期購入
クーポン
高度な分析
要件定義の合言葉です。
最初に作るものと、後で作るものを分ける。
36.2 Square設定チェックリスト
Square設定では、テスト環境と本番環境を分けて確認します。
Squareでは、SandboxとProductionを混ぜないことが重要です。
Sandbox：
テスト用
Production：
本番用
Squareアカウントの確認です。
□ Squareアカウントを作成している
□ 事業者情報を登録している
□ 本番利用に必要な情報を登録している
□ 入金先口座を登録している
□ 店舗情報を確認している
□ Location IDを確認している
Square Developer側の確認です。
□ Square Developer Dashboardにアクセスできる
□ アプリケーションを作成している
□ Sandbox Access Tokenを取得している
□ Production Access Tokenを取得している
□ Sandbox Location IDを確認している
□ Production Location IDを確認している
□ 必要な権限を確認している
環境変数の確認です。
□ SQUARE_ENVIRONMENTを設定している
□ SQUARE_ACCESS_TOKENを設定している
□ SQUARE_LOCATION_IDを設定している
□ SQUARE_WEBHOOK_SIGNATURE_KEYを設定している
□ Sandbox用とProduction用を分けている
□ Access Tokenをコードに直接書いていない
□ Access Tokenをブラウザ側に出していない
Webhook設定の確認です。
□ Sandbox用Webhook URLを設定している
□ Production用Webhook URLを設定している
□ 通知対象イベントを選択している
□ 署名キーを取得している
□ 本番URLがHTTPSになっている
Square設定でよくあるミスです。
□ 本番なのにSandbox Tokenを使っている
□ SandboxなのにProduction Tokenを使っている
□ Location IDが違う
□ Webhook URLが古い
□ 環境変数を設定した後に再デプロイしていない
Square設定の合言葉です。
Token、Location、Webhook URLを環境ごとにそろえる。
36.3 決済テストチェックリスト
決済テストでは、購入者が商品を選び、決済し、注文が正しく記録されるか確認します。
画面だけでなく、DB、Square、メール、管理画面まで見ます。
商品選択
↓
カート
↓
決済
↓
Webhook
↓
注文確定
↓
メール
↓
管理画面
正常系の確認です。
□ 商品詳細ページが表示される
□ カートに商品を追加できる
□ 数量を変更できる
□ カート小計が正しい
□ 送料が正しく計算される
□ 合計金額が正しい
□ 決済リンクを作成できる
□ Square決済画面へ遷移できる
□ 決済が成功する
□ 注文完了ページへ戻れる
DBの確認です。
□ 決済前に注文がpendingで作成される
□ 決済後に注文がpaidになる
□ 注文明細が正しく保存される
□ 購入時点の価格が保存される
□ Square Payment IDが保存される
□ Square Order IDが保存される
在庫の確認です。
□ 決済完了後に在庫が減る
□ 在庫が0の商品は購入できない
□ 同時購入で在庫がマイナスにならない
□ 在庫不足時はエラーまたは手動確認になる
メールの確認です。
□ 購入者へ注文完了メールが届く
□ 管理者へ新規注文通知が届く
□ メール本文の注文内容が正しい
□ メール本文の金額が正しい
□ 問い合わせ先が正しい
異常系の確認です。
□ 決済失敗時に注文がpaidにならない
□ 決済キャンセル時に注文がpendingのままになる
□ 決済リンク作成失敗時にエラー表示が出る
□ 金額不一致が起きた場合に止められる
□ 在庫不足時に決済へ進めない
本番決済テストの確認です。
□ 少額の本番テスト商品を用意している
□ 実際のカードで本番決済を試した
□ 本番Webhookが届いた
□ 本番メールが届いた
□ 本番管理画面に注文が表示された
□ テスト後にテスト商品を非公開にした
決済テストの合言葉です。
決済できた、だけで終わらない。
注文・在庫・メール・管理画面まで確認する。
36.4 Webhookチェックリスト
Webhookは、決済結果をSquareから受け取る重要な仕組みです。
ECでは、決済完了ページよりもWebhookを信頼します。
Squareで決済完了
↓
Webhook受信
↓
注文をpaidにする
Webhook受信の確認です。
□ Webhook受信用APIがある
□ URLがHTTPSで公開されている
□ Square側にWebhook URLを登録している
□ 必要なイベント種別を選択している
□ リクエストを受信できる
□ 2xxレスポンスを返している
署名検証の確認です。
□ Square Webhook署名キーを設定している
□ raw bodyを使って署名検証している
□ 署名が不正なリクエストを拒否している
□ 署名検証を本番でも有効にしている
イベント処理の確認です。
□ event_idを保存している
□ 同じevent_idは二重処理しない
□ イベント種別を確認している
□ 対象の注文を取得できる
□ 決済成功時にpaidへ更新している
□ 在庫を1回だけ減らしている
□ メールを1回だけ送っている
ログの確認です。
□ webhook_eventsテーブルがある
□ event_idを保存している
□ event_typeを保存している
□ 処理結果を保存している
□ エラー内容を保存している
□ 受信日時を保存している
異常系の確認です。
□ 対象注文が見つからない場合にmanual_reviewへ回せる
□ すでにpaidの注文を再処理しない
□ メール送信失敗で注文処理を巻き戻さない
□ 在庫更新失敗時に手動確認できる
□ Webhook未着のpending注文を抽出できる
Webhookの合言葉です。
Webhookは、同じ通知が来ても壊れないように作る。
36.5 セキュリティチェックリスト
ECでは、決済、個人情報、管理画面を扱います。
そのため、セキュリティ確認は必須です。
お金
個人情報
注文情報
管理者権限
秘密情報の確認です。
□ Access Tokenをコードに直接書いていない
□ APIキーをGitHubにpushしていない
□ 環境変数で管理している
□ NEXT_PUBLIC_に秘密情報を入れていない
□ ログにAccess Tokenを出していない
□ ログにWebhook署名キーを出していない
決済まわりの確認です。
□ カード情報を自社DBに保存していない
□ 決済処理はSquareに任せている
□ 金額はサーバー側で計算している
□ ブラウザから送られた金額を信用していない
□ 注文IDを推測しにくい形式にしている
管理画面の確認です。
□ 管理画面にログインが必要
□ 管理者以外はアクセスできない
□ 管理者ロールを確認している
□ 重要操作に確認ダイアログがある
□ 操作履歴を残している
個人情報の確認です。
□ 必要以上の個人情報を取得していない
□ 氏名、住所、電話番号の表示範囲を制限している
□ 管理者だけが注文者情報を見られる
□ 個人情報をGA4などに送っていない
□ 問い合わせ対応時に不要な情報を外部AIへ渡していない
入力値の確認です。
□ フォーム入力を検証している
□ API受信時にサーバー側で検証している
□ 数量が1以上か確認している
□ クーポンコードをサーバー側で検証している
□ 管理画面の更新値も検証している
セキュリティの合言葉です。
秘密情報は出さない。
重要判断はサーバーで行う。
管理画面は必ず守る。
36.6 SEOチェックリスト
SEOは、検索から商品ページやコラムへ来てもらうための準備です。
ECでは、商品ページ、カテゴリページ、ギフトページ、コラム記事が検索入口になります。
検索
↓
商品ページ
↓
購入
基本SEOの確認です。
□ 各ページにtitleが設定されている
□ 各ページにdescriptionが設定されている
□ 商品名が分かりやすい
□ h1が1ページに1つある
□ h2で内容が整理されている
□ 商品説明が薄すぎない
□ 画像にaltが設定されている
商品ページの確認です。
□ 商品名
□ 価格
□ 内容量
□ 商品説明
□ 使い方
□ 配送情報
□ FAQ
□ 関連商品
□ 関連記事
カテゴリページの確認です。
□ カテゴリ名が分かりやすい
□ カテゴリ説明がある
□ 商品一覧が表示されている
□ 並び順が自然
□ 関連カテゴリへリンクしている
構造化データの確認です。
□ 商品ページにProduct構造化データを入れている
□ パンくずリストを入れている
□ 価格や在庫情報が正しい
□ OGP画像を設定している
内部リンクの確認です。
□ トップページから主要商品へリンクしている
□ コラムから商品ページへリンクしている
□ 商品ページから関連商品へリンクしている
□ 商品ページからFAQへ誘導している
□ ギフトページから該当商品へリンクしている
Search Consoleの確認です。
□ Search Consoleに登録している
□ サイトマップを送信している
□ インデックス状況を確認している
□ 検索クエリを確認している
□ 表示回数、クリック数、CTRを確認している
SEOの合言葉です。
検索される言葉で入口を作り、商品ページへ自然につなげる。
36.7 表示速度チェックリスト
ECでは、表示速度が重要です。
ページが遅いと、購入前に離脱される可能性があります。
ページが遅い
↓
見る前に離脱
↓
商品が伝わらない
↓
売れない
ページ構成の確認です。
□ トップページが重すぎない
□ 商品一覧ページが重すぎない
□ 商品詳細ページが重すぎない
□ 不要なアニメーションを入れすぎていない
□ Client Componentを増やしすぎていない
画像の確認です。
□ 商品画像を最適化している
□ 必要以上に大きい画像を使っていない
□ Next.js Imageを活用している
□ ファーストビュー画像の読み込みを確認している
□ 使っていない画像を読み込んでいない
フォントの確認です。
□ フォントを読み込みすぎていない
□ 太さを増やしすぎていない
□ 外部フォントの読み込みを確認している
□ 表示がガタつかないようにしている
JavaScriptの確認です。
□ 不要なライブラリを入れていない
□ 使っていないコンポーネントを読み込んでいない
□ 商品ページを必要以上にClient Component化していない
□ 管理画面用の重い処理を購入者向けページに混ぜていない
キャッシュの確認です。
□ 静的化できるページは静的化している
□ 商品一覧のキャッシュ方針を決めている
□ 商品更新時の再検証方法を決めている
□ 動的処理が必要なページを分けている
Lighthouse確認です。
□ Performanceを確認している
□ Accessibilityを確認している
□ Best Practicesを確認している
□ SEOを確認している
□ 改善項目を記録している
表示速度の合言葉です。
見た目を盛る前に、まず速く表示する。
36.8 管理画面チェックリスト
管理画面は、店舗スタッフが毎日使う画面です。
購入者向けページがきれいでも、管理画面が使いにくいと運用で困ります。
注文を見る
在庫を見る
発送する
メールを確認する
ステータスを変える
認証の確認です。
□ 管理画面にログインが必要
□ 管理者以外は入れない
□ 権限チェックがサーバー側で行われている
□ ログアウトできる
□ 不正アクセス時に拒否される
注文管理の確認です。
□ 注文一覧が見られる
□ 注文詳細が見られる
□ 注文番号で検索できる
□ ステータスで絞り込める
□ 未発送注文を確認できる
□ manual_review注文を確認できる
□ 注文ステータスを変更できる
商品管理の確認です。
□ 商品を登録できる
□ 商品を編集できる
□ 商品を非公開にできる
□ 価格を変更できる
□ 商品画像を管理できる
□ カテゴリを変更できる
□ おすすめ表示を変更できる
在庫管理の確認です。
□ 在庫数を確認できる
□ 在庫数を変更できる
□ 在庫切れ商品を確認できる
□ 催事用在庫や店舗別在庫を確認できる
□ 在庫変更履歴を残せる
配送管理の確認です。
□ 配送ステータスを確認できる
□ 追跡番号を登録できる
□ 発送済みに変更できる
□ 発送完了メールを送れる
□ 店頭受取や催事受取の注文を区別できる
誤操作防止の確認です。
□ キャンセル操作に確認がある
□ 発送済み変更に確認がある
□ 在庫変更に確認がある
□ 操作履歴を残している
□ 管理メモを残せる
管理画面の合言葉です。
管理画面は、店舗の司令室。
今日やるべきことが一目で分かるようにする。
36.9 公開前チェックリスト
公開前チェックは、本番公開直前の最終確認です。
ここで抜けがあると、公開直後にトラブルになります。
公開
↓
注文が入る
↓
設定ミスに気づく
これは避ける
ページ確認です。
□ トップページが表示される
□ 商品一覧ページが表示される
□ 商品詳細ページが表示される
□ カートページが表示される
□ 注文完了ページが表示される
□ FAQが表示される
□ 特定商取引法ページが表示される
□ プライバシーポリシーが表示される
□ 返品・キャンセルポリシーが表示される
本番設定確認です。
□ 本番環境変数を設定している
□ Square Production設定になっている
□ Production Access Tokenを使っている
□ Production Location IDを使っている
□ 本番Webhook URLを設定している
□ メール送信元を本番用にしている
□ 管理者通知メールが正しい
ドメイン確認です。
□ 独自ドメインが設定されている
□ HTTPSでアクセスできる
□ wwwありなしの扱いが決まっている
□ httpからhttpsへリダイレクトされる
□ OGP画像が本番URLで表示される
決済確認です。
□ 本番決済リンクが作成される
□ 少額決済テストが完了している
□ Webhookが本番環境で動いている
□ 注文がpaidになる
□ 在庫が減る
□ メールが届く
□ 管理画面で注文が見える
法務・表示確認です。
□ 価格が税込表示になっている
□ 送料が分かる
□ 配送目安が分かる
□ 返品条件が分かる
□ 事業者情報が正しい
□ 問い合わせ先が正しい
運用確認です。
□ 誰が注文確認するか決まっている
□ 誰が発送するか決まっている
□ 誰が問い合わせ対応するか決まっている
□ 在庫更新の担当が決まっている
□ トラブル時の連絡先が決まっている
公開前の合言葉です。
公開してから確認するのではなく、確認してから公開する。
36.10 公開後運用チェックリスト
公開後は、ECサイトの運用が始まります。
公開したら終わりではありません。
むしろ、公開後からが本番です。
注文
問い合わせ
在庫
発送
エラー
売上
改善
毎日確認する項目です。
□ 新規注文があるか
□ 未発送注文があるか
□ 決済失敗があるか
□ manual_review注文があるか
□ 問い合わせが来ているか
□ 在庫切れ商品があるか
□ メール送信失敗があるか
□ Webhookエラーがあるか
週次で確認する項目です。
□ 売上
□ 注文数
□ 平均注文単価
□ 商品別売上
□ 人気商品
□ 在庫不足商品
□ カート離脱
□ 問い合わせ内容
□ クーポン利用状況
月次で確認する項目です。
□ 月間売上
□ 利益
□ リピート購入数
□ 新規購入者数
□ SEO流入
□ Search Consoleの検索クエリ
□ GA4の購入導線
□ キャンペーン効果
□ 改善施策の結果
トラブル対応の確認です。
□ 決済済みなのにpaidにならない注文を確認できる
□ 在庫不足時の対応ルールがある
□ メール送信失敗時の再送方法がある
□ 返金が必要な場合の手順がある
□ キャンセル対応の手順がある
□ 管理者へエラー通知される
改善運用の確認です。
□ 商品ページを改善している
□ FAQを追加している
□ レシピやコラムを追加している
□ 売れ筋商品をトップに出している
□ 離脱ポイントを確認している
□ クーポンやキャンペーンを検証している
公開後に大切なのは、例外を放置しないことです。
pendingのままの注文
manual_reviewの注文
メール送信失敗
Webhookエラー
在庫ズレ
これらを毎日確認します。
公開後運用の合言葉です。
ECは公開して終わりではなく、数字と注文を見ながら育てる。
第36章のまとめ
この章では、EC開発と運用で使える実務用チェックリストを整理しました。
要件定義、Square設定、決済テスト、Webhook、セキュリティ、SEO、表示速度、管理画面、公開前、公開後運用まで確認することで、トラブルを減らせます。
この章で覚えておきたいポイントは、次の通りです。
1. 要件定義では、最初に作るものと後で作るものを分ける
2. Square設定では、SandboxとProductionを混ぜない
3. 決済テストでは、注文、在庫、メール、管理画面まで確認する
4. Webhookでは、署名検証と重複処理対策を行う
5. セキュリティでは、秘密情報、個人情報、管理画面を守る
6. SEOでは、商品ページ、カテゴリ、コラム、内部リンクを整える
7. 表示速度では、画像、フォント、JavaScript、キャッシュを確認する
8. 管理画面では、店舗スタッフが今日やるべきことを見える化する
9. 公開前には、本番決済、独自ドメイン、法務ページ、運用担当を確認する
10. 公開後は、注文、在庫、エラー、売上、改善を継続して見る
実務用チェックリストの基本は、次の一言にまとめられます。
EC公開は、勢いではなく確認で成功させる。
ひとつずつ確認する。
記録する。
問題があれば直す。
この地道な作業が、安心して売れるECシステムを作ります。