相談する

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

SAP Commerce Cloudのシステム開発は、要件整理から定着化まで6つのフェーズで進みます。

商品、価格、在庫、受注といった販売業務全体を支える仕組みを、前段で決めた内容を次の工程へ引き継ぎながら作ります。全体像の詳細は、下記の完全ガイドで確認できます。

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

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

SAP Commerce Cloudのシステム開発の全体像

SAP Commerce Cloudの構成をコマース領域、顧客・販売領域、物流・会計領域の3層で示した図
領域ごとに役割を分けると、連携範囲を見渡しやすくなります。

SAP Commerce Cloudは、旧称Hybrisとしても知られるエンタープライズ向けのコマース基盤です。小規模なECサイトを短期間で公開するSaaSとは違い、複雑な販売業務を支えるシステムとして検討します。

販売業務システムとしての位置づけ

SAP Commerce Cloudは、B2CとB2Bで異なる販売情報を管理します。

  • 共通情報：商品カタログ・商品属性、顧客・企業組織、契約価格、在庫、カート、注文、返品、プロモーション
  • B2C：会員、検索、レコメンド、決済、チェックアウト
  • B2B：得意先別価格、購買担当者の権限、上長承認、見積、再注文、請求条件

要件整理を画面から始めると、後から業務ルールと連携仕様が膨らみがちです。そこで、受注から在庫引当、出荷、請求、返品までを一連の流れとして描き、各情報の正となるシステムを決めます。

構成要素と連携範囲の切り分け

全体構成は、システムの役割ごとに分けておくと、連携範囲を決めやすくなります。

  • コマース領域：Commerce Cloud本体、フロントエンド、検索、CMS
  • 顧客・販売領域：決済、マーケティング、ERP、CRM、PIM
  • 物流・会計領域：WMS、配送、会計

SAP S/4HANAやSAP Cloud ERPと連携する場合は、商品マスタや得意先、価格の整合性を確認します。さらに、在庫や受注、請求・出荷も確認の対象になります。なお、非SAPの基幹や物流を使う場合も、項目ごとに連携方式を決めます。方式はAPI、イベント、夜間バッチなどから選びます。

フロントエンドは、Accelerator、AngularベースのComposable Storefront、独自のJavaScriptアプリから選びます。

SAP Help Portalによると、Composable StorefrontはCommerce REST APIだけを介してバックエンドと通信します（出典：SAP Help Portal「SAP Commerce Cloud, composable storefront」）。

画面設計の自由度は高まる一方で、APIや認証、キャッシュを別途設計する必要があります。在庫と価格の整合性も、設計の対象になります。

ポイント

販売業務の情報をB2CとB2Bで分けて捉え、連携先の範囲を先に決めておくと、後から業務ルールや連携仕様が膨らむのを抑えられます。

SAP Commerce Cloudのシステム開発の進め方

SAP Commerce Cloudの開発を要件整理、構成選定、設計開発、テスト、稼働、定着化の順に示した6段階の図
前段で決めた内容を次の工程へ引き継ぐ流れが見えます。

開発は、要件整理、構成選定、設計開発、テスト、稼働、定着化の6フェーズで進みます。各フェーズで、納めるもの、決める人、次へ進む条件を先に決めておくと、手戻りを防ぎやすくなります。

1. 要件整理：業務とKPIの決定

導入目的は、売上や受注処理時間といったKPIで表します。ほかにも、価格問い合わせ件数、再注文率、店舗受取率などが指標になります。

「ECサイトを刷新する」という目標は、成功条件として測りにくいものです。そのため、見積作成時間の短縮や在庫確認の二重入力の解消など、業務成果に置き換えます。

現状と将来像で、データフローを比べます。比べる対象の中心は、商品と価格、顧客と在庫です。受注と返品、配送と請求も比べます。

連携が失敗したり値がずれたりしたときに、どこが正かで迷わないよう、データの扱いを先に決めておきます。

  • 正となるシステム：データごとの管理元
  • 更新タイミング：情報を反映する時点
  • 再送方法：連携が失敗したときの処理
  • 担当部署：連携とデータの責任者
  • 例外処理：通常と異なる業務の扱い

特に価格と在庫は、画面に表示された値と注文時に確定する値がずれる場合を想定しておきます。

2. 選定：標準機能と独自開発の境界

構成と業務要件は、フロントの作り方から独自開発の範囲まで、同じ観点で比べながら選定します。

  • フロント：Accelerator、Composable Storefrontのヘッドレス構成、独自フロント
  • 比較軸：更新容易性、人材、SEO、表示速度、CMS、API責任、障害時の切り分け
  • Fit to Standard：標準に合わせる領域と独自開発する領域の区別
  • 独自開発：得意先別価格、複雑な商品構成、承認ルール、独自の受注オーケストレーションなど

商品登録や一般的なチェックアウトは、独自仕様にせず標準機能を使います。一方で、差別化や競争力に直結する要件に投資を集中させると、将来の更新負担を抑えられます。また、判断に迷う要件は、実データに近いPoCで試し、業務効果と実装負荷を同時に確かめます。

3. 設計・開発：連携と非機能要件の確定

設計・開発では、連携方式や運用要件を含めて、次のとおり固めます。

  • システム設計：画面仕様、データモデル、API、認証、権限、検索、キャッシュ
  • 運用設計：監視、ログ、バックアップ、障害時の復旧
  • 連携方式：SAP Integration Suiteなどでリアルタイム、イベント、バッチを使い分ける
  • 実装確認：商品検索、ログイン、価格表示、カート、注文、ERP連携を、早い段階で動かして確かめる
  • 異常系：在庫不足、決済失敗、APIタイムアウト、二重送信、権限不足、返品、連携先停止

価格や在庫の即時処理と、分析用の集計データを同じ方式で扱うと、費用や運用負荷が増える場合があります。

納品物には、設計書、API仕様、テスト証跡を含めます。加えて、環境設定、インフラ構成、移行手順も入れます。これらを成果物として定義しておくと、稼働後の内製化やベンダー交代にも備えられます。

4. テスト：データ・連携・業務の通し検証

テストでは、業務シナリオ、データ移行、性能を次のように確認します。

  • 試験種別：単体、結合、システム、受入、性能、セキュリティ
  • 業務シナリオ：単体の注文は通っても、ERP受注番号やWMS出荷指示、返品在庫の反映で失敗することがあります。
  • 移行確認：少なくとも複数回リハーサルして、コード重複、単位・税・通貨、名寄せ、画像・添付の欠落、無効データを調べる
  • 性能確認：通常時と販促・締め日のピークを想定し、検索・ログイン・価格・在庫・チェックアウトの応答を測る

5. 稼働：切り替え方式と初動体制の準備

稼働時は、切り替えの準備、公開の方式、初動の確認項目を、稼働前にそろえます。

  • 切り替え準備：最終移行手順、凍結期間、並行運用、切り戻しの条件
  • 公開方式：全面切り替えか、商品カテゴリ・国・ブランド・顧客層ごとの段階公開か
  • 初動体制：窓口・監視担当を置き、売上計上、受注、決済、出荷、返品に関わる停止時間を業務部門と合意しておく
  • 日次確認：注文件数、決済失敗率、在庫不整合、連携エラー、検索ゼロ件率、問い合わせ、表示速度
  • SAPの支援：公式サービスの稼働後支援の内容

SAP公式のAccelerated implementation serviceには、稼働後5営業日のハイパーケアが含まれるとされています。

ただし、5日間の支援で企業全体の運用が完了するとは限りません。そのため、自社の運用責任者と開発会社の支援期間は、別途決めておく必要があります（出典：SAP Store「Accelerated implementation service for SAP Commerce Cloud」）。

6. 定着化：現場が使い続ける仕組みづくり

定着化には、現場の運用課題に対応し、継続的に改善していくことが必要です。

  • 運用上の障害：機能不足のほか、商品登録や価格変更の分かりにくさ、承認者の不在、エラー担当の不明、KPIから改善策を決められないことが原因になります
  • 運用ルール：操作マニュアル、権限申請、問い合わせ、エラー再送、月次データ確認、改善要望の優先順位を決める
  • 定着指標：Backoffice利用率、手作業件数、注文修正率、エラー解決時間、営業問い合わせ削減数
  • 更新対応：アドオンの互換性と回帰テストを、継続して確かめる

ポイント

要件整理から定着化まで、各フェーズで決めたことを次の段階へ確実に渡せるかが、手戻りを減らす鍵になります。稼働と定着では、切り戻しの条件と運用ルールも見ておきます。

SAP Commerce Cloudの費用相場とコストの内訳

費用は、ライセンスやサブスクリプションのほか、導入支援、連携、カスタマイズに分けて確認します。さらに、データ移行、テスト、運用保守も費用項目です。

SAPは、契約エディションや取引規模、注文量に応じて個別見積を行います。サイト数や必要なサービスも、見積もりの条件になります。そのため、公開価格から総額を判断するのは難しくなります。

公開情報から見た初期費用のレンジ

出どころが異なるため、初期費用は、公式サービス価格、第三者ベンチマーク、国内レンジの推定を分けて見ます。

  • SAP Store：固定スコープの導入サービス価格
  • 第三者推定：導入実装、連携、カスタマイズ、年間費用のベンチマーク
  • 国内予算仮説：初年度費用と要件別の総額レンジ

SAP Storeのサービスは、一回30万4,130ユーロです。1ユーロ160円で換算すると、約4,900万円になります。

この価格は固定スコープのもので、クラウド契約や複雑な個別連携は対象外です。さらに、大規模な追加開発と社内作業費も含みません（出典：SAP Store、2026年確認）。

2025年の第三者推定では、導入実装が15万〜50万米ドルです。ERP・CRMなどとの連携は5万〜20万米ドル、カスタマイズは5万〜30万米ドルです。加えて、年間ライセンスは10万〜25万米ドル、年間サポート・保守は5万〜10万米ドルです。

1米ドル150円で換算すると、導入実装は約2,250万〜7,500万円です。連携は約750万〜3,000万円、カスタマイズは約750万〜4,500万円になります。第三者推定は予算策定の初期仮説で、SAP公式の価格表ではありません（出典：TechGarçons「SAP Commerce Cloud Implementation Guide」、2025年）。

単純に積み上げた初年度の予算仮説は、おおむね6,000万円〜2億円前後です。ただし、すべての費用項目が必ず加算されるとは限りません。

単一国で標準機能が中心なら、4,000万〜8,000万円程度から検討します。一方で、複数国の展開やERP・WMS・決済との連携、高度なB2Bやマーケットプレイスを含むと、1億〜数億円規模になります。

国内レンジは、公開ベンチマークと一般的な大規模業務システムの相場から推定したものです。公表された価格ではありません。

ランニングコストと期間を含むTCO

ランニング費用と期間は、サービス契約や対象範囲に応じて見積もります。

  • 運用費：サブスクリプション、クラウド、監視、問い合わせ、セキュリティ、データ保守、改善、更新
  • 保守費の参考：一般的な業務システムでは初期開発費の年15〜25％の場合がある
  • 標準的な期間：Fit/Gapは1〜2か月、単一国・標準中心は4〜8か月。ERP・在庫・決済・移行を含む新規構築は6〜12か月
  • 複数国・移行：複数国・複数ブランドや既存Hybris移行は12〜24か月以上
  • SAP公開情報：オンプレミスからCloudへの移行は多くの顧客で4〜8か月

年15〜25％は、SAP Commerce Cloud固有の公式料金ではありません。そのため、SLAや運用時間を分けて見積もります。加えて、改善開発の有無と内製化の範囲も確認します。

SAPが示す移行期間は、構成や変更量に左右される推定です。納期を保証するものではありません（出典：SAP Help Portal「End of Mainstream Maintenance for SAP Commerce」）。

ポイント

初期費用は、公式価格や第三者推定、国内レンジを分けて見比べます。ランニング費用と期間も含めて、総額で判断するのが目安です。

SAP Commerce Cloudの見積もりを取る際のポイント

見積もり条件を規模、業務、連携、非機能の4領域に分けた図
4領域をそろえて示すと、各社の前提を照らし合わせやすくなります。

見積書は、合計金額の安さよりも、前提条件と含まれる作業の違いを確認して読みます。工数は、対象範囲によって変わります。たとえば、商品と価格、在庫と受注、返品のどこまでを含むかで差が出ます。

「開発一式」と書かれた見積もりでは、対象範囲を判断できません。

要件定義書に入れる業務シナリオと非機能要件

見積もりの条件をそろえるため、RFPや見積依頼には業務シナリオと非機能要件を含めます。

  • 規模：国、ブランド、サイト、会員、商品、月間注文数、ピーク時アクセス
  • 業務：B2Bの組織・承認・価格表・見積・再注文、B2Cの会員・クーポン・決済・受注・返品・店舗受取
  • 連携：接続先、データ項目、方向、頻度、方式、再送、照合方法、担当者
  • 非機能：稼働・応答・ピーク注文・可用性、バックアップ、RPO・RTO、監査ログ、個人情報の保持・削除、脆弱性対応

この前提がそろえば、各社が違う範囲で見積もる事態を防げます。決済情報は自社で保持するか、決済サービスに委ねるかも決めておきます。この選択は、費用とセキュリティを左右します。

複数社の同条件比較とデモでの確認

候補会社は、同じ条件で比べます。比べる対象は、実績と担当体制、デモと見積項目です。

  • 実績：Commerce Cloud、S/4HANA・ECC、WMS、PIM、決済、配送との連携、移行、性能試験、保守
  • 担当体制：担当者の経歴、再委託、国内障害対応を確認（資格では、チーム経験は分からない）
  • デモ：検索から注文、ERP連携、出荷、返品まで。在庫不足、決済失敗、APIタイムアウト、承認者不在、権限エラーの場面も確認
  • 見積項目：要件整理、設計、開発、移行、テスト、教育、稼働支援、保守ごとに分け、対象外の作業を明記する

デモでは、業務への理解と障害時の考え方もあわせて確認できます。

移行・テスト・契約の抜けというリスク

見積もりや契約では抜けが出やすいので、範囲ごとに項目を確認します。

  • 別途費用：安い見積もりでは、後から別に加算される場合がある
  • 旧Hybris資産：独自拡張、非推奨モジュール、Java・Spring依存、メディア、回帰テストを一覧にして、Cloudで使えるかを初期判定する
  • 契約・引き渡し：仕様変更、検収、障害責任、SLA、再委託、ソース、設計・API仕様、テスト証跡、環境設定、IaC
  • 情報管理：個人情報・監査ログの保管場所と期間、アクセス権限、削除依頼への対応

対象になるのは、データクレンジングや移行リハーサル、連携・性能試験です。さらに、脆弱性診断や操作教育も含まれます。

法務、情報システム、セキュリティ部門と内容を確認します。法令対応は、SAPを導入すれば自動的に終わるものではありません。そこで、自社の業務と契約に合わせて、受入条件を定めます。

ポイント

見積もりは合計額より前提条件を比べ、業務シナリオと非機能要件を入れたRFPで条件をそろえます。別途費用や契約の抜けも、見積もりの段階で確かめます。

よくある質問（FAQ）

導入では、期間、費用のほか、既存システムとの関係や開発会社の選び方がよく問題になります。初期検討で質問されやすい内容に答えます。

SAP Commerce Cloudのシステム開発には何か月かかりますか？

開発期間の目安は、構成や移行の範囲ごとに異なります。

  • 単一国・標準機能中心：4〜8か月
  • ERP・在庫・決済連携と移行を含む新規構築：6〜12か月
  • 複数国・複数ブランドや既存Hybris移行：12〜24か月以上

期間は、要件整理の圧縮やデータ品質によって大きく変わります。独自開発の量やテスト期間も影響します。そのため、公開日から逆算するだけでなく、Fit/Gapと移行リハーサルの期間を先に確保しておきます。

SAP ERPを使っていなくても導入できますか？

導入できます。SAP Commerce Cloudは単体でも利用できます。

SAP S/4HANAやSAP Cloud ERPと連携すると、商品・価格・在庫・受注の一貫性を作りやすくなります。また、WMSやCRM、決済、PIMとつなぐ場合も、同じ観点で整合性を確かめます。

非SAPの基幹と連携する場合は、マスタコードと在庫引当の意味をそろえます。税、通貨、注文ステータスについても、同じ意味で扱うよう確認します。

SAP Commerce Cloudの導入費用はいくらですか？

導入費用には一律の公開価格がなく、契約エディションや取引規模で変わります。さらに、連携数、独自要件、移行量によっても左右されます。

  • 単一国・標準機能中心：4,000万〜8,000万円程度から
  • 複数国・複雑な連携・高度なB2B：1億〜数億円規模まで
  • SAPの公開サービス：一回30万4,130ユーロ。クラウド契約と追加開発は含まない

見積もりは項目ごとに分けて、前提条件と合わせて確認します。

既存のSAP CommerceやHybrisから移行するときの注意点は何ですか？

移行前は、既存資産を洗い出し、保守情報と合わせて確認します。

  • 移行資産：独自拡張、非推奨モジュール、Java・Spring依存、商品・顧客・注文データ、画像、外部連携、回帰テスト
  • 保守情報：オンプレミス版2205の保守期限
  • 移行判断：期限に追われて急ぐより、更新を妨げるアドオンとデータ品質を先に調べる

SAPは、オンプレミス版2205のMainstream Maintenanceが2026年7月31日に終了すると案内しています。加えて、新しいイノベーションはCommerce Cloudに集中するとしています（出典：SAP Help Portal、2026年確認）。

ポイント

期間と費用は、構成や移行範囲、連携数で大きく変わります。既存資産の洗い出しと前提条件のそろえ方が、判断の目安です。

まとめ

SAP Commerce Cloudは、商品・価格・在庫・受注を中心にした販売業務の再設計です。ERPや物流とつなぎ、決済やマーケティングも連携の対象になります。

成功には、KPIとデータの正を決め、Fit to Standardで独自開発を絞り込みます。さらに、設計の段階から、連携や移行、非機能要件を扱っておく必要があります。

着手前に確認する5項目

着手前に社内で答えを持っておかないと、途中で範囲や責任が曖昧になります。

  • 目的：導入目的とKPI
  • データ：商品・価格・在庫・受注の責任者
  • 連携：ERP・WMS・決済との方式
  • 開発範囲：標準機能と独自開発の境界
  • 責任の範囲：移行・テスト・稼働後保守

5項目が曖昧なまま見積もると、追加費用や納期の延長が起きやすくなります。

次に行うべきアクション

着手に向けては、次のとおり進めます。

  1. 現行業務とデータフローを一覧にし、商品・価格・在庫・注文データでPoCまたはFit/Gapを行う
  2. 検証結果をRFPに反映する
  3. 要件整理からテスト、教育、保守まで分けた見積もりを複数社から取得する

こうして比べると、自社に必要なSAP Commerce Cloudのシステム開発の進め方と総額を、現実的に見極められます。

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

▼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を創業。