Shopify Plusは年商10〜50億円規模のD2C・中堅ECにとって優れた選択肢として日本国内でも導入が急増してきました。一方で、年商50〜200億円に成長した企業、あるいはBtoBや複雑商材を扱う企業からは「Shopify Plusの限界に突き当たった」という相談が2025年以降急増しています。
本記事では、Shopify Plusからの独自フルスクラッチEC移行について、移行判断基準・費用相場・段階ロードマップを解説します。対象は年商50〜200億円、予算3,000〜8,000万円、移行期間8〜14ヶ月を想定する中堅〜準大手EC事業者です。
目次
1. 背景・Shopify Plus限界の典型課題
Shopify Plusの位置づけと限界
Shopify Plusは月額2,000ドル〜の大規模向けプランで、Checkout.liquidカスタマイズやShopify Functions、B2B on Shopifyなど大規模向け機能を提供しています。ただし、プラットフォームの基本思想はBtoC標準業務の最適化にあり、複雑なBtoBロジック・独自業務フロー・深い基幹連携が要求される規模では限界が顕在化します。
年商50〜200億円のShopify Plus利用企業の典型課題
- アプリ月額が30万円超に膨張：定期購入、税区分、カスタム価格、ERP連携など複数のアプリ積み上げで月額費用が25〜50万円、年間300〜600万円に達する
- カスタムロジックをliquidで組めない：取引先別の複雑な商品表示制御、数量階段別割引、配送ルール分岐等をliquid+スクリプトで実装する限界に直面
- BtoB価格階層10段階対応でパフォーマンス劣化：B2B on Shopifyでカンパニー・ロケーション・価格リストを多段階運用すると、カタログ読み込み・カート計算でレスポンス劣化が顕在化
- API制約（Rate Limit）で大規模連携が困難：REST Admin APIのBucket制約・GraphQLのCostコスト消費で、数万SKU更新・1日10万件受注の連携処理が夜間バッチでも間に合わない例がある
- Checkout拡張の範囲外要件：独自の与信判定・複雑な配送分割・BtoB承認ワークフローをCheckout extensionsで実装しきれない
- 5年TCOで独自開発と逆転：アプリ費・Plus料金・Shopify Payments手数料・運用工数を5年積み上げると、独自開発+運用を上回るケースが発生
これらは「Shopify Plusを否定する話」ではなく、事業規模と要件の成長に対して、プラットフォーム境界を認識した上で次の段階に進む経営判断の問題です。
「Shopify Plusを本気で卒業すべきか」の判断材料を揃えたい方へ
GXO株式会社は中堅EC向けにPhase 1 PoC（500〜1,500万円）で要件定義・基本設計を先行し、本開発（2,000〜5,000万円）は稟議確定後にスタートする2段階方式でリスクを最小化します。
2. 移行の選択肢比較とフルスクラッチ判断基準
移行先プラットフォームの選択肢
Shopify Plusの次の選択肢として現実的に検討される構成は4パターンです。
| 移行先 | 初期費用 | 月額ランニング | 開発期間 | 自由度 | 主なデメリット |
|---|---|---|---|---|---|
| Shopify Plus継続＋大規模カスタム | 1,000〜3,000万円 | 月額30〜60万円＋手数料 | 4〜8ヶ月 | 中 | プラットフォーム境界の根本解消はしない |
| Adobe Commerce（Magento）移行 | 2,500〜6,000万円 | 月額40〜80万円 | 8〜14ヶ月 | 高 | 運用難度高、エンジニア採用が難しい |
| 独自フルスクラッチEC（ヘッドレス構成） | 3,000〜8,000万円 | 月額60〜150万円 | 8〜14ヶ月 | 最高 | 初期費用・期間が最大、要件定義の負荷 |
| commercetools/Spree等の商用ヘッドレス | 3,500〜7,000万円 | 月額80〜180万円 | 10〜14ヶ月 | 高 | ライセンス費、国内実装実績の限定 |
フルスクラッチ判断基準チェックリスト
以下の項目で4つ以上該当する場合、独自フルスクラッチへの移行が投資対効果で合理的になりやすいレンジです。
| 判断項目 | フルスクラッチ適合 |
|---|---|
| 年商規模 | 50億円以上 |
| BtoB比率 | 30%以上 |
| Shopify Plusアプリ月額 | 25万円以上 |
| SKU数 | 5万SKU以上 |
| 取引先別価格階層 | 5段階以上 |
| 既存基幹（ERP/WMS）連携 | 深い連携が必須 |
| 独自決済・与信ロジック | あり |
| Checkoutカスタム要件 | Shopify Functions範囲外 |
| 5年TCO比較 | 独自開発が有利な試算 |
ヘッドレス構成が推奨される理由
2026年時点で、フルスクラッチECは「ヘッドレス構成」が事実上の標準です。フロントエンド（Next.js/Nuxt/Astro等）とバックエンド（Node.js/Go/Laravel+API等）を分離することで、以下のメリットが得られます。
- フロントエンドの高速化（SSG/ISR/エッジ配信）
- マイクロサービス的な段階移行（カート→検索→商品詳細→Checkoutの順で切替可能）
- BtoB向けカスタムUI（承認ワークフロー、見積依頼、繰り返し購入、企業別カタログ）を柔軟に実装
- モバイルアプリ・店舗POS・外部チャネルに同一APIで接続
費用内訳の考え方（独自フルスクラッチEC、3,000〜8,000万円帯）
| 機能領域 | 費用帯 | 主要スコープ |
|---|---|---|
| コアECエンジン | 800〜2,000万円 | 商品/カート/注文/在庫/顧客の中核ドメイン、API設計 |
| フロントエンド（BtoC+BtoB） | 600〜1,500万円 | Next.js等でのSSG/ISR、BtoBカスタム画面、パーソナライズ |
| Checkout＋決済 | 400〜1,000万円 | カスタムCheckout、与信/請求書払い、カード決済、税計算 |
| BtoB機能（価格階層/承認） | 400〜1,200万円 | 取引先マスタ、階層価格、承認ワークフロー、見積発行 |
| 基幹連携（ERP/WMS/会計） | 400〜1,000万円 | SAP/Oracle/NetSuite等との双方向連携、在庫・売上・売掛金 |
| 管理画面・運用ツール | 400〜800万円 | 商品・注文・顧客管理、運用オペレーション画面 |
| マイグレーション＋段階切替 | 300〜500万円 | データ移行、並行稼働、カットオーバー計画 |
3. 費用とロードマップ（Phase 1 PoC + 本開発）
Phase 1：PoC・要件定義・基本設計（800〜1,500万円、3〜4ヶ月）
フルスクラッチ移行は「要件定義の精度」が総コストを大きく左右します。Phase 1で次のスコープを完結させます。
- 現状Shopify Plus運用棚卸し：アプリ一覧・カスタム範囲・API消費量・月額内訳・運用工数の可視化
- 業務フロー再設計：BtoC/BtoB/基幹連携の現状フローと、新基盤での再設計案（BPMN）
- 技術アーキテクチャPoC：ヘッドレス構成の技術スタック選定、コア部品の性能検証、BtoB価格計算の負荷試験
- 5年TCO試算：現状継続 vs フルスクラッチ移行 vs Adobe Commerce等、複数シナリオの総コスト比較
- 基本設計書＋±15%精度見積：本開発の費用・期間・段階切替計画を稟議資料として納品
チーム構成は PM 1名 + アーキテクト 1名 + ビジネスアナリスト 1名 + エンジニア 2名 + インフラ専門 1名の計6名、期間は3〜4ヶ月が標準です。
Phase 2：本開発・段階リリース（3,000〜8,000万円、8〜10ヶ月）
フルスクラッチ移行では一括ビッグバン切替は推奨せず、機能単位または顧客セグメント単位で段階切替するアプローチが現実的です。
標準スケジュール例（5,000万円帯、BtoB+BtoC混在、ヘッドレス構成）
| 期間 | フェーズ | 主要マイルストーン |
|---|---|---|
| M1〜M2 | 基盤・アーキテクチャ構築 | インフラ、CI/CD、認証、APIゲートウェイ、コアドメインモデル |
| M3〜M4 | 商品/カタログ/検索＋BtoC画面 | BtoCフロントエンド先行、Shopify Plusと並行稼働（読み取り専用） |
| M5〜M6 | Checkout＋決済＋注文コア | カスタムCheckout、決済基盤、注文処理、与信連携 |
| M6〜M7 | BtoB機能（価格階層/承認） | 取引先マスタ、階層価格、承認ワークフロー、見積 |
| M7〜M8 | 基幹連携（ERP/WMS/会計） | 双方向連携、並行稼働データ整合性チェック |
| M8〜M9 | 管理画面・運用ツール・UAT | 運用画面、オペレーター教育、総合テスト |
| M9〜M10 | 段階カットオーバー | セグメント別に切替、Shopify Plus段階停止 |
5年TCOでの投資判断
年商100億円、Shopify Plusアプリ月額30万円、運用工数10名の企業を想定した5年TCO比較例：
| 項目 | Shopify Plus継続 | 独自フルスクラッチ（5,000万円帯） |
|---|---|---|
| 初期費用 | 0円 | 5,000万円 |
| 月額プラットフォーム/インフラ費 | 60万円×60ヶ月 = 3,600万円 | 20万円×60ヶ月 = 1,200万円 |
| 月額アプリ/ライセンス費 | 30万円×60ヶ月 = 1,800万円 | 5万円×60ヶ月 = 300万円 |
| 月額手数料（決済・取引） | 年間3,000万円×5年 = 1.5億円 | 年間1,800万円×5年 = 9,000万円 |
| 運用・保守人件費 | 年間8,000万円×5年 = 4億円 | 年間6,000万円×5年 = 3億円 |
| カスタム改修費 | 年間500万円×5年 = 2,500万円 | 年間1,000万円×5年 = 5,000万円 |
| 5年TCO合計 | 約6.1億円 | 約4.5億円 |
5年TCO比較を含めた移行可否レポートを先にお渡しします
GXO株式会社は中堅EC向けにPhase 1 PoC（500〜1,500万円）で要件定義・基本設計を先行し、本開発（2,000〜5,000万円）は稟議確定後にスタートする2段階方式でリスクを最小化します。
4. よくある質問（FAQ）
Q1. Shopify Plusから独自ECへの移行で、SEO評価は維持できますか？
適切な移行計画で維持可能です。URL構造の維持、301リダイレクトの網羅設定、構造化データ（Product/Offer/Review/Breadcrumb）の継承、サイトマップの再提出、ページ速度の改善（Core Web Vitals）で、多くの事例で移行後3〜6ヶ月でSEO評価が同等以上に回復します。Phase 1で現状のSEO評価（オーガニック流入・検索順位・被リンク）を棚卸しし、移行設計に反映することを推奨します。
Q2. 段階移行中のデータ整合性はどう担保しますか？
並行稼働期間中は「マスターデータ一元管理」と「双方向イベント同期」の2本柱で整合性を担保します。商品・顧客・注文のマスターデータは新基盤を正とし、Shopify Plusへは読み取り側として同期、新基盤で発生した注文・会員変更はイベントドリブンでShopify Plusに反映します。並行稼働期間は通常2〜4週間、データ差分監視ダッシュボードをPhase 2で構築することが必須です。
Q3. 本開発5,000万円にモバイルアプリは含まれますか？
含まれません。ヘッドレス構成の恩恵でモバイルアプリ（iOS/Android）は同一バックエンドAPIに接続できますが、アプリ自体の実装は別スコープ（800〜2,000万円、3〜6ヶ月）となります。Phase 1でモバイルアプリを含めるかの判断と、API設計への影響を反映することが重要です。店舗POS連携や外部チャネル接続も同様にスコープ追加となります。
5. まとめ
Shopify Plusは年商10〜50億円規模で優れた選択肢ですが、年商50〜200億円、BtoB比率30%以上、アプリ月額25万円超のレンジでは、プラットフォーム境界が事業成長の制約となり始めます。独自フルスクラッチEC（ヘッドレス構成、3,000〜8,000万円、8〜14ヶ月）への移行は、5年TCOで現状継続を下回る試算が成立しやすく、BtoB複雑ロジック・基幹連携・API制約の突破が戦略的な経営判断となります。
Phase 1 PoC（800〜1,500万円、3〜4ヶ月）で現状棚卸し・5年TCO試算・技術アーキテクチャ検証・段階切替計画を先行させることで、本開発の投資判断を稟議で通しやすくなります。
次のアクション：まずは現状のShopify Plusアプリ月額・カスタム範囲・API消費量を棚卸しし、5年TCOで移行妥当性を試算することをお勧めします。
EC基幹システムの本気の刷新は、GXO株式会社へ
年商10〜100億円の中堅EC事業者を対象に、Amazon・楽天・自社ECの統合基幹、D2Cサブスク、AI運用自動化、Shopify Plusからのフルスクラッチ移行までワンストップで対応します。Phase 1 PoC 500〜1,500万円 + 本開発2,000〜5,000万円の2段階で稟議を通しやすい構成です。
追加の一次情報・確認観点
この記事の内容を社内で検討する場合は、一般論だけで判断せず、次の一次情報と自社データを照合してください。特に、稟議・RFP・ベンダー選定では「何を実装するか」よりも「どのリスクをどの水準まで下げるか」を先に決めると、見積もり比較のブレを抑えられます。
| 確認領域 | 参照先 | 自社で確認すること |
|---|---|---|
| デジタル調達 | デジタル庁 | 要件定義、調達、プロジェクト管理の標準観点を確認する |
| Webアプリ品質 | OWASP ASVS | 認証、認可、入力検証、ログ、セッション管理を確認する |
| DX推進 | 経済産業省 DX | レガシー刷新、経営課題、IT投資判断の前提を確認する |
| DX推進 | IPA デジタル基盤センター | DX推進指標、IT人材、デジタル基盤の観点で現状を確認する |
| 個人情報 | 個人情報保護委員会 | 個人情報・委託先管理・利用目的・安全管理措置を確認する |
稟議・RFPで使う数値設計
投資判断では、導入前後で測れる指標を3から5個に絞ります。下表のように、現状値・目標値・測定方法・責任者をセットにしておくと、PoC後に本番化するかどうかを判断しやすくなります。
| 指標 | 現状確認 | 目標の置き方 | 失敗しやすい例 |
|---|---|---|---|
| 対象業務数 | 現状の対象業務を棚卸し | 初期は1から3業務に限定 | 対象を広げすぎて要件が固まらない |
| 月間処理件数 | 件数、担当者、例外率を確認 | 上位20%の高頻度業務から改善 | 件数が少ない業務を先に自動化する |
| 例外対応率 | 手戻り、確認待ち、属人判断を計測 | 例外の分類と承認ルールを定義 | 例外をAIやシステムだけで吸収しようとする |
| 追加要件率 | 過去案件の変更件数を確認 | 要件凍結ラインを設定 | 見積後に仕様が増え続ける |
| 障害・手戻り件数 | 問い合わせ、障害、改修履歴を確認 | 受入基準とテスト観点を定義 | テストをベンダー任せにする |
よくある失敗と回避策
| 失敗パターン | 起きる理由 | 回避策 |
|---|---|---|
| 目的が曖昧なままツール選定に入る | 比較軸が価格や機能数に寄る | 経営課題、業務課題、測定KPIを先に固定する |
| 現場確認が不足する | 例外処理や非公式運用が見落とされる | 担当者ヒアリングと実データ確認を必ず行う |
| 運用責任者が決まっていない | 導入後の改善が止まる | 業務側とIT側の責任分界をRACIで定義する |
| RFPが抽象的で見積が比較できない | 業務フロー、データ、非機能要件が不足 | 見積前に要件定義と受入条件を固める |
GXOに相談する前に整理しておく情報
初回相談では、次の情報があると診断と提案の精度が上がります。すべて揃っていなくても問題ありませんが、分かる範囲で用意しておくと、概算費用・期間・体制の見立てを早く出せます。
- 対象業務の現行フロー、利用中システム、Excel・紙・チャット運用の一覧
- 月間件数、担当人数、手戻り件数、確認待ち時間などの概算
- 個人情報、機密情報、外部委託、権限管理に関する制約
- 希望開始時期、予算レンジ、社内承認者、決裁までの流れ
- 既存システム構成、画面・帳票・データ項目、外部連携、現行ベンダー契約
GXOでは、現状整理、要件定義、RFP作成、ベンダー比較、PoC設計、本番移行計画まで一気通貫で支援できます。記事の内容を自社に当てはめたい場合は、まずは現在の課題と制約を共有してください。