BASE・Shopify・自作EC 個人ECサイトの選び方と比較

個人でネットショップを始めるとき、「BASE・Shopify・それとも自作？」という選択で手が止まる人は少なくない。それぞれのサービスは得意とする状況が根本的に異なり、「どれが一番いいか」ではなく「自分の状況にどれが合うか」を判断する必要がある。この記事では比較軸を先に定義し、表で整理したうえで、状況別の選び方まで書ききる。

比較対象の基本構造

まず3択の本質的な違いを整理する。

BASE
無料で開設できる日本製のECプラットフォーム。商品ページ・決済・配送ラベル印刷が一体化しており、開設から出品までの手順が3択の中で最も短い。スタンダードプランは月額固定費なしで、売れた分だけ手数料が発生する従量課金モデル（執筆時点ではスタンダードプラン：決済手数料3.6%＋40円/件など。プランや機能により異なるため、公式サイトで確認してください）。

Shopify
月額制のグローバルSaaSで、世界規模で展開しているECプラットフォーム。アプリエコシステムが豊富で、多言語・多通貨・サブスクリプション販売など高度な機能を追加できる。執筆時点では最安プラン（Basic）が月額$25（年払い）から。Shopify Paymentsを使う場合、プランによって追加の取引手数料が0〜2%となる（公式ドキュメントを参照。レートは変更されることがあります）。

自作EC
フレームワーク・データベース・決済APIを自分で選んで組み合わせる方法。自由度は最大だが、セキュリティ・バックアップ・決済のPCI DSS対応などをすべて自前で担う。

主要な比較軸を表で整理する

※料金・手数料はプランや時期により変動します。契約前に各サービスの公式サイトを必ず確認してください。

BASEを選ぶべき状況

次の条件に当てはまるなら、BASEから始めるのが合理的と考えられます。

• 技術的な知識がなく、今すぐ出品を始めたい
• ハンドメイド・古着など、主に国内向けに少量販売する
• 月の売上がまだ読めず、固定費を抑えたい
• 在庫管理・梱包・発送作業に時間を集中したい

BASEの強みはセットアップの速さです。スマートフォンから商品登録・売上確認・発送通知ができ、初期コストゼロで動かせます。一方でカスタマイズの限界が早めに来るため、売上規模が変化した段階で乗り換えを検討するというロードマップを最初から描いておくと安心と考えられます。

Shopifyを選ぶべき状況

• 最初から一定の販売量・単価を見込んでいる
• 海外販売・多通貨・サブスクリプションなど複合的な機能が必要
• アプリを組み合わせて機能を拡張したい
• ブランドサイトとしての見せ方にこだわりたい

Shopifyの強みはエコシステムの広さです。SEO・メール自動化・在庫同期・レビュー収集など、多くの課題に対応するアプリが揃っているとされています。ただし月額費用にアプリの月額費用が積み重なるケースがあるため、「基本機能で何をカバーでき、何を追加購入が必要か」を見積もってから選ぶことをおすすめします。

自作ECを選ぶべき状況（実際に構築・運用している視点から）

私は現在、Next.js（App Router）+ TypeScript + Prisma + SQLite で自作ECサイトを構築し、実際に運用しています。

決済まわりの実装

決済には PAY.JP を REST API 直叩きで組み込み、EMV 3-Dセキュア（charge作成→認証ページ→コールバックで確定、失敗時は在庫を戻す）まで自前実装しました。カード情報は PAY.JP のトークン化により非保持型で処理しているため、自分でカード番号を保存する必要はありませんが、全体的なセキュリティ設計の責任は自前で担います。

// charge作成の概略（サーバー側で実行）
const charge = await payjp.charges.create({
  amount: totalAmount,
  currency: 'jpy',
  card: tokenFromClient,
  three_d_secure: true, // EMV 3-Dセキュア有効化
});
// コールバックで認証結果を確認し、失敗時は在庫を戻す

決済フローを細かくコントロールできるのは自作の大きな利点で、在庫の確定タイミングや3Dセキュア失敗時のロールバック処理なども自由に設計できます。Next.js App RouterにStripe決済を導入する手順｜個人サイト最小構成 も構造的に近い内容ですが、私の環境では PAY.JP を選択しています。

インフラとセキュリティの実態

サーバーは自宅の Linux 機で Node アプリを systemd 常駐させ、Cloudflare Tunnel で公開しています。ポート開放なしで https:// のドメインを割り当てられる構成で、ルーターの設定を変えずに済みます。

# systemd で常駐させる
sudo systemctl enable ec-site.service
sudo systemctl start ec-site.service

セキュリティ面では、Next.js の proxy.ts で独自のWAF層を実装しました。

// proxy.ts（WAF の設定値例）
const RATE_LIMIT_PER_MIN = 300;          // レート制限
const LOGIN_FAIL_MAX = 5;                // ログイン失敗上限
const LOCK_DURATION_MS = 15 * 60 * 1000; // 15分ロック

IP自動BAN・レート制限・ログイン失敗5回で15分ロック・画像アップロードのマジックバイト検証を含んでいます。加えて ClamAV を導入し、毎朝4:30のcronスキャンと freshclam 常駐でウイルス検知を設定しています。npm audit で検出された脆弱性は package.json の overrides で随時対処しています。

自作を選ぶ条件と向かない条件

向いている状況：

• 既存プラットフォームでは実現できない独自機能が必要（AI連携・バーチャル試着・カスタムワークフローなど）
• 決済フローを細かくコントロールしたい（在庫確定タイミング・3Dセキュアの挙動など）
• 手数料を決済代行会社の料率だけに抑えたい
• Web開発が本業または副業として成立しており、構築・保守コストを自分の労働で賄える

向いていない状況：

プログラミング未経験で「手数料を抑えたい」という理由だけで自作に進むのは危険と考えられます。セキュリティ設計・TLS証明書の更新・依存パッケージの脆弱性管理・障害対応など、継続的なメンテナンスコストが発生します。これらを軽視すると、顧客情報や決済まわりでの事故リスクが生まれます。

まとめ

3択の判断は 「技術力 × 必要な機能 × 許容できる初期コスト」 の3軸で決まります。

次に取る行動は一つ：BASEまたはShopifyの管理画面と出品フローを実際に触ってみることです（Shopifyの試用期間の詳細は公式サイトで確認してください）。「機能の限界にぶつかった時点で自作を検討する」という順序が、多くの場合リスクを最小化できると考えられます。自作は「やりたいことをプラットフォームがブロックしたとき」の選択肢として温存しておくのが現実的です。