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

Salesforce Commerce Cloudのシステム開発は、ECサイトを作るだけではなく、商品・顧客・注文・在庫・決済をつなぎ、売上と運用を継続的に伸ばす仕組みを段階的に整える取り組みです。

「どこから要件を決めればよいか」「SFRAとコンポーザブルのどちらを選ぶべきか」「費用や期間をどう見積もるか」と悩む担当者向けに、Salesforce Commerce Cloudのシステム開発の進め方を、要件整理から稼働後の定着まで6つのフェーズで解説します。2026年時点の名称や価格の考え方、実務で使える確認項目も紹介します。

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

Salesforce Commerce Cloudのシステムの全体像

Salesforce Commerce Cloudは、B2CまたはB2BのECを運営するクラウド型のコマース基盤です。日本の公式サイトでは2026年時点で「Agentforceコマース（旧Commerce Cloud）」という表記も使われていますが、開発現場や検索ではSFCC、Commerce Cloud、B2C Commerceという呼び方も残っています。名称が変わっても、導入時に整理すべき対象は、販売チャネルとその周辺業務を含む一つのシステムです。

B2Cでは、不特定多数の買い物客が商品を探し、カートに入れ、決済する体験を大量アクセスに耐えられる形で整えます。複数ブランドや国・言語・通貨を扱う場合は、サイト、カタログ、価格表、税、配送、キャンペーンの管理単位を先に決めます。B2Bでは、取引先ごとの価格や購入権限、購買担当者、承認フロー、見積・再注文、請求条件などが加わります。B2Cの画面を流用するだけでは業務に合わないため、対象顧客と注文プロセスを要件定義の冒頭で分けてください。

また、Commerce Cloudだけで商品情報の作成、在庫の正本管理、倉庫作業、返品処理、顧客サポートのすべてが完結するとは限りません。商品はPIM、在庫と出荷はERP・WMS、注文の分割や返品はOMS、顧客接点はSalesforce CRMやMarketing Cloudというように、正しい情報を持つシステムを決める必要があります。商品・価格・在庫の「正本」を曖昧にしたまま開発を始めると、連携後に表示価格や在庫数がずれるためです。

Commerce Cloudの開発では、商品、検索、カート、チェックアウト、会員、注文、プロモーションなどの一般的な業務は、できるだけ標準機能に寄せることが基本です。自社独自の競争力につながる診断、セット販売、会員ランク、店舗受け取りなどは拡張候補になりますが、標準と同じ機能を別コードで作るだけのカスタマイズは避けます。標準に寄せれば、アップデートの影響を受けにくく、運用担当者が管理しやすいからです。

開発方式は、SFRAを利用する方式、SCAPIとPWA Kitなどを利用するコンポーザブル・ヘッドレス方式、両方を組み合わせるハイブリッド方式に分けて検討します。公式開発者ドキュメントでは、SFRAはストアフロントの設計・実装の出発点となるフレームワーク、Composable Storefrontはフロントエンドとコマース機能をAPIで分離する方式として説明されています。画面の自由度だけでなく、SEO、認証、キャッシュ、監視、CI/CDを誰が持つかまで比較することが大切です。

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

進め方は、要件整理、方式・パートナー選定、設計・開発、テスト、稼働、定着の6フェーズに分けると判断しやすくなります。フェーズを分ける目的は、作業を細かく見せることではなく、次の工程へ進む条件を明確にすることです。各段階で成果物と承認者を置き、未決定事項を次工程へ持ち越す場合は、期限と影響範囲を記録します。

最初に、現行ECの課題を売上、顧客体験、業務効率、運用リスクの4方向から整理します。「表示が遅い」「キャンペーン設定に時間がかかる」といった症状を、そのまま機能要件に変えてはいけません。たとえば表示速度なら、対象ページ、端末、時間帯、現在の指標、改善目標を定義し、キャンペーンなら、誰がどの条件をいつ設定し、どの承認を受けるかまで業務フローに落とします。

要件整理のチェックリストは、B2CかB2Bか、対象ブランドと国、言語・通貨・税、商品・価格・在庫の正本、会員情報の移行範囲、決済・配送・返品、不正利用対策、SEO URL、アクセスピーク、権限と監査ログ、外部システムの連携方向・頻度・障害時の再送です。ここでKPIも決めます。CVR、平均注文単価、検索利用率、カゴ落ち率、商品登録時間、注文処理時間などから、導入後に改善を検証できる指標を3〜5個に絞ります。

成果物は、業務フロー、機能一覧、非機能要件、データ項目表、連携一覧、移行方針、KPI、概算スケジュールです。特にデータ項目表では、SKU、商品名、画像、価格、在庫、会員ID、注文番号をどのシステムが持つかを一行ずつ確認します。この資料ができていれば、開発会社の提案を機能数ではなく、抜け漏れと責任分担で比べられます。

方式選定では、まず「画面を自由に作りたい」という要望を、事業上の目的に置き換えます。ブランド表現を短いサイクルで変えたい、アプリや店舗端末にも同じ商品・注文機能を提供したい、既存基幹のAPIを活用したいという目的なら、SCAPIを使うコンポーザブル方式が候補になります。一方、1ブランドで標準的なECを早く立ち上げ、運用チームがBusiness Managerを中心に管理したいなら、SFRAを起点にする方が実装範囲を抑えやすいです。

ハイブリッド方式は、既存SFRAを維持しながら、トップページ、商品検索、会員ページなど効果の大きい領域から段階移行する考え方です。全画面を同時に刷新しないため、リスクを抑えられますが、旧画面と新画面の認証、カート、計測、デザインシステムをつなぐ設計が必要です。選定時は、方式名よりも、移行期間中の二重運用を誰が管理するかを確認してください。

開発会社には、同業・同規模の事例、SFRAとSCAPIの担当実績、OMS・ERP・PIM・WMS・決済との連携経験、データ移行の責任者、テスト計画、保守と内製化支援の範囲を質問します。Salesforce Japan Partner Awardなどの受賞歴は候補を探す入口になりますが、過去の表彰が現在の担当チームや品質を保証するわけではありません。提案時点の認定資格、実装者の経験、再委託の有無を確認することが重要です。

設計では、画面、業務、データ、連携、権限、運用を一つのアーキテクチャにまとめます。B2C Commerceの公式ドキュメントでは、Sandbox、Staging、Development、Productionなどの環境を使い分け、Stagingから本番へデータやコードをレプリケーションする構成が説明されています。環境ごとに誰が設定変更できるか、何をテストし、どの承認で本番へ移すかを決めておくと、手作業による事故を減らせます。

設計の順番は、まず商品・価格・在庫・顧客・注文のデータモデル、次にAPIやバッチによる連携、続いて画面と業務ルール、最後に監視・ログ・権限という流れが安全です。連携仕様では、送信元、送信先、項目、タイミング、件数、タイムアウト、再送、重複排除、エラー通知を定義します。リアルタイム連携が本当に必要かも見直し、在庫や価格は即時、分析用データは日次というように、業務影響に合わせて頻度を分けます。

開発は、商品表示、検索、カート、チェックアウト、会員、注文連携といった業務のまとまりごとに優先順位を付けます。最初から全機能を完成させるのではなく、1ブランド・主要商品・代表的な決済・配送でMVPを作り、受け入れ基準を満たしたらキャンペーンや多言語、他ブランドへ拡張します。独自要件を追加する際は、標準設定、既存拡張、カスタム実装の順で検討し、将来のアップデート時に修正が必要なコードを記録します。

テストは、単体・結合・システム・受け入れの順で行います。ECでは、商品検索から注文完了までの正常系だけでなく、在庫切れ、価格変更、クーポン併用、決済失敗、配送先変更、注文キャンセル、返品、二重送信、連携遅延を一連のシナリオで確認します。B2Bなら、取引先ごとの価格、購入上限、承認者不在、代理注文、再注文の権限も含めます。

性能テストでは、平常時の応答速度だけでなく、セールや広告流入のピーク、検索の大量実行、在庫更新と注文集中が重なる状況を再現します。目標値は、トップページだけでなく商品一覧、商品詳細、カート、決済、会員ログインごとに定めます。コンポーザブル方式では、フロントエンド、SCAPI、認証、CDN、外部検索・決済のどこが遅いかを分けて計測し、サイト全体の数字だけで判断しないことがポイントです。

セキュリティでは、Salesforce側の基盤対策と自社の責任を分けます。権限、管理者の多要素認証、ログ監視、個人情報の保持期間、脆弱性診断、サードパーティースクリプト、委託先アクセスを確認します。経済産業省のクレジットカード・セキュリティガイドライン5.0版では、原則として2025年3月末までのEC加盟店におけるEMV 3-Dセキュア導入が示されました。決済代行会社と、認証・不正利用検知・チャージバック対応の分担をテスト計画に含めてください。

稼働前には、商品・顧客・注文・ポイント・クーポン・画像などの移行対象を確定し、不要データの除外、文字コード、重複、欠損、IDの対応表を確認します。移行リハーサルを少なくとも一度行い、件数照合だけでなく、代表的な商品と会員で検索、ログイン、注文、返品まで通します。旧サイトの停止時間、最終差分の取り込み、DNSやタグの切り替え、問い合わせ窓口も日付と担当者つきで決めます。

切り替え判断には、受け入れテストの未解決件数、重大障害の有無、決済成功、在庫連携、注文連携、バックアップ、監視、問い合わせ体制を使います。「問題があれば戻す」ではなく、どの指標が何分続いたら切り戻すか、切り戻し時に注文や会員情報をどう扱うかをランブックに書きます。段階公開が可能なら、社内利用者、限定顧客、1ブランドの順に対象を広げ、観測してから全体公開します。

公開当日は、開発会社だけでなく、EC運用、CS、物流、決済、マーケティング、経営判断者を含む体制を置きます。注文が通ることだけでなく、商品登録、在庫更新、キャンペーン設定、売上集計、返品受付が業務担当者だけで実行できるかを確認します。稼働直後の数日間は、通常の保守窓口とは別に、障害の優先度と連絡経路を一本化しておくと判断が速くなります。

稼働はゴールではなく、運用担当者が自分で改善できる状態を作るスタートです。運用設計では、商品登録、価格変更、在庫連携、キャンペーン、注文訂正、返品、権限申請、障害対応、リリースの手順と責任者を決めます。担当者向けの操作マニュアルを渡すだけでなく、実際の業務データを使った研修と、問い合わせを分類してFAQや手順を更新する仕組みが必要です。

定着度は、ログイン人数では測れません。商品登録にかかる時間、キャンペーンの公開リードタイム、注文エラー率、返品処理時間、問い合わせの自己解決率、リリース後の障害件数、CVRや検索経由の売上などを月次で確認します。SalesforceのAIやAgentforceガイド付きショッピングを追加する場合も、先に商品属性、在庫、価格、配送予定、顧客権限のデータ品質を点検し、AIの回答を監査できる状態を作ってください。

定着フェーズの契約では、問い合わせ対応だけでなく、月次の改善提案、リリースノートの確認、脆弱性・権限レビュー、性能監視、データ品質の点検、内製化支援を分けて見積もります。運用をすべて外部に依存すると、改善のたびに追加費用が発生しやすくなります。社内で持つ業務と、専門会社に任せる技術領域を半年ごとに見直すことが、長期の総保有コストを抑えます。

Salesforce Commerce Cloudのシステム開発費用相場と内訳

Salesforce Commerce Cloudの費用は、ライセンス、導入支援・開発、外部システム連携、データ移行、運用保守、追加サービスに分けて考えます。公式のB2C Commerce価格ページはGrowth、Plus、Commerce Cloud B2C Premiumをいずれも「Contact for pricing」としており、サイト数や価格表数などの上限は示されますが、日本円の一律価格は公開されていません。したがって、月額いくらと断定する記事や見積には注意が必要です。

開発費の目安は、標準設定中心の小規模PoCや1ブランドの最小構成で300万〜800万円程度、SFRAで1〜2ブランドを本番導入する場合で1,500万〜4,000万円程度、複数ブランド・多言語・OMSやCRM連携を含む場合で4,000万〜1.5億円程度、グローバルな基幹刷新や段階移行まで含む場合で1億〜3億円以上です。これはSalesforce公式の価格表ではなく、リサーチノートにある一般的な業務システム相場と、導入範囲・人月構造から作った記事用の概算レンジです。実際の金額は個別見積もりで確定します。

期間の目安も、PoCなら1〜3か月、1〜2ブランドの本番導入なら4〜8か月、複数国やOMS・ERP・PIMを含むなら8〜18か月、全社・グローバル刷新なら12〜24か月以上です。商品点数、会員数、API数だけでなく、現行データの品質、社内の意思決定速度、コンテンツ準備、移行リハーサルの回数が期間を左右します。短納期を優先する場合は、機能を削るのか、対象ブランドを絞るのか、標準に寄せるのかを明記してください。

ライセンスでは、エディション、サイト数、価格表数、取引量、注文管理、Data Cloud、CRM Analytics、AI機能、サンドボックス、Success Planを確認します。公式価格ページではGrowthが5サイト・10価格表、PlusとPremiumが100サイト・3,500価格表で、Premiumにはフル注文管理やData Cloud関連機能が含まれる構成が示されています。Premier Success Planは純ライセンス料の30%と掲載されているため、採用する場合はライセンスと別行に置きます（出典: Salesforce B2C Commerce Pricing、2026年8月確認）。

実装費には、企画・要件定義、UX設計、アーキテクチャ設計、画面開発、カート・決済、連携、移行、テスト、リリース、研修が含まれます。運用費には、監視、障害対応、軽微改修、定期リリース、脆弱性対応、データ品質管理を含めるかを確認します。さらに、決済代行、検索、レビュー、翻訳、CDN、PIM、OMS、WMS、MuleSoftなどの利用料や保守費が別になる場合があります。見積書の合計額だけでなく、5年間の総保有コストで比較してください。

成果事例の数字は魅力的ですが、自社の予算や効果をそのまま推定する根拠にはしません。Salesforce Japanの資生堂事例では、コンポーザブルストアフロントによりサイト表示が4倍に高速化し、コンバージョン率が13％向上したと報告されています。また、100以上あったAPIを一桁台に集約した取り組みも紹介されています（出典: 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のシステム開発でよくある質問

ここでは、導入前に特に質問されやすい点を、判断基準とともに回答します。自社の状況に当てはめるときは、売上規模だけでなく、ブランド数、国・言語、連携数、業務の複雑さ、社内の運用体制を合わせて確認してください。

向いているかどうかは、企業規模だけで決まりません。複数ブランド・海外展開・CRM連携・高い運用統制など、将来の拡張性に投資する目的があり、ライセンス・開発・運用を含む総保有コストを負担できるなら候補になります。1ブランドで商品数が少なく、標準的な販売だけを低コストで始めたい場合は、他のECサービスも含めて比較し、Commerce Cloudを選ぶ理由を数値で説明できる状態にしてください。

短期立ち上げと標準的なEC運用を優先するならSFRA、フロントエンドの自由度や複数チャネルへの展開を重視するならコンポーザブルが基本的な判断軸です。ただし、コンポーザブルはフロント、認証、キャッシュ、SEO、監視、CI/CDの設計と保守が増えます。全画面を一度に移行する必要はなく、既存SFRAにSCAPIを組み合わせるハイブリッドで、効果を検証しながら段階移行する方法もあります。

一律の日本円価格を公開情報だけで算出することはできません。Salesforceの公式B2C Commerce価格ページは各エディションを個別見積もりとしており、サイト数、価格表数、注文管理、Data Cloud、Success Planなどの構成を確認して営業担当へ相談する形式です。公開情報からできるのは、必要なエディションや追加サービスを洗い出し、ライセンスと実装・連携・運用の費用を分けた予算枠を作ることです。

すべてを任せることはできません。クラウド事業者は基盤やサービス側の対策を担いますが、顧客側には権限設定、個人情報の扱い、管理者アカウント、多要素認証、外部連携、決済運用、ログ監視、脆弱性対応、委託先管理などが残ります。責任分界表を要件定義で作り、設計・テスト・運用の各工程で確認することが必要です。

Salesforce Commerce Cloudのシステム開発のまとめ

Salesforce Commerce Cloudのシステム開発は、要件整理、方式・パートナー選定、設計・開発、テスト、稼働、定着の順で、各工程の完了条件を確認しながら進めます。成功のポイントは、B2C・B2Bの業務差分、商品・価格・在庫の正本、OMS・ERP・PIM・WMSとの連携、SFRA・コンポーザブル・ハイブリッドの選択、移行と切り戻し、クラウドと自社の責任分界を最初に決めることです。

着手時は、現行業務フローと課題一覧、データ・連携の責任分界表、KPIと受け入れ基準の3つを作成します。次に、1ブランド・主要商品・代表的な決済と配送でMVPの範囲を決め、SFRA、コンポーザブル、ハイブリッドの提案を同じ条件で比較します。見積書はライセンス、開発、連携、移行、運用、Success Plan、外部サービスに分け、期間と除外事項まで確認してください。

公開後は、CVRや売上だけでなく、商品登録時間、注文エラー、返品処理、問い合わせ、リリース速度、データ品質を確認し、月次の改善計画へつなげます。AIや新しいチャネルを追加する場合も、先に正しい商品・価格・在庫・顧客データと権限を整えます。短期の導入費だけで判断せず、社内に運用知識を残しながら、5年間の総保有コストと事業成果を見直せる体制を作ることが、Commerce Cloudを活かす近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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