EC-CUBE 4.4へ上げる前に作る互換性台帳｜PHP・プラグイン・独自改修を棚卸しして「更新・保留」を決める
ON THIS PAGE▼
EC-CUBEの更新では、「管理画面にログインできた」「商品詳細が開いた」だけでは、更新可否を判断できません。決済、注文確定時の金額計算、受注メール、会員情報、配送連携、帳票などは、通常の画面遷移とは別の経路で動きます。
そこで更新前に用意したいのが、導入済みの技術資産と業務影響を一枚に集約する互換性台帳です。台帳の目的は、対応の要否を技術者だけの判断に閉じず、更新範囲・検証量・停止リスクを事業側と合意することにあります。
EC-CUBE 4.4は、公式発表で2026年8月のリリース予定と案内されています。この記事で扱うロードマップ上の内容は、2026年8月25日確認時点の予定情報です。正式版の公開状況、アップグレード手順、実際の要件は、実施直前にEC-CUBE公式のリリース情報とアップグレードガイドで確認してください。予定段階の仕様を、確定した移行要件として扱わないことが重要です。
まず決めること：更新作業ではなく「更新判断」の完了条件
更新プロジェクトを始める前に、次の問いへ答えられる状態を完了条件にします。
- 現行環境のEC-CUBE、PHP、DB、OS、Webサーバーのバージョンを記録できているか
- 導入済みプラグイン、テーマ、独自改修を漏れなく洗い出したか
- 決済・受注・在庫・会員・販促など、停止できない業務機能を特定したか
- 各資産について、4.4対応の根拠と確認日を記録したか
- テスト環境、テスト担当、受入条件、切り戻し可否が決まっているか
- 対応不能だった場合の代替策と、更新を保留する条件を決めたか
ここでいう「漏れなく」は、ソースコードだけを意味しません。cronやキュー実行、決済事業者の管理画面設定、メール送信基盤、外部在庫・配送・MAとの連携、運用担当者が手作業で行うCSV処理も対象です。コード管理外の設定ほど、更新後に初めて差分が発覚しやすいためです。
更新の可否を問う会議では、「4.4に対応しているか」だけでなく、「未対応なら、どの業務が止まり、いつまでに誰が代替手段を決めるか」を台帳から提示します。技術的な互換性と事業上の許容可否を分けると、保留判断も説明しやすくなります。
EC-CUBE 4.4で先に確認する基盤依存関係
EC-CUBEの4.4ロードマップでは、Symfony 7.4、PHP 8.2〜8.5、Doctrine ORM 3系・DBAL 4系への対応が予定として示されています。また、Entity拡張やイベント購読を行うプラグイン、旧jQuery APIを使用するテーマ、金額計算に関する実装などは、確認対象として挙げられています。
Symfony 7.4自体はPHP 8.2.0以上を必要とするLTS版です。そのため、EC-CUBE本体だけでなく、PHPを提供するホスティングやコンテナイメージ、PHP拡張、CLIで動く定期処理まで同じ台帳に置きます。Web画面がPHP 8.2以上で動いていても、バッチだけ別のPHP実行環境を参照している構成では、受注連携や定期メール配信で不整合が起こり得ます。
基盤欄に記録する項目
環境単位で、少なくとも以下を記録します。バージョンは「確認日」とセットにしてください。
| 区分 | 記録項目 | 確認先の例 | 判断に使う観点 |
|---|---|---|---|
| EC-CUBE | 現行版、導入方法、最終更新日 | composer.lock、管理画面、リポジトリ | 途中のメジャー・マイナー更新が必要か |
| PHP | Web・CLIそれぞれの版、拡張、設定差分 | サーバー設定、php -v、CI設定 | 4.4の要件と、周辺ライブラリの両方を満たすか |
| DB | 種別、版、文字コード、照合順序、バックアップ復元手順 | DB管理画面、IaC、運用手順書 | Doctrine更新後のスキーマ・クエリ検証ができるか |
| 実行基盤 | OS、Webサーバー、コンテナ、ジョブ実行方式 | ホスティング設定、Dockerfile、cron | 本番と検証環境で差分を再現できるか |
| 周辺基盤 | メール、ストレージ、CDN、外部API認証 | 環境変数、管理画面、設定ファイル | 認証方式や送信元設定を引き継げるか |
なお、PHPのサポート期限や利用可能なバージョンは、利用中のホスティング・OS・コンテナ提供元によって異なります。一般的な期限情報だけで判断せず、契約中サービスでの提供終了日、延長サポートの有無、切替時の設定変更を個別に確認します。
プラグインは「対応表」と「自社での動作確認」を分けて管理する
EC-CUBE公式FAQでは、系統間で内部構造が大きく異なるためプラグイン互換性はなく、対応バージョンの確認が必要だと案内されています。4.4への更新でも、現行環境で稼働しているという事実だけから、互換性を推定しないでください。
オーナーズストアの掲載例でも、対応EC-CUBE版を4.2〜4.3系に限定するプラグインがあります。本体をカスタマイズしている場合には確認が必要という注記もあります。これは特定プラグインの情報であり、全プラグインの4.4非対応を示すものではありません。だからこそ、各プラグインについて提供元の一次情報を確認し、確認日とURLを残します。
プラグイン台帳の列
プラグイン名とバージョンだけでは、優先順位を付けられません。次の列を追加します。
| 列 | 記入内容 |
|---|---|
| 識別情報 | プラグイン名、導入版、提供元、ライセンス・保守契約の有無 |
| 利用機能 | 決済、配送、受注、会員、クーポン、帳票、管理画面など |
| 業務影響 | 停止時に受注不能、出荷保留、手作業代替可能など |
| 対応根拠 | 提供元の対応表・リリースノートURL、問い合わせ番号、確認日 |
| 現時点の判定 | 対応確認済み／回答待ち／非対応／不明 |
| 検証結果 | 実施環境、テストケース、結果、証跡の保存先 |
| 代替策 | 標準機能、別プラグイン、手運用、更新保留 |
| 責任者・期限 | 提供元確認者、改修担当、業務受入担当、判断期限 |
特に決済プラグインは、「テスト決済が通るか」に加え、取消、返金、与信後売上、定期課金など、自社が使う取引パターンを台帳に列挙します。未使用の機能まで無制限に試験する必要はありませんが、日常運用に存在する処理を対象外にしないことが大切です。
テーマと独自改修は、配置場所ではなく依存先で棚卸しする
独自改修は、app配下のファイル一覧だけでは判断できません。テンプレートの上書き、イベント購読、Entity拡張、Serviceの差し替え、JavaScript、CSS、SQL、外部API連携、管理画面の手順変更など、形態が分散するためです。
4.4ロードマップで注意点として示されているEntity拡張・イベント購読・旧jQuery API・金額計算は、台帳上で独立した確認列にします。たとえば「商品詳細を改修した」という記録ではなく、「どのテンプレートを上書きし、どのJavaScript APIに依存し、購入フローへ影響するか」と記します。
独自改修の記録例
| 改修ID | 機能・配置 | 依存先 | 業務影響 | 4.4確認内容 | 判定 |
|---|---|---|---|---|---|
| C-01 | 商品オプション表示・テンプレート | テンプレート上書き、JavaScript | 商品選択・カート投入 | 旧jQuery APIの有無、表示・投入テスト | 要確認 |
| C-02 | 会員ランク別価格・イベント購読 | Event、金額計算 | 商品価格・注文金額 | イベント引数、税・値引き・送料を含む金額テスト | 要改修または検証 |
| C-03 | 出荷CSV連携・定期処理 | CLI、DB、外部API | 出荷指示 | PHP CLI、認証、失敗時の再実行 | 要確認 |
これは記入形式の例であり、特定の改修が4.4で必ず動作しないことを意味しません。改修ごとに、依存先の変更有無を公式情報・ソースコード差分・検証環境で確認します。
ソースコードが十分に管理されていない場合は、先に現行本番のファイル、DB、環境変数、管理画面設定を保全します。ただし、個人情報や認証情報を含むバックアップの取り扱いにはアクセス制御と保管ルールが必要です。検証環境へ本番データを複製するなら、必要性、マスキング、削除期限も別途決めます。
互換性台帳から「更新・要対応・保留」の3区分へ振り分ける
棚卸しの後は、すべてを同じ優先度で直すのではなく、資産単位で次の3区分にします。
1. 更新へ進む
以下を満たすものは、統合テストへ進めます。
- 4.4対応の根拠が、提供元または公式情報で確認できる
- 本番相当の検証環境で、対象機能の受入テストを完了している
- 失敗時の復旧方法と担当者が決まっている
「対応版がある」と「自社の組み合わせで動く」は別です。前者は着手条件、後者はリリース判断の材料として扱います。
2. 改修または提供元確認が必要
対応表が未公開、問い合わせ回答待ち、独自拡張が基盤APIへ依存している、金額や受注処理に差分が出る、といった項目をここに入れます。期限は「本番更新日」から逆算するだけでなく、提供元の回答期限、改修後の結合テスト期間、繁忙期を避ける日程を含めて設定します。
3. 代替策の検討または更新保留
非対応プラグインの代替がない、改修の再現性が低い、検証環境を本番相当にできない場合、更新保留は合理的な選択肢になり得ます。ただし「今回は見送る」で終わらせず、以下を記録します。
- 保留対象と保留理由
- 現行PHP・OS・ホスティングのサポート状況を確認した日
- 継続運用中に行う監視、バックアップ、障害対応の責任者
- 次回判断日と、その時点までに解消すべき条件
- 代替プラグイン、独自開発、カート移行を比較する場合の評価担当
更新を急ぐことだけを正解にすると、繁忙期に受注・決済のリスクを持ち込むことがあります。一方、保留には現行環境を維持する保守コストと、将来の移行差分が増える可能性があります。両方を台帳に記録し、事業判断として承認します。
受入テストは「画面」ではなく業務の完了で設計する
互換性台帳の各行には、対応状況だけでなくテストケースIDを紐付けます。重要なのは、機能名ではなく、開始から完了までの業務でテストすることです。
最低限、実際に利用している条件に絞って、次を確認します。
- 商品表示、在庫表示、バリエーション・オプション選択、カート投入
- 会員登録、ログイン、パスワード再設定、会員価格やポイントなど利用中の施策
- クーポン、送料、手数料、税、値引きを含む注文金額
- 決済の開始から注文完了、管理画面の受注作成、通知メール
- 取消・返金など、利用している決済・受注操作
- 出荷CSV、配送連携、在庫連携、会計連携など後続処理
- 管理画面の権限別操作、定期実行処理、エラーログと監視通知
金額は注文合計だけでなく、商品小計、値引き、送料、手数料、税額、請求額を個別に比較します。表示が正しくても、外部連携へ渡す値が異なる可能性があるためです。
テスト結果には、実施日時、環境、テストデータ、担当者、結果、障害チケット、スクリーンショットやログの保存先を残します。障害が見つかった時点で台帳の判定を「要対応」に戻せるようにし、口頭の完了報告だけで進めないようにします。
リリース判定と切り戻し条件を、更新前に合意する
本番更新の直前に初めて「戻せるか」を考えると、判断が遅れます。互換性台帳とは別に、リリース判定表を作成してください。
判定表には、更新開始時刻、更新停止期限、バックアップ取得時刻、DB変更の有無、切り戻し手順、決定権者、連絡先を記載します。切り戻しでは、アプリケーションのファイルを戻すだけで復旧できるとは限りません。DBマイグレーション、決済側の取引状態、更新中に発生した注文、外部連携の再送をどう扱うかを確認します。
切り戻しの可否が未確認なら、本番作業前に検証環境で復元手順を試します。特に「注文を受け付けた後に戻す」場合の運用は、技術担当だけで決めず、受注・CS・物流・経理の担当者と扱いを合意します。
互換性台帳は、4.4へ一度上げるためだけの資料ではありません。プラグイン追加、決済変更、PHP更新、保守委託先の変更時にも更新し続ければ、次回の更新範囲と確認責任を短時間で把握できます。まずは本番環境の事実を記録し、対応根拠のない項目を可視化するところから始めてください。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。