BigCommerceのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

BigCommerceのシステム開発は、要件整理から運用改善までの6つのフェーズを順に進めます。最初に業務とデータの正を決めることが、後の工程の土台になります。

構成と各フェーズの要点は、この後で順に説明します。全体像は、BigCommerceのシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・BigCommerceのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

BigCommerceのシステムの全体像

BigCommerceは、商品カタログやカート、注文、顧客などを提供するクラウド型コマース基盤です。チェックアウトや価格、販促も提供します。

BigCommerceは、ERPや会計システムそのものではなく、販売チャネルの中心に置きます。WMSやPIM、CRMも、BigCommerceの周りに置く周辺システムです。周辺システムとはAPIやWebhookでつなぎ、こうして業務データを流す中核として機能します。

ECサイトではなくコマース業務の中核という考え方

構成は5層で整理できます。管理画面と基盤のほか、ストアフロントや決済などのアプリ、周辺システムとの連携層、分析・マーケティング基盤を含みます。

• 商品情報：PIMを正データとする構成
• 在庫・原価：ERPやWMSを正データとする構成
• 顧客接点：CRMを正データとする構成

正データは、構成に応じて置き場所を選びます。たとえば、商品・価格・在庫の正をERPに、販売・注文受付の正をBigCommerceに置く方法があります。また、商品説明と画像はPIMに、出荷・請求は既存の基幹に渡す構成も可能です。

特に、商品、価格、在庫、顧客、注文の正データを決めないまま開発すると、在庫ずれや価格の上書き、二重受注につながります。

Stencil・Catalyst・独自ヘッドレスの条件による選び分け

どの方式にするかは、求める表示体験や業務の複雑さ、社内の保守体制によって変わります。

• Stencil：ホスト型ストアフロントとStencilテーマで、既存テーマを調整しやすい方式
• Catalyst：Next.js、React、GraphQL Storefront APIを使う、公式のヘッドレス基盤
• 独自ヘッドレス：独自技術で既存アプリや複数チャネルを統合する選択肢

ブランド体験やSEO、表示速度、複数のフロントエンドを重視するなら、Catalystが候補になります。

独自の表示体験や複雑なコンテンツ構成を求めるなら、Stencilには限界があります。一方で、短期間で標準的なECを立ち上げやすく、運用範囲も抑えやすい方式です。

GraphQL Storefront APIでは、プラットフォームのすべての機能をそのまま扱えるとは限りません。そのため、返品や販促バナー、特殊な注文処理は、対応状況を先に確かめます。

不足する部分は、必要に応じてREST Management APIや外部サービスで補います（出典: BigCommerce公式Catalyst Feature Support、2026年）。

B2Bの会社階層や顧客別価格、見積、承認、最小ロットが重要な場合は、B2B Editionと基幹連携を軸にします。

選定では、売上規模や商品点数、B2Bの複雑度、連携数、保守体制も基準になります。ただし、フロントの自由度だけで決めないようにします。

BigCommerceのシステム開発の進め方

まず、業務の目的と、データの責任の所在を決め、標準機能と個別開発の範囲を分けます。そのうえで、代表的な注文を検証してから全体を作ります。いきなりデザインやAPI実装に入ると失敗しやすいため、この順で進めるのが現実的です。

6つのフェーズは、それぞれの成果物と判断基準を決めながら進めます。

フェーズ1：要件整理による業務とデータの正の決定

まず、B2CかB2Bか、対象国、商品点数、年間GMVを洗い出します。さらに、受注経路、既存システム、社内体制も整理します。

機能一覧に加えて、誰がどの画面で何のデータを使い、何を判断するかを業務フローに書きます。

営業見積や取引先承認、ERPでの在庫引当と請求は、一般消費者向けの注文とは別のシナリオに分けます。

• 商品と価格：SKU・バリエーションの粒度、価格表と割引の優先順位
• 注文と顧客：在庫引当、キャンセル・返品・返金、顧客アカウント条件、注文番号
• 責任とKPI：税・配送・決済の担当と、稼働後に測る指標（3〜5個）

KPIの例には、売上増加や受注工数の削減、在庫精度の向上、B2B顧客の自己完結率などがあります。

フェーズ2：標準機能・アプリ・開発会社の選定

Fit to Standardで優先順位を付けたうえで、標準機能に寄せる業務と個別対応する業務を分けます。

• 標準機能：商品、カテゴリ、通常注文、顧客登録、基本クーポン
• 個別対応：競争優位に直結する顧客別価格、複雑な見積・承認、独自受注連携

標準に合わせられる業務まで個別開発すると、更新のたびに回帰テストが増えます。個別対応の手段は、APIやアプリ、開発から選びます。

標準販売を3か月程度で始めるならStencil、ブランドサイトとEC体験を一体化するならCatalystが候補になります。独自技術で既存アプリや複数チャネルを統合する場合は、カスタムヘッドレスを検討します。

開発会社を比べるときは、日本語の要件定義、国内の決済・税・配送への対応、同規模のB2Bや移行の実績、公開後の保守担当も確認します。

フェーズ3：設計・開発での連携の失敗条件の定義

連携では、商品、価格、在庫、顧客、注文ごとに、送信元と送信先、同期の頻度、更新の優先順位を決めます。さらに、再送の方法と手動での復旧も定義します。

リアルタイム連携でも、夜間の全件照合や差分修正を用意しておくと、通信障害や一時的なAPIエラーが起きても差分を後から直せます。

• Webhook：重複イベントの冪等処理と、順序が入れ替わる場合の処理
• 障害対応：受信ログ、失敗キュー

受信側がHTTP 200を返さない場合、Webhookは再送されます。失敗が続くと、無効化されることもあります（出典: BigCommerce公式Webhooks、2026年）。

画面設計では、通常注文に加えて、在庫切れや価格例外、決済失敗の場面を業務担当と確認します。返品や法人承認、権限不足も対象に含めます。

フェーズ4：テストでの注文と業務連携の通し確認

画面表示の確認で終えず、代表SKU、通常顧客、法人顧客、異なる価格表の顧客、在庫が少ない商品で、一連の業務を通します。

商品登録から返品までを、注文、決済、在庫引当、出荷、請求の順にたどります。また、移行データは本番件数に近いサンプルで検証します。

• 移行データ：文字化け、画像、バリエーション、検索、税区分、顧客重複
• 受入テスト：ログイン・権限、カート、クーポン、送料・税、決済成功・失敗、キャンセル、返品
• 連携・ヘッドレス：在庫・価格同期、Webhook再送、外部停止時の復旧、GraphQL API対応範囲、SEO、リダイレクト

ヘッドレスでは、キャッシュやSEOメタ情報、構造化データ、チェックアウトへの遷移も確認します。さらに、各テストには合格条件、担当者、証跡、課題の期限を付けておきます。

フェーズ5：稼働における段階移行と切り戻しの準備

データ移行のリハーサルは、少なくとも一度行います。そのうえで、差分データの取込時間と確認手順を測ります。また、旧システムはすぐに廃止せず、注文照合や問い合わせ対応に使う参照環境として、一定期間残しておきます。

• 切替準備：切替時刻と担当、DNS、SSL、決済本番キー、メール、在庫、注文通知、返品・問い合わせ窓口
• 当日確認：少額注文による、注文作成・決済・在庫・基幹連携・メールの確認
• 切り戻し：販売・決済・連携の停止や旧システムへの復帰を判断する担当者の決定

注文欠落、在庫差異、決済未確定などについては、切り戻すかどうかを判断する閾値を数値で定めておきます。「問題があれば戻す」とだけ決めると、判断が曖昧になります。

フェーズ6：定着に向けた運用と改善の仕組み化

開発会社に任せきりにせず、社内に運用責任者を置きます。

商品登録や価格変更、在庫調整、顧客承認、返品、障害の一次切り分けは、手順書にまとめます。あわせて、権限は必要最小限に絞ります。

問い合わせ件数や受注処理時間、在庫差異、決済失敗率、B2B顧客のオンライン注文率は、月次で確認して改善の順位を決めます。

• 保守範囲：障害、仕様変更、セキュリティパッチ、APIキー、バックアップ、ログ、改善開発
• ヘッドレス運用：ホスティング、CI/CD、依存パッケージ更新も含む、自社の責任範囲

月次会議でKPIと課題を確認し、3か月ごとに機能追加と運用費を見直すと、導入後の形骸化を防ぐうえで役立ちます。

BigCommerceのシステム開発にかかる費用相場

費用は、項目ごとに分けて考えます。中心になるのは、プラットフォームの料金と決済・GMV連動費、初期構築です。ほかに、次の項目もかかります。

• アプリ：アプリの月額料金も、継続費用として見積もります
• 移行：簡易移行から移行リハーサルまで、構成によって差が出ます
• 連携：連携数が増えると、初期構築費も変わります
• 保守：保守運用費が、継続費用として別にかかります

なお、構築費は一般的な業務システムの相場をもとにした、発注の目安です。

実装費は要件と既存資産によって変わり、BigCommerceも一律の金額を公表していません。そのため、以下の金額は確定価格ではなく、目安として扱います。

公式プラン料金と決済・GMV連動費用の切り分け

2026年6月の年払い料金は、Coreが月29米ドル、Growthが月79米ドル、Scaleが月299米ドルです。Performanceは、月1,499米ドルからのカスタム料金です。

1米ドル=150円で換算すると、それぞれ約4,350円、約11,850円、約44,850円、約22万4,850円になります。

為替や税、契約条件、アプリ料金、決済手数料は、上の金額とは別です（出典: BigCommerce公式Plan & Pricing Updates、2026年）。

セルフサービスプランでは、Open Payment Providerで処理した注文に手数料がかかります。

• Core：Open Payment Providerの注文の手数料は2.0%
• Growth：同じ注文の手数料は1.0%
• Scale：Open Payment Providerの注文は0.6%。月間GMV33,333米ドルを超える部分は0.9%

Embedded Payment Providerの注文は追加料金の対象外です。ただし、決済会社の手数料は別にかかります。そのため、年間GMVや決済方法、上位プランの条件を含めた年間TCOで比べます。

要件と連携数による初期構築費の差

初期費用は構成によって異なります。次に示すのは、標準機能の活用などを前提とした発注の目安です。

• 基本構成：テーマ、基本設定、商品登録、簡易移行、少ない連携で100万〜300万円・1〜3か月
• 標準EC：デザイン調整、決済・配送、CRMまたは会計連携で300万〜1,000万円・3〜6か月
• B2B構成：B2B Edition、顧客別価格、見積・承認、ERP・PIM・WMS連携、移行リハーサルで800万〜2,500万円・6〜12か月
• 高度な構成：Catalystのヘッドレス、多ストア、多言語・多通貨、高度な検索・CMS、複数基幹連携

高度な構成では、費用が2,000万〜1億円以上、期間が9〜18か月程度まで広がる可能性があります。

これらは、一般的な業務システムの相場とBigCommerceの構成から推定した幅であり、個別見積の代わりにはなりません。

費用を抑えるには、代表商品や通常注文、主要決済、最低限の在庫連携でMVPを稼働させ、承認や高度な価格計算は第2段階に回します。

データモデルや権限、注文番号、連携の正データは、後から変えにくいため、初期設計で決めておきます。

保守・アプリ・連携運用を含むランニングコスト

継続費用は、プラットフォームやアプリ、決済、基盤、運用に分けて見積もります。

• プラットフォーム：プラン料金とアプリの月額料金
• 決済・基盤：決済手数料、Open Payment Provider Fee、ホスティング、監視
• 運用：コンテンツ更新、API・アプリ保守
• 見積内訳：障害、問い合わせ、定期監視、仕様変更、データ補正、改善開発、セキュリティ確認

一般的な業務システムでは、保守運用費は初期費用の年15〜25%、または月15万〜80万円を起点にします。24時間監視や大規模な改善を含むと、この額は増えます。

2026年の人月単価の目安は、PMが90万〜150万円、SEが65万〜110万円、プログラマーが50万〜90万円、テスターが45万〜80万円です。見積では、単価と合わせて担当範囲と成果物を確認します。

BigCommerceの見積もりを取る際のポイント

見積は、合計額だけでなく、要件の抜けや連携の責任範囲、納品後の運用体制まで含めて見ます。「一式」と書かれた項目は、対象データや回数、エラー対応、成果物が曖昧になりやすいため、注意が必要です。

RFPに書く業務シナリオとデータ項目

提案依頼書には、会社概要や希望納期に加えて、規模、取引、システム、移行、権限の条件を書きます。

• 規模：商品数・SKU数、顧客数、年間GMV、月間・ピーク時の注文数
• 商取引：国・通貨、決済、配送、税、B2B会社階層、顧客別価格、掛率、最小ロット
• 業務：見積・承認、注文書、請求書、営業担当の代理注文

通常注文のほか、キャンセルや返品、在庫切れ、決済失敗、価格例外、顧客審査、外部停止の場面でもシナリオを作り、データの流れを示します。

納品物には、要件定義書と画面・API仕様書、テスト仕様と証跡を含めるよう依頼します。加えて、移行手順と運用手順も求めます。さらに、環境設定やソースコード、権限一覧も依頼に含めておくと、各社の提案を同じ条件で比べられます。

開発会社の実績と体制による比較

パートナーバッジの有無だけでなく、実績の規模、開発範囲、稼働後の対応体制を見比べます。

• 実績の近さ：商品点数やGMV、B2Bの複雑さ、連携数で見た自社との近さ
• 開発範囲：標準機能と個別開発の分け方
• 運用体制：価格・在庫の不整合時の復旧ログ、保守担当、SLA

公開事例のひとつとして、Videconは約4万商品・300ブランドのB2Bカタログを運用しています。

この事例では、BigCommerce B2B Edition、NetSuite、Google Cloudの連携層を使い、商品・価格・在庫・顧客アカウントを同期しています。

公開事例では、コンバージョン率が217%増、顧客獲得コストが93%減、申請から初回注文までが20〜40分と示されています。

これはVidecon固有の結果であり、自社の効果を保証するものではありません（出典: BigCommerce公式Videcon Case Study、2026年）。

Banner Solutionsの公式事例では、Catalystのヘッドレスフロントや、ERP、検索、CMSなど20以上の技術を統合しています。約50万商品と20万顧客を支える構成です。

高度な構成ほど自由度は上がります。一方で、運用範囲も広がり、フロントのホスティングやAPI、検索、認証、監視を自社または開発会社が運用します。

発注側は、事例の規模だけで選ばず、自社に必要な複雑さかどうかを見極めます。

見積と契約に含める、セキュリティ・契約・責任分界

見積を取る前に、カード情報と個人情報の流れと、その取り扱い責任を確認します。

• カード情報：PCI DSS準拠でも残る責任と、アプリが直接扱う場合のPCI対応・管理範囲
• 決済経路：BigCommerceに渡すか、決済会社のホスト画面へ遷移するかで変わる責任と、見積前のデータフロー図
• 個人情報：アクセス権、管理者、ログ、暗号化、バックアップ、障害通知、削除、海外保管、委託・再委託の確認

個人情報保護委員会のガイドラインでは、委託先の選定や契約、取扱状況の把握が示されています。さらに、再委託先の事前報告・承認や監査の確認も望ましいとされています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

契約には、ソースコードとAPI仕様を含む納品物を明記します。テストコードやIaCも、納品物の範囲に入れます。環境設定や移行データも、契約で範囲を決めておきます。

また、著作権・翻案権や再委託、SLAも契約に書きます。障害責任や変更単価、終了時の引き継ぎは、契約条件として書きます。

開発費を支払ったからといって、ソースコードや著作権が移るとは限りません。そのため、納品物と利用権を個別に定めておきます。

よくある質問（FAQ）

BigCommerceのシステム開発を検討する企業から寄せられやすい質問に答えます。料金や機能の適用条件は契約プランや更新で変わるため、最終的には公式情報と個別見積で確かめます。

BigCommerceのシステム開発にはどのくらいの期間がかかりますか？

標準テーマ、基本設定、簡易移行なら1〜3か月程度、標準ECにデザイン調整と数個の連携を加える場合は3〜6か月程度が目安です。

B2B Edition、複数基幹連携、ヘッドレス、移行リハーサルを含む場合は、6〜18か月程度になる可能性があります。

BigCommerceはヘッドレスで構築したほうがよいですか？

ヘッドレスの要否は、目的と運用体制によって変わります。短期導入で標準機能を中心に、少人数で運用するならStencilが候補になります。

独自のブランド体験や複数チャネル、コンポーザブルな拡張、フロントの開発体制があるなら、Catalystやカスタムヘッドレスが候補です。

GraphQLの対応範囲やチェックアウト、CMS、検索、監視、ホスティング費まで含めて比べます。

日本向けの決済・税・個人情報にも対応できますか？

対応は可能ですが、標準機能で全てがそろうとは限りません。そのため、要件ごとに分けて考えます。

• 国内決済と消費税：表示と計算を、標準機能で足りるかどうか確かめる
• 配送条件：配送の条件を要件として整理する
• 請求書：請求書の要件を整理する
• 返品：返品の扱いを要件として整理する
• 個人情報の権限管理：個人情報を扱う権限の範囲を要件として整理する

どの処理を標準機能、決済プロバイダー、アプリ、外部基幹のどこで行うかを、先に決めます。そのうえで、カード情報の保管先や委託先・再委託先の監督方法を、契約前に確認します。

既存のERPや在庫システムと連携するときの注意点は何ですか？

まず、商品、価格、在庫、顧客、注文の正データを一つずつ決めます。そのうえで、API・Webhook・バッチの方式や、重複処理、失敗時の再送、差分照合、手動復旧、監査ログを設計します。

通常注文に加えて、キャンセル、返品、在庫切れ、価格変更、連携停止もテストケースに含めます。

まとめ

BigCommerce開発では、業務要件、データの正、標準機能と個別開発の境界、連携障害への対応を、先に決めておきます。そのうえで、6つのフェーズごとに成果物と判断基準を合意します。

発注前に確認する最終チェックリスト

発注前には、規模や正データ、業務シナリオといった前提から、方式選定、責任分界、移行、テスト、保守まで、条件を順に確かめます。

• 規模とデータ：年間GMV、ピーク注文数、商品・価格・在庫・顧客・注文の正
• 業務と方式：B2C・B2Bシナリオ、Stencil・Catalyst・ヘッドレスの選定理由
• 移行と運用：決済・税・配送・返品の責任、移行とリハーサル、テスト条件、保守・SLA・引継ぎ

条件があいまいな安い見積は、追加費用や納期延長につながる可能性があります。

代表注文を使った小さな検証からの開始

発注前には、検証範囲、標準機能と個別開発の境界、導入後の総費用を整理しておきます。

• 検証シナリオ：代表商品、通常・法人顧客、価格例外、在庫切れ、決済失敗で見るFit to Standardの境界
• 導入範囲：標準機能で短期導入する部分と、競争力に関わる個別開発の切り分け
• 費用判断：プラットフォーム、決済・GMV、構築、連携、保守を合算した総費用

BigCommerceを販売チャネルと業務システムの中核に設計すると、基幹との責任分界を保ちながら、段階的な機能拡張につなげられます。

▼全体ガイドの記事
・BigCommerceのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。