Salesforce Commerce Cloudのシステム開発の完全ガイド

Salesforce Commerce Cloudは、B2CとB2Bの業務、他システムとの連携、開発方式を見極めて選ぶコマース基盤です。導入後の継続的な成長にも役立ちます。

種類と機能、開発方式を、順に説明します。費用と開発会社の選び方も取り上げます。詳しくは下の関連記事で確認できます。

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

Salesforce Commerce Cloudシステムの概要

Salesforce Commerce Cloudは、商品を見つけてもらうところから、購入、注文処理、顧客対応、分析までを支えるクラウド型のコマース基盤です。公式サイトでは「Agentforceコマース（旧Commerce Cloud）」とも表記されています。実務では、SFCC、B2C Commerce、Commerce Cloudという呼び方も使われます。

CRMとECをつなぐ顧客体験の基盤

一般的なECでは、会員や購入、問い合わせ、キャンペーンの履歴が、別々に管理されることがあります。一方、Commerce CloudはSalesforceのCRMやマーケティング、サービス、データ基盤と連携しやすいのが特徴です。そのため、購入前後の接客を一貫した顧客情報で扱えます。

購入前後の案内：購入した商品に応じた案内と、注文状況の確認
顧客別の販売：会員ランクごとの価格と、再注文へつながる導線

ただし、周辺の業務システムが自動でそろうわけではありません。たとえば、ERPやPIM、WMSのほか、決済や配送、返品管理は別途の設計が必要です。そのため、データの正本とリアルタイム連携の範囲を決め、周辺サービスや開発作業を設計する必要があります。

商品発見から注文・分析までの一連の流れ

Commerce Cloudが扱う業務は、商品の表示から顧客対応、売上分析まで広がります。

商品・購入導線：商品カタログ、価格表、サイト、検索、カテゴリ、レコメンド、カート、チェックアウトを扱う
注文・顧客管理：決済、クーポン、販促、会員、注文履歴、在庫、注文管理、売上分析までを含む
複数チャネル：店舗やコールセンターを含む場合に、POSや注文管理と接続する

公式ページでは、基盤の歴史的な稼働時間が99.99%で、20億人以上の買い物客の取引を支えてきたと示されています（出典：Salesforce公式Agentforceコマースページ、2026年8月参照）。ただし、この数字はプラットフォームの実績を見る材料です。自社の画面や連携API、決済代行、運用手順まで含めた可用性を保証するものではありません。

B2CとB2Bの種類と違い

取引相手の違いが、購入プロセスを考える出発点になります。

種類は、業種よりも取引相手と購買プロセスで見分けます。消費者が短時間で購入するならB2C、法人が契約や承認を経て買うならB2Bが中心になります。両方を扱う場合は、まず共通化するデータや運用と、分ける画面や価格ルールを整理しておきます。

B2Cの大量アクセスと購入率を両立する設計

B2Cでは、広告や検索から訪れた人がすぐ商品を見つけ、少ない操作で決済まで進める導線が欠かせません。

購入率に関わる機能：在庫表示、クーポン、ギフト、会員登録、ゲスト購入
商品選びの支援：レビュー、レコメンド、検索精度、商品バリエーション

季節商戦などでアクセスが急増する場合は、キャッシュやCDN、在庫引当を検証します。決済のタイムアウトや注文の重複も、確かめておきます。

公式SFRA資料は、2,000以上のモバイルストアフロントの分析を設計に活用したと説明しています。モバイルの買い物訪問は60%を超えるとされています（出典：Salesforce Developers「Storefront Reference Architecture」、2026年8月参照）。そのため、PC版を縮めた画面にはせず、スマートフォンでの検索や入力を起点に設計します。

認証や決済も、同じ流れで考えます。

B2Bの取引先別の条件と承認

B2Bでは、取引先や契約、数量によって条件が変わります。その結果、価格や在庫、配送条件も取引先ごとに異なります。地域や販売チャネルも、条件を左右する要素です。

購入権限：購買担当者、承認者、管理者それぞれの役割
取引条件：価格表、最低発注数量、定期注文、請求条件、再注文

注文単位が大きい場合は、営業担当者が関わる業務と、購入者が自分で完了させるセルフサービスを分けておくと、運用しやすくなります。

B2C画面をそのまま使うと、承認や請求、取引先階層に対応できず改修が生じることがあります。逆にB2Bの複雑なルールを消費者向け画面に持ち込むと、購入導線が長くなります。顧客区分、価格の正本、受注後の業務を図に描き、共通化と分離の境界を決めます。

ポイント

B2CかB2Bかは、取引相手と購買プロセスで見分けます。両方を扱うなら、共通化する範囲と分ける範囲の境界を先に決めておくと、後の改修を抑える手がかりになります。

主要機能と周辺システム連携の設計

通常のデータ管理と異常時の対応を一緒に整理できます。

導入では、画面の見た目より先にデータの流れを決めておきます。そのうえで、商品、価格、在庫の登録元と更新頻度を定めます。会員、注文、決済、配送、返品についても、登録元と更新頻度をそれぞれ決めておきます。

エラー時の扱いや再送方法、履歴の保管先も、同じ段階で決めておきます。連携仕様が曖昧なまま画面を作ると、テスト直前の業務変更で納期や費用が膨らみやすくなります。

商品・価格・在庫の正本

設計では、商品と価格の管理元を決めるとともに、在庫連携、注文処理の状態、例外時の扱いを定めます。

商品情報：商品名、説明、画像、規格、カテゴリを、PIM、基幹、Commerce Cloudのどこで管理するかを決める
販売価格：価格表、ERP、契約管理から正本を選ぶ
在庫：倉庫、店舗、外部OMSの在庫引当時期と連携遅延時の表示を定義する
注文状態：受注、支払認証、引当、出荷、配送、返品、返金、キャンセルを一貫管理する
例外処理：在庫連携失敗時の保留・取消・通知を決め、二重送信や部分出荷も試験する

決済が成功したあとに在庫連携が失敗する場合に備えて、タイムアウトや分割返品もテスト対象にします。

OMS・ERP・PIM・WMS・決済の役割分担

Commerce Cloudは、注文を受けるフロント寄りの中核です。ただし、既存業務をすべて置き換えるとは限りません。

ERP・PIM・WMS：財務や仕入れ、商品情報、倉庫作業
OMS・決済：配送や返品の最適化、カード情報や認証

Premiumエディションには、注文管理やデータ活用の機能が含まれる場合があります。ただし、契約条件と国内での提供状況は、個別に確認します。

連携方式は、APIやイベント、バッチ、ファイル連携を使い分けます。たとえば、商品マスタは夜間の同期で足りても、在庫や注文状況は数分以内の反映が必要になることがあります。

連携基盤は、接続だけでなく運用まで設計します。監視、アラート、再処理の仕組みは、稼働後に欠かせません。権限や監査ログの扱いも、設計の範囲に入ります。

ポイント

連携仕様を、画面を作る前にどこまで固められるかが、後戻りの少なさを左右します。エラー時の再送や履歴の扱いまで決めておくと、テスト直前の変更による費用の膨らみを抑えられます。

SFRA・Composable・ハイブリッドの方式比較

短期の立ち上げと標準機能を優先するならSFRA、独自の体験や複数チャネルを柔軟に作るならComposableが候補になります。

既存資産を活かして段階的に移行するなら、ハイブリッドが候補です。売上規模だけでなく、ブランド表現、開発体制、SEOを比べます。更新頻度や将来のチャネル数も、同じ基準に含めます。

SFRAの標準寄りの方式と保守性

SFRAは一般的なEC導線を出発点に、標準を活用しながら必要な独自機能を加える方式です。

基本機能：商品一覧・詳細、カート、チェックアウトを備える
拡張：テンプレートやカートリッジを使った、ブランドデザインや業務機能の追加
標準活用：標準に寄せるほど更新に追従しやすく、初期の不確実性も抑えられる
追加機能：独自仕様の移植は保守負債になり得るため、標準設定、拡張、外部サービスを比べる

要件定義では、差別化につながる機能と、標準に合わせられる機能を分けます。

Composableの自由度と設計範囲の広がり

Composable Storefrontは、画面と、コマースのデータや業務ロジックを分ける方式です。連携にはSalesforce Commerce API（SCAPI）を使います。

構成：PWA Kit、Managed Runtime、React画面、サーバーサイドレンダリング、CDNの組み合わせ
外部サービス：CMSや検索サービスも構成に加えられる
設計範囲：認証、キャッシュ、SEO、構造化データ、監視、デプロイ、脆弱性対応
初期検証：SSRとクライアント表示、URL正規化、在庫・価格取得失敗、APIレート制御

公式資料は、独自のブランド体験や複数技術の構成について説明しています（出典：Salesforce Developers「Headless Commerce with Salesforce Commerce API」、2026年8月参照）。公開事例では、移行後に表示速度が4倍、コンバージョン率が13%向上したと報告されています。ただし、これは特定企業の結果で、同じ成果が得られるとは限りません。

ハイブリッドの段階移行とリスクの分散

既存SFRAを残したまま、一部の機能をSCAPIで置き換える方式です。例は、検索や会員ページです。キャンペーンやアプリ連携も含まれます。全画面を一度に刷新しないため、売上への影響を抑えやすくなります。

社内のフロント開発力も、段階的に高められます。一方で、方式が混在すると、認証やデザインのほか、分析イベントや注文状態の表示が二重になりがちです。

移行単位ごとに、画面の担当方式、共通API、切り戻し方法を文書にまとめておきます。そのうえで、小さなMVPで表示速度と購入率を測り、運用工数や障害対応時間も踏まえて次の範囲を決めます。

ポイント

方式は、早く立ち上げたいか、画面と業務の自由度を求めるか、既存資産をどれだけ残すかで絞り込めます。3つの方式を比べる際は、後から変えにくい部分から確かめると、社内の開発力に合う方式が見えてきます。

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

開発では画面だけでなく、現行業務、データ、連携まで一つの計画に含めます。そのうえで、運用とセキュリティを計画に入れ、移行と教育も同じ計画で扱います。

ECは公開後も改善を重ねる前提で進めます。そのため、初回に全機能を詰めるのではなく、売上と業務への影響が大きい範囲をMVPとして定義します。

▶ 詳細はこちら：Salesforce Commerce Cloudのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

企画・要件定義での業務とKPIの整理

企画では、成果を測る指標と業務の範囲をそろえ、要件の優先度を決めます。

KPI：売上、購入率、平均注文額、リピート率、問い合わせ削減、受注処理時間
業務条件：B2C・B2B、ブランド、国・言語・通貨、税、会員、価格、在庫、決済、配送、返品、キャンセル
優先度：「必須」「初回リリース後」「採用しない」に分け、見積前提をそろえる

成果物には、業務フローや画面・権限一覧、データ項目表を含めます。外部連携や非機能要件、移行対象、テスト方針も、同じ成果物の中で示します。

非機能要件では、ピーク時の同時アクセスや表示速度、障害復旧目標を数値で置きます。ログ保存期間、個人情報、監査要件も、数値で決めておきます。

設計・開発での標準と追加開発の切り分け

設計では、システムの仕様のうち、標準機能と追加開発の境界を明確にします。

設計範囲：画面、データ、API、認証、権限、エラー処理、外部サービス接続
実装方針：標準設定を優先し、検索体験、会員特典、商品提案、独自受注を追加候補にする
変更管理：標準機能を変える場合の、将来の更新への影響の記録
データ移行：件数だけでなく品質も難所です。商品コード、価格期間、画像名、会員メール、注文履歴、退会者データを整理します
移行確認：公開直前の一度きりにせず、複数回試して差分移行、照合、切り戻しを確かめる

テスト・リリースでの実業務とピークの再現

公開前後の確認は、実業務の操作や例外対応から始めて、リリース準備、効果測定の順に進めます。

単体、結合、総合、受入、性能、セキュリティ、移行、運用訓練を行います。
担当者が、検索、購入、決済、引当、出荷、メール、返品、返金の操作を通して確かめます。
クーポン併用、会員ランク変更、在庫切れ、分割配送、決済失敗、外部API停止のケースも試します。
注文停止時間、問い合わせ窓口、監視ダッシュボード、障害時の連絡網、ロールバック条件を明確にします。
公開後の数週間は、購入率、検索ゼロ件率、決済失敗率、在庫差異、返品時間、問い合わせ件数を見て改善します。

費用相場と開発期間の目安

案件範囲が広がるにつれて、費用の概算幅も大きくなります。

Salesforceの公式価格ページでは、Growth、Plus、Commerce Cloud B2C Premiumのいずれも個別見積もりとされています（出典：Salesforce公式B2C Commerce価格ページ、2026年8月参照）。Growthは5サイト・10価格表、Plusは100サイト・3,500価格表です。

Premiumも100サイト・3,500価格表で、注文管理やData Cloud連携などが示されています。公開されている一律の円価格からは、総額を判断できません。

▶ 詳細はこちら：Salesforce Commerce Cloudのシステム開発の見積相場や費用/コスト/値段について

案件規模別の初期導入・開発費

掲載する金額は、公式のライセンス価格ではなく、一般的なエンタープライズECの工程、人月、連携範囲をもとにした2026年時点の記事用の概算です。

検証・最小構成：300万〜800万円
SFRAで1〜2ブランドを本番導入：1,500万〜4,000万円
複数ブランド・多言語・OMSやCRM連携：4,000万〜1億5,000万円
全社・グローバル刷新：1億〜3億円以上

金額は、要件定義やUX、画面、データ移行のどこまでを含めるかで変わります。決済・配送・基幹連携、テスト、教育についても、含める範囲で金額が動きます。

ライセンスや取引量連動費、導入支援は、別料金の場合があります。Success PlanやAI、OMS、Data Cloudも、別料金になることがあります。

決済や検索、レビュー、翻訳サービスは、別料金になる場合もあります。見積書では、この部分を分けてもらいます。

開発期間とランニングコストの目安

期間と運用費は、構成の規模や契約条件ごとに分けて見積もります。

PoC・最小構成：1〜3か月
SFRA・1〜2ブランド：4〜8か月
複数ブランド・多言語・周辺連携：8〜18か月
全社・グローバル刷新：12〜24か月以上
運用費の例：開発費の年15〜25%、または月15万〜80万円程度

期間は、商品点数や会員数、注文履歴の移行量によって前後します。国・通貨数、API品質、社内承認の速さも影響します。

期間を短くするには、初回の範囲を絞り、後続の工程をロードマップに置きます。

運用費には、ライセンスや取引量連動費、追加サービス、保守が含まれます。監視や改善開発、コンテンツ、人材育成も、運用費の対象です。

保守額は、規模や対応時間によって変わり、障害対応や改善作業も関わります。

月次の保守時間や緊急対応の扱い、追加開発単価、未使用時間の扱いを、契約前に確認します。

ポイント

費用は、工程ごとに分けた見積書で比べます。ライセンスや保守を含めて、前提がそろった見積もり同士でなければ、総額の差の理由は分かりません。

開発会社/ベンダーの選び方

知名度や資格だけでなく、自社の業務と方式に合う会社を選びます。実績があっても、B2C中心の会社とB2B中心の会社では得意な領域が異なります。

会社名で比べる前に、RFPに要件と評価基準を書き、同じ前提で提案を受けると、各社を判断しやすくなります。

同規模・同業務の実績と担当範囲

選定では、近い案件の実績と、実際の担当体制、委託条件を確認します。

案件との近さ：売上、商品点数、ブランド数、国、会員数、B2C・B2B、担当工程
技術実績：SFRA、Composable Storefront、SCAPI、Commerce Appsの実績を、それぞれ分けて見る
業務連携：OMS、ERP、PIM、決済、配送、返品ごとの実績
参加体制：責任者、アーキテクト、移行・テスト・運用の担当者を確認し、引き継ぎや体制変更は契約に定める
委託条件：再委託、海外アクセス、個人情報、コードや設定の引き渡し

見積の前提・保守・内製化支援の比較

見積もりは、工程、作業範囲、前提条件をそろえて比較します。

工程別費用：要件定義、設計、開発、連携、移行、テスト、教育、公開、保守
作業範囲：API、バッチ、エラー処理、移行リハーサル、性能試験も含めて比べる
見積前提：商品・会員件数、注文履歴、外部システム・環境、テストデータ、会議回数
内製化支援：コードだけでなく運用、公開、障害対応、分析、開発者向け説明を含める
保守条件：月額範囲、改善料金、更新対応、担当変更時の引き継ぎ

画面数だけの見積もりでは、連携や移行、性能試験が抜けることがあります。保守範囲まで含めると、稼働後の費用と依存度を把握できます。

▶ 詳細はこちら：Salesforce Commerce Cloudのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Salesforce Commerce Cloudのシステム開発の発注/外注/依頼/委託方法について

ポイント

会社を比べる前に、同じ要件と評価基準で提案を受けておくと、各社の強みと前提の違いが見えます。実績は、自社と近い案件か、どの工程を担当したかまで見ると判断の材料になります。

セキュリティと2026年の最新動向

クラウドのセキュリティ機能があっても、EC事業者の責任は残ります。そのため、基盤や導入設定、コードについて、どこまでを誰が受け持つかを決めます。外部連携や決済、アカウント、運用も、同じように分けておきます。

個人情報へのアクセス権や二要素認証、管理者権限は、定期的に確認します。APIクライアントや秘密情報、ログも、定期的に確認する項目です。脆弱性対応や委託先も、定期的に確認する対象です。

決済と個人情報の対策と担当の範囲

決済方式ごとに対策の担当範囲を分け、事業者側で必要な確認を進めます。

カード情報：自社で保持するか決済サービスに委託するかで、設計や審査の範囲が変わる
セキュリティ対策：PCI DSS、脆弱性診断、EMV 3-Dセキュア、不正注文、乗っ取り、パスワードリセット監視
責任分界：プラットフォームの機能と自社の運用に分け、担当を決める

経済産業省は2025年3月末までに、原則としてすべてのEC加盟店でEMV 3-Dセキュアを進める方針を示しました（出典：経済産業省「クレジットカード・セキュリティガイドライン」、2024年資料）。

2026年の新規導入でも、決済事業者やカード会社、サイト、サポートの役割を定めます。認証に失敗したときの購入導線も、テストします。

AI活用の前提となるデータ品質と権限

AI活用では、提供機能の動向を見ながら、参照するデータと運用体制を整えます。

利用前の準備：商品情報、価格の有効期限、在庫の更新頻度、有人への引き継ぎ、プロンプトとログの権限
効果測定：小さな商品カテゴリで試したうえで、回答正確率、有人転送率、購入率、問い合わせ削減率を測る

2025年11月には、国内向けのAgentforceとして、会話で商品発見から購入完了までを支援する機能の提供開始が発表されました（出典：Salesforce公式プレスリリース、2025年11月）。

2026年は、ガイド付きショッピングやAI検索が注目されています。ただし、追加すればすぐ売上が伸びるとは限りません。参照データが誤っていると、誤案内やクレームにつながります。

よくある質問

導入前によくある疑問を、判断に必要な範囲で答えます。契約条件や既存システムによって結論が変わる場合は、要件と見積前提を確認してください。

Salesforce Commerce Cloudのシステム開発費はいくらですか？

ライセンスは、公式ページでは個別見積もりです。総額は要件によって変わり、最小検証の概算は300万〜800万円です。

1〜2ブランドの本番導入は1,500万〜4,000万円、複数ブランドや基幹連携を含む場合は4,000万〜1億5,000万円が目安です。

ライセンスや導入支援、追加サービス、保守は、それぞれ分けて見積もります。

中小規模の企業でも導入できますか？

導入できますが、機能と運用体制を絞ることが大切です。1ブランド、標準寄りの画面、限定的な商品・会員・注文連携から始めます。

購入率や受注処理時間を見て、段階的に広げていきます。一方で、複雑な基幹連携や多言語を初回から含めると、規模にかかわらず費用と期間が増えます。

Commerce CloudだけでECシステムは完成しますか？

すべての企業で、Commerce Cloudだけで完成するとは限りません。データの管理場所によっては、ERPやPIM、OMS、WMSとの連携が必要です。

決済や配送、返品との連携も、必要になることがあります。さらに、CRMや分析との連携も含まれます。

Commerce Cloudを中心に、業務全体で誰が何を受け持つかを設計します。

AI機能は導入時から追加すべきですか？

初回から必ず追加する必要はありません。まず、商品や価格、在庫の条件を整え、権限と有人対応を設計します。配送や返品の条件も、整えておく必要があります。

検索や商品提案のように測りやすい用途から始め、再注文や注文状況の確認にも広げていきます。回答正確率や購入率を見ながら、誤回答や有人転送、データ更新の遅延も監視します。

まとめ

導入判断で押さえる3つの要点

Salesforce Commerce Cloudは、EC構築に加えて、顧客や商品、注文をつなぐ基盤です。在庫やマーケティング、サービスも、同じ基盤でつながります。

B2Cは購入体験と大量アクセスを、B2Bは取引先別の価格や承認、複雑な注文条件を重視します。方式は目的と体制で選びます。

標準活用のSFRA、自由度の高いComposable、既存資産を活かすハイブリッドが候補です。

次に確認する項目

ライセンスだけでなく、連携や移行、テストまでを総保有コストに含めて比べます。セキュリティや保守、AIも、同じ総保有コストの中で見ます。

業務とデータの正本を整理し、標準化する領域と差別化する領域を分けます。MVPから測定と改善を繰り返します。

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