EC商品登録システムの発注は、業務とデータの整理、方式と契約の選定、要件をそろえた見積もり、PoCからの段階導入の順に進めると、運用定着につながります。
各段階で決めることを順に説明します。全体像はEC商品登録システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・EC商品登録システム開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC商品登録システムの全体像

EC商品登録システムは、商品情報を一か所にまとめ、販売チャネルごとの形式に変換して配信するデータのハブです。
扱う情報は、SKUや価格、在庫、画像などです。商品名や説明文、カテゴリ、規格、税率も含まれます。発注の段階では、どの部署の情報を正しいとみなすか、いつ時点の情報を公開するかも決めておきます。
入力画面ではなく配信ハブという役割
商品を一度登録し、その情報を複数チャネルへ配信する流れが中心です。
楽天市場、Amazon、Yahoo!ショッピング、自社ECでは、必須項目が異なります。
- チャネルごとの違い:カテゴリ、文字数、画像仕様、バリエーションの表し方が違います。
- 変換と再送:変換ルールでチャネル間の差を吸収し、失敗した行だけを通知して再送できます。
- CSVの項目:EC-CUBE4の公式マニュアルでは、商品名、画像、カテゴリ、規格を掲載しています。商品コード、在庫、価格、税率なども含まれます。
CSV形式を確認したうえで、一括登録や更新を行う流れも示されています(出典:EC-CUBE公式マニュアル、2026年確認)。
発注・外注を検討しやすい企業の特徴
商品点数、販売先、更新頻度を見て、標準機能で足りるか、連携を検討する必要があるかを判断します。
- 標準機能で足りる場合:商品点数が少なく、販売先が一つで、更新も月数回の場合
- 連携SaaS:商品数、SKU数、販売チャネル、仕入先が増え、価格改定や新商品の公開が毎週発生する場合
- 対象:PIMやMDMの導入が効果を出しやすい領域
PIM(Product Information Management)やMDM(Master Data Management)は、商品情報の管理を担う仕組みです。
外注を判断するときは、担当者の作業時間に加えて、誤表示や在庫連携の漏れ、発売遅延、返品、問い合わせが経営上の損失になっていないかを確認します。Excelの最新版が分からない、あるいはEC・倉庫・POSで商品コードが合わない場合は、ツールを選ぶ前に正本と責任者を決める支援を依頼する価値があります。
EC商品登録システムの発注形態の選び方
標準的な業務にはSaaSやパッケージを使い、独自の業務や既存システムとの接続だけを個別に開発する形は、費用と柔軟性のバランスを取りやすい選択です。選択肢をスクラッチ開発か標準機能かの二択にせず、商品データの複雑さと連携範囲を分けて考えます。
ECカート標準機能・CSV登録を使う方式
ECサイトが一つで、商品属性が複雑でなければ、標準の管理画面とCSV一括登録から始められます。
- 利点:導入費を抑えやすく、運用担当者が自分で変更しやすい
- 注意点:Excelで編集すると、JANコードの先頭ゼロが消えたり、カテゴリIDがずれたり、画像URLが切れたりする場合があります
- 差分確認:EC-CUBE公式マニュアルは、先頭ゼロの消失に注意し、変更前後の内容を見比べるよう勧めています(出典:EC-CUBE公式マニュアル、2026年確認)
商品登録SaaS・パッケージを導入する方式
複数のモールへ同じ商品を出品し、受注や在庫もまとめて扱いたい場合は、商品登録・モール連携SaaSが候補になります。
- 導入の利点と確認事項:初期費用を抑え、既存機能を短期間で使えます。確認したいのは、月額料金、従量課金、追加アプリ、API上限、データ返却条件です。
- ネクストエンジンの基本料金:初期費用0円で、月額3,000円に受注件数200件までが含まれます。
- 機能別料金:商品登録機能だけなら基本料金の範囲で、有料アプリは別途かかります。
- 年間保守:契約から1年が経過した後は、15,000円(税抜)がかかります(出典:ネクストエンジン公式「料金」、2026年8月確認)。
なお、初期設定やデータ移行の費用は、別に見積もる必要があります。個別連携や運用教育の費用も、別に見積もります。
パッケージ拡張・スクラッチ開発を選ぶ方式
仕入先から独自形式のデータを受け取り、品質表示や法令チェックを行う場合は、この方式を検討します。
基幹システム、WMS、POSとつなぎ、複数のECへ配信する場合は、PIM/MDMや個別連携が必要になります。
- パッケージ拡張:標準機能と保守体制を活かせます。
- スクラッチ開発:独自の承認や変換ルールを組み込めます。
開発量を左右するのは、商品点数よりも、SKU構成や属性、更新頻度です。加えて、チャネル差分や正本の場所、移行の難しさも影響します。
まずは代表的な100〜500商品と主要2チャネルでPoCを行い、変換エラー、承認、再送を確かめます。
公開後の差分も確認してから、範囲を広げます。
RFPと要件を整理してから発注する進め方

RFP(提案依頼書)は、現状業務や課題を共有し、対象データや連携先も伝える文書です。納期や予算の考え方、提案範囲も示し、欲しい機能の一覧はその一部として扱います。
RFPは、同じ条件で提案と見積を比べるための基準になります。特に、要件が曖昧だと各社の前提が異なり、金額だけでは比べられません。
現状業務とデータの洗い出し
見積もりの前提をそろえるため、業務量と商品データの管理状況を洗い出します。
- 業務量:商品数とSKU数、新規登録と更新の件数、チャネル、仕入先、担当者
- 保管と時期:画像や仕様書の保管先、発売日が集中する時期
- コード対応:商品コード、JAN、SKU、チャネルID、在庫管理コードの対応関係
- 情報の正本:価格、在庫、説明文、画像、税率ごとに、基準とする情報源を決めます
たとえば、Tシャツ1商品に色5種類とサイズ6種類があれば、商品は1件でもSKUは30件になります。商品数だけを見積先に伝えると、登録と連携の量を実際より小さく伝えてしまいます。
双方向の同期では、EC側で行った修正が基幹側の更新で上書きされる場合があります。そこで、連携方向、更新頻度、競合時の優先順位をRFPに記載します。
機能要件に含める登録前後の業務
機能要件は、登録の前後にある業務も含めて、機能ごとに整理します。
- 商品管理:商品マスタ・SKU登録、複製、一括編集、予約公開、変更履歴
- データ取込:画像・動画・仕様書の紐付け、CSV/Excel/TSV、必須項目と重複SKUの検証
- チャネル連携:カテゴリ・文字数・画像変換、API/CSV反映、失敗通知・再送、結果確認
- 承認と権限:申請・承認、部署・取引先ごとの閲覧・編集・公開権限、操作ログ、公開前レビュー
- AI利用時:参照元、禁止表現、事実確認、承認者、生成ログ、自動公開しない初期設定
AIは入力作業を補助しますが、品質表示や法令に関する最終責任を代わりに負うことはできません。
非機能要件と受け入れ条件の決め方
稼働条件と安全性の要件は、受け入れのときに確認できる形で定めます。
- 稼働・復旧:対応時間、同時利用者数、連携間隔、障害時の再実行、バックアップ世代、復旧目標
- 監視と保護:監視、ログ保存期間、脆弱性対応、暗号化の方法を定めます。MFA、IP制限、SLAも含みます。
誤った商品を止められることや、誰がいつ公開したかを追跡できることも重要です。
登録できただけで受け入れ条件を満たしたとしないよう、注意します。
たとえば、主要2チャネルに100商品を登録し、価格と画像を更新します。そのうえで、指定の形式で反映され、エラー行を特定して再送できることを条件にします。
また、移行件数と許容する欠損を決め、文字化けや画像リンク切れの検査方法も定めておきます。完成の定義が曖昧なままだと、納品後に追加費用や責任範囲をめぐる争いが起きやすくなります。
請負・準委任・保守の契約形態の使い分け

契約の名前より、作業内容や成果物、変更手順が明確かを確認します。
また、どこまでを誰が受け持つかも見ておきます。要件が固まった開発、変わりやすい要件定義、リリース後の保守では、適する契約が異なります。
法務、情シス、現場責任者が、同じ前提で見積書と契約書を確認します。
完成物を確定できる部分は請負契約
請負契約は、合意した成果物を完成させることを中心に発注する形態です。
- 向いている作業:要件、画面、API仕様、テスト項目、納品物、検収条件を定義できる機能開発や、一定範囲のデータ移行
- 費用と変更:固定金額にしやすい一方で、契約後の追加や変更を無制限には含みません
- 確認事項:完成基準、検収期間、不具合、知的財産権、第三者ソフトのライセンスです。加えて、再委託、納期遅延、仕様変更の見積方法も押さえます。
「ECモール連携一式」という書き方では、対象APIや項目、再送テストの回数が分からないため、成果物を機能単位に分けて別紙に記載します。
要件定義や改善は準委任契約
準委任契約は、専門家としての注意義務を果たしながら、合意した業務を遂行する形態です。
- 向いている業務:現状分析、データ項目設計、RFP作成支援、PoCなどが向いています。アジャイル開発や運用改善も、仕様や優先順位が変わる業務です。
- 契約で定めること:月次の作業内容、稼働時間、会議体、成果物の扱い、報告方法
- 契約の考え方:変更のあるアジャイル開発には、準委任がなじみやすいです。
- 段階契約:要件定義は準委任、確定したMVPは請負、改善は準委任とする方法もあります
IPAの資料は、この点を説明しています(出典:IPA「アジャイル開発外部委託モデル契約」、2025年公開資料)。
保守・運用契約に含める障害対応
保守契約では、稼働後に発生する作業と、その対応条件を明確にします。
- 主な運用作業:連携監視、API変更、脆弱性修正、バックアップ、ユーザー・マスタ変更、問い合わせ
- 契約条件:受付時間、一次回答・復旧目標、休日対応を決めます。さらに、対象外作業、月次報告、追加開発単価、データ返却も含めます。
決済情報を扱わない場合でも、管理画面や取引先ファイルへの侵害は、誤表示や情報漏えいにつながります。
経済産業省は、2025年3月の改訂で、EC加盟店に対策を求める方向を示しています(出典:「クレジットカード・セキュリティガイドライン6.0版の改訂」、2025年)。
対策には、脆弱性対策、EMV 3-Dセキュア、不正ログイン対策が含まれます。
システムとPSPの範囲を分けたうえで、保守契約で誰が何を確認するかを決めます。
EC商品登録システムの費用相場と見積の内訳
EC商品登録システムに特化した公的な価格統計は確認できません。そのため、この数字は、2025〜2026年の公式料金、類似するEC構築・PIM導入案件、リサーチノートをもとにした、発注前の目安です。
費用は、商品数やSKU、チャネルの数で大きく変わります。
既存データの状態、API、承認・権限の複雑さによっても変わるため、完成価格として断定せず、見積もりで確認します。
方式別の初期費用・月額・期間の目安
方式ごとの費用と期間は、対象チャネルや導入範囲によって異なります。商品登録・モール連携SaaSでは、公開料金と、支援・アプリ・移行の費用を分けて考えます。
- ECカート標準:初期0〜30万円程度、月額0〜10万円程度、期間は数日〜2か月です。1チャネル中心で、CSV整形や簡単な初期設定を想定しています。
- 商品登録・モール連携SaaS:初期0〜100万円程度、月額3,000円〜30万円程度、導入2週間〜3か月です。
- PIM/MDMクラウド:属性設計や承認、画像・文書、APIを含みます。初期は50〜500万円程度、月額は10万〜100万円程度、期間は2〜6か月です。
- パッケージ+個別連携:初期300万〜1,500万円程度、月額・保守10万〜100万円超、期間は4〜10か月です。
- スクラッチ・大規模PIM基盤:初期1,000万〜5,000万円超、期間は8〜18か月以上になる場合があります。
PIM/MDM、パッケージ+個別連携、スクラッチの金額は、類似するEC/PIM開発から推定したレンジで、公的な公開統計ではありません。
公開料金の見方と導入費の分け方
公開料金は、相場の下限や製品の利用料を把握する参考になります。たとえば、Shopify Japanの料金ページは、年払いの月額を案内しています。
- Basic:月額3,650円
- Grow:月額10,100円
- Advanced:月額44,000円
- Plus:月額368,000円から
(出典:Shopify Japan「料金プラン」、2026年7月24日時点の表示)。カード・外部決済の手数料、アプリ、テーマの費用は、この料金とは別に考えます。
移行や個別開発の費用は、この料金の外で見積もります。
eBASEの2026年4月1日改定の価格表には、月額、導入型ライセンス、年額の保守・L&S価格が掲載されています。
一部のeB-DBP系サービスでは、導入型で320万円、年額L&S価格が64万円の例があります(出典:eBASE「ソフトウェア価格改定表」、2026年4月改定)。
これは特定構成の製品価格で、導入総額ではありません。
要件定義や移行、連携開発、教育が含まれるかは、見積もりの範囲で確認します。
見落としやすい移行費・連携費・運用費
この金額は、案件条件から算出した推定レンジで、特定ベンダーの定価ではありません。見積もりの仮置きとして扱います。
- 要件定義・データ項目設計:20〜100万円程度
- 商品マスタのクレンジング・移行:50〜300万円程度
- モール・EC・基幹API連携:1本あたり50〜300万円程度
- ワークフロー・権限・ログ:50〜200万円程度
- テスト・教育・リリース支援:50〜300万円程度
月額のSaaS料金だけを比べると、移行や連携の追加費用が膨らむことがあります。そのため、3年間のTCO(総保有コスト)で比べます。
3年間のTCOには、初期ライセンスや設定、移行、連携を含めます。月額の料金に加えて、アプリ、保守、監視の費用も入れます。教育や障害対応の費用に加え、将来のチャネル追加や解約時の返却まで合計します。
見積書には、「含む」「含まない」「前提条件」「追加時の単価」を分けて記載してもらいます。
委託先の選定と見積比較で確認するポイント
委託先は、知名度よりも、自社の商品属性やSKU、チャネル、基幹連携に対応できるチームかどうかで選びます。製品の提供や導入支援、開発、保守が、会社によって分かれる場合もあります。
契約の相手と、実装や運用を担当する人を分けて確認します。
業界・SKU・連携の実績の確認
「ECの導入実績があります」という説明だけで済ませず、実績を具体的に質問します。
- 商品・移行:近い属性やバリエーション、移行した商品・SKUの規模
- 連携方式:楽天・Amazon・Yahoo!・自社EC・POS・WMSとの連携
- 運用機能:エラー再送、承認・権限・操作ログ、稼働後の問い合わせ体制
可能であれば、提案の段階から設計・開発・運用の担当者にも参加してもらいます。また、営業資料と現場の回答に差がないかも確認します。
アパレルでは、色・サイズ・シーズンと画像運用が問われます。食品では、特に原材料・アレルゲン・賞味期限が問われます。
BtoBでは、規格書や取引先別の価格、多言語対応などが対象になります。業界によって、重要な項目は変わります。
商品情報の多い企業ではPIM/MDM、モール運営では一括登録と在庫・受注連携の経験を確認します。
導入企業の名前を並べるだけでなく、自社に似た課題をどう解いたかを説明できる会社を候補にします。
同じ前提にそろえた見積比較
同じRFPを各社へ渡し、見積項目と前提をそろえて比較します。
- 見積項目:要件定義、基本設計、画面開発、API連携、CSV変換、データ整理・移行
- 作業範囲:画像移行、テスト、教育、リリース、保守
- 共通前提:商品数500件、SKU数、主要2チャネル、既存データ例を前提にします。API仕様、納期、受け入れ条件も含めます。
移行費が会社によって別料金になっている場合は、同じ範囲にそろえて確認します。
- 評価軸:機能適合度、移行、連携・監視、セキュリティ、導入期間、担当体制
- 費用・契約:3年TCO、契約条件、解約時のデータ返却
最安値を自動的には選ばず、前提が明確で、リスクと除外項目を示す会社を評価します。
極端に安い見積については、要件定義、テスト、移行、保守が含まれているかを質問します。
小さなPoCから本番移行までの責任の確認
候補を2〜3社に絞り、代表商品と主要チャネルでPoCを行います。その際は、登録の速さだけでなく、運用に必要な動きを確かめます。
- 商品データ:商品・SKUの構造を表現できるか
- 紐付け:画像と説明文が正しく紐づくか
- 連携:チャネル別変換のエラーが分かり、再送できるか
- 承認:承認前の商品が公開されないか
- 障害対応:価格改定を安全に反映し、失敗時に元へ戻せるか
本番移行では、全商品を一度に切り替えず、カテゴリやブランド単位で段階的に移行します。
移行の前にはバックアップと差分検証を行います。あわせて、旧システムの参照期間と切り戻しの条件を決めます。
発売日に障害が起きた場合の手動登録の手順と、社内教育の責任者も決めておきます。
現場が登録、承認、再送を自分たちで回せる状態までを、納品条件に含めます。
よくある質問(FAQ)
発注時によくある契約、費用、委託先選びの疑問に答えます。自社の状況と照らし合わせて、RFPに加える質問を確認してください。
EC商品登録システムはSaaSとスクラッチのどちらがよいですか?
標準登録や複数モールへの一括反映が中心であればSaaSが候補です。独自の属性や承認、基幹連携が競争力に直結する場合は、拡張やスクラッチが候補になります。
商品数だけでなく、チャネル差分や更新頻度、データ品質、正本の場所を見ます。100〜500商品程度のPoCで確かめると、判断材料がそろいます。
発注前に予算をどの程度見ておけばよいですか?
商品数やSKU、移行、連携範囲などを踏まえて、方式ごとに初期費用を比べます。
- ECカート標準:初期0〜30万円程度
- 連携SaaS:初期0〜100万円程度
- PIM/MDM:初期50〜500万円程度
- 個別連携・スクラッチ:数百万円から数千万円超になる可能性がある
費用は、商品数やSKUの多さ、移行の量によって変わります。API、承認、テストを含む範囲でも変動します。
月額料金だけでなく、移行・連携・保守・教育を含む3年TCOで予算を組みます。
委託先を選ぶときに最低限聞くべきことは何ですか?
近い商品属性やSKU規模の実績、移行範囲、主要チャネルとの連携を聞きます。エラー再送と監視、権限・承認・ログについても聞きます。加えて、セキュリティ、保守時間、SLAも確認します。
解約時のデータ返却も確認します。また、実際に設計・開発・運用を担当するチームに会い、見積もりの前提と除外項目を質問してください。
要件が決まっていない状態でも外注できますか?
外注はできます。ただし、完成品の固定価格をすぐ求めるより、要件定義、現状分析、データの洗い出しを準委任で依頼し、その成果をもとに開発範囲と請負部分を決める方法が安全です。
契約書には、要件変更の可能性、会議体、成果物を記載します。作業時間や、次段階へ進む判断基準も書いておくと、双方の認識を合わせやすくなります。
まとめ
発注前に整理すること
発注前は、次の順で整理すると、対象範囲と責任が明確になります。
- 商品情報の正本と業務課題を整理し、SKU、チャネル、更新頻度、連携、データ品質から方式を選ぶ。
- 必要範囲に応じてECカート標準、商品登録SaaS、PIM/MDM、パッケージ拡張、スクラッチを検討する。
- RFPに、現状業務と商品・SKU構造、正本と連携方向、変換・承認・権限・再送、非機能、移行、受け入れ条件を記載する。
- 確定成果物は請負、変化する要件定義や改善は準委任、稼働後の監視・障害対応は保守に分ける。
見積比較で決めること
費用は、製品の月額だけでなく、3年TCOで比べます。3年TCOには、要件定義から移行、連携、テストまでを含めます。さらに、教育と保守も入れ、拡張や解約時の返却まで含めます。
2〜3社に同じRFPを渡し、代表商品と主要チャネルでPoCを行います。安さだけでなく、データ品質と運用定着を支えられる委託先を選びます。
▼全体ガイドの記事
・EC商品登録システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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