まだEC-CUBE 2系を使っている会社へ｜旧バージョン放置のリスクと「刷新か延命か」の判断基準
目次
【AIによる要約】
– EC-CUBE 2系は脆弱性の自動修正が届かず、PHPのサポート終了と重なって放置リスクが年々増大しています。
– 刷新か延命かは、カスタマイズ量・予算・データの複雑さで分岐し、判断表で自社の状況をそのまま確認できます。
– 段階的な移行計画と監視体制を先に固めれば、いきなり全面刷新せずとも現実的な延命の選択は十分可能です。
朝、管理画面を開くのが怖い——その感覚は正しい
「EC-CUBE 2系のまま、もう10年近く運営している」
「昔バージョンアップで画面が真っ白になったトラウマがあって、誰も触りたくない」
「前にお願いしていた制作会社と連絡が取れなくなった」
当社カジヤは業界歴10年以上で300社以上のWebシステム・ECサイトを支援してきましたが、この「触りたくないけど放置するのも怖い」状態のEC-CUBE 2系サイトは、相談の現場で何度も見てきました。
そして残念なお知らせになります。今のEC-CUBE 2系は、「放置」が毎年少しずつ高リスクになっていく状態です。この記事では、放置すると何が起きるかを具体的に整理し、「刷新するか、延命するか」を社内会議でそのまま使える判断表の形に落とします。
まず押さえるべき「2つの終了」が重なっている
EC-CUBE 2系のリスクは、単体ではなく複合で来ます。
その1：EC-CUBE本体の古さ
EC-CUBE 2系の最終リリースは2.17系（2.17.2）で、それ以降は新機能や定期的なメンテナンスリリースの対象外です。現行の開発はEC-CUBE 4系以降に移っており、公式は「最新バージョン以外をご利用の場合は、必ず脆弱性リストで該当の脆弱性を確認し対応すること」を利用者に求めています（出典：EC-CUBE「セキュリティ対策について」）。
つまり2系では、4系のような「本体アップデートで脆弱性修正が届く」仕組みが基本なく、都度、該当脆弱性を自分たちで探して個別に手当てする必要があります。公式の脆弱性リストから漏れることを前提とした運用は、本来あるべき姿ではありません。まず自社のバージョンを確認していない場合は、EC-CUBEのバージョンを確認する方法【2系 3系 4系】を参照してください。
その2：PHPのサポート終了
EC-CUBE 2系が動作する環境は、PHP 5系〜7系が中心です。ところがPHP 7系はすでにセキュリティサポートが終了し、公式のサポート対象はPHP 8.2以降のみとなっています（出典：PHP Group「Supported Versions」）。
ここが複合リスクの正体です。
- EC-CUBE 2系はPHP 8系で動かないことが多く、PHPを上げる=本体の大改修が必要
- 逆にPHPを上げなければ、OSやサーバーの更新で動かなくなる日が近づく
- 脆弱性修正もPHPのセキュリティ修正も、どちらももう「自動では来ない」
この板挟みが、EC-CUBE 2系サイトを最も難しくしている構造です。PHP側の費用感や見積もりの仕組みは、「PHPのバージョンアップが必要です」と言われたら？放置するリスクと見積もり金額が決まる仕組みで詳しく解説しています。
放置した場合に起きる5つのリスク
当社が実際に立ち会ってきた改ざん被害の復旧やトラブル対応の経験も踏まえ、放置の帰結を具体的に挙げます。
| リスク | 社内で起きること |
|---|---|
| 脆弱性を突いた攻撃 | 管理画面やフォームからの侵入により、情報漏洩・改ざん。復旧作業とお客様への説明対応で通常業務が止まる |
| 支援できる会社の減少 | 2系を触れるエンジニアは年々減っており、いざ頼みたい時に見積もりが取れない・金額が高止まりする |
| サーバー環境の壁 | サーバー会社のPHP・OS更新で「いつの間にか動かなくなる」事故が起こりうる |
| 決済・連携の仕様変更 | 決済代行会社の3Dセキュア対応やAPI仕様変更に、2系のままでは追随できないケースが出る |
| 説明責任 | 事故後に「なぜ対応しなかったのか」を経営層が説明する局面が必ず来る |
個人情報を扱うECサイトでは、漏洩時の報告義務という論点もあります。こちらは中小企業こそ怖いWebサイトのセキュリティ義務｜改正個人情報保護法の報告義務と、社内で決めるべき最低限のことを参照してください。EC-CUBEの脆弱性そのものの理解は、【EC-CUBE利用事業者へ】ニュースで見る「脆弱性」とは？放置すると起きる5つのリスクと対策が詳しいです。
延命にも「費用」がかかる——その裏側を見える化する
「じゃあとりあえず保守だけで安く延命できないか」と考えますよね。ここで裏側の工程をお見せします。延命のためのセキュリティ対応・環境維持でも、プロは最低限これをやっています。
- 本番への影響を避けるため、まず完全バックアップを取得する
- テスト環境を用意し、本番と同じ条件で修正を検証する
- カスタマイズ部分との干渉（画面・決済・受注連携）を実機で確認する
- 本番へ反映し、切り戻し手順を準備した上で監視する
この工程を省いて「直接本番にパッチを当てる」のが、あの「画面が真っ白になった」事故の典型パターンです。つまり延命は「何もしないこと」と「月額保守」の二択ではなく、上記の工程を維持できるかがコストの正体になります。延命戦略の一般論は、「独自PHPの古いシステム」は最新サーバーに移転できる？老朽化サイトを安全に延命する方法にまとめています。
刷新か延命か——状況→推奨の判断表
当社の見解をはっきり言います。「両方にメリットがあります」では意思決定はできません。 条件に応じて、次のように言い切ります。
| 状況 | 推奨 |
|---|---|
| カスタマイズが少なく、商品・受注データが標準に近い | 刷新（EC-CUBE 4系へ移行）。延命コストを刷新に回した方が総額で安い |
| カスタマイズが大量で仕様書がなく、動く仕組みを抱えている | まず延命（環境維持+監視+WAF）し、1〜2年計画で刷新へ。急に刷新すると業務が止まる |
| クレジット決済で3Dセキュア等の要件を満たせなくなっている | 刷新を優先。決済要件は延命では解決できない |
| 予算は今すぐ組めないが、事業としては今後も続ける | 延命+刷新の段階的計画。途中で「触れない状態」にしないことが条件 |
| 事業そのものを縮小・終了する予定 | 最小限の延命+個人情報の退避計画。サイト閉鎖までの道筋を先に決める |
例外は「3年以内に事業の方針が固まっていない」ケースです。この場合は刷新にも延命にもフル投資せず、現状調査と監視体制に絞って予算を使ってください。
刷新先の4系については、進め方と費用の判断はEC-CUBE 4系のバージョンアップが怖くて触れない人へ｜進め方・費用・自社更新か代行かの判断基準、データ移行の漏れを防ぐ手順はEC-CUBE 4系のデータ移行で失敗しないためのチェックリスト｜受注・会員・商品データの移行漏れを防ぐで解説しています。
延命を選ぶ場合の落とし穴チェックリスト
現場で「やりがちだけど危ない」ポイントです。延命を決めたら、この4つを確認してください。
- テスト環境がないまま運用していないか：ないなら作るところから。本番直修正は事故待ちの状態です（出典：テスト環境（検証用サイト）がない本番修正がどれほど危険か、専門家が分かりやすく解説）
- WAFやアクセス制限で「入口」を減らせているか：本体改修が難しい分、管理画面のIP制限・海外アクセス遮断など環境側の防御で被害確率を下げます
- 改ざん・障害に気づける仕組みがあるか：死活監視とログの定期確認がないと、被害に気づくのが数週間後になります
- 「誰が・いつまでに」判断するかを社内で決めたか：延命は将来の刷新のための時間稼ぎです。期限を決めないと、結局ずっと2系のままになります
まとめ：判断に迷ったら、まず「現状の可視化」から
EC-CUBE 2系の放置リスクは、本体の脆弱性対応終了とPHPのサポート終了が重なったことで、確実に増えています。とはいえ全社が即座に刷新すべきではありません。判断表の通り、データとカスタマイズの状態で分岐させ、延命するなら監視と入口防御を整え、刷新の期限を決める。これが現実的な進め方です。
どちらの選択でも、まず必要なのは「自社のサイトが今どんな状態か」を正確に知ることです。カスタマイズ量、データ構造、サーバー環境を調査して見える化するところから、当社はWebサイト保守管理サービスとして支援しています。代理店を挟まない直接取引で、専任エンジニアが調査から判断材料の整理まで一貫して対応します。EC-CUBE 2系のままお困りの担当者・経営者の方は、まず現状把握のご相談からご連絡ください。
