EC-CUBE4.2から4.3へバージョンアップするには?互換性と移行前の確認事項

EC-CUBE4.2から4.3へバージョンアップするには?互換性と移行前の確認事項EC-CUBE
この記事は約7分で読めます。

EC-CUBE4.2から4.3へのバージョンアップでは、本体だけでなく、プラグイン、独自カスタマイズ、サーバー環境の確認が必要です。
現在の機能を引き継げるかを調べ、テスト環境で注文から出荷まで確認したうえで、本番へ反映します。

「4.2で動いているプラグインはそのまま使えるのか」「PHPを変更すると注文に影響しないか」「受注を止める時間はどのくらい必要か」。
運営担当者が制作会社へ相談する前に整理しておきたいポイントを解説します。

この記事は、主にオープンソース版のEC-CUBE4.2を運用している方向けです。
4.3系への移行を前提に、準備と確認事項を扱います。

更新の必要性や予算から検討する方は、EC-CUBEのバージョンアップ費用・実施時期の判断基準をご覧ください。

EC-CUBE4.2から4.3へのバージョンアップはできる?

EC-CUBE公式には、4.2から4.3への本体バージョンアップ手順が公開されています。
ただし、掲載手順は4.2.3から4.3.0への更新を想定したものです。
現在のバージョンや本体の改修状況によって、必要な作業は変わります。

特に、本体のファイルを直接改修している場合は、そのまま置き換えると独自機能が失われるおそれがあります。
公式手順でも、本体改修がある場合は変更差分の確認が必要とされています。
自社サイトに適用できる手順かどうかを、作業前に確認しましょう。

参考:EC-CUBE公式「4.2から4.3本体バージョンアップ」

最初に確認するのは「いま何が動いているか」

見積もりを依頼するときは、次の情報をまとめると、調査対象や作業範囲が伝わりやすくなります。
分からない項目は、分からないまま相談して構いません。

  • EC-CUBEの正確なバージョンと、サーバー・PHP・データベースの情報
  • 利用中のプラグイン名、バージョン、提供元
  • 決済方法、配送サービス、外部システムとの連携
  • 独自に追加・変更した画面や機能
  • 会員数・商品数・受注件数の規模と、日々の運用手順
  • 希望時期と、注文受付を停止できる時間帯

仕様書がなくても、日々使っている画面や帳票、CSVのサンプルから確認項目を整理できます。
相談時の資料には、顧客の個人情報を含めず、項目名と処理内容が分かるものを用意してください。

プラグインは「4.3対応」と実際の動作を確認する

公式の移行資料では、必要な修正を行うことで、プラグインを4.2と4.3の両方に対応させられると説明されています。
利用中のプラグインが、修正なしで動くという意味ではありません。
4.3に対応した版の提供状況を、提供元の案内で確認します。

参考:EC-CUBE公式「4.2から4.3へのマイグレーション」

プラグインごとに「対応版あり」「提供元へ確認中」「代替・改修が必要」を整理しましょう。
特に決済、配送、会員別価格、ポイントなど、注文に関わる機能から優先して調べます。

未対応のプラグインがある場合は、対応版を待つ、別の製品へ変更する、必要な機能を個別に開発する、といった選択肢があります。
代替製品を導入するときは、機能だけでなく、既存データの引き継ぎや運用方法の変更も確認が必要です。

PHPは動作要件とサポート期限を分けて判断する

公式のシステム要件では、EC-CUBE4.2のPHP対応範囲は7.4〜8.1、4.3は8.1〜8.3です。
ただし、本体の対応範囲だけで採用するPHPを決めることはできません。
プラグイン、独自改修、利用サーバーも含めた確認が必要です。

参考:EC-CUBE公式「システム要件」

PHP8.1は、PHP公式のサポートが2025年12月31日に終了しています。
そのため、4.3の動作要件に含まれているという理由だけで、PHP8.1を継続する判断はできません。
移行時点でのサポート状況と、利用する構成の動作確認結果を合わせて判断しましょう。

参考:PHP公式「サポートを終了したバージョン」

カスタマイズがあるサイトで確認したいこと

独自機能は、画面が表示されるだけでは確認が足りません。
入力、計算、保存、外部への受け渡しまで、業務の流れに沿って確認します。

例えばBtoB-ECでは、得意先ごとの価格、購入できる商品の制限、掛け払い、担当者別の権限などを追加していることがあります。
一般会員の購入テストが通っても、特定の得意先だけ価格が変わる処理に問題が残る可能性があります。

テスト用の得意先や担当者を複数用意し、条件ごとに結果を比較しましょう。
BtoB特有の機能を整理する際は、EC-CUBEでBtoB-ECを構築するための機能とカスタマイズも参考にしてください。

移行前に行いたいテスト一覧

以下はテスト計画の例です。
実際に使っている機能に合わせて項目を追加し、制作会社と運営担当者で確認範囲を共有します。

対象主な確認内容
会員・ログイン既存会員のログイン、新規登録、パスワード再設定、登録情報の変更
商品・価格検索、規格の選択、在庫表示、得意先別価格、税・送料・値引きの計算
注文・決済各決済方法の成功・失敗・途中離脱、受注の作成、決済結果との一致
メール注文受付や出荷案内の送信先、本文、重複送信の有無
管理画面受注検索、変更、キャンセル、出荷処理、帳票の出力
外部連携在庫・受注の連携、CSV入出力、定期処理、エラー時の再実行
アクセス・計測主要URL、リダイレクト、検索エンジン向け設定、購入などの計測

テスト環境では、本番の顧客へメールを送ったり、実際の請求・出荷を発生させたりしない設定が必要です。
決済は提供元のテスト方法に従い、外部連携先もテスト用へ切り替えます。

不具合を見つけた場合は、操作手順、入力した条件、期待した結果、実際の結果を記録します。
修正後はその箇所に加え、関連する注文処理も確認しましょう。

本番への切り替えで決めておくこと

注文受付を止める時間と、直前のデータを扱う方法

テスト環境を用意してから公開までの間にも、本番では注文や会員登録が増えます。
テスト環境のデータをそのまま本番へ戻すと、新しい注文が失われるおそれがあります。

どの時点で注文受付を止めるか、直前までのデータをどう反映するか、外部連携をいつ止めて再開するかを、事前に決めておきます。
停止時間はサイトごとに異なるため、事前のリハーサルを基に見積もります。

問題が起きたときに戻せる状態を用意する

ファイルとデータベースのバックアップをそろえ、復元方法と判断する担当者を決めます。
バックアップを取得するだけでなく、戻せることを確認しておく必要があります。

公開後に新しい注文や決済が発生した場合、単純に以前のデータへ戻すと不整合が起きることがあります。
復旧時に新規受注や決済結果をどう確認するかも、切り替え計画に含めましょう。

公開直後の確認担当を決める

公開後は、注文受付、決済、通知メール、管理画面、外部連携を確認します。
運営担当者も普段の受注処理を行い、異常があればすぐ連絡できる体制を整えます。

EC-CUBE4.3へのバージョンアップでよくある質問

現在のデザインを残せますか?

既存のデザインを引き継ぐ方針で検討できます。
ただし、テンプレートの変更やプラグインの影響によって修正が必要になる場合があります。
見た目に加えて、スマートフォンでの入力や購入操作も確認します。

会員情報や受注履歴は引き継げますか?

引き継ぎを前提に計画します。
ただし、独自項目や外部サービスとの関連付けを含め、移行後のデータ確認が必要です。
件数の一致だけでなく、既存会員のログインや過去の受注詳細も確認しましょう。

EC-CUBE4.0や4.1でも、この記事と同じ手順で更新できますか?

同じ手順をそのまま適用することはできません。
現在のバージョンと改修内容に応じて、移行経路や必要な変更を調査します。
2系・3系を含む旧バージョンからの移行も、別途の計画が必要です。

EC-CUBEのバージョンアップをご検討の方へ

サンクユーでは、EC-CUBEサイトの構築・カスタマイズ・保守についてご相談を承っています。
バージョンアップをご検討の場合は、現在のサイトURL、分かる範囲のバージョン、利用中の機能、希望時期をお知らせください。

まずは、引き継ぎたい機能と運用上の条件を整理し、必要な調査・改修・確認の範囲を検討しましょう。

サンクユーのEC-CUBE構築・カスタマイズサービス
EC-CUBEのバージョンアップを相談する

システム要件・サポート情報の確認日:2026年9月21日。
実施時には、採用するバージョンの公式情報と各プラグイン提供元の案内をご確認ください。

投稿者プロフィール

Nakamura
サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。

Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。

ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。

お気軽にご相談ください

お気軽にご相談ください

タイトルとURLをコピーしました