ECサイトの開発費は商品数で上がるのか｜商品登録作業・移行・システム負荷を分ける

ECサイトの開発費が商品数で上がると言われたとき、経営側が困るのは金額そのものではありません。商品数を半分にしたら開発費も半分になるのかという当たり前の問いに、見積書が答えていないことです。同じ「商品数10,000点」でも、その数字が動かす費用と、まったく動かさない費用が、1枚の紙の中に混ざっています。

この記事は、その混ざったものを分けるための手順書です。値下げ交渉の話はしません。商品数が費用へ効く経路は実在するので、「数量と費用は比例しないはずだ」と先に決めつけることもしません。効く経路と効かない経路を、公開されている一次資料の側から具体的に切り分けます。

TL;DR｜商品数と開発費の関係は3つに分かれる

• 「商品数で開発費が上がるのはおかしい」という結論から入らないでください。 商品数が効く費目は実在します。問題は、効く費目と効かない費目が同じ1行にまとめられていて、発注側がどちらなのか判定できないことです
• 比例してよいのは、人が1点ずつさわる作業です。 撮影・採寸・原稿作成（EC業界で「ささげ」と呼ばれる工程）と、商品データの登録は、点数がそのまま作業量になります。ここが点数比例なのは自然です
• 比例しないのは、画面と機能です。 商品一覧・商品詳細・カート・決済・会員機能は、扱う商品が100点でも10万点でも同じ画面を1回作ります。ここが点数で2倍になっている見積もりは、根拠を聞く価値があります
• 階段状に効くのが、システム側の負荷とデータ移行です。 ある件数レンジを越えると検索の実装方式や移行の進め方が変わり、そこで工数が跳ねます。逆に言えば、レンジをまたがない範囲では増えません
• 「商品数」という言葉が、見積書の中で複数の数に化けます。 カラー3色×サイズ3種類の服1着は、1（型・商品ページ）とも、5（撮影と採寸の対象となる作業ピース）とも、9（SKU）とも数えられます。単価の妥当性を議論する前に、どの数え方で数量欄が埋められているかを確定させてください
• 危ないのは高い見積書だけではありません。 商品数が多いのに性能試験と移行リハーサルの行が無い見積書は、公開直後に止まるリスクを発注側が引き受けている状態です
• この記事が扱うのは、構築時に一度だけ発生する費用です。 稼働後の毎月の保守費で商品数連動が起きている場合はECサイトの保守費用は商品数で上がるのかをご覧ください

「商品数10,000点」が、見積書の中で複数の数に化ける

最初に片付けるべきなのは金額ではなく、数え方です。ここが揃っていない状態で単価を比べても、比較になりません。

EC向けの撮影・採寸・原稿作成を主軸に受託している株式会社ささげ屋（会社概要ページに「創業以来、「ささげ」ひと筋」と記載）は、コストの説明ページで用語を定義しています（2026年8月24日取得）。原文は次のとおりです。

型（品番）：1デザイン＝1型

SKU：サイズとカラーバリエーションごとの総数　3カラーバリエーション/SMLのサイズ展開の場合、「1型9SKU」

さらに、作業量の数え方について注記があります。

※ささげ作業に必要なピースは、撮影のための（カラーバリエーション数）と、採寸だけのための（サイズバリエーション数-1）となります。つまり、上記1型3カラバリ3サイズバリの場合、ささげに必要なSKU数は「5SKU」となります。

そして、ページ側の数え方についても書かれています。

「商品ページ」は1型＝1ページ が一般的です。

3色×3サイズのTシャツ1着を例にすると、次のようになります。

同じ1着が、1とも5とも9とも数えられます。 数え方が変われば9倍の開きが出るので、「1点あたり◯◯円」という単価は、数え方を決めない限り高いとも安いとも言えません。以降この記事では、5にあたる単位を作業ピースと呼びます。

Shopifyのヘルプセンター（2026年8月24日取得）も、商品データの持ち方を同じように区別しています。バリエーションのある商品をCSVで登録する手順について、原文は次のように説明しています。

バリエーションのある商品をアップロードする場合、1行目に最初の商品画像のURLとともに、その商品のすべてのフィールドを入力します。次の行以降には、URLハンドルを入力します。その後、Title、Description、Vendor、およびTags列をスキップします。残りのバリエーションの詳細と各画像のURLを入力します。

つまり1商品が1行では収まらない形式です。同ページには「1つの商品に最大3つのオプションを設定できます」という記載もあります。データ投入の作業量を決めているのは商品の点数ではなく、この行数のほうです。

見積書の数量欄でまず確定させること

数え方の候補は4つあります。見積書の数量欄が「10,000」となっているとき、それがどれなのかを聞いてください。上の表と同じ順（少ないほうから多いほうへ）で並べます。

1. 型（品番）の数
2. 商品ページの数
3. 作業ピースの数
4. SKU（カラー×サイズなどのバリエーション総数）の数

この4つは相互に何倍も違います。相見積もりで単価だけを比べると、単に数え方が違う2枚を比べていることになります。

見積書では、どう書かれているか

EC構築の見積書で商品数が現れるのは、たいてい次のような行です。金額は入れていません。確認すべきなのは金額ではなく、単位と数量の根拠だからです。

見積書の「一式」がなぜ判断を止めるのかは、見積書の「一式」を工程・成果物・工数へ分ける確認方法で扱っています。ここでは、商品数に固有の論点だけを進めます。

この段階で決めつけないでください。 「初期商品登録　10,000点」という行そのものは、まったく正当な書き方です。人が1点ずつ作る作業なので、点数が単位になるのが自然です。問題になるのは、点数の単位が画面や機能の行にまで及んでいるときです。

開発費のどこに商品数が効くのか｜非機能要求グレードで分解する

「商品数は開発費に効くのか」という問いは、実は業界の共通言語で答えが用意されています。

独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センターが公開している「非機能要求グレード2018」（2018年4月版、(c)2010-2018。2026年8月24日取得）は、システム基盤の非機能要求をユーザーとベンダーが合意するための項目集です。同資料の利用ガイド解説編は、対象範囲をこう定めています。

非機能要求グレードでは、上流工程において、情報システムの設計を開始するまでに、ユーザ/ベンダ間で合意すべき要求項目を対象としている。

つまり設計を始める前に発注側と決めておくことのリストであり、まさに見積書の前提にあたります。要求は「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの大項目に整理され、項目一覧には238のメトリクス（指標）が並びます。

このリストの中で、商品数がどこに置かれているかを見ると、論点が一気にはっきりします。

商品数は「業務機能数」ではなく「データ量」の欄に入る

性能・拡張性の大項目は「業務処理量」「性能目標値」「リソース拡張性」「性能品質保証」の4つの中項目でできています。このうち先に決めるべきものについて、解説編はこう書いています。

性能・拡張性に関する非機能要求を合意する場合、「業務処理量」をはじめに決めることが一般的である。

その「業務処理量」の中の小項目「通常時の業務量」には、6つのメトリクスが横並びで置かれています（項目一覧 B.1.1.1〜B.1.1.6）。

商品数はここでいう「データ量」に当たります。そして「業務機能数」は別のメトリクスとして並んでいます。

ここが要点です。非機能要求グレードは開発費の内訳を定めた資料ではありませんが、「データ量」と「業務機能数」を独立した2つの入力として扱っていることは、この並びからはっきり読み取れます。同じ表に載っているが、同じ欄ではない。

見積書に置き換えると、確認すべきことが1つ決まります。「商品数が2倍だから開発費も2倍」という説明が来たとき、その2倍はどちらの欄の話なのか。データ量が2倍になったことは、業務機能数が2倍になったことを意味しません。両方が同時に増えるプロジェクトもありますが、それなら機能側の増分を機能側の根拠で説明してもらう必要があります。

なお同じ資料には「業務量増大度」という小項目もあり、こちらにも同じ6つの軸が増大率として置かれています。データ量増大率（B.1.2.3）のレベルは、1倍／1.2倍／1.5倍／2倍／3倍／10倍以上の6段階です。原典はこのレベルについて「レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。」と注記しています。将来どこまで増える想定かを先に決めておく欄が、標準の項目集に用意されているということです。見積書に商品数が書かれていても、この増大率が書かれていないなら、要件の半分しか固まっていません。

IPAは「データ量」でシステムの重さを区分していない

もう一段深い話があります。非機能要求グレードは、システムを社会的影響の大きさで3つのモデルシステムに分け、それぞれに推奨レベル（ベース値）を割り当てています。ところが「データ量」については、3つとも同じ値が割り当てられています。解説編はその理由を明示しています。

一方、全て同じレベルになっているメトリクスは、システムのベース値としてはどんなシステムでも同じになるが、決まっていない場合のリスクが大きいものをメトリクスとして定義しているためである。例えば、「B.1.1.3 データ量」は要件定義時には決まっているべきであるため、全てレベル 0 を定義している。

データ量は、システムの重さを区分するための軸として使われていません。 使われているのは「決まっていないこと自体がリスクだから、必ず決めておけ」という趣旨です。項目一覧の備考欄にも、次の注意書きがあります。

主要なデータ量しか決まっていない場合、後工程に於いて、検討漏れデータの出現などによるディスク追加などが発生するリスクがある。

ここから読み取れる発注側の行動は明快です。商品数の多さを理由に見積額の増減を交渉するのではなく、商品数と関連するデータ量が要件として確定しているかを先に確認する。確定していないまま進むと、後工程で費用が増える側に振れる、というのが標準の項目集が言っていることです。

なお、非機能要求グレードはシステム基盤の非機能要求を対象とした汎用の資料で、ECサイト専用のガイドではありません。3つのモデルシステムについて、原文はそれぞれ「ごく小規模のインターネット公開システム」「企業内のネットワークに限定した基幹システム」「不特定多数の人が利用するインフラシステム」を想定していると書いており、いずれもECサイトを名指ししたものではありません。ここでは金額の根拠としてではなく、発注側とベンダーが合意すべき項目の並び方を参照しています。

移行費を刻んでいるのは件数ではなく変換ルール数

既存サイトからの乗り換えなら、商品数が最も直接的に効きそうなのはデータ移行です。ここも同じ資料が答えを持っています。

移行性の大項目は「移行時期」「移行方式」「移行対象（機器）」「移行対象（データ）」「移行計画」の5つの中項目でできています。このうち「移行対象（データ）」に置かれているメトリクスと、そのレベルの刻み方を並べると、次のようになります（項目一覧 D.4系。列の対応は原本PDFの座標で確認しました）。

刻みの粗さを見比べてください。 「移行対象無し」を除くと、データの量は1TB未満・1PB未満・1PB以上の3段階しかありません。一方、変換ルール数は「移行ツール不要」を除いて10未満・50未満・100未満・100以上の4段階に刻まれています。移行媒体の種類数に至っては1種類ごとに刻まれています。

ここからの当てはめは筆者による解釈であり、IPAの主張ではありませんが、商品データの移行を考えるうえでは実務的な意味があります。商品テキストデータが数千点から数十万点へ増えても、容量の単位では同じ段階に留まる可能性が高い。一方で、移行元が自社サイトとモール2つの計3系統に分かれている、旧サイトのカテゴリ体系が新サイトと違う、規格値の入力ルールが商材ごとにばらばら、といった事情は、変換ルール数のほうを直接増やします。

同じ資料の「移行計画」には、リハーサルに関するメトリクスも並んでいます。

移行費の見積もりで発注側が確認すべき変数は、件数のほかに少なくとも6つあるということです。データ形式が移行先と同じか、移行媒体（原典の例示はテープ、ディスク、紙の伝票類、ネットワーク接続によるデータ転送）の種類はいくつか、変換ルールは何本か、リハーサルはどの範囲まで見るか、何回やるか、外部連携のリハーサルはあるか。「データ移行費　10,000件」という1行には、このどれも書かれていません。

商品数に比例してよい費用｜人が1点ずつさわる作業

ここまでは「点数では決まらない」側の話でした。ここからは、点数がそのまま費用になる側を扱います。この部分を無視して「数量と費用は比例しない」と言うと、実務と合いません。

EC構築で点数比例が自然なのは、商品情報そのものを人が作る工程です。EC業界ではこれを「ささげ（撮影・採寸・原稿）」と呼びます。

株式会社ささげ屋が公開しているコストの説明ページ（2026年8月24日取得。金額はすべて原文に「（税抜）」と明記）は、この工程の値付けについて、まず次のように書いています。

ささげのコスト（単価）は、ご依頼量や作業場所、業務範囲、クオリティレベルなどにより、大きく変わります。そのため都度のお見積りとなり、当社として単価表等はございません。

この工程を主軸にしている事業者が「単価表はない」と明言しているという事実そのものが、発注側にとっての情報です。同ページは価格表の代わりに、過去事例に基づくコスト感を5パターン公開しています。そのうち依頼形態が近い2つを並べます。

同じ「1回50型程度」でも、型単価平均は¥8,000と¥10,000で違います。 しかも高いほう（ジュエリー）は、SKU数が半分、カット数が半分、採寸箇所も少なく、原稿に至っては作業がありません。作業項目の数だけを見れば少ないほうが、単価は高くなっています。

原文にこの差の理由の説明はないため、ここでは断定しません。リードタイムはジュエリー側のほうが長く（5営業日以内／3営業日以内）、納期の短さが単価を押し上げているという説明も、この2件からは成り立ちません。断定できることは1つだけです。点数もSKU数も作業項目数も納期も、単価を一意に決めていない。 商材が変われば、同じ点数でも単価は動きます。

点数が増えると単価は下がり、期間のほうが先に詰まる

同じページの「毎月依頼」の事例は、量と単価と期間の関係を示しています。

毎月300型のこの事例は型単価平均¥5,000、先ほどのスポット50型は¥8,000です。量が増えると単価は下がる方向に置かれています。ただしこの2つも撮影方法（吊り／モデル）とカット数（6／10）が違うので、差のすべてを量で説明することはできません。

見落とされやすいのは、金額ではなく上から2行目です。1日の撮影数上限が100SKU以内と明記されています。これは費用ではなく期間の制約です。

商品数が多いECの構築で最初に効いてくるのは、多くの場合ここです。開発（画面と機能を作る）は並行して進められますが、商品情報の作成は撮影スタジオの稼働という物理的な上限に当たります。商品数が多いプロジェクトで金額より先に破綻するのは、たいていスケジュールのほうです。 見積書に「初期商品登録　10,000点」とあるとき、聞くべきことは単価だけではありません。1日あたり何点処理する前提か、そこから逆算して何営業日かかるのか、それは公開予定日に間に合うのか、です。

量が閾値を超えると、体制の形そのものが変わる

同じページには、量が一定を超えた場合の考え方も書かれています。

毎月1000SKU以上の撮影（3名以上の専任者）が必要となる場合は、自社内にスタジオを開設される方が効率的です。

外注単価を積み上げる話が、途中から自社の設備投資と人員配置の話へ変わるということです。これは値引き交渉では届かない領域で、経営判断そのものです。商品数がこのレンジに入るなら、見積書の1点単価を削る議論より先に、内製と外注のどちらが総額で安いかを検討する段階に来ています。

なお同ページには「※当社では、1回10万円程度のご依頼からお仕事を承っております」という最低受注金額の記載もあります。点数が少ないほうが1点単価は割高になりやすい、という逆方向の制約も同時に存在します。

商品数に比例しない費用｜同じ画面を1回作る

ECサイトの開発費の中で、商品数が変わってもほぼ動かないのは次の部分です。

• 商品一覧・商品詳細・カート・購入手続きの画面設計と実装
• 会員登録、マイページ、注文履歴
• 決済サービス・配送サービスとの連携
• クーポン、ポイント、セール価格などの販促ロジック
• 管理画面（受注管理、在庫管理、商品編集）
• デザイン、レスポンシブ対応、アクセシビリティ対応
• プロジェクト管理、要件定義、受け入れ支援

商品詳細ページは、10万点を扱うサイトでも1つのテンプレートです。100点でも1つです。点数が増えて増えるのは、そのテンプレートに流し込まれるデータの量であって、テンプレートの数ではありません。

この構造は、ECプラットフォームの提供側の値付けにも現れています。株式会社フューチャーショップのfutureshop Standardプランは登録商品数そのものが料金階層になっていますが（2026年8月24日取得。同ページに「表示価格は全て税抜価格です。別途消費税がかかります。」と明記）、50商品までのプランが月額27,000円、10,000商品までのプランが月額64,000円です。上限は200倍ですが、月額は約2.4倍（2.37倍）です。段階的には上がりますが、比例はしていません。ただしプラン名は登録商品数で区切られているものの、初期費用や画像ホスティングの容量など他の条件も同時に変わるため、この倍率のすべてが商品数によるものではありません。

各社の課金軸の違い（点数で階層化する事業者と、容量や受注件数を軸にする事業者）については、稼働後の費用を扱ったECサイトの保守費用は商品数で上がるのかで5サービスを比較しています。

見積書に戻すと、確認するのは1点です。その行の成果物は、点数で数が増えるものか。 画面・機能・連携の行が点数で増えているなら、増える理由を具体的に説明してもらってください。説明がつく場合もあります（次節）。つかない場合は、数量欄が単なる規模の代用として使われています。

階段状に効く費用｜レンジをまたぐと作り方が変わる

比例でも定額でもない、3つ目の型があります。ある閾値を越えると作り方が変わり、そこで工数が階段状に跳ねるものです。閾値は件数とは限らず、移行元の系統数や変換ルール数のこともあります。EC開発で典型的なのは次の6つです。

階段状であることは、発注側にとって悪い話ではありません。階段の位置が分かれば、そこを避ける設計判断ができるからです。「商品数が多いので検索は専用基盤を使います」という説明は、それ自体は妥当です。確認すべきは、何件を境にその判断をしたのか、その件数は自社の3年後の想定と合っているのかです。

ここで先ほどの「データ量増大率」（1倍／1.2倍／1.5倍／2倍／3倍／10倍以上）が効いてきます。現在の点数だけでなく、増大率まで合意しておけば、階段をまたぐタイミングを設計時に織り込めます。

見積書の行を3分類する早見表

ここまでを1枚にまとめます。自社の見積書の各行を、右端の「実際の課金軸」が埋まるかどうかで仕分けてください。埋まらない行が、確認すべき行です。

3つの型の意味をもう一度そろえておきます。比例するは、点数が増えた分だけ人の作業時間が増えるもの。階段状は、ある閾値（件数・系統数・ルール数など）を越えたときだけ作り方が変わり、そこで跳ねるもの。連動しないは、点数が何倍になっても成果物の数が変わらないものです。

この3つが同じ1行にまとまっている見積書は、金額の妥当性を判定できません。 これは高いという意味ではなく、判定材料が足りないという意味です。

その料金体系が合理的と言えるケース

商品数で費用が上がる見積もりが、正当である場合は具体的にあります。次のいずれかに当てはまり、かつその根拠が見積書または補足資料に書かれているなら、そこは説明済みとして扱ってかまいません。

1. 人が1点ずつ作る作業が含まれている。 撮影・採寸・原稿・データ入力は点数比例が自然です。むしろ点数比例でない見積もり（一式）のほうが、後で作業範囲の争いになります。

2. 現在のプラットフォームの登録上限を超える。 ASP型のサービスには登録商品数の上限があるものがあり、上限を超えると上位プランや別方式へ移る必要が生じます。この場合、商品数は構築方式の選択そのものを動かしています。

3. 検索や一覧の実装方式が、件数を理由に変わっている。 前節の階段です。何件を境に判断したかが示されていれば、説明済みです。

4. 移行元の系統数や変換ルールが、商品数の増加と一緒に増えている。 モールを追加した結果、移行元が3系統になった、というような場合です。増えているのは正確には件数ではなく系統数ですが、実務上は同時に起きます。

5. 商品情報の作成に、公開予定日までの日数では足りない量がある。 体制を厚くするか、期間を延ばすかの判断が必要になります。増員に対する費用増は正当です。

いずれの場合も、ベンダー側が「なぜ商品数がこの費目を動かすのか」を一文で説明できるなら、その行は判定できます。説明が「規模に応じて」で止まるなら、次節です。

確認が必要なケース｜4状態への仕分け

見積書の各行を、妥当か不当かの二択ではなく、次の4状態へ仕分けてください。二択で見ると、根拠が書かれていないだけの行まで「不当」に見えてしまいます。

高リスクの2つ目に注意してください。 商品数が多い案件で性能試験と移行リハーサルの行が無い見積書は、安く見えます。しかしその安さは、公開直後にサイトが重い・商品データが欠けるというリスクを、発注側が引き受けることで成立しています。詳しくは次節で扱います。

「商品数が多いのに安い」見積書のほうが危ないことがある

過大な見積もりだけを警戒すると、逆方向を見落とします。商品数が多い案件で削られやすいのは、次の4つです。

1. 性能試験。 非機能要求グレードの項目一覧では「性能テスト」という小項目名で（見積書では「性能試験」と書かれることが多い項目です）、測定頻度と確認範囲の2つのメトリクスが置かれています（B.4.2）。測定頻度のレベルは「測定しない／構築当初に測定／運用中、必要時に測定可能／運用中、定常的に測定」、確認範囲のレベルは「確認しない／一部の機能について、目標値を満たしていることを確認／全ての機能について、目標値を満たしていることを確認」です（列の対応は原本PDFの座標で確認しました）。

「測定しない」「確認しない」も選択肢として並んでいます。 つまりこれは、やるかやらないかを発注側が選ぶ項目です。商品数が多いのに見積書に性能試験の行が無いなら、選ばれなかった側になっている可能性があります。それが意図した選択なのかを確認してください。

2. 移行リハーサル。 同じくリハーサル回数のレベルは「リハーサル無し／1回／2回／3回／4回／5回以上」です。無しも選べます。商品データの移行は、失敗すると公開できないだけでなく、間違ったデータが公開されるという形でも失敗します。リハーサルの行が無い見積書は、1回きりの本番移行を前提にしています。

3. データ検証。 10,000点を投入したあと、それが正しく入ったかを誰がどう確認するのかは、見積書から抜けやすい行です。全件を目視できる量ではないので、抽出方法と合格基準を決める必要があります。この設計そのものが作業です。

4. プロジェクト管理と受け入れ支援。 商品数が多い案件では、ささげ・登録・移行・検証という並行作業が増え、関係者も社内の商品担当・撮影・物流へ広がります。にもかかわらず、点数連動の行が目立つ見積書ほど、これらを束ねるPM費と、発注側の受け入れテストを支援する行が薄くなりがちです。前掲の早見表のとおり、この2つは点数に連動しませんが、点数が増えると必要な期間と関係者の数のほうが増えます。行が無い場合は、誰がこの調整をする前提なのかを確認してください。

安い見積書を疑えという話ではありません。 削られた行があるなら、それが意図的な判断なのか、単に漏れているのかを分ける、という話です。前者なら発注側の判断として記録すればよく、後者なら後から追加費用として現れます。

同じ10,000点でも、見積書はここまで違う

3社から同じ要件で見積もりを取ったとき、商品数まわりの書かれ方は次のように分かれます。以下は実在する3社の見積書ではなく、書かれ方の違いを示すために作成した記入例です。 金額は入れていません。比較すべきは金額ではなく、何が確定しているかだからです。

A社が最も安く見えることは珍しくありません。 しかしA社の見積書からは、何が含まれ何が含まれていないかを読み取れません。C社は「対象外」と明記しているぶん、自社で手当てすべき範囲がはっきりしています。総額を比べる前に、この表の8行を全社ぶん埋めてください。埋まらない行があるなら、そこが質問になります。

複数社の見積もりを同じ条件へそろえる手順そのものは、開発費用の相場と見積もり妥当性の判断にまとめてあります。

ベンダーへそのまま送れる確認質問10

技術の知識がなくても送れる形にしてあります。金額の交渉ではなく、判定に必要な情報を集めるための質問です。

依頼メールの文面

件名：ECサイト構築お見積もりについての確認（商品数まわり）

お世話になっております。◯◯株式会社の◯◯です。

お送りいただいたお見積もりについて、社内で検討を進めるにあたり、
商品数に関連する下記10点を確認させてください。
金額の見直しをお願いするものではなく、前提をそろえたうえで
判断するための確認です。

下記のうち、既存の資料（機能一覧・項目定義書・移行計画等）で
カバーされているものがあれば、該当資料のご送付でも差し支えありません。
ご対応が可能な範囲と期日について、まずご教示いただけますと幸いです。

確認質問10（コピペしてそのまま使えます）

1. 見積書の数量欄「◯◯点」は、型（品番）・商品ページ・作業ピース（撮影と採寸の対象）・SKUのどの単位で数えた数字でしょうか。
2. 「初期商品登録」1件に含まれる作業範囲（入力項目数、画像枚数、原稿の有無、カテゴリ紐付けの有無）をご教示ください。
3. 撮影・採寸・原稿作成は、この見積もりに含まれますか。含まれない場合、どちらが実施する前提でしょうか。
4. 商品データの元データは、どの形式で、どちらが用意する前提でしょうか。現行サイトからの抽出作業は含まれますか。
5. データ移行で想定している変換ルールの本数と、移行元の系統数（自社サイト・モールなど）をご教示ください。
6. 移行リハーサルは何回、どの範囲（正常ケースのみか、切り戻しを含むか）で実施する計画でしょうか。
7. 投入したデータが正しいことは、誰がどの方法で確認しますか。全件確認か抽出確認か、合格基準は何かをご教示ください。
8. 商品検索・一覧表示は、何件・何項目を前提に設計されていますか。その件数を超えた場合、追加費用は発生しますか。
9. 性能試験は実施されますか。実施する場合、何件相当のデータで、どの機能を対象に測定されますか。
10. 商品情報の作成は1日あたり何点処理する前提でしょうか。そこから逆算した所要営業日数と、公開予定日との整合をご教示ください。

質問を絞りたい場合は、1・2・5・9・10の5問を優先してください。この5問だけで、数え方・作業範囲・移行の実体・過小見積もりの有無・スケジュールという、判断に必要な骨格が埋まります。

なお契約後の増減について確認したい場合は、「商品数が契約後に増減した場合、費用はどのように変わりますか。減った場合に下がる条件はありますか」を追加してください。増える方向の条項しかない見積もりは、数量連動というより値上げ条項に近い設計です。

回答をどう読むか

• 1と2に即答できるなら、その会社は作業量で見積もっています。単価の比較が意味を持ちます
• 1が「点数です」で止まるなら、数え方が確定していません。相見積もりの比較対象になりません
• 3と4が曖昧なら、撮影と元データ準備の作業が、どちらの手元にも置かれていない状態です。契約後に「そちらでご用意いただく前提でした」となりやすい典型です
• 5に「件数ベースでお答えします」と返るなら、変換ルール数が見積もられていません。移行費が件数×単価で置かれているので、系統数と形式の一致有無を聞き直してください
• 6が「本番で1回」なら、リハーサル無しの計画です。それが合意のうえでの選択なのか、単に漏れているのかを確認してください
• 7に「貴社にてご確認ください」と返るなら、検証は自社の作業です。何点を何人で何日かけて見るのかを、社内の計画へ入れてください
• 8と9が「問題ありません」で終わるなら、前提件数が置かれていない可能性があります。数字での回答を依頼してください
• 10に日数の回答が返ってこないなら、商品情報の作成が誰の計画にも入っていません。金額より先に手当てすべき箇所です

見積書のどの行を質問へ変換すればよいか整理しきれない場合は、ECサイトの開発見積書を行項目ごとに確認する（登録不要）もご利用ください。結果の閲覧までメールアドレスの入力は不要です。

開発時と稼働後で、商品数の効き方はどう変わるか

最後に、この記事の範囲を明示しておきます。ここまで扱ったのは構築時に一度だけ発生する費用です。稼働後の毎月の費用は、効き方が変わります。

開発時に1回で終わる作業が、稼働後の月額へ混ざっていないかは、公開後に必ず確認してください。この点はECサイトの保守費用は商品数で上がるのかで、単発作業と継続作業の見分け方として扱っています。

商品数だけでなく、画面数・店舗数・利用者数・連携本数でも、同じ「比例する／階段状／連動しない」の構造が現れます。数量で費用が段階的に上がる見積もりの読み方は、数量課金のシステム費用は妥当かで数量軸をまたいで整理しています。

根拠資料と適用条件

本記事で引用した公開情報は次のとおりです。価格や公開資料は改定されるため、実際の判断では取得日以降の最新情報を各発行元でご確認ください。

各社・各機関が公表した内容と、koromo編集部が整理した確認観点は区別して記載しています。前者は出典と取得日を明示し、後者は「確認観点」として提示しています。

あわせて、次の3点にご注意ください。

ECサイト開発費の「相場」は、本記事では示していません。 商品数と開発費の関係について、公的機関が公表した調査データを確認できなかったためです。検索結果に出てくる構築費用の平均額は、各社が自社の受注や紹介案件を集計したものであり、公的な相場ではありません。

引用した公開価格は、それぞれのサービスや事業者を推奨するものではありません。 費用を決めている変数が事業者ごとに違うことを示すために引用しています。

非機能要求グレードの項目を、そのままECサイトへ当てはめられるわけではありません。 同資料はシステム基盤の非機能要求を対象としており、モデルシステムの定義も一般的なECサイトを名指ししてはいません。本記事では「発注側とベンダーが何を合意すべきか」という項目の並びを参照しており、レベルの選択やベース値をECサイトの推奨値として扱ってはいません。

なお本記事は、法的・会計的・技術的な最終判断を提供するものではありません。契約解釈や費用の会計処理については、それぞれの専門家にご確認ください。

よくある質問