ECサイト構築の費用は？作り方別の目安と失敗しない進め方

「ネットショップ（ECサイト）を作りたいが、費用がピンからキリまでで分からない」——ECサイトの費用は作り方で大きく変わります。同じ「ECを作る」でも、月額数千円で今日から始められる方法もあれば、数百万円かけて独自に作り込む方法もあります。この記事では、3つの作り方それぞれの費用の目安・向き不向き・ランニングコスト、そして「作ったのに売れない」を避ける進め方まで、順を追って解説します。

ECサイトの費用は「作り方」で決まる

まず全体像をつかみましょう。ECの作り方は大きく3方式に分かれ、費用も桁が変わります。

作り方	初期費用の目安	月額の目安	特徴
ASP・カートSaaS（BASE・STORES・Shopify等）	0〜数万円	数千〜数万円	すぐ始められる・標準的
パッケージ利用・カスタマイズ	数十万〜数百万円	数万〜十数万円	ある程度の独自性に対応
フルスクラッチ（独自開発）	数百万円以上	サーバー・保守で数万〜	独自要件・連携に自由に対応

「初期費用が安い＝トータルで安い」とは限りません。ASPは初期が安い代わりに売上に応じた手数料がかかり、フルスクラッチは初期が高い代わりに月々の固定費を抑えやすい、という違いがあります。まず「何を・どれくらい・どう売るか」で、適した作り方が変わります。標準的な販売ならASPで十分なことが多いです。

3つの作り方の中身と費用相場

ASP・カートSaaS（既製サービス）

ネットショップ用のサービスに登録し、商品を登録すればすぐ売れる方式です。BASE・STORES・Shopify・カラーミーショップなどが該当します。

• 費用の目安：初期0〜数万円、月額0〜数万円。売上に応じた決済・システム手数料が別途かかる。
• メリット：最短即日で開店できる。決済・カート・スマホ表示が最初から用意されている。運用や保守を自分で抱えなくてよい。
• デメリット：デザインや機能がサービスの範囲に縛られる。独自の販売ルールや基幹連携は苦手。売上が伸びると手数料の総額が重くなる。

パッケージ（EC構築ソフト）のカスタマイズ

ECに必要な機能が一通り入った土台（パッケージ）を導入し、必要なところだけ作り替える方式です。

• 費用の目安：初期数十万〜数百万円、月額（保守・ライセンス）数万〜十数万円。
• メリット：ゼロから作るより安く早い。会員ランクや複雑な送料計算など、ある程度の独自要件に対応できる。
• デメリット：土台の作法に沿う必要があり、大きく外れる要件はかえって高くつくことがある。バージョンアップ対応が発生する。

フルスクラッチ（独自開発）

要件に合わせてゼロから作る方式です。自由度が最も高い代わりに、費用と期間もかかります。

• 費用の目安：数百万円以上。要件次第で大きく上下する。
• メリット：販売ルール・画面・外部システム連携を思い通りに設計できる。手数料や仕様の制約から自由になれる。
• デメリット：初期費用と開発期間が大きい。仕様が曖昧なまま進めると、追加費用で膨らみやすい。

方式別の向き・不向き早見表

こんな場合	向いている方式
まず小さく試したい／点数が少ない	ASP・カートSaaS
デザインや世界観にこだわりたい	Shopify等の柔軟なASP、またはパッケージ
会員ランク・定期購入など独自ルールがある	パッケージまたはフルスクラッチ
基幹システム・在庫・受発注と連携したい	フルスクラッチ
売上規模が大きく手数料負担を減らしたい	パッケージまたはフルスクラッチ

「まずASPで始め、事業が伸びて独自要件が出たら作り込む」という段階的な進め方も有効です。最初から全部を作り込む必要はありません。判断に迷ったら、次の3つの問いに答えてみてください。

• 今のこだわりは「見た目」か「仕組み」か：見た目中心なら柔軟なASP、仕組み（販売ルールや連携）中心なら開発寄り。
• 1年後に何点・月商いくらを見込むか：規模が小さいうちは既製サービス、伸びる見込みが強いほど独自化の投資が回収しやすい。
• 社内に運用できる人がいるか：運用体制が薄いなら、保守を抱え込まない既製サービスが無難。

ここを曖昧にしたまま「とりあえず立派なものを」と作ると、使わない機能に費用を払うことになりがちです。

ECサイトに必要な主な機能

見積りの前に、ECに何が必要かを把握しておくと、要件の絞り込みがしやすくなります。

• 商品・カタログ：商品登録、カテゴリ、検索、在庫表示、バリエーション（色・サイズ）。
• カート・注文：カート、注文確定、送料・手数料計算、クーポン。
• 決済：クレジットカード、コンビニ払い、代引き、QRコード決済、後払いなど。
• 会員・マイページ：会員登録、購入履歴、お気に入り、住所帳。
• 配送・在庫：配送方法の選択、伝票連携、在庫の引き当て。
• 管理・分析：受注管理、売上集計、メール配信、アクセス分析。

このうち「絶対に必要な機能」と「後から足せる機能」を分けるだけで、初期費用は大きく変わります。最初は核となる販売機能に絞り、会員ランクや高度な分析は運用しながら追加するのが定石です。

目安として、機能を「最初に要るもの」「後で足せるもの」に分けると次のようになります。

最初に要る（必須）	後で足せる（運用しながら）
商品登録・カート・決済・注文管理	会員ランク・ポイント
送料計算・基本的な在庫表示	定期購入・予約販売
問い合わせ・特定商取引法の表記	高度なレコメンド・分析
スマホ表示	多言語・多通貨対応

「あると便利」を最初から全部入れると、費用も期間も膨らみます。まずは注文が取れて出荷できる最小構成で公開し、売上のデータを見ながら投資先を決めるのが、費用対効果の高い進め方です。

見落としがちなランニングコストと連携の壁

ECは「作って終わり」ではなく、売れ続ける限り毎月コストがかかり、周辺システムとの連携が運用の成否を左右します。ここを甘く見ると後で誤算になります。

毎月かかるランニングコスト

初期費用だけで比較すると、後で「思ったより手元に残らない」となりがちです。

• 決済手数料：売上の3〜4%前後が目安。売れるほど総額が増える、いわば売上連動の固定費。
• サーバー・ドメイン：フルスクラッチなら月数千〜数万円。アクセスが増えると上がる。
• 保守・運用：不具合対応、セキュリティ更新、機能改修。外注する場合は月額または都度費用。
• 決済・外部サービスの月額：カートSaaSの月額、メール配信、レビュー機能などの追加ツール。

例：小規模なアパレルショップのケースでは、初期費用がほぼ0でも、月商が伸びるにつれ決済手数料が毎月の一番大きな出費になる、ということが起こります。**「初期いくら」より「月にいくら残るか」**で見るのが正しい比較の仕方です。

決済・物流・在庫の「連携」でつまずく

ECの難しさは、サイト単体ではなく周辺システムとのつながりにあります。ここを甘く見ると、注文は入るのに裏側が回らない、という事態になります。

• 決済連携：決済代行サービスとの接続。カード・後払い・QR決済など複数手段への対応。
• 物流・配送連携：配送業者の送り状発行、出荷通知、追跡番号の反映。
• 在庫連携：実店舗や他モールと在庫を共有する場合、二重販売を防ぐ仕組みが必要。
• 基幹・会計連携：受注データを在庫管理や会計に流し込む。手作業のままだと注文増で破綻する。

例：実店舗とネット販売を並行する小売店のケースでは、在庫連携がないと「店頭で売れた商品がネットでも売れてしまう」欠品トラブルが起きます。こうした連携要件があるほど、既製サービスの範囲を超え、パッケージやフルスクラッチが必要になります。

費用の考え方はシステム開発の費用相場もご覧ください。

「作っただけでは売れない」集客の壁

最も見落とされがちなのが、サイトを作ることと売れることは別だという点です。開店しても、お客さんが来なければ売上はゼロです。

• 集客の手段：検索（SEO）、SNS、広告、メール、モール併売など。どれも継続的な運用が要る。
• かかる費用：広告費、コンテンツ制作、写真撮影、運用の人件費。作った後にこそお金と手間がかかる。
• 改善の運用：アクセスや購入率を見て、商品ページや導線を直し続ける必要がある。

つまり、予算配分は「作る費用」だけでなく「集客・運用の費用」まで含めて考えるべきです。豪華なサイトを作り込んで予算を使い切り、集客にお金が回らず売れない——というのはありがちな失敗です。まずは必要十分な機能で作り、集客・改善に予算を残すほうが、多くの場合うまくいきます。

目安として、「作る費用」と「その後の集客・運用費用」を切り分けて考えると次のようになります。

• 立ち上げ期：まず商品を並べて注文を受けられる状態にする。ここで作り込みすぎない。
• 集客期：検索・SNS・広告で人を集める。写真や商品説明の質が売上を左右する。
• 改善期：アクセスや購入率のデータを見て、売れない原因を1つずつ潰す。

この3段階のどこにお金と時間を使うかは、事業のフェーズで変わります。開店直後にいきなり高機能なサイトが要ることはまれで、多くの場合は「そこそこの機能＋しっかりした集客」の組み合わせが費用対効果に優れます。

100万円で作れるECの範囲と一律料金という選択肢

独自要件のECサイトは費用が青天井になりがちですが、D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）。着手前に総額が確定するので、「まず核となる販売機能から」と範囲を決めて作れます。

100万円の範囲でも、たとえば次のような「核」から始められます。

• 商品カタログ・カート・決済・注文管理といった、販売に必須の一連の流れ。
• 自社の販売ルールに合わせた、既製サービスでは実現しづらい独自の画面や導線。
• まず1つの連携（例：決済または在庫のどちらか）に絞った、実務に耐える最小構成。

会員ランクや高度な分析、複数の外部連携などを最初から全部盛りにすると膨らむため、「今の事業に効く機能」から順に作るのがコツです。追加費用なしで総額が固定されるため、「作ってみたら想定外の請求が来た」というEC開発にありがちなリスクを避けられます。

一律料金の特徴を整理すると、次の点で予算が立てやすくなります。

• 着手前に総額が確定：見積りの積み上げで金額が動かないため、社内の予算承認が通しやすい。
• 追加費用なし：仕様の詰めで金額が膨らむ不安がなく、機能の優先順位に集中できる。
• 成果物の権利が自社に渡る：将来ほかの会社に引き継ぐときも、ソースコードを持っているので不利になりにくい。

「まず小さく作って、売れたら育てる」という進め方と、総額が固定される一律料金は相性が良い組み合わせです。100万円で作れる範囲は100万円で作れるものの具体例もご覧ください。

一般化ミニ事例：3つのパターンで見る費用感

作り方の違いを、よくある3つのケースでイメージしてみましょう（いずれも一般化した例です）。

• 例1：ハンドメイド作家が数十点を売るケース。まずはASP・カートSaaSで開店。初期費用ほぼ0、月額も数千円で始められ、売れた分だけ手数料。作ることより「知ってもらう」が課題なので、集客と写真に手をかけるのが正解。
• 例2：実店舗を持つ小売店がネット販売を始めるケース。店頭在庫との二重販売を避けたいので、在庫連携が論点。標準機能で足りなければパッケージのカスタマイズを検討し、初期数十万〜数百万円が目安。連携をどこまでやるかで費用が動く。
• 例3：独自の会員ランクや定期購入で売るサブスク型のケース。既製サービスの枠に収まりにくく、パッケージのカスタマイズやフルスクラッチが視野に入る。要件を絞れば、まず核の販売機能から一律料金で作る選択肢もある。

同じ「ECを作りたい」でも、売るものと運用の形で最適解はまったく変わります。自分がどのパターンに近いかを見極めることが、費用の無駄をなくす第一歩です。逆に言えば、他社の「これで作った」という事例をそのまま真似ても、自社の売り方や規模が違えば費用も向き不向きもずれます。まずは自社の条件を書き出し、それに合う方式を選ぶ順番が大切です。

見積りと選び方の最終チェック

作り方をひとつに決める前に、見積りの中身と自社の条件を突き合わせておくと、大きな判断ミスを防げます。

見積りを取るときに確認すべきこと

独自開発を検討する段階では、見積りの「安さ」だけでなく、次の点を必ず確認しましょう。ここが曖昧だと、後から追加費用で膨らみます。

• 総額が固定か、都度精算か：着手前に総額が確定していると予算が立てやすい。
• どこまでが基本料金の範囲か：決済・在庫・連携のどれが含まれ、どれが別料金か。
• 保守・運用の費用：公開後の不具合対応や更新が月いくらかかるか。
• 成果物の権利：ソースコードの権利が自社に渡るか（渡らないと将来の乗り換えで不利になる）。

これらは費用そのものと同じくらい重要です。詳しくはシステム開発の費用相場も参考にしてください。

失敗しないECの選び方チェックリスト

次の項目を確認しておくと、作り方の選択で大きな判断ミスを防げます。

• 何を・どれくらいの点数・どんな客層に売るかが言語化できているか。
• 独自の販売ルール（会員ランク・定期購入・特殊な送料など）があるか。
• 基幹システム・在庫・実店舗との連携が必要か。
• 初期費用だけでなく、月々のランニング（手数料・保守）まで試算したか。
• 集客・運用にかける予算を残しているか。
• 独自開発する場合、総額が着手前に固定される発注方式か。
• 成果物（ソースコード）の権利が自社に渡るか。

上から順に「はい」が多いほど既製サービスで足り、「独自ルール」「連携が必要」に該当するほど、パッケージやフルスクラッチの検討が現実的になります。

まとめ

ECサイトの費用は作り方次第で、ASPなら月額数千円〜、パッケージで数十万〜数百万円、独自開発なら数百万円以上が目安です。標準的な販売はASPで十分なことが多く、独自の販売ルールや連携が必要になったときに開発を検討しましょう。比較のポイントは「初期いくら」より「月にいくら残るか」、そして「作った後の集客・運用まで予算を残すこと」です。独自ECも要件を絞れば一律100万円で試せます。「うちのECはどう作るのが最適？」は無料相談で整理しましょう。