Salesforce Commerce Cloudのシステム開発の発注/外注/依頼/委託方法について

Salesforce Commerce Cloudの発注は、まず対象業務と連携範囲を決めることから始まります。RFP作成、契約、委託先選定の順に進めると、実運用に耐えるEC基盤につながります。

発注形態、要件整理、契約、費用、委託先の選び方は、2026年時点の情報をもとに、この順で解説します。

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

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

Salesforce Commerce Cloudの発注前に押さえる全体像

Salesforce Commerce Cloudは、クラウド型のEC基盤です。商品・価格・在庫、カート・決済、注文のほか、顧客情報やプロモーションなども扱います。

ECサイトを契約しただけでは、業務全体は完成しません。ERPやOMSとの役割分担を設計して、初めて実運用に耐えます。ほかに、次の連携先との役割分担も決めておきます。

• PIM
• WMS
• 決済代行
• 配送
• CRM

発注対象（B2CかB2B）の決定

B2CとB2Bでは、求められる購入体験が違います。そのため発注前に、誰がどのチャネルで、どの条件の商品を買うのかを整理しておきます。

• B2C：複数ブランドと大量アクセス、検索・レコメンド、キャンペーン、会員・注文履歴の扱いが中心です。
• B2B：取引先別の価格、購買権限と承認、見積・契約、再注文の扱いが要点です。

B2C向けの設計に、B2B固有の業務を後から加えると、費用と期間が膨らみがちです。

標準機能と追加開発の境界

標準機能が多くても、短期間で安く完成するとは限りません。そこで、一般業務と競争力に関わる機能を分けておきます。

• 標準機能を活用：商品登録、価格設定、カート、注文など。
• 追加開発を検討：独自会員ランクや複雑な在庫引当、特殊返品・基幹連携、独自の購入体験には、設計・開発・テストが必要です。

競争力に直結する部分は拡張し、一般的なEC業務は標準機能に寄せる方針を、RFPに記しておきます。さらに、この方針は将来のアップデートや保守にも対応しやすくします。

Salesforce Commerce Cloudの発注形態の選び方

発注形態は、社内に業務責任者と技術責任者がいるか、既存システムを把握しているか、公開後にどこまで内製するかで選びます。主な方法は、一社への一括委託、設計・開発の分離、自社主導の専門会社活用です。

発注先の会社名を選ぶ前に、要件定義からリリース後の改善まで誰が責任を負うかを決めておきます。

一次請けに企画から保守まで一括委託する方法

導入経験が少ない企業では、工程を同じ一次請けにまとめると、責任を一本化しやすくなります。

• 委託範囲：コンサルティングから要件定義、設計・開発・テスト、移行、リリース、保守まで。
• 向く委託先：ERPやPIM、決済、配送まで横断する案件には、業務と連携をまとめて管理できるSIerやコンサルティング会社が向きます。

画面制作だけを手がける会社は、こうした案件に適さない場合があります。

一括委託は見積の比較対象が見えにくくなりやすいため、ライセンス・導入支援・開発・外部サービス・保守を分けて見積もります。

要件定義、開発、運用を分けて発注する方法

社内にプロジェクトマネージャーや業務知識があれば、工程ごとに発注先を分ける方法があります。

• 要件定義と実装：自社かコンサル会社が要件定義を担い、実装は専門パートナーへ委託します。
• 個別工程：フロントエンドを別会社に、データ移行を基幹ベンダーに任せる形もあります。

発注先を分けるほど、インターフェースごとの責任分界が欠かせません。どこまでを誰が受け持つかを決めていないと、たとえば、PIM会社が商品マスタの項目を定義し、EC会社がそれとは別の名称で実装した場合に、連携テストで手戻りが起きます。

分離発注では、共通の要件一覧、API仕様、課題管理表を用意しておきます。そのうえで、最終承認者を一人に決めます。

短期導入と内製化を両立する段階委託

長期的に社内で運用する企業は、最初から全てを外部へ任せきりにせず、初期構築と運用移管を分けて計画します。

• 初期構築：認定資格やSFRA、SCAPI、Composable Storefrontの経験を持つ会社への委託。
• 運用移管：初期フェーズと並行して、管理画面、商品・価格・プロモーション、リリース手順、障害一次対応を自社担当者へ引き継ぎます。
• 納品条件：コード、設定、テスト仕様書、API一覧、運用マニュアルを契約に含め、ベンダー変更や内製化に備えます。

RFPと要件整理で伝える内容

RFPには、機能だけでなく事業目的や課題、対象ユーザーを書きます。さらに、データの正本・連携方式・非機能要件・運用体制も、まとめておきます。

必須要件と希望要件を分け、代替案を求める部分も明示すると、発注先は同じ条件で提案できます。

機能名だけのRFPでは、会社ごとに解釈が分かれます。その結果、見積の差が仕様の抜けによるのか、体制の違いによるのかを判断しにくくなります。

要件の起点となる事業目標と業務フロー

「新しいECを作る」と書くより、解決したい業務課題を先に書き、現状と将来像の業務フローを比べます。

• 事業課題：初回購入率の改善、複数ブランドの共通運用、取引先の再注文のオンライン化など。
• 業務フロー：商品登録から問い合わせまでの流れで、注文確定・在庫引当・出荷・返品・返金を含みます。

商品・顧客・注文・在庫・価格の正本を持つシステムも決めておきます。このため、後工程の連携設計が安定します。

ERP・PIM・OMS・決済などとの連携要件の具体化

連携要件は、システム名だけでなく項目と方向まで書きます。頻度や再送・重複防止、監視方法も含めます。

• 商品情報：PIMからCommerce Cloudへの連携頻度（日次か）。
• 価格・在庫：ERPやWMSからの反映間隔（数分単位か）。
• 注文：Commerce CloudからOMSへの即時連携の有無。

連携の方式によって、API設計と必要なテストが変わります。MuleSoftなどを使う場合は、基盤のライセンス・開発・運用費を本体と分けて見積もります。

非機能要件、移行、運用責任の記載漏れ防止

RFPでは、非機能要件、運用責任、データ移行の条件を具体的に書いておきます。

• 非機能要件：ピーク時アクセスや表示速度、可用性、バックアップ・ログ保存・監視・障害連絡、権限・監査、脆弱性対応、SEO URL・構造化データ。
• 運用責任：マネージド基盤でも、商品データの品質、外部APIの障害、アカウント管理、個人情報の扱いは自動では解決されません。
• 移行条件：商品・会員・注文・ポイント・クーポンの対象、回数、クレンジング、件数確認、切り戻し条件を明記します。

移行条件をRFPに入れると、本番直前の追加請求を抑えやすくなります。

契約形態と開発プロセスの設計

要件がまだ不確かな工程と、成果物を確定しやすい工程を分けて契約します。全工程を固定価格にすると、要件変更を巡って対立しやすくなります。

一方、すべて準委任にすると、成果物・品質・納期が曖昧になりがちです。そのため発注側は、工程ごとに責任と評価方法を契約書や個別契約で定めます。

請負と準委任の使い分け

要件の確定度と求める責任に応じて、請負と準委任を選びます。

• 請負契約：成果物を納期までに完成させます。要件・画面・機能・テスト基準が固まった開発に向きます。
• 準委任契約：専門家の作業や支援を受けます。現状分析、要件整理、アジャイル改善、運用支援に適しています。

企画・要件定義を準委任、設計・開発を請負または段階請負、公開後の改善を準委任とする組み合わせも検討できます。

契約で定める受入基準、変更管理、再委託

契約前に、成果物や受入条件、変更手続き、再委託と引き継ぎの扱いを確認します。

• 受入：成果物一覧と受入基準、検収期限、瑕疵や不具合の扱いを定めます。
• 変更：仕様変更の承認者と追加費用の算定方法を決めます。標準設定やカートリッジ、フロントエンド、API、外部サービスの納品範囲も明確にします。
• 再委託：委託先、個人情報へのアクセス、データ保管場所、秘密保持を確認します。
• 契約終了時：ソースコードや設定情報の引き渡しと、移管支援を契約に含めます。

要件定義からリリースまでの判断ゲート

工程ごとに次へ進む条件を決めておき、要件が固まらないまま開発に入らないようにします。

1. 現状分析とKPIの定義。
2. Fit to Standardによる要件の整理。
3. アーキテクチャと連携の設計。
4. MVP（Minimum Viable Product）の開発。
5. データ移行のリハーサル。
6. 性能・決済・セキュリティのテスト。
7. ユーザー受入、段階リリース、運用改善。

商品・価格・在庫の正本が決まっていない場合は、画面開発より先にデータ責任者を決めておくと、遅延の防止につながります。

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

ライセンス料金は、売上規模やサイト数、価格表・取引量・機能、契約条件によって変わります。

Salesforce公式のB2C Commerce価格や、Growth、Plus、Commerce Cloud B2C Premiumの価格は、いずれも個別見積もりです。月額は公開情報では断定できません。

ライセンスと開発費を分け、Success PlanやOMS、Data Cloud、AI機能のほか、検索・レビュー・決済も別建てで確認します。

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

下の金額は公式のライセンス価格ではなく、リサーチノートの一般的な業務システム開発相場と、導入時の人月構造から算出した記事用の概算です。

• PoCまたは1ブランドの最小構成：300万〜800万円程度。
• SFRAで1〜2ブランドを本番導入：1,500万〜4,000万円程度。
• 複数ブランド、多言語、OMS・CRM連携を含む：4,000万〜1.5億円程度。
• 全社・グローバル刷新：1億〜3億円以上。

実額は、対象範囲と提案体制を確認した見積もりで決まります。

期間は、最小構成で1〜3か月、1〜2ブランドで4〜8か月、複数ブランド・多言語連携で8〜18か月が目安です。全社・グローバル刷新は、12〜24か月以上が目安です。

データ品質が悪い場合、基幹連携の仕様が不明な場合、国やブランドで業務が異なる場合は、要件整理や移行準備が開発より長くなることがあります。

費用と期間は、どこまでを含んだ幅なのかを確認してから比べます。

ライセンス以外に発生する費用の内訳

総額を項目ごとに分けて出してもらい、追加サービスや保守の条件を確認します。

• 基盤と設計：Commerce Cloudライセンス、初期設計・開発。
• 連携・移行：ERP・PIM・OMS・WMS・決済との連携、商品・会員・注文データの移行。
• 公開準備：コンテンツ制作、SEO、テスト・教育・リリース。
• 運用・追加サービス：保守運用、Success Plan、AI、Data Cloudなど。

Salesforce公式価格ページでは、Premier Success Planは純ライセンス料の30%です。サポートを付ける場合は、ライセンス見積と合わせて確認します。

リサーチノートの一般的な人件費目安は、PMが月90万〜150万円、設計SEが月65万〜110万円です。

実装は月50万〜90万円、テスターは月45万〜80万円、大手SIerは月150万〜200万円程度です。これは特定会社の料金表でも、Commerce Cloud専用の公式価格でもありません。

保守は、初期開発費の年15〜25%程度、または月15万〜80万円程度を仮置きできます。金額は、対応時間や障害対応、改善開発、ライセンス費を含むかどうかで変わります。

委託先の選び方と見積比較のポイント

委託先は知名度だけでなく、Commerce Cloudの実装経験と案件への適合性で選びます。

Salesforce販売元やコンサル会社、SIer、Commerce専門会社、制作会社では、得意領域が異なります。

提案時には、同業・同規模のB2CまたはB2Bの事例を尋ねます。あわせて、SFRA、Composable Storefront、SCAPIの経験や、OMS・ERP・PIM・決済との連携の経験、公開後の保守体制を確認します。

委託先の技術力とプロジェクト体制

営業担当だけでなく、要件定義・設計・開発・テストを担うメンバーにも参加してもらいます。

• 設計力：標準機能と追加開発の判断、SCAPIの認証やレート制限を含むAPI設計。
• 実行力：障害時のログ調査、移行リハーサル、性能試験、公開後の改善。
• 体制：再委託する工程と、品質・情報管理の担当者。

Commerce Cloudの経験年数だけでなく、これらを具体的に説明できるかを見ます。

見積書の前提条件と工程内訳の比較

最安値をそのまま採用せず、工程別に工数と成果物を比べます。

• 工程：要件定義やUX、標準設定、カスタマイズ、フロントエンド。
• 移行・品質：外部連携、データ移行、テスト・教育・リリース。
• 運用：保守の範囲、工数、成果物。

「連携一式」「移行一式」「テスト一式」は、API本数、データ件数、リハーサル回数、性能試験条件に分解します。

安い見積には、要件定義・移行・運用設計が含まれない場合があります。一方で、高い見積には共通基盤やテスト、教育が含まれる場合もあります。

各社に同じ前提を渡し、含む範囲と含まない範囲、追加条件を一覧にして比べます。納期や体制、支払条件も、同じ一覧に並べます。

セキュリティと運用の見積への含め方

クラウド基盤の対策があっても、加盟店側の責任は残ります。

• 加盟店の対策：脆弱性対策、EMV 3-Dセキュア、不正ログイン対策が必要です。
• 責任分界：決済代行、Commerce Cloud、外部ID基盤、社内の個人情報管理について、設計・設定・運用・監査の担当を確認します。
• AI機能：商品・価格・在庫・配送予定のデータの正しさ、回答の監査可否、権限外情報の非表示。
• 段階導入：検索、再注文、注文状況確認など対象業務を限定し、データ品質と評価指標を確かめてから広げる方が安全です。

経済産業省は2025年3月、クレジットカード・セキュリティガイドラインの改訂内容を公表しました。

公式情報では2025年以降、Agentforceガイド付きショッピングなどが案内されています。AIを追加しても、成果は保証されません。

Salesforce Commerce Cloudの発注・外注でよくある質問

費用や期間は案件によって差が大きいため、発注先に確認すべき事項を中心に回答します。

Salesforce Commerce Cloudの導入費用は月額いくらですか？

一律の月額料金は公開されていません。売上規模やサイト数、価格表・取引量・機能、契約条件を伝え、Salesforceか販売パートナーから個別見積もりを取ります。

導入開発や連携・移行、保守・Success Plan・外部サービスの費用は、別途発生します。

開発費の推定は、小規模PoCで300万〜800万円程度、本番導入で1,500万〜4,000万円程度を起点にできます。公式価格ではなく、案件範囲に基づく概算です。

どのような会社にSalesforce Commerce Cloudを委託すべきですか？

同業・同規模の事例があり、B2CまたはB2B業務を理解し、ERP・PIM・OMS・決済の連携を設計できる会社が候補です。

SFRA、Composable Storefront、SCAPIの選択理由を、流行ではなく要件と運用体制から説明できるか確認します。

担当者や再委託の有無、テスト・移行の責任、公開後の保守・内製化支援も確認します。

SFRAとComposable Storefrontはどちらを選べばよいですか？

既存資産の活用やフロントエンドの柔軟性といった、要件と運用体制を基準に選びます。

• SFRA：標準に寄せて短期導入し、既存のCommerce Cloud開発資産を活用する場合に向きます。
• Composable Storefront：他社CMSや検索サービスと組み合わせたい場合に候補です。

Composable StorefrontはReactベースのPWA KitとSCAPIを使い、柔軟なフロントエンドを構成できます。また、Salesforce開発者向けの公式情報でも、SFRAの代替となるヘッドレス構成と位置づけられています。

ただし、SEOや認証、キャッシュ、監視、CI/CDまで設計範囲が広がるため、追加のフロントエンド工数と運用費を確認します。

クラウドなのでセキュリティ対応をすべて任せられますか？

すべては任せられません。Salesforceの基盤と、自社・委託先の運用責任を分けて確認します。

• 責任範囲：Salesforce側と自社・委託先側の分担を決めます。
• 見積条件：RFPに責任分界表、監査ログの保存期間、インシデント連絡時間、脆弱性修正手順を含め、設計・設定・運用の費用も見積もります。

Salesforce側は基盤、認証、ログ、可用性を担います。自社・委託先側は、商品データ、権限、個人情報、脆弱性対応を分担します。

決済設定、不正ログイン対策、EMV 3-Dセキュア、委託先管理の担当も確認します。

まとめ

発注前には、まずB2CかB2Bかを決めておきます。あわせて、対象ブランドと国、チャネルも定めます。そのうえで、次のデータの正本を持つシステムを決めます。

• 商品
• 価格
• 在庫
• 注文

RFPには、SFRA、Composable Storefront、ハイブリッドの方針を書きます。ERP・PIM・OMS・決済との連携、移行、テスト、運用もまとめます。

ライセンスはSalesforceの個別見積もりです。設計・開発・連携・移行・保守、Success Plan、外部サービスは、分けて確認します。

開発費の概算は、小規模PoCで300万〜800万円程度、本番導入で1,500万〜4,000万円程度から考えられます。

数字だけでなく、工程・成果物・体制・前提条件を比べます。実績ある委託先と要件をすり合わせ、契約形態と、どこまでを誰が受け持つかを決めて発注します。

▼全体ガイドの記事
・Salesforce 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を創業。