経済産業省の「電子商取引に関する市場調査」によると、2025年の日本国内BtoC-EC市場規模は約25兆円を超え、前年比9%超の成長を続けています。中でも年商30〜100億円規模の中堅EC事業者は、Amazon・楽天市場・自社ECの3チャネルを並行運用するケースが増加しており、「在庫は3つのチャネルに分散」「顧客データは3つのシステムに散在」という構造的なボトルネックが顕在化しています。
本記事では、年商50億円超の中堅EC事業者が3チャネルの在庫・受注・顧客データを統合する基幹システム(OMS/CRMの統合基盤)を刷新する際の費用相場と構成、そしてPhase 1 PoCから本開発までの2段階ロードマップを解説します。予算帯は2,000〜5,000万円、稼働までの期間は要件定義から数えて6〜12ヶ月が実務相場です。
目次
1. 背景・市場動向と中堅EC特有の4つの課題
市場動向
経済産業省の電子商取引調査では、物販系BtoC-ECの市場規模は2020年の約12兆円から2025年には約16兆円超へと拡大しました。特に中堅EC事業者(年商10〜100億円)は、Amazon・楽天市場・Yahoo!ショッピング・自社ECを並行運用する「マルチチャネル運用」が標準となり、運用の複雑性が指数関数的に増しています。
年商30〜100億円の中堅ECが直面する典型課題
実際の相談現場で共通して挙がる課題は次の4つです。
- 3チャネル在庫ズレによる機会損失と売違い:Amazon・楽天・自社ECで在庫を別管理すると、売り切れチャネルで在庫が余る一方、別チャネルで売違いが発生します。年商50億円規模なら年間3〜8%の機会損失が発生している例があります。
- 返品・交換処理の属人化:各モールのポリシーが異なり、返品対応が担当者のスプレッドシート管理に依存。担当者の退職で業務が停止するリスクが顕在化します。
- CRMが3分断でLTVが見えない:Amazon購入者は匿名、楽天はR-Mail、自社ECは会員DBとバラバラで、クロスチャネル購入者のLTVを把握できません。
- Excel運用の限界:受注データを毎朝Excelに転記して在庫・売上を集計する運用は、年商30億円を超えると担当者3〜5名が専任化し、リアルタイム性を欠きます。
これらは「どこか1社のシステムで解決」するのではなく、受注管理(OMS)・在庫管理(WMS連携)・顧客管理(CRM/CDP)の3領域を統合する基幹システム設計によって初めて解消できる構造課題です。
3チャネル並行運用の限界を感じ始めた経営層の方へ
GXO株式会社は中堅EC向けにPhase 1 PoC(500〜1,500万円)で要件定義・基本設計を先行し、本開発(2,000〜5,000万円)は稟議確定後にスタートする2段階方式でリスクを最小化します。
2. 統合基幹システムの選択肢比較
3チャネル統合の選択肢は大きく4パターンあります。それぞれの費用・期間・向いている規模を整理します。
パターン別比較表
| 実装パターン | 初期費用 | 月額ランニング | 開発期間 | 向いている年商 | 主なデメリット |
|---|---|---|---|---|---|
| SaaS型OMS単体導入(ネクストエンジン/LOGILESS/GoQSystem等) | 30〜200万円 | 月額5〜50万円+件数課金 | 1〜3ヶ月 | 〜30億円 | カスタムロジック非対応、独自KPI未対応 |
| SaaS型OMS+CDP連携(OMS+Treasure Data/karte等) | 300〜1,000万円 | 月額30〜100万円 | 3〜6ヶ月 | 20〜80億円 | 2ベンダー調整、データ統合の設計難度 |
| セミスクラッチ統合基幹(OMS/CRM/CDPを一体設計、フレームワーク活用) | 2,000〜5,000万円 | 月額30〜80万円 | 6〜12ヶ月 | 30〜100億円 | 初期費用が高い、要件定義工程の負荷 |
| フルスクラッチ統合基幹 | 5,000万〜1.5億円 | 月額80〜200万円 | 12〜24ヶ月 | 100億円以上 | 開発期間が長く投資回収まで距離がある |
各パターンの判断基準
SaaS型OMS単体導入(年商〜30億円向け)
ネクストエンジンやLOGILESSなどのOMS SaaSを単体導入する構成です。3チャネルの受注・在庫を一元化できますが、独自の販促ロジック(会員ランク別価格・クロスチャネルクーポン等)や自社KPIでのダッシュボード構築は限界があります。年商30億円を超えると「SaaSの標準機能では回らない」運用が出てきます。
SaaS型OMS+CDP連携(年商20〜80億円向け)
OMSはSaaSで運用コストを抑えつつ、顧客データ統合はTreasure DataやkarteなどのCDPに集約するハイブリッド構成です。LTV分析やチャネル横断のMA施策を打ちたい中堅EC事業者に適しています。ただし2ベンダーのデータ連携設計が鍵となり、API設計・データスキーマ統一に3〜6ヶ月を要します。
セミスクラッチ統合基幹(年商30〜100億円向け、本記事の推奨レンジ)
OMS・CRM・CDPのコア機能を自社要件に合わせて設計・開発し、フレームワーク(Laravel/Next.js/Node.js等)と既存ミドルウェア(Elasticsearch/BigQuery等)を活用して開発期間を短縮する構成です。初期2,000〜5,000万円で自社のKPIと業務フローに完全適合する基幹を構築でき、5年TCOでSaaS積み上げ型より有利になるケースが多く見られます。
フルスクラッチ統合基幹(年商100億円以上向け)
全機能をゼロから設計・開発する構成です。自由度は最高ですが、初期5,000万〜1.5億円、12〜24ヶ月の投資判断が必要で、経営層のコミットが前提となります。
費用内訳の考え方(セミスクラッチ構成、2,000〜5,000万円)
| 機能領域 | 費用帯 | 主要スコープ |
|---|---|---|
| 受注統合(OMS) | 400〜1,200万円 | Amazon SP-API/楽天RMS API/自社EC API統合、受注ステータス一元管理 |
| 在庫統合 | 300〜800万円 | 倉庫在庫と仮引当の一元化、チャネル別配分ロジック |
| 顧客統合(CRM/CDP) | 500〜1,200万円 | 会員名寄せ、購入履歴統合、LTV/RFM分析ダッシュボード |
| 返品・交換ワークフロー | 200〜500万円 | モール別ポリシー対応、返金/再発送の進捗管理 |
| 管理ダッシュボード | 300〜800万円 | 経営ダッシュボード、チャネル別PL、在庫回転率 |
| 既存システム連携 | 300〜500万円 | 会計/WMS/物流APIとのデータ連携 |
3. 費用とロードマップ(Phase 1 PoC + 本開発)
GXOでは中堅EC向けの統合基幹システム刷新を、稟議リスクを抑えるため2段階で進めることを基本としています。
Phase 1:PoC・要件定義・基本設計(500〜1,500万円、2〜3ヶ月)
いきなり本開発に入ると「要件が固まっていないまま5,000万円の発注」というリスクが高まります。Phase 1では次のスコープで上流工程を完結させます。
- 業務フロー可視化:現状3チャネルの受注・在庫・返品・顧客対応フローをBPMNで棚卸し
- データ統合PoC:Amazon SP-API・楽天RMS API・自社ECの主要データを1週間分取得し、名寄せ・統合の技術検証
- 基本設計書:システム構成図、DB設計、API一覧、画面一覧、機能要件書を成果物として納品
- 見積精度向上:本開発の費用を±15%以内の精度で提示
チーム構成は PM 1名 + アーキテクト 1名 + ビジネスアナリスト 1名 + エンジニア 2名の計5名で、2〜3ヶ月が標準です。
Phase 2:本開発・段階リリース(2,000〜5,000万円、6〜9ヶ月)
Phase 1の成果物を基に本開発を進めます。一括ビッグバンリリースではなく、機能単位で段階リリースする構成が中堅ECの実態に適合します。
標準スケジュール例(セミスクラッチ、3,500万円帯)
| 期間 | フェーズ | 主要マイルストーン |
|---|---|---|
| M1〜M2 | 基盤設計・環境構築 | インフラ構築、CI/CD、認証基盤、共通DB設計確定 |
| M3〜M4 | 受注統合(OMS)開発 | Amazon/楽天/自社EC 3API統合、受注一元画面 |
| M5〜M6 | 在庫統合・返品ワークフロー | 在庫引当ロジック、返品管理、WMS API連携 |
| M7 | 顧客統合(CRM/CDP)開発 | 会員名寄せ、LTV/RFM分析ダッシュボード |
| M8 | 管理ダッシュボード・連携仕上げ | 経営ダッシュボード、会計連携、UAT準備 |
| M9 | UAT・並行稼働・本番切替 | 既存システムとの並行運用2週間、段階カットオーバー |
投資回収の目安
年商50億円の中堅EC事業者で、売違い・機会損失・属人化工数を合計すると年間で売上の2〜4%(1億〜2億円)のロスが発生している計算になります。統合基幹を導入して機会損失を半減できれば、初期投資3,500万円は1〜2年で回収される試算です。
稟議を通すための「Phase 1 試算と期待効果」を先にお渡しします
GXO株式会社は中堅EC向けにPhase 1 PoC(500〜1,500万円)で要件定義・基本設計を先行し、本開発(2,000〜5,000万円)は稟議確定後にスタートする2段階方式でリスクを最小化します。
4. よくある質問(FAQ)
Q1. Amazon SP-APIと楽天RMS APIは1つの基幹で本当に統合できますか?
はい、可能です。Amazon SP-APIは商品・在庫・受注・配送の全領域に対応しており、楽天RMS APIも受注・商品・在庫の主要APIが提供されています。ただしAPI制約(Amazonのレート制限、楽天の一部データ取得インターバル)が存在するため、Phase 1 PoCで自社の商品数・受注件数での実効性を検証することを推奨します。3API並行連携は中堅ECでは標準的な構成です。
Q2. 既存のネクストエンジンやLOGILESSから乗り換える場合の移行はどう進めますか?
段階移行が基本です。既存SaaSを残したまま新基幹を並行稼働させ、チャネル単位(まず自社EC、次にAmazon、最後に楽天)でカットオーバーするアプローチが一般的です。過去の受注履歴・顧客データ・商品マスタはデータマイグレーションスクリプトで新基幹に移植し、CSV突合によるデータ整合性チェックを行います。移行期間は2〜3ヶ月が目安です。
Q3. 3,500万円の本開発で、運用開始後のランニングコストはいくらかかりますか?
インフラ費(AWS/GCP)で月額15〜30万円、保守・運用委託(障害対応/小規模改修)で月額40〜80万円、合計で月額55〜110万円が相場です。年間660万〜1,320万円のランニングコストを見込む必要があります。SaaS積み上げ型(OMS+CDP+MA等で月額80〜150万円)と比較しても中長期で有利になるケースが多いです。
5. まとめ
年商30〜100億円の中堅EC事業者が3チャネル(Amazon・楽天・自社EC)の在庫・受注・顧客データを統合する基幹システムは、セミスクラッチ構成(初期2,000〜5,000万円、開発期間6〜12ヶ月)が費用対効果のバランスに優れます。SaaS単体導入では年商30億円超で運用限界が来やすく、フルスクラッチは100億円超でなければ投資回収の距離が遠くなります。
稟議リスクを抑えるには、いきなり本開発に入らず、Phase 1 PoC(500〜1,500万円、2〜3ヶ月)で要件定義・基本設計・見積精度向上を先行する2段階方式が推奨されます。Phase 1の成果物(業務フロー図/基本設計書/技術検証レポート/±15%精度の見積)を経営層に提示することで、本開発の投資判断を大幅に通しやすくできます。
次のアクション:まずは現状の3チャネル運用の年間機会損失と属人化工数を概算し、Phase 1投資の期待回収期間を試算することをお勧めします。
EC基幹システムの本気の刷新は、GXO株式会社へ
年商10〜100億円の中堅EC事業者を対象に、Amazon・楽天・自社ECの統合基幹、D2Cサブスク、AI運用自動化、Shopify Plusからのフルスクラッチ移行までワンストップで対応します。Phase 1 PoC 500〜1,500万円 + 本開発2,000〜5,000万円の2段階で稟議を通しやすい構成です。