目次
ECプラットフォーム選定は経営判断である
なぜプラットフォーム選定で失敗するのか
ECサイト構築を決めた瞬間、多くの企業は同じ問題にぶつかります。Shopifyにするか、MakeShopか、それともEC-CUBEのようなオープンソース型EC で自社サーバーに構築するか。そのECプラットフォーム選定が後々の売上、運用コスト、技術的な負担を大きく左右することを、意思決定の時点では気付きにくいのです。
プラットフォーム選定の重要性
特に厳しいのは、この判断が一度決まると取り返しが難しいという現実です。ASP型ECで3年運用してから「やはりカスタマイズが必要だ」と気付いても、乗り換えには多大なコストと時間がかかります。
逆にオープンソース型ECで構築したものの、保守できるエンジニアが退職してしまい、機能改修が止まるという状況も珍しくありません。
株式会社猫の手が支援する企業の中でも、楽天やYahoo!ショッピングからの本店ECへの移行を検討する際に、このプラットフォーム選定で立ち止まるケースは非常に多くあります。決定基準が曖昧なまま進めてしまう企業ほど、後になって後悔することになるのです。
技術選定と運用リスクの分離理解
ECプラットフォーム選定で最も陥りやすい罠は、技術的なスペックと運用現実を分けて考えていないことです。
「EC-CUBEならカスタマイズできる」という技術的な自由度と、「実際にそのカスタマイズを継続的に保守できるか」という運用現実は全く別の問題です。同様に「Shopifyは管理画面が使いやすい」という利便性と、「3年後に複雑な注文フロー対応が必要になった時に対応できるか」という拡張性も分けて考える必要があります。
運用リスクの見落とし
この分離ができていないと、選定した時点の判断基準が運用段階では全く機能しなくなります。つまり、プラットフォーム選定は現在値ではなく、今後どの軌跡を描くのかを見通した判断でなければならないということです。
ASP型ECとオープンソース型ECの本質的な違い
ASP型ECプラットフォームの特性
ASP型EC（SaaS型EC）とは、ベンダーが提供するクラウドサービスを利用するECサイト構築モデルです。ShopifyやMakeShop、カラーミーなどがこれに該当します。
ASP型ECの最大の特徴は、初期投資が低く、運用負荷が最小化されることです。サーバー管理、セキュリティパッチの適用、インフラのスケーリング、これらすべてがベンダーの責任になります。そのため、Web担当者が一人もいない中小企業でも、ECサイト構築から運用を開始できるのです。
ただし、この利便性の裏側には制約があります。標準機能の範囲内でのECサイト運用を余儀なくされるというのが、ASP型ECの本質的な限界です。MakeShopの場合、複数条件を組み合わせた絞り込み検索（産地×価格帯×品種など）が標準機能では実装できません。これは、ワイン販売、食品販売、アパレルといった属性の多い商品を扱うショップでは深刻な機能不足になります。
検索機能の重要性
検索機能が弱いECサイトでは、ユーザーが目的の商品にたどり着けず、離脱率が高まり、CVRの低下に直結するのです。
オープンソース型ECプラットフォームの特性
EC-CUBEをはじめとするオープンソース型ECは、ソースコードが公開されており、企業が自社のサーバーに構築・カスタマイズするECサイト構築モデルです。
オープンソース型ECの最大の利点は、カスタマイズの自由度が無制限ということです。複数条件検索、複雑な注文フロー、既存システムとの連携、こうした要件をすべて実装可能です。3年後に「注文時に顧客属性に応じた動的な送料計算が必要」という要件が出ても、エンジニアがいれば対応できるのです。
しかし、この自由度には継続的な技術的負担が付随します。セキュリティパッチの適用、インフラのスケーリング対応、アップデートに伴う動作確認、これらを企業側で実施する必要があります。特に深刻なのは、ECサイト構築したエンジニアが退職した後の保守です。ソースコードの品質が低ければ、新しいエンジニアが状況を理解するのに数週間かかることも珍しくありません。
表面的な違いではなく構造を理解する
ASP型ECとオープンソース型ECの違いは、単なる「カスタマイズできる・できない」ではありません。本質的な違いは、運用の責任範囲です。
責任範囲の理解
ASP型ECを選ぶということは、「ベンダーの設計判断を受け入れ、その枠組みの中で最大限の工夫をする」という経営判断です。一方、オープンソース型ECを選ぶということは、「全ての責任を自社で負う代わりに、完全なコントロール権を得る」という経営判断です。
この構造の違いが理解できていないと、ASP型ECで「こんな機能が必要だ」と後悔したり、オープンソース型ECで「こんなに保守に手がかかるなら、ASP型ECにしておけば良かった」と後悔することになるのです。
プラットフォーム比較における5つの判断基準
初期投資と継続投資のバランス
プラットフォーム比較の最初の判断軸は、費用構造です。
ASP型ECの場合、初期費用は数万円から数十万円で、毎月の月額費用が発生します。MakeShopの場合、標準プランで月額6,000円から、エンタープライズプランで月額50,000円を超える場合もあります。
一方、オープンソース型ECの場合、初期構築費用が数百万円から数千万円になることも珍しくありません。ただし、毎月の定額費用が発生しないため、長期的には投資を回収できる可能性があります。
費用比較のポイント
判断基準は、3年間の総コストで比較することです。ASP型ECで月10万円なら36ヶ月で360万円。オープンソース型ECで初期費用500万円なら、3年間でオープンソース型ECが高くなります。しかし、4年目以降を考えると、初期費用がないASP型ECの継続費用が続く一方、オープンソース型ECは保守費用のみで済む可能性があります。
カスタマイズの自由度と保守性
次の判断軸は、カスタマイズ要件がどの程度あるかということです。
「複数条件検索が必要」「既存システムとのデータ連携が必須」「顧客ランク別の動的価格設定が必要」──こうした要件があるなら、オープンソース型ECの検討が必須になります。
しかし同時に、そのカスタマイズを保守し続ける技術体制があるかという現実も見つめる必要があります。専任のエンジニアがいない企業がオープンソース型ECで複数条件検索を実装しても、1年後に「検索がちょっと遅い」という問題が出たとき、解決できる人がいないという状況に陥るのです。
スケーラビリティと将来の成長対応
ECサイトは、成長に伴って負荷が急増する事業です。月間300万円の売上のときと、月間3,000万円のときでは、システムに求められるスペックが変わります。
ASP型ECの場合、基本的にはベンダーがインフラをスケールしてくれるため、この心配が少なくなります。ただし、プランの上限に達すると、より高いプランへのアップグレードが必要になり、月額費用が大幅に上がることもあります。
オープンソース型ECの場合、サーバーのスケーリングは企業の責任です。月間PVが100万から500万に増えた時点で、サーバーリソースを拡張する必要があり、その判断と実施には専門知識が必須です。
判断基準は「3年後の想定売上」です。年間売上が1億円以上に成長する見込みなら、スケーラビリティを重視した設計が必須です。
セキュリティと技術的負債
ECサイトは顧客の決済情報を扱うため、セキュリティは企業の信頼に直結する要素です。
ASP型ECの場合、PCI-DSS（決済カード業界のセキュリティ基準）への準拠はベンダーの責任です。一方、オープンソース型ECで自社サーバーに構築する場合、セキュリティパッチの適用、ファイアウォール設定、定期的なセキュリティ監査を自社で実施する必要があります。
技術的負債の危険性
さらに怖いのが、技術的負債の蓄積です。初期構築時に「とりあえず動く」という基準で実装したコードが、3年後には改修が困難な状態になっているということは珍しくありません。このような状態で新機能を追加しようとすると、既存の脆弱性が露呈し、セキュリティインシデントの運用リスクが高まるのです。
運用人員と専門性の確保可能性
最後で最も重要な判断軸は、運用チームの成熟度です。
オープンソース型ECを選ぶということは、エンジニアの継続的な関与が前提です。専任のバックエンド開発者がいない企業、あるいは現在はいてもその人物への依存度が高い企業では、オープンソース型ECは実質的に選択肢になりません。
一方、ASP型ECであれば、ショップ運用の知識が主軸になります。ただし、MakeShopやShopifyの管理画面で「なぜこの動作をするのか」という理解を深めるには、それなりの学習期間が必要です。
判断基準は、「今後3年間、その技術を理解・保守できるチームがいるか」という現実的な問いです。
実際のECサイト構築事例から学ぶ判断軸
ASP型ECが最適な業種・規模
ASP型ECが最適なのは、以下の条件に当てはまる企業です。
- Web担当者が1～2名程度で、専任のエンジニアがいない
- 初期投資を最小限に抑えたい
- 標準機能の範囲で事業が成立する
- 運用の手間を最小化したい
実例として、食品メーカーが楽天からの本店ECサイト構築への移行を検討する場合を考えてみます。商品カテゴリが比較的シンプル（○○系商品、△△系商品など）で、複数条件検索が必須要件でないなら、MakeShopで十分対応可能です。
このケースでは、初期費用を抑え、月額費用でECサイト運用を開始し、3ヶ月間はSEOやコンテンツ充実に注力する方が、時間とコストの効率が良いのです。
オープンソース型ECが最適な業種・規模
オープンソース型ECが最適なのは、以下の条件に当てはまる企業です。
- 複雑なカスタマイズ要件がある（複数条件検索、動的価格計算など）
- 既存システムとのデータ連携が必須
- 長期的な成長見込みが高く、5年以上の継続運用が前提
- 専任のエンジニアがいる、あるいは外部パートナーとの継続的な関係構築が可能
複雑な商品属性への対応
例えば、ワイン販売やアパレルのようなショップでは、商品属性が多岐にわたります。ワインなら「ぶどう品種×産地×ヴィンテージ×価格帯」、アパレルなら「サイズ×色×素材×価格帯」という複数軸での絞り込みが必須です。ASP型ECの標準機能では対応できないため、EC-CUBEなどのオープンソース型ECで、独自の検索システムをカスタム開発するのが現実的です。
株式会社猫の手がワイン販売の企業を支援した際も、MakeShopの標準検索では複数条件の絞り込みが実装できないため、MakeShop APIと連携した独自の検索システムをカスタム開発しました。このアプローチにより、ユーザーが目的のワインに素早くたどり着け、CVRが向上し、最終的に売上が大幅に増加したのです。
ハイブリッド型の選択肢
実は、ASP型ECとオープンソース型ECのどちらかを選ぶ必要はないというケースも多くあります。
例えば、MakeShopをメインプラットフォームとしながら、MakeShop APIを活用した独自アプリでECサイト機能を拡張するというハイブリッド型です。このアプローチなら、MakeShopの安定した基盤を活かしながら、複雑なカスタマイズ要件にも対応できます。
MakeShop標準では難しい複数条件検索も、独自開発のアプリケーションなら実装可能です。月額費用は0円で、初期開発費用のみの負担になるため、ASP型ECの継続費用と比較しても合理的です。
このハイブリッド型が機能するのは、開発パートナーが継続的にサポートできる体制を持っているときです。
プラットフォーム選定後の運用リスク回避
ベンダーロックインの構造と対策
ECプラットフォーム選定で覚悟する必要があるのが、ベンダーロックインです。特にASP型ECでは顕著です。
MakeShopで3年間運用してきたショップのデータ（商品情報、顧客情報、注文履歴）は、MakeShopのシステムに最適化された形式で保存されています。これを別のプラットフォームに移行しようとすると、データの形式変換、機能の再構築、URLの変更（SEOへのダメージ）など、多大なコストと時間がかかるのです。
データ移行対策
対策としては、データの出力可能性を確認することです。選定段階で、「顧客データ、商品データ、注文履歴を、標準的な形式（CSV、JSON）で出力できるか」を確認しておくことが重要です。
また、URLの構造を自社でコントロールすることも対策になります。プラットフォームがURLを自動生成する仕様だと、プラットフォーム変更時に全ページのURL変更を余儀なくされ、SEO評価が大幅に下がるリスクがあります。
技術的負債の蓄積メカニズム
オープンソース型ECで特に注意が必要なのが、技術的負債の蓄積です。
初期構築から2年経つと、以下のような状況が発生します。初期開発を担当したエンジニアがプロジェクトから外れた。既存のコード品質が低く、新機能の追加時に予期しない動作が発生する。セキュリティパッチの適用を検討しても、更新後の動作確認に膨大な時間がかかる。
こうした状況に陥ると、企業は選択肢を失います。現状維持するしかないのです。結果的に3年後、セキュリティが脆弱なままECサイト運用を続けることになります。
技術的負債への対策
対策は、定期的なコード品質の評価と改善です。毎年1回、「現在のコード状態が新機能追加に対応できるか」を診断する。必要に応じてリファクタリングする。こうした定期的な投資がなければ、技術的負債は指数関数的に蓄積されるのです。
運用チームの成熟度と機能の相互作用
選定したECプラットフォームが機能するかは、運用チームの成熟度に左右されるという現実があります。
例えば、Shopifyを導入したとします。管理画面は直感的で、Web担当者一人でも基本的なECサイト運用は可能です。しかし「GA4で直帰率を見たら、商品詳細ページが50%になっていた」という事態が発生した時、その原因を特定し、改善案を実装できるかは別問題です。
Shopifyなら、テンプレートのカスタマイズやApp Store経由で機能を追加できますが、これらの施策が適切か判断するには、一定の知識が必要です。運用チームがEコマースの知識を持つまでには、通常3ヶ月から6ヶ月の学習期間が必要なのです。
プラットフォーム比較の段階では、このチーム育成の時間を見込む必要があります。
選択後も対応できるカスタマイズ戦略
標準機能の限界を早期に把握する
ECサイト運用開始後、「このような機能が必要」という要件は次々と出てきます。重要なのは、その要件が標準機能で対応可能か、カスタマイズが必須かを早期に判断することです。
MakeShopの場合、複数条件を組み合わせた絞り込み検索は標準機能では実装不可です。ただし、一つの軸での絞り込み（例：価格帯のみ）なら標準機能で対応できます。
「複数条件検索が絶対必要」と判定した時点で、早めにカスタマイズ開発を検討すべきです。1年後に判定するより、3ヶ月で判定して早期に開発を始める方が、コスト効率が良いのです。
柔軟なシステム拡張の設計思想
ASP型ECプラットフォームでカスタマイズするなら、プラットフォーム本体への改変は最小限にという設計思想が重要です。
拡張性を重視した設計
具体的には、MakeShop APIを活用した外部アプリケーションの開発に注力すべきです。こうすることで、MakeShop本体がバージョンアップしても、外部アプリはその影響を受けにくくなります。
例えば、複数条件検索は独立した外部アプリとして開発し、MakeShopのAPI経由でデータを取得・処理する設計です。このアプローチなら、検索アプリの改修が必要になっても、MakeShopの管理画面に影響を与えません。
複数条件検索など売上に直結する機能の実装判断
カスタマイズ開発には費用がかかります。そこで重要なのが、「その機能開発に投資する価値があるか」の判断です。
複数条件検索の場合、商品点数が100件未満なら、ユーザーはスクロールして目的商品を探せます。ただし、商品点数が1,000件を超えるなら、複数条件検索がないと離脱率が50%を超える可能性があります。
判断基準として、以下を検討すべきです。
| 商品点数 | 推定離脱率（複数条件検索なし） | 判定 |
| 100件以下 | 10%以下 | 不要 |
| 300～500件 | 20～30% | 検討段階 |
| 1,000件以上 | 40%以上 | 必須 |
ワイン販売や食品販売のように属性が多い商品カテゴリなら、商品点数が500件で既に複数条件検索が必須になります。一方、シンプルなカテゴリ分けで済む業種なら、1,000件でも検索が不要な場合もあります。
プラットフォーム選定で失敗する企業の共通パターン
技術スペックで判断してしまう罠
失敗する企業の多くは、「Shopifyはカスタマイズできる」「EC-CUBEなら完全自由」という技術的な特性だけでプラットフォーム比較をしてしまいます。
技術と現実のギャップ
しかし、技術的にできることと、実際に自社で実施できることは別です。EC-CUBEで「複雑な注文フロー対応」が技術的に可能でも、実装するエンジニアがいなければ意味がありません。
失敗パターン：オープンソース型ECでECサイト構築したが、6ヶ月後にセキュリティパッチが必要になった時点で、対応できるエンジニアがいないことに気付き、外部パートナーに数百万円の保守費用を請求されるというケースです。
運用体制を無視した選定
ECプラットフォーム選定時に、実際のECサイト運用体制を想定していない企業も多いです。
例えば、「Shopifyなら管理画面が簡単」という理由で選んだものの、現実には月間500万円の売上に対して、Web担当者は0.5名（兼任）という状況です。この場合、毎日のオーダー対応や在庫管理で手一杯になり、SEO対策やマーケティング施策を実行する余力がなくなります。
結果として、「ECサイトを作ったが売上が伸びない」という状態に陥るのです。これはプラットフォームの問題ではなく、運用体制の計画不足です。
将来の成長を想定しない決定
「今は小さいから、安価なASP型ECで十分」と判断し、5年後に年間10億円の売上を目指す企業のケースもあります。
リプラットフォームの負担
その時点で「複数条件検索が必須」「注文処理の自動化が必要」といった要件が出ても、当初選定したASP型ECでは対応できず、全面的なリプラットフォームを強いられるのです。
リプラットフォームには数百万円の費用と半年以上の期間がかかります。その間のアクセスロストやSEO評価の低下も考慮すると、初期段階でのECプラットフォーム選定ミスは極めて大きいのです。
結論：プラットフォーム選定は現在値ではなく軌跡で判断する
ECプラットフォーム選定とは、今後5年間のECサイトの成長軌跡を見通したうえで、その軌跡に最も適切なプラットフォームを選ぶことです。
プラットフォーム選定の本質
つまり、ECプラットフォーム選定は、技術的な判断ではなく経営的な判断だということです。
選定の段階では以下の問いに向き合う必要があります。
- 3年後の想定売上は？
- そのとき、どのような機能が必須か？
- その機能実装を自社で対応できるか？
- 継続的にそれを保守・改善する技術体制があるか？
- 5年後の選択肢を残せるか？
ASP型ECが常に正解ではありません。オープンソース型ECが常に正解でもありません。重要なのは、自社の成長軌跡に沿ったECプラットフォーム選定であり、選定後も軌跡の変化に対応できる柔軟性を持つことです。
複数条件検索が売上に直結する場合は、MakeShop APIを活用した独自アプリ開発によるハイブリッド型も選択肢になります。初期開発費のみで月額費用が発生しないため、長期的には最適な投資になる可能性も高いのです。
成功するプラットフォーム選定の鍵
ECプラットフォーム選定で失敗しないためには、現在のスペックで判断するのではなく、5年間の成長シナリオを描き、その軌跡に対して「どのプラットフォームなら柔軟に対応できるか」を問うべきなのです。
お客様の成功事例
年商2億円の製造業様における基幹システム連携強化プロジェクト
課題：既存のECサイトと基幹システムの連携が不十分で、在庫管理や受注処理に大幅な工数がかかっていました。また、事業拡大に伴い、より柔軟なカスタマイズが求められる状況でした。
施策：オープンソース型プラットフォームを採用し、既存の基幹システムとの連携を強化。在庫の自動同期機能と受注処理の自動化を実装しました。さらに、将来の事業展開を見据えた拡張性の高い設計を行いました。
結果：受注処理時間を70%削減し、在庫管理の精度が大幅に向上。システム運用にかかる人的コストを月間約40時間削減することができました。また、新商品展開時のサイト更新作業も内製化により迅速に対応できるようになりました。
月商500万円のBtoB卸売業様における販売チャネル拡大事例
課題：従来の電話・FAX中心の受注体制から脱却し、オンラインでの取引を本格化したいという要望がありました。しかし、取引先ごとの価格設定や与信管理など、BtoB特有の複雑な要件への対応が必要でした。
施策：ASP型プラットフォームをベースに、BtoB向けの機能を重点的にカスタマイズ。取引先別価格設定、与信枠管理、承認フロー機能を実装し、既存の顧客管理システムとの連携も行いました。
結果：オンライン経由の受注が全体の60%まで拡大し、受注処理の効率化により営業担当者がより戦略的な業務に集中できるようになりました。新規取引先の開拓にも成功し、導入から1年で売上が25%向上しました。
この記事をシェアする
この記事を書いたのは・・・
猫の手 web部門
株式会社猫の手のweb製作部門です！のECサイトに関するおすすめ情報やWEB製作に関する情報を発信していきます。makeshopやカラーミー、shopifyやeccubeなどECサイトのサービス情報も発信していきます。
