BigCommerceのシステム開発は、業務要件と委託範囲を整理してから、発注形態、契約形態、見積の順に決めます。
業務要件を先に整理しておくと、必要な連携や費用も見極めやすくなります。全体像は、BigCommerceのシステム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・BigCommerceのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
BigCommerceのシステム開発を外注する前の全体像
店舗画面だけを作るのか、受注から社内の業務データまでつなぐのかによって、発注の難しさも費用も変わります。
BigCommerceの位置づけ（販売業務の中核）
BigCommerceは、商品・注文・顧客・価格・在庫を扱うコマース業務システムです。
- 販売機能：商品カタログ、SKU、バリエーション、カテゴリ、検索
- 購買機能：カート、チェックアウト、注文、返品、クーポン
- 業務機能：顧客アカウント、決済、配送、レポート
一方で、ERPやWMSは別のシステムです。PIMやCRM、会計システムも、BigCommerceとは別に用意するものです。在庫の正データはERPやWMSに置き、販売用の数量をBigCommerceへ連携する設計が一般的です。
BigCommerceだけで全業務を置き換えると、標準機能で足りない部分が後から個別開発として必要になりがちです。そこで、在庫や価格など、データごとに正とするシステムを先に決めておくと、連携の方式と工数を見積もりやすくなります。
外注範囲の分け方（構築・連携・運用）
見積もりに含める作業は、次のとおり区分して確認します。
- 構築：初期設定やテーマ適用
- 連携：ERP・PIM・WMS・決済との接続
- 移行とテスト：データ移行、動作確認、リリース
- 運用支援：保守、権限設計、操作研修、手順書作成
社内で商品登録やコンテンツ制作を担う場合でも、権限設計や研修、手順書作成は見積の項目に含めます。また、B2Bで顧客別価格表や購買承認などを使うなら、B2B Editionと既存の基幹システムの担当範囲を分けておきます。
規模が大きい案件では、サイト制作よりも業務設計とデータ連携が発注の中心になります。公式のVidecon事例では、4万商品と300超のブランドを扱っています。
さらに、NetSuiteを商品・価格・在庫・顧客データの正として連携している例もあります。出典はBigCommerce公式Videcon事例（2026年8月確認）です。
BigCommerceの発注形態の選び方
標準機能が中心なら、導入支援会社への一括委託が適しています。一方、複雑な連携があるなら、業務設計に強いSI会社や専門パートナーとの協業が適しています。また、社内に技術責任者がいるなら、要件定義は自社で行い、実装だけを外注する方法もあります。
一括請負は窓口を一本化しやすい方法
一括請負は、要件整理から保守までを一社に任せる方法です。デザインや連携、移行、テストも、同じ一社が担います。そのため、発注側の管理負担と会社間の調整を抑えやすく、責任の所在も分かりやすくなります。
初めて導入する企業や、社内にEC・ITの専任者が少ない企業に適しています。ただし、不得意な領域まで一社に任せると、製品やアプリの提案が偏る可能性があります。
RFPには、再委託する作業、決済会社やERPベンダーとの調整の責任、障害時の一次窓口を記載します。そのうえで、再委託先の社名と役割を確認します。
分離発注は専門性と価格を比較しやすい方法
分離発注では、担当領域ごとに専門会社を選び、それぞれの専門性を活かします。業務設計から運用保守まで、役割ごとに別の会社へ振り分ける形になります。
- 業務設計：SI会社に依頼
- フロント制作：CatalystやNext.jsに強い専門会社
- 連携開発：ERP連携を担う基幹システム会社
- 運用保守：専門性を活かせる別会社
既存ベンダーとの関係を活かしながらBigCommerceを追加したい企業にも適しています。
設計書の解釈が異なると、連携不具合や責任の押し付け合いが起きます。そこで、自社か第三者の責任者が、API仕様とデータ項目を統一します。
受け入れ条件や課題管理、変更承認も、同じ責任者がそろえます。発注先を比べるときは、価格だけでなく、調整役の工数も含めた総額で判断します。
RFPと要件整理で決める項目
RFPは、同じ条件で提案と見積を比べるための発注仕様書です。画面仕様が未確定でも、目的と対象範囲、課題は先にそろえておけます。データと連携、納期、予算の考え方も、同じ段階で整理します。
事業要件の書き方（売上・顧客・業務フロー）
事業要件は、販売の形態や規模、受注業務の流れを整理して書きます。販売条件から注文手続きまで、項目ごとに分けて示します。
- 販売条件：B2CかB2Bか、国内か多言語・多通貨か
- 規模：商品数とSKU数、年間GMV、月間注文数、会員数
- 業務：販売チャネルと受注担当者の作業
- B2B要件：会社アカウント、顧客別価格、掛率、最小ロット
- 注文手続き：見積、承認、注文書、請求、営業担当経由の注文
改善したい状態は、「ECをリニューアルする」で止めず、在庫確認の電話を減らすなどの形で具体化します。たとえば、受注入力の二重作業をなくすことや、顧客別価格を自動表示することは、数値や業務時間で表すと優先順位を判断できます。具体化した目標は、標準機能と個別開発の優先順位を委託先が判断する材料になります。
システム要件の記載項目（データの正・例外処理）
システム要件では、データをどこで管理するか、例外が起きたときにどう扱うか、フロントをどう構成するかを定めます。マスターの置き場所は、商品・価格・在庫・顧客・注文ごとに示します。
データの置き場所から、フロントの構成まで、要件として書く項目を分けて示します。
- データと連携：マスターの所在、APIかバッチか、更新頻度
- 例外処理：失敗時の再送、重複防止、手動復旧
- Webhook：重複に備え、受信側の冪等性と監査ログを要件化
- フロント：短期立ち上げはStencil、ブランド体験・SEO・複数ストア重視ならCatalystなど
- Catalyst：Next.js、React、GraphQL Storefront APIを使う公式フレームワーク
Webhookは、注文作成や在庫変更などのイベントをアプリへ通知できます（出典：BigCommerce公式開発者ドキュメント「Webhooks overview」、2026年8月確認）。
コンポーザブル構成も重視する場合は、Catalystなどのヘッドレスが候補になります。ホスティングやキャッシュ、CMS、プレビュー、認証、決済画面の責任の範囲も、設計の段階で決めます。出典はBigCommerce公式開発者ドキュメント「Catalyst overview」（2026年8月確認）です。
RFPの提案条件と選定基準
提出物の形式をそろえて求めると、提案どうしを比べやすくなります。提案書から実績の区分まで、設計、計画、費用、実績に分けて求めます。
- 設計と機能：提案書、概念アーキテクチャ、機能一覧、連携一覧
- 実施計画：移行方針、テスト方針、体制表、スケジュール
- 費用条件：工程別見積、前提条件、除外事項、保守プラン
- 実績：類似事例と機能ごとの標準・設定・アプリ・個別開発・対象外の区分
選定基準は、価格のほか、BigCommerce・B2B・ERP/WMSの経験と移行品質を見ます。担当実績や日本語支援、再委託に加えて、障害対応と納品物の権利も評価の対象にします。
配点を決めたうえで、同じユースケースを提案してもらうと、営業資料の印象に引っぱられにくくなります。
請負と準委任の使い分け
納品物と責任の範囲がはっきりした工程は請負、要件を確かめながら進める工程は準委任とする組み合わせが現実的です。
納品内容や期限、品質は、契約の名称よりも契約書と個別仕様書で具体的に定めます。仕様変更や障害が起きたときに、誰が負担するかも明記します。
請負契約の納品物と受け入れ条件
請負契約は、納品物を完成させる契約です。要件が固まった標準機能の設定や画面制作に向いています。ただし、標準機能で実現できるかをまだ検証している段階で全工程を固定すると、変更契約が増えるおそれがあります。
契約書には、次の項目を具体的に記載します。
- 成果物：画面、機能、連携、移行、テスト
- 検収：方法、テストケース、期間、不具合の扱い
- 契約運用：仕様変更の手続き、遅延報告、再委託
- 権利・環境：知的財産、ソースコード、環境設定、アカウントの帰属
開発費の支払いがあっても、著作権などが移るとは限りません。そのため、利用を許諾する範囲も文章で明確にしておきます。
準委任契約の向いている工程（検証・伴走型）
準委任契約は、専門人材の稼働や業務支援に対して報酬を支払う形態です。最初から納品物を固定しにくい工程に向いています。
業務整理や検証、運用支援の段階が、準委任で進めやすい工程です。
- 検討：業務整理、アーキテクチャ検討
- 検証：Fit to Standard、MVP
- 継続支援：アジャイル改善、運用支援
導入初期は短期間の準委任で仮説を確かめ、そのあとで実装部分を請負に移す方法もあります。
準委任では、作業時間に加えて、役割や月間の稼働目安を定めます。会議体や報告方法は、体制表にまとめます。
課題管理や意思決定の期限も定めておきます。社内の判断待ちで期間が延びないよう、発注側の責任者と承認者も体制表に加えます。
BigCommerceのシステム開発費用の相場
費用は、利用料金と決済・GMV連動費、アプリの費用を分けて試算します。初期構築とデータ移行、外部連携、保守運用は、それぞれ別に見積もります。
以下の金額は、一律の公式価格を示すものではありません。リサーチノートの業務システム相場と構成・連携の複雑さから整理した、発注の目安です。実額は、商品数や既存システム、データ品質などによって変わります。
公式プラン料金とGMV・決済方式
BigCommerceの利用料は、年払いプランと決済方式を合わせて確認します。CoreからPerformanceまで、プランごとに月額が異なります。
- Core：月29米ドル
- Growth：月79米ドル
- Scale：月299米ドル
- Performance：月1,499米ドルからのカスタム料金
1米ドル150円で換算すると、順に月約4,350円、約11,850円、約44,850円、約22万4,850円からです。ただし、為替や税、契約条件のほか、アプリ料金と決済事業者の手数料は別に見る必要があります。
出典はBigCommerce公式Pricing（2026年8月確認）です。
2026年6月1日から、セルフサービスプランでOpen Payment Providerを使う注文には、Open Payment Provider Feeという追加料金が適用されます。料率は、Coreが2.0%、Growthが1.0%、Scaleが0.6%です。
Embedded Payment Providerの注文は、この追加料金の対象外です。なお、決済事業者の手数料は別にかかります。出典はBigCommerce公式「2026 Pricing Update」（2026年8月確認）です。
月額だけでなく、年間GMVや決済方式、追加ストア、アプリまで含めた年間のTCOで比べます。
構築費の目安と変わる要因（連携・業務の複雑さ）
構成ごとの発注の目安は、含める機能や連携の範囲によって変わります。小規模から大規模まで、それぞれの構成に含まれる作業を並べます。
- 小規模：テーマ適用や初期設定、商品登録、簡易移行、少ない外部連携
- 中規模：標準EC、デザイン調整、決済・配送設定、CRMまたは会計連携
- B2B等：B2B Edition、顧客別価格、見積・承認、ERP・PIM・WMS連携
- 大規模：Catalyst、複数ストア、多言語・多通貨、高度な検索、複数基幹連携
目安として、小規模は100万〜300万円程度で1〜3か月程度、中規模は300万〜1,000万円程度で3〜6か月程度です。
B2B等は800万〜2,500万円程度で、期間は6〜12か月程度が一つの目安です。この費用には、品質を重視したデータ移行も含まれます。
大規模案件では、2,000万〜1億円以上、9〜18か月程度になる可能性があります。これらは、要件定義の後に個別見積もりで確定させるための目安の幅です。
保守運用費の内訳と初期開発費との違い
保守費は、運用・管理・改善の作業範囲ごとに見積もります。
- 運用：障害対応、監視、アプリ・API仕様変更、バックアップ
- 管理：権限管理、コンテンツ更新、データ照合
- 改善：改善開発の対象範囲
一般的な業務システムでは、初期開発費の年15〜25％程度を起点にする場合があります。あるいは、月15万〜80万円程度を起点にする場合もあります。どちらも、サポート時間やSLA、連携の本数、改善の範囲によって変わります。
金額は、含まれる作業時間と対応時間帯を確認したうえで判断してください。
BigCommerceの月額料金が上がれば、外注費が同じでも、TCOは増えます。そこで、年間売上の伸びやGMVの閾値、決済手数料を3年程度で試算します。追加ストアやアプリ更新の費用も加えて、初年度だけ安い提案になっていないかを確認します。
委託先の選定と見積比較の確認項目
公式パートナーかどうかに加えて、類似業務の経験を見ます。連携設計や移行とテストの実績、リリース後の体制も確認します。
公式のBanner Solutions事例では、B2B EditionとCatalystを採用しています。ERP、検索、CMSなど20以上の技術を、API駆動で統合しています。出典はBigCommerce公式Banner Solutions事例（2026年8月確認）です。
企業の知名度よりも、自社の課題と似た複雑さを説明できるかを見ることが大切です。
委託先の実績と担当者の確認項目
公開事例の数よりも、実績の中身や担当の体制を見ます。技術対応やセキュリティも確認します。実績の中身から安全管理まで、見る点を項目ごとに分けて示します。
- 実績：商品・顧客数、年間GMV、B2B価格、連携先、移行件数、リリース後の改善
- 体制：可能なら類似案件の担当者が提案から運用まで関わるか、海外チーム・再委託先への引き継ぎ
- 技術：Stencil等の選定理由、API制限、Webhookの重複・遅延、障害時の再送
- 整合性：価格・在庫の不整合を検知する仕組み
- 安全管理：権限、秘密情報、TLS、監査ログ、個人情報の委託・再委託、カード情報の責任の範囲
BigCommerce側のセキュリティ機能があっても、自社の安全管理の責任は残ります。
見積書の工程・前提・除外事項の比べ方
見積書は、工程ごとに人月や単価、期間をそろえて比べます。担当者や納品物の範囲も、同じ基準で並べます。
見積の工程は、設計から導入後までの流れで区分して比べます。
- 設計：要件定義、基本設計、画面設計
- 構築：BigCommerce設定、テーマまたはフロント開発、アプリ設定
- 移行・検証：API連携、データ移行、テスト
- 導入後：教育、リリース、保守
A社が「連携一式」とし、B社が商品・価格・在庫・注文・顧客を分けて書いている場合、総額だけで比べると中身の違いが見えなくなります。移行前のデータクレンジングや受け入れテスト、マニュアル、リリース後の初期対応が除外されていないかも確認します。アプリや決済の契約費を誰が負担するかも、あわせて見ておきます。
見積段階のリスクと変更費用
見積の段階では、発注後に起こりうるリスクと、その際の変更費用を整理しておきます。RFPの段階で代表SKUや代表顧客を使ったMVPを行うと、後工程の手戻りを減らせます。リスク、MVPで見る範囲、変更条件を、それぞれ分けて書いておきます。
- リスク：要件漏れ、移行品質、在庫ずれ、決済失敗、価格誤表示、Webhook重複、アプリ変更、承認遅延
- MVP：代表SKU・顧客で通常注文、キャンセル、返品、在庫切れ、価格例外、決済失敗、連携停止を検証
- 変更条件：追加機能単価、見積有効期限、為替・料金変更、納期延長、中断費用
発注後に出た要望は、口頭だけで進めず、影響範囲や金額、納期、テスト範囲を変更申請に記録します。承認者も明確にしておきます。
よくある質問
発注では、料金に加えて、標準機能と外部連携・個別開発の境界についても疑問が出やすいです。
BigCommerceのシステム開発は何円から発注できますか？
テーマ設定だけの小規模な案件から、B2B Editionや基幹連携を含む構成まで、費用の目安を紹介します。
- 小規模：テーマ適用や初期設定、商品登録、簡易移行、少ない外部連携なら100万〜300万円程度
- 標準EC：デザイン調整、決済・配送設定、CRMまたは会計連携を含む場合は300万〜1,000万円程度
- B2B・基幹連携：B2B Edition、顧客別価格、見積・承認、ERP・PIM・WMS連携を含む場合は800万〜2,500万円程度など、要件で変動
構築費とは別に、BigCommerceの月額料金や決済費用もかかります。
RFPがなくてもBigCommerceの開発会社へ相談できますか？
相談はできます。まとめておくと話を進めやすいのは、業務の内容と規模、既存システム、課題、希望時期、予算の考え方です。
要件が未確定なら、いきなり本開発を発注せず、要件整理やFit to Standard検証を準委任で依頼する方法もあります。
B2Bの価格表や在庫連携も外注できますか？
外注できます。B2B Editionの会社アカウントや顧客別価格を使う方法もあります。ERPやWMSを商品・在庫・価格の正として連携する構成も候補です。
価格や在庫の計算と更新をどこで行うか、APIやWebhookの失敗時の復旧を誰が担うかを決めたうえで、同じ規模の実績を持つ会社へ依頼します。
ヘッドレス構成は必ず選ぶべきですか？
ヘッドレス構成を選ぶかどうかは、目的しだいです。短期で標準ECを立ち上げるならStencil、ブランド体験や複数ストア、独自のSEOやフロントを重視するならCatalystなどが候補です。
ヘッドレスは自由度が上がる一方で、フロント開発やテスト、ホスティング、運用費が増えます。要件への効果を、見積書で比べます。
まとめ
BigCommerceは販売業務の中核と捉えたうえで、ERP、WMS、PIM、CRM、会計システムとの間で、どこまでを誰が受け持つかを整理します。自社の体制に合う一括請負、分離発注、準委任は、その整理をもとに選びます。
発注前のRFPとデータ連携の条件
RFPには、B2C・B2B要件、商品数、顧客数、GMVを書きます。既存システムやデータの正、連携、移行、テストの条件も、同じRFPに含めます。体制や納期、保守の条件も記載します。
工程や工数、前提、除外事項をそろえ、アプリや決済の費用と変更条件も比べます。そのうえで、類似実績と障害対応力も評価します。
初期費用と運用費を合わせたTCO
TCOでは、BigCommerceの利用料から導入後の保守費まで含めて比較します。
- 利用・決済：公式プラン月額、Open Payment Provider Fee、決済手数料
- 導入：アプリ、構築、連携、データ移行
- 運用：保守費用
標準機能と、競争力につながる個別開発を分けたうえで、代表的な商品や顧客、注文のMVPで検証します。そうすれば、過剰な開発を抑えられます。
料金や機能、決済事業者の対応は、更新される可能性があります。契約前に、公式の料金と開発者ドキュメントを確認します。
提案書や契約書、運用手順書には、自社と委託先がそれぞれ担う責任を、具体的に書き残しておきます。
▼全体ガイドの記事
・BigCommerceのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。