CONTENT
ここから
第23章では、Square Sandboxを使った決済テスト、Webhookテスト、在庫切れテスト、同時購入テスト、管理画面テストを整理しました。
この章では、いよいよECサイトを本番公開します。
本番公開とは、実際のお客様がアクセスし、実際のお金が動き、実際の注文が発生する状態にすることです。
開発環境
↓
テスト環境
↓
本番環境
↓
実際の販売開始
本番公開で大切なのは、勢いで公開しないことです。
ECでは、公開直後から注文、決済、個人情報、配送対応が始まります。
そのため、公開前に必要な設定、法務ページ、決済テスト、運用確認を整えておきます。
24.1 本番Squareアカウントの準備
まず、本番用のSquareアカウントを準備します。
Sandboxはテスト用です。
本番販売では、Production環境を使います。
Sandbox：
テスト用。実際のお金は動かない
Production：
本番用。実際のお金が動く
本番公開前に確認するSquare側の項目は、次の通りです。
・Squareアカウントが本番利用できる状態か
・事業者情報が正しいか
・入金先口座が登録されているか
・店舗情報が正しいか
・Location IDを確認したか
・Production Access Tokenを取得したか
・Webhook URLを本番URLに設定したか
SquareのDeveloper Consoleでは、アプリケーションのCredentials画面からSandboxまたはProductionのAccess Tokenを取得できます。Production Access Tokenは本番APIを呼び出すための重要な認証情報です。(developer.squareup.com)
Location IDも重要です。
Location IDは、Square上の店舗や事業拠点を識別するIDです。
SquareのDeveloper Dashboardでは、Squareアカウントに作成されたLocationsを確認できます。Squareアカウント作成時に初期Locationが作られる仕組みです。(developer.squareup.com)
本番用に使う情報は、主に次の3つです。
SQUARE_ENVIRONMENT=production
SQUARE_ACCESS_TOKEN=本番用Token
SQUARE_LOCATION_ID=本番用Location ID
ここで最も危険なのは、SandboxとProductionを混ぜることです。
悪い例：
Production環境なのにSandbox Tokenを使う
SandboxでテストしているつもりがProduction Tokenを使う
本番Webhook URLにSandboxイベントを設定する
Square本番公開前の合言葉はこれです。
Sandboxは練習。
Productionは本番。
絶対に混ぜない。
24.2 本番環境変数の設定
次に、本番環境変数を設定します。
環境変数とは、APIキーやURLなど、アプリの外側から渡す設定値です。
本番ECでは、秘密情報をコードに直接書いてはいけません。
悪い例：
コード内にAccess Tokenを書く
よい例：
VercelのEnvironment Variablesに設定する
本番環境で必要になりやすい環境変数は、次の通りです。
NEXT_PUBLIC_APP_URL=
SQUARE_ENVIRONMENT=
SQUARE_ACCESS_TOKEN=
SQUARE_LOCATION_ID=
SQUARE_WEBHOOK_SIGNATURE_KEY=
DATABASE_URL=
RESEND_API_KEY=
MAIL_FROM=
ADMIN_NOTIFICATION_EMAIL=
ここで注意すべきなのは、NEXT_PUBLIC_の扱いです。
NEXT_PUBLIC_が付いた環境変数は、ブラウザ側に公開される可能性があります。
そのため、秘密情報には使いません。
公開してよい可能性がある：
NEXT_PUBLIC_APP_URL
公開してはいけない：
SQUARE_ACCESS_TOKEN
SQUARE_WEBHOOK_SIGNATURE_KEY
DATABASE_URL
RESEND_API_KEY
本番環境変数を設定するときは、次のように分けます。
Local Development：
ローカル開発用
Preview：
確認用
Production：
本番公開用
Vercelでは、Production、Preview、Developmentなど環境ごとにEnvironment Variablesを設定できます。
本番公開で使う値は、Productionに設定します。
Production Environment Variables：
本番決済用Token
本番DB
本番Webhook署名キー
本番メール送信設定
本番環境変数の設定後は、必ず再デプロイします。
環境変数を設定
↓
再デプロイ
↓
本番アプリに反映
環境変数は、ECの裏側の配線です。
配線を間違えると、表の画面が正しくても決済やメールが動きません。
24.3 Vercelへのデプロイ
Next.jsの本番公開では、Vercelを使う構成が分かりやすいです。
Vercelへデプロイすると、GitHubにpushしたコードをもとにアプリが公開されます。
基本の流れは、次の通りです。
GitHubにコードをpush
↓
Vercelがビルド
↓
本番環境へデプロイ
↓
URLでアクセスできる
デプロイ前に確認することは、次の通りです。
・ビルドエラーがない
・TypeScriptエラーがない
・環境変数が設定されている
・本番DBにつながる
・Square Production設定になっている
・Webhook URLが本番URLになっている
VercelのPreview環境も活用します。
Preview環境とは、本番公開前に変更内容を確認できる環境です。
Pull Request
↓
Preview URL
↓
画面確認
↓
問題なければProductionへ反映
いきなりProductionへ反映するより、Previewで確認してから公開する方が安全です。
本番デプロイ後は、次のページを確認します。
・トップページ
・商品一覧ページ
・商品詳細ページ
・カートページ
・注文完了ページ
・管理画面
・特定商取引法ページ
・プライバシーポリシー
・返品・キャンセルポリシー
デプロイは、ただコードを公開する作業ではありません。
ECの場合は、公開後に決済、Webhook、メール、管理画面まで確認します。
デプロイ成功
だけでは不十分
デプロイ後に購入フロー確認
まで必要
24.4 独自ドメイン設定
ECサイトでは、独自ドメインを設定します。
独自ドメインとは、次のようなURLです。
https://example.com
https://www.example.com
Vercelの初期URLでもサイトは公開できます。
しかし、本番ECでは独自ドメインを使う方が信頼されやすくなります。
Vercel初期URL：
example.vercel.app
独自ドメイン：
example.com
独自ドメイン設定では、主にDNSレコードを設定します。
よく使うのは、次の2つです。
Aレコード：
ルートドメインに使うことが多い
CNAMEレコード：
wwwなどのサブドメインに使うことが多い
たとえば、次のような構成です。
example.com
→ Aレコード
www.example.com
→ CNAMEレコード
Vercelにドメインを追加すると、必要なDNS設定が画面に表示されます。
その内容に従って、ドメイン管理会社側でDNSレコードを設定します。
Vercelにドメイン追加
↓
必要なDNSレコードを確認
↓
ドメイン管理画面で設定
↓
DNS反映を待つ
↓
VercelでValidになるか確認
DNSは反映に時間がかかることがあります。
設定直後にすぐ反映されない場合もあります。
ただし、長時間Validにならない場合は、DNS設定ミスの可能性があります。
よくあるミスです。
・CNAMEのNameが間違っている
・www.example.comとwwwを混同している
・古いレコードが残っている
・AレコードとCNAMEが競合している
・ネームサーバーが別サービスを向いている
独自ドメイン設定では、焦らず、Vercelが表示する値とDNS管理画面の値を1つずつ照合します。
ドメイン設定は感覚で直さない。
表示された値を正確に入れる。
24.5 SSLとHTTPS
ECサイトでは、HTTPSは必須です。
HTTPSとは、通信を暗号化する仕組みです。
購入者が入力する情報や注文情報を安全にやり取りするために必要です。
HTTP：
暗号化されていない通信
HTTPS：
暗号化された通信
Vercelでは、プロジェクトに追加したドメインに対して、DNS設定と検証が完了するとSSL証明書の生成が自動的に試行されます。SSL証明書はDNSレコードが正しく設定され、反映されたあとに有効になります。(vercel.com)
つまり、基本的な流れは次の通りです。
Vercelにドメイン追加
↓
DNS設定
↓
DNS反映
↓
SSL証明書が発行される
↓
HTTPSでアクセスできる
本番公開前には、次のURLを確認します。
https://example.com
https://www.example.com
両方使う場合は、どちらを正式URLにするか決めます。
正式URL：
https://example.com
www：
https://www.example.com から example.com へリダイレクト
または、その逆でも構いません。
大切なのは、URLが分散しないことです。
悪い例：
example.comでも表示
www.example.comでも表示
両方が別ページ扱い
よい例：
正式URLに統一
SSLやHTTPSで確認する項目です。
・httpsで開けるか
・ブラウザで警告が出ないか
・httpからhttpsへリダイレクトされるか
・wwwありなしの扱いが決まっているか
・Squareのredirect_urlもhttpsになっているか
・Webhook URLもhttpsになっているか
決済まわりでは、HTTPSであることが特に重要です。
ECでは、HTTPのまま公開してはいけません。
本番ECはHTTPSで公開する。
24.6 本番決済テスト
本番公開前には、本番環境で少額の決済テストを行います。
Sandboxでテストしていても、本番環境では別の設定を使います。
そのため、本番でも必ず確認します。
Sandboxで成功
↓
本番でも成功するとは限らない
本番決済テストで確認する項目は、次の通りです。
・Production Access Tokenで動いているか
・Production Location IDで動いているか
・本番決済リンクが作成されるか
・実際のカードで決済できるか
・Webhookが本番URLへ届くか
・注文ステータスがpaidになるか
・在庫が減るか
・注文完了メールが届くか
・管理者通知が届くか
・Square Dashboardで決済を確認できるか
本番テストでは、金額の小さいテスト商品を用意すると安全です。
テスト商品：
本番決済確認用 100円
ただし、本番サイトにテスト商品を公開したままにしないよう注意します。
テスト後：
非公開にする
削除ではなくアーカイブする
本番決済テストの流れです。
本番サイトを開く
↓
テスト商品を購入
↓
実際のカードで決済
↓
注文完了ページを確認
↓
Webhook処理を確認
↓
メールを確認
↓
管理画面を確認
↓
必要なら返金テスト
本番決済テストでは、結果を記録します。
実施日時：
2026-07-06 18:00
注文番号：
ORDER-TEST-001
確認結果：
決済OK
Webhook OK
メール OK
在庫更新 OK
管理画面 OK
本番環境では、実際のお金が動きます。
少額で、慎重に、通しで確認します。
24.7 特定商取引法ページ
日本国内でECを行う場合、特定商取引法に基づく表示を準備します。
特定商取引法は、通信販売などの取引で購入者の利益を保護し、取引の公正を確保するための法律です。日本法令外国語訳データベースでも、訪問販売、通信販売、電話勧誘販売などを対象にする法律として説明されています。(japaneselawtranslation.go.jp)
ECサイトでは、購入者が事業者情報や販売条件を確認できるようにします。
特定商取引法ページに載せる主な項目は、一般的に次のような内容です。
・販売事業者名
・運営責任者
・所在地
・電話番号
・メールアドレス
・販売価格
・商品代金以外の必要料金
・支払い方法
・支払い時期
・商品の引渡時期
・返品・交換・キャンセルについて
ページURLの例です。
/legal/tokushoho
/tokushoho
書き方の例です。
販売事業者：
株式会社〇〇
運営責任者：
山田 太郎
所在地：
〒000-0000
愛知県名古屋市〇〇区〇〇
販売価格：
各商品ページに税込価格を表示します。
商品代金以外の必要料金：
送料、振込手数料などが発生する場合があります。
商品の引渡時期：
ご注文確認後、通常3〜5営業日以内に発送します。
特定商取引法ページは、フッターから必ずアクセスできるようにします。
フッター
↓
特定商取引法に基づく表記
このページは、デザインよりも正確さが大切です。
実際の事業者情報、配送条件、返品条件に合わせて作ります。
24.8 プライバシーポリシー
ECでは、氏名、メールアドレス、電話番号、配送先住所などの個人情報を扱います。
そのため、プライバシーポリシーを用意します。
日本の個人情報保護法は、個人情報の適正な取扱いに関する基本事項や、個人情報取扱事業者等の義務を定める法律です。(japaneselawtranslation.go.jp)
プライバシーポリシーでは、主に次の内容を説明します。
・取得する情報
・利用目的
・第三者提供の有無
・外部サービスの利用
・安全管理措置
・問い合わせ先
・開示・訂正・削除などの対応
ECで取得する情報の例です。
・氏名
・メールアドレス
・電話番号
・配送先住所
・注文内容
・決済に関する識別情報
ここで注意すべきなのは、クレジットカード情報を自社で保存しない場合、そのことを明確にしておくことです。
クレジットカード情報は、決済代行サービス上で処理され、当サイトではカード番号等を保存しません。
利用目的の例です。
・商品の発送
・注文確認
・問い合わせ対応
・決済処理
・不正利用防止
・サービス改善
・重要なお知らせの送信
外部サービスを使う場合は、その利用も整理します。
・Square
・メール送信サービス
・アクセス解析ツール
・配送サービス
プライバシーポリシーも、フッターからアクセスできるようにします。
フッター
↓
プライバシーポリシー
プライバシーポリシーは、テンプレートをそのまま貼るだけでは不十分です。
実際に取得している情報、使っている外部サービス、運用方法に合わせて調整します。
24.9 返品・キャンセルポリシー
返品・キャンセルポリシーは、購入前の不安を減らすために重要です。
購入者は、次のようなことを気にします。
・注文後にキャンセルできるのか
・返品できるのか
・不良品だった場合はどうなるのか
・食品でも返品できるのか
・返送料は誰が負担するのか
返品・キャンセルポリシーに書く内容は、次の通りです。
・キャンセル可能なタイミング
・返品可能な条件
・返品できない商品
・不良品や誤配送時の対応
・返送料の負担
・返金方法
・連絡期限
・問い合わせ先
食品ECでは、返品条件を特に明確にします。
食品という商品の性質上、お客様都合による返品・交換は原則としてお受けしておりません。
商品に不備がある場合は、到着後〇日以内にご連絡ください。
ギフト商品では、発送後のキャンセルが難しい場合があります。
発送手続き完了後のキャンセルはお受けできない場合があります。
返品・キャンセルポリシーは、特定商取引法ページにも関連します。
そのため、内容が食い違わないようにします。
特定商取引法ページ：
返品・キャンセル条件
返品・キャンセルポリシー：
詳細な説明
この2つの内容を一致させる
商品ページやFAQにも、簡単に案内を入れると親切です。
返品・キャンセルについては、こちらをご確認ください。
返品条件が分からないと、購入者は不安になります。
逆に、条件が明確だと、安心して購入しやすくなります。
24.10 公開後に見るべき数字
本番公開はゴールではありません。
公開してからが運用の始まりです。
ECでは、公開後に数字を見ながら改善します。
まず見るべき数字は、次の通りです。
・アクセス数
・商品詳細閲覧数
・カート追加数
・決済開始数
・購入完了数
・購入完了率
・離脱ページ
・売上
・平均注文単価
・リピート購入数
流れで見ると、次のようになります。
アクセス
↓
商品詳細を見る
↓
カートに入れる
↓
決済へ進む
↓
購入完了
それぞれの段階で、どこで落ちているかを見ます。
商品詳細は見られている
でもカートに入らない
→ 商品説明、価格、送料、購入ボタンを見直す
カートには入る
でも決済へ進まない
→ 送料、合計金額、支払い方法を見直す
決済へ進む
でも購入完了しない
→ 決済画面、エラー、導線を確認する
公開後すぐに見るべき数字です。
初日：
サイトが正常に表示されているか
決済エラーが出ていないか
Webhookが動いているか
1週間：
どの商品が見られているか
どこで離脱しているか
問い合わせが来ているか
1か月：
売上
注文数
平均注文単価
リピート導線
SEO流入
数字を見る目的は、責めることではありません。
改善ポイントを見つけることです。
売れていない
ではなく
どこで止まっているかを見る
小規模ECでは、最初から大量の分析ツールを入れなくても構いません。
まずは、次の数字を追うだけでも十分です。
・アクセス数
・商品詳細閲覧数
・購入完了数
・売上
・問い合わせ数
公開後の運用で大切なのは、毎日少しずつ確認することです。
注文は入っているか
エラーは出ていないか
メールは送れているか
在庫はズレていないか
問い合わせは来ていないか
ECは公開して終わりではありません。
数字を見ながら、商品ページ、導線、FAQ、メール、SNSを少しずつ改善していきます。
第24章のまとめ
本番公開では、テスト環境で動いたものを、そのまま勢いで公開してはいけません。
Square、Vercel、独自ドメイン、SSL、法務ページ、決済テスト、運用確認をひとつずつ整える必要があります。
この章で覚えておきたいポイントは、次の通りです。
1. 本番SquareアカウントではProduction設定を使う
2. SandboxとProductionのAccess Tokenを混ぜない
3. 本番環境変数はVercelのProductionに正しく設定する
4. Vercelへデプロイしたら購入フローまで確認する
5. 独自ドメインはDNS設定を正確に行う
6. 本番ECは必ずHTTPSで公開する
7. 本番決済テストは少額で慎重に行う
8. 特定商取引法ページを用意する
9. プライバシーポリシーと返品・キャンセルポリシーを整える
10. 公開後はアクセス、購入、離脱、売上の数字を見る
本番公開の基本は、次の一言にまとめられます。
公開する前に、売れても困らない状態にする。
注文が入る。
決済される。
メールが届く。
管理画面に表示される。
発送できる。
問い合わせに対応できる。
ここまで整って、初めて本番ECとして安心して運用できます。
第25章からは応用編として、会員機能、定期購入、クーポン、多店舗・催事対応など、本格ECへ拡張する方法を学んでいきます。