commercetoolsのシステム開発の発注/外注/依頼/委託方法について

commercetoolsのシステム発注では、プラットフォーム契約だけでなく、フロントエンド、基幹連携、データ移行、テスト、運用まで含めた開発範囲を先に定義することが成功の近道です。

commercetoolsは、商品・価格・カート・注文などのコマース機能をAPIで組み合わせるヘッドレス型の基盤です。そのため、一般的なECサイト制作のように画面だけを依頼すると、PIM・ERP・OMS・在庫・決済との連携や、移行後の運用が見積もりから抜けることがあります。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較のポイントを、2026年時点の情報を踏まえて解説します。

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

commercetoolsのシステムを発注する前に知るべき全体像

最初に押さえたいのは、commercetoolsの導入と、commercetoolsを使った業務システムの開発は別の契約・作業になりやすいことです。公式料金ページでは、注文ベースの料金体系に加えて、Checkout、B2B API、追加リージョン、コネクター、監査ログ、性能テストなどを追加できる設計が案内されています。自社が依頼する実装会社の費用やクラウド費用は、このプラットフォーム料金とは分けて考える必要があります。出典はcommercetools公式「Composable Commerce Pricing Plans」、2026年の公式情報です。

発注対象には、要件定義、業務フロー設計、UX設計、フロントエンド、BFFやAPIゲートウェイ、commercetoolsの設定、PIM・ERP・OMS・WMS・検索・決済との連携、既存ECからのデータ移行、SEOリダイレクト、負荷試験、セキュリティ試験、リリース、監視、保守引き継ぎが含まれます。たとえば商品情報をPIM、在庫と会計をERP、配送指示をOMSに置く場合は、どのシステムを正本とするか、更新の順番、失敗時の再送、重複注文を防ぐ冪等性まで決める必要があります。

複数ブランド・多地域・多通貨を展開したい企業、B2CとB2Bを同じコマース基盤で進化させたい企業、既存の基幹システムを活かしながら販売チャネルを増やしたい企業には、commercetoolsの柔軟性が活きやすいです。一方、単一店舗で商品数や業務ルールが少なく、早く安くECを始めたい企業では、画面・受注・決済が一体になったEC SaaSやパッケージの方が合理的な場合があります。発注前に「高いか安いか」だけでなく、3年後に追加チャネルや海外展開をする可能性まで含めて比較することが大切です。

commercetoolsの発注形態はどのように選びますか？

結論として、要件が固まっていて納期と成果物を固定したい部分は請負、要件を検証しながら進める部分は準委任やラボ型、全体を一括して管理したい場合はハイブリッドが選びやすいです。commercetoolsは周辺システムの設計によって難易度が変わるため、全工程を一つの契約方式に押し込めるより、探索・開発・運用の不確実性に合わせて分ける方が、追加費用や責任範囲を説明しやすくなります。

請負契約は、受託者が合意した成果物を完成させ、発注者がその対価を支払う形です。画面一覧、API仕様、データ移行件数、受入基準、テスト項目、納品物が明確な工程であれば、予算と納期を管理しやすいです。たとえば、決められた商品・価格・カート・注文のMVPや、既存データの変換スクリプトなどは、成果物を定義して請負にしやすい領域です。ただし、業務ルールが未確定のまま請負にすると、変更のたびに追加見積もりとなり、発注者と開発会社の双方に負担がかかります。

準委任契約は、専門人材が一定期間業務を遂行することに対して報酬を支払う形です。PoC、要件定義、アーキテクチャ検討、継続的な機能改善のように、成果物の詳細や優先順位が変わる工程に向いています。月ごとの稼働時間、担当ロール、定例会議、成果の確認方法、品質基準を合意しておくと、柔軟性を保ちながら進捗を管理できます。ラボ型開発を選ぶ場合も、チームが何人いるかだけでなく、プロダクトオーナーの意思決定、コードレビュー、テスト自動化、ドキュメントの残し方を確認することが重要です。

実務では、最初に4〜8週間程度のDiscoveryやPoCを準委任で実施し、その結果をもとにMVPの実装を請負または準委任で発注する方法が現実的です。探索では商品・価格・会員・注文のデータモデル、外部連携の難所、ピーク負荷、移行方式を検証します。検証結果を受けて画面一覧、API境界、移行対象、受入基準が固まったら、工程ごとに価格と納期を決めます。こうすると、初期段階で不確実性を無理に固定せず、実装段階では予算の根拠を持たせられます。

RFPと要件整理は何を決めてから依頼しますか？

RFPは、単なる機能一覧ではなく、事業目的、現状の課題、対象範囲、前提条件、非機能要件、納品物、評価方法を候補会社へ同じ条件で伝える文書です。commercetoolsでは、システム境界とデータの責任分担が見積もりを大きく左右します。先に「何を作るか」だけでなく、「何をcommercetoolsに置き、何を外部システムに置くか」を決めることが、比較できるRFPを作るポイントです。

まず、売上、転換率、平均注文単価、受注処理時間、在庫精度、問い合わせ件数、海外展開までの期間など、改善したい指標を書きます。次に、商品数とSKU数、会員数、年間・月間・ピーク時の注文数、対象ブランド、国・通貨・言語、販売チャネル、法人顧客の有無を整理します。数字が不明な場合は、現行システムのログや受注データから最低値・平均値・ピーク値を分けて提示します。注文数だけでなく、商品更新回数や価格計算、在庫同期の頻度も、連携方式と運用費用に影響します。

商品・カテゴリ・商品画像はPIM、顧客・在庫・会計はERPやOMS、決済はPSP、検索は検索サービスというように、各データの正本を決めます。commercetoolsのProduct、Price、Cart、Orderなどをどこまで使うのか、既存のマスタをどのタイミングで同期するのか、業務担当者はMerchant Centerを使うのか、独自管理画面を作るのかもRFPに含めます。API、Webhook、イベント、バッチ、ミドルウェアのどれを使うかは候補会社の提案に任せても、データの責任者と業務上の正解は発注者側で示す必要があります。

機能要件だけでなく、応答時間、可用性、ピーク時の注文処理、障害通知、RTO・RPO、ログ保存期間、権限、暗号化、脆弱性対応、監査要件を記載します。移行では、商品、価格、画像、会員、注文履歴、ポイント、クーポン、SEO用URLとメタ情報を対象にするか、件数と品質基準を明示します。納品条件には、ソースコード、インフラ設定、IaC、CI/CD、テストコード、移行スクリプト、API仕様書、運用手順書、管理者教育、他社への引き継ぎを含めます。これらがない見積もりは初期費用が安く見えても、公開後に自社で作り直す費用が発生しやすいです。

発注からリリースまでの進め方

発注後は、Discovery、PoC、要件定義、設計、開発、データ移行、テスト、段階リリース、運用移管の順に進めると、課題を早期に発見できます。すべての機能を一度に完成させるビッグバン方式ではなく、事業インパクトと技術リスクの大きさで順番を決めます。commercetools公式のL.L.Bean事例でも、ゲストのチェックアウト、登録会員、カタログ・検索などを段階的に移行し、トラフィックを少しずつ切り替えています。

最初の検証では、代表的な商品を数件登録するだけでは不十分です。複雑なバリエーション、地域別価格、法人別価格、在庫引当、割引の組み合わせ、返品、決済失敗、注文キャンセルなど、実際に問題が起きやすいケースを選びます。ERPやPIMとの接続では、正常系だけでなくタイムアウト、順序逆転、同一イベントの重複、部分的な失敗を確認します。PoCの成果物として、採用する構成、未解決の課題、追加費用の条件、本番移行までの仮説を残すと、次の見積もりが具体的になります。

設計段階では、フロントエンド、BFF、commercetools、PIM・ERP・OMS・PSP、検索、CDN、監視の関係を図にします。各連携について、送信元、受信先、データ項目、認証、同期頻度、失敗時の再送、重複防止、担当者を一覧にします。開発会社がcommercetoolsの設定を担当しても、PIMのマスタ整備やERP側の改修まで自動的に含まれるわけではありません。発注者側の情報システム部門、業務部門、既存ベンダーとの役割をRACIなどで合意しておくと、工程途中の責任の押し付け合いを防げます。

テストは単体・結合・総合・受入だけで終わらせず、性能、障害復旧、権限、セキュリティ、データ移行、SEO、運用手順まで確認します。特にECでは、注文が通ることだけでなく、在庫が二重に引き当てられないこと、決済成功後に注文が欠落しないこと、キャンセルが各システムに伝わることを確認します。移行は本番直前に一度だけ行わず、複数回のdry-runで件数差分、文字コード、画像、URL、会員認証を検証します。公開時は、カナリアリリース、機能フラグ、トラフィックの段階的な切り替え、切り戻し条件を用意します。

契約形態と発注時に確認する責任範囲

commercetoolsの開発委託では、開発会社との契約だけでなく、commercetools本体、クラウド、決済、検索、PIMなど複数のサービス契約が関係します。誰がどの契約を締結し、障害時にどこへ連絡し、データやソースコードを誰が保有するかを明記します。契約の名前だけで判断せず、対象工程ごとの成果物、検収方法、変更管理、再委託、秘密保持、個人情報、終了時のデータ返却を確認することが大切です。

契約を分ける場合は、Discoveryと要件定義を準委任、確定したMVPの開発を請負、公開後の改善と運用を準委任にする考え方があります。請負部分には、完成の定義、受入テスト、瑕疵対応の範囲、仕様変更の手続き、遅延時の扱いを記載します。準委任部分には、稼働時間、担当スキル、月次報告、バックログの優先順位、品質を確認する指標を記載します。契約方式を適切に選ぶと、発注者が必要な意思決定を先送りしたまま、開発会社だけに納期責任を負わせる状態を避けられます。

commercetools側のセキュリティ統制を確認しても、自社のフロントエンド、BFF、外部連携、管理者端末まで安全になるわけではありません。2025年のcommercetools公式セキュリティ白書では、インフラ、運用、データ、製品、事業継続・災害復旧、コンプライアンスを含む共有責任モデルが示されています。出典はcommercetools公式「Security White Paper 2025」、2025年の公式情報です。契約では、脆弱性の報告期限、ログの保管場所と期間、アクセス権限、再委託先、海外でのデータ取り扱い、個人情報の削除、インシデント時の連絡体制を確認します。

発注先を将来変更できる状態にするには、ソースコードだけでなく、インフラの構成情報、CI/CD設定、環境変数の管理方法、API仕様、データマッピング、移行スクリプト、テスト結果、障害履歴、監視設定、運用Runbookまで納品対象にします。リポジトリやクラウドアカウントを開発会社の所有にすると、契約終了時の移管が難しくなることがあります。発注者名義のアカウント、最小権限のアクセス、定期的なバックアップ、第三者が再現できる構築手順を契約と運用の両方で整えます。

commercetoolsのシステム開発費用相場と内訳

commercetoolsの導入費用は、公式の一律価格として断定できません。公式ページでは、注文ベースのプランに、B2B API、Checkout、追加リージョン、コネクター、監査ログ、性能テストなどを組み合わせて個別に設計する形が案内されています。以下は、リサーチノートにある一般的な業務システム相場と、フロントエンド・API連携・移行を伴うコンポーザブル構成の工数から整理した、実装費の推定レンジです。commercetools本体の利用料、クラウド、決済手数料、外部SaaSは別に見積もります。

検証・PoCは500万〜1,500万円、期間は2〜4か月が一つの目安です。代表的な商品・価格・カート・決済連携、簡易フロント、APIや性能の検証を行う範囲で、60日無料トライアルを利用できる場合もありますが、トライアルは本番構築費や本契約料金が無料になることを意味しません。

単一ブランドのB2C向けMVPは1,500万〜3,000万円、4〜8か月程度が目安です。商品、会員、カート、注文、基本決済、配送、管理画面、最低限の移行と監視を含む想定です。既存ECからのリプレースでPIM・ERP・OMS・在庫・配送・PSPを連携し、多言語・多通貨、数万〜数十万件の移行、負荷試験まで行う場合は3,000万〜8,000万円、8〜14か月程度を見込みます。大規模B2B、多ブランド、多地域、法人階層、顧客別価格、承認・見積、24時間運用まで含めると、8,000万〜2億円超、12〜24か月以上になる可能性があります。いずれも公式価格ではなく、要件に基づく推定レンジです。

費用は、プラットフォーム利用料、実装・設定、データ移行・連携、テスト・教育、運用保守の箱に分けます。実装費の中でも、要件定義・業務設計を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月のcommercetools公式発表では、カート、注文管理、商品カタログなどを個別に導入し、全面的なリプラットフォームを避けるモジュール型の提供が案内されています。導入を小さくしても、将来のデータモデル、認証、API境界、監視方針を最初に設計することが重要です。

また、発注者が用意できるものと委託先へ任せるものを分けます。商品データの整理、業務ルールの決定、社内の受入担当、既存ベンダーとの調整を発注者が担えば、開発会社の調査工数を減らせます。ただし、社内負担をゼロ円として扱うのは危険です。社内担当者の稼働やデータクレンジングの時間もTCOに含め、MVPの見積もりと本番運用の見積もりを別々に確認します。

委託先の選定と見積比較で見るべきポイント

委託先は、ECサイトを作った会社というだけでなく、commercetoolsのデータモデル、API、周辺連携、移行、性能試験、運用移管を実行できる会社を選びます。公式パートナーランクは候補を絞る材料になりますが、ランクだけで自社案件への適性は判断できません。提案時の質問に対して、具体的な設計、リスク、代替案、発注者側の作業を説明できるかを重視します。

確認したい実績は、導入社数やパートナーランクだけではありません。自社と近い商品数、注文量、ブランド数、国、B2B要件、PIM・ERP・OMS・PSPの構成、移行件数、ピーク負荷、公開後の運用体制を尋ねます。可能であれば、実績の説明を営業資料だけでなく、担当予定のアーキテクトやPMから聞きます。日本語の窓口、国内の障害対応時間、再委託先の所在、保守を別会社へ移す場合の手順も、候補会社の比較項目に含めます。

見積比較では、合計額を並べる前に、同じ前提で作られているかを確認します。commercetoolsの利用料、追加リージョン、B2B APIやCheckoutなどのアドオン、クラウド、CDN、検索、監視、決済、PIM、移行、教育、保守が含まれているかをチェックします。商品・会員・注文の移行件数、データクレンジング、旧URLのリダイレクト、ピーク時の負荷試験、脆弱性診断が「別途」になっていないかも重要です。

候補会社には同じRFPを渡し、工程別の人員、期間、成果物、検収条件、リスク、発注者側の作業を記載してもらいます。提案を点数化する場合は、要件適合、類似実績、技術・連携力、移行計画、運用体制、セキュリティ、費用透明性、コミュニケーションを分けます。金額の安さだけでなく、未確定事項を正直に書いているか、追加費用の発生条件を説明しているかを見れば、契約後の予算変動を予測しやすくなります。

事例の数字は、自社の成果を保証するものではなく、発注設計のヒントとして使います。commercetools公式の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年の公式情報です。このような数字をそのまま見積もりに置くのではなく、段階移行、データ同期、チーム体制、業務側の準備が成果を支えた点に注目します。

見積もりの打ち合わせでは、「自社でも同じ期間でできますか」と聞くより、「どの機能を先に切り出せますか」「どのデータを先に移行できますか」「公開後に切り戻す条件は何ですか」「発注者が準備するデータは何ですか」と質問します。事例の規模が自社より大きくても、リスクを小さな工程に分解する考え方を持ち帰れます。

発注者側には、事業責任者、業務部門の代表、情報システム責任者、データ担当、法務・セキュリティ、既存システムの担当者を置きます。誰が価格ルールを決めるのか、誰が顧客データの正しさを承認するのか、誰がリリースを止められるのかを明確にします。開発会社に丸投げすると、技術的には動いても、業務担当者が使えない、データが更新できない、障害時に判断できないという問題が起きやすいです。

候補会社を決めた後も、月次の経営報告、週次のプロジェクト会議、日々のバックログ管理を分けると、重要な判断が埋もれにくくなります。スコープ、納期、費用、品質のどれを優先するかを変更管理のルールとして合意し、追加機能を入れる場合は、公開時期やテスト範囲への影響まで確認します。

よくある質問

ここでは、commercetoolsのシステムを発注・外注するときに、特に相談が多い疑問へ回答します。費用や期間は要件と体制で変わるため、回答のレンジを自社のRFPに置き換えて確認してください。

検証・PoCだけであれば、500万〜1,500万円程度の推定レンジから検討するケースがあります。単一ブランドのMVPでは1,500万〜3,000万円程度が一つの目安ですが、これはcommercetools本体の料金、クラウド、決済、PIMなどを含まない実装中心の推定です。安い見積もりを探すより、対象機能、移行件数、連携先、テスト、納品物の範囲を揃えて比較することが重要です。

技術的な設計・実装・テストを委託することはできますが、事業目標、業務ルール、商品や顧客データの正しさ、予算と優先順位の決定まで丸投げすることはおすすめできません。発注者側に意思決定者と業務担当を置き、開発会社には構成案、リスク、必要な社内作業を提示してもらいます。特にPIM・ERP・OMSの既存担当者との調整は、発注者が主導する方がスムーズです。

単一チャネルで標準的な販売業務を早く始めたい場合は、画面や受注管理が一体化したEC SaaSの方が初期費用と運用負担を抑えやすいです。複数ブランド・多地域・B2B、既存基幹との複雑な連携、チャネル追加を継続する場合は、APIで機能を組み替えられるcommercetoolsを候補にします。初期費用だけでなく、3〜5年のライセンス、開発、移行、保守、機能追加、社内人材の総額で比較してください。

カード情報は自社のバックエンドに保存せず、PSPのトークン化やホスト型の決済UIを利用できるかを確認します。OAuth 2.0のAPIクライアント、最小権限、暗号化、監査ログ、ログへの個人情報混入防止、脆弱性対応、障害時の連絡体制も要件に入れます。個人情報保護法上の委託先管理や海外での取り扱い、PCI DSSの適用範囲は、法務・セキュリティ担当や専門家と確認し、開発会社の提案だけで判断しないことが大切です。

まとめ

commercetoolsのシステムを発注・外注するときは、プラットフォームの契約だけでなく、画面、業務連携、データ移行、性能・セキュリティ試験、運用保守までを一つの全体像として整理します。発注形態は、要件が固まった部分を請負、検証と改善が必要な部分を準委任とするなど、工程の不確実性に合わせて選ぶと管理しやすいです。

最低限、事業目標、対象チャネル、商品・会員・注文の規模、正本データ、連携先、移行対象、非機能要件、希望時期、社内の担当者を整理します。情報がすべて揃っていなくても、未確定事項として候補会社に渡し、DiscoveryやPoCで検証する項目を分ければ発注を始められます。費用の推定レンジも、これらの前提があるほど比較しやすくなります。

最初から全ブランド・全地域を移行するのではなく、代表的な商品、注文、決済、在庫連携を使って、技術と業務の難所を確認します。PoCの結果をもとにMVPの成果物と受入基準を定め、公開後の改善・保守まで含めた計画へつなげます。段階導入は、初期費用を無条件に下げる方法ではありませんが、リスクと学習を工程ごとに分け、予算の根拠を更新しやすくする方法です。

RFPでは事業目標、商品・注文・会員の規模、正本データ、外部連携、非機能、移行、納品物を明記します。見積もりは、プラットフォーム利用料、実装、連携・移行、テスト・教育、保守を分離し、推定レンジの前提と除外項目を比較します。最後に、commercetoolsの実績だけでなく、担当予定チームの設計力、段階移行の経験、日本語の運用体制、障害対応、他社への保守移管まで確認することが、発注後の手戻りを減らします。

まずは自社の現行システムと業務課題を棚卸しし、全置換ではなくPoCやMVPで検証する範囲を決めてください。発注前に要件と責任範囲を言語化できれば、commercetoolsの柔軟性を活かしながら、費用・納期・品質のバランスを取った開発計画を立てやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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