Blog

ブログ

EC-CUBE 2系から最新版4系へ移行すべき?違いやリスクを専門ベンダーが解説

EC-CUBE 2系のまま運用を続けていませんか?

EC-CUBE 2系は、長年多くのECサイトを支えてきた実績あるプラットフォームです。
一方で、運用期間が長くなるほど、PHPやサーバー環境、決済モジュール、独自カスタマイズ、
セキュリティ対応などの課題が見えにくくなります。

現在の2系環境をすぐに4系へ移行すべきケースもあれば、
まずは2.25へ更新して現行環境を整える方が現実的なケースもあります。
重要なのは、今の環境を正しく把握したうえで、
事業に合った選択肢を選ぶことです。

現状のEC-CUBEで下記のような不安がある方に是非見ていただきたい内容となります

  • EC-CUBEのバージョンが古いままになっている
  • PHPやサーバーのバージョンアップが不安
  • 決済モジュールや外部連携の更新に不安がある
  • 独自カスタマイズが多く、どこを改修しているかわからない
  • スマートフォンでの購入率が伸び悩んでいる
  • 管理画面の操作性や表示速度に不満がある
  • EMV 3-Dセキュアなど決済セキュリティ対応が不透明
  • 今後もEC-CUBEで長く運用したいが、どのバージョンを選ぶべきかわからない

EC-CUBE 2系は現在もサポート期間延長中のバージョンですが、現行最新版は4系です。
2系を継続利用する場合でも、現在のバージョン、PHP環境、適用済みパッチ、決済モジュール、独自カスタマイズの状況を個別に確認しながら運用する必要があります。

「動いているから大丈夫」ではなく、
「今後も安全に改修・運用できる状態か」を確認することが重要です。

特に、長年カスタマイズを重ねているECサイトでは、小さな改修でも影響範囲の調査に時間がかかることがあります。
将来的なリプレースを見据え、まずは現行環境の棚卸しから始めることをおすすめします。

EC-CUBE 2系と現行最新版4系の比較

EC-CUBE 2系といっても、古い2.13系などをそのまま運用している場合と、2系最新版である2.25へ更新する場合では状況が異なります。
ここでは、旧来の2系環境、EC-CUBE 2.25、EC-CUBE 4系を比較します。

比較項目 EC-CUBE 2系
旧来環境
EC-CUBE 2.25 EC-CUBE 4系
現行最新版系
位置づけ 長年運用されてきた2系環境。独自カスタマイズが多いサイトでは、保守が属人化しているケースがあります。 既存の2系環境を継続利用するための最新版。2系の構成を維持しながら、PHPやライブラリ対応を進めたい場合の選択肢です。 EC-CUBEの現行最新版系。中長期的な保守性、拡張性、運用改善を重視する場合に向いています。
PHP対応 古いPHP環境で運用されているケースがあり、サーバー更新時に動作確認や改修が必要になる場合があります。 PHP 8.4に対応しています。既存2系を維持しながらPHP環境を見直したい場合に検討できます。 4.3ではSymfony 6 / PHP 8.3に対応しています。新しい技術基盤での運用に適しています。
セキュリティ対応 利用中バージョン、適用済みパッチ、独自カスタマイズへの影響確認が重要です。 2系最新版として改善が行われていますが、既存カスタマイズや利用プラグインの確認は必要です。 4.3ではパスワードハッシュアルゴリズム改善など、セキュリティ強化が行われています。
決済対応 決済会社・モジュールごとに対応状況の確認が必要です。新しい決済要件への対応で個別改修が必要になる場合があります。 2系を維持したまま対応できる可能性はありますが、決済モジュール側の対応可否確認が必要です。 4系対応の決済プラグインを利用しやすく、決済会社・契約サービスごとの確認を前提に移行設計できます。

※上記は一般的な比較です。実際の対応可否や移行難易度は、利用中のEC-CUBEバージョン、カスタマイズ内容、プラグイン、決済モジュール、サーバー環境によって異なります。

判断の目安
できるだけコストを抑えながら、既存の2系構成を維持してPHP対応やセキュリティ対応を進めたい場合は、EC-CUBE 2.25への更新が選択肢になります。
一方で、一定のコストをかけるのであれば、単なるバージョンアップにとどめず、4系へのリプレースとあわせてデザイン刷新や購入導線改善まで見直すことをおすすめします。

弊社が選ばれる理由

弊社では、EC-CUBE 2系の現行調査から、2.25への更新検討、4系へのリプレース、デザイン刷新、決済・外部システム連携の再設計まで一貫して対応しています。

現行診断

まずは移行すべきかを判断

いきなりリプレースを前提にするのではなく、現在のバージョン、PHP環境、プラグイン、決済、独自カスタマイズを確認し、2.25更新でよいのか、4系移行が必要なのかを整理します。

段階移行

無理のない移行計画を提案

独自カスタマイズが多い場合や、業務フローが複雑な場合でも、段階的な移行計画を立てることで、コストとリスクを抑えながら現実的に進められます。

リプレース

4系への再構築に対応

商品、会員、受注データの移行に加えて、デザイン刷新、購入導線改善、決済再設定、管理画面運用の見直しまで対応できます。

運用保守

公開後の保守までサポート

移行して終わりではなく、公開後の改修、セキュリティ対応、プラグイン更新、決済モジュールの変更など、継続運用を見据えたサポートが可能です。

結論:コストを抑えるなら2.25、投資するなら4系リニューアルがおすすめです

EC-CUBEのバージョンアップは、単に「どのバージョンが新しいか」だけで判断するものではありません。
今回の目的が、できるだけコストを抑えて現在の2系環境を維持することなのか、それとも一定のコストをかけてECサイト全体を見直すことなのかによって、選ぶべき方向性は変わります。

① コストを抑えて、現在の2系環境を維持したい場合

主な目的が、PHP対応やセキュリティ面の見直しであり、デザイン刷新や機能追加、購入導線の改善などを大きく含まないのであれば、EC-CUBE 2.25への更新が現実的な選択肢になります。

既存の2系構成を活かしながら対応できるため、4系へのフルリプレースに比べて、コストや工期を抑えやすい点がメリットです。

② ある程度コストをかけるなら、4系へのリニューアルがおすすめ

一方で、バージョンアップに一定のコストをかけるのであれば、単なるシステム更新だけで終わらせず、EC-CUBE 4系へのリプレースとあわせて、デザイン刷新、購入導線改善、機能強化、管理画面運用の見直しまで行うのがおすすめです。

4系への移行は、既存サイトをそのまま延命する対応ではなく、今後の運用・拡張・売上改善を見据えてECサイト全体を作り直す機会として活用できます。

つまり、短期的なコストを抑えるならEC-CUBE 2.25、今後の成長を見据えて投資するならEC-CUBE 4系でのリニューアル、という考え方が基本になります。

EC-CUBE 2系を使い続けるべきか、2.25へ更新すべきか、4系へ移行すべきかお悩みの方へ。

まずは現行サイトの状況を確認し、貴社に合った現実的な移行方針をご提案します。

【構築事例紹介】規模拡大を見据えたEC運営へ。資金決済法に対応したポイントルール設計とは!?

ECサイトの規模拡大に伴い、重要になるのが「お客様が保有するポイント」の適切な管理です。

特に、購入されたポイントと特典などで付与したポイントがシステム上で混在していると、正確な財務状況の把握が難しくなり、将来的な運営リスクを招く恐れがあります。

本事例では、これらを明確に区分し、利用優先順位をロジカルに制御する仕組みを構築しました。適正な管理基盤を整えることで、無駄なコスト負担を抑え、健全かつ効率的なサイト運営を実現しています。

事業の成長を見据え、バックエンドの管理体制を強化したい運営者様はぜひご一読ください。

月額制アパレルレンタルECサイト運営企業様

【EC-CUBE公式】株式会社ブラボー様の構築事例インタビューが公開されました!!

この度、EC-CUBE公式サイトの「導入事例」コーナーにて、
弊社が開発を担当させていただいた株式会社ブラボー様の事例が公開されました!

今回の記事は、単なる機能紹介だけではありません。
実際にプロジェクトを進行したブラボー様のご担当者様と、
弊社の開発チームによる「対談インタビュー形式」となっております。

リニューアルのきっかけとなった、

  • 現場のリアルな課題
  • 開発パートナーとしてJoolenを選んでいただいた決め手
  • プロジェクト進行中の裏話や、リリース後の反響

など、「プロジェクトの舞台裏」をお話しいただいています。

 

ECサイト運営者様にとって、非常に読み応えがあり、ヒントとなる内容が満載です!
ぜひ、以下のリンクよりインタビュー本編をご覧ください。

▼ 株式会社ブラボー様 構築事例インタビュー(EC-CUBE公式サイト)

https://www.ec-cube.net/cases/bravo/

【構築事例紹介】信頼性向上と現場効率化を実現したカスタマイズ成功事例!!

ECサイト構築事例を公開しました。

この事例では、ショップ運営における以下の主要な課題を、
どのように解決したのかを詳しくご紹介しています。

  • 信頼性の確保: 運営主体の不明瞭さや商品訴求力不足を解消し、潜在顧客が安心して利用できる環境を構築。
  • 現場の効率化: 煩雑なオペレーションを改善し、現場の運営効率化を実現。

「潜在顧客が安心して利用できる信頼性の確保」と「現場の運営効率化」を二大柱とし、
実務に直結する機能開発を実施しました。

この成功事例の詳細を、ぜひ記事でご覧ください!

構築事例 | マンション居住者向けサービス提供事業者

【構築事例紹介】脆弱性の悩みが解決!? 守りと攻め両面からのECサイトリニューアル!!

ECサイトの構築事例を公開しました。

多くの企業が抱える脆弱性対策の問題から、保険契約者様限定の「オリジナル名入れカード」の販売方法など、特殊な要件にも柔軟に対応しました。

リニューアルによって“守り”の課題であったリスクを回避し、同時に”攻め”の戦略となる独自商品の販売を実現した、その舞台裏をご紹介します。

構築事例 | アニコムパフェ オンラインショップ

貴社のECサイトをもっと便利に!カスタマイズ事例のご紹介

今回は、弊社が手掛けた ECサイトのカスタマイズ事例 をご紹介します。
「こんなことできるの?」と思った方、ぜひお気軽にご相談ください。

主なカスタマイズ事例

【1】URLのスラッグ対応
サイトのSEO対策として、商品やカテゴリのURLスラッグをカスタマイズするニーズが増えています。弊社では、商品IDではなく、意味のあるカテゴリ名やキーワードを使用することで、検索エンジンにとって親しみやすいURL構造を実現しました。これにより、
SEO効果の向上とユーザーの利便性が高まりました。

【2】独自クーポンの作成
多くのECサイトでは、特定の条件を満たした顧客にクーポンを配布することが求められます。弊社では、購入金額や会員ランク、特定のカテゴリー購入者向けに、独自のクーポン発行機能を実装しました。これにより、マーケティング施策を柔軟に展開することが可能になり、顧客満足度を向上させています。

【3】独自購入オプションの追加
商品購入時に必要なオプションをカスタマイズできる機能を追加しました。例えば、ギフトラッピングやメッセージカードなど、顧客のニーズに合わせた購入オプションを自由に設定することができ、よりパーソナライズされたショッピング体験を提供しています。

【4】セット商品の販売
セット商品を販売するためのカスタマイズも承りました。特定の商品をセットにして割引価格で提供することで、顧客の購買意欲を刺激し、売上を大幅にアップさせることができました。セット商品には、在庫管理や価格設定など、細かな部分の調整も可能です。

【5】外部レビューとの連携
商品レビューを外部のレビューサイトと連携させることで、信頼性を向上させました。これにより、リアルな口コミをサイト上で紹介できるようにしました。

【6】アンケート作成機能
顧客からのフィードバックを集めるため、アンケート作成機能を導入しました。特定のキャンペーンや商品に対する意見を簡単に収集でき、マーケティング戦略の改善や新商品開発に役立っています。

【7】BtoB向けクローズドサイト機能
法人向け(BtoB)の取引を行うための、クローズドサイト機能も導入しました。全てのページ(会社概要や規約ページを除く)は、ログインしないと閲覧できない設定にすることで、取引先専用の環境を構築しました。

カスタマイズのご相談、お気軽にどうぞ!

「この機能、うちでも使える?
こういう悩みを解決したいけど、どうしたら?」

そんなお悩みをお持ちでしたら、ぜひJoolenにご相談ください。
お問い合わせはこちら

Eccube4.3で「同じURLクエリパラメータを複数回使用しない」を実装してみた

SEO観点におけるURLについて調べていると
URLのクエリパラメータに関するベストプラクティスとして以下の内容が載っていました。

同じパラメータを 2 回使用しないようにします。Googlebot はどちらかの値を無視する可能性があります。
 推奨: ?type=candy,sweet
 非推奨: ?type=candy&type=sweet  (引用)

参考:URL のクエリ パラメータに関するベスト プラクティス

Eccubeで複数選択可の項目を検索すると、 「?type[]=candy&type[]=sweet」 のような、
上記で非推奨とされる「同じパラメータを複数回使用しているURL」になります。
検索エンジンにインデックスさせる対象が、単一選択されたページのみ(「?type[]=candy」「 ?type[]=sweet」 は対象だが 「?type[]=candy&type[]=sweet」 はインデックス対象ではない)
の場合は気にする必要はないと思いますが、もし、複数選択したページをインデックスさせたいなら対応が必要かも(?)ということで今回、Eccube4.3で試してみました。

手順1.複数選択可の検索項目をカスタマイズして追加する

前提条件である「複数選択検索」をできる項目が、Eccube4.3の初期状態では無いので、まずはそれを追加します。
今回は「複数選択可なカテゴリ」を追加します。
(カテゴリ検索は既にあるのですが、単一選択しかできないので、複数選択可な状態のなものを追加します)

1-1.FormTypeのカスタマイズ
EccubeのフォームはFormTypeに実装されているので、カスタマイズして、複数選択可用のカテゴリ項目を追加します。

app/Customize/Form/Extension/ 配下に以下のような「SearchProductTypeExtension.php」を追加します。

実装例
<?php

namespace Customize\Form\Extension;

use Eccube\Form\Type\SearchProductType;
use Eccube\Repository\CategoryRepository;
use Symfony\Bridge\Doctrine\Form\Type\EntityType;
use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\FormBuilderInterface;

class SearchProductTypeExtension extends AbstractTypeExtension
{
private CategoryRepository $categoryRepository;

public function __construct(CategoryRepository $categoryRepository)
{
$this->categoryRepository = $categoryRepository;
}

public static function getExtendedTypes(): iterable
{
yield SearchProductType::class;
}

public function buildForm(FormBuilderInterface $builder, array $options)
{
$categories = $this->categoryRepository->getList(null, true);

$builder->add('category_ids', EntityType::class, [
'class' => 'Eccube\Entity\Category',
'choices' => $categories,
'choice_label' => 'NameWithLevel',
'multiple' => true,
'expanded' => true,
'required' => false,
'label' => 'カテゴリ(複数選択)',
'attr' => [
'class' => 'form-control',
],
]);
}
}

参考:FormTypeカスタマイズの公式ドキュメント

これで、既存のSearchProductType に対して、「category_ids」フォーム項目を追加したことになります。
既に存在するカテゴリ検索項目「category_id」との違いは、チェックボックスになるように「’multiple’ => true」「’expanded’ => true」を追加しただけです。

1-2.Repositoryのカスタマイズ

新しく追加したフィールド「’category_ids’」で検索されるようにRepositoryもカスタマイズします。

app/Customize/Repository配下に以下のようなファイルを追加します。

実装例
<?php

namespace Customize\Repository;

use Doctrine\ORM\EntityManagerInterface;
use Doctrine\ORM\QueryBuilder;
use Eccube\Doctrine\Query\QueryCustomizer;
use Eccube\Repository\QueryKey;

class ProductRepositoryCustomizer implements QueryCustomizer
{

    private EntityManagerInterface $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->entityManager = $entityManager;
    }

    /**
     * 商品検索にカテゴリ(複数)を追加する
     *
     * @param QueryBuilder $builder
     * @param array $params
     * @param $queryKey
     */
    public function customize(QueryBuilder $builder, $params, $queryKey): void
    {
        // category(s)
        if (!empty($params['category_ids'])) {
            $Categories = $params['category_ids'];
            if ($Categories->count() > 0) {
                $subQb = $this->entityManager->createQueryBuilder();
                $subQb->select('1')
                    ->from('Eccube\Entity\ProductCategory', 'pct_sub')
                    ->where('pct_sub.Product = p') // 'p'は親クエリのエイリアス
                    ->andWhere($subQb->expr()->in('pct_sub.Category', ':Categories'));

                $builder->andWhere($builder->expr()->exists($subQb->getDQL()))
                    ->setParameter('Categories', $Categories);
            }
        }
    }

    /**
     * ProductRepository::getQueryBuilderBySearchData に適用する.
     *
     * @return string
     * @see \Eccube\Repository\ProductRepository::getQueryBuilderBySearchData()
     * @see QueryKey
     */
    public function getQueryKey(): string
    {
        return QueryKey::PRODUCT_SEARCH;
    }
}

参考:Repositoryのカスタマイズ

category_ids」が選択されている場合は、選択されたカテゴリIDが、カテゴリとして設定されている商品をExistで絞り込んでいます。

 

1-3.twigのカスタマイズ

app/template/default/Product 配下に src/Eccube/Resource/template/default/Product/list.twig のコードをコピーして配置します。するとapp/template/default/Product/list.twig の方が参照されます。

参考:テンプレートカスタマイズの公式ドキュメント

新しく配置したapp/template/default/Product/list.twigのformタグの中に、category_idsフィールドを追加します。
その時、既存の、「FormTypeのフィールドをfor文でhiddenとして書き出している処理」からcategory_idsフィールドを除外します。

実装例
<form name="form1" id="form1" method="get" action="?">
   {{% for item in search_form  %}
      {# category_idsは除外 #}
      {% if item.vars.name != 'category_ids' %}
            <input type="hidden" id="{{ item.vars.id }}"
                  name="{{ item.vars.full_name }}"
            {% if item.vars.value is not empty %}value="{{ item.vars.value }}" {% endif %}/>
      {% endif %}
   {{% endfor %}
   {{# 新しい複数選択カテゴリフィールドの表示 #}
   {<div class="form-group">
      {{ form_widget(search_form.category_ids) }}
      {{ form_errors(search_form.category_ids) }}
      <button type="submit" class="btn btn-primary mt-2">
            {{ '検索' }}
      </button>
   {</div>
</form>

これで検索結果一覧ページにアクセスすると、複数選択出来るカテゴリのチェックボックスと検索ボタンが追加された画面が表示されます。

これでカテゴリの複数検索すると下記のようなURLになります。(デコードしています)

http://localhost:8080/products/list?mode=&category_id=&name=&pageno=&disp_number=20&orderby=1&category_ids[]=7&category_ids[]=9

※動作確認のため、いくつかカテゴリを追加しています。

これで前提条件である「同じパラメータを複数回使用したURL」の状態になりました。

手順2.複数カテゴリ検索時のURLをカンマ区切りにする

いよいよ本題であるURLのカンマ区切りに着手します。

2-1.検索実行直前にjavascriptで配列 → 文字列 変更する

チェックボックスで選択した値をそのままの状態で検索実行してしまうと、配列のURLが生成されてしまうので、javascript でカンマ区切りの文字列に変更します。

実装例(app/template/default/Product/list.twig に追記しました)
    <script>
        document.addEventListener('DOMContentLoaded', function () {
            const form = document.getElementById('form1');

            form.addEventListener('submit', function (e) {
                const checkboxes = form.querySelectorAll('input[name="category_ids[]"]:checked');
                const selectedValues = Array.from(checkboxes).map(cb => cb.value);

                // 既存の複数inputをdisabledにして送信されないようにする(後で1つのinputにまとめるため)
                checkboxes.forEach(cb => cb.disabled = true);

                // 新しいhidden inputを1つ作成
                const input = document.createElement('input');
                input.type = 'hidden';
                input.name = 'category_ids';
                input.value = selectedValues.join(',');

                form.appendChild(input);
            });
        });
    </script>

上記のjavascript コードで、以下の内容を実行しています。

  • submitの直前に、選択された「category_ids」の値を取得
  • 元々の category_idsチェックボックスフィールド はdisabled
  • 選択された「category_ids」の値をカンマ区切りにしてformに新フィールドとして追加

これだけでURLは、目的である「同じパラメータは1回しか使用されない」状態になります。

http://localhost:8080/products/list?mode=&category_id=&name=&pageno=&disp_number=20&orderby=1&category_ids=7,9
※デコードしています。

しかし、これだけだと検索がうまくいきません。FormTypeでは配列で送られてくることが期待されていますが、文字列で来たためエラーになってしまいます。

今度はFormType側で文字列 → 配列 に変換して帳尻を合わせます。

2-2.FormTypeの処理時に文字列 → 配列 に変換する

手順1で追加した「SearchProductTypeExtension」に以下の内容を追記します。

実装例
<?php

namespace Customize\Form\Extension;

・・・省略・・・use Symfony\Component\Form\FormEvent; use Symfony\Component\Form\FormEvents;
class SearchProductTypeExtension extends AbstractTypeExtension
{
    private CategoryRepository $categoryRepository;

    public function __construct(CategoryRepository $categoryRepository)
    { ・・・省略・・・ }

    public static function getExtendedTypes(): iterable
    { ・・・省略・・・ }
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        ・・・省略・・・ $builder->addEventListener(FormEvents::PRE_SUBMIT, function (FormEvent $event) { $data = $event->getData(); // カンマ区切りの文字列を配列に変換 if (isset($data['category_ids']) && is_string($data['category_ids'])) { $ids = array_filter(array_map('trim', explode(',', $data['category_ids']))); $data['category_ids'] = $ids; $event->setData($data); } });
    }
}

PRE_SUBMIT イベントを使って、カンマ区切り文字列を配列に変換しています。
PRE_SUBMIT イベントは「フォームにデータを送信する前に、リクエストのデータを変更する」時に使うものなので、今回のような目的にはピッタリですね。
参考:Symfony Form Events

FormTypeに上記を修正を適用すると、URLの目的を達成しつつ、検索機能も損なわない状態になります。

一応これで今回の試したかったことは出来ました。お試しだったので「category_ids」に特化したコードになってしまいましたが、本当に運用するつもりなら、処理は部品化して汎用的に使えるようにすると良いと思います。

まとめ

いかがだったでしょうか。今回はたまたま見つけた「同じパラメータを 2 回使用しない」を試してみました。
私は今まで聞いたことが無かったので、SEO対策としての重要度はそこまで高く無いのかもしれません。また、最初にも書いた通り、複数選択された状態をインデックスさせる必要が無い場合はそもそも必要ありません。

それなりに対応コストはかかるので、もし本格的に導入を検討をする際には、一度SEO対策会社の方へ相談してから判断するのが良いでしょう。

 

【必見】今さら聞けない「EC-CUBE」って?できること&便利機能をわかりやすく解説!

こんにちは!
今回はネットショップ運営を考えている方、または今のECサイトに満足していない方に向けて、
日本生まれのECプラットフォーム「EC-CUBE(イーシーキューブ)」をご紹介します。
無料で始められて、しかも柔軟にカスタマイズできるとあって、実は中小企業から大手企業まで幅広く使われているんです。

 

そもそもEC-CUBEって?

EC-CUBEは、日本発のオープンソースECプラットフォーム。
言い換えれば、「自分で自由に作れるネットショップの土台」です。
無料でダウンロード・利用できて、自社に合ったショップを思い通りに作れるのが最大の魅力!
デザインの変更も、機能追加も、まるでブロックのパーツのように組み立て自由自在なのです。

 

EC-CUBEでできること

✅ 商品の登録やカテゴリ分け
✅ 受注〜発送までの一元管理
✅ 会員登録・購入履歴・ポイント機能
✅ HTML/CSSでの自由なデザイン編集
✅ プラグインで機能拡張(クーポンやSNS連携)
つまり、「これがあればネットショップとして十分」な機能が、はじめからそろっています。

これは便利!知っておきたいおすすめ機能

💡 スマホ表示に自動対応
 スマートフォンでも見やすく、購入しやすいUIになっています。
💡 会員ランクやポイント制度もカンタン導入
 リピーター獲得の施策もばっちり。
💡 越境ECも視野に(多言語・多通貨対応)
 必要に応じて、海外販売の足がかりにもなります。
💡 エンジニアにはうれしい構造
 開発やカスタマイズがしやすい設計、開発コミュニティやドキュメントも充実。
💡 管理画面がわかりやすい!
 日本語で操作に迷わず、誰でもショップ運営をスタートできます。

EC-CUBEはこんな人におすすめ!

* これから本格的にネットショップを始めたい方
* 自由にカスタマイズして差別化したい方
* ShopifyやBASEでは物足りなくなってきた方
* 自社独自の販売スタイルに合わせて構築したい方

自分で作りたい人にも、プロに頼んで構築する人にも使いやすいのがEC-CUBEの魅力。
まずは一度、公式サイトやデモで触ってみてはいかがでしょうか?

EC-CUBEは、アイデア次第でショップの可能性がどんどん広がる柔軟なプラットフォームです。
「やってみたいけど、どこから手を付けたらいいかわからない」「自社向けにカスタマイズしたい」など、
導入や運用でお悩みがあれば、ぜひお気軽にご相談ください。
お問い合わせはこちら