EC-CUBEは、ShopifyやMakeShopのようなASPカートと違い、自社のサーバーに置いて動かします。月額のシステム利用料がかからない代わりに、本体の更新・サーバーの管理・セキュリティ対策はすべて自分たちの責任になります。

しかもECサイトなので、扱っているのは個人情報と決済です。コーポレートサイトが止まるのとは、事故が起きたときの重さが違います。

保守費用の相場

EC-CUBEの保守は月額いくらという形が一般的です。WordPressの保守より高くなるのは、決済とサーバーが絡むぶん、確認する範囲が広いためです。

サーバー費用は別です。EC-CUBEは共用サーバーでも動きますが、受注が増えるとVPSやクラウドに移すことになります。月5,000円〜30,000円程度を見ておいてください。

EC-CUBEの保守に含まれるもの

• EC-CUBE本体のアップデート適用
• プラグインの更新と、更新による不具合の確認
• PHP・データベース・サーバーミドルウェアのバージョン追従
• バックアップの取得と保管（データベースとファイルの両方）
• 決済まわりの動作確認（決済代行会社の仕様変更への追従を含む）
• 稼働監視と、停止したときの復旧
• 脆弱性情報の確認と、影響がある場合の対応
• 軽微な修正（商品ページの文言、バナーの差し替えなど）

安いプランは「更新とバックアップだけ」であることが多く、決済まわりの検証は含まれません。EC-CUBEの場合、ここが含まれるかどうかが価格帯の分かれ目です。

放置したときに起きること

1. 個人情報とカード情報が狙われる

ECサイトは、攻撃する側から見て価値の高い標的です。氏名・住所・電話番号・購入履歴が揃っており、決済画面を改ざんできればカード情報も取れます。実際に国内でも、ECサイトからのカード情報流出は毎年発生しています。

流出が起きると、お客様への通知、決済代行会社との調整、フォレンジック調査、カード会社からの調査費用の請求と続きます。調査費用だけで数百万円になることがあり、保守費用とは桁が違います。

2. 決済が突然止まる

決済代行会社は、セキュリティ要件の変更やAPIの仕様変更を定期的に行います。これに追従しないと、ある日を境に決済が通らなくなります。気づくのがカゴ落ちの増加からだと、その間の売上は戻りません。

3. サーバー側の変更で動かなくなる

レンタルサーバー側がPHPのバージョンを上げると、古いEC-CUBEは動かなくなります。EC-CUBE 4.2系・4.3系はPHP 8.1以上が前提で、2系・3系はもっと古いPHPを想定しています。サーバー会社からの告知を見逃すと、ある朝サイトが真っ白になります。

4. バージョンが古いほど移行が高くつく

2系・3系から4系への移行は、アップデートではなく実質的な作り直しです。放置した年数がそのまま移行費用に乗ります。

バージョン移行をどう考えるか

EC-CUBEは 2系・3系・4系で構造が大きく違います。同じ「EC-CUBE」という名前でも、中身は別のシステムだと考えたほうが実態に近いです。

移行費用は、いま入っているカスタマイズの量で決まります。本体のソースを直接書き換えて機能を足していた場合、その差分をすべて4系のやり方に置き換える作業になります。プラグインとして作られていれば、その部分は作り直しで済みます。

「いまは動いているから」と先送りするほど高くなる、という点でWordPressの保守とは性格が違います。EC-CUBEの場合、先送りのコストは保守費用ではなく移行費用として返ってきます。

保守の見積もりで確認する7項目

1. 更新の対象 … 本体だけか、プラグインとPHP・サーバーまで含むか
2. 更新の手順 … 本番でそのまま更新するのか、テスト環境で検証してから反映するのか
3. 決済の検証 … 更新後に決済が通ることを確認するところまで含むか
4. バックアップ … データベースとファイルの両方か。頻度と保管期間。そして復元を試したことがあるか
5. 障害時の対応 … 含まれるのか別料金か。連絡してから着手までの時間の目安。夜間・休日は動くか
6. 脆弱性への対応 … 情報の収集だけか、影響調査と対処まで含むか
7. 解約時 … 何を引き継げるか。サーバーとドメインの権限、バックアップデータ、カスタマイズの仕様書

3番の決済の検証は、EC-CUBE特有の項目です。ここが抜けている見積もりは安く見えますが、更新して決済が止まったときに誰も気づきません。

自社で持つ場合に必要なこと

1. テスト環境を用意し、本番に当てる前に検証できる
2. データベースとファイルのバックアップを取り、実際に復元できることを確認している
3. PHP・データベースのバージョン変更に追従できる
4. 決済代行会社からの通知を受け取り、対応要否を判断できる
5. 脆弱性情報を追い、自社に影響があるかを判断できる

1と2ができていれば、日常の更新は社内でも回せます。難しいのは4と5で、これは情報を追い続けられるかという体制の問題です。受注が売上の主軸になっているなら、外に出したほうが確実です。

ワプラボの場合

ワプラボはEC-CUBEの構築とプラグイン開発を主体としています。納品後は、要件どおりに動作しない箇所の修正を回数無制限で対応しています。仕様の追加・変更にあたる内容は別途お見積りです。

稼働中のサイトへの機能追加・不具合の修正・バージョンの相談にも対応しています。現在のバージョンと、どのような改修をされてきたかをお知らせいただければ、対応可否と費用をご提示します。本体のソースを直接書き換えて拡張されている場合は、まず現状の把握からになります。

まとめ

• EC-CUBEの保守はWordPressより高い。決済とサーバーが絡むぶん確認する範囲が広い
• 価格帯の分かれ目は「テスト環境で検証してから反映するか」と「決済の検証が含まれるか」
• 事故が起きたときの損害は保守費用と桁が違う。調査費用だけで数百万円になることがある
• 決済代行会社の仕様変更とサーバー側のPHP更新は、外から一方的に来る。追従しないと止まる
• 先送りのコストは、保守費用ではなくバージョン移行費用として返ってくる
• 機能をプラグインとして作っておくと、移行のときに効く