何を更新すべきか分からない
運営担当者がEC-CUBEの管理画面だけを確認し、PHPやサーバーの修正状況は分からない。
環境と担当を分け、更新対象の抜けを減らす
PHPの提供元、本体・プラグイン、独自改修を棚卸しし、ホスティング会社と保守会社へ確認する内容を揃えます。
EC-CUBEのPHP対策
更新と保守の判断
PHPを更新すると、購入や決済が止まらないか。今のプラグインや独自処理を残せるか。保守を続けるのと移行するのと、どちらが現実的か。
まず更新対象と担当を確かめ、購入から受注・出荷までの動きを検証します。リベレーターズは、現行環境の調査、互換性の確認、更新・復旧の計画から、継続保守と移行の比較まで支援します。
購入画面が開くだけでは、
確認は終わりません
- 商品・カート価格・送料・在庫
- 決済成功・失敗・キャンセル
- 受注・通知受注登録・結果反映・メール
- 在庫・出荷基幹連携・出荷指示
お客様の操作と、運営側の処理を一連で検証
PHPとEC-CUBEは、別々に対策状況を確認する
PHPはEC-CUBEを動かすソフトウェアです。EC-CUBE本体やプラグインを更新しても、サーバー側のPHPまで修正されるとは限りません。PHPの修正版が適用されたかと、ECの機能が正常に動くかを分けて確認します。
今回のPHP脆弱性・修正版と初動の説明は、PHP脆弱性対策・更新支援にまとめています。このページでは、EC-CUBE固有の互換性、購入・決済、受注連携、更新後の運用を扱います。
EC-CUBE公式のPHPセキュリティリリースの事前案内も、本体・プラグインとの互換性や購入・決済の動作確認を求めています。同案内はリリース前の情報です。最新の修正情報はPHP公式・提供元の告知と照合します。（2026年10月22日確認）
止まっている判断を、確認できる作業に変える
更新で売上が止まるのが怖い
カートの表示は確認できても、決済結果が受注や在庫に正しく反映されるか試せていない。
受注漏れ・二重処理を切替前に見つける
決済成功だけでなく、失敗やキャンセル、通知の再送も含めて、担当者が運営画面で結果を照合します。
保守を続けるか移行するか迷う
更新のたびに見積もりが増え、どの機能が費用や調整の原因なのか分からない。
必要な販売業務を残す方法に予算を配分する
保守継続・部分改修・Shopify移行を、同じ機能と期間の費用で比較し、段階的に改善する範囲を決めます。
上記は支援の作業例です。個別環境の診断結果や、今回のPHP脆弱性への対応実績を示すものではありません。
更新前に、環境・機能・担当を棚卸しする
「EC-CUBEを使っている」だけでは、更新できる範囲は決まりません。正確なバージョンと提供元、必要な業務を確認します。
- サーバーとPHP
実際にWebリクエストを処理するPHPの版・提供元・実行方式、OS、データベース、拡張機能を確認。管理画面・コマンドライン・別サーバーで異なる構成も切り分けます。
確認先：ホスティング会社・サーバー管理者- EC-CUBE本体と拡張
本体の正確な版、決済・配送・会員・検索のプラグイン、独自の送料や購入処理、外部連携を一覧にします。各提供元の対応条件と、改修したコードを照合します。
確認先：制作・保守会社、プラグイン提供元- 運営と切替の条件
受注が増える時間帯、停止できる時間、更新中の注文・決済通知の扱い、バックアップと復元方法を確認。販売側と保守側で、誰が何を確認して公開判断するかを決めます。
確認先：EC運営責任者、保守・連携の担当者
「2系・4系」だけで更新可否を決めない
例えばEC-CUBE 2.25の公式発表にはPHP 8.4対応が記載されています。系統名だけで「古いPHPしか使えない」「移行が必須」とは判断せず、稼働している正確な版と更新先の公式要件を確認します。
本体が対応していても、決済プラグイン・独自改修まで対応する保証にはなりません。また、動作要件を満たすことと、PHPのセキュリティサポート・修正提供が続いていることは別です。
参照：EC-CUBE4のシステム要件、本体の最新リリース情報、EC-CUBE 2.25の公式発表（2026年10月22日確認）。実環境の互換性は検証で確かめます。
購入・決済は、運営側の結果まで照合する
普段の注文と、問題が起きたときの注文を両方試します。決済会社のテスト環境など、合意した試験方法を使い、請求・顧客通知・在庫への影響を管理します。
| 業務 | 試す操作・条件 | 照合する結果 |
|---|---|---|
| 商品・カート | 商品規格、数量変更、会員価格、クーポン、送料、税率 | 表示金額・在庫と、注文確定時の金額が一致する |
| 会員・購入 | ログイン、ゲスト購入、配送先変更、購入画面の入力・確認 | 入力内容が保持され、必要な権限・購入条件が働く |
| 決済 | 成功、失敗、キャンセル、追加認証、画面を閉じた場合 | 決済事業者側の結果・金額・注文番号と、EC-CUBEの受注が対応する |
| 通知・受注 | 決済結果の通知、通知の遅延・再送、受注メール | 未反映を検知でき、同じ通知で受注・請求・在庫処理が重複しない |
| 在庫・出荷 | 基幹・在庫・倉庫システムへの連携、バッチ処理、出荷指示 | 注文データが引き渡され、失敗時に気づき再処理できる |
| 取消・返金 | 店舗で使う取消・返金・在庫戻しの操作 | EC側・決済側・連携先の処理結果と担当者の確認記録が揃う |
テストの成果物は、条件・期待結果・実際の結果・残課題を記録した検証表です。画面がHTTP 200で表示されたことだけで、決済・受注が正常と判断しません。
本番反映と、問題が出たときの戻し方を先に決める
復元と検証の準備
ファイル・データベース・設定のバックアップと、実際に戻せる手順を確認。検証環境で更新・主要業務を試します。
決めること：対象、復元方法、受入条件注文と通知の扱いを合意
反映中の注文受付・決済通知・定期処理をどう扱うか、保守会社と運営側で決定。必要な停止時間と担当者を揃えます。
決めること：作業時間、停止条件、連絡先反映後に実稼働を確認
PHPの適用状況と、購入・決済・受注・連携の結果、エラーログを確認。未確認の処理は残課題として明示します。
確認すること：実行中の版と業務の結果問題時は注文差分も照合
データを過去へ戻すと、反映後の注文が失われる可能性があります。決済側の記録・受注・在庫との差を照合し、再開条件を確認します。
確認すること：注文の欠落・重複、再開判断
未対策の版へ戻すだけで対応完了にはしません。必要な公開制限なども含め、修正を適用して再開する方法を再検討します。不正アクセスが疑われる場合はログを保全し、ホスティング会社や専門窓口と調査範囲を確認します。
緊急対応の後に、継続保守・部分改修・移行を比較する
移行するまでの間も、現行環境への対策は必要です。移行先を先に決めず、残したい販売業務と更新を続ける体制から選びます。
EC-CUBEを保守して使い続ける
必要な機能が今の仕組みに合い、対応版への更新と定期的な確認を継続できる場合。更新の担当・頻度・検証項目・費用を契約と運用へ落とします。
確認：更新可能性と継続体制更新を妨げる部分を改修する
特定のプラグインや独自処理に原因がある場合。不要な機能を整理し、代替・個別改修・外部連携の分離で、今の販売業務を活かせるか検討します。
確認：改修範囲と依存する機能Shopifyなどへ移行する
更新調整の負担が大きく、必要な業務を移行先で構成できる場合。会員・決済・受注・基幹連携・URLを検証し、初期費と運用費を比較します。
確認：業務の引継ぎと総費用移行する場合の詳しい依頼範囲とSEO・費用の考え方は、EC-CUBEからShopifyへの移行支援で確認できます。現行保守を続ける判断も含めて相談できます。
費用は、調査・改修・反映・保守を分けて確認する
見積もりに含める範囲
- 構成と修正状況の調査、更新計画
- 本体・プラグイン・独自機能の互換性改修
- 購入・決済・外部連携の検証
- 本番反映、注文差分・復旧の確認
- 継続保守、または移行の調査・検証
環境数、正確な版、改修履歴、検証環境の有無、決済・連携の種類、停止条件で作業量が変わります。サーバー・プラグイン・外部サービスの利用料も、支援費とは別に確認します。
相談前に分かる範囲で用意するもの
- サイトURL、EC-CUBEとPHPの版
- 利用中の決済・配送・主要プラグイン
- 独自機能、基幹・在庫・出荷の連携
- 保守会社の有無、現在の不具合
- 止められない業務、希望時期・予算条件
不明な項目はそのままで構いません。フォームにパスワードやAPIキーを記載せず、必要なアクセス方法は調査範囲を決めた後に確認します。
対応範囲・費用・作業時期は調査条件を確認して合意します。即時着手・24時間対応・無停止を保証するものではありません。現在の保守会社との協業も含めて進め方を検討できます。
リベレーターズに更新・保守を相談する理由
少数精鋭のチームに、代表がPMとして参加。事業の課題整理から設計・開発・運用まで支援します。
EC-CUBEのPHP対策でよくある質問
Q
EC-CUBEを更新すればPHPの対策も完了しますか？
別に確認します。EC-CUBE本体・プラグインの更新と、サーバー側のPHPへの修正適用は同じ作業ではありません。実際に動くPHPの提供元と修正状況を確認したうえで、購入・決済・受注連携を検証します。
Q
EC-CUBEの版が古いと、Shopifyへの移行が必要ですか？
系統名や古さだけでは判断しません。正確な版と更新先の要件、プラグイン・独自改修、保守体制を確認します。継続保守や部分改修で必要な業務を続けられるかを比較し、移行はその後の選択肢として検討します。
Q
購入画面が正常に表示されれば大丈夫ですか？
表示だけでは判断できません。決済結果と受注番号・金額、通知メール、在庫・出荷連携まで照合します。失敗・キャンセル・通知の遅延や再送時の挙動も、店舗で使う方法に合わせて確認します。
Q
すぐにPHPを更新できない場合はどうすればよいですか？
更新できない原因と提供元の修正状況を保守会社と確認し、必要な暫定措置・公開範囲・改修順を検討します。移行の完了を待って現行環境の対策を先送りするのではなく、修正を適用する計画を別に進めます。
Q
更新時にサイトを止める必要はありますか？
環境と作業内容によります。停止の要否、注文受付や決済通知の扱い、切替時刻、問題時の戻し方を事前に決めます。無停止を前提にせず、運営上の条件に合わせて方法を検討します。
Q
保守会社がいても相談できますか？
相談できます。現在の保守契約と担当範囲を確認し、環境調査、互換性改修、受入確認、切替の役割を整理します。技術的な判断や検証計画だけを先に依頼する進め方も含めて検討できます。
Q
更新後に問題が出たらバックアップへ戻せばよいですか？
戻す対象と期間によっては、新しい注文が欠落したり、決済・在庫の状態がずれたりします。復元手順と注文差分の照合、再開条件を先に決めます。未対策の版に戻しただけで対応完了とは扱いません。
次に検討する支援
更新の見通しが立った後、保守調整と販売機能を長期的に見直す場合は、EC-CUBEからShopifyへの移行支援で、業務を引き継げる範囲と総費用を比較します。
継続保守を選び、社内と保守会社の判断・改修の優先順位を揃えたい場合は、顧問・アドバイザリ支援へ。公開実績一覧から関連する開発・移行の事例も確認できます。
今のEC-CUBEを、どう更新し、どう使い続けるか
利用環境と止められない販売業務を伺い、調査・検証・更新の進め方を整理します。継続保守と移行の比較もご相談ください。
EC-CUBEの更新・保守を相談する