CONTENT
ここから
この章でわかること
この章では、Square APIとNext.jsを使ってECシステムを作る理由を整理します。
まだSquare APIやNext.jsに触れたことがない人でも大丈夫です。
まずはコードを書く前に、全体像をつかみます。
ECサイトを作る方法はいくつもあります。
Shopify、BASE、STORESのような既存ECサービスを使う方法。
Squareの決済リンクを使う方法。
Next.jsで自分専用のECサイトを作る方法。
どれが正解という話ではありません。
大切なのは、
何を外部サービスに任せて、何を自分で作るかです。
本書では、次のような考え方で進めます。
商品ページ・購入導線・ブランド表現
↓
Next.jsで自由に作る
決済処理
↓
Squareに任せる
この組み合わせによって、
自由度が高く、売り始めやすく、運用コストも抑えやすいECシステムを目指します。
1.1 既存ECサービスと自作ECの違い
ECサイトを作る方法は、大きく2つあります。
既存ECサービスを使う方法
自作ECとして作る方法
既存ECサービスとは、Shopify、BASE、STORESなどのように、商品登録、カート、決済、注文管理などが最初から用意されているサービスです。
管理画面にログインして商品を登録すれば、比較的早く販売を始められます。
一方、自作ECは、商品ページ、購入ボタン、注文処理、管理画面などを自分で設計して作る方法です。
自由度は高いですが、作るべきものも増えます。
違いを簡単に整理すると、次のようになります。
| 項目 | 既存ECサービス | 自作EC |
|---|---|---|
| 始めやすさ | 始めやすい | 設計と実装が必要 |
| デザイン自由度 | サービスの範囲内 | 自由に作れる |
| 決済 | 標準で用意されていることが多い | 外部決済と連携する |
| SEO設計 | 制約がある場合がある | 自由に設計できる |
| 独自機能 | 追加しにくい場合がある | 自由に追加できる |
| 運用コスト | 月額・手数料・アプリ費用が発生 | 構成次第で抑えられる |
| 開発難易度 | 低め | 高め |
既存ECサービスは、すでに完成した「街」に自分のお店を出すイメージです。
自作ECは、自分で「お店の場所、外観、内装、導線」を設計するイメージです。
どちらにもメリットがあります。
ただし、ブランドの世界観を強く出したい場合や、商品説明、記事、SEO、独自の販売導線を細かく作りたい場合は、自作ECのほうが向いている場面があります。
1.2 Shopify、BASE、STORES、Square、自作ECの比較
ここでは、代表的な選択肢をざっくり比較します。
なお、料金や仕様は変更される可能性があります。
ここでの説明は、2026年7月6日時点で確認できる公式情報を前提にしています。
Shopify
Shopifyは、本格的なECサイトを作るための代表的なサービスです。
商品管理、決済、配送、在庫、テーマ、アプリなどが揃っており、成長するECサイトに向いています。
公式の料金ページでは、無料トライアル後に月額プランへ移行する構成が案内されています。プランによって機能や費用が変わるため、売上規模や必要機能に応じて選ぶ形になります。(Shopify)
Shopifyは、最初から本格的にEC事業を伸ばしたい場合に強い選択肢です。
ただし、アプリを追加していくと、月額費用が増えることがあります。
BASE
BASEは、日本国内でネットショップを手軽に始めやすいサービスです。
公式の料金ページでは、スタンダードプランは月額0円で、売れたときに決済手数料とサービス利用料が発生する構成が案内されています。また、グロースプランは月額費用が発生する代わりに、決済手数料が抑えられる構成です。(BASE (ベイス) | ネットショップを無料で簡単に作成)
初期費用を抑えて始めたい場合には向いています。
ただし、ブランドサイトとして細かく設計したい場合や、独自の画面・導線を作り込みたい場合は、制約を感じる可能性があります。
STORES
STORESも、日本国内で使いやすいネットショップ作成サービスです。
公式料金ページでは、月額0円のフリープランと、月額費用が発生するスタンダードプランが用意されていると説明されています。ネットショップだけでなく、予約、POSレジ、決済など、店舗運営に関わるサービスも展開されています。(STORES)
小規模店舗や個人事業者がオンライン販売を始めるには使いやすい選択肢です。
一方で、完全に自由なUIや独自ロジックを作りたい場合は、自作ECのほうが向いています。
Square
Squareは、決済や店舗運営に強いサービスです。
特に本書で重要なのは、Squareのリンク決済やCheckout APIです。
Squareのリンク決済は、専用のECサイトがなくてもオンライン決済を受け付けられる方法として公式ヘルプで説明されています。決済リンクを作成し、メールやSNS、Webサイトなどで共有できます。(Square)
また、Square APIのCreatePaymentLinkでは、Squareがホストする決済ページを作成し、そのリンクを購入者に共有して支払いを受け付けることができます。(Square)
つまりSquareは、
決済部分を任せるサービスとして非常に使いやすい存在です。
自作EC
自作ECは、Next.jsなどを使って自分でECサイトを構築する方法です。
商品ページ、購入導線、管理画面、SEO記事、ブランドページなどを自由に作れます。
Next.jsのRoute Handlersを使えば、appディレクトリ内で独自のリクエスト処理を作成できます。Square APIを呼び出す処理やWebhookを受け取る処理も、Next.js側に実装できます。(Next.js)
自作ECは、自由度が高い反面、開発力が必要です。
そのため本書では、いきなりすべてを自作するのではなく、
決済はSquareに任せ、ECサイト部分をNext.jsで作るという現実的な構成を採用します。
比較まとめ
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Shopify | 本格EC、成長前提、大量商品 | 月額・アプリ費用が増える可能性 |
| BASE | 初期費用を抑えて始めたい | 独自UIや細かい設計には制約が出やすい |
| STORES | 小規模店舗、シンプル販売 | 作り込みには制約が出る場合がある |
| Square | 決済だけを素早く導入したい | EC全体の自由設計は別途必要 |
| Next.js自作EC | ブランド表現、SEO、独自導線 | 開発・保守が必要 |
攻略ポイントは、
最初から全部入りのECを目指さないことです。
まずは、商品を見せて、決済できる状態を作る。
そのあと、必要に応じてカート、在庫、管理画面、メール通知を追加していきます。
1.3 小規模事業者・実店舗・D2Cに向く構成
Square APIとNext.jsの組み合わせは、特に次のような事業者に向いています。
小規模事業者
実店舗を持っているお店
D2Cブランド
食品・工芸品・アパレル
催事販売をしている事業者
地域産品を販売したい事業者
高単価商品を丁寧に売りたい事業者
理由は、これらの商材は、ただ商品を並べるだけでは売れにくいからです。
たとえば、食品なら、
誰が作っているのか
どんな素材を使っているのか
どう食べるとおいしいのか
ギフトに向いているのか
どんな歴史があるのか
を伝える必要があります。
工芸品なら、
作り手の背景
技法
素材
使い方
一点ものとしての価値
を伝える必要があります。
このような商品は、テンプレート型のECページだけでは魅力が伝わりきらないことがあります。
そこでNext.jsを使います。
Next.jsであれば、商品ページだけでなく、読み物、特集、FAQ、ブランドストーリー、ギフトページなどを自由に作れます。
一方で、決済部分をすべて自作するのは危険です。
そこでSquareに決済を任せます。
つまり、小規模ECでは次の構成が現実的です。
Next.js
↓
商品を魅力的に見せる
Square
↓
安全に決済する
この役割分担が、無理なく始められるEC構成になります。
1.4 「高速EC」とは何か
本書でいう「高速EC」とは、単に画面表示が速いECサイトのことだけではありません。
ここでいう高速には、3つの意味があります。
表示が速い
販売開始までが速い
改善サイクルが速い
表示が速い
商品ページの表示が遅いと、ユーザーは購入前に離脱します。
特にスマートフォンでは、数秒の遅さが大きなストレスになります。
Next.jsは、ページの作り方を工夫することで、商品ページや記事ページを高速に表示しやすいフレームワークです。
販売開始までが速い
最初からカート、会員機能、在庫管理、メール通知、管理画面をすべて作ろうとすると、販売開始まで時間がかかります。
最初のゴールは、完璧なECサイトではありません。
まずは次の流れを作ります。
商品ページ
↓
購入ボタン
↓
Square決済ページ
↓
注文完了ページ
これができれば、最小構成で販売を始められます。
改善サイクルが速い
ECは、公開して終わりではありません。
むしろ公開後が本番です。
商品説明を変える
写真を差し替える
購入ボタンの位置を変える
FAQを追加する
ギフト導線を追加する
検索流入用の記事を増やす
このような改善を素早く回せることが大切です。
Next.jsで自作していれば、改善したい部分を自分で調整できます。
これが「高速EC」の考え方です。
1.5 ランニングコストを抑える設計思想
ECサイトでは、作る費用だけでなく、運用し続ける費用も重要です。
ランニングコストには、次のようなものがあります。
ECサービスの月額費用
決済手数料
アプリ利用料
サーバー費用
ドメイン費用
メール配信費用
管理作業の人件費
保守費用
既存ECサービスは便利ですが、必要な機能を追加していくうちに、月額費用が増えることがあります。
一方、自作ECでは、設計次第で固定費を抑えられる可能性があります。
たとえば、最初は次のような構成にできます。
Next.js
↓
Vercelにデプロイ
決済
↓
Squareの決済リンク
商品データ
↓
静的データまたは小規模DB
メール
↓
必要になってから導入
Squareのリンク決済は、公式ページで月額固定費がかからず、オンライン決済ごとの手数料が発生する仕組みとして説明されています。(Square)
つまり、最初から大きな固定費を抱えなくても、販売導線を作れる可能性があります。
ただし、ここで注意があります。
ランニングコストを抑えることは大切ですが、
必要な安全性や保守性まで削ってはいけません。
特に、決済、個人情報、注文情報、在庫情報は慎重に扱う必要があります。
攻略ポイントは、
固定費を抑えながら、危険な部分は外部サービスに任せることです。
1.6 決済だけをSquareに任せるメリット
Square APIとNext.jsの構成で一番大きなメリットは、
決済だけをSquareに任せられることです。
ECサイトで最も慎重に扱うべき部分は決済です。
クレジットカード情報や支払い処理を自前で抱え込むと、セキュリティの責任が重くなります。
そこで、Squareの決済ページを使います。
SquareのCreatePaymentLink APIでは、Squareがホストする決済ページを作成し、そのリンクを購入者に共有できます。(Square)
つまり、購入者はSquare側の安全な決済ページで支払いを行います。
自分のECサイト側では、カード番号を直接扱いません。
流れはこうです。
Next.jsの商品ページ
↓
購入ボタンを押す
↓
Next.jsのAPIがSquareに決済リンク作成を依頼
↓
Squareの決済ページURLを受け取る
↓
購入者をSquare決済ページへ移動
↓
支払い完了後、自社サイトへ戻る
この方式のメリットは、次の通りです。
決済画面を自作しなくてよい
カード情報を自社サイトで直接扱わなくてよい
実装量を減らせる
初期リリースが早くなる
小規模ECでも導入しやすい
最初のECでは、これで十分です。
自社サイト内で完全に決済を完結させたい場合は、後からWeb Payments SDKやPayments APIを検討すればよいです。
最初から難しい構成にしないことが、EC開発の攻略ポイントです。
1.7 自作すべき部分と外部サービスに任せる部分
ECを作るときに重要なのは、
何でも自作しないことです。
自作すべき部分と、外部サービスに任せる部分を分けます。
自作すべき部分
自作すべきなのは、売上やブランドに直結する部分です。
トップページ
商品一覧ページ
商品詳細ページ
ブランド紹介ページ
FAQページ
ギフトページ
特集記事
購入ボタン
注文完了ページ
管理画面
これらは、お客様が商品を理解し、購入を決めるための重要な画面です。
特に、商品に物語がある場合、ここを自由に作れることは大きな強みになります。
たとえば、だし、工芸品、アパレル、美容商品、地域産品などは、説明の仕方で印象が大きく変わります。
Next.jsで作れば、商品を単なる一覧ではなく、ブランド体験として見せることができます。
外部サービスに任せる部分
外部サービスに任せるべきなのは、安全性や専門性が高い部分です。
決済処理
カード情報の扱い
決済ページ
決済結果の通知
メール配信
アクセス解析
一部の認証処理
特に決済は、Squareに任せるべき代表例です。
Next.jsのRoute Handlersを使えば、Square APIを呼び出す処理やWebhookを受け取る処理をサーバー側に実装できます。(Next.js)
つまり、Next.jsは外部サービスと連携するための中継地点にもなります。
構成としては、次のようになります。
ユーザー
↓
Next.jsの商品ページを見る
↓
購入ボタンを押す
↓
Next.jsのAPIがSquare APIを呼ぶ
↓
Squareの決済ページで支払う
↓
SquareからWebhookが届く
↓
Next.js側で注文を確定する
このように、Next.jsとSquareを組み合わせることで、
自由な画面設計と安全な決済処理を両立できます。
1.8 本書で作るECシステムの完成イメージ
本書では、最初から巨大なECモールを作るわけではありません。
目指すのは、
小規模事業者が現実的に運用できる、高速で拡張しやすいECシステムです。
最初の完成形は、次のような構成です。
トップページ
↓
商品一覧ページ
↓
商品詳細ページ
↓
購入ボタン
↓
Square決済ページ
↓
注文完了ページ
これが最小構成です。
この段階では、カートや会員機能がなくても構いません。
まずは、商品を販売できる状態を作ります。
次に、必要に応じて機能を追加します。
カート機能
注文データ保存
Webhookによる決済確認
メール通知
在庫管理
管理画面
配送管理
クーポン
ギフト対応
定期購入
アクセス解析
最終的には、次のような構成を目指します。
Next.js
├─ トップページ
├─ 商品一覧ページ
├─ 商品詳細ページ
├─ カート
├─ 注文完了ページ
├─ 管理画面
├─ SEO記事
└─ API処理
Square
├─ 決済ページ
├─ 支払い処理
├─ 決済リンク
└─ Webhook通知
Database
├─ 商品情報
├─ 注文情報
├─ 注文明細
├─ 在庫情報
└─ 顧客情報
外部サービス
├─ メール配信
├─ アクセス解析
└─ 画像管理
攻略の順番は、次の通りです。
STEP 1
商品ページを作る
STEP 2
購入ボタンを作る
STEP 3
Squareの決済リンクを作る
STEP 4
決済完了ページを作る
STEP 5
Webhookで決済完了を確認する
STEP 6
注文データを保存する
STEP 7
在庫・メール・管理画面を追加する
この順番で進めると、途中で迷いにくくなります。
最初からすべてを完成させる必要はありません。
まずは、
1件目の注文を受けられるECを作ること。
そこから、必要な機能を追加して育てていきます。
この章のまとめ
Square APIとNext.jsを組み合わせる理由は、
自由度と安全性のバランスが良いからです。
Next.jsでは、商品ページ、ブランドページ、SEO記事、購入導線、管理画面を自由に作れます。
Squareでは、決済リンクやSquareホスト型の決済ページを使って、支払い処理を任せられます。(Square)
つまり、本書で目指す構成はこれです。
売るための画面
↓
Next.jsで作る
支払いの処理
↓
Squareに任せる
既存ECサービスを使えば早く始められます。
しかし、ブランド表現、SEO、独自導線を作り込みたい場合は、Next.jsによる自作ECに価値があります。
一方で、決済まで全部自作する必要はありません。
危険な部分、専門性が高い部分はSquareに任せます。
この考え方が、本書全体の土台になります。
次の章でやること
次の章では、Squareでできること・できないことを整理します。
Squareには、Checkout API、Payment Links、Web Payments SDK、Payments API、Orders API、Catalog API、Inventory API、Webhookなどがあります。
名前だけ見ると難しそうですが、それぞれの役割を分ければ理解できます。
次章では、SquareをEC開発の「道具箱」として見ながら、どの機能をどの場面で使うのかを整理していきます。