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

Salesforce Commerce Cloudのシステムは、商品・価格・在庫・注文・顧客データをクラウド上でつなぎ、B2CやB2BのECを継続的に成長させるためのコマース基盤です。

「Commerce CloudだけでEC業務が完結するのか」「B2CとB2Bのどちらが自社に合うのか」「ライセンスと開発費を合わせるといくらかかるのか」と迷う方は多いです。この記事では、全体像、機能の種類、開発方式、周辺システム連携、進め方、2026年時点の費用目安、開発会社・サービスの選び方、セキュリティ、よくある質問まで、導入判断に必要な情報をまとめて解説します。

Salesforce Commerce Cloudのシステムとは何ですか？

Salesforce Commerce Cloudは、ECサイトの画面だけを提供するサービスではなく、商品の発見から購入、注文処理、顧客対応、データ分析までを支えるクラウド型のコマース基盤です。現在の公式サイトでは「Agentforceコマース（旧Commerce Cloud）」という表記も使われていますが、実務ではSFCC、B2C Commerce、Commerce Cloudという呼び方も残っています。

CRMとECを同じ顧客体験につなげられる基盤です

一般的なECサイトでは、会員情報、購入履歴、問い合わせ履歴、キャンペーン反応が別々に管理されることがあります。Commerce Cloudは、SalesforceのCRM、マーケティング、サービス、データ基盤と連携しやすいため、購入前の接客から購入後の問い合わせまでを一貫した顧客情報で扱いやすい点が特徴です。たとえば、過去の購入商品に応じた案内、会員ランク別の価格、注文状況の確認、再注文の導線を同じ顧客体験に組み込みやすくなります。

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

商品発見から注文・分析までを一つの流れで考えます

主な対象業務は、商品カタログ、価格表、サイトやブランドの管理、検索、カテゴリ、レコメンド、カート、チェックアウト、決済、クーポン、プロモーション、会員、注文履歴、在庫、注文管理、売上分析です。オンラインだけでなく店舗やコールセンターを含めたユニファイドコマースを目指す場合は、POSや注文管理との接続も検討します。

公式ページでは、Commerce基盤の歴史的な稼働時間として99.99%、20億人以上の買い物客の取引を支えているという数値が示されています（出典：Salesforce公式Agentforceコマースページ、2026年8月参照）。これはプラットフォームの実績を判断する材料ですが、自社の画面、連携API、決済代行、運用手順まで含めた可用性を保証する数字ではありません。導入時は自社のサービスレベル目標と障害時の責任分界を別に定めます。

B2CとB2Bはどちらを選ぶ？システムの種類と違い

Commerce Cloudの種類を考えるときは、業種よりも取引の相手と購買プロセスに注目します。一般消費者が短時間で購入するならB2C、法人の購買担当者が契約条件や承認を経て購入するならB2Bが中心です。両方を扱う場合は、データと運用を共通化する領域、画面や価格ルールを分ける領域を先に整理します。

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

B2Cでは、広告や検索から商品詳細ページへ訪れた人が、迷わずカートに入り、少ない操作で決済できることが重要です。商品バリエーション、在庫表示、クーポン、ギフト、会員登録、ゲスト購入、レビュー、レコメンド、検索精度などが購入率に影響します。季節商戦やキャンペーンでアクセスが急増する場合は、キャッシュ、CDN、在庫引当、決済のタイムアウト、注文の重複登録を含めて性能を検証します。

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

B2Bは取引先別の条件と承認を扱います

B2Bでは、誰でも同じ価格で買うのではなく、取引先、契約、数量、地域、販売チャネルによって価格や在庫、配送条件が変わります。購買担当者、承認者、管理者などの権限を分け、見積や契約に基づく価格表、最低発注数量、定期注文、請求条件、再注文を設計します。注文単位が大きい場合は、営業担当者が関与するプロセスと、購入者がセルフサービスで完了するプロセスを分けると運用しやすくなります。

B2C向けの画面をそのままB2Bに流用すると、承認や請求、取引先階層に対応できず、後から大幅な改修が発生することがあります。反対に、B2Bの複雑なルールを一般消費者向け画面へ持ち込むと、購入導線が長くなります。最初に顧客区分、価格の正本、受注後の業務フローを図にし、共通化と分離の境界を決めます。

主要機能と周辺システム連携をどう設計しますか？

Commerce Cloudの導入では、画面の見た目より先にデータの流れを決めることが重要です。商品、価格、在庫、会員、注文、決済、配送、返品の各データについて、登録元、更新頻度、エラー時の扱い、再送方法、履歴の保管先を定義します。連携仕様が曖昧なまま画面開発を始めると、テスト直前に業務ルールが変わり、納期と費用が膨らみやすくなります。

商品・価格・在庫の正本を決めます

商品名や説明、画像、規格、カテゴリを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や検索サービスを組み合わせられます。公式開発資料でも、独自のブランド体験や複数の技術を組み合わせる構成が説明されています（出典：Salesforce Developers「Headless Commerce with Salesforce Commerce API」、2026年8月参照）。公開されている導入事例の一つでは、コンポーザブルストアフロントへの移行後にサイト表示速度が4倍になり、コンバージョン率が13%向上したと報告されています。ただし、これは特定の企業・要件における結果であり、自社で同じ成果が保証されるわけではありません。

自由度が高い反面、画面、認証、キャッシュ、SEO、構造化データ、監視、デプロイ、脆弱性対応を自社または開発パートナーが設計する範囲が広くなります。特にSSRとクライアント側表示の使い分け、URLの正規化、在庫や価格を取得できないときの表示、APIのレート制御は、開発初期に検証します。

ハイブリッドはリスクを分けて段階移行できます

既存のSFRAサイトを残しながら、検索、会員ページ、キャンペーン、アプリ連携など効果の大きい領域だけをSCAPIで置き換える方法がハイブリッドです。全画面を一度に刷新しないため、移行中の売上影響を抑えやすく、社内のフロント開発力も段階的に高められます。

ただし、方式が混在すると、認証、デザインシステム、分析イベント、注文状態の表示が二重化しやすいです。移行単位ごとに、どの画面をどの方式が担当するか、共通APIをどこに置くか、切り戻しをどう行うかを文書化します。最初に小さなMVPを作り、表示速度、購入率、運用工数、障害対応時間を測ってから次の範囲を決めると安全です。

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

開発は、画面を作る工程だけではありません。現行業務、データ、連携、運用、セキュリティ、移行、教育を一つの計画として進めます。特にECは公開後の改善が前提になるため、初回リリースで全機能を詰め込むより、売上と業務への影響が大きい範囲をMVPとして定義します。

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

企画・要件定義では業務とKPIをそろえます

最初に、売上、購入率、平均注文額、リピート率、問い合わせ削減、受注処理時間などのKPIを定めます。次に、B2CかB2Bか、ブランド数、国・言語・通貨、税、会員区分、価格ルール、在庫拠点、決済、配送、返品、キャンセルを洗い出します。要件を「必須」「初回リリース後」「採用しない」に分けると、見積もりの前提が明確になります。

要件定義の成果物には、業務フロー、画面一覧、権限一覧、データ項目表、外部連携一覧、非機能要件、移行対象、テスト方針を含めます。非機能要件では、ピーク時の同時アクセス、ページ表示速度、障害復旧目標、ログ保存期間、個人情報の扱い、監査要件を数字で置きます。

設計・開発では標準と追加開発を分けます

設計では、画面とデータモデル、API、認証、権限、エラー処理、外部サービスの接続方法を決めます。Commerce Cloudの標準設定で対応できる機能は標準に寄せ、競争力に直結する検索体験、会員特典、商品提案、独自の受注フローなどは追加開発の候補にします。標準機能を変更する場合は、将来のアップデートへの影響を必ず記録します。

データ移行は、件数だけでなく品質が難所です。商品コードの重複、価格の有効期間、画像の命名、会員メールアドレス、注文履歴、退会者データを整理し、テスト環境で複数回リハーサルします。公開直前に一度だけ移行するのではなく、差分移行、照合、切り戻しの手順まで確認します。

テスト・リリースでは実業務とピークを再現します

テストは、単体、結合、総合、受入、性能、セキュリティ、移行、運用訓練に分けます。商品検索から購入、決済、在庫引当、出荷、メール送信、返品、返金までの一連の業務を、実際の担当者が操作します。クーポン併用、会員ランク変更、在庫切れ、分割配送、決済失敗、外部API停止といった例外もシナリオ化します。

リリース当日は、注文受付を止める時間、問い合わせ窓口、監視ダッシュボード、障害時の連絡網、ロールバック条件を明確にします。公開後の最初の数週間は、購入率だけでなく、検索ゼロ件率、決済失敗率、在庫差異、返品処理時間、問い合わせ件数を確認し、改善の優先順位を決めます。

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

Salesforceの公式B2C Commerce価格ページでは、Growth、Plus、Commerce Cloud B2C Premiumのいずれも個別見積もりです。Growthは5サイト・10価格表、Plusは100サイト・3,500価格表、Premiumは100サイト・3,500価格表に加えて注文管理やData Cloud連携などが示されています（出典：Salesforce公式B2C Commerce価格ページ、2026年8月参照）。したがって、公開された一律の円価格だけで総額を判断することはできません。

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

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

以下は、公式ライセンス価格ではなく、一般的なエンタープライズECの工程、人月、連携範囲をもとにした2026年時点の記事用概算です。小規模な検証や1ブランドの最小構成では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か月以上です。商品の点数、会員数、過去注文の移行量、国や通貨の数、既存APIの品質、社内承認の速さによって前後します。短期間を希望する場合は、初回リリースの対象を絞り、後続フェーズを最初からロードマップに置きます。

運用費は、ライセンス・取引量連動費、追加サービス、保守、監視、改善開発、コンテンツ運用、人材育成に分けます。一般的な仮置きとして、保守運用を初期開発費の年15〜25%程度、または月15万〜80万円程度で見積もるケースがありますが、規模、対応時間、障害対応、改善作業の有無で変わります。契約前に、月次の保守時間、緊急対応、追加開発の単価、未使用時間の扱いを確認します。

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

開発会社や導入サービスを選ぶときは、知名度や資格の数だけでなく、自社の業務と方式に合うかを見ます。Commerce Cloudの実績があっても、B2C中心のチームとB2B中心のチームでは得意領域が異なります。会社名の比較から始めるのではなく、RFPに要件と評価基準を記載し、同じ前提で提案を受けると判断しやすくなります。

同規模・同業務の実績と担当範囲を確認します

確認したいのは、単に「導入実績があるか」ではありません。自社と近い売上規模、商品点数、ブランド数、国、会員数、B2C・B2Bの取引形態で、どの工程を担当したかを聞きます。SFRA、Composable Storefront、SCAPI、Commerce Apps、OMS、ERP、PIM、決済、配送、返品の実績を分けて示してもらうと、提案内容と実装力を比較できます。

提案時には、実際に参加する責任者、アーキテクト、データ移行担当、テスト責任者、運用担当を確認します。営業段階の説明者と、開発を担うチームが異なる場合は、引き継ぎ方法と体制変更のルールを契約に入れます。再委託の範囲、海外拠点からのアクセス、個人情報の取扱い、ソースコードや設定の引き渡しも確認対象です。

見積の前提・保守・内製化支援を比較します

見積書は、要件定義、設計、開発、連携、データ移行、テスト、教育、リリース、保守の工程別に分けてもらいます。画面数だけの見積もりでは、API、バッチ、エラー処理、移行リハーサル、性能試験が抜けることがあります。前提となる商品件数、会員件数、注文履歴、外部システム数、環境数、テストデータ、会議回数も明記してもらいます。

導入後に自社で改善したい場合は、設定やコードの引き渡しだけでなく、運用手順、リリース手順、障害対応、分析方法、開発者向けの説明を含めます。月額保守に何が含まれるか、改善開発を依頼する場合の料金、製品アップデートへの対応、担当者変更時の引き継ぎを確認すると、稼働後の費用と依存度を抑えやすくなります。

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

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

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

クラウド基盤のセキュリティ機能を利用できても、EC事業者側の責任がなくなるわけではありません。Salesforceの基盤、導入設定、カスタムコード、外部連携、決済、アカウント、運用手順を責任分界で分けます。個人情報へのアクセス権、二要素認証、管理者権限、APIクライアント、秘密情報、ログ、脆弱性対応、委託先監督を定期的に確認します。

決済と個人情報は自社の対策まで確認します

カード決済は、カード番号を自社環境に保持するか、決済サービスへ委託するかで、設計と審査の範囲が変わります。PCI DSSへの対応、脆弱性診断、EMV 3-Dセキュア、不正注文検知、アカウント乗っ取り対策、パスワードリセットの監視を、プラットフォームの機能と自社運用に分けて確認します。

経済産業省のクレジットカード・セキュリティガイドラインでは、2025年3月末までに原則としてすべてのEC加盟店でEMV 3-Dセキュア導入を進める方針が示されました（出典：経済産業省「クレジットカード・セキュリティガイドライン」、2024年資料）。2026年に新規導入する場合も、決済事業者、カード会社、サイト、カスタマーサポートの役割と、認証失敗時の購入導線を事前にテストします。

AIはデータ品質と権限を整えてから使います

2025年11月、国内向けにコマース領域のAgentforceとして、会話を通じて商品発見から購入完了までを支援する機能の提供開始が発表されました（出典：Salesforce公式プレスリリース、2025年11月）。2026年時点では、ガイド付きショッピングやAI検索などが注目されていますが、AIを追加すれば直ちに売上が伸びるわけではありません。

AIが参照する商品、在庫、価格、配送予定、返品条件が誤っていれば、誤案内やクレームにつながります。まず商品マスタの必須項目、価格の有効期限、在庫の更新頻度、回答できない場合の有人引き継ぎ、プロンプトやログへのアクセス権を整備します。小さな商品カテゴリで試し、回答正確率、有人転送率、購入率、問い合わせ削減率を測定してから対象を広げます。

よくある質問

導入前に多い疑問を、判断に必要なポイントに絞って回答します。自社の契約条件や既存システムによって結論が変わる部分は、要件と見積の前提を確認してください。

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

ライセンスは公式ページで個別見積もりとなっており、開発費を含めた総額は要件によって変わります。記事用の概算では、最小構成の検証で300万〜800万円、1〜2ブランドの本番導入で1,500万〜4,000万円、複数ブランドや基幹連携を含む場合で4,000万〜1億5,000万円を目安にします。ライセンス、導入支援、追加サービス、保守を分けて見積もることが重要です。

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

導入は可能ですが、必要な機能と運用体制を絞ることが大切です。1ブランド、標準寄りの画面、限定的な商品・会員・注文連携から始め、購入率や受注処理時間を確認して段階的に拡張します。複雑な基幹連携や多言語展開を初回から含めると、企業規模にかかわらず費用と期間が大きくなります。

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

すべての企業で完成するわけではありません。商品、価格、在庫、注文、顧客情報をどこで管理するかによって、ERP、PIM、OMS、WMS、決済、配送、返品、CRM、データ分析などとの連携が必要になります。Commerce Cloudを中心に、業務全体の役割分担と責任分界を設計することが成功のポイントです。

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

必ずしも初回から追加する必要はありません。商品情報、価格、在庫、配送、返品条件を正しく整え、権限と有人対応を設計したうえで、検索、商品提案、再注文、注文状況確認など効果を測りやすい用途から始めます。AIを導入する場合は、回答正確率や購入率だけでなく、誤回答、有人転送、データ更新遅延も継続的に監視します。

まとめ

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

Salesforce Commerce Cloudのシステムは、ECサイトの構築機能だけでなく、顧客、商品、注文、在庫、マーケティング、サービスをつなぐコマース基盤です。B2Cは購入体験と大量アクセス、B2Bは取引先別価格や承認、複雑な注文条件を重視します。方式は、標準活用を優先するSFRA、自由度の高いComposable、既存資産を活かすハイブリッドから、目的と体制に合わせて選びます。

次に確認する項目

導入を成功させるには、ライセンス価格だけでなく、連携、データ移行、テスト、セキュリティ、保守、AI活用までを含む総保有コストで比較することが大切です。最初に業務とデータの正本を整理し、標準に寄せる領域と差別化する領域を分け、MVPから測定と改善を繰り返すことで、無理のないコマースシステムを作りやすくなります。