commercetoolsの発注は、要件を整理し、契約範囲を工程ごとに分け、検証と移行を段階的に進めると、予算と責任範囲を管理しながら導入できます。
発注形態、RFPと要件整理、契約と費用、リリースまでの流れを、この順に説明します。全体像は下の▼の記事でも確認できます。
▼全体ガイドの記事
・commercetoolsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
commercetoolsのシステムを発注する前に知るべき全体像
commercetoolsは、商品・価格・カート・注文などをAPIで組み合わせて使うヘッドレス型の基盤です。画面だけを依頼すると、周辺の連携や移行後の運用が見積もりから漏れることがあります。導入契約と業務システム開発は、別の契約や作業になりやすい点にも注意が必要です。
注文ベースの料金に加えて、Checkout、B2B API、追加リージョンなどを追加できます。さらに、コネクター、監査ログ、性能テストも追加の対象になります（出典：commercetools公式「Composable Commerce Pricing Plans」、2026年の公式情報）。実装会社の費用やクラウドの費用は、プラットフォームの料金と分けて見積もります。
発注対象の範囲
発注範囲には、設計から開発までに加えて、移行と試験を入れます。さらに、リリース、監視、保守の引き継ぎまで含めます。範囲が広いぶん、領域ごとに分けて見ると、どこまでを誰が受け持つかを確かめやすくなります。
- 設計と実装：要件定義、業務フロー、UX、フロントエンド、BFFやAPIゲートウェイ、commercetoolsの設定
- 連携と移行：PIM・ERP・OMS・WMS・検索・決済との連携、既存ECのデータ移行、SEOリダイレクト
- 試験と運用：負荷試験とセキュリティ試験、リリース、監視、保守の引き継ぎ
商品情報をPIM、在庫と会計をERP、配送指示をOMSに置く場合は、どれを正本とするか、どの順で更新するか、失敗時にどう再送するかを決めておきます。加えて、重複注文を防ぐ冪等性も押さえておきます。
向いている企業と慎重に比較したい企業
事業の展開範囲とEC業務の複雑さを照らし合わせ、基盤の柔軟性が必要かを判断します。
- 柔軟性を活かしやすい：複数ブランドや多地域、多通貨、B2CとB2Bの共存、既存の基幹を活かした販売チャネルの拡大を進める場合
- 他方式も比較したい：単一店舗で商品数や業務ルールが少なく、早く安く始めたい場合
後者では、画面・受注・決済が一体になったEC SaaSやパッケージが合理的な場合があります。比べるときは、目先の価格だけでなく、3年後のチャネル追加や海外展開の可能性も見ます。
commercetoolsの発注形態の選び方
成果物と納期を固定したい部分は請負、検証しながら進める部分は準委任やラボ型にすると、選びやすくなります。全体を一括で管理したい場合は、ハイブリッドが候補になります。
周辺システムの設計によって難易度は変わるため、探索・開発・運用それぞれの不確実性に合わせて契約を分けると、費用と責任範囲を一つずつ説明できます。
範囲と成果物を固定できる工程での請負契約
請負契約は、受託者が合意した成果物を完成させ、発注者が対価を支払う形です。成果物が明確な工程では、予算と納期の見通しが立ちます。対象範囲は、次のように定義します。
- 仕様：画面一覧、API仕様、データ移行の件数
- 完了条件：受入基準、テスト項目、納品物
- 適用例：仕様を定めた商品・価格・カート・注文のMVP、既存データの変換スクリプト
業務ルールが決まらないまま請負にすると、変更のたびに追加の見積もりが必要になり、発注者と開発会社の双方に負担がかかります。
検証しながら改善する工程での準委任・ラボ型
準委任契約は、専門人材が一定期間業務を行うことに対して報酬を支払う形です。成果物や優先順位が変わりやすい工程では、準委任が向いています。
- 対象工程：PoC、要件定義、アーキテクチャ検討、継続改善
- 合意事項：月ごとの稼働時間、担当ロール、定例会議、成果の確認方法、品質基準
- ラボ型の確認点：人数のほかに、プロダクトオーナーの意思決定、コードレビュー、テスト自動化、ドキュメントの残し方
合意事項を決めておけば、柔軟性を保ったまま進捗を管理できます。
探索と実装を分けるハイブリッド型
最初の4〜8週間程度でDiscoveryやPoCを準委任で行い、その結果をもとに、MVPを請負または準委任で発注する方法があります。探索では、商品・価格・会員・注文のデータモデルを検証します。さらに、外部連携の難所やピーク負荷、移行方式も確かめます。
画面一覧やAPI境界が決まり、移行対象と受入基準も固まったら、工程ごとに価格と納期を決めます。不確実性を初期に固定せず、実装段階の予算に根拠を持たせられます。
RFPと要件整理で決める事項
RFPは、機能一覧ではなく、候補会社に同じ条件を伝えるための文書です。事業目的や課題、対象範囲、前提を示すほか、非機能要件や納品物、評価方法も含みます。
システム境界とデータの責任分担は見積もりを左右するため、commercetoolsと外部システムのどちらに何を置くかを決めておくと、比べやすいRFPになります。
事業目標と対象範囲の数値
事業目標とシステム規模を示す数値は、次の観点で整理します。
- 改善指標：売上、転換率、平均注文単価、受注処理時間、在庫精度、問い合わせ件数、海外展開までの期間
- 対象規模：商品数・SKU数、会員数、年間・月間・ピーク時の注文数
- 販売条件：ブランド、国・通貨・言語、チャネル、法人顧客の有無
数値が分からない場合は、現行システムのログや受注データから、最低値・平均値・ピーク値に分けて示します。商品更新、価格計算、在庫同期の頻度も、連携方式と運用費用に影響します。
システム境界と正本データの明確化
データの置き場所と管理責任をはっきりさせるため、RFPには次の事項を記載します。
- データの正本：商品・カテゴリ・画像はPIM、顧客・在庫・会計はERPやOMS、決済はPSP、検索は検索サービス
- 基盤の範囲：commercetoolsのProduct、Price、Cart、Orderを使う範囲
- 運用方法：既存マスタの同期時期と、Merchant Centerか独自管理画面か
- 連携方式：API、Webhook、イベント、バッチ、ミドルウェアの選定は、候補会社に任せることもできます
- 発注者の責任：データの責任者と業務上の正解を、発注者が示します
RFPに盛り込む非機能・移行・納品条件
機能以外の要件が抜けないよう、試験、移行、納品の条件をまとめて示します。
- 非機能：応答時間、可用性、ピーク処理、障害通知、RTO・RPO、ログ期間、権限、暗号化、脆弱性対応、監査
- 移行：商品、価格、画像、会員、注文履歴、ポイント、クーポン、SEO用URL・メタ情報の対象、件数、品質基準
- 納品：ソース、インフラ設定、IaC、CI/CD、テストコード、移行スクリプト、API仕様、運用手順、教育、他社への引き継ぎ
これらが見積もりに入っていないと、初期費用は安く見えても、公開後に自社で作り直す費用が発生しやすくなります。
発注からリリースまでの進め方
発注後は、DiscoveryとPoCで探索したうえで、要件定義と設計、開発へ進みます。そのあとデータ移行とテストを行い、段階リリースと運用移管へ進めると、課題を早期に見つけやすくなります。
全機能を一度に完成させるビッグバン方式ではなく、事業インパクトと技術リスクをもとに順番を決めます。たとえば、公式のL.L.Bean事例では、チェックアウト、登録会員、カタログ・検索などを段階的に移行し、トラフィックを少しずつ切り替えています。
DiscoveryとPoCで検証する難所
検証では、実運用で問題になりやすい条件を選びます。代表商品を数件登録するだけだと、検証として足りなくなります。
- 商品・価格：複雑なバリエーション、地域別価格、法人別価格、割引の組み合わせ
- 注文・在庫：在庫引当、返品、決済失敗、注文キャンセル
- 連携異常：タイムアウト、順序逆転、イベント重複、部分的な失敗
PoCでは、ERPやPIMとの正常系だけでなく異常系も確かめます。そのうえで、採用構成と未解決課題を記録に残します。追加費用の条件や本番移行までの仮説も記録しておくと、次の見積もりが具体的になります。
設計と開発での責任分担の文書化
連携の仕様と全体構成を一覧にすると、作業範囲と確認点を関係者で共有できます。
- 連携一覧：送受信元、データ項目、認証、同期頻度、再送、重複防止、担当者を記録
- 構成図：フロントエンド、BFF、commercetools、PIM・ERP・OMS・PSP、検索、CDN、監視の関係を図で示す
commercetoolsの設定を委託しても、PIMのマスタ整備やERPの改修が自動的に含まれるとは限りません。そこで、情報システム、業務部門、既存ベンダーの役割を、RACIなどで合意しておくと、責任の押し付け合いを防げます。
移行リハーサルと段階リリース
テストでは、注文処理だけでなく、移行と運用まで確認します。確認は、試験、注文連携、公開準備の3つに分けて見ていきます。
- 試験：単体・結合・総合・受入、性能、障害復旧、権限、セキュリティ、データ移行、SEO、運用手順
- 注文連携：在庫の二重引当防止、決済後の注文欠落防止、キャンセル情報の伝達
- 公開準備：複数回のdry-run、件数差分・文字コード・画像・URL・会員認証の検証
公開時には、カナリアリリースや機能フラグを用意します。トラフィックの段階切替と、切り戻しの条件も決めておきます。
契約形態と発注時に確認する責任範囲
開発会社との契約に加えて、commercetools本体やクラウドのサービス契約も関係します。決済、検索、PIMなどの契約も、あわせて関わります。
契約書には、契約者、障害時の連絡先、データとソースコードの保有者を明記します。契約名だけでなく、工程別の成果物と検収、変更管理、再委託を確認します。さらに、秘密保持、個人情報、終了時のデータ返却も見ておきます。
工程ごとの請負と準委任の使い分け
Discoveryと要件定義は準委任で、確定したMVP開発は請負で、公開後の改善と運用は準委任で進める考え方があります。
- 請負部分：完成の定義、受入テスト、瑕疵対応、仕様変更、遅延時の扱い
- 準委任部分：稼働時間、担当スキル、月次報告、バックログ優先順位、品質指標
適切に使い分けると、発注者が意思決定を先送りしたまま、開発会社だけに納期の責任を負わせる事態を避けられます。
契約に含めるセキュリティとデータの取り扱い
commercetools側の統制があっても、自社のフロントエンドやBFF、外部連携、管理者端末までが安全になるとは限りません。なお、2025年の公式セキュリティ白書は共有責任モデルを示しています。
その範囲には、インフラや運用、データ、製品が入り、事業継続・災害復旧やコンプライアンスも含まれます（出典：commercetools公式「Security White Paper 2025」、2025年の公式情報）。
契約では、脆弱性の報告期限、ログの場所と期間、権限を確認します。加えて、再委託先と海外でのデータ取り扱いも見ておきます。さらに、個人情報の削除、インシデント時の連絡体制も確認します。
保守移管できる納品物の指定
将来の委託先の変更に備えて、ソースコード以外の引き継ぎ物も指定します。
- 構築情報：インフラ構成、CI/CD、環境変数の管理方法、API仕様、データマッピング
- 運用情報：移行スクリプト、テスト結果、障害履歴、監視設定、運用Runbook
- 引き継ぎ条件：発注者名義のアカウント、最小権限、定期バックアップ、第三者が再現できる構築手順
リポジトリやクラウドアカウントが開発会社の所有のままだと、契約終了時に移管が難しくなることがあります。そのため、契約と運用の両方で管理します。
commercetoolsのシステム開発費用相場と内訳
公式の一律価格では断定できません。注文ベースのプランに、B2B APIやCheckoutなどを組み合わせる形です。追加リージョン、コネクター、監査ログ、性能テストも、組み合わせの対象になります。
ここで示すのは、一般的な業務システムの相場と、フロントエンド・API連携・移行を伴う構成の工数から整理した、実装費の推定です。本体利用料やクラウド費用、決済手数料、外部SaaSは、別途見積もります。
規模別の費用と期間の目安
実装費と期間は要件と規模によって変わるため、範囲ごとに推定のレンジを見ます。
- 検証・PoC：500万〜1,500万円、2〜4か月
- 単一ブランドのB2C向けMVP：1,500万〜3,000万円、4〜8か月
- 既存ECのリプレース：3,000万〜8,000万円、8〜14か月
- 大規模B2B・多ブランド・多地域：8,000万〜2億円超、12〜24か月以上となる可能性
PoCは、代表商品・価格、カート・決済連携の検証を中心に想定しています。簡易フロントや、APIと性能の検証も含めます。60日間の無料トライアルを利用できる場合もあります。ただし、本番構築費や本契約料金が無料になるわけではありません。
MVPは、商品と会員、カート、注文などの機能を想定します。基本決済や配送、管理画面、最低限の移行と監視も含めて考えます。リプレースでは、PIM・ERP・OMS・在庫・配送・PSPとの連携、多言語・多通貨、数万〜数十万件の移行、負荷試験を含む場合があります。
大規模案件では、法人階層、顧客別価格、承認・見積、24時間運用まで含む可能性があります。いずれも公式価格ではなく、要件に基づく推定のレンジです。
見積もりを5項目に分けた比較
費用の項目と実装費の構成を分けて見ると、どこに金額が集中しているかを比べられます。
- 全体費用：プラットフォーム利用、実装・設定、移行・連携、テスト・教育、運用保守
- 要件定義・業務設計：実装費の10〜15%程度
- アーキテクチャ・UX・設計：20〜25%程度
- フロント・BFF・連携実装：35〜45%程度
- 移行・テスト・性能・セキュリティ：15〜25%程度
比率は固定の標準値ではなく、比べるための試算です。
一般的な業務システムの人月単価の目安は、PMが90万〜150万円、SEが65万〜110万円、PGが50万〜90万円程度です。人月単価は、専門パートナーや国内開発会社、外資系SIerのどこに頼むかで変わります。担当者の役割や日本語対応によっても変わるため、単価だけで優劣を決めません。
保守・改善は、初期開発費の年15〜25%、または月額数十万〜数百万円を仮置きして考えます。SLAや監視、障害対応を確認します。さらに、追加開発やクラウド、外部SaaSを分けて見ます。
費用を抑える段階導入と責任分担
初期の範囲を絞る方法と、発注者と委託先の作業分担を整理します。
- MVPから始める：全ブランド・地域・チャネルではなく、売上や業務負荷に直結する商品・価格・カート・注文を優先
- 作業を分担する：発注者が商品データ整理、業務ルール決定、受入担当、既存ベンダー調整を担い、開発会社の調査工数を減らす
2026年7月の公式発表では、カート、注文管理、商品カタログなどを個別に導入し、全面的なリプラットフォームを避けるモジュール型の提供が案内されています。
小さく導入する場合でも、将来のデータモデルや認証、API境界は先に設計しておきます。監視方針も決めておきます。また、社内の稼働やデータ整理も、TCOに含めて考えます。
社内の負担をゼロ円として扱うのは危険です。MVPの見積もりと本番運用の見積もりは、別々に確認します。
委託先の選定と見積比較で見るべきポイント
委託先は、EC制作の経験があるかだけでなく、実際に進められるかで選びます。進められるかの中身は、データモデルやAPI、周辺連携、移行、性能試験、運用移管です。
公式パートナーランクは候補を絞る材料になりますが、それだけで適性は判断できません。設計、リスク、代替案、発注者側の作業を、具体的に説明できるかを見ます。
実績と自社案件との類似性
導入社数やパートナーランクだけでなく、自社案件との類似性を確認します。
- 事業規模と要件：商品数、注文量、ブランド数、国、B2B要件
- 技術と移行：PIM・ERP・OMS・PSP構成、移行件数、ピーク負荷
- 運用体制：公開後の体制、日本語窓口、国内障害対応時間、再委託先の所在、保守移管手順
可能なら営業資料だけでなく、担当予定のアーキテクトやPMから実績を聞きます。
見積金額の前提と除外項目
合計額を比べる前に、見積もりの前提と含まれる範囲を揃えます。
- 利用・環境：利用料、追加リージョン、B2B API・Checkoutなどのアドオン、クラウド、CDN、検索、監視、決済、PIM
- 作業範囲：移行、教育、保守、移行件数、データクレンジング、旧URLリダイレクト
- 試験：ピーク時の負荷試験、脆弱性診断が別途になっていないか
各社に同じRFPを渡し、工程別の人員と期間、成果物を記載してもらいます。検収条件、リスク、発注者側の作業も書いてもらいます。
点数化する場合は、要件適合、類似実績、技術・連携力を分けて評価します。移行計画や運用は、別の項目として分けます。セキュリティ、費用の透明性、コミュニケーションも、項目ごとに見ます。
未確定事項と追加費用の条件を正直に説明する提案であれば、契約後の予算の変動を予測しやすくなります。
事例から読み取る進め方と条件
事例の数字は成果を保証するものではなく、発注設計の参考として扱います。2025年の公式顧客事例には、次の実績があります。
- L.L.Bean：25万SKUと550万顧客アカウントを移行し、100以上の機能改善で1,000万米ドル超の増収を報告
- LabelVie Group：B2Bブランドのモバイルコマースを5か月で立ち上げ、公式事例でNPS71を紹介
出典は、commercetools公式「The Top 15 commercetools Customer Stories of 2025」です。これは2025年の公式情報です。
数字をそのまま見積もりに当てはめるのではなく、段階移行、データ同期、チーム体制、業務側の準備に注目します。
打ち合わせでは、先行できる機能やデータ、切り戻しの条件、発注者が準備するデータを質問します。また、規模が異なる事例からも、リスクを小さな工程に分ける考え方を読み取れます。
発注者側の体制づくり
システム導入の判断が滞らないよう、業務・技術・統制の担当者を揃えます。
- 事業・業務：事業責任者、業務部門の代表
- システム・データ：情報システム責任者、データ担当、既存システム担当者
- 統制：法務・セキュリティ担当
価格ルールの決定者、顧客データの承認者、リリースを止める判断者も定めておきます。
丸投げすると、技術的には動いても、業務担当者が使えない、データを更新できない、障害時に判断できないといった問題が起きやすくなります。
月次の経営報告、週次会議、日々のバックログ管理を分けておくと、重要な判断が埋もれにくくなります。
スコープ、納期、費用、品質の優先順位は、変更管理のルールとして合意しておきます。追加機能を入れる場合は、公開時期やテスト範囲への影響も確認します。
よくある質問
費用や期間は、要件と体制によって変わります。ここに示す回答のレンジは、自社のRFPに置き換えて確認してください。
commercetoolsのシステム開発は最低いくらから発注できますか？
検証・PoCは、500万〜1,500万円程度の推定レンジから検討する場合があります。単一ブランドのMVPは、1,500万〜3,000万円程度が目安です。
このMVPの推定は実装が中心で、本体料金やクラウド、決済、PIMなどは含みません。比べる際は、対象機能と移行件数、連携先をそろえます。試験や納品物も、同じ条件で揃えます。
開発会社への丸投げでcommercetoolsを導入できますか？
技術設計・実装・テストは委託できます。一方で、事業目標、業務ルール、商品や顧客データの正しさ、予算と優先順位の決定まで丸投げすることは、おすすめできません。
発注者側に意思決定者と業務担当を置き、開発会社には構成案、リスク、必要な社内作業を示してもらいます。PIM・ERP・OMSの既存担当との調整は、発注者が主導すると進めやすくなります。
commercetoolsとEC SaaSはどのように比較すればよいですか？
単一チャネルで標準的な販売業務を早く始める場合は、画面や受注管理が一体になったEC SaaSが、初期費用と運用負担を抑えやすいです。
複数ブランド・多地域・B2B、複雑な基幹連携、継続的なチャネル追加では、APIで機能を組み替えられるcommercetoolsを候補にします。
初期費用だけでなく、3〜5年分の総額で比べます。ライセンスや開発、移行の費用を含めます。さらに、保守や機能追加、社内人材の費用も見ます。
決済情報や個人情報を扱う場合に何を確認しますか？
カード情報を自社のバックエンドに保存せず、PSPのトークン化やホスト型決済UIを使えるかを確認します。
さらに、OAuth 2.0のAPIクライアントや最小権限、暗号化を要件に入れます。監査ログや個人情報のログ混入防止、脆弱性対応、障害時の連絡体制も、要件に含めます。
個人情報保護法上の委託先管理や海外での取り扱い、PCI DSSの適用範囲は、法務・セキュリティ担当や専門家と確認します。開発会社の提案だけで判断するものではありません。
まとめ
発注時は、プラットフォームの契約だけでなく、画面や業務連携を含めた全体を整理します。移行や性能・セキュリティ試験、運用保守も、同じ一覧に入れます。
工程の不確実性に合わせて、要件が確定した部分は請負、検証と改善が必要な部分は準委任にするなど、発注形態を選びます。
発注前に揃える情報
事業目標と対象チャネル、商品・会員・注文の規模、正本データを整理します。さらに、連携先と移行対象、非機能を整理します。希望時期と社内担当も、そろえておきます。
未確定事項も候補会社に示し、DiscoveryやPoCで検証する項目を分ければ、発注を始められます。前提が揃うほど、費用の推定レンジを並べて比べられます。
小さな検証から広げる発注範囲
発注範囲を広げる前に、検証と委託先選定に必要な判断材料を整理します。
- 現行システムと業務課題を洗い出し、全面置き換えではなく、PoCやMVPで検証する範囲を決めて、代表商品・注文・決済・在庫連携の難所を確かめ、受入基準を決めます。
- RFPには、事業目標と規模、正本データ、外部連携、非機能、移行、納品物を書き、要件と責任範囲を言葉にして残します。
- 見積もりは、利用料、実装、連携・移行、試験・教育、保守に分け、推定の前提と除外項目を比べて、費用・納期・品質のバランスを図ります。
- 担当チームの設計力や段階移行の経験に加えて、日本語の運用体制、障害対応、他社への保守移管も確かめます。
- 公開後の改善と保守も計画に含め、段階導入で初期費用が必ず下がるとは限らないものの、リスクと学習を分けて予算の根拠を後から更新できるようにします。
▼全体ガイドの記事
・commercetoolsのシステム開発の完全ガイド
▼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を創業。