EC-CUBEは、ネットショップの構築に使う日本発のECシステムです。オープンソース版は無料でダウンロードでき、商品や注文の管理などの基本機能を土台に、自社向けの機能を追加できます。ただし、本体が無料であることと、サイトの構築・運営を無料で行えることは同じではありません。
導入を検討する際は、必要なカスタマイズ、開発を担当する人、公開後の保守まで含めて判断する必要があります。本記事では、EC-CUBEの特徴、提供形態、主な機能、費用の考え方と導入手順を解説します。2026年10月16日時点で確認した公式情報をもとに、古い料金情報やクラウド版の受付状況にも注意しながら、選定時の確認点を整理します。
自社ECの構築や運営の見直しを検討している方は、FORCE-Rへご相談ください。
| 確認したいポイント | 結論 | 詳細 |
| EC-CUBEとは？ | 販売業務に合わせて構築するEC基盤 | 基本機能を土台に、プラグインや独自開発で機能や画面を拡張します。 |
| 提供形態の違いは？ | 導入方法と保守・契約範囲が異なる | OSS、クラウド、Enterpriseを区別。クラウド版の公式ページは新規受付停止を案内しています。 |
| 費用で確認することは？ | 構築・運用・将来の更新まで見積もる | 本体が無料でも、開発、サーバー、保守、決済などの費用が必要です。 |
Contents
EC-CUBEとは？自社の販売業務に合わせて構築するECシステム
EC-CUBEは、株式会社イーシーキューブが提供するECサイト構築システムです。オープンソース版ではプログラムのソースコードが公開されており、基本機能を利用しながら独自の機能や画面を開発できます。商品、会員、注文などの仕組みを一から作らずに、自社の販売サイトを構築するための土台として使います。
たとえば、標準的な商品販売に加え、独自の注文項目や、既存の業務システムとつながる処理を必要とする場合に検討できます。用意されたサービスの設定だけで運営する方法と比べ、変更する範囲を広く考えられる一方、設計と開発、運用の負担も引き受ける必要があります。
公式のオープンソース版紹介では、消費者向けや法人向けなど、さまざまな販売の基盤として案内されています。業種の名前だけで適性を決めるのではなく、どの取引をどのように扱いたいかを整理することが大切です。実現したい機能が標準で備わるのか、追加開発が必要なのかを区別しましょう。
オープンソースと無料の範囲
無料なのは、本体をダウンロードして利用できる仕組みであり、構築作業や保守の費用まで含む意味ではありません。オープンソース版は自社で用意したサーバーなどにインストールして使います。商品やデザインの準備に加え、稼働環境の設定、決済の契約、動作確認なども必要です。
公式の製品説明では、無償のGPLライセンスと有償の商用ライセンスを選ぶ方式が案内されています。自社で利用する範囲や、開発成果物の扱いに関わるため、構築を依頼する際は採用するライセンスを確認します。有料の商用ライセンスがあることと、ネットショップで商品を販売する事業者が必ずそれを購入することは、同じ意味ではありません。
開発を外部へ依頼する場合は、本体の利用料がなくても制作費が発生します。独自の機能を増やすほど、設計や検証の作業も増えます。無料という言葉だけを他サービスとの比較材料にせず、公開までに必要な費用と、公開後も継続して発生する費用を分けて把握しましょう。
SaaS型カートと比較するときの見方
比較する軸は、変更できる範囲と、その変更を維持するための体制です。SaaS型では、提供された機能や外部アプリを組み合わせて運営する形が一般的です。EC-CUBEのオープンソース版では、コードを含めて独自の設計を検討できますが、変更した内容を継続して管理する必要があります。
すべてを自社仕様に変えれば使いやすくなるとは限りません。既存の仕事に不要な工程があるなら、システムへそのまま移す前に業務を見直すほうがよい場合もあります。標準機能で対応する部分と、事業上の理由から独自に作る部分を分けることが、費用や保守の負担を抑える判断につながります。
オープンソース版・クラウド版・Enterpriseを区別する
EC-CUBEという名称だけで、料金と保守範囲を一括りにしないことが重要です。自社側で稼働環境を用意するオープンソース版、クラウド型として紹介されるec-cube.co、企業向けの上位パッケージでは、導入の方法や契約する内容が異なります。検討する提供形態を先に確定させましょう。
インターネット上の記事には、以前のクラウドプランや古いバージョンの説明も残っています。記事の更新日だけで最新の申込条件と判断せず、公式の案内と照合する必要があります。見積もりや開発の相談でも、どの提供形態とバージョンを前提にしているかを明示します。
オープンソース版は環境と保守を用意する
オープンソース版では、サーバーや保守を自社または委託先で手配します。公式ダウンロード案内は、自社サーバーやレンタルサーバーへインストールする利用方法を示し、セキュリティチェックシートの確認を求めています。インストールできることだけで、本番運営の準備が終わるわけではありません。
運営に必要な環境は、商品数だけでなく、画像の量、注文数、外部連携、アクセスの集中などで変わります。通常時に表示できても、セールで多数の訪問者が来たときに処理が遅くなる場合があります。想定する販売規模と繁忙時の条件を示し、適切な環境と監視方法を相談することが必要です。
クラウド版の新規受付状況に注意する
2026年10月16日に確認した公式クラウド版紹介ページには、新規登録受付停止中と記載されています。同ページに料金や機能の説明が残っていても、その条件で新規に申し込めるとは考えないようにしましょう。新規利用を検討する場合は、提供元へ受付状況と利用できる選択肢を確認する必要があります。
クラウド版は、サーバーの保守やメンテナンスの負担を抑える提供形態として紹介されています。ただし、クラウドであることを理由に、独自に追加した機能や外部連携、日々の情報管理もすべて任せられるとは限りません。契約する場合は、提供元、制作会社、自社がそれぞれ担当する範囲を確認します。
既存利用者が移行やプラン変更を考える場合も、新規の受付と同じ条件とは限りません。現在の契約、利用しているバージョン、追加機能、運用上の問題を提示して相談します。古い解説記事の低価格プランを、現在も選べる通常の選択肢として予算へ組み込まないことが大切です。
Enterpriseは上位パッケージとして確認する
EC-CUBE Enterpriseは、オープンソース版を土台に企業向けの機能や構成を加えた上位パッケージです。公式Enterprise案内では、セキュリティ、性能、可用性などの要件や、業界ごとの機能を含む製品として紹介されています。無料の本体へすべて同じ機能が標準搭載されているという意味ではありません。
複雑な法人取引や、大規模な販売、複数のシステムが関わる運営を検討する場合は、必要な条件を提示して相談します。機能の名前だけではなく、取引先別の条件、承認の順序、データの管理先などを説明できると、標準部分と個別開発の範囲を確認しやすくなります。費用と支援内容も、個別の提案で照合しましょう。
必要な機能と運営上の課題を整理したい方は、FORCE-Rへお問い合わせください。
主な機能は標準・プラグイン・個別開発に分けて確認する
必要な機能を三つの実現方法に分けると、費用と保守を見積もりやすくなります。標準機能で足りるもの、プラグインで補うもの、独自に開発するものを整理します。追加できる仕組みがあることと、すべてが追加作業なしで使えることを混同しないようにしましょう。
公式の機能一覧には、構築・デザイン、カート・会員、商品、店舗管理などの項目が掲載されています。ただし、採用するバージョンや提供形態によって確認が必要です。導入事例で見た機能が、その店舗向けに個別開発されたものという場合もあるため、標準で使えるかを改めて確認します。
商品・カート・受注管理の基本機能
商品を登録し、注文を受け、出荷まで処理できるかを実際の条件で確かめます。商品名、説明、画像、価格だけでなく、色やサイズなどの規格、販売できる数量、配送条件を当てはめます。通常商品と、管理が複雑な商品の両方で試すことが大切です。
購入者の画面では、商品を選択してから、配送先や支払方法を指定し、注文を完了するまでを確認します。運営側では、注文内容、入金や決済の状態、出荷の対象、発送後の連絡を見ます。単に注文が作られるかだけでなく、担当者が処理状況を判断できるかが運用の確認点です。
商品コードや規格の管理では、倉庫や基幹システムとの関係も考えます。販売画面で一商品に見えるセットでも、倉庫では複数の品物を扱う場合があります。どの単位で在庫を減らし、どの情報を出荷指示に使うかを明確にしておくと、後から個別の修正を増やさずに設計しやすくなります。セットの取消時に各商品の在庫をどう戻すかも、同じ例で確認します。
プラグインと決済サービス
プラグインは、対応バージョンと組み合わせまで確認して選びます。公式オーナーズストアでは、決済、販促、物流・在庫、デザインなどの追加機能が紹介されています。同じ目的のプラグインでも、料金、更新状況、対応環境、提供元の支援内容が異なるため、機能の説明だけで決めないことが必要です。
複数のプラグインが同じ画面や処理に関わる場合、組み合わせによる検証が重要です。一つずつ正常に動いても、同時に利用したときや、本体を更新したときの動作まで保証されるとは限りません。必要な機能を選んだ段階で、制作会社に組み合わせの確認と更新時の対応方針を相談しましょう。
決済では、プラグインの導入と、決済代行会社との契約を分けて確認します。公式の決済サービス一覧で候補を調べ、手数料、審査、入金、取消・返金の操作を照合します。プラグインを追加すればすべての支払方法を直ちに使えるわけではなく、利用する契約や商材の条件にも確認が必要です。
独自の注文方法やシステム連携
個別開発は、既存機能では満たせない条件と、その理由を明確にして依頼します。たとえば、取引先ごとに注文できる商品を変える、特別な入力項目を持つ、社内の承認を経て注文を確定するといった条件です。似た機能名があっても、自社で必要な処理の順番に合うかを確かめます。
既存システムとつなぐ場合は、どこで商品、価格、会員、在庫を管理するかを決めます。双方で同じ情報を修正すると、更新の競合や二重入力が起こりやすくなります。正常な注文だけでなく、取消、欠品、住所変更、連携失敗時の再処理まで設計に含めることが必要です。
店舗を含む構成なら、O2OとOMOの違いの解説も参考になります。店舗へ来てもらうための施策と、会員や購入履歴を共通で扱う仕組みでは、必要なデータが異なります。EC-CUBEで何を作り、POSや会員管理側で何を担うかを区別し、店舗スタッフの仕事まで確認しましょう。
EC-CUBEの費用は構築・運用・将来の更新で見積もる
本体の価格だけでなく、稼働させ続けるための総費用で比較します。構築時の制作・開発、毎月のサーバーや保守、決済や外部サービス、将来の更新に分けると、支出の見落としを減らせます。無料のオープンソース版でも、必要な体制によって総額は変わります。
公開情報だけで、自社サイトの構築費用を一律に決めることはできません。標準に近い店舗と、複雑な取引や多数の連携を持つ店舗では、設計や検証の量が違うためです。見積もりを取得する際は、必要な機能、商品数、連携先、公開後の支援まで同じ前提で提示しましょう。
初期構築で発生する費用
初期費用には、見た目の制作だけでなく、要件整理と検証を含めます。デザイン、商品データの準備、機能追加、決済導入、外部連携、移行、テストなどを分けて確認します。見積もりの総額が近くても、含まれる作業が異なれば、そのまま比較できません。
特に、商品登録や撮影、説明文の作成を誰が行うかを決めておきます。制作会社の担当に含まれると思っていた仕事が、自社側の準備だったという行き違いは、公開の遅れにつながります。何点の商品を登録し、どの状態まで仕上げるかを具体的にしておくことが重要です。
修正回数や追加要望の扱いも確認します。構築中に新しい条件が増えると、すでに作った部分への影響が広がる場合があります。初回公開で必要な機能と、運営を始めてから追加する機能を分け、先に作る理由があるものへ開発費を使うと、予算を管理しやすくなります。
運用費と将来のバージョンアップ
保守契約では、対応する仕事と対応しない仕事を具体的に確認します。サーバー監視、障害対応、本体更新、プラグイン更新、バックアップ、復元などが対象です。月額の保守料が同じでも、緊急時の対応や個別開発部分の修正が含まれるかで、実際の負担は変わります。
将来の更新では、本体だけでなく、プラグイン、独自の改修、稼働環境との関係を確認します。古い機能を動かし続けるために更新を避ける運営では、後からまとめて対応する負担が大きくなることがあります。公開時に使う構成と、更新を判断する担当者を一覧にしておきましょう。
費用対効果は、売上が増えるという期待だけでなく、減らせる作業や処理できる取引でも評価します。現在の二重入力や個別対応に使う時間を記録し、導入後の作業と比べます。他社カートの比較では、Shopify在庫管理の解説も参考に、自社に必要な数量管理や拠点の条件をそろえると判断しやすくなります。
自社ECの運営体制や改善施策を見直したい方は、FORCE-Rへご相談ください。
セキュリティと保守は公開前から担当を決める
オープンソース版では、提供元の情報を確認し、自社サイトへ必要な対策を反映する体制が必要です。公式セキュリティ案内は、利用バージョンの確認、チェックシートや脆弱性情報の確認、対象となる対応の実施という流れを示しています。ソフトウェアが公開されているだけで、自社サイトの修正まで自動で終わるわけではありません。
導入時には、本体、プラグイン、サーバー環境、独自開発の管理を誰が行うかを決めます。問題が見つかった際に、提供元、制作会社、サーバー会社のどこへ連絡するかも確認します。担当が分かれる場合は、連絡を受ける自社側の責任者を置き、情報が止まらないようにしましょう。
更新情報と管理画面の権限
更新情報を受け取る人と、対応を判断する人を明確にします。使っている本体のバージョン、プラグインの名称と提供元、稼働環境を把握していなければ、公開された情報が自社に関係するか判断できません。導入後に担当者が変わることも想定して、構成を記録しておきます。
管理画面は、作業に必要な人だけが適切な権限で利用する運用にします。共通のアカウントを使い回すと、誰が操作したか確認しにくくなります。担当変更時の権限見直しや、外部委託先に渡す権限、認証情報の管理も、公開後の仕事に含めましょう。
バックアップと復旧の確認
バックアップは、取得に加えて戻せることを確認します。商品や注文のデータだけでなく、画像、プログラム、設定が復元に必要になる場合があります。どの範囲をどの頻度で保存し、障害時に誰が戻すかを決めます。復旧までに失われる可能性がある注文の扱いも考えておく必要があります。
更新前には、検証環境で主要な購入操作や受注処理を確認します。公開中のサイトへいきなり変更を加えると、問題が起きた際に購入や出荷へ影響が広がります。変更内容、検証結果、反映日時を残し、異常があれば何を確認するかを決めておくと、原因を追いやすくなります。
EC-CUBEが向いている事業と開発会社を選ぶ判断材料
標準的なカートの設定だけでは足りない理由があり、開発と保守の体制を用意できる事業で検討しやすい選択肢です。独自の商品選択や取引条件、既存システムとの連携など、必要な機能を明確に示せると、採用する価値を判断しやすくなります。
反対に、標準的な商品販売を早く始めたい場合や、技術的な保守へ予算を割きにくい場合は、SaaS型カートも含めて比較します。将来使うかもしれない機能を理由に作り込みすぎず、現在の販売と運営を成立させるために必要な条件から選ぶことが大切です。
開発実績と保守の引き継ぎを確認する
開発会社は、似た画面の制作実績だけでなく、似た業務への対応経験で確認します。法人取引、定期販売、複数倉庫、店舗連携など、自社で重要な処理を説明し、どのように設計と検証を進めるかを聞きます。見た目が近いサイトでも、内部の仕事が同じとは限りません。
納品時には、ソースコード、設定、仕様、テスト結果などをどのように引き継ぐか確認します。特定の担当者しか仕組みを説明できない状態では、改修や委託先変更が難しくなります。サーバーやドメイン、外部サービスの契約名義と管理権限も、会社として把握できる形にしておきましょう。
要件を伝える資料では、操作の順番と期待する結果を一組にします。「法人向け価格が必要」という説明だけでは、会員登録後に価格を変えるのか、商品ごとに契約価格を持つのか分かりません。「取引先Aがログインし、商品Bを十個注文すると契約単価で計算される」といった形にすると、必要なデータと確認する画面を具体化できます。
例外も同じ形式で整理します。取引条件が未承認の会員、在庫不足の商品、注文後の数量変更などを用意し、それぞれ受け付けるか、止めるか、担当者へ回すかを決めます。通常の画面だけで合意して開発を始めるより、後から判断しなければならない点を減らせます。初回公開では対象外とする取引も記録しておきましょう。
打ち合わせでは、困ったときの問い合わせ方法と緊急対応の条件も確認します。公開直後の支援があることと、数年後の更新まで同じ範囲で対応することは別です。保守の契約期間や更新方法を把握し、自社の販売計画と合わせて継続できる体制かを判断します。
公開後の集客と継続購入を改善したい方は、FORCE-Rへお問い合わせください。
導入から公開後の改善までの進め方
業務整理、構築、検証、移行、運用の順に確認する項目を分けます。最初に、販売する商品と取引条件、注文後の処理、外部システムを整理します。公開前には、通常の注文だけでなく、決済失敗、取消、配送条件が異なる組み合わせなどを試し、自社の業務が成立するか確認します。
検討段階では、公式サイトから案内されるデモで基本的な画面の構成を確認できます。ただし、標準のデモは、自社向けの改修後の動作を保証するものではありません。標準で使える操作を確認する段階と、開発後に自社の要件を検査する段階を分けます。商品登録や注文検索など、公開後に繰り返す作業を担当者自身が見ておくと、必要な説明資料も考えやすくなります。
開発後の確認では、画面表示だけでなく、保存された注文や外部へ渡すデータも照合します。購入者には正しい金額が表示されていても、連携先へ割引前の金額が渡ると、請求や出荷の処理が食い違います。受注番号を使い、購入画面、管理画面、決済、倉庫の情報を追える形で検証します。自動処理が止まった注文を誰が発見するかも、受入時の確認事項です。
既存サイトから移行する場合は、商品、会員、画像、注文、ポイントなどの対象を分けます。カード情報や継続中の契約は、通常の商品データと同じ方法で移せるとは限りません。移行元から取り出せる情報と、移行先で使える情報を照合し、必要な手続きを契約先へ確認します。
切り替え前後の未発送注文は、どちらのシステムで処理するか決めます。倉庫への出荷指示を両方から送ると、二重発送の原因になります。注文番号と件数を照合し、在庫を確定する時点を合わせます。公開後は、受注、決済、出荷、メールが正常に流れることを確かめてから販促を広げましょう。
集客では、SNSや検索からどの商品へ来てもらうかを決めます。ソーシャルコマースの種類と注意点の解説も参考に、投稿内容とリンク先をそろえます。サイトを自由に作れることと、自然に購入者が集まることは別です。商品を知ってもらう活動と、訪問後に購入しやすい画面の両方を整えます。
公開後は、訪問者数、購入率、再購入を分けて確認します。ユニークユーザーなどの指標の違いの解説を参考に、数字の定義と対象期間を合わせましょう。初回購入後の案内は、リピート率と向上施策の解説も確認し、商品が使われる時期に合う内容を考えます。改修は課題と目的を決めて行い、変更した内容と結果を残すことが重要です。
まとめ
EC-CUBEは、本体の無料利用とカスタマイズの柔軟性に加え、開発・保守の負担も含めて選ぶECシステムです。標準機能、プラグイン、個別開発を分け、自社の販売条件をどこまで実現するかを整理しましょう。必要な独自機能と、その後も維持できる体制があるかが判断材料です。
提供形態によって料金や担当範囲は異なり、クラウド版の公式ページには新規受付停止の記載もあります。古いプラン情報を前提にせず、現在利用できる構成を確認してください。構築時の費用だけでなく、更新、障害対応、データの引き継ぎまで準備し、公開後も改善を続けられる運営につなげましょう。
自社ECの集客や販売施策にお悩みの方は、FORCE-Rへご相談ください。EC-CUBEの個別仕様や構築・保守条件は提供元や開発会社へ確認し、運営支援の範囲は個別にご相談いただけます。
