Salesforce Commerce Cloudのシステム開発は、要件整理から定着までの6段階で進みます。各段階で成果物と承認者を決めて次へ進めると、稼働後もEC運用を継続的に改善できます。
全体像は、下に載せた完全ガイドでも確認できます。
▼全体ガイドの記事
・Salesforce Commerce Cloudのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Salesforce Commerce Cloudのシステムの全体像
Salesforce Commerce Cloudは、B2CまたはB2BのECを運営するクラウド型のコマース基盤です。日本の公式サイトでは2026年時点で「Agentforceコマース（旧Commerce Cloud）」とも表記されています。
開発現場や検索では、SFCC、Commerce Cloud、B2C Commerceという呼び方も残っています。名称にかかわらず、導入の対象は販売チャネルと周辺業務を含めたシステム全体です。この全体を前提に、導入範囲を決めます。
B2CとB2Bで最初に決めることの違い
B2Cでは、不特定多数の買い物客が商品を探し、カートに入れて決済する体験を整えます。大量アクセスにも備えます。
複数ブランドや国・言語・通貨を扱う場合は、管理単位を先に決めておきます。B2Cでは、サイトや価格表などの管理単位を決め、B2Bでは、取引先別の価格や承認フローなどの業務要件を確認します。
- B2Cの管理単位：サイト、カタログ、価格表、税、配送、キャンペーン
- B2Bの業務要件：取引先別価格、購入権限、購買担当者、承認フロー、見積・再注文、請求条件
B2Cの画面をそのまま流用すると、B2B業務に合いません。そのため、対象顧客と注文プロセスは、要件定義の冒頭で分けておきます。
Commerce Cloudだけで、商品作成、在庫管理、倉庫作業、返品、顧客サポートまで完結するとは限りません。そこで、情報ごとに正本を持つシステムを決めておきます。
- 商品情報：PIM
- 在庫・出荷：ERP・WMS
- 注文分割・返品：OMS
- 顧客接点：Salesforce CRMやMarketing Cloud
商品・価格・在庫の正本が曖昧なままだと、連携後に表示価格や在庫数がずれるおそれがあります。
標準機能と追加開発の境界の設計
商品、検索、カートは、できるだけ標準機能に寄せます。チェックアウトと会員も、標準機能を基本に組みます。注文とプロモーションは、標準機能に寄せて作ります。
- 拡張候補：診断、セット販売、会員ランク、店舗受け取り
- 避けたい実装：標準と同じ機能を別コードで作るカスタマイズ
標準機能に寄せておけば、アップデートの影響を受けにくくなります。運用担当者にとっても、管理しやすくなります。ただし、独自の競争力につながる機能は、拡張候補として別に検討します。
開発方式は、SFRA、SCAPIとPWA Kitなどを使うコンポーザブル・ヘッドレス、両者を組み合わせるハイブリッドに分かれます。
公式開発者ドキュメントでは、SFRAをストアフロントの設計・実装の出発点となるフレームワークとしています。一方、Composable Storefrontは、フロントエンドとコマース機能をAPIで分ける方式です。
方式を比べるときは、画面の自由度に加えて、SEO、認証、キャッシュ、監視、CI/CDを誰が担うかも見ます。
Salesforce Commerce Cloudのシステム開発の進め方
開発は、6つのフェーズに分けて進めます。前半は要件整理、方式・パートナー選定、設計・開発で、後半はテスト、稼働、定着です。工程を分ける目的は、次へ進む条件を明確にすることです。
各段階では成果物と承認者を決めておき、次の段階へ進む条件を満たしているかを確かめます。また、未決定の事項を持ち越す場合は、期限と影響範囲を記録しておきます。
1. 要件整理：業務とデータの全体像
現行ECの課題は、売上、顧客体験、業務効率、運用リスクの4方向から整理します。その際、症状をそのまま機能要件にせず、改善したい状態の形で書いておくことが大切です。
たとえば表示速度を改善する場合は、対象ページ、端末、時間帯、現在の指標、改善目標を定義しておきます。キャンペーンなら、設定者、条件、時期、承認まで業務フローに落とし込みます。
要件整理では、次のとおり項目を確かめます。
- 事業・顧客：B2CかB2Bか、対象ブランドと国、言語・通貨・税
- 商品・取引：商品・価格・在庫の正本、会員移行、決済・配送・返品、不正利用対策
- システム・運用：SEO URL、アクセスピーク、権限・監査ログ、連携方向・頻度・障害時の再送
KPIは、CVR、平均注文単価、検索利用率、カゴ落ち率、商品登録時間、注文処理時間などから選びます。導入後に検証できる指標は、3〜5個に絞ります。
成果物は、業務フロー、機能一覧、非機能要件、データ項目表です。連携一覧、移行方針、KPI、概算スケジュールも、成果物に含めます。データ項目表では、各項目を持つシステムを確認します。
例として、SKU、商品名、画像、価格、在庫は、それぞれの保有元を一行ずつ整理します。会員IDや注文番号も、同じように整理します。
提案は、機能数だけでなく、抜け漏れと責任分担の両面で比べます。
2. 選定：SFRA・コンポーザブル・ハイブリッドの比較
方式を選ぶときは、「画面を自由に作りたい」という要望を、事業の目的に置き換えて考えます。そのうえで、目的と運用体制が合う方式を選びます。
各方式が向くのは、次のような場合です。
- コンポーザブル：ブランド表現を短周期で変える、アプリ・店舗端末へ商品・注文機能を提供、既存基幹APIを活用
- SFRA：1ブランドで標準的なECを早く立ち上げ、Business Manager中心に運用したい場合
- ハイブリッド：既存SFRAを維持し、効果の大きい画面から段階移行したい場合
SCAPIを使うコンポーザブル方式は、こうした目的がある場合の候補になります。SFRAを起点にすると、実装範囲を抑えやすくなります。
ハイブリッドでは、トップページ、商品検索、会員ページなど効果の大きい領域から移行できます。全画面を同時に刷新しないため、リスクを抑えられます。一方で、旧画面と新画面の認証、カート、計測、デザインシステムをつなぐ設計が必要です。
開発会社には、次の実績と担当範囲を尋ねます。
- 導入実績：同業・同規模の事例、SFRA・SCAPIの担当実績
- 連携・移行：OMS・ERP・PIM・WMS・決済との連携、データ移行責任者
- 運用支援：テスト計画、保守、内製化支援の範囲
Salesforce Japan Partner Awardなどの受賞歴は、候補を探す入口として使えます。ただし、過去の表彰が現在の担当チームや品質を保証するわけではありません。
提案の時点で有効な認定資格、実装者の経験、再委託の有無を確かめます。あわせて、移行中の二重運用を誰が担うかも決めておきます。
3. 設計・開発：標準寄りの構成による段階的な開発
画面、業務、データ、連携、権限、運用は、一つのアーキテクチャにまとめておきます。
B2C Commerceでは、公式ドキュメントに示されたSandbox、Staging、Development、Productionなどの環境を使い分けます。Stagingから本番へ、データやコードをレプリケーションする構成も説明されています。
環境ごとに、設定変更者、テスト内容、本番移行の承認者を決めておくと、手作業による事故を減らせます。
設計と実装は、データから運用へ、次の順に具体化します。
- 商品・価格・在庫・顧客・注文のデータモデルを決める
- APIやバッチによる連携の設計
- 画面と業務ルールの設計
- 監視・ログ・権限の整備
連携仕様では、送信元と送信先、項目、タイミングを定義します。加えて、件数、タイムアウト、再送、重複排除、エラー通知も決めておきます。
リアルタイム連携が本当に必要かも見直します。そのうえで、在庫や価格は即時、分析用データは日次など、業務への影響に応じて頻度を分けます。
開発は、商品表示、検索、カート、チェックアウト、会員、注文連携などの業務単位で優先します。まずは最小構成を作ります。
1ブランド・主要商品・代表的な決済と配送でMVPを作ります。受け入れ基準を満たしたら、キャンペーン、多言語、他ブランドへ広げます。
独自要件は、標準設定、既存拡張、カスタム実装の順に検討します。また、アップデート時に修正が必要なコードも記録します。
4. テスト：正常系に加えたピークと障害の検証
テストは、単体、結合、システム、受け入れの順に行います。商品検索から注文完了までの正常系に加えて、次の例外も確認します。
- 注文・在庫：在庫切れ、価格変更、注文キャンセル、返品、連携遅延
- 決済・操作：クーポン併用、決済失敗、配送先変更、二重送信
- B2B：取引先別価格、購入上限、承認者不在、代理注文、再注文権限
性能テストでは、平常時だけでなく、セールや広告流入のピーク、検索の大量実行、在庫更新と注文集中が重なる状況を再現します。応答目標も、トップページだけでなく、商品一覧、商品詳細、カート、決済、会員ログインごとに定めます。
コンポーザブルでは、サイト全体の数字で判断する前に、フロントエンド、SCAPI、認証、CDN、外部検索・決済のどこが遅いかを分けて測ります。
セキュリティでは、Salesforce側の基盤対策と自社が担う責任を分けて考えます。さらに、権限、多要素認証、ログ監視、個人情報の保持期間を確認します。脆弱性診断、サードパーティースクリプト、委託先からのアクセスも、テストの対象です。
経済産業省のクレジットカード・セキュリティガイドライン5.0版は、原則として2025年3月末までのEC加盟店に、EMV 3-Dセキュア導入を示しました。そのため、決済代行会社との間で、認証、不正利用検知、チャージバック対応の分担を決め、テスト計画に含めます。
5. 稼働：移行と切り戻しの準備と公開
まず、稼働前に移行対象を確定し、データの品質と切り替え手順を確認します。
- 移行対象：商品、顧客、注文、ポイント、クーポン、画像
- データ確認：不要データ、文字コード、重複、欠損、ID対応表
- 切り替え準備：旧サイトの停止時間、最終差分、DNS・タグ、問い合わせ窓口を日付・担当者つきで決定
移行リハーサルは、少なくとも一度実施します。件数の照合のほか、代表商品と会員で検索、ログイン、注文、返品まで試します。
切り替えの判断には、受け入れテストの未解決件数、重大障害の有無、決済成功、在庫・注文連携を使います。加えて、バックアップ、監視、問い合わせ体制も判断材料にします。
切り戻しの基準は、どの指標が何分続いたら戻すかで決めておきます。切り戻し時の注文や会員情報の扱いも、ランブックに記しておきます。
段階公開が可能なら、社内利用者、限定顧客、1ブランドの順に広げ、状況を観測してから全体公開します。
公開当日は、開発会社、EC運用、CS、物流、決済を含む体制を置きます。マーケティングの担当者と経営判断者も、加えておきます。
注文だけでなく、商品登録、在庫更新、キャンペーン設定、売上集計、返品受付まで、業務担当者だけで実行できるかを確かめます。
特に、稼働直後の数日間は、通常保守とは別に、障害の優先度と連絡経路を一本化しておきます。
6. 定着：運用指標に基づく改善サイクル
稼働後は、担当者が自ら改善できる状態を作ります。運用手順と責任者を定め、実業務に沿って習熟を支援します。
- 日常業務：商品登録、価格変更、在庫連携、キャンペーン
- 注文・障害：注文訂正、返品、権限申請、障害対応、リリース
- 習熟支援：実データを使った研修、問い合わせ分類、FAQ・手順の更新
定着の度合いを見るには、ログイン人数に加えて、次の業務指標を月次で確認します。
- 業務効率：商品登録時間、キャンペーン公開リードタイム、返品処理時間
- 品質・成果：注文エラー率、問い合わせの自己解決率、リリース後の障害件数、CVR、検索経由の売上
SalesforceのAIやAgentforceガイド付きショッピングを追加する場合は、商品属性、在庫、価格、配送予定、顧客権限のデータ品質を先に点検します。そのうえで、AIの回答を監査できる状態も整えます。
定着フェーズの契約では、問い合わせ対応に加えて、月次改善提案、リリースノート確認、脆弱性・権限レビューを、それぞれ別に見積もります。性能監視、データ品質点検、内製化支援も、別項目として見積もってもらいます。
運用をすべて外部に任せたままだと、改善のたびに追加費用が生じやすくなります。そのため、社内業務と専門会社に任せる技術領域を半年ごとに見直すと、長期の総保有コストを抑えられます。
Salesforce Commerce Cloudのシステム開発費用相場と内訳
費用は、ライセンス、導入支援・開発、外部連携に分けて考えます。さらに、データ移行、運用保守、追加サービスも、別の項目として分けて見ます。公式価格ページでは、各エディションが個別見積もりとされています。
Growth、Plus、Commerce Cloud B2C Premiumは「Contact for pricing」です。サイト数や価格表数などの上限は示されていますが、日本円の一律価格は公開されていません。そのため、月額を断定する記事や見積もりには注意が必要です。
開発費の規模と連携範囲による違い
開発費の概算レンジは、構成や連携の範囲によって異なります。次の金額は、Salesforce公式価格ではありません。
- 小規模PoC・1ブランド最小構成：300万〜800万円程度
- SFRAで1〜2ブランドを本番導入：1,500万〜4,000万円程度
- 複数ブランド・多言語・OMSやCRM連携：4,000万〜1.5億円程度
- グローバル基幹刷新・段階移行を含む：1億〜3億円以上
これらは、リサーチノートの一般的な業務システム相場と、導入範囲や人月構造から作った記事用の概算です。実額は、個別見積もりで確定します。
期間も構成によって変わります。PoCは1〜3か月、1〜2ブランドの本番導入は4〜8か月が目安です。
複数国やOMS・ERP・PIMを含む場合は8〜18か月、全社・グローバル刷新では12〜24か月以上になります。
期間を左右するのは、商品点数、会員数、API数に加えて、現行データの品質です。社内の意思決定の速さ、コンテンツの準備、移行リハーサルの回数も影響します。
短納期を優先するなら、機能を削るのか、対象ブランドを絞るのか、標準に寄せるのかを明記します。
ライセンス・実装・運用の費用を分けた積み上げ
費用は、次の3区分ごとに積み上げます。
- ライセンス：エディション、サイト・価格表数、取引量、注文管理、Data Cloud、CRM Analytics、AI、Sandbox、Success Plan
- 実装：要件定義、設計、画面、決済、連携、移行、テスト、リリース、研修
- 運用・外部サービス：監視、障害対応、軽微改修、定期リリース、脆弱性対応、データ品質管理、各種サービス利用料
公式価格ページでは、Growthは5サイト・10価格表、PlusとPremiumは100サイト・3,500価格表です。Premiumには、フル注文管理やData Cloud関連機能を含む構成があります。
Premier Success Planは、純ライセンス料の30%と掲載されています。採用する場合は、別の行に置きます（出典: Salesforce B2C Commerce Pricing、2026年8月確認）。
決済代行、検索、レビュー、翻訳、CDNの利用料が、別になる場合もあります。PIM、OMS、WMS、MuleSoftなども同様に、利用料や保守費が別立てになることがあります。そのため、5年間の総保有コストで比べます。
運用費に、これらの作業が含まれるかどうかは、見積書で確かめます。
事例の数字と前提条件の読み取り
成果事例の数字は、自社の予算や効果の推定にそのまま使わず、資生堂事例の報告値と前提を確かめます。
- 表示速度：コンポーザブルストアフロントで4倍に高速化
- コンバージョン率：13％向上
- API：100以上から一桁台に集約
これらはSalesforce Japanの事例です（出典: Salesforce Japan「資生堂」導入事例、2026年8月確認）。
これらの前提には、グローバルブランド、既存のCommerce Cloud、MuleSoft、Data Cloudなどがあります。このため、自社も同じ結果になるとは限りません。
効果はCVRだけでなく、表示速度、開発サイクル、API運用費、商品登録時間、問い合わせ削減などで見ます。
事例を使うときは、刷新前の課題、対象ページ、移行範囲、導入期間、運用体制、測定方法を確かめます。公開された数値と自社の仮説は、分けて扱います。
Salesforce Commerce Cloudの見積もりを取る際のポイント
見積もりで確認したいのは、金額の安さよりも、追加費用と責任範囲です。RFPには、要件、対象範囲、品質基準、希望時期、既存システムを記載します。
データ件数、ピークアクセス、運用体制も、同じ条件で各社に伝えます。そのうえで、ライセンス、実装、外部サービス、移行、保守を分けて提案してもらいます。
要件と受け入れ基準の先行整理
要件が曖昧なまま一括で見積もると、開発後に追加費用が生じやすくなります。そのため、機能名だけでなく、利用者、前提データ、操作、例外、完了条件まで記しておきます。
検索要件には、対象項目、絞り込み、並び順、在庫表示、検索ゼロ件時の動作、速度目標を含めます。また、連携要件には、項目、頻度、再送、重複防止、監視通知を書きます。
RFPの添付資料は、現状、データ、構成、品質、運用が伝わるものにします。
- 業務・データ：業務フロー、画面一覧、データ項目、連携一覧、商品・会員・注文サンプル
- 事業・品質：ブランド・国、ピーク時のアクセス・注文数、セキュリティ要件、移行対象
- 運用：社内体制と実際の例外ケース
サンプルデータは、個人情報をマスキングしておきます。受け入れ基準は、担当者が検証できる文章にし、テスト見積もりと同じ言葉で書きます。
複数社の体制と成果物による比較
候補会社は、Salesforce販売元、コンサルティングパートナー、SIer、デジタルエージェンシーなど、役割が異なります。そこで、各社を比べるときは、次の点を並べて見ます。
- 担当体制：要件定義、設計、SFRA・SCAPI実装、連携、テスト、稼働後保守の責任者
- 担当者の経験：経験年数、認定資格、類似案件の範囲、再委託先
- 協業方法：英語や海外拠点との連携方法
見積書では、工程別工数、単価、前提、除外を見ます。加えて、変更管理、検収・支払い条件、保守応答時間も確認します。
「標準機能で対応」の範囲に、設定、データ整備、画面調整、テスト、マニュアル作成が含まれるかを質問します。
安い提案が悪いとは限りません。ただし、要件定義、移行、障害時の再送、稼働後の改善が除外になっていれば、実際の総額は変わります。
リスクと責任分界の契約への落とし込み
契約の前に、想定されるリスクを洗い出し、対応と責任者を決めておきます。
- 開発・移行：要件変更、データ移行品質、性能不足
- 外部・サービス：外部仕様変更、決済障害、Salesforceのリリース影響
- 情報管理：個人情報漏えい、外部スクリプトの脆弱性
基盤の可用性や認証機能があっても、加盟店側のPCI DSS対応、個人情報保護法上の安全管理、EMV 3-Dセキュア、不正ログイン対策、委託先監督は別途必要です。
契約と設計書には、障害の一次切り分け、ログ保管期間、データ所有権、設定・ソース・文書の引き渡し、再委託を明記します。
退任時の引き継ぎ、環境の削除、個人情報を扱う作業の承認も、あらかじめ定めておきます。さらに、Salesforce、開発会社、決済会社、社内運用チームの間で、どこまでを誰が受け持つかを図にして示します。
Salesforce Commerce Cloudのシステム開発でよくある質問
導入前によくある質問を、判断の基準とあわせて並べます。判断では、売上規模だけでなく、ブランド数、国・言語、連携数、業務の複雑さ、運用体制も見ます。
Salesforce Commerce Cloudは中小規模のECにも向いていますか？
企業の規模よりも、将来の拡張性に投資する目的があるかで判断します。その目的には、複数ブランド、海外展開、CRM連携、高い運用統制などが含まれます。
ライセンス・開発・運用を含む総保有コストを負担できるなら候補です。一方、1ブランドで商品数が少なく、標準販売を低コストで始めたい場合は、他サービスも比べます。
Commerce Cloudを選ぶ理由は、数値で説明できるように整えておきます。
SFRAとコンポーザブルストアフロントはどちらを選べばよいですか？
短期の立ち上げと標準運用を優先するならSFRA、フロントの自由度や複数チャネル展開を重視するならコンポーザブルが、基本の判断軸になります。
コンポーザブルでは、フロント、認証、キャッシュの設計と保守が増えます。さらに、SEO、監視、CI/CDも同様に増えます。ただし、全画面を一度に移行する必要はありません。
既存SFRAにSCAPIを組み合わせるハイブリッドで、効果を確かめながら段階移行する方法もあります。
ライセンス費用を公開情報だけで算出できますか？
一律の日本円価格は、公開情報からは算出できません。Salesforce公式B2C Commerce価格ページでも、各エディションは個別見積もりとされています。
そのため、サイト数、価格表数、注文管理、Data Cloud、Success Planなどの構成を整理し、営業担当へ相談します。
公開情報から必要なエディションと追加サービスを洗い出せば、ライセンス、実装、連携、運用を分けた予算枠を作れます。
クラウドなのでセキュリティ対策をすべて任せられますか？
クラウド事業者は基盤やサービス側を担いますが、顧客側にもセキュリティ対応が残ります。そのため、対策をすべて任せることはできません。
- アカウント・権限：権限設定、管理者アカウント、多要素認証
- データ・運用：個人情報、外部連携、決済運用、ログ監視
- 継続管理：脆弱性対応、委託先管理
要件定義で責任分界表を作り、設計、テスト、運用の各工程で、その内容を確かめます。
Salesforce Commerce Cloudのシステム開発のまとめ
Commerce Cloudの開発は、要件整理から定着まで、各工程の完了条件を確かめながら進めます。そのうえで、業務の違い、データの正本、連携、開発方式、移行、責任分界は、初期の段階で決めておきます。
着手時に作る資料の3点への絞り込み
着手の時点では、現行業務の把握、データと連携の責任の整理、効果の測り方の3つを資料にまとめておきます。
- 現状把握：現行業務フローと課題一覧
- データ整理：データ・連携の責任分界表
- 効果検証：KPIと受け入れ基準
次に、1ブランド・主要商品・代表的な決済と配送でMVPを定めます。SFRA、コンポーザブル、ハイブリッドの提案を、同じ条件で比べます。
見積書は、ライセンス、開発、連携、移行、運用に分けて作ってもらいます。Success Planと外部サービスの費用も別に示してもらい、期間と除外事項まで確かめます。MVPの範囲をそろえておくと、各社の費用を横並びで比べられます。
導入後の改善まで含めた計画
公開後の成果確認と継続的な運用に向けて、次の観点を月次の改善計画に反映します。
- 公開後の指標：CVR、売上、商品登録時間、注文エラー、返品処理、問い合わせ
- 改善サイクル：リリース速度とデータ品質も見て、月次改善につなげる
- AI・新チャネル：商品・価格・在庫・顧客データと権限の事前整備
- 長期運用：社内に運用知識を残し、5年間の総保有コストと成果を見直せる体制
▼全体ガイドの記事
・Salesforce 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を創業。