SAP Commerce Cloudの発注は、販売業務と連携範囲を整理し、発注形態を決めたうえで、要件整理、開発、契約、委託先の選定へと進みます。
標準機能と独自開発を分けて段階的に委託すると、責任範囲と予算を管理しやすくなります。
▼全体ガイドの記事
・SAP Commerce Cloudのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SAP Commerce Cloudの発注・外注の全体像
画面開発だけを切り出すと、後から連携や業務ルールの抜けが見つかりやすくなります。そのため、最初に商品から出荷経路までを業務フローにまとめ、システムの責任範囲を決めます。
販売業務基盤としての発注範囲
SAP Commerce Cloudは、B2Cの会員、検索、販促に加えて、決済やチェックアウトにも対応します。
B2Bでは、企業組織や権限、購買承認を扱うほか、得意先別価格や見積、再注文にも対応できます。
SAP S/4HANAやSAP ERPと連携すると、商品や価格、在庫の情報を受注、出荷、請求まで一貫させやすくなります。
WMSや配送、決済のほか、PIMやCMS、CRMも関係します。そのため、委託先にはフロントエンドの開発力だけでなく、業務データ設計と連携運用の力が求められます。
- 販売条件：チャネル、対象国・拠点、ブランド、商品点数、取引先数
- 処理規模：ピーク時のアクセス数や注文数
- 既存環境：利用中のシステムと移行対象データ
承認ルートや店舗受取、在庫のリアルタイム表示の有無によって、必要な開発とテストの量は変わります。
標準機能と独自開発の境界の決め方
業務を標準機能に合わせる範囲と、競争力のために作り込む範囲を分けておきます。
- 標準に合わせる領域：商品登録や一般的なカート、受注、コンテンツ管理
- 独自性を保つ領域：得意先別価格、複雑な商品構成、独自の受注ルール
- 対応方法：標準機能、設定、拡張、周辺システム、業務変更
- 独自フロント：API、認証、キャッシュ、検索、在庫整合性も評価の対象
標準で足りる領域まで独自仕様にすると、初期費用に加えて更新や障害対応の負担が増えます。反対に、独自領域を標準に合わせると、現場がExcelや手作業に戻る可能性があります。
Fit to Standardの判断理由が分かれば、見積の差が人月によるものか、対応範囲によるものかを比べられます。
SAP公式資料によると、Composable StorefrontはAngularベースのJavaScriptフロントエンドで、Commerce REST APIを介してバックエンドと通信します（出典: SAP Help Portal「SAP Commerce Cloud, composable storefront」、2026年確認）。
一括請負・準委任・段階発注から選ぶ発注形態
発注形態は、要件がどこまで確定しているか、業務変更があるか、社内に管理できる人材がいるかで選びます。
大規模なSAP Commerce Cloudでは、企画・要件定義から運用改善まで工程を分けると、責任範囲と予算を管理しやすい場合があります。
要件が固まっている領域の請負契約
完成条件を明確にできる作業は、請負契約の対象と完成の判定方法を決めてから発注します。
- 契約の形：成果物と完成条件を定め、その成果に対して対価を払う
- 向く領域：画面・機能・API仕様、移行対象、テスト項目、納品物が明確な開発や追加機能
- 留意点：納期と予算を見通しやすい一方、要件追加には変更管理と追加見積が必要
完成は、定めたテストデータと受入条件を満たす状態として定義しておきます。導入が済んだだけで完成とすると、受入の判断が曖昧になるからです。
完成条件の例は、商品検索や得意先別価格、在庫照会のほか、注文登録とERP受注連携です。
受入条件に性能や権限、異常系、ログ、障害時の再送も含めると、公開直前の問題を減らせます。
要件が変わる領域の準委任契約
仕様が変わりうる業務では、委託する作業範囲と発注側の判断体制を整理しておきます。
- 契約の形：専門家が一定の業務を行うことに対価を支払う
- 向く領域：現行業務の調査、Fit/Gap、構成検討、アジャイル開発、運用改善
- 契約で定める点：完成責任の範囲、成果物、会議体、報告内容、品質指標
最終仕様を固めにくい領域に適しており、発注側にはプロダクトオーナーや業務責任者を置きます。
委託先の作業時間や体制は管理しやすい契約ですが、優先順位や仕様、受入判断は社内で決める必要があります。
委託先の提案を聞きながら決める場合でも、業務ルールの最終承認者がいないと、会議が増えて予算と納期が膨らみがちです。
PoC・MVPからの段階発注
不確実性が高い場合は、全機能の本番構築より先にPoCやMVPを発注します。そのうえで、次の業務を実データに近い条件で動かして確かめます。
- 業務フロー：商品検索、価格表示、在庫照会、ログイン、カート、注文、ERP連携
- 異常系：在庫不足、決済失敗、APIタイムアウト、二重送信、権限不足時の扱い
PoCの成果を本番開発へ引き継ぐ契約とし、検証用コードや設計・テスト資産を本番で流用するかどうか、データやAPI仕様を誰が所有するかを決めます。
MVPの成功条件は、画面が動くことよりも、営業担当が指定された得意先価格で注文でき、ERP側で受注・出荷へ進められるといった業務成果で定義します。
発注前のRFPと要件整理の範囲
RFPは詳細設計まで完成させなくても構いません。そのかわり、業務目的や範囲、連携先、データ、非機能要件を整理し、納期と予算の前提もそろえておきます。
見積を左右する要素は、画面数だけでなく、価格・在庫・受注の連携方式やデータ品質にもあります。
商品・価格・在庫・受注からみた業務要件
RFPには、誰が何を購入するのかを記載します。そのうえで、販売形態や展開地域ごとに必要な業務要件を整理します。
- B2B：得意先ごとの価格表、見積から注文へ進む流れ、購買承認、担当者・請求先の権限、再注文、納期回答
- B2C：会員登録、ゲスト購入、販促、決済、返品、問い合わせ
- 複数国・多言語・多通貨：税、通貨換算、在庫引当単位、タイムゾーン、法令対応
商品から請求までの各データについて、正となるシステムと更新のタイミングを決めます。
価格や在庫はリアルタイムでも、分析データは夜間バッチで足りる場合があります。全データをリアルタイム化すると障害の影響範囲が広がるため、許容時間と整合性で方式を選びます。
RFPに含める非機能要件と移行条件
非機能要件には、繁忙期やキャンペーン時の性能、障害時の復旧目標、運用時間を含めます。
- 運用要件：監視、バックアップ、ログ保存、権限、個人情報の扱い
- 受注異常：決済後に受注が作られない場合の受入条件
- 連携異常：在庫引当前の二重注文や、連携失敗を検知できないケース
移行対象には、得意先、契約価格、在庫が含まれます。さらに、商品画像や説明文、注文履歴や返品も移行の対象になります。会員や権限、検索属性も、同じく移行の対象です。
移行前の重複や欠損、コードの不一致をどこまで許容するか、クレンジングを発注側と委託先のどちらが担うか、移行リハーサルの回数を明記します。
移行と連携テストを終盤にまとめると、稼働直前になって不整合が見つかります。そのため、早い段階から実データに近いサンプルで検証します。
RFPの成果物と提案条件の指定粒度
提案書で回答してほしい項目は、RFPに設けておきます。たとえば、標準・設定・拡張の判定を指定します。設計と移行に関する回答は、候補の提案を比べる材料になります。
- 構成図：全体の構成を図で回答してもらう
- APIとバッチ一覧：連携とバッチの範囲を一覧で回答してもらう
- 移行・テスト計画：移行とテストの進め方を回答してもらう
体制表や前提・除外事項、課題管理の方法などに加えて、納品物、保守時間帯、SLA、追加開発単価も、提案時に確かめます。
候補各社に同じ質問への回答を求めると、自由形式の提案より比べやすくなります。また、デモやワークショップでは、画面の見栄えよりも業務例外への対応を確かめます。
- 注文例外：在庫不足や決済失敗後の再注文
- B2B業務：得意先別価格や承認者不在
- 連携障害：ERP連携のタイムアウト
提案の段階で難しい問題を質問できる会社は、稼働後のリスクを早く見つけられる傾向があります。
発注後の開発の進め方（要件定義・設計・テスト）
要件定義で業務とデータの境界を固めたうえで、設計では標準機能、拡張、連携の責任分界を決め、開発に進みます。
Commerce Cloudやフロントエンド、ERPやWMSが同時に動きます。そのため、統合テストを工程の後半だけに置く進め方は避けます。
要件定義でのFit/Gapと業務責任
現行の販売・受注業務を洗い出し、売上だけでなく目標とするKPIも決めます。あわせて、業務部門などの参加者も早い段階で集めます。
- KPI：受注処理時間、価格問い合わせ件数、在庫確認・返品処理時間
- 利用状況：売上、店舗受取率、再注文率
- 参加部門：業務、情報システム、物流、経理、法務、セキュリティ
Fit/Gapでは、標準機能で足りるか、業務を変えるか、設定やAPI連携、拡張開発で補うか、対象外とするかを、差分ごとに選びます。
拡張するときは、更新による影響や追加テストの量、将来の保守担当、撤去の条件を記録しておきます。要件定義書に判断理由を残しておくと、担当者が替わっても不要なカスタマイズを抑えやすくなります。
設計・開発での連携とアップデートの前提
画面を先に作ると連携仕様が後回しになり、手戻りが生じやすくなります。そこで設計では、次の構成と連携条件を定義します。
- 構成：Commerce Cloud、Composable Storefrontまたは独自フロント、検索、CMS、決済
- 接続先：SAP ERP、WMS、配送、会計、CRM
- 連携条件：データの送受信先、方式、頻度、エラー時の再送、重複防止、監視、照合
2026年時点では、SAP Commerce Cloud 2211系のJDK 21とSpring 6への対応も、発注条件に含めます。
SAPは、JDK 21とSpring 6への更新で、カスタム拡張やプロジェクト設定の調整が必要と案内しています（出典: SAP Help Portal「Update Release 2211-jdk21.1」、2025年公開・2026年確認）。
独自拡張には古いAPIや非推奨のライブラリを組み込まないようにし、更新時の回帰テストも契約の作業に含めます。
テスト・移行・リリースの一体管理
テストと業務確認は、種別ごとに分けたうえで、一連の流れとして進めます。
- テスト種別：単体、機能、連携、移行リハーサル、性能、セキュリティ、ユーザー受入
- 業務フロー：商品登録、検索、価格、在庫、カート、決済、受注、出荷、返品
- 異常系：再送による二重登録の有無、ERPとCommerce Cloudの注文番号照合
SAP公式の案内では、オンプレミス版2205のMainstream Maintenanceが2026年7月31日に終了します。
SAPは新しいイノベーションをCommerce Cloudに集中すると説明しています（出典: SAP Help Portal「End of Mainstream Maintenance for SAP Commerce」、2026年確認）。
既存のHybrisやSAP Commerceから移行する場合、サーバーの移設だけでなく、独自拡張や非推奨モジュール、商品・画像・注文データを洗い出します。
回帰テストと運用手順も確かめます。なお、SAP FAQの移行期間は一般に4〜8か月ですが、複雑さによって変わります。
移行期間の目安は推定で、納期を保証するものではありません（出典: SAP Help Portal「End of Mainstream Maintenance for SAP Commerce」、2026年確認）。
契約形態と委託範囲の明文化
契約では、開発作業に加えて、意思決定と情報提供の担当を作業ごとに決めておきます。データ作成から稼働後支援までの各作業についても、担当の範囲を書き分けておきます。
委託先の範囲が、Commerce Cloudだけか、ERP・WMS・ミドルウェアの改修や決済会社との調整まで含むかによって、見積と責任が変わります。
成果物・責任分界・変更手続きの定め方
納品物と変更手続きは、引き継ぎと費用管理に必要な範囲まで、契約で明確にしておきます。
- 成果物：要件定義書、業務フロー、Fit/Gap一覧、構成図、画面・API・データ仕様
- 納品物：ソースコード、環境設定、テスト計画・結果、移行・運用手順、教育資料、設定値・再現手順
- 変更管理：起票者、調査期限、追加費用、納期影響、承認者、優先順位を下げる機能
要件定義の後に機能を追加する場合は、優先順位を下げる機能とセットで判断します。
契約に「開発一式」とだけ書くと、他社への引き継ぎや障害調査が難しくなります。さらに、口頭での依頼のまま進めると、請負と準委任の境界が曖昧になり、想定外の作業費が出やすくなります。
知的財産・セキュリティ・保守の条件
契約の前に、知的財産、セキュリティ、保守の条件を確かめます。
- 権利と引渡し：コード、設定、設計・テスト資産、移行スクリプト、API仕様の利用権
- ライセンス：改変可否、再利用条件、契約終了後の利用可否
- セキュリティ：認証・認可、Backofficeのアクセス制御、個人情報の保持・削除、決済情報、暗号化、ログ、脆弱性対応、事故連絡
- 保守：受付時間、障害優先度、一次回答、復旧目標、更新・追加開発の料金
法務担当と確認しながら、自社や別の会社が納品後に改修できる状態を確保します。
SAP Security Guideのセッションや PCI、属性暗号化、HTTPヘッダー、ネットワーク、SSL/TLSも確認の対象です。
更新対応の料金と追加開発の料金は、分けて定めておきます。
SAP Commerce Cloudの費用相場とコストの内訳
費用は、エディションや取引規模、サイト数、対象国のほか、ユーザー、連携本数、改修、移行、保守範囲によって変わります。
国内向けに一律の公開価格表は確認できないため、公式の固定サービス価格と第三者ベンチマークを分けて扱います。
ここで示す金額は、発注額を決めつけるものではなく、RFPを作る時点の予算仮説です。
導入・連携・個別開発に分けた初期費用
初期費用の参考値は、公式の固定サービス価格と第三者ベンチマークを区別して読みます。
米ドルの円換算は1米ドル150円としています。
- SAP Store：導入サービスは一回304,130ユーロ。1ユーロ160円換算で約4,900万円
- 導入実装：15万〜50万米ドル、約2,250万〜7,500万円
- ERP・CRM連携：5万〜20万米ドル、約750万〜3,000万円
- カスタマイズ：5万〜30万米ドル、約750万〜4,500万円
SAPの一回料金は固定サービスの範囲で、クラウド契約や複雑な連携、大規模な追加開発は含みません（出典: SAP Store、2026年確認）。
SAP側のサービス名は「Accelerated implementation service for SAP Commerce Cloud」です。
第三者ベンチマークはSAP公式の価格ではなく、実際の見積の根拠とはいえません。
第三者ベンチマークは、提案額を比べる際の初期材料としては使えます（出典: TechGarçons「SAP Commerce Cloud Implementation Guide」、2025年公開）。
国内の予算は、導入支援やERP・WMS・決済連携の区分に分けて立てます。さらに、ライセンスやサブスクリプション、フロント、移行の費用も、この区分に加えて予算に入れます。
性能・セキュリティ試験や教育も見積に含めます。そのうえで、標準機能中心の単一国構成なら、4,000万〜8,000万円程度から検討します。
複数国や複数ブランド、高度なB2B、ERP/WMS/決済連携を含む場合は、1億〜数億円規模になる可能性があります。
国内のレンジは公表価格ではなく、公式サービス価格や第三者ベンチマーク、大規模な業務システムの相場から推定した幅です。
TCOに含めるランニングコストと開発期間
TCOには運用費と開発期間も含めます。次の参考値は、自社の条件に照らして確かめます。
- 運用費：サブスクリプション、クラウド、監視、ヘルプデスク、障害・セキュリティ対応、更新、改善、社内人員
- 年間費用の推定：ライセンス10万〜25万米ドル、サポート・保守5万〜10万米ドル
- 保守の一般論：初期開発費の年15〜25％。サブスクリプションを含むかで意味が異なる
- 期間の目安：要件整理等1〜2か月、単一国サイト4〜8か月、連携等を含む構築6〜12か月
- 複雑な構築：複数国・複数ブランド・既存Hybris移行は12〜24か月以上
年間費用の推定は契約条件や取引規模で変わるため、SAPや委託先に確かめます（出典: TechGarçons「SAP Commerce Cloud Implementation Guide」、2025年公開）。
SAP FAQの「多くの顧客は4〜8か月」という目安も、移行の複雑さや変更範囲によって変わります。
期間を短くするには、機能を削るだけでなく、標準機能の採用やデータ整備の前倒し、意思決定者の確保、MVP範囲の限定にも取り組みます。
委託先の選定と見積比較で確認するポイント
委託先は、SAPの知識に加えて、自社の販売業務と周辺システムへの理解で選びます。
委託先には、B2BやB2Cの経験と業界を尋ねます。さらに、S/4HANAやECCでの経験、WMSや決済連携の実績を確かめます。また、移行や保守体制、担当チームの経験も尋ねます。
案件の近さから見る実績
公開されている実績は、自社の案件条件と照らし合わせて、適合する経験と体制があるかを確かめます。
- 案件の近さ：業界、取引モデル、サイト・拠点数、データ量、連携方式
- B2B事例：得意先別価格や見積が中心なら、一般消費者向けEC事例は参考程度にとどめる
- 海外対応：多言語・多通貨、税、現地決済、タイムゾーン、拠点別在庫
- 公開例：SAPの標準導入、NTT DATAのCommerce Cloud・マーケットプレイス・ERP・Emarsys連携
- 移行・支援例：Capgeminiのクラウド移行、Accentureの短期導入・大規模支援、国内窓口の企業
国内窓口の例には、日本ソフトウエア株式会社があります。認定や担当者、再委託、保守体制は提案時に確かめ、企業名よりも自社要件への適合性で評価します。
作業と前提をそろえた見積比較
見積は総額だけでなく、作業と前提を同じ粒度にそろえて比べます。
- 作業範囲：要件定義、設計、設定、拡張、フロント、連携、移行、テスト、教育、リリース、保守
- 見積条件：人数、期間、成果物、前提、除外、再委託、追加作業単価
- 総額の差：A社は連携費を含み、B社は別途とする場合、総額の比較では差が見えにくい
安い見積では、要件定義の短さや商品だけの移行、モック連携テスト、性能試験の対象外を確かめます。さらに、稼働後のハイパーケアがなかったり、ソースコードや設計書が納品されなかったりする場合もあります。
高い見積でも、データ整備や実データのリハーサル、異常系試験、運用設計、更新対応を含むなら、TCOの面で妥当な場合があります。
スコープクリープとベンダーロックインの防止
機能追加は止めず、追加時の費用や納期、テストへの影響を見える形にして、優先順位を見直せるようにします。
- 範囲管理：必須、初回後に回す機能、対象外を区分
- 変更判断：追加時の費用、納期、テストへの影響を並べて示す
- 進捗管理：月次課題レビューと段階ごとの予算・品質・リスク報告
API仕様やデータモデルは、委託先から引き渡してもらい、社内で読める形にしておきます。さらに、環境構成やCI/CD、監視設定、テストコード、障害履歴も引き渡しの対象です。
保守会社による変更の可否、ライセンスや部品の制約、委託先が撤退した場合の復旧担当を確かめます。引き継ぎの期間と費用を契約時に定めておくと、稼働後も選択肢を残せます。
よくある質問（FAQ）
発注の際には、費用や内製と外注の分担、納期、既存のSAPからの移行について、質問が多く寄せられます。
SAP Commerce Cloudのシステム開発費はどのくらいですか？
費用に一律の価格はありません。標準機能中心の単一国サイトは、4,000万〜8,000万円程度からが目安です。
- 複雑な構成：複数国、ERP/WMS・決済連携、高度なB2Bを含むと1億〜数億円規模
- 参考値：SAP公式の一回304,130ユーロの導入サービスや第三者ベンチマーク
クラウド契約や個別要件が含まれているかを確かめ、RFPに基づく見積で判断します。
SAP Commerce Cloudの開発は請負と準委任のどちらがよいですか？
仕様と受入条件が固まった領域には請負が、業務調査やFit/Gap、アジャイル開発、運用改善など変化しやすい領域には準委任が適しています。
大規模な案件では、要件定義を準委任、確定した開発を請負、稼働後の改善を準委任にする方法もあります。どの契約形態でも、成果物や責任分界、変更手続き、受入条件は明文化しておきます。
SAP Commerce Cloudの導入期間はどれくらいかかりますか？
標準機能中心の単一国サイトは4〜8か月、ERP・在庫・決済・移行・B2Bを含む場合は6〜12か月が目安です。
複数国や既存Hybrisからの移行は12〜24か月以上かかります。SAP FAQも、多くの顧客で4〜8か月と推定しています。
要件の変更やデータ品質、意思決定の速さ、テストの回数によって変わります。短い納期を求めるなら、MVPと後続リリースを分けて進めます。
SAP ERPを使っていなくてもSAP Commerce Cloudを発注できますか？
発注はできます。ただし、SAP ERPがなくても、商品や価格、在庫を管理するシステムとの接続設計は必要です。顧客、受注、出荷、請求も、接続設計の対象になります。
SAP製品を使うかどうかは導入の条件ではなく、必要な販売機能やデータ連携で判断します。候補の会社には、SAP以外の基幹やWMS、決済との連携経験と、将来SAP ERPへ移行する際の拡張方針を尋ねます。
まとめ
SAP Commerce Cloudの発注では、画面だけでなく、商品から出荷までを含む販売業務全体を対象にします。そのうえで、標準機能と独自開発を分け、請負や準委任、段階発注を組み合わせます。
RFPには、業務や連携、移行に加えて、性能やセキュリティ、受入条件、納品物、保守も含めます。
発注前の確認項目
対象チャネルとKPI、商品や注文の正となるシステム、ERP・WMS・決済連携、移行データを確かめます。
標準・拡張の判定と非機能要件、テスト範囲を決めます。見積では、作業や除外、体制、成果物を同じ粒度にそろえたうえで、追加単価や保守、更新対応も比べます。
業務シナリオを使ったRFP作成
最初から完璧な仕様書を作る必要はありません。重要な業務シナリオを数本選んで、候補の会社とFit/Gapを確かめます。
- B2B注文：得意先別価格での注文
- 例外注文：在庫不足時の注文や決済失敗後の再注文
- 連携復旧：ERP連携が止まった注文の再送
業務に基づくRFPと、将来の更新・運用を見据えた契約が、発注を成功へ近づけます。
▼全体ガイドの記事
・SAP Commerce Cloudのシステム開発の完全ガイド
▼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を創業。