ECサイト/システム開発の保守・運用費用・ランニングコストについて

ECサイト／システムは、構築して公開した瞬間がゴールではなく、むしろ「公開してから」が本当のスタートです。商品を売り続け、売上を伸ばし、顧客との関係を育てていくためには、サイトを24時間365日安定稼働させ、決済・在庫・会員・受注物流の連携を止めずに維持し続ける継続的な保守・運用が欠かせません。ECサイトはカートが常時動き、その裏側で決済代行・在庫管理・配送・会員データが連動する「売上に直結するシステム」です。サーバーが落ちれば即座に機会損失が発生し、決済が止まれば顧客は離脱し、脆弱性を放置すればクレジットカード情報の漏えいという致命的な事故につながります。そのためECサイト／システムの保守・運用費用とランニングコストの設計は、単なる「維持費」ではなく、売上・利益・顧客からの信頼を守るための重要な経営判断です。「毎月いくらかかるのか」「保守費用には何が含まれるのか」「決済手数料や販売手数料はどれくらい利益を圧迫するのか」といった疑問は、EC運営に関わる誰もが避けて通れないテーマと言えます。

本記事では、ECサイト／システム開発の保守・運用費用・ランニングコストに焦点を当て、カートASP／SaaS・オープンソース・パッケージ・フルスクラッチという4つの構築手法別の保守コスト構造の違い、モール出店と自社ECで異なる手数料構造、規模別（月商別）の月額保守費用の相場、EC固有のコスト内訳（決済代行手数料・販売手数料・セキュリティ・商品登録運用など）、保守契約の形態、そして利益率を意識したランニングコスト最適化までを、具体的な金額とともに体系的に解説します。これからECサイトを立ち上げる方はもちろん、すでに運営していて「思ったより毎月のコストがかさむ」と悩む方、リプレイスやプラットフォーム乗り換えを検討している方にとっても、現実的な予算計画と利益設計を立てるための判断材料が得られる内容です。最後までお読みいただくことで、ECサイト／システムの総所有コストを正しく見積もり、利益の残るコスト構造を設計するための視点が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・ECサイト／システム開発の完全ガイド

ECサイト／システムの保守・運用費用の全体像

ECサイト／システムの保守・運用費用を理解するうえで、まず押さえておくべき最大のポイントは、「どの構築手法で作ったECか」「モールに出店するのか自社ECで持つのか」によって、毎月のコスト構造が根本から変わるという事実です。ECの構築手法は大きく、カートASP／SaaS（Shopifyやmakeshopなど）、オープンソース（EC-CUBEやWooCommerceなど）、パッケージ（ecbeingなど）、フルスクラッチ（完全オーダーメイド開発）の4つに分けられます。同じ「ECの保守」と言っても、この4つでは毎月誰が何にお金を払うのかがまったく異なります。一般的なシステム保守では初期開発費の年間15%程度が保守費の目安とされますが、ECの場合はこの人的保守費に加えて、決済手数料や販売手数料といった「売上に比例して増えるランニングコスト」が大きな比重を占める点が、他のシステムと決定的に違う特徴です。つまりECのコストは「固定費」だけでなく「売上連動の変動費」を含めて総合的に捉える必要があります。

具体的な相場感を整理すると、カートASP／SaaSは初期0〜数十万円・月額0〜数万円と手軽な反面、サーバー保守はサービス提供側が担うためインフラの心配は不要ですが、売上が伸びるほど決済・販売手数料が利益を圧迫します。オープンソースは初期50万〜300万円・月額数万円〜で、ライセンス無償でカスタマイズ性が高い一方、サーバーやセキュリティ、バージョンアップを自社で管理する責任が生じます。パッケージは初期300万〜3,000万円・月額5万〜30万円程度で、基幹連携や業種別機能の実績が豊富です。フルスクラッチは初期数千万〜数億円・月額数十万〜数百万円規模となり、自由度は最大ですが、インフラ設計・24時間365日の監視・脆弱性対応をすべて自社または保守ベンダーが担うため、総所有コスト（TCO）が格段に大きくなります。本記事では、この4手法の構造と「モール対自社EC」の手数料構造を軸に、ECならではの保守・運用費用とランニングコストの全体像を分解していきます。

カートASP／SaaSで構築したECの最大の利点は、サーバーの保守・運用、システムのバージョンアップ、セキュリティパッチの適用といった「技術的な保守」をすべてサービス提供側が代行してくれる点にあります。Shopifyやmakeshop、BASE、STORESといったプラットフォームでは、運営者はサーバーダウンや脆弱性対応をほとんど気にする必要がなく、商品登録や受注処理といった「運用」に集中できます。月額利用料も数千円〜数万円と予算化しやすく、初期費用も抑えられるため、立ち上げ期や中小規模のEC事業者に最適です。ただし注意すべきは、技術的な保守が不要になる代わりに、決済手数料や販売手数料といった売上連動コストがサービス側に支払われる構造になっている点です。月商が小さいうちは負担も小さいですが、売上が拡大すると手数料の絶対額が膨らみ、「保守は楽だが利益が残りにくい」という状態に陥ることがあります。

一方、オープンソース・パッケージ・フルスクラッチで構築したECは、システムを自社の資産として保有する代わりに、保守・運用の責任もすべて自社側に移ります。サーバーやインフラを独自に設計・維持し、脆弱性が発見されればパッチを当て、決済代行会社やモール・基幹システムとの連携を保ち続ける必要があります。とくにフルスクラッチは、ゼロから構築するためインフラの冗長化やセキュリティ設計を一から行わなければならず、24時間365日の監視体制を含めると保守・運用のTCOが格段に大きくなります。パッケージはその中間で、ベンダーが標準機能とセキュリティを手厚く提供する分、保守サポート費が月額固定でかかるのが一般的です。その代わり、決済手段の選択や手数料交渉の自由度が高く、売上規模が大きくなるほど「自前で持つ」ことのコストメリットが効いてくるという逆転の構造があります。どの手法が自社にとって合理的かは、現在の月商と将来の成長見通しによって変わるため、保守コストは構築手法の選定段階から設計しておくことが重要です。

もう一つ、構築手法を選ぶ際に保守・運用費用の観点から見落とされがちなのが、ベンダーロックインと将来の乗り換えコストです。カートASP／SaaSは手軽に始められる反面、そのプラットフォームの仕様や手数料体系に縛られ、後から別のサービスへ移行しようとすると、商品データ・顧客データ・受注履歴の移行に手間とコストがかかります。逆にフルスクラッチはソースコードを完全に自社所有できるためベンダーロックインを回避できますが、特定の開発会社しか中身を把握していない「属人化したブラックボックス」になると、その会社からしか保守を受けられず、結果的に別の形のロックインに陥ることがあります。実務的には「まずSaaSやパッケージで標準機能を試し、標準で詰まる独自要件が明確になってからフルスクラッチへ段階的に移行する」のが現実解とされます。保守・運用コストを長期的に抑えるには、データのエクスポート性や仕様のドキュメント化といった「いざというときに乗り換えられる柔軟性」も評価軸に入れて、構築手法と保守体制を選ぶことが将来の選択肢を狭めないために重要です。

ECのランニングコストを語るうえで、構築手法と並んで重要なのが「モールに出店するのか、自社ECとして持つのか」という出店形態の違いです。Amazon・楽天市場・Yahoo!ショッピングといったモールは、すでに巨大な集客力と決済インフラを備えており、初期費用は無料〜10万円程度で即座に販売を開始できるのが最大の魅力です。しかしその対価として、売上に対して数%〜十数%の販売手数料（ロイヤリティ）に加え、ポイント原資の負担、モール内広告費、月額出店料などが課されます。自社ECの決済手数料（3〜5%）と比べると、モールの総手数料負担は重くなる傾向があり、これが利益率を継続的に圧迫します。さらに、モールはデザインのカスタマイズ性が低くブランドの世界観を出しにくいうえ、顧客データが自社資産になりにくいため、CRMやリピート施策が打ちにくいという構造的なデメリットもあります。

一方、自社ECは独自ドメインで設計の自由度が高く、ブランドを確立しやすいうえ、顧客データを自社で蓄積してCRM・ファンマーケティングに活用できるため、中長期の利益率を高く保てます。半面、立ち上げ当初は集客力がゼロからのスタートとなり、SEO・SNS・広告に時間とコストを投じる必要があります。この集客コストもまた、見えにくいながら確実に発生するランニングコストです。実務的には「モールで売上を作りつつ、自社ECでブランドと顧客資産を育てる」という併用が定石とされます。ランニングコストの観点では、モールは手数料が高い代わりに集客コストが低く、自社ECは手数料が低い代わりに集客コストが高い、というトレードオフを理解することが鍵です。チャネルごとに手数料込みの利益率を比較し、「モールで新規顧客を獲得し、リピートは手数料の低い自社ECへ誘導する」といったチャネル設計を行うことで、EC全体のコスト効率を最適化できます。出店形態の選択は、保守費そのものよりも手数料という変動費を通じて、利益構造に長期的な影響を与えます。

ECのランニングコストを正しく管理するには、「固定費」と「売上連動の変動費」を明確に分けて捉えることが欠かせません。固定費とは、売上の多寡にかかわらず毎月一定額が発生するコストで、プラットフォームの月額利用料、サーバー・インフラ費用、保守契約費、各種SaaSやアプリの利用料などが含まれます。これらは予算化しやすく、月初の段階で「今月いくらかかるか」が読めるコストです。対して変動費は、売上が増えるほど比例して増えるコストで、ECの代表格が決済代行手数料（売上の3〜5%程度）、モールやプラットフォームの販売手数料、システム利用料（1〜3%程度）、そして物流・梱包費です。これらは売上が伸びれば伸びるほど絶対額が膨らむため、「売上が増えているのに利益が増えない」という事態を引き起こす元凶になりがちです。ECのコスト管理は、まずこの2種類のコストを仕分けるところから始まります。

この固定費と変動費の比率は、ECの成長ステージによって最適なバランスが変わります。立ち上げ期で月商が小さいうちは、固定費を極力抑えて変動費中心にする（=ASP／SaaSやモールで手数料を払う）方が、リスクを抑えて始められます。一方、月商が数百万円を超えて安定してくると、変動費である手数料の絶対額が固定費を上回り、「月額固定の有料プランやオープンソース・パッケージに乗り換えて、手数料率を下げた方が手元に利益が残る」という損益分岐点が訪れます。EC運営の保守・運用コストを考えるうえでは、この損益分岐点を常に意識し、自社が今どのステージにいて、どちらのコスト構造が有利なのかを定期的に見直すことが、利益を最大化する鍵になります。後述する規模別の相場やコスト内訳も、この「固定費と変動費」の視点で読み解いていくと理解が深まります。

もう一つ、ECの保守・運用費用を考えるうえで欠かせない視点が、初期構築費用と保守・運用費用を切り離さず「5年間の総所有コスト（TCO）」で比較するという考え方です。たとえば、初期費用が安いカートASP／SaaSやモールは導入のハードルが低い一方、売上が拡大すると決済・販売手数料が積み上がり、5年スパンで見ると手数料の累計が初期構築費用をはるかに上回ることがあります。逆に、初期費用が高いパッケージやフルスクラッチは最初の投資こそ大きいものの、決済手段や手数料を自社でコントロールできるため、売上規模が大きければ5年TCOで見て有利になるケースもあります。「初期費用が安いから」「月額が安いから」という単年・単月の判断ではなく、自社の成長見通しを織り込んだ5年TCOで構築手法と出店形態、保守体制を選ぶことが、長期的にムダのないコスト構造を実現する鍵になります。EC事業は数年単位で成長するものだからこそ、保守・運用コストもその時間軸で設計する視点が求められます。

規模別に見る月額保守・運用費用の相場

ECサイト／システムの月額保守・運用費用は、月商（売上規模）によって大きく変わります。ここでは小規模・中規模・大規模の3つに分けて、それぞれの相場感とコストの主体がどこにあるのかを見ていきます。重要なのは、規模によって「保守費用の主役」が変わるという点です。小規模では決済手数料が費用の中心、中規模ではプラットフォーム月額と機能拡張、大規模ではセキュリティと基幹連携の保守が主役になります。また規模が上がるにつれて、採用される構築手法もASP／SaaSからオープンソース、パッケージ、フルスクラッチへと移っていく傾向があります。自社の月商がどのレンジにあるかを踏まえて、適切なコスト水準を把握しましょう。

月商100万円未満の小規模ECの月額保守・運用費用は、0円〜数万円程度が一般的な相場です。この規模では、BASEやSTORESといった無料または低価格のカートASP／SaaS、あるいはモール出店を利用するケースが中心で、サーバー保守やシステムのバージョンアップはサービス側が担うため、純粋な「システム保守費」はほとんど発生しません。代わりに費用の主体となるのが決済手数料・販売手数料です。たとえば売上の3.6%〜6.6%程度が決済・サービス利用手数料として差し引かれるため、月商50万円であれば月2万〜3万円程度が手数料として消えていく計算になります。つまり小規模ECでは「保守費はほぼゼロだが、売れた分だけ手数料がかかる」というコスト構造になっており、固定費の負担が小さい代わりに、利益率は手数料率に大きく左右されます。在庫リスクと同様に、コストリスクも売上に連動して小さく抑えられるのがこの段階の特徴です。

小規模ECの段階では、初期投資と固定費を抑えてスモールスタートできることが最大のメリットです。商品が売れなければ手数料も発生しないため、コストリスクを小さく抑えながら市場の反応を見られます。ただし注意したいのは、売上が伸びてきたときに手数料の負担が急に重く感じられるようになる点です。月商が100万円に近づくと、決済・販売手数料の絶対額が月数万円に達し、「もっと手数料率の低い有料プランやプラットフォームに乗り換えた方が得ではないか」という検討が必要になります。小規模ECの運営者は、目先の固定費の安さだけでなく、売上が伸びたときの手数料負担まで見据えて、早めに次のステージのコスト構造を試算しておくことが賢明です。とくにモール一本で始めた場合は、リピート顧客が増えてきた段階で自社ECへの誘導を検討すると、手数料負担を圧縮しやすくなります。

月商数百万〜数千万円の中規模ECの月額保守・運用費用は、数万円〜数十万円程度が相場です。この規模になると、有料のカートASP（Shopifyの上位プランやmakeshopなど）やオープンソース（EC-CUBE・WooCommerce）を採用するケースが増え、プラットフォームの月額固定費に加えて、機能を拡張するためのアプリ・プラグイン利用料、サーバー・インフラの維持費、そして軽微な保守対応の費用が積み上がっていきます。たとえば、プラットフォーム月額が数万円、レビュー機能や定期購入機能などの拡張アプリが合計で月数万円、サーバー維持費が月数万円、保守サポートが月数万円〜十数万円といった具合に、複数の費目が合算されて月額数十万円規模に達するのが典型的なパターンです。決済手数料も売上に比例して増えるため、月商が大きくなるほど手数料の絶対額が無視できない水準になります。

中規模ECで特に注意すべきは、「気づかないうちにアプリ・オプションの月額が膨らんでいる」というコストの肥大化です。便利だからと拡張アプリを次々に追加していくと、一つひとつは月数千円でも、合計すると月数万円〜十数万円に膨れ上がります。また、オープンソースを採用している場合は、サーバーやシステムのセキュリティ対応・バージョンアップを自社または保守ベンダーが担う必要があり、ここで月額固定の保守契約（後述）を結ぶケースが一般的です。中規模ECは「売上は伸びているのに、コストも一緒に膨らんで利益が思うように残らない」という壁にぶつかりやすいステージでもあります。費目ごとにコストを棚卸しし、本当に必要な機能・サービスだけに絞り込む定期的な見直しが、利益を確保するうえで効果的です。あわせて、この段階は構築手法の見直し（手数料の高いASPから自社資産型のオープンソースへの移行など）を検討する好機でもあります。

月商数千万〜数億円の大規模ECの月額保守・運用費用は、数十万円〜数百万円以上に達します。この規模では、パッケージ（ecbeingなど）やフルスクラッチで構築された独自性の高いECが中心となり、保守・運用の内容も格段に高度になります。具体的には、高度なセキュリティ対策と脆弱性対応、基幹システムや在庫管理システム・物流システム（ERP／WMS）との連携保守、定期的なバージョンアップ、そして専任の運用体制の維持といった項目が費用の主役になります。大規模ECはサイトの停止が即座に多額の機会損失につながるため、24時間365日の監視体制や障害発生時の即時対応（高いSLA水準）が求められ、その分だけ保守費用も高くなります。月額数百万円という金額は一見高額に見えますが、月商数億円のビジネスを止めないための「保険」として合理的な投資と位置づけられます。

大規模ECの保守費用を考えるうえで重要なのは、サービスレベル（SLA）によって費用が数倍変わるという点です。「24時間365日の障害対応・即時復旧」を求めるか、「平日日中のみの対応」で十分かによって、必要な人員体制とコストはまったく異なります。また、大規模ECではフルスクラッチゆえにインフラを独自設計しているケースが多く、サーバーの冗長化やオートスケーリング、CDN、WAF（Web Application Firewall）といったインフラコストが月額で大きな比重を占めます。さらに、セール時や繁忙期にはアクセスが平常時の数倍〜数十倍に跳ね上がるため、その負荷に耐えるためのサーバー増強コストも織り込む必要があります。加えて、複数倉庫やオムニチャネル（OMO）対応で実店舗POSと在庫をリアルタイム連携している場合は、その連携基盤の保守も大きな費目になります。大規模ECは、保守費用を「コスト」ではなく「売上を守り、伸ばすための投資」として捉え、SLAと費用のバランスを事業規模に見合った水準で設計することが求められます。

ECサイト／システム固有のコスト内訳と売上比例コスト

「月額いくら」という保守費用が提示されたとき、その金額に何が含まれ、別途どんなコストが発生するのかを理解しておくことは、ECの利益設計に不可欠です。ECサイト／システムのランニングコストは、システム利用料・サーバー／インフラといった固定費に加えて、決済代行手数料（3〜5%）、システム利用料（1〜3%）、販売手数料、アプリ／オプション費、セキュリティ・脆弱性対応費、商品登録・コンテンツ運用費、保守サポート費といった多様な費目で構成されます。とくにECならではの「売上に比例して増えるコスト」と「セキュリティ・物流に関わるコスト」は、他のWebシステムにはない特徴であり、利益を圧迫する大きな要因です。ここでは、EC特有のコスト内訳を具体的に分解していきます。

コスト内訳を見ていく前に押さえておきたいのが、初期構築費用と運用費用は密接に連動しているという点です。「初期費用を安く抑えること」だけを優先して構築すると、かえって運用フェーズの保守費用が高くつくケースが少なくありません。たとえば、安く作るために拡張性を犠牲にした構成にすると、後から機能を追加するたびに割高な改修費が発生したり、セキュリティ設計が不十分なまま運用に入って後追いで対策費がかさんだりします。また、受注・物流・基幹システムとの連携仕様を要件定義の段階で詰めきれていないと、稼働後に二重入力や連携エラーが発生し、それを是正する追加開発が運用フェーズに重くのしかかります。逆に、初期段階で運用を見据えた設計（保守しやすい構造、適切なセキュリティ、無理のない技術選定、連携仕様の作り込み）に投資しておけば、運用フェーズのコストを継続的に抑えられます。つまりECのコストは、初期費用と運用費用を切り分けるのではなく、「初期にどこへ投資すれば運用が楽になるか」という連動の視点で捉えることが、トータルでムダのないコスト構造を実現する前提になります。以下では、その運用フェーズで発生する具体的な費目を一つずつ見ていきます。

ECのランニングコストで最も大きな比重を占めるのが、決済代行手数料と販売手数料という「売上比例コスト」です。決済代行手数料は、クレジットカードやコンビニ決済、後払い、QRコード決済などの決済手段を利用する際に決済代行会社へ支払う手数料で、一般的に売上の3〜5%程度が目安です。これに加えて、プラットフォームによっては売上の1〜3%程度のシステム利用料や、モール出店の場合は数%〜十数%の販売手数料が発生します。たとえば月商1,000万円のECで決済手数料が3.5%なら月35万円、これにシステム利用料2%が加われば月20万円が、毎月売上から自動的に差し引かれていく計算です。これらは売上が伸びるほど絶対額が膨らむため、利益率の設計において決定的な影響を持ちます。さらにBtoB-ECでは掛け払い・請求書払い、越境ECでは多通貨決済など、扱う決済手段が増えるほど手数料体系も複雑になる点に注意が必要です。

注意すべきは、これらの手数料率は決済手段やプラットフォーム、契約内容によって大きく異なり、わずか数%の差が年間で見ると数十万円〜数百万円の差になる点です。たとえば決済手数料が3.5%か4.5%かの1%の差は、月商1,000万円なら月10万円・年間120万円の差です。手数料率は「固定で変えられないもの」と思い込まれがちですが、実際には売上規模に応じた料率交渉や、より手数料率の低い決済サービスへの切り替え、銀行振込など低手数料の決済手段の併用によって最適化できる余地があります。後述するShopifyペイメントのように、プラットフォーム純正の決済を使うことで外部決済の追加手数料（0.5〜2.0%程度）を免除できる仕組みもあります。決済・販売手数料は「EC最大のランニングコスト」として、定期的に料率を見直すことが利益確保に直結します。

また、決済まわりのコストは手数料率だけでなく、入金サイクルやチャージバック（不正利用による返金）といった見えにくい要素も含めて評価する必要があります。決済代行会社によって売上金が振り込まれるまでの入金サイクルは異なり、サイクルが長いほど運転資金の確保が必要になるため、実質的なコストとして効いてきます。さらに、複数の決済手段を提供すること自体は、カゴ落ち（決済直前の離脱）を防いで売上を取りこぼさないために重要ですが、決済手段を増やすほど管理する手数料体系も複雑になります。クレジットカード、コンビニ決済、後払い、QRコード決済、キャリア決済など、自社の客層がよく使う決済手段に絞りつつ、それぞれの手数料率と入金条件を一覧で把握しておくことが、決済コストを「見える化」して最適化する第一歩になります。決済は売上の入り口であると同時に、最大のコスト発生源でもあるという二面性を意識しましょう。

自社ECサイトと並行して楽天市場やAmazon、Yahoo!ショッピングといったモールに出店している場合は、モールの販売手数料も大きなランニングコストになります。モールの手数料体系はプラットフォームごとに異なりますが、売上に対して数%〜十数%の販売手数料に加えて、ポイント原資の負担、広告費、月額出店料などが課されるのが一般的で、自社ECの決済手数料（3〜5%）と比べると総コスト負担は重くなる傾向があります。モールは集客力が高く新規顧客を獲得しやすいという大きなメリットがある一方、手数料が利益を圧迫しやすいため、「モールで新規顧客を獲得し、リピートは手数料の低い自社ECへ誘導する」といったチャネル設計が、EC全体のコスト効率を高めるうえで有効です。自社ECとモールそれぞれの手数料込みの利益率を比較し、チャネルごとのコスト構造を把握したうえで販売戦略を組み立てることが重要です。

ECサイト／システムは顧客のクレジットカード情報や個人情報を扱うため、セキュリティ・脆弱性対応のコストが他のWebシステム以上に重要です。とくに近年はクレジットカードの不正利用が深刻化しており、EC運営者には不正利用対策が事実上義務化されています。具体的には、本人認証サービスであるEMV 3-Dセキュア（3Dセキュア2.0）の導入、不正検知システム（不正注文をスコアリングして検出する仕組み）の利用、クレジットカード番号の非保持化、そしてPCI DSS（クレジットカード業界のセキュリティ基準）への準拠、脆弱性診断の定期実施などが求められます。これらの対策にはツールの利用料（月額数千円〜数万円）や脆弱性診断の費用（年数十万円〜）がかかりますが、もし対策を怠ってカード情報漏えいやチャージバックが発生すれば、損害賠償や信頼失墜という比較にならないほど大きな損失を招きます。セキュリティ費用は「削ってはいけないランニングコスト」として確実に確保すべき項目です。

もう一つECに特有のコストが、セール時や繁忙期のサーバー増強費用です。ECサイトはセール、新商品発売、テレビやSNSでの紹介などをきっかけに、平常時の数倍〜数十倍のアクセスが瞬間的に集中することがあります。この負荷に耐えられないと、最も売れるタイミングでサイトが落ちて大きな機会損失を招くため、繁忙期に合わせてサーバーをスケールアップ（増強）したり、オートスケーリングやCDNを活用したりするコストが発生します。クラウド環境であれば必要なときだけ増強して繁忙期後に縮小するという柔軟な運用が可能ですが、それでも繁忙期の月はインフラ費用が跳ね上がります。とくに年末商戦や大型セールの時期は、性能・負荷設計の良し悪しが売上を直接左右するため、平常時から余裕を持った構成と監視体制を整えておくことが重要です。これらEC固有のコストを保守費用と一体で捉えることが、現実的な予算管理につながります。

ECのランニングコストで見落とされがちなのが、商品登録・コンテンツ運用にかかる人的コストです。ECは商品を「売る」ために、商品画像の撮影・加工、説明文の作成、特集ページやキャンペーンページの更新、新商品の登録といった「攻めの運用」を継続的に行う必要があります。これらは直接システム保守費には含まれないものの、売上を作るための重要な運用工数であり、社内で内製するにせよ外注するにせよ、確実に発生するコストです。とくに商品点数（SKU）が多いECや、季節商材・トレンド商材を扱うECでは、商品の入れ替えやページ更新の頻度が高く、この運用コストが大きな比重を占めます。AIレコメンドや検索機能を活かすにも、土台となる商品データ（属性・説明・画像）の整備が前提となるため、データ整備の工数も含めて見積もる必要があります。

物流・梱包費も、ECビジネスを継続するうえで売上に比例して必ず発生するコストであり、利益率に直結します。具体的には、配送料（宅配便の単価）、梱包資材費（段ボール・緩衝材・テープなど）、倉庫保管費、ピッキング・梱包の人件費（または物流アウトソーシングのフィー）が含まれます。物流をアウトソーシング（3PL）する場合は、保管料・入出庫料・配送代行料がかかりますが、自社で抱える人件費や倉庫コストと比較してトータルで判断する必要があります。さらに、BtoC通販では一定割合の返品が必ず発生し、返品時の往復送料、検品・再梱包・再入庫の人件費、再販売できない商品の損失が、地味ながら利益を削っていきます。商品説明やサイズ表記の充実によって返品そのものを減らす取り組みも、広い意味でのランニングコスト最適化につながります。

このほかにも、ECサイトには「見落とされがちな隠れたランニングコスト」が数多く存在します。たとえば、エラー監視ツール、CDN、メール配信サービス、CRM／MAツール、レビュー機能、チャットサポートツールといった各種SaaSの月額利用料は、一つひとつは数千円〜数万円でも合算すると月数万円〜数十万円規模になります。また、ユーザー数や送信通数に応じて課金が増えるサービスは、売上拡大とともにコストも膨らみます。保守契約を結ぶ際には、これらの外部サービス費用が保守費に含まれるのか、別途実費負担なのかを必ず確認しましょう。ECサイト／システムの総所有コストを正確に把握するには、(1)システム保守費、(2)インフラ費、(3)決済・販売手数料、(4)物流・梱包費、(5)各種SaaS・運用費の5つをすべて合算して評価することが欠かせません。この全体像を持つことが、利益の残るEC運営の出発点になります。

保守契約の形態とランニングコスト最適化

ECサイト／システムの保守費用は、開発会社や運用代行会社とどのような契約形態を結ぶかによっても変わります。とくにオープンソースやフルスクラッチで構築したECは、保守・運用を自社だけで賄うのが難しく、外部のパートナーと保守契約を結ぶのが一般的です。代表的な契約形態は、月額固定型・スポット（都度）型・成果報酬／複合型の3つです。そして契約形態を選んだうえで、プラットフォームの見直しや決済手数料の最適化、アプリ・物流コストの精査、利益率管理といった継続的なコスト最適化を回していくことが、利益の残るEC運営の決め手になります。ここでは、契約形態の選び方と、ランニングコストを抑えて利益を残す具体的な方法をあわせて解説します。

月額固定型は、「毎月一定額で保守・運用対応を行う」という契約で、ECの保守契約として最も一般的な形態です。費用の目安は月額数万円〜30万円程度で、対応内容によって幅があります。バグ修正やシステムの軽微な改修、セキュリティ対応、定期的なバージョンアップといった「技術的な保守」を含むものから、商品登録・受注処理・問い合わせ対応・特集ページ更新といった「運用代行」までを含むものまで、契約によって範囲が異なります。月額が一定で予算化しやすく、毎月安定して対応してもらえる安心感があるため、常時稼働が前提で継続的に改修・運用が発生するECに向いています。選ぶ際のポイントは、契約に含まれる対応範囲（スコープ）と稼働時間、そして障害発生時の対応時間（平日日中のみか、24時間365日か）というサービスレベルを明確にしておくことです。ECは深夜や休日にも注文が入るため、売上規模が大きいほど対応時間の長さが重要になりますが、その分費用も上がります。

スポット型（都度見積もり）は、「不具合が起きたときだけ」「OSやシステムのアップデートが必要なときだけ」必要が生じた都度に依頼して費用を支払う契約です。とくにEC-CUBEなどのオープンソースで構築したECで、脆弱性対応・不具合修正が発生したときに都度見積もりで対応するケースに多く見られます。平常時のランニングコストを抑えられるのが最大のメリットですが、緊急時に対応が後回しにされたり、繁忙期のトラブルで割高な費用を請求されたりするリスクがあります。一方、成果報酬／複合型は、「売上の5〜10%」を保守・運用費として支払う成果報酬型や、「月額固定＋売上の数%」を組み合わせた複合型で、運用代行会社が売上拡大にコミットする形態です。運用パートナーと事業者の利害が一致しやすい反面、売上が大きくなるほど支払額も膨らみます。立ち上げ期は成果報酬や月額固定で伴走してもらい、運用が安定してきたら一部を内製化してスポット型に切り替えるなど、成長ステージに応じて契約形態と内製化の比率を定期的に見直す柔軟さが、コスト最適化につながります。

最も効果が大きいコスト最適化策の一つが、トータルコストの観点からのプラットフォーム見直しです。ECのコストは「月額固定費」と「売上連動の手数料」のバランスで決まるため、売上規模に応じて最適なプラットフォームは変わります。たとえば、立ち上げ期は無料・低価格のASPやモールで手数料率が高めでも問題ありませんが、月商が50万〜100万円を超えてくると、月額固定費を払ってでも手数料率の低い有料ASPやオープンソースに乗り換えた方が、トータルでは手元に残る利益が増えるという損益分岐点が訪れます。手数料率が1%下がるだけでも、月商1,000万円なら年間120万円のコスト削減になります。自社の月商と手数料の絶対額を定期的に計算し、「今のプラットフォーム・出店形態が本当に最適か」を見直すことが、利益を最大化する第一歩です。あわせて、モールへの依存度が高い場合は、自社ECへの送客比率を高めて手数料負担を圧縮する施策も検討に値します。

決済手数料の最適化も、EC最大のランニングコストである手数料に直接効く施策です。具体的には、決済手数料の低い決済手段（銀行振込など）を選択肢に加える、売上規模に応じて決済代行会社に料率交渉を行う、といった方法があります。とくに効果的なのが、プラットフォーム純正の決済サービスを使うことです。たとえばShopifyでは、Shopifyペイメント（純正決済）を利用すると、外部決済サービスを使った場合にかかる追加の取引手数料（0.5〜2.0%程度）が免除されます。この差は売上が大きいほど無視できない金額になります。複数の決済手段を提供することはカゴ落ち防止のために重要ですが、それぞれの手数料率を把握し、純正決済や低手数料の手段を優先的に案内することで、決済コストを抑えながら売上を伸ばすことが可能です。さらに、固定費の削減には、アプリ・プラグインの厳選と公式テーマの活用も効果的です。使っていないアプリを定期的に棚卸しして解約するだけで月数万円規模の削減につながり、公式テーマを活用すればデザインの初期費用と改修費用を大きく抑えられます。物流コストも、配送会社との単価交渉や梱包資材の見直しで継続的に圧縮できます。

ECのランニングコストを利益の観点から管理する指針として有効なのが、「3:3:4の法則」です。これは、ECの売上を、原価（仕入れ・製造コスト）30%、広告・販促費30%、その他経費＋利益40%という比率で配分するという、利益設計の目安となる考え方です。この法則に照らすと、これまで述べてきたシステム保守費・決済手数料・物流費・各種SaaS費用といったランニングコストは「その他経費」に含まれ、この40%の枠の中で利益を確保できるかどうかが、ECビジネスの健全性を左右します。もし各種ランニングコストが膨らんで「その他経費」が肥大化すれば、利益はほとんど残らなくなってしまいます。逆に言えば、コストを最適化してこの枠を圧縮できれば、その分が利益に直結します。構築手法・出店形態の選定から日々の運用コストの精査まで、すべてはこの利益配分のバランスを保つための取り組みと言えます。

重要なのは、この3:3:4という比率を定期的にチェックし、自社のECがバランスを崩していないかをモニタリングすることです。たとえば、広告費をかけて売上を伸ばしても、決済手数料・物流費・SaaS費用といったランニングコストが一緒に膨らんでいては、売上が増えても利益が増えないという状態に陥ります。月次で売上に対する各コストの比率を可視化し、「決済手数料が想定より高い」「アプリ費が膨らんでいる」「物流費の比率が上がっている」「モール手数料が利益を圧迫している」といった異常を早期に発見して手を打つことが、利益を守るうえで欠かせません。ECサイト／システムの保守・運用コストは、単に「安くする」のではなく、売上と利益のバランスの中で「適正化する」という視点で捉えることが、持続的に利益を生むEC運営の本質です。この利益率目線でのコスト管理こそが、ランニングコスト最適化の最終的なゴールと言えます。

まとめ

本記事では、ECサイト／システム開発の保守・運用費用・ランニングコストについて、4つの構築手法別のコスト構造、モールと自社ECの手数料構造の違い、規模別の月額相場、EC固有のコスト内訳、保守契約の形態、そして利益を残すためのコスト最適化までを体系的に解説しました。ECの保守・運用費用は、カートASP／SaaS・オープンソース・パッケージ・フルスクラッチという構築手法と、モール出店か自社ECかという出店形態によって「誰が何に払うか」が根本から変わります。月額相場は、小規模（月商100万円未満）で0円〜数万円、中規模（月商数百万〜数千万円）で数万円〜数十万円、大規模（月商数千万〜数億円）で数十万円〜数百万円以上が目安です。ECならではの特徴は、決済代行手数料（3〜5%）・販売手数料・物流費といった「売上に比例して増える変動費」が利益を大きく左右する点にあります。これに加えて、クレジットカード不正利用対策（EMV 3-DセキュアやPCI DSS準拠等）や繁忙期のサーバー増強、商品登録・コンテンツ運用といったEC固有のコストも織り込む必要があります。

コストを抑えて利益を残すには、売上規模に応じたプラットフォーム・出店形態の見直し、Shopifyペイメントのような純正決済の活用による決済手数料の最適化、アプリの厳選と公式テーマの活用、外注費・物流コストの精査が有効です。そして最終的には、「3:3:4の法則（原価30%・広告販促30%・その他経費＋利益40%）」を指針に、システム保守費・手数料・物流費といったランニングコストを利益率の観点から管理することが、持続的に利益を生むEC運営の鍵となります。ECサイト／システムの保守・運用コストは、単なる「維持費」ではなく、売上と利益を守り伸ばすための投資です。固定費と変動費を分けて把握し、5つのコスト（システム保守費・インフラ費・決済／販売手数料・物流費・各種SaaS／運用費）を合算した総所有コストで評価することから、利益の残るコスト設計を始めましょう。保守費用やリプレイス・プラットフォーム乗り換えのコスト試算は、複数の開発・運用会社に自社の現状を共有して見積もりを取ることから着手するのがおすすめです。

▼全体ガイドの記事
・ECサイト／システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。