ECプラットフォーム開発の発注/外注/依頼/委託方法について

ECプラットフォームの発注は、業務整理と方式決定から始まります。そのあと、RFPと契約の整備、委託先選定を経て、移行・運用へ進みます。この流れで進めると、販売と業務の改善につながります。

発注形態から委託先選定まで、決める内容は段階ごとに異なります。全体像はECプラットフォーム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・ECプラットフォーム開発の完全ガイド

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

ECプラットフォームの発注・外注で決める項目

外注を始めるときに最初に決めるのは、製品名ではなく事業目的と委託範囲です。画面制作だけを頼むのか、受注・在庫・物流・会計まで連携させるのかで、体制と予算が変わります。

2024年の国内BtoC-EC市場規模は26.1兆円、EC化率は9.8%です。また、ECを販売ページではなく業務基盤として設計する段階に入っています（出典: 経済産業省「令和6年度電子商取引に関する市場調査」、2025年）。

売上だけでなく業務改善まで含む目的

目的は、測定できるKPIと業態別の要件に分けて書き出し、そのうえで発注範囲を決めます。

• 業務KPI：受注処理時間を何時間減らすか、在庫差異をどれだけ抑えるかを測る指標。
• BtoC：販促、会員、レビュー、定期購入を要件に含める。
• BtoB：取引先別価格、掛け払い、承認、見積・再注文を整理する。
• 店舗連携：ECと店舗の会員ID、商品、在庫、ポイント、注文をそろえること。

業務面では、電話・FAX受注を何割減らすか、店舗受取を何件可能にするかも指標にします。

売上だけを目的にすると、デザインや広告機能に予算が偏り、二重入力や欠品対応が残る可能性があります。

プラットフォーム提供会社と開発会社の役割分担

発注先を選ぶ前に、基盤を提供する会社と、開発・運用を担う会社の役割を分けて考えます。

• 基盤提供会社：Shopifyやfutureshopなど、プラットフォームを提供する会社。
• 制作会社・SIer：要件定義、デザイン、連携開発、移行を担う会社。
• 委託先候補：認定パートナー、独自パッケージのSIer、スクラッチ会社。
• 責任者：要件定義から保守、障害の一次対応まで、工程ごとに定める担当。

SaaSを契約しても、商品データの整理、API連携、テーマ開発、テスト、運用設計を自社だけで終えられるとは限りません。

役割が曖昧だと、障害が基盤、追加開発、連携先のどこにあるのか分かりにくくなります。そこで、工程ごとの責任者を確かめておきます。

ECプラットフォームの発注形態の選び方

発注形態は、事業規模、業務の複雑さ、既存システムとの連携数、社内の開発・運用体制で選びます。

短期間で立ち上げるならSaaS、標準機能と独自要件の両方を満たすならクラウド型パッケージが候補です。

技術担当がいて独自拡張を重視するならオープンソースが候補になります。また、既製品では競争上の業務を表せないなら、スクラッチが候補です。

• SaaS：基盤運用を任せ、制作や連携は外注する形。
• パッケージ：標準機能を使い、必要な業務を拡張する形。
• オープンソース：技術担当を置き、独自に拡張する方式。
• スクラッチ：既製品で表せない独自業務を開発する方式。

SaaSを利用し制作・連携だけ外注する形態

SaaSを使う場合は、提供会社へ任せる基盤運用と、外部へ委託する作業を分けて考えます。

• 基盤運用：サーバー運用と基盤の更新を、提供会社に任せる範囲。
• 外部委託：デザイン、テーマ、商品登録、決済設定、アプリ連携を、外部に頼む作業。
• 向く用途：市場テストや新ブランドなど、早期販売を目指す場合。
• 追加対応：在庫引当や複雑な承認は、外部サービスや追加開発で補う。

Shopifyの公式料金は、年払い表示でBasic月3,650円、Grow月10,100円、Advanced月44,000円、Plus月368,000円からです（出典: Shopify日本「料金プラン」、確認時点の公開価格）。

ただし、この料金にはテーマ制作、アプリ、移行、外部決済、取引手数料、運用代行が含まれません。料金プランだけを見て、構築費がかからないと判断しないようにします。

パッケージ・オープンソースを導入して拡張する形態

パッケージやクラウドECは、標準機能を使い、基幹、POS、WMSなどと連携する方式です。CRMとの連携も対象になります。中堅企業やBtoB、定期通販の事業で候補になります。複数ブランドや店舗在庫連携の場合も候補です。

この方式では、標準機能と追加開発の境界がそのまま費用と保守の負担になります。その境界は、RFPで明らかにします。

• オープンソースの維持：サーバー、プラグイン、脆弱性対応の費用に加え、更新、監視、保守の費用もかかります。
• 個別カスタマイズ：増えるほど、更新や担当交代の負担が重くなります。
• 提案書の記載：標準機能や設定にあたる部分と、個別開発や業務変更にあたる部分を分けて書いてもらいます。

フルスクラッチは独自業務に投資する形態

フルスクラッチなら、商流や価格計算、受注審査、店舗運営、海外展開などを独自に組み込めます。ただし、自由度が高ければ成功するとは限りません。

要件定義、品質、セキュリティを管理する体制が必要です。さらに、障害対応や開発者の確保も欠かせません。差別化につながらない登録や決済まで独自開発すると、保守の負担が増えます。

既製品で対応できる領域と、利益率や顧客体験に直結する独自業務への投資は、分けて考えます。

RFPと要件整理の進め方

RFPは、提案依頼先に同じ条件で回答してもらう文書です。

業務、KPI、範囲、データ量を記載します。

連携や非機能要件、時期も書きます。

予算と回答形式も記載します。

前提がそろわない相見積もりでは、金額を比べにくくなります。

現状と達成目標をそろえて示します。

現行業務とデータの洗い出し

商品登録から会計までを、業務フローとして書き出します。

注文から返金までの各段階で、担当者、画面、入力データ、承認、連携先を確認します。

欠品や部分出荷、注文分割、予約は、デモで見落としやすい業務です。

定期購入のスキップや店舗受取、店舗とECをまたぐ返品も、見落としやすい業務です。

現行業務と移行データを一覧にし、抜けやすい例外処理も洗い出します。

• 業務フロー：商品登録から会計までの流れと、担当、画面、入力、承認、連携先。
• 例外業務：欠品、分割出荷、注文分割、予約、定期購入のスキップ、店舗受取・返品の扱い。
• 移行データ：商品、SKU、価格、在庫、顧客、会員ランク、ポイント、注文、配送先、画像、レビューの項目と件数。

重複や表記ゆれは、移行時に直すか、現行のまま移すかを決めます。また、AI検索やレコメンドを使う場合は、属性と履歴の品質、定義、権限を先に確かめておきます。

機能要件の優先順位と受入条件

機能要件は、優先順位と受入条件に分けて記載します。そうすると、各社の提案を同じ基準で見比べられます。

• 優先度：「必要」「できれば必要」「将来検討」に分け、商品、検索、会員、販促、決済、注文などを整理する。
• BtoB・定期通販：BtoBは取引先別価格、掛け払い、見積、承認、再注文を含める。定期通販は配送サイクル、停止、スキップ、解約を定める。
• オムニチャネル：会員統合、店舗在庫、BOPIS、店舗返品を要件とする。
• 在庫の受入条件：更新後5分以内の反映、在庫不足時の受付前エラーの定義。
• 決済の受入条件：与信失敗、二重決済、返金、部分返金、チャージバックのテスト。

配送、CMS、SEO、分析なども、優先度を決める対象です。

条件を具体的に示すと、提案会社の回答と見積もりを並べて比べられます。

非機能要件と責任分界

繁忙期に止まらないための条件と、委託先とのあいだでどこまでを誰が受け持つかを、RFPで明らかにします。

• 性能：月間注文数、ピーク時の同時アクセス、商品・会員数、画像容量、在庫更新件数を示す。
• 運用継続：性能試験の方法と合格基準、可用性、バックアップ、RTO・RPO、監視、ログ、権限、脆弱性診断、障害連絡、復旧訓練、切り戻しの定義。
• 契約・データ：所有権、API、追加単価、更新影響、返却形式、再委託、海外保管の確認。
• 決済ページ：自社サイトのスクリプトと外部タグ、それぞれの管理責任。

出典はPCI Security Standards Councilで、対象規格はPCI DSS v4.0.1です。

EC決済ページのスクリプト攻撃対策は、2025年3月31日から有効です。

発注からリリースまでの進め方

企画から始め、要件定義、設計、開発を経て進みます。その後、移行、テスト、リリースを行い、運用改善へ移ります。各段階で成果物と意思決定者を決めておくと、要件が膨らむのを防げます。

要件定義が無償の提案に含まれていると、開発後に有償の変更になる場合があります。そのため、契約範囲と成果物を分けて確認します。

企画とベンダー選定の評価表

候補会社を同じ条件で評価できるよう、関係者と確認方法をそろえます。

• 参加部門：経営、営業、商品、物流、店舗、情報システム、法務、CSの担当者。
• 提案比較：会社概要、実績、方式、範囲、体制、日程、費用、前提、リスクを同じ質問票で聞く。
• 評価項目：機能適合、業界・商流の経験、連携、移行、保守、セキュリティ、提案の具体性、担当者との相性。
• デモ：商品登録だけでなく、返品、欠品、部分出荷、割引併用、会員ランク変更、店舗受取、返金、障害復旧、権限、CSV、API再送まで試す。

現場の担当者に操作してもらい、業務が簡単になる点と、変更が必要な点を記録します。

設計・開発・テストの段階的な確認

設計から公開まで、納めるものと、変更や試験をどう管理するかを決めておきます。

• 設計・進捗：データモデル、連携、エラー、権限、ログの設計と、週次会議、課題一覧、デモ環境。
• 変更管理：影響、追加費用、納期、試験方法を、変更管理票に記録する。
• 試験：単体、結合、総合、受入、負荷、セキュリティ、移行の各試験。
• 公開準備：バックアップ、DNS・決済切替、窓口、監視、切り戻しのリハーサル。

決済失敗、在庫不足、二重送信、配送先変更は、試験の対象に含めます。返品、キャンセル、返金、外部API停止も、試験で確かめます。また、公開後の安定運用も納品条件に含めます。

移行と運用引き継ぎ

移行対象と稼働後の運用担当を決め、引き継ぎの条件も開発工程に含めます。

• 移行データ：パスワード、注文、商品コード、在庫、ポイント、定期購入、URL、画像、同意履歴の整理。
• 照合：移行するデータと移行しないデータを分け、件数とサンプルの照合方法を決める。
• 運用・保守：商品、価格、在庫、一次対応の担当、受付時間、初動時間、復旧目標、重大障害の連絡経路を決める。
• 内製化：ソース、設計書、API仕様、運用手順、教育を納品物に含める。

月次報告、定例会、軽微な改修の範囲も、SLAや保守仕様書に記載します。

ECプラットフォーム開発の契約形態の選び方

契約形態は、要件がどこまで固まっているか、成果物がどれだけ明確か、発注者の管理体制がどうかで選びます。

工程ごとに分ける方法もあり、たとえば要件定義は準委任、設計・開発は請負、保守・改善は準委任とします。一方で、一つの契約ですべてを固定すると、要件変更や連携先の仕様変更に対応しにくくなる場合があります。

請負契約の成果物と検収条件

請負では、成果物の完成条件と検収条件を契約前に具体化します。

• 納品物：画面、機能、連携、移行、試験、設計書、ソース、マニュアルの一覧。
• 検収条件：期限、修正回数、瑕疵対応、再検収を定める。「一式」の記載は、範囲と完成条件で補う。
• 適する工程：要件と受入条件が比較的固まった開発に向く。
• 未確定仕様：外部決済や基幹側の仕様が未確定なまま全工程を請負で固定すると、変更費用の交渉が増えます。

要件定義だけを先に検収し、その結果をもとに開発の契約を結ぶ方法もあります。

準委任契約の役割と作業時間の管理

準委任は、専門家が合意した業務を遂行する契約です。成果物の完成を無条件に約束する契約とは異なります。

• 適する工程：要件定義、管理、アジャイル開発、運用改善、技術支援。
• 管理項目：稼働時間、担当、作業、会議、報告、優先順位を明確にする。
• 指揮命令：発注者が受託会社の担当者へ直接指示せず、分担と窓口を体制図で示す。
• 契約管理：再委託、秘密保持、個人情報、知財、利用範囲、終了時の引き継ぎの確認。

月次報告と次月計画を使えば、費用と優先順位を管理できます。

どの契約にも共通する変更・知財・終了の条件

変更申請、再見積もり期限、追加単価、納期変更、未使用工数の扱いを決めます。さらに、ソース、設定、デザイン、テスト、移行ツールの権利と、既存ライブラリの扱いも確認します。

将来の切替に備え、データ返却、形式、移行支援単価、アカウント・ドメイン名義、決済情報の引き継ぎを定めます。

解約できるだけでなく、事業を止めずに移行できることが、長期運用の条件です。

ECプラットフォームの外注費用相場

費用は、利用料、制作・開発、連携に分けて考えます。移行、決済手数料、保守も、別に見ておきます。SaaSの公開価格と、パッケージやスクラッチの費用は、同じ初期費用として比べられません。

以下は、2025〜2026年の公開価格と類似する業務システム開発をもとにした予算の目安です。税別で要件ごとに異なり、確定見積もりではありません。

方式別の初期費用と期間の目安

方式ごとの初期費用、月額費用、期間を比べたうえで、外注作業の費用も加えて予算を組みます。

• モール型：初期0〜6万円程度、月額0〜13万円程度に販売手数料が加わります。即日〜1か月程度で始められる場合があります。
• ASP・SaaS：制作外注を除く初期0〜10万円程度、月額0〜5万円程度と決済手数料。即日〜1か月程度が目安です。
• オープンソース：構築30万〜200万円程度、サーバー月5,000円〜3万円程度、保守月3万〜15万円程度が目安です。期間は1〜4か月程度です。
• クラウドEC・パッケージ：基幹・WMS連携やBtoB要件を含むと、初期300万〜1,500万円程度、期間4〜8か月程度が目安です。
• フルスクラッチ：3,000万円から数億円、期間6〜18か月以上になる可能性があります。

futureshopの公式料金は、初期22,000円から、月額基本料金27,000円からです。

omni-channelの料金は、商品数30,000の掲載で初期752,000円、月額167,000円です（出典: 株式会社フューチャーショップ「料金」、確認時点の税別公開価格）。

商品登録、デザイン、撮影、移行、運用代行は別費用になります。そのため、事業開始までの総額で見積もります。

また、オプションや決済にも、別途費用がかかります。料金表は、発注費用の一部として扱います。

連携・移行・保守の費用

POS、ERP、会計、WMS、CRM、MAとの連携やデータ移行は、見積もりが膨らみやすい項目です。

複数ブランドや店舗在庫の同期も対象に含め、範囲と条件を明らかにします。

• 対象業務：POS、ERP、会計、WMS、CRM、MA、会員・商品・在庫・注文、複数店舗。
• 予算目安：3〜6システムの連携・移行は、類似する業務システム開発からの推定で、500万〜3,000万円程度を追加計上することがある。
• 大規模案件：店舗・ブランドが多く、リアルタイム在庫や複雑な返品を含む場合、3,000万円〜1億円超になる可能性があります。
• 変動条件：連携方向、データ件数、APIの有無、リアルタイム性、エラー時の再送、移行データの整備状況で変わる。各社共通の公開料金ではない。
• 見積内訳：方式、担当範囲、試験件数、保守費を、連携先ごとに分けた内訳。

5年TCOによる初期費用以外の比較

初期費用以外の支出や、事業の成長に伴う費用の変化を、5年単位で見通します。

• 費用項目：構築、利用料、手数料、アプリ、サーバー、保守、監視、開発、更新、移行、教育、社内工数。
• SaaS：初期費用が低くても、売上に応じた決済・取引手数料やアプリ費が積み上がることがあります。
• スクラッチ：保守要員、クラウド、脆弱性対応、改修費を含める。
• 成長時の比較：1年目、3年目、5年目の累計を出し、注文数、売上、商品・会員数、店舗数、APIコール数による従量費を分けること。

成長シナリオを当てはめて、費用と事業価値のバランスがよい方式を選びます。

委託先選定と相見積もりで比べる点

知名度や導入社数より、自社の商流と運用に合うかどうかで選びます。BtoCやBtoBでは必要な機能が異なります。定期通販や越境、OMOでも、求める機能は変わります。

自社に近い商品数や注文数、店舗数の事例を聞き、既存システムや移行条件の近さも確かめます。加えて、どの業務をどう変えたか、誰が保守したかも確認します。

業界・商流・連携実績の確認

自社に近い業務の実績に加えて、提案から運用までの担当体制も確かめます。

• 業務実績：業界、SKU、注文、ピーク負荷、BtoB、定期購入、店舗、海外、決済、物流、基幹、移行の実績。
• デモと体制：失敗しやすい業務のデモ、提案・実装・保守の体制、再委託、担当の継続。
• 会社の役割：SaaS提供会社と認定パートナー、ライセンス会社と導入SIerの区別。

障害や変更時に、誰が窓口になるかも確かめます。さらに、複数社を自社で調整する場合は、その管理工数も見込んでおきます。

見積書の作業単位と前提条件

見積書は、作業範囲と積算条件をそろえたうえで比べます。

• 作業内訳：要件、UI、画面、管理画面、API、移行、負荷試験、セキュリティ診断、リリース、教育、保守を行単位で示す。
• 積算条件：時間、単価、人数、期間、成果物、除外、追加費用。
• 機能の範囲：標準、設定、個別開発、別サービス、対象外の区分を示してもらう。APIの項目対応、頻度、再送、監視も見る。
• 移行の範囲：件数、変換、名寄せ、試験回数、切替、旧システムの保持期間。

対象外が多い低額の見積もりでは、後からの追加費用に注意します。

リスクとプロジェクト管理体制の比較

提案書には、リスク、発生条件、影響、回避策、判断者を記載してもらいます。例として、商品データの遅れ、API変更、決済審査、性能不足、現場定着、担当交代が挙げられます。

前提と対策が具体的な会社は、発注後の管理にも見通しが立ちます。責任者、技術、業務、デザインの役割を確かめます。試験、移行、保守の役割と稼働率も見ます。

会議の頻度、課題の優先度、経営報告、意思決定の期限、遅延時の連絡経路を評価します。また、発注者側にも責任者と現場のキーユーザーを置きます。

発注条件に含めるセキュリティと2026年の最新動向

ECでは、決済情報、氏名、住所、購買・閲覧履歴、問い合わせを扱います。そのため、保存するデータと利用目的、権限、暗号化を確かめます。ログやバックアップ、委託先、保管場所、削除方法も見ます。

特定商取引法の表示、返品・解約、定期購入の最終確認画面など、法令に関わる表示や業務も、要件・テストに含めます。

決済方式とPCI DSSの責任分界

決済方法と委託先ごとに、カード情報やセキュリティ管理を誰が担うかを決めます。

• 決済方式：カード情報を自社環境で保存、処理、通過させるか、決済会社に委託するか。外部ページ、埋め込み、トークン化の比較も。
• 責任分界：決済会社が準拠していても、自社側の責任は残る。
• 自社の管理：ページのスクリプト、アクセス制御、脆弱性対応。

PCI Security Standards Councilは、PCI DSS v4.0.1のスクリプト対策要件を案内しています。この対策は、2025年3月31日から有効です。

タグ一覧、変更承認、完全性確認、監視、診断、事故時の連絡経路を仕様書に含めます。さらに、認証だけでなく、運用の証跡も確かめます。

API・ヘッドレス・AIの採用判断

2026年時点の技術も、課題と導入条件に照らして採用を判断します。

• 基盤技術：クラウド、API、ヘッドレス、Composable Commerceの検討。チャネルの再利用や表示速度も見る。
• 商品情報：PIMを使ってまとめて管理する目的を明らかにする。
• AI機能：検索、レコメンド、チャットボットを、表示速度や問い合わせ削減などの課題に結び付ける。
• 導入前提：商品属性、顧客同意、購買履歴、在庫、価格の品質。
• AIエージェント：変更・返金の範囲、上限、承認、人への引き継ぎ、ログ、誤回答時の補償を定める。

フロントとコマース機能を分けると、自由度は上がります。一方で、開発や監視、障害の切り分けを担う責任も増えます。

売上の向上は言い切らず、検索精度や対応時間、レコメンド経由率などを指標にします。

効果を確かめながら、段階的に導入します。

ECプラットフォームの発注・外注でよくある質問

発注形態や費用、委託先、社内体制について、発注前の判断に役立つ回答をまとめます。

ECプラットフォームの発注は自社開発と外注のどちらがよいですか？

早期に立ち上げたい場合や、専門知識が必要な連携・セキュリティがある場合は、SaaSやパッケージを選び、設計・開発・移行・保守を外注する方法が現実的です。

継続的な開発体制があり、独自業務が競争力の中心なら、内製や共同開発も候補になります。ただし、稼働後も改善を続ける責任者と体制が欠かせません。

ECプラットフォーム開発の見積もりは何社から取るべきですか？

候補を3〜5社程度に絞り、同じRFPと業務シナリオで依頼する方法が一般的です。

会社数を増やしすぎると、質問対応や比較に時間がかかり、提案内容も表面的になることがあります。

価格、前提、対象外、体制、実績を同じ評価表で比べます。保守、移行、追加費用、5年TCOも、評価表に入れます。

ECプラットフォームの費用は初期費用だけ見ればよいですか？

初期費用だけでは不十分です。利用料や手数料、アプリ、連携、移行を含め、5年TCOで比べます。保守、監視、開発、教育、社内工数も、その範囲に入ります。

注文数や商品数による従量費、プラン変更、解約時の移行費も確認します。そのうえで、導入後の予算増を抑えます。

RFPに最低限入れるべき項目は何ですか？

RFPに最低限入れるのは、目的、KPI、業態、商品・会員・注文数です。業務、機能、既存システム、連携、移行、性能についても記載します。加えて、セキュリティ、法令、時期、体制、予算、保守も入れます。

RFPには、範囲を標準、設定、追加開発に分けて書き、対象外も明記します。

データ所有権、API、解約時の返却も含めます。評価方法も入れると、候補各社が同じ前提で回答できます。

まとめ

発注前には、売上だけでなく、受注や在庫、物流、顧客、店舗連携まで目的に含めて定めます。そのうえで、規模や複雑さ、連携、社内体制から方式を選びます。

RFPには、業務や要件、受入条件、移行、保守、責任の分け方を記し、同じ条件で提案を受けます。契約は、工程ごとに請負と準委任を使い分けます。

初期費用だけでなく、利用料や手数料、連携、移行を含め、5年TCOで比較します。保守や開発、社内工数も、その計算に入れます。そのうえで、業務と成長に合う委託先を選びます。

▼全体ガイドの記事
・ECプラットフォーム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【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を創業。